Seminar Cloud&Heat Titan / SecuStack – Patch-, Release- und Lifecycle-Management

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Seminar verbindet Schwachstellenbewertung, Patches, Plattform-Baselines, Yaook-Upgrades, Offline-Artefakte und Change Management. Ziel ist ein reproduzierbarer Lifecycle-Prozess über Firmware, Betriebssystem, Kubernetes, Yaook und OpenStack.

Lernziele

• Schwachstellen risikoorientiert priorisieren und Komponenten zuordnen
• eine vollständige Plattform-Baseline pflegen
• Patches und Releases gestuft testen und freigeben
• Yaook- und OpenStack-Upgrades kontrolliert überwachen
• Offline-Updatepakete und Rückfallverfahren nachvollziehbar vorbereiten

Zielgruppe und Voraussetzungen

Zielgruppe: Plattformadministration, IT-Sicherheit, Change und Release Management, Cloud Operations, technische Serviceverantwortung.

Voraussetzungen: Erfahrung im Betrieb von Linux- oder Cloud-Plattformen. Grundlagen zu Kubernetes und OpenStack sowie Verständnis für Wartungsfenster.

Seminarinhalte

Tag 1: Schwachstellen, Patches und Versionsbaselines

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Patch- und Schwachstellenprozess

Patches werden anhand Risiko, Exponierung, Verfügbarkeit, Abhängigkeiten und Testbarkeit priorisiert.

1. Schritt 1 – Informationsquellen bündeln: Herstellerhinweise, Projektmeldungen, Scannergebnisse und interne Befunde werden einem Komponentenbestand zugeordnet.
2. Schritt 2 – Risiko bewerten: Schweregrad, Ausnutzbarkeit, Erreichbarkeit, vorhandene Kontrollen und betroffene Daten bestimmen die Priorität.
3. Schritt 3 – Umsetzung planen: Test, Wartungsfenster, Reihenfolge, Backup, Abbruchkriterium und Rückfall werden pro Patchpaket festgelegt.
4. Schritt 4 – Wirksamkeit bestätigen: Versionsstand, Funktionstest, erneuter Scan und Abschlussdokumentation belegen die Behebung.

Praxisbezug: Bearbeitung eines beispielhaften kritischen Sicherheitsupdates vom Eingang bis zum Wirksamkeitsnachweis.

Schwachstellenmanagement und technische Nachweise

Schwachstellen werden über Bestand, Bewertung, Behandlung, Ausnahme und Wirksamkeitsprüfung lückenlos gesteuert.

1. Schritt 1 – Bestand zuordnen: Befunde werden auf konkrete Komponente, Version, Exponierung und Verantwortlichkeit abgebildet.
2. Schritt 2 – Priorität bestimmen: Technischer Schweregrad wird um Erreichbarkeit, Ausnutzbarkeit, Schutzkontrollen und Betriebswirkung ergänzt.
3. Schritt 3 – Behandlung festlegen: Patch, Konfigurationsänderung, Isolation, Abschaltung oder befristete Risikoakzeptanz werden dokumentiert.
4. Schritt 4 – Abschluss belegen: Erneuter Scan, Versionsnachweis und Funktionstest bestätigen die wirksame Behebung.

Praxisbezug: Bewertung und Behandlung einer Beispielschwachstelle einschließlich begründeter Priorisierung.

Release- und Versionsmanagement

Abhängige Versionen von Firmware, Betriebssystem, Kubernetes, Yaook und OpenStack werden als gemeinsame Plattform-Baseline verwaltet.

1. Schritt 1 – Baseline erfassen: Aktive Versionen, Build-Quellen, Konfigurationsstände und Abweichungen werden vollständig inventarisiert.
2. Schritt 2 – Zielrelease bewerten: Funktionen, Sicherheitskorrekturen, Inkompatibilitäten, Datenmigrationen und Supportzeiträume werden geprüft.
3. Schritt 3 – Freigabekette definieren: Labor, Vorproduktion, Pilot und Produktion erhalten definierte Eintritts- und Austrittskriterien.
4. Schritt 4 – Versionsnachweis pflegen: Sollstand, Iststand, Ausnahme, Frist und verantwortliche Stelle werden kontinuierlich aktualisiert.

Praxisbezug: Erstellung einer Plattform-Baseline und eines gestuften Freigabemodells.

Tag 2: Yaook-Lifecycle, Offline-Updates und Changes

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Yaook-Lifecycle und kontrollierte Upgrades

Upgrades werden über deklarative Versionsänderungen gesteuert und mit Abhängigkeits-, Zustands- und Funktionstests abgesichert.

1. Schritt 1 – Kompatibilität prüfen: Zielversionen von Operatoren, OpenStack-Diensten, Kubernetes und abhängigen Komponenten werden vorab abgeglichen.
2. Schritt 2 – Änderungsreihenfolge festlegen: CRDs, Operatoren, gemeinsame Dienste und OpenStack-Komponenten werden in eine kontrollierte Upgrade-Sequenz gebracht.
3. Schritt 3 – Rollout überwachen: Conditions, Upgrade-Barrieren, Jobs, Pod-Restarts und Servicezustände werden während der Änderung beobachtet.
4. Schritt 4 – Nachprüfung durchführen: API, Authentifizierung, Netzwerk, Compute, Storage und ausgewählte Workloads werden nach dem Upgrade getestet.

Praxisbezug: Erstellung eines Upgrade-Runbooks mit Vorprüfung, Reihenfolge, Abbruchkriterien und Nachtests.

Updates in Offline- und Air-Gapped-Umgebungen

Offline-Updates benötigen kontrollierte Übergabepunkte, vollständige Artefaktlisten, Integritätsnachweise und lokale Bereitstellungsdienste.

1. Schritt 1 – Artefaktbedarf ermitteln: Container-Images, Pakete, Firmware, Helm-Charts, CRDs, Signaturen und Dokumentation werden versionsgenau zusammengestellt.
2. Schritt 2 – Transfer freigeben: Quelle, Prüfsumme, Signatur, Malwareprüfung, Vier-Augen-Freigabe und Transfermedium werden dokumentiert.
3. Schritt 3 – Lokale Quellen aktualisieren: Registry, Paketspiegel und Firmwareablage werden ohne unkontrollierte Überschreibung gepflegt.
4. Schritt 4 – Rollout nachweisen: Version, Funktion, Rückfallfähigkeit und vollständige Entfernung temporärer Transferdaten werden geprüft.

Praxisbezug: Entwicklung eines Offline-Updatepakets mit Manifest, Prüfsummen, Freigabe und Einspielreihenfolge.

Change Management und Wartungsfenster

Technische Änderungen werden mit Risiko, Abhängigkeit, Kommunikationsplan, Freigabe und Rückfall steuerbar gemacht.

1. Schritt 1 – Änderung beschreiben: Zweck, Umfang, betroffene Dienste, erwarteter Nutzen und Nicht-Ziele werden präzise festgehalten.
2. Schritt 2 – Risiko analysieren: Fehlerdomäne, Kundenauswirkung, Datenrisiko, Paralleländerungen und fehlende Tests werden bewertet.
3. Schritt 3 – Durchführung vorbereiten: Schritte, Rollen, Zeitplan, Monitoring, Abbruchkriterien und Rückfall werden verbindlich dokumentiert.
4. Schritt 4 – Abschluss bewerten: Funktion, Nebenwirkungen, Monitoring, Dokumentation und gegebenenfalls Nacharbeit werden bestätigt.

Praxisbezug: Erstellung eines Standard-Changes und eines risikoreichen Normal-Changes für eine Plattformkomponente.

Praxislabor

• Bearbeitung eines beispielhaften kritischen Sicherheitsupdates vom Eingang bis zum Wirksamkeitsnachweis.
• Bewertung und Behandlung einer Beispielschwachstelle einschließlich begründeter Priorisierung.
• Erstellung einer Plattform-Baseline und eines gestuften Freigabemodells.
• Erstellung eines Upgrade-Runbooks mit Vorprüfung, Reihenfolge, Abbruchkriterien und Nachtests.
• Entwicklung eines Offline-Updatepakets mit Manifest, Prüfsummen, Freigabe und Einspielreihenfolge.
• Erstellung eines Standard-Changes und eines risikoreichen Normal-Changes für eine Plattformkomponente.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.