Who Did This? The Attribution Problem of Shared Accounts

There is a row in the database log: thirty thousand records in the customer table were updated on Tuesday morning. The account that opened the session is an application account. Four people know its password. The auditor asks who did this and nobody can answer. This article is about why a record can exist and still point at no one, and what to do about it.

The Auditor's Unanswerable Question

The question that produces the most findings in an audit is not whether you keep records. Records are usually kept. The question that produces findings is this: can you tie the record to a person?

At the database layer that link breaks often, and the break is not a malfunction. It is the natural consequence of the system working as designed. Applications connect with a single account, administrative work happens under an elevated account, maintenance runs under a scheduler account. Each is sensible on its own; together they produce an environment where no action can be attributed to a human being.

Five Places Identity Disappears

What these five have in common is that none of them gets reported as a vulnerability. All of them are parts of a working architecture. The problem only becomes visible when something goes wrong, or when an auditor picks a sample.

What the Standards Say

This is one of the areas where audit standards speak most plainly, and there is little room for interpretation.

The identity management control in ISO/IEC 27001 requires individual accountability: every user must have a unique identifier that is not shared with anyone else. The privileged access rights control expects elevated permissions to be limited, allocated and monitored. Environments where several people share one administrator password with no mechanism to attribute actions to individuals get flagged as a non conformity.

The card payment standard puts the same expectation more sharply: every account, including administrative and vendor accounts, must have a unique ID for traceability.

All of these standards also recognise the same escape hatch: where a shared account is technically unavoidable, compensating controls must be defined and documented. The typical accepted compensation is holding the account in a vault where each use is checked out and returned individually. In other words the standard does not forbid a shared account; it forbids unattributable use of one.

Why Shared Accounts Cannot Simply Be Removed

The typical decision taken at this point is the wrong one: let us remove the shared accounts. In practice that is often impossible, and forcing it produces worse outcomes.

An application connects with a single identity so that connection pooling works. Opening a separate database session per end user defeats the pool and degrades performance badly. The application pool account is therefore a deliberate architectural choice, not an oversight.

On the administrative side an absolute separation is not always achievable either. Some maintenance tools are built to run under a specific account, some vendor products insist on their own installer account. Forcing the issue pushes the team onto unrecorded paths: unable to get in with their own account, someone uses the shared one and does not mention it.

The Right Distinction: Connection Identity and Action Identity

The distinction that solves this is the following. The identity that connects to the database and the identity accountable for the action do not have to be the same. What matters is that the link between them is recorded.

Connection identity is a technical necessity: which account opened the session and what rights it has. This is usually a service account and should stay that way.

Action identity is a governance necessity: who asked for this work, who approved it and who executed it. That information cannot be derived from the database session; it has to be produced by the layer the work passes through.

Once that distinction exists, the answer changes. The database log still shows the service account, but that execution has a request record, and the record carries three named people. The auditor's question is now answerable: who opened the request behind the action, on what stated basis it was approved, and who pressed the button.

SQL Change Guard uses this model. It reaches the target server over its own defined connection, while the person who started the execution is held separately on the request record, and even in scheduled or packaged flows the person who pressed the button is captured. Work done over a shared connection therefore runs without breaking individual accountability.

A Workable Checklist

The steps below can be applied in order, and none of them requires rewriting the architecture.

1. Build the inventory. List every account that connects to production databases and write one fact next to each: how many people sit behind this account? In most organisations this list has never been produced, and on its own it is revealing.

2. Set application accounts aside. Application pool accounts are not what this discussion is about; the identity behind them belongs in the application log. Point the focus at accounts humans use by hand. That is where the real risk sits.

3. Define an attribution path for every manually used account. If a person uses this account, which record will point at them? If the answer is none, use of that account has to be tied to a request record.

4. Get passwords out of circulation. A shared password living in a chat thread, a spreadsheet or someone's memory amounts to the same thing: when it is rotated, nobody knows who still has access. Passwords should be held centrally and stored encrypted on the application side.

5. Measure. What share of the operations that ran in production last month can be traced to a person? That single number is the indicator to track throughout the programme, and it should climb over time.

Frequently Asked Questions

Would giving each user their own application account not solve it?

In theory yes, in practice no. Applications rely on a single identity to pool connections efficiently; opening a session per end user defeats the pool and degrades performance badly. Per user identity already exists in the application layer and belongs there. What needs to be answerable at the database layer is who performed the manual operations that happen outside the application's own flow.

Does the database's own auditing not cover this?

Database auditing records what ran and which session it came from very well. What it cannot record is the real person behind that session, because that information never reaches the database. If the session is a service account, the audit row shows the service account. What is missing is not data but the identity to attach it to, and that identity has to be produced by the layer the work passes through.

We use a password vault. Is that enough?

A vault is an important step in the right direction, and it is exactly the compensating control the standards accept: holding the account in a vault where each use is checked out and returned individually. What a vault cannot show is what was done with the access. The record says a named person checked the account out at 09:40 on Tuesday; it cannot say that they updated thirty thousand rows in the customer table and that the work rested on a specific request. The two records are meaningful together.

If an administrator connects directly with a management tool, is this layer not bypassed?

It is, and that should be said plainly: no governance layer can stop someone who can reach the server with a management tool. That is a fact of the architecture rather than a product shortcoming. What closes it is not a technical block but a two layer discipline. First, scope: reducing how many people can connect directly to production servers and requiring a stated reason for the connections that remain. Second, cross checking: your database activity monitoring records are compared against your request records on a schedule, and every operation with no matching request is listed as an exception. If that list is not empty, the process scope is incomplete; if it is empty, the discipline is working. The value of a governance layer is not making direct connections impossible but making them noticeable.

We are a small team and everyone knows each other. Is this still necessary?

Attribution is not about distrust, it is about protection. When something breaks in production and nobody knows who did it, suspicion settles on everyone who had access to that account. A clear record protects the people who did not do it as much as anyone else. Teams also change: the four people everyone knows today may all have left in two years, and by then only the record remains.

Where should we start?

With an account inventory and one question: how many people sit behind each account? Then focus only on the accounts humans use by hand and define an attribution path for each. Those two steps close the largest audit finding without touching the architecture. For application accounts the right answer is not splitting them but moving manual work onto a separate record.