Bundesamt für Sicherheit in der Informationstechnik

M 4.263 Absicherung von SAP Destinationen

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

Verantwortlich für Umsetzung: Administrator

Ein SAP System kann neben der Server-Rolle, in der es seine Funktionen zum Zugriff anbietet, auch die Client-Rolle annehmen, in der es auf Funktionen anderer SAP Systeme zugreift. Destinationen beschreiben dabei die unterschiedlichen Zielsysteme und enthalten alle zum Zugriff notwendigen Informationen. Generell sind dies der Rechnername oder die IP-Adresse, das zu verwendende Protokoll und Nummer des Kommunikationsports, die die Netzverbindung zum Zielsystem beschreiben.

Für Destinationen können aber auch Authentisierungsinformationen hinterlegt werden. Beim Zugriff auf die Destination werden diese dann zur Anmeldung am Zielsystem genutzt. Sind keine Authentisierungsinformationen hinterlegt, so müssen diese durch den aufrufenden Benutzer angegeben werden. Die entfernte Ausführung erfolgt dann unter den Berechtigungen des angegebenen Benutzers. In diesem Zusammenhang werden im Kontext von Destinationen, auf die über RFC (Remote Function Call) zugegriffen wird, üblicherweise folgende Begrifflichkeiten verwendet:

  • RFC-Benutzer: Der Benutzer, der im Server-System aktiv ist und bestimmte Berechtigungen besitzt.
  • RFC-Service-Benutzer: Ein RFC-Benutzer wird dann Service-Benutzer genannt, wenn die Anmeldedaten (Benutzer und Kennwort) beim Client gespeichert sind.

Destinationen werden in einer mandantenunabhängigen Tabelle gehalten, daher hat jeder Benutzer Zugriff auf alle Destinationen im SAP System. Somit muss der Zugriff auf die Destinationen abgesichert werden. Folgende Empfehlungen sind für Destinationen zu berücksichtigen:

Speichern von Authentisierungsinformationen

Authentisierungsinformationen sollten nur dann hinterlegt werden, wenn dies nicht zu vermeiden ist. Es ist dabei abzuwägen, ob der Schutz des benutzten Passwortes oder der Schutz des Zielsystems vor unberechtigten Zugriffen überwiegt. Es ist zu beachten, dass für RFC-Destinationen, die aus Programmen heraus genutzt werden, die Authentisierungsinformationen hinterlegt werden müssen, sofern das Server-System nicht für die so genannte Trusted-RFC-Kommunikation konfiguriert ist, so dass generell alle RFC-Aufrufe aus den vertrauten SAP System ohne Authentisierung erfolgen können.

Werden Authentisierungsinformationen hinterlegt, so sollte ausschließlich ein Benutzer vom Typ Kommunikation gewählt werden. Insbesondere sollten keine Dialog-Benutzer eingetragen werden, da sonst über die Destination eine interaktive Anmeldung ohne Passworteingabe möglich ist.

Die Möglichkeit, Passwörter unverschlüsselt zu speichern, sollte nicht benutzt werden.

Zugriff auf Destinationen

Der Zugriff auf Destinationen muss eingeschränkt werden, so dass nur berechtigte Benutzer darauf zugreifen können.

Der Zugriff auf Destinationen kann über das Berechtigungsobjekt S_ICF gesteuert werden. Folgende Berechtigungsfelder sind für das Berechtigungsobjekt definiert, die für die Zugriffssteuerung benutzt werden:

  • ICF_FIELD: Typ des zu schützenden Objekts
    Dieses Feld kann folgende Werte beinhalten:
    • SERVICE: für Verwendung von ICF-Services
    • DEST: für Verwendung von RFC-Destinationen (ab 6.20)
  • ICF_VALUE: Wert des zu schützenden ICF-Objektes
    Dieses Feld enthält den Wert des entsprechenden Objektes. Die Werte, die geschützt werden sollen, werden in der Transaktion SICF für ICF-Services und in der Transaktion SM59 für RFC-Destinationen gepflegt.

Folgendes ist dabei zu beachten:

  • Destinationen müssen nach Einsatzszenarien gruppiert werden. Benutzern kann dann der Zugriff auf alle im Szenario benötigten Destinationen erlaubt werden. Probleme treten jedoch dann auf, wenn Destinationen in mehreren Szenarien eingesetzt werden, da pro Destination nur eine Zuordnung zu genau einer Gruppe möglich ist. In diesem Fall muss eine weitere Unterteilung erfolgen.
  • Der Zugriff auf Destinationen mit unterschiedlichem Schadenspotential muss über getrennte Berechtigungen gesteuert werden.

Es ist zu bedenken, dass eine Destination für viele Zwecke genutzt werden kann. Der Zugriffsschutz kann daher nur als Einstiegshürde dienen. Schlussendlich muss der Schutz des Zielsystems durch die aufgerufenen Funktionen selbst und die Berechtigungsvergabe im Zielsystem erfolgen.

Dies gilt insbesondere für Destinationen, auf die über Trusted-RFC zugegriffen wird (dann auch "Trusted Destination" genannt). In diesem Fall werden die Berechtigungen über die Berechtigungsobjekte S_RFC und S_RFCACL gesteuert.

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

Unbenutzte Destinationen absichern

Für nicht benutzte Destinationen muss entschieden werden, ob diese nur vorübergehend oder gar nicht mehr genutzt werden. Im ersten Fall sind die Destinationen zu deaktivieren, im zweiten Fall sind die Destinationen zu löschen.

Übertragen von Destinationen in andere Systeme

Werden Destinationen von einem System in ein anderes System übertragen, so werden auch die in Destinationen gespeicherten Authentisierungsdaten übertragen. Diese Destinationen können dann im System, in das sie importiert wurden, sofort zum erfolgreichen Zugriff auf das in der Destination angegebene Zielsystem benutzt werden. Dies ist beim Übertragen von Destinationen (z. B. bei Systemkopien) zu berücksichtigen.

Zugriff auf Destinationspflege und -tabelle einschränken

Die Pflege von Destinationen erfolgt über die Transaktion SM59. Es wird empfohlen, den Zugriff auf diese Transaktion auf die berechtigten Administratoren einzuschränken (Berechtigungsobjekt S_TCODE).

Es ist zu bedenken, dass die RFC-Destinationsdaten in der Tabelle RFCDES abgelegt werden. Hinterlegte Passwörter sind dabei kodiert gespeichert, im SAP System sind jedoch alle Informationen vorhanden, um die Passwörter zu dekodieren. Der direkte Tabellenzugriff ist daher ebenso einzuschränken (siehe M 4.264 Einschränkung von direkten Tabellenveränderungen in SAP Systemen ).

THOST Tabelle absichern

In der Tabelle THOST werden symbolische Rechnernamen (SAP Name), die innerhalb des SAP Systems verwendet werden, auf DNS -Rechnernamen (Netz-Name) abgebildet. Der Zugriff auf die Tabellenpflege (Transaktion SM55 oder über SE16) muss daher auf die berechtigten Administratoren eingeschränkt werden (Berechtigungsobjekt S_TCODE).

Auf die Konsistenz der SAP Namen mit den Netz-Namen ist zu achten, damit auf die jeweils richtigen IT-Systeme zugegriffen wird.

Prüffragen:

  • Werden die Destinationen im SAP System so abgesichert, dass nicht jeder Benutzer Zugriff auf alle Destinationen hat?

  • Werden Benutzer-Anmeldeinformationen für Destinationen nur dann gespeichert, wenn andere Lösungen nicht in Frage kommen?

  • Wurden bei der Hinterlegung von Authentisierungsinformationen im SAP System ausschließlich Benutzer vom Typ Kommunikation gewählt (und keine Benutzer vom Typ Dialog)?

  • Werden Passwörter im SAP System nur verschlüsselt gespeichert?

  • Wird der Zugriff auf Destinationen mit unterschiedlichem Schadenspotential über getrennte Berechtigungen gesteuert?

  • Haben nur berechtigte SAP Administratoren Zugriff auf die Transaktion SM59 zur Pflege von Destinationen?

  • Ist der direkte Tabellenzugriff auf die RFC -Destinationsdaten auf berechtigte SAP Administratoren eingeschränkt?

  • Ist der direkte Tabellenzugriff auf die symbolischen Rechnernamen in der Tabelle THOST auf berechtigte SAP Administratoren eingeschränkt?

  • Wurde auf die Konsistenz der SAP -Namen mit den Netz-Namen geachtet?

Stand: 13. EL Stand 2013