Single Sign-On vs. Multi-Factor-Authentication
In diesem Blog spreche ich von Möglichkeiten, Risiken, technischen oder menschlichen Faktoren, die sich beim Einsatz von SAP Single Sign-On ergeben können und davon, wie eine sichere Authentifizierung bzw. MFA ein SSO-System sinnvoll ergänzen kann.
Ein technisch korrekt etabliertes Single Sign-On (SSO) bietet viele Vorteile für SAP-Unternehmen wie z. B. den Einsatz von Tokens zur Authentifizierung; den Entfall von Passworten sowie der Passwortverwaltung; die Identifizierung der Kommunikationspartner; Verschlüsselung- und Integritätsschutz von Netzwerkverbindungen usw. Ein schlecht implementiertes SAP SSO kann die allgemeine Sicherheit im schlimmsten Fall auch schwächen und einem unberechtigten Anwender (oder Angreifer) den Zugriff auf jedes angebundene System gewähren. Auch die auf der #OPCDE2019 vorgestellten SAP-Gateway-to-Heaven-Exploits, die man auch besser unter der Onapsis-Bezeichnung „10KBLAZE“ kennt, profitieren von SAP-Unternehmen in denen DIAG- und RFC-Verbindungen noch im Klartext, ohne Integritätsschutz oder PKI-Authentication stattfinden. Im Worst-Case-Szenario gelangt eine andere Person unter verschiedensten Umständen an das Anmeldetoken wie z. B. das Anmeldepasswort, das SAP Logon Ticket, oder das Kerberos Service Ticket bzw. den privaten Schlüssel des Anmelde-Zertifikats.
SSO bietet Zugriff auf viele Ressourcen, sobald der Benutzer erstmalig authentifiziert wurde. Dies erhöht die negativen Auswirkungen, falls die Anmeldeinformationen anderen Personen zur Verfügung stehen und missbraucht werden können. Da reicht schon ein Arbeitsplatz aus, der nicht gesperrt wurde, wenn der Mitarbeiter nicht am Platz ist. Das kommt häufiger vor als man denkt und kann natürlich auch dann passieren, wenn das Unternehmen gar keine SSO-Lösung einsetzt.
Wichtig ist es daher eine „Clean-Desk“-Policy umzusetzen und entsprechende Awareness bei den Mitarbeitern aufzubauen. Aber auch technische Maßnahmen können eingeführt werden, wenn ein Unternehmen für sich entscheidet, dass das Risiko eines potentiellen Missbrauchs zu hoch ist.
Es gelten zwei Grundsätze. Das Single Sign-On Verfahren muss auf aktuellen und sicheren Verschlüsselungsalgorithmen- und Authentifizierungsmethoden basieren und der SSO-Mechanismus darf nicht schwächer sein als die Authentifizierungsmethode selbst. Darüber hinaus bieten gute SSO-Lösungen jederzeit Unterstützung für verschiedene MFA-Verfahren.
Passwörter werden als Schlüssel zu unseren Informationen angesehen und sollten daher sicher ausgewählt und mit Sorgfalt behandelt werden. Passwörter begleiten uns im Alltag und werden häufig beim Zugriff auf das Betriebssystem oder beim Anmelden an Unternehmensanwendungen eingesetzt; SAP ist eine von vielen. Aufgrund ihrer Multi-System-Landschaft und der schrecklichen dezentralen Passwortverwaltung ist eine SAP-Landschaft ein optimaler Kandidat für die Verwendung von Single Sign-On (SSO), um die Gesamtzahl der für mehrere Systemlandschaften erforderlichen Passwörter deutlich zu reduzieren bzw. die Passwortanmeldung komplett abzuschaffen.
Die einfache Kombination aus Benutzer-ID und Passwort ist heute längst nicht mehr gut genug, um unsere wichtigsten Informationen ausreichend zu schützen. Beispiele sind Ihr Bankkonto, Ihre Bitcoin-Wallet, Ihr iCloud-Konto oder andere sensible Systeme bzw. Cloud-Dienste. In vielen Fällen müssen Sie hier eine zweite Art der Authentifizierung einsetzen, um Ihre Konten vor ungewolltem Einsatz bzw. Phishing zu schützen. Dann spricht man meist von Multi-Factor-Authentication (MFA) oder auch Zwei-Faktor-Authentifizierung (2FA).
SSO und MFA befassen sich beide mit der Authentifizierung. Während SSO meist einfach zu bedienen und vollautomatisch für den Benutzer abläuft, gestaltet sich der Einsatz von MFA oft unbequem, ist aber deutlich sicherer und somit für kritischste Anwendungen bzw. Transaktionen verpflichtend. Wie kann man beides so vereinen, dass die erforderliche Sicherheit und gleichzeitig Anwenderfreundlichkeit erreicht werden?
Table of Contents
Multi-Factor-Authentication (MFA)
MFA verwendet mehrere (mindestens aber zwei) verschiedene Faktoren, um Ihre Identität zu überprüfen.
- Etwas, das du weißt
- Passwort, persönliche Identifikationsnummer oder Login-Name
- Etwas, das Du hast
- Sicherheitstoken; Smartphone-App; Passcode-Generator; SMS; E-Mail oder andere Faktoren
- Etwas, das Du bist
- Biometrische Sicherheitsfaktoren wie etwa Fingerabdruck oder Gesichtserkennung
Basierend auf IP-Geolokalisierung oder sonstigen Anti-Fraud-Algorithmen senden einige Dienste auch E-Mails, die Ihre zusätzliche Bestätigung zur Anmeldung benötigen. Der Vorteil ist, dass MFA sehr sicher ist. Die Kombination von etwas, das Sie wissen, mit etwas, das Sie haben oder sind, reduziert das Risiko von kompromittierten Konten erheblich. Der wichtigste Nachteil von MFA sind seine Unannehmlichkeiten: Sie müssen etwas tun, das Zeit braucht, was oft zu einer negativen Benutzererfahrung führt.
Was ist Single Sign-On (SSO)?
Zu aller erst müssen Sie wissen: SSO ist nicht gleich SSO. Es gibt verschiedene Geschmacksrichtungen und die Terminologie ist nicht klar geregelt. Und natürlich sollte Ihr SSO auf standardisierten SSO-Technologien wie Kerberos, SAML 2.0 oder CBA basieren.
Enterprise Single Sign-On (E-SSO): Zu verstehen als Client-Software, die Anmeldebildschirme automatisch (Skriptbasiert) mit dem richtigen Benutzernamen und Kennwort auffüllt. Der Benutzer muss nach einer „Anlernphase“ das Kennwort in verschiedenen Anwendungen nicht mehr manuell eingeben. Geschützt werden alle Credentials über ein Master-Passwort. Ein Beispiel dafür ist der Password-Manager, der in viele Browser integriert ist, sowie viele kommerzielle Produkte bis hin zu Enterprise-Lösungen. Anmeldeinformationen werden entweder auf dem PC oder einer Smartcard sowie auf Servern, Verzeichnisdiensten oder Datenbanken im LAN oder der Cloud gespeichert. E-SSO-Lösungen werden häufig in Fällen verwendet, in denen die Anwendungen keine echten SSO-Mechanismen unterstützen. Sie sind technisch gesehen keine wirkliche SSO-Lösung bzw. lösen nicht die technischen Probleme hinter der Komponente Endanwender.
?? Schwache Sicherheit und häufig mit Usability-Problemen verbunden
Single Password/Single Credential: Es wird immer das gleiche Passwort verwendet, um sich an vielen Diensten zu authentifizieren. In der Regel wird ein zentrales Kennwort aus dem Active Directory über die Synchronisation an alle angebundenen Dienste verteilt, während die Anmeldemethode unverändert bleibt.
?? Nicht sehr sicher und hat viele Nachteile (Security & Usability)
Single Sign-On: Das Konzept des echten SSO basiert auf der Idee, dem Benutzer Zugriff auf alle Anwendungen über eine einmalige Anmeldung zu ermöglichen. Diese sollte hochsicher sein. Meist wird dazu jedoch die Windows-Anmeldung am Active Directory verwendet. Dies wird als primäre Authentifizierung betrachtet. Darauf aufbauend werden Industriestandards wie Kerberos, X.509 oder SAML 2.0 eingesetzt und somit letztlich Kennwörter durch Security-Token ersetzt. SSO reduziert somit die Anzahl der vom Benutzer benötigten Kennwörter auf das absolute Minimum. Der Identity Provider hat dafür Sorge getragen, dass sich der Benutzer als gültiger Anwender identifiziert hat und anschließend einen Vertrauensnachweis ausgestellt. Im Prinzip überprüft der Anwendungsserver nur diesen Nachweis bzw. das vertrauenswürdige Security-Token, anstatt den Benutzer selbst zu authentifizieren.
SSO bedeutet nicht, dass man auf allen Systemen das gleiche, sondern im besten Fall überhaupt kein Passwort mehr hat. Es handelt sich um eine Vereinfachung, aber es sollten je nach Einsatzumgebung hohe Sicherheitsanforderungen in Betracht gezogen werden.
?? Ein Benutzer muss sich immer nur ein Kennwort merken, und in Kombination mit starker Authentifizierung oder MFA kann gezielt zusätzliche Sicherheit erreicht werden.
?? SSO ist schnell und bequem für den Endbenutzer und infolgedessen gibt es weniger Anrufe an den Service Desk für Passwort-Resets, wodurch die IT-Supportkosten reduziert werden. Technisch werden keine Passwörter mehrmals erneut übertragen, wie es bei den ersten beiden Ansätzen der Fall ist.
?? SSO setzt IMMER auf verschlüsselte Netzwerkverbindungen und auf moderne Algorithmen- und Standards, um eine höchstmögliche Security zu gewährleisten.
Verwenden von SSO in Hochsicherheits-Umgebungen und Einsatz von starker Authentifizierung
Hochsicherheits-Umgebungen wie die US-Regierung erfordern z. B. die Einhaltung der FIPS 140-2-Standards und die Verwendung der Smartcard-Authentifizierung als primäre Methode für den Zugriff auf ihre IT-Systeme. Die Smartcard enthält einen privaten Schlüssel, welcher mit einer PIN geschützt ist. Somit wird eine Zwei-Faktor-Sicherheit erreicht. Wenn Sie die Smartcard aus dem Lesegerät entfernen, wird der Computer sofort gesperrt. Diese Art der primären Authentifizierung (starke Authentifizierung) gilt als hochsicher und wird von einigen Unternehmen verwendet, die solche Anforderungen haben.
Insbesondere haben wir die Erfahrung gemacht, dass in der Regel die Kombination mit Gebäudezugang, Zeiterfassung oder Zahlungssystemen am sinnvollsten ist. In diesem Fall verbleibt die (Firmen-)Karte nicht im Kartenleser, wenn der Mitarbeiter das Mittagessen genießt. Selbstverständlich ist es möglich, dies mit Ihren SAP-Zugriffssteuerungen zu kombinieren und sogar diese Methode der starken Authentifizierung für alle (oder einige) SAP-Benutzer/-Systeme in Ihrer Organisation durchzusetzen.
Wenn Sie jedoch keine Smartcards, Lesegeräte oder gar PKI mit einem angeschlossenen Kartenverwaltungssystem besitzen, macht es wenig Sinn, über diese Methode nachzudenken.
Verwenden von MFA für die sichere Authentifizierung an Ihren wichtigsten Systemen
Nach unserer Erfahrung verfügen die meisten Unternehmen nur über wenige SAP-Systeme bzw. Anwendungen mit höheren Sicherheitsanforderungen. Wir empfehlen, die SAP-Systeme in Sicherheitszonen zu kategorisieren und auf dieser Basis das gewünschte Authentifizierungsverfahren zu definieren.
Wenn Sie SAP-Systeme haben, auf denen Sie Single Sign-On nicht verwenden bzw. zulassen möchten ist es möglich, eine zusätzliche Authentifizierung an einem zentralen Authentifizierungsserver (z. B. einem LDAP/AD) zu erzwingen. Wenn Sie beispielsweise auf Ihr SAP Employee Self-Services (ESS)-Portal zugreifen, müssen Sie sich mit Ihren Active Directory-Anmeldeinformationen anmelden oder sogar einen Einmal-Passcode (OTP) eingeben. Beim Zugriff auf alle anderen SAP-Anwendungen dagegen ist ein SSO konfiguriert.
Eine Methode, die ich auch oft umgesetzt habe, ist folgende: MFA beim Zugriff auf die erste SAP-Anwendung des Tages. Der daraufhin authentifizierte Benutzer kommt nun während des gesamten Arbeitstages in den Genuss von SSO. Unabhängig davon, welchen Ansatz Sie wählen, stellen Sie immer sicher, dass die Übertragung von Authentifizierungsdaten über verschlüsselte Kommunikationskanäle erfolgt. Und letztlich ist der Benutzer die letzte Bastion. Steigern Sie ständig das Security-Bewusstsein der Benutzer, schulen Sie sie im Hinblick auf den sicheren Umgang mit IT-Systemen. Führen Sie Richtlinien für den sauberen Schreibtisch und den Sperrbildschirm ein. Diese nichttechnischen Ansätze werden auch dazu beitragen, die Sicherheit zu erhöhen, mal ganz abgesehen von SAP oder SSO. ?
Wenn Sie erfahren möchten, wie SSO und MFA in Ihrer SAP-Umgebung eingesetzt werden können, sprechen Sie uns an!
With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.
Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.
Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.
- Cloud-Integration leicht gemacht: Xiting Central Workflows (XCW) trifft auf SAP Cloud - 30. Juli 2024
- Von Wehmut und Vorfreude: Das bevorstehende Ende von SAP IDM - 20. März 2024
- 2024 SAP Cloud Identity Services & IAM Portfolio: Was ist neu? - 26. Februar 2024
