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.
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.
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.
Interner Kompetenzmachtkampf
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.
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.
SAP-Cloud-Strukturen absichern
SAP-Cloud-Strukturen werden sicher, wenn man sich dieser Gefahren bewusst ist. Wichtig ist vor allem:
SAP-Cloud-Strukturen werden sicher, wenn man sich dieser Gefahren bewusst ist. Wichtig ist vor allem:
- Für Transparenz sorgen: Schon eine unternehmenseigene SAP-Infrastruktur bietet genug Möglichkeiten, durch Fehlkonfigurationen Schwachstellen für Angreifer zu öffnen. Ein automatisches Assessment ist nicht nur bei On-Premise-Strukturen Pflicht, sondern erst recht auch während des Prozesses der Migration in die Cloud und später im Betrieb. Das schließt auch die Überwachung eventuell angefallener Testumgebungen mit ein.
- Datensicherheit groß schreiben: Es ist selbstverständlich, dass man es sich sehr genau überlegen muss, welche unternehmenskritischen Daten und Anwendungen man außer Haus geben will. Bei den eigentlich immer unternehmenskritischen ERP-Daten- und -Anwendungen sind die Hürden per se hoch anzusetzen.
- Zuständigkeiten kennen: Die Idee, Verantwortung in die Cloud abzugeben, ist verlockend, aber falsch. Denn je nach Service Level Agreement, das hoffentlich aufmerksam gelesen wurde, oder SAP-Cloud-Lösung bleiben Aufgaben beim Unternehmen. Nur die Funktionstüchtigkeit der Hardware sowie die Bereitstellung ausreichender Rechenleistung und Speicherkapazität kann man immer vom Serviceprovider erwarten.
- Bei SAP HANA Enterprise Cloud als Beispiel für ein Cloud-Angebot verwaltet das Unternehmen selbst weiterhin die Nutzer und deren Profile, die Parameter eines Systems, überwacht das für die sichere Übertragung wichtige Transport-Managementsystem und wendet die SAP-Security-Notes an.
- Und das ist auch gut so. Denn kein Externer dürfte oder sollte genug Wissen haben, um im Einzelfall über jedes Nutzerprofil Entscheidungen treffen zu können. Sicher wird die Cloud erst dann, wenn man weiß, was man ihr anvertrauen kann und die Kontrolle dennoch nicht aus der Hand gibt.
* Mariano Nunez ist Experte für SAP-Sicherheit und hat als erster ein Open-Source-basiertes SAP- und ERP-Penetration-Test-Verfahren entwickelt.
Be the first to comment