Wir wollen Sie nach dem Szenario und einem dicken Vermögensschaden aus der letzten Woche natürlich nicht im Regen stehen lassen. Aus diesem beschreiben wir in diesem Blog Post, wie das IKS von SAP verwendet werden kann, um präventiv tätig zu werden, oder schwache Kennwort-Hashes erst gar nicht auftreten.
Grundsätzliche Vermeidung schwacher Kennwort-Hashes in SAP
Die einfachste und wohl auch effektivste Art der Prävention ist die generelle Deaktivierung der Speicherung schwacher Kennwort-Hashes in SAP. Allerdings sollten Sie die folgenden Einstellungen nicht leichtfertig vornehmen, sondern vorab klären, ob bestimmte Abhängigkeiten bestehen, die gegebenenfalls eine Kompatibilität zu alten Systemen erfordern und die schwachen Hashes demnach benötigt werden. Wir hatten das Vorgehen bereits kurz in einem der letzten Artikel angerissen, sodass jetzt eine detaillierte Schritt-für-Schritt Anleitung mit vielen bunten Bildern folgt:
- Nach der Eingabe der Anmeldeinformationen rufen Sie zunächst die Transaktion „RZ11“ auf:
2. Den Profilparameter „login/password_downwards_compatibility“ pflegen:
3. Nach einem Klick auf „Anzeigen“ zeigen sich die Einstellungen des Profilparameters:
Ein Wert von „1“ entspricht dem Standard, der dazu führt, dass auch die alten Hash Werte (mit MD5 und SHA1) berechnet werden. Ändern Sie den Wert auf „0“, so werden die alten Hash Werte nicht mehr berechnet und lediglich der bislang sicherste Kennwort-Hash mit dem iSSHA1-Algorithmus berechnet. Ein kleiner Hinweis an dieser Stelle: Die Änderungen werden erst nach einem Neustart der Instanz wirksam.
Mit der Änderung des Profilparameters auf „0“ sind Sie allerdings noch nicht auf der sicheren Seite. Denn die alten Hash Werte befinden sich nach wie vor in dem SAP System. Allerdings kann ich Sie beruhigen. Auch diesen Umstand können wir bereinigen. Rufen Sie dafür die Transaktion „SA38“ auf:
4. Aufruf von „SA38“ zur Löschung der alten Kennwort Hashes (/n beendet die aktuelle Transaktion):
5. Eingabe und starten des Programms „CLEANUP_PASSWORD_HASH_VALUES“.
Nach dem Starten des Programms werden umgehend alle schwachen Kennwort-Hashes in der „USR02“ gelöscht. Stattdessen wird das Kennwort fortan nur noch mit dem iSSHA-1 Algorithmus generiert. Damit hätten wir zunächst das größte Problem in diesem Zusammenhang gelöst. Es bestehen allerdings noch weitere Möglichkeiten dem beschriebenen Szenario aus dem letzten Blog Post zu begegnen.
Die Mär vom Berechtigungsobjekt „S_TABU_DIS“
Der ein oder andere versierte Leser würde initial die Berechtigung für das Lesen bestimmter Tabellen in SAP über die „SE16“ mit Hilfe des SAP Berechtigungsobjekts „S_TABU_DIS“ einschränken. Allerdings muss ich Ihnen den Zahn an dieser Stelle ziehen, denn diese Maßnahme kratzt nur an der Oberfläche des Eisberges. Andreas Wiegenstein hat dazu einen etwas ausführlicheren Blog Artikel mit dem Titel „The truth about S_TABU_DIS“ geschrieben und beschreibt drei verschiedene Arten des Datenbankzugriffs mittels ABAP in SAP:
- Open SQL
- EXECSQL
- ABAP Database Connectivity (ADBC)
Wird mittels einer der genannten Methoden auf die Datenbank zugegriffen, so greift das Berechtigungsobjekt „S_TABU_DIS“ in keinem der drei Vorgehen. Davon ausgenommen sind Standardzugriffe über SAP, wie z.B. das LogonPad. Ausschließlich in diesen Fällen greift das Berechtigungsobjekt und verhindert einen kritischen Zugriff auf z.B. die SAP Tabelle „USR02“, sofern richtig konfiguriert.
Ein Schwenk in die Tiefen der Berechtigungsobjekte werden wir an dieser Stelle nicht unternehmen. Das Gebiet ist sehr weitläufig und reicht problemlos für einen eigenen Artikel aus. Sollten Sie Probleme beim Ändern / Anlegen von Berechtigungsobjekten haben, dann bleiben Sie am Ball. Zu gegebener Stunde werden wir einen entsprechenden Artikel nachreichen.
Die Prüfung des Zugriffs auf die USR02
Aus verschiedensten Gründen kann das Entfernen alter Kennwort-Hashes nicht sinnvoll oder ungewünscht sein. In diesem Fall wird es nahezu unmöglich präventive Maßnahmen zu ergreifen. Sollten Sie andere Erfahrungen haben, oder Kniffe aus den weiten Welten des SAP Universums kennen, dann freuen wir uns über einen Kommentar unter dem Artikel.
Mit der richtigen Vorbereitung können Sie allerdings reaktive Vorkehrungen treffen. In diesem Zusammenhang spielt der Datenschutz allerdings eine enorm große Rolle. Die Business-Transaktionsanalyse stellt zum Beispiel eine Möglichkeit dar, die allerdings der Restriktion unterliegt, dass sie im SAP Standard lediglich die letzten 2 Tage aufzeichnet. Diese Art der Analyse führt neben den ausgeführten Transaktionen und dem Zugriff auf Tabellen auch den zugehörigen Benutzer an. Genau aus dem Grund sollte der Betriebsrat / die Datenschutzabteilung involviert werden. Die Transaktionsanalyse kann ganz einfach über den Transaktionscode „STAD“ aufgerufen werden. Neben der Angabe der Transaktion „SE16“ und des Programms für die Tabelle USR02 „/1BCDWB/DBUSR02“ sollte das Leseintervall angegeben werden. Die Standardeinstellungen von „00:10:00“ bedeuten z.B., dass lediglich 10 Minuten vor und 10 Minuten nach dem angegebenen Zeitpunkt analysiert werden.
Darüber hinaus besteht die Möglichkeit das Read Access Logging zu aktivieren. Nachteil dieser Option sind die fehlenden Daten aus der Vergangenheit, denn es werden lediglich lesende Zugriffe geloggt, wenn das Logging auch aktiviert ist. Außerdem wird das Read Access Logging (kurz RAL) erst seit dem Release Stand 7.40 SP02 unterstützt. Das detaillierte Vorgehen zur Umsetzung des Read Access Loggings finden Sie am Beispiel der Tabelle USR02 in englischer Sprache unter dem folgenden Link:
How to Configure Read Access Logging in SAP
Einrichtung des Vier-Augen-Prinzips für Stammdatenänderungen
In dem Szenario aus dem letzten Blog Artikel von Pjotr Melnikow mit dem Titel „Schwarzer Peter: Wer mit den Hunden schläft, …“ hatte der Buchhalter einen Benutzer mit den umfangreichen „SAP_ALL“ Rechten übernehmen können, um die Stammdaten eines Kreditors zu ändern. Unter der Annahme, dass in dem Unternehmen kein Vier-Augen-Prinzip für Stammdatenänderungen vorhanden ist, konnte das Geld ohne Weiteres auf das Konto seines Strohmannes umgeleitet werden. Das Unternehmen hatte es demnach versäumt eine funktionierende Funktionstrennung umzusetzen. Damit Ihnen so etwas nicht passiert, zeigen wir Ihnen was Sie in SAP einstellen müssen, um z.B. eine Freigabe der Änderungen von Bankverbindungen in den Kreditorenstammdaten von einer zweiten Person genehmigen zu lassen. Nun wollen wir natürlich nicht alle Änderungen genehmigen lassen, weshalb an dieser Stelle das asymmetrische Vier-Augen-Prinzip zum Zuge kommt. Mit Hilfe dieses Instruments können einzelne Datenfelder definiert werden, die eine Freigabe benötigen. In dem genannten Szenario wäre das z.B. die Bankleitzahl und Kontonummer. Für Kreditoren / Lieferanten befinden sich diese Werte in der Tabelle LFBK in den Feldern:
- BANKL: Bankschlüssel
- BANKN: Bankkontonummer
Damit hätten wir die sensiblen Datenfelder schnell und einfach identifiziert, sodass wir das asymmetrische Vier-Augen-Prinzip für genau diese Datenfelder definieren werden. Dafür gehen Sie wie folgt vor:
- Zunächst öffnen Sie das Customizing in SAP mit der Transaktion „SPRO“ und navigieren zu: Finanzwesen > Debitoren- und Kreditorenbuchhaltung > Kreditorenkonten > Stammdaten > Anlegen der Kreditorenstammdaten vorbereiten > Sensible Felder für 4-Augen-Prinzip (Kreditoren)
2. Über einen Klick auf die Uhr mit grünem Haken gelangen Sie in die Ansicht: Sicht „Sensible Felder“ ändern:
3. Über den Reiter „Neue Einträge“ fügen Sie die erwähnten technischen Feldnamen wie auf dem Bild dargestellt ein, sofern noch nicht vorhanden
Sobald Sie danach oben auf die Brille mit dem Stift geklickt haben, müssen Sie die Übernahme bestätigen. Damit aber noch nicht genug. Zusätzlich müssen die Rollen angepasst werden, sodass es Benutzer gibt, die Änderungen auch freigeben können. Ansonsten bleiben die Kreditoren nach einer Änderung gesperrt, was zur Folge hat, dass keine Zahlungen mehr an den entsprechenden Kreditor veranlasst werden können. Mit dem Programm „RFKCON00“, das über die Transaktion „SA38“ aufgerufen werden kann, erhalten Sie eine Liste aller Kreditorenstammdaten, die eine Freigabe benötigen.
