Ich bin dann mal wer anders…
Auch heute noch melden sich viele Anwender gemäß dem SAP-Standard mit ihrem SAP-Benutzernamen und Kennwort am SAP-GUI an. Die eingegebenen Credentials werden dabei unverschlüsselt über das Netzwerk übertragen. Zur Absicherung der Netzwerkkommunikation für DIAG und RFC bietet SAP die „Secure Network Communications“-Schnittstelle (SNC) an, über die sich Benutzer an SAP-Systemen anmelden können, ohne einen Benutzernamen oder ein Kennwort eingeben zu müssen.
Für die Benutzerauthentifizierung mit Sicherheitstoken, zum Beispiel ein X.509-Zertifikat oder das Kerberos-Ticket, ist eine Zuordnung erforderlich, um zu definieren, welches Sicherheitstoken zu welchem SAP-Benutzer gehört. Darüber kann ein sogenanntes Single Sign-On umgesetzt werden.
Dieser Blog befasst sich mit dem potentiellen Risiko, das mit der der Zuordnung von SNC-Namen einhergeht. Diese Zuordnung kann in erster Linie von Insidern missbraucht werden. Die Idee für diesen Blog-Artikel entstand durch die Frage eines unserer Kunden, die wir nicht zum erstem Mal gehört haben: Warum kann ich als Admin jedem SAP-Benutzer meinen eigenen SNC-Namen zuweisen? Ist das nicht ein potenzielles Sicherheitsproblem?
Kundenaussage (Abstrakt): „…wir glauben, dass dies ein Risiko ist, da jeder, der Pflegezugriff auf SU01 hat, seinen SNC-Namen auf jeden potentiellen SAP-Benutzer setzen und sich dann mit diesem Benutzer anmelden kann.“
Table of Contents
Technischer Hintergrund
Zwischen dem SAP-Benutzernamen und dem Windows AD-Benutzernamen besteht kein direkter Zusammenhang. Die Benutzernamen im SAP und AD sind in vielen Unternehmen unterschiedlich.
Wird ein entsprechendes SSO-Produkt eingesetzt, z.B. SAP Single Sign-On 3.0, muss für die Aktivierung von SNC der SAP-Benutzername mit dem Distinguished Name (DN) des Benutzer-Zertifikats bzw. dem Kerberos Principal Name (KPN) verknüpft werden. Dies ist erforderlich, damit der Anwender nach einer erfolgreichen Authentisierung auch eine Sitzung unter seinem SAP-User erhält.
Über die Transaktion SU01 wird die Benutzer-Zugriffskontrollliste (Tabelle USRACL) erweitert. Wenn keine Fehler aufgetreten sind, aktiviert das System das Kennzeichen „Kanonischer Name bestimmt“. Alternativ kann man die SNC-Namen über die Transaktion SM30 direkt in Tabelle USRACL eintragen oder automatisierte Reports (RSUSR300) sowie die ZBV bzw. ein Identity Management hierfür einsetzen.
Wichtig ist nur, dass innerhalb des SAP-Systems die SNC-Namen mithilfe der konfigurierten SNC-Bibliothek kanonisiert werden. Dies bedeutet, dass der auf der Registerkarte SU01 angezeigte lesbare SNC-Name in einen vom System verwendeten binären kanonischen Namen (USRACL-HNAME) konvertiert wird.
SU01
Wenn nun also ein „böser Admin“ seinen eigenen SNC-Namen dem SAP-Account seines Chefs zuweist, kann er sich (unbemerkt) mit dem SAP-Account seines Chefs anmelden und naja tun, was auch immer er tun möchte. Danach setzt er einfach den alten SNC-Namen ein. Während dieses Vorgangs hat sein Chef davon nichts mitbekommen und auch sein Passwort wurde nicht verändert.
Für diese Insider-Bedrohung braucht es nicht einmal viel kriminelle Energie oder irgendwelche speziellen Tools. Ein schlecht umgesetztes SAP-Berechtigungskonzept reicht schon aus. Sie benötigen lediglich die Erlaubnis, die Transaktion SU01 zu verwenden. Leider haben viele Unternehmen oft zu viele SAP-Benutzer (Admins), die SU01-Pflegeberechtigungen haben.
Daher muss bei Single Sign-On verstärkt auf die SAP-Benutzerverwaltung geachtet werden, insbesondere auf die Pflege von SNC-Namen im Kontext von SNC. Der potenzielle Missbrauch ist jedoch auf Benutzer mit SU01-Pflegeberechtigungen beschränkt, und Sie können solche Änderungen natürlich protokollieren. Aber wer überprüft die Protokolle wirklich regelmäßig? Wäre es nicht besser, eine technische und automatisierte Lösung zur Überwachung und Minimierung dieses spezifischen Risikos zu haben?
Erst einmal ist ein vernünftiges SAP-Berechtigungskonzept sicherlich hilfreich. Es gibt zudem Möglichkeiten die Änderungen an SNC-Namen zu steuern und SU01 zusätzlich für diesen Bereich einzuschränken. Darüber hinaus können Sie Tabellenprotokollierung, Änderungsdokumente oder die automatische Überwachung, Erkennung sowie Alarmierung nutzen.
Lösungsansätze
Abschließend möchten wir Ihnen einige (sicherlich nicht alle) Lösungsmöglichkeiten aufzeigen.
ZSU01
Möglich wäre das Erstellen einer SU01 Screen-Variante via Transaktion SHD0. Dort könnte das Register SNC oder auch einzelne Felder in diesem Register ausgeblendet werden. Die Screen-Variante könnte man dann über eine Z-Transaktion bspw. als ZSU01 bereitstellen oder alternativ die SU01 modifizieren, sodass diese im Standard immer diese Variante nutzt und den SNC-Bereich somit ausblendet. Man könnte den SNC Namen lesbar darstellen, sodass man zumindest sieht, was für ein Wert gepflegt ist, jedoch ohne diesen ändern zu können.
Einschränken der SNC-Pflegeberechtigung | S_USER_GRP (36)
Nutzen Sie den Customizing-Schalter CHECK_NONPW_LGNDATA. Anstatt nur die Aktivität „Ändern“ (02) zu prüfen, können Sie im Berechtigungsobjekt S_USER_GRP die Aktivität „Erweiterte Pflege“ (36) prüfen.
Damit wird es möglich, die Berechtigungen für einzelne Benutzeradministratoren besser zu trennen. Beispielsweise kann die Pflege von SNC-Namen auf einige wenige Administratoren beschränkt werden. Weitere Informationen finden Sie im SAP-Hinweis 1882254
Hinweise zur Protokollierung der SNC Namenspflege (Änderungsbelege)
Der SNC-Name der Benutzer in Tabelle USRACL ist seit längerer Zeit auch in den Änderungsbelegen zum Benutzer (siehe Transaktion SUIM / Report RSUSR100N bzw. Report RSSCD100 für Objektklasse = IDENTITY). Für die anderen relevanten Tabellen des Paketes SECN (also insbesondere RFCDESSECU, SNCSYSACL, USRACLEXT, und USREXTID) zeigt Report RDDPRCHK in Spalte „SCDO Object“ an, ob für eine Tabelle ein Änderungsbelegobjekt existiert (hier also für Tabelle USRACL).
Note 419933 – FAQ: Maintenance of change documents in user administration
[…]
As of Note 1079207, additional change documents for the user are stored in the central change documents in the object class IDENTITY. This includes (among other things) documents for the attributes reference user, alias, SNC name and CUA-specific attributes such as child systems, role assignment and the assignment of manual profiles.
[..]
You can activate the general table logging in accordance with Notes 1916 and 163694. … LDAP, PSE, SNC administration
[…]
Note 1079207 – Downports: CUA change docs, archiving, 12 hour time format
[…]
SNC name – Change documents are evaluated using the new report RSUSR100N.
[…]
The system uses the selection option ‚SNC Name‘ to evaluate changes to the switch ‚Insecure communication allowed (user- specific)‘ as well as to the field ‚SNC Name‘ of the user (Both can be maintained on the tab page SNC of transaction SU01.).
[…]
Regelmäßige automatisierte Prüfung mit dem Security Architect
Mit dem Xiting Security Architect können Sie neben vielen anderen Checks Ihre SAP-Landschaft auch auf doppelt gepflegte SNC-Namen prüfen lassen. Mit SP14 ermöglichen wir die Prüfung SNC_DUPLICATE, die anzeigt, ob mindestens zwei Benutzer mit demselben SNC-Namen gefunden wurden.
Automatische Erkennung und Alarmierung mit ETD
SAP Enterprise Threat Detection (SAP ETD) ist eine Sicherheitslösung, die im Kern verdächtige Ereignisse in Echtzeit erkennt. Eine der vielen Funktionen von SAP ETD ist neben der Erfassung von verschiedensten Logs aus einer SAP-Umgebung oder der forensischen Untersuchung, auch die Erkennung von Angriffen sowie die – auf Wunsch – damit verbundene Alarmierung. Sie können ETD so anpassen, dass es u. a. als Warnsystem für Ereignisse im Zusammenhang mit der SNC-Namenszuordnung verwendet wird, um nur einen der vielen Anwendungsfälle zu nennen.
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
