SAP-Security wird zur Betriebsaufgabe: Fünf Empfehlungen für CIOs

SAP-Systeme steuern zentrale Geschäftsprozesse und enthalten Daten, deren Ausfall oder Manipulation unmittelbar den Geschäftsbetrieb treffen kann. Trotzdem bleibt ihre Absicherung in vielen Unternehmen eine Spezialdisziplin. Klassische Netzwerk- und Endpoint-Security schafft Transparenz über Verbindungen und Geräte. Was innerhalb der SAP-Systeme passiert, kann dabei jedoch zum blinden Fleck werden: Welche Funktionen werden aufgerufen, welche Berechtigungen bestehen und auf welche Daten wird zugegriffen?

Wie real das Risiko ist, haben die vergangenen Monate gezeigt: Kritische Schwachstellen in SAP NetWeaver wurden bereits aktiv ausgenutzt. Zugleich veröffentlicht SAP weiterhin regelmäßig neue kritische Sicherheitslücken. Auch der SAP Security Patch Day im September 2026 brachte wieder mehrere kritische Schwachstellen, darunter zwei in NetWeaver mit CVSS-Werten von 10,0 und 9,8.

Gleichzeitig verändert sich die SAP-Landschaft. Unternehmen verlagern Prozesse in die Cloud, setzen auf Clean Core, binden spezialisierte Anwendungen an und beginnen, KI-Agenten in Geschäftsprozessen einzusetzen. Damit wächst nicht nur die Zahl der technischen Komponenten. Es entstehen neue Identitäten, Zugriffe und Vertrauensbeziehungen, die kontrolliert werden müssen.

SAP selbst behandelt KI-Agenten inzwischen als eigenständige Akteure mit eigenen Identitäten und begrenzten Berechtigungen. Agenten können auf Anwendungen und Daten zugreifen, Werkzeuge aufrufen und Aktionen in Geschäftsprozessen auslösen. Damit werden Fragen wie „Was darf dieser Agent?“, „Auf welche Daten darf er zugreifen?“ und „Wer kann seine Aktionen nachvollziehen?“ zu neuen Aufgaben für Security und Governance.

Die Diskussionen auf der IT-Onlinekonferenz im September haben vor diesem Hintergrund vor allem eines gezeigt: SAP-Security muss aus dem Projektmodus herauskommen und Teil des Tagesgeschäfts werden.

Transparenz über SAP-Security-Risiken schaffen

Der Einstieg muss dabei nicht kompliziert sein. Eine Empfehlung aus der Praxis: mit einem produktiven System beginnen und an einem festen Termin fünf Punkte prüfen – offene HotNews-Notes, Standardbenutzer, kritische Berechtigungen, die Konfiguration der Protokollierung und extern erreichbare Services. Das Ergebnis ist zunächst schlicht eine dokumentierte Liste mit Datum.

Damit wird sichtbar, wo tatsächlich Handlungsbedarf besteht. Gerade in hybriden SAP-Landschaften ist diese Transparenz Voraussetzung dafür, Risiken nicht nur technisch zu erfassen, sondern nach ihrer Bedeutung für Prozesse und Geschäftsbetrieb zu priorisieren.

Verantwortung für SAP-Security festlegen

Eine Liste allein verbessert die Sicherheit noch nicht. Es braucht einen Namen dahinter: eine Person oder Funktion, die für SAP-Security verantwortlich ist – mit Zeit für diese Aufgabe und nicht nur mit einer Zuständigkeit im Organigramm.

Regelmäßige Checks, automatisierte Schwachstellenprüfungen und ein klarer Umgang mit kritischen Security Notes überführen SAP-Security anschließend in den laufenden Betrieb. Aus einer Bestandsaufnahme wird ein Prozess.

S/4HANA-Transformation für mehr Security nutzen

Eine S/4HANA-Transformation bietet gleichzeitig die Gelegenheit, das Sicherheitsniveau strukturell anzuheben. Prozesse, Rollen, Schnittstellen und Architekturen werden ohnehin neugestaltet. Security erst nach dem Go-live aufzuräumen, macht die Aufgabe häufig aufwendiger.

Das gilt ebenso für Clean Core. Eine Clean-Core-Transformation bringt eigene Herausforderungen für Architektur, Erweiterungen und Governance mit sich. Werden neue Geschäftsprozesse über Cloud-Services, spezialisierte Business-Anwendungen und Erweiterungen außerhalb des ERP-Kerns umgesetzt, müssen Identitäten, Berechtigungen, Schnittstellen-Governance, Logging und Compliance Teil der Architektur sein.

Mit KI-Agenten kommt eine weitere Ebene hinzu. KI-Agenten können bereits heute Aufgaben in SAP-Landschaften übernehmen und Prozesse automatisieren. Damit entstehen zugleich neue Anforderungen an Zugriffe und Berechtigungen: Agenten können auf Anwendungen und Daten zugreifen und Aktionen in Unternehmenssystemen ausführen. SAP arbeitet deshalb unter anderem daran, technische Ausführungsgrenzen mit Autorisierungsmodellen, Identity and Access Management und Audit Trails zu verbinden.

SAP-Security nach Risiko statt Checkliste priorisieren

Parallel steigt der regulatorische Druck, insbesondere für Unternehmen aus kritischen und regulierten Bereichen. Die Erfahrungen aus der IT-Onlinekonferenz zeigen jedoch: Mehr Anforderungen bedeuten nicht, dass alles gleichzeitig umgesetzt werden muss.

Unternehmen sollten ihre eigenen Gestaltungsspielräume kennen und nachvollziehen können, welche Systeme, Prozesse und Zugänge besonders schützenswert sind. Daraus lässt sich eine Zielarchitektur entwickeln, die regulatorische Anforderungen, technischen Betrieb und wirtschaftlichen Aufwand zusammenführt.

SAP-Security wird damit zu einer Aufgabe, die weit über das Einspielen von Patches hinausgeht. Je stärker sich SAP-Landschaften aus ERP-Kern, Cloud-Services, Erweiterungen, Schnittstellen und KI-Agenten zusammensetzen, desto enger müssen Security, Architektur und Betrieb zusammenarbeiten.

Die Beiträge und Diskussionen der IT-Onlinekonferenz zeigen zugleich, dass der Einstieg nicht zwangsläufig ein Großprojekt sein muss. Transparenz über die eigene Landschaft, eine klare Verantwortung und feste Abläufe schaffen eine Basis, auf der sich das Sicherheitsniveau Schritt für Schritt weiterentwickeln lässt.

Executive Summary SAP-Security

SAP-Security muss vom Einzelprojekt ins Tagesgeschäft rücken. Die Executive Summary der IT-Onlinekonferenz zeigt, wie Unternehmen Transparenz schaffen, Verantwortlichkeiten festlegen und Security bei S/4HANA, Clean Core und KI-Agenten von Beginn an berücksichtigen.

Jetzt anfordern