Übersicht

Von heutigen IT-Service-Architekturen wird ein hohes Maß an Sicherheit sowie eine zentrale, moderne Benutzerverwaltung erwartet. Neben sicherer Kommunikation ist die Authentifizierung von BenutzerInnen und Diensten wichtig. Bisher wurden zur Authentifizierung hauptsächlich passwortbasierte Verfahren verwendet. Ein neuer Trend geht nun jedoch in Richtung "passwordless" Techniken, die zwar noch selten, aber im häufiger Anwendung finden. Sie sind einfach zu bedienen und halten den gleichen Anforderungen an die IT-Sicherheit stand wie passwortbasierte Verfahren.

Im Rahmen eines DTLab-Projektes wurde ein Prototyp für das IT-Referat (RIT) der Landeshauptstadt München entwickelt, der die gemeinsame Verwendung des Standards FIDO2 und des Authentifizierungssystems für webbasierte Dienste, OpenID Connect, aufzeigen sollte. Zusätzlich wurde für die Kommunikation zwischen Microservices mit SPIFFE/SPIRE ein modernes Framework evaluiert, mit dem Ziel, sichere Ende-zu-Ende-Kommunikation zwischen Diensten zu ermöglichen. Am Projekt waren vier Studierendenteams des Masters IT-Sicherheit der HM Hochschule München University of Applied Sciences beteiligt.

Problem

Die Verwendung von Benutzernamen und Passwörtern ist bereits seit Jahrzehnten ein großes Problem. Sie bieten keinen 100%igen-Schutz und AngreiferInnen können sie durch Schadsoftware oder durch sogenannte "Social Engineering"-Angriffe leicht herausfinden und dadurch an persönliche Informationen von BenutzerInnen gelangen. Aus diesem Grund wurde der Standard FIDO2 entwickelt. Er bietet eine moderne Authentifizierung basierend auf Hardware- und Software-Tokens an. Jedoch beschreibt er nicht, wie diese Technologien in bestehende Authentifizierungsframeworks und in die Prozesse einer Organisation eingebunden werden sollen. Im Rahmen dieses Projektes sollten daher folgende Punkte erörtert werden:

• Wie kann FIDO2 in Kombination mit OpenID Connect eingesetzt werden?
• Welche technische Prozesse sind notwendig, damit MitarbeiterInnen einfach einen neuen Benutzer erstellen können?
• Wie kann ein Portal zur Selbstverwaltung aufgebaut werden?

Neben der Kommunikation mit dem Endanwender bedienen sich heutige Anwendungen oft einer sogenannten "Microservice"-Architektur. Aus IT-Sicherheitssicht ist hier oft das Problem, dass sich Anwendungen gegenseitig nicht stark authentifizieren, bzw. dass die Authentifizierung sogar komplett fehlt. Das SPIFFE/SPIRE-Framework bietet eine Möglichkeit, diese Authentifizierung auf "Microservice"-Ebene durchzuführen.

Lösungsansatz / Ergebnis

Die Projektgruppen entwickelten eine Beispielanwendung basierend auf einer "Microservice"-Architektur. Bei der Beispielanwendung handelte es sich um eine Webapplikation, welche mit einer Datenbank kommunizierte. Die Anwendungen liefen in einer selbstbetriebenen Kubernetes-Umgebung als Container. Als Identitätsmanagementlösung wurde die Open-Source-Lösung Keycloak verwendet.

Projektgruppe 1 beschäftigte sich mit dem Thema Identitäten und baute eine zentrale Instanz von Keycloak auf. Dabei wurden diverse Prozesse technisch implementiert, die aufzeigen sollten, wie eine moderne Benutzerauthentifizierung ohne Benutzername und Passwort funktioniert. Es wurden dabei auch Prozesse berücksichtigt, wie das Verlieren von FIDO2-Tokens oder das Hinzufügen von FIDO2-Tokens.

Die Architektur und der Betrieb der Infrastruktur basierend auf Kubernetes in AWS wurde von der Projektgruppe 2 realisiert. Dabei wurde eine SPIFFE/SPIRE-Umgebung implementiert und die einzelnen Dienste mit starken Authentifizierungsmerkmalen ausgestattet. Dadurch wurde gewährleistet, dass nur vertrauensvolle Instanzen miteinander kommunizieren dürfen.

Projektgruppe 3 beschäftigte sich mit der eigentlichen Anwendung und entwickelte eine "Single-Page"-Webapplikation. Diese Webapplikation wurde über Gitlab direkt in die AWS-Umgebung eingesetzt und nutzte Keycloak für das Benutzermanagement sowie die Authentifizierung der Benutzer.

Des Weiteren wurde während des Projektes eine Schwachstelle im Open-Source-Projekt Keycloak identifiziert. Diese wurde an Red Hat gemeldet und die CVE-Nummer CVE-2021-3632 vergeben. Eine Lösung wurde von der Projektgruppe bereitgestellt und von Red Hat veröffentlicht.

Prototypen

Die einzelnen Prototypen wurden auf dem Seclab-GitHub Account veröffentlicht.