Auditiable Access
You build auditiable access by tying every database query and server command to one person. Teams do this by linking identity tools to system roles and saving every action log. Many teams start by sharing a single admin key across the whole group. When someone runs a bad query, nobody knows who did it. Broad permissions make this problem much worse. One shared login can read or delete data without leaving a clear trail. How to set up auditiable access with native roles To fix shared logins, y
Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build auditiable access by tying every database query and server command to one person. Teams do this by linking identity tools to system roles and saving every action log. Many teams start by sharing a single admin key across the whole group. When someone runs a bad query, nobody knows who did it. Broad permissions make this problem much worse. One shared login can read or delete data without leaving a clear trail.
How to set up auditiable access with native roles
To fix shared logins, you must give each person a unique user account. You can link your main identity provider to your cloud servers and databases. When an engineer needs to work, they log in with their own email. The identity tool checks their group and maps them to a database role. This role holds the exact permissions they need for their job.
Next, you must turn on native logging inside each database and server. The system records the user name, the time, and the session start. You then send these logs to a central log storage bucket. Security teams lock this bucket so nobody can alter or delete past records. Now you have a basic trail of who logged into each system.
Teams also set up role rules to limit what users can do. You can create a read role for daily checks and a write role for fixes. Engineers only use the write role when they must fix a broken table. This native workflow stops people from using admin keys for simple tasks.
What native roles solve and what they miss
Native roles and login logs solve the first half of the audit puzzle. They tell you who opened a session and when they logged in. They also stop outsiders from getting into your servers with stolen static keys. Auditors like to see that every person has their own account.
Still, native setups leave a huge gap during the active session. A role decides who can log in, not what each command does in flight. Once an engineer logs in, the role lets them run any allowed query. Native logs often miss the exact text of every command or query. Turning on full query logging inside a database can slow down the whole server.
Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native roles also fail to filter out private data from query results. If a user has read rights on a table, they read the whole table. The database sends back raw emails, phone numbers, card numbers, and national IDs. You cannot use a basic role to rewrite matched fields in results on the fly. Also, native tools cannot pause a dangerous delete command to ask a peer for approval.
Why command-level logs matter for security reviews
During a security review, auditors ask for more than just login times. They want to know which exact records a user read or changed. If a breach happens, login logs only show that an engineer was online. They do not prove what data left the server during that hour.
Command-level logs record the exact action, the user identity, and the timestamp together. When you capture every query and command, you remove all doubt during an audit. You can see every table read and every system fix in one place. Teams also need a way to mask sensitive fields before results reach the screen. Rewriting card numbers and national IDs in results keeps private data safe during daily work.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between login logs and auditiable access?
Login logs only show when a user entered a server or database. Auditiable access records every single query or command that user ran during the session.
Why do shared admin accounts fail security audits?
Shared accounts hide the true person behind an action. When five people use one key, you cannot prove who deleted a table.
How does data masking help during daily database checks?
Data masking rewrites matched fields like emails and phone numbers in query results. Engineers can fix bugs using real tables while private data stays hidden.