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