Bundesamt für Sicherheit in der Informationstechnik

M 4.258 Sichere Konfiguration des SAP ABAP-Stacks

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Der ABAP -Stack ist die traditionelle Ausführungsumgebung eines SAP Systems. Dies trifft insbesondere auf die Systemversionen zu, die allgemein mit dem Begriff SAP R/3 bezeichnet werden, da die R/3 Komponenten und Module im ABAP-Stack ausgeführt werden.

Die initiale Konfiguration des ABAP-Stacks ist aufwendig und umfasst viele Einzelschritte. Der Aufwand erhöht sich, wenn neben der Konfiguration der reinen SAP Basis auch Applikationen und Module konfiguriert werden müssen, wie das in R/3-Systemen notwendig ist. Hier müssen alle relevanten Behörden- oder Unternehmensprozesse durch Konfiguration (Customizing) oder Anpassungen im ABAP-Code nachgebildet werden.

Im Folgenden werden die aus Sicherheitssicht wichtigsten Schritte aufgezeigt, die bei der initialen Konfiguration des ABAP-Stacks durchzuführen sind. Die Darstellung beschränkt sich auf die Konfiguration der SAP Basis und geht damit nicht auf Module oder Applikationen ein.

Mandant für den Betrieb festlegen

Zunächst muss ein Mandant für den Betrieb des SAP Systems festgelegt werden. Als "Mandant" (engl. Client) wird in einem SAP System eine technische Unterteilung verstanden. Dies ist nicht mit dem Mandantenbegriff im Sinne von "Kunde" zu verwechseln. Nach der Installation dürfen die existierenden Standardmandaten mit den Nummern 000 (SAP Referenzmandant), 001 (Produktionsvorbereitungsmandant), und 066 (Earlywatch-Mandant) nicht genutzt werden.

Ein SAP System kann mehrere Mandanten mit unterschiedlichen Verwendungszwecken enthalten. Alle Mandanten eines SAP Systems hängen jedoch über den SAP Referenzmandanten zusammen, in dem Konfigurationen erfolgen, die global für das gesamte SAP System gelten.

Aus Sicherheitssicht ist zu fordern, dass Mandanten mit sehr unterschiedlichen Sicherheitsanforderungen nicht zusammen in einem SAP System betrieben werden. So darf etwa ein Produktivmandant nie zusammen mit einem Entwicklungsmandanten in einem SAP System betrieben werden. Beim gemeinsamen Betrieb können Entwickler auch mandanten-unabhängige Objekte ändern, so dass dies direkt Auswirkungen auf den Produktivmandanten hat. Daher ist eine Separation zwingend erforderlich.

Sicherheitsrelevante IMG-Aktivitäten durchführen

Der SAP Implementation Guide (IMG, SAP Reference IMG) ist eine von SAP vordefinierte, systeminterne Liste, die die Konfigurationsschritte enthält, die zur Konfiguration eines SAP Systems durchzuführen sind. Die Liste ist hierarchisch aufgebaut und jeweils auf die verwendete Systemversion und die installierten Komponenten abgestimmt. Daneben besteht die Möglichkeit, eigene IMGs zu erstellen (Projekt IMGs), in denen nur die im Rahmen der Systemverwendung notwendigen Konfigurationsschritte aus dem SAP Reference IMG enthalten sind. IMGs bieten zudem die Möglichkeit festzuhalten, welche Konfigurationen bereits durchgeführt wurden, so dass dadurch der Konfigurationsstatus vorgehalten werden kann.

In M 2.346 Nutzung der SAP Dokumentation findet sich ein Hinweis auf die SAP IMG Dokumentation, die zu beachten ist. Alle im Rahmen der Planung festgelegten IMG-Aktivitäten (siehe auch M 2.341 Planung des SAP Einsatzes ) müssen abgearbeitet werden.

Folgende IMG-Aktivitäten sind immer durchzuführen:

Durch die IMG-Aktivitäten werden unter anderem auch die nachfolgend beschriebenen Maßnahmen berührt. Da diese jedoch aus Sicherheitssicht eine große Relevanz aufweisen, werden sie hier explizit aufgeführt.

Profilparameter anpassen

Über Profilparameter können grundsätzliche Funktionen eines SAP Systems konfiguriert werden. Daher müssen im Rahmen der Konfiguration auch die Profilparameter an die Bedürfnisse angepasst werden. Da Profile in mehreren Ausprägungen existieren (z. B. Start-Profil, Default-Profil, Instanz-Profil), müssen sich Administratoren mit dem Profil-Mechanismus vertraut machen.

Generell ist für jeden einzelnen Profilparameter die zu verwendende Einstellung zu definieren. Folgende Parameter verdienen dabei aus Sicherheitssicht besondere Aufmerksamkeit:

  • alle Parameter mit dem Präfix "auth/"
  • alle Parameter mit dem Präfix "login/"
  • alle Parameter mit dem Präfix "snc/", sofern SNC eingesetzt wird
  • alle Parameter mit dem Präfix "ssf/", sofern SSF eingesetzt wird

Für die Profil-Verwaltung sollte die Transaktion RZ10 verwendet werden. Das manuelle Ändern auf Dateisystemebene sollte unterbleiben. Für die Anzeige der Profilparameter kann auch der Report RSPARAM benutzt werden, der über die Transaktion SE38 aufgerufen wird. Die Profil-Dateien sind auf Betriebssystemebene vor unberechtigtem Zugriff zu schützen.

Hinweise auf Detailinformationen zum Umgang mit Profilen finden sich in M 2.346 Nutzung der SAP Dokumentation .

Systemänderbarkeit konfigurieren

Je nach Rolle eines SAP Systems muss die Systemänderbarkeit eingestellt werden. Durch die Einstellung wird bestimmt, ob Änderungen an internen System-Komponenten und Applikationskomponenten überhaupt erlaubt sind oder nicht. Dies betrifft beispielsweise den ABAP-System-Code, generell alle Objekte im Data Dictionary (DDIC) sowie den Objektnamensraum.

Für Produktiv-Systeme wird empfohlen, die Systemänderbarkeit global auf "nicht änderbar" zu setzen. Damit können Änderungen nur noch über das Transportsystem eingespielt werden. Dies ist für Produktiv-Systeme wünschenswert, damit Änderungen nur über definierte Prozeduren und Abläufe erfolgen. Wichtig ist hier, einen geordneten Änderungsmanagementprozess zu definieren und einzuhalten, siehe M 4.272 Sichere Nutzung des SAP Transportsystems .

Für Test- und Qualitätssicherungssysteme sollten die gleichen Einstellungen wie im Produktivsystem verwendet werden, also global "nicht änderbar". Änderungen sind im Entwicklungssystem vorzunehmen und nach dem Durchlauf des Qualitätssicherungsprozesses in das Qualitätssicherungs- und final in das Produktiv-System zu transportieren.

Für Entwicklungssysteme sollten die Komponenten, die durch die Entwicklung nicht betroffen werden, auf "nicht änderbar" gesetzt werden. Die Komponenten, in denen entwickelt wird, müssen hingegen auf "änderbar" gesetzt werden.

Die Einstellungen der Systemänderbarkeit können über die Transaktion SE06 oder SE03 erreicht werden.

Hinweise auf detaillierte Informationen zum Thema finden sich in M 2.346 Nutzung der SAP Dokumentation .

Mandanten-Konfiguration durchführen

Neben der übergreifenden Änderbarkeit des SAP Systems können auch einzelne Mandanten gegen Veränderungen mandantenabhängiger Eigenschaften geschützt werden. Diese Einstellung ist für alle produktiven Mandanten zu benutzen. Durch die Einstellungen wird auch beeinflusst, ob Mandanten-Veränderungen automatisch aufgezeichnet werden, so dass Einstellungsveränderungen nach der Prüfung automatisch als Transportauftrag verfügbar sind und in andere Mandanten transportiert werden können, die mit den gleichen Einstellungen betrieben werden sollen.

Das Änderungsmanagement-Konzept muss festlegen, nach welchem Schema Änderungen zwischen Mandaten verteilt werden und welche Mandanten welchen Verwendungszweck (z. B. Produktivmandant, Testmandant, Entwicklungsmandant) besitzen.

Die Einstellungen erfolgen über die Transaktion SCC4. Für die eigenen Produktivmandanten sind folgende Einstellungen empfohlen (Hinweis: Die angegebenen Bezeichnungen der Einstellungswerte finden sich so in der abgekürzten Schreibweise im SAP System.):

  • Rolle des Mandanten: "Produktiv"
  • Änderungen und Transporte für mandantenabhängige Objekte: "keine Änderung erlauben"
  • Änderungen an mandantenübergreifenden Objekten: "keine Änderungen von Repository- und mand.unabh. Cust.-Obj."
  • Schutz bzgl. Mandantenkopierer und Vergleichstool: "Schutzstufe 2: kein Überschreiben, keine ext. Verfügbarkeit"
  • Einschränkungen beim Starten von CATT und eCATT: "eCATT und CATT nicht erlauben"

Entsprechende Einstellungen sollten im Test- und Akzeptanzsystem gelten. Für andere Mandanten (Entwicklung, Schulung, Demo) sind die Einstellungen geeignet zu definieren.

Administratoren müssen sich mit den Auswirkungen der Mandanten-Konfiguration sehr genau vertraut machen. Hinweise auf entsprechende Detail-Dokumentation findet sich in M 2.346 Nutzung der SAP Dokumentation ,.

Ausführbare Betriebssystemkommandos absichern

Der ABAP-Stack bietet die Möglichkeit an, Betriebssystemkommandos auszuführen. Die Kommandos werden mit den Betriebssystemrechten des technischen Betriebssystembenutzers ausgeführt, unter dem das SAP System abläuft. Dies sind in der Regel weitreichende Administratorrechte.

Der Zugriff auf diese Funktionalität muss daher abgesichert werden. Insbesondere das Anlegen oder Verändern von Kommandos muss verhindert werden. Daher sollten folgende Hinweise umgesetzt werden:

  • Die Berechtigungen, externe Betriebssystemkommandos auszuführen (Berechtigung S_LOG_COM) oder zu pflegen, (Berechtigung S_RZL_ADM mit ACTVT=01) sind restriktiv zu vergeben.
  • Der Zugriff auf die Transaktion SM49 "Externe Betriebssystemkommandos ausführen" ist auf die berechtigten Administratoren einzuschränken.
  • Der Zugriff auf die Transaktion SM69 "Externe Betriebssystemkommandos pflegen" ist auf die berechtigten Administratoren einzuschränken.
  • Für die Betriebssystemkommandos besteht die Möglichkeit, die beim Aufruf genutzten Parameterwerte vorzugeben und zu verhindern, dass zusätzliche Parameter angehängt werden können. Von dieser Möglichkeit sollte Gebrauch gemacht werden. Dies trifft insbesondere für selbst definierte Kommandos zu.

Hinweise auf Detailbeschreibungen zum Absichern der Betriebssystemkommandos finden sich in M 2.346 Nutzung der SAP Dokumentation .

Passwortqualität sicherstellen

Damit die Passwortqualität beim Zugang zum SAP System sichergestellt wird, sind die folgenden Hinweise zu berücksichtigen.

Es sollte eine minimale Passwortlänge definiert werden. Dazu dient der Profilparameter "login/min_password_lng". Es wird ein Wert von 8 Zeichen empfohlen. Dieser Wert stellt gleichzeitig die maximale Passwortlänge des ABAP-Stacks dar.

Für Passwörter sollten Komplexitätskriterien definiert werden. Dies sind über die folgenden Profilparameter einstellbar:

  • login/min_password_diff:
    Mindestanzahl der unterschiedlichen Zeichen zwischen neuem und altem Passwort
  • login/min_password_digits:
    Mindestanzahl von Ziffern im Passwort
  • login/min_password_letters:
    Mindestanzahl von Buchstaben im Passwort
  • login/min_password_specials:
    Mindestanzahl von Sonderzeichen im Passwort

Bei der Definition von Komplexitätskriterien ist darauf zu achten, dass konsistente Vorgaben eingestellt werden.

Für Passwörter sollte eine maximale Gültigkeitsdauer vorgegeben werden, so dass eine regelmäßige Passwortänderung erzwungen wird. Dies wird über den Profilparameter "login/password_expiration_time" konfiguriert, der die Anzahl der Tage angibt, nach denen das Passwort zu ändern ist. Empfehlenswert sind Werte zwischen 60 und 90 Tagen.

Es können verbotene Passwörter definiert werden. Diese sind in der Tabelle USR40 über die Transaktion SM31 zu pflegen. Hierüber sollten typische Trivial-Passwörter verhindert werden.

Die eingestellten Werte sind entsprechend der geltenden Passwortrichtlinie zu wählen.

Schutz vor Passwort-Attacken konfigurieren

Es wird empfohlen, das SAP System vor Passwort-Attacken zu schützen, indem nach einer Anzahl von Anmelde-Fehlversuchen die Verbindung unterbrochen wird. Die Anzahl wird durch den Profilparameter "login/fails_to_session_end" konfiguriert.

Um wiederholt angegriffene Benutzerkonten vor weiteren Angriffen zu schützen, wird empfohlen, Benutzerkonten nach einer Anzahl von Anmelde-Fehlversuchen zu sperren. Die Anzahl wird durch den Profilparameter "login/fails_to_user_lock" konfiguriert.

Es muss außerdem entschieden werden, ob gesperrte Benutzerkonten automatisch wieder um Mitternacht entsperrt werden oder ob dies manuell durch den Benutzer-Administrator erfolgen muss. Das Verhalten wird über den Profilparameter "login/failed_user_auto_unlock" gesteuert.

Die eingestellten Werte sind entsprechend der geltenden Passwortrichtlinie zu wählen.

Mehrfachanmeldungen verhindern

SAP Systeme können verhindern, dass das gleiche Benutzerkonto für mehrere parallele Anmeldungen verwendet wird. In der Regel sind in Produktiv-Systemen Mehrfachanmeldungen durch die gleiche Person nicht sinnvoll und sollten daher unterbunden werden. Das Verhalten kann für SAPGui- und RFC-Sitzungen separat gesteuert werden wird über die Profilparameter "login/disable_multi_gui_login" und "login/disable_multi_rfc_login" definiert.

Bevor Mehrfachanmeldungen über RFC unterbunden werden, muss sichergestellt sein, dass parallele Sitzungen mit demselben technischen Benutzerkonto ausgeschlossen sind.

Single Sign-On sicher konfigurieren

Werden mehrere SAP Systeme betrieben, so kann die Benutzeranmeldung über den SAP Single Sign-On (SSO) Mechanismus vereinfacht werden. Eine wiederholte Passwort-Eingabe ist dann nicht mehr notwendig, da nach einem erfolgreichen Login vom SAP System ein Single Sign-On Ticket ausgestellt wird, welches den Zugriff auf andere SAP Systeme ohne erneutes Login erlaubt. Ob und zwischen welchen SAP Systemen der Single Sign-On Mechanismus genutzt wird, muss in der Planungsphase festgelegt werden.

Folgende sicherheitsrelevante Aspekte sind zu bedenken, wenn Single Sign-On verwendet wird:

  • Single Sign-On sollte nur zwischen vertrauenswürdigen Systemen konfiguriert werden. Insbesondere Single Sign-On Szenarien über Unternehmens- oder Behördengrenzen hinweg sind unter Sicherheitsgesichtspunkten zu vermeiden.
  • Es empfiehlt sich, pro Szenario nur ein System für die zentrale Anmeldung einzusetzen, das SSO-Tickets ausstellt. Alle anderen Systeme sollten SSO-Tickets nur akzeptieren.
  • Besonders wichtig ist, dass die Kommunikation zwischen dem Browser des Benutzers und dem SAP System verschlüsselt wird. Ansonsten besteht potentiell die Gefahr, dass Angreifer das SSO-Ticket abhören und damit ohne Anmeldung auf das SAP System zugreifen können.

Folgende Profilparameter regeln die SSO-Konfiguration für ein SAP System:

  • login/accept_sso2_ticket:
    System akzeptiert SSO-Tickets.
  • login/create_sso2_ticket:
    System stellt SSO-Tickets aus.
  • login/ticket_expiration_time:
    Gültigkeitsdauer der ausgestellten SSO-Tickets in Stunden
  • login/ticket_only_by_https:
    SSO-Tickets werden nur beim Zugriff über HTTPS ausgestellt.
  • login/ticket_only_to_host:
    SSO Tickets werden nur bei Zugriffen auf das ausstellende System verwendet.

Für die Konfiguration von SSO sind zusätzliche administrative Tätigkeiten durchzuführen, die über die Transaktionen SSO2, SSO2_ADMIN (SSO2_ACL) und STRUSTSSO2 gemanagt werden können. SAP empfiehlt, die Transaktion SSO2 zu nutzen.

Hinweise auf Detailinformationen finden sich in M 2.346 Nutzung der SAP Dokumentation .

Neben dem SAP SSO-Mechanismus über Tickets können auch externe Systeme für SSO genutzt werden. Diese müssen dann jedoch über die SNC-Schnittstelle (Secure Network Communication) eingebunden sein. Für Windows-basierte Umgebungen (ab Windows 2000) wird auf die Möglichkeit hingewiesen, Single Sign-On über Kerberos zu nutzen. In diesem Fall erfolgt die Anmeldung nur am Windows-System. Beim Zugriff auf das SAP System ist dann keine Eingabe von Benutzername und Passwort mehr notwendig. Der verwendete Windows-Kerberos SNC-Provider ist standardmäßig und ohne Mehrkosten verfügbar. Es muss jedoch bedacht werden, dass der Windows Kerberos SNC-Provider keine Verschlüsselung der Kommunikation anbietet. Daher ist nur SNC-basierte Authentisierung verfügbar. Ab Windows 2000 besteht jedoch standardmäßig die Möglichkeit, IPSec zwischen Rechnern einzusetzen und so eine generelle Verschlüsselung der Kommunikation zu erreichen. Ob dies eine mögliche Variante ist, um Single Sign-On in einem Unternehmen oder einer Behörde umzusetzen, muss jeweils entscheiden werden.

Weitere Maßnahmen zu SNC finden sich in M 5.125 Absicherung der Kommunikation von und zu SAP Systemen , SAP Informationsquellen in M 2.346 Nutzung der SAP Dokumentation .

Prüffragen:

  • Werden die existierenden Standardmandanten des SAP Systems im Betrieb nicht genutzt?

  • Ist sichergestellt, dass Mandanten mit sehr unterschiedlichen Sicherheitsanforderungen nicht zusammen in einem SAP System betrieben werden?

  • Sind die Administratoren mit dem Profil-Mechanismus im SAP System vertraut?

  • Sind die Profil-Dateien des SAP Systems auf Betriebssysstemebene vor unberechtigtem Zugriff geschützt?

  • Ist für das SAP Produktiv-System der Parameter zur Systemänderbarkeit auf "nicht änderbar" gesetzt?

  • Sind für die Test- und Qualitätssysteme die gleichen Einstellungen wie im SAP Produktivsystem verwendet worden, also global "nicht änderbar"?

  • Sind die SAP Komponenten des Entwicklungssystems, die durch die Entwicklung nicht betroffen sind, auf nicht änderbar gesetzt?

  • Sind im SAP System die Einstellungen für alle produktiven Mandanten so gewählt, dass sie gegen Veränderungen mandantenabhängiger Eigenschaften geschützt sind?

  • Wird bei der SAP Mandanten Konfiguration im Änderungsmanagement-Konzept festgelegt, nach welchem Schema Änderungen zwischen Mandanten verteilt werden?

  • Sind die SAP Administratoren mit den Auswirkungen der Mandanten-Konfiguration vertraut?

  • Wird im SAP System der Zugriff auf ausführbare Betriebssystemkommandos abgesichert, insbesondere das Anlegen oder Verändern von Kommandos?

  • Ist die Passwortqualität im SAP System technisch sichergestellt?

  • Sind die SAP Systeme so konfiguriert, dass nach einer Anzahl von Anmelde-Fehlversuchen die Verbindung unterbrochen wird?

  • Ist das SAP System so eingestellt, dass Mehrfachanmeldungen für das gleiche Benutzerkonto verhindert werden?

  • Ist festgelegt, zwischen welchen SAP Systemen der SAP Single Sign-On Mechanismus genutzt wird?

Stand: 13. EL Stand 2013