5 Zugriffskontrolle 5.1 Systemmodell Grundmodell Grundmodell zur Beschreibung der VorgŠnge in einem IVS:

Transkript

1 5 Zugriffskontrolle 5.1 Systemmodell Grundmodell Grundmodell zur Beschreibung der VorgŠnge in einem IVS: Zugriffssystem: < S,P,O > S Menge von Subjekten P Menge von Operatoren O Menge von Objekten Beispiele fÿr Subjekte Benutzer Prozesse Prozeduren Prozessoren Beispiele fÿr Objekte GerŠte Dateien SŠtze Speichersegmente Prozesse Prozeduren 5-1

2 Zugriffssystem Operatoren sind immer objektspezifisch definiert Beispiele: Datei: Erzeugen, Vernichten; ffnen, Schlie en; Lesen, Schreiben;... Drucker: Benutzen Ein Tripel < s, p,o >mit s S, p P, o O hei t Zugriffsweg Es gibt S P O Zugriffswege. Subjekte Operatoren Objekte 5-2

3 Zugriffssystem Feststellung Nicht alle Zugriffswege sind notwendig oder erwÿnscht. Subjekte Operatoren Objekte erlaubt nicht erlaubt 5-3

4 5.1.2 EinschrŠnkung der Zugriffswege: Zugriffsrelation Zwei Mšglichkeiten der EinschrŠnkung: a) Das Verbotene explizit nennen. b) Das Erlaubte explizit nennen. Vorgehensweise b) ist sicherer. Die erlaubten Zugriffswege werden in einer Zugriffsrelation ZR zusammengefasst: < s, p,o > ZR S P O Zugriffsrelation in Matrixschreibweise: O 1 O 2 O 3 S 1 p 1 p 1 - S 2 p 1 p 2 - p 1 S 3 p 1 p 2 - Die EintrŠge in der ZR werden auch als Rechte bezeichnet. Ein Tripel < s, p,o > ZR bedeutet, dass Subjekt s das Recht p an Objekt o besitzt. 5-4

5 Beispiel: Umgang mit Geldkonten Objekte Sparkonto S Girokonto G Festgeldkonto F O = {S,G,F} Subjekte EigentŸmer(in) E Mutter M Tante T Finanzberater B S = {E,M,T,B} Operationen Kontostand Lesen L Einzahlung E Auszahlung A P = {L,E,A} 5-5

6 Beispiel Nutzungsabsicht EigentŸmer darf alles Mutter darf Sparkonto lesen, Girokonto einzahlen Tante darf Sparkonto einzahlen, Girokonto einzahlen Berater darf Girokonto lesen, einzahlen, auszahlen, Festgeldkonto lesen, einzahlen, auszahlen Zugriffsrelation: S G F E L,E,A L,E,A L,E,A M L A T E E B L,E,A L,E,A 5-6

7 Speicherung der Zugriffsrelation a) Zentrale Speicherung Tripel zusammengefasst aufgelistet s 1 p 1 o 1 s 1 p 1 o 2 s 1 p 1 o 3 s 1 p 2 o 1 s 2 p 1 o 1 s 2 p 2 o 2 : : : b) Subjektorientierte Speicherung (ausweisorientiert, ticket-oriented, capability-oriented) s 1 :p 1 o 1 s 2 : p 1 o 1 p 1 o 2 p 2 o 2 p 1 o 3 p 2 o 1 c) Objektorientierte Speicherung (Zugriffskontrollisten) o 1 :s 1 p 1 o 2 : s 1 p 1 o 3 : s 1 p 1 s 1 p 2 s 2 p 2 s 2 p 1 d) Operatororientierte Speicherung (analog zu oben) 5-7

8 5.1.3 Rechtevergabe (Autorisierung) Bei dynamischen Systemen (S, P, oder O veršnderlich) Vergabe von Rechten Entzug von Rechten Beide sind Operationen an den EintrŠgen der Zugriffsrelation ZR. Daher muss ihre Nutzung kontrolliert werden. => Vergaberelation VR: VR S { v,e} S P O mit den Rechten v: vergeben e: entziehen Die Vergaberelation legt fest, welche Subjekte, welche EintrŠge (Tripel) der ZR veršndern dÿrfen. 5-8

9 Rechtevergabe (Autorisierung) Wirkung: x S darf < s, p, o > vergeben <=> < x, v, < s, p, o > > VR x S darf < s, p, o > entziehen <=> < x, e, < s, p, o > > VR <s, p, o > ZR Einsatzmšglichkeiten Besitzervergabe: < s, p, o > ZR <s, { v,e},< x, p, o >> VR EigentŸmervergabe < s, own,o> ZR <s, { v,e},< x, p, o >> VR Zentrale Vergabe s 0 S: < s 0,{ v,e},< x, p, o >> VR 5-9

10 5.1.4 Zugriffskontrollinstanz Vorgabe einer ZR nur sinnvoll, wenn ihre Einhaltung sichergestellt werden kann. Es muss eine Zugriffskontrollinstanz ZK geben, die bei jedem Zugriff < s, p,o > prÿft, ob < s, p,o > ZR Ein kontrolliertes Zugriffssystem ist ein Quintupel KZS := <S, P,O, ZR, ZK > mit ZS = <S,P,O > Zugriffssystem ZKS : = < ZR, ZK > Zugriffskontrollsystem Die Schreibweise soll auch darauf hinweisen, dass beim Systementwurf Ÿber alle 5 Komponenten Aussagen gemacht werden mÿssen. Die Zugriffskontrolle muss jeden Zugriff auf ZulŠssigkeit prÿfen 5-10

11 PrŸfung der Zugriffe auf ZulŠssigkeit s p o (s, p, o) ZK ZR 5-11

12 Plazierung der Zugriffskontrolle Plazierung beim Subjekt (p,o) s p o ZK s ZR Plazierung beim Operator s s o p o ZK ZR Plazierung beim Objekt (s, p) s p o ZK ZR 5-12

13 5.1.5 Bedingte Zugriffskontrolle Beim realen Betrieb eines Zugriffskontrollsystems zeigt es sich schnell, dass die blo e Ja/Nein-Regel ãzugriff oder kein ZugriffÒ fÿr eine flexible Zugriffskontrolle nicht ausreicht. Beispiele: Der Zugriff eines Mitarbeiters soll nur wšhrend der Arbeitszeit erfolgen kšnnen. Die SicherungslŠufe sollen nur zwischen Uhr und Uhr an Werktagen durchgefÿhrt werden. Die Kollegen einer anderen Abteilung sollen den eigenen Abteilungsrechner grundsštzlich schon benutzen dÿrfen, jedoch nur, wenn er gerade nicht ausgelastet ist. Zur Inanspruchnahme eines vorgesehenen Zugriffsweges mÿssen weitere Bedingungen erfÿllt werden, die Ÿber der Zeit veršnderliche Wahrheitswerte annehmen kšnnen. 5-13

14 Bedingte Zugriffskontrolle Die Zugriffswege werden dazu mit PrŠdikaten assoziiert. Wir schreiben fÿr einen erlaubten Zugriffsweg < s, p,o P( x 1,x 2,...,x n ) > Bedeutung: Zugriff von s mit p auf o nur erlaubt, wenn PrŠdikat Ÿber den Grš en x 1,x 2,...,x n wahr Jedes Tripel der Zugriffsrelation kann mit einem spezifischen PrŠdikat versehen werden. Eine ZR, in der mindesten ein Tripel eine Zusatzbedingung tršgt, hei t dann eine bedingte Zugriffsrelation. Beispiele fÿr x: Ð die Systemuhr Ð die Prozessorauslastung Ð die verfÿgbaren Betriebsmittel Ð die Herkunft der Subjekte Ð der Inhalt der Objekte Ð speziell eingefÿhrte Schaltgrš en 5-14

15 Bedingte Zugriffskontrolle Der Bezug auf Wert, Umfang oder Wichtigkeit des Objektinhaltes hat als inhaltsabhšngige Zugriffskontrolle eine gewisse EigenstŠndigkeit gefunden. Die Grš en stammen offenbar aus der Systemumgebung (Zeit, Last, VerfŸgbarkeit, Anwesenheiten u.dgl.) aus den Subjekten (Grš en, die das Subjekt besitzt oder kennt) aus den Operationen (Version, Umfang, Laufzeit u.dgl.) aus den Objekten (Inhalt, Informationsmuster u.dgl.) In einfachen FŠllen (Schaltgrš en mÿssen in gewissen vorgegebenen Wertgrenzen liegen), kann die relationale Tabellenstruktur der Zugriffsrelation beibehalten werden. Z. B. kann s p o ug 1 og 2 ug 2 og 2 bedeuten, dass der Zugriffsweg < s, p, o > nur erlaubt ist, wenn ug 1 ² x 1 ² og 1 ug 2 ² x 2 ² og 2 wahr ist. 5-15

16 5.1.6 Gruppierungen Ist die Anzahl der beteiligten Elemente (Subjekte, Operatoren, Objekte) gro, so sind Gruppierungen nÿtzlich Subjekte (Rollen) Projektgruppe Abteilung Prozesse aus bestimmten Anwendungssystem Programme aus bestimmter Programmiersprache Objekte (Ordnungskriterien) Sachgebiet Kunde Bilder Messwerte Personaldaten Operationen (Operationscharakter) Lesende / Schreibende Existenzoperatoren Pflege-/Wartungsoperationen 5-16

17 Gruppierungen Wenn Gruppen angegeben sind, werden in der Zugriffsrelation Gruppenbezeichner verwendet: ZR S G P G O G Die Gruppierung kann natÿrlich auch nur fÿr eine oder zwei der drei Gruppen vorgenommen werden. Bei Gruppierung benštigen wir eine Zuordnung der Individuen zu den Gruppen. Im allgemeinen Fall lšsst sich das wiederum durch Relationen beschreiben Gruppenzuordnung der Subjekte: ZO S S S G Gruppenzuordnung der Operatoren: ZO P P P G Gruppenzuordnung der Objekte: ZO O O O G Gruppen kšnnen disjunkt Ÿberlappend geschachtelt sein. 5-17

18 Beispiel ( berlappende Gruppen): G1 s 1 s x G3 s 3 s 5 s 2 G2 s 4 Subjekt s x gehšrt sowohl G1 als auch G2 an (z.b. Person arbeitet in zwei Projekten) Es gilt also < s x,s G1 > ZO S <s x,s G2 > ZO S s x erhšlt Zugriff p auf o, genau dann wenn < s G1,p,o> ZR <s G2,p,o> ZR 5-18

19 Ringschutz Um die Zugriffskontrolle mit geringem Hardwareaufwand unterstÿtzen zu kšnnen, ist eine massive Vereinfachung erforderlich: So kann man auf Differenzierung typspezifischer Rechte verzichten und nur noch das Zugriffsrecht z vorsehen. Was jedoch in der Regel bleibt, ist eine graduelle SchutzwŸrdigkeit der Objekte eine graduelle Privilegierung der Subjekte Beides kann man leicht durch die folgende Zugriffsrelation erreichen: o 1 o 2 o 3 o 4... s 1 z z z z s 2 z z z s 3 z z s 4 z : Die s i und die o k sind dabei als Subjekt- bzw. Objektgruppen anzusehen. 5-19

20 Ringschutz Der Ringschutz wurde im Betriebssystem MULTICS zum ersten Mal realisiert. Der Name Ringschutz resultiert von der Vorstellung, dass Objekte mit abgestufter SchutzwŸrdigkeit bzw. Subjekte mit abgestuften Rechten in konzentrischen Ringen dargestellt werden kšnnen Subjekt der Klasse (Ringnummer) k darf auf Objekt der Klasse j zugreifen, gdw k ² j Objekte mit Ringnummer i dÿrfen nur von Subjekten mit Ringnummer k ² i benutzt werden 5-20

21 Ringschutz Ringschutz in vereinfachter Form auf vielen Maschinen verfÿgbar z.b. VAX (DEC) kennt vier Ringe: 1 Kernel 2 Executive 3 Supervisor 4 User Die meisten Maschinen kennen nur zwei Ringe 1 privilegiert (system-mode, supervisor-mode) 2 nicht privilegiert (user-mode) 5-21

22 5.2Realisierung der Zugriffskontrolle Zugriffskontrolle - wie im vorigen Abschnitt beschrieben - ist zunšchst ein allgemeines Konzept, dessen Realisierung auf verschiedenen Ebenen erfolgen kann. Um wirksam zu sein, muss Zugriffskontrolle vor allem auch auf Hardware-Ebene, also beim Zugriff des Prozessors auf den Speicher stattfinden. Die meisten Prozessoren bieten Schutzmechanismen an, die im Rahmen der Adressierung direkt in den Zugriffsweg eingebaut sind. Je nach MŠchtigkeit und KomplexitŠt der Adressumsetzung kšnnen unterschiedliche Zugriffskontrollen eingesetzt werden 5-22

23 5.2.1 Speicherschutz Speichertrennregister Im Einbenutzerbetrieb reicht es aus, das Betriebssystem gegen Fehler der Anwendungsprogramme zu schÿtzen. Legt man das Betriebssystem mit allen seinen Teilen in den Randbereich des Speichers (Anfang oder Ende) so genÿgt ein einziges Register, das die kleinste oder grš te zulšssige Adresse eines Anwendungsprogramms festlegt. Die Einhaltung muss von der Hardware gewšhrleistet werden Trennwert Betriebssystem Anwendungsprogramm zu schützender Bereich Es findet keine Differenzierung nach Operationstyp statt. Alle Zugriffe werden gleichbehandelt. 5-23

24 Speichergrenzregister (Relative Adressierung) Bei Mehrprogrammbetrieb - insbesondere Mehrbenutzerbetrieb - und relativer, zusammenhšngender Adressierung belegt ein Programm einen zusammenhšngenden Speicherbereich, dessen Anfang und Ende ŸberprŸft werden kšnnen Basisregister B G Grenzregister Anwendungsprogramm zu schützender Bereich 5-24

25 Funktionsweise des Grenzregisters Wie Ÿblich bei relativer Adressierung, wird zur (relativen) Programmadresse der Inhalt des Basisregisters hinzugezšhlt Kleinere Adressen als die Basisadresse sind daher nicht mšglich. Die Obergrenze wird mit Hilfe des Grenzregisters geprÿft. Bei berschreitung lšst der Prozessor eine entsprechende Unterbrechung aus Basisregister B Unterbrechung Programmadresse +? < G Grenzregister 5-25

26 Speicherschutz bei mehrstufiger Adressumsetzung Tabellenbasisregister und SegmenttabelleneintrŠge werden um ein LŠngenfeld ergšnzt. Bei berschreitung wird eine Unterbrechung ausgelšst. Tabellenbasisadresse Länge Basis Segmenttabelle? < Länge Basis + Seitentabelle? < + Speicher K Segment Seite Byte 5-26

27 Verallgemeinerung Die fÿr die Zugriffskontrolle wesentliche Idee besteht darin, nicht mit direkten, absoluten Adressen zu arbeiten, sondern durch einen Indirektionsschritt Ÿber eine Umsetzungstabelle die Mšglichkeit der Kontrolle zu haben Aus der Adresse wird dann ein Objektdeskriptor, der das adressierte Objekt eindeutig beschreibt, aber keinen direkten Zugriff erlaubt. Der Objektdeskriptor kann die Art des erlaubten Zugriffs genauer spezifizieren. Allgemeines Schema: Objektdeskriptor Umsetzung und Kontrolle Objekt 5-27

28 5.2.2 Capabilities Objektdeskriptoren, die fÿr Zugriffskontrollzwecke eingesetzt werden, hei en Berechtigungen oder Capabilities. Eine Capability enthšlt einen Bezeichner (Kennung) fÿr das Objekt und ein Feld, in dem die Rechte gespeichert sind, die der Besitzer der Capability an dem Objekt hat. Typ Rechte Bezeichner Sind die Rechte typspezifisch, so ist der Typ des bezeichneten Objekts Teil der Capability Capabilities bilden eine subjektorientierte Speicherung der Zugriffskontrollmatrix. Capabilities kšnnen als Parameter weitergegeben werden. Sie kšnnen auch kopiert werden. Das Recht, eine Capability zu kopieren, kann explizit vorgesehen sein 5-28

29 Bezeichner Der Bezeichner muss eindeutig sein, d.h. es dÿrfen nicht zwei Objekte denselben Bezeichner besitzen. (space unique identifier) Wird ein Objekt gelšscht, so ist der Bezeichner frei geworden und kšnnte fÿr ein neu erzeugtes Objekt wiederverwendet werden Existieren jedoch noch alte Capabilities auf das gelšschte Objekt (dangling references), so kšnnte man mit diesen Capabilities auf das neu erzeugte Objekt zugreifen. (Schutzverletzung) Man fordert daher von Bezeichnern die Eindeutigkeit auch Ÿber die Zeit (time unique identifier). Bezeichner dÿrfen daher nicht wiederverwendet werden. Beispiel: Man verwendet zur Objektbezeichnung einen 64-Bit -ZŠhler, der bei jeder Objekterzeugung inkrementiert wird. Damit kann man 585 Jahr lang jede Nanosekunde einen neuen Bezeichner generieren 5-29

30 IntegritŠt der Capabilities Capabilities erfÿllen ihre Schutzfunktion nur dann, wenn sie nicht gefšlscht oder verfšlscht werden kšnnen ( fšschungssicherer Ausweis). Ihre Erzeugung, Vernichtung, Modifikation und Weitergabe muss durch die Kontrollinstanz erfolgen. Mšglichkeiten des Schutzes a) Hardware-UnterstŸtzung: Spezielle Kennzeichnung (tag-bit) Capability Normaldatum C C N N N N C N Nachteil: Hoher Hardware-Aufwand Speicherausschnitt 5-30

31 IntegritŠt der Capabilities b) Spezielle BehŠlter (partitioned memory) Capabilities werden in speziellen Segmenten getrennt von anderen Daten gehalten Capability-Segment Normales Segment Kopieren nicht erlaubt c) Gegliederte Segmente Segmentdeskriptor Normale Daten Normale Daten Capabilities Capabilities 5-31

32 5.2.3 Zugriffskontrollisten (ZKL) (access control list, ACL) WŠhrend Capabilities eine subjektorientierte Zugriffskontrolle darstellen, bilden die Zugriffskontrollisten eine Objektorientierte Zugriffskontrolle Capability Umsetzung und Kontrolle Objekt r i o i globale Tabelle Bezeichner Zugriffskontrolliste Objekt o i Typ s 1 r 1 s 2 r 2 s 3 r 3 Bei jedem Zugriff wird in der ZKL geprÿft, ob das zugreifende Subjekt die erforderlichen Rechte fÿr die Operation besitzt. ZKL mÿssen ebenso wie Capabilities vor Manipulation geschÿtzt sein. 5-32

33 Zugriffskontrollisten und Capabilities Capabilities sind sehr flexibel, da sie als geschÿtzte, permanente Referenzen (Pointer) auf Objekte angesehen werden kšnnen. Probleme bereitet die Kontrolle ihrer Verbreitung und die Schwierigkeit, Rechte wieder zu entziehen. ZKLen erlauben jederzeit einen Rechteentzug, sind aber ineffizient, wenn jeder Zugriff zu einer Durchsuchung der Liste fÿhrt. Kompromisslšsung: Es werden ZKLen verwendet, jedoch wird beim ersten Zugriff eine temporšr gÿltige Capability erzeugt, die fÿr die nachfolgenden Zugriffe eingesetzt wird. In gewisser Weise geht das Unix-Dateisystem so vor (Rechte im Directory, Erzeugen eines temporšren Dateideskriptors) 5-33