Unternehmen bleibt in der Verantwortung

SAP-Cloud-Sicherheit lässt sich nicht delegieren

14.11.2016
Mariano Nunez ist Experte für SAP-Sicherheit. Schon früh veröffentlichte er Risiken in SAP-Konfigurationen und zeigte Möglichkeiten zur Minimierung auf. Zudem entwickelte als erster ein Open-Source-basiertes SAP- und ERP-Penetration-Test-Verfahren. Mit zahlreichen Fortune-100-Unternehmen und auch mit Vertretern von Sicherheitsdienstleistern oder Streitkräften steht er im Kontakt. Nunez ist Bachelor of Science für Computerwissenschaften.
Hinter dem Outsourcing von SAP-Systemen steht häufig der Wille, Ressourcen und Aufwand einzusparen. Doch will man nicht auch die Verantwortlichkeit für SAP-Sicherheit los werden? Der Weg in die Cloud befreit von dieser Pflicht jedoch nicht.

Die SAP-Cloud steht auf der Tagesordnung. Verschiedene Motive spielen dabei eine Rolle: Vor allem geht es um das Einsparen von Geld, Ressourcen und Arbeitsaufwand. Bei der Migration in die Cloud zeigt sich dann oft das Problem, die in der SAP-Cloud - egal ob Public, Private oder Hybrid - zunehmende Komplexität in den Griff zu bekommen. Da ist man dann schon mit dem Mapping und der Verknüpfung von Daten, Anwendungen und Instanzen mehr als beschäftigt.

Die Sicherung der Verfügbarkeit und der Produktivität der Anwendungen sind aber eine weitere wichtige Aufgabe für einen alles andere als trivialen und schon in der Planung komplexen Migrationsprozess: Verschiedene Abteilungen entwickeln nämlich bisweilen ihre eigenen Roadmaps und für die Migration in die Cloud stehen verschiedene SAP-Umgebungen bereit. Eine solche Komplexität sorgt für Risiken.

Auch in der Wolke ist Transparenz von Schwachstellen und auffälligem Benutzerverhalten Grundlage für die Sicherheit von SAP-Implementierungen.
Auch in der Wolke ist Transparenz von Schwachstellen und auffälligem Benutzerverhalten Grundlage für die Sicherheit von SAP-Implementierungen.
Foto: Maksim Kabakou - shutterstock.com

Fragen der IT-Sicherheit sind daher nicht die einzigen, geschweige denn die wichtigsten Fragen, die sich den Verantwortlichen beim Weg in die Cloud stellen. Aber sie stellen sich und werden gestellt. Nicht umsonst betont auch die DSAG die Sorge um den Zugriff auf und die Kontrolle der Daten.

Gefährlicher Blindflug durch die SAP-Wolke

Ein Blindflug in und durch die SAP-Wolke ist zu gefährlich. Nicht nur wegen der erhöhten Komplexität der Strukturen, die Fehlkonfigurationen und damit Schwachstellen wahrscheinlicher macht. Auch leistungsfähige Schnittstellen sind notwendig, wenn Applikationen in der Wolke etwa Daten von einer On-Premise-Instanz abrufen wollen. Ein solcher Datenverkehr bietet aber immer eine Angriffsfläche. Nicht zu unterschätzen ist zudem die Tatsache, dass nicht alle Cloud-Technologien gleiche Sicherheitsstandards bieten. Und nicht immer entsprechen diese Standards den internen Compliance-Kriterien oder gesetzliche Vorschriften.

Einen weiteren Unsicherheitsfaktor stellt die sogenannte Shadow-IT dar: Fachabteilungen gehen unter Umständen mit Teilen ihrer Anwendungen und Daten ohne Absprache mit der IT-Abteilung in die Cloud. In einem solchen Fall wird die Sicherheitslage schnell noch unübersichtlicher und damit gefährlicher.

IT-Sicherheitsverantwortliche stehen dann oft vor einem internen Kompetenzmachtkampf, denn ohne ein Tool zum Assessment neu entstandener Schwachstellen kann man eine Abteilung oder höhere Instanzen selten davon überzeugen, von der Wolke wieder herabzusteigen, die Lösungen wieder on premise zu installieren und die Cloud zu verlassen. Und funktioniert die eigene Applikation erst mal in der Cloud, verursacht ihr Abschalten nicht unerheblichen Schaden, bis die Anwendung wieder lokal installiert und live geschaltet ist. Es bleibt dann in der Regel nichts anderes übrig, als die Schatten-IT sicher zu machen.

Ein weiteres Problem liegt beim Provider: Die Aussicht lockt, das regelmäßig notwendige Einspielen von Patches und in dessen Folge aufwändige Neukonfigurieren endlich auf den Schreibtisch von jemand anderem, dem Serviceprovider, zu legen. Doch das erweist sich als trügerische Hoffnung. Viele Provider sind nicht an ständigen Updates interessiert, sie kosten auch sie Zeit und Geld und manche tendieren deshalb dazu, aufwändige Sicherheitsupdates nicht zu implementieren.

Damit gelangen wir zu einem sicher nicht oft offen ausgesprochenen Kernproblem: Dem ein oder oder anderem IT-Sicherheitsbeauftragten im Unternehmen geht es beim Weg in die Cloud vielleicht auch darum, Verantwortung für die SAP-Sicherheit, von der man sich überfordert fühlt, elegant nach außen abzugeben und dem Serviceprovider für den Ernstfall ins Pflichtenheft zu schreiben. Dann war man im Ernstfall wenigstens nicht selber schuld. Ein Service Level Agreement haben im eigenen Unternehmen genug Leute mit abgesegnet, um auch mitschuldig zu sein.