2 Secure Design and Access Control

Build security into system design

Secure architecture makes protection part of a system’s structure rather than an afterthought. It identifies what must be protected, who or what may access it, and how those decisions will continue to be enforced if components fail or are attacked.

Security is a concern throughout a system’s life cycle, from requirements and architecture through implementation and operation. Design principles guide architectural choices, but do not replace threat analysis, testing, or ongoing review.

Apply secure design principles

Several principles guide how a system should enforce protection:

• Least privilege: Give each user, service, and process only the access needed for its assigned tasks.

• Complete mediation: Check authorization whenever a protected resource or action is requested, not just at login or when a session begins.

• Fail securely: If an authorization decision cannot be made, deny the request rather than granting access by default.

• Separation and isolation: Divide sensitive functions and limit communication between components so a compromise in one area is less likely to spread.

• Defense in depth: Use multiple, complementary safeguards so failure of one control does not expose the entire system.

• Simplicity and reviewability: Keep security rules understandable enough to test, audit, and maintain.

These principles inform architecture, including separation, isolation, modularity, and layering. They work alongside—not in place of—threat analysis, testing, and continuing review.

Distinguish identity, authentication, and authorization

Access control asks which subject may perform which action on which resource, and under what conditions. A subject may be a person, application, or service; a resource may be a database, file, API, or cloud account.

The terms Identity, Authentication, and Authorization describe distinct parts of an access decision. Identity represents the claimed user, device, or service. Authentication verifies that identity, for example by using a password and a separate authentication factor. Authorization decides whether the authenticated subject may perform a particular action on a resource.

Successful authentication does not mean that the subject has unrestricted access. A user may sign in successfully and still be denied access to payroll data or an administrative operation.

Choose and enforce an authorization model

Authorization policies can be organized in different ways:

• Role-based access control (RBAC): Assign permissions to job or service roles, then give subjects access through those roles. For example, a support analyst may read support tickets but not change billing settings.

• Attribute-based access control (ABAC): Make decisions using attributes such as the subject’s role, the resource’s sensitivity, the requested action, or the current context. For example, an employee may view a record only when assigned to its case and using an approved device.

Whatever the model, enforce authorization on every protected request and limit access to the required data and actions. Deny requests that do not match an explicit rule.

Limit permissions in practice

Least privilege applies to people and non-human identities, including applications, automated jobs, and cloud services. Practical ways to limit unnecessary access include:

• Separate ordinary and administrative accounts; use elevated permissions only for tasks that require them.

• Scope permissions to specific resources and actions instead of granting broad, account-wide permissions where possible.

• Give each workload a dedicated service identity and permissions rather than sharing a powerful account or embedding credentials in code.

• Limit the duration of elevated access by using time-limited elevation when temporary access is needed.

• Remove permissions when someone changes roles or leaves, and periodically check for unnecessary or accumulated privileges.

• Separate critical duties. For example, have one person approve a sensitive change and another implement it to reduce the risk of error or misuse.

A cloud application that generates reports might need read access to one reporting dataset. It should not receive permission to edit that dataset, administer the cloud account, or read unrelated customer records. If the application is compromised, narrowly scoped permissions limit what an attacker can do.

Layer safeguards across cloud systems

Defense in depth combines safeguards at different points in a system. A cloud application might use strong authentication for administrators, fine-grained authorization in the application, restricted network paths between services, encrypted connections, protected secrets, and audit logs. These controls address different failure modes; none should be treated as a substitute for the others.

Network segmentation can restrict which systems communicate, but network location alone should not establish trust. A zero-trust approach evaluates access to resources based on identity and authorization rather than assuming that a user or device is trustworthy because it is inside a network perimeter.

Apply access decisions to users and service identities as well as network flows. Log important authorization decisions and administrative actions, protect those logs from unauthorized changes, and test both permitted and denied requests.

Maintain access controls over time

Secure design builds protection into architecture and operations. Identity establishes who or what is requesting access; authentication verifies that identity; authorization determines which actions are allowed. Least privilege limits each subject to necessary permissions, while defense in depth combines complementary controls to contain failures.

Apply authorization consistently, deny access unless a policy permits it, and review permissions as systems and responsibilities change.

• Zero trust