Autorisierungsmodelle: RBAC, MAC und DAC
Vergleichen Sie rollenbasierte, verbindliche und benutzerbestimmte Zugriffskontrollmodelle und lernen Sie, wann welches Modell im Unternehmens- und Behördenkontext geeignet ist.
Autorisierungsmodelle: RBAC, MAC und DAC ist eine kostenlose Security+ Academy-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Security+ Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Überblick über Zugriffssteuerungsmodelle
Zugriffssteuerungsmodelle definieren die Regeln und Richtlinien dafür, welche Subjekte (Benutzer, Prozesse) auf welche Objekte (Dateien, Systeme, Daten) zugreifen dürfen. Das gewählte Modell bestimmt, wer Zugriff gewähren kann, wie Berechtigungen vergeben werden und wie die Durchsetzung erfolgt. Die Security+-Prüfung behandelt vier grundlegende Modelle: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC) und Rule-Based Access Control. Für die Entwicklung wirksamer Autorisierungssysteme ist es entscheidend, die Stärken und geeigneten Einsatzbereiche der einzelnen Modelle zu verstehen.
Discretionary Access Control (DAC)
Bei Discretionary Access Control (DAC) entscheidet der Besitzer einer Ressource selbst, wer auf seine Ressourcen zugreifen darf, und kann anderen Benutzern Zugriff gewähren oder entziehen. Das „discretionary“ genannte Merkmal besteht darin, dass die Besitzer die Entscheidungen treffen – das System setzt diese Entscheidungen durch, gibt sie aber nicht vor. Dieses Modell wird in den meisten persönlichen Computerumgebungen verwendet (Dateiberechtigungen von Windows NTFS sowie Linux/Unix). Die Sicherheitseinschränkung von DAC besteht darin, dass jeder Ressourcenbesitzer korrekte Zugriffsentscheidungen treffen muss. Ein Benutzer, der Zugriff auf eine Datei erhalten hat, kann diesen Zugriff ohne Beteiligung eines Administrators an andere weitergeben und dadurch möglicherweise sensible Daten einem größeren Personenkreis zugänglich machen als vorgesehen.
# DAC example: Linux file permissions (owner controls access)
# Create a file and check default permissions
touch confidential_data.txt
ls -la confidential_data.txt
# -rw-rw-r-- 1 alice users (owner=alice, can read/write; group can read/write; others read)
# Owner (Alice) discretionarily removes all access for others
chmod 600 confidential_data.txt
# -rw------- 1 alice users (only Alice can read/write)
# Alice grants read to a specific user via ACL
setfacl -m u:bob:r confidential_data.txtDAC-Risiken: das Problem des verwirrten Stellvertreters
DAC weist zwei grundlegende Sicherheitsrisiken auf. Transitive Zugriffe: Benutzer A gewährt Benutzer B Zugriff, Benutzer B gewährt Benutzer C Zugriff – der ursprüngliche Besitzer weiß möglicherweise nicht einmal, dass C Zugriff auf seine Ressource hat. Das Problem des verwirrten Stellvertreters: Ein privilegiertes Programm, das im Auftrag eines Benutzers mit geringeren Berechtigungen handelt, kann seine Privilegien unbeabsichtigt auf eine Weise nutzen, die dem Benutzer selbst nicht möglich wäre. In DAC-Umgebungen kann ein einziges kompromittiertes Konto möglicherweise auf alle Ressourcen zugreifen, für die dieser Benutzer Berechtigungen erhalten hat, und vor der Entdeckung des Angriffs weiteren Personen Zugriff gewähren. DAC ist praktisch, erschwert jedoch die strikte Begrenzung des Informationsflusses.
Mandatory Access Control (MAC)
Bei Mandatory Access Control (MAC) setzt das Betriebssystem Zugriffsrichtlinien anhand von Sicherheitskennzeichnungen durch, die sowohl Subjekten (Benutzern) als auch Objekten (Daten) zugewiesen sind. Benutzer können diese Richtlinien weder außer Kraft setzen noch ändern – nur der Systemadministrator oder die Sicherheitsrichtlinie kann sie anpassen. MAC wird in geheimschutzbedürftigen staatlichen und militärischen Umgebungen eingesetzt, in denen Daten strikt voneinander abgeschottet werden müssen. Eine Person mit der Freigabestufe „Secret“ kann nicht auf Daten mit der Kennzeichnung „Top Secret“ zugreifen, selbst wenn der Datenbesitzer ihr Zugriff gewähren möchte. Das Bell-LaPadula-Modell (kein Lesen nach oben, kein Schreiben nach unten) und das Biba-Modell (kein Schreiben nach oben, kein Lesen nach unten) sind formale MAC-Implementierungen.
# SELinux is a MAC implementation for Linux
# Check SELinux mode and policy
getenforce # Enforcing / Permissive / Disabled
sestatus # Detailed SELinux status
# View SELinux security context labels on files
ls -Z /etc/passwd
# system_u:object_r:passwd_file_t:s0 /etc/passwd
# Security context: user:role:type:level
# A process can only access files where its type has explicit permission
sudo ausearch -m avc -ts recent # View MAC policy denialsBell-LaPadula- und Biba-MAC-Modelle
Zwei formale MAC-Modelle bilden Sicherheitsziele mithilfe mathematischer Regeln ab. Bell-LaPadula konzentriert sich auf die Vertraulichkeit: Subjekte dürfen keine Daten oberhalb ihrer Klassifizierungsstufe lesen (kein Lesen nach oben) und keine Daten auf eine niedrigere Klassifizierungsstufe schreiben (kein Schreiben nach unten). Dadurch wird verhindert, dass sensible Informationen zu nicht autorisierten Benutzern gelangen. Biba konzentriert sich auf die Integrität: Subjekte dürfen nicht auf eine höhere Integritätsstufe schreiben (kein Schreiben nach oben) und nicht von einer niedrigeren Integritätsstufe lesen (kein Lesen nach unten). Biba verhindert, dass Daten mit hoher Integrität durch Eingaben mit niedriger Integrität verunreinigt werden. Reale MAC-Systeme wie SELinux kombinieren Aspekte beider Modelle.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) weist Rollen statt einzelnen Benutzern direkt Berechtigungen zu und ordnet anschließend Benutzer diesen Rollen zu. Dadurch wird die Verwaltung einzelner Berechtigungen in großem Maßstab erleichtert. Häufige Rollen in Unternehmensumgebungen sind: admin, auditor, developer, HR_manager, finance_analyst. Wenn eine neue beschäftigte Person hinzukommt, wird sie der passenden Rolle zugewiesen und erbt sofort alle für diese Rolle erforderlichen Berechtigungen. Bei einem Positionswechsel ändert sich ihre Rolle, und die Berechtigungen werden automatisch angepasst. RBAC ist das vorherrschende Modell in IAM-Systemen von Unternehmen.
# RBAC example (database permissions)
# Create roles and assign permissions
CREATE ROLE readonly_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_analyst;
CREATE ROLE data_engineer;
GRANT SELECT, INSERT, UPDATE ON customer_data TO data_engineer;
# Assign users to roles
GRANT readonly_analyst TO alice;
GRANT data_engineer TO bob;
# When Alice is promoted: revoke old role, grant new one
REVOKE readonly_analyst FROM alice;
GRANT data_engineer TO alice;Vorteile von RBAC: Skalierbarkeit und Funktionstrennung
Der wichtigste Vorteil von RBAC ist die administrative Skalierbarkeit. Eine Änderung der Berechtigungen einer Rolle wirkt sich sofort auf alle Benutzer mit dieser Rolle aus – einzelne Benutzerdatensätze müssen nicht in Hunderten von Systemen aktualisiert werden. RBAC unterstützt auf natürliche Weise die Funktionstrennung, indem sichergestellt wird, dass keine einzelne Rolle miteinander unvereinbare Berechtigungen besitzt (beispielsweise eine Rolle, die sowohl Finanztransaktionen erstellen als auch genehmigen kann). RBAC vereinfacht außerdem die Compliance: Prüfer können Rollen und deren Berechtigungen überprüfen, anstatt Tausende individueller Benutzerzuweisungen zu auditieren. Die Einschränkung ist die Rollenexplosion: Unternehmen erstellen manchmal zu viele granular aufgegliederte Rollen, was die Verwaltung verkompliziert und den Skalierbarkeitsvorteil zunichtemacht.
Rule-Based Access Control
Rule-Based Access Control (nicht zu verwechseln mit RBAC) gewährt oder verweigert Zugriff anhand einer Reihe von bedingten Regeln und nicht allein anhand der Identität oder Rolle. Firewallregeln sind das klassische Beispiel: „TCP von 192.168.1.0/24 zu beliebigem Ziel über Port 443 erlauben. Den gesamten anderen Datenverkehr verweigern.“ Der Zugriff wird nacheinander anhand der Regeln ausgewertet, bis eine Übereinstimmung gefunden wird. Regelbasierte Zugriffssteuerung wird häufig mit anderen Modellen kombiniert: MAC verwendet Sicherheitskennzeichnungen als Regeln, und Attribute-Based Access Control (ABAC) erweitert die regelbasierte Logik, indem mehrere Attribute (Abteilung des Benutzers, Gerätetyp, Tageszeit, Klassifizierung der Ressource) gleichzeitig für fein abgestufte Entscheidungen ausgewertet werden.
# Rule-based access control: iptables firewall rules
# Rules are evaluated in order; first match wins
# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow specific source IP to SSH
iptables -A INPUT -s 10.0.0.100 -p tcp --dport 22 -j ACCEPT
# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Default deny all other inbound
iptables -A INPUT -j DROPAttribute-Based Access Control (ABAC)
ABAC (Attribute-Based Access Control) ist das flexibelste und am feinsten abgestufte Zugriffssteuerungsmodell. Bei Zugriffsentscheidungen werden mehrere Attribute gleichzeitig ausgewertet: Attribute des Subjekts (Abteilung des Benutzers, Freigabestufe, Standort), Attribute des Objekts (Datenklassifizierung, Besitzerabteilung, Aufbewahrungskennzeichnung), Umgebungsattribute (Tageszeit, Gerätetyp, Netzwerkstandort) und Aktionsattribute (Lesen, Schreiben, Löschen). Eine Richtlinie könnte lauten: „Zugriff erlauben, wenn user.department = Finance UND resource.classification = Internal UND device.type = corporate UND time.hour BETWEEN 8 AND 18.“ ABAC ermöglicht Zero-Trust-Richtlinienentscheidungen und wird von Produkten wie XACML und cloudbasierten IAM-Richtlinien-Engines implementiert.
Das passende Modell auswählen
Das geeignete Zugriffssteuerungsmodell hängt von den Sicherheitsanforderungen und dem organisatorischen Kontext ab. DAC: geeignet für persönliche Computer und kleine Teams, in denen Komfort Vorrang vor strenger Kontrolle hat. MAC: erforderlich in geheimschutzbedürftigen staatlichen oder militärischen Umgebungen mit strikt voneinander abgeschotteten Informationen. RBAC: ideal für Unternehmen, in denen administrative Skalierbarkeit entscheidend ist und Rollen klar den beruflichen Funktionen entsprechen. ABAC: geeignet für Cloud-Umgebungen und Zero-Trust-Architekturen, in denen kontextbezogene, fein abgestufte Richtlinien erforderlich sind. In der Praxis verwenden die meisten Unternehmen eine Kombination: RBAC als Grundlage und ABAC für kontextsensitive Zugriffsentscheidungen.
Zugriffssteuerungslisten (ACLs)
Unabhängig vom Zugriffssteuerungsmodell sind Zugriffssteuerungslisten (ACLs) der am häufigsten verwendete technische Implementierungsmechanismus. Eine an eine Ressource angehängte ACL legt fest, welche Subjekte welche Aktionen ausführen dürfen. Dateisystem-ACLs (Windows NTFS, Linux-POSIX-ACLs) steuern den Zugriff auf Dateien und Verzeichnisse. Netzwerk-ACLs steuern den Datenverkehr auf Router- oder Cloud-Netzwerkebene. Datenbank-ACLs steuern den Zugriff auf Tabellen und einzelne Zeilen. ACLs können jedes der besprochenen Modelle implementieren: Die ACL einer Datei implementiert DAC, wenn der Eigentümer sie steuert; die ACL eines Sicherheitssystems implementiert MAC, wenn Labels die Einträge bestimmen; und die ACL einer Anwendung implementiert RBAC, wenn sich die Einträge auf Rollen beziehen.
# Windows NTFS ACL example using icacls
# View current ACL on a folder
icacls 'C:\Sensitive\HR_Data'
# BUILTIN\Administrators:(OI)(CI)(F) <- Full control
# CONTOSO\HR_Team:(OI)(CI)(RX) <- Read and Execute
# Grant specific permissions to HR Managers group
icacls 'C:\Sensitive\HR_Data' /grant 'CONTOSO\HR_Managers:(OI)(CI)(M)'
# (OI)=Object Inherit, (CI)=Container Inherit, (M)=Modify
# Remove access for a former contractor
icacls 'C:\Sensitive\HR_Data' /remove 'CONTOSO\contractors'Kurze Überprüfung
Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.
Lektionszusammenfassung
In dieser Lektion haben Sie gelernt: DAC ermöglicht es Ressourceneigentümern, den Zugriff zu steuern (flexibel, aber riskant); MAC verwendet vom System erzwungene Sicherheitslabels (streng und in Umgebungen mit Verschlusssachen eingesetzt); RBAC weist Rollen Berechtigungen zu und ist dadurch in Unternehmen skalierbar; und ABAC wertet mehrere Attribute für fein abgestimmte Zero-Trust-Entscheidungen aus. Als Nächstes sehen wir uns föderierte Identitäten: SAML, OAuth und OpenID Connect an.
Häufig gestellte Fragen
Ist die Lektion „Autorisierungsmodelle: RBAC, MAC und DAC“ kostenlos?
Ja — der vollständige Text von „Autorisierungsmodelle: RBAC, MAC und DAC“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Security+ Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Autorisierungsmodelle: RBAC, MAC und DAC“?
Vergleichen Sie rollenbasierte, verbindliche und benutzerbestimmte Zugriffskontrollmodelle und lernen Sie, wann welches Modell im Unternehmens- und Behördenkontext geeignet ist. Du übst Security+ Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Security+ Academy zu starten?
Keine Vorkenntnisse erforderlich. Security+ Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Autorisierungsmodelle: RBAC, MAC und DAC“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Security+ Academy-Lektion Code schreiben und ausführen?
Ja. Jede Security+ Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Passwortrichtlinien und Multifaktor-Authentifizierung
- Biometrie und tokenbasierte Authentifizierung
- Autorisierungsmodelle: RBAC, MAC und DAC
- Föderierte Identitäten: SAML, OAuth und OpenID Connect