Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Workforce and services marketplace platform |
| Company Size | Roughly 300 employees |
| Cloud Environment | AWS (production and non-production accounts) |
| Databases | Amazon Aurora MySQL on RDS, about ten instances |
| Compliance | ISO 27001 and SOC 2, previously supported by a cloud security tool |
| Access Model | Just-in-time database access with maker and approver roles |
| Current State | Access approvals are logged; the statements run during each session are not captured in a searchable audit trail |
| Focus Area | Evidence of what happened inside database sessions |
The Situation: Strong on Who, Silent on What
This team takes audits seriously. They achieved ISO 27001 and SOC 2 with a cloud security tool in place, they keep production access to a small group, and they adopted just-in-time database access so that no engineer holds a standing production password.
That model produces excellent answers to one set of questions. Who requested access to which database? Who approved it? For how long? When did it end? Every one of those facts is recorded and can be shown on demand.
The next question in an access review is a different one: what did they do while they were connected? For that, the evidence thinned out. Aurora can be configured to emit audit and general logs, but those logs are written from the database’s point of view. They show connections and statements under the database user in play, and when that user is a shared or role-based identity the log cannot say which human ran which statement. The team’s own engineers had already raised the same gap internally. They wanted database logging correlated with the developer who ran each statement, and they wanted to know how to query the log data once it landed in storage.
The Core Tension
Auditors work backwards from risk. The risk in a production database is not that someone connected. It is that someone read or changed data they shouldn’t have. Evidence that proves a connection was authorized is necessary, but it is not evidence that the activity inside the connection was appropriate.
The usual responses are unsatisfying. Turning on native database auditing produces large, unstructured logs that nobody can easily search and that do not map to a person. Buying a traditional database activity monitoring product solves the logging but typically routes query traffic through the vendor’s infrastructure, which sits badly with a team that avoids adding third parties and wants production data to stay in its own accounts.
Where the Gaps Were
No Link Between the Approval and the Activity
The approval record lived in one system and database logs lived in another. Connecting them meant matching timestamps by hand and guessing, with a shared database user standing between the two. An auditor asking “show me everything this person ran under this approval” had no single place to look.
Logs Existed but Were Not Usable Evidence
Raw database logs are voluminous and not designed for retrieval by person, table, or time window. During an audit, the effort of finding the three relevant statements inside gigabytes of log text is exactly the kind of work that stretches an audit from days to weeks and pulls engineers away from their jobs.
No Visibility Into Volume
An auditor does not only care that someone queried the worker table. They care whether it was 12 rows or 1.2 million. Connection-level logging does not say.
Blocked or Rejected Activity Left No Trace
A dangerous statement that was attempted is itself a signal. Without a layer that evaluates statements before execution, there is no record of attempts, only of what ran.
The Evidence Had to Stay in the Customer’s Own Account
The team’s preference is to keep production data and the records about it inside its own AWS accounts. A solution that exported query text to an external SaaS to store the audit trail would trade one compliance question for another.
How Cloudanix Addresses This Situation
A Query Proxy That Sees Every Statement
Cloudanix Database Activity Monitoring runs as a secure query proxy in the customer’s own AWS account, on the same container infrastructure used for Database JIT. Once a person has approved access, every SQL statement they send passes through the proxy before it reaches Aurora. The proxy is where the record is created, so nothing depends on a database setting someone might forget to enable.
What Each Audit Record Contains
For every query, DAM stores full state and metadata:
- The identity of the real person who ran it, not a shared database user
- The statement itself
- The database, tables, and columns it touched
- The time it ran and how long it took
- How many rows it returned
- Whether it ran, was masked, or was blocked by a guardrail, and which rule applied
Because DAM is built on the same lifecycle as JIT, each record carries the approval it was run under. An auditor can follow one line from request, to approver, to every statement executed in the session.
Searchable by the Questions Auditors Ask
The audit trail is written to storage in the customer’s own AWS account, and it is queryable and searchable. Typical audit questions become simple lookups:
| Audit question | How the trail answers it |
|---|---|
| Who accessed the worker records table last quarter? | Filter by table and date range |
| What did this engineer run during their approved session? | Filter by identity and session |
| Did anyone pull a large volume of personal data? | Filter by row count above a threshold |
| Were any destructive statements attempted on production? | Filter by blocked statements |
| Does executed activity match the approved change? | Compare the session’s statements with the approval and ticket reference |
Blocked Attempts Are Evidence Too
Guardrails evaluate statements before execution. A DELETE without a WHERE clause, an attempt on a restricted table, or a request exceeding the row limit is stopped and logged with the rule that stopped it. Showing an auditor that unsafe actions were prevented, not merely detected afterward, is a stronger control narrative than showing that logs exist.
Anomaly Detection on Top of the Trail
Because every statement flows through one place, DAM can also flag unusual patterns, such as a session pulling far more rows than is typical or querying tables outside an identity’s normal behavior. Treat these as prompts for review. They sit alongside the preventive guardrails and the audit record rather than replacing them.
Evidence That Does Not Leave Your Account
Both the proxy and the audit store live in the customer’s AWS environment. The records that prove compliance are held by the same team that is being audited, under their own retention and access controls, with no external system holding copies of query text.
See Cloudanix DAM in Action
In this 2-minute interactive walkthrough, see how Cloudanix DAM inspects, masks, and records queries, with your data never leaving your cloud.
How This Maps to the Frameworks
DAM provides evidence. It does not replace the judgement of an auditor or the written policies your framework requires. What it contributes is the data behind the controls that auditors test for.
- ISO 27001: Access control, logging and monitoring, and information-access restriction controls all ask for evidence that access is limited, logged, and reviewed. Query-level records, masking policies, and guardrail logs give you artifacts for each.
- SOC 2: The Security and Confidentiality criteria expect that access to sensitive data is restricted, monitored, and that activity can be reviewed. A searchable trail tied to an approval supports the monitoring and review points.
- Periodic access reviews: Instead of reviewing who has access, reviewers can see what that access was used for.
What to Know Before You Start
- DAM covers MySQL (including Aurora MySQL) for this scenario. Other engines in the same environment, such as a hosted document store, are not part of this audit trail today.
- Only activity that passes through the proxy is recorded. To make the trail complete, retire shared database credentials so the proxy path is the only path. Database JIT’s short-lived, per-session credentials are what make that practical.
- The audit trail records what the database was asked and what it returned in terms of volume. Retention period and access to the audit storage are settings you control, so decide them in line with your framework’s evidence requirements.
Platform Impact
| Dimension | Before | After (DAM audit trail) |
|---|---|---|
| Evidence of approved access | Strong | Strong, and linked to activity |
| Evidence of what ran | Raw logs under a shared DB user | Every statement attributed to a named person |
| Time to answer an auditor’s query | Manual log search across systems | A filtered search on one trail |
| Visibility into data volume | None | Row count on every query |
| Prevented attempts | Not recorded | Logged with the blocking rule |
| Where evidence lives | Mixed | Your own AWS account |
Key Outcomes
- ✅ Who and What: Approval records and executed statements in a single trail.
- ✅ Named Accountability: Every query attributed to the person who ran it.
- ✅ Fast Audit Responses: Searchable by person, table, time, and row count.
- ✅ Preventive Evidence: Blocked statements are logged along with the rule.
- ✅ Data Sovereignty: Proxy and audit store stay in your own AWS account.
- ✅ Built on JIT: Access control and data control follow the same lifecycle.
Can You Show an Auditor What Happened Inside the Session?
If your access approvals are airtight but you cannot show the statements behind them, Cloudanix DAM gives you query-level evidence that is searchable, attributable, and stored in your own cloud.
Book a Free Assessment to see a live audit trail on your own MySQL environment in under 30 minutes.
Related Resources
- Closing the Audit Trail Gap: From Missing Logs to Complete JIT Access Auditing
- Query-Level Audit and PII Masking for MySQL OLTP Databases in a Multi-Cloud FinTech
- Database Activity Monitoring: Real-Time Data Security
- What is SOC 2 Compliance?
- Database Activity Monitoring Use Cases: How DAM Prevents Data Loss
