Authentifizierung und Autorisierung in der IT E-Book

Andreas Lehmann

• Herausgeber: Carl Hanser Verlag GmbH & Co. KG
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 108

Beschreibung

- die Grundlagen der Authentifizierung und Autorisierung erklärt
- anhand praxisrelevanter Anwendungsfälle dargelegt
- die sinnvollen Lösungsmöglichkeiten erläutert
- effektive Kombinationen und Entscheidungswege beschrieben
- keine bis wenige Vorkenntnisse nötig
- Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches

Das Buch beschreibt grundsätzlich verschiedene Methoden der Authentifizierung und Autorisierung im Rahmen betrieblicher Informationssysteme. Startpunkt ist die Problemstellung, dass Daten und Informationen, Datenflüsse und Informationsflüsse sowohl im Lokalen als auch im Netzwerk geschützt werden müssen. Dazu identifiziert das Buch mehrere Bereiche und Schutzmaßnahmen, wie diese zu kombinieren sind und wie sie sich auf Basis vorhandener Technologien umsetzen lassen. Auch potenzielle Implementierungspattern sind beschrieben.
Sie erfahren, wie Sie Daten insbesondere im Rahmen der DSGVO und der immer stärkeren Verteilung auf Basis von Cloud-native Architekturen schützen können. So reicht es nicht mehr aus, eine einfache Benutzeranmeldung zu implementieren, sondern es müssen auf unterschiedlichsten Ebenen abhängig von der Kritikalität mehr oder weniger umfangreiche und sehr feinmaschige Sicherheitsmechanismen umgesetzt werden.

AUS DEM INHALT //
Ressourcen schützen/Anwendungsfälle/OpenID/OAuth 2.0/OpenID Connect/JSON Web Token/UMA/SAML/XACML/Policy Enforcement/Hashfunktionen/Asymmetrische Verschlüsselung/Abschließender Vergleich

Leseprobe

Andreas LehmannMark LubkowitzBernd Rehwaldt

Authentifizierung und Autorisierung in der IT

Grundlagen und Konzepte

Alle in diesem Werk enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Werk enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebensowenig übernehmen Autoren und Verlag die Gewähr dafür, dass die beschriebenen Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt also auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.Die endgültige Entscheidung über die Eignung der Informationen für die vorgesehene Verwendung in einer bestimmten Anwendung liegt in der alleinigen Verantwortung des Nutzers.

Aus Gründen der besseren Lesbarkeit wird auf die gleichzeitige Verwendung der Sprachformen männlich, weiblich und divers (m/w/d) verzichtet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Bibliografische Information der Deutschen Nationalbibliothek:Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – mit Ausnahme der in den §§ 53, 54 URG genannten Sonderfälle –, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

© 2024 Carl Hanser Verlag München, www.hanser-fachbuch.deLektorat: Brigitte Bauer-SchiewekCopy editing: Petra Kienle, FürstenfeldbruckUmschlagdesign: Marc Müller-Bremer, München, www.rebranding.deUmschlagrealisation: Max KostopoulosTitelmotiv: © stock.adobe.com/tomozina1Druck und Bindung: Hubert & Co. GmbH & Co. KG BuchPartner, Göttingen

Print-ISBN:        978-3-446-47949-4E-Book-ISBN:   978-3-446-48000-1E-Pub-ISBN:     978-3-446-48001-8

Inhalt

Titelei

Impressum

Inhalt

Vorwort

1 Ressourcen schützen

1.1 Rollenkonzepte

1.2 Lokale Authentifizierung

1.3 Zentrale Authentifizierung

1.4 Föderierte Authentifizierung

1.5 Prinzipien der Authentifizierung

1.6 Standards der Authentifizierung

1.7 Dezentrale Authentifizierung

2 Anwendungsfälle

2.1 Vertrauenswürdiger Client

2.2 Single Page Application

2.3 Anwenderdetails

2.4 Interne Vertrauensstellung

2.5 Ressourcenzugriff

2.6 Föderierte Authentifizierung

2.7 Föderierte Identität

2.8 Service-Kommunikation

2.9 Zusammenfassung

3 OpenID

3.1 OpenID-Rollen

3.2 URL-basierte Identität

3.3 Normalisierung

3.4 Discovery und Delegated Identity

3.5 Shared Secret und Association herstellen

3.6 Requesting Authentication

3.7 Autorisierung zusichern

3.8 Verifying Assertions

3.9 Extensions und Simple Registration

3.10 Einsatzgebiete für OpenID

3.11 Der OpenID-Authentifizierungsprozess in der Übersicht

4 OAuth 2.0

4.1 OAuth-Rollen

4.2 Der OAuth-Berechtigungsprozess „Authorization Code Grant“

4.3 Überprüfen der Token durch den Resource Server

4.4 Identifier

4.5 OAuth Grants (Flows)

4.6 OAuth-Einsatzgebiete

4.7 Beispielimplementierung für Java

5 OpenID Connect

6 JSON Web Token

6.1 Struktur

6.2 Claims

6.3 Einsatzgebiete

7 UMA

7.1 Rollen

7.2 Relevante Konzepte

7.3 Verwalten und schützen, kontrollieren und autorisieren

7.4 Möglicher Flow

8 SAML

8.1 SAML-Rollen

8.2 SAML Assertions

8.3 Channel Exchanges

8.4 Web Single-Sign-on

8.5 Primary Flows

8.6 Einsatzgebiete für SAML

9 XACML

10 Policy Enforcement

10.1 Endpoint Interceptor

10.2 Container Plugin

10.3 Gateway

10.4 Entscheidungshilfe

11 Hashfunktionen

11.1 In Deutschland einsetzbare Hashfunktionen

11.2 Salts

11.3 Work Factors

12 Asymmetrische Verschlüsselung

12.1 Einsetzbare, asymmetrische Verschlüsselungsfunktionen

12.2 Identitäten und Zertifikate

12.3 Technische Handhabung

13 Abschließender Vergleich

Vorwort

The world’s most valuable resource is no longer oil, but data.

Economist, 2017

„The world’s most valuable resource is no longer oil, but data“ ist die Titelzeile des Economist aus dem Jahr 2017. Sie hat sich mittlerweile zu „Data is the new oil“ weiterentwickelt. Adressierte der Economist mit ihr ursprünglich das Monopol der dominierenden Firmen im Digitalmarkt, wird sie heute meist verwendet, um die Wertigkeit und das Potenzial von Daten hervorzuheben. Die Existenz einiger der weltweit wirtschaftskräftigsten Unternehmen basiert rein auf Daten. Allgemeiner gesagt: Daten sind heute längst einer der wichtigsten Rohstoffe jedes Unternehmens.

Dieser Rohstoff ist wertvoll.

Dieser Rohstoff ist schutzwürdig.

Dieser Rohstoff benötigt besondere Behandlung.

Der Verlust oder die Veröffentlichung von vertraulichen Daten kann einerseits erheblichen Schaden für ein Unternehmen verursachen. Umfassen diese Daten andererseits personenbezogene Informationen, dann folgen auch strafrechtliche Konsequenzen mit teils empfindlichen Geldstrafen.

Lagerten Werte früher häufig in Tresoren, werden sie heute beinahe ausschließlich in IT-Systemen aufbewahrt. Ein Tresor schützt seinen Inhalt etwa durch Wissen in Form einer Zahlenkombination, Besitz in Form eines Schlüssels oder beides. Wer die Zahlenkombination kennt oder den Schlüssel besitzt, konnte sich autorisieren und auf den Inhalt des Tresors zugreifen. Eine Authentifizierung, also wer den Tresor öffnet, war nicht nötig.

Anders sieht es bei IT-Systemen aus. Um in IT-Systemen verarbeitete Daten angemessen zu schützen, müssen drei Ziele erreicht werden: Vertraulichkeit, Integrität, Verfügbarkeit.

       Vertraulichkeit: Die Daten sind nur den Personen und Systemen zugänglich, die diese zur Erfüllung ihrer jeweiligen Tätigkeit benötigen.

       Integrität: Die Daten sind inhaltlich korrekt und Änderungen nachvollziehbar.

       Verfügbarkeit: Die Daten sind gegen Löschen und sonstigen Verlust des Zugriffs gesichert.

Erreichen lassen sich diese drei Ziele, indem sich jede zugreifende Person und jedes zugreifende System authentifizieren und autorisieren müssen.

Welche Maßnahmen zum Schutz von Daten dafür heutzutage in Frage kommen und was es dabei zu beachten gilt, das ist Inhalt dieses Buches.

München, Januar 2024

Andreas Lehmann, Mark Lubkowitz, Bernd Rehwaldt

1Ressourcen schützen

For many organizations, security comes down to basic economics.If the cost of security is less than the likely cost of losses due to lack of security,security wins.If the cost of security is more than the likely cost of losses, accept the losses.

Bruce Schneier, Data and Goliath:The Hidden Battles to Collect Your Data and Control Your World

Die in IT-Systemen gelagerten, schützenswerten Daten werden oft verallgemeinert als Ressourcen bezeichnet. Sie sind aber mehr als das. Denn Daten lassen sich zu Informationen verarbeiten, diese zu Wissen und Erkenntnisse veredeln, schlussendlich dann Erfahrung sammeln. Qualität und Quantität der Daten beeinflussen ihren Geschäftswert und wirken sich direkt auf den Wettbewerbsvorteil aus. Verallgemeinert als Ressourcen bezeichnete Daten sind also hoch kritische, wirtschaftliche Grundlage eines modernen Unternehmens.

Bild 1.1Genealogie: Daten lassen sich zu Informationen verarbeiten, aus denen sich Wissen ableiten lässt. Die letzte Qualitätsstufe ist Erfahrung. Je mehr Daten im Zugriff sind und je besser deren Qualität ist, desto höher ist der Geschäftswert und desto größer der Wettbewerbsvorteil.

Beim Schutz dieser Ressourcen geht es im Kern darum, nur einem autorisierten Kreis von Personen oder Systemen Zugang zu diesen zu verschaffen. Nun haben nicht alle Ressourcen den gleichen Schutzbedarf. Auf der einen Seite gibt es Ressourcen, die öffentlich zugängliche Daten repräsentieren und dementsprechend einen geringen Schutzbedarf aufweisen. Auf der anderen Seite stehen personenbezogene Daten, deren Schutz sogar von gesetzlicher Seite vorgeschrieben und reguliert ist. Wiederum gibt es Daten, die Geheimnisse darstellen.

Um dieser Tatsache Rechnung zu tragen, werden Ressourcen in unterschiedlich abgestufte Ressourcengruppen geordnet. Der Detailgrad und die Unterscheidungsart können erheblich variieren. Als Faktoren lassen sich unter anderem Quelle, Form, Bezug, Zweck und Verfahren heranziehen, aber auch Verarbeitungsart, Verfügbarkeit und Wert. Diesen Ressourcengruppen sind dann unterschiedliche Schutzklassen zugeordnet, etwa „öffentlich“, „intern“, „geheim“ oder „streng geheim“. Von den Schutzklassen hängt ab, welche Elemente des Schutzes angewendet werden sollen.

Tabelle 1.1 Schutzklassen: Zunächst gilt es, die Daten in unterschiedliche Ressourcengruppen zu unterteilen. Welche Faktoren zur Einordnung herangezogen werden, ist individuell unterschiedlich. Dann lassen sich den Ressourcengruppen Schutzklassen zuteilen, die etwa Art und Anzahl der Elemente zur Authentifizierung bestimmen.

Ressourcengruppe

Schutzklasse

Schutzelemente

Kundendaten

geheim

doppelt

Auftragsdaten

intern

einfach

Mitarbeiterdaten

streng geheim

mehrfach

Unternehmensdaten

öffentlich

keins

Auch die Art des Zugangs zu den Ressourcen ist unterschiedlich. Der grundlegendste Unterschied differenziert, ob lesender oder schreibender Zugriff oder beides erfolgt. Sie beantwortet also die Frage, ob jemand oder etwas Daten einsehen und diese auch verändern darf.

1.1Rollenkonzepte

Um unterschiedliche Berechtigungen im Umgang mit den Ressourcen zu ermöglichen, kommen in der Regel Rollenkonzepte zum Einsatz. Im einfachsten Fall sind die Ressourcen gruppiert und unterschiedliche Rollen für lesenden und schreibenden Zugriff je Ressourcengruppe definiert. Zugang zu einer Ressourcengruppe erhalten eine Person oder ein System, wenn ihnen eine der entsprechenden Rollen zugeordnet ist.Tabelle 1.2 zeigt beispielhaft vier verschiedene Rollen, die unterschiedliche Rechte zum Zugriff auf bestimmte Daten festlegen. Sie kann wiederum je nach Ressourcengruppe unterschiedlich ausfallen.

Tabelle 1.2 Rollenkonzepte: Rollen definieren die Art des Zugriffs auf Daten. Diese Rollen lassen sich Personen und Systemen zuordnen und der Zugriff somit detailliert festlegen.

Rolle

erstellen

lesen

verändern

löschen

Rolle A

ja

nein

nein

nein

Rolle B

ja

ja

nein

nein

Rolle C

ja

ja

ja

nein

Rolle D

ja

ja

ja

ja

In der Regel werden Ressourcen im Kontext eines IT-Systems verwaltet. Dieses IT-System ist dafür zuständig den Schutz der Ressourcen sicherzustellen. Das schafft es, indem der Zugang zu den Ressourcen nicht direkt, sondern über Funktionen des IT-Systems erfolgt. Diese Funktionen autorisieren den Zugriff, indem sie für ihre Ausführung eine bestimmte Rolle verlangen.

Bild 1.2Ressourcenschutz: IT-Systeme regeln den Zugriff auf Ressourcen. Sie fordern für die Ausführung bestimmter Funktionen eine bestimmte Rolle. In diesem Fall darf „Person A“ etwa neue Einträge erstellen, vorhandene aber nicht lesen. In diesem Beispiel kommt für alle Daten dieselbe Rollentabelle zum Einsatz.

Damit das IT-System aber weiß, in welchem Kontext welcher Rolle die Ausführung erfolgt, muss die Rolle vorab ermittelt werden. Hierzu wird in der Regel das Konzept einer Session verwendet, die mit der Anmeldung des Benutzers oder Systems startet.

Dieser Vorgang ist die Authentifizierung. Das System fordert den Benutzer auf, seine Identität nachzuweisen. Dieser Nachweis erfolgt durch die Vorlage von Identitätsmerkmalen. Dabei können drei Klassen von Identitätsmerkmalen verwendet werden: Besitz, Wissen und immer häufiger auch Eigenschaft. Zur Klasse Wissen gehören Kennwörter, PINs und Ähnliches. Besitz beschreibt die Tatsache, dass die Person beispielsweise ein bestimmtes Smartphone oder einen Token-Generator hat. Unter Eigenschaft sind Persönlichkeitsmerkmale wie ein Fingerabdruck, ein Irismuster oder Gesichtscharakteristiken versammelt.

Welche dieser Identitätsmerkmale zur Authentifizierung benötigt werden, ist in einem Identity and Access Management (kurz IAM) festgelegt. Das Identity Management (IM) verwaltet die Identitätsinformationen einer Person oder eines Systems. Hier sind also Kennwörter, PINs, Fingerabdruck-Muster oder Mobilfunknummern hinterlegt. Das Access Management (AM) verwaltet die verschiedenen Rollen, die für den Ressourcenzugriff im Kontext einer Applikation existieren. Hier ist auch festgelegt, welcher Benutzer welche Rollen bekommt.

Tabelle 1.3 Authentifizierungsfaktoren: Wissen, Besitz und Eigenschaft sind grundlegende Konzepte in der Informationssicherheit. Sie lassen sich einzeln oder in Kombination verwenden.

Faktor

Beschreibung

Beispiele

Wissen

basiert auf dem Wissen einer Person

Kennwort, PIN, TAN, Antworten auf Sicherheitsfragen

Besitz

bezieht sich auf den Besitz eines physischen Objekts

Smartcards, Hardware-Token, Mobiltelefon, TPM

Eigenschaft

basiert auf einem physischen oder biometrischen Merkmal

Fingerabdruck, Gesichtserkennung, Biometrie

Da mit den unterschiedlichen Schutzklassen unterschiedliche Kritikalitäten des Ressourcenzugriffs verbunden sind, können diese Schutzklassen auch Einfluss auf die vom Anwender bei der Authentifizierung verlangten Identitätsmerkmale haben. So reicht vielleicht für das Erlangen von Lesezugriff auf „intern“ klassifizierte Ressourcen eine einfache Kennwortauthentifizierung. Der schreibende Zugang zu „geheim“ klassifizierten Ressourcen fordert hingegen den Nachweis von zwei Identitätsmerkmalen aus unterschiedlichen Klassen, wie Kennwort aus der Klasse Wissen und ein Token aus dem im Besitz des Anwenders befindlichen Token-Generators. Diese Kombination heißt Mehr-Faktor-Authentifizierung.

Bild 1.3Authentifizierung: Personen und Systeme nutzen einen oder mehrere Faktoren, um sich gegenüber einer Anwendung zu authentifizieren. Nach erfolgreicher Prüfung erhalten die Personen oder Systeme entsprechende Rollen.

1.2Lokale Authentifizierung

In der Vergangenheit war es ein typischer Ansatz, dass jede Anwendung für ihr Identity and Access Management selbst verantwortlich zeichnete. Das bedeutet, dass jede Anwendung ihre eigene Benutzer- und Rollenverwaltung hat und selbst Funktionen für die Authentifizierung der Anwender bereitstellt. Die Identitätsinformationen der Anwender lagen in der Hoheit der Anwendung.

Werden mehrere Anwendungen durch dieselbe Person benutzt, sind die Identitätsinformationen mehrfach vorhanden. Das führt zu unterschiedlichen Benutzernamen und Passwörtern. Auch die Aktualisierung von Personendaten wie Anschrift und E-Mail muss an mehreren Stellen vorgenommen werden. Gleiches gilt für die Umsetzung gesetzlicher Anforderungen, etwa Auskünfte gemäß DSGVO, die jede Anwendung dann selbst umsetzen muss.

Bild 1.4Lokale Authentifizierung: Bislang verwaltete jede Anwendung die Zugangsdaten für Personen und Systeme selbst.

1.3Zentrale Authentifizierung

Ein erster Lösungsschritt ist das Single-Sign-on-Verfahren, kurz SSO. Innerhalb einer Sicherheitsdomäne, etwa einem Unternehmen, stellt ein Identitätsanbieter, kurz IDP für Identity Provider, ein zentrales Identity and Access Management bereit. Dieser Identitätsanbieter verwaltet die Identitätsinformationen der Anwender für alle Anwendungen innerhalb der Sicherheitsdomäne und ermöglicht gleichzeitig die Authentifizierung der Anwender. Das entbindet die Anwendungen von der Pflicht einer eigenen Identitätsverwaltung, setzt aber auch ein striktes Vertrauensverhältnis zwischen Anwendung und Identitätsanbieter voraus.

Bild 1.5Single-Sign-on: Im Vergleich zu bisherigen Lösungen müssen sich Personen und System nur gegenüber des Identitätsanbieters authentifizieren. Die Anwendungen übertragen die Identitätsverwaltung an den Identitätsanbieter.

Diese Lösung erlaubt es, schnell auf ein identifiziertes Sicherheitsrisiko zu reagieren, weil Benutzer hier zentral für alle Anwendungen gesperrt werden können. Für den Anwender vereinfacht sich das Management seiner Identitätsmerkmale, weil diese zentral hinterlegt sind. Für die einzelne Anwendung bedeutet es, dass sie sich zentralen Richtlinien des Identitätsmanagements unterwirft. Hier kommen Standards zum Tragen, die in diesem Buch beschrieben sind.

1.4Föderierte Authentifizierung