Die Sicherheit von Webanwendungen steigern mit Spring Security, Keycloak und weiteren Schutzfunktionen.
Noch nie war Webanwendungssicherheit so umsatzentscheidend wie heute. Ganze Branchen sind im Digitalisierungssog angelangt. Und viele Softwareanbieter kommen kaum noch um ein SaaS-Modell ihrer Plattformen herum. Damit Services im Internet sicher und hier in Europa auch DSGVO-konform laufen, ist ein Blick auf die Risiken hilfreich, um dann entsprechende Präventivmaßnahmen einleiten zu können.
Die Non-Profit-Organisation „Open Web Application Security Project“ (OWASP) veröffentlicht jährlich ihre Top 10 der meisten Angriffe auf Webanwendungen und deren größten Risiken. Darunter fallen auch jene, die direkt mit dem Identitäts- und Zugriffsmanagement der Webanwendungen zusammenhängen. Es ist ein Teil der gesamten Sicherheit und heutzutage kann sich niemand mehr dabei einen Fauxpas erlauben. Die Nutzersicherheit ist das Zünglein an der Waage. Man riskiert sonst leicht einen Imageschaden, der kaum wieder gut zu machen ist. Mal davon abgesehen, wie teuer ein solcher Vorfall am Ende werden kann, wenn nicht sogar das ganze Geschäft davon abhängig ist.
Eine mangelhafte Zugangskontrolle ist die größte Gefahr
In 2021 nennt die OWASP als die größte Gefahr für Webanwendungen eine mangelhafte Zugangskontrolle („Broken Access Control“). Schon damit erhält man einen Eindruck, wie wichtig eine saubere Nutzerauthentifizierung ist. Die Empfehlung ist hier unter anderem den OAuth-Standard (Oauth 2.0) einzusetzen. Den kann man für eine Java-basierte Webanwendung mit dem Spring Security Framework implementieren. Dadurch ist es möglich die einfache Zugangskontrolle auf eine Anwendung von der Genehmigung durch die Anwendung selbst zu trennen. Diese Aufgabe übernimmt dann ein „Authorization Server“, der der Anwendung (Client) die Berechtigung eines Nutzers oder einer anderen Entität mitteilt und quasi die Genehmigung zum Zugriff ermöglicht. Die Anwendung vertraut der genehmigenden Instanz und erteilt dann selbst den Zugriff.
Spring Security ist keine allumfassende Lösung für das Access Management von Webanwendungen
Bei weitem jedoch reicht Spring Security nicht aus, um die Nutzersicherheit für Anwendungen im Netz zu garantieren. Warum nicht? Für jede angeschlossene Anwendung ist eine eigene Implementierung notwendig. Das kostet viel Zeit und erfordert höchste Konzentration bei jeder einzelnen Integration, die nur über Eigenprogrammierung läuft.
Out-of-the-box ist das Ganze schon mit Keycloak zu haben. D.h. weder muss man sich die Mühe machen es für jede weitere, angeschlossene Anwendung einzeln zu implementieren, noch muss man es überhaupt durch Programmierung implementieren.
Keycloak bietet OAuth 2.0 out-of-the-box
Besitzt man schon eine Spring Security-Implementierung in seiner Java-Anwendung, ist es einfach über den dafür vorgesehenen Keycloak Adapter die Multifunktionalität und den dadurch erhaltenen Komfort mit Keycloak hinzuzufügen. Mittelfristig unterstützt Keycloak jedoch keine Java Adaptoren mehr. Daher ist die Empfehlung jetzt sogar gleich beides miteinander einzusetzen und nicht stufenweise. Daher empfiehlt die Keycloak-Community den Einsatz von Spring Security.
Hier findet man weiterführende Infos zur Absicherung von Webanwendungen mit Spring Security 5 und Keycloak. Spring Security selbst entwickelt sich weiter und bietet bald (ab November 2022) eine Möglichkeit einen eigenen Server zur Authentifizierung aufzusetzen. Mehr darüber kann man hier erfahren.
Hinsichtlich dieser Funktion bleibt abzuwarten, ob das eine Alternative zu Keycloak werden könnte. Denn die Open-Source-Software bringt einiges an Features out-of-the-box mit, so dass es für alternative Anbieter schwer wird, mithalten zu können. Die eigene Keycloak-Admin-Konsole ist zum Beispiel ein ganz starkes Plus, warum viele weiterhin auf Keycloak setzen.
Keycloak kann wie Spring Security nicht die Rundum-Sicherheit für Nutzeridentitäten bieten.
Grundsätzlich ist es aber so, dass weder Spring Security noch Keycloak selbst einen unrechtmäßigen Zugang von unbefugtem Zugriff trennen können. Und genau das passierte weltweit im Dezember 2020: Zwei Wochen vor Weihnachten wurde die Kompromittierung der Security-Plattform Orion von SolarWinds durch die IT-Sicherheitsfirma FireEye entdeckt, da sie selbst von dem Hack betroffen war.
Die Angreifer beschafften sich den Single-Sign-On-Schlüssel. Und bewegten sich dann „hierarchisch“, d.h. mit entsprechenden Adminrechten versehen in der SolarWinds-Plattform. Dort installierten sie den sogenannten Sunburst-Trojaner, der mit einem Update bei allen Orion-Kunden ausgeliefert wurde. Im Überblick nachzulesen ist die Geschichte des folgenschweren Coups auf Spektrum.de.
Die Installation eines Trojaners ist mit der Trennung von Zugang und Zugriff nicht mehr möglich.
Das wäre nicht passiert, hätte SolarWind in ihrem System den Zugang, einfacher gesagt den Login, von der Genehmigung der Zugriffsrechte getrennt. Möglich wird das durch die Implementierung des Berechtigungsframeworks SecuRole®, was eine Ende-zu-Ende-Sicherheit gewährleistet. Hierbei entsteht eine weitere Sicherheitsebene, die die Zugriffsberechtigung unabhängig vom Login checkt und freigibt. Und zwar über eine weitere Prüfinstanz, die nicht davon betroffen ist, wenn der SSO-Schlüssel entwendet wurde. Hacker hätten zwar die Möglichkeit sich in irgendeiner Weise Zugang zu beschaffen, wenn sie an die Credentials gelangt sind, können sich aber nur lateral, also auf der Ebene eines einfach registrierten Nutzers bewegen ohne wirkliche Rechte im System. Somit hätten sie auch nicht die Chance wie ein Administrator zu agieren, um einen Trojaner zu installieren.
Mehr über eine Ende-zu-Ende-Sicherheit für Internetidentitäten findet man in dem kostenfreien Webinar mit unserem Partner KuppingerCole: The evolution of access control
Fazit: Nur das Zusammenspiel von Spring Security, Keycloak und Erweiterungen machen einen umfassenden Nutzerschutz aus.
Wir halten fest, dass nicht eine der genannten Ergänzungen die alleinige IAM-bezogene Sicherheit für Webanwendungen darstellt. Sondern ein Aufbau aller Komponenten am meisten Sinn macht und nur zusammen eine wirkliche Steigerung des Schutzes für Webapplikationen bieten kann.
Übersicht über die Unterschiede: Spring Security, Keycloak und Login-Master
Die nachfolgende Tabelle gibt einen Überblick über die angesprochenen Punkte. Darüber hinaus zeigt sie die weitergehenden Unterschiede zwischen Spring Security, Keycloak und einer umfassenden IAM-Lösung für Webanwendungen und –services auf:
| Funktion | Login-Master | Keycloak (out-of-the-box) | Spring Security |
|---|---|---|---|
| Authentisierung (Authentifikation, bessere Identifikation) | Siehe Keycloak | Ja | Ja, selbst programmiert - für jede einzelne Anwendung |
| Token Based Authorisation (Trennung der Login-Funktionalität von der konkreten Zugriffsfreigabe) | Ja, mit der Keycloak-Extension SecuRole® | Ja, mit Einschränkungen | Nein: Wenn eine Anwendung auf die Gruppe eines Benutzers zurückgreift, wird diese in einer lokalen User Registry gespeichert. Das ist bei Cloud-basierten Anwendungen problematisch. |
| DSGVO-konforme Behandlung der Benutzerdaten | Ja | Ja, aber nur teilweise | Ja, mit großen Einschränkungen, da jede Anwendung selbst Daten sammelt und damit quasi "selbst" verantwortlich für die DSGVO-Konformität ist. |
| Zentrale Ablage von Benutzerinformationen und Credentials | Siehe Keycloak | Ja | Nein, jede Anwendung selbst (Datensilo!) |
| Zentrales IMS mit: 1) Rollenmanagement: - über Role Shop - über ABAC (Vergabe von Rechten basierend auf Attributwerten wie „Organisatorische Einheit, Planstelle usw.) - über Zentraladministrator -über Delegierte Administratoren 2) Audit 3) automatischen Prozessen 4) Import aus autoritativen Datenquellen 5) Online-Definition von Applikationen und Rollen 6) Rezertifizierung | Ja | Nur partiell bzw. manuell durch den zentralen Administrator über ein paar Dialoge | Nein |
| Absicherung nicht-Java-basierter Anwendungen | Ja | Ja | Nein |
Das war:
Erweiterungen mit Spring Security, Keycloak, dem Berechtigungsframework SecuRole® und Login-Master‘s Sicherheits- und IAM-Funktionen für Webapplikationen
Quellenangaben: