A.8.3
Information access restriction
Technological controlsCheckpoints 5Evidence 5Cases 5
Control objective
When a single account can reach far more than the job in front of it needs, one stolen password or one careless click puts the whole store of information in play. This control exists to keep each user and each process working inside the narrow slice of data and functionality their duties actually call for, as the organization's access control policy defines it. By implementing least privilege and need-to-know at the system, application, and data layers, it aims to prevent unauthorized viewing, modification, and leakage.
Key checkpoints
- Is access to information and application system functions restricted according to the access control policy and per-duty authorization definitions (roles/menus/functions/data scope)?
- Following least privilege and need-to-know, are the accessible data and functions separated per user/role?
- Is unauthorized access blocked at the screen/menu/function/record/field level, and is the scope of viewing/output/download of results controlled?
- Are sensitive functions (bulk queries, downloads, administrator menus, and so on) separately restricted/approved and logged?
- Are applications configured to access back-end resources (databases/files/APIs) using least-privilege accounts?
Implementation guidance
- Define a role-based (RBAC) or attribute-based (ABAC) authorization model from the access control policy, and document a permission matrix per menu/function/data.
- Verify authorization on the server side for every request, so protection does not rely on hidden/disabled UI elements alone (block bypass via direct URL/API calls).
- Control bulk queries/downloads/copying through server-side authorization, volume limits, approval, and logging. Use masking to limit disclosed data and watermarks for deterrence and tracing; neither watermarks nor their presence substitute for authorization or prevent copying.
- Use least-privilege service accounts for application-to-database connections instead of shared administrator accounts, and confine access to the required tables/views/procedures.
- Link grant/change/revoke procedures with periodic access rights review (A.5.18), and prevent risky privilege combinations through segregation of duties (A.5.3).
- Log authorization grant and denial events (A.8.15) and connect them to monitoring.
Evidence
- Access control policy and per-role/per-duty permission matrix
- Application menu/function permission configuration screens and user-to-role mapping status
- Server-side authorization logic/configuration (for example, permission-check code, policy files)
- Bulk-query/download restriction and approval records
- Application-to-database service account grant records and access rights review results
Nonconformity examples
- Menus are only hidden in the UI while server-side authorization is absent, so unauthorized functions/data can be reached via direct URL/API calls.
- Broad query/download permissions are granted by default regardless of duty, so least privilege is not upheld.
- The application connects with an over-privileged database administrator account and can access all tables.
- There is no restriction, approval, or logging for bulk queries/downloads of personal data.
- The permission matrix is not kept current, so actual granted permissions differ from defined ones.