Seminar Cloud&Heat Titan / SecuStack – SCS-Standards und interoperabler Cloudbetrieb

Inhaltsübersicht

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

Seminarprofil

Das Seminar ordnet die Titan- beziehungsweise SecuStack-Umgebung in die Ziele und Prüfmechanismen des Sovereign Cloud Stack ein. Standards, Konformität, Portabilität, Betriebsautonomie und beschaffbare Nachweise werden praxisbezogen bewertet.

Lernziele

• SCS-Ziele und technische Ebenen korrekt einordnen
• geltende Anforderungen und Prüfumfänge strukturiert erfassen
• Konformität mit reproduzierbaren Tests und Evidenz bewerten
• Workload-Portabilität einschließlich versteckter Abhängigkeiten prüfen
• Souveränitäts- und Beschaffungsanforderungen messbar formulieren

Zielgruppe und Voraussetzungen

Zielgruppe: Cloud-Architektur, Plattformbetrieb, IT-Strategie, technische Beschaffung, Compliance, Interoperabilitäts- und Migrationsverantwortung.

Voraussetzungen: Grundverständnis von OpenStack, Kubernetes und Cloud-Betriebsmodellen. Kenntnisse zu Standards oder Ausschreibungen sind hilfreich.

Seminarinhalte

Tag 1: SCS-Ziele, Standards und Konformität

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

Sovereign Cloud Stack im Überblick

SCS beschreibt offene Standards, Referenzimplementierungen und Konformitätsanforderungen für interoperable, souveräne Cloud-Infrastrukturen.

1. Schritt 1 – Ziele einordnen: Interoperabilität, Portabilität, offene Schnittstellen, nachvollziehbarer Betrieb und Vermeidung proprietärer Abhängigkeiten werden betrachtet.
2. Schritt 2 – Ebenen unterscheiden: IaaS-Standards, Kubernetes-Bezug, Betriebsanforderungen und Zertifizierungs- beziehungsweise Konformitätsaspekte werden getrennt.
3. Schritt 3 – Plattformbezug herstellen: OpenStack-, Kubernetes- und Betriebsfunktionen der Titan- beziehungsweise SecuStack-Umgebung werden den SCS-Themenfeldern zugeordnet.
4. Schritt 4 – Nutzen bewerten: Migration, Ausschreibung, Föderation, Mehranbieterstrategie und interne Standardisierung werden als konkrete Einsatzfelder bewertet.

Praxisbezug: Erstellung einer Zuordnung zwischen Plattformfunktionen und SCS-Zielen.

SCS-Standards und Konformitätsprüfung

Konformität wird anhand definierter Anforderungen, reproduzierbarer Tests und dokumentierter Abweichungen geprüft.

1. Schritt 1 – Anforderungsstand festlegen: Gültige Standardversion, verpflichtende Kriterien, optionale Merkmale und Geltungsbereich werden dokumentiert.
2. Schritt 2 – Ist-Zustand erfassen: API-Verhalten, Ressourcenmodelle, Versionen, Betriebsfunktionen und technische Grenzen werden erhoben.
3. Schritt 3 – Tests durchführen: Automatisierte Prüfsuiten und ergänzende manuelle Kontrollen werden in einer reproduzierbaren Umgebung ausgeführt.
4. Schritt 4 – Abweichungen behandeln: Ursache, Auswirkung, Korrektur, Ausnahme und erneute Prüfung werden nachvollziehbar gesteuert.

Praxisbezug: Planung einer SCS-Konformitätsprüfung mit Testumfang, Evidenz und Abweichungsprozess.

Interoperabilität und Workload-Portabilität

Portabilität hängt nicht nur von APIs, sondern auch von Images, Netzwerkmodellen, Storageklassen, Metadaten und Betriebsprozessen ab.

1. Schritt 1 – Portabilitätsobjekte erfassen: Images, Instanzen, Volumes, Netzdefinitionen, Sicherheitsregeln, DNS und Automatisierungscode werden betrachtet.
2. Schritt 2 – Abhängigkeiten markieren: Proprietäre Images, besondere Hardware, externe Dienste, feste Adressen und anbieterspezifische APIs werden identifiziert.
3. Schritt 3 – Migrationspfad testen: Export, Konvertierung, Import, Netzanschluss und Funktionstest werden mit einer repräsentativen Workload durchgeführt.
4. Schritt 4 – Grenzen dokumentieren: Nicht portable Funktionen, Datenvolumen, Ausfallzeit und notwendige Anpassungen werden offen festgehalten.

Praxisbezug: Entwicklung eines Portabilitätstests für eine kleine Drei-Schichten-Anwendung.

Tag 2: Souveränität, Beschaffung und Pilotnachweis

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

Digitale Souveränität und Betriebsautonomie

Souveränität wird als tatsächliche Fähigkeit verstanden, Plattform, Daten, Schlüssel, Updates und Betrieb ohne unkontrollierbare Abhängigkeiten zu beherrschen.

1. Schritt 1 – Abhängigkeiten erfassen: Software, Hardware, Wissen, Lieferkette, Schlüssel, Support, Telemetrie und externe Dienste werden untersucht.
2. Schritt 2 – Kontrollrechte bewerten: Administrationszugang, Quelloffenheit, Datenexport, Schlüsselbesitz und Änderungsfähigkeit werden überprüft.
3. Schritt 3 – Autonomiegrad bestimmen: Eigenbetrieb, Offline-Fähigkeit, lokales Wissen, Ersatzteilstrategie und Wiederaufbau werden messbar bewertet.
4. Schritt 4 – Verbesserungen priorisieren: Kritische Abhängigkeiten werden nach Risiko, Aufwand und erreichbarem Autonomiegewinn geordnet.

Praxisbezug: Erstellung einer Souveränitätsmatrix mit Abhängigkeit, Kontrollgrad und Verbesserungsmaßnahme.

Anforderungsmanagement und Beschaffung

Technische Anforderungen werden so formuliert, dass Sicherheit, Offenheit, Betrieb und Abnahme überprüfbar ausgeschrieben werden können.

1. Schritt 1 – Bedarf strukturieren: Workloads, Kapazität, Schutzbedarf, Standort, Offline-Fähigkeit und Betriebsmodell werden als Muss- und Soll-Kriterien formuliert.
2. Schritt 2 – Nachweise verlangen: Architektur, Komponentenliste, Sicherheitskonzept, Standards, Testprotokolle und Lebenszyklusinformationen werden gefordert.
3. Schritt 3 – Betriebsleistungen abgrenzen: Installation, Überwachung, Wartung, Support, Reaktionszeiten und Wissenstransfer werden eindeutig beschrieben.
4. Schritt 4 – Abnahme verankern: Funktion, Performance, Sicherheit, Wiederanlauf, Dokumentation und Übergabe erhalten messbare Kriterien.

Praxisbezug: Entwicklung eines Anforderungskatalogs für eine souveräne On-Premises-Cloud.

Pilotierung und technische Validierung

Ein Pilot reduziert Unsicherheit, wenn repräsentative Workloads, Betriebsverfahren und Sicherheitskontrollen getestet werden.

1. Schritt 1 – Pilotumfang festlegen: Workload, Datenklasse, Nutzergruppe, Integrationen und Erfolgskriterien werden begrenzt und repräsentativ gewählt.
2. Schritt 2 – Testfälle ableiten: Funktion, Leistung, Ausfall, Backup, Sicherheit, Monitoring und Betrieb werden in konkrete Tests übersetzt.
3. Schritt 3 – Ergebnisse messen: Messwerte, Abweichungen, Bedienaufwand und notwendige Anpassungen werden nachvollziehbar dokumentiert.
4. Schritt 4 – Produktionsfreigabe entscheiden: Erfüllte Kriterien, Restpunkte, Risiken und Bedingungen werden in eine belastbare Freigabeentscheidung überführt.

Praxisbezug: Entwicklung eines Pilotplans für eine repräsentative Anwendung.

Praxislabor

• Erstellung einer Zuordnung zwischen Plattformfunktionen und SCS-Zielen.
• Planung einer SCS-Konformitätsprüfung mit Testumfang, Evidenz und Abweichungsprozess.
• Entwicklung eines Portabilitätstests für eine kleine Drei-Schichten-Anwendung.
• Erstellung einer Souveränitätsmatrix mit Abhängigkeit, Kontrollgrad und Verbesserungsmaßnahme.
• Entwicklung eines Anforderungskatalogs für eine souveräne On-Premises-Cloud.
• Entwicklung eines Pilotplans für eine repräsentative Anwendung.

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.