What is Identity-Aware Access Control?
Definition
Traditional database access often relies on shared service accounts or broad credentials that don't distinguish between individual users, which makes it difficult to know who actually made a given change even when the change itself is logged. Identity-Aware Access Control ties permissions and activity to a specific, authenticated identity instead, whether that's an individual developer, a specific service, or an automated pipeline. This matters for both security and governance: restricting what a given identity can do limits the blast radius of a compromised credential, and recording which identity made which change is what makes an audit trail actually trustworthy rather than just a list of actions with no reliable attribution.
Why Identity-Aware Access Control matters
An audit trail that says a change was made without reliably identifying who made it is significantly less useful than one that can say exactly who, both for security investigations and for demonstrating Separation of Duties during a compliance review. Shared credentials and broad service accounts make that attribution unreliable by design, since multiple people or systems might be using the same access without being individually distinguishable. This becomes a real liability the moment an organization needs to answer a specific question: exactly who approved this particular change.
How Identity-Aware Access Control works
Rather than granting broad database access to a shared account, permissions are tied to individual, authenticated identities, whether human or service accounts, and each identity's actions are logged under its own name. This makes it possible to restrict specific identities to specific kinds of changes, a developer might be able to propose changes but not approve them, and to trust that logged activity accurately reflects who actually did what. Access can also be scoped narrowly, granting only the specific permissions an identity actually needs rather than broad database-level access by default.
How Liquibase helps
Liquibase Secure incorporates identity-aware controls as part of its governance layer, so permissions and audit trails are tied to specific users or services rather than shared credentials. This directly supports Separation of Duties policies, since enforcing that the author and approver of a change are different people only works if the system can reliably tell those two identities apart in the first place. Reviewing which identities hold which permissions on a recurring basis, not just when access is first granted, helps catch privileges that should have been revoked once a project ended or a role changed. Service accounts used by automated pipelines deserve the same identity discipline as human users, since a shared pipeline credential can otherwise become an untracked way around the same controls applied everywhere else.
