iX 2/2020
S. 112
Wissen
SAP-Security

SAP-Basiswissen – ein kleines Kompendium

Stabiles Fundament

Safuat Hamdy, Marco Hammel

In der SAP-Welt funktioniert vieles etwas anders als in anderen Bereichen der IT. Eine lockere Artikelserie zu SAP-spezifischen Sicherheitsanforderungen soll Aufklärung schaffen.

Auf Außenstehende wirkt die SAP-Welt wie ein schwer zugängliches Paralleluniversum, die Community gleicht einer Geheimloge mit eigener Sprache und eigenen Ritualen. In Sachen IT-Sicherheit geht es hier vor allem um Rollen und Berechtigungen, ein fraglos wichtiger, aber eben nicht der einzige Aspekt. Wenn selbst Securityfachleuten oftmals das grundsätzliche Verständnis fehlt, können sie weder die richtigen Fragen stellen noch notwendige Maßnahmen vorschlagen. Das wäre jedoch dringend erforderlich, denn auch SAP-Installationen haben kritische Schwachstellen jenseits von Rollen und Berechtigungen. Die Bedeutung von Sicherheit in diesem Umfeld dürfte sich erschließen, wenn man bedenkt, dass Organisationen diesen Systemen oft ihr gesamtes digitales Vermögen oder zumindest wesentliche Anteile davon anvertrauen.

Dieser Artikel startet eine lose Serie zum Thema SAP-Sicherheit. Dazu gehören zunächst die Grundlagen und darauf aufbauend Penetrationstests, Security Operations, Incident Detection, Response und Forensik. Die Beiträge sollen Nicht-SAP-Fachleuten ein Verständnis des Systems vermitteln, ohne dass sie zahlreiche Kurse absolvieren müssen. Dieses Kompendium und die daran anschließenden Teile beschreiben verschiedene Techniken, von R/3 über NetWeaver und HANA bis zur SAP Cloud.

Der Vielfalt und Komplexität der einzelnen Techniken unter der Dachmarke kann man natürlich nicht komplett gerecht werden. Spitzfindige Experten unter den Lesern mögen es daher nachsehen, wenn einige Punkte zugunsten des Verständnisses vereinfacht dargestellt sind. Ziel ist, zu zeigen, wie die SAP-Welt grundsätzlich tickt.

Alle Unternehmen, Behörden und Organisationen müssen ihre Ressourcen und immer komplizierteren Abläufe mit IT-Systemen steuern und überwachen. Die Ressourcen umfassen Kapital, Material, Waren, Fahrzeuge, Betriebsmittel, Betriebseinrichtungen, aber auch Personal, Kunden, Lieferanten und Verschiedenes mehr. Als besondere Herausforderung gilt, die zahlreichen beteiligten Anwendungen (ERP, CRM, HR et cetera) mit weiteren Systemen zusammenzubringen, etwa Produktionsanlagen und Fertigungsstraßen.

System für große Aufgaben

Auch wenn das Akronym SAP gerne spöttisch als „Sanduhr-Anzeige-Programm“ gescholten wird, gründet sich der Erfolg des Unternehmens darauf, dass sich viele Produkte gut dazu eignen, große Transaktionslasten und enorme Mengen strukturierter Daten zu bewältigen. Darüber hinaus arbeiten verschiedene betriebswirtschaftliche Anwendungen wie Rechnungswesen, Marketing und Produktionsplanung auf einem einheitlichen Datenmodell und mit denselben Kundenstammdaten. In der Regel gehört die Integration der verschiedenen Angebote zum Lieferumfang.

R/3, im Juli 1992 veröffentlicht, war – und ist es bei manchen Anwendern immer noch – eine monolithisch aufgebaute Client-­Server-Software, die von Warenwirtschaft bis Personalverwaltung verschiedene betriebswirtschaftliche Programme wie schon im Vorgänger R/2 unter einem Datenmodell vereinigt. Das „R“ steht für „Realtime“, womit man den Anspruch formulierte, dem Anwender alle Funktionen möglichst ohne Verzögerung bereitzustellen. Auch wenn R/3 ursprünglich für den Betrieb auf IBMs AS/400 zugeschnitten war, lief ein großer Teil der Installationen unter Unix und nachrangig auch auf Windows.

Im Gegensatz zu bisherigen Mainframe-Konzepten bildet eine Dreischichtenarchitektur (daher die 3 in R/3) aus ­Client, Serveranwendung und Datenbank den Unterbau. Der Server stellte die Funktionen und die Anwendungslogik über die eigens entwickelte Laufzeitumgebung für die proprietäre Programmiersprache ABAP (Allgemeiner Berichts-Aufbereitungs-Prozessor) zur Verfügung. Durch die Datenbankabstraktionsschicht Open SQL ließen sich ABAP-Programme unabhängig von der verwendeten Datenbank einsetzen.

Weitere Funktionen einer R/3-Installation umfassen unter anderem:

  • eine Art Multi-Tenant-Fähigkeit über sogenannte Mandanten;
  • Lastverteilung durch die logische Verknüpfung verschiedener Applikationsserver über den Message Server;
  • Werkzeuge zur Jobverwaltung und Druckintegration;
  • Benutzer- und Berechtigungsverwaltung;
  • Entwicklungstools (Workbench) sowie Deployment- und Versionierungswerkzeuge, die als Transport Management System (TMS) bezeichnet werden;
  • ein eigenes Kommunikationsprotokoll auf Grundlage von TCP/IP zum Austausch mit anderen Anwendungen (Remote Function Call, RFC) über ein separates Gateway;
  • eine proprietäre Clientsoftware für die Interaktion des Anwenders mit dem System (SAP GUI) über das DIAG-Protokoll, das ebenfalls vom Gateway bereitgestellt wird.

Sicherheit war noch nicht gefragt

Aus Sicherheitssicht ist es interessant und bis heute relevant, dass keines der beiden Kommunikationsprotokolle ursprünglich den Einsatz von Verschlüsselung vorsah, bestimmte Funktionen über das RFC-Protokoll keine Authentifizierung verlangten und der Server in der Interaktion mit dem SAPGUI Befehle zur Ausführung auf dem Betriebssystem des Clients übermitteln kann. Entsprechend ergibt sich ein noch recht übersichtliches Bild an typischen Eingabequellen für ein R/3-System (Abbildung 1).

Als Client-Server-System präsentierte R/3 sich noch einigermaßen übersichtlich (Abb. 1).

Ein wesentlicher Punkt bei der stetigen Anpassung des Systems war die Einführung des Internet Transaction Servers (ITS) 1997 als Webserver inklusive verschiedener Erweiterungen in ABAP, um SAP-Applikationen über HTTP als Webanwendungen in Form von sogenannten Business Server Pages bereitzustellen und R/3 damit fit für das Internetzeitalter zu machen. Technisch betrachtet basiert NetWeaver auf den Grundfunktionen von R/3.

Kommentare lesen (1 Beitrag)