Access Control Modelle: DAC, MAC, RBAC, ABAC & 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"

Feld	Wert
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