Sicherheit im Zahlungsverkehr ist ein Thema was regelmäßig hinterfragt und geprüft werden muss. Sei es durch die interne Revision im Unternehmen, oder auch einen externen Audit bzw. Wirtschaftsprüfer. Durch den Ausbruch von COVID-19 wird das Homeoffice zu einem der führenden Arbeitskonzepte. Dies hat aber auch aufgezeigt, dass es hier bzgl. Infrastruktur stellenweise Nachholbedarf gibt und man beim Arbeiten von zuhause sogar weitreichendere Sicherheitsmechanismen etablieren muss.
Die aktuelle Unsicherheit lässt die inneren Alarmglocken der Nutzer oft zu schnell verstummen und man liest immer öfter von Phishing-Attacken oder Fraud durch Social Engineering wie beim „Fake President“ (siehe auch https://www.dertreasurer.de/news/software-treasury-it/kriminelle-schlagen-mit-neuer-fake-president-masche-zu-2010411/).
Dabei sind das 4-Augen-Prinzip und Segregation of Duties schon lange in den Prozessen der Finanzabteilungen etabliert. Aber was hilft dies alles, wenn hier weiterhin nur einfache Passwörter verwendet werden?
Heutige Rechenleistung, die handelsübliche Computer leisten, machen Brute-Force-Angriffe (Testen möglicher Passwortkombinationen durch ein automatisches System) nicht mehr zu einer exotischen Angriffsform aus dem Darknet, sondern für jedermann möglich. Aus Social-Media Präsenzen lassen sich persönliche Hintergründe erfahren und daraus Hinweise ableiten, um Passwörter schneller zu knacken.
Dies ruft nach Mechanismen wie einer Zwei-Faktor-Authentifizierung (2FA) heutzutage auch oft als MFA (Multi-Faktor Authentifizierung) bekannt. Im Kontext PSD2 hat man ebenfalls schon davon gehört und aus dem privaten Umgang im Online-Shopping beispielsweise mit PayPal, bei Amazon oder der eigenen Hausbank ist dies heutzutage nur mehr schwer wegzudenken.
Ab dem 1. Januar 2021 verlangt die EU-Zahlungsdiensterichtlinie eine starke Authentifizierung (SCA = Strong Customer Authentication) z.B. auch für Online-Kartenzahlungen. Dann müssen zwei von drei Sicherheitsfaktoren erfüllt sein: Wissen, Besitz und Inhärenz. Es gibt aber gesetzlich festgeschriebene Ausnahmen und Ausgrenzungen von dieser Regel. Damit können und werden Online-Händler Kartenzahlungen weiterhin bequemer gestalten und die Anzahl der Kaufabbrüche im Zahlungsprozess gering halten (siehe https://www.it-finanzmagazin.de/psd2-ausnahmen-der-starken-kundenauthentifizierung-sca-111100/).
Doch auch für die Zahlungsfreigabeprozesse in ihrem SAP-System sollten Verfahren zur 2-Faktor-Authentifizierung eingerichtet werden.
Im Gegensatz zum privaten Umfeld kommt für den SAP-Zugriff eine E-Mail als zweiter Faktor nicht in Frage. Ein dienstliches Mobiltelefon wäre eine Option, dabei sendet eine App nach Aufforderung im Freigabeprozess eine Push-Benachrichtigung (alternativ via SMS) mit einem Code an das Smartphone des Nutzers, der diesen dann eingibt und bestätigt.
Zusätzlich zum Passwort (Wissen) wird hier das Handy als Hardware-Komponente (Besitz) genutzt. Der Zugriff auf das Telefon ist meist über biometrische Charakteristika abgesichert (Inhärenz) und das System, bestehend aus dem Telefon als “harte” und dem Passwort als “weiche” Komponente, ist in vielen Fällen Best-Practice.
Nun stellt sich die Frage mit welchen Komponenten man die 2FA in einer SAP-Landschaft umsetzen kann. Workflow-basierte Zahlungsfreigaben werden über SAP Bank Communication Management (BCM) abgewickelt. Hier gibt es die Möglichkeit ein sog. „Externes Sicherheitsprodukt“ für die digitale Unterschrift zu integrieren.
Für die Freigabe via SAP GUI basiert dies technisch auf dem sog. Secure Store and Forward (SSF) Framework und der Verwendung von SAP Single Sign-On mit den Komponenten Secure Login Client und Server. Dies hat natürlich Auswirkungen auf die Infrastruktur und es ist zudem zu prüfen, ob dafür eine schon vorhandene Lösung (z.B. DIGIPASS/OneSpan, RSA Secure ID,…) wiederverwendet werden kann oder ob ein neuer RADIUS-Server angeschafft werden muss.
Zum Zeitpunkt der Zahlungsfreigabe wird dann über die SAP Benutzerstammdaten ein Token angefordert, der über ein zusätzliches Pop-Up vom Secure Login Client eingegeben werden muss:
Wir verweisen für weitere Details auf den folgenden Blog-Artikel:
https://blogs.sap.com/2015/10/27/digital-signatures-in-sap-gui-with-one-time-passwords/
Unter S/4HANA gibt es hier (seit Release OP1809 FPS1) weitere Möglichkeiten. Für die Freigabekommt weiterhin BCM zum Einsatz, dies lässt sich aber auch über die Fiori-Oberfläche via Approve Bank Payments (App ID F0673A) durchführen (Verweis auf Fiori Apps Apps Reference Library: https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/detail/Apps(‚F0673A‘)/S18OP).
Dafür ist es möglich eine optionale Benutzerauthentifizierung zu konfigurieren und dabei entweder auf SAP Authentication 365 (SAP365) und (nach Registrierung) einen SMS-basierten Prozess zu verweisen oder den SAP Cloud Platform Identity Authentication Service (IAS) zu nutzen und z.B. Google Authenticator für ein One-Time Password (OTP) als Token zu verwenden:
Für die Einrichtung muss eine HTTP-Destination konfiguriert werden, welche auf den Tenant der SAP Cloud Platform und den entsprechenden Service verweist:
Der SAML 2.0 Service muss muss dort einfach aktiviert werden und die Benutzer werden über die E-Mail-Adresse am Benutzerstamm identifiziert:
Die Applikation bietet hier einen einfachen Onboarding-Prozess z.B. über das Scannen eines QR-Codes aus der Google Authenticator App. Zum Zeitpunkt der Freigabe erhält man dann über die Fiori-Oberfläche ein Pop-up zur Eingabe des Verifizierungstoken:
Weitere Informationen zum SAP Cloud Platform Identity Authentication Service (IAS) findet man hier: https://www.sap.com/products/cloud-platform/use-cases/identity-authentication.html?btp=510b17a3-2fef-4a64-962e-3c9ab74dc654
Dieses Szenario ist auch für andere SAP-Komponenten wie z.B. SAP Advanced Payment Management (APM) relevant. Auch bei der Nutzung des Cloud-Service SAP Multi-Bank Connectivity (MBC) kann es ebenfalls nötig sein hier eine starke Authentifizierung für die Zahlungsfreigabe zu implementieren.
So gibt es z.B. auch bei der Bankenkommunikation via SWIFT entsprechende Vorgaben aus dem sog. Customer Security Programme (CSP) hier entsprechende Security Controls zu berücksichtigen (siehe auch https://www.swift.com/myswift/customer-security-programme-csp).
Diese werden jährlich aktualisiert und sollen künftig auch durch unabhängige Audits geprüft werden.
2020 wurde dies durch die aktuelle Situation noch einmal geschoben, es ist aber nur eine Frage der Zeit, bis diese externen Assessments verpflichtend sind. Unter dem folgenden Link sind diese Vorgaben auch nochmal aufgeführt: https://www.infoguard.ch/de/blog/swift-csp-v2020-diese-controls-duerfen-sie-nicht-aus-den-augen-verlieren (siehe Sektion 4.2 Authentifizierung mit mehreren Faktoren).
Sie haben weitere Fragen oder benötigen Unterstützung bei der Einführung einer 2-Faktor-Authentifizierung für ihre SAP-Zahlungsverkehrsprozesse? Dann sprechen sie uns (PAYMENTS.CC Kontakt) an!