SAP-Systeme unterliegen besonderen Sicherheitsvorgaben. Da sie in der Regel kritische Daten für den Geschäftsbetrieb enthalten, sollte an dieser Stelle sämtlichen Security-Aspekten besonderes Augenmerk gelten. Betrachtet man SAP-Systeme zunächst aus der Innensicht als isolierte Einheiten, gelten folgende Maßnahmen als Grundsicherung:

Die SAP-Software Governance, Risk und Compliance (GRC) Suite unterstützt Anwender dabei, diese firmeninternen Security-Aspekte unter Kontrolle zu behalten.

Allerdings funktionieren SAP-Systeme selten isoliert. Die meisten Geschäftsprozesse erstrecken sich heute über vielfältige Systeme und auch über Unternehmensgrenzen hinweg, zum Beispiel zwischen verschiedenen Firmen oder über mobile Zugriffe, so dass Daten auch öffentliche und unsichere Netze passieren. Deshalb sind zusätzliche Anstrengungen notwendig, um die Datenwege abzusichern. Nur so lässt sich die Datenvertraulichkeit und -integrität wahren - die beiden wesentlichen Elemente eines gesicherten Datentransfers. Folgende Techniken helfen, den Datenaustausch in SAP-Landschaften abzusichern.

Netzsicherheit

Netzwerkzonen

Unternehmen setzen für ihre Intranets in den meisten Fällen TCP/IP-Netze ein. Die Technik gestattet es, Netze auf Basis von IP-Adressen, Netzmasken und Routing-Daten in Datenblöcke zu untergliedern. Diese miteinander verbundenen Segmente bezeichnet man als Netzwerkzonen. Der Sicherheit halber sollten Anwender ihre SAP-Systeme in eine separate Netzwerkzone legen. Das bringt folgende Vorteile:

• Man kann eindeutig zwischen der Benut-zergemeinschaft und den Backend-Sys-temnetzen unterscheiden.

• Für das Backend lässt sich ein strengeres Sicherheitsniveau anwenden.

• Das Filtern des ein- und abgehenden Netzverkehrs erlaubt eine bessere Zugriffskontrolle für das Backend.

• Der Netzverkehr lässt sich besser optimieren.

Firewalls

Wichtige Elemente einer effektiven Zugriffskontrolle sind Firewalls. Diese legen fest, welche Verbindungen sich zwischen Kommunikationspartnern herstellen lassen. Es gibt abhängig von der Information, die sie benutzen, um den Netzverkehr zu filtern, zwei Typen von Firewalls:

1. Paketfilter können den Netzverkehr auf Basis der Information filtern, die in den TCP- und/oder IP-Vorsätzen, zum Beispiel IP-Adresse und TCP-Ports, enthalten ist.

2. Application-Gateways filtern den Verkehr auf Basis von Informationen auf Anwendungsebene. Das heißt, sie können Informationen herausziehen, die sich tiefer in der Anwendung befinden.

SAP bietet keine Paketfilter-Firewall. Bei Application-Gateways stehen dagegen mehrere Möglichkeiten zur Verfügung:

• Der SAProuter kann den Datenverkehr in der SAP-Netzschnittstelle, einer privaten Netzzwischenschicht, die von SAP-Protokollen wie RFC und DIAG genutzt wird, weiterleiten und filtern.

• Der SAP Web Dispatcher kann an Netweaver-Anwendungs-Server gerichtete HTTP(S)-Anfragen filtern.

Damit lässt sich eine effiziente Zugriffskontrolle zu den Backend-Systemen erreichen:

• Externe Geschäftspartner verbinden sich nicht direkt mit dem Backend-System. Stattdessen werden ihre Anfragen vom SAProuter/SAP Web Dispatcher in der Demilitarisierten Zone (DMZ) gefiltert und weitergeleitet.

• Die Firewall der Backend-Netzzone lässt nur Verkehr zu, der von den Application-Gateways in der DMZ stammt.

• Die Backend-Netzzone wird ferner durch eine zweite interne Firewall des internen Benutzernetzes geschützt.

Die Sicherheit lässt sich erhöhen, indem die DMZ in zwei Zonen unterteilt wird:

• eine äußere DMZ,

• eine innere DMZ.

Die äußere DMZ dient als Einstiegspunkt vom Internet in das Unternehmen. Die innere DMZ bildet den Zugang zum Backend-Netz, entweder von der äußeren DMZ oder vom internen Benutzernetz, wobei hier innere SAProuter, innere SAP Web Dispatcher oder Portalsysteme eingesetzt werden, die es gestatten, auf Inhalte im SAP-Backend zuzugreifen.

Reverse Invoke

"Reverse Invoke" ermöglicht den Aufbau von Netzverbindungen vom Backend aus. Das erhöht die Netzsicherheit, da die Firewalls keinerlei Verbindungsaufbau von außen zulassen. SAProuter wie auch SAP Web Dispatcher lassen sich für eine Nutzung mit Reverse Invoke einrichten.

Ein Beispiel: Eine Web-Anwendung wird durch ein SAP-System im Backend-Netz bedient. Möchte ein Benutzer die Web-Anwendung nutzen, startet er einen Web-Browser und verbindet sich mit einem SAP Web Dispatcher in der DMZ. Der SAP Web Dispatcher dient als Einstiegspunkt. Ist jedoch eine Reverse-Invoke-Verbindung eingerichtet, wird die Verbindung im SAP-System vom "Internet Communication Manager" (ICM) initiiert und nicht vom SAP Web Dispatcher. Daher lässt sich die innere Firewall so einstellen, dass keine eingehenden Verbindungen gestattet sind.