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 across two VPCs |
| Sensitive Data | Worker and customer personal details, onboarding records, payment-related records |
| Support Access | Support team reads production data through a BI tool in read-only mode |
| Compliance | ISO 27001 and SOC 2 |
| Focus Area | Giving support the context they need without exposing raw personal data |
The Situation: Read-Only Is Not the Same as Safe
This platform connects a large pool of workers with the businesses that need them. That means the production database is full of people: names, contact details, identity and onboarding records, and payment-related information for workers and customers alike.
The team had already made a sensible decision about who may touch that database. Direct access was restricted to a small DevOps group. The support team, which handles questions from workers and customers every day, used a business-intelligence tool configured read-only. Support could look but not change.
Read-only addressed the risk of accidental modification. It did not address the risk of exposure. A BI tool connected to a production database with a read user shows whatever that user can read, and in a database where the user has SELECT on the table, that means every column of every row. A support agent looking into one worker’s payout question could scroll, filter, and export the entire population’s contact and payment-related fields. Nothing about the tooling said they shouldn’t.
The Core Tension
Support genuinely needs production visibility. Telling them to work from screenshots or escalate every question to engineering is not realistic when the platform handles customer issues all day. But the need to see this worker’s payout status is not the same as a need to see every worker’s bank details. The task calls for the former. A read grant provides the latter.
Native database controls do not close that gap cleanly. A MySQL role can allow or deny access to a table, and in some designs to a column. It cannot say “show this agent the last four digits and mask the rest,” and it cannot present different views of the same query to different roles. The usual workaround is building and maintaining sanitized copies or views for support, which adds a second data pipeline that drifts out of sync and quietly becomes its own risk.
Where the Gaps Were
Every Column Is Visible to Every Reader
A read user sees plaintext. There is no distinction between the columns support needs to resolve a ticket, such as status, dates, and the last few digits of an identifier, and the columns they do not need, such as full contact numbers, national identity details, and complete payment fields. Under ISO 27001 and SOC 2, and under any privacy regime that expects access to personal data to be limited to a legitimate and scoped need, blanket visibility is the finding an assessor goes looking for.
Exports Were Unconstrained
A BI tool is built to pull data out. Filters, saved queries, and CSV downloads are features. For a support workflow that means the distance between “looking up one record” and “downloading the population” is a few clicks, with no control to stop it and often no record that it happened.
Sanitized Copies Would Create a New Problem
Maintaining a masked replica or a set of views for support is the traditional answer. It means more infrastructure, a refresh pipeline, schema drift each time the application changes, and a second place where sensitive data lives. For a team that prefers a lean footprint, that trade was unattractive.
Sending Production Queries to a Vendor Was Not an Option
A hosted masking or monitoring service would put production query text and result sets on infrastructure the team does not control. For a platform whose business is people’s personal data, that was unacceptable regardless of the features on offer.
How Cloudanix Addresses This Situation
Masking at the Query Layer: One Database, Different Views by Role
Cloudanix Database Activity Monitoring places a secure query proxy between users and the Aurora MySQL databases. The proxy runs on the customer’s own container service in their own AWS account. When a query returns results, DAM applies masking policies after execution and before the rows reach the user, based on who is asking.
The same SELECT therefore returns different results depending on the role:
| Column type | Support role sees | Role with a verified need sees |
|---|---|---|
| Email address | a****@example.com | Full address |
| Phone number | ******4821 | Full number |
| Government or identity number | Fully masked | Last four digits |
| Bank or payment identifier | Hashed or redacted | Unmasked, for authorized finance roles only |
| Free-text fields holding embedded identifiers (JSON) | Masked at the specified JSON path | Unmasked |
Nothing about the underlying tables changes. There is no copy, no view, and no application modification. The database keeps one set of data, and the proxy decides what each reader is permitted to see of it.
Eight Masking Strategies, Matched to the Field
Different fields need different treatment, so DAM offers several strategies: full mask, show last four, show first four, mask email, mask phone, hash, redact, and tokenize. Hashing, for instance, lets support confirm that two records share the same identifier without ever seeing it. Masking applies to JSON fields via path-based rules, which matters when sensitive values are embedded inside a JSON column. Aggregate masking applies as well, so a COUNT or a GROUP BY cannot be used as a side channel to reconstruct what a mask was hiding.
Guardrails Contain the Export Risk
Masking controls what is visible. Guardrails control how much can be pulled. Administrators can set row-count limits and restrict specific tables or columns for a role, so a support session cannot return a million rows or touch a table that has no place in a support workflow. Statements that would modify or destroy data, such as DELETE, DROP, and TRUNCATE, can be blocked outright, and a missing WHERE clause can be rejected. A blocked statement returns a clear message naming the rule.
Every Support Query Is Attributed and Recorded
DAM logs each statement to storage in the customer’s own account: who ran it, when, which tables and columns, and how many rows came back. When someone asks “who looked at this worker’s record, and why,” the answer is a search, not a reconstruction.
Access Is Still Requested and Approved
Masking sits on top of Database JIT. Support requests access for a stated reason, an approver grants a time-bound window, and credentials are short-lived and issued per session. Masking governs what they see during the window. Approval governs whether the window exists at all.
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 You Roll It Out Without Disrupting Support
- Pick the columns that matter. Start with the handful of fields that carry real exposure: contact details, identity numbers, and payment identifiers. Masking policies are authored by an administrator in the Cloudanix console.
- Define the support role. Choose which strategy applies to which column for support, and which roles keep fuller visibility.
- Start in observation. Review the query log for a week or two to see which columns support actually reads and where masking affects a real workflow.
- Tighten and extend. Add row limits and table restrictions where the log shows no legitimate need.
Because masking happens at the proxy, adding or changing a policy does not require touching the application or the schema.
What to Know Before You Start
- DAM supports MySQL on RDS and Aurora for this scenario. Other engines in the same environment, such as a hosted document store, are not covered by this workflow today.
- Masking applies to the data path that goes through the proxy. Anyone who can reach the database by another route, such as a shared credential left in a script, bypasses it. Pair masking with Database JIT so that routes using shared passwords are retired.
- DAM masks fields you tell it to mask. It does not claim to discover every sensitive column on its own, so keep a reviewed list of the fields that need protection.
Platform Impact
| Dimension | Before | After (DAM masking) |
|---|---|---|
| What support sees | Every column, in plaintext | Only what the role needs; the rest masked |
| Same query, different roles | Identical results | Results vary by role at the proxy |
| Bulk export from a BI session | Unconstrained | Row limits and table/column restrictions |
| Evidence of who viewed what | Little or none | Every query attributed and stored in your account |
| Sanitized replicas to maintain | Considered as an option | Not needed |
| Where sensitive data travels | N/A | Stays inside your AWS account |
Key Outcomes
- ✅ Least-Privilege Visibility: Support sees what the task requires, nothing more.
- ✅ No Schema or Application Changes: Masking lives at the query layer.
- ✅ Right Strategy per Field: Mask, partial reveal, hash, redact, or tokenize.
- ✅ Contained Exports: Row limits and table restrictions bound what a session can pull.
- ✅ Accountability: Every support query is attributed and searchable.
- ✅ Data Sovereignty: Proxy and logs stay in your own cloud.
Is Your Support Team Reading Raw Personal Data Every Day?
If a read-only BI tool is your only control on production data, your support team can see more than any ticket needs. Cloudanix DAM masks sensitive fields by role at the query layer, so they get the context to help customers and nothing extra.
Book a Free Assessment to see role-based masking on your own MySQL data in under 30 minutes.
