FernFH MediaWiki - Benutzerbeiträge [de-at]

Computer- und Netzwerksicherheit

2026-02-13T20:29:36Z

VÖLKL Peter:

[[Computer- und Netzwerksicherheit - Gesamt|Computer- und Netzwerksicherheit - Gesamt (Achtung - immer die aktuellste Version!)]]

'''Version für das Sommersemester 2026'''

[[Special:PermanentLink/5584|Computer- und Netzwerksicherheit - Grundlagen|Computer- und Netzwerksicherheit - Grundlagen]]

[[Special:PermanentLink/2157|Computer- und Netzwerksicherheit - Bewusstseinsbildung|Computer- und Netzwerksicherheit - Bewusstseinsbildung]]

[[Special:PermanentLink/2278|Computer- und Netzwerksicherheit - Kryptograhpie|Computer- und Netzwerksicherheit - Kryptograhpie]]

[[Special:PermanentLink/2711|Computer- und Netzwerksicherheit - Zugriffssteuerung|Computer- und Netzwerksicherheit - Zugriffssteuerung]]

[[Special:PermanentLink/2280|Computer- und Netzwerksicherheit - Netzwerksicherheit|Computer- und Netzwerksicherheit - Netzwerksicherheit]]

Benutzer:VÖLKL Peter

2025-03-11T20:23:00Z

VÖLKL Peter:

<div>[[Datei:Völkl Peter 2024-054 klein.jpg|300x200px|left|thumb|Peter Völkl]]'''Peter Völkl''' (''Jahrgang 1984'') startete seine berufliche Laufbahn nach dem Abschluss seiner Ausbildung an der '''HTBLuVA für EDV und Organisation''' im Jahr 2005 als '''Softwareentwickler beim Österreichischen Roten Kreuz'''. 2008 übernahm er die Leitung einer Abteilung der Blutspendezentrale für Wien, Niederösterreich und Burgenland, die für die '''IT-Services des Blutbereichs''' verantwortlich war. Neben der Führung der Abteilung lagen seine Schwerpunkte in der '''Koordination und Überwachung von IT-Projekten und -Prozessen''' sowie in der '''Entwicklung, Testung und Validierung von IT-Systemen'''.
Parallel zu seiner beruflichen Tätigkeit begann er 2010 das '''Bachelorstudium Wirtschaftsinformatik an der FernFH''', das er 2012 abschloss. Im Anschluss absolvierte er die '''Masterstudiengänge Wirtschaftsinformatik an der FernFH sowie Information Management and IT Security an der FH Technikum Wien''', die er 2014 erfolgreich beendete.
Von November 2014 bis 2024 war Peter Völkl als '''wissenschaftlicher Mitarbeiter an der FernFH''' tätig. Ab Juli 2016 übernahm er die '''Studiengangsleitung des Masterstudiengangs Wirtschaftsinformatik''' und leitete seit 2023 zudem das '''Institut für Informationstechnologie und Wirtschaftsinformatik'''.
Seit Oktober 2024 ist er '''Kaufmännischer Leiter der Blutspendezentrale für Wien, Niederösterreich und Burgenland''' im '''Österreichischen Roten Kreuz'''.
 </div>

Datei:Völkl Peter 2024-054 klein.jpg

2025-03-11T20:21:44Z

VÖLKL Peter:

Computer- und Netzwerksicherheit

2025-02-03T05:16:58Z

VÖLKL Peter:

[[Computer- und Netzwerksicherheit - Gesamt|Computer- und Netzwerksicherheit - Gesamt (Achtung - immer die aktuellste Version!)]]

'''Version für das Sommersemester 2025'''

[[Special:PermanentLink/5584|Computer- und Netzwerksicherheit - Grundlagen|Computer- und Netzwerksicherheit - Grundlagen]]

[[Special:PermanentLink/2157|Computer- und Netzwerksicherheit - Bewusstseinsbildung|Computer- und Netzwerksicherheit - Bewusstseinsbildung]]

[[Special:PermanentLink/2278|Computer- und Netzwerksicherheit - Kryptograhpie|Computer- und Netzwerksicherheit - Kryptograhpie]]

[[Special:PermanentLink/2711|Computer- und Netzwerksicherheit - Zugriffssteuerung|Computer- und Netzwerksicherheit - Zugriffssteuerung]]

[[Special:PermanentLink/2280|Computer- und Netzwerksicherheit - Netzwerksicherheit|Computer- und Netzwerksicherheit - Netzwerksicherheit]]

Benutzer:VÖLKL Peter

2025-02-03T05:15:49Z

VÖLKL Peter:

<div>[[file:Voelkl_mittel.jpg|300x150px|left|thumb|Peter Völkl]]'''Peter Völkl''' (''Jahrgang 1984'') startete seine berufliche Laufbahn nach dem Abschluss seiner Ausbildung an der '''HTBLuVA für EDV und Organisation''' im Jahr 2005 als '''Softwareentwickler beim Österreichischen Roten Kreuz'''. 2008 übernahm er die Leitung einer Abteilung der Blutspendezentrale für Wien, Niederösterreich und Burgenland, die für die '''IT-Services des Blutbereichs''' verantwortlich war. Neben der Führung der Abteilung lagen seine Schwerpunkte in der '''Koordination und Überwachung von IT-Projekten und -Prozessen''' sowie in der '''Entwicklung, Testung und Validierung von IT-Systemen'''.Parallel zu seiner beruflichen Tätigkeit begann er 2010 das '''Bachelorstudium Wirtschaftsinformatik an der FernFH''', das er 2012 abschloss. Im Anschluss absolvierte er die '''Masterstudiengänge Wirtschaftsinformatik an der FernFH sowie Information Management and IT Security an der FH Technikum Wien''', die er 2014 erfolgreich beendete.Von November 2014 bis 2024 war Peter Völkl als '''wissenschaftlicher Mitarbeiter an der FernFH''' tätig. Ab Juli 2016 übernahm er die '''Studiengangsleitung des Masterstudiengangs Wirtschaftsinformatik''' und leitete seit 2023 zudem das '''Institut für Informationstechnologie und Wirtschaftsinformatik'''.Seit Oktober 2024 ist er '''Kaufmännischer Leiter der Blutspendezentrale für Wien, Niederösterreich und Burgenland''' im '''Österreichischen Roten Kreuz'''. </div>

Frontend Development

2024-09-30T16:38:52Z

VÖLKL Peter:

[[Frontend Development in 2024 - Gesamt|Frontend Development - Gesamt]]

Frontend Development

2024-09-30T16:38:33Z

VÖLKL Peter:

[[Frontend Development - Gesamt|Frontend Development in 2024 - Gesamt]]

Informatik und IT

2024-09-30T16:32:59Z

VÖLKL Peter:

[[Einführung in Computational Intelligence und AI|Einführung in Computational Intelligence und AI]]

[[Webserver Infrastructures|Webserver Infrastructures]]

[[Cloud Computing Security|Cloud Computing Security]]

[[KI in der Wirtschaft|KI in der Wirtschaft]]

Cloud Computing Security

2024-09-06T10:21:32Z

VÖLKL Peter:

[[Grundlagen und Architektur des Cloud Computing|Grundlagen und Architektur des Cloud Computing]]

[[Sicherheitsfragen bei der Nutzung von Cloud-Diensten|Sicherheitsfragen bei der Nutzung von Cloud-Diensten]]

[[Private und Public Cloud Security|Private & Public Cloud Security]]

[[Virtualisierungssicherheit|Virtualisierungssicherheit]]

[[Sicherheitsempfehlungen für Cloud-Systeme|Sicherheitsempfehlungen für Cloud-Systeme]]

Web Development

2024-06-17T13:06:08Z

VÖLKL Peter:

[[Einführung in PHP und Webentwicklung|Einführung in PHP und Webentwicklung]] [[Datenbankintegration (Webdevelopment)|Datenbankintegration]]

[[Entwicklung in E-Commerce-Plattformen|Entwicklung in E-Commerce-Plattformen]]

Web Development

2024-06-17T13:05:24Z

VÖLKL Peter: Die Seite wurde neu angelegt: „Einführung in PHP und Webentwicklung Datenbankintegration Entwicklung in E-Commerce-Plattformen“

Einführung in PHP und Webentwicklung
Datenbankintegration
Entwicklung in E-Commerce-Plattformen

Advanced Topics in Web Software Engineering

2024-06-17T13:04:43Z

VÖLKL Peter:

[[Architektur-Design für Webanwendungen|Architektur-Design für Webanwendungen]] [[Version Control und Zusammenarbeit|Version Control und Zusammenarbeit]] [[DevOps and Continuous Integration Continuous Deployment|DevOps und Continuous Integration/Continuous Deployment (CI/CD)]] [[Testing und Qualitätssicherung (Webdevelopment)|Testing und Qualitätssicherung]] [[Performance-Optimierung (Webdevelopment)|Performance-Optimierung]]

Advanced Topics in Web Software Engineering

2024-06-17T13:02:50Z

VÖLKL Peter: Die Seite wurde neu angelegt: „Architektur-Design für Webanwendungen Version Control und Zusammenarbeit DevOps und Continuous Integration/Continuous Deployment (CI/CD) Testing und Qualitätssicherung Performance-Optimierung“

Architektur-Design für Webanwendungen
Version Control und Zusammenarbeit
DevOps und Continuous Integration/Continuous Deployment (CI/CD)
Testing und Qualitätssicherung
Performance-Optimierung

Web Software Quality Assurance

2024-06-11T15:33:07Z

VÖLKL Peter:

[[Testplanung und Teststrategie|Testplanung und Teststrategie]] [[Testdesign und Testfälle|Testdesign und Testfälle]] [[Testautomatisierung|Testautomatisierung]] [[Testdurchführung und Berichterstattung|Testdurchführung und Berichterstattung]] [[Werkzeuge für Qualitätssicherung von Web-Software|Werkzeuge für Qualitätssicherung von Web-Software]]

Web Software Quality Assurance

2024-06-11T15:32:29Z

VÖLKL Peter: Die Seite wurde neu angelegt: „Testplanung und Teststrategie Testdesign und Testfälle Testautomatisierung Testdurchführung und Berichterstattung Werkzeuge für Qualitätssicherung von Web-Software“

Testplanung und Teststrategie
Testdesign und Testfälle
Testautomatisierung
Testdurchführung und Berichterstattung
Werkzeuge für Qualitätssicherung von Web-Software

Webserver Infrastructures

2024-06-11T15:25:36Z

VÖLKL Peter:

[[Webserver Grundlagen|Webserver Grundlagen]] [[Lastausgleich und Skalierbarkeit|Lastausgleich und Skalierbarkeit]] [[Leistungsoptimierung (Webserver)|Leistungsoptimierung]] [[Hochverfügbarkeit und Ausfallsicherheit (Webserver)|Hochverfügbarkeit und Ausfallsicherheit]]

Webserver Infrastructures

2024-06-11T15:24:36Z

VÖLKL Peter: Die Seite wurde neu angelegt: „Webserver Grundlagen Lastausgleich und Skalierbarkeit Leistungsoptimierung Hochverfügbarkeit und Ausfallsicherheit“

Webserver Grundlagen
Lastausgleich und Skalierbarkeit
Leistungsoptimierung
Hochverfügbarkeit und Ausfallsicherheit

Frontend Development

2024-06-11T15:16:27Z

VÖLKL Peter:

[[Wiederholung Webentwicklungstechnologien|Wiederholung Webentwicklungstechnologien]] [[Grundlagen der JavaScript-Programmierung|Grundlagen der JavaScript-Programmierung]] [[Document Object Model|Document Object Model (DOM)]] [[JavaScript-Frameworks und -Bibliotheken|JavaScript-Frameworks und -Bibliotheken]] [[Asynchrone Programmierung und Datenübertragung|Asynchrone Programmierung und Datenübertragung]] [[Responsive Webdesign und Barrierefreiheit|Responsive Webdesign und Barrierefreiheit]] [[Leistungsoptimierung (Frontend Development)|Leistungsoptimierung]]

Frontend Development

2024-06-11T15:14:28Z

VÖLKL Peter: Die Seite wurde neu angelegt: „Wiederholung Webentwicklungstechnologien Grundlagen der JavaScript-Programmierung Document Object Model (DOM) JavaScript-Frameworks und -Bibliotheken Asynchrone Programmierung und Datenübertragung Responsive Webdesign und Barrierefreiheit Leistungsoptimierung“

Wiederholung Webentwicklungstechnologien
Grundlagen der JavaScript-Programmierung
Document Object Model (DOM)
JavaScript-Frameworks und -Bibliotheken
Asynchrone Programmierung und Datenübertragung
Responsive Webdesign und Barrierefreiheit
Leistungsoptimierung

Cloud Computing Security

2024-06-11T06:07:41Z

VÖLKL Peter:

[[Grundlagen und Architektur des Cloud Computing|Grundlagen und Architektur des Cloud Computing]]

[[Sicherheitsfragen bei der Nutzung von Cloud-Diensten|Sicherheitsfragen bei der Nutzung von Cloud-Diensten]]

[[Private und Public Cloud Security|Private & Public Cloud Security]]

[[Sicherheitsempfehlungen für Cloud-Systeme|Sicherheitsempfehlungen für Cloud-Systeme]]

[[Virtualisierungssicherheit|Virtualisierungssicherheit]]

Cloud Computing Security

2024-06-11T06:07:15Z

VÖLKL Peter:

[[Grundlagen und Architektur des Cloud Computing|Grundlagen und Architektur des Cloud Computing]]

[[Sicherheitsfragen bei der Nutzung von Cloud-Diensten|Sicherheitsfragen bei der Nutzung von Cloud-Diensten]]

[[Private &amp; Public Cloud Security|Private & Public Cloud Security]]

[[Sicherheitsempfehlungen für Cloud-Systeme|Sicherheitsempfehlungen für Cloud-Systeme]]

[[Virtualisierungssicherheit|Virtualisierungssicherheit]]

Cloud Computing Security

2024-06-11T06:05:45Z

VÖLKL Peter: Die Seite wurde neu angelegt: „Grundlagen und Architektur des Cloud Computing Sicherheitsfragen bei der Nutzung von Cloud-Diensten Private & Public Cloud Security Sicherheitsempfehlungen für Cloud-Systeme Virtualisierungssicherheit“

Grundlagen und Architektur des Cloud Computing
Sicherheitsfragen bei der Nutzung von Cloud-Diensten
Private & Public Cloud Security
Sicherheitsempfehlungen für Cloud-Systeme
Virtualisierungssicherheit

Computer- und Netzwerksicherheit - Zugriffssteuerung

2024-04-04T06:26:47Z

VÖLKL Peter:

= Zugriffssteuerung =

Die Zugriffssteuerung (Access Control) regelt den Zugriff und die Kommunikation von IT-Systemen mit ihren Anwendern, Ressourcen und anderen IT-Systemen. Es handelt sich dabei um eine zentrales Element der meisten IT-Systeme, da davon alle Schutzziele (Vertraulichkeit, Integrität und Verfügbarkeit; siehe Lektion "[[Computer- und Netzwerksicherheit_-_Grundlagen#S%C3%A4ulen_der_Informationssicherheit_-_CIA_Triade|Säulen der Informationssicherheit - CIA Triade]]") betroffen sein können.

In dieser Lektion werden die grundlegenden Begriffe der Zugriffssteuerung erläutert und weiter die konkreten Techniken der Zertifikate und der Fernzugriffe sowie potentielle Angriffsvektoren näher behandelt.

== Grundbegriffe der Zugriffssteuerung ==

Um die Schutzziele der Vertraulichkeit, Integrität und Verfügbarkeit des Datenaustausches mit IT-Systemen gewährleisten zu können müssen die jeweiligen Anforderungen an die Kommunikation definiert werden. Dabei gibt es einige wesentliche Begriffe, welche oft auch von Technikern falsch verwendet werden. Beispielsweise werden ''Identifikation'', ''Authentifikation'' und ''Autorisation'' manchmal fälschlicherweise als Akronyme verwendet, obwohl es sich dabei um grundlegend unterschiedliche Begriffe handelt. Auch ist es wichtig zu wissen, wie bestimmte Anforderungen an die Zugriffssteuerung implementiert werden können.

=== Zugriff ===

Beim Zugriff handelt es sich um die Kommunikation mit einem IT-System. Diese kann sowohl mit einem Anwender, als auch mit einem anderen IT-System oder seiner Ressourcen stattfinden. In den meisten Fällen gibt es dabei Anforderungen an Identifikation, Authentifikation und Autorisation, sowie an die Nachverfolgbarkeit und Nichtabstreitbarkeit (siehe weiter auch Lektion "[[Computer- und Netzwerksicherheit_-_Kryptograhpie#Kryptographie|Krypotgraphie]]" Unterkapitel 2 - 5).

Ressourcen können dabei alle Komponenten sein, welche einen Zugriff auf Daten ermöglichen oder diese beinhalten, wie beispielsweise: Datenbanken, Tabellen und Dateien. Die Zugriffe können dabei sowohl über lokale Verbindungen, als auch über das Netzwerk/Internet oder unterschiedliche Datenträger erfolgen.

=== Identifikation ===

Die Identifikation bezeichnet die Benennung eines bestimmten Systems oder einer Person, welche auf ein System zugreifen möchte. Dabei ist weder sichergestellt durch wen diese Benennung erfolgt ist, noch ob es sich bei der Benennung tatsächlich um das benannte System oder die benannte Person handelt.

Zur Identifikation dienen oft die eindeutige User-ID, die E-Mailadresse oder der Name.

Ein Beispiel ist eine Anwesenheitsliste: Die Protokollführung schreibt die Namen der anwesenden Personen auf, welche diese wiederum identifizieren. Dabei ist jedoch noch nicht sichergestellt, ob die jeweiligen Personen tatsächlich die sind, die sie vorgeben zu sein. Im schlechtesten Fall sind sie der Protokollführung nicht bekannt und identifizieren sich durch Nennung ihres Namens.

=== Authentifikation ===

Die eindeutige Identifikation einer Person oder eines Systems wird als Authentifikation bezeichnet. Erst dadurch wird sichergestellt, dass es sich dabei tatsächlich um die Identifizierten handelt.

Es gibt drei unterschiedliche Kategorien von Authentifikationsmethoden und -merkmale:

* '''Wissen''' (was jemand weiß),
* '''Besitz''' (was jemand besitzt) und
* '''Biometrie''' (was jemand ist).
Die drei Merkmale Wissen, Besitz und Biometrie werden oft auch als „Wissen, Haben und Sein“ bezeichnet.

Eine häufig eingesetzte Methode ist das Passwort. Dieses ist in der Kategorie des '''Wissens''' eingeordnet, da es von jedem eingesetzt werden kann, der es kennt. Es kann daher auch weitergegeben oder ausgespäht werden. Je komplexer es ist, desto leichter kann es auch vergessen werden. Je häufiger es verwendet wird, desto schneller kann es herausgefunden werden. Zu komplexe Passwörter sind daher keine gute Lösung zur sicheren Authentifikation, da sie von vielen Usern vergessen oder aufgeschrieben werden. Dasselbe gilt für zu einfache Passwörter, da sie leicht erraten werden können.

Beim Merkmal des '''Besitzes''' wird die Authentifikation über etwas erreicht, dass nur der zu Authentifizierende besitzt. Beispiele dafür sind ein Personalausweis oder eine Chipkarte (z.B. eine Bankomatkarte). Damit die Weitergabe dieses Merkmals überhaupt nicht, oder nur sehr schwierig möglich ist, sollte es möglichst nicht vervielfältigt werden können.

Unter '''Biometrie''' werden Merkmale verstanden, die an eine bestimmte Person (oder ein bestimmtes System) gebunden sind. Sie sind öffentlich sichtbar oder beobachtbar, jedoch nicht leicht duplizierbar. Häufig bekannte Beispiele für biometrische Merkmale sind Fingerabdrücke, Venenmuster, die Iris-Muster der Augen und Stimmmuster. Weitere, oft weniger bekannte, Merkmale sind jedoch auch die Art des Ganges einer Person, ihre Tastenanschläge, ihr Schreibstil und aber auch die Art und Weise wie sie sich innerhalb eines Programmes oder einer Webseite bewegen.

Je nach Sicherheitsanforderungen können dabei auch mehrere Merkmale kombiniert werden um die Authentifizierungsqualität noch weiter zu verstärken. Ein bekanntes Beispiel dafür ist die zur Bargeldbehebung mittels Bankomatkarte notwendige Authentifizierung. Dabei wird ein Besitzmerkmal (Bankomatkarte) mit einem Wissensmerkmal (PIN-Code) kombiniert. Ist jemand im Besitz der Karte, benötigt er zusätzlich noch den PIN-Code und umgekehrt. Mit einem der beiden Merkmale allein kann keine gültige Authentifikation erfolgen und damit auch kein Geld behoben werden.

Werden zwei Merkmale kombiniert, wird dies auch als '''Zwei-Faktor-Authentifizierung''' bezeichnet. Wichtig ist dabei immer, dass zwei Merkmale unterschiedlicher Kategorien (Wissen, Besitz und Biometrie) kombiniert werden. Die Kombination zweier Merkmale derselben Kategorie, erhöht zwar die Sicherheit, gilt dabei jedoch nicht als Zwei-Faktor-Authentifizierung. Die einzelnen Merkmalskategorien und die sich daraus ergebenen Authentifizierungslevel sind weiter in Abbildung "Authentifizierungsfaktoren: Wissen, Besitz und Biometrie" dargestellt.

Ob die Authentifizierungsqualität durch den Einsatz von drei Faktoren weiter stark erhöht werden kann, ist umstritten. Dies ist stark von den jeweils eingesetzten Techniken, aber auch von deren Akzeptanz bei den Anwendern, abhängig.

[[Datei:IT244 15.png|300px|none|thumb| Authentifizierungsfaktoren: Wissen, Besitz und Biometrie]]


=== Autorisation ===

Bei der Autorisation handelt es sich um die Berechtigung, die eine authentifizierte Person oder ein authentifiziertes System für einen bestimmten Zugriff hat. So können in einem System beispielsweise unterschiedliche Rollen existieren, welche wiederum unterschiedliche Zugriffe ermöglichen. Wie ein System unterschiedliche Autorisationen verwaltet und behandelt wird als [[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Zugriffssteuerungsmodelle|Zugriffssteuerungsmodell]] bezeichnet.

Die Authentifikation stellt damit sicher, dass es sich um jemand bestimmten handelt und die Autorisation regelt wiederum welche bestimmten Rollen welche Zugriffe bekommen.

=== Nachverfolgbarkeit und Nichtabstreitbarkeit ===

Bei der Nachverfolgbarkeit und Nichtabstreitbarkeit handelt es sich um Zugriffsmerkmale, welche eine genaue Dokumentation der jeweiligen Systemkommunikation ermöglichen. Je nach Anforderung wird dabei dokumentiert, welche Zugriffe stattgefunden haben und unter welchen (Sicherheits-)Parametern diese aufgebaut wurden. Um eine lückenlose Nachverfolgbarkeit sicherzustellen, ist es erforderlich, den Erfolg der Authentifikation und die erteilte Autorisation zu dokumentieren.

In manchen Fällen ist es weiter erforderlich eine Nichtabstreitbarkeit von Zugriffen zu ermöglichen. Als '''Nichtabstreitbarkeit''' wird bezeichnet, das eine Person die Erstellung einer gesendeten Nachricht nicht mehr abstreiten kann. Dies beinhaltet auch automatisch die Integrität der Nachricht. Es muss daher für eine Nichtabstreitbarkeit auch sichergestellt sein, dass die Nachricht nicht mehr verändert wurde, da anderenfalls der Absender behaupten könnte, ursprünglich eine andere Nachricht erstellt zu haben.

Die Nichtabstreitbarkeit kann mit Hilfe asymmetrischer Kryptographie Methoden sichergestellt werden (siehe Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie"). Dabei wird der Hashwert einer Nachricht mit dem privaten Schlüssel des Absenders verschlüsselt. Zur Prüfung der Integrität (ob die Nachricht der abgesendeten Nachricht entspricht), muss nun nur noch der verschlüsselte Hashwert mit dem öffentlichen Schlüssel entschlüsselt und mit dem aktuellen Hashwert der Nachricht verglichen werden. Da die Verschlüsselung nur vom Besitzer des privaten Schlüssels durchgeführt werden kann, ist hier eine Nichtabstreitbarkeit gewährleistet.

=== Zugriffssteuerungsmodelle ===

Zugriffssteuerungsmodelle (Access Control Models) regeln die Art und Weise von Zugriffen. Sie definieren dabei die möglichen Regeln und Ziele der Zugriffe und stellen diese den jeweiligen Zugriffssteuerungstechnologien zur Verfügung. Die Modelle sind ein wesentlicher Bestandteil des jeweiligen Betriebssystems, da sie grundlegende Entscheidungen der internen Zugriffe beeinflussen. Sie sind daher direkt im Kern des Betriebssystems integriert. [Ha13, 219]

Es wird zwischen drei verschiedenen Kategorien von Zugriffssteuerungsmodellen unterschieden:

* Eigner-definierte Zugriffssteuerung (DAC: Discretionary Access Control),
* Obligatorische Zugriffssteuerung (MAC: Mandatory Access Control) und
* Rollenbasierte Zugriffssteuerung (RBAC: Role Based Access Control).
Da eine gleichzeitige Unterstützung mehrerer Modelle meist nicht sinnvoll realisierbar ist, ist die Modellauswahl eine grundlegende Entscheidung für das IT-System. Das am häufigsten anzutreffende Modell ist das der Eigner-definierten Zugriffssteuerung.

'''Eigner-definierte Zugriffssteuerung'''

Bei der Eigner-definierten Zugriffssteuerung haben alle Daten einen definierten Eigner (oft auch als Besitzer bezeichnet). Dieser ist fest mit den Daten oder der Datei verbunden. Der Eigner definiert, welche Personen oder Systeme Zugriff auf die Daten erhalten und in welcher Form (z.B.: lesen, schreiben, ändern, ausführen oder verweigern).

Die Zugriffsberechtigungen sind dabei meist über Access Control Lists (ACL‘s) definiert. Dabei handelt es sich um eine Auflistung aller Berechtigten und der jeweils zugeordneten Rechte.

Dieses Modell ist in aktuellen Windows-, Linux- und Mac-Systemen anzutreffen. In diesen Systemen hat jede Datei einen Besitzer und eine entsprechende ACL zugeordnet.

Einzelne User und Systeme können hier meist in Berechtigungsgruppen zusammengefasst werden. In diesem Fall können die ACL’s sowohl Zuordnungen einzelner User und Systeme, als auch Berechtigungsgruppen enthalten.

'''Obligatorische Zugriffssteuerung'''

Die obligatorische Zugriffssteuerung findet ihre Anwendung in Bereichen mit sehr hohem Sicherheitsbedarf. Sie kommt daher meist in behördlichen und militärischen Systemen zum Einsatz.

In diesem Modell ist keine individuelle Behandlung einzelner User und Dateien vorgesehen. Der Zugriff ist abhängig von unterschiedlichen Sicherheitsstufen, auf denen sich Daten und User befinden. Meist ist dabei eine Änderung von Dateiberechtigungen durch die User nicht möglich.

Die Umsetzung der Sicherheitsstufen erfolgt durch Vertrauens-Levels (Clearance) für User und Sensitivitäts-Labels für Dateien. Mögliche Sicherheitsstufen wären z.B.: nicht vertraulich, vertraulich, geheim und streng geheim.

Der Zugriff auf Daten erfolgt gemäß den jeweiligen Sicherheitsstufen. Sind die Stufe der Datei und die Stufe des Users ident, darf er auf die Daten zugreifen. Ob er auf Daten von darunterliegenden Stufen zugreifen darf, kann unterschiedlich implementiert sein. Meist dürfen Informationen nur von niedrigeren Levels zu höheren Levels übertragen werden und nicht umgekehrt. Zugriffe zwischen unterschiedlichen Levels werden dabei meist auch von eigenen Überwachungsdienstprogrammen gesteuert und genehmigt.

Zusätzlich werden meist hierarchische Zuordnungen vergeben, in denen sich sowohl Daten, als auch User befinden können. Die hierarchische Zuordnung steht dann nochmals über der Zuordnung des Sicherheitslevels. Damit ist sichergestellt, dass die Zugriffe nicht nur gemäß des Vertrauens-Levels, sondern auch gemäß der Zugriffs-Notwendigkeit erfolgen. Befindet sich ein User nicht in derselben hierarchischen Zuordnung, wie die jeweiligen Daten, wird davon ausgegangen, dass er keinen Zugriff benötigt und der Zugriff daher verweigert.

Ein frei verfügbares Betriebssystem, welches das Modell der obligatorischen Zugriffssteuerung einsetzt, ist beispielsweise SE Linux [Na09].

'''Rollenbasierte Zugriffssteuerung'''

Bei der rollenbasierten Zugriffssteuerung werden Organisationsrichtlinien und -abläufe in ein Zugriffsmodell übersetzt. Dabei werden einzelnen Usern oder Systemen bestimmte (Organisations-)Rollen zugeordnet. Der Zugriff auf Daten hängt dabei von der jeweiligen Rolle des Zugreifenden ab. Die Berechtigung wird bei jedem Zugriffsversuch überprüft und dann genehmigt oder abgewiesen.

Bei den hier eingesetzten Rollen handelt es sich nicht um Gruppen im Sinne der Eigner-definierten Zugriffssteuerung, sondern um Rollen innerhalb des jeweiligen Geschäftsprozesses bzw. einer Organisationseinheit. So kann ein User eine Rolle haben, die ihm aus einer Anwendung heraus Zugriff auf einen Datensatz gestattet und aus einer anderen Anwendung nicht mehr, obwohl es sich um denselben Datensatz handelt. Wichtig ist dabei immer die Betrachtung des aktuellen Zwecks des Zugriffes.

Die Implementierung rollenbasierter Zugriffssteuerungen ist daher auch komplexer als die der Eigner-definierten Zugriffssteuerung.

== Passwortsicherheit ==

Wie bereits in der Lektion zu [[Computer- und_Netzwerksicherheit_-_Kryptograhpie|Kyptographie]] beschrieben, hat die sichere Speicherung von Passwörtern eine hohe Priorität und sollte in einer entsprechend sicheren Architektur erfolgen. Zusätzlich zur technischen Sicherheit ist eine entsprechende '''Passwortkomplexität von besonderer Relevanz'''. Ein noch so effizient abgesicherter Passwortspeicher verliert an Bedeutung, wenn das darin gespeicherte Passwort selbst unsicher ist.

Ein unsicheres Passwort hat entweder:

* eine zu geringe '''Komplexität''' und kann daher durch [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Bruteforce]]- oder [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Hash-Kollisions-Angriffe]] gefunden werden, oder
* kann durch '''[[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]''' herausgefunden werden (z.B.: Name des Kindes mit Jahreszahl, Anfangsbuchstaben des Titels des Lieblingsliedes, usw.).
Die Komplexität eines Passwortes ergibt sich aus der '''Entropie''' – also den möglichen unterschiedlichen Kombinationen bzw. dem [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Schl%C3%BCssel_(Key)_und_Keyspace|Keyspace]]. Daraus und an der Anzahl an Passwörtern, welche pro Sekunde geprüft werden können, ergibt sich dann wiederum die Dauer, in welcher das Passwort durch Ausprobieren (Bruteforce-Angriff) gefunden werden kann.

Für die Komplexität von Passwörter galt lange eine bestimmte Mindestlänge (meist 8 Zeichen) und eine Kombination aus den Merkmalen:

* Kleinbuchstaben,
* Großbuchstaben,
* Ziffern und
* Sonderzeichen
als ausreichender Schutz.

Beispielsweise ein Passwort '''„''f9D22+P#''“''' mit 8 Zeichen und Erfüllung aller oben genannten Kriterien hat somit folgende Komplexität:

* 26 Kleinbuchstaben +
* 26 Großbuchstaben +
* 10 Ziffern +
* 36 Sonderzeichen (alle Sonderzeichen der deutschen Tastatur)
* '''= 98 Mögliche Zeichen pro Stelle'''.
* '''Bei 8 Zeichen sind das 98^8 mögliche Passwortkombinationen.'''
Ein Hochleistungs-PC, welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''23 Tage''' um das Passwort herauszufinden.

Ein Problem solcher komplexen Passwörter ist, dass es für die meisten User schwierig ist, sie sich zu einzuprägen. Dadurch besteht ein erhöhtes Risiko, dass die Passwörter:

* vergessen werden,
* auf einem Zettel notiert werden,
* nicht ausreichend oft geändert werden oder
* nur minimal geändert werden – beispielsweise durch simple Variation einzelner Teile des Passwortes, wie einer Ziffer am Ende.
Aufgrund der oben genannten Schwächen und der dennoch geringen Entropie noch gut merkbarer Passwortlängen, können diese Passwortrichtlinien '''nicht mehr als Stand der Technik''' betrachtet werden. Eine wesentlich bessere Möglichkeit ist die Nutzung von zufälligen Wörtern aus dem Wörterbuch. [Ga17]

Bei der Nutzung von '''vier zufälligen Wörtern aus dem Wörterbuch''' (kein Satz, sondern tatsächlich zufällig gewählte Wörter), ergibt sich bei Nutzung der 100.000 unterschiedlichen Wörter des Österreichischen Wörterbuchs [AF20] folgende Komplexität:

* '''100.000 mögliche Wörter pro „Stelle“ (ein Wort ist somit eine Stelle).'''
* '''Bei 4 Wörtern sind das 100.000^4 mögliche Passwortkombinationen.'''
Ein Hochleistungs-PC (der selbe PC wie im ersten Beispiel), welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''738 Jahre''' um das Passwort herauszufinden.

Ein Beispiel für ein Passwort aus 4 unzusammenhängenden Wörtern aus dem deutschen Duden ist: '''„''Dachs faul logisch Gerät''“'''.

Das Passwort weißt somit eine '''wesentlich höhere Entropie''' auf und ist für einen Menschen gleichzeitig '''leichter merkbar'''.

Leider ist diese Form der Passwörter in '''vielen Systemen noch nicht implementiert''' und es werden noch die veralteten Komplexitätsmerkmale des ersten Beispiels abgerufen. Diese Hürde kann ganz einfach überwunden werden, indem am Ende des Passworts eine Ziffer und ein Sonderzeichen gestellt werden. Da diese keine wirkliche Relevanz für die genannte Passwortsicherheit haben, können hier auch Zeichen genutzt werden, die schnell zu tippen sind. Das oben genannte Passwort könnte damit dann einfach '''''„Dachs faul logisch Gerät 9+“''''' lauten.

== Zertifikate ==

Zertifikate dienen der Feststellung der Identitäten von Personen und Systemen auf digitalem Wege. Ein Zertifikat ist ein digitales Dokument, indem bestimmte Daten angegeben sind, welche eine Person oder ein System und optional auch zugehörige Eigenschaften identifizieren. Zertifikate sind wesentliche Bestandteile von Public-Key-Systemen und enthalten zusätzlich den jeweiligen Public-Key des Zertifikatsinhabers (siehe auch Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie").

Um die Echtheit eines Zertifikats zu bestätigen, kann dieses von anderen Stellen signiert werden. Diese Stellen werden als '''Zertifizierungsstellen (CA: Certification Authority)''' bezeichnet. Die Signatur erfolgt dabei, wie in Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" beschrieben, durch hashen des Zertifikates und Verschlüsselung des Hashwertes durch den privaten Schlüssel der Zertifizierungsstelle. Da der öffentliche Schlüssel – wiederum durch das Zertifikat der Zertifizierungsstelle – bekannt ist, kann der Hashwert korrekt entschlüsselt, und die Signatur damit als gültig erkannt, werden.

Ob diese Echtheitsbestätigungen nun '''hierarchisch''' erfolgen ([[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Public-Key-Infrastruktur_(PKI)|Public-Key-Infrastruktur]]), oder über ein dezentral '''verteiltes Vertrauensmodell''' ([[Computer- und Netzwerksicherheit_-_Zugriffssteuerung#Web_of_Trust_(WOT)|Web of Trust]]) ist von der jeweiligen Implementierung abhängig. Derzeit sind beide Modellvarianten im Einsatz und finden ihre Anwendung in einer Vielzahl von Systemen. Die Zertifikate der behördlich akzeptierten digitalen Signaturen basieren derzeit auf dem hierarchischen Modell der Public-Key-Infrastruktur.

Ein Zertifikat ist mit einem Ausweisdokument vergleichbar. Auf dem Ausweis befinden sich die Daten der Person und ein Verweis auf den Aussteller. Durch Sicherheitsmerkmale am Dokument (Wasserzeichen, Silberstreifen,…) wird dabei die Echtheitsprüfung ermöglicht. Der Aussteller (z.B. eine Behörde) bestätigt damit die Identität des Inhabers (z.B. Personalausweis) und gegebenenfalls auch bestimmte durch das Dokument erlaubte Tätigkeiten (z.B. Führerschein).

Die Echtheit eines Zertifikates kann von der jeweiligen Zertifizierungsstelle auch wieder zurückgezogen werden. Zu diesem Zweck werden '''Zertifikats-Sperrlisten (CRL: Certificate Revocation Lists)''' eingesetzt, welche Einträge der Seriennummern aller Zertifikate mit zurückgenommenen Echtheitsbestätigungen enthält. Die Sperrliste ist selbst wiederum von der jeweiligen Zertifizierungsstelle signiert, um ihre Echtheit zu bestätigen.

Der Aufbau und der mögliche Inhalt eines Zertifikates ist im '''X.509 Standard''' [Ne99] definiert. Ein entsprechendes Beispiel (das aktuelle Zertifikat des Online-Campus) ist in Abbildung "Zertifikat" dargestellt.

[[Datei:IT244 16.png|300px|none|thumb|Zertifikat]]


=== Public-Key-Infrastruktur (PKI) ===

Bei der Public-Key-Infrastruktur (PKI) handelt es sich um ein hierarchisch aufgebautes System von Zertifizierungsstellen. Das bedeutet, dass jede Zertifizierungsstelle das in sie gesetzte Vertrauen an nachfolgende Stellen weiterverteilen kann, indem sie die zugehörigen Zertifikate signiert.

Daraus ergibt sich dann eine Hierarchie aus mehreren Zertifikaten, die bis zu einem Stammzertifikat rückverfolgt werden können sind. Durch das Vertrauen in das jeweilige Stammzertifikat wird auch den nachfolgenden Zertifikaten vertraut.

In den meisten Anwendungen, die PKI Zertifikate einsetzen (z.B. Internetbrowser für HTTPS Verbindungen), sind bereits einige gängige Stammzertifikate der großen Zertifizierungsstellen vorinstalliert. Es ist jedoch meist auch möglich weitere Stammzertifikate hinzuzufügen, denen dann ebenfalls vertraut wird. In Abbildung "Zertifizierungspfad" ist die Hierarchie des Zertifikates des Online-Campus dargestellt. Die Stammzertifizierungsstelle ist in diesem Fall das Unternehmen Go Daddy.

[[Datei:IT244 17.png|300px|none|thumb|Zertifizierungspfad]]


Zusätzlich zu den Zertifizierungsstellen gibt es in der PKI noch weitere Instanzen, welche hautsächlich für den Zertifizierungsprozess verantwortlich sind. Die Hauptakteure der PKI sind:

* Zertifizierungsstelle (CA: Certification Authority),
* Registrierungsstelle (RA: Registration Authority) und
* Validierungsdienst (VA: Validation Authority)
Die '''Registrierungsstelle''' ist in der PKI dafür verantwortlich die Identität des Antragsstellers zu überprüfen und dies wiederum der Zertifizierungsstelle mitzuteilen. Die '''Validierungsstelle''' ist für die Gültigkeitsprüfung von bereits ausgestellten Zertifikaten verantwortlich. Sie verwaltet auch die Zertifikats-Sperrlisten und ihre Erreichbarkeit ist meist in einem Datenfeld in den Zertifikaten selbst angegeben.

Soll nun ein neues Zertifikat ausgestellt werden, muss folgender '''Zertifizierungsprozess''' durchlaufen werden:

# Der Antrag für das neue Zertifikat wird an die Registrierungsstelle (RA) geschickt
# Die Registrierungsstelle (RA) überprüft den Antrag und stellt sicher, dass es sich bei der Identität tatsächlich um die der antragstellenden Person oder des zugehörigen IT-Systems (z.B. bei einem Webserver-Zertifikat) handelt.
# Wenn die Registrierungsstelle die Identität bestätigen kann, sendet sie den Antrag weiter an die Zertifizierungsstelle (CA).
# Die Zertifizierungsstelle (CA) stellt nun das beantragte Zertifikat aus, generiert dafür einen privaten und einen öffentlichen Schlüssel und sendet diese an die antragsstellende Person.
Oft ist es auch möglich das Schlüsselpaar selbst zu generieren und dem Antrag nur den öffentlichen Schlüssel beizufügen. Dies ist für die Ausstellung des Zertifikates ausreichend, da der private Schlüssel für seine Signierung nicht benötigt wird (diese wird durch den privaten Schlüssel der CA durchgeführt). In diesem Fall ist zusätzlich sichergestellt, dass der private Schlüssel nur der antragsstellenden Person bekannt ist.

Gerade bei der Überprüfung durch die Registrierungsstelle gibt es unterschiedliche Qualitäten. Wird hier ungenau vorgegangen, kann dies zu Zertifikaten falscher Identitäten führen.

=== Web of Trust (WOT) ===

Das Modell des Web of Trust ist im Gegensatz zur PKI nicht hierarchisch, sondern dezentral aufgebaut. Es basiert auf einer dezentralen Vertrauensverteilung zwischen den Teilnehmern, ähnlich dem Freundes- und Bekanntenkreis einer Person. Die Schlüssel sind dabei nicht in einer hierarchischen Struktur zentral abrufbar und überprüfbar, sondern werden direkt von den Benutzern verwaltet. Jeder User hat seinen eigenen Schlüsselbund, wobei hier zwischen dem privaten und dem öffentlichen Schlüsselbund unterschieden wird.

Am '''privaten Schlüsselbund''' befinden sich die privaten Schlüssel des Users, mit denen Daten signiert und entschlüsselt werden können. Am '''öffentlichen Schlüsselbund''' befinden sich die eigenen öffentlichen Schlüssel, sowie die öffentlichen Schlüssel anderer User. Mit den öffentlichen Schlüsseln können Nachrichten verschlüsselt und Signaturen geprüft werden.

Die Vertrauensstufen werden über die öffentlichen Schlüssel der Teilnehmer ermittelt. Dazu gibt es im öffentlichen Schlüsselbund für jeden Schlüssel ein '''Key Legimitation Field''', in dem der jeweilige '''Vertrauensgrad (Owner Trust)''' des Schlüssels angegeben wird.

Im WOT gibt es folgende Vertrauensgrade:

* unknown: Personen über die keine Informationen bekannt sind,
* not trusted: Personen denen nicht vertraut wird,
* marginal: Personen denen nicht voll vertraut wird,
* complete: Personen denen voll vertraut wird und
* ultimate: eigener öffentlicher Schlüssel.
Wer als vertrauenswürdig eingestuft wird, liegt somit beim jeweiligen Schlüsselbund Inhaber.

Die Vertrauensgrade können an andere User (z.B. über einen Schlüsselserver) weitergegeben werden, indem die jeweiligen Schlüssel durch den eigenen privaten Schlüssel signiert werden. Dies wird auch als '''indirekte Zertifizierung''' bezeichnet.

Ist dem User, der einen dritten Schlüssel signiert hat, im eigenen Schlüsselbund einem Vertrauensgrad zugewiesen, so erhält der von ihm signierte Schlüssel je nach eigener Einstellung denselben Vertrauensgrad oder niedriger. Zusätzlich kann definiert werden, wie viele signierte Schlüssel eines niedrigeren Vertrauensgrades notwendig sind, um die Vertrauensstufe um eine Stufe aufzuwerten. Die Standartwerte hierfür sind 3 signierte Schlüssel anderer User für die Aufwertung und ein signierter Schlüssel eines anderen Users für dieselbe Stufe.

Diese Abhängigkeiten sind in Abbildung "Web of Trust - Vertrauensnetzwerk" ersichtlich: Anna kennt sowohl Peter, als auch Christoph persönlich und hat daher ihre öffentlichen Schlüssel in ihrem öffentlichen Schlüsselbund abgelegt. Christoph hat nur eine direkte Beziehung zu Anna, nicht aber zu Peter. Da sich Christophs öffentlicher Schlüssel im öffentlichen Schlüsselbund von Anna befindet, erkennt Peter sein Zertifikat als gültig an.

[[file:img1643193688517.png|300px|alt=Web of Trust - Vertrauensnetzwerk|none|thumb|Web of Trust - Vertrauensnetzwerk]]

Die erste Implementierung des WOT war '''Pretty Good Privacy (PGP)''' [Sy15]. Es ist ein Softwarepaket, welches die Sicherstellung der Authentizität, Integrität und Vertraulichkeit von E-Mails sowie beliebiger Dateien ermöglicht. '''GnuPG''' [Gn15] ist die frei verfügbare Version, die unter der GNU General Public License [Fr07] steht. Ein möglicher Windows Client für GnuPG ist beispielsweise Gpg4win [In15b].

=== Neue Zertifikatsmodelle und Erweiterungen ===

Sowohl im Bereich des PKI, als auch im WOT Modell, gibt es mittlerweile einige bekannte Sicherheitslücken und Protokollfehler. Weiter ist gerade im PKI Modell die Rolle der CA enorm wichtig. Werden hier nur schlechte Identitätskontrollen bei der Ausstellung von Zertifikaten durchgeführt, kann es zu falschen validen Identitäten kommen. Im Bereich des WOT können beispielsweise die Schlüsselserver zum Generieren von SPAM-Versandlisten genutzt werden, da die zugehörigen E-Mailadressen der Zertifikate dort frei verfügbar sein müssen. Weiter sind über die WOT soziale Netzwerke der User analysierbar, da die Trustlevel und ihre Abhängigkeiten leicht analysiert werden können. [Br14]

Um diese Schwachstellen zu beseitigen wird bereits an möglichen neuen Protokollen und Erweiterungen geforscht. Den meisten Ansätzen gemein ist, die Abhängigkeit von einzelnen CA’s zu verringern. Fehler einer CA sollen möglichst auf Seite der Endanwendung (wie z.B. im Browser oder Mail Client) frühzeitig erkannt und angezeigt werden. [Br14]

Einer dieser neuen Ansätze ist die Software ''Perspectives'' [Ca15]. Dabei handelt es sich um eine Browsererweiterung, die jedes Zertifikat zusätzlich mit einem sogenannten Notary-Server abgleicht. Damit können beispielsweise Man-in-the-Middle Angriffe frühzeitig erkannt werden.

Weitere aktuelle Erweiterungen sind [Br14]:

* Pinning [EPS14],
* Certificate Transparency [LLK13],
* Microsoft SmartScreen [Mi15] und
* DANE [HVS12].

== Angriffsvektoren der Access Control ==

Die Angriffsmethoden der Access Control sind sehr vielfältig und haben oft [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffsvektoren_der_Kryptographie|Angriffsvektoren der Kryptographie]] und [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Angriffsvektoren_der_Daten%C3%BCbertragung|Datenübertragung]], sowie [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]als Grundlage. Dies trifft insbesondere auf Angriffe gegen die Integrität und Authentizität zu.

Dazu bereits behandelte Angriffsvektoren sind:

* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Brute-Force Angriffe]],
* [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Phishing|Phishing]] und
* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Angriffe gegen Hashwerte]].
Eine weitere wichtige Angriffsmethode ist die des '''Pharming.''' Dabei wird die Anfrage eines Users auf einen bösartigen Server umgeleitet. Er glaubt sich sicher und gibt dann dort seine geheimen Daten ( wie z.B.: Zugangsdaten und Transaktionsdaten) preis. Beim Pharming handelt es sich daher um einen [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Man-in-the-Middle_Angriff|Man-in-the-Middle Angriff]].

== Wiederholungsaufgaben/Übungen ==

'''1 Was ist der Unterschied zwischen Identifikation, Authentifikation und Autorisation?'''

'''2 Was ist eine Zwei-Faktor-Authentifikation?'''

'''3 Welche drei Zugriffssteuerungsmodelle gibt es?'''

'''4 Erklären Sie das Modell der Eigner-definierten Zugriffssteuerung.'''

'''5 Was sind Zertifikate und die damit verbundenen Vertrauensmodelle?'''

'''6 Was bedeutet PKI und wer sind ihre Hauptakteure? Wie hängen diese Akteure zusammen?'''

'''7 Eine Passwortrichtlinie fordert ein Passwort, bestehend aus Kleinbuchstaben, Großbuchstaben und Ziffern mit einer Länge von 10 Zeichen. Wie wird die Komplexität des Passworts berechnet (wie viele mögliche Passwörter gibt es)?'''

Computer- und Netzwerksicherheit - Kryptograhpie

2024-03-19T13:37:15Z

VÖLKL Peter:

= Kryptographie =

Bei der Kryptographie handelt es sich um Methoden, Daten in eine Form zu bringen, in der Sie nur von denen gelesen werden können, die dazu berechtigt sind. Für alle anderen sollen die Daten während ihrer Übermittlung und Speicherung unlesbar sein.

Die Kryptographie hat ihren bekannten Ursprung in den Jahren um 2000 v. Chr. Die Ägypter nutzten Hieroglyphen um Grabkammern zu dekorieren und die Lebensgeschichte des Verstorbenen zu erzählen. Das Augenmerk lag dabei jedoch nicht in der Unkenntlichmachung der Informationen sondern darin, sie durch die bildhafte Darstellungsform zeremoniell und majestätisch wirken zu lassen. [Ha13, 760]

Eine der ersten Methoden mit der Absicht einen Text unkenntlich zu machen, war die hebräische '''Atbash''' Methode. Dabei wurde als Schlüssel jedem Buchstaben im Alphabet ein anderer Buchstabe zugewiesen. Ein Beispiel für einen Schlüssel wären demnach die folgenden beiden Zeilen [Ha13, 760]:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

ZYXWVUTSRQPONMLKJIHGFEDCBA

Damit könnte nun beispielsweise der Text „KRYPTO“ zum Text „PIBKGL“ verschlüsselt werden, indem der Buchstabe des ursprünglichen Textes in der ersten Zeile des Schlüssels nachgesehen und dann durch den jeweiligen Buchstaben der zweiten Zeile ersetzt wird. Zur Entschlüsselung wird dieselbe Technik umgekehrt angewendet, indem der Buchstabe des verschlüsselten Textes in der zweiten Zeile gesucht und dann durch den jeweiligen Eintrag der ersten Zeile ersetzt wird.

Ein weiterer historisch erfolgreicher Algorithmus ist der '''Cäsar-Algorithmus'''. Er wurde in der Zeit der gallischen Kriege von Julius Cäsar entwickelt und eingesetzt um vertrauliche Nachrichten zu übermitteln, ohne dem Nachrichtenboten vertrauen zu müssen. Das Prinzip des Cäsar- Algorithmus ist simpel. Jeder Buchstabe der Nachricht wird um eine bestimmte Anzahl an Stellen im Alphabet nach hinten verschoben, wobei beim Erreichen des letzten Buchstaben Z wieder mit dem ersten Buchstaben A weitergezählt wird. Die Anzahl der Buchstaben, um die die Nachricht verschoben wird, wird dabei meist als Teil des Algorithmus Namens angegeben. So sind bei einer Cäsar 5 Verschlüsselung die Buchstaben der Nachricht um 5 Stellen verschoben und bei einer Cäsar 15 Verschlüsselung um 15 Stellen.

Der Text „KRYPTO“ wird durch Anwendung einer Cäsar 5 Verschlüsselung zu „PWDUYT“. Dabei wird auch deutlich, dass beim Verschieben des Buchstaben Y zum Buchstaben D, nach Erreichen von Z wieder mit A begonnen wird.

Der Cäsar-Algorithmus ist aus heutiger Sicht auch von Nicht-Kryptographen leicht zu knacken. Aus damaliger Sicht war es jedoch ein sehr sicheres Verfahren, da der Bildungsgrad der Bevölkerung nicht sehr hoch war und viele nicht schreiben und lesen konnten.

Eine deutliche Verbesserung des Cäsar-Algorithmus würde im 16. Jahrhundert von Blaise de Vigenere entwickelt und deshalb auch als '''Vigenere-Algorithmus''' bezeichnet. Dabei wird nicht mehr jeder Buchstabe um eine bestimmte Anzahl von Zeichen verschoben, sondern ein Schlüssel definiert, der die jeweilige Verschiebung der einzelnen Buchstaben bestimmt. Im nachfolgenden Beispiel wird ein Text mit Hilfe des Schlüssels „KRYPTO“ verschlüsselt.

Klartext: '''DIETA'''UBEISTA'''UFDEMD'''ACH

Schlüssel: '''KRYPTO'''KRYPTO'''KRYPTO'''KRY

Verschlüsselt: '''NZCIT'''ILVGHMO'''EWBTFR'''KTF

Der Schlüssel wird für die gesamte Länge der Nachricht immer wieder wiederholt. Im Beispiel befindet sich der Buchstabe D bei seinem ersten vorkommen im Text unter dem Buchstaben K des Schlüssels und wird daher um 10 Zeichen verschoben und somit zu einem N. Bei seinem zweiten Vorkommen befindet sich das D der Nachricht jedoch unter dem Y des Schlüssels und wird daher zu einem B.

Um den Abstand zwischen dem Zeichen der Nachricht und dem Zeichen des Schlüssels schneller manuell ermitteln zu können wird oft eine Tabelle eingesetzt, in der alle möglichen Abstandskombinationen aufgelistet sind. Diese wird als Vigenere-Tabelle bezeichnet und ist in Abbildung "Vigenere-Tabelle" zu sehen.

[[Datei:IT244 7.png|300px|none|thumb|Vigenere-Tabelle]]


In dieser Lektion werden nun weiter die Grundbegriffe der Kryptographie, ihre wesentlichen Methoden und mögliche Angriffsvektoren genauer behandelt.

== Wesentliche Begriffe der Kryptographie ==

In der Kryptographie gibt es einige wichtige Grundbegriffe. Sie dienen der Beschreibung der Methoden und den unterschiedlichen Stadien von Ver- und Entschlüsselung. Diese Begriffe sind nun nachfolgend beschrieben.

=== Klartext (Plaintext) ===

Beim Klartext handelt es sich um die unverschlüsselte Nachricht, die übertragen werden soll. Solange sich die Nachricht in diesem Zustand befindet kann sie von jedem gelesen werden, der Zugriff auf sie hat.

=== Geheimtext (Ciphertext) ===

Dabei handelt es sich um eine verschlüsselte Klartext Nachricht. Sie ist in diesem Zustand nicht lesbar. Jeder, der in den Besitz des Geheimtextes kommt muss den zugehörigen Algorithmus und Schlüssel kennen um die Nachricht wieder in den Klartext umwandeln zu können.

=== Chiffre (Cipher / Algorithmus) ===

Die zur Ver- und Entschlüsselung eingesetzte Methode und der zugehörige Algorithmus werden als Chiffre (Cipher) bezeichnet. Sie verarbeitet einen Plaintext mit Hilfe des Keys zu Ciphertext und umgekehrt. Dabei handelt es sich um eine Ansammlung von Umwandlungen der Zeichen (oder Bits) des Textes.

Es gibt '''bekannte''' und '''unbekannte''' Chiffren. Alle gängig eingesetzten Chiffren sind hinlänglich ihrer genauen Funktionsweise bekannt. Die Stärke der Chiffre ist von wesentlicher Bedeutung für die Sicherheit. Die Unbekannte ist dabei immer der Schlüssel. Ein wesentlicher Vorteil von bekannten Chiffren ist die große Anzahl an Nutzern und der Möglichkeit sie öffentlich zu analysieren und zu testen. Damit werden gefundene Schwachstellen meist schnell veröffentlicht und behoben. Dass die Sicherheit eines kryptographischen Verfahrens im Wesentlichen in der Geheimhaltung des Schüssels und nicht in der des Ciphers liegt, ist die wesentliche Aussage von [[#Security by_Obscurity_und_das_Kerckhoffs%E2%80%99sche_Prinzip|Kerckhoff‘s Prinzip]].

Unbekannte Chiffren werden meist von Nachrichtendiensten eingesetzt. Ihr Vorteil liegt darin, dass ein möglicher Angreifer nicht nur den Schlüssel, sondern auch die Chiffre herausfinden muss, um die Nachricht lesen zu können. Der wesentliche Nachteil ist das Fehlen einer breiten Anwenderschicht und die damit verbundenen Reviews und Tests. Es muss daher sehr viel Aufwand in die Entwicklung und Testung der Chiffre gesteckt werden, um mögliche Sicherheitslücken identifizieren zu können.

Bei den Chiffren wird zwischen '''''[[#Symmetrische Verfahren|symmetrischen ]] '''und''' '''''[[#Asymmetrische Verfahren|asymmetrischen ]]Algorithmen unterschieden.

=== Schlüssel (Key) und Keyspace ===

Der '''Schlüssel''' wird von der Chiffre verwendet um Variabilität und Unregelmäßigkeiten in den Algorithmus zu bringen. Damit soll sichergestellt werden, dass dieselbe Chiffre, angewendet auf denselben Klartext, durch den Einsatz unterschiedlicher Schlüssel zu unterschiedlichen Geheimtexten führt. Somit ist der Schlüssel das wesentliche, geheim zuhaltende, Element.

Welche möglichen Schlüssel für eine Chiffre angewendet werden können, wird durch den '''Keyspace''' definiert. Dieser enthält alle möglichen Schlüssel. Je größer der Keyspace ist, desto mehr unterschiedliche Schlüssel existieren. Je mehr mögliche Schlüssel auf eine Chiffre anwendbar sind, desto aufwändiger wird es für einen Angreifer eine Nachricht durch bloßes Ausprobieren unterschiedlicher Schlüssel zu entschlüsseln.

Der Cäsar Algorithmus hat beispielsweise einen Keyspace von 26 möglichen Schlüsseln, da es genauso viele Buchstaben im lateinischen Alphabet gibt. Ein Angreifer würde durch einfaches durchprobieren daher maximal 26 Versuche benötigen, wobei die Verwendung des Schlüssels A sehr unwahrscheinlich ist, da der Text damit gleich bleiben würde.

Aktuelle Cipher haben hingegen wesentlich größere Keyspaces. Beispielsweise hat [[#Aktuelle Kryptographie-Standards_mit_symmetrischen_Methoden|AES256]] eine Schlüssellänge von 256 Bit. Daraus ergibt sich ein Keyspace von 2256 möglichen Schlüsseln. Da ein Angreifer durch zufälliges durchprobieren einen Schlüssel in der Regel nach der Hälfte der möglichen Kombinationen errät, muss er hier ca. (2256)/2 = 2255 Versuche durchführen.

=== Verschlüsselung (Encryption) / Entschlüsselung (Decryption) ===

Bei der '''Verschlüsselung''' handelt es sich um die Umwandlung von Klartext in Geheimtext mittels zugehöriger Chiffre und Schlüssel und bei der '''Entschlüsselung''' um die Umwandlung des Geheimtextes zurück in den Klartext.

Der Ablauf eines Weges vom Klartext über den Geheimtext zurück zum Klartext ist in Abbildung "Zusammenhang der Kryptographie Begriffe" noch einmal grafisch dargestellt.

[[Datei:IT244 8.png|300px|none|thumb|Zusammenhang der Kryptographie Begriffe]]


== Security by Obscurity und das Kerckhoffs’sche Prinzip ==

Ein kryptographisches System lässt sich durch die bloße Geheimhaltung der zugehörigen Chiffre nicht gewährleisten. Dieser Versuch wird auch als '''Security by Obscurity''' bezeichnet, da hier davon ausgegangen würde, dass alleine die Unwissenheit über die Methodik der Chiffre zu mehr Sicherheit führt. Dadurch ergeben sich jedoch einige wesentliche Probleme. Die geringe Anzahl an eingeweihten Anwendern entdeckt Fehler des Ciphers spät bis überhaupt nicht. Sobald die geheime Chiffre jedoch bekannt wird, ist jede durch ihre Geheimhaltung erreichte Sicherheit gebrochen. Wurde dann nicht auf eine ausreichende Geheimhaltung und Komplexität der Schlüssel geachtet hat wird das gesamte System unbrauchbar.

Kerkhoff entwickelte 1883 die Grundprinzipien sicherer Verschlüsselung, welche bis heute Bestand haben. Einer dieser Grundsätze wird heute als das '''Kerhoffs‘sche Prinzip''' bezeichnet. Es besagt, dass nicht das System selbst, sondern der Schlüssel geheim sein muss, um eine maximale Sicherheit zu erreichen. Der Algorithmus soll immer öffentlich bekannt sein. Der Schlüssel muss dabei unbedingt geheim gehalten werden. Je mehr unterschiedliche Geheimnisse rund um ein kryptographisches System nötig sind, umso verwundbarer ist es gegenüber möglichen Angriffen, welche Teile der Geheimnisse herausfinden. [Ha13, 767]

Auch wenn das Kerhoffs‘sche Prinzip besagt, dass die Sicherheit alleinig in der Geheimhaltung des Schlüssels liegt, so hat Security by Obscurity doch auch manchmal ihre Berechtigung. So kann beispielsweise durch die Kombination mehrerer bekannter Verfahren eine Unregelmäßigkeit hergestellt werden, welche möglichen Angreifern eine Analyse erschwert und damit eine erste Hürde darstellt, die überwunden werden muss.

Eine bekannte Anwendung ist das sogenannte „Salzen“ von Hashwerten. Dabei wird dem Plaintext vor der Hashwertberechnung ein zusätzlicher Teil („Salt“) hinzugefügt. Gelingt es einem Angreifer nun anhand der Hashwerte mögliche Ausgangswerte zu konstruieren, kann er den Ursprungswert nur durch das zusätzliche Wissen des „Salts“ rekonstruieren. Die berechneten Werte sind somit unbrauchbar.

== Symmetrische Verfahren ==

Bei einem symmetrischen kryptographischen Verfahren (Chiffre) wird ein Klartext mit ein und '''demselben Schlüssel''' verschlüsselt und auch wieder entschlüsselt (siehe Abbildung "Symmetrische Verfahren mit einem Schlüssel"). Bei symmetrischen Verfahren werden '''Substitutions-Methoden''' und '''Transpositions-Methoden''' angewendet, um den Klartext unkenntlich zu machen. Diese können innerhalb der Chiffre natürlich auch beliebig kombiniert werden.

[[Datei:IT244 9.png|300px|none|thumb|Symmetrische Verfahren mit einem Schlüssel]]


=== Substitutions-Methoden ===

Bei der Substitution handelt es sich um die Umwandlung eines Zeichens (oder Bits) durch ein anderes. Dies wären beispielsweise bei einem Cäsar 5 Algorithmus das Ersetzen des Zeichen K durch das Zeichen P zur Verschlüsselung und das Ersetzen des Zeichens P durch das Zeichen K zur Entschlüsselung. Der Schlüssel ist hierbei der Wert 5, welcher die Zuordnung des jeweiligen Zielzeichens ermöglicht.

Ein Beispiel auf Bit-Ebene ist die einfache XOR Verknüpfung des Schlüssels mit dem Text, welche ebenfalls in beide Richtungen anwendbar ist:

Klartext: 010010110101001001011001

Schlüssel: 010000010100001001000011

Geheimtext: 000010100001000000011010

Die Berechnung des Geheimtextes und des Klartextes ist dabei in beide Richtungen über die Verknüpfung mit dem Schlüssel möglich.

Ist der mittels XOR verknüpfte Schlüssel:

* gleich lang wie die Nachricht,
* zufällig generiert und
* wird dieser nur ein einziges Mal verwendet,
wird dies als '''One-Time-Pad''' bezeichnet. Diese Methode ist, ohne den Schlüssel in Besitz zu bekommen, definitiv unknackbar und damit die sicherste kryptographische Methode. Die Herausforderung besteht hierbei darin den Schlüssel sicher zu übermitteln, da dieser gleich lang wie die Nachricht sein muss. Dies ist meist nur sehr umständlich machbar und mit einem ähnlichen Aufwand verbunden, wie die Übermittlung der Nachricht selbst. One-Time-Pads werden daher eher zur Übermittlung kleinerer, hoch sensibler, Datenmengen eingesetzt. Sie könnten jedoch an Bedeutung gewinnen, da eine sichere Übermittlung von größeren Schlüsseln mittels Quantentechnologien immer praxistauglicher wird.

=== Transpositions-Methode ===

Bei der Transposition werden einzelne Teile des Textes mit anderen Teilen vertauscht. Der Schlüssel gibt dabei an, welcher Teil mit welchem vertauscht werden soll.

Ein Beispiel für eine einfache Transpositions-Methode ist in Abbildung "Transpositions-Cipher" dargestellt. Dabei wird der Plaintext zuerst in Gruppen zerlegt. Diese Gruppen werden nun gemäß dem Schlüsselwert intern neu angeordnet und ergeben dann in Summe wiederum den Ausgabetext. Auch diese Methode ist in beide Richtungen – sowohl zur Ver-, als auch zur Entschlüsselung – anwendbar.

[[Datei:IT244 10.png|300px|none|thumb|Transpositions-Cipher]]


=== Aktuelle Kryptographie-Standards mit symmetrischen Methoden ===

In der nachfolgenden Tabelle "Gängige Standards mit symmetrischen Algorithmen" sind die aktuell gängigsten symmetrischen Chiffren und ihre Eckpunkte aufgelistet.

Tabelle: Gängige Standards mit symmetrischen Algorithmen

{| style="border-collapse: collapse;" border="1"
! width="34%" | Standard Name
! width="34%" | Algorithmus
! width="31%" | Schlüssellängen
|-
| Data Encryption Standard (DES)
| Data Encryption Algorithm (DEA)
| 56 Bit Schlüssel 
(+8 Bit Parität = 64Bit)
|-
| Triple-DES (3DES)
| Triple Data Encryption Algorithm (TDEA)
| 112 Bit
|-
| Advanced Encryption Standard (AES)
| Rijndael
|
128 Bit

192 Bit

256 Bit
|-
| International Data Encryption Algorithm (IDEA)
| International Data Encryption Algorithm (IDEA)
| 128 Bit
|-
| Blowfish
| Blowfish
| Variable Länge zwischen 32 und 448 Bit
|-
| RC4
| RC4
| Variable Länge
|}

== Asymmetrische Verfahren ==

Bei asymmetrischen Verfahren werden zur Verschlüsselung und Entschlüsselung einer Nachricht '''zwei unterschiedliche Schlüssel''' verwendet. Die beiden Schlüssel gehören dabei immer zusammen und bilden ein '''Schlüsselpaar''' (siehe Abbildung "Asymmetrische Verfahren mit zwei unterschiedlichen Schlüsseln"). Es ist somit nicht möglich eine Nachricht mit demselben Schlüssel zu entschlüsseln, mit dem sie verschlüsselt wurde. Es kann dabei jeder der beiden Schlüssel zur Verschlüsselung einer Nachricht eingesetzt werden. Zur Entschlüsselung wird dabei immer der jeweils andere Schlüssel benötigt.

[[Datei:IT244 11.png|300px|none|thumb|Asymmetrische Verfahren mit zwei unterschiedlichen Schlüsseln]]


Dies ist auch vergleichbar mit einem Vorhängeschloss und einem Schlüssel. Das Schloss kann eingesetzt werden um eine Kiste zu versperren. Ohne den zugehörigen Schlüssel kann das Schloss jedoch nicht mehr geöffnet werden. Im Fall der asymmetrischen Verschlüsselung ist jeder der beiden Schlüssel gleichzeitig das Schloss des jeweils anderen Schlüssels:

* Key 1 = Schloss 2 (kann von Key 2 geöffnet werden)
* Key 2 = Schloss 1 (kann von Key 1 geöffnet werden)
Die beiden Schlüssel werden als '''Public-Key''' und '''Private-Key''' bezeichnet. Diese Bezeichnungen beruhen darauf, dass einer der beiden Schlüssel immer privat – also nur einer bestimmten Person bekannt – sein sollte. Der andere Schlüssel kann dann öffentlich an alle weitergegeben werden, die Nachrichten an den Besitzer des Private-Keys schicken wollen. Er ist somit public.

Will nun jemand eine Nachricht an den Besitzer des Private-Keys übermitteln kann er nun den dazu den '''Public-Key für die Verschlüsselung''' verwenden. Da die Nachricht nur mit dem zugehörigen Private-Key entschlüsselt werden kann, kann sie auch nur von dessen Besitzer gelesen werden. Der Public-Key ist zwar öffentlich verfügbar, jedoch zur Entschlüsselung der Nachricht nicht verwendbar.

Diese Methode kann nun auch umgekehrt verwendet werden um eine Nachricht durch den Besitzer des '''Private-Keys zu''' '''signieren'''. Dabei wird meist ein [[#Hashing|Hashwert]] der Nachricht generiert, die signiert werden soll. Dieser Hashwert wird nun mit dem Private-Key verschlüsselt und an die Nachricht angehängt. Will nun ein Empfänger prüfen, ob die Nachricht tatsächlich vom Besitzer des Private-Keys stammt, muss er nur den Hashwert mit dem öffentlich verfügbaren Public-Key entschlüsseln und mit dem aktuellen Hashwert der empfangenen Nachricht vergleichen. Sind die beiden Hashwerte ident, ist somit sichergestellt, dass die Nachricht vom Besitzer des Private-Keys stammen muss, da nur er den Hashwert korrekt verschlüsseln konnte. Würde sie auf dem Weg zum Empfänger verändert worden sein, wären die Hashwerte unterschiedlich.

Asymmetrische Methoden basieren auf komplexen mathematischen Berechnungen und sind vergleichsweise langsam. Sie werden daher meist nicht für die Verschlüsselung der Nachricht, sondern nur für die Verschlüsselung eines Schlüssels für die Anwendung einer symmetrischen Methode verwendet. Damit ist sichergestellt, dass der Schlüssel sicher übertragen wird und gleichzeitig eine schnellere Ver- und Entschlüsselung der übrigen Nachricht, mittels symmetrischer Methoden, erfolgen kann.

Eine weit verbreitete asymmetrische Methode wurde 1977 von Ronald L. '''R'''ivest, Adi '''S'''hamir und Leonard '''A'''dleman entwickelt und trägt daher den Namen '''RSA'''. Sie ist eine Weiterentwicklung des Diffie-Hellmann [[#Schl%C3%BCsseltauschverfahren|Schlüsseltauschverfahrens]]. Genauso wie dieses basiert sie auf dem Einsatz von '''[[#Schl%C3%BCsseltauschverfahren|Einwegfunktionen]]'''. Das Schlüsselpaar wird bei RSA durch den Einsatz sehr großer Primzahlen generiert, wobei die Anwendung des ersten Schlüssels die Nachricht unkenntlich macht und die zusätzliche Anwendung des zweiten Schlüssels die Anwendung des ersten Schlüssels wieder aufhebt. Der zugehörige zweite Schlüssel der Einwegfunktion ist nur durch Primfaktorzerlegungen sehr großer Primzahlen berechenbar. Dies ist jedoch ein sehr rechen- und damit zeitaufwändiger Vorgang.

Eine weiter asymmetrische Methode ist die der '''E'''lliptic '''C'''urve '''C'''ryptographie ('''ECC'''). Sie basiert auf der Berechnung von Punkten entlang einer elliptischen Kurve in einem zweidimensionalen Koordinatensystem. Dabei werden eine bestimmte Kurve und ein Startpunkt angegeben. Das Schlüsselpaar ergibt sich dann durch die Koordinaten eines Zielpunkts und der Anzahl der nötigen Schritte, die nötig sind, um vom Startpunkt aus zu ihm zu gelangen. Ähnlich der Berechnung der Multiplikation zweier Primzahlen ist und der Schwierigkeit einer Rückrechnung mittels Primfaktorzerlegung ist es einfach einen Punkt auf der Kurve zu berechnen, jedoch schwierig die Anzahl der nötigen Schritte zu ermitteln, die nötig sind um zu diesem Punkt zu gelangen. Ein Beispiel einer solchen Elliptic Curve ist in Abbildung "Elliptic Curve" dargestellt.

Die ECC Methoden sind stärker als die herkömmlichen asymmetrischen Methoden. Sie können sehr gut als performante Hardwarekomponenten implementiert werden und eignen sich daher besonders für den Einsatz in mobilen Endgeräten mit geringer Rechenleistung.

[[Datei:IT244 12.png|300px|none|thumb|Elliptic Curve]]


== Schlüsseltauschverfahren ==

Eine wesentliche Herausforderung der verschlüsselten Datenübertragung ist der Schlüsseltausch. Es muss daher eine Methode gefunden werden den nötigen Schlüssel zur Entschlüsselung der Nachricht an den Empfänger zu übermitteln, ohne dass dieser abgefangen werden kann. Würde der Schlüssel einfach vor der Übermittlung einer Nachricht übertragen werden, dann könnte ein möglicher Angreifer sowohl den Schlüssel, als auch den verschlüsselte Nachricht abfangen und dann beides gemeinsam einsetzen und die Nachricht einfach entschlüsseln.

Um dieses Problem zu lösen gibt es einige Methoden, die daher auch als Schlüsseltauschverfahren bezeichnet werden.

Die erste veröffentlichte mögliche Schlüsseltausch-Methode wurde 1976 von Diffie und Hellmann entwickelt. Sie basiert auf dem Einsatz von mathematischen Einwegfunktionen. Eine '''Einwegfunktion''' ist eine Funktion, welche leicht berechnet werden kann, deren Rückrechnung jedoch sehr schwierig ist. Dies lässt sich mit dem Mischen zweier Farbkübel zu vergleichen: Es ist zwar leicht zwei Farben zu mischen, jedoch enorm aufwändig sie wieder in ihre ursprünglichen Farbtöne aufzuteilen (vgl. Abbildung "Einwegfunktion der Farbmischung") und manuell nur durch ausprobieren möglich.

[[Datei:IT244 13.png|300px|none|thumb|Einwegfunktion der Farbmischung]]


Dies macht sich der Diffie-Hellmann Schlüsseltausch nun zu Nutze, indem er mathematische Einwegfunktionen verwendet um einen gemeinsamen und geheimen Schlüssel über eine unsichere Leitung auszutauschen. Die Vorgehensweise ist nachfolgend durch ein Beispiel mit Farbkübeln beschrieben und dann anschließend mathematisch erklärt.

Der Ablauf ist dabei folgendermaßen:

# Beide Teilnehmer vereinbaren eine '''gemeinsame (nicht geheime) Farbe.'''
# Jeder Teilnehmer generiert eine eigene '''geheime Farbe''', nur er selbst kennt.
# Nun '''mischen sie jeweils die geheime Farbe zur gemeinsamen Farbe'''.
# Danach '''übermitteln''' sie sich gegenseitig die '''Mischungen'''.
# Jeder Teilnehmer mischt seine '''eigene geheime Farbe zur empfangenen Mischung''' des anderen. Damit haben nun beide einen Farbkübel mit derselben Mischung aus: '''gemeinsame Farbe + eigene geheime Farbe + geheime Farbe des anderen'''.
# Die gemeinsame Mischung kann nun als Schlüssel für den geheimen Nachrichtenaustausch verwendet werden.
Die einzelnen Schritte des Schlüsseltauschs sind in Abbildung "Ablauf des Diffie-Hellmann Schlüsseltausches" noch einmal bildlich dargestellt. In der rechten Spalte ist ersichtlich welche Informationen ein möglicher Angreifer mithören kann. Er gelangt zwar an die gemeinsame Farbe und an die beiden Mischungen. Es ist ihm jedoch nicht möglich die geheimen Farben zu ermitteln. Damit fehlt ihm auch die Möglichkeit den gemeinsamen Schlüssel herauszufinden.

[[Datei:IT244 14.png|300px|none|thumb|Ablauf des Diffie-Hellmann Schlüsseltausches]]


Mathematisch betrachtet basiert der Diffie-Hellmann Schlüsseltausch auf dem ''diskreten Logarithmus-Problem'' und wird mit Hilfe folgender Formel abgebildet:

''n = gk mod p''

Das ''diskrete Logarithmus-Problem'' beschreibt die Schwierigkeit für gegebene Werte der Variablen ''n'', ''g'' und der Primzahl ''p'' den Wert der Variablen ''k'' zu finden. Bei kleinen Werten ist eine Berechnung von k noch machbar. Je größer sie jedoch werden, desto länger wird die dafür benötigte Zeit, da ein Rückrechnen nur durch Ausprobieren möglich ist. Für jedes zusätzliche Bit des Wertes müssen doppelt so viele Versuche angewendet werden.

Beim Schlüsseltausch sind '''''g''''' und '''''p''''' nun die gemeinsamen Werte (gemeinsame Farbe), welche öffentlich übermittelt werden und '''''n''''' das jeweilige Mischergebnis. '''''k''''' ist dabei der jeweils geheime Wert (eigene geheime Farbe), welcher niemals übermittelt wird.

Um zur gemeinsamen Farbmischung zu kommen macht sich der Schlüsseltausch nun zu Nutze, dass (x a) b gleich (x b)a  und damit x a b ist. Sind a und b nun die beiden geheimen Zahlen können sie zum jeweils anderen Ergebnis hinzugefügt werden, ohne den jeweiligen Exponenten der anderen Seite zu kennen. Übermittelt wird hierbei immer nur das Ergebnis.

Angewendet auf die oben genannte Formel des ''diskreten'' ''Logarithmus-Problems'' ergibt sich nun folgender Ablauf des Schlüsseltauschs:

# Die gemeinsamen Werte für '''''g''''' und '''''p''''' werden übermittelt
# Beide Teilnehmer generieren eine geheime Zahl (Teilnehmer A: '''''a'''''; Teilnehmer B: '''''b''''')
# Sie berechnen nun jeweils aus '''''g, p''''' und ihrer eigenen geheimen Zahl ('''''a''''' bzw. '''''b''''') den Wert zur Übermittlung: 
Teilnehmer A: ''A = ga mod p'' 
Teilnehmer B: ''B = gb mod p''
# Teilnehmer A übermittelt nun den Wert '''''A''''' an Teilnehmer B und Teilnehmer B den Wert '''''B''''' an Teilnehmer A.
# Nun können beide Teilnehmer mit ihrer eigenen geheimen Zahl den gemeinsamen Schlüssel '''''K''''' berechnen: 
Teilnehmer A: ''K = Ba mod p ''Teilnehmer B: ''K = Ab mod p''
# Beide Teilnehmer können nun K zur Verschlüsselung ihrer geheimen Nachrichten verwenden.
Das '''''Ba mod p''''' gleich '''''Ab mod p''''' ist, kann mittels gegenseitigem Einsetzen bewiesen werden:

''K = Ba mod p = (gb mod p)a mod p = gb a mod p''

''K = Ab mod p = (ga mod p)b mod p = ga b mod p''

'''''K = gb a mod p = ga b mod p'''''

Da ein möglicher Angreifer jedoch nur in Besitz der Werte g, p, A und B kommt, kann er den Schlüssel K nur mit enorm hohem Aufwand ermitteln.

Auf dem Grundprinzip von Diffie-Hellmann wurde später mit [[#Asymmetrische Verfahren|RSA]] die asymmetrischen Verschlüsselungsmethoden entwickelt. Die Diffie-Hellmann Methode wurde inzwischen auch um die verstärkte Sicherheit von Elliptic Curves erweitert und findet ihre diesbezügliche Verbreitung unter dem Namen Elliptic Curve Diffie-Helman (ECDH).

== Hashing ==

Beim Hashing handelt es sich um die Anwendung einer '''nicht reversiblen Funktion''', auf einen bestimmten Wert. Das Ergebnis einer Hash-Funktion ist somit nicht auf den Ausgangswert umkehrbar. Dabei wird meist ein Wert variabler Länge zu einem Wert fixer Länge umgewandelt, der dem Ursprungswert nicht mehr ähnelt.

Ein guter Hash-Algorithmus hat möglichst wenige '''Kollisionen'''. Das bedeutet, dass die Wahrscheinlichkeit bei unterschiedlichen Eingangswerten denselben Ausgangswert zu bekommen sehr gering ist.

Das nachfolgende Beispiel in Tabelle "Beispiel Hashfunktion HashMe()" zeigt mögliche Hashwerte einer fiktiven Hashfunktion HashMe(). Die letzten beiden Zeilen sind ein Beispiel einer Kollision.

Tabelle: Beispiel Hashfunktion HashMe()

{| style="border-collapse: collapse;" border="1"
! width="49%" | Eingangswert
! width="28%" | Hashwert = HashMe(Eingangswert)
! width="22%" | 
|-
| Peter
| 0c74c6051287c95d
|
 
|-
|
Guten Tag!

Hiermit nehme ich Ihr Angebot mit der Nummer 12334 an.

Mit freundlichen Grüßen,

Miriam Muster
| 878b87429ff50296
|
 
|-
| Mich gibt es hoffentlich nur einmal!
| ae4692a6f28a03cd
| '''Kollision'''
|-
| 45667533423233467885354
|
ae4692a6f28a03cd
| 
|}
Da ein Hashwert einer bestimmten Nachricht immer gleich ist, eignet er sich sehr gut zur '''Integritätsprüfung'''. Sobald sich ein Teil der Nachricht ändert, ändert sich auch der Hashwert. Das Vorhandensein einer Änderung der Nachricht kann somit einfach durch den Vergleich des Original-Hashwertes und des aktuellen Hashwertes aufgezeigt werden.

Dieses Prinzip wird auch bei '''digitalen Signaturen''' verwendet. Dabei wird ein Hashwert der zu signierenden Nachricht generiert und mit dem [[#Asymmetrische Verfahren|Private-Key]] des Absenders verschlüsselt. Dieser wird der Nachricht dann als Signatur beigefügt. Der Empfänger kann nun den Hashwert mit dem Public-Key entschlüsseln und mit dem aktuellen Hashwert der empfangenen Nachricht vergleichen. Sind die beiden Werte gleich ist sichergestellt, dass:

* sich der Inhalt der Nachricht nicht verändert hat und
* der Besitzer des Private-Key ist auch der Absender der Nachricht ist, da nur er eine Verschlüsselung durchführen kann, welche mit dem zugehörigen Public-Key korrekt entschlüsselt wird.
Da mit Hash-Werten die Integrität von Nachrichten geprüft werden kann, werden diese auch oft als '''Fingerprint''' oder '''Message-Digest''' bezeichnet.

Einige derzeit gängige Hash-Algorithmen sind in Tabelle "Gängige Hash-Algorithmen" aufgelistet.

Tabelle: Gängige Hash-Algorithmen

{| style="border-collapse: collapse;" border="1"
! width="26%" | Standard Name
! width="32%" | Länge des Hash-Wertes
! width="40%" | Anmerkung
|-
| MD4
| 128 Bit
| Optimiert für schnelle Berechnung
|-
| MD5
| 128 Bit
| Komplexerer Algorithmus als MD4 und daher langsamere Berechnung
|-
| SHA
| 160 Bit
| Ähnlich wie MD4
|-
| HAVAL
| Variable Länge
| Ähnlich wie MD5
|-
| Tiger
| 192 Bit
|
Ähnlich wie MD4

Optimiert für 64 Bit Systeme
|}

== Angriffsvektoren der Kryptographie ==

Die möglichen direkten Angriffsvektoren der Kryptographie teilen sich in die, nachfolgend beschriebenen, Kategorien:

* Brute-Force Angriffe,
* Kryptoanalyse und
* Angriffe gegen Hashwerte.
Um die genannten Angriffe ausführen zu können, ist es meist erforderlich den zugehörigen Datenverkehr abzuhören und gegebenenfalls auch zu manipulieren. Dazu werden oft [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Sniffing|Sniffing]]- und [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Man-in-the-Middle_Angriff|Man-in-the-Middle-Attacken]] genutzt.

=== Brute-Force Angriffe ===

Bei Brute-Force Angriffen wird versucht eine Verschlüsselung zu knacken, indem eine '''Vielzahl möglicher Schlüssel ausprobiert''' wird. Dabei steigt mit der Länge der Schlüssel auch die Anzahl der dazu nötigen Versuche (siehe auch [[#Schl%C3%BCssel (Key)_und_Keyspace|Keyspace]]).

Die Stärke einer Chiffre wird daher auch dadurch angegeben, wie lange es dauern würde, durch einen Brute-Force Angriff einen möglichen Schlüssel zu finden.

Um die Möglichkeiten einzuschränken wird daher oft die Methode des '''Wörterbuchangriffs''' eingesetzt. Dabei werden keine beliebigen Schlüssel generiert, sondern stattdessen Einträge eines Wörterbuches bzw. einer Liste häufig eingesetzter Schlüssel (bzw. Passwörter) verwendet. Diese Listen werden meist auch nach der statistischen Häufigkeit der Verwendung der Begriffe gereiht, um die am häufigsten genutzten Passwörter auch zuerst zu versuchen. Die zugehörigen Statistiken werden dabei aus bereits im Internet veröffentlichten oder gestohlenen Passwortlisten generiert.

Da der Aufwand eines Angriffes mit der Länge der verwendeten Schlüssel zunimmt, kann ihm besonders durch den Einsatz langer Schlüssel begegnet werden. Auch ist es wichtig Passwörter zu verwenden, welche nicht durch Wörterbücher und Passwortlisten generiert werden können.

=== Kryptoanalyse ===

Bei der Kryptoanalyse handelt es sich um ein Teilgebiet der Kryptographie. Sie hat zum Gegenstand aus möglichen bekannten Teilen eines kryptographischen Systems (Klartext, Geheimtext, Chiffre) nicht bekannte Teile herauszufinden.

Da der Algorithmus einer Chiffre in der Regel bekannt ist, kann die Kryptoanalyse diesen als Basis verwenden. Um nun den Schlüssel oder den Klartext rekonstruieren zu können, stehen dem Analytiker folgende Analysemethoden zur Verfügung:

* '''Ciphertext-Only''' (der Analyse steht nur der Geheimtext zur Verfügung),
* '''Known-Plaintext''' (der Analyse steht der Geheimtext und der Klartext zur Verfügung),
* '''Chosen-Plaintext''' (der Analyse steht der Geheimtext zur Verfügung und der Klartext kann für die Analyse frei gewählt werden) und
* '''Chosen-Ciphertext''' (der Analyse steht der Klartext zur Verfügung und der Geheimtext kann für die Analyse frei gewählt werden).

=== Angriffe gegen Hashwerte ===

Angriffe gegen Hashwerte haben das Ziel Kollisionen zu finden, die zu einem gesuchten Hashwert führen. Werden beispielsweise Passwörter als Hash gespeichert und kommt ein Angreifender in den Besitz dieser Daten, kann er die Passwörter nicht einfach aus den Werten berechnen, da Hashwerte nicht reversibel sind.

Es ist jedoch möglich (ähnlich wie einem [[#Brute-Force Angriffe|Brute-Force Angriff]]) aus einer Liste von Passwörtern mögliche Hashwerte zu berechnen und diese dann mit den Hashwerten zu vergleichen.

Da diese Listen sehr groß (einige Terrabyte und mehr) werden können und damit auch nur sehr schwer zu durchsuchen sind, wurde die Methode der '''Rainbow-Tables''' entwickelt. Dabei handelt es sich um eine näherungsweise Suche, die mögliche Teilstücke des Hashwerts berechnet. Die Suche erfolgt damit in mehreren Schritten verknüpften Tabellen, ist jedoch wesentlich schneller als die Suche in einer enorm großen Liste. Der Name Rainbow-Tables kommt dabei von einer der ersten grafischen Darstellungen der zugehörigen Methode. Dabei wurden die einzelnen Schritte (Tabellen) in unterschiedlichen Farben dargestellt.

Diesem Angriff kann entgegengewirkt werden, indem die '''Passwortlänge erhöht''' wird und indem der Hashwert bei der Berechnung zusätzlich „gesalzen“ wird. Durch die Erhöhung der Länge wird die nötige Menge der vorausberechnenden Werte entsprechend höher, was einen Angriff auf lange Passwörter entsprechend erschwert. Beim '''Salzen''' wird dem Passwort vor der Hashwertberechnung ein zusätzlicher Wert hinzugefügt. Dieser Wert wird als „Salt“ bezeichnet. Kann dieser Ausgangswert nun mittels Rainbow-Tables ermittelt werden, handelt es sich um den gesalzenen Wert und nicht um das tatsächliche Passwort. Die Angreifenden müssten daher einerseits den Salt kennen und dann sehr aufwändig eine eigene Rainbow-Table generieren, die ebenfalls diesen Salt anhält.

== Wiederholungsaufgaben/Übungen ==

'''1 Erklären Sie den Cäsar-Algorithmus anhand der Verschlüsselung des Wortes '''"'''WIBA'''"''' durch Cäsar 5.'''

'''2 Erklären Sie die Begriffe Klartext, Geheimtext, und Chiffre. Stellen Sie Ihre Zusammenhänge bei der Verschlüsselung und Entschlüsselung grafisch dar.'''

'''3 Erklären Sie den Begriff “Security by Obscurity“? Welches Prinzip spricht dagegen?'''

'''4 Wodurch unterscheiden sich symmetrische und asymmetrische Kryptographie-Verfahren?'''

'''5 Wie läuft der Diffie-Hellmann Schlüsseltausch ab. Erklären Sie ihn anhand eines einfachen Beispiels mit Farbkübeln ODER mathematisch.'''

'''6 Was ist Hashing und wozu wird es eingesetzt?'''

'''7 Was ist ein Brute-Force Angriff?'''

Computer- und Netzwerksicherheit - Kryptograhpie

2024-03-19T13:36:10Z

VÖLKL Peter:

= Kryptographie =

Bei der Kryptographie handelt es sich um Methoden, Daten in eine Form zu bringen, in der Sie nur von denen gelesen werden können, die dazu berechtigt sind. Für alle anderen sollen die Daten während ihrer Übermittlung und Speicherung unlesbar sein.

Die Kryptographie hat ihren bekannten Ursprung in den Jahren um 2000 v. Chr. Die Ägypter nutzten Hieroglyphen um Grabkammern zu dekorieren und die Lebensgeschichte des Verstorbenen zu erzählen. Das Augenmerk lag dabei jedoch nicht in der Unkenntlichmachung der Informationen sondern darin, sie durch die bildhafte Darstellungsform zeremoniell und majestätisch wirken zu lassen. [Ha13, 760]

Eine der ersten Methoden mit der Absicht einen Text unkenntlich zu machen, war die hebräische '''Atbash''' Methode. Dabei wurde als Schlüssel jedem Buchstaben im Alphabet ein anderer Buchstabe zugewiesen. Ein Beispiel für einen Schlüssel wären demnach die folgenden beiden Zeilen [Ha13, 760]:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

ZYXWVUTSRQPONMLKJIHGFEDCBA

Damit könnte nun beispielsweise der Text „KRYPTO“ zum Text „PIBKGL“ verschlüsselt werden, indem der Buchstabe des ursprünglichen Textes in der ersten Zeile des Schlüssels nachgesehen und dann durch den jeweiligen Buchstaben der zweiten Zeile ersetzt wird. Zur Entschlüsselung wird dieselbe Technik umgekehrt angewendet, indem der Buchstabe des verschlüsselten Textes in der zweiten Zeile gesucht und dann durch den jeweiligen Eintrag der ersten Zeile ersetzt wird.

Ein weiterer historisch erfolgreicher Algorithmus ist der '''Cäsar-Algorithmus'''. Er wurde in der Zeit der gallischen Kriege von Julius Cäsar entwickelt und eingesetzt um vertrauliche Nachrichten zu übermitteln, ohne dem Nachrichtenboten vertrauen zu müssen. Das Prinzip des Cäsar- Algorithmus ist simpel. Jeder Buchstabe der Nachricht wird um eine bestimmte Anzahl an Stellen im Alphabet nach hinten verschoben, wobei beim Erreichen des letzten Buchstaben Z wieder mit dem ersten Buchstaben A weitergezählt wird. Die Anzahl der Buchstaben, um die die Nachricht verschoben wird, wird dabei meist als Teil des Algorithmus Namens angegeben. So sind bei einer Cäsar 5 Verschlüsselung die Buchstaben der Nachricht um 5 Stellen verschoben und bei einer Cäsar 15 Verschlüsselung um 15 Stellen.

Der Text „KRYPTO“ wird durch Anwendung einer Cäsar 5 Verschlüsselung zu „PWDUYT“. Dabei wird auch deutlich, dass beim Verschieben des Buchstaben Y zum Buchstaben D, nach Erreichen von Z wieder mit A begonnen wird.

Der Cäsar-Algorithmus ist aus heutiger Sicht auch von Nicht-Kryptographen leicht zu knacken. Aus damaliger Sicht war es jedoch ein sehr sicheres Verfahren, da der Bildungsgrad der Bevölkerung nicht sehr hoch war und viele nicht schreiben und lesen konnten.

Eine deutliche Verbesserung des Cäsar-Algorithmus würde im 16. Jahrhundert von Blaise de Vigenere entwickelt und deshalb auch als '''Vigenere-Algorithmus''' bezeichnet. Dabei wird nicht mehr jeder Buchstabe um eine bestimmte Anzahl von Zeichen verschoben, sondern ein Schlüssel definiert, der die jeweilige Verschiebung der einzelnen Buchstaben bestimmt. Im nachfolgenden Beispiel wird ein Text mit Hilfe des Schlüssels „KRYPTO“ verschlüsselt.

Klartext: '''DIETA'''UBEISTA'''UFDEMD'''ACH

Schlüssel: '''KRYPTO'''KRYPTO'''KRYPTO'''KRY

Verschlüsselt: '''NZCIT'''ILVGHMO'''EWBTFR'''KTF

Der Schlüssel wird für die gesamte Länge der Nachricht immer wieder wiederholt. Im Beispiel befindet sich der Buchstabe D bei seinem ersten vorkommen im Text unter dem Buchstaben K des Schlüssels und wird daher um 10 Zeichen verschoben und somit zu einem N. Bei seinem zweiten Vorkommen befindet sich das D der Nachricht jedoch unter dem Y des Schlüssels und wird daher zu einem B.

Um den Abstand zwischen dem Zeichen der Nachricht und dem Zeichen des Schlüssels schneller manuell ermitteln zu können wird oft eine Tabelle eingesetzt, in der alle möglichen Abstandskombinationen aufgelistet sind. Diese wird als Vigenere-Tabelle bezeichnet und ist in Abbildung "Vigenere-Tabelle" zu sehen.

[[Datei:IT244 7.png|300px|none|thumb|Vigenere-Tabelle]]


In dieser Lektion werden nun weiter die Grundbegriffe der Kryptographie, ihre wesentlichen Methoden und mögliche Angriffsvektoren genauer behandelt.

== Wesentliche Begriffe der Kryptographie ==

In der Kryptographie gibt es einige wichtige Grundbegriffe. Sie dienen der Beschreibung der Methoden und den unterschiedlichen Stadien von Ver- und Entschlüsselung. Diese Begriffe sind nun nachfolgend beschrieben.

=== Klartext (Plaintext) ===

Beim Klartext handelt es sich um die unverschlüsselte Nachricht, die übertragen werden soll. Solange sich die Nachricht in diesem Zustand befindet kann sie von jedem gelesen werden, der Zugriff auf sie hat.

=== Geheimtext (Ciphertext) ===

Dabei handelt es sich um eine verschlüsselte Klartext Nachricht. Sie ist in diesem Zustand nicht lesbar. Jeder, der in den Besitz des Geheimtextes kommt muss den zugehörigen Algorithmus und Schlüssel kennen um die Nachricht wieder in den Klartext umwandeln zu können.

=== Chiffre (Cipher / Algorithmus) ===

Die zur Ver- und Entschlüsselung eingesetzte Methode und der zugehörige Algorithmus werden als Chiffre (Cipher) bezeichnet. Sie verarbeitet einen Plaintext mit Hilfe des Keys zu Ciphertext und umgekehrt. Dabei handelt es sich um eine Ansammlung von Umwandlungen der Zeichen (oder Bits) des Textes.

Es gibt '''bekannte''' und '''unbekannte''' Chiffren. Alle gängig eingesetzten Chiffren sind hinlänglich ihrer genauen Funktionsweise bekannt. Die Stärke der Chiffre ist von wesentlicher Bedeutung für die Sicherheit. Die Unbekannte ist dabei immer der Schlüssel. Ein wesentlicher Vorteil von bekannten Chiffren ist die große Anzahl an Nutzern und der Möglichkeit sie öffentlich zu analysieren und zu testen. Damit werden gefundene Schwachstellen meist schnell veröffentlicht und behoben. Dass die Sicherheit eines kryptographischen Verfahrens im Wesentlichen in der Geheimhaltung des Schüssels und nicht in der des Ciphers liegt, ist die wesentliche Aussage von [[#Security by_Obscurity_und_das_Kerckhoffs%E2%80%99sche_Prinzip|Kerckhoff‘s Prinzip]].

Unbekannte Chiffren werden meist von Nachrichtendiensten eingesetzt. Ihr Vorteil liegt darin, dass ein möglicher Angreifer nicht nur den Schlüssel, sondern auch die Chiffre herausfinden muss, um die Nachricht lesen zu können. Der wesentliche Nachteil ist das Fehlen einer breiten Anwenderschicht und die damit verbundenen Reviews und Tests. Es muss daher sehr viel Aufwand in die Entwicklung und Testung der Chiffre gesteckt werden, um mögliche Sicherheitslücken identifizieren zu können.

Bei den Chiffren wird zwischen '''''[[#Symmetrische Verfahren|symmetrischen ]] '''und''' '''''[[#Asymmetrische Verfahren|asymmetrischen ]]Algorithmen unterschieden.

=== Schlüssel (Key) und Keyspace ===

Der '''Schlüssel''' wird von der Chiffre verwendet um Variabilität und Unregelmäßigkeiten in den Algorithmus zu bringen. Damit soll sichergestellt werden, dass dieselbe Chiffre, angewendet auf denselben Klartext, durch den Einsatz unterschiedlicher Schlüssel zu unterschiedlichen Geheimtexten führt. Somit ist der Schlüssel das wesentliche, geheim zuhaltende, Element.

Welche möglichen Schlüssel für eine Chiffre angewendet werden können, wird durch den '''Keyspace''' definiert. Dieser enthält alle möglichen Schlüssel. Je größer der Keyspace ist, desto mehr unterschiedliche Schlüssel existieren. Je mehr mögliche Schlüssel auf eine Chiffre anwendbar sind, desto aufwändiger wird es für einen Angreifer eine Nachricht durch bloßes Ausprobieren unterschiedlicher Schlüssel zu entschlüsseln.

Der Cäsar Algorithmus hat beispielsweise einen Keyspace von 26 möglichen Schlüsseln, da es genauso viele Buchstaben im lateinischen Alphabet gibt. Ein Angreifer würde durch einfaches durchprobieren daher maximal 26 Versuche benötigen, wobei die Verwendung des Schlüssels A sehr unwahrscheinlich ist, da der Text damit gleich bleiben würde.

Aktuelle Cipher haben hingegen wesentlich größere Keyspaces. Beispielsweise hat [[#Aktuelle Kryptographie-Standards_mit_symmetrischen_Methoden|AES256]] eine Schlüssellänge von 256 Bit. Daraus ergibt sich ein Keyspace von 2256 möglichen Schlüsseln. Da ein Angreifer durch zufälliges durchprobieren einen Schlüssel in der Regel nach der Hälfte der möglichen Kombinationen errät, muss er hier ca. (2256)/2 = 2255 Versuche durchführen.

=== Verschlüsselung (Encryption) / Entschlüsselung (Decryption) ===

Bei der '''Verschlüsselung''' handelt es sich um die Umwandlung von Klartext in Geheimtext mittels zugehöriger Chiffre und Schlüssel und bei der '''Entschlüsselung''' um die Umwandlung des Geheimtextes zurück in den Klartext.

Der Ablauf eines Weges vom Klartext über den Geheimtext zurück zum Klartext ist in Abbildung "Zusammenhang der Kryptographie Begriffe" noch einmal grafisch dargestellt.

[[Datei:IT244 8.png|300px|none|thumb|Zusammenhang der Kryptographie Begriffe]]


== Security by Obscurity und das Kerckhoffs’sche Prinzip ==

Ein kryptographisches System lässt sich durch die bloße Geheimhaltung der zugehörigen Chiffre nicht gewährleisten. Dieser Versuch wird auch als '''Security by Obscurity''' bezeichnet, da hier davon ausgegangen würde, dass alleine die Unwissenheit über die Methodik der Chiffre zu mehr Sicherheit führt. Dadurch ergeben sich jedoch einige wesentliche Probleme. Die geringe Anzahl an eingeweihten Anwendern entdeckt Fehler des Ciphers spät bis überhaupt nicht. Sobald die geheime Chiffre jedoch bekannt wird, ist jede durch ihre Geheimhaltung erreichte Sicherheit gebrochen. Wurde dann nicht auf eine ausreichende Geheimhaltung und Komplexität der Schlüssel geachtet hat wird das gesamte System unbrauchbar.

Kerkhoff entwickelte 1883 die Grundprinzipien sicherer Verschlüsselung, welche bis heute Bestand haben. Einer dieser Grundsätze wird heute als das '''Kerhoffs‘sche Prinzip''' bezeichnet. Es besagt, dass nicht das System selbst, sondern der Schlüssel geheim sein muss, um eine maximale Sicherheit zu erreichen. Der Algorithmus soll immer öffentlich bekannt sein. Der Schlüssel muss dabei unbedingt geheim gehalten werden. Je mehr unterschiedliche Geheimnisse rund um ein kryptographisches System nötig sind, umso verwundbarer ist es gegenüber möglichen Angriffen, welche Teile der Geheimnisse herausfinden. [Ha13, 767]

Auch wenn das Kerhoffs‘sche Prinzip besagt, dass die Sicherheit alleinig in der Geheimhaltung des Schlüssels liegt, so hat Security by Obscurity doch auch manchmal ihre Berechtigung. So kann beispielsweise durch die Kombination mehrerer bekannter Verfahren eine Unregelmäßigkeit hergestellt werden, welche möglichen Angreifern eine Analyse erschwert und damit eine erste Hürde darstellt, die überwunden werden muss.

Eine bekannte Anwendung ist das sogenannte „Salzen“ von Hashwerten. Dabei wird dem Plaintext vor der Hashwertberechnung ein zusätzlicher Teil („Salt“) hinzugefügt. Gelingt es einem Angreifer nun anhand der Hashwerte mögliche Ausgangswerte zu konstruieren, kann er den Ursprungswert nur durch das zusätzliche Wissen des „Salts“ rekonstruieren. Die berechneten Werte sind somit unbrauchbar.

== Symmetrische Verfahren ==

Bei einem symmetrischen kryptographischen Verfahren (Chiffre) wird ein Klartext mit ein und '''demselben Schlüssel''' verschlüsselt und auch wieder entschlüsselt (siehe Abbildung "Symmetrische Verfahren mit einem Schlüssel"). Bei symmetrischen Verfahren werden '''Substitutions-Methoden''' und '''Transpositions-Methoden''' angewendet, um den Klartext unkenntlich zu machen. Diese können innerhalb der Chiffre natürlich auch beliebig kombiniert werden.

[[Datei:IT244 9.png|300px|none|thumb|Symmetrische Verfahren mit einem Schlüssel]]


=== Substitutions-Methoden ===

Bei der Substitution handelt es sich um die Umwandlung eines Zeichens (oder Bits) durch ein anderes. Dies wären beispielsweise bei einem Cäsar 5 Algorithmus das Ersetzen des Zeichen K durch das Zeichen P zur Verschlüsselung und das Ersetzen des Zeichens P durch das Zeichen K zur Entschlüsselung. Der Schlüssel ist hierbei der Wert 5, welcher die Zuordnung des jeweiligen Zielzeichens ermöglicht.

Ein Beispiel auf Bit-Ebene ist die einfache XOR Verknüpfung des Schlüssels mit dem Text, welche ebenfalls in beide Richtungen anwendbar ist:

Klartext: 010010110101001001011001

Schlüssel: 010000010100001001000011

Geheimtext: 000010100001000000011010

Die Berechnung des Geheimtextes und des Klartextes ist dabei in beide Richtungen über die Verknüpfung mit dem Schlüssel möglich.

Ist der mittels XOR verknüpfte Schlüssel:

* gleich lang wie die Nachricht,
* zufällig generiert und
* wird dieser nur ein einziges Mal verwendet,
wird dies als '''One-Time-Pad''' bezeichnet. Diese Methode ist, ohne den Schlüssel in Besitz zu bekommen, definitiv unknackbar und damit die sicherste kryptographische Methode. Die Herausforderung besteht hierbei darin den Schlüssel sicher zu übermitteln, da dieser gleich lang wie die Nachricht sein muss. Dies ist meist nur sehr umständlich machbar und mit einem ähnlichen Aufwand verbunden, wie die Übermittlung der Nachricht selbst. One-Time-Pads werden daher eher zur Übermittlung kleinerer, hoch sensibler, Datenmengen eingesetzt. Sie könnten jedoch an Bedeutung gewinnen, da eine sichere Übermittlung von größeren Schlüsseln mittels Quantentechnologien immer praxistauglicher wird.

=== Transpositions-Methode ===

Bei der Transposition werden einzelne Teile des Textes mit anderen Teilen vertauscht. Der Schlüssel gibt dabei an, welcher Teil mit welchem vertauscht werden soll.

Ein Beispiel für eine einfache Transpositions-Methode ist in Abbildung "Transpositions-Cipher" dargestellt. Dabei wird der Plaintext zuerst in Gruppen zerlegt. Diese Gruppen werden nun gemäß dem Schlüsselwert intern neu angeordnet und ergeben dann in Summe wiederum den Ausgabetext. Auch diese Methode ist in beide Richtungen – sowohl zur Ver-, als auch zur Entschlüsselung – anwendbar.

[[Datei:IT244 10.png|300px|none|thumb|Transpositions-Cipher]]


=== Aktuelle Kryptographie-Standards mit symmetrischen Methoden ===

In der nachfolgenden Tabelle "Gängige Standards mit symmetrischen Algorithmen" sind die aktuell gängigsten symmetrischen Chiffren und ihre Eckpunkte aufgelistet.

Tabelle: Gängige Standards mit symmetrischen Algorithmen

{| style="border-collapse: collapse;" border="1"
! width="34%" | Standard Name
! width="34%" | Algorithmus
! width="31%" | Schlüssellängen
|-
| Data Encryption Standard (DES)
| Data Encryption Algorithm (DEA)
| 56 Bit Schlüssel 
(+8 Bit Parität = 64Bit)
|-
| Triple-DES (3DES)
| Triple Data Encryption Algorithm (TDEA)
| 112 Bit
|-
| Advanced Encryption Standard (AES)
| Rijndael
|
128 Bit

192 Bit

256 Bit
|-
| International Data Encryption Algorithm (IDEA)
| International Data Encryption Algorithm (IDEA)
| 128 Bit
|-
| Blowfish
| Blowfish
| Variable Länge zwischen 32 und 448 Bit
|-
| RC4
| RC4
| Variable Länge
|}

== Asymmetrische Verfahren ==

Bei asymmetrischen Verfahren werden zur Verschlüsselung und Entschlüsselung einer Nachricht '''zwei unterschiedliche Schlüssel''' verwendet. Die beiden Schlüssel gehören dabei immer zusammen und bilden ein '''Schlüsselpaar''' (siehe Abbildung "Asymmetrische Verfahren mit zwei unterschiedlichen Schlüsseln"). Es ist somit nicht möglich eine Nachricht mit demselben Schlüssel zu entschlüsseln, mit dem sie verschlüsselt wurde. Es kann dabei jeder der beiden Schlüssel zur Verschlüsselung einer Nachricht eingesetzt werden. Zur Entschlüsselung wird dabei immer der jeweils andere Schlüssel benötigt.

[[Datei:IT244 11.png|300px|none|thumb|Asymmetrische Verfahren mit zwei unterschiedlichen Schlüsseln]]


Dies ist auch vergleichbar mit einem Vorhängeschloss und einem Schlüssel. Das Schloss kann eingesetzt werden um eine Kiste zu versperren. Ohne den zugehörigen Schlüssel kann das Schloss jedoch nicht mehr geöffnet werden. Im Fall der asymmetrischen Verschlüsselung ist jeder der beiden Schlüssel gleichzeitig das Schloss des jeweils anderen Schlüssels:

* Key 1 = Schloss 2 (kann von Key 2 geöffnet werden)
* Key 2 = Schloss 1 (kann von Key 1 geöffnet werden)
Die beiden Schlüssel werden als '''Public-Key''' und '''Private-Key''' bezeichnet. Diese Bezeichnungen beruhen darauf, dass einer der beiden Schlüssel immer privat – also nur einer bestimmten Person bekannt – sein sollte. Der andere Schlüssel kann dann öffentlich an alle weitergegeben werden, die Nachrichten an den Besitzer des Private-Keys schicken wollen. Er ist somit public.

Will nun jemand eine Nachricht an den Besitzer des Private-Keys übermitteln kann er nun den dazu den '''Public-Key für die Verschlüsselung''' verwenden. Da die Nachricht nur mit dem zugehörigen Private-Key entschlüsselt werden kann, kann sie auch nur von dessen Besitzer gelesen werden. Der Public-Key ist zwar öffentlich verfügbar, jedoch zur Entschlüsselung der Nachricht nicht verwendbar.

Diese Methode kann nun auch umgekehrt verwendet werden um eine Nachricht durch den Besitzer des '''Private-Keys zu''' '''signieren'''. Dabei wird meist ein [[#Hashing|Hashwert]] der Nachricht generiert, die signiert werden soll. Dieser Hashwert wird nun mit dem Private-Key verschlüsselt und an die Nachricht angehängt. Will nun ein Empfänger prüfen, ob die Nachricht tatsächlich vom Besitzer des Private-Keys stammt, muss er nur den Hashwert mit dem öffentlich verfügbaren Public-Key entschlüsseln und mit dem aktuellen Hashwert der empfangenen Nachricht vergleichen. Sind die beiden Hashwerte ident, ist somit sichergestellt, dass die Nachricht vom Besitzer des Private-Keys stammen muss, da nur er den Hashwert korrekt verschlüsseln konnte. Würde sie auf dem Weg zum Empfänger verändert worden sein, wären die Hashwerte unterschiedlich.

Asymmetrische Methoden basieren auf komplexen mathematischen Berechnungen und sind vergleichsweise langsam. Sie werden daher meist nicht für die Verschlüsselung der Nachricht, sondern nur für die Verschlüsselung eines Schlüssels für die Anwendung einer symmetrischen Methode verwendet. Damit ist sichergestellt, dass der Schlüssel sicher übertragen wird und gleichzeitig eine schnellere Ver- und Entschlüsselung der übrigen Nachricht, mittels symmetrischer Methoden, erfolgen kann.

Eine weit verbreitete asymmetrische Methode wurde 1977 von Ronald L. '''R'''ivest, Adi '''S'''hamir und Leonard '''A'''dleman entwickelt und trägt daher den Namen '''RSA'''. Sie ist eine Weiterentwicklung des Diffie-Hellmann [[#Schl%C3%BCsseltauschverfahren|Schlüsseltauschverfahrens]]. Genauso wie dieses basiert sie auf dem Einsatz von '''[[#Schl%C3%BCsseltauschverfahren|Einwegfunktionen]]'''. Das Schlüsselpaar wird bei RSA durch den Einsatz sehr großer Primzahlen generiert, wobei die Anwendung des ersten Schlüssels die Nachricht unkenntlich macht und die zusätzliche Anwendung des zweiten Schlüssels die Anwendung des ersten Schlüssels wieder aufhebt. Der zugehörige zweite Schlüssel der Einwegfunktion ist nur durch Primfaktorzerlegungen sehr großer Primzahlen berechenbar. Dies ist jedoch ein sehr rechen- und damit zeitaufwändiger Vorgang.

Eine weiter asymmetrische Methode ist die der '''E'''lliptic '''C'''urve '''C'''ryptographie ('''ECC'''). Sie basiert auf der Berechnung von Punkten entlang einer elliptischen Kurve in einem zweidimensionalen Koordinatensystem. Dabei werden eine bestimmte Kurve und ein Startpunkt angegeben. Das Schlüsselpaar ergibt sich dann durch die Koordinaten eines Zielpunkts und der Anzahl der nötigen Schritte, die nötig sind, um vom Startpunkt aus zu ihm zu gelangen. Ähnlich der Berechnung der Multiplikation zweier Primzahlen ist und der Schwierigkeit einer Rückrechnung mittels Primfaktorzerlegung ist es einfach einen Punkt auf der Kurve zu berechnen, jedoch schwierig die Anzahl der nötigen Schritte zu ermitteln, die nötig sind um zu diesem Punkt zu gelangen. Ein Beispiel einer solchen Elliptic Curve ist in Abbildung "Elliptic Curve" dargestellt.

Die ECC Methoden sind stärker als die herkömmlichen asymmetrischen Methoden. Sie können sehr gut als performante Hardwarekomponenten implementiert werden und eignen sich daher besonders für den Einsatz in mobilen Endgeräten mit geringer Rechenleistung.

[[Datei:IT244 12.png|300px|none|thumb|Elliptic Curve]]


== Schlüsseltauschverfahren ==

Eine wesentliche Herausforderung der verschlüsselten Datenübertragung ist der Schlüsseltausch. Es muss daher eine Methode gefunden werden den nötigen Schlüssel zur Entschlüsselung der Nachricht an den Empfänger zu übermitteln, ohne dass dieser abgefangen werden kann. Würde der Schlüssel einfach vor der Übermittlung einer Nachricht übertragen werden, dann könnte ein möglicher Angreifer sowohl den Schlüssel, als auch den verschlüsselte Nachricht abfangen und dann beides gemeinsam einsetzen und die Nachricht einfach entschlüsseln.

Um dieses Problem zu lösen gibt es einige Methoden, die daher auch als Schlüsseltauschverfahren bezeichnet werden.

Die erste veröffentlichte mögliche Schlüsseltausch-Methode wurde 1976 von Diffie und Hellmann entwickelt. Sie basiert auf dem Einsatz von mathematischen Einwegfunktionen. Eine '''Einwegfunktion''' ist eine Funktion, welche leicht berechnet werden kann, deren Rückrechnung jedoch sehr schwierig ist. Dies lässt sich mit dem Mischen zweier Farbkübel zu vergleichen: Es ist zwar leicht zwei Farben zu mischen, jedoch enorm aufwändig sie wieder in ihre ursprünglichen Farbtöne aufzuteilen (vgl. Abbildung "Einwegfunktion der Farbmischung") und manuell nur durch ausprobieren möglich.

[[Datei:IT244 13.png|300px|none|thumb|Einwegfunktion der Farbmischung]]


Dies macht sich der Diffie-Hellmann Schlüsseltausch nun zu Nutze, indem er mathematische Einwegfunktionen verwendet um einen gemeinsamen und geheimen Schlüssel über eine unsichere Leitung auszutauschen. Die Vorgehensweise ist nachfolgend durch ein Beispiel mit Farbkübeln beschrieben und dann anschließend mathematisch erklärt.

Der Ablauf ist dabei folgendermaßen:

# Beide Teilnehmer vereinbaren eine '''gemeinsame (nicht geheime) Farbe.'''
# Jeder Teilnehmer generiert eine eigene '''geheime Farbe''', nur er selbst kennt.
# Nun '''mischen sie jeweils die geheime Farbe zur gemeinsamen Farbe'''.
# Danach '''übermitteln''' sie sich gegenseitig die '''Mischungen'''.
# Jeder Teilnehmer mischt seine '''eigene geheime Farbe zur empfangenen Mischung''' des anderen. Damit haben nun beide einen Farbkübel mit derselben Mischung aus: '''gemeinsame Farbe + eigene geheime Farbe + geheime Farbe des anderen'''.
# Die gemeinsame Mischung kann nun als Schlüssel für den geheimen Nachrichtenaustausch verwendet werden.
Die einzelnen Schritte des Schlüsseltauschs sind in Abbildung "Ablauf des Diffie-Hellmann Schlüsseltausches" noch einmal bildlich dargestellt. In der rechten Spalte ist ersichtlich welche Informationen ein möglicher Angreifer mithören kann. Er gelangt zwar an die gemeinsame Farbe und an die beiden Mischungen. Es ist ihm jedoch nicht möglich die geheimen Farben zu ermitteln. Damit fehlt ihm auch die Möglichkeit den gemeinsamen Schlüssel herauszufinden.

[[Datei:IT244 14.png|300px|none|thumb|Ablauf des Diffie-Hellmann Schlüsseltausches]]


Mathematisch betrachtet basiert der Diffie-Hellmann Schlüsseltausch auf dem ''diskreten Logarithmus-Problem'' und wird mit Hilfe folgender Formel abgebildet:

''n = gk mod p''

Das ''diskrete Logarithmus-Problem'' beschreibt die Schwierigkeit für gegebene Werte der Variablen ''n'', ''g'' und der Primzahl ''p'' den Wert der Variablen ''k'' zu finden. Bei kleinen Werten ist eine Berechnung von k noch machbar. Je größer sie jedoch werden, desto länger wird die dafür benötigte Zeit, da ein Rückrechnen nur durch Ausprobieren möglich ist. Für jedes zusätzliche Bit des Wertes müssen doppelt so viele Versuche angewendet werden.

Beim Schlüsseltausch sind '''''g''''' und '''''p''''' nun die gemeinsamen Werte (gemeinsame Farbe), welche öffentlich übermittelt werden und '''''n''''' das jeweilige Mischergebnis. '''''k''''' ist dabei der jeweils geheime Wert (eigene geheime Farbe), welcher niemals übermittelt wird.

Um zur gemeinsamen Farbmischung zu kommen macht sich der Schlüsseltausch nun zu Nutze, dass (x a) b gleich (x b)a  und damit x a b ist. Sind a und b nun die beiden geheimen Zahlen können sie zum jeweils anderen Ergebnis hinzugefügt werden, ohne den jeweiligen Exponenten der anderen Seite zu kennen. Übermittelt wird hierbei immer nur das Ergebnis.

Angewendet auf die oben genannte Formel des ''diskreten'' ''Logarithmus-Problems'' ergibt sich nun folgender Ablauf des Schlüsseltauschs:

# Die gemeinsamen Werte für '''''g''''' und '''''p''''' werden übermittelt
# Beide Teilnehmer generieren eine geheime Zahl (Teilnehmer A: '''''a'''''; Teilnehmer B: '''''b''''')
# Sie berechnen nun jeweils aus '''''q, p''''' und ihrer eigenen geheimen Zahl ('''''a''''' bzw. '''''b''''') den Wert zur Übermittlung: 
Teilnehmer A: ''A = ga mod p'' 
Teilnehmer B: ''B = gb mod p''
# Teilnehmer A übermittelt nun den Wert '''''A''''' an Teilnehmer B und Teilnehmer B den Wert '''''B''''' an Teilnehmer A.
# Nun können beide Teilnehmer mit ihrer eigenen geheimen Zahl den gemeinsamen Schlüssel '''''K''''' berechnen: 
Teilnehmer A: ''K = Ba mod p ''Teilnehmer B: ''K = Ab mod p''
# Beide Teilnehmer können nun K zur Verschlüsselung ihrer geheimen Nachrichten verwenden.
Das '''''Ba mod p''''' gleich '''''Ab mod p''''' ist, kann mittels gegenseitigem Einsetzen bewiesen werden:

''K = Ba mod p = (gb mod p)a mod p = gb a mod p''

''K = Ab mod p = (ga mod p)b mod p = ga b mod p''

'''''K = gb a mod p = ga b mod p'''''

Da ein möglicher Angreifer jedoch nur in Besitz der Werte g, p, A und B kommt, kann er den Schlüssel K nur mit enorm hohem Aufwand ermitteln.

Auf dem Grundprinzip von Diffie-Hellmann wurde später mit [[#Asymmetrische Verfahren|RSA]] die asymmetrischen Verschlüsselungsmethoden entwickelt. Die Diffie-Hellmann Methode wurde inzwischen auch um die verstärkte Sicherheit von Elliptic Curves erweitert und findet ihre diesbezügliche Verbreitung unter dem Namen Elliptic Curve Diffie-Helman (ECDH).

== Hashing ==

Beim Hashing handelt es sich um die Anwendung einer '''nicht reversiblen Funktion''', auf einen bestimmten Wert. Das Ergebnis einer Hash-Funktion ist somit nicht auf den Ausgangswert umkehrbar. Dabei wird meist ein Wert variabler Länge zu einem Wert fixer Länge umgewandelt, der dem Ursprungswert nicht mehr ähnelt.

Ein guter Hash-Algorithmus hat möglichst wenige '''Kollisionen'''. Das bedeutet, dass die Wahrscheinlichkeit bei unterschiedlichen Eingangswerten denselben Ausgangswert zu bekommen sehr gering ist.

Das nachfolgende Beispiel in Tabelle "Beispiel Hashfunktion HashMe()" zeigt mögliche Hashwerte einer fiktiven Hashfunktion HashMe(). Die letzten beiden Zeilen sind ein Beispiel einer Kollision.

Tabelle: Beispiel Hashfunktion HashMe()

{| style="border-collapse: collapse;" border="1"
! width="49%" | Eingangswert
! width="28%" | Hashwert = HashMe(Eingangswert)
! width="22%" | 
|-
| Peter
| 0c74c6051287c95d
|
 
|-
|
Guten Tag!

Hiermit nehme ich Ihr Angebot mit der Nummer 12334 an.

Mit freundlichen Grüßen,

Miriam Muster
| 878b87429ff50296
|
 
|-
| Mich gibt es hoffentlich nur einmal!
| ae4692a6f28a03cd
| '''Kollision'''
|-
| 45667533423233467885354
|
ae4692a6f28a03cd
| 
|}
Da ein Hashwert einer bestimmten Nachricht immer gleich ist, eignet er sich sehr gut zur '''Integritätsprüfung'''. Sobald sich ein Teil der Nachricht ändert, ändert sich auch der Hashwert. Das Vorhandensein einer Änderung der Nachricht kann somit einfach durch den Vergleich des Original-Hashwertes und des aktuellen Hashwertes aufgezeigt werden.

Dieses Prinzip wird auch bei '''digitalen Signaturen''' verwendet. Dabei wird ein Hashwert der zu signierenden Nachricht generiert und mit dem [[#Asymmetrische Verfahren|Private-Key]] des Absenders verschlüsselt. Dieser wird der Nachricht dann als Signatur beigefügt. Der Empfänger kann nun den Hashwert mit dem Public-Key entschlüsseln und mit dem aktuellen Hashwert der empfangenen Nachricht vergleichen. Sind die beiden Werte gleich ist sichergestellt, dass:

* sich der Inhalt der Nachricht nicht verändert hat und
* der Besitzer des Private-Key ist auch der Absender der Nachricht ist, da nur er eine Verschlüsselung durchführen kann, welche mit dem zugehörigen Public-Key korrekt entschlüsselt wird.
Da mit Hash-Werten die Integrität von Nachrichten geprüft werden kann, werden diese auch oft als '''Fingerprint''' oder '''Message-Digest''' bezeichnet.

Einige derzeit gängige Hash-Algorithmen sind in Tabelle "Gängige Hash-Algorithmen" aufgelistet.

Tabelle: Gängige Hash-Algorithmen

{| style="border-collapse: collapse;" border="1"
! width="26%" | Standard Name
! width="32%" | Länge des Hash-Wertes
! width="40%" | Anmerkung
|-
| MD4
| 128 Bit
| Optimiert für schnelle Berechnung
|-
| MD5
| 128 Bit
| Komplexerer Algorithmus als MD4 und daher langsamere Berechnung
|-
| SHA
| 160 Bit
| Ähnlich wie MD4
|-
| HAVAL
| Variable Länge
| Ähnlich wie MD5
|-
| Tiger
| 192 Bit
|
Ähnlich wie MD4

Optimiert für 64 Bit Systeme
|}

== Angriffsvektoren der Kryptographie ==

Die möglichen direkten Angriffsvektoren der Kryptographie teilen sich in die, nachfolgend beschriebenen, Kategorien:

* Brute-Force Angriffe,
* Kryptoanalyse und
* Angriffe gegen Hashwerte.
Um die genannten Angriffe ausführen zu können, ist es meist erforderlich den zugehörigen Datenverkehr abzuhören und gegebenenfalls auch zu manipulieren. Dazu werden oft [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Sniffing|Sniffing]]- und [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Man-in-the-Middle_Angriff|Man-in-the-Middle-Attacken]] genutzt.

=== Brute-Force Angriffe ===

Bei Brute-Force Angriffen wird versucht eine Verschlüsselung zu knacken, indem eine '''Vielzahl möglicher Schlüssel ausprobiert''' wird. Dabei steigt mit der Länge der Schlüssel auch die Anzahl der dazu nötigen Versuche (siehe auch [[#Schl%C3%BCssel (Key)_und_Keyspace|Keyspace]]).

Die Stärke einer Chiffre wird daher auch dadurch angegeben, wie lange es dauern würde, durch einen Brute-Force Angriff einen möglichen Schlüssel zu finden.

Um die Möglichkeiten einzuschränken wird daher oft die Methode des '''Wörterbuchangriffs''' eingesetzt. Dabei werden keine beliebigen Schlüssel generiert, sondern stattdessen Einträge eines Wörterbuches bzw. einer Liste häufig eingesetzter Schlüssel (bzw. Passwörter) verwendet. Diese Listen werden meist auch nach der statistischen Häufigkeit der Verwendung der Begriffe gereiht, um die am häufigsten genutzten Passwörter auch zuerst zu versuchen. Die zugehörigen Statistiken werden dabei aus bereits im Internet veröffentlichten oder gestohlenen Passwortlisten generiert.

Da der Aufwand eines Angriffes mit der Länge der verwendeten Schlüssel zunimmt, kann ihm besonders durch den Einsatz langer Schlüssel begegnet werden. Auch ist es wichtig Passwörter zu verwenden, welche nicht durch Wörterbücher und Passwortlisten generiert werden können.

=== Kryptoanalyse ===

Bei der Kryptoanalyse handelt es sich um ein Teilgebiet der Kryptographie. Sie hat zum Gegenstand aus möglichen bekannten Teilen eines kryptographischen Systems (Klartext, Geheimtext, Chiffre) nicht bekannte Teile herauszufinden.

Da der Algorithmus einer Chiffre in der Regel bekannt ist, kann die Kryptoanalyse diesen als Basis verwenden. Um nun den Schlüssel oder den Klartext rekonstruieren zu können, stehen dem Analytiker folgende Analysemethoden zur Verfügung:

* '''Ciphertext-Only''' (der Analyse steht nur der Geheimtext zur Verfügung),
* '''Known-Plaintext''' (der Analyse steht der Geheimtext und der Klartext zur Verfügung),
* '''Chosen-Plaintext''' (der Analyse steht der Geheimtext zur Verfügung und der Klartext kann für die Analyse frei gewählt werden) und
* '''Chosen-Ciphertext''' (der Analyse steht der Klartext zur Verfügung und der Geheimtext kann für die Analyse frei gewählt werden).

=== Angriffe gegen Hashwerte ===

Angriffe gegen Hashwerte haben das Ziel Kollisionen zu finden, die zu einem gesuchten Hashwert führen. Werden beispielsweise Passwörter als Hash gespeichert und kommt ein Angreifender in den Besitz dieser Daten, kann er die Passwörter nicht einfach aus den Werten berechnen, da Hashwerte nicht reversibel sind.

Es ist jedoch möglich (ähnlich wie einem [[#Brute-Force Angriffe|Brute-Force Angriff]]) aus einer Liste von Passwörtern mögliche Hashwerte zu berechnen und diese dann mit den Hashwerten zu vergleichen.

Da diese Listen sehr groß (einige Terrabyte und mehr) werden können und damit auch nur sehr schwer zu durchsuchen sind, wurde die Methode der '''Rainbow-Tables''' entwickelt. Dabei handelt es sich um eine näherungsweise Suche, die mögliche Teilstücke des Hashwerts berechnet. Die Suche erfolgt damit in mehreren Schritten verknüpften Tabellen, ist jedoch wesentlich schneller als die Suche in einer enorm großen Liste. Der Name Rainbow-Tables kommt dabei von einer der ersten grafischen Darstellungen der zugehörigen Methode. Dabei wurden die einzelnen Schritte (Tabellen) in unterschiedlichen Farben dargestellt.

Diesem Angriff kann entgegengewirkt werden, indem die '''Passwortlänge erhöht''' wird und indem der Hashwert bei der Berechnung zusätzlich „gesalzen“ wird. Durch die Erhöhung der Länge wird die nötige Menge der vorausberechnenden Werte entsprechend höher, was einen Angriff auf lange Passwörter entsprechend erschwert. Beim '''Salzen''' wird dem Passwort vor der Hashwertberechnung ein zusätzlicher Wert hinzugefügt. Dieser Wert wird als „Salt“ bezeichnet. Kann dieser Ausgangswert nun mittels Rainbow-Tables ermittelt werden, handelt es sich um den gesalzenen Wert und nicht um das tatsächliche Passwort. Die Angreifenden müssten daher einerseits den Salt kennen und dann sehr aufwändig eine eigene Rainbow-Table generieren, die ebenfalls diesen Salt anhält.

== Wiederholungsaufgaben/Übungen ==

'''1 Erklären Sie den Cäsar-Algorithmus anhand der Verschlüsselung des Wortes '''"'''WIBA'''"''' durch Cäsar 5.'''

'''2 Erklären Sie die Begriffe Klartext, Geheimtext, und Chiffre. Stellen Sie Ihre Zusammenhänge bei der Verschlüsselung und Entschlüsselung grafisch dar.'''

'''3 Erklären Sie den Begriff “Security by Obscurity“? Welches Prinzip spricht dagegen?'''

'''4 Wodurch unterscheiden sich symmetrische und asymmetrische Kryptographie-Verfahren?'''

'''5 Wie läuft der Diffie-Hellmann Schlüsseltausch ab. Erklären Sie ihn anhand eines einfachen Beispiels mit Farbkübeln ODER mathematisch.'''

'''6 Was ist Hashing und wozu wird es eingesetzt?'''

'''7 Was ist ein Brute-Force Angriff?'''

AI assisted Engineering

2024-02-12T13:33:28Z

VÖLKL Peter:

[[Grundlagen von AI in Engineering und Softwareentwicklung|AI assisted Engineering - Grundlagen von AI in Engineering und Softwareentwicklung]]

[[Prompt-Entwicklung und -Anwendung|AI assisted Engineering - Prompt-Entwicklung und -Anwendung]]

[[AI-gestützte Datenanalyse und Modellierung|AI assisted Engineering - AI-gestützte Datenanalyse und Modellierung]]

[[Softwareentwicklung mit AI|AI assisted Engineering - Softwareentwicklung mit AI]]

AI assisted Engineering

2024-02-12T13:32:55Z

VÖLKL Peter: Die Seite wurde neu angelegt: „ Grundlagen von AI in Engineering und Softwareentwicklung Prompt-Entwicklung und -Anwendung AI-gestützte Datenanalyse und Modellierung Softwareentwicklung mit AI“

[[AI assisted Engineering - Grundlagen von AI in Engineering und Softwareentwicklung|Grundlagen von AI in Engineering und Softwareentwicklung]]

[[AI assisted Engineering - Prompt-Entwicklung und -Anwendung|Prompt-Entwicklung und -Anwendung]]

[[AI assisted Engineering - AI-gestützte Datenanalyse und Modellierung|AI-gestützte Datenanalyse und Modellierung]]

[[AI assisted Engineering - Softwareentwicklung mit AI|Softwareentwicklung mit AI]]

Computer- und Netzwerksicherheit

2024-02-09T10:48:41Z

VÖLKL Peter:

[[Computer- und Netzwerksicherheit - Gesamt|Computer- und Netzwerksicherheit - Gesamt (Achtung - immer die aktuellste Version!)]]

'''Version für das Sommersemester 2024'''

[[Special:PermanentLink/5584|Computer- und Netzwerksicherheit - Grundlagen|Computer- und Netzwerksicherheit - Grundlagen]]

[[Special:PermanentLink/2157|Computer- und Netzwerksicherheit - Bewusstseinsbildung|Computer- und Netzwerksicherheit - Bewusstseinsbildung]]

[[Special:PermanentLink/2278|Computer- und Netzwerksicherheit - Kryptograhpie|Computer- und Netzwerksicherheit - Kryptograhpie]]

[[Special:PermanentLink/2711|Computer- und Netzwerksicherheit - Zugriffssteuerung|Computer- und Netzwerksicherheit - Zugriffssteuerung]]

[[Special:PermanentLink/2280|Computer- und Netzwerksicherheit - Netzwerksicherheit|Computer- und Netzwerksicherheit - Netzwerksicherheit]]

Grundlagen der Modellierung

2023-11-02T14:25:53Z

VÖLKL Peter:

[[Grundlagen der Modellierung - Gesamt |Grundlagen der Modellierung - Gesamt (Achtung - immer die aktuellste Version!)]]

'''Version für das Wintersemester 2023/2024'''

[[Grundlagen der Modellierung - Einleitung|Grundlagen der Modellierung - Einleitung]]

[[Grundlagen der Modellierung - Datenmodellierung|Grundlagen der Modellierung - Datenmodellierung]]

[[Grundlagen der Modellierung - Prozess- und Ablauf- und Geschäftsprozessmodellierung|Grundlagen der Modellierung - Prozess- und Ablauf- und Geschäftsprozessmodellierung]]

[[Grundlagen der Modellierung - Prozess- und Ablaufmodellierung|Grundlagen der Modellierung - Prozess- und Ablaufmodellierung]]

[[Grundlagen der Modellierung - Geschätfsprozessmodellierung|Grundlagen der Modellierung - Geschätfsprozessmodellierung]]

[[Grundlagen der Modellierung - Objektorientierte Modelle|Grundlagen der Modellierung - Objektorientierte Modelle]]

[[Grundlagen der Modellierung - Quellen|Grundlagen der Modellierung - Quellen]]

Grundlagen der Modellierung - Gesamt

2023-11-02T14:25:14Z

VÖLKL Peter:

{{:UrheberrechtDefault}}
 <hr> 
{{:Benutzer:VÖLKL_Peter}}
 <hr> 
{{:Grundlagen der Modellierung - Einleitung|Grundlagen der Modellierung - Einleitung}}

{{:Grundlagen der Modellierung - Datenmodellierung|Grundlagen der Modellierung - Datenmodellierung}}

{{:Grundlagen der Modellierung - Prozess- und Ablauf- und Geschäftsprozessmodellierung|Grundlagen der Modellierung - Prozess- und Ablauf- und Geschäftsprozessmodellierung}}

{{:Grundlagen der Modellierung - Objektorientierte Modelle|Grundlagen der Modellierung - Objektorientierte Modelle}}

{{:Grundlagen der Modellierung - Quellen|Grundlagen der Modellierung - Quellen}}

Grundlagen der Modellierung

2023-11-02T14:23:31Z

VÖLKL Peter:

[[Grundlagen der Modellierung - Gesamt |Grundlagen der Modellierung - Gesamt (Achtung - immer die aktuellste Version!)]]

'''Version für das Wintersemester 2023/2024'''

[[Grundlagen der Modellierung - Einleitung|Grundlagen der Modellierung - Einleitung]]

[[Grundlagen der Modellierung - Datenmodellierung|Grundlagen der Modellierung - Datenmodellierung]]

[[Grundlagen der Modellierung - Prozess- und Ablauf- und Geschätfsprozessmodellierung|Grundlagen der Modellierung - Prozess- und Ablauf- und Geschätfsprozessmodellierung]]

[[Grundlagen der Modellierung - Prozess- und Ablaufmodellierung|Grundlagen der Modellierung - Prozess- und Ablaufmodellierung]]

[[Grundlagen der Modellierung - Geschätfsprozessmodellierung|Grundlagen der Modellierung - Geschätfsprozessmodellierung]]

[[Grundlagen der Modellierung - Objektorientierte Modelle|Grundlagen der Modellierung - Objektorientierte Modelle]]

[[Grundlagen der Modellierung - Quellen|Grundlagen der Modellierung - Quellen]]

Computer- und Netzwerksicherheit - Grundlagen

2023-08-10T16:20:16Z

VÖLKL Peter:

= Grundlagen der Informationssicherheit =

== Einleitung ==

Die Sicherheit der Informationstechnologie ist ein wesentlicher Bestandteil der Unternehmenssicherheit, da viele Prozesse einer intensiven IT-Unterstützung bedürfen und ohne sie nicht mehr, oder nur teilweise, funktionieren können. Es ist daher enorm wichtig, die möglichen Risiken zu kennen und diese, bezugnehmend auf die einzelnen Unternehmensprozesse, bewerten zu können. So umfangreich die Informationssysteme eines Unternehmens sind, so umfangreich sind auch die zu beachtenden Angriffsvektoren, sowie die Szenarien für Datenverlust, Nichtverfügbarkeit und Datendiebstahl. Die Computer- und Netzwerksicherheit ist ein wesentlicher Bestandteil der Informationssicherheit und greift in jede erdenkliche Materie der Informationstechnologie ein.

Die Zwischenfälle im IT-Sicherheitsbereich nahmen in den letzten Jahren immer mehr zu. Einer Statistik der Internet-Sicherheitslage in Österreich von CERT.at und GovCERT.gv.at zufolge ist die Anzahl der IT-Sicherheitszwischenfälle von unter 10 pro Monat im Jahr 2009 auf konstant über 500 pro Monat ab Ende des Jahres 2012 gestiegen. Gegen Ende 2013 kann sogar von 1000 Zwischenfällen pro Monat ausgegangen werden, die Tendenz ist weiterhin steigend. [Ni13, 13]

== Informations- und IT-Sicherheit ==

Rund um den Bereich der IT-Sicherheit gibt es viele, oft falsch verstandene Begrifflichkeiten wie Datenschutz, Datensicherheit und Informationssicherheit [Ha12, 28]. Nachfolgend werden diese Begriffe nun kurz beschrieben, um einen Überblick über die Materie zu verschaffen.

=== Informationssicherheit ===

Bei der Informationssicherheit handelt es sich um die ganzheitliche Betrachtung der Sicherheit und den Schutz aller Art von Informationen. Dabei ist es nicht relevant, ob diese Informationen in elektronischer oder nicht elektronischer Form vorliegen.

=== IT-Sicherheit ===

Die IT-Sicherheit ist Teil der Informationssicherheit (siehe Abbildung "Schnittmenge Informations-Sicherheit und IT-Sicherheit"). Sie beschäftigt sich mit dem Schutz aller Art von elektronischer Information. Das beinhaltet alle EDV und Kommunikationssysteme, wie Computer, Internetverbindungen und Netzwerke, Telefonie und die für den Betrieb der Systeme zugrundeliegende Infrastruktur wie beispielsweise die Stromversorgung.

[[Datei:IT244 1.png|300px|none|thumb|Schnittmenge Informations-Sicherheit und IT-Sicherheit ]]


=== Datenschutz und Datensicherheit ===

Der Datenschutz regelt den Schutz personenbezogener Daten, welche in elektronischer oder manueller - nicht elektronisch geführter - Form vorliegen. In Österreich ist der Datenschutz sowohl in einem Bundesgesetz (DSG), als auch in 9 Landesgesetzen geregelt.

''Jedermann hat, insbesondere auch im Hinblick auf die Achtung seines Privat- und Familienlebens, Anspruch auf Geheimhaltung der ihn betreffenden personenbezogenen Daten, soweit ein schutzwürdiges Interesse daran besteht. Das Bestehen eines solchen Interesses ist ausgeschlossen, wenn Daten infolge ihrer allgemeinen Verfügbarkeit oder wegen ihrer mangelnden Rückführbarkeit auf den Betroffenen einem Geheimhaltungsanspruch nicht zugänglich sind.'' [Bg19, § 1. (1)]

Die Einhaltung des Datenschutzes ist Teil der Informationssicherheit bzw. IT-Sicherheit und damit des IT-Sicherheitsmanagements. Die beiden Begrifflichkeiten werden jedoch oft vermischt oder verwechselt. So ist der Datenschutz selbst nur ein kleiner Teilbereich. IT-Sicherheit betrachtet wesentlich mehr als den Schutz personenbezogener Daten und bezieht sich auf alle Unternehmensprozesse und ihre IT-Unterstützung.

== Säulen der Informationssicherheit - CIA Triade ==

Die IT-Sicherheit und damit das IT-Sicherheitsmanagement basieren auf drei Säulen, welche den zu betrachtenden Rahmen aller durchzuführenden Analysen und den damit verbundenen Maßnahmen darstellen. Sie tragen somit bildlich das Dach der IT-Sicherheit und sorgen nur in ihrer gemeinsamen Betrachtung für die Stabilität und Sicherheit des gesamten IT-Sicherheits-Systems. Ihr Fundament ist das IT-Sicherheitsbewusstsein und die damit verbundene Bewusstseinsbildung ist die notwendige Maßnahme (siehe Abbildung "Aufbau der IT-Sicherheit").

Die drei Säulen sind:

* Vertraulichkeit (Confidentiality),
* Integrität (Integrity) und
* Verfügbarkeit (Availability).
[[Datei:IT244 2.png|300px|none|thumb|Aufbau der IT-Sicherheit]]


Die drei Säulen der IT-Sicherheit werden oft auch als „CIA-Triade“ <ref>Der genaue Ursprung der „CIA-Triade“ ist nicht genau feststellbar. Die zugrundeliegenden Konzepte waren bereits vor Jahrtausenden im militärischen Kontext bekannt. Sie befinden sich beispielsweise in den Werken „Commentarii de bello Gallico“ [Ca58] des römischen Feldherren Gaius Julius Cäsar.</ref> oder „AIC-Principles“ bezeichnet, da die englischen Bezeichnungen mit den Buchstaben C, I und A beginnen.

=== Vertraulichkeit (Confidentiality) ===

Unter Vertraulichkeit wird die Einschränkung der Datenzugriffe auf einen bestimmten Anwenderkreis verstanden. Unberechtigte dürfen keinen Zugriff auf die IT-Systeme und Daten haben. Dies sind beispielsweise die Absicherung des gesamten Systems vor IT-Zugriffen unberechtigter Dritter und aber auch die Definition unterschiedlicher Berechtigungsstufen innerhalb der berechtigten Anwender. So sollte es beispielsweise einem Anwender erlaubt sein, die benötigten Programme zu starten, nicht jedoch neue Software zu installieren oder die gesamte Datenbank zu kopieren.

Je nach System kann die Vertraulichkeit über Benutzer- und Programm-Berechtigungen und auch physische Zutrittskontrolle sichergestellt werden. Die hier gesetzten Maßnahmen sind jene Maßnahmen, welche am häufigsten mit IT-Sicherheit in Zusammenhang gebracht werden, jedoch ohne Betrachtung der anderen beiden Bereiche Integrität und Verfügbarkeit nicht vollständig sind.

=== Integrität (Integrity) ===

Die Integrität ist die Betrachtung des Datenbestandes im Zusammenhang mit allen verfügbaren, und nicht verfügbaren, Daten. Innerhalb des Datenbestandes muss sichergestellt werden, dass die Daten selbst vollständig, unverfälscht, korrekt zusammenhängend und nicht widersprüchlich sind. Das bedeutet, dass der Datenbestand lückenlos sein muss und das Fehlen von Daten ersichtlich sein muss. Auch darf durch die Nichtverfügbarkeit einzelner Daten keine Kettenreaktion auf andere Daten ausgelöst werden, welche wiederum zu weiteren falschen Daten führen würde.

Ein Beispiel hierfür ist das Fehlen von Messwerten eines über das Netzwerk angebundenen Medizinproduktes, welches für eine gewisse Zeit durch eine Störung nicht korrekt angebunden war. Wird dieses Lückenproblem nicht korrekt vom darüberlegenden IT-System behandelt, könnten hierbei falsche Durchschnittswerte entstehen, welche wiederum zu einem falschen Diagnosevorschlag führen würden.

=== Verfügbarkeit (Availability) ===

Bei der Verfügbarkeit wird die Funktionsbereitschaft der IT-Systeme zu den Zeitpunkten bezeichnet, zu denen sie benötigt werden. Dabei handelt es sich um alle Maßnahmen gegen Ausfälle oder Datenverlust. Hierbei ist es auch erforderlich den Zusammenhang zwischen den Systemen zu betrachten, da der Ausfall eines als unwichtig erscheinenden Systems andere wichtige Systeme beeinträchtigen könnte.

So kann beispielsweise der Ausfall eines Dateiservers als wenig wichtig eingestuft werden, da die Daten in den Kernprozessen nicht unmittelbar im Zugriff sein müssen. Wenn hingegen eine wichtige Software des Kernprozesses seine Logdateien auf genau diesen Dateiserver ablegen muss, wird die anfangs als unwichtig eingestufte Dateiablage auf einmal zu einer kritischen Komponente, da sonst wiederum die Integrität gefährdet wäre.

=== Kontrollmechanismen ===

Rund um die CIA-Triade sind drei Kontrollmechanismen definiert, um ihre grundsätzlichen Ziele im Detail analysieren zu können [Fr13, 29]:

* '''Physische Kontrolle''': Schutz der IT-Systeme vor physischem Zugriff durch Maßnahmen wie Zäune, Schlösser und Wachpersonal.
* '''Technische Kontrolle''': Schutz der IT-Systeme und Daten vor technischen Zugriffen über Netzwerke und Anwenderzugriffe. Beispielsweise durch Benutzerberechtigungen, Firewalls, Datenverschlüsselung und das Verhindern des Betriebs von unerlaubten IT-Komponenten im eigenen IT-System.
* '''Administrative Kontrolle''': Installation, Schulung und Kontrolle von IT-Sicherheitsprozessen und IT-Sicherheitsmanagement und allen damit verbundenen Richtlinien und Vorgaben und die Einhaltung der damit verbundenen Gesetzlichen Vorgaben.

=== Risiko- und Schwachstelleneinteilung der Schutzziele ===

Um eine einheitliche Betrachtung und Maßnahmensetzung zu ermöglichen sollten alle Risiken gemäß der Schutzziele der CIA-Triade kategorisiert werden. Eine Einteilung in mehrere Kategorien ist in einigen Fällen möglich, jedoch nicht immer voll abgrenzbar [Ha12, 267]. Im Rahmen der Analyse sollte jedoch stets darauf geachtet werden, eine mögliche Einstufung in jeder der drei Säulen zu bedenken. So kann beispielsweise das Risiko einer Schadsoftware mehr als einem Schutzziel zugeordnet werden, da sie sowohl die Integrität als auch die Verfügbarkeit und die Vertraulichkeit gefährden kann [Ha12, 268].

Bei der Analyse der Risiken werden mögliche Schwachstellen der Schutzziele aufgedeckt, welche wiederum zu möglichen Bedrohungen führen. Daraus ergeben sich dann die dafür notwendigen Maßnahmen. Zwischen diesen drei Bereichen bestehen nun einige direkte Abhängigkeiten, die sich jedoch auch oft überschneiden können. Das bedeutet, dass eine Schwachstelle mehrere Risiken bedingen kann und mehreren Risiken durch eine einzelne Maßnahme begegnet werden kann. Abbildung "Zusammenhang von Schwachstellen, Bedrohungen und abgeleiteten Maßnahmen" beschreibt die hier erwähnten Zusammenhänge anhand einiger Beispiele aus dem Softwarebereich:

[[file:img1643450062206.png|300px|none|thumb|Zusammenhang von Schwachstellen, Bedrohungen und abgeleiteten Maßnahmen]]

Die möglichen Bedrohungen durch das Ausnutzen von Schwachstellen werden oft auch als '''Angriffsvektoren''' bezeichnet. Ein Angriffsvektor ist dabei der Weg, den ein Angreifer wählen kann um sein jeweiliges Angriffsziel zu erreichen.

== Informationssicherheits-Standards ==

Die IT-Sicherheit und die Einführung und der Aufbau von IT-Sicherheits-Management-Systemen sind in unterschiedlichen Normen und Standards geregelt, die teilweise aufeinander aufbauen oder referenzieren.

Die wesentlichen drei Standards sind:

* die ISO/IEC 2700x Reihe,
* IT-Grundschutz-Standards des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und
* das Österreichische Informationssicherheitshandbuch.

=== ISO/IEC 2700x Reihe ===

Eine Reihe verbreiteter internationaler Informationssicherheits-Standards ist die ISO/IEC 2700x Reihe. Sie wurde von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) begründet und wird stetig ausgebaut.

Das Basisdokument der Reihe ist die ISO/IEC 27000 [Is14] (Informationstechnologie, Sicherheitstechnik, Informationssicherheits-Managementsysteme). Sie definiert die Grundbegriffe und bietet einen Gesamtüberblick. Einige Teile der Reihe wurden von Standards der British Standards Institution (BSI) abgeleitet.

Die grundlegenden Teile der ISO/IEC 2700x sind:

* ISO/IEC 27001 bis 27004: Definition, Betrieb und Kontrolle von Informationssicherheits-Managementsystemen (ISMS) und
* ISO/IEC 27005: Informationssicherheits-Risikomanagement.
Die weiteren Teile beschäftigen sich mit dem Audit und branchenspezifischen und technischen Ausprägungen der ersten fünf Standards. Ein Beispiel dafür ist die EN ISO 27799, welche sich auf das Sicherheitsmanagement im Gesundheitswesen bezieht.

=== IT-Grundschutz-Standards des Bundesamtes für Sicherheit in der Informationstechnik (BSI) ===

Der BSI IT-Grundschutz Standard teilt sich in mehrere Dokumente. Er wird durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) der Bundesrepublik Deutschland stetig weiterentwickelt und herausgegeben.

Die Teile des IT-Grundschutz sind:

* BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) [Bu08a],
* BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise [Bu08b],
* BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz [Bu08c] und
* BSI-Standard 100-4: Notfallmanagement [Bu08d].
Bei allen BSI Standards handelt es sich um Empfehlungen zu Methoden, Prozessen und Verfahren der Informationssicherheit. Die Standards dienen der fachlichen Unterstützung von Anwendern der Informationstechnik und bieten die Möglichkeit, entweder die Empfehlungen direkt zu verwenden oder diese erforderlichenfalls an die eigenen Bedürfnisse anzupassen. [Bu15]

=== Österreichisches Informationssicherheitshandbuch ===

Beim Österreichisches Informationssicherheitshandbuch [Ze13] handelt es sich um ein vom Österreichischen Bundeskanzleramt herausgegebenes Werk, welches teilweise auf bestehenden Standards und Normen wie den BSI IT-Grundschutz und die ISO/IEC 2700x aufbaut und Vorgehensweisen für den Aufbau und Betrieb von Informationssicherheit-Management-Systemen. Die Struktur entspricht dabei derer der ISO/IEC 27001 und ISO/IEC 27002.

Das Informationssicherheitshandbuch beschreibt seine eigene Ausrichtung und Umfang wie folgt: ''Von der Ausrichtung versteht sich das Informationssicherheitshandbuch […] als Sammlung von Leitlinien und Empfehlungen für die Praxis, die entsprechend den spezifischen Anforderungen und Bedürfnissen in einer Einsatzumgebung angepasst werden müssen. Dies wird auch durch die Online-Funktionalitäten wie Checklisten unterstützt. Es soll eine Ergänzung zu den bestehenden Regelungen und Vorschriften (Datenschutzgesetz, Informationssicherheitsgesetz, Verschlusssachenvorschriften, Amtsgeheimnis, …) darstellen und setzt diese weder außer Kraft noch steht es zu ihnen im Widerspruch.'' [Ze13, 27]

== Informationssicherheits-Management ==

''IT-Security ist keine Software, kein Werkzeug und auch kein Zustand. IT-Security ist ein Prozess!'' [KRS08, 401]

Dieser Satz beschreibt die grundlegende Definition bereits ganz gut. Um IT-Sicherheit einzuführen benötigt es keiner einzelnen Produkte oder reiner persönlicher Ansichten, sondern einen unterstützenden Unternehmensprozess des IT-Sicherheitsmanagements. Es kann dabei nicht als eigenständiges Vorhaben betrachtet werden, sondern gliedert sich in die Betrachtung aller Geschäftsprozesse mit ein. Ein wesentlicher Fehler wäre es, sie Einführung von IT-Sicherheit als zeitlich begrenztes Projekt abzuwickeln, ohne danach einen funktionierenden Managementprozess zu haben, der sich um die Aufrechterhaltung und stetige Verbesserung des IT-Sicherheitsstatus kümmert.

Der Schutz von Informationen und Daten ist auch für kleine und mittlere Unternehmen von großer Bedeutung, ''da für diese ein entsprechender Verlust von Daten oder deren Manipulation, sehr rasch, ein existenzbedrohendes Potential annehmen kann.'' [Fr13, 8]

Die Implementierung eines durchgängigen und effizienten IT-Sicherheitsmanagements bedarf detailliertes Wissen über das betreffende Unternehmen und Fachkompetenz im Bereich der IT und IT-Sicherheit. Durch standardisierte Methoden und vormodellierte interne Kontrollsysteme kann es jedoch ermöglicht werden, den operativen Teil des IT-Sicherheitsmanagements durch Spezialisten der Geschäftsprozesse mit IT-Basiswissen durchzuführen.

Um IT-Sicherheitsmanagement in einem Unternehmen zu implementieren, wird ein '''IT-Sicherheitsmanagement-System (ISMS)''' aufgesetzt. Dieses System ist die Grundlage des IT-Sicherheitsprozesses, welcher, als Managementprozess, wiederum durch entsprechende Prozessnahtstellen Teil aller Unternehmensprozesse ist.

''Ein ISMS ist ein Teil eines allgemeineren, umfassenderen Management-Systems, das andere Teile der Organisation, möglicherweise die gesamte Organisation, und weitere Themen umfasst. Das ISMS baut auf der Einschätzung der Geschäftsrisiken auf. Ein ISMS sollte daher als ein Mittel verstanden werden, mit dem das Management einer Organisation auf erkannte Risiken im Geschäft der Organisation reagiert.'' [KRS08, 45f]

Die Vorgehensweise für die Installation eines ISMS ist im BSI-Standard folgendermaßen beschrieben [Bu08a, 24ff]:

# Festlegung des Geltungsbereiches, für den das ISMS gelten soll
# Ermittlung von Rahmenbedingungen
# Formulierung von Sicherheitszielen und einer Leitlinie zur Informationssicherheit
# Aufbau einer Informationssicherheitsorganisation
Darüber hinaus ist die Einrichtung eines ISMS ein stetig andauernder Prozess, welcher sich in einen Plan-Do-Check-Act Kreiskauf darstellen lässt. Nach der Planung und Implementierung muss das ISMS regelmäßig inhaltlich überprüft werden und die aus der Überprüfung resultierten Erkenntnisse wiederum in die ursprüngliche Planung und damit in die eigentliche Umsetzung integriert werden. In der ISO 27001 ist dieser Kreislauf folgend ausformuliert [II08, 6]:

# '''Planen (Einrichten eines ISMS):''' Einrichten einer ISMS-Politik sowie von Zielen, Prozessen und Verfahren, die für das Risikomanagement und die Verbesserung der Informationssicherheit notwendig sind, um Ergebnisse im Einklang mit den übergeordneten Grundsätzen und Zielen der Organisation zu erreichen.
# '''Durchführen (Umsetzen und Durchführen des ISMS):''' Umsetzen und Durchführen der ISMS-Politik, Maßnahmen, Prozesse und Verfahren.
# '''Prüfen (Überwachen und Überprüfen des ISMS):''' Bewerten und gegebenenfalls Messen der Prozessleistung an der ISMS-Politik, den ISMS-Zielen und der praktischen Erfahrungen, sowie Berichten der Ergebnisse an das Management zur Überprüfung.
# '''Handeln (Instandhalten und Verbessern des ISMS):''' Ergreifen von Korrektur- und Vorbeugemaßnahmen, basierend auf den Ergebnissen interner ISMS-Audits und Management-Überprüfungen oder anderer wesentlicher Informationen, um eine ständige Verbesserung des ISMS zu erreichen.
Wichtige Teile eines ISMS sind daher auch das IT-Business Continuity Management und das IT-Risikomanagement, sowie die sich daraus ergebenden IT-Maßnahmenziele. Für die laufende Analyse, Kontrolle und Weiterentwicklung maßgebend ist das interne Kontrollsystem, welches mit geeigneten Methoden und Checklisten für die Schaffung und Einhaltung des gewünschten IT-Sicherheitsstandards sorgt.

== Business Kontinuität und Sicherheitszwischenfälle ==

Das IT-Business Continuity Management besteht aus dem IT-Notfallmanagement und dem IT-Verfügbarkeitsmanagement [Ha12, 149]. Seine Grundlage ist ein funktionierendes IT-Risikomanagement und entsprechende Risikoanalysen, welche wiederum auf den Geschäftsprozessen basieren.

''Das IT-Business Continuity Management (IT BCM) konzentriert sich als Teilbereich des Unternehmens-Business Continuity Managements auf diejenigen Arbeitsabläufe und Prozesse, die maßgeblich von IT-Systemen unterstützt werden.'' [Ha12, 151]

Der Output des IT-Business Continuity Managementprozesses ist der Business Continuity Plan (BCP). In diesem Plan werden konkrete Maßnahmenziele für die jeweiligen Prozesse der Business Impact Analyse (BIA) und den dazugehörigen Risiken aus der Analyse des Notfallmanagements und des Verfügbarkeitsmanagements definiert.

=== Business Impact Analyse (BIA) ===

Im Rahmen der Business Impact Analyse werden alle Geschäftsprozesse hinsichtlich ihrer Auswirkungen bei teilweisen, oder gänzlichen Ausfällen analysiert. Dadurch wird festgestellt, auf welche Prozesse im Business Continuity Plan ein besonderes Augenmerk gelegt werden muss und welche vernachlässigbar sind. Sie betrachtet noch keine Risiken im Detail, sondern nur die Auswirkungen des Ausfalls von Prozessen. Dabei werden alle Geschäftsprozesse und Prozessschritte analysiert und entsprechend bewertet.

Harich beschreibt die Durchführung einer Business Impact Analyse in 7 Phasen, welche der Prozessanalyse, sollten die Prozesse noch nicht bekannt sein, nachgestellt sind [Ha12, 156ff]:

* '''Phase 1 - Vorauswahl der Geschäftsprozesse''': Anfertigung einer priorisierten Liste der wichtigsten Prozesse, um weniger wichtige Prozesse aus der Betrachtung auszunehmen, insbesondere die Aussortierung von Prozessen, welche ohne Auswirkungen auf den Unternehmenserfolg für längere Zeit ausfallen dürfen.
* '''Phase 2 - Schadensanalyse''': Entstehender Schaden, wenn der analysierte Prozess die Prozessziele nicht erreicht. Es empfiehlt sich eine Staffelung nach Ausfallszeit, da die entstehenden Schäden meist von der Ausfallsdauer abhängen.
* '''Phase 3 - Festlegung Prozess Service Level Agreements''': Festlegung der maximal tolerierten Ausfallzeit und dem minimalen Wiederanlaufniveau, das ist die minimale Funktionalität die für den Bereich erforderlich ist, je Prozess.
* '''Phase 4 - Berücksichtigung von Abhängigkeiten''': Wenn Prozesse voneinander abhängig sind, dann müssen diese Abhängigkeiten erfasst werden und in die Analyse mit einfließen. So kann ein Prozess einen höheren Service Level benötigen, da ein anderer wichtigerer Prozess von ihm abhängig ist.
* '''Phase 5 - Priorisierung der Geschäftsprozesse''': Aufgrund der Erkenntnisse aus den Phasen 2 bis 4 werden nun die Prozesse erneut priorisiert und gegebenenfalls aus der weiteren Betrachtung ausgenommen. Auch wird definiert, ob in der weiteren Betrachtung ein komplettes Notfallmanagement, oder lediglich die Definition simpler Arbeitsabläufe im Rahmen des BCP notwendig ist.
* '''Phase 6 - Zuordnung von Werten''': Unter Werten werden hier die IT-Systeme verstanden, welche für das Funktionieren des Prozesses benötigt werden beziehungsweise verantwortlich sind. Da diese Zuordnung oft sehr komplex und aufwändig ist, wird empfohlen, sie nur für die wichtigsten Prozesse im Detail durchzuführen.
* '''Phase 7 - Festlegung Asset Service Level Agreements''': In der letzten Phase werden nun die maximalen Ausfallszeiten und Wiederanlaufzeiten für die in Phase 6 zugeordneten IT-Systeme bestimmt. Die Klassifizierung erfolgt dabei über die zugrundeliegenden Prozesse und deren definierten Parametern und Zeiten.
Für die Schadensanalyse in Phase 2 sind im BSI Standard folgende Schadenskategorien definiert [13, p. 37]:

* „niedrig“: Ausfall hat eine geringe, kaum spürbare Auswirkung
* „normal“: Ausfall hat spürbare Auswirkungen
* „hoch“: Ausfall hat erhebliche Auswirkungen
* „sehr hoch“: Ausfall oder Beeinträchtigung führen zu existenziell bedrohlichen Auswirkungen

=== IT-Notfallmanagement ===

''Das IT-Notfallmanagement hat die grundsätzliche Aufgabe, Methoden und Maßnahmen bereitzustellen, die zur schnellen Lösung einer Krisensituation dienen. Das IT-Notfallmanagement ist ein Sammelbegriff für alle Schritte von der Notfallvorsorge, Notfallübungen über den Notbetrieb bis hin zur Bewältigung eines Notfalls. Es umfasst die Definition von Verantwortlichkeiten, die Erstellung und Pflege von Notfallplänen und aller Maßnahmen, die im Rahmen von Notfällen abzuarbeiten sind.'' [Ha12, 163f]

Der Umfang des IT-Notfallmanagements ist ein sehr weitreichender. Die tatsächliche Anwendung ist hier jedoch stark von der Unternehmensgröße abhängig. So ist es in kleinen Unternehmen zwar ebenfalls erforderlich, Überlegungen zu allen Teilbereichen, wie beispielsweise der Notfallorganisation, zu treffen, die Komplexität ist jedoch wesentlich geringer. Es können daher einige Aspekte zusammengefasst betrachtet werden. Die Prozessschritte des Notfallmanagementprozesses laut IT-Grundschutz des BSI [Bu08d] sind in Abbildung "Notfallmanagement-Prozess" entsprechend ihrer Reihenfolge und ihrer Zusammenhänge dargestellt.

[[Datei:IT244 4.png|300px|none|thumb|Notfallmanagement-Prozess]]


Die in der Konzeption des Notfallmanagements zu erarbeitenden Punkte sind:

* '''Ablauforganisation''',
* '''Krisenkommunikation''' und
* '''Notfallhandbuch''' (Maßnahmenplan, Checklisten).

=== IT-Risikomanagement ===

Genauso wie das IT-Sicherheitsmanagement ist das IT-Risikomanagement ein stetiger Prozess. ''Auch nach Einführung eines Risikomanagementsystems für Informationssicherheit wird es keinen Tag X geben, an dem der CISO [Chief Information Security Officer] verkündet, ab jetzt sei alles sicher. Er wird höchstens sagen können, dass man auf Unsicherheit gezielt und planvoll reagieren kann und genau weiß, auf welche Risiken man sich einlassen will und auf welche lieber nicht.'' [Kl11, 25]

Das IT-Risikomanagement beschäftigt sich mit der Analyse und Bewertung der IT-Risiken innerhalb der Geschäftsprozesse. Grundlage des IT-Risikomanagements ist somit die Prozessanalyse und die Business-Impact-Analyse, da nicht nur die Eintrittswahrscheinlichkeit, sondern auch die möglichen Auswirkungen wesentlicher Bestandteil der Risikoanalyse sind.

Um die Risiken einzuschätzen ist Erfahrung mit den Geschäftsprozessen und den notwendigen IT-Systemen notwendig. Denn nur durch das aus dieser Erfahrung resultierende Wissen lässt sich die Existenz der Schwachstellen und Bedrohungen feststellen und die zugehörigen Risiken abschätzen. Obwohl die Einschätzung grundsätzlich mit entsprechender Prozess- und Technologieerfahrung möglich ist, werden viele Risiken ohne eine entsprechende Risikoanalyse oft nicht erkannt, da es zusätzlich zu dem möglichen Wissen notwendig ist, sich im Rahmen der Risikoanalyse lückenlos mit dem Prozess auseinanderzusetzen.

Bei dieser Art der Risikoanalyse handelt es sich um den kombinierten Ansatz nach dem Österreichischen Informationssicherheitshandbuch [Ze13, 97]. Hier wird anhand der Schutzbedarfsfeststellung der Business-Impact-Analyse festgelegt, welche Risiken einer detaillierten Analyse (hohe Auswirkung) bedürfen und bei welchen auf einen hohen Detaillierungsgrad verzichtet werden kann (niedrige und mittlere Auswirkung) und eine Grundschutzanalyse ausreichend ist. Die Vorgehensweisen bei diesen beiden Analysearten werden nachfolgend genauer beschrieben.

==== Detaillierte Risikoanalyse ====

Die betroffenen Prozesse aus der Business-Impact-Analyse werden nun einer Bedrohungsanalyse und einer Schwachstellenanalyse unterzogen. Dabei wird betrachtet, welche möglichen Bedrohungen zu einer Störung des Prozesses führen können und welche Schwachstellen im Prozess oder seiner IT-Unterstützung diese Bedrohungen begünstigen können. Danach werden die bereits bestehenden Sicherheitsmaßnahmen analysiert und ihr aktueller Nutzen und die korrekte Funktion bewertet. Sobald alle Risiken bekannt sind, werden sie hinsichtlich ihrer Eintrittswahrscheinlichkeit und des möglichen Schadens bewertet und ein Gesamtrisiko berechnet. [Ze13, 97ff]

Um keine mögliche Bedrohung zu übersehen empfiehlt es sich, mit einer Checkliste zu arbeiten, die eine lückenlose Betrachtung aller möglichen Bedrohungstypen oder Kategorien ermöglicht.

Um mit den bewerteten Risiken nun vergleichbare Berechnungen durchführen zu können, werden die Faktoren dabei mit nummerischen Werten für beispielsweise „Niedrig“ bis „Sehr hoch“ beschrieben [Ha12, 304]:

* Niedrig (Wert 1)
* Mittel (Wert 2)
* Hoch (Wert 3)
* Sehr hoch (Wert 4)
Die gängigste und gleichzeitig einfachste Formel zur Berechnung der Risiken ist:

<math display="block">Risiko = Schaden*Eintrittswahrscheinlichkeit</math>

Da jedoch auch die bestehenden Maßnahmen in die Analyse einfließen, wird die Formel in der detaillieren Risikoanalyse um den Faktor <math display="inline">Ma\text{ß}nahmen</math> erweitert, welcher die Eintrittswahrscheinlichkeit wieder verringert:

<math display="block">Risiko = Schaden*(Eintrittswahrscheinlichkeit - Ma\text{ß}nahmen)</math>

Hier wird nicht das bloße Vorhandensein, sondern die Qualität der Maßnahmen bewertet. [Ha12, 301]

Die oben genannte Formel berücksichtigt nur Maßnahmen, welche die Eintrittswahrscheinlichkeit minimieren. Es kann jedoch auch Maßnahmen geben, mit denen der entstehende Schaden gesenkt werden kann. So senkt beispielsweise eine unterbrechungsfreie Notstromversorgung die Eintrittswahrscheinlichkeit eines stromausfallbedingten IT-Systemausfalls, eine automatische Löschanlage in einem Serverraum minimiert hingegen den möglichen Schaden bei einem Brand, nicht aber die Eintrittswahrscheinlichkeit des Brandes. Die endgültige Formel wird daher noch um den Faktor der Schadensminimierenden Maßnahmen erweitert:

<math display="block">Risiko = \left( Schaden - M_{\text{Schaden}} \right)*(Eintrittswahrscheinlichkeit - M_{\text{Eintritt}})\ </math>

Um nun die Risikoanalyse übersichtlich und gut sortiert darzustellen, können, die Risiken auch in Form einer Risikomatrix dargestellt werden. Dabei empfiehlt sich die Risikomatrix gemäß der '''ALARP (As Low As Reasonably Practicable)''' [Kl11, 150f] Methode darzustellen. Die Achsen der Matrix sind hierbei die Eintrittswahrscheinlichkeit und der Schaden, welche in der hier angeführten Analyse noch um die Qualität der jeweiligen Maßnahmen reduziert wurden. Die daraus entstehende Matrix ist in Tabelle "ALARP Risikomatrix" dargestellt. Sie orientiert sich an der von Klipper [Kl11, 151] beschrieben Darstellung und berücksichtigt die Werte Niedrig bis Hoch der oben genannten Bewertung. Der grün dargestellte Bereich ist dabei der „akzeptable Bereich“. Alle hier eingeordneten Risiken müssen nicht weiter behandelt werden. Die Risiken im „ALARP-Bereich“ werden nur behandelt, wenn sie mit sehr einfachen Maßnahmen in den grünen Bereich gebracht werden können. Sie sind somit vorhanden, können aber noch akzeptiert werden. Eine besondere Betrachtung erfordern nur die Risiken im roten „inakzeptablen“ Bereich. Hier müssen Maßnahmen gesetzt werden, die dafür geeignet sind, die Faktoren so weit zu beeinflussen, damit die Risiken in den ALARP Bereich wechseln.
[[file:img1643143624475.png|300px|alt=ALARP Risikomatrix|none|thumb|ALARP Risikomatrix]]
==== Grundschutzansatz Risikoanalyse ====

''Ziel des Grundschutzansatzes ist es, den Aufwand für die Erstellung eines Informationssicherheitskonzeptes angemessen zu begrenzen.'' [Ze13, 110]

Bei der Grundschutzanalyse wird das IT-System anhand von vorhandenen Bausteinen möglichst genau nachmodelliert. Danach werden die vorhanden Maßnahmen mit den empfohlenen Maßnahmen in Form eines Soll-Ist-Vergleichs verglichen und daraus das weitere Vorgehen abgeleitet. Die einzelnen Bausteine für die Modellierung definieren sich durch die IT-Grundschutz Standards des BSI [Bu13]. Die einzelnen Module sind, der einfacheren Betrachtung halber, in einzelne Schichten gegliedert. Die unterschiedlichen Schichten und der aus Ihnen abgeleitete Aufbau des IT-Systems sind in Abbildung "Schichten des IT-Grundschutz Modells" dargestellt.

[[Datei:IT244 5.png|300px|none|thumb|Schichten des IT-Grundschutz Modells ]]


Aus den empfohlenen Maßnahmen des jeweiligen Bausteines ergeben sich die Soll-Parameter für das IT-System. Es wird dabei grundsätzlich nicht auf die beiden Faktoren Schaden und Eintrittswahrscheinlichkeit eingegangen, da dies bereits durch die Konzeption des Grundschutzstandards global berücksichtigt wurde. Bei Abweichungen des Ist-Systems müssen entweder Maßnahmen getroffen werden um die Lücke zu füllen, oder die Abweichung mit einer entsprechenden Begründung akzeptiert werden.

=== IT-Maßnahmenziele ===

Anhand der Ergebnisse der Risikoanalyse werden nun Maßnahmenziele abgeleitet, um entweder das jeweilige Modul des TI-Grundschutz-Modells zu erfüllen, oder um die in der detaillierten Risikoanalyse ermittelten Risiken auf einen akzeptierten Level zu bringen.

Bevor eine vollkommen neue Maßnahme eingeführt wird, empfiehlt es sich mögliche bereits vorhandene Maßnahmen hinlänglich ihrer Erweiterbarkeit und Verbesserbarkeit zu überprüfen [Ha12, 314], da es sich dabei meist um die schnellste und günstigste Lösung handeln wird.

Die ISO/IEC 27001 definiert im Anhang B [II08, 20ff] folgende Kategorien möglicher Maßnahmenziele:

* Sicherheitspolitik,
* Organisation der Informationssicherheit,
* Management von Vermögenswerten,
* Personelle Sicherheit,
* Physische und umgebungsbezogene Sicherheit,
* Management der Kommunikation des Betriebes,
* Zugriffskontrolle,
* Beschaffung, Entwicklung und Wartung von Informationssystemen,
* Management von Informationssicherheits-Vorfällen,
* Betriebliches Kontinuitätsmanagement (Business Continuity Management) sowie
* Einhaltung von Verpflichtungen.
Die Maßnahmenziele müssen für die eigenen Prozesse ausdefiniert werden und stehen dann als Maßnahmenkatalog zur Begegnung mit den festgestellten Risiken zur Verfügung.

== Wiederholungsaufgaben/Übungen ==

'''1 Erklären Sie, worin sich die Begriffe Informationssicherheit, IT-Sicherheit und Datenschutz unterscheiden.'''

'''2 Was ist die CIA-Triade? Erklären Sie kurz was genau unter C, I und A verstanden wird.'''

'''3 Welche Kontrollmechanismen gibt es, um die Ziele der CIA-Triade analysieren zu können?'''

'''4 Was versteht man unter Schwachstellen, Bedrohungen und Maßnahmen und wie hängen sie zusammen?'''

'''5 Zählen Sie wesentliche Standards der Informationssicherheit auf und erläutern Sie kurz ihre Herkunft und ihren Zweck.'''

'''6 Sie sind mit der Durchführung eines Projektes zur Einführung von Informationssicherheit im Unternehmen beauftragt. Welches System werden Sie dazu einführen und was muss nach Projektende unbedingt beachten werden und warum?'''

'''7 Erklären Sie kurz den Begriff des IT-Business Continuity Managements. Welche Analysemaßnahmen müssen darin durchgeführt werden und wie hängen sie zusammen?'''

'''8 Wie funktioniert eine Risikoanalyse nach dem Grundschutzansatz?'''

Computer- und Netzwerksicherheit - Grundlagen

2023-08-10T16:17:57Z

VÖLKL Peter:

= Grundlagen der Informationssicherheit =

== Einleitung ==

Die Sicherheit der Informationstechnologie ist ein wesentlicher Bestandteil der Unternehmenssicherheit, da viele Prozesse einer intensiven IT-Unterstützung bedürfen und ohne sie nicht mehr, oder nur teilweise, funktionieren können. Es ist daher enorm wichtig, die möglichen Risiken zu kennen und diese, bezugnehmend auf die einzelnen Unternehmensprozesse, bewerten zu können. So umfangreich die Informationssysteme eines Unternehmens sind, so umfangreich sind auch die zu beachtenden Angriffsvektoren, sowie die Szenarien für Datenverlust, Nichtverfügbarkeit und Datendiebstahl. Die Computer- und Netzwerksicherheit ist ein wesentlicher Bestandteil der Informationssicherheit und greift in jede erdenkliche Materie der Informationstechnologie ein.

Die Zwischenfälle im IT-Sicherheitsbereich nahmen in den letzten Jahren immer mehr zu. Einer Statistik der Internet-Sicherheitslage in Österreich von CERT.at und GovCERT.gv.at zufolge ist die Anzahl der IT-Sicherheitszwischenfälle von unter 10 pro Monat im Jahr 2009 auf konstant über 500 pro Monat ab Ende des Jahres 2012 gestiegen. Gegen Ende 2013 kann sogar von 1000 Zwischenfällen pro Monat ausgegangen werden, die Tendenz ist weiterhin steigend. [Ni13, 13]

== Informations- und IT-Sicherheit ==

Rund um den Bereich der IT-Sicherheit gibt es viele, oft falsch verstandene Begrifflichkeiten wie Datenschutz, Datensicherheit und Informationssicherheit [Ha12, 28]. Nachfolgend werden diese Begriffe nun kurz beschrieben, um einen Überblick über die Materie zu verschaffen.

=== Informationssicherheit ===

Bei der Informationssicherheit handelt es sich um die ganzheitliche Betrachtung der Sicherheit und den Schutz aller Art von Informationen. Dabei ist es nicht relevant, ob diese Informationen in elektronischer oder nicht elektronischer Form vorliegen.

=== IT-Sicherheit ===

Die IT-Sicherheit ist Teil der Informationssicherheit (siehe Abbildung "Schnittmenge Informations-Sicherheit und IT-Sicherheit"). Sie beschäftigt sich mit dem Schutz aller Art von elektronischer Information. Das beinhaltet alle EDV und Kommunikationssysteme, wie Computer, Internetverbindungen und Netzwerke, Telefonie und die für den Betrieb der Systeme zugrundeliegende Infrastruktur wie beispielsweise die Stromversorgung.

[[Datei:IT244 1.png|300px|none|thumb|Schnittmenge Informations-Sicherheit und IT-Sicherheit ]]


=== Datenschutz und Datensicherheit ===

Der Datenschutz regelt den Schutz personenbezogener Daten, welche in elektronischer Form vorliegen. In Österreich ist der Datenschutz sowohl in einem Bundesgesetz (DSG), als auch in 9 Landesgesetzen geregelt.

''Jedermann hat, insbesondere auch im Hinblick auf die Achtung seines Privat- und Familienlebens, Anspruch auf Geheimhaltung der ihn betreffenden personenbezogenen Daten, soweit ein schutzwürdiges Interesse daran besteht. Das Bestehen eines solchen Interesses ist ausgeschlossen, wenn Daten infolge ihrer allgemeinen Verfügbarkeit oder wegen ihrer mangelnden Rückführbarkeit auf den Betroffenen einem Geheimhaltungsanspruch nicht zugänglich sind.'' [Bg19, § 1. (1)]

Die Einhaltung des Datenschutzes ist Teil der Informationssicherheit bzw. IT-Sicherheit und damit des IT-Sicherheitsmanagements. Die beiden Begrifflichkeiten werden jedoch oft vermischt oder verwechselt. So ist der Datenschutz selbst nur ein kleiner Teilbereich. IT-Sicherheit betrachtet wesentlich mehr als den Schutz personenbezogener Daten und bezieht sich auf alle Unternehmensprozesse und ihre IT-Unterstützung.

== Säulen der Informationssicherheit - CIA Triade ==

Die IT-Sicherheit und damit das IT-Sicherheitsmanagement basieren auf drei Säulen, welche den zu betrachtenden Rahmen aller durchzuführenden Analysen und den damit verbundenen Maßnahmen darstellen. Sie tragen somit bildlich das Dach der IT-Sicherheit und sorgen nur in ihrer gemeinsamen Betrachtung für die Stabilität und Sicherheit des gesamten IT-Sicherheits-Systems. Ihr Fundament ist das IT-Sicherheitsbewusstsein und die damit verbundene Bewusstseinsbildung ist die notwendige Maßnahme (siehe Abbildung "Aufbau der IT-Sicherheit").

Die drei Säulen sind:

* Vertraulichkeit (Confidentiality),
* Integrität (Integrity) und
* Verfügbarkeit (Availability).
[[Datei:IT244 2.png|300px|none|thumb|Aufbau der IT-Sicherheit]]


Die drei Säulen der IT-Sicherheit werden oft auch als „CIA-Triade“ <ref>Der genaue Ursprung der „CIA-Triade“ ist nicht genau feststellbar. Die zugrundeliegenden Konzepte waren bereits vor Jahrtausenden im militärischen Kontext bekannt. Sie befinden sich beispielsweise in den Werken „Commentarii de bello Gallico“ [Ca58] des römischen Feldherren Gaius Julius Cäsar.</ref> oder „AIC-Principles“ bezeichnet, da die englischen Bezeichnungen mit den Buchstaben C, I und A beginnen.

=== Vertraulichkeit (Confidentiality) ===

Unter Vertraulichkeit wird die Einschränkung der Datenzugriffe auf einen bestimmten Anwenderkreis verstanden. Unberechtigte dürfen keinen Zugriff auf die IT-Systeme und Daten haben. Dies sind beispielsweise die Absicherung des gesamten Systems vor IT-Zugriffen unberechtigter Dritter und aber auch die Definition unterschiedlicher Berechtigungsstufen innerhalb der berechtigten Anwender. So sollte es beispielsweise einem Anwender erlaubt sein, die benötigten Programme zu starten, nicht jedoch neue Software zu installieren oder die gesamte Datenbank zu kopieren.

Je nach System kann die Vertraulichkeit über Benutzer- und Programm-Berechtigungen und auch physische Zutrittskontrolle sichergestellt werden. Die hier gesetzten Maßnahmen sind jene Maßnahmen, welche am häufigsten mit IT-Sicherheit in Zusammenhang gebracht werden, jedoch ohne Betrachtung der anderen beiden Bereiche Integrität und Verfügbarkeit nicht vollständig sind.

=== Integrität (Integrity) ===

Die Integrität ist die Betrachtung des Datenbestandes im Zusammenhang mit allen verfügbaren, und nicht verfügbaren, Daten. Innerhalb des Datenbestandes muss sichergestellt werden, dass die Daten selbst vollständig, unverfälscht, korrekt zusammenhängend und nicht widersprüchlich sind. Das bedeutet, dass der Datenbestand lückenlos sein muss und das Fehlen von Daten ersichtlich sein muss. Auch darf durch die Nichtverfügbarkeit einzelner Daten keine Kettenreaktion auf andere Daten ausgelöst werden, welche wiederum zu weiteren falschen Daten führen würde.

Ein Beispiel hierfür ist das Fehlen von Messwerten eines über das Netzwerk angebundenen Medizinproduktes, welches für eine gewisse Zeit durch eine Störung nicht korrekt angebunden war. Wird dieses Lückenproblem nicht korrekt vom darüberlegenden IT-System behandelt, könnten hierbei falsche Durchschnittswerte entstehen, welche wiederum zu einem falschen Diagnosevorschlag führen würden.

=== Verfügbarkeit (Availability) ===

Bei der Verfügbarkeit wird die Funktionsbereitschaft der IT-Systeme zu den Zeitpunkten bezeichnet, zu denen sie benötigt werden. Dabei handelt es sich um alle Maßnahmen gegen Ausfälle oder Datenverlust. Hierbei ist es auch erforderlich den Zusammenhang zwischen den Systemen zu betrachten, da der Ausfall eines als unwichtig erscheinenden Systems andere wichtige Systeme beeinträchtigen könnte.

So kann beispielsweise der Ausfall eines Dateiservers als wenig wichtig eingestuft werden, da die Daten in den Kernprozessen nicht unmittelbar im Zugriff sein müssen. Wenn hingegen eine wichtige Software des Kernprozesses seine Logdateien auf genau diesen Dateiserver ablegen muss, wird die anfangs als unwichtig eingestufte Dateiablage auf einmal zu einer kritischen Komponente, da sonst wiederum die Integrität gefährdet wäre.

=== Kontrollmechanismen ===

Rund um die CIA-Triade sind drei Kontrollmechanismen definiert, um ihre grundsätzlichen Ziele im Detail analysieren zu können [Fr13, 29]:

* '''Physische Kontrolle''': Schutz der IT-Systeme vor physischem Zugriff durch Maßnahmen wie Zäune, Schlösser und Wachpersonal.
* '''Technische Kontrolle''': Schutz der IT-Systeme und Daten vor technischen Zugriffen über Netzwerke und Anwenderzugriffe. Beispielsweise durch Benutzerberechtigungen, Firewalls, Datenverschlüsselung und das Verhindern des Betriebs von unerlaubten IT-Komponenten im eigenen IT-System.
* '''Administrative Kontrolle''': Installation, Schulung und Kontrolle von IT-Sicherheitsprozessen und IT-Sicherheitsmanagement und allen damit verbundenen Richtlinien und Vorgaben und die Einhaltung der damit verbundenen Gesetzlichen Vorgaben.

=== Risiko- und Schwachstelleneinteilung der Schutzziele ===

Um eine einheitliche Betrachtung und Maßnahmensetzung zu ermöglichen sollten alle Risiken gemäß der Schutzziele der CIA-Triade kategorisiert werden. Eine Einteilung in mehrere Kategorien ist in einigen Fällen möglich, jedoch nicht immer voll abgrenzbar [Ha12, 267]. Im Rahmen der Analyse sollte jedoch stets darauf geachtet werden, eine mögliche Einstufung in jeder der drei Säulen zu bedenken. So kann beispielsweise das Risiko einer Schadsoftware mehr als einem Schutzziel zugeordnet werden, da sie sowohl die Integrität als auch die Verfügbarkeit und die Vertraulichkeit gefährden kann [Ha12, 268].

Bei der Analyse der Risiken werden mögliche Schwachstellen der Schutzziele aufgedeckt, welche wiederum zu möglichen Bedrohungen führen. Daraus ergeben sich dann die dafür notwendigen Maßnahmen. Zwischen diesen drei Bereichen bestehen nun einige direkte Abhängigkeiten, die sich jedoch auch oft überschneiden können. Das bedeutet, dass eine Schwachstelle mehrere Risiken bedingen kann und mehreren Risiken durch eine einzelne Maßnahme begegnet werden kann. Abbildung "Zusammenhang von Schwachstellen, Bedrohungen und abgeleiteten Maßnahmen" beschreibt die hier erwähnten Zusammenhänge anhand einiger Beispiele aus dem Softwarebereich:

[[file:img1643450062206.png|300px|none|thumb|Zusammenhang von Schwachstellen, Bedrohungen und abgeleiteten Maßnahmen]]

Die möglichen Bedrohungen durch das Ausnutzen von Schwachstellen werden oft auch als '''Angriffsvektoren''' bezeichnet. Ein Angriffsvektor ist dabei der Weg, den ein Angreifer wählen kann um sein jeweiliges Angriffsziel zu erreichen.

== Informationssicherheits-Standards ==

Die IT-Sicherheit und die Einführung und der Aufbau von IT-Sicherheits-Management-Systemen sind in unterschiedlichen Normen und Standards geregelt, die teilweise aufeinander aufbauen oder referenzieren.

Die wesentlichen drei Standards sind:

* die ISO/IEC 2700x Reihe,
* IT-Grundschutz-Standards des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und
* das Österreichische Informationssicherheitshandbuch.

=== ISO/IEC 2700x Reihe ===

Eine Reihe verbreiteter internationaler Informationssicherheits-Standards ist die ISO/IEC 2700x Reihe. Sie wurde von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) begründet und wird stetig ausgebaut.

Das Basisdokument der Reihe ist die ISO/IEC 27000 [Is14] (Informationstechnologie, Sicherheitstechnik, Informationssicherheits-Managementsysteme). Sie definiert die Grundbegriffe und bietet einen Gesamtüberblick. Einige Teile der Reihe wurden von Standards der British Standards Institution (BSI) abgeleitet.

Die grundlegenden Teile der ISO/IEC 2700x sind:

* ISO/IEC 27001 bis 27004: Definition, Betrieb und Kontrolle von Informationssicherheits-Managementsystemen (ISMS) und
* ISO/IEC 27005: Informationssicherheits-Risikomanagement.
Die weiteren Teile beschäftigen sich mit dem Audit und branchenspezifischen und technischen Ausprägungen der ersten fünf Standards. Ein Beispiel dafür ist die EN ISO 27799, welche sich auf das Sicherheitsmanagement im Gesundheitswesen bezieht.

=== IT-Grundschutz-Standards des Bundesamtes für Sicherheit in der Informationstechnik (BSI) ===

Der BSI IT-Grundschutz Standard teilt sich in mehrere Dokumente. Er wird durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) der Bundesrepublik Deutschland stetig weiterentwickelt und herausgegeben.

Die Teile des IT-Grundschutz sind:

* BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) [Bu08a],
* BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise [Bu08b],
* BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz [Bu08c] und
* BSI-Standard 100-4: Notfallmanagement [Bu08d].
Bei allen BSI Standards handelt es sich um Empfehlungen zu Methoden, Prozessen und Verfahren der Informationssicherheit. Die Standards dienen der fachlichen Unterstützung von Anwendern der Informationstechnik und bieten die Möglichkeit, entweder die Empfehlungen direkt zu verwenden oder diese erforderlichenfalls an die eigenen Bedürfnisse anzupassen. [Bu15]

=== Österreichisches Informationssicherheitshandbuch ===

Beim Österreichisches Informationssicherheitshandbuch [Ze13] handelt es sich um ein vom Österreichischen Bundeskanzleramt herausgegebenes Werk, welches teilweise auf bestehenden Standards und Normen wie den BSI IT-Grundschutz und die ISO/IEC 2700x aufbaut und Vorgehensweisen für den Aufbau und Betrieb von Informationssicherheit-Management-Systemen. Die Struktur entspricht dabei derer der ISO/IEC 27001 und ISO/IEC 27002.

Das Informationssicherheitshandbuch beschreibt seine eigene Ausrichtung und Umfang wie folgt: ''Von der Ausrichtung versteht sich das Informationssicherheitshandbuch […] als Sammlung von Leitlinien und Empfehlungen für die Praxis, die entsprechend den spezifischen Anforderungen und Bedürfnissen in einer Einsatzumgebung angepasst werden müssen. Dies wird auch durch die Online-Funktionalitäten wie Checklisten unterstützt. Es soll eine Ergänzung zu den bestehenden Regelungen und Vorschriften (Datenschutzgesetz, Informationssicherheitsgesetz, Verschlusssachenvorschriften, Amtsgeheimnis, …) darstellen und setzt diese weder außer Kraft noch steht es zu ihnen im Widerspruch.'' [Ze13, 27]

== Informationssicherheits-Management ==

''IT-Security ist keine Software, kein Werkzeug und auch kein Zustand. IT-Security ist ein Prozess!'' [KRS08, 401]

Dieser Satz beschreibt die grundlegende Definition bereits ganz gut. Um IT-Sicherheit einzuführen benötigt es keiner einzelnen Produkte oder reiner persönlicher Ansichten, sondern einen unterstützenden Unternehmensprozess des IT-Sicherheitsmanagements. Es kann dabei nicht als eigenständiges Vorhaben betrachtet werden, sondern gliedert sich in die Betrachtung aller Geschäftsprozesse mit ein. Ein wesentlicher Fehler wäre es, sie Einführung von IT-Sicherheit als zeitlich begrenztes Projekt abzuwickeln, ohne danach einen funktionierenden Managementprozess zu haben, der sich um die Aufrechterhaltung und stetige Verbesserung des IT-Sicherheitsstatus kümmert.

Der Schutz von Informationen und Daten ist auch für kleine und mittlere Unternehmen von großer Bedeutung, ''da für diese ein entsprechender Verlust von Daten oder deren Manipulation, sehr rasch, ein existenzbedrohendes Potential annehmen kann.'' [Fr13, 8]

Die Implementierung eines durchgängigen und effizienten IT-Sicherheitsmanagements bedarf detailliertes Wissen über das betreffende Unternehmen und Fachkompetenz im Bereich der IT und IT-Sicherheit. Durch standardisierte Methoden und vormodellierte interne Kontrollsysteme kann es jedoch ermöglicht werden, den operativen Teil des IT-Sicherheitsmanagements durch Spezialisten der Geschäftsprozesse mit IT-Basiswissen durchzuführen.

Um IT-Sicherheitsmanagement in einem Unternehmen zu implementieren, wird ein '''IT-Sicherheitsmanagement-System (ISMS)''' aufgesetzt. Dieses System ist die Grundlage des IT-Sicherheitsprozesses, welcher, als Managementprozess, wiederum durch entsprechende Prozessnahtstellen Teil aller Unternehmensprozesse ist.

''Ein ISMS ist ein Teil eines allgemeineren, umfassenderen Management-Systems, das andere Teile der Organisation, möglicherweise die gesamte Organisation, und weitere Themen umfasst. Das ISMS baut auf der Einschätzung der Geschäftsrisiken auf. Ein ISMS sollte daher als ein Mittel verstanden werden, mit dem das Management einer Organisation auf erkannte Risiken im Geschäft der Organisation reagiert.'' [KRS08, 45f]

Die Vorgehensweise für die Installation eines ISMS ist im BSI-Standard folgendermaßen beschrieben [Bu08a, 24ff]:

# Festlegung des Geltungsbereiches, für den das ISMS gelten soll
# Ermittlung von Rahmenbedingungen
# Formulierung von Sicherheitszielen und einer Leitlinie zur Informationssicherheit
# Aufbau einer Informationssicherheitsorganisation
Darüber hinaus ist die Einrichtung eines ISMS ein stetig andauernder Prozess, welcher sich in einen Plan-Do-Check-Act Kreiskauf darstellen lässt. Nach der Planung und Implementierung muss das ISMS regelmäßig inhaltlich überprüft werden und die aus der Überprüfung resultierten Erkenntnisse wiederum in die ursprüngliche Planung und damit in die eigentliche Umsetzung integriert werden. In der ISO 27001 ist dieser Kreislauf folgend ausformuliert [II08, 6]:

# '''Planen (Einrichten eines ISMS):''' Einrichten einer ISMS-Politik sowie von Zielen, Prozessen und Verfahren, die für das Risikomanagement und die Verbesserung der Informationssicherheit notwendig sind, um Ergebnisse im Einklang mit den übergeordneten Grundsätzen und Zielen der Organisation zu erreichen.
# '''Durchführen (Umsetzen und Durchführen des ISMS):''' Umsetzen und Durchführen der ISMS-Politik, Maßnahmen, Prozesse und Verfahren.
# '''Prüfen (Überwachen und Überprüfen des ISMS):''' Bewerten und gegebenenfalls Messen der Prozessleistung an der ISMS-Politik, den ISMS-Zielen und der praktischen Erfahrungen, sowie Berichten der Ergebnisse an das Management zur Überprüfung.
# '''Handeln (Instandhalten und Verbessern des ISMS):''' Ergreifen von Korrektur- und Vorbeugemaßnahmen, basierend auf den Ergebnissen interner ISMS-Audits und Management-Überprüfungen oder anderer wesentlicher Informationen, um eine ständige Verbesserung des ISMS zu erreichen.
Wichtige Teile eines ISMS sind daher auch das IT-Business Continuity Management und das IT-Risikomanagement, sowie die sich daraus ergebenden IT-Maßnahmenziele. Für die laufende Analyse, Kontrolle und Weiterentwicklung maßgebend ist das interne Kontrollsystem, welches mit geeigneten Methoden und Checklisten für die Schaffung und Einhaltung des gewünschten IT-Sicherheitsstandards sorgt.

== Business Kontinuität und Sicherheitszwischenfälle ==

Das IT-Business Continuity Management besteht aus dem IT-Notfallmanagement und dem IT-Verfügbarkeitsmanagement [Ha12, 149]. Seine Grundlage ist ein funktionierendes IT-Risikomanagement und entsprechende Risikoanalysen, welche wiederum auf den Geschäftsprozessen basieren.

''Das IT-Business Continuity Management (IT BCM) konzentriert sich als Teilbereich des Unternehmens-Business Continuity Managements auf diejenigen Arbeitsabläufe und Prozesse, die maßgeblich von IT-Systemen unterstützt werden.'' [Ha12, 151]

Der Output des IT-Business Continuity Managementprozesses ist der Business Continuity Plan (BCP). In diesem Plan werden konkrete Maßnahmenziele für die jeweiligen Prozesse der Business Impact Analyse (BIA) und den dazugehörigen Risiken aus der Analyse des Notfallmanagements und des Verfügbarkeitsmanagements definiert.

=== Business Impact Analyse (BIA) ===

Im Rahmen der Business Impact Analyse werden alle Geschäftsprozesse hinsichtlich ihrer Auswirkungen bei teilweisen, oder gänzlichen Ausfällen analysiert. Dadurch wird festgestellt, auf welche Prozesse im Business Continuity Plan ein besonderes Augenmerk gelegt werden muss und welche vernachlässigbar sind. Sie betrachtet noch keine Risiken im Detail, sondern nur die Auswirkungen des Ausfalls von Prozessen. Dabei werden alle Geschäftsprozesse und Prozessschritte analysiert und entsprechend bewertet.

Harich beschreibt die Durchführung einer Business Impact Analyse in 7 Phasen, welche der Prozessanalyse, sollten die Prozesse noch nicht bekannt sein, nachgestellt sind [Ha12, 156ff]:

* '''Phase 1 - Vorauswahl der Geschäftsprozesse''': Anfertigung einer priorisierten Liste der wichtigsten Prozesse, um weniger wichtige Prozesse aus der Betrachtung auszunehmen, insbesondere die Aussortierung von Prozessen, welche ohne Auswirkungen auf den Unternehmenserfolg für längere Zeit ausfallen dürfen.
* '''Phase 2 - Schadensanalyse''': Entstehender Schaden, wenn der analysierte Prozess die Prozessziele nicht erreicht. Es empfiehlt sich eine Staffelung nach Ausfallszeit, da die entstehenden Schäden meist von der Ausfallsdauer abhängen.
* '''Phase 3 - Festlegung Prozess Service Level Agreements''': Festlegung der maximal tolerierten Ausfallzeit und dem minimalen Wiederanlaufniveau, das ist die minimale Funktionalität die für den Bereich erforderlich ist, je Prozess.
* '''Phase 4 - Berücksichtigung von Abhängigkeiten''': Wenn Prozesse voneinander abhängig sind, dann müssen diese Abhängigkeiten erfasst werden und in die Analyse mit einfließen. So kann ein Prozess einen höheren Service Level benötigen, da ein anderer wichtigerer Prozess von ihm abhängig ist.
* '''Phase 5 - Priorisierung der Geschäftsprozesse''': Aufgrund der Erkenntnisse aus den Phasen 2 bis 4 werden nun die Prozesse erneut priorisiert und gegebenenfalls aus der weiteren Betrachtung ausgenommen. Auch wird definiert, ob in der weiteren Betrachtung ein komplettes Notfallmanagement, oder lediglich die Definition simpler Arbeitsabläufe im Rahmen des BCP notwendig ist.
* '''Phase 6 - Zuordnung von Werten''': Unter Werten werden hier die IT-Systeme verstanden, welche für das Funktionieren des Prozesses benötigt werden beziehungsweise verantwortlich sind. Da diese Zuordnung oft sehr komplex und aufwändig ist, wird empfohlen, sie nur für die wichtigsten Prozesse im Detail durchzuführen.
* '''Phase 7 - Festlegung Asset Service Level Agreements''': In der letzten Phase werden nun die maximalen Ausfallszeiten und Wiederanlaufzeiten für die in Phase 6 zugeordneten IT-Systeme bestimmt. Die Klassifizierung erfolgt dabei über die zugrundeliegenden Prozesse und deren definierten Parametern und Zeiten.
Für die Schadensanalyse in Phase 2 sind im BSI Standard folgende Schadenskategorien definiert [13, p. 37]:

* „niedrig“: Ausfall hat eine geringe, kaum spürbare Auswirkung
* „normal“: Ausfall hat spürbare Auswirkungen
* „hoch“: Ausfall hat erhebliche Auswirkungen
* „sehr hoch“: Ausfall oder Beeinträchtigung führen zu existenziell bedrohlichen Auswirkungen

=== IT-Notfallmanagement ===

''Das IT-Notfallmanagement hat die grundsätzliche Aufgabe, Methoden und Maßnahmen bereitzustellen, die zur schnellen Lösung einer Krisensituation dienen. Das IT-Notfallmanagement ist ein Sammelbegriff für alle Schritte von der Notfallvorsorge, Notfallübungen über den Notbetrieb bis hin zur Bewältigung eines Notfalls. Es umfasst die Definition von Verantwortlichkeiten, die Erstellung und Pflege von Notfallplänen und aller Maßnahmen, die im Rahmen von Notfällen abzuarbeiten sind.'' [Ha12, 163f]

Der Umfang des IT-Notfallmanagements ist ein sehr weitreichender. Die tatsächliche Anwendung ist hier jedoch stark von der Unternehmensgröße abhängig. So ist es in kleinen Unternehmen zwar ebenfalls erforderlich, Überlegungen zu allen Teilbereichen, wie beispielsweise der Notfallorganisation, zu treffen, die Komplexität ist jedoch wesentlich geringer. Es können daher einige Aspekte zusammengefasst betrachtet werden. Die Prozessschritte des Notfallmanagementprozesses laut IT-Grundschutz des BSI [Bu08d] sind in Abbildung "Notfallmanagement-Prozess" entsprechend ihrer Reihenfolge und ihrer Zusammenhänge dargestellt.

[[Datei:IT244 4.png|300px|none|thumb|Notfallmanagement-Prozess]]


Die in der Konzeption des Notfallmanagements zu erarbeitenden Punkte sind:

* '''Ablauforganisation''',
* '''Krisenkommunikation''' und
* '''Notfallhandbuch''' (Maßnahmenplan, Checklisten).

=== IT-Risikomanagement ===

Genauso wie das IT-Sicherheitsmanagement ist das IT-Risikomanagement ein stetiger Prozess. ''Auch nach Einführung eines Risikomanagementsystems für Informationssicherheit wird es keinen Tag X geben, an dem der CISO [Chief Information Security Officer] verkündet, ab jetzt sei alles sicher. Er wird höchstens sagen können, dass man auf Unsicherheit gezielt und planvoll reagieren kann und genau weiß, auf welche Risiken man sich einlassen will und auf welche lieber nicht.'' [Kl11, 25]

Das IT-Risikomanagement beschäftigt sich mit der Analyse und Bewertung der IT-Risiken innerhalb der Geschäftsprozesse. Grundlage des IT-Risikomanagements ist somit die Prozessanalyse und die Business-Impact-Analyse, da nicht nur die Eintrittswahrscheinlichkeit, sondern auch die möglichen Auswirkungen wesentlicher Bestandteil der Risikoanalyse sind.

Um die Risiken einzuschätzen ist Erfahrung mit den Geschäftsprozessen und den notwendigen IT-Systemen notwendig. Denn nur durch das aus dieser Erfahrung resultierende Wissen lässt sich die Existenz der Schwachstellen und Bedrohungen feststellen und die zugehörigen Risiken abschätzen. Obwohl die Einschätzung grundsätzlich mit entsprechender Prozess- und Technologieerfahrung möglich ist, werden viele Risiken ohne eine entsprechende Risikoanalyse oft nicht erkannt, da es zusätzlich zu dem möglichen Wissen notwendig ist, sich im Rahmen der Risikoanalyse lückenlos mit dem Prozess auseinanderzusetzen.

Bei dieser Art der Risikoanalyse handelt es sich um den kombinierten Ansatz nach dem Österreichischen Informationssicherheitshandbuch [Ze13, 97]. Hier wird anhand der Schutzbedarfsfeststellung der Business-Impact-Analyse festgelegt, welche Risiken einer detaillierten Analyse (hohe Auswirkung) bedürfen und bei welchen auf einen hohen Detaillierungsgrad verzichtet werden kann (niedrige und mittlere Auswirkung) und eine Grundschutzanalyse ausreichend ist. Die Vorgehensweisen bei diesen beiden Analysearten werden nachfolgend genauer beschrieben.

==== Detaillierte Risikoanalyse ====

Die betroffenen Prozesse aus der Business-Impact-Analyse werden nun einer Bedrohungsanalyse und einer Schwachstellenanalyse unterzogen. Dabei wird betrachtet, welche möglichen Bedrohungen zu einer Störung des Prozesses führen können und welche Schwachstellen im Prozess oder seiner IT-Unterstützung diese Bedrohungen begünstigen können. Danach werden die bereits bestehenden Sicherheitsmaßnahmen analysiert und ihr aktueller Nutzen und die korrekte Funktion bewertet. Sobald alle Risiken bekannt sind, werden sie hinsichtlich ihrer Eintrittswahrscheinlichkeit und des möglichen Schadens bewertet und ein Gesamtrisiko berechnet. [Ze13, 97ff]

Um keine mögliche Bedrohung zu übersehen empfiehlt es sich, mit einer Checkliste zu arbeiten, die eine lückenlose Betrachtung aller möglichen Bedrohungstypen oder Kategorien ermöglicht.

Um mit den bewerteten Risiken nun vergleichbare Berechnungen durchführen zu können, werden die Faktoren dabei mit nummerischen Werten für beispielsweise „Niedrig“ bis „Sehr hoch“ beschrieben [Ha12, 304]:

* Niedrig (Wert 1)
* Mittel (Wert 2)
* Hoch (Wert 3)
* Sehr hoch (Wert 4)
Die gängigste und gleichzeitig einfachste Formel zur Berechnung der Risiken ist:

<math display="block">Risiko = Schaden*Eintrittswahrscheinlichkeit</math>

Da jedoch auch die bestehenden Maßnahmen in die Analyse einfließen, wird die Formel in der detaillieren Risikoanalyse um den Faktor <math display="inline">Ma\text{ß}nahmen</math> erweitert, welcher die Eintrittswahrscheinlichkeit wieder verringert:

<math display="block">Risiko = Schaden*(Eintrittswahrscheinlichkeit - Ma\text{ß}nahmen)</math>

Hier wird nicht das bloße Vorhandensein, sondern die Qualität der Maßnahmen bewertet. [Ha12, 301]

Die oben genannte Formel berücksichtigt nur Maßnahmen, welche die Eintrittswahrscheinlichkeit minimieren. Es kann jedoch auch Maßnahmen geben, mit denen der entstehende Schaden gesenkt werden kann. So senkt beispielsweise eine unterbrechungsfreie Notstromversorgung die Eintrittswahrscheinlichkeit eines stromausfallbedingten IT-Systemausfalls, eine automatische Löschanlage in einem Serverraum minimiert hingegen den möglichen Schaden bei einem Brand, nicht aber die Eintrittswahrscheinlichkeit des Brandes. Die endgültige Formel wird daher noch um den Faktor der Schadensminimierenden Maßnahmen erweitert:

<math display="block">Risiko = \left( Schaden - M_{\text{Schaden}} \right)*(Eintrittswahrscheinlichkeit - M_{\text{Eintritt}})\ </math>

Um nun die Risikoanalyse übersichtlich und gut sortiert darzustellen, können, die Risiken auch in Form einer Risikomatrix dargestellt werden. Dabei empfiehlt sich die Risikomatrix gemäß der '''ALARP (As Low As Reasonably Practicable)''' [Kl11, 150f] Methode darzustellen. Die Achsen der Matrix sind hierbei die Eintrittswahrscheinlichkeit und der Schaden, welche in der hier angeführten Analyse noch um die Qualität der jeweiligen Maßnahmen reduziert wurden. Die daraus entstehende Matrix ist in Tabelle "ALARP Risikomatrix" dargestellt. Sie orientiert sich an der von Klipper [Kl11, 151] beschrieben Darstellung und berücksichtigt die Werte Niedrig bis Hoch der oben genannten Bewertung. Der grün dargestellte Bereich ist dabei der „akzeptable Bereich“. Alle hier eingeordneten Risiken müssen nicht weiter behandelt werden. Die Risiken im „ALARP-Bereich“ werden nur behandelt, wenn sie mit sehr einfachen Maßnahmen in den grünen Bereich gebracht werden können. Sie sind somit vorhanden, können aber noch akzeptiert werden. Eine besondere Betrachtung erfordern nur die Risiken im roten „inakzeptablen“ Bereich. Hier müssen Maßnahmen gesetzt werden, die dafür geeignet sind, die Faktoren so weit zu beeinflussen, damit die Risiken in den ALARP Bereich wechseln.
[[file:img1643143624475.png|300px|alt=ALARP Risikomatrix|none|thumb|ALARP Risikomatrix]]
==== Grundschutzansatz Risikoanalyse ====

''Ziel des Grundschutzansatzes ist es, den Aufwand für die Erstellung eines Informationssicherheitskonzeptes angemessen zu begrenzen.'' [Ze13, 110]

Bei der Grundschutzanalyse wird das IT-System anhand von vorhandenen Bausteinen möglichst genau nachmodelliert. Danach werden die vorhanden Maßnahmen mit den empfohlenen Maßnahmen in Form eines Soll-Ist-Vergleichs verglichen und daraus das weitere Vorgehen abgeleitet. Die einzelnen Bausteine für die Modellierung definieren sich durch die IT-Grundschutz Standards des BSI [Bu13]. Die einzelnen Module sind, der einfacheren Betrachtung halber, in einzelne Schichten gegliedert. Die unterschiedlichen Schichten und der aus Ihnen abgeleitete Aufbau des IT-Systems sind in Abbildung "Schichten des IT-Grundschutz Modells" dargestellt.

[[Datei:IT244 5.png|300px|none|thumb|Schichten des IT-Grundschutz Modells ]]


Aus den empfohlenen Maßnahmen des jeweiligen Bausteines ergeben sich die Soll-Parameter für das IT-System. Es wird dabei grundsätzlich nicht auf die beiden Faktoren Schaden und Eintrittswahrscheinlichkeit eingegangen, da dies bereits durch die Konzeption des Grundschutzstandards global berücksichtigt wurde. Bei Abweichungen des Ist-Systems müssen entweder Maßnahmen getroffen werden um die Lücke zu füllen, oder die Abweichung mit einer entsprechenden Begründung akzeptiert werden.

=== IT-Maßnahmenziele ===

Anhand der Ergebnisse der Risikoanalyse werden nun Maßnahmenziele abgeleitet, um entweder das jeweilige Modul des TI-Grundschutz-Modells zu erfüllen, oder um die in der detaillierten Risikoanalyse ermittelten Risiken auf einen akzeptierten Level zu bringen.

Bevor eine vollkommen neue Maßnahme eingeführt wird, empfiehlt es sich mögliche bereits vorhandene Maßnahmen hinlänglich ihrer Erweiterbarkeit und Verbesserbarkeit zu überprüfen [Ha12, 314], da es sich dabei meist um die schnellste und günstigste Lösung handeln wird.

Die ISO/IEC 27001 definiert im Anhang B [II08, 20ff] folgende Kategorien möglicher Maßnahmenziele:

* Sicherheitspolitik,
* Organisation der Informationssicherheit,
* Management von Vermögenswerten,
* Personelle Sicherheit,
* Physische und umgebungsbezogene Sicherheit,
* Management der Kommunikation des Betriebes,
* Zugriffskontrolle,
* Beschaffung, Entwicklung und Wartung von Informationssystemen,
* Management von Informationssicherheits-Vorfällen,
* Betriebliches Kontinuitätsmanagement (Business Continuity Management) sowie
* Einhaltung von Verpflichtungen.
Die Maßnahmenziele müssen für die eigenen Prozesse ausdefiniert werden und stehen dann als Maßnahmenkatalog zur Begegnung mit den festgestellten Risiken zur Verfügung.

== Wiederholungsaufgaben/Übungen ==

'''1 Erklären Sie, worin sich die Begriffe Informationssicherheit, IT-Sicherheit und Datenschutz unterscheiden.'''

'''2 Was ist die CIA-Triade? Erklären Sie kurz was genau unter C, I und A verstanden wird.'''

'''3 Welche Kontrollmechanismen gibt es, um die Ziele der CIA-Triade analysieren zu können?'''

'''4 Was versteht man unter Schwachstellen, Bedrohungen und Maßnahmen und wie hängen sie zusammen?'''

'''5 Zählen Sie wesentliche Standards der Informationssicherheit auf und erläutern Sie kurz ihre Herkunft und ihren Zweck.'''

'''6 Sie sind mit der Durchführung eines Projektes zur Einführung von Informationssicherheit im Unternehmen beauftragt. Welches System werden Sie dazu einführen und was muss nach Projektende unbedingt beachten werden und warum?'''

'''7 Erklären Sie kurz den Begriff des IT-Business Continuity Managements. Welche Analysemaßnahmen müssen darin durchgeführt werden und wie hängen sie zusammen?'''

'''8 Wie funktioniert eine Risikoanalyse nach dem Grundschutzansatz?'''

Benutzer:VÖLKL Peter

2023-05-31T09:51:33Z

VÖLKL Peter:

<div>[[file:Voelkl_mittel.jpg|300x150px|left|thumb|Peter Völkl]]
{| style="height: 144px;"
|- style="height: 144px;"
| style="height: 144px; width: 1238px;" | Peter Völkl, Jahrgang 1984, begann seine berufliche Laufbahn, nach dem Abschluss seiner Ausbildung an der HTBLuVA für EDV und Organisation, 2005 als Softwareentwickler beim Österreichischen Roten Kreuz. Dort übernahm er 2008 die Leitung einer, für die IT Services des Blutbereiches verantwortlichen, Abteilung der Blutspendezentrale für Wien, Niederösterreich und das Burgenland. Seine Schwerpunkte lagen hierbei, neben der Führung der Abteilung, in der laufenden Koordination und Überwachung von IT Projekten und Prozessen, sowie der Entwicklung, Testung und Validierung von IT Systemen. Neben seiner beruflichen Tätigkeit begann er 2010 mit dem Bachelorstudium der Wirtschaftsinformatik an der FernFH, welches er 2012 abschloss. Anschließend absolvierte er 2014 die Masterstudien Wirtschaftsinformatik an der FernFH und Information Management and IT Security an der FH Technikum Wien. Ab November 2014 war Peter Völkl als wissenschaftlicher Mitarbeiter an der FernFH tätig, ist seit Juli 2016 Studiengangsleiter des Masterstudiengangs Wirtschaftsinformatik und seit 2023 Leiter des Instituts für Wirtschaftsinformatik.
|}
</div>

Informationstechnologie und Informationssysteme

2023-05-03T06:10:11Z

VÖLKL Peter:

[[IT244 - Computer-_und_Netzwerksicherheit|IT244 - Computer- und Netzwerksicherheit]]

[[IT523 - Verteilte Systeme|IT523 - Verteilte Systeme]]

[[IT422 - Technische Sicherheitsaspekte|IT422 - Technische Sicherheitsaspekte]]

[[IT445 - Requirements Engineering and Cost Estimation|IT445 - Requirements Engineering and Cost Estimation]]

[[IT449_-_e-Government|IT449 - E-Government]]

[[IT534 - Kryptographie und Zugriffskontrolle|IT534 - Kryptographie und Zugriffskontrolle]]

[[IT546 - Web-Application- und E-Business-Security|IT546 - Web-Application- und E-Business-Security]]

[[IS434 - Managementinformations- und Berichtssysteme|IT43B - Managementinformations- und Berichtssysteme]]

[[IS532 - E-Commerce-Systeme|IT530 - E-Commerce-Systeme]]

[[IS533 - Management kooperativer Informationssysteme|IT43A - Management kooperativer Informationssysteme]]

Informationstechnologie und Informationssysteme

2023-05-03T06:09:44Z

VÖLKL Peter:

[[IT244 -_Computer-_und_Netzwerksicherheit|IT244 - Computer- und_Netzwerksicherheit]][[IT523 - Verteilte Systeme|IT523 - Verteilte Systeme]]

[[IT422 - Technische Sicherheitsaspekte|IT422 - Technische Sicherheitsaspekte]]

[[IT445 - Requirements Engineering and Cost Estimation|IT445 - Requirements Engineering and Cost Estimation]]

[[IT449_-_e-Government|IT449 - E-Government]]

[[IT534 - Kryptographie und Zugriffskontrolle|IT534 - Kryptographie und Zugriffskontrolle]]

[[IT546 - Web-Application- und E-Business-Security|IT546 - Web-Application- und E-Business-Security]]

[[IS434 - Managementinformations- und Berichtssysteme|IT43B - Managementinformations- und Berichtssysteme]]

[[IS532 - E-Commerce-Systeme|IT530 - E-Commerce-Systeme]]

[[IS533 - Management kooperativer Informationssysteme|IT43A - Management kooperativer Informationssysteme]]

Computer- und Netzwerksicherheit

2023-02-06T12:21:51Z

VÖLKL Peter:

[[Computer- und Netzwerksicherheit - Gesamt|Computer- und Netzwerksicherheit - Gesamt (Achtung - immer die aktuellste Version!)]]

'''Version für das Sommersemester 2023'''

[[Special:PermanentLink/2706|Computer- und Netzwerksicherheit - Grundlagen|Computer- und Netzwerksicherheit - Grundlagen]]

[[Special:PermanentLink/2157|Computer- und Netzwerksicherheit - Bewusstseinsbildung|Computer- und Netzwerksicherheit - Bewusstseinsbildung]]

[[Special:PermanentLink/2278|Computer- und Netzwerksicherheit - Kryptograhpie|Computer- und Netzwerksicherheit - Kryptograhpie]]

[[Special:PermanentLink/2711|Computer- und Netzwerksicherheit - Zugriffssteuerung|Computer- und Netzwerksicherheit - Zugriffssteuerung]]

[[Special:PermanentLink/2280|Computer- und Netzwerksicherheit - Netzwerksicherheit|Computer- und Netzwerksicherheit - Netzwerksicherheit]]

Grundlagen der Modellierung - Datenmodellierung

2022-11-02T11:55:28Z

VÖLKL Peter:

= Datenmodellierung =

Bei der Datenmodellierung geht es um die zweckmäßige und effiziente Strukturierung von Daten in Informationssystemen. Die Modelle behandeln unterschiedliche Arten von Speicheranwendungen. Beispielsweise ist das ER-Modell im Bereich der Datenbanksysteme beheimatet, XML und JSON dahingegen im Bereich der Nahtstellen und Datenstrukturen innerhalb und zwischen einzelnen Systemen auf Dateiebene.


== Entity-Relationship Modell (ER-Modell) ==

Das Entity-Relationship Modell (ER-Modell) wurde bereits im vorherigen Semester, im Studienheft „Datenbanksysteme“ (Schikuta, E.), genau erläutert. Nachfolgend werden nun die wesentlichen Punkte dieses Skriptums nochmals auszugsweise wiederholt.

Das '''Entity-Relationship-Modell (ER-Modell)''' ist eines der ältesten (Chen, 1976) und am weitesten verbreiteten Modelle zum Entwurf von Datenbankmodellen und wird auch gerne im Bereich der allgemeinen Software Entwicklung eingesetzt. Durch seine besonders einfachen Darstellungsmöglichkeiten ist es sehr gut für die Kommunikation mit den Endbenutzern geeignet.

Die Grundidee des Entity-Relationship-Modells (Objekt-Beziehungs-Modell) besteht darin, die Welt als Sammlung von '''Entitäten (Entity''' oder '''Objekttypen''') und '''Beziehungen''' ('''Relationship''') zwischen diesen Objekttypen zu sehen.


=== Modellierungsobjekte des ER-Modells ===


==== Entitäten ====

Ein Objekt wird '''Entität-Instanz''' genannt. Entität-Instanzen sind dabei einzelne Exemplare von Dingen oder Begriffen. Dies können beispielsweise sein:

* Personen: der Kunde, Lieferant, Mitarbeiter etc.
* Gegenstände: Handelsware, Rohstoff, Maschine etc.
* Abstrakte Begriffe: Konto, Buchung, Bestellung etc.
Entität-Instanzen mit gleichen Eigenschaften lassen sich zu Entitäten (Objekttypen) zusammenfassen, z.B. Kunden, Bestellungen etc. Die Eigenschaften einer Entität-Instanz werden durch '''Attribute''' beschrieben, z.B. Name, Baujahr, Preis, Bestellnummer.

Hinweis: Im ER – Modell bezeichnet der Begriff Entität immer eine Klasse (Typ) von Instanzen, nicht eine Instanz!

Zwischen zwei, aber auch mehr, Entitäten können Beziehungen bestehen, z.B. „Kunde bestellt Maschine“. Die Beziehung wird dabei durch die Rolle der an ihr beteiligten Entitäten beschrieben. Die Beziehungen können zwischen Entitäten gleichen Typs oder zwischen Entitäten verschiedenen Typs bestehen.

Die wichtigsten Symbole in der grafischen Notation des ER-Modells werden in Abbildung 2 dargestellt.

[[Datei:Wiba mt233 201607 a.007.png|300px|none|thumb|Grafische Notation im ER-Modell]]

Attribute können auch Beziehungen zugeordnet werden (siehe Abbildung 3). Hier ist bei der Modellierung zu entscheiden, ob dieses Beziehungsattribut nicht einer der beiden Entitäten zugeordnet werden kann oder soll.

[[Datei:Wiba mt233 201607 a.008.png|300px|none|thumb|Beispiel Beziehungsattribut]]

Eine minimale Menge von Attributen, deren Werte die zugeordnete Entität-Instanz eindeutig innerhalb aller Instanzen seines Objekttyps identifiziert, nennt man '''Schlüssel'''. Oft gibt es Attribute, die künstlich als Schlüssel eingebaut werden, z.B. Personalnummer, Vorlesungsnummer, …

Schlüsselattribute werden durch Unterstreichen (manchmal auch durch doppelt gezeichnete Ovale) gekennzeichnet (siehe Abbildung 4).

[[Datei:Wiba mt233 201607 a.009.png|300px|none|thumb|Beispiel Schlüsselattribut]]

==== Beziehungen ====

Beziehungen repräsentieren eigentlich Aggregate von zwei oder mehreren an der Beziehung teilnehmenden Entitäten. Die Anzahl der aggregierten Entitäten heißt '''Grad''' der Beziehung (unäre, binäre, n-äre Beziehung). Entitäten haben in einer Beziehung eine minimale und eine maximale '''Kardinalität''' bzw. Komplexität.

Die Beziehungen können vom Typ '''1:1''', '''1:n''', '''n:1''', oder '''m:n''' sein. Entsprechende Beispiele für die einzelnen Kardinalitäten findet man in Abbildung 5:

[[Datei:Wiba mt233 201607 a.010.png|300px|none|thumb|Beispiele Kardinalitäten]]

Diese Kardinalitäten können folgendermaßen interpretiert werden:

* 1:1 – ein Ehemann hat genau eine Ehefrau (normalerweise), und umgekehrt.
* 1:n – ein Kunde besitzt mehrere Konten, aber jedes Konto gehört genau einem Kunden.
* m:n – Ein Kunde kann mehrere Artikel kaufen und jeder Artikel kann von mehreren Kunden gekauft werden.
Bei der Angabe der Kardinalitäten ist es auch möglich Intervalle durch Angabe der minimalen und maximalen Kardinalität zu definieren. In Abbildung 6 ist sowohl eine n:m und eine n:1 Beziehung definiert, wobei das Maximum der Kardinalität die Beziehungsmultiplizität definiert.

[[Datei:Wiba mt233 201607 a.011.png|300px|none|thumb|Beispiel Kardinalitäten mit Intervallen]]

Im obigen Beispiel sieht man, dass es ohne weiters möglich ist, auch mehr als eine Beziehung zwischen Entitäten zu definieren. Im spezifischen Fall sind dies zwei binäre Beziehungen.

In manchen Fällen ist es notwendig auch n-äre Beziehungen zu modellieren. In der Abbildung 7 ist eine ternäre Beziehung dargestellt und die entsprechende Interpretation der Kardinalitäten angegeben.

[[Datei:Wiba mt233 201607 a.012.png|300px|none|thumb|Beispiel ternäre Beziehung]]

Es ist aber empfohlen n-äre Beziehungen nur in wirklich begründeten Fällen zu modellieren.

Unter einer '''schwachen Entität''' versteht man eine Entität, die kein Schlüsselattribut besitzt (d.h. wo die Instanzen nicht eindeutig unterschieden werden können). Solche Instanzen können nur über eine Beziehung zu einer anderen Entität eindeutig identifiziert werden. Schwache Entitäten werden grafisch durch einen doppelten Rand gekennzeichnet.

Im nachfolgenden Beispiel Abbildung 8 ergibt sich die schwache Entität dadurch, dass ein Hörsaal durch seine Nummer, Größe und seinen Typ nicht eindeutig auf einem Universitätscampus identifiziert werden kann, auf dem es eine Vielzahl von Gebäuden mit jeweils mehreren Hörsälen gibt, die in jedem Gebäude von der Nummer 1 an gezählt werden. Das bedeutet es gibt in jedem Gebäude einen Hörsaal mit der Nummer 1. Erst mit der Angabe des Gebäudes (identifying owner) kann dadurch jeder Hörsaal eindeutig identifiziert werden.

[[Datei:Wiba mt233 201607 a.013.png|300px|none|thumb|Beispiel Schwache Entität]]


=== Beispiel eines ER-Modells ===

Im abschließenden (vereinfachten) Beispiel dieser Lektion wollen wir, basierend auf einem gegebenen Ausschnitt der Realität einer „Bank“, eine Modellierung mit Hilfe des ER-Modells durchführen.

Ausgangsposition für unseren Ansatz bildet eine Anforderungsbeschreibung in natürlichsprachiger Form. Es wird angenommen, dass sich diese Beschreibung aus den Interviews mit den Benutzern bzw. Auftragsgebern ergeben hat. Eine in der Praxis simple, aber übliche Vorgangsweise, um Entitätskandidaten zu erhalten, ist alle Hauptworte im Text zu identifizieren und als ersten Ansatz für Entitäten zu verwenden. Dieses Verfahren wird in der CRC-Methode vertieft (siehe die Aufgaben zu dieser Lektion).

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Eine mögliche Modellierung dieser Anforderungsbeschreibung als ER-Modell findet man in Abbildung 9.

[[Datei:Wiba mt233 201607 a.014.png|300px|none|thumb|Beispiel „Bank“: ER-Modell]]

== Extensible Markup Language (XML) ==

Die Extensible Markup Language (XML) ist ein Standard für den Aufbau von Dateidokumenten. Sie wurde vom World Wide Web Consortium (W3C) entwickelt. Es handelt sich dabei um eine sehr flexible Modellierungsform für Textformate welche wiederum von der Standard Generalized Markup Language (SGML, ISO8879) abgeleitet wurde. (World Wide Web Consortium (W3C), 2014)

''XML ist eine Markup-Sprache, und es ist nur eine Markup-Sprache. […] Der XML-Hype ist so extrem geworden, dass viele Leute glauben, XML könne sogar Kaffee kochen der den Familienhund waschen.'' (Harold & Means, 2005, S. 5)

Die Designziele von XML selbst sind (World Wide Web Consortium (W3C), 2008):

* XML soll direkt und unkompliziert über das Internet nutzbar sein,
* XML soll eine große Anzahl unterschiedlicher Applikationen unterstützen,
* XML soll mit SGML kompatibel sein,
* eine Programmierung von Anwendungen, welche XML Dokumente verarbeiten können, soll einfach möglich sein,
* die Anzahl von optionalen Features soll in XML so gering wie möglich gehalten werden und optimal Null sein,
* XML Dokumente sollen menschenlesbar und leicht verständlich sein,
* die Modellierung von XML Dokumenten soll schnell erstellt werden können,
* das Design von XML Dokumenten soll formal und präzise sein,
* die Erstellung von XML Dokumenten soll einfach sein und
* die Kürze und Kompaktheit der XML Elemente ist von geringer Bedeutung.
Der Hauptvorteil bei XML liegt, im Gegensatz zu eigen entwickelten Dateistrukturmodellen, in der schnellen und einheitlichen Verarbeitbarkeit für den Entwickler. In nahezu jeder gängigen Programmiersprache existieren bereits fertige Parser, welche die Generierung und Verarbeitung der Datenstrukturen, ohne größeren Programmieraufwand, ermöglichen.


=== Aufbau eines XML Dokuments ===

Jedes XML Dokument beinhaltet '''ein einziges''' XML '''Wurzel-Element''', welches selbst jeweils wiederum beliebig viele weitere '''Elemente''' beinhalten kann. Alle Elemente dürfen wiederum beliebig viele weitere Elemente enthalten. Zusätzlich kann das Dokument '''XML Deklarationen''', auch bezeichnet als Processing Instructions (PI), und beliebig viele '''Kommentare''' enthalten. Die Zeichenkodierung der Dokumente darf '''alle Unicodezeichen''' enthalten, wobei jedes XML verarbeitende Programm zumindest die Kodierungen UTF-8 und UTF-16 akzeptieren muss. Alle Bezeichnungen eines Dokuments, seien es die von Elementen oder Attributen, sind '''Case Sensitive'''. Da es sich dabei um ein einfaches Textdokument handelt, kann es auch von allen Texteditoren und Internetbrowsern, ohne weitere Hilfsmittel und Plugins, angezeigt werden. (World Wide Web Consortium (W3C), 2008)

Vom Aufbau sehen sich XML und HTML (Hypertext Markup Language) Dokumente sehr ähnlich. Sie unterscheiden sich jedoch darin, dass die Art und teilweise die Anzahl der Elemente in HTML fest vorgegeben, in XML jedoch alle Elemente frei modellierbar, sind. Das Metamodell der zu verwendeten Elemente eines XML Dokuments kann somit vom Modellierer selbst festgelegt werden. HTML dient der Modellierung von Webseitendokumenten und hat fest vorgegebene Strukturen und Elemente um eine einheitliche grafische Verarbeitung durch die Internetbrowser zu ermöglichen. Das Design der Elemente selbst ist jedoch in beiden Fällen sehr restriktiv vorgegeben.

Die '''XML Deklaration''' gibt die eingesetzte XML Version, und optional das Encoding, an. Dadurch wird den verarbeitenden Programmen die Verarbeitung erleichtert. Gerade die Angabe des Encodings kann viele Verarbeitungsprobleme im Vorfeld abfangen, da der Parser damit die eingesetzten Zeichen kennt und sie korrekt interpretieren kann. Nachfolgend ist in Abbildung 10 ein minimales XML Dokument dargestellt, welches nur eine XML Deklaration und ein einzelnes XML Element, namens „mein_wurzel_element“, ohne weitere Attribute und ohne Wert, beinhaltet.

<pre><?xml version="1.0" encoding="UTF-8"?>

<mein_wurzel_element /></pre>
Abbildung 10 – Minimales XML Dokument

Da einige Zeichen in der XML Syntax eine spezielle Bedeutung haben, müssen sie im Text nötigenfalls in einer anderen Form geschrieben werden, um sie innerhalb von XML Elementen nutzen zu können:

* < wird zu ''&lt;''
* > wird zu ''&gt;''
* " wird zu ''&quot;''
* ' wird zu ''&apos;''
* & wird zu ''&amp;''


=== XML-Elemente ===

Die einzelnen XML Elemente sind alle nach demselben Schema aufgebaut. Sie haben eine '''Elementbezeichnung''' und können '''beliebig viele Attribute''' enthalten. Weiter können sie selbst einen '''Inhalt''' haben, welcher wiederum aus Elementen bestehen kann.

Ein Element besteht aus einem oder zwei sogenannten Tags. Ein '''Tag''' wird durch '''spitze Klammern (<,>)''' an seinem Beginn und Ende ausgezeichnet. Ob ein Element aus '''einem oder zwei Tags''' besteht, hängt davon ab, '''ob es selbst einen eigenen Inhalt''' besitzt, oder nicht. Der Inhalt kann aus Text oder weiteren Elementen bestehen. Am '''Beginn''' jedes Tags steht der '''Name des Elements'''.

Hat ein Element '''keinen''' '''Inhaltsbereich''', besteht es aus nur '''einen einzigen Tag.''' Dessen abschließenden spitzen Klammer wird ein Schrägstrich vorangestellt ''(<elementname />'') um die Abwesenheit eines Inhaltbereiches zu signalisieren.

Sollte das Element dahingegen '''einen Inhaltsbereich''' haben, wird der erste Tag durch eine einfache spitze Klammer geschossen ''(<elementname>''). Danach folgt dann der eigentliche Inhalt des Elements. Nach dem Inhalt, und damit am Ende des Elements, steht in diesem Fall ein zweiter Tag, welcher wiederum einen Schrägstrich nach der einleitenden spitzen Klammer hat (''</elementname>).''

Die '''Attribute''' eines Elements befinden sich immer innerhalb des ersten Tags. In einem Element darf ein gewählter Attributname nur einmal vorkommen. Somit ist es beispielsweise nicht möglich einem Element „person“ mehrmals das Attribut „name“ zu zuzuweisen. die Reihenfolge der einzelnen Attribute eines Elements ist dahingegen nicht relevant und kann beliebig gewählt werden. Ein möglicher Aufbau eines Elements „person“ mit den Attributen „vorname“, „nachname“ und „ausweisnummer“ ist in Abbildung 11 dargestellt.

<person vorname="Peter" nachname="Völkl" ausweisnummer="1234567"/>

Abbildung 11 – XML Element „person“

In Abbildung 12 sind weiter:

* ein Element ''„element_1“'' ohne Inhalt und ohne Attribute,
* ein Element ''„element_2“'' ohne Inhalt und mit Attributen,
* ein Element ''„element_3“'' mit Inhalt und ohne Attributen,
* ein Element ''„element_4“'' mit Inhalt und mit Attribut und
* ein Element ''„element_5“'' mit Attributen und weiteren Elementen im Inhalt exemplarisch dargestellt.
<pre><element_1 />

<element_2 attribut_1="Attributwert 1" attribut_2="Attributwert 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein Inhaltstext</element_3>

<element_4 attribut_1="Wert 1">Noch ein Inhaltstext</element_4>

<element_5 attribut_1="Attributwert 1">

<element_1 />

<element_2 attribut1="Test 1" 
attribut_2="Test 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein anderer Inhaltstext</element_3>

</element_5>
</pre>
Abbildung 12 – XML Elemente mit unterschiedlichen Tags


=== Kommentare ===

Zusätzlich zu den Deklarationen und Elementen, kann ein XML Dokument auch Kommentare enthalten. Diese können sich an jeder Position im Dokument befinden an der auch ein Element stehen dürfte, also überall außer im Attributbereich eines Tags. Sie werden bei der Interpretation des Dokuments ignoriert. Kommentare dienen primär der Lesbarkeit durch Menschen. Mit ihnen können einzelne Teile des Dokuments mit Erklärungen versehen werden, die dem Anwender bei nicht automatisierter Betrachtung helfen können, den Inhalt zu verstehen.

Ein Kommentar ist hinlänglich seines Inhaltes kaum beschränkt. Es darf einzig keine zwei direkt zusammenhängenden Minuszeichen (--) enthalten. Sollte sich innerhalb eines Kommentars ein XML Element befinden, wird es nicht als Element, sondern als Kommentartext interpretiert. Damit können auch einzelne Teile eines Dokuments „auskommentiert“ werden, um sie bei der Interpretation zu ignorieren, ohne sie aus dem Dokument löschen zu müssen. Dies ist gerade bei der Entwicklung von Schnittstellen hilfreich, da die Musterdateien somit abgeändert werden können, ohne einzelne Inhalte zu löschen.

Kommentare werden durch die Zeichenfolge '''' wieder beendet. Alle Zeichen, welche sich zwischen diesen beiden Teilen befinden gelten damit als Kommentartext und nicht als XML Element.


=== Document Type Definitions (DTD) ===

Die Document Type Definition (DTD) wird verwendet um die '''Struktur eines XML Dokuments''' zu definieren. Ohne eine DTD darf es auf beliebigen Elementen in beliebiger Reihenfolge mit beliebigem Inhalt und Attributen aufgebaut sein. Die DTD schränkt nun genau diese Freiheit wieder ein und definiert damit das '''Metamodell des XML Dokuments'''.

Um, in einem XML Dokument, eine zugehörige DTD anzugeben. Wird eine eigene Deklaration verwendet, welche am Beginn des Dokumentes nach der XML Deklaration stehen muss. Sie wird mit ''<!DOCTYPE'' eingeleitet und wiederum mit einer einfachen Spitzen Klammer abgeschlossen. Es kann auch mehrere dieser Deklarationen in einem Dokument geben.

Innerhalb der DTD Deklaration des XML Dokuments wird zuerst der Name der Dokumentenart angegeben und danach einer der Identifier SYSTEM oder PUBLIC, sowie ihre zugehörigen Parameter.

Der Identifier '''''SYSTEM''''' gibt an, dass es sich dabei um eine eigene Definition handelt. Der zugehörige Parameter ist hierbei der Pfad zu der Datei, welche die angegebene DTD enthält.

Der Identifier '''''PUBLIC''''' weist auf eine allgemein standardisierte DTD hin, welche dem XML Parser bekannt sein sollte. Hier werden zwei Parameter benötigt. Der Erste gibt an, um welchen Public Identifier es sich dabei handelt und der zweite Parameter verweist optional auf eine alternative DTD Datei, welche verwendet wird falls der genannte Identifier dem Parser nicht bekannt ist.

In Abbildung 13 ist die Deklaration einer eigenen DTD „schema.dtd“ angegeben und in Abbildung 14 die Deklaration eines XML Dokumentes als, dem System bekannten, Dokumententyp HTML.

<!DOCTYPE mein_schema SYSTEM "schema.dtd">

Abbildung 13 – XML DOCTYPE für eigene DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 //EN" "http://www.w3.org/TR/html4/strict.dtd">

Abbildung 14 – XML DOCTYPE für HTML

In der DTD Datei können nun die einzelnen Elemente und die Struktur des XML Dokuments definiert werden:

* '''Elemente''' werden durch <!ELEMENT …> und
* '''Attribute''' über <!ATTLIST …> definiert.
'''Element Definition <!ELEMENT …>'''

Bei der Definition eines Elements wird sowohl die '''Bezeichnung des Elements''', als auch sein '''möglicher Inhalt''' definiert. Dabei wird als erstes der Elementname und dahinter der Inhalt in Klammer angegeben.

Der '''Inhalt''' kann entweder:

* leer (Schlüsselwort '''''EMPTY'''''),
* beliebig (Schlüsselwort '''''ANY'''''),
* reiner Text (Schlüsselwort '''''#PCDATA''''') oder
* weitere Elemente (Angabe des gewünschten '''Elementnamen''') sein.
Dabei sind auch die Angaben unterschiedlicher Inhalte und Typen kombinierbar.

Sollen mehrere Inhalte, wie beispielsweise unterschiedliche Elemente, beinhaltet sein, werden diese innerhalb der Klammer durch '''Beistriche''' ( ''',''' ) oder '''Pipes''' ( '''|''' ) getrennt.

Dabei gibt ein '''Beistrich''' das Vorhandensein beider Elemente in '''genau dieser Reihenfolge''' und eine '''Pipe''' das Vorhandensein '''nur''' '''eines der beiden Elemente''' an.

Weiter sind auch '''Verschachtelungen''' dieser beiden Operatoren durch Setzen von '''Klammern''' zulässig.

Zusätzlich gibt es noch die Möglichkeit hinter jedem Element, oder Klammerausdruck, anzugeben, ob das Element:

* '''optional''' ist (durch ein Fragezeichen: '''?'''),
* beliebig '''oft aber''' '''mindestens einmal''' vorkommt (durch ein Pluszeichen: '''+''') oder
* '''beliebig oft''' '''und optional''' vorkommen kann (durch einen Stern: '''*''').
Wird hinter einem Eintrag keine Angabe über die Häufigkeit gemacht, muss er genau einmal vorkommen.

Im nachfolgenden Beispiel, in Abbildung 15, sind folgende Elemente definiert:

* ''element_1'' hat keinen Inhalt,
* ''element_2'' hat einen Textinhalt,
* ''element_3'' beinhaltet ''element_1'' und ''element_2'',
* ''element_4'' beinhaltet ''element_1'' und (entweder ''element_2'' oder ''element_3''),
* ''element_5'' beinhaltet 0-n Mal ''element_1'' und 1-n Mal ''element_4'',
* ''element_6'' beinhaltet optional ''element_4'',
* ''element_7'' beinhaltet ''element_1'' und optional ''element_7'' und
* ''element_8'' beinhaltet beliebig viele ''element_1'', ''element_2'' und ''element_3'' in beliebiger Reihenfolge.
Bei der Definition von verschachtelten Elementen sind auch '''Rekursionen zulässig''', wie das gerade genannte Beispiel mit element_7 zeigt. Hier muss jedoch darauf geachtet werden, die Rekursion '''als optional zu deklarieren''' (Angabe von ?, * oder |), da die Rekursion sonst verpflichtend endlos und damit nie erfüllbar wäre.

<pre><!ELEMENT element_1 EMPTY>

<!ELEMENT element_2 #PCDATA>

<!ELEMENT element_3 (element_1, element_2)>

<!ELEMENT element_4 (element_1, (element_2 | element_3))>

<!ELEMENT element_5 (element_1*, element_4+)>

<!ELEMENT element_6 (element_4?)>

<!ELEMENT element_7 (element_1, element_7?)>

<!ELEMENT element_8 (element_1|element_2|element_3)*>
</pre>
Abbildung 15 – DTD Elemente

'''Attribut Definition <!ATTLIST …>'''

Um ein definiertes Element '''mit Attributen auszustatten''' wird mittels ''<!ATTLIST'' eine Attributliste definiert. Dazu wird zuerst der '''Name''' des Elements angegeben, für das die Attributliste gilt sowie danach der '''Attributname''' und sein '''Typ,''' sowie optional eine Definition von möglichen Werten und ob der Parameter verpflichtend vorkommen muss. Dabei können entweder '''mehrere Attribute in einer Definition''' '''oder jedes Attribut einzeln''' in einer '''eigenen Definition''' angegeben werden.

Mögliche Datentypen für Attribute sind:

* '''''CDATA''''' für beliebige Zeichenketten,
* '''''ID''''' für einen eindeutigen Wert unter den Elementen desselben Typs innerhalb des XML Dokuments,
* '''''IDREF''''' für eine Referenz auf ein anderes Element desselben Typs innerhalb des Dokuments mittels Wert des ID Attributs,
* '''''ENTITY''''' für eine Referenz auf ein externes Element,
* '''''ENTITYS''''' für eine Liste von ''ENTITY‘s'',
* '''''NMTOKEN''''' für einen Namen (eine Bezeichnung) des Elements innerhalb des XML Dokuments,
* '''''NMTOKENS''''' für eine Liste von ''NMTOKEN’s'' oder
* eine fest definierte '''Menge möglicher Eingabewerte''', getrennt durch Pipes in der Form ''(wert1|wert2|wert2).''
Zusätzlich kann hinter der Angabe des Datentyps noch:

* '''#REQUIRED''', für verpflichtend anzugebende Attribute,
* '''#IMPLIED''', für optionale Attribute,
* oder ein '''automatischer Standardwert''' in Anführungszeichen,
angegeben werden.

Eine Sonderform der Angabe des Standardwertes ist der Parameter '''#FIXED''', gefolgt von einem Standardwert in Anführungszeichen. Dabei handelt es sich um einen nicht veränderbaren Standardwert bzw. einen statischen Attributwert.

Im nachfolgenden Beispiel, in Abbildung 16, wird eine DTD für ein Element ''element_1'' mit den Attributen ''e1_id'', welches eine eindeutige ID innerhalb des Dokuments enthält, ''e1_name'', welches eine eindeutige Bezeichnung des Element enthält, ''e1_kommentar'', welches einen Kommentartext enthalten soll und ''e1_wochentag'', welches ein Wochentagkürzel enthält.<pre><!ELEMENT element_1 EMPTY>

<!ATTLIST element_1 e1_id ID>

<!ATTLIST element_1 e1_name ENTITY>

<!ATTLIST element_1 e1_kommentar CDATA>

<!ATTLIST element_1 e1_wochentag (MO|DI|MI|DO|FR|SA|SO)>
</pre>
Abbildung 16 – DTD Attribute


=== Beispiel eines XML Modells ===

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Die Anforderungsbeschreibung gleicht der des Beispiels eines ER Modells in Punkt 2.1.2. In diesem Fall soll jedoch kein Datenbankmodell, sondern ein Modell für ein Dateibasiertes XML Dokument für den Datenaustausch erstellt werden. Eine mögliche Modellierung dieser Anforderungsbeschreibung als DTD findet sich in Abbildung 17 und ein mögliches darauf basierendes XML Dokument in Abbildung 18. Dabei wurde aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf.

<pre>
<!ELEMENT filialliste (filiale*)>

<!ELEMENT filiale (kredit*, konto*)>

<!ATTLIST filiale filialname ID>

<!ATTLIST filiale stadt CDATA>

<!ATTLIST filiale vermoegen CDATA>

<!ELEMENT kredit (kunde)>

<!ATTLIST kredit nummer ID>

<!ATTLIST kredit betrag CDATA>

<!ELEMENT konto (kunde)>

<!ATTLIST konto nummer ID>

<!ATTLIST konto kontostand CDATA>

<!ELEMENT kunde EMPTY>

<!ATTLIST kunde name ID>

<!ATTLIST kunde strasse CDATA>

<!ATTLIST kunde stadt CDATA>
</pre>
Abbildung 17 – Beispiel „Bank“: XML-Modell, DTD Datei

<pre>
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE bank SYSTEM "bank.dtd">

<filialliste>

<filiale filialname="Meine Bank" stadt="Wien" vermoegen="5 mrd eur">

<kredit nummer="100" betrag="200000 eur">

<kunde name="Max Muster" strasse="Musterplatz 1" stadt="Wien">

</kredit>

<kredit nummer="101" betrag="10000 eur">

<kunde name="Maria Muster" strasse="Mustergasse 3" stadt="Wien">

</kredit>

</filiale>

<filiale filialname="Deine Bank" stadt="Wien" vermoegen="1 mrd eur">

<konto nummer="200" kontostand="3000 eur">

<kunde name="Hans Meier" strasse="Mustergasse 1" stadt="Graz">

</konto>

</filiale>

<filiale filialname="Seine Bank" stadt="Wien" vermoegen="2 mrd eur">

</filiale>

</filialliste>
</pre>
Abbildung 18 – Beispiel „Bank“: XML-Modell, XML Datei


== JavaScript Object Notation (JSON) ==

Die JavaScript Object Notation (JSON) wurde ursprünglich zur Speicherung und Übertragung von Datenstrukturen in JavaScript entwickelt. Es handelt sich dabei um ein reines Textformat, welches, ähnlich wie in XML, durch die Vorgabe einer klaren Struktur, eine einheitliche Abbildung von Daten ermöglicht. JSON ist in der RFC 4627 definiert und ist wiederum Teil des ECMAScript Programming Standards, welcher wiederum die wesentlichen Objekt Literale von JavaScrip definiert. (RFC Network Working Group, 2006)

Genau wie in XML, zeichnet sich JSON durch seine Menschenlesbarkeit und die Vielzahl verfügbarer Implementierungen in allen gängigen Programmiersprachen aus. JSON ist somit nicht auf JavaScript beschränkt, hat dort jedoch seinen eigentlichen Ursprung. Damit ist auch hier eine schnelle und einfache Implementierung von Nahtstellen zwischen unterschiedlichen Anwendungen möglich. Da die Syntax in JSON wesentlich kompakter geschrieben wird, als in XML, wird es häufig für die Datenübertragungen in Webservices, wie beispielsweise Services mit REST Schnittstellen (Fielding, 2000), eingesetzt.


=== Aufbau eines JSON Dokuments ===

Die '''Elemente''' und '''Attribute''' sind in JSON werden als '''Objekte''' und '''Key-Values''' bezeichnet. Jede Struktur ist über Objekte Abgebildet, welche selbst wiederum beliebig Objekte enthalten können. Ähnlich wie in XML muss in der obersten Hierarchiestufe ein einzelnes Objekt stehen. Die gemeinsame Verschachtelung von Objekten geschieht über '''Arrays''' Struktur.

Die möglichen '''Datentypen''' der einzelnen Objekte sind:

* String,
* Number,
* Boolean und
* null.
Sie müssen jedoch nicht eigens deklariert werden, sondern ergeben sich durch ihre Schreibweise innerhalb der Datei. ''Strings'' werden mit umschließenden Anführungszeichen geschrieben, ''Numbers'' in Zahlenschreibweise ohne Anführungszeichen und ''Booleans'' direkt als Werte ''true'' und ''false''.

Objekte werden durch geschwungene Klammern ( '''{''' , '''}''' ) deklariert. Sie können beliebig viele Key-Values enthalten. Nach dem Namen einer Key-Value steht immer ein Doppelpunkt, gefolgt von ihrem enthaltenen Wert, welcher wiederum ein eigenes Objekt sein kann. Die einzelnen Key-Values werden durch Beistriche getrennt. Ein Wert kann auch ein Array aus Werten sein. Es wird durch eckige Klammern ( '''[''' , ''']''' ) deklariert und enthält beliebig viele, durch Beistriche getrennte, Werte.

Im Gegensatz zu XML gibt es in JSON Dateien '''keine Kommentare'''.

Der Text der JSON Dokumente soll laut Spezifikation (RFC Network Working Group, 2006) Unicode kodiert sein, wobei standardmäßig UTF-8 verwendet wird. Der verwendete Zeichensatz des Dokuments wird vom Parser über seine ersten beiden Zeichen erkannt. Es werden dazu die, in ihrer binären Form, enthaltenen Nullen betrachtet:

* 00 00 00 xx ergibt UTF-32BE <ref>Die Zusätze ''BE'' und ''LE'' steht für ''Big Endian'' und ''Little Endian'' und beziehen sich auf die Reihenfolge in der die einzelnen Bits des Zeichens gespeichert werden. Somit steht das erste Bit des Zeichens entweder links (LE) oder rechts (BE) in der binären Abbildung.</ref> ,
* 00 xx 00 xx ergibt UTF-16BE,
* xx 00 00 00 ergibt UTF-32LE,
* xx 00 xx 00 ergibt UTF-16LE und
* xx xx xx xx ergibt UTF-8.
In Abbildung 19 ist ein JSON Objekt für eine Person definiert, welches Key-Values für einen Vornamen, einen Nachnamen und eine Ausweisnummer enthält. Weiter hat die Person ein Array mit Objekten, welche je einen Schlüssel der Person mit der jeweiligen Raumnummer abbilden.
<pre>
{"vorname" : "Peter",

"nachname" : "Völkl",

"ausweisnummer" : 1234567,

"schluessel" : [{"raumnummer" : 22},{"raumnummer" : 33}]

}
</pre>
Abbildung 19 – Beispiel JSON Objekt


=== JSON Schema ===

Im Gegensatz zu XML gibt es bei JSON Daten keine standardisierte Möglichkeit eine eigene, formale, Definition zu erstellen, gegen welche die Struktur automatisiert geprüft werden kann. Eine entsprechende Standardisierung, das JSON Schema, befindet sich derzeit in Ausarbeitung und liegt bereits im Entwurfsstadium vor. Es kann jedoch aktuell nicht davon ausgegangen werden, dass diese unfertige Standardisierung mit jedem Parser eingesetzt werden kann. (Galiegue, 2013)


=== Beispiel eines JSON Modells ===

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Die Anforderungsbeschreibung gleicht der des Beispiels des ER Modells in Punkt 2.1.2 und des XML Modells in Punkt 2.2.5. Die JSON Struktur könnte beispielsweise dem Austausch von Filialdaten über ein Webservice dienen. Eine mögliche Modellierung dieser Anforderungsbeschreibung findet sich nachfolgend in Abbildung 17. Dabei wurde ebenfalls wieder aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf. Die, in dem Beispiel enthaltenen, Einrückungen dienen der besseren Lesbarkeit und nicht erforderlich.

<pre>
{"filialliste" : [ {"filialname“ : "Meine Bank",

"stadt" : "Wien",

"vermoegen" : "5 mrd eur",

"kredite" : [ {"nummer" : "100",

"betrag" : "20000 eur"},

"kunde" : {"name" : "Max Muster",

"strasse" : "Musterplatz 1",

"stadt" : "Wien"}

},

{"nummer" : "101",

"betrag" : "10000 eur"},

"kunde" : {"name" : "Maria Muster",

"strasse" : "Mustergasse 3",

"stadt" : "Wien"}

}

],

"konten" : []

},

{"filialname“ : "Deine Bank",

"stadt" : "Wien",

"vermoegen" : "1 mrd eur",

"kredite" : [],

"konten" : [ {"nummer" : "200",

"betrag" : "3000 eur"},

"kunde" : {"name" : "Hans Meier",

"strasse" : "Mustergasse 1",

"stadt" : "Graz"}

}

]

},
</pre>
Abbildung 20 – Beispiel „Bank“: JSON-Modell, Teil 1/2

<pre>
{"filialname“ : "Seine Bank",

"stadt" : "Wien",

"vermoegen" : "2 mrd eur",

"kredite" : [],

"konten" : []

} ]

}
</pre>
Abbildung 21 – Beispiel „Bank“: JSON-Modell, Teil 2/2

Grundlagen der Modellierung - Datenmodellierung

2022-11-02T11:53:55Z

VÖLKL Peter:

= Datenmodellierung =

Bei der Datenmodellierung geht es um die zweckmäßige und effiziente Strukturierung von Daten in Informationssystemen. Die Modelle behandeln unterschiedliche Arten von Speicheranwendungen. Beispielsweise ist das ER-Modell im Bereich der Datenbanksysteme beheimatet, XML und JSON dahingegen im Bereich der Nahtstellen und Datenstrukturen innerhalb und zwischen einzelnen Systemen auf Dateiebene.


== Entity-Relationship Modell (ER-Modell) ==

Das Entity-Relationship Modell (ER-Modell) wurde bereits im vorherigen Semester, im Studienheft „Datenbanksysteme“ (Schikuta, E.), genau erläutert. Nachfolgend werden nun die wesentlichen Punkte dieses Skriptums nochmals auszugsweise wiederholt.

Das '''Entity-Relationship-Modell (ER-Modell)''' ist eines der ältesten (Chen, 1976) und am weitesten verbreiteten Modelle zum Entwurf von Datenbankmodellen und wird auch gerne im Bereich der allgemeinen Software Entwicklung eingesetzt. Durch seine besonders einfachen Darstellungsmöglichkeiten ist es sehr gut für die Kommunikation mit den Endbenutzern geeignet.

Die Grundidee des Entity-Relationship-Modells (Objekt-Beziehungs-Modell) besteht darin, die Welt als Sammlung von '''Entitäten (Entity''' oder '''Objekttypen''') und '''Beziehungen''' ('''Relationship''') zwischen diesen Objekttypen zu sehen.


=== Modellierungsobjekte des ER-Modells ===


==== Entitäten ====

Ein Objekt wird '''Entität-Instanz''' genannt. Entität-Instanzen sind dabei einzelne Exemplare von Dingen oder Begriffen. Dies können beispielsweise sein:

* Personen: der Kunde, Lieferant, Mitarbeiter etc.
* Gegenstände: Handelsware, Rohstoff, Maschine etc.
* Abstrakte Begriffe: Konto, Buchung, Bestellung etc.
Entität-Instanzen mit gleichen Eigenschaften lassen sich zu Entitäten (Objekttypen) zusammenfassen, z.B. Kunden, Bestellungen etc. Die Eigenschaften einer Entität-Instanz werden durch '''Attribute''' beschrieben, z.B. Name, Baujahr, Preis, Bestellnummer.

Hinweis: Im ER – Modell bezeichnet der Begriff Entität immer eine Klasse (Typ) von Instanzen, nicht eine Instanz!

Zwischen zwei, aber auch mehr, Entitäten können Beziehungen bestehen, z.B. „Kunde bestellt Maschine“. Die Beziehung wird dabei durch die Rolle der an ihr beteiligten Entitäten beschrieben. Die Beziehungen können zwischen Entitäten gleichen Typs oder zwischen Entitäten verschiedenen Typs bestehen.

Die wichtigsten Symbole in der grafischen Notation des ER-Modells werden in Abbildung 2 dargestellt.

[[Datei:Wiba mt233 201607 a.007.png|300px|none|thumb|Grafische Notation im ER-Modell]]

Attribute können auch Beziehungen zugeordnet werden (siehe Abbildung 3). Hier ist bei der Modellierung zu entscheiden, ob dieses Beziehungsattribut nicht einer der beiden Entitäten zugeordnet werden kann oder soll.

[[Datei:Wiba mt233 201607 a.008.png|300px|none|thumb|Beispiel Beziehungsattribut]]

Eine minimale Menge von Attributen, deren Werte die zugeordnete Entität-Instanz eindeutig innerhalb aller Instanzen seines Objekttyps identifiziert, nennt man '''Schlüssel'''. Oft gibt es Attribute, die künstlich als Schlüssel eingebaut werden, z.B. Personalnummer, Vorlesungsnummer, …

Schlüsselattribute werden durch Unterstreichen (manchmal auch durch doppelt gezeichnete Ovale) gekennzeichnet (siehe Abbildung 4).

[[Datei:Wiba mt233 201607 a.009.png|300px|none|thumb|Beispiel Schlüsselattribut]]

==== Beziehungen ====

Beziehungen repräsentieren eigentlich Aggregate von zwei oder mehreren an der Beziehung teilnehmenden Entitäten. Die Anzahl der aggregierten Entitäten heißt '''Grad''' der Beziehung (unäre, binäre, n-äre Beziehung). Entitäten haben in einer Beziehung eine minimale und eine maximale '''Kardinalität''' bzw. Komplexität.

Die Beziehungen können vom Typ '''1:1''', '''1:n''', '''n:1''', oder '''m:n''' sein. Entsprechende Beispiele für die einzelnen Kardinalitäten findet man in Abbildung 5:

[[Datei:Wiba mt233 201607 a.010.png|300px|none|thumb|Beispiele Kardinalitäten]]

Diese Kardinalitäten können folgendermaßen interpretiert werden:

* 1:1 – ein Ehemann hat genau eine Ehefrau (normalerweise), und umgekehrt.
* 1:n – ein Kunde besitzt mehrere Konten, aber jedes Konto gehört genau einem Kunden.
* m:n – Ein Kunde kann mehrere Artikel kaufen und jeder Artikel kann von mehreren Kunden gekauft werden.
Bei der Angabe der Kardinalitäten ist es auch möglich Intervalle durch Angabe der minimalen und maximalen Kardinalität zu definieren. In Abbildung 6 ist sowohl eine n:m und eine n:1 Beziehung definiert, wobei das Maximum der Kardinalität die Beziehungsmultiplizität definiert.

[[Datei:Wiba mt233 201607 a.011.png|300px|none|thumb|Beispiel Kardinalitäten mit Intervallen]]

Im obigen Beispiel sieht man, dass es ohne weiters möglich ist, auch mehr als eine Beziehung zwischen Entitäten zu definieren. Im spezifischen Fall sind dies zwei binäre Beziehungen.

In manchen Fällen ist es notwendig auch n-äre Beziehungen zu modellieren. In der Abbildung 7 ist eine ternäre Beziehung dargestellt und die entsprechende Interpretation der Kardinalitäten angegeben.

[[Datei:Wiba mt233 201607 a.012.png|300px|none|thumb|Beispiel ternäre Beziehung]]

Es ist aber empfohlen n-äre Beziehungen nur in wirklich begründeten Fällen zu modellieren.

Unter einer '''schwachen Entität''' versteht man eine Entität, die kein Schlüsselattribut besitzt (d.h. wo die Instanzen nicht eindeutig unterschieden werden können). Solche Instanzen können nur über eine Beziehung zu einer anderen Entität eindeutig identifiziert werden. Schwache Entitäten werden grafisch durch einen doppelten Rand gekennzeichnet.

Im nachfolgenden Beispiel Abbildung 8 ergibt sich die schwache Entität dadurch, dass ein Hörsaal durch seine Nummer, Größe und seinen Typ nicht eindeutig auf einem Universitätscampus identifiziert werden kann, auf dem es eine Vielzahl von Gebäuden mit jeweils mehreren Hörsälen gibt, die in jedem Gebäude von der Nummer 1 an gezählt werden. Das bedeutet es gibt in jedem Gebäude einen Hörsaal mit der Nummer 1. Erst mit der Angabe des Gebäudes (identifying owner) kann dadurch jeder Hörsaal eindeutig identifiziert werden.

[[Datei:Wiba mt233 201607 a.013.png|300px|none|thumb|Beispiel Schwache Entität]]


=== Beispiel eines ER-Modells ===

Im abschließenden (vereinfachten) Beispiel dieser Lektion wollen wir, basierend auf einem gegebenen Ausschnitt der Realität einer „Bank“, eine Modellierung mit Hilfe des ER-Modells durchführen.

Ausgangsposition für unseren Ansatz bildet eine Anforderungsbeschreibung in natürlichsprachiger Form. Es wird angenommen, dass sich diese Beschreibung aus den Interviews mit den Benutzern bzw. Auftragsgebern ergeben hat. Eine in der Praxis simple, aber übliche Vorgangsweise, um Entitätskandidaten zu erhalten, ist alle Hauptworte im Text zu identifizieren und als ersten Ansatz für Entitäten zu verwenden. Dieses Verfahren wird in der CRC-Methode vertieft (siehe die Aufgaben zu dieser Lektion).

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Eine mögliche Modellierung dieser Anforderungsbeschreibung als ER-Modell findet man in Abbildung 9.

[[Datei:Wiba mt233 201607 a.014.png|300px|none|thumb|Beispiel „Bank“: ER-Modell]]

== Extensible Markup Language (XML) ==

Die Extensible Markup Language (XML) ist ein Standard für den Aufbau von Dateidokumenten. Sie wurde vom World Wide Web Consortium (W3C) entwickelt. Es handelt sich dabei um eine sehr flexible Modellierungsform für Textformate welche wiederum von der Standard Generalized Markup Language (SGML, ISO8879) abgeleitet wurde. (World Wide Web Consortium (W3C), 2014)

''XML ist eine Markup-Sprache, und es ist nur eine Markup-Sprache. […] Der XML-Hype ist so extrem geworden, dass viele Leute glauben, XML könne sogar Kaffee kochen der den Familienhund waschen.'' (Harold & Means, 2005, S. 5)

Die Designziele von XML selbst sind (World Wide Web Consortium (W3C), 2008):

* XML soll direkt und unkompliziert über das Internet nutzbar sein,
* XML soll eine große Anzahl unterschiedlicher Applikationen unterstützen,
* XML soll mit SGML kompatibel sein,
* eine Programmierung von Anwendungen, welche XML Dokumente verarbeiten können, soll einfach möglich sein,
* die Anzahl von optionalen Features soll in XML so gering wie möglich gehalten werden und optimal Null sein,
* XML Dokumente sollen menschenlesbar und leicht verständlich sein,
* die Modellierung von XML Dokumenten soll schnell erstellt werden können,
* das Design von XML Dokumenten soll formal und präzise sein,
* die Erstellung von XML Dokumenten soll einfach sein und
* die Kürze und Kompaktheit der XML Elemente ist von geringer Bedeutung.
Der Hauptvorteil bei XML liegt, im Gegensatz zu eigen entwickelten Dateistrukturmodellen, in der schnellen und einheitlichen Verarbeitbarkeit für den Entwickler. In nahezu jeder gängigen Programmiersprache existieren bereits fertige Parser, welche die Generierung und Verarbeitung der Datenstrukturen, ohne größeren Programmieraufwand, ermöglichen.


=== Aufbau eines XML Dokuments ===

Jedes XML Dokument beinhaltet '''ein einziges''' XML '''Wurzel-Element''', welches selbst jeweils wiederum beliebig viele weitere '''Elemente''' beinhalten kann. Alle Elemente dürfen wiederum beliebig viele weitere Elemente enthalten. Zusätzlich kann das Dokument '''XML Deklarationen''', auch bezeichnet als Processing Instructions (PI), und beliebig viele '''Kommentare''' enthalten. Die Zeichenkodierung der Dokumente darf '''alle Unicodezeichen''' enthalten, wobei jedes XML verarbeitende Programm zumindest die Kodierungen UTF-8 und UTF-16 akzeptieren muss. Alle Bezeichnungen eines Dokuments, seien es die von Elementen oder Attributen, sind '''Case Sensitive'''. Da es sich dabei um ein einfaches Textdokument handelt, kann es auch von allen Texteditoren und Internetbrowsern, ohne weitere Hilfsmittel und Plugins, angezeigt werden. (World Wide Web Consortium (W3C), 2008)

Vom Aufbau sehen sich XML und HTML (Hypertext Markup Language) Dokumente sehr ähnlich. Sie unterscheiden sich jedoch darin, dass die Art und teilweise die Anzahl der Elemente in HTML fest vorgegeben, in XML jedoch alle Elemente frei modellierbar, sind. Das Metamodell der zu verwendeten Elemente eines XML Dokuments kann somit vom Modellierer selbst festgelegt werden. HTML dient der Modellierung von Webseitendokumenten und hat fest vorgegebene Strukturen und Elemente um eine einheitliche grafische Verarbeitung durch die Internetbrowser zu ermöglichen. Das Design der Elemente selbst ist jedoch in beiden Fällen sehr restriktiv vorgegeben.

Die '''XML Deklaration''' gibt die eingesetzte XML Version, und optional das Encoding, an. Dadurch wird den verarbeitenden Programmen die Verarbeitung erleichtert. Gerade die Angabe des Encodings kann viele Verarbeitungsprobleme im Vorfeld abfangen, da der Parser damit die eingesetzten Zeichen kennt und sie korrekt interpretieren kann. Nachfolgend ist in Abbildung 10 ein minimales XML Dokument dargestellt, welches nur eine XML Deklaration und ein einzelnes XML Element, namens „mein_wurzel_element“, ohne weitere Attribute und ohne Wert, beinhaltet.

<pre><?xml version="1.0" encoding="UTF-8"?>

<mein_wurzel_element /></pre>
Abbildung 10 – Minimales XML Dokument

Da einige Zeichen in der XML Syntax eine spezielle Bedeutung haben, müssen sie im Text nötigenfalls in einer anderen Form geschrieben werden, um sie innerhalb von XML Elementen nutzen zu können:

* < wird zu ''&lt;''
* > wird zu ''&gt;''
* " wird zu ''&quot;''
* ' wird zu ''&apos;''
* & wird zu ''&amp;''


=== XML-Elemente ===

Die einzelnen XML Elemente sind alle nach demselben Schema aufgebaut. Sie haben eine '''Elementbezeichnung''' und können '''beliebig viele Attribute''' enthalten. Weiter können sie selbst einen '''Inhalt''' haben, welcher wiederum aus Elementen bestehen kann.

Ein Element besteht aus einem oder zwei sogenannten Tags. Ein '''Tag''' wird durch '''spitze Klammern (<,>)''' an seinem Beginn und Ende ausgezeichnet. Ob ein Element aus '''einem oder zwei Tags''' besteht, hängt davon ab, '''ob es selbst einen eigenen Inhalt''' besitzt, oder nicht. Der Inhalt kann aus Text oder weiteren Elementen bestehen. Am '''Beginn''' jedes Tags steht der '''Name des Elements'''.

Hat ein Element '''keinen''' '''Inhaltsbereich''', besteht es aus nur '''einen einzigen Tag.''' Dessen abschließenden spitzen Klammer wird ein Schrägstrich vorangestellt ''(<elementname />'') um die Abwesenheit eines Inhaltbereiches zu signalisieren.

Sollte das Element dahingegen '''einen Inhaltsbereich''' haben, wird der erste Tag durch eine einfache spitze Klammer geschossen ''(<elementname>''). Danach folgt dann der eigentliche Inhalt des Elements. Nach dem Inhalt, und damit am Ende des Elements, steht in diesem Fall ein zweiter Tag, welcher wiederum einen Schrägstrich nach der einleitenden spitzen Klammer hat (''</elementname>).''

Die '''Attribute''' eines Elements befinden sich immer innerhalb des ersten Tags. In einem Element darf ein gewählter Attributname nur einmal vorkommen. Somit ist es beispielsweise nicht möglich einem Element „person“ mehrmals das Attribut „name“ zu zuzuweisen. die Reihenfolge der einzelnen Attribute eines Elements ist dahingegen nicht relevant und kann beliebig gewählt werden. Ein möglicher Aufbau eines Elements „person“ mit den Attributen „vorname“, „nachname“ und „ausweisnummer“ ist in Abbildung 11 dargestellt.

<person vorname="Peter" nachname="Völkl" ausweisnummer="1234567"/>

Abbildung 11 – XML Element „person“

In Abbildung 12 sind weiter:

* ein Element ''„element_1“'' ohne Inhalt und ohne Attribute,
* ein Element ''„element_2“'' ohne Inhalt und mit Attributen,
* ein Element ''„element_3“'' mit Inhalt und ohne Attributen,
* ein Element ''„element_4“'' mit Inhalt und mit Attribut und
* ein Element ''„element_5“'' mit Attributen und weiteren Elementen im Inhalt exemplarisch dargestellt.
<pre><element_1 />

<element_2 attribut_1="Attributwert 1" attribut_2="Attributwert 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein Inhaltstext</element_3>

<element_4 attribut_1="Wert 1">Noch ein Inhaltstext</element_4>

<element_5 attribut_1="Attributwert 1">

<element_1 />

<element_2 attribut1="Test 1" 
attribut_2="Test 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein anderer Inhaltstext</element_3>

</element_5>
</pre>
Abbildung 12 – XML Elemente mit unterschiedlichen Tags


=== Kommentare ===

Zusätzlich zu den Deklarationen und Elementen, kann ein XML Dokument auch Kommentare enthalten. Diese können sich an jeder Position im Dokument befinden an der auch ein Element stehen dürfte, also überall außer im Attributbereich eines Tags. Sie werden bei der Interpretation des Dokuments ignoriert. Kommentare dienen primär der Lesbarkeit durch Menschen. Mit ihnen können einzelne Teile des Dokuments mit Erklärungen versehen werden, die dem Anwender bei nicht automatisierter Betrachtung helfen können, den Inhalt zu verstehen.

Ein Kommentar ist hinlänglich seines Inhaltes kaum beschränkt. Es darf einzig keine zwei direkt zusammenhängenden Minuszeichen (--) enthalten. Sollte sich innerhalb eines Kommentars ein XML Element befinden, wird es nicht als Element, sondern als Kommentartext interpretiert. Damit können auch einzelne Teile eines Dokuments „auskommentiert“ werden, um sie bei der Interpretation zu ignorieren, ohne sie aus dem Dokument löschen zu müssen. Dies ist gerade bei der Entwicklung von Schnittstellen hilfreich, da die Musterdateien somit abgeändert werden können, ohne einzelne Inhalte zu löschen.

Kommentare werden durch die Zeichenfolge '''' wieder beendet. Alle Zeichen, welche sich zwischen diesen beiden Teilen befinden gelten damit als Kommentartext und nicht als XML Element.


=== Document Type Definitions (DTD) ===

Die Document Type Definition (DTD) wird verwendet um die '''Struktur eines XML Dokuments''' zu definieren. Ohne eine DTD darf es auf beliebigen Elementen in beliebiger Reihenfolge mit beliebigem Inhalt und Attributen aufgebaut sein. Die DTD schränkt nun genau diese Freiheit wieder ein und definiert damit das '''Metamodell des XML Dokuments'''.

Um, in einem XML Dokument, eine zugehörige DTD anzugeben. Wird eine eigene Deklaration verwendet, welche am Beginn des Dokumentes nach der XML Deklaration stehen muss. Sie wird mit ''<!DOCTYPE'' eingeleitet und wiederum mit einer einfachen Spitzen Klammer abgeschlossen. Es kann auch mehrere dieser Deklarationen in einem Dokument geben.

Innerhalb der DTD Deklaration des XML Dokuments wird zuerst der Name der Dokumentenart angegeben und danach einer der Identifier SYSTEM oder PUBLIC, sowie ihre zugehörigen Parameter.

Der Identifier '''''SYSTEM''''' gibt an, dass es sich dabei um eine eigene Definition handelt. Der zugehörige Parameter ist hierbei der Pfad zu der Datei, welche die angegebene DTD enthält.

Der Identifier '''''PUBLIC''''' weist auf eine allgemein standardisierte DTD hin, welche dem XML Parser bekannt sein sollte. Hier werden zwei Parameter benötigt. Der Erste gibt an, um welchen Public Identifier es sich dabei handelt und der zweite Parameter verweist optional auf eine alternative DTD Datei, welche verwendet wird falls der genannte Identifier dem Parser nicht bekannt ist.

In Abbildung 13 ist die Deklaration einer eigenen DTD „schema.dtd“ angegeben und in Abbildung 14 die Deklaration eines XML Dokumentes als, dem System bekannten, Dokumententyp HTML.

<!DOCTYPE mein_schema SYSTEM "schema.dtd">

Abbildung 13 – XML DOCTYPE für eigene DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 //EN" "http://www.w3.org/TR/html4/strict.dtd">

Abbildung 14 – XML DOCTYPE für HTML

In der DTD Datei können nun die einzelnen Elemente und die Struktur des XML Dokuments definiert werden:

* '''Elemente''' werden durch <!ELEMENT …> und
* '''Attribute''' über <!ATTLIST …> definiert.
'''Element Definition <!ELEMENT …>'''

Bei der Definition eines Elements wird sowohl die '''Bezeichnung des Elements''', als auch sein '''möglicher Inhalt''' definiert. Dabei wird als erstes der Elementname und dahinter der Inhalt in Klammer angegeben.

Der '''Inhalt''' kann entweder:

* leer (Schlüsselwort '''''EMPTY'''''),
* beliebig (Schlüsselwort '''''ANY'''''),
* reiner Text (Schlüsselwort '''''#PCDATA''''') oder
* weitere Elemente (Angabe des gewünschten '''Elementnamen''') sein.
Dabei sind auch die Angaben unterschiedlicher Inhalte und Typen kombinierbar.

Sollen mehrere Inhalte, wie beispielsweise unterschiedliche Elemente, beinhaltet sein, werden diese innerhalb der Klammer durch '''Beistriche''' ( ''',''' ) oder '''Pipes''' ( '''|''' ) getrennt.

Dabei gibt ein '''Beistrich''' das Vorhandensein beider Elemente in '''genau dieser Reihenfolge''' und eine '''Pipe''' das Vorhandensein '''nur''' '''eines der beiden Elemente''' an.

Weiter sind auch '''Verschachtelungen''' dieser beiden Operatoren durch Setzen von '''Klammern''' zulässig.

Zusätzlich gibt es noch die Möglichkeit hinter jedem Element, oder Klammerausdruck, anzugeben, ob das Element:

* '''optional''' ist (durch ein Fragezeichen: '''?'''),
* beliebig '''oft aber''' '''mindestens einmal''' vorkommt (durch ein Pluszeichen: '''+''') oder
* '''beliebig oft''' '''und optional''' vorkommen kann (durch einen Stern: '''*''').
Wird hinter einem Eintrag keine Angabe über die Häufigkeit gemacht, muss er genau einmal vorkommen.

Im nachfolgenden Beispiel, in Abbildung 15, sind folgende Elemente definiert:

* ''element_1'' hat keinen Inhalt,
* ''element_2'' hat einen Textinhalt,
* ''element_3'' beinhaltet ''element_1'' und ''element_2'',
* ''element_4'' beinhaltet ''element_1'' und (entweder ''element_2'' oder ''element_3''),
* ''element_5'' beinhaltet 0-n Mal ''element_1'' und 1-n Mal ''element_4'',
* ''element_6'' beinhaltet optional ''element_4'',
* ''element_7'' beinhaltet ''element_1'' und optional ''element_7'' und
* ''element_8'' beinhaltet beliebig viele ''element_1'', ''element_2'' und ''element_3'' in beliebiger Reihenfolge.
Bei der Definition von verschachtelten Elementen sind auch '''Rekursionen zulässig''', wie das gerade genannte Beispiel mit element_7 zeigt. Hier muss jedoch darauf geachtet werden, die Rekursion '''als optional zu deklarieren''' (Angabe von ?, * oder |), da die Rekursion sonst verpflichtend endlos und damit nie erfüllbar wäre.

<pre><!ELEMENT element_1 EMPTY>

<!ELEMENT element_2 #PCDATA>

<!ELEMENT element_3 (element_1, element_2)>

<!ELEMENT element_4 (element_1, (element_2 | element_3))>

<!ELEMENT element_5 (element_1*, element_4+)>

<!ELEMENT element_6 (element_4?)>

<!ELEMENT element_7 (element_1, element_7?)>

<!ELEMENT element_8 (element_1|element_2|element_3)*>
</pre>
Abbildung 15 – DTD Elemente

'''Attribut Definition <!ATTLIST …>'''

Um ein definiertes Element '''mit Attributen auszustatten''' wird mittels ''<!ATTLIST'' eine Attributliste definiert. Dazu wird zuerst der '''Name''' des Elements angegeben, für das die Attributliste gilt sowie danach der '''Attributname''' und sein '''Typ,''' sowie optional eine Definition von möglichen Werten und ob der Parameter verpflichtend vorkommen muss. Dabei können entweder '''mehrere Attribute in einer Definition''' '''oder jedes Attribut einzeln''' in einer '''eigenen Definition''' angegeben werden.

Mögliche Datentypen für Attribute sind:

* '''''CDATA''''' für beliebige Zeichenketten,
* '''''ID''''' für einen eindeutigen Wert unter den Elementen desselben Typs innerhalb des XML Dokuments,
* '''''IDREF''''' für eine Referenz auf ein anderes Element desselben Typs innerhalb des Dokuments mittels Wert des ID Attributs,
* '''''ENTITY''''' für eine Referenz auf ein externes Element,
* '''''ENTITYS''''' für eine Liste von ''ENTITY‘s'',
* '''''NMTOKEN''''' für einen Namen (eine Bezeichnung) des Elements innerhalb des XML Dokuments,
* '''''NMTOKENS''''' für eine Liste von ''NMTOKEN’s'' oder
* eine fest definierte '''Menge möglicher Eingabewerte''', getrennt durch Pipes in der Form ''(wert1|wert2|wert2).''
Zusätzlich kann hinter der Angabe des Datentyps noch:

* '''#REQUIRED''', für verpflichtend anzugebende Attribute,
* '''#IMPLIED''', für optionale Attribute,
* oder ein '''automatischer Standardwert''' in Anführungszeichen,
angegeben werden.

Eine Sonderform der Angabe des Standardwertes ist der Parameter '''#FIXED''', gefolgt von einem Standardwert in Anführungszeichen. Dabei handelt es sich um einen nicht veränderbaren Standardwert bzw. einen statischen Attributwert.

Im nachfolgenden Beispiel, in Abbildung 16, wird eine DTD für ein Element ''element_1'' mit den Attributen ''e1_id'', welches eine eindeutige ID innerhalb des Dokuments enthält, ''e1_name'', welches eine eindeutige Bezeichnung des Element enthält, ''e1_kommentar'', welches einen Kommentartext enthalten soll und ''e1_wochentag'', welches ein Wochentagkürzel enthält.<pre><!ELEMENT element_1 EMPTY>

<!ATTLIST element_1 e1_id ID>

<!ATTLIST element_1 e1_name ENTITY>

<!ATTLIST element_1 e1_kommentar CDATA>

<!ATTLIST element_1 e1_wochentag (MO|DI|MI|DO|FR|SA|SO)>
</pre>
Abbildung 16 – DTD Attribute


=== Beispiel eines XML Modells ===

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Die Anforderungsbeschreibung gleicht der des Beispiels eines ER Modells in Punkt 2.1.2. In diesem Fall soll jedoch kein Datenbankmodell, sondern ein Modell für ein Dateibasiertes XML Dokument für den Datenaustausch erstellt werden. Eine mögliche Modellierung dieser Anforderungsbeschreibung als DTD findet sich in Abbildung 17 und ein mögliches darauf basierendes XML Dokument in Abbildung 18. Dabei wurde aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf.

<!ELEMENT filialliste (filiale*)>

<!ELEMENT filiale (kredit*, konto*)>

<!ATTLIST filiale filialname ID>

<!ATTLIST filiale stadt CDATA>

<!ATTLIST filiale vermoegen CDATA>

<!ELEMENT kredit (kunde)>

<!ATTLIST kredit nummer ID>

<!ATTLIST kredit betrag CDATA>

<!ELEMENT konto (kunde)>

<!ATTLIST konto nummer ID>

<!ATTLIST konto kontostand CDATA>

<!ELEMENT kunde EMPTY>

<!ATTLIST kunde name ID>

<!ATTLIST kunde strasse CDATA>

<!ATTLIST kunde stadt CDATA>

Abbildung 17 – Beispiel „Bank“: XML-Modell, DTD Datei

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE bank SYSTEM "bank.dtd">

<filialliste>

<filiale filialname="Meine Bank" stadt="Wien" vermoegen="5 mrd eur">

<kredit nummer="100" betrag="200000 eur">

<kunde name="Max Muster" strasse="Musterplatz 1" stadt="Wien">

</kredit>

<kredit nummer="101" betrag="10000 eur">

<kunde name="Maria Muster" strasse="Mustergasse 3" stadt="Wien">

</kredit>

</filiale>

<filiale filialname="Deine Bank" stadt="Wien" vermoegen="1 mrd eur">

<konto nummer="200" kontostand="3000 eur">

<kunde name="Hans Meier" strasse="Mustergasse 1" stadt="Graz">

</konto>

</filiale>

<filiale filialname="Seine Bank" stadt="Wien" vermoegen="2 mrd eur">

</filiale>

</filialliste>

Abbildung 18 – Beispiel „Bank“: XML-Modell, XML Datei


== JavaScript Object Notation (JSON) ==

Die JavaScript Object Notation (JSON) wurde ursprünglich zur Speicherung und Übertragung von Datenstrukturen in JavaScript entwickelt. Es handelt sich dabei um ein reines Textformat, welches, ähnlich wie in XML, durch die Vorgabe einer klaren Struktur, eine einheitliche Abbildung von Daten ermöglicht. JSON ist in der RFC 4627 definiert und ist wiederum Teil des ECMAScript Programming Standards, welcher wiederum die wesentlichen Objekt Literale von JavaScrip definiert. (RFC Network Working Group, 2006)

Genau wie in XML, zeichnet sich JSON durch seine Menschenlesbarkeit und die Vielzahl verfügbarer Implementierungen in allen gängigen Programmiersprachen aus. JSON ist somit nicht auf JavaScript beschränkt, hat dort jedoch seinen eigentlichen Ursprung. Damit ist auch hier eine schnelle und einfache Implementierung von Nahtstellen zwischen unterschiedlichen Anwendungen möglich. Da die Syntax in JSON wesentlich kompakter geschrieben wird, als in XML, wird es häufig für die Datenübertragungen in Webservices, wie beispielsweise Services mit REST Schnittstellen (Fielding, 2000), eingesetzt.


=== Aufbau eines JSON Dokuments ===

Die '''Elemente''' und '''Attribute''' sind in JSON werden als '''Objekte''' und '''Key-Values''' bezeichnet. Jede Struktur ist über Objekte Abgebildet, welche selbst wiederum beliebig Objekte enthalten können. Ähnlich wie in XML muss in der obersten Hierarchiestufe ein einzelnes Objekt stehen. Die gemeinsame Verschachtelung von Objekten geschieht über '''Arrays''' Struktur.

Die möglichen '''Datentypen''' der einzelnen Objekte sind:

* String,
* Number,
* Boolean und
* null.
Sie müssen jedoch nicht eigens deklariert werden, sondern ergeben sich durch ihre Schreibweise innerhalb der Datei. ''Strings'' werden mit umschließenden Anführungszeichen geschrieben, ''Numbers'' in Zahlenschreibweise ohne Anführungszeichen und ''Booleans'' direkt als Werte ''true'' und ''false''.

Objekte werden durch geschwungene Klammern ( '''{''' , '''}''' ) deklariert. Sie können beliebig viele Key-Values enthalten. Nach dem Namen einer Key-Value steht immer ein Doppelpunkt, gefolgt von ihrem enthaltenen Wert, welcher wiederum ein eigenes Objekt sein kann. Die einzelnen Key-Values werden durch Beistriche getrennt. Ein Wert kann auch ein Array aus Werten sein. Es wird durch eckige Klammern ( '''[''' , ''']''' ) deklariert und enthält beliebig viele, durch Beistriche getrennte, Werte.

Im Gegensatz zu XML gibt es in JSON Dateien '''keine Kommentare'''.

Der Text der JSON Dokumente soll laut Spezifikation (RFC Network Working Group, 2006) Unicode kodiert sein, wobei standardmäßig UTF-8 verwendet wird. Der verwendete Zeichensatz des Dokuments wird vom Parser über seine ersten beiden Zeichen erkannt. Es werden dazu die, in ihrer binären Form, enthaltenen Nullen betrachtet:

* 00 00 00 xx ergibt UTF-32BE <ref>Die Zusätze ''BE'' und ''LE'' steht für ''Big Endian'' und ''Little Endian'' und beziehen sich auf die Reihenfolge in der die einzelnen Bits des Zeichens gespeichert werden. Somit steht das erste Bit des Zeichens entweder links (LE) oder rechts (BE) in der binären Abbildung.</ref> ,
* 00 xx 00 xx ergibt UTF-16BE,
* xx 00 00 00 ergibt UTF-32LE,
* xx 00 xx 00 ergibt UTF-16LE und
* xx xx xx xx ergibt UTF-8.
In Abbildung 19 ist ein JSON Objekt für eine Person definiert, welches Key-Values für einen Vornamen, einen Nachnamen und eine Ausweisnummer enthält. Weiter hat die Person ein Array mit Objekten, welche je einen Schlüssel der Person mit der jeweiligen Raumnummer abbilden.

{"vorname" : "Peter",

"nachname" : "Völkl",

"ausweisnummer" : 1234567,

"schluessel" : [{"raumnummer" : 22},{"raumnummer" : 33}]

}

Abbildung 19 – Beispiel JSON Objekt


=== JSON Schema ===

Im Gegensatz zu XML gibt es bei JSON Daten keine standardisierte Möglichkeit eine eigene, formale, Definition zu erstellen, gegen welche die Struktur automatisiert geprüft werden kann. Eine entsprechende Standardisierung, das JSON Schema, befindet sich derzeit in Ausarbeitung und liegt bereits im Entwurfsstadium vor. Es kann jedoch aktuell nicht davon ausgegangen werden, dass diese unfertige Standardisierung mit jedem Parser eingesetzt werden kann. (Galiegue, 2013)


=== Beispiel eines JSON Modells ===

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Die Anforderungsbeschreibung gleicht der des Beispiels des ER Modells in Punkt 2.1.2 und des XML Modells in Punkt 2.2.5. Die JSON Struktur könnte beispielsweise dem Austausch von Filialdaten über ein Webservice dienen. Eine mögliche Modellierung dieser Anforderungsbeschreibung findet sich nachfolgend in Abbildung 17. Dabei wurde ebenfalls wieder aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf. Die, in dem Beispiel enthaltenen, Einrückungen dienen der besseren Lesbarkeit und nicht erforderlich.

{"filialliste" : [ {"filialname“ : "Meine Bank",

"stadt" : "Wien",

"vermoegen" : "5 mrd eur",

"kredite" : [ {"nummer" : "100",

"betrag" : "20000 eur"},

"kunde" : {"name" : "Max Muster",

"strasse" : "Musterplatz 1",

"stadt" : "Wien"}

},

{"nummer" : "101",

"betrag" : "10000 eur"},

"kunde" : {"name" : "Maria Muster",

"strasse" : "Mustergasse 3",

"stadt" : "Wien"}

}

],

"konten" : []

},

{"filialname“ : "Deine Bank",

"stadt" : "Wien",

"vermoegen" : "1 mrd eur",

"kredite" : [],

"konten" : [ {"nummer" : "200",

"betrag" : "3000 eur"},

"kunde" : {"name" : "Hans Meier",

"strasse" : "Mustergasse 1",

"stadt" : "Graz"}

}

]

},

Abbildung 20 – Beispiel „Bank“: JSON-Modell, Teil 1/2

{"filialname“ : "Seine Bank",

"stadt" : "Wien",

"vermoegen" : "2 mrd eur",

"kredite" : [],

"konten" : []

} ]

}

Abbildung 21 – Beispiel „Bank“: JSON-Modell, Teil 2/2

Grundlagen der Modellierung - Datenmodellierung

2022-11-02T11:52:26Z

VÖLKL Peter:

= Datenmodellierung =

Bei der Datenmodellierung geht es um die zweckmäßige und effiziente Strukturierung von Daten in Informationssystemen. Die Modelle behandeln unterschiedliche Arten von Speicheranwendungen. Beispielsweise ist das ER-Modell im Bereich der Datenbanksysteme beheimatet, XML und JSON dahingegen im Bereich der Nahtstellen und Datenstrukturen innerhalb und zwischen einzelnen Systemen auf Dateiebene.


== Entity-Relationship Modell (ER-Modell) ==

Das Entity-Relationship Modell (ER-Modell) wurde bereits im vorherigen Semester, im Studienheft „Datenbanksysteme“ (Schikuta, E.), genau erläutert. Nachfolgend werden nun die wesentlichen Punkte dieses Skriptums nochmals auszugsweise wiederholt.

Das '''Entity-Relationship-Modell (ER-Modell)''' ist eines der ältesten (Chen, 1976) und am weitesten verbreiteten Modelle zum Entwurf von Datenbankmodellen und wird auch gerne im Bereich der allgemeinen Software Entwicklung eingesetzt. Durch seine besonders einfachen Darstellungsmöglichkeiten ist es sehr gut für die Kommunikation mit den Endbenutzern geeignet.

Die Grundidee des Entity-Relationship-Modells (Objekt-Beziehungs-Modell) besteht darin, die Welt als Sammlung von '''Entitäten (Entity''' oder '''Objekttypen''') und '''Beziehungen''' ('''Relationship''') zwischen diesen Objekttypen zu sehen.


=== Modellierungsobjekte des ER-Modells ===


==== Entitäten ====

Ein Objekt wird '''Entität-Instanz''' genannt. Entität-Instanzen sind dabei einzelne Exemplare von Dingen oder Begriffen. Dies können beispielsweise sein:

* Personen: der Kunde, Lieferant, Mitarbeiter etc.
* Gegenstände: Handelsware, Rohstoff, Maschine etc.
* Abstrakte Begriffe: Konto, Buchung, Bestellung etc.
Entität-Instanzen mit gleichen Eigenschaften lassen sich zu Entitäten (Objekttypen) zusammenfassen, z.B. Kunden, Bestellungen etc. Die Eigenschaften einer Entität-Instanz werden durch '''Attribute''' beschrieben, z.B. Name, Baujahr, Preis, Bestellnummer.

Hinweis: Im ER – Modell bezeichnet der Begriff Entität immer eine Klasse (Typ) von Instanzen, nicht eine Instanz!

Zwischen zwei, aber auch mehr, Entitäten können Beziehungen bestehen, z.B. „Kunde bestellt Maschine“. Die Beziehung wird dabei durch die Rolle der an ihr beteiligten Entitäten beschrieben. Die Beziehungen können zwischen Entitäten gleichen Typs oder zwischen Entitäten verschiedenen Typs bestehen.

Die wichtigsten Symbole in der grafischen Notation des ER-Modells werden in Abbildung 2 dargestellt.

[[Datei:Wiba mt233 201607 a.007.png|300px|none|thumb|Grafische Notation im ER-Modell]]

Attribute können auch Beziehungen zugeordnet werden (siehe Abbildung 3). Hier ist bei der Modellierung zu entscheiden, ob dieses Beziehungsattribut nicht einer der beiden Entitäten zugeordnet werden kann oder soll.

[[Datei:Wiba mt233 201607 a.008.png|300px|none|thumb|Beispiel Beziehungsattribut]]

Eine minimale Menge von Attributen, deren Werte die zugeordnete Entität-Instanz eindeutig innerhalb aller Instanzen seines Objekttyps identifiziert, nennt man '''Schlüssel'''. Oft gibt es Attribute, die künstlich als Schlüssel eingebaut werden, z.B. Personalnummer, Vorlesungsnummer, …

Schlüsselattribute werden durch Unterstreichen (manchmal auch durch doppelt gezeichnete Ovale) gekennzeichnet (siehe Abbildung 4).

[[Datei:Wiba mt233 201607 a.009.png|300px|none|thumb|Beispiel Schlüsselattribut]]

==== Beziehungen ====

Beziehungen repräsentieren eigentlich Aggregate von zwei oder mehreren an der Beziehung teilnehmenden Entitäten. Die Anzahl der aggregierten Entitäten heißt '''Grad''' der Beziehung (unäre, binäre, n-äre Beziehung). Entitäten haben in einer Beziehung eine minimale und eine maximale '''Kardinalität''' bzw. Komplexität.

Die Beziehungen können vom Typ '''1:1''', '''1:n''', '''n:1''', oder '''m:n''' sein. Entsprechende Beispiele für die einzelnen Kardinalitäten findet man in Abbildung 5:

[[Datei:Wiba mt233 201607 a.010.png|300px|none|thumb|Beispiele Kardinalitäten]]

Diese Kardinalitäten können folgendermaßen interpretiert werden:

* 1:1 – ein Ehemann hat genau eine Ehefrau (normalerweise), und umgekehrt.
* 1:n – ein Kunde besitzt mehrere Konten, aber jedes Konto gehört genau einem Kunden.
* m:n – Ein Kunde kann mehrere Artikel kaufen und jeder Artikel kann von mehreren Kunden gekauft werden.
Bei der Angabe der Kardinalitäten ist es auch möglich Intervalle durch Angabe der minimalen und maximalen Kardinalität zu definieren. In Abbildung 6 ist sowohl eine n:m und eine n:1 Beziehung definiert, wobei das Maximum der Kardinalität die Beziehungsmultiplizität definiert.

[[Datei:Wiba mt233 201607 a.011.png|300px|none|thumb|Beispiel Kardinalitäten mit Intervallen]]

Im obigen Beispiel sieht man, dass es ohne weiters möglich ist, auch mehr als eine Beziehung zwischen Entitäten zu definieren. Im spezifischen Fall sind dies zwei binäre Beziehungen.

In manchen Fällen ist es notwendig auch n-äre Beziehungen zu modellieren. In der Abbildung 7 ist eine ternäre Beziehung dargestellt und die entsprechende Interpretation der Kardinalitäten angegeben.

[[Datei:Wiba mt233 201607 a.012.png|300px|none|thumb|Beispiel ternäre Beziehung]]

Es ist aber empfohlen n-äre Beziehungen nur in wirklich begründeten Fällen zu modellieren.

Unter einer '''schwachen Entität''' versteht man eine Entität, die kein Schlüsselattribut besitzt (d.h. wo die Instanzen nicht eindeutig unterschieden werden können). Solche Instanzen können nur über eine Beziehung zu einer anderen Entität eindeutig identifiziert werden. Schwache Entitäten werden grafisch durch einen doppelten Rand gekennzeichnet.

Im nachfolgenden Beispiel Abbildung 8 ergibt sich die schwache Entität dadurch, dass ein Hörsaal durch seine Nummer, Größe und seinen Typ nicht eindeutig auf einem Universitätscampus identifiziert werden kann, auf dem es eine Vielzahl von Gebäuden mit jeweils mehreren Hörsälen gibt, die in jedem Gebäude von der Nummer 1 an gezählt werden. Das bedeutet es gibt in jedem Gebäude einen Hörsaal mit der Nummer 1. Erst mit der Angabe des Gebäudes (identifying owner) kann dadurch jeder Hörsaal eindeutig identifiziert werden.

[[Datei:Wiba mt233 201607 a.013.png|300px|none|thumb|Beispiel Schwache Entität]]


=== Beispiel eines ER-Modells ===

Im abschließenden (vereinfachten) Beispiel dieser Lektion wollen wir, basierend auf einem gegebenen Ausschnitt der Realität einer „Bank“, eine Modellierung mit Hilfe des ER-Modells durchführen.

Ausgangsposition für unseren Ansatz bildet eine Anforderungsbeschreibung in natürlichsprachiger Form. Es wird angenommen, dass sich diese Beschreibung aus den Interviews mit den Benutzern bzw. Auftragsgebern ergeben hat. Eine in der Praxis simple, aber übliche Vorgangsweise, um Entitätskandidaten zu erhalten, ist alle Hauptworte im Text zu identifizieren und als ersten Ansatz für Entitäten zu verwenden. Dieses Verfahren wird in der CRC-Methode vertieft (siehe die Aufgaben zu dieser Lektion).

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Eine mögliche Modellierung dieser Anforderungsbeschreibung als ER-Modell findet man in Abbildung 9.

[[Datei:Wiba mt233 201607 a.014.png|300px|none|thumb|Beispiel „Bank“: ER-Modell]]

== Extensible Markup Language (XML) ==

Die Extensible Markup Language (XML) ist ein Standard für den Aufbau von Dateidokumenten. Sie wurde vom World Wide Web Consortium (W3C) entwickelt. Es handelt sich dabei um eine sehr flexible Modellierungsform für Textformate welche wiederum von der Standard Generalized Markup Language (SGML, ISO8879) abgeleitet wurde. (World Wide Web Consortium (W3C), 2014)

''XML ist eine Markup-Sprache, und es ist nur eine Markup-Sprache. […] Der XML-Hype ist so extrem geworden, dass viele Leute glauben, XML könne sogar Kaffee kochen der den Familienhund waschen.'' (Harold & Means, 2005, S. 5)

Die Designziele von XML selbst sind (World Wide Web Consortium (W3C), 2008):

* XML soll direkt und unkompliziert über das Internet nutzbar sein,
* XML soll eine große Anzahl unterschiedlicher Applikationen unterstützen,
* XML soll mit SGML kompatibel sein,
* eine Programmierung von Anwendungen, welche XML Dokumente verarbeiten können, soll einfach möglich sein,
* die Anzahl von optionalen Features soll in XML so gering wie möglich gehalten werden und optimal Null sein,
* XML Dokumente sollen menschenlesbar und leicht verständlich sein,
* die Modellierung von XML Dokumenten soll schnell erstellt werden können,
* das Design von XML Dokumenten soll formal und präzise sein,
* die Erstellung von XML Dokumenten soll einfach sein und
* die Kürze und Kompaktheit der XML Elemente ist von geringer Bedeutung.
Der Hauptvorteil bei XML liegt, im Gegensatz zu eigen entwickelten Dateistrukturmodellen, in der schnellen und einheitlichen Verarbeitbarkeit für den Entwickler. In nahezu jeder gängigen Programmiersprache existieren bereits fertige Parser, welche die Generierung und Verarbeitung der Datenstrukturen, ohne größeren Programmieraufwand, ermöglichen.


=== Aufbau eines XML Dokuments ===

Jedes XML Dokument beinhaltet '''ein einziges''' XML '''Wurzel-Element''', welches selbst jeweils wiederum beliebig viele weitere '''Elemente''' beinhalten kann. Alle Elemente dürfen wiederum beliebig viele weitere Elemente enthalten. Zusätzlich kann das Dokument '''XML Deklarationen''', auch bezeichnet als Processing Instructions (PI), und beliebig viele '''Kommentare''' enthalten. Die Zeichenkodierung der Dokumente darf '''alle Unicodezeichen''' enthalten, wobei jedes XML verarbeitende Programm zumindest die Kodierungen UTF-8 und UTF-16 akzeptieren muss. Alle Bezeichnungen eines Dokuments, seien es die von Elementen oder Attributen, sind '''Case Sensitive'''. Da es sich dabei um ein einfaches Textdokument handelt, kann es auch von allen Texteditoren und Internetbrowsern, ohne weitere Hilfsmittel und Plugins, angezeigt werden. (World Wide Web Consortium (W3C), 2008)

Vom Aufbau sehen sich XML und HTML (Hypertext Markup Language) Dokumente sehr ähnlich. Sie unterscheiden sich jedoch darin, dass die Art und teilweise die Anzahl der Elemente in HTML fest vorgegeben, in XML jedoch alle Elemente frei modellierbar, sind. Das Metamodell der zu verwendeten Elemente eines XML Dokuments kann somit vom Modellierer selbst festgelegt werden. HTML dient der Modellierung von Webseitendokumenten und hat fest vorgegebene Strukturen und Elemente um eine einheitliche grafische Verarbeitung durch die Internetbrowser zu ermöglichen. Das Design der Elemente selbst ist jedoch in beiden Fällen sehr restriktiv vorgegeben.

Die '''XML Deklaration''' gibt die eingesetzte XML Version, und optional das Encoding, an. Dadurch wird den verarbeitenden Programmen die Verarbeitung erleichtert. Gerade die Angabe des Encodings kann viele Verarbeitungsprobleme im Vorfeld abfangen, da der Parser damit die eingesetzten Zeichen kennt und sie korrekt interpretieren kann. Nachfolgend ist in Abbildung 10 ein minimales XML Dokument dargestellt, welches nur eine XML Deklaration und ein einzelnes XML Element, namens „mein_wurzel_element“, ohne weitere Attribute und ohne Wert, beinhaltet.

<pre><code><?xml version="1.0" encoding="UTF-8"?>

<mein_wurzel_element /></code></pre>

Abbildung 10 – Minimales XML Dokument

Da einige Zeichen in der XML Syntax eine spezielle Bedeutung haben, müssen sie im Text nötigenfalls in einer anderen Form geschrieben werden, um sie innerhalb von XML Elementen nutzen zu können:

* < wird zu ''&lt;''
* > wird zu ''&gt;''
* " wird zu ''&quot;''
* ' wird zu ''&apos;''
* & wird zu ''&amp;''


=== XML-Elemente ===

Die einzelnen XML Elemente sind alle nach demselben Schema aufgebaut. Sie haben eine '''Elementbezeichnung''' und können '''beliebig viele Attribute''' enthalten. Weiter können sie selbst einen '''Inhalt''' haben, welcher wiederum aus Elementen bestehen kann.

Ein Element besteht aus einem oder zwei sogenannten Tags. Ein '''Tag''' wird durch '''spitze Klammern (<,>)''' an seinem Beginn und Ende ausgezeichnet. Ob ein Element aus '''einem oder zwei Tags''' besteht, hängt davon ab, '''ob es selbst einen eigenen Inhalt''' besitzt, oder nicht. Der Inhalt kann aus Text oder weiteren Elementen bestehen. Am '''Beginn''' jedes Tags steht der '''Name des Elements'''.

Hat ein Element '''keinen''' '''Inhaltsbereich''', besteht es aus nur '''einen einzigen Tag.''' Dessen abschließenden spitzen Klammer wird ein Schrägstrich vorangestellt ''(<elementname />'') um die Abwesenheit eines Inhaltbereiches zu signalisieren.

Sollte das Element dahingegen '''einen Inhaltsbereich''' haben, wird der erste Tag durch eine einfache spitze Klammer geschossen ''(<elementname>''). Danach folgt dann der eigentliche Inhalt des Elements. Nach dem Inhalt, und damit am Ende des Elements, steht in diesem Fall ein zweiter Tag, welcher wiederum einen Schrägstrich nach der einleitenden spitzen Klammer hat (''</elementname>).''

Die '''Attribute''' eines Elements befinden sich immer innerhalb des ersten Tags. In einem Element darf ein gewählter Attributname nur einmal vorkommen. Somit ist es beispielsweise nicht möglich einem Element „person“ mehrmals das Attribut „name“ zu zuzuweisen. die Reihenfolge der einzelnen Attribute eines Elements ist dahingegen nicht relevant und kann beliebig gewählt werden. Ein möglicher Aufbau eines Elements „person“ mit den Attributen „vorname“, „nachname“ und „ausweisnummer“ ist in Abbildung 11 dargestellt.

<person vorname="Peter" nachname="Völkl" ausweisnummer="1234567"/>

Abbildung 11 – XML Element „person“

In Abbildung 12 sind weiter:

* ein Element ''„element_1“'' ohne Inhalt und ohne Attribute,
* ein Element ''„element_2“'' ohne Inhalt und mit Attributen,
* ein Element ''„element_3“'' mit Inhalt und ohne Attributen,
* ein Element ''„element_4“'' mit Inhalt und mit Attribut und
* ein Element ''„element_5“'' mit Attributen und weiteren Elementen im Inhalt exemplarisch dargestellt.

<pre><code>
<element_1 />

<element_2 attribut_1="Attributwert 1" attribut_2="Attributwert 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein Inhaltstext</element_3>

<element_4 attribut_1="Wert 1">Noch ein Inhaltstext</element_4>

<element_5 attribut_1="Attributwert 1">

<element_1 />

<element_2 attribut1="Test 1" 
attribut_2="Test 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein anderer Inhaltstext</element_3>

</element_5>
</code></pre>
Abbildung 12 – XML Elemente mit unterschiedlichen Tags


=== Kommentare ===

Zusätzlich zu den Deklarationen und Elementen, kann ein XML Dokument auch Kommentare enthalten. Diese können sich an jeder Position im Dokument befinden an der auch ein Element stehen dürfte, also überall außer im Attributbereich eines Tags. Sie werden bei der Interpretation des Dokuments ignoriert. Kommentare dienen primär der Lesbarkeit durch Menschen. Mit ihnen können einzelne Teile des Dokuments mit Erklärungen versehen werden, die dem Anwender bei nicht automatisierter Betrachtung helfen können, den Inhalt zu verstehen.

Ein Kommentar ist hinlänglich seines Inhaltes kaum beschränkt. Es darf einzig keine zwei direkt zusammenhängenden Minuszeichen (--) enthalten. Sollte sich innerhalb eines Kommentars ein XML Element befinden, wird es nicht als Element, sondern als Kommentartext interpretiert. Damit können auch einzelne Teile eines Dokuments „auskommentiert“ werden, um sie bei der Interpretation zu ignorieren, ohne sie aus dem Dokument löschen zu müssen. Dies ist gerade bei der Entwicklung von Schnittstellen hilfreich, da die Musterdateien somit abgeändert werden können, ohne einzelne Inhalte zu löschen.

Kommentare werden durch die Zeichenfolge '''' wieder beendet. Alle Zeichen, welche sich zwischen diesen beiden Teilen befinden gelten damit als Kommentartext und nicht als XML Element.


=== Document Type Definitions (DTD) ===

Die Document Type Definition (DTD) wird verwendet um die '''Struktur eines XML Dokuments''' zu definieren. Ohne eine DTD darf es auf beliebigen Elementen in beliebiger Reihenfolge mit beliebigem Inhalt und Attributen aufgebaut sein. Die DTD schränkt nun genau diese Freiheit wieder ein und definiert damit das '''Metamodell des XML Dokuments'''.

Um, in einem XML Dokument, eine zugehörige DTD anzugeben. Wird eine eigene Deklaration verwendet, welche am Beginn des Dokumentes nach der XML Deklaration stehen muss. Sie wird mit ''<!DOCTYPE'' eingeleitet und wiederum mit einer einfachen Spitzen Klammer abgeschlossen. Es kann auch mehrere dieser Deklarationen in einem Dokument geben.

Innerhalb der DTD Deklaration des XML Dokuments wird zuerst der Name der Dokumentenart angegeben und danach einer der Identifier SYSTEM oder PUBLIC, sowie ihre zugehörigen Parameter.

Der Identifier '''''SYSTEM''''' gibt an, dass es sich dabei um eine eigene Definition handelt. Der zugehörige Parameter ist hierbei der Pfad zu der Datei, welche die angegebene DTD enthält.

Der Identifier '''''PUBLIC''''' weist auf eine allgemein standardisierte DTD hin, welche dem XML Parser bekannt sein sollte. Hier werden zwei Parameter benötigt. Der Erste gibt an, um welchen Public Identifier es sich dabei handelt und der zweite Parameter verweist optional auf eine alternative DTD Datei, welche verwendet wird falls der genannte Identifier dem Parser nicht bekannt ist.

In Abbildung 13 ist die Deklaration einer eigenen DTD „schema.dtd“ angegeben und in Abbildung 14 die Deklaration eines XML Dokumentes als, dem System bekannten, Dokumententyp HTML.

<!DOCTYPE mein_schema SYSTEM "schema.dtd">

Abbildung 13 – XML DOCTYPE für eigene DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 //EN" "http://www.w3.org/TR/html4/strict.dtd">

Abbildung 14 – XML DOCTYPE für HTML

In der DTD Datei können nun die einzelnen Elemente und die Struktur des XML Dokuments definiert werden:

* '''Elemente''' werden durch <!ELEMENT …> und
* '''Attribute''' über <!ATTLIST …> definiert.
'''Element Definition <!ELEMENT …>'''

Bei der Definition eines Elements wird sowohl die '''Bezeichnung des Elements''', als auch sein '''möglicher Inhalt''' definiert. Dabei wird als erstes der Elementname und dahinter der Inhalt in Klammer angegeben.

Der '''Inhalt''' kann entweder:

* leer (Schlüsselwort '''''EMPTY'''''),
* beliebig (Schlüsselwort '''''ANY'''''),
* reiner Text (Schlüsselwort '''''#PCDATA''''') oder
* weitere Elemente (Angabe des gewünschten '''Elementnamen''') sein.
Dabei sind auch die Angaben unterschiedlicher Inhalte und Typen kombinierbar.

Sollen mehrere Inhalte, wie beispielsweise unterschiedliche Elemente, beinhaltet sein, werden diese innerhalb der Klammer durch '''Beistriche''' ( ''',''' ) oder '''Pipes''' ( '''|''' ) getrennt.

Dabei gibt ein '''Beistrich''' das Vorhandensein beider Elemente in '''genau dieser Reihenfolge''' und eine '''Pipe''' das Vorhandensein '''nur''' '''eines der beiden Elemente''' an.

Weiter sind auch '''Verschachtelungen''' dieser beiden Operatoren durch Setzen von '''Klammern''' zulässig.

Zusätzlich gibt es noch die Möglichkeit hinter jedem Element, oder Klammerausdruck, anzugeben, ob das Element:

* '''optional''' ist (durch ein Fragezeichen: '''?'''),
* beliebig '''oft aber''' '''mindestens einmal''' vorkommt (durch ein Pluszeichen: '''+''') oder
* '''beliebig oft''' '''und optional''' vorkommen kann (durch einen Stern: '''*''').
Wird hinter einem Eintrag keine Angabe über die Häufigkeit gemacht, muss er genau einmal vorkommen.

Im nachfolgenden Beispiel, in Abbildung 15, sind folgende Elemente definiert:

* ''element_1'' hat keinen Inhalt,
* ''element_2'' hat einen Textinhalt,
* ''element_3'' beinhaltet ''element_1'' und ''element_2'',
* ''element_4'' beinhaltet ''element_1'' und (entweder ''element_2'' oder ''element_3''),
* ''element_5'' beinhaltet 0-n Mal ''element_1'' und 1-n Mal ''element_4'',
* ''element_6'' beinhaltet optional ''element_4'',
* ''element_7'' beinhaltet ''element_1'' und optional ''element_7'' und
* ''element_8'' beinhaltet beliebig viele ''element_1'', ''element_2'' und ''element_3'' in beliebiger Reihenfolge.
Bei der Definition von verschachtelten Elementen sind auch '''Rekursionen zulässig''', wie das gerade genannte Beispiel mit element_7 zeigt. Hier muss jedoch darauf geachtet werden, die Rekursion '''als optional zu deklarieren''' (Angabe von ?, * oder |), da die Rekursion sonst verpflichtend endlos und damit nie erfüllbar wäre.

<pre><code>
<!ELEMENT element_1 EMPTY>

<!ELEMENT element_2 #PCDATA>

<!ELEMENT element_3 (element_1, element_2)>

<!ELEMENT element_4 (element_1, (element_2 | element_3))>

<!ELEMENT element_5 (element_1*, element_4+)>

<!ELEMENT element_6 (element_4?)>

<!ELEMENT element_7 (element_1, element_7?)>

<!ELEMENT element_8 (element_1|element_2|element_3)*>
</code></pre>
Abbildung 15 – DTD Elemente

'''Attribut Definition <!ATTLIST …>'''

Um ein definiertes Element '''mit Attributen auszustatten''' wird mittels ''<!ATTLIST'' eine Attributliste definiert. Dazu wird zuerst der '''Name''' des Elements angegeben, für das die Attributliste gilt sowie danach der '''Attributname''' und sein '''Typ,''' sowie optional eine Definition von möglichen Werten und ob der Parameter verpflichtend vorkommen muss. Dabei können entweder '''mehrere Attribute in einer Definition''' '''oder jedes Attribut einzeln''' in einer '''eigenen Definition''' angegeben werden.

Mögliche Datentypen für Attribute sind:

* '''''CDATA''''' für beliebige Zeichenketten,
* '''''ID''''' für einen eindeutigen Wert unter den Elementen desselben Typs innerhalb des XML Dokuments,
* '''''IDREF''''' für eine Referenz auf ein anderes Element desselben Typs innerhalb des Dokuments mittels Wert des ID Attributs,
* '''''ENTITY''''' für eine Referenz auf ein externes Element,
* '''''ENTITYS''''' für eine Liste von ''ENTITY‘s'',
* '''''NMTOKEN''''' für einen Namen (eine Bezeichnung) des Elements innerhalb des XML Dokuments,
* '''''NMTOKENS''''' für eine Liste von ''NMTOKEN’s'' oder
* eine fest definierte '''Menge möglicher Eingabewerte''', getrennt durch Pipes in der Form ''(wert1|wert2|wert2).''
Zusätzlich kann hinter der Angabe des Datentyps noch:

* '''#REQUIRED''', für verpflichtend anzugebende Attribute,
* '''#IMPLIED''', für optionale Attribute,
* oder ein '''automatischer Standardwert''' in Anführungszeichen,
angegeben werden.

Eine Sonderform der Angabe des Standardwertes ist der Parameter '''#FIXED''', gefolgt von einem Standardwert in Anführungszeichen. Dabei handelt es sich um einen nicht veränderbaren Standardwert bzw. einen statischen Attributwert.

Im nachfolgenden Beispiel, in Abbildung 16, wird eine DTD für ein Element ''element_1'' mit den Attributen ''e1_id'', welches eine eindeutige ID innerhalb des Dokuments enthält, ''e1_name'', welches eine eindeutige Bezeichnung des Element enthält, ''e1_kommentar'', welches einen Kommentartext enthalten soll und ''e1_wochentag'', welches ein Wochentagkürzel enthält.
<pre><code>
<!ELEMENT element_1 EMPTY>

<!ATTLIST element_1 e1_id ID>

<!ATTLIST element_1 e1_name ENTITY>

<!ATTLIST element_1 e1_kommentar CDATA>

<!ATTLIST element_1 e1_wochentag (MO|DI|MI|DO|FR|SA|SO)>
</code></pre>
Abbildung 16 – DTD Attribute


=== Beispiel eines XML Modells ===

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Die Anforderungsbeschreibung gleicht der des Beispiels eines ER Modells in Punkt 2.1.2. In diesem Fall soll jedoch kein Datenbankmodell, sondern ein Modell für ein Dateibasiertes XML Dokument für den Datenaustausch erstellt werden. Eine mögliche Modellierung dieser Anforderungsbeschreibung als DTD findet sich in Abbildung 17 und ein mögliches darauf basierendes XML Dokument in Abbildung 18. Dabei wurde aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf.

<!ELEMENT filialliste (filiale*)>

<!ELEMENT filiale (kredit*, konto*)>

<!ATTLIST filiale filialname ID>

<!ATTLIST filiale stadt CDATA>

<!ATTLIST filiale vermoegen CDATA>

<!ELEMENT kredit (kunde)>

<!ATTLIST kredit nummer ID>

<!ATTLIST kredit betrag CDATA>

<!ELEMENT konto (kunde)>

<!ATTLIST konto nummer ID>

<!ATTLIST konto kontostand CDATA>

<!ELEMENT kunde EMPTY>

<!ATTLIST kunde name ID>

<!ATTLIST kunde strasse CDATA>

<!ATTLIST kunde stadt CDATA>

Abbildung 17 – Beispiel „Bank“: XML-Modell, DTD Datei

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE bank SYSTEM "bank.dtd">

<filialliste>

<filiale filialname="Meine Bank" stadt="Wien" vermoegen="5 mrd eur">

<kredit nummer="100" betrag="200000 eur">

<kunde name="Max Muster" strasse="Musterplatz 1" stadt="Wien">

</kredit>

<kredit nummer="101" betrag="10000 eur">

<kunde name="Maria Muster" strasse="Mustergasse 3" stadt="Wien">

</kredit>

</filiale>

<filiale filialname="Deine Bank" stadt="Wien" vermoegen="1 mrd eur">

<konto nummer="200" kontostand="3000 eur">

<kunde name="Hans Meier" strasse="Mustergasse 1" stadt="Graz">

</konto>

</filiale>

<filiale filialname="Seine Bank" stadt="Wien" vermoegen="2 mrd eur">

</filiale>

</filialliste>

Abbildung 18 – Beispiel „Bank“: XML-Modell, XML Datei


== JavaScript Object Notation (JSON) ==

Die JavaScript Object Notation (JSON) wurde ursprünglich zur Speicherung und Übertragung von Datenstrukturen in JavaScript entwickelt. Es handelt sich dabei um ein reines Textformat, welches, ähnlich wie in XML, durch die Vorgabe einer klaren Struktur, eine einheitliche Abbildung von Daten ermöglicht. JSON ist in der RFC 4627 definiert und ist wiederum Teil des ECMAScript Programming Standards, welcher wiederum die wesentlichen Objekt Literale von JavaScrip definiert. (RFC Network Working Group, 2006)

Genau wie in XML, zeichnet sich JSON durch seine Menschenlesbarkeit und die Vielzahl verfügbarer Implementierungen in allen gängigen Programmiersprachen aus. JSON ist somit nicht auf JavaScript beschränkt, hat dort jedoch seinen eigentlichen Ursprung. Damit ist auch hier eine schnelle und einfache Implementierung von Nahtstellen zwischen unterschiedlichen Anwendungen möglich. Da die Syntax in JSON wesentlich kompakter geschrieben wird, als in XML, wird es häufig für die Datenübertragungen in Webservices, wie beispielsweise Services mit REST Schnittstellen (Fielding, 2000), eingesetzt.


=== Aufbau eines JSON Dokuments ===

Die '''Elemente''' und '''Attribute''' sind in JSON werden als '''Objekte''' und '''Key-Values''' bezeichnet. Jede Struktur ist über Objekte Abgebildet, welche selbst wiederum beliebig Objekte enthalten können. Ähnlich wie in XML muss in der obersten Hierarchiestufe ein einzelnes Objekt stehen. Die gemeinsame Verschachtelung von Objekten geschieht über '''Arrays''' Struktur.

Die möglichen '''Datentypen''' der einzelnen Objekte sind:

* String,
* Number,
* Boolean und
* null.
Sie müssen jedoch nicht eigens deklariert werden, sondern ergeben sich durch ihre Schreibweise innerhalb der Datei. ''Strings'' werden mit umschließenden Anführungszeichen geschrieben, ''Numbers'' in Zahlenschreibweise ohne Anführungszeichen und ''Booleans'' direkt als Werte ''true'' und ''false''.

Objekte werden durch geschwungene Klammern ( '''{''' , '''}''' ) deklariert. Sie können beliebig viele Key-Values enthalten. Nach dem Namen einer Key-Value steht immer ein Doppelpunkt, gefolgt von ihrem enthaltenen Wert, welcher wiederum ein eigenes Objekt sein kann. Die einzelnen Key-Values werden durch Beistriche getrennt. Ein Wert kann auch ein Array aus Werten sein. Es wird durch eckige Klammern ( '''[''' , ''']''' ) deklariert und enthält beliebig viele, durch Beistriche getrennte, Werte.

Im Gegensatz zu XML gibt es in JSON Dateien '''keine Kommentare'''.

Der Text der JSON Dokumente soll laut Spezifikation (RFC Network Working Group, 2006) Unicode kodiert sein, wobei standardmäßig UTF-8 verwendet wird. Der verwendete Zeichensatz des Dokuments wird vom Parser über seine ersten beiden Zeichen erkannt. Es werden dazu die, in ihrer binären Form, enthaltenen Nullen betrachtet:

* 00 00 00 xx ergibt UTF-32BE <ref>Die Zusätze ''BE'' und ''LE'' steht für ''Big Endian'' und ''Little Endian'' und beziehen sich auf die Reihenfolge in der die einzelnen Bits des Zeichens gespeichert werden. Somit steht das erste Bit des Zeichens entweder links (LE) oder rechts (BE) in der binären Abbildung.</ref> ,
* 00 xx 00 xx ergibt UTF-16BE,
* xx 00 00 00 ergibt UTF-32LE,
* xx 00 xx 00 ergibt UTF-16LE und
* xx xx xx xx ergibt UTF-8.
In Abbildung 19 ist ein JSON Objekt für eine Person definiert, welches Key-Values für einen Vornamen, einen Nachnamen und eine Ausweisnummer enthält. Weiter hat die Person ein Array mit Objekten, welche je einen Schlüssel der Person mit der jeweiligen Raumnummer abbilden.

{"vorname" : "Peter",

"nachname" : "Völkl",

"ausweisnummer" : 1234567,

"schluessel" : [{"raumnummer" : 22},{"raumnummer" : 33}]

}

Abbildung 19 – Beispiel JSON Objekt


=== JSON Schema ===

Im Gegensatz zu XML gibt es bei JSON Daten keine standardisierte Möglichkeit eine eigene, formale, Definition zu erstellen, gegen welche die Struktur automatisiert geprüft werden kann. Eine entsprechende Standardisierung, das JSON Schema, befindet sich derzeit in Ausarbeitung und liegt bereits im Entwurfsstadium vor. Es kann jedoch aktuell nicht davon ausgegangen werden, dass diese unfertige Standardisierung mit jedem Parser eingesetzt werden kann. (Galiegue, 2013)


=== Beispiel eines JSON Modells ===

Anforderungsbeschreibung:

''„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“''

Die Anforderungsbeschreibung gleicht der des Beispiels des ER Modells in Punkt 2.1.2 und des XML Modells in Punkt 2.2.5. Die JSON Struktur könnte beispielsweise dem Austausch von Filialdaten über ein Webservice dienen. Eine mögliche Modellierung dieser Anforderungsbeschreibung findet sich nachfolgend in Abbildung 17. Dabei wurde ebenfalls wieder aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf. Die, in dem Beispiel enthaltenen, Einrückungen dienen der besseren Lesbarkeit und nicht erforderlich.

{"filialliste" : [ {"filialname“ : "Meine Bank",

"stadt" : "Wien",

"vermoegen" : "5 mrd eur",

"kredite" : [ {"nummer" : "100",

"betrag" : "20000 eur"},

"kunde" : {"name" : "Max Muster",

"strasse" : "Musterplatz 1",

"stadt" : "Wien"}

},

{"nummer" : "101",

"betrag" : "10000 eur"},

"kunde" : {"name" : "Maria Muster",

"strasse" : "Mustergasse 3",

"stadt" : "Wien"}

}

],

"konten" : []

},

{"filialname“ : "Deine Bank",

"stadt" : "Wien",

"vermoegen" : "1 mrd eur",

"kredite" : [],

"konten" : [ {"nummer" : "200",

"betrag" : "3000 eur"},

"kunde" : {"name" : "Hans Meier",

"strasse" : "Mustergasse 1",

"stadt" : "Graz"}

}

]

},

Abbildung 20 – Beispiel „Bank“: JSON-Modell, Teil 1/2

{"filialname“ : "Seine Bank",

"stadt" : "Wien",

"vermoegen" : "2 mrd eur",

"kredite" : [],

"konten" : []

} ]

}

Abbildung 21 – Beispiel „Bank“: JSON-Modell, Teil 2/2

Grundlagen der Modellierung - Einleitung

2022-11-02T08:48:29Z

VÖLKL Peter:

= Einleitung =

Modellierung und Modellierungssprachen sind ein essentieller Bestandteil der meisten Themenfelder der Wirtschafsinformatik. Die Modellierung bildet dabei einen existierenden, erwarteten oder geplanten Sachverhalt in Form eines Modells ab. Dabei handelt es sich um eine Darstellung, welche der betroffenen Zielgruppe und Zielsetzung angepasst wurde. In den nachfolgenden Lektionen werden der Modellbegriff und die ordnungsgemäße Modellierung, sowie die Grundlagen einzelner, in der Wirtschafsinformatik besonders relevanter, Modellierungsformen erläutert.


== Der Modellbegriff ==

Bei einem Modell handelt es sich um eine vereinfachte Darstellung der Realität oder ihres Soll-Zustandes. Durch diese Abstraktion ist eine genauere Betrachtung oder Planung bestimmter Einzelaspekte möglich. Es betrachtet nur so viele Details wie nötig sind, um das zugrunde liegende Problem vollständig zu beschreiben. Der Begriff „Modell“ leitet sich aus dem lateinischen Wort „modulus“ ab und bezeichnete einen Maßstab im Bereich der Architektur. Laut dem deutschen Duden Fremdwörterbuch (2010), bedeutet Modell: ''Objekt, Gebilde, das die inneren Beziehungen und Funktionen von etwas abbildet bzw. [schematisch] veranschaulicht [und vereinfacht, idealisiert]''.

Für Wirtschaftsinformatiker und Wirtschaftsinformatikerinnen gehören Modelle und Modellierungstechniken zum unumgänglichen Handwerkszeug, insbesondere die Modelle, die in Informationssystemen abgebildet werden und jene, die wir in der Softwareentwicklung verwenden.

Modelle gibt es nicht nur in der Wirtschaftsinformatik, sondern auch in allen anderen Themenfeldern der Wissenschaft, Forschung und Entwicklung. So werden beispielsweise in der Wirtschaftsinformatik Datenmodelle verwendet und anatomische Modelle in der Medizin.

Die gängigen Modelle in der Wirtschaftsinformatik sind:

* '''Datenmodelle''',
* '''Prozess- und Ablaufmodelle''',
* '''Geschäftsprozessmodelle''' und
* '''objektorientierte Modelle'''.
Auf diese vier speziellen Modelle und ihre gängigsten Ausprägungen wird in den Lektionen [[Grundlagen der_Modellierung_-_Datenmodellierung|Datenmodellierung]] bis [[Grundlagen der_Modellierung_-_Objektorientierte_Modelle|Objektorientierte Modelle]] im Detail eingegangen.

Auch die Erstellung eines Test- oder Entwicklungssystems in der Software- und Systementwicklung ist ein (Soll-)Modell des Echtsystems. Meist hat es jedoch einen sehr geringen Abstrahierungsgrad, da es dem Echtsystem so nahe wie möglich kommen soll.

Die richtige Wahl eines Modells ist essentiell für den Erfolg der gewünschten Betrachtung, da es durch eine zu starke oder falsche Abstraktion der Darstellung auch zu fehlerhaften Annahmen und Resultaten führen kann.

Jedes Modell lässt sich selbst wiederum in einem Metamodell beschreiben, welches die Modellierung selbst definiert. Ein Metamodell definiert somit die einzelnen Bausteine eines Modells und wie sie anzuwenden sind.

Die drei Hauptmerkmale des allgemeinen Modellbegriffs nach Herbert Stachowiak, dem Begründer der allgemeinen Modelltheorie, sind (Stachowiak, 1973, S. 131ff):

* '''Abbildungsmerkmal''': Modelle sind Abbildungen oder Repräsentationen natürlicher oder künstlicher Objekte, die selbst wiederum Modelle sein können. Es handelt sich dabei auch um die Zuordnung von Original-Attributen zu Modell-Attributen.
* '''Verkürzungsmerkmal''': Modelle bestehen, in der Regel, nicht aus allen, sondern nur aus den relevanten, Attributen des betrachteten Objektes. Um die korrekten Attribute für ein Modell auszuwählen ist sowohl das Wissen über alle möglichen Attribute des Originalobjektes als auch über die Attribute des Modells notwendig.
* '''Pragmatisches Merkmal''': Modelle sind nicht alleine einem Zweck, sondern auch einem bestimmten Anwenderkreis und Zeitraum zugeordnet. ''Eine pragmatisch vollständige Bestimmung des Modellbegriffs hat nicht nur die Frage zu berücksichtigen, wovon etwas Modell ist, sondern auch, für wen, wann und wozu bezüglich seiner je spezifischen Funktionen es Modell ist.''
Ein Beispiel für ein einfaches Modell und seine Attribute ist das eines Smartphones:

Je nach Abstrahierungsgrad ändern sich die mögliche Darstellung und die relevanten Attribute. Eine mögliche Aufstellung der Attribute und Abbildungen unterschiedlicher Abstrahierungsgrade ist in der Tabelle "Einfaches Modell eines Smartphones" dargestellt.

Tabelle – Einfaches Modell eines Smartphones

{| style="border-collapse: collapse;" border="1"
! width="24%" | Anwendungsfall:
! width="25%" | Technischer Aufbau eines konkreten Smartphones
! width="24%" | Abbildung eines konkreten Smartphones
! width="24%" | Piktogramm für Smartphone
|-
| Attribute:
|
* Gerätetyp
* Betriebssystem
* Hersteller
* Gehäuse
* Schrauben
* Kabel
* Platinen
* Speicher
* Anschlüsse
* …
|
* Gerätetyp
* Betriebssystem
* Hersteller
|
* Gerätetyp
|-
| Abbildung:
| [[Datei:Wiba mt233 201607 a.002.png|300px|thumb]]
| [[Datei:Wiba mt233 201607 a.003.png|300px|thumb]]  
| [[Datei:Wiba mt233 201607 a.004.png|300px|thumb]]
|}


== Modellbildung und Anforderungen an ein Modell ==

Bei der Modellbildung geht es um die ausreichende Abbildung eines realen Systems zur Beschreibung einer bestimmten Fragenstellung oder eines Zustandes. Dazu können entweder bestehende Modelle verwendet werden, oder ein eigenes, geeignetes, Metamodell geschaffen werden. Meist handelt es sich bei den gängigen Modellierungsaufgaben in der Wirtschaftsinformatik jedoch um Situationen, in denen bestehende Modellarten zur Anwendung kommen können und sollten. Die Verwendung eines weit verbreitenden, und im eigenen Fachbereich allgemein bekannten, Modells führt zu einem schnelleren Verständnis für alle beteiligten Personen.

Die Modellbildung lässt sich generell in vier Schritten beschreiben und durchführen (Oeser, 2012, S. 7):

* Schritt 1: Vereinfachung und Formulierung des Problems
* Schritt 2: Formalisierung und Quantifizierung des Problems
* Schritt 3: Verarbeitung des Datenmaterials und Erstellung des Modells
* Schritt 4: Interpretation und Rückschluss auf den ursprünglichen Sachverhalt
In Schritt 1 und 2 wird deutlich, dass die Anforderungen an ein Modell durch die Formulierung des zugrunde liegenden Problems definiert werden. Dieser Planungsschritt ist sehr wichtig, da die Modellauswahl für den weiteren Erfolg der Modellierung, und der damit verbundenen Behandlung der Problemstellung, essentiell ist.

Im 4. Schritt wird die Erfüllung der Zielsetzung des Modells nochmals überprüft und damit sichergestellt, dass es den Sachverhalt problemadäquat widerspiegelt.

Der Modellierer hat, durch seine Tätigkeit, eine '''hohe Verantwortung''' gegenüber der Zielsetzung des Modells. Durch eine zu hohe Abstrahierung kann es zu Fehlern in allen, anhand des Modells abgeleiteten, Folgerungen kommen. Diese Fehler wirken sich dann auf alle Bereiche aus, welche das Modell einsetzen. Wesentliche Fehler können in der Praxis auch sehr schlimme Folgen haben, wie das nachfolgende Beispiel beschreibt.

{| class="wikitable" style="border-collapse: collapse; width: 100%;" border="1"
|-
| style="width: 100%;" |
''22.09.2006: '''23 Menschen sterben in den Trümmern des Transrapid'''''

''Bei dem schweren Transrapid-Unglück im emsländischen Lathen sind 23 Menschen getötet worden. Das teilte die Polizei am Freitag abend mit. Zehn Menschen sollen die Katastrophe verletzt überlebt haben. Der Transrapid war am Vormittag auf einen Reinigungswagen geprallt.'' <ref>http://www.faz.net/aktuell/gesellschaft/magnetbahn-unfall-23-menschen-sterben-in-den-truemmern-des-transrapid-1357701.html, Aufruf der Seite am 03.11.2014</ref>

Der Transrapid nutzt eine neue Antriebsform und ein spezielles Leitsystem mit einigen Sicherheitsmaßnahmen. Der Zug wird durch Magnete in der Schiene bewegt. Weiter umgreift das Fahrwerk des Zuges die Schiene und haltet ihn in Position, was wiederum ein entgleisen verhindert. Zusätzlich ist jeder Zug mit einem Ortungssystem ausgestattet, welches seine Daten kontinuierlich mit dem Leitsystem der Streckenanlage abgleicht. Ein Zusammenstoß zweier Züge ist daher, zumindest dem Modell nach, durch die zentrale Steuerung des Streckenantriebs und die Positionsbestimmung nicht möglich. Das System galt daher als enorm sicher.

Leider gab es in diesem Modell eine Komponente, welche nicht beachtet wurde. Die Streckenfahrzeuge und Reinigungswagen sind mit herkömmlichen Dieselantrieben ausgestattet und verfügten über keine Ortungssysteme. Daher war es auch möglich, dass ein Reinigungsfahrzeug übersehen wurde und in dessen Folge 23 Menschen starben.
|}


== Die Grundsätze ordnungsmäßiger Modellierung (GoM) ==

Bei den Grundsätzen ordnungsgemäßer Modellierung (GoM) handelt es sich um semantische Empfehlungen zur bedarfsgerechten Informationsmodellierung. Damit wurde eine bewusste Einschränkung der Modellierungsfreiheit, zugunsten der Zielgerichtetheit der Modellierung selbst, eingeführt. Dies soll wiederum die Modellqualität erhöhen. Die GoM wurden von Becker, Rosemann und Schütte, in Anlehnung an den Grundsätzen ordnungsgemäßer Buchführung (GoB), entwickelt. (Becker, Rosemann, & Schütte, 1995, S. 437)

Die GoM definieren einen Ordnungsrahmen, bestehend aus sechs Grundsätzen, welchen wiederum ein Metamodell zugrunde liegt, in dem die einzelnen GoM Objekte, Attribute und ihre Beziehungen untereinander definiert werden (Becker, Rosemann, & Schütte, 1995, S. 437ff):

* Grundsatz der Richtigkeit,
* Grundsatz der Relevanz,
* Grundsatz der Wirtschaftlichkeit,
* Grundsatz der Klarheit,
* Grundsatz der Vergleichbarkeit und dem
* Grundsatz des systematischen Aufbaus.
Zusammengefasst sollen sie die Qualität von Informationsmodellen sicherstellen.


=== Grundsatz der Richtigkeit ===

Ein Modell kann sowohl semantisch, als auch syntaktisch richtig sein. Die syntaktische Richtigkeit bezieht sich dabei auf die korrekte Einhaltung der Vorgaben des Metamodells. Bei der semantischen Richtigkeit handelt es sich um die korrekte Abbildung des Modellierungsobjektes. Dies bedeutet nicht nur, dass das Modellierungsobjekt, dem Zweck entsprechend, vollständig abgebildet sein muss, sondern auch, dass es in sich keine Wiedersprüche aufweisen darf. Die Richtigkeit beinhaltet auch die eindeutige und korrekte Benennung von modellierten Objekten. Hierbei sollen Synonyme <ref>Synonyme sind unterschiedliche Benennungen für den gleichen Begriff. (z.B. kann für den Begriff Auto auch Kraftfahrzeug, Wagen oder Automobil verwendet werden).</ref> und Homonyme <ref>Ein Homonym ist die gleiche Benennung für zwei oder mehrere Begriffe (z.B. Golf ist ein Sport, eine Meeresbucht und ein Fahrzeug).</ref> vermeiden werden.


=== Grundsatz der Relevanz ===

Bei der Modellierung müssen die mit ihr bezweckten Ziele eingehalten werden. Die in dem Modell enthaltenen Elemente und Beziehungen sind relevant, wenn das Modellierungsziel bei ihrer Reduzierung nicht mehr erfüllt werden würde. Das Modell muss sich wieder in eine Beschreibung des beschriebenen Objektes zurückführen lassen, ohne für die Betrachtung relevante Aspekte zu verlieren.


=== Grundsatz der Wirtschaftlichkeit ===

Der Grundsatz der Wirtschaftlichkeit limitiert die Tiefe und den Umfang eines Modells hinlänglich der, durch die Modellierung selbst, entstehenden Kosten. Es handelt sich dabei um eine Abwägung zwischen dem, durch die Modellierung entstehenden, Nutzen durch eine bessere Abbildbarkeit des zugrunde liegenden Problems und der Verbesserung der Interaktion zwischen den Modellnutzern und den Kosten, die durch die Modellierung entstehen. Je umfangreicher und tiefergehend ein Modell gebildet wird, desto mehr Aufwand muss in seine Erstellung investiert werden.


=== Grundsatz der Klarheit ===

Die Anwendbarkeit des Grundsatzes der Klarheit ist, ähnlich der Relevanz, stark von den Anwendern des Modells abhängig. So ist es nötig, die Darstellung eines Modells der Zielgruppe anzupassen. Analog zur syntaktischen Richtigkeit ist auch eine klare Darstellung des Modells essentiell. Dabei geht es insbesondere um die verwendeten Symbole auf Ebene des Metamodells, als auch um die Anordnung der Symbole innerhalb des Modells selbst. Dieser Grundsatz kann beispielsweise bedeuten, dass ein sehr komplexes Modell in weitere Abstrahierungsebenen geteilt werden muss, um für den Anwender verständlich zu bleiben. Hierfür werden meist die Möglichkeiten von Substitutionen und Detailmodellen geschaffen.


=== Grundsatz der Vergleichbarkeit ===

Ähnlich dem Grundsatz der Richtigkeit wird beim Grundsatz der Vergleichbarkeit in eine syntaktische und eine semantische Vergleichbarkeit unterschiedenen. Die beiden Grundsätze der Richtigkeit und Vergleichbarkeit lehnen sich dabei auch aneinander an. Bei der syntaktischen Vergleichbarkeit handelt es sich um eine Vergleichbarkeit unterschiedlicher Modelle, mit derselben zugrunde liegenden Modellierungsanforderung. Dadurch soll auch eine Überführung von Modellen mit unterschiedlichen Metamodellen ermöglicht werden. Die semantische Vergleichbarkeit bezieht sich auf die inhaltliche Vergleichbarkeit. Damit soll der Vergleich unterschiedlicher Modelle zueinander ermöglicht werden.


=== Grundsatz des systematischen Aufbaus ===

Bei in unterschiedlichen Sichten aufgebauten Modellen müssen die Sichten untereinander konsistent sein. Das bedeutet, dass die Bezüge der unterschiedlichen Sichten zueinander vorhanden sein müssen. So muss beispielsweise ein Ablaufmodell, welches auf ein Datenmodell referenziert, auch sicherstellen, dass das entsprechende Datenmodell entsprechend modelliert ist und umgekehrt. Um hierbei alle relevanten Sichten zu integrieren, liegen solchen Modellen übergreifende Architekturkonzepte zu Grunde.


=== Erweiterung der GoM ===

Die eingeführten Grundsätze ordnungsgemäßer Modellierung wurden von ihrem Mitbegründer Reinhard Schütte in Form der „neuen Grundsätze ordnungsgemäßer Modellierung“ überarbeitet. Diese erweiterten Grundsätze weichen von den herkömmlichen in einigen Teilen ab. Das Ziel der Überarbeitung war, die theoretische Begründung und die praktische Prüfbarkeit der Grundsätze zu verbessern.

Diese „neuen Grundsätze ordnungsgemäßer Modellierung“ sind (Schütte, 1997):

* Grundsatz der Konstruktionsadäquanz,
* Grundsatz der Sprachadäquanz,
* Grundsatz des systematischen Aufbaus,
* Grundsatz der Klarheit und der
* Grundsatz der Vergleichbarkeit.
Die erweiterten Grundsätze selbst werden aus, als allgemeingültig erachteten, Zwecken abgeleitet, welche in Abbildung 1 dargestellt sind.

[[Datei:Wiba mt233 201607 a.006.png|300px|none|thumb|Zweckbezogene Ableitung der Grundsätze ordnungsmäßiger Modellierung (Schütte, 1997, S. 3)]]

Dabei unterscheiden sie sich primär in zwei Grundsätzen, von den ursprünglichen GoM:

* Grundsatz der Konstruktionsadäquanz und der
* Grundsatz der Sprachadäquanz.
Diese beiden sollten den Grundsatz der Richtigkeit und den Grundsatz der Relevanz ersetzen. Inhaltlich wurden jedoch auch bei den anderen Grundsätzen einige Ergänzungen durchgeführt.

Der '''Grundsatz der Konstruktionsadäquanz''' ist dabei als wichtigster Grundsatz definiert. Hierbei wird der Nutzen des Modells, für seinen jeweiligen Modellierungszweck, in den Vordergrund gestellt und der Konsens der Modellersteller herangezogen, da sie bewerten können, ob der Abstrahierungsgrad des Modells die Realität für die Aufgabenstellung angemessen abbildet. Es muss somit zwischen den Anwendern eine Einigkeit über die, ausreichend durch das Modell abgebildete, Problemstellung und die Art der gewählten Darstellung bestehen. Auch muss ein Konsens bezüglich einheitlicher Namenskonventionen herrschen. Ein inhaltlich identes Attribut oder Objekt muss auch in allen Modellen dieselbe Bezeichnung haben.

Der '''Grundsatz der Sprachadäquanz''' beschreibt dabei die Spracheignung und Sprachrichtigkeit in Relation zum Modellsystem. Die Spracheignung bezieht sich auf die Auswahl der geeigneten Modellierungstechnik für den jeweiligen Modellierungszweck. Die Sprachrichtigkeit bezieht sich dagegen auf die korrekte Anwendung der, im Metamodell definierten, Sprachsyntax.

Diese neuen GoM werden jedoch, im Gegensatz zu ihrer ursprünglichen Version, kaum angewendet, obwohl sie sich durch eine hohe theoretische Begründung und praktische Prüfbarkeit auszeichnen.

IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen - Gesamt

2022-10-01T06:19:14Z

VÖLKL Peter:

{{:UrheberrechtCC}}
 <hr> 
{{:Benutzer:Neuroth-Pfeiffer_Thomas}}
 <hr> 

{{:IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen - Auslöser und Treiber der digitalen Transformation}}

{{:IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen - Transformation von Geschäftsmodellen}}

{{:IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen - Reifegrade der digitalen Transformation}}

{{:IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen - Technologien zur Unterstützung der digitalen Transformation}}

{{:IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen - Auswirkungen der digitalen Transformation auf die Arbeitswelt}}

UrheberrechtCC

2022-10-01T06:18:27Z

VÖLKL Peter: Die Seite wurde neu angelegt: „<div><div>„Creative Commons Namensnennung – Share Alike 4.0 International Public License“ (CC BY SA 4.0.)</div><div> </div><div>Es wird ausdrücklich erklärt, dass alle Angaben trotz sorgfältiger Bearbeitung ohne Gewähr erfolgen und eine Haftung des Autors/der Autorin oder des Verlegers/der Verlegerin ausgeschlossen ist.</div><div> </div>“

<div><div>„Creative Commons Namensnennung – Share Alike 4.0 International Public License“ (CC BY SA 4.0.)</div><div> </div><div>Es wird ausdrücklich erklärt, dass alle Angaben trotz sorgfältiger Bearbeitung ohne Gewähr erfolgen und eine Haftung des Autors/der Autorin oder des Verlegers/der Verlegerin ausgeschlossen ist.</div><div> </div>

Management und Kommunikation

2022-10-01T05:41:46Z

VÖLKL Peter:

[[MN411 - Gesprächsführung, Verhandeln und Konfliktlösung|MN411 - Gesprächsführung, Verhandeln und Konfliktlösung]]

[[MN412 - Management und Organisation|MN412 - Management und Organisation]]

[[MN436 - Gruppen- und Organisationsdynamik|MN436 - Gruppen- und Organisationsdynamik]]

[[MN425 - Beratungstheorie, methoden und -werkzeuge|MN425 - Beratungstheorie, methoden und -werkzeuge]]

[[MN437 - Knowledge Management Instruments & Enterprise Knowledge Infrastructures|MN437 - Knowledge Management Instruments & Enterprise Knowledge Infrastructures]]

[[MN438 - Forschungs,- Technologie- und Innovationsprojekte|MN438 - Forschungs,- Technologie- und Innovationsprojekte]]

[[MN439_Virtuelles_Arbeiten_und_Lernen|MN439 - Virtuelles Arbeiten und Lernen]]

Informationstechnologie und Informationssysteme

2022-10-01T05:40:23Z

VÖLKL Peter:

[[IT523 - Verteilte Systeme|IT523 - Verteilte Systeme]]

[[IT422 - Technische Sicherheitsaspekte|IT422 - Technische Sicherheitsaspekte]]

[[IT445 - Requirements Engineering and Cost Estimation|IT445 - Requirements Engineering and Cost Estimation]]

[[IT449_-_e-Government|IT449 - E-Government]]

[[IT534 - Kryptographie und Zugriffskontrolle|IT534 - Kryptographie und Zugriffskontrolle]]

[[IT546 - Web-Application- und E-Business-Security|IT546 - Web-Application- und E-Business-Security]]

[[IS434 - Managementinformations- und Berichtssysteme|IT43B - Managementinformations- und Berichtssysteme]]

[[IS532 - E-Commerce-Systeme|IT530 - E-Commerce-Systeme]]

[[IS533 - Management kooperativer Informationssysteme|IT43A - Management kooperativer Informationssysteme]]

Informationstechnologie und Informationssysteme

2022-10-01T05:39:49Z

VÖLKL Peter:

[[IT523 - Verteilte Systeme|IT523 - Verteilte Systeme]]

[[IT422 - Technische Sicherheitsaspekte|IT422 - Technische Sicherheitsaspekte]]

[[IT445 - Requirements Engineering and Cost Estimation|IT445 - Requirements Engineering and Cost Estimation]]

[[IT449_-_e-Government|IT449 - E-Government]]

[[IT534 - Kryptographie und Zugriffskontrolle|IT534 - Kryptographie und Zugriffskontrolle]]

[[IT538_-_Industrie_4.0_und_IoT_Security|IT538 - Industrie 4.0 und IoT Security]]

[[IT546 - Web-Application- und E-Business-Security|IT546 - Web-Application- und E-Business-Security]]

[[IS434 - Managementinformations- und Berichtssysteme|IT43B - Managementinformations- und Berichtssysteme]]

[[IS532 - E-Commerce-Systeme|IT530 - E-Commerce-Systeme]]

[[IS533 - Management kooperativer Informationssysteme|IT43A - Management kooperativer Informationssysteme]]

Informationssystemmanagement und -Sicherheit

2022-10-01T05:39:31Z

VÖLKL Peter:

[[IM412 - Führung und Organisation im IT-Bereich|IM412 - Führung und Organisation im IT-Bereich]]

[[IM423 - Informationssicherheitsmanagement|IM423 - Informationssicherheitsmanagement]]

[[IM535 - IT-Governance|IM535 - IT-Governance]]

[[IM436 - Internationale IT-Projekte und Projektcontrolling|IM436 - Internationale IT-Projekte und Projektcontrolling]]

[[IM448 - Collaborative Business|IM448 - Collaborative Business]]

[[IM449 - Outsourcing, Offshoring & Alliances|IM449 - Outsourcing, Offshoring & Alliances]]

[[IM537_-_Digitale_Transformation_und_Digitalisierung_von_Gesch%C3%A4ftsprozessen|IM537 - Digitale Transformation und Digitalisierung von Geschäftsprozessen]]

[[IS421 - Business & Competitive Intelligence Systems|IM540 - Business & Competitive Intelligence Systems]]

Computer- und Netzwerksicherheit - Zugriffssteuerung

2022-04-03T08:12:44Z

VÖLKL Peter:

= Zugriffssteuerung =

Die Zugriffssteuerung (Access Control) regelt den Zugriff und die Kommunikation von IT-Systemen mit ihren Anwendern, Ressourcen und anderen IT-Systemen. Es handelt sich dabei um eine zentrales Element der meisten IT-Systeme, da davon alle Schutzziele (Vertraulichkeit, Integrität und Verfügbarkeit; siehe Lektion "[[Computer- und Netzwerksicherheit_-_Grundlagen#S%C3%A4ulen_der_Informationssicherheit_-_CIA_Triade|Säulen der Informationssicherheit - CIA Triade]]") betroffen sein können.

In dieser Lektion werden die grundlegenden Begriffe der Zugriffssteuerung erläutert und weiter die konkreten Techniken der Zertifikate und der Fernzugriffe sowie potentielle Angriffsvektoren näher behandelt.

== Grundbegriffe der Zugriffssteuerung ==

Um die Schutzziele der Vertraulichkeit, Integrität und Verfügbarkeit des Datenaustausches mit IT-Systemen gewährleisten zu können müssen die jeweiligen Anforderungen an die Kommunikation definiert werden. Dabei gibt es einige wesentliche Begriffe, welche oft auch von Technikern falsch verwendet werden. Beispielsweise werden ''Identifikation'', ''Authentifikation'' und ''Autorisation'' manchmal fälschlicherweise als Akronyme verwendet, obwohl es sich dabei um grundlegend unterschiedliche Begriffe handelt. Auch ist es wichtig zu wissen, wie bestimmte Anforderungen an die Zugriffssteuerung implementiert werden können.

=== Zugriff ===

Beim Zugriff handelt es sich um die Kommunikation mit einem IT-System. Diese kann sowohl mit einem Anwender, als auch mit einem anderen IT-System oder seiner Ressourcen stattfinden. In den meisten Fällen gibt es dabei Anforderungen an Identifikation, Authentifikation und Autorisation, sowie an die Nachverfolgbarkeit und Nichtabstreitbarkeit (siehe weiter auch Lektion "[[Computer- und Netzwerksicherheit_-_Kryptograhpie#Kryptographie|Krypotgraphie]]" Unterkapitel 2 - 5).

Ressourcen können dabei alle Komponenten sein, welche einen Zugriff auf Daten ermöglichen oder diese beinhalten, wie beispielsweise: Datenbanken, Tabellen und Dateien. Die Zugriffe können dabei sowohl über lokale Verbindungen, als auch über das Netzwerk/Internet oder unterschiedliche Datenträger erfolgen.

=== Identifikation ===

Die Identifikation bezeichnet die Benennung eines bestimmten Systems oder einer Person, welche auf ein System zugreifen möchte. Dabei ist weder sichergestellt durch wen diese Benennung erfolgt ist, noch ob es sich bei der Benennung tatsächlich um das benannte System oder die benannte Person handelt.

Zur Identifikation dienen oft die eindeutige User-ID, die E-Mailadresse oder der Name.

Ein Beispiel ist eine Anwesenheitsliste: Die Protokollführung schreibt die Namen der anwesenden Personen auf, welche diese wiederum identifizieren. Dabei ist jedoch noch nicht sichergestellt, ob die jeweiligen Personen tatsächlich die sind, die sie vorgeben zu sein. Im schlechtesten Fall sind sie der Protokollführung nicht bekannt und identifizieren sich durch Nennung ihres Namens.

=== Authentifikation ===

Die eindeutige Identifikation einer Person oder eines Systems wird als Authentifikation bezeichnet. Erst dadurch wird sichergestellt, dass es sich dabei tatsächlich um die Identifizierten handelt.

Es gibt drei unterschiedliche Kategorien von Authentifikationsmethoden und -merkmale:

* '''Wissen''' (was jemand weiß),
* '''Besitz''' (was jemand besitzt) und
* '''Biometrie''' (was jemand ist).
Die drei Merkmale Wissen, Besitz und Biometrie werden oft auch als „Wissen, Haben und Sein“ bezeichnet.

Eine häufig eingesetzte Methode ist das Passwort. Dieses ist in der Kategorie des '''Wissens''' eingeordnet, da es von jedem eingesetzt werden kann, der es kennt. Es kann daher auch weitergegeben oder ausgespäht werden. Je komplexer es ist, desto leichter kann es auch vergessen werden. Je häufiger es verwendet wird, desto schneller kann es herausgefunden werden. Zu komplexe Passwörter sind daher keine gute Lösung zur sicheren Authentifikation, da sie von vielen Usern vergessen oder aufgeschrieben werden. Dasselbe gilt für zu einfache Passwörter, da sie leicht erraten werden können.

Beim Merkmal des '''Besitzes''' wird die Authentifikation über etwas erreicht, dass nur der zu Authentifizierende besitzt. Beispiele dafür sind ein Personalausweis oder eine Chipkarte (z.B. eine Bankomatkarte). Damit die Weitergabe dieses Merkmals überhaupt nicht, oder nur sehr schwierig möglich ist, sollte es möglichst nicht vervielfältigt werden können.

Unter '''Biometrie''' werden Merkmale verstanden, die an eine bestimmte Person (oder ein bestimmtes System) gebunden sind. Sie sind öffentlich sichtbar oder beobachtbar, jedoch nicht leicht duplizierbar. Häufig bekannte Beispiele für biometrische Merkmale sind Fingerabdrücke, Venenmuster, die Iris-Muster der Augen und Stimmmuster. Weitere, oft weniger bekannte, Merkmale sind jedoch auch die Art des Ganges einer Person, ihre Tastenanschläge, ihr Schreibstil und aber auch die Art und Weise wie sie sich innerhalb eines Programmes oder einer Webseite bewegen.

Je nach Sicherheitsanforderungen können dabei auch mehrere Merkmale kombiniert werden um die Authentifizierungsqualität noch weiter zu verstärken. Ein bekanntes Beispiel dafür ist die zur Bargeldbehebung mittels Bankomatkarte notwendige Authentifizierung. Dabei wird ein Besitzmerkmal (Bankomatkarte) mit einem Wissensmerkmal (PIN-Code) kombiniert. Ist jemand im Besitz der Karte, benötigt er zusätzlich noch den PIN-Code und umgekehrt. Mit einem der beiden Merkmale allein kann keine gültige Authentifikation erfolgen und damit auch kein Geld behoben werden.

Werden zwei Merkmale kombiniert, wird dies auch als '''Zwei-Faktor-Authentifizierung''' bezeichnet. Wichtig ist dabei immer, dass zwei Merkmale unterschiedlicher Kategorien (Wissen, Besitz und Biometrie) kombiniert werden. Die Kombination zweier Merkmale derselben Kategorie, erhöht zwar die Sicherheit, gilt dabei jedoch nicht als Zwei-Faktor-Authentifizierung. Die einzelnen Merkmalskategorien und die sich daraus ergebenen Authentifizierungslevel sind weiter in Abbildung "Authentifizierungsfaktoren: Wissen, Besitz und Biometrie" dargestellt.

Ob die Authentifizierungsqualität durch den Einsatz von drei Faktoren weiter stark erhöht werden kann, ist umstritten. Dies ist stark von den jeweils eingesetzten Techniken, aber auch von deren Akzeptanz bei den Anwendern, abhängig.

[[Datei:IT244 15.png|300px|none|thumb| Authentifizierungsfaktoren: Wissen, Besitz und Biometrie]]


=== Autorisation ===

Bei der Autorisation handelt es sich um die Berechtigung, die eine authentifizierte Person oder ein authentifiziertes System für einen bestimmten Zugriff hat. So können in einem System beispielsweise unterschiedliche Rollen existieren, welche wiederum unterschiedliche Zugriffe ermöglichen. Wie ein System unterschiedliche Autorisationen verwaltet und behandelt wird als [[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Zugriffssteuerungsmodelle|Zugriffssteuerungsmodell]] bezeichnet.

Die Authentifikation stellt damit sicher, dass es sich um jemand bestimmten handelt und die Autorisation regelt wiederum welche bestimmten Rollen welche Zugriffe bekommen.

=== Nachverfolgbarkeit und Nichtabstreitbarkeit ===

Bei der Nachverfolgbarkeit und Nichtabstreitbarkeit handelt es sich um Zugriffsmerkmale, welche eine genaue Dokumentation der jeweiligen Systemkommunikation ermöglichen. Je nach Anforderung wird dabei dokumentiert, welche Zugriffe stattgefunden haben und unter welchen (Sicherheits-)Parametern diese aufgebaut wurden. Um eine lückenlose Nachverfolgbarkeit sicherzustellen, ist es erforderlich, den Erfolg der Authentifikation und die erteilte Autorisation zu dokumentieren.

In manchen Fällen ist es weiter erforderlich eine Nichtabstreitbarkeit von Zugriffen zu ermöglichen. Als '''Nichtabstreitbarkeit''' wird bezeichnet, das eine Person die Erstellung einer gesendeten Nachricht nicht mehr abstreiten kann. Dies beinhaltet auch automatisch die Integrität der Nachricht. Es muss daher für eine Nichtabstreitbarkeit auch sichergestellt sein, dass die Nachricht nicht mehr verändert wurde, da anderenfalls der Absender behaupten könnte, ursprünglich eine andere Nachricht erstellt zu haben.

Die Nichtabstreitbarkeit kann mit Hilfe asymmetrischer Kryptographie Methoden sichergestellt werden (siehe Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie"). Dabei wird der Hashwert einer Nachricht mit dem privaten Schlüssel des Absenders verschlüsselt. Zur Prüfung der Integrität (ob die Nachricht der abgesendeten Nachricht entspricht), muss nun nur noch der verschlüsselte Hashwert mit dem öffentlichen Schlüssel entschlüsselt und mit dem aktuellen Hashwert der Nachricht verglichen werden. Da die Verschlüsselung nur vom Besitzer des privaten Schlüssels durchgeführt werden kann, ist hier eine Nichtabstreitbarkeit gewährleistet.

=== Zugriffssteuerungsmodelle ===

Zugriffssteuerungsmodelle (Access Control Models) regeln die Art und Weise von Zugriffen. Sie definieren dabei die möglichen Regeln und Ziele der Zugriffe und stellen diese den jeweiligen Zugriffssteuerungstechnologien zur Verfügung. Die Modelle sind ein wesentlicher Bestandteil des jeweiligen Betriebssystems, da sie grundlegende Entscheidungen der internen Zugriffe beeinflussen. Sie sind daher direkt im Kern des Betriebssystems integriert. [Ha13, 219]

Es wird zwischen drei verschiedenen Kategorien von Zugriffssteuerungsmodellen unterschieden:

* Eigner-definierte Zugriffssteuerung (DAC: Discretionary Access Control),
* Obligatorische Zugriffssteuerung (MAC: Mandatory Access Control) und
* Rollenbasierte Zugriffssteuerung (RBAC: Role Based Access Control).
Da eine gleichzeitige Unterstützung mehrerer Modelle meist nicht sinnvoll realisierbar ist, ist die Modellauswahl eine grundlegende Entscheidung für das IT-System. Das am häufigsten anzutreffende Modell ist das der Eigner-definierten Zugriffssteuerung.

'''Eigner-definierte Zugriffssteuerung'''

Bei der Eigner-definierten Zugriffssteuerung haben alle Daten einen definierten Eigner (oft auch als Besitzer bezeichnet). Dieser ist fest mit den Daten oder der Datei verbunden. Der Eigner definiert, welche Personen oder Systeme Zugriff auf die Daten erhalten und in welcher Form (z.B.: lesen, schreiben, ändern, ausführen oder verweigern).

Die Zugriffsberechtigungen sind dabei meist über Access Control Lists (ACL‘s) definiert. Dabei handelt es sich um eine Auflistung aller Berechtigten und der jeweils zugeordneten Rechte.

Dieses Modell ist in aktuellen Windows-, Linux- und Mac-Systemen anzutreffen. In diesen Systemen hat jede Datei einen Besitzer und eine entsprechende ACL zugeordnet.

Einzelne User und Systeme können hier meist in Berechtigungsgruppen zusammengefasst werden. In diesem Fall können die ACL’s sowohl Zuordnungen einzelner User und Systeme, als auch Berechtigungsgruppen enthalten.

'''Obligatorische Zugriffssteuerung'''

Die obligatorische Zugriffssteuerung findet ihre Anwendung in Bereichen mit sehr hohem Sicherheitsbedarf. Sie kommt daher meist in behördlichen und militärischen Systemen zum Einsatz.

In diesem Modell ist keine individuelle Behandlung einzelner User und Dateien vorgesehen. Der Zugriff ist abhängig von unterschiedlichen Sicherheitsstufen, auf denen sich Daten und User befinden. Meist ist dabei eine Änderung von Dateiberechtigungen durch die User nicht möglich.

Die Umsetzung der Sicherheitsstufen erfolgt durch Vertrauens-Levels (Clearance) für User und Sensitivitäts-Labels für Dateien. Mögliche Sicherheitsstufen wären z.B.: nicht vertraulich, vertraulich, geheim und streng geheim.

Der Zugriff auf Daten erfolgt gemäß den jeweiligen Sicherheitsstufen. Sind die Stufe der Datei und die Stufe des Users ident, darf er auf die Daten zugreifen. Ob er auf Daten von darunterliegenden Stufen zugreifen darf, kann unterschiedlich implementiert sein. Meist dürfen Informationen nur von niedrigeren Levels zu höheren Levels übertragen werden und nicht umgekehrt. Zugriffe zwischen unterschiedlichen Levels werden dabei meist auch von eigenen Überwachungsdienstprogrammen gesteuert und genehmigt.

Zusätzlich werden meist hierarchische Zuordnungen vergeben, in denen sich sowohl Daten, als auch User befinden können. Die hierarchische Zuordnung steht dann nochmals über der Zuordnung des Sicherheitslevels. Damit ist sichergestellt, dass die Zugriffe nicht nur gemäß des Vertrauens-Levels, sondern auch gemäß der Zugriffs-Notwendigkeit erfolgen. Befindet sich ein User nicht in derselben hierarchischen Zuordnung, wie die jeweiligen Daten, wird davon ausgegangen, dass er keinen Zugriff benötigt und der Zugriff daher verweigert.

Ein frei verfügbares Betriebssystem, welches das Modell der obligatorischen Zugriffssteuerung einsetzt, ist beispielsweise SE Linux [Na09].

'''Rollenbasierte Zugriffssteuerung'''

Bei der rollenbasierten Zugriffssteuerung werden Organisationsrichtlinien und -abläufe in ein Zugriffsmodell übersetzt. Dabei werden einzelnen Usern oder Systemen bestimmte (Organisations-)Rollen zugeordnet. Der Zugriff auf Daten hängt dabei von der jeweiligen Rolle des Zugreifenden ab. Die Berechtigung wird bei jedem Zugriffsversuch überprüft und dann genehmigt oder abgewiesen.

Bei den hier eingesetzten Rollen handelt es sich nicht um Gruppen im Sinne der Eigner-definierten Zugriffssteuerung, sondern um Rollen innerhalb des jeweiligen Geschäftsprozesses bzw. einer Organisationseinheit. So kann ein User eine Rolle haben, die ihm aus einer Anwendung heraus Zugriff auf einen Datensatz gestattet und aus einer anderen Anwendung nicht mehr, obwohl es sich um denselben Datensatz handelt. Wichtig ist dabei immer die Betrachtung des aktuellen Zwecks des Zugriffes.

Die Implementierung rollenbasierter Zugriffssteuerungen ist daher auch komplexer als die der Eigner-definierten Zugriffssteuerung.

== Passwortsicherheit ==

Wie bereits in der Lektion zu [[Computer- und_Netzwerksicherheit_-_Kryptograhpie|Kyptographie]] beschrieben, hat die sichere Speicherung von Passwörtern eine hohe Priorität und sollte in einer entsprechend sicheren Architektur erfolgen. Zusätzlich zur technischen Sicherheit ist eine entsprechende '''Passwortkomplexität von besonderer Relevanz'''. Ein noch so effizient abgesicherter Passwortspeicher verliert an Bedeutung, wenn das darin gespeicherte Passwort selbst unsicher ist.

Ein unsicheres Passwort hat entweder:

* eine zu geringe '''Komplexität''' und kann daher durch [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Bruteforce]]- oder [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Hash-Kollisions-Angriffe]] gefunden werden, oder
* kann durch '''[[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]''' herausgefunden werden (z.B.: Name des Kindes mit Jahreszahl, Anfangsbuchstaben des Titels des Lieblingsliedes, usw.).
Die Komplexität eines Passwortes ergibt sich aus der '''Entropie''' – also den möglichen unterschiedlichen Kombinationen bzw. dem [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Schl%C3%BCssel_(Key)_und_Keyspace|Keyspace]]. Daraus und an der Anzahl an Passwörtern, welche pro Sekunde geprüft werden können, ergibt sich dann wiederum die Dauer, in welcher das Passwort durch Ausprobieren (Bruteforce-Angriff) gefunden werden kann.

Für die Komplexität von Passwörter galt lange eine bestimmte Mindestlänge (meist 8 Zeichen) und eine Kombination aus den Merkmalen:

* Kleinbuchstaben,
* Großbuchstaben,
* Ziffern und
* Sonderzeichen
als ausreichender Schutz.

Beispielsweise ein Passwort '''„''f9D22+P#''“''' mit 8 Zeichen und Erfüllung aller oben genannten Kriterien hat somit folgende Komplexität:

* 26 Kleinbuchstaben +
* 26 Großbuchstaben +
* 10 Ziffern +
* 36 Sonderzeichen (alle Sonderzeichen der deutschen Tastatur)
* '''= 98 Mögliche Zeichen pro Stelle'''.
* '''Bei 8 Zeichen sind das 98^8 mögliche Passwortkombinationen.'''
Ein Hochleistungs-PC, welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''23 Tage''' um das Passwort herauszufinden.

Ein Problem solcher komplexen Passwörter ist, dass es für die meisten User schwierig ist, sie sich zu einzuprägen. Dadurch besteht ein erhöhtes Risiko, dass die Passwörter:

* vergessen werden,
* auf einem Zettel notiert werden,
* nicht ausreichend oft geändert werden oder
* nur minimal geändert werden – beispielsweise durch simple Variation einzelner Teile des Passwortes, wie einer Ziffer am Ende.
Aufgrund der oben genannten Schwächen und der dennoch geringen Entropie noch gut merkbarer Passwortlängen, können diese Passwortrichtlinien '''nicht mehr als Stand der Technik''' betrachtet werden. Eine wesentlich bessere Möglichkeit ist die Nutzung von zufälligen Wörtern aus dem Wörterbuch. [Ga17]

Bei der Nutzung von '''vier zufälligen Wörtern aus dem Wörterbuch''' (kein Satz, sondern tatsächlich zufällig gewählte Wörter), ergibt sich bei Nutzung der 100.000 unterschiedlichen Wörter des Österreichischen Wörterbuchs [AF20] folgende Komplexität:

* '''100.000 mögliche Wörter pro „Stelle“ (ein Wort ist somit eine Stelle).'''
* '''Bei 4 Wörtern sind das 100.000^4 mögliche Passwortkombinationen.'''
Ein Hochleistungs-PC (der selbe PC wie im ersten Beispiel), welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''738 Jahre''' um das Passwort herauszufinden.

Ein Beispiel für ein Passwort aus 4 unzusammenhängenden Wörtern aus dem deutschen Duden ist: '''„''Dachs faul logisch Gerät''“'''.

Das Passwort weißt somit eine '''wesentlich höhere Entropie''' auf und ist für einen Menschen gleichzeitig '''leichter merkbar'''.

Leider ist diese Form der Passwörter in '''vielen Systemen noch nicht implementiert''' und es werden noch die veralteten Komplexitätsmerkmale des ersten Beispiels abgerufen. Diese Hürde kann ganz einfach überwunden werden, indem am Ende des Passworts eine Ziffer und ein Sonderzeichen gestellt werden. Da diese keine wirkliche Relevanz für die genannte Passwortsicherheit haben, können hier auch Zeichen genutzt werden, die schnell zu tippen sind. Das oben genannte Passwort könnte damit dann einfach '''''„Dachs faul logisch Gerät 9+“''''' lauten.

== Zertifikate ==

Zertifikate dienen der Feststellung der Identitäten von Personen und Systemen auf digitalem Wege. Ein Zertifikat ist ein digitales Dokument, indem bestimmte Daten angegeben sind, welche eine Person oder ein System und optional auch zugehörige Eigenschaften identifizieren. Zertifikate sind wesentliche Bestandteile von Public-Key-Systemen und enthalten zusätzlich den jeweiligen Public-Key des Zertifikatsinhabers (siehe auch Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie").

Um die Echtheit eines Zertifikats zu bestätigen, kann dieses von anderen Stellen signiert werden. Diese Stellen werden als '''Zertifizierungsstellen (CA: Certification Authority)''' bezeichnet. Die Signatur erfolgt dabei, wie in Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" beschrieben, durch hashen des Zertifikates und Verschlüsselung des Hashwertes durch den privaten Schlüssel der Zertifizierungsstelle. Da der öffentliche Schlüssel – wiederum durch das Zertifikat der Zertifizierungsstelle – bekannt ist, kann der Hashwert korrekt entschlüsselt, und die Signatur damit als gültig erkannt, werden.

Ob diese Echtheitsbestätigungen nun '''hierarchisch''' erfolgen ([[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Public-Key-Infrastruktur_(PKI)|Public-Key-Infrastruktur]]), oder über ein dezentral '''verteiltes Vertrauensmodell''' ([[Computer- und Netzwerksicherheit_-_Zugriffssteuerung#Web_of_Trust_(WOT)|Web of Trust]]) ist von der jeweiligen Implementierung abhängig. Derzeit sind beide Modellvarianten im Einsatz und finden ihre Anwendung in einer Vielzahl von Systemen. Die Zertifikate der behördlich akzeptierten digitalen Signaturen basieren derzeit auf dem hierarchischen Modell der Public-Key-Infrastruktur.

Ein Zertifikat ist mit einem Ausweisdokument vergleichbar. Auf dem Ausweis befinden sich die Daten der Person und ein Verweis auf den Aussteller. Durch Sicherheitsmerkmale am Dokument (Wasserzeichen, Silberstreifen,…) wird dabei die Echtheitsprüfung ermöglicht. Der Aussteller (z.B. eine Behörde) bestätigt damit die Identität des Inhabers (z.B. Personalausweis) und gegebenenfalls auch bestimmte durch das Dokument erlaubte Tätigkeiten (z.B. Führerschein).

Die Echtheit eines Zertifikates kann von der jeweiligen Zertifizierungsstelle auch wieder zurückgezogen werden. Zu diesem Zweck werden '''Zertifikats-Sperrlisten (CRL: Certificate Revocation Lists)''' eingesetzt, welche Einträge der Seriennummern aller Zertifikate mit zurückgenommenen Echtheitsbestätigungen enthält. Die Sperrliste ist selbst wiederum von der jeweiligen Zertifizierungsstelle signiert, um ihre Echtheit zu bestätigen.

Der Aufbau und der mögliche Inhalt eines Zertifikates ist im '''X.509 Standard''' [Ne99] definiert. Ein entsprechendes Beispiel (das aktuelle Zertifikat des Online-Campus) ist in Abbildung "Zertifikat" dargestellt.

[[Datei:IT244 16.png|300px|none|thumb|Zertifikat]]


=== Public-Key-Infrastruktur (PKI) ===

Bei der Public-Key-Infrastruktur (PKI) handelt es sich um ein hierarchisch aufgebautes System von Zertifizierungsstellen. Das bedeutet, dass jede Zertifizierungsstelle das in sie gesetzte Vertrauen an nachfolgende Stellen weiterverteilen kann, indem sie die zugehörigen Zertifikate signiert.

Daraus ergibt sich dann eine Hierarchie aus mehreren Zertifikaten, die bis zu einem Stammzertifikat rückverfolgt werden können sind. Durch das Vertrauen in das jeweilige Stammzertifikat wird auch den nachfolgenden Zertifikaten vertraut.

In den meisten Anwendungen, die PKI Zertifikate einsetzen (z.B. Internetbrowser für HTTPS Verbindungen), sind bereits einige gängige Stammzertifikate der großen Zertifizierungsstellen vorinstalliert. Es ist jedoch meist auch möglich weitere Stammzertifikate hinzuzufügen, denen dann ebenfalls vertraut wird. In Abbildung "Zertifizierungspfad" ist die Hierarchie des Zertifikates des Online-Campus dargestellt. Die Stammzertifizierungsstelle ist in diesem Fall das Unternehmen Go Daddy.

[[Datei:IT244 17.png|300px|none|thumb|Zertifizierungspfad]]


Zusätzlich zu den Zertifizierungsstellen gibt es in der PKI noch weitere Instanzen, welche hautsächlich für den Zertifizierungsprozess verantwortlich sind. Die Hauptakteure der PKI sind:

* Zertifizierungsstelle (CA: Certification Authority),
* Registrierungsstelle (RA: Registration Authority) und
* Validierungsdienst (VA: Validation Authority)
Die '''Registrierungsstelle''' ist in der PKI dafür verantwortlich die Identität des Antragsstellers zu überprüfen und dies wiederum der Zertifizierungsstelle mitzuteilen. Die '''Validierungsstelle''' ist für die Gültigkeitsprüfung von bereits ausgestellten Zertifikaten verantwortlich. Sie verwaltet auch die Zertifikats-Sperrlisten und ihre Erreichbarkeit ist meist in einem Datenfeld in den Zertifikaten selbst angegeben.

Soll nun ein neues Zertifikat ausgestellt werden, muss folgender '''Zertifizierungsprozess''' durchlaufen werden:

# Der Antrag für das neue Zertifikat wird an die Registrierungsstelle (RA) geschickt
# Die Registrierungsstelle (RA) überprüft den Antrag und stellt sicher, dass es sich bei der Identität tatsächlich um die der antragstellenden Person oder des zugehörigen IT-Systems (z.B. bei einem Webserver-Zertifikat) handelt.
# Wenn die Registrierungsstelle die Identität bestätigen kann, sendet sie den Antrag weiter an die Zertifizierungsstelle (CA).
# Die Zertifizierungsstelle (CA) stellt nun das beantragte Zertifikat aus, generiert dafür einen privaten und einen öffentlichen Schlüssel und sendet diese an die antragsstellende Person.
Oft ist es auch möglich das Schlüsselpaar selbst zu generieren und dem Antrag nur den öffentlichen Schlüssel beizufügen. Dies ist für die Ausstellung des Zertifikates ausreichend, da der private Schlüssel für seine Signierung nicht benötigt wird (diese wird durch den privaten Schlüssel der CA durchgeführt). In diesem Fall ist zusätzlich sichergestellt, dass der private Schlüssel nur der antragsstellenden Person bekannt ist.

Gerade bei der Überprüfung durch die Registrierungsstelle gibt es unterschiedliche Qualitäten. Wird hier ungenau vorgegangen, kann dies zu Zertifikaten falscher Identitäten führen.

=== Web of Trust (WOT) ===

Das Modell des Web of Trust ist im Gegensatz zur PKI nicht hierarchisch, sondern dezentral aufgebaut. Es basiert auf einer dezentralen Vertrauensverteilung zwischen den Teilnehmern, ähnlich dem Freundes- und Bekanntenkreis einer Person. Die Schlüssel sind dabei nicht in einer hierarchischen Struktur zentral abrufbar und überprüfbar, sondern werden direkt von den Benutzern verwaltet. Jeder User hat seinen eigenen Schlüsselbund, wobei hier zwischen dem privaten und dem öffentlichen Schlüsselbund unterschieden wird.

Am '''privaten Schlüsselbund''' befinden sich die privaten Schlüssel des Users, mit denen Daten signiert und entschlüsselt werden können. Am '''öffentlichen Schlüsselbund''' befinden sich die eigenen öffentlichen Schlüssel, sowie die öffentlichen Schlüssel anderer User. Mit den öffentlichen Schlüsseln können Nachrichten verschlüsselt und Signaturen geprüft werden.

Die Vertrauensstufen werden über die öffentlichen Schlüssel der Teilnehmer ermittelt. Dazu gibt es im öffentlichen Schlüsselbund für jeden Schlüssel ein '''Key Legimitation Field''', in dem der jeweilige '''Vertrauensgrad (Owner Trust)''' des Schlüssels angegeben wird.

Im WOT gibt es folgende Vertrauensgrade:

* unknown: Personen über die keine Informationen bekannt sind,
* not trusted: Personen denen nicht vertraut wird,
* marginal: Personen denen nicht voll vertraut wird,
* complete: Personen denen voll vertraut wird und
* ultimate: eigener öffentlicher Schlüssel.
Wer als vertrauenswürdig eingestuft wird, liegt somit beim jeweiligen Schlüsselbund Inhaber.

Die Vertrauensgrade können an andere User (z.B. über einen Schlüsselserver) weitergegeben werden, indem die jeweiligen Schlüssel durch den eigenen privaten Schlüssel signiert werden. Dies wird auch als '''indirekte Zertifizierung''' bezeichnet.

Ist dem User, der einen dritten Schlüssel signiert hat, im eigenen Schlüsselbund einem Vertrauensgrad zugewiesen, so erhält der von ihm signierte Schlüssel je nach eigener Einstellung denselben Vertrauensgrad oder niedriger. Zusätzlich kann definiert werden, wie viele signierte Schlüssel eines niedrigeren Vertrauensgrades notwendig sind, um die Vertrauensstufe um eine Stufe aufzuwerten. Die Standartwerte hierfür sind 3 signierte Schlüssel anderer User für die Aufwertung und ein signierter Schlüssel eines anderen Users für dieselbe Stufe.

Diese Abhängigkeiten sind in Abbildung "Web of Trust - Vertrauensnetzwerk" ersichtlich: Peter kennt sowohl Anna, als auch Christoph persönlich und hat daher ihre öffentlichen Schlüssel in seinem öffentlichen Schlüsselbund abgelegt. Christoph hat nur eine direkte Beziehung zu Anna, nicht aber zu Peter. Da sich Christophs öffentlicher Schlüssel im öffentlichen Schlüsselbund von Anna befindet, erkennt Peter sein Zertifikat als gültig an.

[[file:img1643193688517.png|300px|alt=Web of Trust - Vertrauensnetzwerk|none|thumb|Web of Trust - Vertrauensnetzwerk]]

Die erste Implementierung des WOT war '''Pretty Good Privacy (PGP)''' [Sy15]. Es ist ein Softwarepaket, welches die Sicherstellung der Authentizität, Integrität und Vertraulichkeit von E-Mails sowie beliebiger Dateien ermöglicht. '''GnuPG''' [Gn15] ist die frei verfügbare Version, die unter der GNU General Public License [Fr07] steht. Ein möglicher Windows Client für GnuPG ist beispielsweise Gpg4win [In15b].

=== Neue Zertifikatsmodelle und Erweiterungen ===

Sowohl im Bereich des PKI, als auch im WOT Modell, gibt es mittlerweile einige bekannte Sicherheitslücken und Protokollfehler. Weiter ist gerade im PKI Modell die Rolle der CA enorm wichtig. Werden hier nur schlechte Identitätskontrollen bei der Ausstellung von Zertifikaten durchgeführt, kann es zu falschen validen Identitäten kommen. Im Bereich des WOT können beispielsweise die Schlüsselserver zum Generieren von SPAM-Versandlisten genutzt werden, da die zugehörigen E-Mailadressen der Zertifikate dort frei verfügbar sein müssen. Weiter sind über die WOT soziale Netzwerke der User analysierbar, da die Trustlevel und ihre Abhängigkeiten leicht analysiert werden können. [Br14]

Um diese Schwachstellen zu beseitigen wird bereits an möglichen neuen Protokollen und Erweiterungen geforscht. Den meisten Ansätzen gemein ist, die Abhängigkeit von einzelnen CA’s zu verringern. Fehler einer CA sollen möglichst auf Seite der Endanwendung (wie z.B. im Browser oder Mail Client) frühzeitig erkannt und angezeigt werden. [Br14]

Einer dieser neuen Ansätze ist die Software ''Perspectives'' [Ca15]. Dabei handelt es sich um eine Browsererweiterung, die jedes Zertifikat zusätzlich mit einem sogenannten Notary-Server abgleicht. Damit können beispielsweise Man-in-the-Middle Angriffe frühzeitig erkannt werden.

Weitere aktuelle Erweiterungen sind [Br14]:

* Pinning [EPS14],
* Certificate Transparency [LLK13],
* Microsoft SmartScreen [Mi15] und
* DANE [HVS12].

== Angriffsvektoren der Access Control ==

Die Angriffsmethoden der Access Control sind sehr vielfältig und haben oft [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffsvektoren_der_Kryptographie|Angriffsvektoren der Kryptographie]] und [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Angriffsvektoren_der_Daten%C3%BCbertragung|Datenübertragung]], sowie [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]als Grundlage. Dies trifft insbesondere auf Angriffe gegen die Integrität und Authentizität zu.

Dazu bereits behandelte Angriffsvektoren sind:

* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Brute-Force Angriffe]],
* [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Phishing|Phishing]] und
* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Angriffe gegen Hashwerte]].
Eine weitere wichtige Angriffsmethode ist die des '''Pharming.''' Dabei wird die Anfrage eines Users auf einen bösartigen Server umgeleitet. Er glaubt sich sicher und gibt dann dort seine geheimen Daten ( wie z.B.: Zugangsdaten und Transaktionsdaten) preis. Beim Pharming handelt es sich daher um einen [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Man-in-the-Middle_Angriff|Man-in-the-Middle Angriff]].

== Wiederholungsaufgaben/Übungen ==

'''1 Was ist der Unterschied zwischen Identifikation, Authentifikation und Autorisation?'''

'''2 Was ist eine Zwei-Faktor-Authentifikation?'''

'''3 Welche drei Zugriffssteuerungsmodelle gibt es?'''

'''4 Erklären Sie das Modell der Eigner-definierten Zugriffssteuerung.'''

'''5 Was sind Zertifikate und die damit verbundenen Vertrauensmodelle?'''

'''6 Was bedeutet PKI und wer sind ihre Hauptakteure? Wie hängen diese Akteure zusammen?'''

'''7 Eine Passwortrichtlinie fordert ein Passwort, bestehend aus Kleinbuchstaben, Großbuchstaben und Ziffern mit einer Länge von 10 Zeichen. Wie wird die Komplexität des Passworts berechnet (wie viele mögliche Passwörter gibt es)?'''

Computer- und Netzwerksicherheit - Zugriffssteuerung

2022-04-03T08:08:28Z

VÖLKL Peter:

= Zugriffssteuerung =

Die Zugriffssteuerung (Access Control) regelt den Zugriff und die Kommunikation von IT-Systemen mit ihren Anwendern, Ressourcen und anderen IT-Systemen. Es handelt sich dabei um eine zentrales Element der meisten IT-Systeme, da davon alle Schutzziele (Vertraulichkeit, Integrität und Verfügbarkeit; siehe Lektion "[[Computer- und Netzwerksicherheit_-_Grundlagen#S%C3%A4ulen_der_Informationssicherheit_-_CIA_Triade|Säulen der Informationssicherheit - CIA Triade]]") betroffen sein können.

In dieser Lektion werden die grundlegenden Begriffe der Zugriffssteuerung erläutert und weiter die konkreten Techniken der Zertifikate und der Fernzugriffe sowie potentielle Angriffsvektoren näher behandelt.

== Grundbegriffe der Zugriffssteuerung ==

Um die Schutzziele der Vertraulichkeit, Integrität und Verfügbarkeit des Datenaustausches mit IT-Systemen gewährleisten zu können müssen die jeweiligen Anforderungen an die Kommunikation definiert werden. Dabei gibt es einige wesentliche Begriffe, welche oft auch von Technikern falsch verwendet werden. Beispielsweise werden ''Identifikation'', ''Authentifikation'' und ''Autorisation'' manchmal fälschlicherweise als Akronyme verwendet, obwohl es sich dabei um grundlegend unterschiedliche Begriffe handelt. Auch ist es wichtig zu wissen, wie bestimmte Anforderungen an die Zugriffssteuerung implementiert werden können.

=== Zugriff ===

Beim Zugriff handelt es sich um die Kommunikation mit einem IT-System. Diese kann sowohl mit einem Anwender, als auch mit einem anderen IT-System oder seiner Ressourcen stattfinden. In den meisten Fällen gibt es dabei Anforderungen an Identifikation, Authentifikation und Autorisation, sowie an die Nachverfolgbarkeit und Nichtabstreitbarkeit (siehe weiter auch Lektion "[[Computer- und Netzwerksicherheit_-_Kryptograhpie#Kryptographie|Krypotgraphie]]" Unterkapitel 2 - 5).

Ressourcen können dabei alle Komponenten sein, welche einen Zugriff auf Daten ermöglichen oder diese beinhalten, wie beispielsweise: Datenbanken, Tabellen und Dateien. Die Zugriffe können dabei sowohl über lokale Verbindungen, als auch über das Netzwerk/Internet oder unterschiedliche Datenträger erfolgen.

=== Identifikation ===

Die Identifikation bezeichnet die Benennung eines bestimmten Systems oder einer Person, welche auf ein System zugreifen möchte. Dabei ist weder sichergestellt durch wen diese Benennung erfolgt ist, noch ob es sich bei der Benennung tatsächlich um das benannte System oder die benannte Person handelt.

Zur Identifikation dienen oft die eindeutige User-ID, die E-Mailadresse oder der Name.

Ein Beispiel ist eine Anwesenheitsliste: Die Protokollführung schreibt die Namen der anwesenden Personen auf, welche diese wiederum identifizieren. Dabei ist jedoch noch nicht sichergestellt, ob die jeweiligen Personen tatsächlich die sind, die sie vorgeben zu sein. Im schlechtesten Fall sind sie der Protokollführung nicht bekannt und identifizieren sich durch Nennung ihres Namens.

=== Authentifikation ===

Die eindeutige Identifikation einer Person oder eines Systems wird als Authentifikation bezeichnet. Erst dadurch wird sichergestellt, dass es sich dabei tatsächlich um die Identifizierten handelt.

Es gibt drei unterschiedliche Kategorien von Authentifikationsmethoden und -merkmale:

* '''Wissen''' (was jemand weiß),
* '''Besitz''' (was jemand besitzt) und
* '''Biometrie''' (was jemand ist).
Die drei Merkmale Wissen, Besitz und Biometrie werden oft auch als „Wissen, Haben und Sein“ bezeichnet.

Eine häufig eingesetzte Methode ist das Passwort. Dieses ist in der Kategorie des '''Wissens''' eingeordnet, da es von jedem eingesetzt werden kann, der es kennt. Es kann daher auch weitergegeben oder ausgespäht werden. Je komplexer es ist, desto leichter kann es auch vergessen werden. Je häufiger es verwendet wird, desto schneller kann es herausgefunden werden. Zu komplexe Passwörter sind daher keine gute Lösung zur sicheren Authentifikation, da sie von vielen Usern vergessen oder aufgeschrieben werden. Dasselbe gilt für zu einfache Passwörter, da sie leicht erraten werden können.

Beim Merkmal des '''Besitzes''' wird die Authentifikation über etwas erreicht, dass nur der zu Authentifizierende besitzt. Beispiele dafür sind ein Personalausweis oder eine Chipkarte (z.B. eine Bankomatkarte). Damit die Weitergabe dieses Merkmals überhaupt nicht, oder nur sehr schwierig möglich ist, sollte es möglichst nicht vervielfältigt werden können.

Unter '''Biometrie''' werden Merkmale verstanden, die an eine bestimmte Person (oder ein bestimmtes System) gebunden sind. Sie sind öffentlich sichtbar oder beobachtbar, jedoch nicht leicht duplizierbar. Häufig bekannte Beispiele für biometrische Merkmale sind Fingerabdrücke, Venenmuster, die Iris-Muster der Augen und Stimmmuster. Weitere, oft weniger bekannte, Merkmale sind jedoch auch die Art des Ganges einer Person, ihre Tastenanschläge, ihr Schreibstil und aber auch die Art und Weise wie sie sich innerhalb eines Programmes oder einer Webseite bewegen.

Je nach Sicherheitsanforderungen können dabei auch mehrere Merkmale kombiniert werden um die Authentifizierungsqualität noch weiter zu verstärken. Ein bekanntes Beispiel dafür ist die zur Bargeldbehebung mittels Bankomatkarte notwendige Authentifizierung. Dabei wird ein Besitzmerkmal (Bankomatkarte) mit einem Wissensmerkmal (PIN-Code) kombiniert. Ist jemand im Besitz der Karte, benötigt er zusätzlich noch den PIN-Code und umgekehrt. Mit einem der beiden Merkmale allein kann keine gültige Authentifikation erfolgen und damit auch kein Geld behoben werden.

Werden zwei Merkmale kombiniert, wird dies auch als '''Zwei-Faktor-Authentifizierung''' bezeichnet. Wichtig ist dabei immer, dass zwei Merkmale unterschiedlicher Kategorien (Wissen, Besitz und Biometrie) kombiniert werden. Die Kombination zweier Merkmale derselben Kategorie, erhöht zwar die Sicherheit, gilt dabei jedoch nicht als Zwei-Faktor-Authentifizierung. Die einzelnen Merkmalskategorien und die sich daraus ergebenen Authentifizierungslevel sind weiter in Abbildung "Authentifizierungsfaktoren: Wissen, Besitz und Biometrie" dargestellt.

Ob die Authentifizierungsqualität durch den Einsatz von drei Faktoren weiter stark erhöht werden kann, ist umstritten. Dies ist stark von den jeweils eingesetzten Techniken, aber auch von deren Akzeptanz bei den Anwendern, abhängig.

[[Datei:IT244 15.png|300px|none|thumb| Authentifizierungsfaktoren: Wissen, Besitz und Biometrie]]


=== Autorisation ===

Bei der Autorisation handelt es sich um die Berechtigung, die eine authentifizierte Person oder ein authentifiziertes System für einen bestimmten Zugriff hat. So können in einem System beispielsweise unterschiedliche Rollen existieren, welche wiederum unterschiedliche Zugriffe ermöglichen. Wie ein System unterschiedliche Autorisationen verwaltet und behandelt wird als [[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Zugriffssteuerungsmodelle|Zugriffssteuerungsmodell]] bezeichnet.

Die Authentifikation stellt damit sicher, dass es sich um jemand bestimmten handelt und die Autorisation regelt wiederum welche bestimmten Rollen welche Zugriffe bekommen.

=== Nachverfolgbarkeit und Nichtabstreitbarkeit ===

Bei der Nachverfolgbarkeit und Nichtabstreitbarkeit handelt es sich um Zugriffsmerkmale, welche eine genaue Dokumentation der jeweiligen Systemkommunikation ermöglichen. Je nach Anforderung wird dabei dokumentiert, welche Zugriffe stattgefunden haben und unter welchen (Sicherheits-)Parametern diese aufgebaut wurden. Um eine lückenlose Nachverfolgbarkeit sicherzustellen, ist es erforderlich, den Erfolg der Authentifikation und die erteilte Autorisation zu dokumentieren.

In manchen Fällen ist es weiter erforderlich eine Nichtabstreitbarkeit von Zugriffen zu ermöglichen. Als '''Nichtabstreitbarkeit''' wird bezeichnet, das eine Person die Erstellung einer gesendeten Nachricht nicht mehr abstreiten kann. Dies beinhaltet auch automatisch die Integrität der Nachricht. Es muss daher für eine Nichtabstreitbarkeit auch sichergestellt sein, dass die Nachricht nicht mehr verändert wurde, da anderenfalls der Absender behaupten könnte, ursprünglich eine andere Nachricht erstellt zu haben.

Die Nichtabstreitbarkeit kann mit Hilfe asymmetrischer Kryptographie Methoden sichergestellt werden (siehe Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie"). Dabei wird der Hashwert einer Nachricht mit dem privaten Schlüssel des Absenders verschlüsselt. Zur Prüfung der Integrität (ob die Nachricht der abgesendeten Nachricht entspricht), muss nun nur noch der verschlüsselte Hashwert mit dem öffentlichen Schlüssel entschlüsselt und mit dem aktuellen Hashwert der Nachricht verglichen werden. Da die Verschlüsselung nur vom Besitzer des privaten Schlüssels durchgeführt werden kann, ist hier eine Nichtabstreitbarkeit gewährleistet.

=== Zugriffssteuerungsmodelle ===

Zugriffssteuerungsmodelle (Access Control Models) regeln die Art und Weise von Zugriffen. Sie definieren dabei die möglichen Regeln und Ziele der Zugriffe und stellen diese den jeweiligen Zugriffssteuerungstechnologien zur Verfügung. Die Modelle sind ein wesentlicher Bestandteil des jeweiligen Betriebssystems, da sie grundlegende Entscheidungen der internen Zugriffe beeinflussen. Sie sind daher direkt im Kern des Betriebssystems integriert. [Ha13, 219]

Es wird zwischen drei verschiedenen Kategorien von Zugriffssteuerungsmodellen unterschieden:

* Eigner-definierte Zugriffssteuerung (DAC: Discretionary Access Control),
* Obligatorische Zugriffssteuerung (MAC: Mandatory Access Control) und
* Rollenbasierte Zugriffssteuerung (RBAC: Role Based Access Control).
Da eine gleichzeitige Unterstützung mehrerer Modelle meist nicht sinnvoll realisierbar ist, ist die Modellauswahl eine grundlegende Entscheidung für das IT-System. Das am häufigsten anzutreffende Modell ist das der Eigner-definierten Zugriffssteuerung.

'''Eigner-definierte Zugriffssteuerung'''

Bei der Eigner-definierten Zugriffssteuerung haben alle Daten einen definierten Eigner (oft auch als Besitzer bezeichnet). Dieser ist fest mit den Daten oder der Datei verbunden. Der Eigner definiert, welche Personen oder Systeme Zugriff auf die Daten erhalten und in welcher Form (z.B.: lesen, schreiben, ändern, ausführen oder verweigern).

Die Zugriffsberechtigungen sind dabei meist über Access Control Lists (ACL‘s) definiert. Dabei handelt es sich um eine Auflistung aller Berechtigten und der jeweils zugeordneten Rechte.

Dieses Modell ist in aktuellen Windows-, Linux- und Mac-Systemen anzutreffen. In diesen Systemen hat jede Datei einen Besitzer und eine entsprechende ACL zugeordnet.

Einzelne User und Systeme können hier meist in Berechtigungsgruppen zusammengefasst werden. In diesem Fall können die ACL’s sowohl Zuordnungen einzelner User und Systeme, als auch Berechtigungsgruppen enthalten.

'''Obligatorische Zugriffssteuerung'''

Die obligatorische Zugriffssteuerung findet ihre Anwendung in Bereichen mit sehr hohem Sicherheitsbedarf. Sie kommt daher meist in behördlichen und militärischen Systemen zum Einsatz.

In diesem Modell ist keine individuelle Behandlung einzelner User und Dateien vorgesehen. Der Zugriff ist abhängig von unterschiedlichen Sicherheitsstufen, auf denen sich Daten und User befinden. Meist ist dabei eine Änderung von Dateiberechtigungen durch die User nicht möglich.

Die Umsetzung der Sicherheitsstufen erfolgt durch Vertrauens-Levels (Clearance) für User und Sensitivitäts-Labels für Dateien. Mögliche Sicherheitsstufen wären z.B.: nicht vertraulich, vertraulich, geheim und streng geheim.

Der Zugriff auf Daten erfolgt gemäß den jeweiligen Sicherheitsstufen. Sind die Stufe der Datei und die Stufe des Users ident, darf er auf die Daten zugreifen. Ob er auf Daten von darunterliegenden Stufen zugreifen darf, kann unterschiedlich implementiert sein. Meist dürfen Informationen nur von niedrigeren Levels zu höheren Levels übertragen werden und nicht umgekehrt. Zugriffe zwischen unterschiedlichen Levels werden dabei meist auch von eigenen Überwachungsdienstprogrammen gesteuert und genehmigt.

Zusätzlich werden meist hierarchische Zuordnungen vergeben, in denen sich sowohl Daten, als auch User befinden können. Die hierarchische Zuordnung steht dann nochmals über der Zuordnung des Sicherheitslevels. Damit ist sichergestellt, dass die Zugriffe nicht nur gemäß des Vertrauens-Levels, sondern auch gemäß der Zugriffs-Notwendigkeit erfolgen. Befindet sich ein User nicht in derselben hierarchischen Zuordnung, wie die jeweiligen Daten, wird davon ausgegangen, dass er keinen Zugriff benötigt und der Zugriff daher verweigert.

Ein frei verfügbares Betriebssystem, welches das Modell der obligatorischen Zugriffssteuerung einsetzt, ist beispielsweise SE Linux [Na09].

'''Rollenbasierte Zugriffssteuerung'''

Bei der rollenbasierten Zugriffssteuerung werden Organisationsrichtlinien und -abläufe in ein Zugriffsmodell übersetzt. Dabei werden einzelnen Usern oder Systemen bestimmte (Organisations-)Rollen zugeordnet. Der Zugriff auf Daten hängt dabei von der jeweiligen Rolle des Zugreifenden ab. Die Berechtigung wird bei jedem Zugriffsversuch überprüft und dann genehmigt oder abgewiesen.

Bei den hier eingesetzten Rollen handelt es sich nicht um Gruppen im Sinne der Eigner-definierten Zugriffssteuerung, sondern um Rollen innerhalb des jeweiligen Geschäftsprozesses bzw. einer Organisationseinheit. So kann ein User eine Rolle haben, die ihm aus einer Anwendung heraus Zugriff auf einen Datensatz gestattet und aus einer anderen Anwendung nicht mehr, obwohl es sich um denselben Datensatz handelt. Wichtig ist dabei immer die Betrachtung des aktuellen Zwecks des Zugriffes.

Die Implementierung rollenbasierter Zugriffssteuerungen ist daher auch komplexer als die der Eigner-definierten Zugriffssteuerung.

== Passwortsicherheit ==

Wie bereits in der Lektion zu [[Computer- und_Netzwerksicherheit_-_Kryptograhpie|Kyptographie]] beschrieben, hat die sichere Speicherung von Passwörtern eine hohe Priorität und sollte in einer entsprechend sicheren Architektur erfolgen. Zusätzlich zur technischen Sicherheit ist eine entsprechende '''Passwortkomplexität von besonderer Relevanz'''. Ein noch so effizient abgesicherter Passwortspeicher verliert an Bedeutung, wenn das darin gespeicherte Passwort selbst unsicher ist.

Ein unsicheres Passwort hat entweder:

* eine zu geringe '''Komplexität''' und kann daher durch [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Bruteforce]]- oder [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Hash-Kollisions-Angriffe]] gefunden werden, oder
* kann durch '''[[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]''' herausgefunden werden (z.B.: Name des Kindes mit Jahreszahl, Anfangsbuchstaben des Titels des Lieblingsliedes, usw.).
Die Komplexität eines Passwortes ergibt sich aus der '''Entropie''' – also den möglichen unterschiedlichen Kombinationen bzw. dem [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Schl%C3%BCssel_(Key)_und_Keyspace|Keyspace]]. Daraus und an der Anzahl an Passwörtern, welche pro Sekunde geprüft werden können, ergibt sich dann wiederum die Dauer, in welcher das Passwort durch Ausprobieren (Bruteforce-Angriff) gefunden werden kann.

Für die Komplexität von Passwörter galt lange eine bestimmte Mindestlänge (meist 8 Zeichen) und eine Kombination aus den Merkmalen:

* Kleinbuchstaben,
* Großbuchstaben,
* Ziffern und
* Sonderzeichen
als ausreichender Schutz.

Beispielsweise ein Passwort '''„''f9D22+P#''“''' mit 8 Zeichen und Erfüllung aller oben genannten Kriterien hat somit folgende Komplexität:

* 26 Kleinbuchstaben +
* 26 Großbuchstaben +
* 10 Ziffern +
* 36 Sonderzeichen (alle Sonderzeichen der deutschen Tastatur)
* '''= 98 Mögliche Zeichen pro Stelle'''.
* '''Bei 8 Zeichen sind das 98^8 Mögliche Passortkombinationen.'''
Ein Hochleistungs-PC, welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''23 Tage''' um das Passwort herauszufinden.

Ein Problem solcher komplexen Passwörter ist, dass es für die meisten User schwierig ist, sie sich zu einzuprägen. Dadurch besteht ein erhöhtes Risiko, dass die Passwörter:

* vergessen werden,
* auf einem Zettel notiert werden,
* nicht ausreichend oft geändert werden oder
* nur minimal geändert werden – beispielsweise durch simple Variation einzelner Teile des Passwortes, wie einer Ziffer am Ende.
Aufgrund der oben genannten Schwächen und der dennoch geringen Entropie noch gut merkbarer Passwortlängen, können diese Passwortrichtlinien '''nicht mehr als Stand der Technik''' betrachtet werden. Eine wesentlich bessere Möglichkeit ist die Nutzung von zufälligen Wörtern aus dem Wörterbuch. [Ga17]

Bei der Nutzung von '''vier zufälligen Wörtern aus dem Wörterbuch''' (kein Satz, sondern tatsächlich zufällig gewählte Wörter), ergibt sich bei Nutzung der 100.000 unterschiedlichen Wörter des Österreichischen Wörterbuchs [AF20] folgende Komplexität:

* '''100.000 mögliche Wörter pro „Stelle“ (ein Wort ist somit eine Stelle).'''
* '''Bei 4 Wörtern sind das 100.000^4 Mögliche Passwortkombinationen.'''
Ein Hochleistungs-PC (der selbe PC wie im ersten Beispiel), welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''738 Jahre''' um das Passwort herauszufinden.

Ein Beispiel für ein Passwort aus 4 unzusammenhängenden Wörtern aus dem deutschen Duden ist: '''„''Dachs faul logisch Gerät''“'''.

Das Passwort weißt somit eine '''wesentlich höhere Entropie''' auf und ist für einen Menschen gleichzeitig '''leichter merkbar'''.

Leider ist diese Form der Passwörter in '''vielen Systemen noch nicht implementiert''' und es werden noch die veralteten Komplexitätsmerkmale des ersten Beispiels abgerufen. Diese Hürde kann ganz einfach überwunden werden, indem am Ende des Passworts eine Ziffer und ein Sonderzeichen gestellt werden. Da diese keine wirkliche Relevanz für die genannte Passwortsicherheit haben, können hier auch Zeichen genutzt werden, die schnell zu tippen sind. Das oben genannte Passwort könnte damit dann einfach '''''„Dachs faul logisch Gerät 9+“''''' lauten.

== Zertifikate ==

Zertifikate dienen der Feststellung der Identitäten von Personen und Systemen auf digitalem Wege. Ein Zertifikat ist ein digitales Dokument, indem bestimmte Daten angegeben sind, welche eine Person oder ein System und optional auch zugehörige Eigenschaften identifizieren. Zertifikate sind wesentliche Bestandteile von Public-Key-Systemen und enthalten zusätzlich den jeweiligen Public-Key des Zertifikatsinhabers (siehe auch Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie").

Um die Echtheit eines Zertifikats zu bestätigen, kann dieses von anderen Stellen signiert werden. Diese Stellen werden als '''Zertifizierungsstellen (CA: Certification Authority)''' bezeichnet. Die Signatur erfolgt dabei, wie in Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" beschrieben, durch hashen des Zertifikates und Verschlüsselung des Hashwertes durch den privaten Schlüssel der Zertifizierungsstelle. Da der öffentliche Schlüssel – wiederum durch das Zertifikat der Zertifizierungsstelle – bekannt ist, kann der Hashwert korrekt entschlüsselt, und die Signatur damit als gültig erkannt, werden.

Ob diese Echtheitsbestätigungen nun '''hierarchisch''' erfolgen ([[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Public-Key-Infrastruktur_(PKI)|Public-Key-Infrastruktur]]), oder über ein dezentral '''verteiltes Vertrauensmodell''' ([[Computer- und Netzwerksicherheit_-_Zugriffssteuerung#Web_of_Trust_(WOT)|Web of Trust]]) ist von der jeweiligen Implementierung abhängig. Derzeit sind beide Modellvarianten im Einsatz und finden ihre Anwendung in einer Vielzahl von Systemen. Die Zertifikate der behördlich akzeptierten digitalen Signaturen basieren derzeit auf dem hierarchischen Modell der Public-Key-Infrastruktur.

Ein Zertifikat ist mit einem Ausweisdokument vergleichbar. Auf dem Ausweis befinden sich die Daten der Person und ein Verweis auf den Aussteller. Durch Sicherheitsmerkmale am Dokument (Wasserzeichen, Silberstreifen,…) wird dabei die Echtheitsprüfung ermöglicht. Der Aussteller (z.B. eine Behörde) bestätigt damit die Identität des Inhabers (z.B. Personalausweis) und gegebenenfalls auch bestimmte durch das Dokument erlaubte Tätigkeiten (z.B. Führerschein).

Die Echtheit eines Zertifikates kann von der jeweiligen Zertifizierungsstelle auch wieder zurückgezogen werden. Zu diesem Zweck werden '''Zertifikats-Sperrlisten (CRL: Certificate Revocation Lists)''' eingesetzt, welche Einträge der Seriennummern aller Zertifikate mit zurückgenommenen Echtheitsbestätigungen enthält. Die Sperrliste ist selbst wiederum von der jeweiligen Zertifizierungsstelle signiert, um ihre Echtheit zu bestätigen.

Der Aufbau und der mögliche Inhalt eines Zertifikates ist im '''X.509 Standard''' [Ne99] definiert. Ein entsprechendes Beispiel (das aktuelle Zertifikat des Online-Campus) ist in Abbildung "Zertifikat" dargestellt.

[[Datei:IT244 16.png|300px|none|thumb|Zertifikat]]


=== Public-Key-Infrastruktur (PKI) ===

Bei der Public-Key-Infrastruktur (PKI) handelt es sich um ein hierarchisch aufgebautes System von Zertifizierungsstellen. Das bedeutet, dass jede Zertifizierungsstelle das in sie gesetzte Vertrauen an nachfolgende Stellen weiterverteilen kann, indem sie die zugehörigen Zertifikate signiert.

Daraus ergibt sich dann eine Hierarchie aus mehreren Zertifikaten, die bis zu einem Stammzertifikat rückverfolgt werden können sind. Durch das Vertrauen in das jeweilige Stammzertifikat wird auch den nachfolgenden Zertifikaten vertraut.

In den meisten Anwendungen, die PKI Zertifikate einsetzen (z.B. Internetbrowser für HTTPS Verbindungen), sind bereits einige gängige Stammzertifikate der großen Zertifizierungsstellen vorinstalliert. Es ist jedoch meist auch möglich weitere Stammzertifikate hinzuzufügen, denen dann ebenfalls vertraut wird. In Abbildung "Zertifizierungspfad" ist die Hierarchie des Zertifikates des Online-Campus dargestellt. Die Stammzertifizierungsstelle ist in diesem Fall das Unternehmen Go Daddy.

[[Datei:IT244 17.png|300px|none|thumb|Zertifizierungspfad]]


Zusätzlich zu den Zertifizierungsstellen gibt es in der PKI noch weitere Instanzen, welche hautsächlich für den Zertifizierungsprozess verantwortlich sind. Die Hauptakteure der PKI sind:

* Zertifizierungsstelle (CA: Certification Authority),
* Registrierungsstelle (RA: Registration Authority) und
* Validierungsdienst (VA: Validation Authority)
Die '''Registrierungsstelle''' ist in der PKI dafür verantwortlich die Identität des Antragsstellers zu überprüfen und dies wiederum der Zertifizierungsstelle mitzuteilen. Die '''Validierungsstelle''' ist für die Gültigkeitsprüfung von bereits ausgestellten Zertifikaten verantwortlich. Sie verwaltet auch die Zertifikats-Sperrlisten und ihre Erreichbarkeit ist meist in einem Datenfeld in den Zertifikaten selbst angegeben.

Soll nun ein neues Zertifikat ausgestellt werden, muss folgender '''Zertifizierungsprozess''' durchlaufen werden:

# Der Antrag für das neue Zertifikat wird an die Registrierungsstelle (RA) geschickt
# Die Registrierungsstelle (RA) überprüft den Antrag und stellt sicher, dass es sich bei der Identität tatsächlich um die der antragstellenden Person oder des zugehörigen IT-Systems (z.B. bei einem Webserver-Zertifikat) handelt.
# Wenn die Registrierungsstelle die Identität bestätigen kann, sendet sie den Antrag weiter an die Zertifizierungsstelle (CA).
# Die Zertifizierungsstelle (CA) stellt nun das beantragte Zertifikat aus, generiert dafür einen privaten und einen öffentlichen Schlüssel und sendet diese an die antragsstellende Person.
Oft ist es auch möglich das Schlüsselpaar selbst zu generieren und dem Antrag nur den öffentlichen Schlüssel beizufügen. Dies ist für die Ausstellung des Zertifikates ausreichend, da der private Schlüssel für seine Signierung nicht benötigt wird (diese wird durch den privaten Schlüssel der CA durchgeführt). In diesem Fall ist zusätzlich sichergestellt, dass der private Schlüssel nur der antragsstellenden Person bekannt ist.

Gerade bei der Überprüfung durch die Registrierungsstelle gibt es unterschiedliche Qualitäten. Wird hier ungenau vorgegangen, kann dies zu Zertifikaten falscher Identitäten führen.

=== Web of Trust (WOT) ===

Das Modell des Web of Trust ist im Gegensatz zur PKI nicht hierarchisch, sondern dezentral aufgebaut. Es basiert auf einer dezentralen Vertrauensverteilung zwischen den Teilnehmern, ähnlich dem Freundes- und Bekanntenkreis einer Person. Die Schlüssel sind dabei nicht in einer hierarchischen Struktur zentral abrufbar und überprüfbar, sondern werden direkt von den Benutzern verwaltet. Jeder User hat seinen eigenen Schlüsselbund, wobei hier zwischen dem privaten und dem öffentlichen Schlüsselbund unterschieden wird.

Am '''privaten Schlüsselbund''' befinden sich die privaten Schlüssel des Users, mit denen Daten signiert und entschlüsselt werden können. Am '''öffentlichen Schlüsselbund''' befinden sich die eigenen öffentlichen Schlüssel, sowie die öffentlichen Schlüssel anderer User. Mit den öffentlichen Schlüsseln können Nachrichten verschlüsselt und Signaturen geprüft werden.

Die Vertrauensstufen werden über die öffentlichen Schlüssel der Teilnehmer ermittelt. Dazu gibt es im öffentlichen Schlüsselbund für jeden Schlüssel ein '''Key Legimitation Field''', in dem der jeweilige '''Vertrauensgrad (Owner Trust)''' des Schlüssels angegeben wird.

Im WOT gibt es folgende Vertrauensgrade:

* unknown: Personen über die keine Informationen bekannt sind,
* not trusted: Personen denen nicht vertraut wird,
* marginal: Personen denen nicht voll vertraut wird,
* complete: Personen denen voll vertraut wird und
* ultimate: eigener öffentlicher Schlüssel.
Wer als vertrauenswürdig eingestuft wird, liegt somit beim jeweiligen Schlüsselbund Inhaber.

Die Vertrauensgrade können an andere User (z.B. über einen Schlüsselserver) weitergegeben werden, indem die jeweiligen Schlüssel durch den eigenen privaten Schlüssel signiert werden. Dies wird auch als '''indirekte Zertifizierung''' bezeichnet.

Ist dem User, der einen dritten Schlüssel signiert hat, im eigenen Schlüsselbund einem Vertrauensgrad zugewiesen, so erhält der von ihm signierte Schlüssel je nach eigener Einstellung denselben Vertrauensgrad oder niedriger. Zusätzlich kann definiert werden, wie viele signierte Schlüssel eines niedrigeren Vertrauensgrades notwendig sind, um die Vertrauensstufe um eine Stufe aufzuwerten. Die Standartwerte hierfür sind 3 signierte Schlüssel anderer User für die Aufwertung und ein signierter Schlüssel eines anderen Users für dieselbe Stufe.

Diese Abhängigkeiten sind in Abbildung "Web of Trust - Vertrauensnetzwerk" ersichtlich: Peter kennt sowohl Anna, als auch Christoph persönlich und hat daher ihre öffentlichen Schlüssel in seinem öffentlichen Schlüsselbund abgelegt. Christoph hat nur eine direkte Beziehung zu Anna, nicht aber zu Peter. Da sich Christophs öffentlicher Schlüssel im öffentlichen Schlüsselbund von Anna befindet, erkennt Peter sein Zertifikat als gültig an.

[[file:img1643193688517.png|300px|alt=Web of Trust - Vertrauensnetzwerk|none|thumb|Web of Trust - Vertrauensnetzwerk]]

Die erste Implementierung des WOT war '''Pretty Good Privacy (PGP)''' [Sy15]. Es ist ein Softwarepaket, welches die Sicherstellung der Authentizität, Integrität und Vertraulichkeit von E-Mails sowie beliebiger Dateien ermöglicht. '''GnuPG''' [Gn15] ist die frei verfügbare Version, die unter der GNU General Public License [Fr07] steht. Ein möglicher Windows Client für GnuPG ist beispielsweise Gpg4win [In15b].

=== Neue Zertifikatsmodelle und Erweiterungen ===

Sowohl im Bereich des PKI, als auch im WOT Modell, gibt es mittlerweile einige bekannte Sicherheitslücken und Protokollfehler. Weiter ist gerade im PKI Modell die Rolle der CA enorm wichtig. Werden hier nur schlechte Identitätskontrollen bei der Ausstellung von Zertifikaten durchgeführt, kann es zu falschen validen Identitäten kommen. Im Bereich des WOT können beispielsweise die Schlüsselserver zum Generieren von SPAM-Versandlisten genutzt werden, da die zugehörigen E-Mailadressen der Zertifikate dort frei verfügbar sein müssen. Weiter sind über die WOT soziale Netzwerke der User analysierbar, da die Trustlevel und ihre Abhängigkeiten leicht analysiert werden können. [Br14]

Um diese Schwachstellen zu beseitigen wird bereits an möglichen neuen Protokollen und Erweiterungen geforscht. Den meisten Ansätzen gemein ist, die Abhängigkeit von einzelnen CA’s zu verringern. Fehler einer CA sollen möglichst auf Seite der Endanwendung (wie z.B. im Browser oder Mail Client) frühzeitig erkannt und angezeigt werden. [Br14]

Einer dieser neuen Ansätze ist die Software ''Perspectives'' [Ca15]. Dabei handelt es sich um eine Browsererweiterung, die jedes Zertifikat zusätzlich mit einem sogenannten Notary-Server abgleicht. Damit können beispielsweise Man-in-the-Middle Angriffe frühzeitig erkannt werden.

Weitere aktuelle Erweiterungen sind [Br14]:

* Pinning [EPS14],
* Certificate Transparency [LLK13],
* Microsoft SmartScreen [Mi15] und
* DANE [HVS12].

== Angriffsvektoren der Access Control ==

Die Angriffsmethoden der Access Control sind sehr vielfältig und haben oft [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffsvektoren_der_Kryptographie|Angriffsvektoren der Kryptographie]] und [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Angriffsvektoren_der_Daten%C3%BCbertragung|Datenübertragung]], sowie [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]als Grundlage. Dies trifft insbesondere auf Angriffe gegen die Integrität und Authentizität zu.

Dazu bereits behandelte Angriffsvektoren sind:

* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Brute-Force Angriffe]],
* [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Phishing|Phishing]] und
* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Angriffe gegen Hashwerte]].
Eine weitere wichtige Angriffsmethode ist die des '''Pharming.''' Dabei wird die Anfrage eines Users auf einen bösartigen Server umgeleitet. Er glaubt sich sicher und gibt dann dort seine geheimen Daten ( wie z.B.: Zugangsdaten und Transaktionsdaten) preis. Beim Pharming handelt es sich daher um einen [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Man-in-the-Middle_Angriff|Man-in-the-Middle Angriff]].

== Wiederholungsaufgaben/Übungen ==

'''1 Was ist der Unterschied zwischen Identifikation, Authentifikation und Autorisation?'''

'''2 Was ist eine Zwei-Faktor-Authentifikation?'''

'''3 Welche drei Zugriffssteuerungsmodelle gibt es?'''

'''4 Erklären Sie das Modell der Eigner-definierten Zugriffssteuerung.'''

'''5 Was sind Zertifikate und die damit verbundenen Vertrauensmodelle?'''

'''6 Was bedeutet PKI und wer sind ihre Hauptakteure? Wie hängen diese Akteure zusammen?'''

'''7 Eine Passwortrichtlinie fordert ein Passwort, bestehend aus Kleinbuchstaben, Großbuchstaben und Ziffern mit einer Länge von 10 Zeichen. Wie wird die Komplexität des Passworts berechnet (wie viele mögliche Passwörter gibt es)?'''

Computer- und Netzwerksicherheit - Zugriffssteuerung

2022-04-03T08:03:57Z

VÖLKL Peter:

= Zugriffssteuerung =

Die Zugriffssteuerung (Access Control) regelt den Zugriff und die Kommunikation von IT-Systemen mit ihren Anwendern, Ressourcen und anderen IT-Systemen. Es handelt sich dabei um eine zentrales Element der meisten IT-Systeme, da davon alle Schutzziele (Vertraulichkeit, Integrität und Verfügbarkeit; siehe Lektion "[[Computer- und Netzwerksicherheit_-_Grundlagen#S%C3%A4ulen_der_Informationssicherheit_-_CIA_Triade|Säulen der Informationssicherheit - CIA Triade]]") betroffen sein können.

In dieser Lektion werden die grundlegenden Begriffe der Zugriffssteuerung erläutert und weiter die konkreten Techniken der Zertifikate und der Fernzugriffe sowie potentielle Angriffsvektoren näher behandelt.

== Grundbegriffe der Zugriffssteuerung ==

Um die Schutzziele der Vertraulichkeit, Integrität und Verfügbarkeit des Datenaustausches mit IT-Systemen gewährleisten zu können müssen die jeweiligen Anforderungen an die Kommunikation definiert werden. Dabei gibt es einige wesentliche Begriffe, welche oft auch von Technikern falsch verwendet werden. Beispielsweise werden ''Identifikation'', ''Authentifikation'' und ''Autorisation'' manchmal fälschlicherweise als Akronyme verwendet, obwohl es sich dabei um grundlegend unterschiedliche Begriffe handelt. Auch ist es wichtig zu wissen, wie bestimmte Anforderungen an die Zugriffssteuerung implementiert werden können.

=== Zugriff ===

Beim Zugriff handelt es sich um die Kommunikation mit einem IT-System. Diese kann sowohl mit einem Anwender, als auch mit einem anderen IT-System oder seiner Ressourcen stattfinden. In den meisten Fällen gibt es dabei Anforderungen an Identifikation, Authentifikation und Autorisation, sowie an die Nachverfolgbarkeit und Nichtabstreitbarkeit (siehe weiter auch Lektion "[[Computer- und Netzwerksicherheit_-_Kryptograhpie#Kryptographie|Krypotgraphie]]" Unterkapitel 2 - 5).

Ressourcen können dabei alle Komponenten sein, welche einen Zugriff auf Daten ermöglichen oder diese beinhalten, wie beispielsweise: Datenbanken, Tabellen und Dateien. Die Zugriffe können dabei sowohl über lokale Verbindungen, als auch über das Netzwerk/Internet oder unterschiedliche Datenträger erfolgen.

=== Identifikation ===

Die Identifikation bezeichnet die Benennung eines bestimmten Systems oder einer Person, welche auf ein System zugreifen möchte. Dabei ist weder sichergestellt durch wen diese Benennung erfolgt ist, noch ob es sich bei der Benennung tatsächlich um das benannte System oder die benannte Person handelt.

Zur Identifikation dienen oft die eindeutige User-ID, die E-Mailadresse oder der Name.

Ein Beispiel ist eine Anwesenheitsliste: Die Protokollführung schreibt die Namen der anwesenden Personen auf, welche diese wiederum identifizieren. Dabei ist jedoch noch nicht sichergestellt, ob die jeweiligen Personen tatsächlich die sind, die sie vorgeben zu sein. Im schlechtesten Fall sind sie der Protokollführung nicht bekannt und identifizieren sich durch Nennung ihres Namens.

=== Authentifikation ===

Die eindeutige Identifikation einer Person oder eines Systems wird als Authentifikation bezeichnet. Erst dadurch wird sichergestellt, dass es sich dabei tatsächlich um die Identifizierten handelt.

Es gibt drei unterschiedliche Kategorien von Authentifikationsmethoden und -merkmale:

* '''Wissen''' (was jemand weiß),
* '''Besitz''' (was jemand besitzt) und
* '''Biometrie''' (was jemand ist).
Die drei Merkmale Wissen, Besitz und Biometrie werden oft auch als „Wissen, Haben und Sein“ bezeichnet.

Eine häufig eingesetzte Methode ist das Passwort. Dieses ist in der Kategorie des '''Wissens''' eingeordnet, da es von jedem eingesetzt werden kann, der es kennt. Es kann daher auch weitergegeben oder ausgespäht werden. Je komplexer es ist, desto leichter kann es auch vergessen werden. Je häufiger es verwendet wird, desto schneller kann es herausgefunden werden. Zu komplexe Passwörter sind daher keine gute Lösung zur sicheren Authentifikation, da sie von vielen Usern vergessen oder aufgeschrieben werden. Dasselbe gilt für zu einfache Passwörter, da sie leicht erraten werden können.

Beim Merkmal des '''Besitzes''' wird die Authentifikation über etwas erreicht, dass nur der zu Authentifizierende besitzt. Beispiele dafür sind ein Personalausweis oder eine Chipkarte (z.B. eine Bankomatkarte). Damit die Weitergabe dieses Merkmals überhaupt nicht, oder nur sehr schwierig möglich ist, sollte es möglichst nicht vervielfältigt werden können.

Unter '''Biometrie''' werden Merkmale verstanden, die an eine bestimmte Person (oder ein bestimmtes System) gebunden sind. Sie sind öffentlich sichtbar oder beobachtbar, jedoch nicht leicht duplizierbar. Häufig bekannte Beispiele für biometrische Merkmale sind Fingerabdrücke, Venenmuster, die Iris-Muster der Augen und Stimmmuster. Weitere, oft weniger bekannte, Merkmale sind jedoch auch die Art des Ganges einer Person, ihre Tastenanschläge, ihr Schreibstil und aber auch die Art und Weise wie sie sich innerhalb eines Programmes oder einer Webseite bewegen.

Je nach Sicherheitsanforderungen können dabei auch mehrere Merkmale kombiniert werden um die Authentifizierungsqualität noch weiter zu verstärken. Ein bekanntes Beispiel dafür ist die zur Bargeldbehebung mittels Bankomatkarte notwendige Authentifizierung. Dabei wird ein Besitzmerkmal (Bankomatkarte) mit einem Wissensmerkmal (PIN-Code) kombiniert. Ist jemand im Besitz der Karte, benötigt er zusätzlich noch den PIN-Code und umgekehrt. Mit einem der beiden Merkmale allein kann keine gültige Authentifikation erfolgen und damit auch kein Geld behoben werden.

Werden zwei Merkmale kombiniert, wird dies auch als '''Zwei-Faktor-Authentifizierung''' bezeichnet. Wichtig ist dabei immer, dass zwei Merkmale unterschiedlicher Kategorien (Wissen, Besitz und Biometrie) kombiniert werden. Die Kombination zweier Merkmale derselben Kategorie, erhöht zwar die Sicherheit, gilt dabei jedoch nicht als Zwei-Faktor-Authentifizierung. Die einzelnen Merkmalskategorien und die sich daraus ergebenen Authentifizierungslevel sind weiter in Abbildung "Authentifizierungsfaktoren: Wissen, Besitz und Biometrie" dargestellt.

Ob die Authentifizierungsqualität durch den Einsatz von drei Faktoren weiter stark erhöht werden kann, ist umstritten. Dies ist stark von den jeweils eingesetzten Techniken, aber auch von deren Akzeptanz bei den Anwendern, abhängig.

[[Datei:IT244 15.png|300px|none|thumb| Authentifizierungsfaktoren: Wissen, Besitz und Biometrie]]


=== Autorisation ===

Bei der Autorisation handelt es sich um die Berechtigung, die eine authentifizierte Person oder ein authentifiziertes System für einen bestimmten Zugriff hat. So können in einem System beispielsweise unterschiedliche Rollen existieren, welche wiederum unterschiedliche Zugriffe ermöglichen. Wie ein System unterschiedliche Autorisationen verwaltet und behandelt wird als [[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Zugriffssteuerungsmodelle|Zugriffssteuerungsmodell]] bezeichnet.

Die Authentifikation stellt damit sicher, dass es sich um jemand bestimmten handelt und die Autorisation regelt wiederum welche bestimmten Rollen welche Zugriffe bekommen.

=== Nachverfolgbarkeit und Nichtabstreitbarkeit ===

Bei der Nachverfolgbarkeit und Nichtabstreitbarkeit handelt es sich um Zugriffsmerkmale, welche eine genaue Dokumentation der jeweiligen Systemkommunikation ermöglichen. Je nach Anforderung wird dabei dokumentiert, welche Zugriffe stattgefunden haben und unter welchen (Sicherheits-)Parametern diese aufgebaut wurden. Um eine lückenlose Nachverfolgbarkeit sicherzustellen, ist es erforderlich, den Erfolg der Authentifikation und die erteilte Autorisation zu dokumentieren.

In manchen Fällen ist es weiter erforderlich eine Nichtabstreitbarkeit von Zugriffen zu ermöglichen. Als '''Nichtabstreitbarkeit''' wird bezeichnet, das eine Person die Erstellung einer gesendeten Nachricht nicht mehr abstreiten kann. Dies beinhaltet auch automatisch die Integrität der Nachricht. Es muss daher für eine Nichtabstreitbarkeit auch sichergestellt sein, dass die Nachricht nicht mehr verändert wurde, da anderenfalls der Absender behaupten könnte, ursprünglich eine andere Nachricht erstellt zu haben.

Die Nichtabstreitbarkeit kann mit Hilfe asymmetrischer Kryptographie Methoden sichergestellt werden (siehe Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie"). Dabei wird der Hashwert einer Nachricht mit dem privaten Schlüssel des Absenders verschlüsselt. Zur Prüfung der Integrität (ob die Nachricht der abgesendeten Nachricht entspricht), muss nun nur noch der verschlüsselte Hashwert mit dem öffentlichen Schlüssel entschlüsselt und mit dem aktuellen Hashwert der Nachricht verglichen werden. Da die Verschlüsselung nur vom Besitzer des privaten Schlüssels durchgeführt werden kann, ist hier eine Nichtabstreitbarkeit gewährleistet.

=== Zugriffssteuerungsmodelle ===

Zugriffssteuerungsmodelle (Access Control Models) regeln die Art und Weise von Zugriffen. Sie definieren dabei die möglichen Regeln und Ziele der Zugriffe und stellen diese den jeweiligen Zugriffssteuerungstechnologien zur Verfügung. Die Modelle sind ein wesentlicher Bestandteil des jeweiligen Betriebssystems, da sie grundlegende Entscheidungen der internen Zugriffe beeinflussen. Sie sind daher direkt im Kern des Betriebssystems integriert. [Ha13, 219]

Es wird zwischen drei verschiedenen Kategorien von Zugriffssteuerungsmodellen unterschieden:

* Eigner-definierte Zugriffssteuerung (DAC: Discretionary Access Control),
* Obligatorische Zugriffssteuerung (MAC: Mandatory Access Control) und
* Rollenbasierte Zugriffssteuerung (RBAC: Role Based Access Control).
Da eine gleichzeitige Unterstützung mehrerer Modelle meist nicht sinnvoll realisierbar ist, ist die Modellauswahl eine grundlegende Entscheidung für das IT-System. Das am häufigsten anzutreffende Modell ist das der Eigner-definierten Zugriffssteuerung.

'''Eigner-definierte Zugriffssteuerung'''

Bei der Eigner-definierten Zugriffssteuerung haben alle Daten einen definierten Eigner (oft auch als Besitzer bezeichnet). Dieser ist fest mit den Daten oder der Datei verbunden. Der Eigner definiert, welche Personen oder Systeme Zugriff auf die Daten erhalten und in welcher Form (z.B.: lesen, schreiben, ändern, ausführen oder verweigern).

Die Zugriffsberechtigungen sind dabei meist über Access Control Lists (ACL‘s) definiert. Dabei handelt es sich um eine Auflistung aller Berechtigten und der jeweils zugeordneten Rechte.

Dieses Modell ist in aktuellen Windows-, Linux- und Mac-Systemen anzutreffen. In diesen Systemen hat jede Datei einen Besitzer und eine entsprechende ACL zugeordnet.

Einzelne User und Systeme können hier meist in Berechtigungsgruppen zusammengefasst werden. In diesem Fall können die ACL’s sowohl Zuordnungen einzelner User und Systeme, als auch Berechtigungsgruppen enthalten.

'''Obligatorische Zugriffssteuerung'''

Die obligatorische Zugriffssteuerung findet ihre Anwendung in Bereichen mit sehr hohem Sicherheitsbedarf. Sie kommt daher meist in behördlichen und militärischen Systemen zum Einsatz.

In diesem Modell ist keine individuelle Behandlung einzelner User und Dateien vorgesehen. Der Zugriff ist abhängig von unterschiedlichen Sicherheitsstufen, auf denen sich Daten und User befinden. Meist ist dabei eine Änderung von Dateiberechtigungen durch die User nicht möglich.

Die Umsetzung der Sicherheitsstufen erfolgt durch Vertrauens-Levels (Clearance) für User und Sensitivitäts-Labels für Dateien. Mögliche Sicherheitsstufen wären z.B.: nicht vertraulich, vertraulich, geheim und streng geheim.

Der Zugriff auf Daten erfolgt gemäß den jeweiligen Sicherheitsstufen. Sind die Stufe der Datei und die Stufe des Users ident, darf er auf die Daten zugreifen. Ob er auf Daten von darunterliegenden Stufen zugreifen darf, kann unterschiedlich implementiert sein. Meist dürfen Informationen nur von niedrigeren Levels zu höheren Levels übertragen werden und nicht umgekehrt. Zugriffe zwischen unterschiedlichen Levels werden dabei meist auch von eigenen Überwachungsdienstprogrammen gesteuert und genehmigt.

Zusätzlich werden meist hierarchische Zuordnungen vergeben, in denen sich sowohl Daten, als auch User befinden können. Die hierarchische Zuordnung steht dann nochmals über der Zuordnung des Sicherheitslevels. Damit ist sichergestellt, dass die Zugriffe nicht nur gemäß des Vertrauens-Levels, sondern auch gemäß der Zugriffs-Notwendigkeit erfolgen. Befindet sich ein User nicht in derselben hierarchischen Zuordnung, wie die jeweiligen Daten, wird davon ausgegangen, dass er keinen Zugriff benötigt und der Zugriff daher verweigert.

Ein frei verfügbares Betriebssystem, welches das Modell der obligatorischen Zugriffssteuerung einsetzt, ist beispielsweise SE Linux [Na09].

'''Rollenbasierte Zugriffssteuerung'''

Bei der rollenbasierten Zugriffssteuerung werden Organisationsrichtlinien und -abläufe in ein Zugriffsmodell übersetzt. Dabei werden einzelnen Usern oder Systemen bestimmte (Organisations-)Rollen zugeordnet. Der Zugriff auf Daten hängt dabei von der jeweiligen Rolle des Zugreifenden ab. Die Berechtigung wird bei jedem Zugriffsversuch überprüft und dann genehmigt oder abgewiesen.

Bei den hier eingesetzten Rollen handelt es sich nicht um Gruppen im Sinne der Eigner-definierten Zugriffssteuerung, sondern um Rollen innerhalb des jeweiligen Geschäftsprozesses bzw. einer Organisationseinheit. So kann ein User eine Rolle haben, die ihm aus einer Anwendung heraus Zugriff auf einen Datensatz gestattet und aus einer anderen Anwendung nicht mehr, obwohl es sich um denselben Datensatz handelt. Wichtig ist dabei immer die Betrachtung des aktuellen Zwecks des Zugriffes.

Die Implementierung rollenbasierter Zugriffssteuerungen ist daher auch komplexer als die der Eigner-definierten Zugriffssteuerung.

== Passwortsicherheit ==

Wie bereits in der Lektion zu [[Computer- und_Netzwerksicherheit_-_Kryptograhpie|Kyptographie]] beschrieben, hat die sichere Speicherung von Passwörtern eine hohe Priorität und sollte in einer entsprechend sicheren Architektur erfolgen. Zusätzlich zur technischen Sicherheit ist eine entsprechende '''Passwortkomplexität von besonderer Relevanz'''. Ein noch so effizient abgesicherter Passwortspeicher verliert an Bedeutung, wenn das darin gespeicherte Passwort selbst unsicher ist.

Ein unsicheres Passwort hat entweder:

* eine zu geringe '''Komplexität''' und kann daher durch [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Bruteforce]]- oder [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Hash-Kollisions-Angriffe]] gefunden werden, oder
* kann durch '''[[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]''' herausgefunden werden (z.B.: Name des Kindes mit Jahreszahl, Anfangsbuchstaben des Titels des Lieblingsliedes, usw.).
Die Komplexität eines Passwortes ergibt sich aus der '''Entropie''' – also den möglichen unterschiedlichen Kombinationen bzw. dem [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Schl%C3%BCssel_(Key)_und_Keyspace|Keyspace]]. Daraus und an der Anzahl an Passwörtern, welche pro Sekunde geprüft werden können, ergibt sich dann wiederum die Dauer, in welcher das Passwort durch Ausprobieren (Bruteforce-Angriff) gefunden werden kann.

Für die Komplexität von Passwörter galt lange eine bestimmte Mindestlänge (meist 8 Zeichen) und eine Kombination aus den Merkmalen:

* Kleinbuchstaben,
* Großbuchstaben,
* Ziffern und
* Sonderzeichen
als ausreichender Schutz.

Beispielsweise ein Passwort '''„''f9D22+P#''“''' mit 8 Zeichen und Erfüllung aller oben genannten Kriterien hat somit folgende Komplexität:

* 26 Kleinbuchstaben +
* 26 Großbuchstaben +
* 10 Ziffern +
* 36 Sonderzeichen (alle Sonderzeichen der deutschen Tastatur)
* '''= 98 Mögliche Zeichen pro Stelle'''.
* '''Bei 8 Zeichen sind das 98^8 Mögliche Passortkombinationen.'''
Ein Hochleistungs-PC, welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''23 Tage''' um das Passwort herauszufinden.

Ein Problem solcher komplexen Passwörter ist, dass es für die meisten User schwierig ist, sie sich zu einzuprägen. Dadurch besteht ein erhöhtes Risiko, dass die Passwörter:

* vergessen werden,
* auf einem Zettel notiert werden,
* nicht ausreichend oft geändert werden oder
* nur minimal geändert werden – beispielsweise durch simple Variation einzelner Teile des Passwortes, wie einer Ziffer am Ende.
Aufgrund der oben genannten Schwächen und der dennoch geringen Entropie noch gut merkbarer Passwortlängen, können diese Passwortrichtlinien '''nicht mehr als Stand der Technik''' betrachtet werden. Eine wesentlich bessere Möglichkeit ist die Nutzung von zufälligen Wörtern aus dem Wörterbuch. [Ga17]

Bei der Nutzung von '''vier zufälligen Wörtern aus dem Wörterbuch''' (kein Satz, sondern tatsächlich zufällig gewählte Wörter), ergibt sich bei Nutzung der 100.000 unterschiedlichen Wörter des Österreichischen Wörterbuchs [AF20] folgende Komplexität:

* '''100.000 mögliche Wörter pro „Stelle“ (ein Wort ist somit eine Stelle).'''
* '''Bei 4 Wörtern sind das 100.000^4 Mögliche Passortkombinationen.'''
Ein Hochleistungs-PC (der selbe PC wie im ersten Beispiel), welcher 2.148.000.000 Passwörter in der Sekunde ausprobieren kann, benötigt somit durchschnittlich ca. '''738 Jahre''' um das Passwort herauszufinden.

Ein Beispiel für ein Passwort aus 4 unzusammenhängenden Wörtern aus dem deutschen Duden ist: '''„''Dachs faul logisch Gerät''“'''.

Das Passwort weißt somit eine '''wesentlich höhere Entropie''' auf und ist für einen Menschen gleichzeitig '''leichter merkbar'''.

Leider ist diese Form der Passwörter in '''vielen Systemen noch nicht implementiert''' und es werden noch die veralteten Komplexitätsmerkmale des ersten Beispiels abgerufen. Diese Hürde kann ganz einfach überwunden werden, indem am Ende des Passworts eine Ziffer und ein Sonderzeichen gestellt werden. Da diese keine wirkliche Relevanz für die genannte Passwortsicherheit haben, können hier auch Zeichen genutzt werden, die schnell zu tippen sind. Das oben genannte Passwort könnte damit dann einfach '''''„Dachs faul logisch Gerät 9+“''''' lauten.

== Zertifikate ==

Zertifikate dienen der Feststellung der Identitäten von Personen und Systemen auf digitalem Wege. Ein Zertifikat ist ein digitales Dokument, indem bestimmte Daten angegeben sind, welche eine Person oder ein System und optional auch zugehörige Eigenschaften identifizieren. Zertifikate sind wesentliche Bestandteile von Public-Key-Systemen und enthalten zusätzlich den jeweiligen Public-Key des Zertifikatsinhabers (siehe auch Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" Lektion "Kryptographie").

Um die Echtheit eines Zertifikats zu bestätigen, kann dieses von anderen Stellen signiert werden. Diese Stellen werden als '''Zertifizierungsstellen (CA: Certification Authority)''' bezeichnet. Die Signatur erfolgt dabei, wie in Kapitel "[[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Asymmetrische_Verfahren|Asymmetrische Verfahren]]" beschrieben, durch hashen des Zertifikates und Verschlüsselung des Hashwertes durch den privaten Schlüssel der Zertifizierungsstelle. Da der öffentliche Schlüssel – wiederum durch das Zertifikat der Zertifizierungsstelle – bekannt ist, kann der Hashwert korrekt entschlüsselt, und die Signatur damit als gültig erkannt, werden.

Ob diese Echtheitsbestätigungen nun '''hierarchisch''' erfolgen ([[Computer- und_Netzwerksicherheit_-_Zugriffssteuerung#Public-Key-Infrastruktur_(PKI)|Public-Key-Infrastruktur]]), oder über ein dezentral '''verteiltes Vertrauensmodell''' ([[Computer- und Netzwerksicherheit_-_Zugriffssteuerung#Web_of_Trust_(WOT)|Web of Trust]]) ist von der jeweiligen Implementierung abhängig. Derzeit sind beide Modellvarianten im Einsatz und finden ihre Anwendung in einer Vielzahl von Systemen. Die Zertifikate der behördlich akzeptierten digitalen Signaturen basieren derzeit auf dem hierarchischen Modell der Public-Key-Infrastruktur.

Ein Zertifikat ist mit einem Ausweisdokument vergleichbar. Auf dem Ausweis befinden sich die Daten der Person und ein Verweis auf den Aussteller. Durch Sicherheitsmerkmale am Dokument (Wasserzeichen, Silberstreifen,…) wird dabei die Echtheitsprüfung ermöglicht. Der Aussteller (z.B. eine Behörde) bestätigt damit die Identität des Inhabers (z.B. Personalausweis) und gegebenenfalls auch bestimmte durch das Dokument erlaubte Tätigkeiten (z.B. Führerschein).

Die Echtheit eines Zertifikates kann von der jeweiligen Zertifizierungsstelle auch wieder zurückgezogen werden. Zu diesem Zweck werden '''Zertifikats-Sperrlisten (CRL: Certificate Revocation Lists)''' eingesetzt, welche Einträge der Seriennummern aller Zertifikate mit zurückgenommenen Echtheitsbestätigungen enthält. Die Sperrliste ist selbst wiederum von der jeweiligen Zertifizierungsstelle signiert, um ihre Echtheit zu bestätigen.

Der Aufbau und der mögliche Inhalt eines Zertifikates ist im '''X.509 Standard''' [Ne99] definiert. Ein entsprechendes Beispiel (das aktuelle Zertifikat des Online-Campus) ist in Abbildung "Zertifikat" dargestellt.

[[Datei:IT244 16.png|300px|none|thumb|Zertifikat]]


=== Public-Key-Infrastruktur (PKI) ===

Bei der Public-Key-Infrastruktur (PKI) handelt es sich um ein hierarchisch aufgebautes System von Zertifizierungsstellen. Das bedeutet, dass jede Zertifizierungsstelle das in sie gesetzte Vertrauen an nachfolgende Stellen weiterverteilen kann, indem sie die zugehörigen Zertifikate signiert.

Daraus ergibt sich dann eine Hierarchie aus mehreren Zertifikaten, die bis zu einem Stammzertifikat rückverfolgt werden können sind. Durch das Vertrauen in das jeweilige Stammzertifikat wird auch den nachfolgenden Zertifikaten vertraut.

In den meisten Anwendungen, die PKI Zertifikate einsetzen (z.B. Internetbrowser für HTTPS Verbindungen), sind bereits einige gängige Stammzertifikate der großen Zertifizierungsstellen vorinstalliert. Es ist jedoch meist auch möglich weitere Stammzertifikate hinzuzufügen, denen dann ebenfalls vertraut wird. In Abbildung "Zertifizierungspfad" ist die Hierarchie des Zertifikates des Online-Campus dargestellt. Die Stammzertifizierungsstelle ist in diesem Fall das Unternehmen Go Daddy.

[[Datei:IT244 17.png|300px|none|thumb|Zertifizierungspfad]]


Zusätzlich zu den Zertifizierungsstellen gibt es in der PKI noch weitere Instanzen, welche hautsächlich für den Zertifizierungsprozess verantwortlich sind. Die Hauptakteure der PKI sind:

* Zertifizierungsstelle (CA: Certification Authority),
* Registrierungsstelle (RA: Registration Authority) und
* Validierungsdienst (VA: Validation Authority)
Die '''Registrierungsstelle''' ist in der PKI dafür verantwortlich die Identität des Antragsstellers zu überprüfen und dies wiederum der Zertifizierungsstelle mitzuteilen. Die '''Validierungsstelle''' ist für die Gültigkeitsprüfung von bereits ausgestellten Zertifikaten verantwortlich. Sie verwaltet auch die Zertifikats-Sperrlisten und ihre Erreichbarkeit ist meist in einem Datenfeld in den Zertifikaten selbst angegeben.

Soll nun ein neues Zertifikat ausgestellt werden, muss folgender '''Zertifizierungsprozess''' durchlaufen werden:

# Der Antrag für das neue Zertifikat wird an die Registrierungsstelle (RA) geschickt
# Die Registrierungsstelle (RA) überprüft den Antrag und stellt sicher, dass es sich bei der Identität tatsächlich um die der antragstellenden Person oder des zugehörigen IT-Systems (z.B. bei einem Webserver-Zertifikat) handelt.
# Wenn die Registrierungsstelle die Identität bestätigen kann, sendet sie den Antrag weiter an die Zertifizierungsstelle (CA).
# Die Zertifizierungsstelle (CA) stellt nun das beantragte Zertifikat aus, generiert dafür einen privaten und einen öffentlichen Schlüssel und sendet diese an die antragsstellende Person.
Oft ist es auch möglich das Schlüsselpaar selbst zu generieren und dem Antrag nur den öffentlichen Schlüssel beizufügen. Dies ist für die Ausstellung des Zertifikates ausreichend, da der private Schlüssel für seine Signierung nicht benötigt wird (diese wird durch den privaten Schlüssel der CA durchgeführt). In diesem Fall ist zusätzlich sichergestellt, dass der private Schlüssel nur der antragsstellenden Person bekannt ist.

Gerade bei der Überprüfung durch die Registrierungsstelle gibt es unterschiedliche Qualitäten. Wird hier ungenau vorgegangen, kann dies zu Zertifikaten falscher Identitäten führen.

=== Web of Trust (WOT) ===

Das Modell des Web of Trust ist im Gegensatz zur PKI nicht hierarchisch, sondern dezentral aufgebaut. Es basiert auf einer dezentralen Vertrauensverteilung zwischen den Teilnehmern, ähnlich dem Freundes- und Bekanntenkreis einer Person. Die Schlüssel sind dabei nicht in einer hierarchischen Struktur zentral abrufbar und überprüfbar, sondern werden direkt von den Benutzern verwaltet. Jeder User hat seinen eigenen Schlüsselbund, wobei hier zwischen dem privaten und dem öffentlichen Schlüsselbund unterschieden wird.

Am '''privaten Schlüsselbund''' befinden sich die privaten Schlüssel des Users, mit denen Daten signiert und entschlüsselt werden können. Am '''öffentlichen Schlüsselbund''' befinden sich die eigenen öffentlichen Schlüssel, sowie die öffentlichen Schlüssel anderer User. Mit den öffentlichen Schlüsseln können Nachrichten verschlüsselt und Signaturen geprüft werden.

Die Vertrauensstufen werden über die öffentlichen Schlüssel der Teilnehmer ermittelt. Dazu gibt es im öffentlichen Schlüsselbund für jeden Schlüssel ein '''Key Legimitation Field''', in dem der jeweilige '''Vertrauensgrad (Owner Trust)''' des Schlüssels angegeben wird.

Im WOT gibt es folgende Vertrauensgrade:

* unknown: Personen über die keine Informationen bekannt sind,
* not trusted: Personen denen nicht vertraut wird,
* marginal: Personen denen nicht voll vertraut wird,
* complete: Personen denen voll vertraut wird und
* ultimate: eigener öffentlicher Schlüssel.
Wer als vertrauenswürdig eingestuft wird, liegt somit beim jeweiligen Schlüsselbund Inhaber.

Die Vertrauensgrade können an andere User (z.B. über einen Schlüsselserver) weitergegeben werden, indem die jeweiligen Schlüssel durch den eigenen privaten Schlüssel signiert werden. Dies wird auch als '''indirekte Zertifizierung''' bezeichnet.

Ist dem User, der einen dritten Schlüssel signiert hat, im eigenen Schlüsselbund einem Vertrauensgrad zugewiesen, so erhält der von ihm signierte Schlüssel je nach eigener Einstellung denselben Vertrauensgrad oder niedriger. Zusätzlich kann definiert werden, wie viele signierte Schlüssel eines niedrigeren Vertrauensgrades notwendig sind, um die Vertrauensstufe um eine Stufe aufzuwerten. Die Standartwerte hierfür sind 3 signierte Schlüssel anderer User für die Aufwertung und ein signierter Schlüssel eines anderen Users für dieselbe Stufe.

Diese Abhängigkeiten sind in Abbildung "Web of Trust - Vertrauensnetzwerk" ersichtlich: Peter kennt sowohl Anna, als auch Christoph persönlich und hat daher ihre öffentlichen Schlüssel in seinem öffentlichen Schlüsselbund abgelegt. Christoph hat nur eine direkte Beziehung zu Anna, nicht aber zu Peter. Da sich Christophs öffentlicher Schlüssel im öffentlichen Schlüsselbund von Anna befindet, erkennt Peter sein Zertifikat als gültig an.

[[file:img1643193688517.png|300px|alt=Web of Trust - Vertrauensnetzwerk|none|thumb|Web of Trust - Vertrauensnetzwerk]]

Die erste Implementierung des WOT war '''Pretty Good Privacy (PGP)''' [Sy15]. Es ist ein Softwarepaket, welches die Sicherstellung der Authentizität, Integrität und Vertraulichkeit von E-Mails sowie beliebiger Dateien ermöglicht. '''GnuPG''' [Gn15] ist die frei verfügbare Version, die unter der GNU General Public License [Fr07] steht. Ein möglicher Windows Client für GnuPG ist beispielsweise Gpg4win [In15b].

=== Neue Zertifikatsmodelle und Erweiterungen ===

Sowohl im Bereich des PKI, als auch im WOT Modell, gibt es mittlerweile einige bekannte Sicherheitslücken und Protokollfehler. Weiter ist gerade im PKI Modell die Rolle der CA enorm wichtig. Werden hier nur schlechte Identitätskontrollen bei der Ausstellung von Zertifikaten durchgeführt, kann es zu falschen validen Identitäten kommen. Im Bereich des WOT können beispielsweise die Schlüsselserver zum Generieren von SPAM-Versandlisten genutzt werden, da die zugehörigen E-Mailadressen der Zertifikate dort frei verfügbar sein müssen. Weiter sind über die WOT soziale Netzwerke der User analysierbar, da die Trustlevel und ihre Abhängigkeiten leicht analysiert werden können. [Br14]

Um diese Schwachstellen zu beseitigen wird bereits an möglichen neuen Protokollen und Erweiterungen geforscht. Den meisten Ansätzen gemein ist, die Abhängigkeit von einzelnen CA’s zu verringern. Fehler einer CA sollen möglichst auf Seite der Endanwendung (wie z.B. im Browser oder Mail Client) frühzeitig erkannt und angezeigt werden. [Br14]

Einer dieser neuen Ansätze ist die Software ''Perspectives'' [Ca15]. Dabei handelt es sich um eine Browsererweiterung, die jedes Zertifikat zusätzlich mit einem sogenannten Notary-Server abgleicht. Damit können beispielsweise Man-in-the-Middle Angriffe frühzeitig erkannt werden.

Weitere aktuelle Erweiterungen sind [Br14]:

* Pinning [EPS14],
* Certificate Transparency [LLK13],
* Microsoft SmartScreen [Mi15] und
* DANE [HVS12].

== Angriffsvektoren der Access Control ==

Die Angriffsmethoden der Access Control sind sehr vielfältig und haben oft [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffsvektoren_der_Kryptographie|Angriffsvektoren der Kryptographie]] und [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Angriffsvektoren_der_Daten%C3%BCbertragung|Datenübertragung]], sowie [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Angriffsvektor_Social_Engineering|Social Engineering]]als Grundlage. Dies trifft insbesondere auf Angriffe gegen die Integrität und Authentizität zu.

Dazu bereits behandelte Angriffsvektoren sind:

* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Brute-Force_Angriffe|Brute-Force Angriffe]],
* [[Computer- und_Netzwerksicherheit_-_Bewusstseinsbildung#Phishing|Phishing]] und
* [[Computer- und_Netzwerksicherheit_-_Kryptograhpie#Angriffe_gegen_Hashwerte|Angriffe gegen Hashwerte]].
Eine weitere wichtige Angriffsmethode ist die des '''Pharming.''' Dabei wird die Anfrage eines Users auf einen bösartigen Server umgeleitet. Er glaubt sich sicher und gibt dann dort seine geheimen Daten ( wie z.B.: Zugangsdaten und Transaktionsdaten) preis. Beim Pharming handelt es sich daher um einen [[Computer- und_Netzwerksicherheit_-_Netzwerksicherheit#Man-in-the-Middle_Angriff|Man-in-the-Middle Angriff]].

== Wiederholungsaufgaben/Übungen ==

'''1 Was ist der Unterschied zwischen Identifikation, Authentifikation und Autorisation?'''

'''2 Was ist eine Zwei-Faktor-Authentifikation?'''

'''3 Welche drei Zugriffssteuerungsmodelle gibt es?'''

'''4 Erklären Sie das Modell der Eigner-definierten Zugriffssteuerung.'''

'''5 Was sind Zertifikate und die damit verbundenen Vertrauensmodelle?'''

'''6 Was bedeutet PKI und wer sind ihre Hauptakteure? Wie hängen diese Akteure zusammen?'''

'''7 Eine Passwortrichtlinie fordert ein Passwort, bestehend aus Kleinbuchstaben, Großbuchstaben und Ziffern mit einer Länge von 10 Zeichen. Wie wird die Komplexität des Passworts berechnet (wie viele mögliche Passwörter gibt es)?'''