Die meisten Konfigurationsabweichungen in SAP entstehen nicht durch unberechtigte Zugriffe. Sie entstehen durch berechtigte Benutzer, die aus legitimen Gründen Änderungen vornehmen, diese aber nur unvollständig dokumentieren und später nicht wieder zurücksetzen. Ein Basis Engineer erhöht während eines Incidents die Anzahl der Dialog-Workprozesse in RZ10 und löst damit das Problem. Ein Consultant öffnet den Produktionsmandanten, um eine dringende Korrektur vorzunehmen, und vergisst anschließend, ihn wieder zu sperren. Ein Authorization Admin weist einem Benutzer während des Monatsabschlusses vorübergehend eine zusätzliche Rolle zu, und die Aufgabe zur Entfernung bleibt drei Wochen im Backlog, bis die Dringlichkeit längst vergessen ist.
Jedes dieser Ereignisse ist real und hatte zum jeweiligen Zeitpunkt eine nachvollziehbare Begründung. Keines davon muss unautorisiert gewesen sein. Trotzdem hinterlassen alle das Produktionssystem in einem anderen Zustand als in der dokumentierten Baseline.
Genau diese Abweichung zwischen dokumentiertem und tatsächlichem Zustand ist Configuration Drift. Und genau dort liegen häufig die Ursachen für Incidents, die zunächst keine offensichtliche Erklärung haben.
Warum Configuration Drift nicht dasselbe ist wie fehlerhaftes Change Management
Change Management in SAP, insbesondere das STMS-Transportsystem und die dazugehörigen Genehmigungsprozesse, erfasst Änderungen, die über die formale Transportlandschaft laufen: ABAP-Code und Konfigurationen, die von Entwicklung über Qualität bis in die Produktion transportiert werden.
Configuration Drift entsteht dagegen genau in den Bereichen, die das Transportmanagement nicht abdeckt.
Direkte Tabellenänderungen über SM30 oder SE16N in Produktion. Profilparameter, die direkt in RZ10 angepasst werden. HANA-Konfigurationsänderungen über HANA Studio oder SQL, die nicht über ein Configuration-Management-Tool laufen. Änderungen an RFC-Destinationen, die keinen Transport erzeugen. Änderungen an Benutzerstammdaten außerhalb des rollenbasierten Provisioning-Workflows.
All diese Änderungen sind technisch möglich und in dringenden Situationen manchmal notwendig. Gleichzeitig liegen sie systematisch außerhalb des Transportprotokolls.
Wenn eine Post-Incident-Analyse mit der Aussage endet „wir wissen nicht, wann das geändert wurde“, geht es fast immer um eine dieser Kategorien. STMS zeigt nichts, weil nichts transportiert wurde. Die Änderung ist trotzdem real. Informationen darüber, wann sie vorgenommen wurde und von wem, können in den SAP-Änderungsbelegen vorhanden sein, allerdings nur, wenn das Logging für die betreffende Tabelle entsprechend konfiguriert wurde und jemand weiß, wo er danach suchen muss.
Die drei Konfigurationsebenen, die unabhängig voneinander driften können
Drift bei Berechtigungen und Benutzerstammdaten
Die Berechtigungskonfiguration in SAP kann über mehrere Wege verändert werden. Rollenänderungen, die über STMS transportiert werden, sind sichtbar. Direkte Änderungen an Benutzerstammdaten über SU01, Rollenzuweisungen über PFCG oder Rebuilds des Berechtigungspuffers erscheinen dagegen nicht im Transportwesen.
Sie erzeugen Änderungsinformationen in der Historie der USR*-Tabellen, werden aber normalerweise nur geprüft, wenn jemand SCU3 gezielt öffnet und nach Änderungen an Benutzeradministrationstabellen sucht.
Das Drift-Muster, das in diesem Bereich besonders häufig zu Problemen führt, ist eine temporäre Berechtigungsvergabe ohne zeitliche Begrenzung, die später nie entfernt wurde. Ein Benutzer verfügt noch immer über eine sensible Berechtigung, die er vor drei Monaten für ein Projekt erhalten hat. Ein Service Account hat für eine Migration umfangreiche Rechte bekommen, die nach Abschluss der Migration nie bereinigt wurden. Ein Authorization Admin weist eine Rolle „nur zum Testen“ zu und plant, sie später wieder zu entfernen, vergisst es aber.
Die relevante Monitoring-Frage ist nicht, ob diese Änderungen zum Zeitpunkt ihrer Durchführung autorisiert waren. Entscheidend ist, ob der heutige Zustand der Berechtigungslandschaft dem Zustand entspricht, der heute tatsächlich gelten sollte, und wann eine Abweichung davon entstanden ist.
Drift bei System- und Instanzkonfiguration
Profilparameter in RZ10 bestimmen das Verhalten der SAP-Applikationsserver: Anzahl der Workprozesse, Speicherzuweisungen, Buffer-Größen und Timeout-Werte. Änderungen an diesen Parametern benötigen häufig einen Neustart, um wirksam zu werden, und sollten theoretisch kontrollierte Ereignisse sein.
In der Praxis werden sie unter Incident-Druck vorgenommen, teilweise nur unvollständig dokumentiert und anschließend nicht immer zurückgesetzt, wenn das ursprüngliche Problem behoben wurde.
Die Mandanteneinstellungen in SCC4 sind ein besonders risikoreicher Bereich. Die Einstellung „No changes allowed“ in einem Produktionsmandanten sorgt dafür, dass Customizing-Änderungen einen Transport erfordern. Wird diese Einstellung für eine dringende direkte Korrektur vorübergehend geändert und danach nicht wieder zurückgesetzt, bleibt der Produktionsmandant für direktes Customizing durch alle Benutzer offen, die über entsprechende Tabellenpflegeberechtigungen verfügen.
Ein solcher Zustand kann monatelang ohne sichtbare operative Auswirkungen bestehen bleiben, bis ein Auditor ihn entdeckt oder ein Entwickler anfängt, direkt in Produktion zu ändern, weil das System es zulässt.
HANA-Konfigurationsparameter, die über HANA Studio oder mit ALTER SYSTEM SET geändert werden, gehören zu den am wenigsten sichtbaren Kategorien. Sie erzeugen keine ABAP-Änderungsbelege. Stattdessen werden sie in der eigenen HANA-Konfigurationshistorie erfasst, beispielsweise in M_INIFILE_CONTENT_HISTORY. Sie sind jedoch weder Teil eines SAP-Transports noch des ABAP Change Document Frameworks.
Eine vor sechs Wochen vorgenommene und inzwischen vergessene Änderung eines HANA-Parameters kann in einem Bereich die Performance verbessern und gleichzeitig an anderer Stelle verschlechtern. Für das Basis-Team, das heute nach der Ursache einer Performance-Verschlechterung sucht, kann dieser Zusammenhang schwer zu erkennen sein.
Drift bei Integrations- und Interface-Konfiguration
RFC-Destinationen in SM59, logische Systemdefinitionen, IDoc-Partnerprofile in WE20 und Einstellungen des ALE-Verteilungsmodells sind Integrationsobjekte, die in etablierten Landschaften nicht immer über Transporte bewegt werden. Häufig werden sie direkt im Zielsystem angelegt oder verändert.
Ein typisches Drift-Szenario, das zu Integrationsfehlern führt, ist eine RFC-Destination, die zu Testzwecken auf ein anderes System umgestellt und anschließend nicht zurückgesetzt wurde. Ein weiteres Beispiel ist ein Partnerprofil, dessen Outbound-Parameter während eines Projekts verändert wurde, sodass das Produktionssystem später IDocs mit einem falschen Nachrichtentyp versendet.
Änderungsinformationen für die relevanten Tabellen können in SAP vorhanden sein. Häufig fehlt jedoch ein Monitoring, das solche Änderungen automatisch sichtbar macht.
Wo Änderungsinformationen liegen und was sie nicht erfassen
SAP führt Änderungsinformationen für Tabellen, bei denen entsprechendes Logging aktiviert ist. SCU3 zeigt, welche Tabellen wann und von wem geändert wurden, jedoch nur für Tabellen mit aktivierter Änderungsprotokollierung. Das betrifft lediglich einen Teil aller Tabellen und ist nicht in jeder SAP-Implementierung gleich konfiguriert.
SM20, das Security Audit Log, protokolliert unter anderem Ereignisse aus der Benutzeradministration, fehlgeschlagene Berechtigungsprüfungen und Änderungen an Systemeinstellungen. Die tatsächliche Abdeckung hängt jedoch von der Konfiguration des Audit Logs ab: Welche Ereignisklassen sind aktiv? Welche Mandanten werden überwacht? Werden alle Benutzer erfasst oder nur definierte Gruppen?
STMS und SE01 zeigen, was über das Transportsystem gelaufen ist. Sie zeigen nichts über Änderungen außerhalb der Transportlandschaft. Und genau dort entsteht ein großer Teil der operativ relevanten Configuration Drift.
Diese Lücke zwischen einer tatsächlich durchgeführten Änderung und den Informationen, die nach einem Incident noch auffindbar sind, ist einer der Hauptgründe dafür, dass Post-Incident-Reviews zu Aussagen kommen wie: „Wir gehen davon aus, dass dies vor ungefähr drei Wochen geändert wurde, können aber weder das genaue Datum noch die konkrete Änderung bestätigen.“
| Achtung: In vielen SAP-Implementierungen wurde das Change Logging für bestimmte Tabellen während der ursprünglichen Einführung aktiviert und danach nie erneut überprüft, obwohl sich die Landschaft weiterentwickelt hat. Tabellen, die beim Go-live nicht als sensibel galten, können heute geschäftskritische Konfigurationen enthalten. Prüfen Sie in den Tabelleneigenschaften von SE11, für welche Tabellen das Logging aktiviert ist, und vergleichen Sie diese Liste mit den Tabellen Ihrer wichtigsten Risikobereiche. |
|---|
Was Configuration Drift Monitoring erfordert
Baseline-Snapshots eines bekannten Sollzustands
Drift lässt sich nur im Vergleich mit einer definierten Baseline erkennen. Die Baseline ist ein Konfigurationszustand, der geprüft, freigegeben und als korrekt dokumentiert wurde. Ohne diesen Referenzzustand kann jede aktuelle Konfiguration als gültig betrachtet werden, da kein Vergleichsmaßstab existiert.
Praktische Baselines für Configuration Drift Monitoring können beispielsweise die Rollen- und Profilzuweisungen nach Abschluss der vierteljährlichen Access Reviews sein, die Werte der RZ10-Profilparameter nach jedem Wartungsfenster, die Liste der RFC-Destinationen nach Abschluss eines Integrationsprojekts oder die SCC4-Mandanteneinstellungen bei jedem System Health Review.
Diese Point-in-Time-Snapshots dokumentieren den vorgesehenen Zustand und dienen anschließend als Referenz für zukünftige Vergleiche.
Ereignisse, die sofortige Alerts erfordern
Nicht jede Konfigurationsänderung muss mit derselben Dringlichkeit behandelt werden. Einige Änderungen stellen ein so hohes Risiko dar, dass innerhalb weniger Minuten ein Alert ausgelöst werden sollte.
Dazu gehört beispielsweise, wenn die SCC4-Einstellung eines Produktionsmandanten von „No changes allowed“ auf einen anderen Wert geändert wird. Dasselbe gilt für direkte Änderungen an USR02 außerhalb der üblichen Geschäftszeiten.
Auch Änderungen an SM59-RFC-Destinationen für kritische Systemverbindungen und Anpassungen an der HANA-Datei global.ini gehören in diese Kategorie. Wenn solche Änderungen unbeabsichtigt sind, können sie unmittelbar zu Sicherheits- oder Betriebsrisiken führen.
Änderungen, die täglich geprüft werden sollten
Eine größere Gruppe von Konfigurationsänderungen sollte täglich überprüft werden, ohne dass dafür sofort ein kritischer Alert erforderlich ist.
Dazu gehören Änderungen an AGR_USERS für Rollenzuweisungen, Anpassungen an TVARVC, beispielsweise für Varianten, die in Background Jobs genutzt werden, Änderungen an Job-Schedules in SM36 und Anpassungen an Partnerprofilen in WE20.
Keine dieser Änderungen muss zwangsläufig um 03:00 Uhr jemanden wecken. Sie sollte aber innerhalb von 24 Stunden geprüft werden, um sicherzustellen, dass sie beabsichtigt und korrekt dokumentiert wurde.
| In der Praxis: Ein täglicher Drift Review kann etwa fünfzehn Minuten dauern, wenn die Monitoring-Ausgabe gut strukturiert ist: eine Liste aller Konfigurationsänderungen der vergangenen 24 Stunden, nach Kategorie gruppiert und jeweils mit Benutzer und Zeitstempel. Die meisten SAP-Teams erhalten eine solche Liste nicht automatisch. Sie haben Zugriff auf einzelne Logs wie SCU3, SM20 oder STMS, aber keine aggregierte Sicht. Einen geplanten Report oder Monitoring-Alert aufzubauen, der diese Übersicht täglich liefert, ist meist weniger aufwendig als erwartet und zeigt seinen Wert spätestens beim ersten relevanten Fund. |
|---|
Der Incident, den Drift Monitoring verhindert
Configuration Drift wird in Post-Incident-Reviews fast immer nach demselben Muster sichtbar. Das System verhält sich unerwartet. Das Team beginnt mit der Analyse. Es entdeckt eine Konfiguration, die nicht mit der Dokumentation übereinstimmt. Anschließend wird geprüft, wann diese Änderung vorgenommen wurde. Entweder existiert überhaupt kein nachvollziehbarer Eintrag oder es gibt einen sechs Wochen alten Log-Eintrag, den niemand einer dokumentierten Change-Anforderung zuordnen kann.
Die Untersuchung dauert Stunden oder Tage. Die Behebung kostet zusätzliche Zeit. Am Ende wird die Root Cause möglicherweise als „unauthorized configuration change“ dokumentiert, obwohl die präzisere Beschreibung eigentlich lautet: „autorisierte Konfigurationsänderung, die nicht nachverfolgt, dokumentiert oder überwacht wurde“.
Configuration Drift Monitoring verhindert nicht, dass berechtigte Benutzer Änderungen durchführen. Es macht diese Änderungen zum Zeitpunkt ihrer Durchführung sichtbar, solange die Person, die sie vorgenommen hat, den Grund noch erklären kann und ein Rollback eine kleine operative Maßnahme statt einer aufwendigen Produktions-Incident-Analyse ist.
Diese kontinuierliche Sichtbarkeit ohne manuellen Aufwand ist der Unterschied zwischen Configuration Management, das im Alltag tatsächlich funktioniert, und Configuration Management, das lediglich auf dem Papier existiert.
Redpeaks überwacht SAP-Konfigurationsänderungen, darunter Berechtigungsänderungen, Anpassungen an Profilparametern und Änderungen an Mandanteneinstellungen. Tägliche Drift-Zusammenfassungen sowie unmittelbare Alerts für risikoreiche Konfigurationsereignisse helfen dabei, relevante Abweichungen frühzeitig zu erkennen.
