Zum Hauptinhalt springen

Patch Management

Jeder Patch, der in Produktion geht, läuft denselben risikobasierten Weg: identifizieren, bewerten, priorisieren, testen, im Vier-Augen-Prinzip freigeben, ausrollen und dokumentieren. Kritische Fixes werden schnell umgesetzt, risikoarme Arbeiten fahren im regulären Release-Zyklus mit, alles ist nachvollziehbar.

Prioritätsklassen und Umsetzungsfristen​

Kritisch
Schwachstellen mit unmittelbarer, erheblicher Gefahr für Vertraulichkeit, Integrität oder Verfügbarkeit oder aktiv ausgenutzte Lücken.
Unverzüglich
Hoch
Schwachstellen mit hohem Risiko, bei denen Missbrauch wahrscheinlich oder ein erheblicher Betriebsimpact möglich ist.
Innerhalb von 24 Stunden
Mittel
Relevantes, aber nicht unmittelbares Risiko oder funktionale Updates mit sicherheitsseitiger Relevanz.
Innerhalb von 2 Tagen
Niedrig
Geringe sicherheitsseitige Relevanz oder rein funktional-technische Verbesserungen ohne erhöhtes Risiko.
Innerhalb von 3 Tagen (bzw. regulärer Zyklus)

Was im Scope liegt​

Betriebssysteme, Container- und Runtime-Komponenten (Docker, Kubernetes, soweit administriert), Applikationen (eigenentwickelt und Standardsoftware), Drittanbieter-Bibliotheken und Abhängigkeiten, Datenbanken, Cloud- und Infrastrukturkomponenten unter administrativem Einfluss sowie Sicherheitskomponenten (Firewalls, Endpoint-Security, IAM/SSO, Monitoring, Security-Tools).

Bei vollständig gemanagten Services (SaaS, Managed Databases, Cloud-Plattformdienste, Hosting-Basisinfrastruktur) liegt das Patching der zugrunde liegenden Plattform im Shared-Responsibility-Modell beim Anbieter. Unser eigener Scope umfasst dann weiterhin kundenseitig administrierte Konfigurationen und Workloads, Aktualisierung eigener Anwendungen und Deployments, Bewertung providerseitiger Security Advisories sowie Risikobewertung und Nachverfolgung relevanter Sicherheitsupdates.

Die sieben Grundsätze​

✓
Risikobasierter Ansatz
Patches werden nach Kritikalität und potenziellen Auswirkungen auf Vertraulichkeit, Integrität, Verfügbarkeit und Datenschutz priorisiert.
✓
Zeitnahe Umsetzung
Sicherheitsrelevante Updates werden im jeweiligen Prioritätsfenster ausgerollt.
✓
Test vor Produktion
Jede Änderung wird vor der Ausbringung in die Produktivumgebung technisch verifiziert.
✓
Nachvollziehbarkeit
Patch-Maßnahmen sind dokumentiert, die Umsetzung ist revisionsfest protokolliert.
✓
Umgebungstrennung
Entwicklungs-, Test- und Produktivumgebung bleiben getrennt. Nichts geht ungeprüft durch.
✓
Vier-Augen-Prinzip
Produktive Patches werden von der technischen Leitung im Vier-Augen-Prinzip geprüft und freigegeben.
✓
Rollback-Fähigkeit
Für jeden produktiven Patch existiert ein dokumentierter Rückweg auf einen geeigneten vorherigen stabilen Stand.

Fristüberschreitungen und Kompensationsmaßnahmen​

Lässt sich ein Patch nicht innerhalb seines Fensters umsetzen, entscheidet die technische Leitung nach Team-Abstimmung und dokumentiert Begründung und Kompensationsmaßnahmen im zugehörigen Pull Request oder in der technischen Dokumentation. Typische Kompensationsmaßnahmen: Konfigurationsanpassungen, Deaktivierung nicht erforderlicher Funktionen, verschärfte Zugriffsbeschränkungen, zusätzliche Überwachung oder organisatorische Einschränkungen bis zur Umsetzung.

Nachweise​

  • Patch-bezogene Artefakte und Nachweise werden mindestens ein Jahr aufbewahrt.
  • Die Dokumentation umfasst betroffene Komponente, Quelle des Patches, Priorität, Datum der Bewertung, Datum der Umsetzung, verantwortliche Rollen, Prüfergebnisse und ggf. Abweichungen oder Kompensationsmaßnahmen.
  • Manuelle Testnachweise liegen im Pull Request. Automatisierte Testnachweise liegen in den Azure-DevOps-Pipelines.

Passende Seiten​