Konstruktionsprinzipien sicherer Systeme

(1)

Grundlagen der

IT-Sicherheit

Teil 3

Rüdiger Dierstein, S.M.

Technische Universität München WS 2002/03

ThesenSep01/1/

Grundl Dez-02

Diese Unterlagen sind Begleitmaterial zur Vorlesung

„Sicherheit von IT-Systemen (IT-Sicherheit)“ an der Technischen Universität München. Sie dienen aus- schließlich dem persönlichen Gebrauch der Hörerin- nen und Hörer der Vorlesung . Alle Rechte an den Un- terlagen, einschließlich der Übersetzung in fremde Sprachen bleiben dem Verfasser vorbehalten.

Teile dieses Werkes dürfen nur mit Angabe der Quelle und mit Genehmigung des Verfassers in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfah- ren), auch für Zwecke der Unterrichtsgestaltung, re- produziert oder unter Verwendung elektronischer Sys- teme verarbeitet, vervielfältigt oder verbreitet werden.

 Copyright Rüdiger Dierstein, 82234 Oberpfaffenhofen, 2002

Konstruktionsprinzipien sicherer Systeme

► Erlaubnisprinzip vs.

Verbotsprinzip

► Vollständigkeit

► Minimalprinzip

(Geringste Berechtigung, „Need- to-know”)

► Akzeptanz

► Verhältnismäßigkeit oder Angemessenheit

► Allgemeine Kenntnis

► Einfachheit

Problem

Prinzipien für die Konstruktion sicherer Syste- me können zu widersprüchlichen Anfor- derungen führen. Dann muss für den prakti- schen Anwendungsfall der jeweils bestmögli- che Kompromiss gefunden werden.

Modell Okt-01 / Mod1/Modell Sep-01 /Empf/ Konstprinz Dez00 /Prinz1/

Erlaubnisprinzip

Es sind alle Aktionen untersagt, die nicht ausdrücklich erlaubt sind.

Folge

Fehlfunktion der Sicherung kein Zugriff = keine Aktion wird schnell bemerkt

Wichtig für Konzept- und Implementierungsfehler – müssen (sollten) immer zu Zugriffsverweigerung führen

Problem

Fehlfunktion der Sicherung „Denial of Service“ = automatische Alarmfunktion

Hinweise

► Das Bundesdatenschutz (BDSG) baut bisher auf dem Erlaubnisprinzip auf. Widerspruch zur gängigen Praxis in der Informationstechnik!

► Für Sonderzustände wie Wartung, Reparatur Pflege, Putzen, … erzwingt das Erlaubnisprinzip Sonderregelungen.

Fortsetzung

Konstprinz Dez00 /Prinz2/

(2)

Verbotsprinzip

Es sind alle Aktionen erlaubt, die nicht ausdrücklich untersagt sind.

Folge

Fehlfunktion der Sicherung „wilder“ Zugriff = unbefugte Aktionen möglich werden nicht bemerkt oder nicht gemeldet

Problem

Fehlfunktion der Sicherung beliebige Nutzung + Missbrauch keine Alarmfunktion

Hinweise

Die Praxis der Informationstechnik läuft nahezu ausschließlich nach dem Verbotsprinzip ab.

„Alles ist erlaubt, solange es nicht ausdrücklich verboten wird!“

Erlaubnisprinzip vs. Verbotsprinzip

Prinzipielle Frage der Vorgehensweise Erlaubnisprinzip

Welche Elemente (Komponenten) des Systems sollen zugänglich sein?

Verbotsprinzip

Welche Elemente (Komponenten) des Systems müssen geschützt werden?

Unterschiede

insbesondere beim Übergang von Normalbetrieb zu Sonderzuständen mit Ausfall (oder Aussetzen) der Si- cherungsmaßnahmen:

Erlaubnisprinzip (Total)-Sperre aller Zugänge Funktionsausfall (Denial of Service)

Verbotsprinzip Öffnung aller Zugänge Ausfall aller Sicherungen

Typische Beispiele

► Übergang Routinebetrieb → Reinigung

► Übergang Routinebetrieb → Wartung

► Stromausfall, Katastrophenfälle, …

Konstprinz Dez00 /Prinz3a/

Vollständigkeit der Autorisierung

Jede Aktion mit jedem Objekt in jedem Zustand muss autorisiert werden.

Dies gilt insbesondere für alle Sonderzustände:

► Reinigung

► Hardwarewartung (→ Fernwartung!)

► Hardwareänderung

► Softwarewartung

► Softwareanpassung und -ergänzung

► Systeminstallation und –pflege (auch Ände- rung von Systemparametern, „patches“, etc.)

► Ausfälle des Systems

► Wiederanlauf

► Alarm- und Katastrophenzustände

► Besucher

► Vorgesetzte (Vorstände!)

► … Problem

Wer darf was in Sondersituationen?

Minimalprinzip

Prinzip der geringsten Berechtigung oder Prinzip des „Need-to-know“

Jedes Subjekt erhält nur so viele Rechte, wie es zur Ausführung einer Aufgabe (Aktion) benö- tigt.

Hinweise

Hierarchische Berechtigungsmodelle (z.B. Bell- LaPadula) gelten nur in engen und speziellen Be- reichen.

Im Alltag richten sich Autorisierungen und damit Zugriffsmodelle immer nach dem Rollenspiel der beteiligten Elemente.

Hierarchische Berechtigungsmodelle führen bei Sondersituationen (s.o.) fast immer zu Problemen!

In der Wirtschaft¹¹¹¹ verbreitet das komplementäre Prinzip als „Need-to-withhold“

1 Don Parker, IFIP-Konferenz Helsinki (SF), 1990

Konstprinz Dez00 /Prinz 5/

(3)

Akzeptanz

Prinzip des Wohlverhaltens

Konzipiere Sicherungsmaßnahmen immer so, dass alle Benutzer (Betroffenen) angestachelt werden, sie einzuhalten.

Voraussetzungen

Maßnahmen sind

► angemessen

► erforderlich

► zweckmäßig

► einfach

► durchschaubar

Benutzerreaktionen

► Passivität = Versuch, den Maßnahmen aus- zuweichen, nur das Nötigste, Unumgängli- che tun

► Reaktanz (Renitenz, Resistenz) = Sich- Sträuben gegen die Anforderungen, „Ra- che“ der Betroffenen bis zur Sabotage

► Über-Konformität = Nutzung der Maßnah- me, aber ohne aktive Beteiligung (Kreativi- tät)

Verhältnismäßigkeit, Angemessenheit

Aufwand und Ziele jeder Sicherung müssen in einem

vertretbaren Verhältnis zu- einander stehen.

Verhältnismäßigkeit wird beeinflusst durch:

► alle Arten von Rechtsvorschriften (vgl. Defini- tion von Datenschutz)

► Gewährleistung der Ordnungsmäßigkeit (Ver- lässlichkeit)

► Notwendigkeit

► Wirtschaftlichkeit

► Wirkung der Maßnahmen (Effizienz)

► … …

Probleme

► Übermäßige Sicherung im Widerspruch zur Funktionalität oder Funktionsfähigkeit

► Änderung der Erfordernisse und der Wirksamkeit durch Änderung der Technik (Technologie)

Fortsetzung

Zitat zur

Verhältnismäßigkeit Verhältnismäßigkeit Verhältnismäßigkeit Verhältnismäßigkeit

„Der Wirtschaft sind verfassungsrechtlich genau die Kosten zumutbar, die sie aufbringen muss, um ihre Verarbeitung personenbezogener Informationen frei von Eingriffen in grundrechtlich geschützte Be- reiche der Bürger zu halten, und um die Kontrolle der Rechtmäßigkeit der Verarbeitung durch die betroffenen Bürger und die zuständigen staatlichen Stellen zu ermöglichen.“

W. Podlech in der Computerwoche vom 26.3.1976

Konstprinz Dez00 /Prinz 7a/

Offenlegung

► Alle Benutzern (Betroffenen) sollen das Ziele und Wirkungsweise der Sicherungsmaßnahmen bekannt sein.

► Sicherungsmaßnahmen müssen so konzipiert und implementiert werden, dass diese Kenntnis ihre Verlässlichkeit nicht beein- trächtigt.

Grundsatz

Kein Sicherungsverfahren darf auf die Unwissenheit oder Unfähigkeit

möglicher Eindringlinge bauen!

Beispiele:

► Funktionsweise eines Kombinationsschlosses

► Kerckhoff’sches Prinzip in der Kryptographie

(4)

Einfachheit

Der Kern jedes Sicherungssystems – oder sicheren IT-Systems muss

► so einfach und

► so klein wie möglich sein.

Gründe und Probleme

► Korrektheitsbeweise für größere und komplexe Systeme problematisch

► Entdecken und Erkennen unzulässiger Zugriffswege (→ Schnittstellen)

► Unmöglichkeit des Testens auf Nicht- Vorhandensein von Fehlern

► Vollständiges Austesten aller Möglichkeiten sehr schnell unausführbar oder unmöglich

Kriterien und Evaluierung

Warum Evaluierung nach Kriterien?

► komplexe Aufgabenstellungen

► komplexe Systeme

► Standardisierung und Vergleichbarkeit

► Erhöhung der Verlässlichkeit

► Angebotsvielfalt

► …

Was wird evaluiert?

► Produkte (Komponenten) –

mit unbekannter Einsatzumgebung Hardware und Hardwarekomponenten Betriebssysteme

Systemkomponenten Anwendersysteme offene Software aller Art

Sicherheitssysteme und -komponenten

…

► Systeme -

mit bekannter Einsatzumgebung Systeme für bestimmte Einsatzbereiche, (militärische IT-Systeme, Systeme für Bankanwendungen, ...)

Systeme für definierte Aufgaben, (Ver- kehrsleitsysteme, Steuerungen für Kraft- werke, Überwachungseinrichtungen, …)

Fortsetzung

Krit.doc Dez-00 /1/

Wer nutzt Evaluierung und Kriterien?

Hersteller

(neutrale) Bewertung der Sicherheit von Produkten

Verkaufsförderung

Risikominderung bei Gewährleistung und Haftung

… Anwender

Entscheidungshilfe bei Beschaffung und Einsatz

Risikominderung bei Gewährleistung und Haftung

Sicherheitsanalyse der proprietären Sys- teme

…

Evaluatoren Markt

…

Krit.doc Dez-00 /2/

(5)

Trusted Computer Systems Evaluat Trusted Computer Systems Evaluat Trusted Computer Systems Evaluat Trusted Computer Systems Evaluatiiiion on on on Criteria (TCSEC)

Criteria (TCSEC) Criteria (TCSEC)

Criteria (TCSEC) –– –– –– –– The „Orange Book“ The „Orange Book“ The „Orange Book“ The „Orange Book“

► ab 1978 entwickelt vom US Department of Defense, 1985 veröffentlicht

► erster „offizieller“ Meilenstein zum Problem Sicherheit von DV-Systemen

als Standard für Hersteller

Versuch einer „Metrik“ für die Vertrauenswürdig- keit von Computern

► Grundsätzlich auf militärische Anwen- dungen ausgerichtet

► hierarchisches Modell der Sicherheitsstu- fen

Folgen

► wesentlicher (zusätzlicher) Anstoß für ähnli- che Vorhaben weltweit

Nachteile

► begrenzter Geltungsbereich (Verteidigung)

► begrenzter Systembegriff (Betriebssysteme)

► begrenzte Bedeutung von Sicherheit (fast nur Vertraulichkeit)

Krit.doc Dez-00 /3/

TCSEC – Historie

1967 Task Force des DoD – Entwurf von Sicher- heitsmaßnahmen für DV-Systeme, insbesondere gegen unberechtigten Zugriff 1970 Ergebnisbericht „Security for Computer Sys-

tems“

1972 Anderson Report: „Computer Security Tech- nology Study“

1973 Bell-LaPadula Modell

(1) Mathematische. Grundlagen (2) A Mathematical Model

(3) Refinement of the Mathematical Model 1976 „Unified Exposition and Multics Interpreta-

tion of the Bell-LaPadula Model“

1977 Beginn der DoD Computer Sec. Initiative 1978 Beginn der Arbeiten zu Evaluationskriterien

in den USA (Mitre Corp. + NBS)

1981 Gründung des DoD Computer Security Cen- ter (CSC)

1982 1. Entwurf der TCSEC 1983 TCSEC „Orange Book“

1984 CSC wird zum Nationsl CSC (NCSC) – Erste Evaluationen

1985 Erste Revision der TCSEC

1987 TNI „Red Book“ – Trusted Network Inter- pretation of the TCSEC

1988 Entwurf TDI – Trusted DBMS Interpretation of the TCSEC

Krit.doc Dez-00 /4/

Sicherheitsanforderungen

nach dem „Orange Book“

(1)(1)

(1)(1) Markierungen (tags)

Objekte haben Markierungen, über die alle Zugriffe darauf regel- und kontrollierbar sind (2)

(2)(2)

(2) Sicherheitskonzept (security policy) Es gibt ein explizites und wohldefiniertes Si- cherheitskonzept, dessen Einhaltung durch das System erzwungen wird.

(3) (3)(3)

(3) Identifizierung und Authentisierung (au- thentication)

Alle Subjekte müssen identifizierbar sein. (4)

(4)(4)

(4) Verantwortbarkeit, Beweissicherung (accountability)

Protokolldaten müssen gesammelt und sicher aufbewahrt werden, um die Verantwortlichen für sicherheitskritische Aktionen feststellen zu kön- nen.

(5)(5)(5)

(5) Qualität (assurance)

Sicherheitsmechanismen müssen mit nachvoll- ziehbarer Qualität die Forderungen 1.-4. erfül- len

(6)(6)(6)

(6) Ständiger Schutz (continuous protection) Mechanismen nicht umgehbar und gegen unbefugte Änderungen geschützt.

Krit.doc Dez-00 /5/

Sicherheitsanforderungen für Netze

nach dem „Red Book“

Sicherheitsanforderungen nach dem „Orange Book“auf Netze nicht anwendbar (→ Kap. 2 des Red Book)

Sicherheitsdienste nach dem TNI

(

T

rusted

N

etwork

I

nterpretation of the TCSEC)

► Integrität der Kommunikation Authentisierung

Integrität der Daten

Sende- und Empfangsbeweis

► Abhörsicherheit

Vertraulichkeit der Daten

Schutz vor Verkehrsflussanalyse Auswahl von Überstragungsstrecken

► Diensteverweigerung Kontinuität des Betriebs protokollbasierter Schutz Netzüberwachung Anmerkung

Erweiterung der Sicherheitsaspekte des Orange Book, aber weiterhin keine durchgreifende Syste- matik

Krit.doc Dez-00 /6/

(6)

Nationale und internationale Kriterien

seit 1978

und davor Vorarbeiten in Deutschland (IABG, GDD et al.)

1983 Veröffentlichung der IABG, Ottobrunn (v.d.Brück, Jahl et al.), Erweiterung auf Vertraulichkeit – Integrität - Verfügbar- keit

➨ erste systematische Strukturierung der Bedeutung des Begriffs Sicherheit ➧➧➧➧ 1989 deutsche Kriterien (BSIEC) veröffentlicht

verschiedene nationale Kriterienkataloge in UK, F, NL, D, CDN, …

1991 Versuch einer Harmonisierung der nationalen Kriterien durch die europäische Ge- meinschaft (ITSEC)

1992 Erweiterung des Bedeutungsumfangs durch die Zurechenbarkeit (accountabili- ty) in den kanadischen Kriterien

seit 1993

Arbeit an den Common Criteria (CC) unter Führung der USA mit dem Ziel noch größerer Flexibilität und Allgemeinheit 1997 Version 1.0 der CC

Ende 1999

Version 2.0 der CC, gemeinsames Vor- gehen mit der ISO

Fortsetzung

Krit.doc Dez-00 /7/

Nationale und internationale Kriterien (Fts.)

Kriterienkataloge

1983/85 USA DoD (US-Department of Defense) Trusted Computer System Evaluation Cri- teria (TCSEC), genannt „Orange Book”

1985–89 Deutschland BSI (Bundesamt für Si- cherheit in der Informationstechnik) IT-Sicherheitskriterien – Kriterien für die Be- wertung der Sicherheit von Systemen der Informationstechnik (IT) – 1. Fassung (BSISEC)

1990–91 CEC Information Technology Security Evaluation Criteria, Version 1.2 (ITSEC) 1990–?? ISO/IEC (JTC1/SC27/WG3)

Evaluation Criteria for IT Security (ECITS) 1992–93 Kanada (CSSC/CSE)

Canadian Trusted Computer Product Evaluation Criteria Version 3.0 (CTCPEC) 1992–93 USA (NIST und NSA)

Federal Criteria for Information Technology Security, Draft Version 1.0 (FC-ITS) 1994– 99/… USA/CDN/EU (Common Critria Editorial

Board)

Common Criteria Version 2.0 (CC)

Fortsetzung

Krit.doc Dez-00 /7/

Nationale und internationale Kriterien (Fts.)

Folgen Folgen Folgen Folgen

◆ Nutzung auch für nicht-militärische Anwendun- gen

◆ neue Standards in IT-Sicherheit

◆ Erweiterung und Verbesserung des Geltungsbereichs

des Systembegriffs

der Definition von Sicherheit der Anwendungen

Problem Problem Problem Problem

◆ zunehmend Verlust der Systematik wegen zuviel

„Harmonisierung“ und „Universalität“

Krit.doc Dez-00 /6/

(7)

Grundfunktionen und Mechanismen

Einige Definitionen (nach ITSEC)

► Evaluation (Evaluation)

die Bewertung eines IT-Systems oder -Produkts (TOE) anhand definierter Kriterien (Evaluationskri- terien)

► Zertifizierung (Certification)

die Abgabe einer formalen (förmlichen?) Erklärung, die die Ergebnisse einer Evaluation und die ord- nungsgemäße Anwendung der benutzten Evaluati- onskriterien bestätigt

► Akkreditierung (Accreditation) hat je nach den Umständen zwei Definitionen.

1. das Verfahren, welches für ein Prüflabor die technische Kompetenz und die Unparteilichkeit anerkennt, die zugehörigen Aufgaben durchzu- führen

2. das Verfahren, welches ein IT-System zum Be- trieb in einer speziellen Umgebung freigibt

► System (System)

eine spezifische IT-Installation mit einem bestimmten Zweck und einer spezifischen Betriebsumgebung

► Produkt (Product)

ein Paket aus IT-Software und/oder -Hardware, das eine bestimmte Funktionalität bietet, die zur Verwen- dung oder zur Integration in einer Vielzahl von Sys- temen entworfen wurde

Fortsetzung

Grundfkt.doc Dez-00 /Def1/

Einige Definitionen (nach ITSEC) (Fts.)

► Evaluationsgegenstand – ^TOE

ein IT-System oder -Produkt, das einer Evaluation unterzogen wird (Target of Evaluation)

► Sicherheitsziele (Security Objectives) Der Beitrag zur Sicherheit, den ein TOE leisten soll^*)

► Sicherheitsvorgaben (Security Target) Eine Spezifikation der von einem TOE geforderten Sicherheit, die als Grundlage für die Evaluation verwendet wird. Die Sicherheitsvorgaben spezifizieren sowohl die sicherheitsspezifischen Funktionen des TOE als auch die Sicherheitsziele, die Bedrohungen dieser Ziele sowie die einzelnen Sicherheitsmecha- nismen oder –maßnahmen, die verwendet werden.

► Vertrauenswürdigkeit (Assurance) Eigenschaft des TOE, die das Maß an Vertrauen ausdrückt, welches man in die durch den TOE be- reitgestellte Sicherheit haben kann

► Sicherheit (Security)

Die Kombination aus Vertrauenswürdigkeit, Integrität und Verfügbarkeit

►►► Hinweis: In ITSEC werden duale und mehrsei- tige Sicherheit in der Definition von Sicherheit nicht er- wähnt, obwohl an vielen Stellen die Zurechenbarkeit (engl. accountability) bereits angesprochen wird. ◄◄◄

*) Entspricht einem Punkt im semantischen Raum.

Grundfunktionen der Sicherheit Grundfunktionen der Sicherheit Grundfunktionen der Sicherheit Grundfunktionen der Sicherheit

(3. Schicht des Modells) (3. Schicht des Modells) (3. Schicht des Modells) (3. Schicht des Modells)

Welche funktionellen Eigenschaften muss ein IT-System besitzen, damit es als ssssi-i-i-i-

cher cher cher

cher angesehen werden kann?

Grundfunktionen bilden die 3. Schicht des semantischen Modells. Also lautet die Frage aus- führlicher:

Grundfunktionen im semantischen Modell

Welche kennzeichnenden funktionellen Eigenschaften muss ein IT-System besitzen, damit die An- forderungen an seine Sicherheit (Sicher- heitsziele) prinzipiellprinzipiellprinzipiell erfüllt werden kön-prinzipiell nen?

Beachte:

Bei den Grundfunktionen wird weder gefragt, mit welchen Mitteln (Verfahren, Vorrichtungen, Maß- nahmen) die Sicherheitsanforderungen verwirklicht werden, noch wie gut das geschieht.

Kennzeichnende funktionelle Kennzeichnende funktionelle Kennzeichnende funktionelle Kennzeichnende funktionelle Eigenschaften der S

Eigenschaften der S Eigenschaften der S

Eigenschaften der Siiiicherheit cherheit cherheit cherheit

Kennzeichnende Eigenschaft (Grundfunktion) im semantischen Modell heißt

► notwendig

Das IT-System muss diese Eigenschaften besitzen, wenn es den Sicherheits- anforderungen genügen soll.

► vollständig

Sie reichen – richtig implementiert – aus, um die Anforderungen an die Sicherheit des IT-Systems zu erfüllen.

► technisch unabhängig

Sie sind nicht an bestimmte Mechanismen oder Maßnahmen – an eine bestimmte technische oder organisatorische Verwirk- lichung – gebunden.

Zusatzforderung der Wirtschaftlichkeit:

Zusatzforderung der Wirtschaftlichkeit:Zusatzforderung der Wirtschaftlichkeit:

Zusatzforderung der Wirtschaftlichkeit:

► überdeckungsfrei

Die Eigenschaften sollen sich nicht unnötig ü- berlappen.

(8)

Sechs Grundfunktionen im semantischen Modell

1. Authentisierung 2. Rechteverwaltung 3. Rechtekontrolle 4. Protokollierung

(oder Audit)

5. Fehlerüberbrückung 6. Überwachung

als Eigenschaften der elementaren Aktionen Zugriff und Übertragung

Zuordnung der Grundfunktionen

Authentisierung Rechteverwaltung Rechtekontrolle

Ordnungsmäßi OrdnungsmäßiOrdnungsmäßi Ordnungsmäßiggggkeitkeitkeitkeit

Protokollierung Fehlerüberbrückung Überwachung

Berücksichtigung Berücksichtigung Berücksichtigung Berücksichtigung nicht

nichtnicht

nicht----ordnungsordnungsordnungsordnungs---- mäßiger Eleme mäßiger Elememäßiger Eleme mäßiger Elemennnntetete te

Grundfkt.doc Dez-00 /Gfkt1/

Grundfunktionen im deutschen Nationalen Kriterienkatalog (BSIEC)

1. Identifikation und Authentisierung 2. Rechteverwaltung 3. Rechteprüfung 4. Beweissicherung 5. Wiederaufbereitung 6. Fehlerüberbrückung 7. Gewährleistung der

Funktionalität

8. Übertragungssicherung

Zuordnung der BSISEC-Funktionen

1.–3. ➠➠➠➠ Ordnungsmäßigkeit

4.–7. ➠➠ Berücksichtigung nicht-rdnungsmäßiger ➠➠ Elemente

8. ➠➠➠➠ Übertragungssicherung 8. ist ein Mechanismus also Ebene 4

!!

Mechanismen (Maßnahmen)

Mechanismen (Maßnahmen) auf der 4. Schicht des semantischen Modells, setzen die Grundfunktionen der dritten Schicht in

reale Abläufe, Vorgänge oder Sachverhalte um.

Mechanismen (Maßnahmen) können sein

physikalische Vorrichtungen (Hardware) oder Software

Kombinationen aus Hard- und Software Vorkehrungen in der Infrastruktur organisatorische Maßnahmen personelle Maßnahmen In der Praxis sehr häufig

Kombinationen aus technischen, organisa- torischen und personellen Vorkehrungen Funktionstüchtigkeit und Vertrauenswürdigkeit der Mechanismen (Maßnahmen) sind ein wesentlicher Teil der

Qualität (engl. assurance) der Sicherheit eines IT-Systems.

Funktionalität vs. Qualität (BSI)

Unterscheide genau:

Funktionalität

(engl. functionality) Welche

Grundfunktionen (Eigenschaften) der Sicherheit müssen in einem IT-System vorhanden sein, das als sicher angesehen werden soll?

Qualität

(engl. assurance) Wie gut

sind die Grundfunktionen (Eigenschaften) in einem bestimmten IT-System durch Mechanis- men (Maßnahmen) verwirklicht worden?

Hinweise

► Qualität bezieht sich nicht allein auf die Güte der Maßnahmen, d.h. der technischen oder or- ganisatorischen Verwirklichung einer Sicher- heitsforderung!

► Statt Qualität wird in den ITSEC – und anders- wo – der Begriff Vertrauenswürdigkeit (engl.:

assurance) verwendet.

Grundfkt.doc Dez-00 /Qual1/

(9)

Qualität, Assurance

BSI – Qualität

► Maß für die Güte, mit der eine (Sicherheits)- Anforderung in einem IT-System erfüllt wird ITSEC – Assurance

► confidence in the correctness or the effec- tiveness of the security enforcing functions of a TOE (target of evaluation)²

Bewertung (Evaluation) der Qualität

nach der Vertrauenswürdigkeit

► der Sicherheitsanforderungen

► der Spezifikation der Systemteile

► der Abgrenzung zu nicht zu evaluieren- den Systemteilen

► des Herstellungsvorgang ( ISO 9000)

► des Betriebs

► der anwenderbezogenen Dokumentation sowie nach der Stärke (Güte)

► der verwendeten Mechanismen (Maß- nahmen)

2Darin ist vor allem das Vertrauen in die Korrektheit und Wirksamkeit der Mechanismen und ihrer Implementierung enthalten.

Grundfkt Jan-02 /Qual2/

Zusammenhang

Orange Book ⇔ ⇔ ⇔ ⇔ IT-Kriterien

Orange

Book BSIEC ITSEC

D ⇔⇔⇔⇔ ./. ⇔⇔ ⇔⇔

C1 ⇔⇔⇔⇔ F2/Q1 ⇔⇔ ⇔⇔ F-C1, E1 C2 ⇔⇔⇔⇔ F2/Q2 ⇔⇔⇔⇔ F-C2, E2 B1 ⇔⇔⇔⇔ F3/Q3 ⇔⇔ ⇔⇔ F-B1, E3 B2 ⇔⇔⇔⇔ F4/Q4 ⇔⇔ ⇔⇔ F-B2, E4 B3 ⇔⇔⇔⇔ F5/Q5 ⇔⇔⇔⇔ F-B3, E5 A1 ⇔⇔⇔⇔ F6/Q6 ⇔⇔ ⇔⇔ F-B3, E6

Kennzeichnender Unterschied oberer Teil

(D – C2) DACDACDACDAC – Discretionary Access Control benutzerbestimmbare Zugriffskontrolle unterer Teil

(B1 – A1) MAC – Mandatory Access Control vorgeschriebene (regelbasierte) Zugriffs- kontrolle

Grundfkt Jan-02 /Klas7/

Authentisierung

Authentiz Authentiz Authentiz Authentizität ität ität ität

► Bestätigung einer behaupteten Identität

► Nachweis der Originalität

► Nachweis der Unversehrtheit (Integrität, Voll- ständigkeit)

► Nachweis des korrekten Zusammenhangs

Subjekt Objekt

(Veranlasser) (Ergebnis, Gegenstand, Vorgang, …)

Hinweis Hinweis Hinweis Hinweis

Authentizität ist nicht auf Personen beschränkt. Authentizität wird von jedem IT-System und dessen Kom- ponenten gefordert, insbesondere von maschinellen Systemen und den mit ihnen verarbeiteten Daten^.

Authent.doc Dez-02 /Def1

Authentisierung

Identification and Authentication Identification and Authentication Identification and Authentication Identification and Authentication

ITSEC 1991

2.34

In many TOEs^*) there will be requirements to deter- mine and control the users who are permitted access to resources controlled by the TOE. This involves not only establishing the claimed identity of a user, but also verifying that the user is indeed the user claimed. This is done by the user providing the TOE with some information that is known by the TOE to be associated with the user in question.

2.35

This heading^**) shall cover any functions intended to establish and verify a claimed identity.

2.36

This heading shall include any functions to enable new user identities to be added, and older user identities to be removed or invalidated. Similarly, it shall include any functions to generate, change, or allow authorized users to inspect, the authentication information required to verify the identity of particular users. It shall also include functions to assure the in- tegrity of, or prevent the unauthorized use of authentication information. It shall include any function to limit the opportunity for repeated attempts to establish a false identity.

*) TOE Target of Evaluation

**) Generic Heading Grundfunktion, Basisfunktion

Authent.doc Dez-02 /Def2

(10)

Authentisierung

Sprachgebrauch (insb. juristisch)

authentisieren

einen Gegenstand rechtsgültig machen authentifizieren

Echtheit eines Gegenstandes rechtsgültig feststellen und bezeugen

Definitionen (nach BSIEC)

^*)

Identifizierung

Bestimmung der Identität eines Subjekts oder Objekts

Authentisierung

Nachweis der angegebenen Identität Die Feststellung der Identität eines Gegenstandes schließt in der Praxis in aller Regel eine Authentisie- rung mit ein.

Zitat BSIEC

„Eine Authentisierung kann nur dann unterbleiben, wenn eine fehlerhafte Identifikation praktisch aus- geschlossen werden kann.“

*) IT-Sicherheitskriterien – Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik (IT), – 1. Fassung 1989, ISBN 3-88784-192-1

Authent.doc Dez-02 /Def3/

Authentisierung

Aufgabe der Authentisierung

Feststellung + Gewährleistung, dass die an einer Aktion beteiligten Elemente

authentisch sind.

Das heißt:

Subjekte, Objekte und AktionenAktionenAktionenAktionen sind tatsäch- lich diejenigen, die sie zu sein vorgeben.

Zusatz

Authentisierung schließt ein die korrekte Zuordnung von Objekten zu Veranlassern.

Dies gilt insbesondere für die Aktion Übertragung (Zu- ordnung von Nachrichten zu Absendern und Empfän- gern).

Authent.doc Dez-02 /Aufg

Authentisierung

Symmetrie der Authentisierung

Folgerung für IT-Systeme

Authentisierung in IT-Systemen muss immer symmetrisch sein!

Beispiele

System authentisiert Benutzer und Benutzer authentisiert System Empfänger authentisiert Sender und Sender authentisiert Empfänger zusätzlich

Empfänger und Sender authentisieren über- tragene Daten

Fortsetzung

Authent Dez-02 /Sym1/

Authentisierung

Symmetrie der Authentisierung (Fts.)

Authentisierung bei Zugriffen

◆ Aktion:

Subjekt greift zu auf Objekt.

Gefordert:

Authentizität von Subjekt und Objekt

Authentisierung bei Übertragung

◆ Aktion:

Sender überträgt Daten (Nachrich- ten) an Empfänger.

Gefordert:

Authentizität von Sender, Empfänger und Daten

Authent.doc Dez-02 /Sym2/

(11)

Authentisierung

Problem der Authentizität

Wann sind Elemente authentisch?

◆ Wenn ihre Struktur authentisch ist?

oder

◆ Wenn ihre Funktion authentisch ist?

Beispiele für „Was ist authentisdch?“

Authent.doc Dez-02 /Probl

Benutzer mit Bart Benutzer mit Geheim- dienstauftrag („umgedreh- ter“ Mitarbeiter)

ungeändertes Pro-

gramm mit Fehlern geändertes Programm ohne Fehler

unveränderter Rechner

Rechner mit altem System auf neuer CPU

Rechner mit neuem Sys- tem auf alter CPU

Authentisierung

Komponenten der Authentisierung Vorstellung

Behaupten (Angeben, Vorzeigen) einer Identität

Verifizierung

Prüfung der behaupteten Identität, d.h.

Nachweis, dass diese Angabe rechtens ist

Abhängigkeit des Prüfmechanismus

► vom Gegenstand, dessen Authentizität fest- zustellen ist,

► von der Prüfinstanz, die die Authentizität feststellt,

aber auch

► von den Anforderungen an die Verlässlich- keit der Authentisierung

Beispiele für Anforderungen:

Beweisbarkeit gegenüber Dritten (wg. Rechtsverbind- lichkeit) ∙ Abhängigkeit vom Umfeld (Authentisierung an der Pforte vs. Authentisierung im Netz) ∙ …

Authent.doc Dez-02 /Komp1/

Authentisierung

Vorstellung

(Behaupten oder Angeben einer Identität)

Möglichkeiten der Vorstellung

Vorstellung als Ganzes

Ein Gegenstand (Subjekt oder Objekt) wird von der authentisierenden Instanz als Ganzes erkannt (wahrgenommen) und geprüft.

Vorzeigen eines Authentikators Die authentisierende Instanz erkennt und prüft nur einen signifikanten Teil oder einen Vertreter des Gegenstandes (pars pro toto)

Beispiele

◆ Person (als Ganzes) an der Pforte ⇔⇔⇔⇔ Person (durch Stimme oder Name) am Telefon

◆ Programm durch Lesen des (ganzen) Programmtextes

Programm durch Prüfen einer Checksumme oder Signatur

Hinweis

Vorstellung ist immer nur Behauptung ohne Nach- weis, ob die Behauptung richtig oder rechtens ist.

Authent Dez-02 /Komp2/

Authentisierung

Verifizierung

(Prüfung und Bestätigung einer behaupteten Identität)

Aufgabe der Verifizierung

Die behauptete Identität

ist richtig (korrekt)richtig (korrekt)richtig (korrekt)richtig (korrekt) und wird zu recht bzu recht bzu recht beazu recht beaeaeannnnsprucht.sprucht.sprucht.sprucht.

Das heißt:

► Das Element (der Gegenstand oder die Aktion) ist tatsächlich und ggf. beweisbar dasjenige, das es zu sein vorgibt.

Authent Dez-02 Komp3

(12)

Authentisierung

Authentikatoren

In der Umgangssprache:

Etwas,

das man ist oder weiß oder kann oder hat

Der Authentikator tritt an die Stelle des zu authentisierenden Elements. Ein kennzeichnender Teil des Ganzen wird als „Ersatz“ für das Ganze ge- nommen (pars pro toto).

Authent.doc Dez-02 /Authk1/Authent.doc Dez-02 ./Authk1/

Authentisierung

Arten von Authentikatoren

Originärer Authentikator

vorhandene physische oder geistige Ei- genschaft eines Gegenstands

Zugewiesener Authentikator

übergebener oder erworbener Besitz Originär

Originär Originär Originär

► zum Gegenstand gehörend, aus seinerSubstanz oder seinem Verhalten „ableitbar“

Beispiele

Fingerabdruck oder Stimme eines Menschen, Prüf- summe eines Programms, Schriftbild einer Schreib- maschine, ….:

Zugewiesen Zugewiesen Zugewiesen Zugewiesen

► physischer oder geistiger Besitz – Gegenstände, Wissen oder Können

Beispiele

Schlüssel, Passwörter, Chipkarten, …

Authent.doc Dez-02 ./Authk2/

Authentisierung

Verifizierung mit Authentikatoren Zwei Forderungen:

Keine Fälschung

Der Authentikator ist „echt“.

Kein Missbrauch

Die Zuordnung Authentikator Element (Gegenstand oder Aktion) besteht zu recht.

Fortsetzung

Authent.doc Dez-02 Authk3

Authentisierung

Verifizierung mit Authentikatoren (Fts.)

Grundsatzfrage Grundsatzfrage Grundsatzfrage

Grundsatzfrage an Authentikat an Authentikat an Authentikat an Authentikato oo oren ren ren ren

Ist die Zuordnung

Gegenstand Authentikator eindeutig und rechtens?

Probleme

◆ Originäre Authentikatoren Imitation

Fälschung

…

◆ Zugewiesene Authentikatoren Verlust

Diebstahl Vergessen Verrat

… Hinwe

is

Viele Authentikatoren sind Mischformen.

(13)

Authentisierung

Authentisierung mit A Authentisierung mit A Authentisierung mit A

Authentisierung mit Au uu uthentikatoren thentikatoren thentikatoren thentikatoren (Fts.)

V e r g l e i c h V e r g l e i c h V e r g l e i c h V e r g l e i c h

gespeicherter

Authentikator

}

⁼

^↓↓↓↓ {

vorgezeigter Authentikator

Voraussetzung

Authentisierende Instanz muss den Authentikator vor dem Vergleich „kennen“

Vergleichsergebnis

Identität oder „ausreichende“ Übereinstimmung

Bewertung des Vergleichs

stark abhängig von der Art und den Eigenschaften des verwendeten Authentikators und den Fähigkei- ten der authentisierenden Instanz

Beispiel Mensch:

⇒⇒

⇒⇒Passbild ⋁ Unterschrift ⋁ Stimme v Fingerab- druck

Fortsetzung

Authent.doc Dez-02 /Authk4/Authent.doc Dez-02 /Authk5/

Authentisierung

Authentisierung mit Authentikatoren Authentisierung mit Authentikatoren Authentisierung mit Authentikatoren Authentisierung mit Authentikatoren

(Fts.) Bewertung des Vergleichs

Entscheidung Vergleichs-

ergebnis angenommen abgewiesen Über-

einstimmung kein

Fehler FR

keine Über-

einstimmung FA kein

Fehler FR = False Rejection (fehlerhafte Abweisung) FA FA

FA FA = False Acceptance (fehlerhafte Annah- me

Ziel der Bewertung

FR = FA = 0

Praktische Näherung

FR = FA mit EER ≪≪≪≪ 1%

EER = Equal Error Rate

Authent.doc Dez-02 /Authk6/

Authentisierung

Authentisierung von Personen Authentisierung von Personen Authentisierung von Personen Authentisierung von Personen

Für Personen ist die Authentisierung als Ganzes noch immer weit verbreitet, sinnvoll

und wirksam.

Authentisierende Instanzen

sind dann ebenfalls Menschen: Pförtner, Wachpersonal, …

aber auch: Kollegen, Vorgesetzte etc.

im privaten Bereich: Angehörige, Freunde, Bekann- te, …

Juristische Formulierung

„XY ist dem Unterzeichneten persönlich bekannt“.

Juristische Folge

Die so authentisierte Person XY darf selbst wieder als authentisierende Instanz handeln (z.B. durch Unterschreiben eines Schriftstücks).

Fortsetzung

Authentisierung

Authentikatoren für Personen

◆ Schlüssel

◆ Ausweise

ohne Photo / mit Handunterschrift / mit Photo Magnetkarten

Chip-Karten („smart cards“) mit PIN (Passwort) Chip-Karten mit Fingerabdruck

◆ Passwörter, PINs (Kennwörter, „Parole“)

◆ Unterschrift von Hand (Handunterschrift) statisch: nur als Graph f(x))

dynamisch: Graph f(x) und Geschwindigkeit f’(x), ggf. auch Beschleunigung f^”^”^”^”(x)

◆ digitale Signaturen

mit geeigneten Protokollen, insbesondere mit asymmetrischen Schlüsseln

◆ biometrische Verfahren

Fingerabdruck ( Akzeptanz, Missbrauch) Gesicht

Stimme

Augenhintergrund (Netz-/Aderhaut (Retina / Uvea)

genetischer Code ( Gefahr des Missbrauchs) Adern des Handgelenks

Knochenmaße ( Praktikabilität)

(14)

Authentisierung

Passwörter als Authentikatoren Definition

Authentisierung mit Passwort Angabe (schriftlich oder mündlich) einer Zeichenkombination und Vergleich mit einem gespeicher- ten (gemerkten) Duplikat

Vorteile

leichte Implementierung leichte Installation

keine besondere Hardware

flexibel, anpassbar an Einsatzbedingungen ausreichend sicher bei sorgfältiger Anwen- dung

Problem

Mangelnde Sorgfalt, technisch und menschlich, ist die

entscheidende Schwachstelle.

Fortsetzung

Authent.doc Dez-02 /Passw1/

Authentisierung

Passwörter als Authentikatoren (Fts.) Forderungen an Passwortverfahren

► Einwegverschlüsselung der Passwortdatei (un- entschlüsselbare Vergleichskopie)

► sicherer Eingabeweg (➨ Abhören, Anzapfen, …)

► Sicherung der Abfrageprozedur (➨ logon)

► Mindestlänge 8 Zeichen)

► Zeichenvorrat mit Sonderzeichen

► begrenzte Gültigkeitsdauer

► begrenzte Wiederholungsanzahl

► Dunkelfeldtastung (➨ Kommandowiederholung)

► Kontrolle auf unzulässige Passwörter (➨ Wör- terbuch)

Problem der Handhabung

Passwörter sind Wissen von Menschen. Men- schen im Alltag sind

vergesslich bedingt lernfähig einfallsarm.

Folgen

► Passwörter zu kurz (Beispiel: PINs), zu langle- big zu leicht erratbar falsch aufbewahrt …

► allgemeines Akzeptanzproblem: ➨ Vergesslich- keit

Fortsetzung

Authentisierung

Passwörter als Authentikatoren (Fts.) Falsche Lösung

maschinengenerierte Zeichenfolgenfolgen als zu merkende Passwörter

Systematische Verfremdung als Lösung

(1) Verwende einen sehr vertrauten Begriff oder Satz als Ausgangstext!

(2) Verfremde diesen Text systematisch!

Beispiele

Zu (1): Vertrauter Satz Aller Anfang ist schwer.

Zu (2): Systematische Verfremdung

Verwende nur die Konsonanten für ein 10-stelliges Passwort ➨ llrnfngsts

Fortsetzung

Authentisierung

Authentisierung von Programmen

Vorstellung

Behaupten (Angeben, Vorzeigen) einer Identität

Verifizierung

Prüfung der behaupteten Identität, d.h. Nachweis, dass diese Angabe rechtens ist.

Für Programme heißt das

► Behaupten der Identität durch bloßes Vor- handensein (beim Laden, beim Aufruf, …)

► Verifizierung mit Hilfe von Signaturen u.a.

(heute i. A. nicht vorhanden)

► Praktische Vorgehensweise

Indirekte Prüfung der Identität durch

organisatorische Maßnahmen, z.B. strenge Bibliotheksverwaltung

Abschotten der Zugriffe (→ „Das Programm kann sich nicht geändert haben!“)

Fortsetzung

Authent.doc Dez-02 /Passw3/Authent.doc Dez-02 /Obj1/

(15)

Authentisierung

Authentisierung von Programmen

(Fts.)

Das aufrufende oder aufgerufene Programm ist das „.richtige“, d.h. tatsächlich dasjenige, das es zu sein vorgibt.

Es ist insbesondere nicht manipuliert ( ➨➨➨➨ Viren).

Möglichkeiten der Prüfung

► Prüfung als Ganzes

Das Programm wird von der authentisierenden Instanz als Ganzes verifiziert (geprüft).

► Prüfung eines Authentikators

Die authentisierende Instanz analysiert nur einen signifikanten Teil oder eine Signatur als Vertreter des Programms (pars pro toto)

Hinweis

Auch das Verhalten und die Umgebung von Programmen haben Signatur-Charakter.

Authent.doc Dez-02 /Passw4/Authent.doc Dez-02 /Obj2/

Authentisierung

Entdeckung von Manipulationen (Viren)

Grundsätzlicher Ansatz Grundsätzlicher Ansatz Grundsätzlicher Ansatz Grundsätzlicher Ansatz

Kein Programmaufruf ohne Authentisierung

Das bedeutet insbesondere:

Jedes Programm muss vor jeder Ausführung nachweisen, dass es sich in integrem, unma- nipuliertem Zustand befindet.

Drei Schritte Drei Schritte Drei Schritte Drei Schritte

(1) Validieren der Programme

(2) Zertifizieren und Festhalten des zertifizier- ten Zustands

(3) Vergleich Ad-hoc-Zustand ⇔⇔⇔⇔ zertifizierter Zustand vor jedem Aufruf (Laden)

Fortsetzung

Authent.doc Dez-02 /Obj3

Authentisierung

Programm

):

Manipulation Detection Code – MDC

Meyer, C.H./ Schilling M.; Secure Program Load with Manipulation Detection Code Proc. Securicom 88 – 6ème Congrès Mondial de la Protection et de la Sécurité Informatique et des Communications, Pa- ris ‘88

Authent Dez-02 /Obj4

Hash

DEA MDC

Programm- Bibliothek

MDC- Liste

Hash DEA

Vergleich integre Bereiche

integrer Kanal

integrer Bereich offener

Kanal

Laden LadenLaden

Laden nur, falls MDCListe = MDCaktuell

öffentlicher Schlüssel

Authentisierung

Authentisierung von Gegenständen

Der auftretende oder übertragene Gegen- stand – Subjekt oder Objekt – (Gerät, Datei, Schriftstück, Bild, aufgerufene oder auf- rufendes Programm, …) ist der „richtige“, d.h. tatsächlich dasjenige, der er zu sein vorgibt.

Das heißt insbesondere für Programme und Geräte:

Sie sind nicht manipnicht manipnicht manipnicht manipuuuuliert.liert.liert.liert.

Anmerkung.

Vgl. Hierzu die Themen Viren, Manipulationen in Net- zen, …).

Authent Dez-02 /Obj5

(16)

Authentisierung

Prüfung mit Signaturen

Signaturen sind Authentikatoren, die mit einem Gegenstand ver- bunden sind oder in Beziehung gesetzt werden können.

►

Originäre Signatur

Leite aus dem zu authentisierenden Gegenstand einen eindeutig zuordenbaren Code ab (z.B.

Hash-Code) und verbinde Code + Gegenstand.

►

Zugewiesene Signatur

Verstecke im Gegenstand (Code, Hardware, …) eine Markierung (Wasserzeichen, engl. water marking) so, dass sie von einem Angreifer nicht gefälscht (nachgemacht), wenn möglich gar nicht entdeckt werden kann ( →→→→ Steganographie).

Fortsetzung

Authent Dez-02 /Obj5a

Authentisierung

Funktionale Anforderungen an Signaturen (Authentikatoren)

(1) Echtheitsfunktion

Authentizität von Gegenstand (Datei, Schriftstück, Bild, Programm, Dokument, …) und Veranlasser (2) Identitätsfunktion

Zuordnung von Signatur (Unterschrift) und Akteur (Signierender, Aussteller)

(3) Abschlussfunktion

willentliches Definieren und Kennzeichnen des Gegenstandes als ein Ganzes

(4) Warnfunktion

Hinweis auf die rechtliche Bedeutung des Signie- rens (bewusster Vollzug des Signierens und be- wusstes Erkennen möglicher Folgen)

(5) Beweisfunktion Nachweis

der Urheberschaft des Ausstellers (Signie- renden) und

der Integrität des signierten Gegenstandes

Authentisierung

Handunterschrift als Authentikator

Funktionale Anforderungen

Die funktionalen Anforderungen von der Handun- terschrift im klassischen Rechtsverkehr seit jeher erfüllt werden.

Folge für Forderung (5)

Die klassische Unterschrift war das einzige Beweis- mittel im Rechtsstreit, das keine richterliche Bewer- tung (Beweiswürdigung) benötigte (→→→→ unmittelbare Wahrnehmung; Inaugenscheinnahme)..

Elektronische Unterschrift im Netz

^*) Eingabe der Handunterschrift über berührungs- intensives Pad, Touchscreen und Grafiktablett Nutzung von

statischen Merkmalen Graph f(t), Geschwindigkeit f’(t) und

Druck (Beschleunigung) f^”^”^”^”(t)

*)Fraunhofer-Institut für integrierte Publikations- und Informationssys- teme (IPSI), Darmstadt

Authentisierung

Handunterschrift als Authentikator (Fts.)

Vorteile

► Elektronische Unterschrift erfüllt die funktionalen Anforderungen an Authentikatoren.

► Sie erfüllt insbesondere die Abschluss- und Warnfunktion,

► weil sie wie Handunterschrift bewusst abge- geben wird (im Gegensatz zu Fotografie oder Video, zu Iris- oder Retina-Scanning u.Ä.).

► Akzeptanz: Nutzung eines jedermann längst vertrauten Verfahrens

► Keine kriminelle „Vorbelastung“ wie beim Fingerabdruck.

(17)

Authentisierung

Fingerabdruck als Authentikator

Vorteile

► Elektronische Unterschrift erfüllt die funktionalen Anforderungen an Authentikatoren.

► Eindeutige Zuordnungen selbst bei sehr großen Auswahlmengen (> 10⁸–10⁹Exemplare) oder engsten Verwandten (eineiige Zwillinge)

► Erstellung einer Restmenge von 50-150 Exem- plaren maschinell in kürzester Zeit (Minuten?) möglich.

► Gut für Erkennungsdienstliche Probleme, weil

„Spuren“ unbewusst erzeugt werden können.

► Keine Gesundheitsschäden bekannt

Nachteile

► Reduktion der Restmenge auf ein Exemplar z.Zt. nur manuell, sehr zeit- und arbeitsaufwen- dig (mehrere Tage/ Wochen)

► z.Zt. (2002) nur mit Spezialisten möglich

► unbrauchbar für alle Zwecke, die schnell Eindeutigkeit bei großer Teilnehmerzahl fordern (weltweiter Bankverkehr, elektronischer Handel ...)

► Gefahr des „Universal Identifier!“ ( gläserner Mensch)

Authentisierung

Autorisierung (Rechtevergabe)

Begriffe

Rechte Rechte Rechte

Rechte (authorization)

► Rechte

► Berechtigungen

► Autorisierungen

► Befugnisse

► Erlaubnisse

werden synonym verwendet. Ebenso sind synonym

► Rechtevergabe • Zuweisung von Rechten • Zuweisung von Berechtigungen • Befugnisver- gabe • Autorisierung

Danach werden auch folgende Begriffe weitestgehend mit gleicher Bedeutung verwendet:

unbefugte unberechtigte missbräuchliche unerlaubte

Nutzung Nutzung Nutzung Nutzung

Eigentümer (owner)

Derjenige, dem ein Element eines IT-Systems oder ein Teil davon gehört oder der dafür verantwortlich ist und der damit das Recht hat zu bestimmen, in welcher Weise es benutzt, geändert oder in ande- rer Weise darüber verfügt werden darf

Zwei Bestandteile

► Autorisierung (Vergabe, Zuweisung) von Rechten an Subjekte und Objekte und deren

► dynamische Verwaltung

Rechte definieren:

„Welches Subjekt darf was wann wie mit wel- chem Objekt?“

Diese Definition ist auf

Relationen undundund Aktionen und anzuwenden.

Die Rechtevergabe muss dynamisch

(zeitlich variabel) sein können.

Rechteverw.doc Dez00 /2/

(18)

Autorisierung im IT-System

Abbildung

► externe Rechte

interne Rechte

Interne Rechte definieren

► Welches Subjekt darf auf welches Ob- jekt wie zugreifen?

► Welches Subjekt darf an welches Ob- jekt wie übertragen?

Vergabe und Verwaltung der Rechte

grundsätzlich anzuwenden auf

alle Gegenstände und Aktionen, also grundsätzlich auf alle Subjekte und Objekte.

Beispiele für zu autorisierende Elemente

► Benutzer

► Geräte

► Gerätetypen

► Befehle, ..., Programme

► Programmsysteme

► Dateien

► Speicherbereiche

► ...

Vergabe der Rechte

hängt von der Anwendung und deren Risiken ab, also vom Anforderungskatalog.

Interne Autorisierungen

Beispiele für interne Zugriffsrechte 1

.

Zugriffe auf Objekte in Dateien (Felder)

lesen (read)

schreiben, ändern, löschen (write, erase, up- date)

ausführen (execute)

…

2 .

Zugriffe auf Dateien (Dateiverwaltung) anlegen (create)

entfernen (delete)

…

3.

Zugriffe auf Dateiverwaltung (Rechtevergabe) autorisieren (authorise)

Rechte löschen (deauthorise)

…

4 . …

Anmerkungen

Ist solch eine hierarchische Ordnung der Rechte geeignet für Abbildung des „Rollenspiels“?

Ausführen (execute) ≠ Lesen (read)

Rechteverw.doc Dez00 /4a/

Autorisierung (Vergabe der Rechte)

Berücksichtige alle Zustände!

► Betrieb

► geplante Sonderzustände

► ungeplante Sonderzustände Betrieb

Routine- oder Produktionsbetrieb Test- und Probebetrieb

…

Geplante Sonderzustände Wartung

Reinigung Wiederanlauf

Installation, Änderung Vorführung, Besuch (?) Ungeplante Sonderzustände

Fehler (Störung, Ausfall) Fehlerbehebung, Wiederanlauf Alarm

Sabotage, Unfall, Katastrophe

…