Access Control models: DAC, MAC, RBAC, ABAC and Zero Trust

Access control answers three fundamental questions: Who is allowed to access? What can be accessed? And under what conditions? The answers are codified in various access control models—depending on the requirements, each model offers different trade-offs between security and usability.

The Four Basic Models

1. DAC - Discretionary Access Control:

Principle: The resource owner decides on access rights
  → Flexible, user-friendly
  → Standard in Windows NTFS, Unix file systems

Unix file system (classic DAC):
  ls -la /home/user/file.txt
  -rw-r--r-- 1 user group 1234 Mar 04 10:00 file.txt
   rwx = Owner: read/write/execute
    rwx = Group: read only
     rwx = Others: read only

  chmod 640 file.txt  # rw-r-----
  chown user:department file.txt

Windows NTFS ACL:
  → Every file/folder has an Access Control List (ACL)
  → ACE (Access Control Entry) per user/group
  → Inheritance: Subfolders inherit parent ACLs

DAC Weaknesses:
  ✗ Trojan horses: Malware with user rights = user file access
  ✗ Unintended sharing: User shares file → Recipient shares it further
  ✗ No centrally enforced policy framework

---

2. MAC - Mandatory Access Control:

Principle: System-wide policy determines access (not the owner)
  → Very strict, typical for high-security environments
  → Military classification: TOP SECRET, SECRET, CONFIDENTIAL

Bell-LaPadula Model (Confidentiality):
  "No Read Up, No Write Down"
  → Users with SECRET clearance cannot read TOP SECRET files
  → Users with SECRET clearance cannot write to CONFIDENTIAL files
  → Prevents information flow from higher to lower levels

SELinux (MAC in Linux):
  → Every process and every file has a SELinux label (Security Context)
  → Policy defines: which process is allowed to access which file
  → httpd (Apache) is NOT allowed to access /etc/shadow (regardless of DAC permissions!)

  Check SELinux status:
  getenforce  # Enforcing / Permissive / Disabled

  Display context:
  ls -Z /var/www/html/
  # -rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
  #                       ↑ SELinux Context

  SELinux Denial Errors:
  ausearch -m avc -ts recent  # Recent SELinux Denials
  audit2why < /var/log/audit/audit.log  # Why denied?

AppArmor (Alternative to SELinux, Ubuntu):
  → Profile-based (program path instead of labels)
  → Easier to configure
  → /etc/apparmor.d/usr.sbin.nginx (Nginx profile)

---

3. RBAC - Role-Based Access Control:

Principle: Permissions are assigned to roles, not directly to individuals
  → Scalable for enterprises
  → Standard in enterprise IT

Concepts:
  User → Role → Permissions → Resources

Active Directory RBAC:
  The "IT Support" group has "Reset Password" permission for the "Users" OU
  The "Financial Accountants" group has read/write permissions on the "Financial Data" share

  Group Hierarchy Best Practice:
  User accounts → Global Groups → Domain Local Groups → Resource permissions
  (AGDLP model: Accounts → Global → Domain Local → Permissions)

Kubernetes RBAC:
  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: pod-reader
    namespace: production
  rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  ---
  kind: RoleBinding
  subjects:
  - kind: ServiceAccount
    name: monitoring-agent
  roleRef:
    kind: Role
    name: pod-reader

PostgreSQL RBAC:
  CREATE ROLE readonly;
  GRANT CONNECT ON DATABASE mydb TO readonly;
  GRANT USAGE ON SCHEMA public TO readonly;
  GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

  CREATE ROLE analyst LOGIN PASSWORD 'securepass';
  GRANT readonly TO analyst;

RBAC Weaknesses:
  ✗ Role Explosion: too many roles, unmanageable
  ✗ Overprivileged Roles: role has more rights than necessary
  ✗ Static: no context reference (time, device, location)

---

4. ABAC - Attribute-Based Access Control:

Principle: Access is based on attributes of the user, resource, and context
  → Fine-grained, flexible, context-sensitive
  → Standard: XACML (eXtensible Access Control Markup Language)

ABAC Policy Example:
  Access ALLOWED if:
    user.department == "Finance"
    AND user.clearance_level >= "confidential"
    AND resource.classification == "confidential"
    AND context.time BETWEEN "08:00" AND "18:00"
    AND context.location == "office_network"

  → No password, no matter how secure: outside office hours → Access denied

AWS IAM as ABAC:
  {
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}",
        "aws:PrincipalTag/Project": "${aws:ResourceTag/Project}"
      }
    }
  }
  → Developers may only launch instances of their own project/environment

Zero Trust as the Evolution of Access Control

Zero Trust Access Control Principles:

"Never Trust, Always Verify"
  → No implicit trust based on network location
  → Every access must be authenticated + authorized
  → Continuous verification (not just at login)

Policy Decision Point (PDP) + Policy Enforcement Point (PEP):
  Request:
  User → PEP (Firewall/Proxy) → PDP (Policy Engine) → [Allow/Deny]

  PDP checks:
  → User identity (MFA passed?)
  → Device status (compliant? up-to-date?)
  → Risk level (Login from Nigeria at 3 a.m.?)
  → Resource classification (how sensitive?)
  → Network location (VPN/internal/external?)

Microsoft Entra ID Conditional Access (PDP example):
  Policy: "Access to Finance app"
  Conditions:
    User: Finance department group
    Platform: Windows, iOS, Android (not Linux without management!)
    Location: NOT high-risk countries
    Device: Compliant (enrolled in Intune, up-to-date)
    Sign-in Risk: Low (Entra ID risk assessment: no Impossible Travel)
  Grant: Multi-factor authentication required
  Session: Token lifetime 1 hour (re-authentication required afterward)

---

Implementing permissions - Checklist:

□ Least Privilege as a fundamental principle:
  Every user/service account receives EXACTLY the permissions that are necessary
  No "Full Admin because it’s easier"

□ Regular access reviews:
  Quarterly: Who has which permissions? Are they still valid?
  Upon role changes: immediate adjustment (Joiner/Mover/Leaver process)

□ Separate privileged access:
  Admin accounts ≠ everyday accounts (no browsing with admin accounts!)
  PAM solution (CyberArk, Teleport) for privileged access

□ Time-based access:
  Just-in-time: Permissions only when needed, automatically expiring
  Microsoft Entra PIM: Admin rights max. 8 hours, with approval + MFA

□ Audit logging:
  Every access to critical resources is logged
  In particular: Access to privileged accounts, sensitive data

□ Separation of duties:
  No single person can execute a critical process in its entirety
  Example: Create transfer + approve = two different people