Diskretion are Zugri skontrollen - Praktische...

Diskretionare Zugriffskontrollen

Udo Kelter

06.12.1999

Zusammenfassung dieses Lehrmoduls

Systeme, die von unterschiedlichen Benutzern mit verschiedenen Rech-ten benutzt werden, mussen Zugriffskontrollen realisieren. In diesemLehrmodul betrachten wir diesen Themenkomplex ganz allgemein undweitgehend unabhangig von SEU als Anwendungsgebiet bzw. OMS alsDatenverwaltungssystemen. Wir fuhren zunachst wichtige Grundbe-griffe ein und stellen ein Ebenenmodell vor, anhand dessen wir Zu-griffskontrollen aus Anwendersicht und auf technischen Ebenen unter-scheiden konnen. Von den verschiedenen Arten von Zugriffskontroll-mechanismen gehen wir nur auf die diskretionaren Zugriffskontrollennaher ein. Nach Einfuhrung der wichtigsten Grundbegriffe (Objekt,Subjekt, ACL, Rechtewerte, Besitzer usw.) diskutieren wir noch dieUnterstutzung von Gruppenstrukturen und typorientierte Zugriffskon-trollen.

Vorausgesetzte Lehrmodule: keine

Stoffumfang in Vorlesungsdoppelstunden: 1.2

1

Diskretionare Zugriffskontrollen 2

Inhaltsverzeichnis

1 Einleitung 3

2 Motivation und Grundbegriffe 4

2.1 Ein Ebenenmodell fur Zugriffskontrollen . . . . . . . . . . . . 42.2 Zugriffskontrollen aus Anwendungssicht . . . . . . . . . . . . 52.3 Realisierungsort von Zugriffskontrollen . . . . . . . . . . . . . 7

3 Arten von Zugriffskontrollmechanismen 10

4 Diskretionare Zugriffskontrollen 12

4.1 Subjekte und Objekte . . . . . . . . . . . . . . . . . . . . . . 124.2 Zugriffsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Rechtewerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4 Modifikation von Rechten . . . . . . . . . . . . . . . . . . . . 174.5 Die ACL neu erzeugter Objekte . . . . . . . . . . . . . . . . . 18

5 Gruppenorientierte Zugriffskontrollen 18

6 Typorientierte Zugriffskontrollen 21

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

c©1999 Udo Kelter Stand: 06.12.1999


1 Einleitung

Mit Zugriffskontrollen muß man sich generell immer dann befassen,wenn man Applikationen entwirft, bei denen mehrere Benutzer, dieunterschiedliche Rechte haben, auf den gleichen Daten arbeiten1. Dieprinzipielle Probleme und Losungsansatze sind dabei weitgehend un-abhangig vom Anwendungsgebiet und vom eingesetzten Datenverwal-tungssystem.

Als Beispiel fur ein Anwendungsgebiet werden wir in diesem Lehr-modul Software-Entwicklungsumgebung (SEU) benutzen, als Beispielefur Datenverwaltungssysteme sowohl klassische Dateisysteme als auchdas Objektmanagementsystem (OMS) PCTE, dessen Besonderheit indiesem Kontext darin liegt, da Objekte typisiert und attributiert sind.

Es gibt oft unterschiedliche Vorstellungen davon, welche und wieintensive Zugriffskontrollen sinnvoll sind. Zugriffskontrollen sind tech-nische Verfahren, die bestimmte Anforderungen befriedigen, namlichSicherheitsanforderungen. Eine wichtige Frage, die in diesem Lehr-modul nicht behandelt wird, ist, wie solche Sicherheitsanforderungenbei der Systemanalyse erfaßt werden. Die ublichen Methoden zur Da-tenmodellierung behandeln den Aspekt der Zugriffskontrollen uber-haupt nicht. Allenfalls in Funktionsmodellen werden Funktionen er-faßt, durch die Rechte administriert und kontrolliert werden konnen.Wie wir sehen werden, sind derartige Funktionen aber eher das Ergeb-nis eines Entwurfsprozesses, in dem die Frage, auf welcher Software-Schicht die Zugriffskontrollen realisiert werden, zu beantworten ist.

In diesem Lehrmodul werden einleitend zunachst Grundbegriffe derZugriffskontrollen vorgestellt, und zwar zunachst aus einer eher allge-meinen Sicht, danach werden die grundlegenden Mechanismen, die inOMS oder Dateisystemen verfugbar sind, vorgestellt.

1Die Mehrbenutzerfahigkeit darf nicht verwechselt werden mit der Mehrprozeß -fahigkeit. Ein System kann mehrere Benutzer haben, die immer nur einer nach demanderen das System exklusiv nutzen konnen. Umgekehrt ist es denkbar, daß beimeinem Einbenutzersystem der Benutzer mehrere Applikationen gleichzeitig laufenlaßt. Das Thema Mehrprozeßfahigkeit wird in [TID] diskutiert.



2 Motivation und Grundbegriffe

2.1 Ein Ebenenmodell fur Zugriffskontrollen

Zugriffskontrollen behandeln das Problem, daß nicht jeder Benutzerbeliebig auf die Daten eines Systems zugreifen darf. Dieses Problemmuß man auf mehreren Abstraktionsebenen betrachten (s. Bild 1):

Abbildung 1: Ebenen der Zugriffskontrollen

Aus der Anwendungssicht besteht das Problem darin, daß es be-stimmte Daten, die man typischerweise als Dokumente auffaßt, gibt,zu denen unterschiedliche Benutzer zugreifen, die ggf. bestimmte Rol-len spielen. Ein Dokument wird nun in einem oder mehreren Objek-ten, Dateien oder sonstigen Speicherungsgranulaten des unterliegen-den Datenverwaltungssystems gespeichert; diese Entscheidungen wer-den beim Entwurf der Applikation getroffen. Wenn man direkt aufDateien arbeitet, entfallt die mittlere Schicht in Bild 1.

Zugriffskontrollen gehoren zu den grundlegenden Leistungen vonDatenverwaltungssystemen, speziell naturlich auch von DBMS undOMS; diese Zugriffskontrollen arbeiten naturlich nur mit den Spei-cherungsgranulaten, die das Datenverwaltungssystem realisiert.



2.2 Zugriffskontrollen aus Anwendungssicht

Die Problemstellung Zugriffskontrollen unterstellt, daß es uberhauptmehrere Benutzer gibt. Im Kontext von SEU waren dies also “Ent-wickler”. Die Motivation fur Zugriffskontrollen wachst mit der Großeder Projekte. In sehr kleinen Projekten, in denen ohnehin nur wenigeEntwickler zusammenarbeiten, ist der “Problemdruck” zur Einfuhrungvon Zugriffskontrollen nicht besonders hoch. In großeren Projektenmit Dutzenden von Entwicklern steigt mit der Anzahl der Entwicklerdie Wahrscheinlichkeit zufalliger und ungewollter Veranderungen bzw.Zerstorungen von Daten anderer Benutzer, so daß man hier bereitszum Selbstschutz Zugriffskontrollmechanismen verlangen wird.

Eine noch starkere Motivation fur Zugriffskontrollen besteht, wennman in einer Entwicklungsabteilung einen nach ISO 9000 zertifizier-ten Entwicklungsprozeß installiert hat. Hier muß z.B. sichergestelltwerden, daß, nachdem ein Stuck Software alle Prufungen uberstan-den hat und nunmehr als korrekt und abgenommen gilt, nicht durchIrrtumer diese Software noch einmal nachtraglich verandert wird. Indie gleiche Richtung zielt der Aspekt der Produkthaftung, der in vie-len sicherheitskritischen Anwendungen dazu fuhrt, daß der Herstellereines Softwareprodukts nachweisen muß, daß er alle moglichen undmachbaren Schritte unternommen hat, um die Qualitat seiner Softwa-re sicherzustellen.

Generell kann man sagen, daß Zugriffskontrollen immer dann ange-bracht sind, wenn es gewisse Bedrohungen (also unerwunschte oderunzulassige Ereignisse) geben kann, die zu bestimmten Schaden, ty-pischerweise der Zerstorung von Daten oder dem Verlust ihrer Ver-traulichkeit, fuhren konnen. Gegen solche Bedrohungen sieht man Si-cherheitsmaßnahmen vor, die Bedrohungen entgegenwirken oder denUmfang von Schaden vermindern konnen oder die helfen, eingetreteneSchaden zu entdecken. Aus Aufwandsgrunden kann man immer nurMaßnahmen gegen die “wichtigsten” Bedrohungen und Schaden ein-richten. Eine konkrete Auswahl von Sicherheitsmaßnahmen und ihreorganisatorische Einbettung nennt man Sicherheitsstrategie (secu-

rity policy). Wir interessieren uns hier nur fur solche Maßnahmen, die



durch den Rechner automatisch ausgefuhrt werden (im Gegensatz zuden nicht minder wichtigen organisatorischen Maßnahmen).

Zur Realisierung einer automatisierten Sicherheitsstrategie mußdas Gesamtsystem Zugriffskontrollmechanismen anbieten. Dabeiist es aus Benutzersicht gleichgultig, ob diese Zugriffskontrollen in derApplikation oder im unterliegenden Datenverwaltungssystem realisiertwerden. Aus Benutzersicht bemerkt man die Zugriffskontrollen typi-scherweise an folgenden Merkmalen:

– Man muß eine sogenannte login-Prozedur durchlaufen, bevor mandas System benutzen kann. Diese Prozedur erlaubt es dem Systemzu erkennen, welcher Benutzer das System gerade benutzen will.Die login-Prozedur besteht darin, daß ein Benutzer sich dem Systemgegenuber identifiziert, d.h. also seinen Benutzernamen angibt, undferner einen Beweis liefert, daß er tatsachlich dieser Benutzer ist,sich also autorisiert. Dieser Beweis besteht typischerweise aus ei-nem Schlusselwort.

– Es gibt Administrationsfunktionen, durch die die Menge der zuge-lassenen Benutzer verwaltet wird und einzelnen Benutzern Rechteerteilt oder entzogen werden konnen. Die Administrationsfunktio-nen sind im konkreten Fall so einzusetzen, daß die gewunschte Si-cherheitsstrategie realisiert wird. Erst durch eine geeignete Admi-nistration des Systems konnen die Sicherheitsziele erreicht werden.Fur die Benutzerverwaltung ist ublicherweise nur ein Systemadmi-nistrator zustandig, wahrend die Rechte an einzelnen Dokumentenmeist von “normalen” Benutzern verandert werden konnen.

– Sofern nun ein Benutzer versucht, Aktionen durchzufuhren, diegemaß der Rechteadministration nicht erlaubt sind, wird dieser Ver-such abgelehnt werden, d.h. im einfachsten Fall erscheint eine Feh-lermeldung. Daruber hinaus kann sich bei manchen Systemen derAdministrator von solchen Fehlversuchen sowie anderen sicherheits-relevanten Ereignissen informieren lassen.

Aus einer softwaretechnischen Sicht stellt sich das Sicherheitspro-blem so dar, daß der Anwender eine bestimmte Sicherheitsstrategiewunscht und daß diese im Prinzip eine Anforderung an das System ist.



Die Sicherheitsstrategie wird einerseits automatisiert in der Software(oder Hardware, worauf wir hier nicht eingehen) durch Sicherheits-mechanismen realisiert, andererseits manuell durch die Systemadmini-stration. Diese Aufteilung in einen automatisierten und einen manu-ellen Teil ist aber bereits eine wichtige Entwurfsentscheidung.

Unerfreulich am softwaretechnischen Stand der Technik bzw. derPraxis ist, daß die Sicherheitsstrategie - also die eigentliche Anforde-rung - typischerweise nur verbal und eher luckenhaft formuliert wird.

2.3 Realisierungsort von Zugriffskontrollen

Die vorstehend beschriebenen Leistungsmerkmale von Zugriffskontrol-len mussen vom Gesamtsystem realisiert werden. Es stellt sich hier diegenerelle Frage, in welchen Softwareschichten man wie Zugriffskontrol-

len realisieren kann bzw. sollte. Tatsachlich konnen Zugriffskontrollenauf allen drei bisher angesprochenen Ebenen realisiert werden:

– innerhalb der Applikationen, also hier einer SEU

– im Datenverwaltungssystem, also dem OMS

– im Dateisystem bzw. Betriebssystem incl. eventuell zugehorigerDienstprogramme

Da Zugriffskontrollen sehr aufwendig zu realisieren sind, liegt esnaturlich nahe, fur ihre Realisierung moglichst weitgehend die Dienstedes unterliegenden Datenverwaltungssystems auszunutzen.

Eine erste wesentliche Beobachtung ist hier, daß auf allen drei Ebe-nen unterschiedliche Schutzeinheiten existieren: Innerhalb der SEUsollten einem Benutzer Funktionen angeboten werden, durch die Rech-te an Dokumenten verwaltet werden. Ein Dokument wird i.a. durchmehrere Objekte und Beziehungen im OMS realisiert sein.

Das OMS bietet Funktionen zur Verwaltung von Rechten an Objek-

ten an. Die Art und Weise, wie Objekte und Beziehungen auf Dateienabgebildet werden, ist implementierungsspezifisch und kann bei jederImplementierung des API eines OMS anders gestaltet sein. Jedenfallskann man i.a. nicht davon ausgehen, daß ein Objekt oder eine Bezie-hung genau einer Datei des unterliegenden Dateisystems entspricht.



Das Datei- (bzw. Betriebs-) System bietet wiederum Funktionenzur Verwaltung von Rechten an Dateien an.

Die einzelnen Ebenen unterscheiden sich nicht nur bzgl. derSchutzeinheiten, sondern auch bzgl. der Zugriffsmodi, also den Grup-pen moglicher Operationen auf den Schutzeinheiten. In Betriebssyste-men unterscheidet man typischerweise lesen, schreiben und ausfuhren;im OMS von PCTE kann man z.B. Zugriffe auf Attribute eines Ob-jekts unterscheiden von Operationen mit seinen ausgehenden Linksoder deren Attributen; in der SEU kann man dokumenttypspezifischeOperationen unterscheiden.

Die einzelnen Ebenen konnen sich weiterhin im Begriff des “Benut-zers” oder einer “Rolle” unterscheiden. In diesem Fall benotigt manfur jede Ebene eigene Funktionen fur die Benutzer- und Rechtever-waltung und eine eigene login-Prozedur. In H-PCTE muß man z.B.beim Start einer Umgebung einen PCTE-Benutzernamen (der volligunabhangig vom Benutzernamen im Betriebssystem sein kann) undein Paßwort angeben.

Aus den vorstehenden Uberlegungen sollte klargeworden sein, daßman einen Zugriffskontrollmechanismus auf einer hoheren Ebene nur inAusnahmefallen direkt auf den Mechanismus der nachsttieferen Ebenezuruckfuhren kann und daß man u.U. wesentliche Teile eines Zugriffs-kontrollmechanismus auf einer hoheren Ebene neu realisieren muß.

Ein Ansatz besteht nun darin, die Zugriffskontrollen ausschließlichin der SEU, also oberhalb dieses Datenhaltungssystems zu realisieren.Argumente fur und gegen diesen Ansatz sind:

– Wenn die SEU auf einem Dateisystem basiert, das keine Zugriffs-kontrollen anbietet, bleibt nicht anderes ubrig.

– Der Aufwand zur Realisierung der Zugriffskontrollmechanismen isthoch.

– Die Realisierung der Zugriffskontrollmechanismen ist im Prinzip un-sicher. Man kann die Zugriffskontrollen der SEU umgehen, indemman einfach neue Applikationen auf Basis des Datenhaltungssy-stems realisiert, in denen die Zugriffskontrollen eben nicht realisiert



sind. Derartige technologische Attacken sind allerdings wenig wahr-scheinlich.

Speziell das Aufwandsargument spricht dafur, die Zugriffskontrol-len weitgehend auf das unterliegende Datenhaltungssystem zu verla-gern. Problempunkte hierbei sind:

– Man muß die Standardwerkzeuge des Datenhaltungssystems einset-zen, um die Benutzer zu verwalten und Rechte zu andern. Dies istauf Mehrbenutzersystemen und erst recht Rechnernetzen mit einerzentralen Benutzeradministration durchaus problematisch, dennhier muß man jemandem, der eigentlich nur eine SEU verwaltensoll, sehr viel weitergehende Rechte einraumen.

– Es kann leicht zu Problemen kommen, wenn Softwarentwickler dieStandardwerkzeuge zur Benutzeradministration und Rechteverwal-tung bedienen mussen. Diese Werkzeuge sind in erster Linie fur Sy-stemadministratoren entwickelt worden und teilweise sehr komplex,also entsprechend schwer zu erlernen. Die Bedienschnittstellen sindmeist nicht konsistent mit den Bedienschnittstellen der SEU. Deneinzelnen Dokumenten ist oft nicht ohne weiteres ein Bezeichner fureine Datei oder ein Objekt zuzuordnen. Die Benutzungsfreundlich-keit derartiger Ansatze durfte daher i.a. gering sein.

– Weiter kann die Funktion der SEU von gewissen Annahmen bzw.Konsistenzkriterien uber die Rechtesituation abhangen; diese Kon-sistenzbedingungen konnen versehentlich verletzt werden.

Insgesamt spricht viel dafur, die Bedienschnittstellen innerhalb derSEU in angepaßter und integrierter Form zu realisieren, den Rechte-zustand der Dokumente einer SEU im Sinne einer Datenkapselung nuruber diese Softwareschicht zu andern, die eigentliche Durchfuhrung derRechteprufungen aber auf das unterliegende Datenhaltungssystem zuubertragen.



3 Arten von Zugriffskontrollmechanismen

Die in Dateisystemen, DBMS oder OMS auftretenden Zugriffskontroll-mechanismen kann man in insgesamt drei Gruppen aufteilen:

1. Diskretionare Zugriffskontrollen (discretionary access controls,DAC): Diskretionar bedeutet: im Ermessen von jemand liegend.Diese Zugriffskontrollen sind insofern diskretionar als es hier demErmessen eines sogenannten Besitzers eines Objekts, einer Da-tei oder eines sonstigen Datengranulats uberlassen wird zu bestim-men, welche anderen Benutzer in welcher Weise auf dieses Granulatzugreifen durfen. Ein Beispiel fur diskretionare Zugriffskontrollensind die Zugriffskontrollen in normalen UNIX-Dateisystemen. Wirgehen weiter unten noch genauer auf die Merkmale diskretionarerZugriffskontrollen ein.

2. Informationsflußkontrollen (mandatory access controls, MAC):Es gibt hier im wesentlichen zwei Varianten: eine zur Sicherstellungder Vertraulichkeit von Daten und eine zur Sicherstellung der Kor-rektheit von Daten; wir erlautern hier nur die erste Variante.

Bei diesen Zugriffskontrollmechanismen werden zunachst einmalInformationen bezuglich ihrer Vertraulichkeit klassifiziert, z.B. ineiner Folge von Geheimhaltungsstufen: z.B. 1. offen, 2. geheimund 3. streng geheim. Ebenso werden alle Benutzer dahingehendeingestuft, zu welchen Klassen von Dokumenten sie zugreifen (d.h.hier lesend zugreifen) durfen. Diese Klasse von Verfahren basiertwesentlich auf der Annahme, daß jeweils ein ganzes Dokument in-nerhalb eines Objekts – zu denken ist hierbei primar an Dateien, diein einem OMS durch lange Felder simulierbar waren – enthalten ist.Dabei wird nicht dem eigentlichen Dokument eine Vertraulichkeits-stufe zugeordnet, sondern dem Objekt, also dem Behalter, wobeider aktuell vorhandene Inhalt dann keine weitere Rolle mehr spielt.

Die wesentlichste Besonderheit dieser Verfahren liegt darin, daßsie beim Verarbeiten von Informationen die Geheimhaltungsmerk-male der Eingabedaten auf die Ausgabedaten fortpflanzen. Wennbeispielsweise ein Programm drei Eingabedateien liest, von denen



eine ein streng geheimes Dokument enthalt, und wenn dieses Pro-gramm dann vier Ausgabedateien schreibt, gilt der Inhalt jeder die-ser vier Ausgabedateien als streng geheim, denn zumindest potenti-ell hatte dieses Programm in jede dieser Ausgabedateien das strenggeheime Dokument oder Teile davon hineinschreiben konnen. Ope-rational gesehen erlaubt es das Betriebssystem einem Prozeß, dergeheime Daten gelesen hat, nicht mehr, irgendwelche Daten in eineDatei zu schreiben, die als “offen” klassifiziert ist (oder allgemeinergesagt, denen eine geringere Vertraulichkeitsstufe zugeordnet ist).Alternativ kann man festlegen, da die Vertraulichkeitsstufe implizitdurch den Schreibzugriff soweit ntig angehoben wird. Diese Uber-wachung von potentiellen Informationsflussen ist der entscheidendeUnterschied im Vergleich zu den diskretionaren Zugriffskontrollver-fahren.

Die schon erwahnte zweite Variante zielt darauf hin, die Korrekt-heit bzw. Zuverlassigkeit von Daten sicherzustellen. Sie ist analogzur ersten Variante gestaltet. Es wird verhindert, daß ein Prozeß,der “ungeprufte” oder “unsichere” Daten gelesen hat, Daten in eineDatei schreibt, die als “zuverlassig” oder “uberpruft” klassifiziertist.

3. Uberwachung sicherheitsrelevanter Ereignisse: Die Uberwa-chung besteht darin, daß bei jedem Auftreten eines sicherheitsrele-vanten Ereignisses ein Eintrag in eine Protokolldatei vorgenommenwird. Aus diesem Eintrag konnen die wesentlichen Merkmale desEreignisses sowie die Identifikation des Benutzers, der dieses Ereig-nis durchgefuhrt hat, spater entnommen werden. Welche Ereignisseals relevant erachtet werden, sollte anhand diverser Kriterien ein-stellbar sein.

Dieser Mechanismus verhindert unzulassige Zugriffe auf Datennicht direkt, er liefert aber Hinweise auf mogliche Attacken gegendas System oder kann es erlauben, bei eingetretenen Schaden, denVerursacher zu ermitteln und verhindert dadurch moglicherweiseindirekt eine mutwillige Zerstorung von Daten oder den Bruch vonGeheimnissen.



Diskretionare Zugriffskontrollen und Uberwachungsfunktionen tre-ten sehr haufig auf.

Informationsflußkontrollen sind seltener, sie sind auch bei einerfeingranularen Datenmodellierung wenig sinnvoll: Bei einer feingranu-laren Modellierung sind wesentliche Anteile der Information uber einDokument in der Struktur des Objektnetzwerks enthalten, also tech-nisch gesehen in den Beziehungen zwischen Objekten. Diese Strukturspielt aber fur die Informationsflußkontrollen praktisch keine Rolle, dai.w. nur der Informationsgehalt der Attribute eines Objekts klassifi-ziert wird.

Uberwachungsfunktionen sind bei einer feingranularen Datenmo-dellierung wegen der hohen Anzahl elementarer Zugriffe ebenfalls pro-blematisch. Wir betrachten daher i.f. nur noch diskretionare Zugriffs-kontrollen.

4 Diskretionare Zugriffskontrollen

Im folgenden wollen wir zunachst einige elementare Grundbegriffe derdiskretionaren Zugriffskontrollen erlautern.

4.1 Subjekte und Objekte

Unter einem Subjekt versteht man eine aktive Instanz, in deren Na-men Zugriffe durchgefuhrt werden und deren Zugriffe zu kontrollierensind. Subjekte sind Inhaber von “Rechten”. Die Subjekte, die Sieublicherweise in UNIX-Dateisystemen kennen, sind

– der Besitzer einer Datei,

– eine Gruppe sowie

– der Rest der Benutzer, die man als spezielle weitere Gruppe auffas-sen kann.

Neben Benutzern und Benutzergruppen sind auch Programme bzw.Programmgruppen als Subjekte denkbar.



In der Begriffswelt der diskretionaren Zugriffskontrollen verstehtman unter einer Schutzeinheit (dort auch Objekt genannt) eine pas-sive Instanz, die zu schutzende Daten enthalt. In Dateisystemen sindtypischerweise einzelne Dateien Schutzeinheiten. In einem OMS liegenals Schutzeinheiten nahe:

– einzelne atomare Objekte

– komplette komplexe Objekte

Komplexe Objekte fuhren zu dem Problem, daß Schutzeinheiten uber-lappen konnen; dies betrachten wir hier zunachst nicht, sondern um-stellen vorerst “disjunkte” Schutzeinheiten, also nur atomare Objekte.

Es sind eine ganze Reihe verschiedener Verfahren denkbar, wie mandiskretionare Zugriffskontrollen realisieren kann. Die einfachste Formbesteht darin, in einer sogenannten Zugriffsmatrix anzugeben, wel-che Subjekte auf welche Objekte zugreifen durfen. Ein Beispiel fureine solche Matrix ist:

Objekte

Subjekte O1 O2 O3 ........ O74

S1 - - + .... +

S2 + - - .... +

.. - - + .... -

S15 - + + .... -

Diese Matrix muß nun bei jedem Zugriff eines Subjekts zu einerSchutzeinheit ausgewertet werden. Fur die Auswertung nehmen wirzunachst an, daß ein Prozeß immer nur fur genau ein Subjekt arbeitet,welches wir das aktive Subjekt dieses Prozesses nennen. Sei S alsodas aktive Subjekt des Prozesses und M die Zugriffsmatrix, dann darfder Prozeß auf ein Objekt O genau dann zugreifen, falls M[S,O] einPlus enthalt.

Die Zugriffsmatrix wird ublicherweise nicht zentral gespeichert,sondern spaltenweise bei den Objekten, d.h. an jedem Objekt wird furalle Subjekte angegeben, ob sie auf dieses Objekt zugreifen konnen.Diese Liste nennt man auch die Zugriffskontrolliste (access con-



trol list, ACL) fur dieses Objekt2. Der wesentliche Vorteil von ACLgegenuber einer zentralen Speicherung der Zugriffsmatrix liegt darin,daß sich die gesamte Information uber die Rechte an einem Objekt beidem Objekt selbst befindet und immer lokal ausgewertet werden kann;eine zentrale Ressource wird hierdurch vermieden.

4.2 Zugriffsmodi

Eine erste Erweiterung des oben vorgestellten Konzeptes besteht darin,daß man mehrere Zugriffsmodi unterscheidet. In UNIX und vielenanderen Dateisystemen werden z.B. drei Modi unterschieden

R lesen

W schreiben

X ausfuhren bzw. navigieren uber Verzeichnisse

Die Zugriffsmatrix bleibt im Prinzip erhalten, allerdings wird jetztnicht mehr binar angegeben, ob uberhaupt zu dem Objekt zugegriffenwerden kann, sondern es werden die jeweils erlaubten Zugriffsmodi auf-gelistet. Ein Beispiel fur eine Zugriffsmatrix fur die o.g. Zugriffsmodiist:

Objekte


S1 R RW RWX .... -

S2 W - RWX .... X

Statt der Auflistung der Abkurzungen der Zugriffsmodi ist es im allge-meinen effizienter, die Menge der Zugriffsmodi in Form eines Bitfeldesdarzustellen. In unserem Beispiel benotigen wir also fur jeden Matri-xeintrag drei Bits, da wir drei verschiedene Zugriffsmodi unterschiedenhaben. Die vorstehende Matrix sahe dann folgendermaßen aus:

2Genaugenommen werden nur die Eintrage gespeichert, die nicht den Vorgabe-wert (hier: Minus) enthalten.



Objekte


S1 -+- ++- +++ .... ---

S2 +-- --- +++ .... --+

OMS haben semantisch wesentlich reichhaltigere Datenmanipula-tionsoperationen als ein Dateisystem. Daher mussen hier auch mehrZugriffsmodi unterschieden werden (PCTE unterscheidet bspw. rund20, teilweise sehr spezielle Zugriffsmodi). Die Anzahl der Zugriffsmodiist aber fur die prinzipielle Funktion diskretionarer Zugriffskontrollenunerheblich.

4.3 Rechtewerte

Als zweite Erweiterung der bisherigen Konzepte betrachten wir denFall, daß ein Prozeß fur mehrere Subjekte gleichzeitig arbeitet, mit an-deren Worten, mehrere aktive Subjekte hat. Wesentlich ist hier, daßder Prozeß die Rechte dieser Subjekte gleichzeitig ausnutzen konnenmuß. Ein typisches Beispiel fur einen solchen Fall ist, daß ein Be-nutzer innerhalb eines Projekts bestimmte Rechte ausnutzen will, dieallen Projektmitgliedern eingeraumt werden, sowie ferner die Rechtevon einer oder mehreren speziellen Untergruppen, in denen er Mitgliedist.

Bei mehreren aktiven Subjekten entstehen Probleme mit der Inter-pretation von Eintragen in der Zugriffsmatrix. Betrachten wir folgen-den Fall:

– S1 und S2 sind aktive Subjekte eines Prozesses

– S1 darf bei Objekt O in einem bestimmten Modus zugreifen

– S2 darf bei Objekt O im gleichen Modus nicht zugreifen.

Unklar ist hier vor allem die Bedeutung des Minuszeichens fur S2 inder ACL. Fur dieses sind zwei Interpretationen denkbar.

– Der Zugriff ist explizit verboten und soll unter gar keinenUmstanden erlaubt sein (anonymous soll auf keinen Fall in /etc



Dateien anlegen oder loschen konnen), auch dann nicht, wenn eineder anderen aktivierten Gruppen das entsprechende Recht hat.

– Diesem Subjekt als solchem soll mit dieser Rechtefestlegung nichtdas Recht geben werden, den Zugriff durchzufuhren. Damit sollaber nicht ausgeschlossen werden, daß der Zugriff dennoch durch-gefuhrt wird, wenn namlich eine andere gleichzeitig aktive Gruppedas Recht hat.

Die Losung dieses Problems liegt darin, drei verschiedene Rechtewer-

te zu unterscheiden

+ Dieser Wert zeigt an, daß dem Subjekt der Zugriff erlaubt sein soll.

- Dieser Wert zeigt an, daß der Zugriff explizit verboten sein soll,d.h. der Zugriff ist auch dann nicht moglich, wenn er einem ande-ren gleichzeitig aktiven Subjekt erlaubt worden ist.

? Dieser Wert (“undefiniert”) zeigt an, daß der Zugriff fur dieses spe-zielle Subjekt nicht explizit gewahrt wird, es wird aber nicht aus-geschlossen, daß der Zugriff dennoch moglich ist, weil das Rechteinem anderen gleichzeitig aktiven Subjekt gewahrt worden ist.

Der Wert “undefiniert” ist Vorgabewert, d.h. in der ACL werdennur die Eintrage tatsachlich gespeichert, in denen andere Werte als ?

auftreten.Die drei Rechtewerte machen eine dreiwertige Logik fur die Aus-

wertung von Rechtefestlegungen erforderlich. Seien also S1, ..., Sn dieaktiven Subjekte eines Prozesses und O eine Schutzeinheit. Der Prozeßdarf nun genau dann auf O zugreifen, wenn

– wenigstens ein Subjekt Si explizit die Erlaubnis hat (Rechtewert+ ), im hier interessierenden Modus auf das Objekt zuzugreifen

– fur kein Subjekt Si der Zugriff explizit verboten worden ist (Rech-tewert - )

Als Beispiel betrachten wir folgende Matrix von Rechtefestlegungen:



Objekte


S1 -+- ++? +++ .... ???

S2 +-- ??? +++ .... ??+

Wir nehmen an, daß die Subjekte S1 und S2 fur einen Prozeß aktivsind. Dann darf dieser Prozeß bei den Objekten O1 bis O3 in folgen-den Modi zugreifen: bei O1 : gar nicht; bei O2 : RW; bei O3 : RWX;bei O74 : X.

4.4 Modifikation von Rechten

Wir haben nunmehr eine Vorstellung vom “Rechtezustand” von Ob-jekten und der Auswertung dieses Zustands gewonnen. Eine andereFrage ist, wie dieser Zustand erzeugt wird.

Hierzu muß das Datenverwaltungssystem Operationen zurVerfugung stellen, mit denen ein Eintrag der ACL modifiziert werdenkann. Die Details der entsprechenden APIs und/oder Dienstprogram-me sind hier unwesentlich.

Nun waren die Zugriffskontrollen praktisch sinnlos, wenn jeder Be-nutzer hingehen konnte und die ACL eines Objekts verandern durfte.Dieses Recht wird daher durch einen eigenen Zugriffsmodus kontrol-liert. Dieser heißt Besitzer- (owner-) Modus. Ein Besitzer einesObjekts ist ein Subjekt, dem das Besitzer-Recht an diesem Objektgewahrt ist.

In UNIX-Dateisystemen hat ein Objekt immer nur einen Besitzer;es spricht aber konzeptionell nichts dagegen, mehrere Besitzer zuzulas-sen (dies ist in PCTE der Fall). Bei mehreren Besitzern muß sicherge-stellt werden, daß jedes Objekt immer mindestens einen Besitzer hat,denn sonst waren die Rechte an diesem Objekt nie wieder anderbar.Daher muß die Operation, mit der man ACLs modifiziert, verhindern,daß der letzte Besitzer eines Objekts sich selbst das Besitzer-Rechtentzieht.



4.5 Die ACL neu erzeugter Objekte

Wir haben bisher nur eine Operation unterstellt, die ACLs von exi-

stierenden Objekten modifiziert. Welche Rechte sind aber an neu er-zeugten Objekten vorhanden? Ein denkbarer Weg ist, bei allen Opera-tionen, die explizit oder implizit Objekte erzeugen3, einen Parameteranzugeben, der die initiale ACL des Objekts angibt. Das ware aller-dings ziemlich umstandlich und ineffizient, denn normalerweise sollenalle von einem Prozeß erzeugten Objekte die gleiche ACL haben. Esist sinnvoller, die initiale ACL von Objekten in einer “globalen Va-riablen” pro Prozeß angegeben. In UNIX-Systemen ist dies die soge-nannte umask , in PCTE ist es die Default-ACL des Prozesses, dieentsprechend dem Prinzip der Datenkapselung uber spezielle Opera-tionen und gelesen werden kann.

5 Gruppenorientierte Zugriffskontrollen

Großere Softwareentwicklungsprojekte werden immer arbeitsteiligdurchgefuhrt. Hierbei wird im allgemeinen die Gesamtaufgabe inmehrere Teilaufgaben aufgeteilt. Entsprechend dieser Grobaufteilungder Aufgaben wird eine organisatorische Aufteilung in Arbeitsgrup-pen vorgenommen. Neben dieser mengenmaßigen Aufteilung der an-fallenden Arbeiten unterscheidet man oft auch qualitativ nach derArt der durchgefuhrten Arbeit, z.B. Entwicklung, Test, Qualitatssi-cherung, Dokumentation usw. Man spricht in diesem Zusammenhangauch von verschiedenen Rollen, die die entsprechenden Mitarbeiterbei der Ausubung dieser Tatigkeiten spielen. Etwas verallgemeinerndkann man hieraus folgern, daß man in der Organisationsstruktur einesProjekts diverse Arbeitsgruppen unterscheiden wird, die bestimm-te Aufgaben haben. Den einzelnen Arbeitsgruppen werden naturlichverschiedene Kompetenzen und damit auch verschiedene Rechte zuste-hen. Einen Zugriffskontrollmechanismus nennen wir nunmehr grup-

penorientiert, sofern er Hierarchien von Arbeitsgruppen unterstutzt.

3In selbstreferentiellen Systemen wie PCTE werden bei vielen Gelegenheitenimplizit Objekte erzeugt, beispielsweise beim Anlegen von Typen.



Ein Beispiel einer Gruppenhierarchie zeigt Bild 2.

Abbildung 2: Beispiel fur eine Gruppenhierarchie

In diesem Beispiel nehmen wir an, daß ein großeres Projekt in zweiTeilprojekte aufgeteilt ist, die von den Arbeitsgruppen Teilprojekt 1

und Teilprojekt 2 bearbeitet werden sollen. Innerhalb jedes Teil-projekts unterscheiden wir die Bereiche Organisation, Implementie-rung und Dokumentation und bilden entsprechende Untergruppen,z.B. TP1 org . Innerhalb der Implementierungsgruppen unterscheidenwir weiter nach der Implementierung einer Benutzerschnittstelle undder Implementierung von Kommunikationssoftware. Auf der letztenEbene in Bild 2 sind einzelne Entwickler angegeben; die gestricheltenLinien zeigen an, in welchen Gruppen die Mitarbeiter Mitglied sind.Ein Mitarbeiter kann naturlich Mitglied in mehreren Gruppen sein undmuß je nachdem, in welchem Kontext er gerade arbeitet, die Rechtedieser Gruppe ausnutzen konnen.

Die Unterstutzung von Hierarchien von Arbeitsgruppen bestehtnun vor allem darin, daß man derartige Gruppenhierarchien zunachsteinmal im System erfassen kann und anschließend nicht nur einzelnen



Benutzern, sondern auch Gruppen Rechte zuteilen kann. Gruppenals Subjekte sind in rudimentarer Form auch von UNIX und ande-ren Betriebssystemen her bekannt, wo jeder Datei genau eine Gruppezugeordnet werden kann (mit dem Kommando chgrp ); dieser Grup-pe konnen einzelne Zugriffsrechte erteilt werden. Im Unterschied zuUNIX verlangen wir hier, daß nicht nur eine einzige Gruppe, sondernbeliebig viele Gruppen Rechte an einem Objekt haben konnen. Beispie-le fur solche Rechte sind:

– alle Mitglieder der Gruppe Teilprojekt 1 durfen alle Daten vonTeilprojekt 1 lesen

– alle Mitglieder der Gruppe TP1 impl durfen die Bibliotheken vonTeilprojekt 1 verandern

– alle Mitglieder der Gruppe TP1 UI impl durfen die Quelltexte derUI-Software von Teilprojekt 1 verandern

Jede einzelne der drei vorgenannten allgemeinen Rechtefestlegun-gen fuhrt zu Eintragen in der Zugriffskontrolliste aller betroffenen ato-maren Objekte. Wenn also O ein solches Objekt ist, dann muß dieACL von O Eintrage fur die Subjekte Teilprojekt 1 , TP1 impl undTP1 UI impl enthalten.

Wie wir oben schon gesehen haben, mussen die Rechte mehrererGruppen gleichzeitig ausnutzbar sein. Die Frage ist hier, ob und wieein Prozeß festlegen kann, welche Gruppen fur ihn aktiviert werden sol-len. Eine aktive Gruppe ist naheliegenderweise immer der Benutzer,fur den ein Prozeß arbeitet.

Diffiziler ist die Frage, welche Gruppen-Subjekte, die ja Rollen oderArbeitsgruppen reprasentieren, aktiviert werden konnen. Da ein Be-nutzer abwechselnd in verschiedenen Rollen oder in verschiedenen Teil-projekten arbeiten kann, ware es wenig sinnvoll – man denke hier anexplizite Verbote –, zugleich alle Gruppen zu aktivieren, in denen die-ser Benutzer Mitglied ist. Man konnte nun ein Kommando bereitstel-len, mit dem der Benutzer nach eigenem Ermessen eine oder mehrereGruppen aktivieren kann. Dies ware aber nicht unbedingt angemessen,denn es kann z.B. Rollen geben, die sich gegenseitig ausschließen (z.B.



Entwickler und Qualitatssicherer). Eine zu starke Einschrankung derZahl der gleichzeitig aktivierbaren Gruppen, z.B. auf 1, ware ebenfallsnicht angemessen. Ein sinnvoller Kompromiß zwischen diesen beidenExtremen besteht darin, daß ein Prozeß genau eine Gruppe, in der derBenutzer Mitglied ist, explizit aktivieren kann, und daß als Nebeneffektalle Obergruppen dieser Gruppe gemaß der Gruppenstruktur ebenfallsimplizit aktiviert werden.

Die Gruppenstruktur ist nicht unbedingt baumartig, sondern kannim allgemeinen ein gerichteter, zyklusfreier Graph sein. Es ist sinnvollzu erzwingen, daß eine eindeutige Wurzel vorhanden ist, dann konnennamlich dieser Wurzel systemweit geltende Rechte oder Verbote erteiltwerden.

Eine detailliertere Behandlung dieses Themas findet sich in [Ke90].

6 Typorientierte Zugriffskontrollen

Bei den bisherigen Betrachtungen waren wir ausschließlich von Datei-en, Objekten oder ahnlichen Granulaten als Schutzeinheiten ausgegan-gen.

Oft werden allerdings noch kleinere Schutzeinheiten benotigt. Bei-spielsweise konnte ein Objekt, das ein Dokument reprasentiert, einAttribut zustand haben, das die Werte ’ungepruft’, ’vorgepruft’ und’abgenommen’ haben konnte. Dieses Attribut darf nur von einem Qua-litatssicherer verandert werden, die restlichen Attribute nur von denEntwicklern.

Die Rechte an den Attributen eines Objekts sind also nicht immereinheitlich. Man konnte nun versucht sein zu fordern, daß deshalbauch Rechte an einzelnen Attributen vergeben werden konnen. Dieskann zum einen zu Effizienzproblemen fuhren, deren Relevanz vomEinzelfall abhangt und die unter bestimmten Umstanden auch durchinterne Optimierungen behebbar sind; festzuhalten ist hier jedoch, daßpraktisch kein OMS so feinkornige Schutzeinheiten realisiert.

Gravierender ist das Problem der Administration der Rechte: DerAufwand, derartig feingranulare Rechte von Hand zu verwalten, ist



prohibitiv. Benotigt wird daher ein besser handhabbares Konzept.Hierbei konnen wir im vorigen Beispiel ausnutzen, daß die Rechte anden Attributen bei allen Objekten des entsprechenden Typs gleichartigstrukturiert sind.

Wenn man ein Objekt als ein Tupel in einer relationalen Daten-bank betrachtet und die Menge der Objekte eines Typs als Relation,dann haben die bisherigen, an Objekten orientierten Rechte den Ef-fekt, eine Teilmenge der Objekte zugreifbar zu machen; dies entsprichteiner Selektion. Erganzend hierzu wird das Analogon zu einer Projek-tion benotigt, wobei einzelne Attribute nur lesbar sind oder komplettausgeblendet werden. Bild 3 deutet diesen Effekt schematisch an.

Abbildung 3: Wirkung von Instanz- und Typrechten

Eine Projektion entspricht typorientierten Rechten. Insgesamtwirken die instanzorientierten und die typorientierten Rechte multipli-kativ, d.h. um auf ein Attribut zugreifen zu konnen, mussen entspre-chende Instanz- und Typrechte vorhanden sein (vgl. [Ke92]).

Typrechte werden in DBMS und OMS durch Sichtenmechanismenrealisiert, in Dateisystemen gibt es das Konzept nicht, weil keine be-nutzerdefinierten Dateitypen unterstutzt werden. Die Details der Sich-tenmechanismen hangen naturlich stark von den Besonderheiten desjeweiligen Datenmodells ab.



Literatur

[Ke90] Kelter, U.: Group-oriented discretionary access controls fordistributed structurally object-oriented database systems; p.23-33 in: Proc. European Symposium on Research in ComputerSecurity, Toulouse, October 24-26; AFCET; 1990/10

[Ke92] Kelter, U.: Type-level access controls for distributed struc-turally object-oriented database systems; p.21-40 in: Proc.European Symposium on Research in Computer Security,Toulouse, November 23-25; LNiCS 648, Spinger; 1992/10

[SEU] Kelter, U.: Lehrmodul “Software-Entwicklungsumgebungen”;1999/11

[TID] Kelter, U.: Lehrmodul “Transaktionen und die Integritat vonDatenbanken”; 1999


Index

access control list, 14ACL, 14Arbeitsgruppe, 18

Bedrohungen, 5Besitzer, 17

DAC, 10Default-ACL, 18discretionary access controls, 10

Informationsflußkontrollen, 10

MAC, 10mandatory access controls, 10

Rechtewerte, 16Rolle, 18

Schaden, 5Schutzeinheit, 13security policy, 5Sicherheitsstrategie, 5Subjekt, 12

aktives, 13

Uberwachung sicherheitsrelevanter Er-eignisse, 11

Zugriffskontrolliste, 13Zugriffsmatrix, 13Zugriffskontrollen

diskretionare, 3, 10, 12Modifikation von Rechten, 17Rechtewerte, 15

gruppenorientierte, 18informationsflußbasierte, 10Mechanismen, 6

Realisierungsort, 7Schutzeinheiten, 7typorientierte, 21

Zugriffsmodus, 8, 14

24

Diskretion are Zugri skontrollen - Praktische...

Documents

Transcript of Diskretion are Zugri skontrollen - Praktische...