Bachelorarbeit FAKULT AT INFORMATIK - Marco Feder Betreuer: Prof. Dr.-Ing. Johann Uhrmann - OPUS 4
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
FAKULTÄT INFORMATIK
Bachelorarbeit
Authentifizierung und Autorisierung in einer
verteilten Microservice-Umgebung
Marco Feder
Betreuer: Prof. Dr.-Ing. Johann Uhrmann
Betreuer am Ort der Durchführung: Roland Mieslinger
ERKLÄRUNG ZUR BACHELORARBEIT
Feder, Marco
Hochschule Landshut
Fakultät Informatik
Hiermit erkläre ich, dass ich die Arbeit selbständig verfasst, noch
nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als
die angegebenen Quellen oder Hilfsmittel benützt, sowie wörtliche
und sinngemäße Zitate als solche gekennzeichnet habe.
..................... ....................................................
(Datum) (Unterschrift des Studierenden)
Abstract Viele Sicherheitsorganisationen warnen vor Anfälligkeiten in Anwendungen, die aufgrund eines mangelnden Authentifizierungs- und Autorisierungssystems entstehen. In der Ver- gangenheit wurde diese Thematik von vielen Unternehmen als eher nachrangig betrachtet, ihre Bedeutung wurde jedoch in den letzten Jahren zunehmend erkannt. Die Agrolab GmbH steht zurzeit vor einer großen Aufgabe. Das mittlerweile seit 30 Jahren bestehende monolithische Datenbanksystem soll schrittweise zu einem neuen, auf Microser- vice Technologien basierten System umgebaut werden. Hierbei ist es nötig, von Beginn an ein gutes Authentifizierungs- und Autorisierungsschema zu erstellen, welches im Rahmen dieser Arbeit entworfen wird. Zunächst werden daher einige bekannte Sicherheitskonzep- te sowie Protokolle analysiert, dargestellt und mit den Anforderungen des Unternehmens abgeglichen. Für die Umsetzung dieser Konzepte wird ein Security-Framework, das mit den Technologien der neuen Architektur kompatibel ist, untersucht und anschließend aus- gewählt. Ein selbst programmierter Prototyp soll die künftigen Abläufe im Unternehmen darstellen und die Umsetzbarkeit der Anforderungen unter Beweis stellen.
Inhaltsverzeichnis A
Inhaltsverzeichnis
1 Einleitung 1
1.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Beschreibung und Analyse des aktuellen Systems 5
2.1 Das AGROLAB LIMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Interne Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Beschreibung des Zielsystems 11
3.1 Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Authentifizierung und Autorisierung 14
4.1 Begriffserklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Protokolle für Authentifizierungs-und Autorisierungsprozesse . . . . 15
4.2.1 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Open Authorization . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 OpenID Connect . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Autorisierungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1 Rollenbasierter Ansatz . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2 Attributbasierter Ansatz . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 Fazit zu beiden Ansätzen . . . . . . . . . . . . . . . . . . . . . 24
Inhaltsverzeichnis B
4.3.4 Hybrider Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Architektur und Spezifikation 27
5.1 Anforderungen an das neue System . . . . . . . . . . . . . . . . . . . 27
5.2 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6 Tools für die Umsetzung 32
6.1 Keycloak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Implementierung eines Prototypen 35
7.1 Aufbau des Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Verknüpfung mit dem bestehenden Active Directory . . . . . . . . . 36
7.3 Spring Boot Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.1 Aufbau und Funktionalität . . . . . . . . . . . . . . . . . . . . 37
7.3.2 Verwaltung der Zugriffsrechte . . . . . . . . . . . . . . . . . . 39
7.3.3 Agrolab Security Library . . . . . . . . . . . . . . . . . . . . . 42
7.3.4 Anmeldung über Identity Provider . . . . . . . . . . . . . . . 44
7.3.5 Zwei-Faktor-Authentifizierung . . . . . . . . . . . . . . . . . . 45
7.4 Angular Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.5 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.5.1 Aufbau einer Keycloak-Instanz . . . . . . . . . . . . . . . . . . 49
7.5.2 Grundaufbau des Clusters . . . . . . . . . . . . . . . . . . . . . 51
8 Fazit 54
Literaturverzeichnis I
Abbildungsverzeichnis VI
Tabellenverzeichnis VII
Glossar VIII
Akronyme XII
1 Einleitung 1
1 Einleitung
1.1 Ausgangssituation
Die AGROLAB GROUP GmbH wurde 1986 von einer Gruppe aus drei Personen
in der alten Dorfschule von Oberhummel als Labor - speziell für landwirtschaftli-
che Untersuchungen - gegründet. Mittlerweile agiert das Unternehmen europaweit
und hat rund 1500 Mitarbeiter, die an 20 verschiedenen Standorten tätig sind. Berei-
che wie Agrar-, Umwelt-, Wasser-, Lebensmittel-, und Futtermittelanalytik werden
vom Unternehmen abgedeckt. [agra]
Das Geschäftsmodell wird in der Abbildung 1.1 veranschaulicht.
Abb. 1.1: Überblick über den Agrolab Geschäftsprozess
Die Kunden können einen Auftrag, in dem die zu untersuchende Probe mit den
gewünschten Kriterien definiert wird, analog, aber auch digital an die Firma übermitteln.1 Einleitung 2
Analog bedeutet in diesem Fall per Brief und digital meint das AgroLab Online Or-
dering and Result Assistance (ALOORA), ein Kundenportal zur Erfassung von
Daten und Abrufen von Messergebnissen. Sobald der Auftrag eingegangen ist,
wird er durch einen Kundenbetreuer, der auch als Ansprechperson agiert, im inter-
nen System erfasst. Dieser Schritt erfolgt über ein Labor Information Management
System (LIMS), das im späteren Verlauf der Arbeit näher betrachtet wird. Über die-
ses Verwaltungssystem werden anschließend die Arbeitsschritte der Untersuchung
erfasst, die vom Labor-Team durchgeführt werden. Nachdem die Proben durch das
Labor gegangen sind, werden die Ergebnisse an das LIMS rückgemeldet, anschlie-
ßend wird ein Befund und eine Rechnung an den Kunden geschickt.
1.2 Motivation
Als erstes Labor arbeiteten wir arbeitsteilig, d.h. nach dem Vorbild
”
industrieller Prozesse – und tun es noch heute. Außerdem setzten wir
von Anfang an auf IT. “ [agra]
Das Unternehmen hat sich also bereits zur Gründungszeit Mitte der 80er Jahre auf
IT gestützt und sein eigenes internes Verwaltungssystem, das LIMS, entwickelt. Im
Laufe der letzten Jahre wurde das System in vielerlei Hinsicht den Kundenanfor-
derungen angepasst, sodass es sich immer stärker zu einem Monolithen, der auf
veralteten Technologien basiert, entwickelt hat. Durch die mittlerweile hohe Kom-
plexität und Vielseitigkeit ist die Anpassung sowie die Wartbarkeit des Programms
nur noch schwer umsetzbar. Aus diesen Gründen hat die IT-Leitung beschlossen,
schrittweise eine neue Architektur im Unternehmen einzuführen. Hierbei wur-
de entschieden, auf eine Microservice basierte Technologie, die Spring Boot als
Backend-Framework und Angular für den Frontend-Bereich verwendet, umzustei-
gen.
Auch das Thema Authentifizierung und Autorisierung spielt natürlich eine wich-
tige Rolle bei diesem Umstieg. Große Organisationen, die sich mit der Sicherheit
von Anwendungen auseinandersetzen, warnen vor Problemen in diesen Berei-1 Einleitung 3
chen. Die Open Web Application Security Project (OWASP) ist beispielsweise eine
Organisation von Experten, die sich mit dieser Thematik befasst. Deren Ziel ist
es, auf bekannte Sicherheitsrisiken hinzuweisen und dadurch Endanwender und
Organisationen diesbezüglich aufzuklären und Lösungsansätze in Form von Do-
kumentationen und sogar Tools zur Verfügung zu stellen. [secc]
Eine bekannte Übersicht ist die OWASP Top-10, welche die wichtigsten Risiken
präsentiert.
Abb. 1.2: OWASP Top-10 Risiken aus dem Jahr 2017 [owaa]
Unter dem Punkt A2:2017-Broken Authentication“bezeichnet die OWASP eine Si-
”
cherheitslücke, bei der ein Angreifer temporär bis sogar permanent eine andere
Identität annimmt, die meist aufgrund eines mangelnden Session- sowie Passwort-
managements entsteht. Dadurch können sensible Nutzerdaten in falsche Hände
geraten. Der Autorisierungsaspekt wird im Punkt A5:2017-Broken Access Con-
”
trol“angesprochen und thematisiert. [owab]
Die Auflistung macht klar, dass Authentifizierung und Autorisierung eigentlich
wichtige Themen bezüglich sicherer Entwicklung wären und Unternehmen in die-
sem Bereich sich wesentlich stärker engagieren müssen. Es ist daher unerlässlich,
sich bei der Entwicklung einer neuen Architektur von Beginn an mit der Thematik1 Einleitung 4 intensiv zu beschäftigen und ein tragfähiges Konzept zu entwickeln. Es ist nur schwer möglich ein solches System im Nachhinein einzubinden. Vor allem in großen Unternehmen mit einer Vielzahl von Benutzern muss sich erst einmal bewusst gemacht werden, wie wichtig diese beiden Themen sind. Wie kann eine Anwendung die Identität des Benutzers sicherstellen? Woher weiß ein Service, ob der Autor einer einkommenden Anfrage überhaupt die Autorisierung hat diese auszuführen? Wie wird sichergestellt, ob dieser Autor nicht einfach die Identität eines anderen annimmt? Wie kann ein Anwender mehrere Services nutzen, ohne sich bei jedem einzelnen anmelden zu müssen? Diese Fragen sollen unter anderem im Rahmen dieser Arbeit geklärt werden. 1.3 Ziel der Arbeit Das Ziel der Arbeit ist es, eine Vorgehensweise für den Authentifizierungs- und Au- torisierungsprozess in der neuen Architekur der AGROLAB Gmbh zu entwickeln. Hierbei müssen zunächst einige Sicherheitsprotokolle und Standards analysiert und dargestellt werden. Zusätzlich soll ein Security-Framework ausgewählt wer- den, das die derzeit verwendeten Konzepte unterstützt und den Anforderungen des Unternehmens entspricht. Folglich werden mehrere Komponenten miteinander verglichen und anhand von festgelegten Kriterien bewertet. Ein selbst implemen- tierter Prototyp soll anschließend die Umsetzbarkeit der durch die Arbeit gewonnen Erfahrungen beweisen und als Entscheidungskriterium dienen. Hierbei sollen die Hintergrundabläufe vom Login des Anwenders auf dem Frontend Bereich bis hin zur Kommunikation zwischen Microservices dargestellt werden.
2 Beschreibung und Analyse des aktuellen Systems 5
2 Beschreibung und Analyse des
aktuellen Systems
Um ein neues Authentifizierungs- und Autorisierungsschema erstellen zu können,
muss zunächst einmal ein Überblick über den aktuellen Prozess und die zur-
zeit verwendeten Technologien geschaffen werden. Im Folgenden bezieht sich die
Abkürzung LIMS immer auf die Eigenentwicklung des Unternehmens.
2.1 Das AGROLAB LIMS
Wie bereits erwähnt ist der Kern des Unternehmens das LIMS, dessen Entwick-
lung bereits vor 30 Jahren begann. Dieses System verwendet hauptsächlich Oracle-
Technologien, die in Procedural Language/Structured Query Language (PL/SQL)
implementiert sind. Dabei handelt es sich um eine Programmiersprache, die sehr
ADA ähnelt.
Gehen Aufträge von Kunden über das ALOORA-System oder per Post ein, müssen
diese Daten zunächst in das interne System aufgenommen werden. Dies erfolgt
über die sogenannten Erfasser. Sie werden intern als Customer Relationship Mana-
gement (CRM) bezeichnet und stellen die direkte Kommunikation mit dem Kunden
sicher. Im Probeneingangskontrollbereich werden die Auftragsinformationen über
eine Nutzeroberfläche, die mit Oracle Forms implementiert ist, in das LIMS ein-
gefügt, wo die Proben kontrolliert werden. Anschließend erfolgt eine Laborfreigabe
und eine Auftragsbestätigung wird zum Kunden gesendet. Nachfolgend wird die
Probe im Labor analysiert. Die Arbeitsplatzfolge des Probendurchlaufs wird von2 Beschreibung und Analyse des aktuellen Systems 6
Abb. 2.1: Die Aufgaben des AGROLAB LIMS im Überblick
der Laborleitung im LIMS konfiguriert. Sobald die Messergebnisse feststehen, wer-
den diese in das Oracle-Datenbanksystem über eine Java-Anwendung eingefügt.
Wenn alle Proben eines Auftrags analysiert sind, wird dieser automatisch als ab-
geschlossen markiert und von den Kundenbetreuern eingesehen. Dort kann der
CRM sowohl Rechnungen als auch Befunde erstellen und über eine zusätzliche
Oberfläche die gewünschte Versandart wählen. Zur Report-Generierung wird ak-
tuell ein weiteres Oracle Produkt namens Oracle Reports verwendet. [agrb]
Besonders wichtig ist hier zu erwähnen, dass jeder Standort zwar mit dem gleichen
LIMS arbeitet, dieses jedoch individuell konfiguriert werden kann. Der Hauptnut-
zer des Systems ist somit das Unternehmen selbst. Anforderungen und Änderungs-
vorschläge werden deshalb meist von hausinternen Mitarbeitern vorgebracht. In
den letzten Jahren wurden somit viele Anpassungen und Erweiterungen am Sys-
tem durchgeführt, sodass es sich langsam zu einem Monolithen entwickelt hat und
nun in eine neue Microservice basierte Architektur überführt werden muss.
Die vielen Standorte und Abteilungen des Unternehmens bringen natürlich auch
eine große Anzahl an Nutzern mit sich, die auf irgendeine Weise verwaltet wer-
den müssen. Microsofts Active Directory wird derzeit zur Authentifizierung und
Autorisierung verwendet.2 Beschreibung und Analyse des aktuellen Systems 7
2.2 Active Directory
Active Directory (AD) ist ein von Microsoft hergestellter Verzeichnisdienst bzw. eine
Datenbank zur Verwaltung von Zugriffsrechten in einem Netzwerk. Das Hauptziel
des Services ist die Authentifizierung von Nutzern. Hierbei wird sichergestellt, dass
nur autorisierte Personen Zugriff auf Netzwerkressourcen haben. Die Einstellun-
gen werden in einem sogenannten Domain Controller (DC) konfiguriert, sodass bei
einer Anpassung diese nur einmalig zentral abgeändert werden müssen. Wenn bei-
spielsweise eine Passwortänderung eines Nutzers durchgeführt werden soll und
keine zentrale Konfigurierung möglich ist, müsste die Operation bei jedem Rechner
einzeln ausgeführt werden. [acta]
Die einzelnen Elemente werden intern als Objekte mit Attributen gespeichert. In-
”
tern“ bedeutet in diesem Fall in der eigenen Domäne. Darunter fallen beispielsweise
Ressourcen wie Computer und Drucker, aber auch Benutzerkonten, Gruppen und
Zugriffsrechte. Im AD-Verzeichnis gibt es mehrere Möglichkeiten Objekte zu klassi-
fizieren. Besonders erwähnenswert sind hier die Container und die Organizational
Unit (OU).
Abb. 2.2: Darstellung der einzelnen Komponenten im Active Directory2 Beschreibung und Analyse des aktuellen Systems 8 Der Hauptunterschied zwischen beiden Typen ist, dass nur OU erstellt und ihnen Gruppenrichtlinien zugewiesen werden können. Container sind hingegen vordefi- niert. [actb] Hervorzuheben sind: Computers, Users, ForeignSecurityPrincipals und Managed Service Accounts. Neue Rechner, die ins Netzwerk aufgenommen wer- den, werden automatisch in der Computers-Kategorie erfasst und sollten zu einer selbst erstellten OU hinzugefügt werden. In der Users-Kategorie befinden sich alle existierenden Nutzer sowie Standardnutzer, wie zum Beispiel das Administratoren- oder das Gastkonto. Auch Sicherheitsgruppen werden hier gespeichert. Natürlich besteht auch die Möglichkeit mehrere Domänen zusammenzufügen. Um dies zu ermöglichen, müssen sich diese untereinander vertrauen, wodurch anschließend die Objekte der jeweils anderen Domäne im ForeignSecurityPrincipals-Container angezeigt werden. Die ManagedServiceAccounts-Kategorie ist für Dienstkonten gedacht. Das sind Nutzerkonten, die dauerhaft aktiv sein müssen und von einer Anwendung selbst verwendet werden. [acta] OUs hingegen werden zur Gruppierung von Objekten verwendet. Diese können je nach Anwendungsfall von einem Administrator erstellt und auch dementspre- chend gefüllt werden. Ein gutes Beispiel ist hierbei eine IT-OU. Alle Mitarbei- ter der Abteilung können in dieser aufgenommen werden und über konfigurier- te Gruppenrichtlinien Zugriffsrechte zugewiesen bekommen. Natürlich existieren auch vordefinierte Organisationseinheiten, wie zum Beispiel die einzelnen DCs. Im Unternehmen selbst kommunizieren viele Services mit dem AD über das Light- weight Directory Access Protocol (LDAP). Dieses Sicherheitsprotokoll wird im späteren Verlauf der Arbeit genauer analysiert. 2.3 Interne Authentifizierung Wie läuft nun der Authentifizierungsprozess ab und welche Applikationen kom- munizieren überhaupt mit dem System? Bevor diese Fragen beantwortet werden können, muss die AD-Struktur des Unternehmens genauer betrachtet werden. Wenn ein Client auf den Service zugreifen möchte, wird dieser über die Adresse:
2 Beschreibung und Analyse des aktuellen Systems 9
agrolab.world “erreicht. Hinter dieser stehen fünf DCs, die alle die gleichen Infor-
”
mationen gespeichert haben. Es spielt keine Rolle, welcher angesprochen wird, da
alle untereinander konsistent sind und somit nur ein Verfügbarkeitsthema vorliegt.
Die AGROLAB GmbH hat sich in den letzten Jahrzehnten ständig erweitert, sodass
mehrere Domänen im Verzeichnisdienst zusammengeführt wurden. Eine Verein-
heitlichung der entstandenen Anpassungen hat jedoch nie stattgefunden, sodass es
kein erkennbares Schema gibt, das abgebildet werden kann. Applikationen wie das
LIMS, das firmeninterne Wiki und natürlich die Rechner selbst sind an den Service
gebunden. Das Grundprinzip einer Authentifizierung wird in 2.3 gezeigt.
Abb. 2.3: Authentifizierungsablauf beim Active Directory
Ein Nutzer meldet sich mit seinen AD-Credentials über eine Oberfläche an. Im
Hintergrund kommuniziert die Applikation über ein Protokoll mit dem Verzeich-
nisdienst. Wenn der Nutzer gefunden wird und die Eingabedaten bestätigt wurden,
ist dieser nun dazu berechtigt auf die Ressource zuzugreifen. Erfolgt hingegen kei-
ne Bestätigung, gilt der Anwender als nicht authentifiziert und hat somit nicht die
nötige Berechtigung um Zugriff zu erlangen.
Zur Kommunikation innerhalb der Firma werden hauptsächlich Microsoft Pro-
dukte wie Outlook und Skype for Business verwendet, die sich gut an das AD
anbinden lassen. Für die Konfiguration und Wartung ist der externe Dienstleister
OSYON zuständig, die IT-Abteilung selbst kann keine Änderungen an der Struk-
tur durchführen, besitzt jedoch die Möglichkeit lesend darauf zuzugreifen. Wenn2 Beschreibung und Analyse des aktuellen Systems 10 eine Anpassung trotzdem notwendig ist wie zum Beispiel bei der Integration eines neuen Tools, muss diese bei OSYON selbst angefordert werden. Durch diese hohe Komplexität des Verzeichnissystems und der Vielzahl an verknüpften Applikatio- nen wurde beschlossen, dass auch bei der neuen Architektur das alte Verzeichnis- system weiterhin unterstützt werden soll. Ein Konzept für die Nutzerauthentifizie- rung und der Authentifizierung zwischen den einzelnen Microservices ist daher unerlässlich.
3 Beschreibung des Zielsystems 11
3 Beschreibung des Zielsystems
Wie bereits beschrieben hat sich das AGROLAB LIMS in den letzten Jahren stark zu
einem Monolithen entwickelt und soll nun mit Hilfe einer Microservice basierten
Technologie modularisiert werden.
3.1 Microservices
In short, the microservice architectural style is an approach to develo-
”
ping a single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often
an HTTP resource API. “ [mica]
Microservices ist also ein Architekturstil, der versucht eine einzige Anwendung
in mehrere kleine, voneinander unabhängige Services zu trennen. Jeder Service
soll hier für einen einzigen Prozess stehen, der nur für eine spezielle Aufgabe
zuständig ist. Die Wartbarkeit und Testbarkeit wird durch die geringe Komple-
xität garantiert. Bei Erweiterungen können diese weiterhin geteilt werden, da sie
schließlich immer unabhängig voneinander arbeiten und über ein einfaches Pro-
tokoll wie zum Beispiel Representational State Transfer (REST) kommunizieren.
Dies erleichtert ebenfalls das Verteilen einer neuen Anwendungsversion, da nur
der geänderte Service ausgetauscht werden muss, solange dieselben Schnittstellen
vorhanden sind. [micb]
Die IT-Abteilung des Unternehmens hat beschlossen nun schrittweise das alte mo-
nolithische System in einzelne Services zu unterteilen. Ein Projektteam beschäftigt
sich bereits ausführlich mit der Implementierung der ersten Anwendungen. Als3 Beschreibung des Zielsystems 12
Framework wird hier das Open-Source Projekt Spring Boot verwendet, das auf
Java basiert und sich heutzutage bei vielen Unternehmen durchgesetzt hat. Die
Unabhängigkeit der einzelnen Services spielt bei der Verteilung der Applikation
eine wichtige Rolle. Bei einer Änderung im Programm muss aktuell das gesamte
System kurzzeitig ausgeschaltet werden um auf eine neue Version zu aktualisieren.
Bei einem Fehlverhalten einer einzigen Funktion kann das gesamte System unter
Umständen ausfallen. Im Microservice-Umfeld wird bei einer nötigen Änderung
nur der jeweils betroffene angepasst und erneut an die Standorte verteilt. Dies
senkt die Ausfallzeit und ermöglicht zudem eine bessere Behandlung von Fehlern.
Das Deployment der einzelnen Applikationen erfolgt in Form von Containern, die
durch die Open-Source Entwicklung Docker erstellt werden.
3.2 Docker
Anwendungscontainer können darüber hinaus in völlig identischer
”
Form auf verschiedenen Systemen laufen. Fehler der Kategorie auf dem
”
anderen Rechner lief es aber“ verlieren daher an Bedeutung. “ [doc]
Ein Container ist eine Art virtuelle Maschine und soll genau dieses Problem behe-
ben. Er beinhaltet alle Informationen und Abhängigkeiten, die zu einem problem-
losen Start der Applikation auf jedem System benötigt werden. Im Gegensatz zu
einer normalen virtuellen Maschine besitzen Container kein eigenes Betriebssystem
und keinen eigenen Kernel, wodurch sie kompakt sind und mit wenig Ressourcen-
aufwand Endbenutzern zur Verfügung stehen. [doc] Vor allem die Microservice-
Architektur lässt sich gut mit der Verwendung von Containern kombinieren. Jeder
Dienst kann in einem eigenen Container laufen und durch die starke Kapselung
problemlos verteilt werden. Ein weiterer Vorteil ist die Verwaltung der Skalierbar-
keit. Wird ein Dienst aufgrund der aktuellen Saison beispielsweise öfter benötigt,
können mehrere Instanzen gestartet werden, um die Vielzahl an Anfragen abzuar-
beiten, und gegebenenfalls anschließend wieder abgeschaltet werden. Kommuni-
kation spielt in beiden Konzepten eine wichtige Rolle und erfordert somit ein gutes3 Beschreibung des Zielsystems 13 Authentifizierungs- und Autorisierungskonzept.
4 Authentifizierung und Autorisierung 14
4 Authentifizierung und
Autorisierung
Um ein gutes Schema zu erstellen, müssen zunächst bekannte Sicherheitsprotokolle
sowie Autorisierungsansätze analysiert und erläutert werden.
4.1 Begriffserklärung
Vielen Entwicklern ist der Unterschied zwischen Authentifizierung und Autori-
sierung nicht klar, sodass die Begriffe manchmal im falschen Kontext verwendet
werden. Prinzipiell lässt sich die Authentifizierung als die Prüfung der Authen-
tisierung einer Person beschreiben. Damit ist die Verifikation der Identität des
Nutzers gemeint. Solche Nachweise können geheime Informationen, wie zum Bei-
spiel ein Passwort, eine Antwort auf eine Sicherheitsfrage, der Personalausweis,
der Reisepass, der Führerschein oder der Fingerabdruck sein. Diese werden an-
schließend vom Authentifizierungsservice auf Richtigkeit überprüft. Dieser Ablauf
erfolgt meist mit Hilfe eines Login-Prozesses. [aaa]
Im Anschluss findet die Autorisierung der Person statt. Je nach Ausgang der Anmel-
dung werden dieser Nutzerrechte zugewiesen oder verweigert. Eine erfolgreiche
Anmeldung bedeutet jedoch nicht, dass der Nutzer alle zur Verfügung stehenden
Funktionalitäten automatisch verwenden kann. In den meisten Fällen weist der Au-
torisierungsprozess dem Benutzer verschiedene Rechte in Form von Rollen oder
Attributen zu. [aaa]4 Authentifizierung und Autorisierung 15
4.2 Protokolle für Authentifizierungs-und
Autorisierungsprozesse
4.2.1 LDAP
LDAP ist ein altes, einfaches Authentifizierungsprotokoll, das den Zugriff auf Infor-
mationen in einem Verzeichnisdienst wie zum Beispiel Active Directory ermöglicht.
Operationen wie das Hinzufügen, Löschen sowie das Modifizieren von Einträgen
werden durch das Protokoll unterstützt. Wie und wo die Daten gespeichert werden,
wird jedoch nicht erfasst. [ldaa]
Abb. 4.1: Aufbau eines LDAP-Systems
Ein LDAP-System hat einen hierarchischen, aus mehreren Einträgen bestehenden
baumartigen Aufbau. Das Wurzelelement wird in den meisten Fällen als Basis be-
zeichnet und stellt den obersten Punkt der Struktur dar. Jeder Eintrag besteht aus
einer Objektklasse, welche wiederum mit Kindeinträgen erweitert werden kann.
Hier entsteht eine Vater-Kind Beziehung zwischen den einzelnen Elementen, so-
dass die Attribute weitervererbt werden. Eine Objektklasse muss einen eindeuti-
gen Namen haben und steht für einen Container von Eigenschaften. Die Klasse
beschreibt welche Attribute optional und welche verpflichtend sind. Eine Vielzahl
von Standard-Objektklassen wird in LDAP-Systemen vorgegeben und kann sogar4 Authentifizierung und Autorisierung 16
als eigener Teil der Hierarchie verwendet werden. Attribute besitzen in der Regel
einen Namen und einen Datentyp. Mit Hilfe der Attributeinträge muss eine Hier-
archiestufe immer eindeutig identifiziert werden können.
Ein Beispiel eines LDAP-Systems wird in 4.1 gezeigt. Agrolab ist in diesem Fall
eine definierte Objektklasse. In dieser Organisation existieren zwei OUs, die IT und
die CRMs. Eine Person mit dem Attribut cn=Marco“ ist Teil der IT. CN ist hier ein
”
Standardattribut in LDAP-Systemen und steht für common name“. Der Pfad ei-
”
ner Hierarchiestufe wird als RDN bezeichnet und steht für Relative Distinguished
”
Name“. Um nun Zugriff auf die Person zu erhalten müssen im Protokoll alle rela-
tiven Pfade, die von der Wurzel aus zur gesuchten Person führen, angegeben wer-
den. Dieser Pfad wird als Distinguished Name (DN) bezeichnet und identifiziert
ein LDAP-Objekt eindeutig. Das Protokoll hat somit den DN: cn=Marco, ou=IT,
o=Agrolab und greift so auf die Person im Authentifizierungsprozess zu. [ldab]
Angenommen ein Dienst authentifiziert seine Nutzer über einen mit LDAP kom-
munizierenden Verzeichnisdienst. Dann wird zunächst unter Verwendung der An-
meldeinformationen der Eintrag im Verzeichnis über den DN gesucht. Bei einem Er-
folg kann in einem zweiten Schritt das Passwort validiert werden. Im Hintergrund
wird der LDAP-Befehl bind“ausgeführt, der eine Authentifizierungsanfrage an
”
den Verzeichnisdienst sendet. Dieser Request beinhaltet zum einen den DN und
zum anderen das Passwort des Nutzers. Wenn die Nutzerdaten übereinstimmen,
wird Zugriff gewährt, ansonsten erfolgt eine Fehlermeldung des Services.
4.2.2 Open Authorization
Open Authorization (OAuth) 1.0 ist ein offenes Protokoll für standardisierte, siche-
re Application Programming Interface (API) Autorisierung. Das Protokoll wurde
2007 anfangs für die Twitter API entworfen, ziemlich schnell jedoch durch dessen
Nachfolger OAuth 2.0 aufgrund von einigen aufgetretenen Schwächen abgelöst.
Durch dieses Protokoll ist es einem Nutzer möglich einer Anwendung Zugriff auf
seine Daten zu erlauben, die von einer Drittanwendung bereitgestellt werden, ohne
Anmeldedaten preiszugeben.4 Authentifizierung und Autorisierung 17
Die neue Version des Protokolls zielt auf dieselbe Funktionalität, ist jedoch nicht
abwärtskompatibel, da es sich um ein komplett neues Protokoll handelt. Beispiels-
weise werden keine kryptografischen Signaturen für die Kommunikation zwischen
Maschinen mehr verwendet und damit der Implementierungsaufwand für die In-
tegration in eine Anwendung deutlich gesenkt. Dies ist jedoch zugleich eines der
Hauptkritikpunkte an dem neuen Protokoll, da der Sicherheitsaspekt keinen so
hohen Stellenwert erhält. Weitere Neuerungen sind zum Beispiel die Einführung
von Refresh-Token, mit denen es möglich ist den Access-Token zu erneuern ohne
den gesamten Anmeldeablauf neu durchzuführen. Das Gewähren der Rechte wird
durch sogenannte Grant-Types erfüllt. Diese werden in OAuth unterstützt und
können in den Anwendungen integriert werden. [oaua] In 4.2 ist der Standardab-
Abb. 4.2: Überblick über den OAuth 2.0 Ablauf
lauf dargestellt.
Zunächst müssen die am Prozess beteiligten Rollen definiert werden.4 Authentifizierung und Autorisierung 18
Rolle Kurzbeschreibung
Resource Owner Nutzer, der einem Client Zugriff auf geschützte Daten
erteilt.
Resource Server Ort, an dem die geschützten Daten liegen.
Client Anwendung, die auf geschützte Daten zugreifen will.
Authorization Server Authentifiziert den Resource Owner und stellt Token aus.
Tab. 4.1: Beteiligte Rollen des Open Authorization Protokolls
Wenn ein Nutzer einem Client Zugriff auf Daten einer Drittanwendung ertei-
len möchte, muss dieser in der Regel auf einen Verbinden mit“-Button drücken.
”
Im Hintergrund wird eine Anfrage an den Authorization-Server gestellt und die
Umleitadresse mitgesendet. Der Resource-Owner muss sich anschließend bei die-
sem mit seinen Anmeldedaten authentifizieren. Im Anschluss wird dem Nutzer
ein Fenster angezeigt, in dem er der Client-Applikation den Zugriff auf gewis-
se Informationen bestätigen muss. Ein kurzlebiger Authorization code wird an die
vorher bekannt gemachte Umleitadresse gesendet und kann vom Client verwendet
werden um sich ein Access- und ein Refresh-Token vom Authorization Server aus-
stellen zu lassen. Mit dem Access-Token kann der Client nun auf die gewünschten
Daten des Resource Server für eine gewisse Zeit zugreifen, bis die Gültigkeit des
Tokens abläuft. Das Refresh-Token kann hier verwendet werden um ein neues zu
erhalten, ohne den gesamten Prozess neu ausführen zu müssen. [oaub]
OAuth war ursprünglich nur als Autorisierungsprotokoll gedacht und hat nichts
mit der Authentifizierung zu tun. Das Access-Token ist jedoch nicht für den Client
relevant, sondern nur für den Resource Server. Dieser muss nicht einmal wissen,
welche Anwendung Daten beansprucht. Er muss nur das Token validieren und
eine Antwort verfassen. Zudem präsentiert das Access-Token nicht einen Nutzer
und sagt auch nichts über den Authentifizierungsstatus aus. Es beschreibt nur die
erlaubten Zugriffe und sollte nicht für Informationen über den Nutzer missbraucht
werden. Für den Authentifizierungsaspekt sind Erweiterungen des Protokolls wie4 Authentifizierung und Autorisierung 19
zum Beispiel OpenID Connect (OIDC), das im folgenden Abschnitt beschrieben
wird, entwickelt worden. [oaub]
4.2.3 OpenID Connect
OIDC ist ein Authentifizierungsprotokoll, das auf OAuth aufsetzt und einige Er-
weiterungen mit sich bringt. Ein ID-Token sowie eine Nutzerdatenschnittstelle
werden zur Verfügung gestellt. Im Gegensatz zum normalen OAuth-Ablauf erhält
der Client nicht nur ein Refresh- und ein Access-Token, sondern noch zusätzlich
ein ID-Token, in dem Daten, die von der Applikation zur Nutzerauthentifizierung
verwendet werden können, stehen. Bei dem ID-Token handelt es sich immer um ein
JSON Web Token (JWT). Dieses besteht grundsätzlich aus drei Teilen, dem Header,
dem Payload und der Signature. Der Aufbau wird in 4.3 verdeutlicht.
Abb. 4.3: Aufbau eines JWT
Wie der Name des Tokens impliziert, ist es im JSON-Format geschrieben. Im Hea-
der befindet sich der Typ sowie der Algorithmus, der zum Signieren verwendet
wird. Im Body, der auch oft als Payload bezeichnet wird, sind die Hauptinforma-
tionen des Nutzers wie zum Beispiel dessen Name, Email oder ID gespeichert.
Diese einzelnen Attribute werden als Claims bezeichnet. Einige Standard-Claims
werden bereits von der OIDC-Spezifikation vorgegeben, es können jedoch auch4 Authentifizierung und Autorisierung 20
eigene erstellt werden. Der dritte Teil beinhaltet die digitale Signatur. Diese wird
mit dem im Header genannten Algorithmus, dem Header selbst, dem Payload und
einem geheimen Schlüssel generiert. Das gesamte Token wird anschließend base64
kodiert und die einzelnen Teile mit einem Punkt separiert. Die Client-Anwendung
kann das Token dekodieren und auf die Information zur Identitätsüberprüfung
zugreifen. [aut]
Bei der Implementierung von OIDC muss zudem noch ein sogenannter User-Info
Endpunkt bereitgestellt werden, der zum Erlangen von weiteren Informationen
über den angemeldeten Benutzer angesprochen werden kann. Die Applikation
kann anschließend eine Anfrage mit einem Scope an diese Adresse senden. Ein
Scope ist ein vordefinierter Rahmen, der bestimmte Claims als Rückgabe erwartet.
Wenn eine Anfrage mit dem Scope: email“ gesendet wird, erhält die Anwendung
”
beispielsweise die E-mail-Claims: email und email verified. Anders als bei OAuth
besitzt der Programmierer bei der Anbindung von OIDC weniger Freiheiten, da
strikte Rahmenbedingungen wie die Form des ID-Tokens oder die vordefinierten
Scopes und Claims bei Informationsabfragen unterstützt werden müssen. Zusam-
menfassend ist zu sagen, dass OAuth allein für die Autorisierung und somit die
Zuteilung von Rechten zuständig ist, während OIDC für das Abfragen von Nutzer-
informationen und somit für die Authentifizierung eingesetzt wird. [oauc]4 Authentifizierung und Autorisierung 21
4.3 Autorisierungsansätze
Neben den verwendeten Protokollen spielt im Punkt Autorisierung ein gutes Kon-
zept für die Zugriffskontrolle eine wichtige Rolle. Es gibt einige Ansätze, die sich
mit dem Access-Management beschäftigen, wobei die zwei bekanntesten das Role-
based Access Control (RBAC) und das Attribute-based Access Control (ABAC)
sind. Diese beiden Ansätze werden im Rahmen dieser Arbeit erläutert und mitein-
ander verglichen. Zudem wird überprüft, inwiefern beide Konzepte vereint werden
können.
4.3.1 Rollenbasierter Ansatz
Beim RBAC werden Privilegien über Rollen abgebildet. Diese sollen eine bestimmte
Identität abstrahieren und verhindern, dass jedem einzelnen Nutzer Rechte zuge-
wiesen werden müssen. Das Erstellen der Rollen kann vor allem in großen Unter-
nehmen sehr schwierig sein, da es eine Vielzahl von Funktionen und Zuständigkeits-
bereiche im Rahmen des Geschäftsprozesses gibt, was die Komplexität bzw. die
Individualität einer Rolle deutlich erhöht. Der Autorisierungsprozess besteht aus
zwei Zuweisungen, wie in Abbildung 4.4 zu sehen ist.
Abb. 4.4: Prinzip des RBAC [rba]
Zunächst einmal müssen die unterschiedlichen Komponenten des Modells auf-4 Authentifizierung und Autorisierung 22
gezeigt werden. Ein User ist in diesem Fall ein Nutzer oder auch Computer be-
ziehungsweise Prozess, der auf eine Ressource zugreifen möchte. Eine Rolle ist
die Funktion einer Person in der Organisation. Als Berechtigung wird die Aner-
kennung eines gewissen Zugriffsrechts auf ein Objekt bezeichnet, die an Rollen
geknüpft ist. Wenn ein Nutzer eine Operation auf ein Objekt durchführen möchte,
werden in einer Sitzung zur Laufzeit seine in Rollen gekapselte Berechtigungen
mit den zur Durchführung benötigten verglichen und dementsprechend der Zu-
griff gewährt beziehungsweise verweigert. [acca] Das National Institute of Stan-
dards and Technology (NIST) ist eine Behörde, die für Standardisierungsprozesse
in den Vereinigten Staaten zuständig ist. Diese hat ein eigenes Referenzmodell für
die RBAC entwickelt, das in dieser Arbeit dargestellt wird. Es wird zwischen vier
unterschiedlichen Varianten differenziert.
Das Basisschema wird als Flat RBAC bezeichnet und beinhaltet die Standardkon-
zepte des Ansatzes. Einem User können mehrere Rollen zugeteilt werden, die
wiederum aus mehreren Berechtigungen bestehen um Operationen auf Objekte
durchführen zu können. Dieses Modell unterstützt somit eine n:n-Beziehung zwi-
schen Nutzern und Rollen. Dadurch ist es immer möglich herauszufinden, welche
Rollen einem User zugeordnet sind und welche User eine gewisse Rolle besitzen.
Dies wird als user-role preview“ bezeichnet. Dieses Modell besitzt somit eine
”
Rollenzuweisung und eine Berechtigungszuweisung. Es definiert kein Schema für
eine richtige Sitzungsverwaltung, da dies von System zu System unterschiedlich
abgewickelt werden kann. In manchen werden beim Erstellen einer Sitzung al-
le Rollen des Nutzers aktiviert, während bei anderen dies konfiguriert werden
kann. [SFK00]
Die nächste Stufe ist das Hierarchical RBAC, das zusätzlich eine hierarchische
Ordnung der Rollen definiert. Die meisten Unternehmen bauen diese nach ihrer
internen Struktur auf. Dadurch entsteht eine transitive Beziehung zwischen den
einzelnen Rollen. Eine übergeordnete Rolle besitzt somit alle Berechtigungen der
hierarchisch darunter liegenden. Es muss nicht unbedingt nur eine einzige hier-
archische Struktur vorliegen. Es können auch mehrere voneinander unabhängige4 Authentifizierung und Autorisierung 23
Baumstrukturen existieren, sodass es immer noch als hierarchisches Modell be-
zeichnet wird. [SFK00]
Das Constrained RBAC bringt eine Verstärkung des Prinzips Separation of Duty
(SOD) mit sich. Dies hat hauptsächlich Auswirkungen auf die Rollenzuweisung
der Nutzer und basiert auf dem Least privilege-Prinzip. Nach diesem Ansatz soll
ein User nur auf die für seine Haupttätigkeit benötigten Funktionen zugreifen
können. Dadurch wird verhindert, dass ein Nutzer zu viele Rechte erlangt und
dadurch schädliche Operationen durch Nebeneffekte auslösen kann. Diese Ein-
schränkungen können entweder statisch oder dynamisch erteilt werden. Die Ertei-
lung erfolgt bei der statischen Variante über die Rollenzuweisung. Wenn ein Nutzer
mehrere Rollen, die durch eine Richtlinie jedoch nicht miteinander verbunden wer-
den dürfen, erhalten möchte, wird dies bereits bei der Zuweisung blockiert. Bei der
dynamischen Variante kann ein User zwar diese Rollen besitzen, jedoch wird in der
Sitzung überprüft, ob ein Nutzer zwei nicht gleichzeitig nutzbare Berechtigungen
verwendet. Dieses Konzept kann beispielsweise bei Akkreditierungsprozessen hel-
fen. Wenn eine Vorschrift besagt, dass das Aufgeben und das Annehmen eines Auf-
trags nicht von der gleichen Personen durchgeführt werden darf, dann kann durch
eine aktiv geschaltete Regel dies auditiert und nachgewiesen werden. [SFK00]
Das Symmetric RBAC ist laut NIST die höchste Stufe und fügt dem Flat RBAC-
Modell noch eine sogenannte role-permission preview“ hinzu. Bei diesem Ansatz
”
muss ein Interface, das die Beziehungen zwischen Berechtigungen und Rollen so-
wie Operationen anzeigt, vorhanden sein. Dadurch ist es einfacher nicht benötigte
Erlaubnisse zu identifizieren und diese anschließend zu entfernen. [SFK00]
4.3.2 Attributbasierter Ansatz
Ein Problem, das das Rollenmodell mit sich bringt, ist seine mangelnde Skalier-
barkeit. Angenommen ein CRM soll beispielsweise nur Aufträge in den Bereichen
Wasser, Boden und Hopfen für Standorte in Kiel, Bruckberg und Leinefelde er-
fassen dürfen. Bereits diese kleine Einschränkung würde eine Vielzahl von Rollen
benötigen um alle möglichen Kombinationen abzudecken. Deshalb wurde in den4 Authentifizierung und Autorisierung 24
letzten Jahren ein attributbasierter Ansatz als Berechtigungskonzept immer bedeu-
tender. Das ABAC besitzt laut NIST folgende Komponenten:
• Attribute: Können Nutzercharakteristiken, Objektcharakteristiken oder auch
Aktionen definieren.
• Subjekt: Ein User oder auch eine Ressource, die Aktionen in einem Netzwerk
durchführen kann.
• Objekt: Gespeicherte Daten in einem Netzwerk.
• Operation: Eine Aktion, die von einem Subjekt durchgeführt wird.
• Policy: Vielzahl an Regeln, die Aktionen von Subjekten einschränken.
Bei diesem Konzept wird eine Policy mit Regeln im Unternehmen definiert. Diese
verwaltet die Berechtigungen im System. Besitzt ein Nutzer und eine Ressource ein
durch eine Regel definiertes Attribut, kann Zugriff gewährt werden. [acca]
4.3.3 Fazit zu beiden Ansätzen
Letzten Endes lässt sich sagen, dass beide Systeme ihre Vor -und Nachteile haben.
Das RBAC ist beispielsweise vor allem für kleine Unternehmen einfach zu erstel-
len, es besitzt eine einfache Berechtigungsüberprüfung und ist gut für Auditierung
geeignet, da jederzeit statisch abgefragt werden kann, wer auf welche Ressource
zugreifen kann. Da das Schema meistens nach Geschäftsrollen aufgebaut ist, kann
sich ein Business-Owner zudem relativ schnell in das System einarbeiten und Au-
torisierungprozesse verstehen.
Die Schwierigkeit bei diesem Modell ist die Erstellung einer guten Struktur, für
die bereits zu Beginn alle Rollen und Ressourcen bekannt sein müssen. Eine zu
feingranulare Trennung der einzelnen Berechtigungen kann sehr schnell zu einer
hohen Anzahl an Rollen führen, sodass der Überblick verloren geht. Um dies zu
verhindern sollten nicht für jeden Sonderfall Rollen erstellt werden, um das Risi-
ko zu minimieren, dass nur ein paar Personen sich in dieser befinden. Dies steht4 Authentifizierung und Autorisierung 25 natürlich im Widerspruch zu dem Least privilege-Konzept und muss dementspre- chend abgewogen werden. Beim ABAC hingegen wird die Skalierbarkeit sehr gut durch das einfache Hin- zufügen von Regeln gehandhabt. Das System ist ebenfalls sehr flexibel, da die Verwaltung zentral in einer Policy stattfindet und dadurch feingranular gearbei- tet werden kann um eine klare SOD zu erhalten. Berechtigungen von einzelnen Nutzern können dynamisch geändert werden und erfordern keine große Umstruk- turierung des gesamten Systems. Die zentrale Definition der einzelnen Regeln kann bei einer großen Anzahl zu einer hohen Komplexität führen, die speziell die Auditierung deutlich erschwert sowie einen hohen Wartungsaufwand beansprucht. [acca] 4.3.4 Hybrider Ansatz Nichtsdestotrotz sind die Vorteile beider Konzepte nicht zu vernachlässigen, sodass in letzter Zeit mehrere Ansätze entstanden sind beide miteinander zu kombinieren. Dies hat vor allem positive Auswirkungen auf größere Unternehmensstrukturen. Bei diesem Konzept sind im Laufe der Zeit drei unterschiedliche Varianten entstan- den, die beide Ansätze miteinander kombinieren. Zum Einen gibt es das Attribute-Centric Hybrid Model, in dem eine Rolle genauso wie ein weiteres Attribut, das einem Nutzer zugeteilt werden kann, behandelt wird und somit nicht wie beim RBAC für eine Sammlung von Rechten steht. Beim Auto- risierungsprozess kann dieses Attribut abgefragt werden, und überprüft werden, ob der User Teil einer gewissen Rolle ist. Auch wenn dieser Ansatz die Vorteile des ABAC mit sich bringt, ist der größte Vorteil des rollenbasierten Ansatzes nicht vertreten. Es besteht keine Möglichkeit ein einheitliches Schema der Zugriffsrechte zu erstellen, da es zwar Rollen gibt, diese jedoch wie Attribute behandelt wer- den. [hyb] Das Role-Centric Hybrid Model versucht diesen Nachteil zu kompensieren. Bei die- sem werden Nutzer Rollen zugeteilt und erhalten dadurch Zugriffsrechte. Zusätzlich
4 Authentifizierung und Autorisierung 26 können attributbasierte Policies hinzugefügt werden um weitere Einschränkungen für den einzelnen User zu definieren. Ganz wichtig ist hier zu erwähnen, dass die Zugriffsrechte nur eingeschränkt und nicht erweitert werden können. Dadurch ist eine hohe Flexibilität und Skalierbarkeit unter Beibehaltung einer Rollenstruktur verfügbar. Die Regeln werden wie beim ABAC in einem Repository aufbewahrt und können schnell angepasst werden. Die Auditierbarkeit ist bei diesem Ansatz ebenfalls kein Problem, da die Rollenstruktur nach dem Geschäftsmodell aufge- baut ist, sodass Business-Owner diese schnell verstehen können und einen bes- seren Überblick über die einzelnen Berechtigungen besitzen. Ein Nutzer, der die Rolle eines Auftraggebers beispielsweise besitzt, kann ein Attribut Standort zuge- teilt werden, das dynamisch gesetzt wird und den Arbeitsbereich des Users somit einschränkt. [hyb] Eine weitere Möglichkeit der Umsetzung bietet das Dynamic-Roles model. Bei die- sem werden Rechte wie beim RBAC Rollen zugeteilt. Die Zuweisung zwischen Usern und Rollen erfolgt anschließend über eine attributbasierte Regel. Dieses Konzept ermöglicht es Automatisierungsprozesse bei der Rollenzuteilung zu im- plementieren. Besitzt ein Nutzer beispielsweise gewisse Attribute wird diesem die dementsprechende Rolle zugeteilt. Bei einer Änderung kann die Rollenzuweisung automatisch abgeändert werden. Wenn beispielsweise ein Nutzer die drei Attri- bute Standort, Sprachraum und Position mit einem bestimmten Wert belegt hat, kann diesem direkt eine Rolle zugeteilt oder, je nach Regeldefinition, aberkannt werden. [hyb] [accb] Abschließend lässt sich sagen, dass in den vielen Fällen eine Kombination der un- terschiedlichen Ansätze gewählt wird. Das in dieser Arbeit verwendete Konzept wird im späteren Verlauf detaillierter betrachtet und die genaue Verwendung im Rahmen des Prototypen beschrieben.
5 Architektur und Spezifikation 27 5 Architektur und Spezifikation Da im letzten Kapitel auf einige Sicherheitskonzepte ausführlich eingegangen wur- de, wird nun die praktische Umsetzung im Rahmen der neuen Architektur näher betrachtet. 5.1 Anforderungen an das neue System Bisher werden alle Rollen und Gruppenzuweisungen auf dem AD-Server des Un- ternehmens verwaltet und an die Kernfunktionalitäten des LIMS angebunden. Eine Microservice Architektur erfordert jedoch eine konkrete Spezifizierung von Rech- ten und Privilegien. Folglich ergibt sich die Notwendigkeit der Konfiguration und Einstellung eines zusätzlichen Services, der unternehmensintern verwaltet wer- den kann. Eine Absprache mit dem externen Dienstleister ist ansonsten bei jeder kleinen Änderung nötig und treibt die Entwicklungsdauer sowie Komplexität des aus mehreren Domänen bestehenden AD unnötig in die Höhe. Die vorhandenen Strukturen sind komplex und in einigen Fällen nicht aussagekräftig genug, sodass die neue Architektur diese nicht einfach übernehmen kann, jedoch immer noch eine gewisse Anbindung an diese Useraccounts haben soll. Da nicht nur Microser- vices, sondern auch andere Applikationen wie das Projektmanagementtool JIRA oder der E-Mail-Client Outlook an diese gebunden sind, sollen auch diese weiter- hin über das AD verwaltet werden. Ein neues Authentifizierungsmodell kommt somit nicht in Frage. Die einzelnen Microservices benötigen jedoch einen eigenen Verwaltungsmechanismus, der unabhängig von LDAP-Gruppen konfiguriert wer- den kann um Zugriffsrechte innerhalb der Architektur zu gewährleisten. Der neue
5 Architektur und Spezifikation 28 Service soll somit für jegliche Authentifizierungsanfragen verfügbar sein und an sämtliche neu entwickelte Applikationen mit wenig Konfigurationsaufwand ange- bunden werden können. Eine Unterstützung von bekannten Sicherheitsprotokol- len ist natürlich ebenfalls unerlässlich um Prinzipien wie das Single Sign On (SSO) oder eine Zwei-Faktor-Authentifizierung (2FA) zu verwirklichen, die für User der neuen Anwendungen vonnöten sind. Die einzelnen Sitzungen der Nutzer müssen ebenfalls in irgendeiner Weise verwaltet werden können und durch eine passende Verschlüsselung gesichert werden um Man-in-the-Middle (MitM) Angriffen entge- genzuwirken. Natürlich soll der neue Service ebenfalls unterschiedliche Autorisie- rungsstrategien wie das RBAC bzw. ABAC unterstützen und mit den Frontend- und Backend-Frameworks kombinierbar sein. Dies ermöglicht eine zentrale Ver- waltung der Rollen und Attributen im Service. Die Anforderungen an das neue System werden in Tabelle 5.1 in einer Übersicht dargestellt.
5 Architektur und Spezifikation 29
Anforderung Kurzbeschreibung
Active Directory Anbindung des Services an den Verzeichnisdienst um auf
Nutzer, Gruppen und Rollen zugreifen zu können.
LDAP Ein sicherer LDAP Verbindungsaufbau soll zum Ver-
zeichnisdienst erstellt werden.
Clustering Der Service soll eine horizontale Skalierung unterstützen
um Verfügbarkeitsprobleme zu minimieren.
Protokolle Bekannte Authentifizierungsprotokolle sollen imple-
mentiert werden.
Gruppierung Der Service soll eigene Nutzer, Rollen und Gruppen er-
stellen und mit diesen Operationen durchführen.
Zugriffsrechte Rechte und Privilegien für die einzelnen Applikationen
sollen erstellt und zugeteilt werden.
Single-Sign-On Ein Nutzer soll sich nicht bei mehreren Services anmel-
den müssen.
Kompatibilität Der Service soll mit wenig Konfigurationsaufwand
mit dem Backend-Framework Spring Boot und dem
Frontend-Framework Angular kompatibel sein.
Sessionmanagement Der Service soll in der Lage sein aktuelle Sitzungen mit
Microservices anzuzeigen.
Verschlüsselung Der Service soll nur über sichere Verbindungen ansprech-
bar sein.
Zwei-Faktor- Der Service soll in der Lage sein einen Mechanismus für
Authentifizierung eine 2FA zu implementieren.
Tab. 5.1: Übersicht über die Anforderungen an das neue Authentifizierungsmodell5 Architektur und Spezifikation 30
5.2 Entwurf
Abb. 5.1: Entwurfsmodell für das neue Authentifizierungs- und Autorisierungs-
modell
Das in 5.1 dargestellte Modell visualisiert einen Entwurf für die mögliche Zu-
sammenarbeit der einzelnen Komponenten. Das AD soll wie in den Anforderun-
gen beschrieben mit einem neuen Service verbunden werden und dessen User,
Gruppen und Rollen importieren, sodass Applikationen, die nicht im Rahmen der
neuen Architektur entwickelt werden, immer noch problemlos verwaltet werden
können. In diesem Schema basiert die Kommunikation zwischen dem bereits vor-
handenen AD und dem neuen Service auf LDAP. Die einzelnen Applikationen und
User der neuen Microservice-Architektur stehen per REST in Verbindung mit dem
neuen Service, der jegliche Authentifizierungs- sowie Autorisierungsprozesse steu-
ert. Darunter fallen Aufgaben wie die Unterstützung von Protokollen wie OAuth
und OIDC, aber auch die Implementierung eines sicheren Datenaustausches zwi-
schen den einzelnen Instanzen. Diese Kommunikation basiert meistens auf einem
Tokenaustausch zwischen den einzelnen Komponenten. Wenn ein User sich bei-
spielsweise auf einer Frontend-Anwendung anmeldet, erhält dieser einen Token,
der im Anschluss von Backend-Applikationen verwendet wird um den Nutzer zu5 Architektur und Spezifikation 31 authentifizieren und zu autorisieren. Dadurch kann und wird das SSO umgesetzt, das bei einer Microservice Architektur aufgrund der Vielzahl an unterschiedlichen Services und Abhängigkeiten unerlässlich ist. Hinter dem neuen Authentifizierungs- und Autorisierungsservice stehen mehrere Instanzen, die untereinander Replikationen enthalten. Im Fall des Ausfalls eines Services sind immer noch Instanzen vorhanden, die zur Nutzerauthentifizierung angesprochen werden können. Verfügbarkeit ist bei diesem Modell ein wichtiges Thema, da bei einem Ausfall des kompletten Systems kein Microservice mehr in der Lage wäre mit einem anderen zu kommunizieren. Die einzelnen Nutzersitzungen können in diesem Modell ebenfalls verwaltet werden, da die Applikationen an den neuen Service gebunden werden und somit ein Logging prinzipiell möglich ist. Durch die zentrale Position können im neuen Service nicht nur bereits bestehende Privilegien des AD übernommen werden, sondern auch neue erschaffen werden. Durch die Replikation der einzelnen Instanzen besteht kein Problem Privilegien der Nutzer auszuwerten, da die komplette Rechte- und Rollenkonfiguration in diesem Service stattfindet.
6 Tools für die Umsetzung 32 6 Tools für die Umsetzung Für die Umsetzung der Anforderungen ist ein Framework vonnöten. Natürlich lie- ße sich ein komplettes Authentifizierungs- und Autorisierungssystem samt Server selbst implementieren, jedoch wäre dies eine sehr komplexe und zeitaufwändige Arbeit, die zudem noch sehr fehleranfällig wäre. Da die Entwicklung eines Si- cherheitsservices nicht zu den Kernkompetenzen des Unternehmens gehört, ist die Entscheidung auf ein externes Framework gefallen. Eine bekannte Lösung für ein solches System ist beispielsweise das Open-source Framework Apache Shiro. Dieses Projekt wurde 2008 von der Apache Foundation übernommen und bietet eine API für Sicherheitsmechanismen in Java-Applikati- onen. Das Framework unterstützt einige gewünschte Features, wie zum Beispiel die Authentifizierung durch LDAP oder die Autorisierung durch RBAC oder ABAC. Ein Problem bei der Verwendung dieses Security-Frameworks ist jedoch das Fehlen eines zentralen Servers. Das Framework bietet zwar einige Methoden um Proto- kolle und Zugriffsrechteverwaltung zu vereinfachen und einen Security Manager, der als zentraler Punkt agiert, benötigt jedoch trotzdem die Implementierung eines eigenen Servers und einer Datenbank um die einzelnen User, Sitzungen und Pro- zesse zu verwalten, was den Konfigurationsaufwand deutlich erhöht. [seca] Eine weitere Lösung stellt eine Cloudlösung dar. Hierbei gibt es mehrere Anbieter, wie zum Beispiel den Identity-Cloud Provider Okta. Dieser ermöglicht durch über 6.000 vorgefertigte Integrationen zu Applikationen einen sicheren Verbindungsauf- bau und Ablauf zwischen Personen und Diensten. User Management, SSO sowie bekannte Protokolle werden unterstützt und können einfach implementiert wer- den. [secb] Im Gegensatz zu Apache Shiro ist dieses Projekt kein Open-Source
6 Tools für die Umsetzung 33 Projekt und benötigt eine Lizenz um im kommerziellen Bereich verwendet werden zu können. Somit kommt dieses Framework ebenfalls nicht in Frage. Ein großer Nachteil bei dieser Art von Software ist, dass der Entwickler bei der Nutzung keine Möglichkeit hat Hintergrundprozesse bei Fehlern in der Implementierung einzusehen um ein besseres Verständnis zu erhalten. Somit muss ständig eine Zu- sammenarbeit mit dem Verkäufer stattfinden, was die Entwicklungsprozesse deut- lich verlangsamen und die Verfügbarkeit des Services einschränken kann. Dies darf jedoch bei einem Authentifizierungssystem nicht passieren, da ohne ein funk- tionierendes Authentifizierungssystem keine Autorisierung stattfinden kann und somit kein Microservice mehr miteinander kommunizieren kann. Durch die Anbin- dung des Systems an die Cloud kann ein Standort ohne Internetverbindung nicht selbständig arbeiten. 6.1 Keycloak Ein Open Source Projekt, das in den letzten Jahren im Bereich Microservices immer beliebter wurde, ist die von Red Hat geförderte Software Keycloak, deren erste Version 2014 auf den Markt kam. Sie besitzt einige Features wie zum Beispiel das SSO und unterstützt eine Vielzahl an Authentifizierungsprotokollen. Anders als bei Apache Shiro ist dieses Framework nicht nur auf Java-Anwendungen beschränkt, sondern bietet einige sogenannte Adapter für unterschiedliche Entwicklungsberei- che wie zum Beispiel Spring Boot oder Angular, die für Agrolab ausschlaggebend sind. Diese können in die jeweiligen Anwendungen per Import eingefügt wer- den und das Konfigurieren deutlich vereinfachen. Keycloak bietet ebenfalls einen eigenen Server, der auf JBoss basiert und sogar über ein eigenes Docker-Image ge- startet werden kann. Dieser agiert als Authentifizierungsservice sowie Nutzer und Rollenverwaltungsservice, der durch eine verbundene Datenbank alle User sowie Zugriffsrechte persistiert. Eine eigene Nutzeroberfläche vereinfacht ebenfalls das Erstellen und Verwalten des Systems. Die Entwickler des Projekts arbeiten sehr stark mit der Community über Foren und Ticketsystemen zusammen. Vor allem
6 Tools für die Umsetzung 34 die Tatsache, dass das Projekt Open-source ist, ermöglicht es vielen Anwendern die Abläufe im Hintergrund zu analysieren um Sicherheitslücken so schnell wie möglich zu melden, sodass diese geschlossen werden. Die hohe Anzahl an Updates zeigt, dass in dieses Projekt trotz der mittlerweile 7. Major-Version, die im August 2019 veröffentlicht wurde, immer noch viel Arbeit gesteckt wird und Anfragen der Anwender umgesetzt werden. [key] Um die Umsetzbarkeit der geforderten Bedingungen zu beweisen wird der Pro- totyp, welcher im Rahmen dieser Arbeit entworfen wird, mithilfe von Keycloak implementiert. Das Demo-Projekt sowie der Keycloak Server verwenden die im August erschienene Version 7.0.0.
Sie können auch lesen
