# Database Data Protection

> Database data protection at the database layer comes down to two controls: gate access just-in-time (who can connect, with what role, for how long) and mask at query time (what's actually returned, based on the requester's role). Plus engine-native masking for Postgres, MySQL, Snowflake, and the Postgres RLS alternative when a workflow gateway isn't an option.

Source: https://www.bytebase.com/database-data-protection/

---

## Sensitive data. Gated and masked.

Database data protection at the database layer comes down to two controls. Gate decides who can reach the data and for how long. Mask decides what they see when they do.

## Two controls. One sensitive dataset.

### Gate

Who can connect, with what role, for how long. Just-in-time grants replace standing credentials. Requests carry a stated reason, route to an approver, expire on a clock. Standing privileges fall to near zero; every access has a documented trail.

### Mask

What's actually returned. Dynamic data masking transforms sensitive values at query time based on the requester's role — full value for one user, hashed for another, last-four for a third. The data at rest does not change; the SELECT result does.

## Read in order.

### Start with the principles

The four questions every access control system has to answer, with engine-specific GRANT syntax for Postgres, MySQL, SQL Server, and Oracle. /blog/database-access-control-best-practices

### Gate access just-in-time

Walks through the JIT workflow end-to-end — request, approval rules, time window, auto-revoke. Why standing access is the wrong default. /blog/just-in-time-database-access

### Mask what they shouldn't see

DDM as a practical primitive — what query-time masking transforms, where it differs from static masking, and the policy patterns that govern who sees what. /blog/what-is-dynamic-data-masking

## Get Started

- [Contact us](https://www.bytebase.com/contact-us/)
- [Start now (cloud)](https://console.bytebase.com)