Monitoring und Patching lösen unterschiedliche Teile desselben Sicherheitsproblems. Patches beseitigen bekannte Schwachstellen vor ihrer Ausnutzung. Monitoring erkennt Angriffsversuche auf ungepatchte Lücken sowie unerwartetes Verhalten nach Patches oder Konfigurationsänderungen. Probleme entstehen, wenn Organisationen beides verwechseln: Monitoring soll zuverlässig sagen, wann zu patchen ist, oder Patches werden ohne Überwachung von Regressionen und vorherigen Angriffsmustern eingespielt.
Dieser Artikel grenzt den Monitoring-Beitrag zu einem SAP-Sicherheits- und Patchprogramm ab und erläutert die Konfiguration für einen wirksamen Einsatz.
Patching verhindert, Monitoring erkennt: warum der Unterschied zählt
Ein Kernel-Patch schließt eine Lücke im SAP-Code. Danach lässt sie sich über diesen Pfad im System nicht mehr ausnutzen. Ein speziell auf diese CVE gerichteter Alert wird dafür entbehrlich, kann aber für andere ungepatchte CVEs derselben Funktionsbausteinfamilie weiter relevant sein.
Beide Kontrollen betreffen unterschiedliche Risikofenster. Zwischen CVE-Veröffentlichung und Patch liegen je nach Zyklus oft Wochen oder Monate. Monitoring kann in dieser Zeit Ausnutzungsversuche erkennen. Nach dem Patch schützt es weiterhin durch Erkennung neuer ungepatchter Schwachstellen und möglicher unvollständiger, fehlerhafter oder nebenwirkungsreicher Patch-Anwendungen.
Monitoring als Patch-Ersatz zu betrachten, weil jeder Angriff rechtzeitig erkannt werde, kompensiert fehlende Prävention durch eine erkennende Kontrolle. Das ist ein struktureller Risikomanagementfehler. Beide Maßnahmen ergänzen sich.
Was Monitoring für SAP-Sicherheit und Patching leisten kann
Angriffsversuche vor der Patch-Anwendung erkennen
Zwischen Security Note und Produktivpatch bleibt die Schwachstelle vorhanden. Veröffentlichte CVE-Details, betroffene Bausteine und Ausnutzungsmethoden stehen auch Angreifern zur Verfügung. Aufrufe betroffener Bausteine zu überwachen, besonders RFC-Aufrufe nicht genehmigter Quellsysteme, warnt vor Sondierung oder Ausnutzung. SAP-RFC-Sicherheitsmonitoring beschreibt passende Muster für RFC-Angriffe, die viele schwere SAP-CVEs der letzten Jahre betreffen.
DUF für RFC-Funktionsaufrufe und DUB für fehlgeschlagene Berechtigungsprüfungen liefern das Rohsignal. Ein mangels Berechtigung abgewiesener Aufruf eines sensiblen Bausteins deutet auf Sondierung hin. Viele solche Aufrufe aus derselben Quelle in kurzer Zeit sprechen für automatisierte Erkundung. Ohne explizite Konfiguration erzeugt das keinen traditionellen Betriebsalert.
Baselines vor Patches und Vergleich danach
Kernel-, HANA-Patches und Support Package Stacks ändern Produktivcode und mitunter Performance. Ein geänderter HANA-SQL-Optimierer kann Ausführungspläne verbessern oder stark verschlechtern. Änderungen der Workprozessverwaltung können Dialogantwortzeiten erst unter realer Last beeinflussen.
Eine vor jedem Patch erfasste Baseline ermöglicht Regressionserkennung innerhalb von Stunden statt Tagen. Dazu gehören Dialogantwortzeiten, HANA-Speicherprofile, Laufzeiten teurer Statements und WP-Auslastung. Deutliche Änderungen nach dem Patch sind Untersuchungskandidaten, wobei die zeitliche Korrelation eine klare Anfangshypothese liefert.
Fehlt die Baseline, wird ein zwei Wochen später erkanntes Problem oft nicht zugeordnet. Das Basis-Team untersucht alle Ursachen und braucht Tage, um einen geänderten SQL-Ausführungsplan als Folge des Patches nachzuweisen.
Abweichungen von gehärteten Konfigurationen
Härtung erzeugt verifizierte Profilparameter, gesperrte Mandanteneinstellungen, eingeschränkte RFC-Destinationen und Gateway-ACLs. Dieser Zustand ist die Baseline. Änderungsmonitoring macht ihn dauerhaft statt punktuell. Das SAP-Konfigurationsdrift-Monitoring erklärt, welche Tabellenänderungen Änderungsbelege erzeugen und welche nicht.
Was Monitoring nicht leisten kann
Es bestimmt nicht, welche SAP Security Notes für die konkrete Version und Konfiguration gelten. Dafür sind SAP-Werkzeuge wie Solution-Manager-Patchanalyse oder Cloud ALM beziehungsweise ein Scanner mit Zugriff auf die Note-Datenbank nötig. Eine Plattform für Betriebsmetriken besitzt nicht automatisch das Softwareinventar für einen CVE-Abgleich.
Es ersetzt kein SAP-Sicherheitsassessment. Dieses bewertet Rollen, RFC-Sicherheit, Mandanten- und Systemeinstellungen, Netzwerkexposition und Zugriffskontrollen mit spezifischer Expertise und Werkzeugen.
Monitoring spielt keine Patches ein. Es kann Patch-Probleme, ausgelassene Systeme und Kernelversionen unter einem festgelegten Minimum erkennen. Planung, Test und Ausführung des Patch-Workflows liegen außerhalb seines Umfangs.
Achtung: Ein Alert bei jeder neuen Security Note erzeugt Lärm ohne zusätzlichen Sicherheitsbeleg. Relevant ist, ob die betroffene Version läuft und ob eine Ausnutzung versucht wird. Ersteres benötigt Versionsinventar, Letzteres Sicherheitslog-Analyse gegen bekannte Angriffsmuster.
Profilparameter für die Überwachung der Härtungsdrift
Benutzer mit RZ10-Berechtigung können Instanzprofile ändern. Die Wirkung tritt nach Neustart oder bei einigen Parametern unmittelbar über RZ11 ein. Echtzeiterkennung dieser Änderungen macht die Härtung auditierbar.
login/fails_to_user_lock: Erwartet 3 bis 5. Null deaktiviert die Kontosperre vollständig und erlaubt unbegrenzte Passwortversuche. Dies ist eine häufige Härtungslücke in Assessments.
auth/object_disabling_active: Erwartet N. Y erlaubt das Deaktivieren von Berechtigungsobjekten und umgeht rollenbasierte Kontrollen. In Produktion stets N.
login/no_automatic_user_sapstar: Erwartet 1. Steuert, ob SAP* bei gelöschtem Benutzerstammsatz mit Standardpasswort zugreifen kann. Null schafft eine kritische Hintertür. In Produktion 1.
gw/sec_info und gw/reg_info: Erwartet Pfade zu secinfo/reginfo. Fehlende oder permissive Dateien erlauben unberechtigte Programmregistrierung am SAP Gateway, ein Pfad mehrerer schwerer CVEs.
icm/server_port_*: Nur notwendige Ports. Unerwartete ICM-Ports exponieren SAP-Dienste im Netzwerk. Jeder neue Port gehört in die Änderungssteuerung.
Überwachung erfolgt direkt per RZ11-Abfragen oder über SCU3 für Profiltabellen. Alerts bei Abweichung vom Soll liefern kontinuierliche Absicherung, die ein punktuelles Assessment nicht bietet. Die SAP-Alert-Best-Practices erläutern die Konfiguration.
Monitoring nach dem Patch: das 72-Stunden-Fenster
Die 72 Stunden nach einem wesentlichen Patch sind besonders risikoreich. Regressionen treten auf, geänderte Integrationen treffen reale Nachrichtenflüsse und Benutzer melden Veränderungen, die tatsächliche Probleme sein können oder nicht.
Temporär sollte empfindlicher überwacht werden: niedrigere Dialogschwellen, aktive WP-Beobachtung, expliziter Vergleich teurer HANA-Statements mit der Vorher-Baseline und erhöhte Aufmerksamkeit für betroffene Schnittstellen. Nach 72 Stunden bestätigter Stabilität folgt die normale Überwachung.
Die HANA-Metriken bleiben ähnlich, der Kontext ändert sich. Abweichungen vom Zustand vor dem Patch sind aussagekräftiger als Abweichungen von langfristigen Mittelwerten, weil der Patch-Zeitpunkt eine prüfbare Ursache nahelegt. Baseline-Snapshots ermöglichen den direkten Vergleich; ohne sie muss der Zustand manuell rekonstruiert werden.
Eine Monitoring-Schicht für das Härtungsprogramm aufbauen
Ohne Monitoring driftet Härtung durch Notfallmaßnahmen, Projekte und viele kleine Entscheidungen. Entscheidend ist, ob das erkannt wird. SAP-Sicherheits- und Zuverlässigkeitsmonitoring ordnet die Funktionen in einen breiteren Rahmen ein.
Drei Komponenten sind erforderlich: sofortige Parameterabweichungserkennung, Sicherheitslog-Analyse für RFC-Muster und Häufungen fehlgeschlagener Berechtigungen sowie der Vergleich nach Patches mit zuvor standardmäßig erfassten Snapshots.
Nach der Systemanbindung ist die Umsetzung nicht komplex, verlangt aber explizites Design: Welche Parameter, welche Muster und welche Snapshot-Prozedur? Dieses Design verbindet ein berichtendes Tool mit einer aktiv unterstützenden Sicherheits- und Patch-Schicht.
Redpeaks überwacht Profilparameter, Sicherheitsereignisse und Performance-Baselines über agentenloses RFC und bietet Alerts für Sicherheitsmuster und Regressionen. Entdecken Sie die Sicherheitsmonitoring-Abdeckung.
