1.5Access control models

Access control decides "who may touch what, and how far," and choosing the wrong model creates excessive privilege (a breeding ground for leaks) or, conversely, under-privilege that halts work. This section covers choosing—from owner-discretion DAC, to org-enforced MAC, to role-bundled RBAC, to context-aware ABAC—by requirements (sensitivity, scale, flexibility, auditability), closing with the AAA framework that governs authentication, authorization, and accounting.

1.5.1The main control models

• DAC (discretionary access control) lets the resource owner decide at their discretion who is permitted (typical of ordinary file-share permissions). It is flexible but prone to excessive privilege if the owner sets it loosely, and organization-wide control is weak.
• MAC (mandatory access control) is enforced by the system based on organization-defined labels (classification/clearance). Owners cannot widen permissions on their own; it suits high-secrecy environments like military/government. Low in flexibility but strong in control.
• RBAC (role-based) bundles permissions to a role rather than to individual users and assigns users to roles. Roles like "accounting" or "HR" simplify permission management and ease auditing in large organizations. On transfer, you just switch the role.
• ABAC (attribute-based) is the most flexible model, deciding dynamically by combining user attributes, resource attributes, and environment (time, location, device, risk). It enables fine-grained, context-dependent control like "allow if in accounting and from the internal network during business hours."

1.5.2Rule/time-based and AAA

• Rule-based applies common admin-defined rules uniformly to everyone (e.g., an ACL "deny this port from this source"). Time-based controls permission by hours/period (e.g., deny access to certain systems outside business hours). Both also appear as parts of ABAC conditions.
• AAA has three pillars: authentication (who you are) -> authorization (what you may do) -> accounting (a record of what you did). Access-control models mainly govern the authorization decision, and AAA brackets it with authentication and audit records. It is implemented with RADIUS/TACACS+, etc.

You are designing access control for a hospital information system. The requirements are complex: (1) patient charts are highly sensitive and staff outside the care team must not widen viewing on their own; (2) there are thousands of staff with frequent transfers, so per-individual permissions are impractical; (3) on-call physicians must access data for wards they normally cannot reach, only during nighttime emergencies. Forcing this into one model is the root of failure. First, the scale and frequent transfers in (2) point naturally to RBAC: bundling permissions into roles like "physician," "nurse," and "medical records" means a transfer is just a role switch and auditing is easier. But the strong control requirement in (1)—outsiders must not widen viewing on their own—is risky under owner-discretion DAC (sharing spreads by on-the-spot judgment) and calls for a MAC-style idea where the system enforces classification so staff cannot widen their own scope. And the "only during nighttime emergencies" condition in (3) cannot be expressed by role alone; it is better handled by time-based (on-call hours) or, more generally, ABAC combining "role = physician AND on-call = true AND time = night" to grant dynamically. In practice, a hybrid that layers ABAC context conditions atop an RBAC foundation is the realistic solution. Finally, who opened which chart and when must always be recorded by AAA accounting for later audit and incident investigation—in regulated domains like medical information, "accounting (who viewed)" is as important as "authorization (may they view)." The lesson is the design judgment of reverse-mapping each requirement keyword to a model and combining models rather than clinging to a single one.

1.5.3Section summary

• DAC = owner discretion (watch for excessive privilege), MAC = system-enforced via labels (for high secrecy); choose by required sensitivity and control strength
• RBAC bundles by role to simplify scale/transfers, ABAC is dynamic and fine-grained via attributes + environment, and time-based handles time conditions like on-call
• A combination like RBAC + ABAC is the realistic solution rather than a single model; AAA (authentication -> authorization -> accounting) keeps records for audit