A CI pipeline that pushes nightly builds to a PostgreSQL replica keeps a static service‑account password in a shared secret store, while an offboarded contractor’s key remains active because the team never rotates it. When a security auditor asks for proof that every machine‑initiated query to the cardholder‑data database was authorized and logged, the answer often reads, “we have logs, but they are incomplete and the credentials are still in use.” This scenario shows why non‑human identities pose a unique challenge for PCI DSS compliance.
Why the current approach falls short of PCI DSS expectations
Most organizations treat service accounts like human users: they grant broad database privileges, store the credential in a configuration file, and rely on the database’s native audit log. The setup satisfies the basic requirement that an identity exists, but it does not satisfy PCI DSS requirement 10, which demands detailed tracking of who accessed cardholder data and when. The audit records tie to the database process, not to the individual machine identity, and they cannot prove that a particular CI job or automation script received approval before it ran. Because the credential never changes, a compromised secret can be used indefinitely, violating the principle of least privilege and the requirement to protect stored cardholder data.
What a proper control model must include
To meet PCI DSS, a control model for non‑human identities needs three pieces:
- Identity verification: each machine must present a token that proves its membership in a specific service‑account group.
- Enforcement at the data path: the gateway that actually talks to PostgreSQL must approve, block, or mask requests before they reach the database.
- Continuous evidence: every approval decision, command execution, and data response must be recorded in an immutable audit trail that auditors can review on demand.
If the first two items succeed but the data‑path enforcement point is missing, the organization cannot generate the third. The enforcement outcomes, session recording, inline masking, just‑in‑time approval, appear only when a gateway sits between the identity provider and PostgreSQL.
How hoop.dev provides PCI DSS evidence for PostgreSQL
hoop.dev is a Layer 7 gateway that proxies PostgreSQL connections. It authenticates machines via OIDC or SAML, reads group membership, and then decides whether the request may proceed. Because the gateway sits in the data path, it enforces policies that the database itself cannot.
hoop.dev records each session, captures the exact SQL statement, and stores the result of any masking operation. hoop.dev stores every approval decision, each command execution, and every data response in an immutable audit trail. If a query attempts to read a column that contains PAN (primary account number), hoop.dev masks that field in real time, ensuring that the raw PAN never leaves the gateway.
When a high‑risk operation, such as a bulk export of transaction tables, arrives, hoop.dev pauses the request and routes it to a human approver. The approver’s decision logs alongside the session, creating a concrete audit record that satisfies PCI DSS requirement 10. Because hoop.dev stores the credential used to connect to PostgreSQL, the machine never sees the password, eliminating the risk of credential leakage.