Administrators · Privileged access (PAM)
Recorded database sessions (PostgreSQL)
Not available yet
This article describes a feature in development. You cannot use it yet; the article is here to help you plan.
Privileged access is being extended to databases. People keep their usual client (psql, DBeaver, DataGrip) and connect through the privileged access gateway. The gateway signs in to the database with the vaulted or temporary credential, which the person never sees, and records every statement. PostgreSQL comes first; MySQL/MariaDB and Microsoft SQL Server follow later.
Is it available?
Not yet. The database proxy is built and tested against PostgreSQL 18, but the gateway listener, the console screens and the connection tickets are still in development. This article describes how it will work, so that you can plan targets, profiles and rules.
How will a connection work?
- The person requests the database account under «Access» › «My access» and, once approved, activates the access.
- They ask for a connection. The console shows the gateway host, port 6432, the user (the access handle, which starts with
l-) and a single-use password, the connection ticket, valid for one minute. - The client connects over TLS and checks the gateway's certificate (
sslmode=verify-full). Connections without TLS are refused. - The gateway redeems the ticket, opens its own TLS connection to the database, checks that the database's key is the one you confirmed for the target, and signs in with SCRAM-SHA-256.
What is recorded?
| Recorded | Not recorded |
|---|---|
| Each statement, its duration, the command result, the rows affected and errors | The result rows |
| The text of prepared statements | Parameter values, unless the profile asks for them (by default only their number and types) |
| The size of a COPY | The content of a COPY |
Statements that contain PASSWORD are always redacted. A profile can also redact the literal values in the statement text ('…' becomes '?'). Recordings are encrypted, sealed and kept like SSH recordings.
Can I block dangerous statements?
Each access profile will hold up to 64 rules (regular expressions), each with an action: raise an alert, end the session, or block the statement. Treat blocking as a guard rail: dynamic SQL can avoid a pattern. The real control is a least-privilege or temporary database role for each access.
What does the gateway refuse?
- connections without TLS, and replication connections;
- a ticket used twice, expired or meant for another person;
- a database other than the access's own, unless the target allows the choice;
- a database whose key does not match the confirmed one;
- MD5, GSS or SSPI sign-in to the database.
When the access period ends, or when an administrator ends the session, the person's client receives the reason and both connections close.
Was this page helpful?
Thank you. Your answer stays in this browser; nothing is sent.
Sorry about that. Try:
- searching for the exact text of the message or the error code
- the error code index
- asking your organization's administrator