Der richtige Umgang mit Passwörtern nach der Einführung von SAP Single Sign-On
Willkommen zu einem neuen Artikel aus unserer Reihe „SSO Insider-Tips“ und meinem ersten Blog über sichere Authentifizierung und Single Sign-On in diesem neuen Jahrzehnt. Warum hat das so lange gedauert? Ich war damit beschäftigt, eine sichere SSO-Infrastruktur für viele Unternehmen aufzubauen, und bin es immer noch.
In einigen unserer letzten Blogs haben wir über die Vorteile von SSO oder darüber gesprochen, wie man die Verschlüsselung zur Sicherung der SAP-Kommunikation forciert. Die Verschlüsselung steht immer an erster Stelle, darüber hinaus wird die Authentifizierung durch einen sicheres Token ergänzt oder ersetzt, darum geht es bei SSO.
Im Allgemeinen ist der Umgang mit Dutzenden von Anmeldeinformationen in der heutigen IT-Welt ein Problem für sich und Kernthema in zahlreichen Sensibilisierungskampagnen. In diesem Blog möchten wir einige Ansätze zum richtigen Umgang mit Passwörtern vorstellen, mit denen sich die SAP-Landschaft noch sicherer betreiben lässt, ohne die Anforderungen und Bedürfnisse der Benutzer oder Systemadministratoren auszuklammern.
Table of Contents
Einführung
Passwörter werden als Schlüssel zu unseren Informationen angesehen und sollten daher sicher ausgewählt und mit Sorgfalt behandelt werden. Sie begleiten uns im Alltag und werden häufig beim Zugriff auf das Betriebssystem oder der Anmeldung an Unternehmensanwendungen wie SAP eingesetzt. Der Schutz dieser Zugangsdaten hat nicht ohne Grund einen sehr hohen Stellenwert aus Sicht der IT-Security, stellen Credentials doch noch immer das primäre Einfallstor für die meisten Angriffe dar.
Anwender sehen sich in ihrer täglichen Arbeit mit immer mehr Accounts für unterschiedliche Systeme und Anwendungen konfrontiert und müssen sich für jeden Zugang am besten auch noch ein komplexes und möglichst sicheres Passwort merken, welches dann auch noch regelmäßig erneuert werden muss. Das kann nicht funktionieren, überfordert viele Anwender und bietet der IT-Security nur Nachteile.
Single Sign-On (SSO) hat seit langem das Potenzial zahlreiche mit diesem Thema verbundene Probleme zu lösen. Dennoch gibt es viele Unternehmen, die SSO entweder überhaupt nicht einsetzen, oder nie an den Punkt kommen und Verschlüsselung sowie SSO auch konsequent und verpflichtend einsetzen. Grundsätzlich gilt also auch im Umfeld SAP das Prinzip: „Verzichte, wenn immer möglich auf Passworte und nutze Single Sign-On“.
Definition: Single Sign-On (SSO) ist ein zentraler Sitzungs- und Benutzerauthentifizierungsdienst, bei dem ein Satz von Anmeldeinformationen für den Zugriff auf mehrere Anwendungen verwendet werden kann. Mit einer einzigen Authentifizierung kann der Benutzerzugriff auf mehrere Systeme, Anwendungen und Ressourcen automatisiert bereitgestellt werden.
Inzwischen sind SAP-Landschaften zunehmend komplexer geworden als noch vor 10 Jahren. Sie bestehen aus verschiedensten Systemen, die sich eng mit bestehenden IT-Komponenten verzahnen und erstrecken sich in die Cloud. Business-Anwendungen, die in diesen hybriden SAP-Umgebungen ausgeführt werden, sollen von überall auf der Welt und auf jedem Gerät verwendet werden können. Eine SAP-Landschaft ist also die optimale Umgebung für den Einsatz von Single Sign-On, um die Gesamtzahl der für mehrere Systemlandschaften erforderlichen Passwörter drastisch zu reduzieren und bestenfalls die Passwortanmeldung komplett abzuschaffen.
Mit Einsatz eines SSO-Verfahrens kann die Benutzerauthentifizierung beim Zugriff auf die unterschiedlichen SAP-Anwendungen an ein zentrales System ausgelagert werden. Dieses kann deutlich besser abgesichert werden, als jedes einzelne SAP-System für sich. Zugriffe auf das jeweilige SAP-System sind dann nur noch mittels Security Token wie einem X.509-Zertifikat, einem Kerberos-Ticket oder einer SAML-Assertion möglich. Damit musste sich der Anwender bereits vorgelagert ausweisen, was unter Umständen dann auch den Einsatz einer mehrstufigen Authentifizierung notwendig machte. Die Security Token selbst sind kryptografisch geschützt und enthalten natürlich keine Credentials.
Das Passwortmanagement in den verschiedenen SAP-Systemen kann dank SSO für die Masse der SAP-Anwender entfallen, was dann zu einer spürbaren Vereinfachung der Benutzerstammpflege in der gesamten SAP-Landschaft führt. Vorbei sind die Zeiten, in denen man sich Dutzende von Passwörtern für verschiedene Systeme merken oder diese häufig ändern musste. Ein zusätzlicher Vorteil besteht in der Möglichkeit, bestimmte Anwender schnell aus allen SAP-Systemen auszusperren, z.B. wenn der Benutzer das Unternehmen verlässt. Kein Zugriff auf das Active Directory bedeutet dann auch, dass kein Zugriff auf on-premise SAP-Anwendungen sowie integrierte Cloud-Anwendungen wie SAP Ariba oder SuccessFactors mehr möglich ist.
Zum Ärger, dem Aufwand und den Kosten, die mit der Verwaltung bzw. Rücksetzung der verschiedenen Zugangsdaten einhergehen gesellen sich auch Sicherheitsproblematiken. Niemand will auf Phishing-Mails hereinfallen. Und niemand verwendet absichtlich ein sehr einfaches Passwort, damit Hacker per Wörterbuch- oder Brute-Force-Attacke besonders leichtes Spiel haben. Die gängigen Regelungen- und Empfehlungen für sichere Passworte sind den meisten Anwendern durchaus bekannt. Stellt das Unternehmen jedoch keine SSO-Lösung zur Verfügung, bleibt der sichere Umgang mit den vielen Zugangsdaten letztlich in der Verantwortung der Anwender.
Der richtige Umgang mit Passwörtern, nachdem Single Sign-On für alle SAP-Systeme und Anwendungen eingeführt wurde
Aus unserer Sicht besteht das Ziel einer vollständigen Implementierung von SAP Single Sign-On darin, die Sicherheit durch Vertraulichkeit, Integrität und Authentizität zu erhöhen. Es sind keine unverschlüsselten Verbindungen zu diesem System zulässig (Ausnahmen möglich) und es sollten nur noch wenige SAP-Accounts in der Lage sein, eine Passwort-Anmeldung an diesem System durchzuführen. Dieses Ziel wird selten konsequent umgesetzt und somit existieren weiterhin Passwörter in den SAP-Systemen und geraten schon bald in Vergessenheit.
SSO kümmert sich nicht um den Passwortstatus eines SAP-Benutzers. Wenn es noch vorhanden ist und SNC+SSO nicht erzwungen wird, können Benutzer (wie auch Angreifer) die Sicherheit leicht umgehen. Passwortrichtlinien bleiben weiterhin aktiv und somit werden auch regelmäßige Passwortänderungen erforderlich.
Während der Transition in den produktiven Betrieb und damit der Bereitstellung von SSO für eine größere Gruppe von SAP-Systemen und Anwendern, empfehlen wir die Kennwörter aus verschiedenen Gründen aktiviert zu lassen. Nach ausreichender Testphase kann der Übergang zu einer passwortlosen Anmeldung zielgerichtet und gesteuert vom SAP-System durchgeführt werden, was immer dann passiert, wenn ein Passwortwechsel gefordert wird. Alternativ können die Anwender in den Prozess einbezogen werden und ihr Passwort im Self-Service-Verfahren löschen oder die Passworte werden automatisiert über ein Identity Management deaktiviert.
Der Anwender hat hier die
Möglichkeit, entweder ein neues Passwort zu vergeben oder das vorhandene selbst
zu löschen. Diese Einstellung wird über den Profilparameter login/password_change_for_SSO = 1 erreicht. Das SAP System
bringt dann bei Anmeldung mit SSO (SNC) folgenden Dialog:
Insider Tipp: Wenn alle Anwender durchgängig eine eigene personalisierte Anmeldung mittels SSO durchführen, sollte das Passwort in diesem SAP-System deaktiviert werden. Wichtig ist, dass auch wirklich alle Anwendungen auf diesem System berücksichtigt werden, welche über die Protokolle DIAG, RFC oder HTTP konsumiert werden. In diesem Fall empfiehlt sich die Konfiguration des Profilparameters login/password_change_for_SSO = 3 (Das Passwort wird ohne Meldung deaktiviert). Anwender sehen somit keinen Passwortwechsel-Dialog mehr. Positiver Nebeneffekt – wurden die Passworte deaktiviert, sind auch keine Passwort-Hashes in der Datenbank mehr vorhanden.
Keine Regeln ohne Ausnahmen!
So ganz kommt man auch mit Einsatz von SAP Single Sign-On nicht um Passworte herum. Zusätzlich zu den Dialogbenutzern kann es eine ganze Reihe von Kommunikations-, Service- und Systembenutzern geben. Grundsätzlich gibt es also einige Benutzer, die weiterhin zwingend ein Passwort benötigen, z. B. für Transportimporte und sonstige Wartungsaufgaben oder für Schnittstellen. Diesen Konten werden weiterhin Passwörter gemäß den Richtlinien Ihres Unternehmens zugewiesen. Umso wichtiger ist der korrekte technische und organisatorische Umgang mit diesen Benutzertypen und Passwörtern sowie die Verwendung der sichersten Hash-Methode in Ihrem SAP-System.
Insider Tipp: Die SAP-Systeme sollten keine rückwärtskompatiblen Hashwerte (BCODE, PASSCODE) erzeugen. Es wird empfohlen die SAP-Systeme dahingehend zu konfigurieren, dass diese ausschließlich mit Code Version H (PWDSALTESHASH) arbeiten. Umgesetzt wird dies mittels des Profilparameters login/password_downwards_compatibility = 0. Ein Hinderungsgrund dies umzusetzen, ist nicht selten der Betrieb einer ZBV in einer aus NW Release-Sicht stark heterogenen SAP-Landschaft.
Regelmäßiger Passwortwechsel ade – meint jetzt auch das BSI
Inzwischen rät auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) in seiner aktuellen Ausgabe des BSI-Grundschutz-Kompendiums (Februar 2020) von einem regelmäßigen Passwortwechsel ab. Eine erzwungene regelmäßige Änderung von Passwörtern gilt somit als überholt. Viele der Empfehlungen und Richtlinien werden auch SAP-Unternehmen und künftige Sicherheitskonzepte beeinflussen.
Lieber für jede (!) Anwendung bzw. jedes SAP-System ein eigenes und sicheres Passwort setzen. Das ist völlig in Ordnung und schützt noch immer am besten vor sogenannten „Credential Stuffing“ oder „Password Spraying“ und auch „Brute Force“ angriffen. Eine Steigerung der Awareness und Sensibilisierung der Anwender für das Thema sichere Passwörter kann mit Einsatz von SSO unterstützt werden. Die Anzahl der erforderlichen Passworte wird massiv reduziert und somit IT-Systeme wieder einfacher nutzbar gemacht ohne Abstriche zugunsten der Security zu machen.
Das BSI-Werk ist mit seinen über 800 Seiten keine leichte Kost, enthält aber einige Sicherheitsvorgaben für SAP-Systeme, u. a. APP.4.2.A31, in der ein sicher konfiguriertes Single Sign-On empfohlen wird, oder APP.4.2.A18, in der zur Abschaltung jeglicher unsicherer Kommunikation und Einsatz von SNC und TLS geraten wird, was letztlich die Nutzung verschiedener SSO-Verfahren ermöglicht. Interessierte können das auch gerne mal hier nachschlagen.
Fazit
Der Einsatz von Single Sign-On bietet viele Vorteile aus Sicht der Produktivität und Security und schafft eine höhere Akzeptanz der Endanwender und Systembetreiber. Ist das Missbrauchsrisiko im SSO-Umfeld als hoch einzustufen, gilt SSO alleine hinsichtlich der Risikoeinstufung nicht mehr als ausreichend. In diesen Fällen muss eine Multi-Faktor-Authentifizierung oder sichere Primärauthentifizierung eingesetzt werden. Sowohl im Umfeld verschiedener Identity Provider, als auch durch die Lösung SAP Single Sign-On 3.0 werden unterschiedliche MFA-Methoden in Form von Hardware- und Softwaretoken unterstützt.
Ist ein potentieller Angreifer auf welchem Weg auch immer an ein Passwort gelangt, dann stehen die Tore offen, um dieses Credential-Pair sowie auch das Schema aus dem sich das Passwort zusammensetzt, so oder in abgewandelter Form bei anderen Accounts- oder Systemen zu versuchen. Dank KI & Machine Learning gibt es inzwischen Algorithmen, die künftige Passworte vorhersagen können. Das Stichwort lautet „Password-Guessing Machines“.
Insider Tipp: Wenn uns die Vergangenheit eines gezeigt hat, dann dass wir uns nicht darauf verlassen können, dass unsere Credentials auf verschiedenen IT-Systemen auch wirklich ausreichend abgesichert sind. Daher gilt, verzichten Sie am besten lieber ganz darauf, mit Passwörtern zu arbeiten. Setzen Sie wann immer möglich ein gut abgesichertes SSO-System ein. Insbesondere beim Einsatz von Cloud-Anwendungen sollten keine Passwörtern zur Authentifizierung eingesetzt werden. Stattdessen nutzen Sie die Vorteile von SAML 2.0 und lagern Sie die Anmeldung an einen zentralen vertrauenswürdigen Identity Provider aus, der wiederum mittels SSO oder MFA bedient wird.
In diesem Zusammenhang abschließend noch ein paar Regeln:
- Nutzen Sie Passworte nur dann, wenn kein besseres Authentifizierungsverfahren umsetzbar ist.
- Nutzen Sie ausschließlich verschlüsselte Verbindungen (SNC+TLS). Stellen Sie sicher, dass die eingesetzten Verfahren und Algorithmen dem aktuellen Stand der Technik entsprechen.
- Nutzen Sie für jedes System ein anderes Passwort.
- Erstellen Sie möglichst lange und komplexe Passwörter und setzen Sie einen Generator ein.
- Nutzen Sie einen Passwort-Manager (…und notiert das Masterpasswort auf Papier).
- Nutzen Sie Zwei-Faktor-Authentifizierung für kritische Systeme oder privilegierte Accounts.
Schaut euch auch die anderen Artikel unserer Blog-Reihe „SAP Single Sign-On Insider Tips“ an:
- SAP Single Sign-On Insider Tips – Volume #5
- SAP Single Sign-On Insider Tips – Volume #4
- SAP Single Sign-On Insider Tips – Volume #3
- SAP Single Sign-On Insider Tips – Volume #2
- SAP Single Sign-On Insider Tips – Volume #1
Und hier noch ein kleiner Ausblick. Im nächsten Blog Härtung von SNC und TLS mit der SAP CommonCryptoLib geht es darum, wie Ihr SNC und TLS optimal konfiguriert und härtet. Gibt es im Bereich Authentifizierung und SSO noch andere Themen, die Sie besonders interessiert und über die ich einen Blog schreiben soll? Dann geben Sie mir Bescheid!
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
