How to Design Future-Proof Access Control

TL;DR

Enforce access by named activities or permissions, not by hard-coded roles scattered throughout application code. Centralize policy decisions, deny access when checks fail, rely only on trustworthy decision data, and explicitly handle ownership, multi-tenancy, workflows, and row-level restrictions so policies remain auditable and adaptable without requiring code changes.

Transcript

Hello everybody. Hello RSA community. It's really my pleasure to be here. I wanna talk to you about a really important topic in the world of information security that I, I don't think is addressed really well overall, and that's about designing access control. I want you to understand my perspective of this topic. I tend to teach software developer... Read More

Key Insights

• Hard-coded role checks are fragile because they embed security policy directly in source code. When roles such as manager, administrator, or editor appear throughout an application, changing the policy requires finding, modifying, testing, and deploying the affected code.
• Auditability is a characteristic of secure software because auditors must be able to determine its security properties. Scattered role checks force auditors or quality assurance teams to search extensive code and infer the effective policy, making reliable verification extremely difficult.
• Centralized access control is easier to understand and maintain than checks distributed throughout individual features. A shared policy enforcement function and persisted policy store create a consistent place to evaluate permissions and inspect the rules governing application behavior.
• Permission-based enforcement checks the requested activity rather than hard-coding a role. A feature can ask whether the user has access to edit an article, while a central policy mechanism determines which roles, claims, attributes, customers, or conditions authorize that activity.
• Multi-tenancy requires policy to vary between customers using the same software. One customer may restrict a report to administrators, while another may permit managers and other leads, so embedding a single role rule in shared application code cannot represent both requirements cleanly.
• Horizontal access control governs access to specific data, including individual database rows or records owned by a particular user. Broad role checks do not establish whether someone may view or change one specific object, so explicit data-level authorization is necessary.
• Fail-closed behavior denies access when authorization logic encounters an error or cannot make a valid decision. An open-by-default mechanism can grant access when something goes wrong, so denial should be the immediate result of an authorization failure.
• Trusted inputs are essential to authorization because access decisions can become unsafe when driven by data that an attacker can alter. The policy mechanism should distinguish trustworthy claims and attributes from tainted inputs before using them to grant access.

Questions & Answers

Q: How should developers enforce access control in enterprise software?

Developers should enforce access control by checking the requested activity or permission, such as whether a user may edit an article, rather than checking for a hard-coded role at each feature. A centralized function should evaluate persisted policy using appropriate claims or attributes. This structure separates policy from application code and makes future policy changes easier to support.

Q: Why are hard-coded roles a poor access control design?

Hard-coded roles couple authorization policy directly to source code. When checks for managers, administrators, or editors are repeated throughout an application, every policy change can require code modifications and deployment. The resulting policy is also difficult to audit because reviewers must inspect scattered checks and reconstruct the effective rules from the implementation.

Q: How does centralized access control improve auditability?

Centralized access control gives auditors and quality assurance teams a consistent location for examining policy and authorization decisions. Without centralization, reviewers may have to search a large codebase for individual role checks and infer how they interact. A shared enforcement function backed by persisted policy makes the intended rules more visible, testable, and provable.

Q: What is horizontal access control in a web application?

Horizontal access control determines whether a user may access a specific piece of data, such as an individual database row or a record that belongs to another user. A broad role alone does not answer that question. The application must evaluate data-specific conditions, including ownership, rather than relying only on general categories such as manager or administrator.

Q: Why does multi-tenancy require flexible authorization policy?

Multi-tenancy allows different customers to apply different rules to the same software feature. One customer may reserve a report for administrators, while another may permit managers, administrators, and other leads. A single hard-coded role check cannot express both policies cleanly. Centralized, persisted policy can select the correct rules for each customer without forking the codebase.

Q: What does fail closed mean for access control?

Failing closed means denying access whenever authorization logic fails, encounters an error, or cannot produce a valid decision. An open-by-default design grants access when something goes wrong, creating an unsafe outcome. The recommended behavior is immediate denial so that a malfunction or missing policy does not accidentally expose a protected feature or data record.

Q: What data should drive an authorization decision?

Authorization decisions should rely on trusted claims, attributes, policy records, and relevant application data. Developers should be cautious about using inputs that an attacker can taint or manipulate, because altered data could influence the decision and produce unauthorized access. The enforcement mechanism should evaluate the trustworthiness of decision inputs before granting the requested activity.

Q: How does permission-based access control support future requirements?

Permission-based access control places a stable activity name at the enforcement point, such as permission to edit an article. The underlying centralized policy can later map that activity to roles, customer-specific rules, ownership requirements, workflows, or other claims and attributes. Developers can therefore change the policy without rewriting the authorization check embedded in every protected feature.

Summary & Key Takeaways

• Hard-coded role checks couple security policy directly to source code. Across a large application, scattered checks make policy difficult for auditors and quality assurance teams to reconstruct, and every policy change requires another code change. Roles can remain part of the model, but they should not serve as enforcement points.

• Modern enterprise software requires controls beyond broad roles. Different customers may need different rules for the same feature, while individual records may require ownership or other data-specific restrictions. Frameworks often provide weak support for these horizontal and multi-tenant requirements, leaving developers to implement fragile, feature-specific checks themselves.

• A stronger design checks whether a user may perform a named activity, such as editing an article. A centralized function then evaluates persisted policy and relevant claims or attributes. This separates enforcement from policy, supports customer-specific rules, improves auditability, and allows future requirements to be incorporated without rewriting every feature-level check.