Security-Tutorial für SAP: In zehn Schritte zu mehr SAP-Sicherheit

Dieses SAP-Sicherheits-Tutorial beschreibt in zehn Schritten, worauf Security-Admins bei der SAP-Implementierung und Bereitstellung achten müssen.

Viele Unternehmen betrachten SAP-Anwendungen als Spezialsoftware, die Sicherheitsressourcen und Fachleute mit SAP-Erfahrung...

erfordert. Es ist zwar richtig, dass die meisten Firmen für die Implementierung die Unterstützung externer SAP-Experten brauchen. Doch gibt es auch eine Reihe von Möglichkeiten mit eigenen Ressourcen und Personal ein sicheres SAP-Umfeld umzusetzen und aufrecht zu erhalten.

Dieses Tutorial beschreibt die zehn wichtigsten Schritte für eine sichere SAP-Implementierung und zeigt, was die IT-Security-Abteilung dazu beitragen kann, die SAP-Sicherheit zu gewährleisten.

1. Ausrichtung der SAP-Konfigurationseinstellungen auf Unternehmensrichtlinien

Die IT-Security-Richtlinien eines Unternehmens sollten zwingend Softwareanforderungen zum Beispiel für Mindestlänge von Passwörtern, Passwortstärke und maximale Anzahl möglicher falscher Kennworteingaben spezifizieren. Diese Anforderungen sollten alle Anwendungen erfüllen müssen - und SAP sollte keine Ausnahme sein. In SAP sind diese Einstellungen konfigurierbar und lassen sich mit Hilfe der Systemparameter steuern. Die Parameter können über die SAP-Transaktion RSPFPAR eingesehen werden.

Achten Sie auf folgende Parameter, die alle gesetzt sein sollten, um die vordefinierten Unternehmensrichtlinien einzuhalten:

login / password_expiration_time (default 0, empfohlen 30)
Benutzer sind gezwungen, ihr SAP Passwort nach dieser Anzahl von Tagen zu ändern.

login / min_password_lng (default 3, 8 + empfohlen)
Setzt die minimale Passwortlänge.

login / fails_to_session_end (default 3, empfohlen 3)
Anzahl der Versuche, ein ungültiges Passwort einzugeben, bevor SAP die Sitzung beendet.

login / fails_to_user_lock (default 12, empfohlen 5)
Anzahl der Versuche, ein ungültiges Passwort einzugeben, bevor SAP die Benutzerstammsätze für weitere Anmeldungen sperrt.

2. Zugang zu generischen Benutzerkonten

Wie viele andere Anwendungen wird SAP mit einer Reihe von generischen Accounts ausgeliefert. Diese sollen für die Erstinstallation und das Setup verwendet werden, und die Passwörter der Accounts sind allgemein bekannt. Es ist daher wichtig, dass diese IDs sofort abgesichert bezihungsweise geändert werden, sobald das Setup abgeschlossen ist.

Die wichtigste Setup-ID ist die SAP*ID. Zusammen mit anderen generischen IDs kann der Status dieser ID mit dem SAP-Report RSUSR003 überprüft werden.

Die Passwörter dieser generischen IDs sollten zurückgesetzt werden und die privilegierten Profile (SAP_ALL und SAP_NEW) entfernt werden. Es ist wichtig zu beachten, dass sich das SAP*-Konto mit einem Standard- und allgemein bekannten Passwort selbst neu generieren kann, wenn es gelöscht wurde. Deshalb ist es von zentraler Bedeutung, dass das SAP*Konto gesichert beziehungsweise geändert, aber nicht gelöscht wird und dass der Systemparameter login/no_automatic_user_sapstar auf = 1 gesetzt wird.

3. Zuweisung von umfassenden Zugangsprofilen

Mehr zum Thema SAP

Unser Experte erklärt in diesem Artikel den Unterschied zwischen SAP ABAP und Basis.

Innerhalb von SAP ERP gibt es mit SOP ein Modul für die Absatz- und Produktionsplanung. Wir erläutern die Funktionen und grenzen es von SAP Flexible Planning ab.

Auf der Sapphire Now 2014 präsentierte SAP zusammen mit seinen Partner einige Neuheiten. Wir präsentieren einige Produkte in einer Übersicht.

Genauso wie mit generischen IDs wird SAP auch mit einer Reihe von privilegierten generischen Profilen ausgeliefert. Diese gewähren einen umfassenden Zugang zum System. Diese Rechte sollten deshalb nur bei der ersten Einrichtung des Systems und für nachfolgende Notfälle genutzt werden. Zu normalen Zeiten sollten Support- und Projektteam-Nutzer nur beschränkten Zugriff haben und es sollte nur das erlaubt sein, was sie für ihre tägliche Arbeit brauchen.

Das wichtigste privilegierte Zugangsprofil in einem SAP-System, dessen man sich stets bewusst sein sollte, ist das SAP_ALL Profil. Dieses Profil ermöglicht den Zugriff auf alle Transaktionen und Objekte, und daher auf alle Funktionen oder Aktionen im SAP-System. Es ist entscheidend, dass dieses Profil nicht auf Basis einer Routine zugeordnet wird. Auch das SAP_NEW Profil ermöglicht den Zugang zu allen Transaktionen und Berechtigungsobjekten.

Die Transaktion SUIM ermöglicht eine detaillierte Berichterstattung über den Benutzerzugriff. Firmen können den Report verwenden, um die Zuweisung von Wide Access Profilen für die Nutzer zu überprüfen. Mit dem „Users to Profiles Report“ lässt sich zudem eine Liste der Benutzer-IDs anzeigen, die SAP_ALL oder SAP_NEW Profilen zugeordnet sind. Mit dieser Information kann der Nutzerzugriff nach Bedarf überarbeitet und beschränkt werden.

4. Support und Projektteam-Zugriff

SAP wird ohne spezifische Profile oder Rollen für Support- oder Projektteam-Mitglieder geliefert. Um sicherzustellen, dass der Zugriff für diese Benutzer angemessen beschränkt ist, ist es daher wichtig, diese Profile zu definieren. In vielen Projekten wird diese Anforderung übersehen, und folglich werden die Mitglieder des Projektteams dem SAP_ALL Profil zugeordnet oder einem breiten Zugangsprofil, das lose auf SAP_ALL basiert.

Um zu gewährleisten, dass Support- und Projektteam-Mitglieder angemessen eingeschränkt wurden, sollten Sie nach Rollenspezifikationen suchen, die die Zugriffsanforderungen dieser Anwender abgrenzen und eine Reihe von Rollen für jede Gruppe festlegen. Allgemein gesagt, sollten definierte Rollen für die folgenden Gruppen gefunden werden:

  • Entwickler;
  • Basis-Administratoren;
  • Security (Role) –Administration;
  • Security (User) –Administration;
  • Funktionen / Konfigurationen.

Es sollte auch ein Prozess installiert sein, der bestätigt, dass die Rollen für die Bedürfnisse der Organisation richtig definiert sind.

5. Angemessene Trennung in Rollengestaltung und Zugriffsverwaltung

Da SAP ist ein integriertes System ist, besteht die Gefahr eines internen Betrugs, wenn inkompatible Verantwortlichkeiten derselben Person zugeordnet sind. Wenn beispielsweise ein Benutzer über die Rechte verfügt, Bankdaten zu verwalten und einen Zahlungslauf ausführt, könnte es für ihn oder sie möglich sein, die Kontrollen zu umgehen und Zahlungen auf eigene Konten umzulenken.

Das Management und Monitoring der Aufgabentrennung (segregation of duties, kurz SOD) ist im SAP-Umfeld ein wichtiger Teil des Sicherheitsprozesses. Die relevanten SoD Risiken für das Business des Unternehmens müssen klar festgelegt werden, und die Einhaltung dieser Vorschriften muss in Genehmigungs- und Bereitstellungsprozesse eingebettet werden.

Um sicherzustellen, dass die SODs in die Rollengestaltung der Organisation und in die Zugangverwaltungsprozesse integriert sind, sollte ein Tool wie SAP GRC Risk Analysis and Remediation (RAR) installiert werden. Dieses Tool kann die Risiken verwalten. In kleineren Firmen können manuelle Prozesse als Alternative eingesetzt werden, aber die Grenzen dieser Verfahren (z. B. Überwachung auf Rollenebene im Gegensatz zu Transaktionsebene) sollten den Verantwortlichen bewusst sein und entsprechend gemanagt werden.

6. Zugangsverfahren für den Notfall und für hochprivilegierte Anwender

Rollen sollten festgelegt werden, um für jeden Tag die Zugriffsanforderungen für Support- und Projektteams festzulegen. Allerdings ist es wichtig, dass diese Benutzer eine Eskalationsroute zur Verfügung haben, die es ihnen ermöglicht, Zugriffsrechte zu erweitern, wenn sich entsprechende Umstände ergeben: Das kann nötig sein, wenn sich zum Beispiel nicht replizierbare Probleme in einem nicht auf Produktion abzielenden System ergeben. Dieser Notfallzugang sollte durch den Leiter des SAP-Supports genehmigt werden und nur für einen definierten Zeitraum zugewiesen werden.

Zugangsprozesse für den Notfall und der Einsatz von Tools wie SAP GRC Superuser Privilege Management (SPM) können die Verteilung und Verwendung von hochpriviligierten Zugriffsrechten steuern und überwachen.

7. Überprüfung Benutzerzugang und Organisation

Die laufende Überwachung und Überprüfung ist notwendig, um die Einhaltung der Sicherheitsrichtlinien eines Unternehmens zu gewährleisten und die strengen Erwartungen der internen und externen Audits an das SAP-System zu erfüllen. Die SAP-Systemverwaltungsprozesse müssen etwa regelmäßige Überprüfungen doppelter Benutzer-IDs, generischer Konten und Passwort-Parameter ebenso einschließen wie die regelmäßige Überprüfung der Angemessenheit aktuell zugewiesener Zugangsrechte.

Während einige der in einer SAP-Umgebung erforderlichen Überprüfungen Aktivitäten spezifisch für ein SAP-System verlangen, sollten die meisten dieser Verfahren in jeder gut kontrollierten Anwendungsumgebung vorhanden sein.

8. Change-Management-Verfahren

Die strikte Einhaltung von Change Control Procedures und ein Transportpfad durch Entwicklung, QA / Tests und Produktionsumgebungen ist entscheidend für die Integrität der Daten, die in der Produktionsumgebung eines SAP-Systems gespeichert sind. SAP verfügt über einen eingebauten Transportmechanismus mit dem Namen Change and Transport System (CTS). Wichtig dabei ist, dass der Zugang zu den zentralen Transaktionen, die verwendet werden, um das CTS zu verwalten, sich ausschließlich auf die administrativen Mitarbeiter beschränkt, die sie für ihre Aufgaben benötigen.

Neben der Zugangsverwaltung für die relevanten CTS-Funktionen beinhaltet effektives Change-Management im SAP-Umfeld auch generische Change-Management-Praktiken. Dazu gehören die Dokumentation, die Prüfung aller Änderungen und die Wartung eines Audit-Trails für Business-Approvals.

9. Zugang zu sensiblen Funktionen

In einem integrierten System wie SAP kann auf sensitive Verwaltungsfunktionen und Geschäftstransaktionen innerhalb der gleichen Umgebung zugegriffen werden. Es ist daher wichtig, dass solche sensiblen Funktionen entsprechend eingeschränkt sind und nur die Personen sie abrufen können, die für diese Aktivitäten zuständig sind.

Der Auditor kann eine Liste der Funktionen bereitstellen, die vorsichtig eingeschränkt werden sollten. Dies sind beispielsweise:

  • Zugriff für das Anlegen und die Pflege von Benutzern und Rollen;
  • Zugriff, um Betriebssystembefehle auszuführen;
  • Zugriff auf Transport-Transaktionen und Objekte;
  • Zugriff, um Programme zu erstellen oder zu ändern;
  • Zugriff, um das System für die Konfiguration zu öffnen und zu schließen;
  • Zugriff auf Debug-Programme (so dass Anwender Berechtigungsprüfungen umgehen können).

10. Eigentum von Sicherheitsprozessen

Der „Besitz“ von Sicherheitsmechanismen ist wichtig, um in einem SAP-System eine angemessene Kontrolle darüber zu haben, wer was tun kann. Nur das Unternehmen kann die Auswirkungen erfassen, wenn ein Zahlungssachbearbeiter auch die Rechnungen von Lieferanten bezahlen darf oder die Spesenabrechnungen von Mitarbeitern. Das Unternehmen beziehungsweise der Sicherheitsverantwortliche muss deshalb festlegen, ob diese Tätigkeiten ausgeführt werden dürfen. Es ist wichtig zu wissen, welche Mitarbeiter Zugang zu welchen SAP-Funktion haben und es ist wichtig, dass der Zugang für diese Funktionen ständig kontrolliert wird.

Ohne ein angemessenes Verständnis und ohne eine entsprechende Gestaltung der Berechtigungsstrukturen sind Business-Verantwortliche nicht in der Lage, fundierte Entscheidungen zu treffen. Es ist daher wichtig, dass das SAP-Rollendesign so einfach ist, dass es die Verantwortlichen verstehen. Ein Security-Projekt sollte deshalb ein Element der Aus- oder Weiterbildung für Buiness-Verantwortliche sein, und zwar sowohl bei der ersten Implementierung als auch im fortlaufenden Prozess.

Fazit: SAP-Sicherheit als Teil der IT-Security

Die oben genannten Ratschläge decken nur die Sicherheitsgrundlagen einer SAP-Implementierung ab. Die Tipps sollten zeigen, dass die Grundlagen der SAP-Sicherheit den Security-Anforderungen in jedem gut kontrollierten Anwendungsumfeld ähnlich sind. Letztlich ist SAP nur eine weitere Business-Anwendung. Während der Einsatz von speziellen SAP-Kenntnissen am Anfang wichtig ist, damit alles rund läuft, ist es ebenso wichtig, dass die IT-Sicherheitsabteilung ihre Verantwortung bei einer SAP-Implementierung sieht und diese Verantwortung nicht auf SAP-Spezialisten abschiebt.

Der CIO ist daran erinnert, dass er letztendlich für die gesamte Sicherheit und Compliance des Unternehmens verantwortlich ist. So betrachtet gibt es wenig Spielraum für die Unterscheidung zwischen allgemeiner IT-Sicherheit wie E-Mail, Firewalls und Web-Servern und spezieller SAP-Security, die kontrolliert, wie Mitarbeiter auf das System zugreifen, wie sie die Daten verarbeiten und wie sie die Funktionen ausführen. Effektive IT-Abteilungen verfolgen eine ähnliche Philosophie, indem Sie die IT-Sicherheit holistisch und unternehmensübergreifend betrachten. Damit wird die Gefahr von Security-Verletzungen jeglicher Art radikal reduziert.

Über den Autor: Richard Hunt ist Geschäftsführer von Turnkey Consulting. Das Unternehmen ist spezialisiert auf IT-Sicherheit und kombiniert Business-Consulting mit der technischen Umsetzung von IT-Sicherheits-Lösungen für SAP-Systeme. Das Unternehmen wurde im Jahr 2004 von Hunt gegründet und hat heute Niederlassungen in Großbritannien, Australien, Deutschland und den USA. Es betreut Kunden in Europa, den USA und Asien.

Richard arbeitet seit mehr als einem Jahrzehnt in der IT-Security-Branche. Seine Karriere begann er als Sicherheitsberater bei PricewaterhouseCoopers (PwC), wo er spezialisiert war auf SAP-Sicherheit und IT-Security Reviews. Im Laufe seiner Karriere war er an mehr als 20 IT-Security-Projekten beteiligt und arbeitete bei einer ganze Reihen von Projekten und Branchen in Großbritannien, Asien und Australien.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Business-Software

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close