Role-based Access Control

Transkript

1 Technische Universität München Fakultät für Informatik Lehrstuhl VII Theoretische Informatik und Grundlagen der KI Hauptseminar Security: zwischen formalen Methoden und Praxis Role-based Access Control 23. Juni 2004 Bearbeiter: Sebastian Esch Betreuer: Dr. Stefan Katzenbeisser

2 1. Inhaltsverzeichnis 1. Inhaltsverzeichnis Einführung Was ist Zugriffskontrolle? Zugriffskontrolle im Bezug auf andere Sicherheitsmaßnahmen Die Zugriffsmatrix Implementierungsansätze Andere Access Control Policies Discretionary Access Control Mandatory Access Control Role-Based Access Control Entwicklungsgeschichte Formale Beschreibung Administration Principle of Least Privilege Separation of Duties Literatur...15 Seite 2

3 2. Einführung Dieses Paper behandelt das Thema Role-Based Access Control, einem Ansatz für die Zugriffskontrolle in Computersystemen der von 1992 bis heute am National Institute for Standards and Technology entwickelt wurde. Das Kapitel Einführung gibt einen Überblick, was Zugriffskontrolle bedeutet und wo sie im Sicherheitskonzept von Computersystemen eingeordnet ist, sowie eine Abgrenzung zu anderen Komponenten in diesem Sicherheitskonzept. Das Kapitel Andere Access Control Policies gibt einen Überblick über die klassischen Methoden für die Zugriffskontrolle: Discretionary Access Control (DAC) und Mandatory Access Control (MAC). Im Kapitel Role-Based Access Control (RBAC) wird das rollenbasierte Modell im Detail vorgestellt. Es wird kurz auf die Entwicklungsgeschichte eingegangen. Dann wird die formale Beschreibung des RBAC Modells beschrieben und anschließend die Prinzipien Least Privilege und Separation of Duties erläutert Was ist Zugriffskontrolle? Das Ziel von Zugriffskontrolle ist es, Aktionen und Operationen von Benutzern zu beschränken, um zu Verhindern, dass gegen Sicherheitsrichtlinien verstoßen wird, die in einer Organisation gelten. Dazu gehört auch, Programme einzuschränken, die von einem Benutzer ausgeführt werden. Dabei sollen die allgemeinen Ziele von Sicherheit in Informationssystemen erreicht werden: Vertraulichkeit, Integrität und Verfügbarkeit der Daten Zugriffskontrolle im Bezug auf andere Sicherheitsmaßnahmen Zugriffskontrolle ist eine von mehreren Komponenten, die zur Umsetzung von Sicherheitsrichtlinien in Computersystemen dient. Dabei kann Zugriffskontrolle aber auf keinen Fall alleine stehen, da Zugriffskontrolle eine erfolgreiche und korrekte Identifikation voraussetzt, die von der Autorisierungskomponente gewährleistet werden muss. Die Zugriffskontrolle kann nur den Zugriff von legitimierten Benutzern beschränken. Wenn sich ein Angreifer der Identität eines Benutzers bemächtigt, ist die Zugriffskontrolle nicht in der Lage, das System vor unbefugtem Zugriff zu schützen. Seite 3

4 Um die Zugriffe im System wirkungsvoll einzuschränken werden alle Anfragen an einen Referenzmonitor geschickt, der überprüft, ob die vom Benutzer gewünschte Aktion erlaubt ist. Dazu stellt der Referenzmonitor eine Anfrage an eine Datenbank, die alle Zugriffsrechte speichert. Erst, wenn sichergestellt ist, dass der Benutzer für den Zugriff auf das Objekt berechtigt ist, wird der Zugriff gewährt. Abbildung 1 - Zugriffskontrolle und andere Sicherheitsdienste Diese Datenbank wird von einem oder mehreren Sicherheitsadministratoren entsprechend der Sicherheitsrichtlinien der Organisation gepflegt. Es kann aber auch der Fall sein, dass Benutzer berechtigt sind, gewisse Bereiche der Datenbank selbstständig zu verändern, um beispielsweise Rechte an persönlichen Dateien festzulegen. Die Auditingkomponente überwacht alle Anfragen und Zugriffswünsche und protokolliert diese mit. Dadurch ist eine nachträgliche Analyse der Zugriffe möglich und versuchte oder erfolgreiche Verstöße gegen die Sicherheitsrichtlinien können aufgespürt werden. Durch die Nachvollziehbarkeit aller Aktionen im System ist auch eine gewisse Abschreckung der Benutzer gegeben, Verstöße gegen die Sicherheitsrichtlinien zu begehen. Seite 4

5 Das in Abbildung 1 gezeigte Bild einer Sicherheitsarchitektur entspricht nicht immer dem Bild in der Realität. Die scharfe Trennung zwischen Autorisierung, Zugriffskontrolle, Auditing und Administration ist in der Praxis nicht immer genau so scharf implementiert. Auch die Trennung der Zugriffsdaten und der Datenobjekte ist, wie später gezeigt, in der Praxis oft so nicht gegeben. Es wird bei der Zugriffskontrolle zwischen Richtlinien und Mechanismen unterschieden. Richtlinien legen fest, wie über Zugriffe entschieden wird und die Zugriffe kontrolliert werden. Mechanismen sind konkrete Hardware- und Softwarefunktionen, die unabhängig von Richtlinien implementiert werden und dann entsprechend einer Richtlinie konfiguriert werden können Die Zugriffsmatrix Es wurde eine ganze Reihe von Abstraktionen entwickelt, um das Thema Zugriffskontrolle zu diskutieren. Die bedeutendste These dabei ist diejenige, dass alle Ressource, die von Computersystemen verwaltet werden, Objekte sind, in denen Daten gespeichert sind, (z.b. Dateien). Aktivitäten im System werden von Subjekten ausgelöst, wobei es sich um Benutzer oder vom Benutzer ausgeführte Programme handelt. Ein Benutzer kann verschiedene Subjekte darstellen, wenn er sich beispielsweise für unterschiedliche Projekte mit unterschiedlichen Rechten als verschiedene Subjekte anmeldet. Subjekte können wiederum selber Objekte sein. Zum Beispiel können Prozesse, die ein Benutzer in einer verteilten Umgebung startet, von diesem Unterbrochen oder Beendet werden. Die Bedeutung von Zugriffsrechten kann je nach Art der Objekte unterschiedlich sein. Bei Dateien sind die Zugriffsrechte typischerweise Lesen, Schreiben, Ausführen und Besitzen, wobei Besitzen bedeutet, dass der Benutzer in der Lage ist, die Zugriffsrechte der Datei zu verändern. File 1 File 2 File 3 Account 1 Account 2 Alice, Inquiry Credit Bob Read Write Inquiry Debit Inquiry Credit John Read Inquiry Debit Abbildung 2 Access Matrix Seite 5

6 Bei einem Bankkonto könnten die Rechte Kontostand abfragen, Einzahlen und Abheben sein. Solche Zugriffe werden als Anwendungslogik implementiert; im Gegensatz zu Operationen auf Dateien, die vom Betriebssystem verwaltet werden. Die Zugriffsmatrix ist ein Modell, das für jedes Subjekt und jedes Objekt die vorhandenen Zugriffsrechte festlegt. Jedes Subjekt hat eine Zeile und jedes Objekt eine Spalte in der Matrix. Jedes Element in der Matrix enthält für das entsprechende Subjekt die Zugriffsrechte auf das entsprechende Objekt. Die Aufgabe der Zugriffskontrolle ist es nun, nur solche Operationen zuzulassen, die in der Zugriffsmatrix erlaubt sind. Dazu verwendet man einen Referenzmonitor, der jeden Zugriff auf das System überprüft. Das Zugriffsmatrixmodell trennt ganz klar Autorisierung und Zugriffskontrolle Implementierungsansätze In einem realen System wird die Zugriffsmatrix sehr groß und die meisten Einträge werden leer sein. Deshalb ist die Zugriffsmatrix sehr selten wirklich als Matrix implementiert. Es werden nun drei Methoden vorgestellt, wie die Zugriffsmatrix in wirklichen Systemen realisiert wird Access Control Lists Ein verbreiteter Ansatz ist durch Zugriffskontrolllisten (Access Control Lists bzw. ACLs). Jedem Objekt ist eine ACL zugeordnet, die für jedes Subjekt die entsprechenden Zugriffsrechte enthält. File 1 John Alice Bob Read Read Write File 2 Alice Bob Write File 3 Alice Bob Read Abbildung 3 Access Control List Seite 6

7 Im Prinzip ist die Spalte für File 1 in der Matrix als ACL für File 1 gespeichert, und so weiter. Mit einem Blick auf eine ACL können alle berechtigten Subjekte festgestellt werden. Mann kann auch einfach alle Zugriffe auf ein Objekt verbieten, in dem man die ACL durch eine leere ersetzt. Will man aber für ein Subjekt alle Zugriffsrechte ermitteln, kommt man nicht umhin, die ACLs für alle Objekte zu überprüfen. Wenn ein Benutzer aus einer Organisation ausscheidet, wird in der Praxis einfach der Benutzer gelöscht. Wechselt der Benutzer aber nur das Aufgabengebiet, müssen alle ACLs angepasst werden. Viele Systeme erlauben Gruppennamen in ACLs. In heutigen Betriebssystemen, wie zum Beispiel Linux, werden verkürzte ACLs benutzt, in denen nur wenige oder nur ein Gruppenname vorkommen kann. Dahingegen können in einigen Softwarepakten zur Zugriffskontrolle sehr umfangreiche ACLs angelegt werden Capabilities Capabilities sind analog zu ACLs. Jedem Subjekt wird eine Liste mit Objekten zugeordnet, die so genannte Capability List. Dies entspricht dem Abspeichern der Matrix in Reihen. John File 1 File 2 File 3 Write Read Write Alice File 1 File 2 Read Write Bob File 1 File 3 Read Abbildung 4 Capablity List Bei Capablity Lists ist es einfach alle Zugriffsrechte eines Subjekts zu bestimmen. Um aber alle Zugriffsrechte für ein Objekt zu ermitteln, muss man wieder alle Capability Lists durchgehen. Einige Systeme wurden in den 70er Jahren mit diesem Ansatz entwickelt, konnten sich aber nicht durchsetzten. Heutige Betriebssysteme setzen auf ACL-basierte Ansätze. Seite 7

8 Authorization Relations ACL- und Capability-basierte Ansätze haben analoge Vor- und Nachteile. Es gibt aber auch Ansätze, die weder eine Betrachtung der Subjekte noch eine Betrachtung der Objekte vorteilhaft macht. Ein Beispiel dafür ist die Autoriserungsrelation in Abbildung 4. Jedes Tupel spezifiziert ein Zugriffsrecht eines Subjekts auf ein Objekt. Wenn die Tabelle nach Subjekten sortiert wird, entspricht sie einer Capability List. Wenn sie nach Objekten sortiert wird, entspricht sie einer ACL. Subject Access Mode Object Alice File 1 Alice Read File 1 Alice Write File 1 Alice Read File 2 Alice Write File 2 Bob Read File 1 Bob File 2 Bob Read File 2 Bob Write File 2 Abbildung 5 Authrization Relation Seite 8

9 3. Andere Access Control Policies Neben der Role-based Access Control Policy, die im nächsten Kapitel behandelt wird, gibt es zwei Policies, die schon länger etabliert sind. Auf der einen Seite die relative flexible Discretionary Access Control Policy und die restriktive, in amerikanischen Regierungs- und Militärsystemen eingesetzte, Mandatory Access Control Policy. Diese beiden Richtlinien sind im Orange Book des amerikanischen Verteidigungsministeriums als Standards festgelegt Discretionary Access Control Bei Discretionary Access Control wird anhand der Identität des Benutzers und Berechtigungen, die für jeden Benutzer und jedes Objekt den Zugriffsmodus festlegen, entschieden, ob ein Zugriff gestattet wird, oder nicht. Die Flexibilität von DAC hat zu einer weiten Verbreitung in Systemen geführt, die von der Industrie eingesetzt werden. Der große Nachteil von DAC ist, dass es nicht möglich ist, den Informationsfluss wirksam zu regeln. Beispielsweise kann ein Benutzer, der ein Objekt lesen kann, diese Informationen an jeden beliebigen Benutzer weitergeben. Bei Richtlinien, die auf expliziten Erlaubnissen (positiven Autorisierungen) für den Zugriff beruhen, spricht man von geschlossenen Richtlinien. Die standardmäßige Entscheidung des Referenzmonitors ist eine Verweigerung des Zugriffs. Offene Richtlinien erlauben grundsätzlich den Zugriff und nur wenn ein explizites Verbot (negative Autorisierungen) für den Zugriff besteht, lehnt der Referenzmonitor den Zugriff ab. Es können auch positive und negative Autorisierungen gemeinsam eingesetzt werden, allerdings kann diese Mischung aus Verboten und Berechtigungen sehr kompliziert werden Mandatory Access Control Bei Mandatory Access Control wird der Zugriff auf Subjekte und Objekte durch eine Klassifikation in Sicherheitsstufen geregelt. Die Sicherheitsstufe eines Objekts spiegelt die Empfindlichkeit der Informationen dar, zum Beispiel den potentiellen Schaden, wenn die Information in falsche Hände gerät. Die Sicherheitsstufe, die ein Benutzer erhält, spiegelt die Vertrauenswürdigkeit des Benutzers wieder. Im einfachsten Fall ist die Sicherheitsstufe ein Element einer geordneten Menge. In Seite 9

10 militärischen und Regierungskreisen in den USA besteht diese Menge normalerweise aus den Elementen Top Secret (TS), Secret (S), Confidential (C) und Unclassified (U) mit der Relation TS > S > C > U. Jede Sicherheitsstufe dominiert sich und alle niedrigeren in dieser Hierarchie. Zugriff auf ein Objekt wird nur gewährt, wenn die Sicherheitsstufe eine bestimmte Relation zwischen den Sicherheitsstufen erfüllt. Read Down: Die Sicherheitsstufe eines Subjekts muss die des Objekts das gelesen werden soll dominieren. Write Up: Die Sicherheitsstufe eines Subjekts muss von der Sicherheitsstufe des zu schreibenden Objekts dominiert werden. So ist es nur möglich, dass Informationen in höhere oder gleiche Sicherheitsstufen weitergegeben werden. Durch diese Regeln entsteht der Nebeneffekt, dass jemand der Sicherheitsstufe S besitzt, Objekte mit Sicherheitsstufe TS überschreiben kann. Deswegen wird oft das Schreiben auf die gleiche Sicherheitsstufe beschränkt. Weiterhin kann ein Benutzer der sich als Subjekt mit Sicherheitsstufe S anmeldet keine Objekte mit Klassifizierung U oder C bearbeiten. Um das zu erreichen muss sich der Benutzer als Subjekt mit entsprechend niedrigerer Sicherheitsstufe anmelden. Dazu kann sich jeder Benutzer mit allen Sicherheitsstufen anmelden, die von seiner Sicherheitsstufe dominiert werden. Nun stellt sich die Frage, warum dann überhaupt die Write-Up-Regel existiert. In erster Linie, um zu verhindern, dass bösartige Software Informationen an niedrigere Stufen weitergibt. Der Benutzer genießt das Vertrauen, es wird davon ausgegangen, dass Benutzer keine Informationen weitergeben. Wenn man die Regeln umdreht, bekommt man eine Zugriffskontroll-Richtlinie, die die Integrität von Daten sicherstellt. Seite 10

11 4. Role-Based Access Control Um den Anforderungen der kommerziellen Anwendungen nachzukommen, wurden neben der zu schwachen DAC und der zu restriktiven MAC die Rollen-basierten Richtlinien entwickelt. Dabei wird die Tätigkeit eines Benutzers im System stärker berücksichtigt. Als erstes wird in diesem Kapitel kurz die Entwicklungsgeschichte von Role-based Access Control beschrieben. Anschließend wird RBAC formal Beschrieben. Weiter wird auf die Vorteile bei der Administration, das Prinzip der wenigsten Privilegien und die Trennung von Aufgaben eingangen. Eine Rolle ist eine Menge von Transaktionen, die ein Benutzer innerhalb der Organisation ausführen kann. Eine Transaktion ist eine Operation oder Programmfunktion mit dem dazugehörigen Datenobjekt Entwicklungsgeschichte Das Prinzip der Rollen-basierten Zugriffskontrolle wurde 1992 erstmals von David Ferrariolo und Richard Kuhn in [FK92] veröffentlicht. Seit 1995 gibt es von der ACM jährliche Workshops zum Thema RBAC. Ravi Sandhu veröffentlichte 1996 ein umfassendes Framwork für RBAC. Im Februar 2004 wurde RBAC als offizieller ANSI Standard anerkannt Formale Beschreibung Trans_a Object 1 User 1 Role 1 User Object 2 Trans_b Abbildung 6 Role Relationships Jedem Subjekt ist eine aktive Rolle zugeordnet, die es gerade benutzt: AR(s : subject) = { the active role for subject s } Jedes Subjekt kann für eine oder mehrere Rollen autorisiert sein: RA(s : subject) = { authorized roles for subject s } Jede Rolle kann für eine oder mehrere Transaktionen autorisiert sein: TA(r : role) = { transaction authorized for role r } Seite 11

12 Subjekte können Transaktionen durchführen. Das Prädikat exec(s, t) ist wahr, wenn das Subjekt s die Transaktion t zum aktuellen Zeitpunkt ausführen kann, ansonsten ist es falsch: exec(s : subject, t :transaction) = true iff subject s can execute transaction t Es werden drei Grundregeln benötigt: 1. Rollenzuweisung: Ein Subjekt kann nur eine Transaktion ausführen, wenn ihm eine Rolle zugewiesen ist: s : subject, t : transaction (exec(s, t) AR(s) ) (1) Der Anmeldeprozess wird nicht als Transaktion betrachtet. 2. Rollenautorisierung: Die aktive Rolle eines Subjekts muss für das Subjekt erlaubt sein: s : subject ((AR(s) RA(s)) (2) 3. Transaktionsautorisierung: Ein Subjekt kann eine Transaktion nur genau dann durchführen, wenn die Transaktion für die aktive Rolle erlaubt ist: s : subject, t : transaction (exec(s, t) t TA(AR(s))) (3) Mit (1) und (2) ist sichergestellt, dass Benutzer nur Transaktionen ausführen können, für die sie autorisiert sind. Durch die Bedingung genau dann, wenn, ist es möglich weitere Beschränkungen einzuführen. Die Regel garantiert nicht, dass eine Transaktion, nur weil sie in TA(RA(s)) enthalten ist, wirklich ausgeführt werden darf. So kann zum Beispiel für einen Auszubildenden die Transaktionen für eine Rolle weiter eingeschränkt werden. Die obigen Regeln benötigt keine Prüfung, ob ein Benutzer zum Zugriff auf ein Objekt berechtigt ist, da diese Information im bisherigen Transaktionsbegriff mit enthalten ist. Wenn man die Bedeutung des Transaktionsbegriffs allerdings nur als Operation ohne Bindung an ein Objekt betrachtet, benötigt man eine vierte Regel: s : subject, t : transaction, o : object (exec(s, t) (access(ar(s), t, o, x) (4) Die Funktion access(r, t, o, x) stellt fest, ob ein Subjekt in Rolle r auf einem Object o im Modus x eine Transaktion t ausführen darf. Bei x handelt es sich hier um einen Modus aus einer Menge wie zum Beispiel {read, write, append} Administration RBAC ist in Hinsicht auf Richtlinien und Organisationsstrukturen sehr flexibel. Eine seiner größten Stärken sind die Möglichkeiten, die es für die Administration bietet. Seite 12

13 Wenn die Transaktionen in einem System einmal definiert sind, ändern sie sich relativ selten. Die Aufgaben des Administrators bestehen in erster Linie darin, die Mitgliedschaften in der Menge der spezifizierten Rollen zu verwalten. Wenn ein neuer Benutzer in die Organisation eintritt, bekommt er einfach eine bestehende Rolle zugewiesen. Ändert eine Person ihre Tätigkeit in der Organisation, bekommt sie einfach eine neue Rolle zugewiesen und die alten Mitgliedschaften werden aufgehoben. Wenn ein Benutzer die Organisation verlässt, werden alle Mitgliedschaften in Rollen gelöscht. Object 1 Object 2 Trans_a Trans_b Healer User 1 User 2 Object 3 Object 4 Trans_c Trans_d Intern User 3 User 4 Object 5 Object 6 Trans_e Trans_f Doctor User 5 User 6 Abbildung 7 Multi-Role-Relationship Zusätzlich kann eine Hierarchie von Rollen aufgebaut werden. Beispielsweise kann in einem Krankenhaus das medizinische Personal auf folgenden Rollen augebaut sein: Pfleger (Healer), Arzt im Praktikum (Intern) und Arzt (Doctor), siehe Abbildung 7. Wenn einem Benutzer die Rolle Doctor zugewiesen wird, bekommt er automatisch auch die Berechtigungen für die Transaktionen der Rollen Intern und Healer. Wenn einem Benutzer die Rolle Intern zugewiesen wird, kann dieser Transaktionen der Rollen Intern und Healer Seite 13

14 ausführen, aber nicht Transaktionen der Rolle Doctor. Wird einem Benutzer die Rolle Healer zugeteilt, kann er nur Transaktionen der Rolle Healer ausführen Principle of Least Privilege Das Principle of Least Privilege bedeutet, dass ein Benutzer nur so viele Berechtigungen bekommt, wie unbedingt nötig, um seine Aufgabe zu erfüllen. Dazu ist es erforderlich, die Aufgabe des Benutzers zu identifizieren und das Minimum der Berechtigungen zu bestimmen, um diese Aufgabe auszuführen. Durch die Beschränkung auf das Minimum an Berechtigungen wird verhindert, dass unnötig zugelassene Operationen benutzt werden können, um gegen die Sicherheitsrichtlinien zu verstoßen Separation of Duties Mechanismen in RBAC können benutzt werden, um das Prinzip der Aufgabenteilung zu erreichen. Bei der Aufgabenteilung geht es um die Vermeidung des Missbrauchs, der durch die Zusammenarbeit verschiedener, durch die Aufgabe gegebener, Fähigkeiten auftreten kann. Aufgabenteilung setzt für eine Menge von Transaktionen voraus, dass ein einzelner Benutzer nicht alle Transaktionen dieser Menge ausführen kann. Diese Transaktionsmengen variieren je nach Anwendung. In einer Bank könnten zum Beispiel die Transaktionen Auszahlung erfassen und Auszahlung freigeben erfordern, dass unterschiedliche Benutzer diese durchführen. Man unterscheidet zwischen statischer Aufgabenteilung und dynamischer Aufgabenteilung. Bei statischer Aufgabenteilung wird durch Verteilung der Transaktionen auf verschiedene Rollen erreicht, dass ein Benutzer nicht alle Transaktionen ausführen kann. Bei dynamischer Aufgabenteilung wird durch eine Überprüfung der Rolle und der Benutzeridentifikation zum aktuellen Zeitpunkt ermittelt, ob der Benutzer die Transaktion durchführen darf. Seite 14

15 5. Literatur Bücher und Artikel: [FK92] D.F. Ferraiolo and D.R. Kuhn, Role Based Access Control, 15th National Computer Security Conference, 1992 [SS94] Ravi Sandhu and P. Samarati, Access Control: Principles and Practice, IEEE Communications, Volume 32, Number 9, September 1994 Internet: [RBAC] - Role Based Access Control National Institute of Standards and Technology Computer Security Resource Center Seite 15