Non-discretionary Access Control
Non discretionary access control is a central model where admins set all rules. Users cannot pass their own rights to other people on the team. Most teams set up this model using job roles or security labels. Admins map each person to a fixed role in the central directory. That role grants fixed rights to specific servers, apps, and data stores. Trouble starts when teams make these shared roles too broad for daily work. One wide role can give an engineer full write rights across production. Ho
Discretionary Access Control (DAC) + Non-Human Identity Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Non discretionary access control is a central model where admins set all rules. Users cannot pass their own rights to other people on the team. Most teams set up this model using job roles or security labels. Admins map each person to a fixed role in the central directory. That role grants fixed rights to specific servers, apps, and data stores. Trouble starts when teams make these shared roles too broad for daily work. One wide role can give an engineer full write rights across production.
How non discretionary access control works in practice
In a discretionary model, file owners decide who can read their files. A non discretionary model removes that choice from the regular user. A central security team defines every rule for the whole company. Nobody can share a login key or grant a teammate extra rights. The system checks a central policy table before it opens any session.
Role-based control is the most common form of this security model. Admins build roles that match real job duties on the team. A billing role might allow read rights on payment tables only. An operations role might allow shell sessions on web servers. When a person changes jobs, the admin swaps their assigned role.
Some teams also use lattice rules or clear security labels on data. Each file or table gets a sensitivity tag from the admin team. Each user gets a matching clearance level in their central profile. The system compares both tags every time a user starts a session. If the tags do not match, the system blocks the request right away.
Why teams choose central rules for production
Central rules stop permission sprawl across large engineering teams. Without central control, users share folders and tables with peers to move fast. Over months, nobody knows who holds rights to read sensitive customer data. A central model puts every rule in one place for review.
Auditors also prefer this model because reviews take much less time. An auditor can check ten team roles instead of five hundred accounts. When an employee leaves the company, admins revoke their central role once. No stray file permissions remain active on old servers or data stores.
Discretionary Access Control (DAC) + Non-Human Identity Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What static role models solve and what they miss
Static roles do a good job of deciding who can log in. They verify that a user belongs to the right group at login time. They also block unauthorized staff from opening a network session at all. This stops outside attackers and unapproved staff at the front door.
Still, static roles do not inspect what happens inside an active session. Once a database or server accepts the login, the role steps back. The native system trusts every command that fits the broad role permissions. A support engineer with read rights can still pull ten thousand card numbers. A developer with write rights can still drop a table by mistake.
Static roles also stay active twenty-four hours a day for every user. Engineers keep high-level rights even when they are not fixing an issue. Also, shared database roles hide which person ran a specific query. The database log only shows the generic role name, not the human user. To stay safe, teams must check individual commands and mask sensitive fields like emails or phone numbers in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between discretionary and non discretionary access control?
Discretionary control lets resource owners share their files with any other user. Non discretionary control puts admins in charge of all rules and blocks user sharing.
Is role-based access control a non discretionary model?
Yes, role-based control is the most popular type of non discretionary model. Admins assign permissions to job roles, and users cannot pass those rights along.
Why do central roles still leave data at risk during sessions?
Central roles only check permissions when a user logs in to a system. They do not block bad queries or rewrite card numbers in query results.