Query governance

Production database access control

"Run this query and send me the result" exists in every organisation, and in most of them it is recorded nowhere. This flow turns it into a request, a decision and a piece of evidence.

The problem

Reading data from the live environment is a legitimate need: a customer complaint is investigated, the root cause of a bug is traced, a report is verified.

The problem is not the need but the way it is met. The query is passed on verbally, the result leaves as a file, and who saw which data is recorded nowhere. When the auditor asks who looked at production data last month, there is no answer.

The flow

The path of a query request

1 Request The query, its justification and the addresses the result will go to are entered.
2 Rule check The query is parsed. Critical object access and query rules are applied.
3 Column preview Only a schema question is asked of the target server. The query is not run and no data is read.
4 Classification Columns are flagged against sensitive data patterns.
5 Masking and approval Sensitive columns are masked. Any column requested unmasked needs a justification and an extra approval.
6 Delivery The result is not shown on screen. It is delivered as an encrypted, password protected package.
7 Audit Who took which data, for what reason, and which column went out unmasked, all stay on record.
Sensitive data

How the masking decision is made

Two detectors

The first looks at the column name, the second at the value itself. Even when the column name looks innocent, content matching an identifier pattern is caught.

Validators

Not everything that matches a pattern is sensitive. Checksum algorithms run for national identifiers, card numbers and IBANs, so random digits are not masked by mistake.

Full and partial masking

A value can be hidden entirely, or the last few characters can be left visible. Partial masking is the middle ground: enough to recognise a record, not enough to carry the data.

An unmasked column is not forbidden, it is accounted for. Some investigations need the real value. The product does not block that; it asks for a justification, opens an extra approval step, and records which column went out unmasked and who approved it. Governance is not about banning access. It is about accounting for it.

Delivery

How the result is delivered

Encrypted package

The result is never rendered on screen; it is packaged as a password protected archive. The package password is stored encrypted and shown to the requester inside the application, with a reason recorded.

Recipient approval

Delivery addresses can be checked. If an address has not been approved before, an extra approval step is added. The aim is to stop live data from quietly leaving for an external address.

Per server tightening

The delivery mode is defined as an organisation wide ceiling. A request may only choose something stricter; loosening is rejected.

Masking audit record

Which column was masked under which rule is kept as a separate record. Threshold and sampling settings are frozen at delivery time, so "what was the threshold that day" can be answered later.

Screens

Production query request screen with the query, its justification and the delivery addresses
Query request The query, the justification and the delivery addresses.
Query result detail with the masked columns and the delivered package
Result and masking Which column was masked and where the package went.
Sensitive data patterns screen with the pattern definitions and the masking style
Sensitive data patterns Pattern definitions and the masking style.
Critical object definitions screen with database, schema, object type and the access control switch
Critical object definitions Which objects need their own approval before they can be read is written here.
Email sources screen with the approved addresses a result may be delivered to
Approved delivery addresses The addresses a result may reach are approved in advance.

Next