SOAMANAGER Security Settings | SAP Web Services absichern

(Last Updated On: 27. Dezember 2018)

Oft werde ich gefragt, was denn die einzelnen Sicherheitseinstellungen bei der Erstellung und Konfiguration von Web Services bedeuten, insbesondere wenn diese auf dem SOAMANAGER aufgesetzt werden. Dieser Thematik wollen wir uns heute einmal widmen. 

Im Wesentlichen soll es darum gehen, all diejenigen abzuholen, die noch nie mit dem SOAMANAGER und seiner WSDL-Funktionalität zu tun hatten, aber jetzt mit der Technologie arbeiten müssen und sich sorgen um die Security Konfiguration machen.

Für mich ist die Thematik immer sehr amüsant, weil ich sowohl SAP Kunden betreue, die noch nie einen Webservice definiert (geschweige denn entwickelt) haben, als auch Entwickler, die nicht aus der SAP Welt kommen und innerhalb ihrer Applikation mit SAP sprechen wollen. Die Technologien beider Seiten sind für die jeweils andere immer ein Buch mit sieben Siegeln.

Die Desktop- und Web-Entwickler holen den Rosenkranz aus dem Nachtkästchen, wenn es um CPIC bzw. RFC geht – und die SAP Anwender sehen WSDL und Webschnittstellen im Allgemeinen als Alien-Technologie aus einer vergessenen Zeit an.

In meinem konkreten Beispiel ging es beim Kunden konkret darum, dass man im Bezug auf die Konfiguration der Enterprise Services im SAP System bei einem Audit aussagefähig sein wollte. „Warum sind unsere Services so konfiguriert, wie sie es sind, und wie können wir sie noch weiter absichern?“.

Gleichzeitig können Sie dir gezeigten Erläuterungen jedoch auch zur Bewertung bzw. Auditierung von SOAMANAGER-Einstellungen verwenden. Lesen Sie unbedingt bis zum Ende, der Kontext der Konfiguration eines Service Consumer oder Service Provider ist bei der Bewertung wichtig!

Was ist überhaupt der SOAMANAGER?


Wozu ist denn der SOAMANAGER überhaupt gut? Die Technologie ist im wesentlichen dazu da, ABAP-Funktionsbausteine des SAP-Systems als Web Services zur Verfügung zu stellen, und im Gegenzug diese von anderen SAP-Systemen zu konsumieren. 

Zwar kann der SOAMANAGER auch andere WSDL Web Services konsumieren, aber im Wesentlichen wird er im SAP Umfeld vor allen Dingen zur Bereitstellung von ABAP Geschäftslogik über das Web genutzt.

Was ist denn jetzt schon wieder WSDL?


WSDL steht für Web Services Description Language und ist ein offizieller Standard des W3C. Dabei handelt es sich um einen XML Dialekt, welcher einen Web Service beschreibt.

Ein WSDL Web Service arbeitet mit einem sogenannten Binding. Der Web Service kann mehrere Aktionen haben, zum Beispiel Auslesen (bzw. Abrufen) oder Abspeichern (bzw. Senden) von Daten. Jede dieser Aktion wird mit einem logischen Port verknüpft. Ein WSDL Web Service kann also über mehrere logische Ports aufgerufen werden.

Wenn Sie im SAP System einen Web Service definieren, erstellen Sie meistens ein entsprechendes WSDL Dokument. Dieses WSDL Dokument definiert die verschiedenen Funktionen, die der Web Service nach außen hin anbietet.

Diese Funktionen können nun auf unterschiedliche Art und Weise konsumiert werden. Die zwei gängigsten Beispiele ist ein Konsum eines Web Service über SOAP oder als RESTful Service.

SOAP und REST Services über den SOAMANAGER


Sowohl das Simple Object Access Protocol (SOAP) als auch jede Form von Representational State Transfer (REST) Protokollen sind für die eigentliche Kommunikation zuständig. Sie übertragen also Daten an den Service, die dieser dann mit Hilfe seiner angebotenen Funktionen interpretiert und manipuliert.

Die beiden Ansätze unterscheiden sich in der Art und Weise, wie diese Datenübertragung statt findet. SOAP unterstützt ausschließlich den XML-Standard. Das heißt zu zu übertragende Daten müssen in eine XML-Struktur überführt werden, bevor der Web Service aufgerufen wird.

Ein RESTful Web Service versteht hingegen verschiedene Datenformate. Neben XML können die zu übertragenden Daten auch in einem HTML- oder JSON-Dokument enkodiert sein. Vor allen Dingen JSON ist in dieser Hinsicht wesentlich schlanker als XML und reduziert dadurch den zu übertragenden Brutto Datenpayload. RESTful Services werden daher besonders gerne im Mobile Umfeld verwendet.

Im SAP Umfeld kennen wir alle ein RESTful Web Service Protokoll: Das von Microsoft implementierte OData Protokoll. Es basiert auf JSON und ist eine sehr weit verbreitete Implementierung der REST Architektur.

Wie erstellt man in SAP einen Webservice?


Die klassische Vorgehensweise zur Erstellung eines Web Services (wir reden jetzt nicht von einem OData Service über SAPUI5 und das NetWeaver Gateway, sondern über die ABAP Welt) ist wie folgt:

  1. Sie erstellen in der SE37 einen ABAP Funktionsbaustein mit der gewünschten Web Service Funktionalität und setzen diesen im Reiter Attributes -> Processing Type auf „Remote-Enabled“. Damit kann der Funktionsbaustein aus der Ferne aufgerufen werden. Erstmal allerdings nur über RFC und nicht über das Web.
  2. Dafür müssen wir einen Webservice erstellen. Dies geht im Funktionsbaustein im Menü unter Utilities -> More Utilities -> Create Web Service -> From the Function Module. Die Einstellungen, welche Sie im Wizard tätigen, können Sie nachträglich auch noch ändern.
  3. Sie öffnen nun die Transkation SOAMANAGER. Dort konfigurieren Sie nun das WSDL Dokument zu diesem Web Service und erstellen dadurch die sogenannten Bindings. Sie tun dies im Reiter Service Adminisration -> Web Service Configuration. Filtern Sie nach Object Name und suchen Sie den soeben erstellten Web Service.
  4. Wählen Sie den Service auf und begeben Sie sich in den Reiter Configurations. Wählen Sie „Create Service“. Im Folgebildschirm geben Sie unter „Service Name“ den Namen des Services ein. Nun legen Sie eines von eventuell mehreren Bindings für diesen Service an. Im Punkt Provider Security können Sie nun die ersten Sicherheitseinstellungen für dieses Binding festlegen. Genau diesen Schritt werden wir genauer in diesem Posting durchleuchten
  5. Nach Abschluss der Konfiguration aktivieren Sie den Service und generieren dadurch die WSDL Definition und eine URL zum Aufruf des Services. Sie können den Service im Anschluss beispielsweise über soapUI testen, indem Sie die .wsdl-Datei des Services downloaden und in soapUI laden.
SOAMANAGER IT Sicherheits Audit
Im Wizard zur WSDL Definition eines Web Services in der Transaktion SOAMANAGER stolpern Sie irgendwann über die Konfiguration der „Provider Security“

Wie sichert man den SOAMANAGER ab?


Reden wir nicht mehr um den heißen Brei herum und kommen zu dem, was den Kunden (und Sie als Leser) am brennendsten interessiert. Um einen Web Service beziehungsweise den SOAMANAGER ordnungsgemäß abzusichern, müssen Sie auf verschiedenen Ebenen schrauben.

  • In der Konfiguration des Web Services
  • In der Konfiguration des SOAMANAGER
  • In der Konfiguration des Internet Communication Manager (ICM)

SAP Web Service Sicherheitsvoreinstellungen


Beginnen wir mit Konfiguration des Web Service an sich. Hierzu begeben Sie sich zunächst über die SE37 bzw. die SE80 in die Konfiguration des Funktionsbausteins. Dort finden Sie die entsprechende Service Definition. 

 Den ersten Schritt zur Anpassung der Sicherheitskonfiguration machen Sie in der Konfiguration des eigentlichen Funktionsbausteins.

Von dort können Sie in den Reiter Konfiguration wechseln. Begeben Sie sich in den Bereich Sicherheitsprofil, um die ersten sicherheitsrelevanten Einstellungen vorzunehmen. Die Einstellungen, die Sie hier tätigen, gelten als Mindeststandard. Sie können in der Transaktion SOAMANGER abweichende Einstellungen vornehmen, wenn diese einem höheren Sicherheitsprofil als dem in der Servicedefinition gewählten entsprechen. Das im Service definierte Sicherheitsprofil kann jedoch nicht unterschritten werden.

Die Konfiguration des Sicherheitsprofils hat Auswirkungen auf die Authentifizierungsstufe des Web Services

Das Sicherheitsprofil beeinflusst die Folgeeinstellung der Authentifizierungsstufe und der Transportsicherheit. Ein Sicherheitsprofil mit Status Hoch bewirkt eine Authentifizierungsstufe vom Typ Strong. Dies hat zur Folge, dass für die Authentifizierung zwingend X.509 Client-Zertifikate genutzt werden müssen. Der Aufrufer des Web Services muss also mit einem Zertifikat beim Web Service authentifiziert werden.

Die Sicherheitsprofile Mittel oder Niedrig führen beide zur Authentifizierungsstufe Basic. Damit ist eine ganz normale Authentifizierung über Benutzername und Kennwort gemeint. Die beiden Sicherheitsprofile unterscheiden sich in der Position der Authentifizierungsdaten.

Sicherheitsprofil Mittel: Die Authentifizierungsdaten werden im HTTP-Header gesendet und können in der Standardeinstellung sowohl über HTTP als auch über HTTPS gesendet werden.

Sicherheitsprofil Niedrig:  Diese Einstellung führt zu einer sogenannten Document Authentication. Die Authentifizierungsdaten erfolgen anhand der im Dokument gespeicherten Benutzername und Kennwort Kombination.

Sicherheitsprofil None: Führt zur Authentifizierungsstufe None. Es findet keine Authentifizerung statt.

Den Unterschied zwischen der HTTP Header Authentication und der Document Authentication sehen Sie in folgendem Screenshot aus dem soapUI Portal. Orange markiert sehen Sie den übergebenen Wert aus dem HTTP Authentication Header, rot markiert die Anmeldeinformationen im Dokument selbst.

Der Unterschied liegt hier also im Detail. Die Einstellung kann beispielsweise in Zusammenhang mit Intrusion Detection Systemen relevant sein. Eine Header Authentication gilt allgemein als sicherer, weil ohne ein erfolgreiche Header Authentifizierung der Payload, also das Dokument, nicht mal betrachtet werden muss.

Wie Sie sehen, ist das SOAP-Dokument im Standard unverschlüsselt und der Dokumententext einfach nur Base64 enkodiert. Eine Verschlüsselung der Anmeldeverfahren können Sie für beide Verfahren implementieren. Erlauben Sie den Datenaustausch nur per HTTPS, bestimmt der verwendete TLS-Cipher die Verschlüsselung von Header- und Dokument-Authentifizierungsdaten. Diese Einstellung nehmen Sie im Bereich Transportsicherheit vor.

Alternativ zur Verschlüsselung über HTTPS können Sie HTTP-Verkehr erlauben und stattdessen die eigentliche Nachricht, also den SOAP Body, signieren und verschlüsseln. Der HTTP Header kann somit im Klartext versendet werden, der Body ist jedoch in sich verschlüsselt und vom Absender signiert.

Wenn Sie im Wizard zum Anlegen einer Service-Definition die Profile PRF_DT_IF_SEC_HIGH oder nachträglich in der Web Service Konfiguration das Profil Hoch auswählen, muss der Web Service sowohl über eine Verschlüsselung zur Sicherstellung der Vertraulichkeit (HTTPS oder Document Verschlüsselung) als auch über eine Maßnahme zur Sicherstellung der Integrität (in Form von Transportgarantien) verfügen.

Wählen Sie im Wizard hingegen PRF_DT_IF_SEC_MEDIUM bzw. eine Transportischerheitsstufe von Mittel, sind Transportgarantien keine Pflicht. Es wird also verschlüsselt, aber die Datenübertragung kann auch flüchtig geschehen.

Wählen Sie ein Profil von Niedrig, muss weder Verschlüsselung noch Transportgarantie, aber immer noch eine Authentifizierung (über HTTP Header oder Document Authentication) von statten gehen. Wählen Sie ein Transportsicherheitsprofil von None, kann der Service auch ohne Authentifizierung konsumiert werden.

 Wichtiger Hinweis: Es macht wenig Sinn, die Authentifizierung über den HTTP-Header durchzuführen und diesen unverschlüsselt über das Netzwerk zu versenden. Wenn Sie also für die Transportsicherheit nicht auf HTTPS setzen wollen, sondern einfach nur den SOAP Body verschlüsseln, sollten Sie auch die Dokumentenauthentifizierung wählen.

SOAMANAGER Voreinstellungen


Kommen wir nun zu den sogenannten Voreinstellungen des SOAMANAGER. Wie wir bereits gelernt haben, können Sie diese grundsätzlich unterschiedlich von den Voreinstellungen des Web Services pflegen. Sie können die Voreinstellungen jedoch nicht unterbieten, andernfalls ist der jeweilige Web Service nicht konsumierbar. Sie können nur höhere Sicherheitsstandards ansetzen, aber nicht niedrigere.

Begeben Sie sich dazu in der Transaktion SOAMANGER in den Bereich Applikations- und Scenario-Administration -> Administration einzelner Services -> für Services und Consumer-Proxys. Wählen Sie die Details des jeweiligen Services.

Unter Sicherheit auf Transportebene legen Sie fest, ob Sie HTTPS Verschlüsselung nutzen wollen oder nicht. Sie können alternativ im nächsten Bereich, Sicherheit a. Nachrichtenebene, die Verschlüsselung auf Dokumentenebene implementieren, oder lediglich eine Signatur einstellen.

Hinweis: Die Verschlüsselung auf Nachrichtenebene hat den Vorteil, dass sie auch dann noch intakt ist, wenn beispielsweise durch einen Reverse Proxy eine SSL Termination erfolgt. Dadurch ist der Nachrichteninhalt auch im internen Netz noch verschlüsselt. Sie werden jedoch sehen, dass in den Empfehlungen der SAP immer eine Verschlüsselung auf Transportebene erfolgen sollte. Eine Verschlüsselung auf Nachrichtenebene alleine ist nicht im Sinne des Herstellers. Sie ist lediglich eine zusätzliche Absicherungskomponente.

Wenn Sie einen Haken bei Sichere Konversation setzen, wird das Verfahren WS-SecureConversation aktiviert. Voraussetzung ist eine SAP-interne SSL-Vertrauensbeziehung zwischen den beiden Systemen und die Konfiguration der SSF-Funktionalität. Die Einstellung bedeutet nicht, dass die anderen Verfahren per se unsicher sind. Es bedeutet nur, dass ein von SAP empfohlenes Verfahren genutzt wird, in welchem vorab symmetrische Schlüssel ausgetauscht werden, ohne dabei ein asymmetrisches Verschlüsselungsverfahren wie OpenPGP zu nutzen – sondern ein symmetrisches Verschlüsselungsverfahren. Die Option „Signatur und Verschlüsselung“ alleine ist im Endeffekt auch als „sicher“ zu betrachten.

Wenn Sie einen Haken bei Erweiterter Signatur- und Header-Schutz setzen, wird folgendes Verfahren genutzt. Dadurch stellen Sie sicher, dass die Signatur vor ihrer Übertragung verschlüsselt wird. Kommuniziert das als Service Provider fungierende SAP System mit einem anderen SAP-System, werden diese SAP-eigenen Headerdaten verschlüsselt. Wenn das SAP System als Service Consumer fungiert, wird der SOAP Header veschlüsselt. Das sollten Sie tun, wenn Sie beispielsweise die SOAP-Nachricht nicht bereits in HTTPS kapseln.

Im nächsten Bereich, unter Authentifizierungseinstellungen, kommt es stark auf die Voreinstellungen des Web Service an. Wenn Sie im Web Service in der SE80 das Sicherheitsprofil auf Mittel oder Niedrig gestellt haben, können Sie hier eine Benutzeranmeldung über Benutzername und Kennwort einstellen.

Der „ABAP-Service-Benutzer“ ist ein Benutzer auf dem SAP NetWeaver AS ABAP, der zum Aufruf des hinter dem Web Service steckenden Funktionsbausteins per RFC genutzt wird. Es sollte sich hierbei um einen Service-Benutzer handeln, der sich am System nicht interaktiv anmelden kann und minimale Berechtigungen erhält.

Wenn Sie nicht eine Authentifizierung über einen individuellen SAP Benutzer, sondern über einen ABAP Service User entscheiden, geschieht dies oft, weil eine Middleware in die Kommunikation involviert ist. Dieses Szenario spreche ich weiter unten an. Grundsätzlich sollte sich jeder User mit seinem eigenen, persönlichen Benutzer anmelden, um den Service zu konsumieren. Die Verwenndung des ABAP-Service-User ist jedoch in Ordnung, wenn eine technische Komponente die dazwischen sich um die Authentifizierung der Endbenutzer kümmert.

Wenn Sie einen Authentifizeurngsmechanismus für Single Sign-On verwenden (also SPNego, SAP Logon Tickets oder SAML), wird dieser Service Benutzer nicht für den Aufruf verwendet, sondern die Identität des im Konsumentensystem ngemeldeten Benutzer an das Anbietersystem propagiert.

Ein Anwender würde sich zunächst mit seinem Benutzer am Clientsystem anmelden und würde  mit seiner Identität den dahinterliegenden Funktionsbaustein aufrufen. Bei allen anderen Varianten meldet sich der Benutzer zwar mit seinem auf dem Anbietersystem gespeicherten Benutzer an, jedoch erfolgt der Aufruf über den ABAP Service Benutzer.

 Hinweis: Steht bei Authentifizierungsstufe: None, findet keine Authentifizierung statt. Jeder kann den Funktionsbaustein mit den Rechten des ABAP-Service-Benutzer aufrufen.

Der ABAP Service Benutzer benötigt in der Regel die Rolle SAP_BC_WEBSERVICE_CONSUMER. Die anderen WEBSERVICE-Rollen sind in der Regel nicht notwendig. Diese werden wir in einem späteren Kapitel genauer erläutern.

Im letzten Bereich regeln Sie die Authentifizierung.  Damit Sie hier Einstellungen festlegen können, müssen Sie unter Authentifizierungsmethode den Haken bei Keine Authentifizierung entfernen. Unter Authentifizierung auf Transportebene können Sie dann im Anschluss folgende Optionen festlegen

  • Benutzer-ID und Kennwort: Benutzer-ID und Kennwort werden über eine Anmeldemakse per HTTP Protokoll übergeben. Bei einem Transport-Sicherheitsprofil von Strong haben Sie diese Auswahlmöglichkeit nicht.
  • X.509-SSL-Client-Zertifikat. Die Authentifizierung erfolgt über X.509 SSL/TLS Zertifikate. Hierzu muss eine entpsrechende Vertrauensstellung zwischen den Systemen konfiguriert werden.
  • Single Sign-On über SAP-Zusicherungsticket. Die Anmeldung über SAP Logon Tickets gilt wird vom Hersteller grundsätzlich nicht mehr empfohlen. Sofern die Übertragung allerdings per 
  • Single Sign-On über SPNego ist ein Verfahren zur Anmeldung an Webservices über Kerberos und gilt als sicher, solange die SNC-Parameter snc/… entsprechend konfiguriert wurden.

Zusätzlich oder alternativ zur Authentifizerung auf Transportebene können Sie auch auf Nachrichtenebene eine sogenannte Dokumentenauthentifizierung konfigurieren. Hierbei stehen Ihnen folgende Konfigurationsmöglichkeiten zur Verfügung. 

Hinweis: Authentifizerung auf Nachrichtenebene erfolgt grundsätzlich unverschlüsselt. Sie können also die Integrität einer Nachricht sicherstellen, aber nicht deren Vertraulichkeit. Sie müssen sie entweder durch eine Verschlüsselung auf Nachrichtenebene oder eine Verschlüsselung auf Transportebene absichern. Diese Einstellung konnten Sie weiter oben tätigen. Weitere Informationen im SAP Help Portal unter Verwendung der Authentifizierung auf Nachrichtenebene.

  • Benutzer-ID und Kennwort. Hierbei erfolgt die Authentifizierung über die im abgesendeten XML Dokument hinterlegten Anmeldedaten. Diese sind in der Regel, wie oben gezeigt, unverschlüsselt, wenn Sie weiter oben im Bereich Sicherheit a. Nachrichtenebene keine Verschlüsselung implementiert haben. Um zu verhindern, dass die Authentifizierungsdaten im Klartext übertragen werden, sollten Sie zusätzlich eine Verschlüsselung auf Transportebene (HTTPS) implementieren. Genauer gesagt handelt es sich um das Verfahren WS-Security UsernameToken.
  • X.509-Zertifikat. Die Anmeldung erfolgt über eine signierte SOAP-Message, die mit dem auf dem SAP-System hinterlegten Zertifikat übereinstimmen muss. Dies gilt als sicher, sofern das Zertifikat durch einen privaten Schlüssel gesichert ist. Genauer gesagt handelt es sich um das Verfahren WS-Security XML Signature/Encryption.
  • Single Sign-On mit SAML 1.1 Assertions. Dieses Verfahren gilt als sicher, sofern Sie beim Service-Provider nicht das auf DSA-basierende Client-Zeritfikat, sondern ein auf RSA basierendes Zertifikat verwenden oder den Haken bei „Sichere Kommunikation“ gesetzt haben. Weitere Informationen dazu erhalten Sie im SAP Help Portal.

Konfigurationsempfehlungen und Anleitungen von der SAP

Sie werden sich jetzt vielleicht denken: Boah! Das ist ja voll der Overkill. Ich wollte eigentlich wissen, wie ich meinen Webservice sicher konfiguriere, und keine Masterarbeit schreiben. Dann kann ich Sie trösten: Die SAP liefert einfach verständliche Konfigurationsempfehlungen aus.

Dort erhalten Sie eine Entscheidungsmatrix, welche Konfigurationsprofile Ihnen bei welchem SAP NetWeaver Release empfohlen werden. Grundsätzlich empfiehlt Ihnen der Hersteller, ein Verfahren zu wählen, bei welchem die Identität des Benutzers auf dem Clientsystem propagiert wird und gleichzeitig Sicherheit auf Nachrichtenebene bietet. 

Andere Einstellungen sollten Sie wählen, wenn Sie keine andere Wahl haben, weil Sie etwa kein Single Sign-On Verfahren nutzen können. Links in der Navigationsleiste erhalten Sie außerdem Konfigurationsbeispiele für AS ABAP und AS Java. Dort wird Ihnen die Konfiguration der empfohlenen Szenarien entsprechend gezeigt.

Eins sollte Ihnen beim Betrachten der Konfigurationsempfehlungen auffallen: Es wird keine einzige Konfiguration empfohlen, bei welcher keine Authentifzierung über einen SAP-Endbenutzer verwendet wird. Ist ja auch logisch, denn niemand soll ohne Authentifzierung dazu in der Lage sein, einen Funktionsbaustein zu nutzen, welcher sensible Daten preis gibt oder verändert.

Warum findet man trotzdem in vielen SAP Systemen Webservices, die in der Laufzeitkonfiguration des SOAMANAGER ohne Authentifizierung konfiguriert werden, sondern stattdessen nur einen ABAP Service Nutzer hinterlegt haben?

Das kann einen legitimen Grund haben. Beispielsweise wenn zwischen dem Service Consumer und dem Service Provider eine Middleware tätig ist. Der Workflow ist dann in der Regel so

  • Der Service Consumer meldet sich über einen Authentifzierungsmechanismus an der Middleware an
  • In der Konfiguration der Middleware-Komponente sind Benutzername und Kennwort des ABAP Service User hinterlegt, der beim Service Provider hinterlegt wurde
  • Die Middleware Komponente ruft den Web Service des Service Providers auf und verwendet dabei den ABAP Service Benutzer und dessen Kennwort, welches zuvor vom Administrator eingepflegt wurde.
  • Der Service Provider empfängt den Request über die Middleware und liefert eine Antwort
  • die Middleware liefert die Antwort des Service Provider an den authentifzierten Benutzer der Middlewarekomponente aus.

Diese Konfiguration ist per se nicht unsicher. Denn zum einen muss der Administrator Benutzername und Kennwort des ABAP Service User kennen, um sich am Service Provider zu authentifizieren. Zum Anderen, und das ist wichtig, muss sich der Service Consumer, also der Endbenutzer, an der Middlewarekomponente authentifzieren.

Entfällt die Authentifizierung an der Middlewarekomponente jedoch, bedeutet dies wiederum, dass jeder über die Middleware die Schnittstelle nutzen kann, ohne sich mit einem personalisierten User authentifizieren zu müssen. Das ist wiederum aus Sicht eines Security Auditors ein No-Go. Deswegen finden Sie dieses Konfigurationsszenario auch nicht in den Empfehlungen der SAP. Es kommt also ganz konkret auf die Situation an.

Ebenfalls sollte Ihnen auffallen, dass in den Konfigurationsempfehlungen der SAP nur solche Konfigurationen als sicher gelten, welche entweder das herstellereigene Verfahren WS-SecureConversation oder eine simple HTTPS Verschlüsselung verwenden. Eine Verschlüsselung lediglich auf Nachrichtenebene gilt als unzureichend, kann jedoch zusätzlich erfolgen.

Profilparameter zur Absicherung des SOAMANAGER

Zusätzlich zu den weiter oben geschilderten Überlegungen können Sie noch weitere Maßnahmen ergreifen, um Ihre Enterprise Services entsprechend abzusichern.

  • wdisp/max_permitted_uri_len. Bestimmt die maximale Länge eine URL, die der Web Dispatcher entgegen nehmen kann. In einigen Angriffsszenarien wird über die URL ein Redirect über eine andere, sensible URL versucht, die ursprünglich seitens des Web Dispatchers gefiltert wird. Um hier auch in der letzten Verteidigungslinie eine Gegenmaßnahme bieten zu können, sollte die maximale Länge einer URL begrenzt werden. Der Standardwert von 2048 Zeichen kann hier beispielsweise auf 255 geändert werden. Vorsicht: Dieser Parameterwechsel muss getestet oder auf Basis der Zugriffs-Logs des Web Dispatchers bestätigt werden, um sicherzustellen, dass im Tagesbetrieb keine URLs höherer Länge benötigt werden.
  • wdisp/max_uri_char_range. Bestimmt anhand der dezimalen Repräsentation eines ASCII-Zeichens die erlaubten Zeichen in einer URL. Beispiel: 37-127 entspricht den normalen alphanumerischen Zeichen auf der Tastatur. Um in der letzten Verteidigungslinie Angriffsszenarien über Sonderzeichen zu verhindern (um beispielsweise Kommentarzeichen für eine SQL-Injection zu inkludieren), sollten die erlaubten Zeichen beschränkt werden. Wenn zusätzlich das %-Zeichen verboten wird, verhindert man auch die URL-Kodierung von Sonderzeichen (Vorsicht: hier besteht Testbedarf).
  • wdisp/max_url_map_entries. Bestimmt die maximale Anzahl von Einträgen in der URL-Mapping-Tabelle des SAP Web Dispatchers.
  • wdisp/max_permission_table_size. Beschränkt die maximale Anzahl von Einträgen in der URI-Permission-Tabelle. Dies verhindert beispielsweise die Injection neuer Einträge in die Tabelle über beispielsweise gekaperte Cronjobs.
  • wdisp/max_permission_table_entry_size. Bestimmt die maxiamle Anzahl von Zeichen in einem Eintrag in der Permission Tabelle des Web Dispatchers. Dies bildet eine zusätzliche Verteidigungslinie gegen Injections neuer Einträge in die Tabelle.
  • wdisp/server_info_location. Angabe, woher der SAP Web Dispatcher die Information über die Applikationsserver bekommt, an die er die Web Requests verteilen kann. Der SAP Web Dispatcher bezieht seine Serverinformation vom Message-Server. Der Parameter gibt die (relative) URL an, wo diese Information im Message-Server steht. Sie können diese Information auch in einer Datei hinterlegen. In diesem Fall können Sie mit diesem Parameter den Dateipfad angeben, indem Sie ihn auf file://<path> setzen.

Steuerung des Zugriffs auf SICF-Knoten über den SAP Web Dispatcher

Über den SAP Web Dispatcher oder einen anderen Reverse Proxy Ihrer Wahl sollten Sie den Zugriff auf die einzenen Web Services sowie auf die Konfiguration des SOAMANAGER einschränken. Die einzelnen WSDL-Knoten finden Sie in der Regel unterhalb von /sap/bc/srt/wsdl.

Schränken Sie außerdem den Zugriff auf den SICF-Knoten /sap/bc/webdynpro/sap/appl_soap_management sowie auf /sap/admin ein.  Sie können den Zugriff beispielsweise auf den IP-Adressbereich Ihrer Administrator-Arbeitsplätze beschränken. Beachten Sie außerdem, dass über den Knoten /sap/bc/gui/sap/its/webgui ebenfalls ein Aufruf der Transaktion SOAMANAGER möglich ist.

Absicherung von ICF Knoten über das Berechtigungsobjekt S_ICF.

Zusätzlich zu einer Application Level Firewall (ALF) wie den SAP Web Dispatcher können Sie die einzelnen SICF-Knoten außerdem über das Berechtigungsobjekt S_ICF absichern. Hierbei konfigurieren Sie für einen bestimmten SICF-Knoten zunächst einen sogenannten „SAP Authorization String“, wie im Screenshot gezeigt.

SICF Knoten im SAP System über Berechtigungen absichern.

Im Anschluss können Sie denn in einer Rolle das Berechtigungsobjekt S_ICF hinzufügen und dort das Feld ICF_FIELD mit diesem String befüllen. Damit genehmigen Sie den Zugriff auf genau diesen (und keinen anderen) SICF Knoten.

Rollen und Berechtigungen

Die folgende Tabelle zeigt eine offizielle Übersicht der SAP zu den verschiedenen Standard Rollen im Web Service Umfeld. Beachten Sie, dass der ABAP Service User in der Regel lediglich die Rolle
SAP_BC_WEBSERVICE_SERVICE_USER benötigt, keine andere.

Rolle Beschreibung
SAP_BC_WEBSERVICE_SERVICE_USER Rolle für Hintergrundbenutzer der Web Service Runtime
SAP_BC_WEBSERVICE_ADMIN_TEC Rolle für technische Administration Web Services Monitoring von Sequences, Messages, Logging, Tracing, bgRFC , Process Integration Monitoring der Payload für Component SAP_BASIS Administration von Tracing and Logging, bgRFC , RFC Definition, Ausführung und Publizierung von Web Services Adminstration des Internet Communication Framework Administration der RFC-Destination Administration des Task Watcher and Event Handler
SAP_BC_WEBSERVICE_ADMIN_BIZ Rolle für den Business Administrator
SAP_BC_WEBSERVICE_CONSUMER Nutzer eines Web Service
SAP_BC_WEBSERVICE_OBSERVER Benutzerrolle zur Ansicht aller Informationen zu Web Services
SAP_BC_WEBSERVICE_DEBUGGER Rolle mit Berechtigung zum Debuggen
SAP_BC_WEBSERVICE_ADMIN Administrationsberechtigungen für Web Services im AS ABAP, veraltet, aber noch gültig

Pflege der Tabelle HTTP_WHITELIST

Eine weitere Maßnahme ist die Pflege der Tabelle HTTP_WHITELIST. Diese fixiert URLs, die für eine Weiterleitung innerhlab einer WebDynpro ABAP bzw. Business Server Page (BSP) erlaubt sind. Beispielsweise könnte der Funktionsbaustein sap-exiturl beim Verlassen einer Stateful BSP genutzt werden, um eine entsprechende Weiterleitung auf einen Web Service auszuführen, der andernfalls nicht erreichbar wäre.

Um zu verhindern, dass die URL Filter des SAP Web Dispatcher durch eine Weiterleitung umgagngen werden, empfiehlt sich daher die Pflege einer Whitelist. Ein beispielhafter Eintrag würde wie folgt aussehen.

Protocol=https,host=nonprod.organisation.org,port=23443,url=/sap/redirects/*

In ihren eigenen ABAP-Entwicklungen können Sie die Tabelle HTTP_WHITELIST über den Funktionsbaustein CL_HTTP_UTILITY=>CHECK_HTTP_WHITELIST prüfen.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.