Access Control Modelle: DAC, MAC, RBAC, ABAC und Zero Trust

Zugriffskontrolle beantwortet drei fundamentale Fragen: Wer darf zugreifen? Auf was darf zugegriffen werden? Und unter welchen Bedingungen? Die Antworten sind in verschiedenen Access-Control-Modellen kodifiziert - je nach Anforderung bietet jedes Modell andere Sicherheits- und Usability-Tradeoffs.

Die vier Grundmodelle

1. DAC - Discretionary Access Control:

Prinzip: Der Ressourcen-Eigentümer entscheidet über Zugriffsrechte
  → Flexibel, benutzerfreundlich
  → Standard in Windows NTFS, Unix-Dateisysteme

Unix-Dateisystem (klassisches DAC):
  ls -la /home/user/datei.txt
  -rw-r--r-- 1 user gruppe 1234 Mar 04 10:00 datei.txt
   rwx = Eigentümer: read/write/execute
    rwx = Gruppe: read only
     rwx = Andere: read only

  chmod 640 datei.txt  # rw-r-----
  chown user:abteilung datei.txt

Windows NTFS ACL:
  → Jede Datei/Ordner hat Access Control List (ACL)
  → ACE (Access Control Entry) pro Benutzer/Gruppe
  → Vererbung: Unterordner erben elterliche ACLs

DAC Schwächen:
  ✗ Trojanische Pferde: Malware mit User-Rechten = User-Datei-Zugriff
  ✗ Unbeabsichtigte Weitergabe: User teilt Datei → Empfänger teilt weiter
  ✗ Kein zentral erzwungenes Policy-Framework

---

2. MAC - Mandatory Access Control:

Prinzip: Systemweite Policy entscheidet über Zugriff (nicht der Eigentümer)
  → Sehr strikt, typisch für Hochsicherheitsumgebungen
  → Militär-Klassifizierung: TOP SECRET, SECRET, CONFIDENTIAL

Bell-LaPadula-Modell (Vertraulichkeit):
  "No Read Up, No Write Down"
  → User mit SECRET-Clearance kann keine TOP SECRET Dateien lesen
  → User mit SECRET-Clearance kann nicht in CONFIDENTIAL Dateien schreiben
  → Verhindert Informationsfluss von höherer zu niedrigerer Stufe

SELinux (MAC in Linux):
  → Jeder Prozess, jede Datei hat SELinux-Label (Security Context)
  → Policy definiert: welcher Prozess darf auf welche Datei zugreifen
  → httpd (Apache) darf NICHT auf /etc/shadow zugreifen (egal wie die DAC-Rechte sind!)

  SELinux Status prüfen:
  getenforce  # Enforcing / Permissive / Disabled

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

  Fehler bei SELinux-Denials:
  ausearch -m avc -ts recent  # Letzte SELinux-Denials
  audit2why < /var/log/audit/audit.log  # Warum denied?

AppArmor (Alternative zu SELinux, Ubuntu):
  → Profil-basiert (Programm-Pfad statt Labels)
  → Einfacher zu konfigurieren
  → /etc/apparmor.d/usr.sbin.nginx (Nginx-Profil)

---

3. RBAC - Role-Based Access Control:

Prinzip: Berechtigungen werden Rollen zugewiesen, nicht Personen direkt
  → Skalierbar für Unternehmen
  → Standard in Enterprise-IT

Konzepte:
  User → Rolle → Berechtigungen → Ressourcen

Active Directory RBAC:
  Gruppe "IT-Support" hat Berechtigung "Passwort zurücksetzen" für OU "Benutzer"
  Gruppe "Finanz-Buchhalter" hat Lese/Schreibrechte auf "Finanzdaten"-Share

  Gruppen-Hierarchie Best Practice:
  Benutzerkonten → Global Groups → Domain Local Groups → Ressourcen-Berechtigungen
  (AGDLP-Modell: 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 Schwächen:
  ✗ Role Explosion: zu viele Rollen, unüberschaubar
  ✗ Overprivileged Roles: Rolle hat mehr Rechte als nötig
  ✗ Statisch: kein Kontextbezug (Zeit, Gerät, Standort)

---

4. ABAC - Attribute-Based Access Control:

Prinzip: Zugriff basiert auf Attributen von User, Ressource und Kontext
  → Feingranular, flexibel, kontextsensitiv
  → Standard: XACML (eXtensible Access Control Markup Language)

ABAC-Policy-Beispiel:
  Zugriff ERLAUBT wenn:
    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"

  → Kein Passwort egal wie sicher: außerhalb Bürozeiten → Zugriff verweigert

AWS IAM als ABAC:
  {
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}",
        "aws:PrincipalTag/Project": "${aws:ResourceTag/Project}"
      }
    }
  }
  → Entwickler dürfen nur Instanzen ihres eigenen Projekts/Environments starten

Zero Trust als Access Control Evolution

Zero Trust Access Control Prinzipien:

"Never Trust, Always Verify"
  → Kein implizites Vertrauen basierend auf Netzwerk-Location
  → Jeder Zugriff muss authentifiziert + autorisiert sein
  → Kontinuierliche Prüfung (nicht nur beim Login)

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

  PDP prüft:
  → Benutzeridentität (MFA bestanden?)
  → Gerätezustand (compliant? aktuell?)
  → Risikolevel (Login aus Nigeria um 3 Uhr?)
  → Ressourcen-Klassifizierung (wie sensitiv?)
  → Netzwerk-Location (VPN/intern/extern?)

Microsoft Entra ID Conditional Access (PDP-Beispiel):
  Richtlinie: "Zugriff auf Finance-App"
  Bedingungen:
    User: Finance-Abteilung-Gruppe
    Platform: Windows, iOS, Android (nicht Linux ohne Mgmt!)
    Location: NICHT Risikoländer
    Device: Compliant (Intune-eingeschrieben, aktuell)
    Sign-in Risk: Low (Entra ID-Risikobewertung: kein Impossible Travel)
  Gewähren: Mehrstufige Authentifizierung erforderlich
  Sitzung: Token-Lifetime 1 Stunde (re-auth danach)

---

Berechtigungen implementieren - Checkliste:

□ Least Privilege als Grundprinzip:
  Jeder User/Service-Account bekommt GENAU die Berechtigungen die nötig sind
  Kein "Full Admin weil einfacher"

□ Access Reviews regelmäßig:
  Quartalsweise: Wer hat welche Berechtigungen? Noch gültig?
  Bei Rollenwechsel: sofortige Anpassung (Joiner/Mover/Leaver-Prozess)

□ Privileged Access getrennt:
  Admin-Konten ≠ Alltags-Konten (keine Surfen mit Admin-Konto!)
  PAM-Lösung (CyberArk, Teleport) für privilegierten Zugang

□ Time-Based Access:
  Just-in-Time: Berechtigungen nur wenn benötigt, automatisch ablaufend
  Microsoft Entra PIM: Admin-Rechte max. 8h, mit Approval + MFA

□ Audit Logging:
  Jeder Zugriff auf kritische Ressourcen geloggt
  Besonders: Zugriff auf privilegierte Konten, sensitive Daten

□ Separation of Duties:
  Kein Einzelner kann kritischen Prozess komplett ausführen
  Beispiel: Überweisung anlegen + freigeben = zwei verschiedene Personen