Data masking

Data masking redacts sensitive columns in query results before they leave the agent. Masking is configured per connection.

Rules

A masking rule matches columns by a glob pattern on the bare column name (e.g. email or *_email, case-insensitive; a table-qualified pattern such as *.email does not match a column called email). The first matching rule wins. Each rule applies a strategy:

• Redact — replace the value with *****. The value is overwritten, not removed; the column stays in the result.
• Hash — replace the value with its SHA-256 hash.
• Partial — keep the first N and the last N characters and replace the rest with *. N defaults to 3. If the value is 2N characters or shorter, the whole value is masked.

Table-scoped rules

A rule can name a table (billing.customers, billing.*, or a bare customers for any schema) so it applies to that table only. On PostgreSQL the agent matches the table each value comes from. On MySQL, MongoDB and SQL Server the table is not known, so a scoped rule masks the column in every table: it can mask more than you scoped, never less.

Exemptions

Choose Exempt instead of a strategy to pass a column through and keep automatic detection off it, for a column that only looks sensitive (an internal ID that happens to validate as a CPF). A masking rule that matches always wins over an exemption. A table-scoped exemption only applies where the table is known (PostgreSQL).

Automatic detection

Besides rules, each connection can detect sensitive values by itself:

• Off (default): only rules mask data.
• Best effort: masks values with a strong signature, checked by their check digits or structure: payment cards (Luhn and a known issuer prefix), IBAN, CPF, CNPJ, e-mail, UUID, IP and MAC addresses, and the formatted Brazilian identifiers below. Near-zero false positives.
• Strict: also masks columns by name in the selected languages (pt-BR, en-US): salario, rg, cnh, ssn, ... More coverage, more chance of masking a column that is not sensitive.

Automatic detection runs only while masking is on for the connection, and rules always win. Set it in the connection's masking editor, or with the CLI:

relay connections masking set pg-prod --auto-mode best_effort
relay connections masking set pg-prod --auto-mode strict --locale pt-BR --locale en-US

Each detected category has a default strategy: identifiers and cards are redacted, e-mail, phone and postal code are partially shown, UUIDs hashed.

Brazilian identifiers

Every recognizer checks the official check digits, so a number with the right shape but a wrong check digit is not masked. Identifiers with a single check digit are only recognized when formatted, since a bare number would validate by chance too often; their bare form is caught by column name in strict mode.

Custom detectors

Add your own formats (an internal account number, for example) as RE2 regular expressions. A pattern must match the whole value, can be up to 512 characters, and an invalid pattern is rejected when you save. Up to 32 per connection. They run before the built-in detectors, even with automatic detection off, and use the strategy you pick.

Reviewing detected columns

The Detected columns list on the Masking page shows the columns automatic detection (or a custom detector) masked, by connection, table and category. Only names are reported, never values. Accept keeps masking the column with an explicit rule; Exempt adds an exemption for it.

Precedence for one value: masking rule, then exemption, then custom detector, then built-in detector, then column name.

Enabling masking

Turn masking on for a connection and manage its rules from the connection's editor. The Masking page lists connections and lets you toggle redaction per connection.