S/4HANA Performance-Optimierung
HANA-spezifische Analyse, SQL-Tuning und proaktives Monitoring.
Weiterlesen →
SAP-Systeme erfordern regelmäßige Updates und Patches – vom Kernel-Update über ABAP-Stack-Patches bis hin zu Security Notes. Ein systematischer Patch-Prozess ist entscheidend für Systemstabilität und -sicherheit. Zu viele Unternehmen patchen reaktiv oder gar nicht – mit erheblichen Risiken.
SAP unterscheidet verschiedene Patch-Kategorien:
Etablieren Sie einen festen Patch-Kalender: Security Notes monatlich bewerten und kritische innerhalb von 2 Wochen einspielen. Kernel-Updates quartalsweise durchführen. Support Packages halbjährlich planen. HANA-Revisionen mit den SAP-empfohlenen Revisionsstufen abgleichen. Synchronisieren Sie den Patch-Kalender mit den Wartungsfenstern und Projekt-Freezes Ihres Unternehmens.
Nicht jeder Patch ist gleich kritisch. Bewerten Sie anhand folgender Kriterien: CVSS-Score bei Security Notes (ab 9.0 ist HotNews, sofortige Aktion erforderlich), betroffene Systemkomponenten (ein Kernel-Patch betrifft alle Systeme, eine Correction Note nur spezifische Funktionen), Abhängigkeiten zu anderen Patches und bekannte Seiteneffekte (SAP Release Notes lesen!). Dokumentieren Sie die Risikoanalyse für jeden Patch-Zyklus – das ist auch ein Audit-Nachweis.
Jeder Patch durchläuft die Systemlandschaft: Zuerst im Sandbox-System installieren und Basistests durchführen. Dann im Quality-System mit definierten Regressionstests validieren. Erst nach erfolgreicher Validierung im Produktivsystem einspielen. Für kritische Security Notes, die sofort eingespielt werden müssen, definieren Sie einen beschleunigten Prozess mit reduzierten, aber fokussierten Tests.
Jeder Patch-Vorgang braucht einen Fallback-Plan: Für Kernel-Updates: alten Kernel aufbewahren und bei Problemen zurückwechseln (Rolling Kernel Switch). Für Support Packages: Backup vor der Installation erstellen. SPAM bietet einen Dequeue-Mechanismus. Für HANA-Revisionen: Snapshot oder Backup der Datenbank vor dem Update. Für Security Notes: SNOTE ermöglicht die Rücknahme einzelner Notes. Testen Sie Rollback-Prozeduren regelmäßig – im Ernstfall zählt jede Minute.
Für größere Landschaften lohnt sich die Automatisierung: SAP Solution Manager Change Management für den gesamten Patch-Workflow. SAP Landscape Management (LaMa) für automatisierte Kernel-Updates. System Recommendations im Solution Manager für automatische Identifikation relevanter Patches. FRUN (Focused Run) für zentrales Patch-Monitoring. Custom-Skripte für standardisierte Pre- und Post-Patch-Checks.
Messen Sie Ihre Patch-Disziplin: Patch-Compliance-Rate (Anteil der eingespielten vs. verfügbaren Patches), Time-to-Patch (Tage von der Veröffentlichung bis zur Produktivnahme), offene kritische Security Notes (älter als 30 Tage) und Patch-bedingte Incidents (Probleme nach dem Patchen). Berichten Sie diese KPIs monatlich – sie sind auch für Auditoren relevant.
Ein systematischer Patch-Prozess ist keine Option, sondern eine Notwendigkeit. Die meisten erfolgreichen Angriffe auf SAP-Systeme nutzen bekannte, aber nicht gepatchte Schwachstellen. Investieren Sie in einen robusten Prozess mit klarem Kalender, Risikoanalyse, Test-Pipeline und Rollback-Strategien.
HANA-spezifische Analyse, SQL-Tuning und proaktives Monitoring.
Weiterlesen →Das SAP Security Audit Log richtig konfigurieren und auswerten.
Weiterlesen →10 Maßnahmen für sichere SAP-Systeme.
Weiterlesen →Wir helfen Ihnen bei der Umsetzung – von der Analyse bis zum Go-Live.
Jetzt anfragen