In der Computersicherheit ist die diskretionäre Zugriffskontrolle ( Discretionary Access Control , DAC ) eine Art der Zugriffskontrolle, die in den Trusted Computer System Evaluation Criteria [ 1 ] (TCSEC) definiert ist. Sie dient dazu, den Zugriff auf Objekte basierend auf der Identität der Subjekte und/oder Gruppen, denen sie angehören, einzuschränken. Die Kontrollen sind diskretionär , da ein Subjekt mit einer bestimmten Zugriffsberechtigung diese Berechtigung (gegebenenfalls indirekt) an jedes andere Subjekt weitergeben kann (sofern dies nicht durch eine obligatorische Zugriffskontrolle untersagt ist ).
Diskretionäre Zugriffskontrolle wird üblicherweise im Gegensatz zur obligatorischen Zugriffskontrolle (MAC) diskutiert. Gelegentlich spricht man von einer „diskretionären“ oder „rein diskretionären“ Zugriffskontrolle für ein System, dem die obligatorische Zugriffskontrolle fehlt. Systeme können jedoch sowohl MAC als auch DAC gleichzeitig implementieren. DAC bezeichnet dabei eine Kategorie von Zugriffskontrollen, die Benutzer untereinander übertragen können, während MAC eine zweite Kategorie von Zugriffskontrollen darstellt, die die erste einschränkt.
Durchführung
Die Bedeutung des Begriffs ist in der Praxis nicht so eindeutig wie in der Definition des TCSEC-Standards, da die TCSEC-Definition von DAC keine bestimmte Implementierung vorschreibt. Es gibt mindestens zwei Implementierungen: mit Eigentümer (als weit verbreitetes Beispiel) und mit Fähigkeiten. [ 2 ]
Mit Eigentümer
Der Begriff DAC wird häufig in Kontexten verwendet, die davon ausgehen, dass jedes Objekt einen Eigentümer hat , der die Zugriffsrechte auf das Objekt kontrolliert. Dies liegt wahrscheinlich daran, dass viele Systeme DAC tatsächlich mithilfe des Eigentümerkonzepts implementieren. Die TCSEC-Definition spricht jedoch nicht explizit von „Eigentümern“, weshalb ein Zugriffskontrollsystem nicht zwingend ein Eigentumskonzept benötigt, um der TCSEC-Definition von DAC zu entsprechen.
Bei dieser DAC-Implementierung können Benutzer (Eigentümer) Richtlinien festlegen und/oder Sicherheitsattribute zuweisen. Ein einfaches Beispiel ist der Unix-Dateimodus , der in den jeweils drei Bits für Benutzer, Gruppe und Andere Schreib-, Lese- und Ausführungsrechte repräsentiert. (Darüber steht ein weiteres Bit, das zusätzliche Eigenschaften angibt.)
Mit Fähigkeiten
Ein weiteres Beispiel: Capability-Systeme werden mitunter als Systeme mit Ermessensspielraum beschrieben, da sie es Subjekten ermöglichen, ihre Zugriffsrechte an andere Subjekte weiterzugeben, obwohl es bei Capability-basierter Sicherheit im Kern nicht darum geht, den Zugriff „aufgrund der Identität von Subjekten“ einzuschränken. Im Allgemeinen erlauben Capability-Systeme nicht, Berechtigungen „an beliebige andere Subjekte“ weiterzugeben; das Subjekt, das seine Berechtigungen weitergeben möchte, muss zunächst Zugriff auf das empfangende Subjekt haben, und Subjekte haben im Allgemeinen nur Zugriff auf eine streng begrenzte Anzahl von Subjekten, die dem Prinzip der minimalen Berechtigungen entspricht .
Siehe auch
- Zugriffskontrollliste
- Attributbasierte Zugriffskontrolle (ABAC)
- Kontextbasierte Zugriffskontrolle (CBAC)
- Graphbasierte Zugriffskontrolle (GBAC)
- Gitterbasierte Zugriffskontrolle (LBAC)
- Obligatorische Zugriffskontrolle (MAC)
- Rollenbasierte Zugriffskontrolle (RBAC)
- Regelbasierte Zugriffskontrolle (RSBAC)
- Fähigkeitsbasierte Sicherheit
- Risikobasierte Authentifizierung
- XACML (Extensible Access Control Markup Language)
Referenzen
Zitate
- ^ Bewertungskriterien für vertrauenswürdige Computersysteme . US-Verteidigungsministerium. Dezember 1985. DoD-Standard 5200.28-STD. Archiviert vom Original am 27.05.2006.
- ^ http://fedoraproject.org/wiki/Features/RemoveSETUID – Fedora 15 entfernt SETUID zugunsten von (Linux-Kernel-)Funktionen.
Quellen
- P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner und J. F. Farrell. Die Unvermeidbarkeit des Scheiterns: Die fehlerhafte Annahme von Sicherheit in modernen Computerumgebungen . In: Proceedings der 21. Nationalen Konferenz für Informationssystemsicherheit, S. 303–314, Oktober 1998. PDF-Version .