Moving Enforcement Into the Database
Once an application's access behavior has been made visible, a harder design question remains: which component is responsible for enforcing it on every path to the data? The m-NGAC proposal answers by embedding an NGAC-based policy system in the database environment rather than leaving authorization scattered across applications or in an intermediary that rewrites SQL. This chapter follows that placement, its different treatment of reads and writes, and the boundary between a stated architectural advantage and a demonstrated isolation guarantee.
What changes when policy moves with the data
Traditional database privileges are useful but often coarse. GRANT and REVOKE can control access to tables or columns, and roles can group permissions around job functions. Some database products add row-level or column-level controls. But when the rule depends on the relationship between a particular user, a particular row, a field, an operation, and changing context, a table-level permission is not enough by itself.
Organizations commonly fill the gap in application code. A web service checks the current user, adds a filter, chooses which fields to render, and denies an operation when a condition fails. Another service that reads the same database may implement a similar rule differently. A reporting tool or SQL editor may not pass through those checks at all. The application layer can therefore become both the place where the policy is fragmented and the place where a direct connection can bypass it.
The NIST report proposes m-NGAC, embedded Next Generation Access Control, as a way to put policy representation and enforcement closer to the data. NGAC is an attribute-based, policy-driven model standardized through ANSI/INCITS and developed by NIST. Instead of representing authorization only as a list of roles and privileges, it connects users, resources, operations, and attributes in a policy graph. Different policy classes can coexist in that graph, so a role-based rule and other attribute- or relationship-based rules can share the same protected resources.
The proposed change is not simply to copy application checks into stored procedures. It changes which layer owns the decision. The database environment is intended to understand the request, identify the data elements and operation involved, consult policy, and enforce the resulting decision before protected data or a state-changing operation crosses the boundary. The report presents this as a way to make enforcement consistent whether a request arrives through a web application, an analytics tool, an administrative interface, or a direct SQL client.
The architecture divides that work into three principal components. The Source is the user, application, or external system that submits a database operation. From the database's perspective, it behaves like a normal client issuing a SELECT, INSERT, UPDATE, or DELETE. The Mediator is implemented with database-resident objects and logic in the resource schema—the schema containing the protected data. It intercepts requests, identifies the requesting user, and determines which database objects and fields the request touches.
The Adjudicator stores and evaluates the NGAC policy.