IT-Sicherheit: Zugriffskontrolle - ... · PDF fileUni Bremen: „grp“ zur ......
Transcript of IT-Sicherheit: Zugriffskontrolle - ... · PDF fileUni Bremen: „grp“ zur ......
IT-Sicherheit:
Zugriffskontrolle
2
AAA
Zugriffskontrolle (access control) regelt: „Wer darf in einem IT-Systemauf welche Ressourcen
wie zugreifen“.
Alternativer Begriff: Autorisierung (authorization)AAA = Authentication, Authorization, Accounting(Authentisierung, Autorisierung, Abrechnung)
3
Grundbegriffe: Zugriffskontrolle
Subjekt (subject): Initiator der HandlungBenutzer (z.B. Alice, Bob), Gruppen, Prozesse, Rechner/Geräte
Genauer: principal als IT-Realisierung einer person oder Funktion
Objekt (object): Gegenstand der Handlung, RessourceDateien, SQL-Tabellen, Konto, Prozesse
Achtung: Subjekte können auch Objekte sein.
Berechtigung (permission)bzw. Zugriffsrecht (access right):
Was genau darf gemacht werden
Z.B.: lesen, schreiben, ausführen, löschen
4
Unterschiedliche Ebenen derZugriffskontrolle
Abhängigkeit der höherenEbenen von denZugriffskontrollmechanismender niedrigeren EbenenZugriffskontrollmechanismensind in höheren Ebenenkomplexer.Fehler in niedrigeren Ebenenkönnen zum Umgehen derSicherheitsmechanismen derhöheren Ebenen führen.
Anwendung
Middleware
Betriebssystem
Hardware
5
Referenzmonitor
Principle of Complete Mediation
The protection mechanism should check every access toevery object.
Referenzmonitor
Subjekte Objekte
6
Zugriffsmatrix (Lampson 1974)
Zugriffskontrolle wird in ihrer grundlegenden Form dargestelltdurch eine Zugriffskontrollmatrix (access control matrix) Mmit:
M: S x O 2R
(S Menge der Subjekte, O Menge der Objekte,R Menge der Zugriffsrechte wie z.B. read, write, execute)
Subjekt s darf Objekt o genau dann lesen, wenn
read M(s,o).
7
Beispiel für eine Zugriffsmatrix
{read}Frank
{read}{read}Janet
{suspend}{execute}Bob
{write}{read,write}
Alice
Prozess 1Datei 3Datei 2Datei 1Subjekt/
Objekt
M(Alice,Datei1)
={read,write}
8
Zugriffskontrolllisten (1)
Zugriffsmatrix ist oft dünn besetzt, d.h. eine vollständigeSpeicherung ist zu speicherintensiv O(|S| |O|).
Zugriffskontrolllisten (access control lists, ACLs):Realisierung der Matrix nach Spalten
Subjekte und deren Zugriffsrechte werden beim Objekt
gespeichert.
Beispiel:
ACL(Datei1)=((Alice, {read,write}),(Frank,{read}))
9
Zugriffskontrolllisten (2)
am häufigsten eingesetztes Konzept für dieZugriffskontrolle in gängigen Betriebssystemen(Windows NT (= 2000/XP), Unix/Linux)Vorteile:
vergebene Zugriffsrechte sind effizient für ObjektebestimmbarRechterücknahme (pro Objekt) ist meist effizientrealisierbareinfach zu implementieren
10
Zugriffskontrolllisten (3)
Nachteile:Bestimmen der Subjekt-Rechte i.d.R. sehr aufwendig(alle Objekte im System untersuchen)
aufwendige ACL-Kontrollen bei jedem Zugriff
schlechte Skalierbarkeit bei sehr dynamischwechselnder Menge von Subjekten, falls ACLs füreinzelne Subjekte/Nutzer vergeben werden
11
Beispiel: Zugriffskontrolle in Unix
Subjekte:Benutzer: User-ID, Group-ID, supplementary Group IDs (bis zu 16)Prozeß: User-ID/Group-ID (effective, real, saved),supplementary Group IDs
Dateien:Owner (User-ID), Group (Group-ID)rwx-bits für: Owner, Group, OthersUid, sGid: Rechteveränderung bei Dateiaufruf
Verzeichnisse:Ebenso, plus:t-Bit (nur der Eigentümer darf Dateien in diesem Verzeichnis löschen)sGid-Bit (steuert Gruppe bei Datei-Erzeugung)
12
Beispiel: Zugriffskontrolle in Unix
Schutzbits sind einfache Form von ACLInformationen für die Zugriffskontrolle den Dateien zugeordnet
Schutzbit-ACL so nicht feingranular genug:Alice kann nicht Bob allein nur Lese-Rechte auf eine bestimmteDatei geben.
Uni Bremen: „grp“ zur Einrichtung von Gruppen durch Benutzer
FreeBSD, Solaris haben zusätzliches ACL-Konzept
Befehle: getfacl, setfacl
13
FreeBSD-ACLs (POSIX .1e)
Menge von Tripeln Typ:Name:Rechteuser::rwx (Dateieigner) 1
group::r-x (Gruppe der Datei) 3
other::r-x (Der Rest) 5
Neu:user:fritz:r-x (spezifischer Benutzer) 2
group:katzen:rwx (spezifische Gruppe) 4
Einschränkung über Maske (chmod-Kompatibilität)mask::r-x (schränkt alles außer 1 und 5 ein)
14
Windows-ACLs (1)
Zugriffsrechte auf Dateien, Ordner oder Drucker werden mitAccess Control Lists verwaltet.
Pro Objekt:
Security identification number (SID) als Bezeichner für Eigner
ACL
ACL besteht aus einzelnen Access Control Entries (ACEs):a) Typ des ACE (Erlauben, Verweigern; Überwachen)
b) Subjekt (Benutzer oder Gruppe), für den/die der ACE giltSID als Bezeichner für Subjekt
c) Operationen, für die der ACE gilt (Bitmaske)
d) Vererbbarkeit der ACE auf Unterobjekte
15
Windows-ACLs (2)
ACL:
Vererbbarkeit:
16
Windows-ACLs (3)
Besitzer hat immer VollzugriffBesitzer kann auch eine Gruppe sein
Alle ACEs werden in Reihenfolgeausgewertet.
GUI:Deny hat Vorrang vor Allow-Regeln
Vorsicht: Verbietet man einer Gruppealles, gibt es keine Möglichkeit,Einzelnen Rechte zu geben!!
17
Capabilities (1)
Zeilenweise Realisierung der Matrix
Capability, Zugriffsticket mit Objekt-ID und Rechtebits
Capability-Besitz berechtigt zur Wahrnehmung der Rechte
Für jedes Subjekt s eine Capability-Liste (Clist)Beispiel Clist (Alice) = ((Datei1, {read,write}), ((Datei3, {write}))
18
Capabilities (2)
Beispiele von Systemen mit Capability-Konzept:IBM System/38 und AS/400, Mach- -Kern (Ports), Amoeba
UNIX: File Descriptor = flüchtige CapabilityDeskriptor-Tabelle in User-Structure = C-List
Übergabe von Deskriptoren über UNIX-Domain-Sockets
Achtung: Keine Capabilties in diesem Sinne:“POSIX Capabilities” (z.B. von Linux ab 2.2 unterstützt)
Besseres Wort: Privileges
Renaissance des Capability-Konzeptes durch Zertifikate
19
Capabilities (3)
Vorteile :
einfache Bestimmung der Subjekt – Rechte
einfache Zugriffskontrolle: nur noch Ticketkontrolle!
einfache Delegation von Rechten andere Benutzer/Subjekte
Nachteile:
Rechterücknahme schwierig (Ticket ist aus der Hand)
keine Subjekt-Ticket Kopplung,Besitz berechtigt automatisch zur Wahrnehmung der Rechte
Objekt-Sicht auf Rechte schwierig: Wer darf was?
22
Bis hierher: DAC(Discretionary Access Control)
Bislang:Subjekte entscheiden über dieZugriffsberechtigungen(vgl. chmod in Unix/Linux oder Dialogfenster zurRechtevergabe in Windows 2000/XP).Subjekt bestimmt weitgehend die Security Policyfür „seine“ Objekte(benutzerbestimmte Zugriffskontrolle bzw.discretionary access control).
23
Mandatory Access Control (MAC)
In besonders sicherheitskritischen Bereichen mit z.B.hohen Anforderungen an die Vertraulichkeit istbenutzerbestimmte Zugriffskontrolle nicht angemessen.
Typisches Beispiel: Militär, Geheimdienste
Einführung geeigneter Modelle, die vom Systemumgesetzt werden.Systembestimmte Zugriffskontrolle(mandatory access control)Bekanntestes Beispiel für Mandatory Access Control:Bell-LaPadula-Modell
24
Das Bell-LaPadula-Modell (BLP)
David Bell and Len LaPadula, 1973:auf Initiative der US Air Force
Zweck:einfache Sicherheitsmechanismen für die Verifikation
Formales Sicherheitsmodell
Beschränkung des Informationsflusses, d.h. Sicherheitsziel ist dieVertraulichkeit
25
Das Bell-LaPadula-Modell (BLP)
Ein vereinfachtes BLP-Modell:Multilevel Security System (MLS)
Alle Subjekte und Objekte erhalten eineSicherheitsmarkierung (label)gemäß der Stufe ihrer Vertraulichkeit wie z.B.top secret > secret > confidential > unclassifiedIdee: Höher klassifizierte Daten dürfen nur vonMitarbeitern mit einer ausreichenden Sicherheitsstufegelesen werden.
26
Bell-LaPadula-Modell (2)
Formalisierung der Idee:M sei die Zugriffsmatrix.SC sei eine Menge von Sicherheitsmarkierungen, und auf SCgelte eine partielle Ordnung.o O: SC(o) SC sei die Sicherheitsmarkierung von Objekt o(classification)s S: SC(s) SC sei die Sicherheitsmarkierung von Subjekt s(clearance)
Simple Security-Property (no read-up) :
s S. o O : read M(s,o) SC(o) SC(s)
27
Bell-LaPadula-Modell (3)Die no-read-up-Regel reicht nicht: Trojanische Pferde
könnten höher klassifizierte Daten einfach nach untenschreiben.
Die kritische Neuerung des BLP-Modelles ist mithin diezweite Regel:*-Property (no write-down) :
s S. o O : write M(s, o) SC(s) SC(o)
Manchmal fordert man auch, dass sich dieSicherheitsmarkierungen weder für Objekte noch fürSubjekte zur Systemlaufzeit ändern(Strong Tranquility Property).
28
Beispiele: BLP
Viele Betriebssysteme bieten BLP-Erweiterungen: u.a.
Sun Trusted Solaris 7, Trusted HP-Unix, Linux-DerivateErweiterter Referenz-Monitor zur Überprüfung der BLP-Regeln
Meist teure, veraltete Version des Betrie
Daten-Diode (-„Pumpe“):Daten können über ein Kommunikations-Device (Daten-Diode)von Low nach High transferiert (gepumpt) werden,aber nicht in der umgekehrten Richtung.
Beispiel: NRL-Pump (US Naval Research Laboratory), 1993
29
Fazit: BLP
Stärken:einfach zu implementieren (Anpassung des Referenzmonitors)
formales Modell (man kann Sätze über Eigenschaften beweisen)
gut geeignet zum Nachbilden hierarchischer Informationsflüsse:
z.B. beim Militär, Geheimdienst
Schwächen:beschränkte Ausdrucksfähigkeit:keine Integrität (blindes Schreiben)
Keine Modellierung von verdeckten Kanälen (covert channels),über die Informationen dann doch unberechtigt fließen können
31
Verdeckte Kanäle
Zugriffskontrolle schützt den Datencontainer, nicht die InformationMöglichkeit von verdeckten Kanälen
Verdeckte Kanäle (covert channels) :
Informationsfluß über einen Kanal, der nicht explizit zurInformationsübertragung vorgesehen ist
Beispiele:
Ressourcen-Konflikt: High-Level-Prozess erzeugt eine Datei, so dass einLow-Level-Prozess eine Fehlermeldung erhält, wenn eine Datei mitgleichem Namen erzeugt wird (1 Bit Information)
High-Level-Prozess kann gemeinsam genutzte Ressourcen (Position desFestplattenkopfes, Inhalt des Caches) in einem Zustand hinterlassen, sodass der Low-Level-Prozess anhand von Antwortzeiten zusätzlicheInformationen gewinnen kann.
32
Rollenbasierte Zugriffskontrolle (1)
Bei der rollenbasierten Zugriffskontrolle (role-based
access control, RBAC) werden die Rechte nicht mehrdirekt an Subjekte, sondern an Rollen (roles) geknüpft.
Rollen entsprechen häufig Funktionen/Aufgaben, die ineiner Organisation (Krankenhaus, Bank, Behörden,Unternehmen) auftreten.
geeignet für hierarchisch aufgebaute Organisationen
Beispiel: Krankenhaus:Arzt, Pflegepersonal, Apotheker
33
Rollenbasierte Zugriffskontrolle (2)
Komponenten des RBAC96-Modelles gemäß Sandhu et al.:
Mengen:Users (U), Roles (R), Permissions (P), Sessions (S)
Relationen:
UA ⊆ UxR (user assignment)
PA ⊆ PxR (permission assignment)
RH ⊆ RxR (role hierarchy), RH ist eine partielle Ordnung auf RxR
Rollen werden von Benutzern in Sessions (Sitzungen) aktiviert, wobeijede Session genau einen User hat. Andererseits kann ein User mehrereSessions aktivieren.
34
Komponenten von RBAC96
U
Users
P
Permiss.R
Roles
S
Sessions
UA PA
RH
.
.
.
35
Rollenhierarchie: BeispielChefarzt
NachtschwesterTagschwester
Oberschwester
Schwester
Medizinisches Personal
Arzt
36
Einsatzgebiete
Betriebssysteme (RACF von IBM, Windows NT/2000zumindest als Gruppenkonzept)Middleware (z.B Web Services)Rollenbasierte Administrationswerkzeuge wie z.B. dieDirXMetaRole von Siemens oder IBM TivoliDatenbanken (z.B. Oracle, Sybase, Informix)Enterprise Resource Planning Systeme wie z.B. SAPKrankenhausinformationssysteme, Bankenanwendungen(weite Verbreitung im Bankenbereich)...
37
Stärken
Rollenkonzepte sind flexibel verwendbarvereinfachtes Berechtigungsmanagement(wenn bspw. Benutzer häufig wechseln, dann braucht inder Regel nur die Relation UA angepasst zu werden)Abbildung von hierarchischen Organisationsstrukturenintuitive Abbildung auf GeschäftprozesseMöglichkeit, organisationsinterne Sicherheits- undKontrollregeln abzubilden (z.B. das Konzept derAufgabentrennung im Bankenbereich)sowohl Vertraulichkeit als auch Datenintegrität(BLP kann durch RBAC simuliert werden)
38
Schwächen
Woher bekommt man überhaupt die Rollen, die für eineOrganisation relevant sind?(Problem des Role Engineerings)automatische Zuweisung von Berechtigungen zu Rollenwird nicht ausreichend unterstützt (manuelle Zuweisung ingroßen Organisationen nicht praktikabel)Rollenproliferation (Beispiel: Krankenhaus mit 250 Rollen)
Viele Projekte zur Einführung von RBAC scheitern auso.g. Gründen.kein Schutz gegenüber Covert Channels.
39
Nächster Termin
Mo, 25.04.2005 10–12 Uhr, MZH 1400:
• Zugriffskontrolle (Vertiefung und Aufgaben)
Übungsblatt 2 auf Stud.IP, s.:https://elearning.uni-bremen.de