Seminar Cloud&Heat Titan / SecuStack – Intensivseminar Architektur, Bereitstellung und Plattformdienste

Inhaltsübersicht

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

Seminarprofil

Das Intensivseminar bündelt Architektur, physische Infrastruktur, Inbetriebnahme, Kubernetes, Yaook und die wichtigsten OpenStack-Plattformdienste. Es eignet sich als zusammenhängender technischer Einstieg für Aufbau- und Übergabeprojekte und fasst die entsprechenden Fachseminare in verdichteter Form zusammen.

Lernziele

• eine vollständige Referenzarchitektur mit Fehlerdomänen und Vertrauenszonen erstellen
• physische Infrastruktur, Kühlung, Strom und Skalierungsreserven bewerten
• Bereitstellung, Inbetriebnahme und Abnahme schrittweise planen
• Kubernetes- und Yaook-Zustände sicher interpretieren
• Identität, Compute, Netzwerk und Storage als integrierte OpenStack-Dienste betreiben

Zielgruppe und Voraussetzungen

Zielgruppe: Cloud- und Lösungsarchitektur, Plattformadministration, technische Projektleitung, Systemintegration, Rechenzentrums- und Netzwerkbetrieb.

Voraussetzungen: Gute Kenntnisse in Linux, Virtualisierung und IP-Netzwerken. Erste praktische Erfahrung mit Kubernetes oder OpenStack wird empfohlen.

Seminarinhalte

Tag 1: Gesamtarchitektur und Dimensionierung

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

Einordnung von Titan und SecuStack

Die Einheit ordnet die Plattform als vorkonfigurierte, skalierbare On-Premises-Cloud für souveräne und besonders geschützte Betriebsmodelle ein.

1. Schritt 1 – Anwendungsfall abgrenzen: Schutzbedarf, Datenlokation, Verfügbarkeitsziel und erforderliche Offline-Fähigkeit werden als belastbare Rahmenbedingungen erfasst.
2. Schritt 2 – Leistungsumfang strukturieren: Hardware, Cloud-Plattform, Betriebswerkzeuge, Sicherheitsfunktionen und optionale Betriebsleistungen werden voneinander abgegrenzt.
3. Schritt 3 – Betriebsmodell zuordnen: Eigenbetrieb, unterstützter Betrieb und vollständig betreute Varianten werden anhand von Verantwortlichkeiten und Reaktionszeiten verglichen.
4. Schritt 4 – Zielbild dokumentieren: Die gewählte Ausbaustufe wird mit Annahmen, Abhängigkeiten, offenen Entscheidungen und Abnahmekriterien festgehalten.

Praxisbezug: Erstellung eines kompakten Zielbilds für einen beispielhaften KRITIS-nahen oder souveränen On-Premises-Einsatz.

Referenzarchitektur und Schichtenmodell

Die Plattform wird in physische Infrastruktur, Kubernetes- und Operator-Ebene, OpenStack-Dienste, Sicherheitsfunktionen und Betriebsprozesse zerlegt.

1. Schritt 1 – Schichten identifizieren: Rack, Compute, Storage, Netzwerk, Management, Kubernetes, Yaook-Operatoren und OpenStack-Dienste werden in einer Gesamtübersicht verortet.
2. Schritt 2 – Abhängigkeiten erfassen: Steuerungs-, Daten- und Verwaltungswege werden zwischen den Schichten nachvollzogen und kritische Kopplungen markiert.
3. Schritt 3 – Fehlerdomänen bilden: Ausfallbereiche für Strom, Kühlung, Netzwerk, Hosts, Cluster-Komponenten und Plattformdienste werden systematisch getrennt.
4. Schritt 4 – Architektur bewerten: Redundanz, Wartbarkeit, Skalierbarkeit und Sicherheitszonen werden gegen die zuvor definierten Anforderungen geprüft.

Praxisbezug: Aufbau eines Architekturdiagramms mit Schichten, Schnittstellen, Vertrauensgrenzen und Fehlerdomänen.

Steuerungs-, Management- und Datenebenen

Getrennte Ebenen reduzieren Fehlerfolgen und schaffen kontrollierbare Zugriffswege für Administration, Plattformdienste und Nutzlasten.

1. Schritt 1 – Datenflüsse klassifizieren: BMC-Zugriffe, Kubernetes-Steuerung, OpenStack-APIs, Storage-Verkehr, Tenant-Verkehr und Monitoring werden getrennt erfasst.
2. Schritt 2 – Vertrauenszonen festlegen: Administrations-, Infrastruktur-, Service- und Mandantenzonen werden mit erlaubten Kommunikationsbeziehungen definiert.
3. Schritt 3 – Zugriffswege begrenzen: Jump Hosts, Management-VPN, Mehrfaktorverfahren und rollenbasierte Freigaben werden den administrativen Tätigkeiten zugeordnet.
4. Schritt 4 – Kontrollpunkte bestimmen: Protokollierung, Filterung, Zertifikatsprüfung und Anomalieerkennung werden an geeigneten Übergängen vorgesehen.

Praxisbezug: Entwurf einer Kommunikationsmatrix mit Quelle, Ziel, Protokoll, Zweck und Genehmigungsstatus.

Sizing, Kapazität und Reserven

Ressourcenbedarf wird aus Workloads, Schutzbedarf, Wachstum, Wartungsfenstern und Hochverfügbarkeitsanforderungen abgeleitet.

1. Schritt 1 – Lastprofile erfassen: CPU-, RAM-, Storage-, IOPS- und Netzanforderungen werden getrennt nach Grundlast, Spitzenlast und Wachstum dokumentiert.
2. Schritt 2 – Overcommit festlegen: Zulässige Überbuchung wird für Compute-Ressourcen anhand von Workload-Klassen und Performance-Risiken bewertet.
3. Schritt 3 – Ausfallreserve berechnen: Kapazität für Knotenwartung, Hostausfall, Rebuilds und geplante Erweiterungen wird als feste Reserve eingeplant.
4. Schritt 4 – Grenzwerte definieren: Warn-, Planungs- und Eskalationsschwellen werden für zentrale Ressourcen und Fehlerdomänen festgelegt.

Praxisbezug: Berechnung eines groben Kapazitätsmodells mit N+1-Reserve und Wachstumspuffer.

Tag 2: Hardware, Strom, Kühlung und Skalierung

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

Physische Infrastruktur und Hardwaretopologie

Die physische Basis wird vom Rack über Server und Netzkomponenten bis zu Stromversorgung und Sensorik betrachtet.

1. Schritt 1 – Komponenten inventarisieren: Servertypen, Netzkomponenten, Massenspeicher, Managementschnittstellen, PDUs und Sensoren werden mit ihrer Funktion erfasst.
2. Schritt 2 – Verkabelung nachvollziehen: Management-, Storage- und Datennetze sowie Strompfade werden den jeweiligen Ports und Redundanzgruppen zugeordnet.
3. Schritt 3 – Ressourcenprofile bilden: CPU, Arbeitsspeicher, lokale Datenträger, Netzbandbreite und Reservekapazitäten werden pro Knotenklasse dokumentiert.
4. Schritt 4 – Fehlerauswirkungen prüfen: Der Ausfall einzelner Server, Switches, Strompfade oder Sensoren wird gegen das geplante Betriebsmodell bewertet.

Praxisbezug: Erstellung einer vereinfachten Rack- und Verkabelungsdokumentation für eine Titan-Ausbaustufe.

Rack, Stromversorgung und physische Redundanz

Physische Verfügbarkeit hängt von sauberer Aufstellung, getrennten Strompfaden, Belastungsreserven und dokumentierten Wartungsverfahren ab.

1. Schritt 1 – Standort prüfen: Traglast, Abmessungen, Zugang, Brandschutz, Umgebung und Serviceflächen werden gegen die Anforderungen geprüft.
2. Schritt 2 – Strompfade dokumentieren: Einspeisung, USV, PDUs, A/B-Verteilung, Absicherung und Messpunkte werden vollständig erfasst.
3. Schritt 3 – Lasten berechnen: Nennleistung, reale Last, Anlaufverhalten, Reserve und Erweiterung werden je Strompfad bewertet.
4. Schritt 4 – Ausfall testen: Umschaltung, einzelner Strompfad und Wiederkehr werden unter kontrollierten Bedingungen geprüft.

Praxisbezug: Erstellung einer Strompfad- und Lastmatrix mit Redundanzprüfung.

Luft- und Wasserkühlung

Kühlung wird als betriebliche Infrastruktur mit Leistungsgrenzen, Sensorik, Wartung und Fehlerreaktion behandelt.

1. Schritt 1 – Kühlkonzept einordnen: Luft- und Wasserkühlung werden hinsichtlich Dichte, Effizienz, Standortanforderung und Wartung verglichen.
2. Schritt 2 – Betriebsparameter festlegen: Temperatur, Durchfluss, Druck, Feuchte und zulässige Grenzbereiche werden dokumentiert.
3. Schritt 3 – Sensorik überwachen: Messpunkte, Alarmgrenzen, Trendanalyse und Korrelation mit IT-Last werden eingerichtet.
4. Schritt 4 – Fehlerfall planen: Pumpen-, Lüfter-, Leckage- oder Gebäudetechnikausfall werden mit Lastreduktion und Abschaltreihenfolge verbunden.

Praxisbezug: Auswertung eines Kühlungsalarms und Entwicklung einer gestuften Reaktion.

Skalierung vom Einzelrack zur größeren Plattform

Skalierung betrifft neben Compute auch Netzwerk, Storage, Management, Kühlung, Strom, Fehlerdomänen und Betriebsorganisation.

1. Schritt 1 – Engpass bestimmen: Kapazität und Wachstum werden getrennt für Compute, RAM, Storage, Netzwerk und Plattformdienste bewertet.
2. Schritt 2 – Erweiterungsmodell wählen: Knotenweise Erweiterung und zusätzliche Micro-DC-Einheiten werden hinsichtlich Fehlerdomänen und Betriebsaufwand verglichen.
3. Schritt 3 – Integration planen: Adressierung, Routing, Storage-Verteilung, Clusterzuordnung, Monitoring und Ersatzteile werden abgestimmt.
4. Schritt 4 – Skalierung abnehmen: Kapazität, Performance, Failover, Rebalancing und Dokumentation werden nach der Erweiterung geprüft.

Praxisbezug: Entwurf eines Erweiterungsschritts mit zusätzlichen Compute- und Storage-Ressourcen.

Tag 3: Bereitstellungsplanung und Inbetriebnahme

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

Bereitstellungs- und Inbetriebnahmeplanung

Eine belastbare Inbetriebnahme verbindet technische Arbeitspakete mit Abhängigkeiten, Rollen, Prüfpunkten und Rückfalloptionen.

1. Schritt 1 – Voraussetzungen prüfen: Standort, Strom, Kühlung, Netzwerk, Namensauflösung, Zeitquelle, Zertifikate und Zugangswege werden vor Lieferung verifiziert.
2. Schritt 2 – Arbeitspakete ordnen: Aufstellung, Verkabelung, Basisprüfung, Clusteraktivierung, Plattformkonfiguration und Abnahme werden in eine feste Reihenfolge gebracht.
3. Schritt 3 – Verantwortung zuweisen: Für jedes Arbeitspaket werden Durchführung, Freigabe, Dokumentation und Eskalation eindeutig zugeordnet.
4. Schritt 4 – Rückfall planen: Abbruchkriterien, Wiederanlaufpunkte und sichere Zwischenzustände werden für risikoreiche Schritte festgelegt.

Praxisbezug: Erstellung eines Inbetriebnahmeplans mit Meilensteinen, Abhängigkeiten und Abnahmepunkten.

Netzwerkdesign und Segmentierung

Ein tragfähiges Design trennt Management, Plattformdienste, Storage, Mandanten und externe Übergänge nach Schutz- und Leistungsbedarf.

1. Schritt 1 – Zonen definieren: Vertrauensniveau, Datenklasse, Kommunikationsbedarf und Betriebsverantwortung werden pro Zone festgelegt.
2. Schritt 2 – Adressräume planen: IPv4- und gegebenenfalls IPv6-Bereiche, Reserven, Routinggrenzen und Überschneidungen werden dokumentiert.
3. Schritt 3 – Redundanz auslegen: Uplinks, Bonding, Switch-Paare, Gateways und Fehlerdomänen werden auf Wartbarkeit und Ausfallsicherheit geprüft.
4. Schritt 4 – Durchsatz dimensionieren: Ost-West-, Nord-Süd-, Storage- und Managementverkehr werden mit Spitzenlast und Reserve betrachtet.

Praxisbezug: Entwurf eines segmentierten Netzplans mit VLAN-, Routing- und Hochverfügbarkeitskonzept.

Technische Inbetriebnahme

Die Aktivierung erfolgt kontrolliert vom physischen Systemzustand bis zur nutzbaren Cloud-Plattform.

1. Schritt 1 – Grundzustand prüfen: Seriennummern, Firmwarestände, Verkabelung, Sensorwerte, Strompfade und Managementzugriffe werden gegen die Lieferdokumentation geprüft.
2. Schritt 2 – Basisdienste validieren: Zeit, DNS, Zertifikatsketten, Registry-Zugriffe und interne Kommunikationspfade werden vor dem Plattformstart getestet.
3. Schritt 3 – Clusterzustand herstellen: Knotenrollen, Kubernetes-Komponenten und Yaook-Operatoren werden in definierter Reihenfolge auf Betriebsbereitschaft geprüft.
4. Schritt 4 – Cloud-Dienste freigeben: OpenStack-Endpunkte, Identitätsdienste, Images, Netzwerke, Storage und Beispielinstanzen werden funktional validiert.

Praxisbezug: Durchführung einer simulierten Inbetriebnahme anhand einer Prüfliste mit dokumentierten Soll- und Ist-Werten.

Abnahme und Betriebsfreigabe

Die Abnahme verbindet technische Funktionstests mit Sicherheits-, Leistungs- und Dokumentationsnachweisen.

1. Schritt 1 – Abnahmekatalog festlegen: Funktion, Performance, Hochverfügbarkeit, Wiederanlauf, Logging, Berechtigungen und Sicherheitsvorgaben werden in prüfbare Kriterien übersetzt.
2. Schritt 2 – Tests reproduzierbar ausführen: Testdaten, Startzustand, erwartetes Ergebnis und tatsächliches Ergebnis werden pro Prüffall dokumentiert.
3. Schritt 3 – Abweichungen bewerten: Mängel werden nach Risiko, Betriebsrelevanz und erforderlicher Nacharbeit priorisiert.
4. Schritt 4 – Freigabe dokumentieren: Restpunkte, Verantwortlichkeiten, Fristen, Betriebsgrenzen und formale Freigabe werden nachvollziehbar festgehalten.

Praxisbezug: Entwicklung eines Abnahmeprotokolls für Plattformfunktion, Ausfallsicherheit und Sicherheitskontrollen.

Tag 4: Kubernetes, Yaook und deklarative Konfiguration

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

Kubernetes-Grundlagen für den Plattformbetrieb

Kubernetes stellt die Orchestrierungsebene für die OpenStack-Kontrolldienste und die zugehörigen Operatoren bereit.

1. Schritt 1 – Objekte einordnen: Namespaces, Pods, Deployments, StatefulSets, Services, Jobs, ConfigMaps und Secrets werden nach Funktion unterschieden.
2. Schritt 2 – Zustand lesen: Desired State, aktueller Status, Conditions, Events und Controller-Verantwortung werden systematisch ausgewertet.
3. Schritt 3 – Scheduling verstehen: Node Labels, Taints, Affinitäten, Ressourcenanforderungen und PodDisruptionBudgets werden auf Platzierung und Verfügbarkeit bezogen.
4. Schritt 4 – Basisdiagnose durchführen: Podstatus, Logs, Events, Endpunkte und Ressourcenverbrauch werden in fester Reihenfolge geprüft.

Praxisbezug: Analyse einer Beispielanwendung mit Deployment, Service, ConfigMap, Secret und gestörtem Pod.

Yaook-Operatoren und deklarativer Betrieb

Yaook nutzt Kubernetes-Operatoren, um OpenStack-Dienste deklarativ bereitzustellen und fortlaufend auf den gewünschten Zustand abzugleichen.

1. Schritt 1 – Custom Resources identifizieren: Dienstspezifische Ressourcen und ihre Spezifikation werden den erzeugten Kubernetes-Objekten zugeordnet.
2. Schritt 2 – Reconciliation verfolgen: Änderung, Operator-Reaktion, erzeugte Teilressourcen und Statusbedingungen werden über mehrere Schleifen beobachtet.
3. Schritt 3 – Abhängigkeiten lesen: Datenbanken, Message Queues, Zertifikate, Secrets, Services und Jobs werden als verwaltete Teilressourcen verstanden.
4. Schritt 4 – Eingriffe begrenzen: Manuelle Änderungen an abgeleiteten Objekten werden vermieden oder als temporäre Diagnosemaßnahme klar dokumentiert.

Praxisbezug: Änderung einer Testkonfiguration über eine Custom Resource und Beobachtung der Operator-Reconciliation.

Custom Resources, Status und Reconciliation

Eine präzise Interpretation von Spec, Status und Conditions ist Voraussetzung für sichere Änderungen und zielgerichtete Fehleranalyse.

1. Schritt 1 – Spec prüfen: Gewünschte Version, Replikate, Ressourcen, Konfiguration, Zertifikate und Abhängigkeiten werden vollständig gelesen.
2. Schritt 2 – Status interpretieren: Observed Generation, Conditions, Teilressourcen und Fehlermeldungen werden dem aktuellen Änderungsstand zugeordnet.
3. Schritt 3 – Reconciliation beobachten: Events, Operator-Logs und Objektänderungen werden zeitlich korreliert, ohne den Prozess durch parallele Eingriffe zu verfälschen.
4. Schritt 4 – Stabilen Zustand bestätigen: Ready-Bedingungen, Replikatstatus, Endpunkte und Dienstfunktion werden nach Abschluss geprüft.

Praxisbezug: Auswertung einer nicht bereiten Custom Resource und Ableitung der zuerst zu prüfenden Abhängigkeit.

Konfiguration, Secrets und Zertifikate

Konfigurationsdaten, Geheimnisse und Zertifikate werden getrennt, versioniert und mit minimalem Zugriff verwaltet.

1. Schritt 1 – Daten klassifizieren: Öffentliche Konfiguration, vertrauliche Parameter, Passwörter, Schlüssel und Zertifikate werden eindeutig unterschieden.
2. Schritt 2 – Ablage festlegen: ConfigMaps, Kubernetes-Secrets, externe Schlüsselverwaltung und verschlüsselte Repositories werden nach Schutzbedarf gewählt.
3. Schritt 3 – Rotation planen: Gültigkeit, Erneuerung, Abhängigkeiten, Rollout und Rückfall werden für Zertifikate und Zugangsdaten festgelegt.
4. Schritt 4 – Verwendung prüfen: Mounts, Umgebungsvariablen, Dateirechte und unbeabsichtigte Ausgabe in Logs werden kontrolliert.

Praxisbezug: Planung einer Zertifikatsrotation mit betroffenen Diensten, Reihenfolge und Prüfschritten.

Tag 5: OpenStack-Kerndienste und Betriebsübergabe

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

Keystone-Grundlagen und Servicekatalog

Keystone stellt Identitäten, Projekte, Rollen, Tokens und den Servicekatalog für die übrigen OpenStack-Dienste bereit.

1. Schritt 1 – Identitätsobjekte ordnen: Domänen, Benutzer, Gruppen, Projekte und Rollen werden mit eindeutiger Verantwortlichkeit modelliert.
2. Schritt 2 – Rollenzuweisungen prüfen: Direkte und gruppenbasierte Zuweisungen werden nach Geltungsbereich und Vererbung ausgewertet.
3. Schritt 3 – Tokenfluss nachvollziehen: Authentifizierung, Tokeninhalt, Gültigkeitsdauer und Verwendung an Service-Endpunkten werden analysiert.
4. Schritt 4 – Servicekatalog kontrollieren: Regionen, Services, Endpunkte und Schnittstellentypen werden auf Vollständigkeit und korrekte Zieladressen geprüft.

Praxisbezug: Aufbau eines kleinen Identitätsmodells und Prüfung der daraus resultierenden Token- und Kataloginformationen.

Instanz-Lifecycle und Betriebszustände

Der vollständige Lebenszyklus einer Instanz wird von der Anforderung bis zur geordneten Außerbetriebnahme betrachtet.

1. Schritt 1 – Bereitstellung planen: Image, Flavor, Netzwerk, Sicherheitsgruppen, Schlüssel, Metadaten und Storage werden vor dem Start vollständig festgelegt.
2. Schritt 2 – Instanz starten: Scheduler-Entscheidung, Port-Erzeugung, Volume-Anbindung und Hypervisor-Status werden während des Boot-Vorgangs geprüft.
3. Schritt 3 – Betriebsänderungen durchführen: Resize, Reboot, Rebuild, Snapshot, Stop und Migration werden mit ihren Auswirkungen auf Verfügbarkeit und Daten bewertet.
4. Schritt 4 – Außerbetriebnahme sichern: Datenexport, Löschung, Freigabe abhängiger Ressourcen und Nachweis der Bereinigung werden kontrolliert abgearbeitet.

Praxisbezug: Durchführung eines Instanz-Lifecycles einschließlich Resize, Snapshot, Wiederherstellung und geordneter Löschung.

Neutron-Ressourcen und Portmodell

Neutron bildet virtuelle Netze, Subnetze, Ports, Router, Sicherheitsgruppen und Adresszuweisungen als kontrollierbare Ressourcen ab.

1. Schritt 1 – Netzobjekte unterscheiden: Provider-Netze, Self-Service-Netze, Subnetze, Ports und Router werden nach Eigentum und Funktion getrennt.
2. Schritt 2 – Portbindung verstehen: MAC-Adresse, feste IP, Sicherheitsgruppen, Binding-Informationen und Gerätezuordnung werden am Port nachvollzogen.
3. Schritt 3 – Adressierung planen: Subnetze, DHCP, Gateways, Reservierungen und Überschneidungsrisiken werden vor der Bereitstellung geprüft.
4. Schritt 4 – Ressourcenbeziehungen prüfen: Instanz, Port, Netzwerk, Router und externe Anbindung werden als vollständiger Kommunikationspfad betrachtet.

Praxisbezug: Aufbau eines Tenant-Netzes mit Subnetz, Router, Instanzport und kontrollierter externer Erreichbarkeit.

Storage-Architektur und Datenklassen

Block-, Image-, Objekt- und lokale Speicherfunktionen werden nach Persistenz, Leistung, Schutzbedarf und Wiederherstellbarkeit eingeordnet.

1. Schritt 1 – Datenarten klassifizieren: Betriebssystem-Images, Boot-Volumes, Anwendungsdaten, Backups, Protokolle und temporäre Daten werden getrennt betrachtet.
2. Schritt 2 – Dienstzuordnung treffen: Glance, Cinder, Objektspeicher und lokale Ephemeral-Datenträger werden nach Lebenszyklus und Zugriffsmuster ausgewählt.
3. Schritt 3 – Leistungsziele definieren: Kapazität, IOPS, Latenz, Durchsatz und Wiederherstellungsanforderungen werden pro Datenklasse festgelegt.
4. Schritt 4 – Fehlerdomänen prüfen: Knoten-, Datenträger-, Rack- und Standortausfälle werden gegen Replikation und Backupstrategie bewertet.

Praxisbezug: Erstellung einer Datenklassenmatrix mit passendem Storage-Dienst, Schutz und Wiederherstellungsziel.

Dokumentation und Übergabe in den Betrieb

Technische Dokumentation wird so strukturiert, dass Routinebetrieb, Störung und Audit ohne Wissensinseln beherrschbar bleiben.

1. Schritt 1 – Dokumentklassen bilden: Architektur, Inventar, Konfiguration, Betriebshandbuch, Notfallhandbuch, Prüfprotokolle und Änderungsnachweise werden getrennt gepflegt.
2. Schritt 2 – Betriebswissen sichern: Standardaufgaben, Grenzwerte, Eskalationen und bekannte Besonderheiten werden als versionierte Runbooks beschrieben.
3. Schritt 3 – Zugriff regeln: Vertrauliche Unterlagen, Geheimnisse und Notfallinformationen erhalten abgestufte Berechtigungen und sichere Ablageorte.
4. Schritt 4 – Pflegeprozess definieren: Änderungsanlässe, Verantwortliche, Prüffristen und Freigabeschritte werden für jede Dokumentklasse festgelegt.

Praxisbezug: Aufbau einer Übergabematrix mit Dokument, Eigentümer, Schutzklasse, Aktualisierungsanlass und Prüffrist.

Praxislabor

• Erstellung eines kompakten Zielbilds für einen beispielhaften KRITIS-nahen oder souveränen On-Premises-Einsatz.
• Erstellung einer vereinfachten Rack- und Verkabelungsdokumentation für eine Titan-Ausbaustufe.
• Erstellung eines Inbetriebnahmeplans mit Meilensteinen, Abhängigkeiten und Abnahmepunkten.
• Analyse einer Beispielanwendung mit Deployment, Service, ConfigMap, Secret und gestörtem Pod.
• Aufbau eines kleinen Identitätsmodells und Prüfung der daraus resultierenden Token- und Kataloginformationen.
• Aufbau einer Übergabematrix mit Dokument, Eigentümer, Schutzklasse, Aktualisierungsanlass und Prüffrist.

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.