Seminar Cloud&Heat Titan / SecuStack – Intensivseminar Sicherheit, Souveränität und Compliance

Inhaltsübersicht

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

Seminarprofil

Das Intensivseminar bündelt Bedrohungsmodell, Härtung, Verschlüsselung, Air-Gap-Betrieb, SCS-Orientierung, Compliance und Auditnachweise. Es fasst die sicherheits- und souveränitätsbezogenen Fachseminare in einem durchgängigen Kontrollmodell zusammen.

Lernziele

• Schutzbedarf, Angriffsflächen und Kontrollen methodisch ableiten
• Plattform-, Netzwerk- und Workload-Härtung überprüfbar umsetzen
• Schlüssel, Secrets und Verschlüsselung über den gesamten Lebenszyklus steuern
• Air-Gap- und Offline-Prozesse sicher gestalten
• SCS-, Souveränitäts- und Compliance-Anforderungen mit Auditnachweisen verbinden

Zielgruppe und Voraussetzungen

Zielgruppe: Informationssicherheit, Plattformadministration, Security Operations, Compliance, Architektur, Auditvorbereitung und technische Risikoverantwortung.

Voraussetzungen: Gute Kenntnisse in Netzwerken, Linux und grundlegender Cloud-Sicherheit. OpenStack- oder Kubernetes-Erfahrung ist hilfreich.

Seminarinhalte

Tag 1: Bedrohungsmodell und Härtungsbaseline

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

Bedrohungsmodell und Schutzbedarf

Das Bedrohungsmodell verbindet schützenswerte Werte, Angreiferprofile, Angriffsflächen und vorhandene Kontrollen.

1. Schritt 1 – Schutzwerte erfassen: Mandantendaten, Plattformzugänge, Schlüsselmaterial, Images, Konfigurationen und Betriebsnachweise werden klassifiziert.
2. Schritt 2 – Bedrohungen zuordnen: Externe Angriffe, Insider, Lieferkette, Fehlkonfiguration, Ausfall und Datenabfluss werden systematisch betrachtet.
3. Schritt 3 – Angriffsflächen markieren: Externe Endpunkte, Managementzugänge, APIs, Registries, Transfermedien und Wartungsschnittstellen werden bewertet.
4. Schritt 4 – Kontrollen priorisieren: Präventive, detektive und korrektive Maßnahmen werden nach Risiko und Wirksamkeit geordnet.

Praxisbezug: Erstellung eines kompakten Bedrohungsmodells mit Schutzwerten, Bedrohungen und priorisierten Kontrollen.

Härtungsbaseline für Plattformkomponenten

Eine versionierte Baseline reduziert unnötige Funktionen, beschränkt Zugriffe und definiert überprüfbare Sollwerte.

1. Schritt 1 – Komponenten erfassen: Firmware, BMC, Betriebssystem, Kubernetes, Yaook, OpenStack-Dienste und Administrationswerkzeuge werden einbezogen.
2. Schritt 2 – Sollwerte definieren: Dienste, Ports, Protokolle, Kryptografie, Dateirechte, Auditierung und Kontoschutz werden festgelegt.
3. Schritt 3 – Ausnahmen steuern: Technisch notwendige Abweichungen erhalten Begründung, Kompensationsmaßnahme, Eigentümer und Ablaufdatum.
4. Schritt 4 – Konformität messen: Automatisierte und manuelle Prüfungen liefern einen reproduzierbaren Nachweis über den aktuellen Härtungsstand.

Praxisbezug: Entwicklung einer Baseline-Prüfliste für Managementzugänge, Betriebssystem und OpenStack-APIs.

Netzwerksicherheit und administrative Zugänge

Administrative Pfade und Zonenübergänge werden auf notwendige Verbindungen beschränkt und vollständig protokolliert.

1. Schritt 1 – Zugangswege festlegen: Management-VPN, Jump Host, Out-of-Band-Management und Notfallzugang werden getrennt geplant.
2. Schritt 2 – Filterregeln ableiten: Kommunikationsmatrix und Minimalprinzip bestimmen Firewall-, ACL- und Sicherheitsgruppenregeln.
3. Schritt 3 – Protokollschutz prüfen: TLS, Zertifikatsprüfung, sichere Cipher und Abschaltung veralteter Protokolle werden kontrolliert.
4. Schritt 4 – Zugriff überwachen: Anmeldung, Privilegierung, Konfigurationsänderung und ungewöhnliche Verbindungsversuche werden erfasst.

Praxisbezug: Prüfung eines administrativen Zugriffswegs vom Arbeitsplatz bis zum Managementendpunkt.

Sichere Workload-Bereitstellung

Sicherheit der Plattform ersetzt nicht die kontrollierte Konfiguration von Images, Instanzen, Netzwerken und Anwendungsschichten.

1. Schritt 1 – Vertrauenswürdiges Image wählen: Freigabestatus, Signatur, Patchstand und Härtungsprofil werden vor der Bereitstellung geprüft.
2. Schritt 2 – Zugriff minimieren: Schlüsselbasierte Anmeldung, getrennte Administrationswege und restriktive Sicherheitsgruppen werden umgesetzt.
3. Schritt 3 – Daten schützen: Verschlüsselte Volumes, sichere Secrets und minimierte Metadaten reduzieren das Risiko eines Datenabflusses.
4. Schritt 4 – Betrieb absichern: Patchen, Host-basierte Protokollierung, Schwachstellenprüfung und geordnete Außerbetriebnahme werden eingeplant.

Praxisbezug: Bereitstellung einer gehärteten Beispielinstanz mit minimalem Netzwerkzugriff und verschlüsseltem Volume.

Tag 2: Schlüssel, Secrets und Verschlüsselung

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

Schlüsselmanagement-Architektur

Schlüsselverwaltung trennt Schlüsselmaterial, Richtlinien, Nutzung und Administration von den verschlüsselten Daten.

1. Schritt 1 – Schlüsselobjekte erfassen: Master Keys, Volume-Schlüssel, Zertifikatsschlüssel, Signaturschlüssel und Secrets werden klassifiziert.
2. Schritt 2 – Vertrauensanker festlegen: Softwarebasierte KMS, HSM oder angebundene Schlüsselplattformen werden nach Schutzbedarf und Verfügbarkeit bewertet.
3. Schritt 3 – Zugriffsmodell definieren: Erzeugen, Nutzen, Rotieren, Sichern, Wiederherstellen und Vernichten erhalten getrennte Rollen.
4. Schritt 4 – Ausfallverhalten planen: KMS-Ausfall, Netzwerkunterbrechung, Schlüsselverlust und Notfallzugriff werden mit klaren Grenzen beschrieben.

Praxisbezug: Entwurf einer Schlüsselarchitektur für verschlüsselte Volumes und Dienstzertifikate.

Schlüssel-Lifecycle und Rotation

Schlüssel werden von der Erzeugung bis zur nachweisbaren Vernichtung kontrolliert und mit abhängigen Datenbeständen verknüpft.

1. Schritt 1 – Erzeugung absichern: Zufallsquelle, Schlüssellänge, Algorithmus, Eigentümer und Zweck werden festgelegt.
2. Schritt 2 – Nutzung begrenzen: Zulässige Dienste, Gültigkeitsdauer, Exportierbarkeit und Protokollierung werden durch Richtlinien eingeschränkt.
3. Schritt 3 – Rotation durchführen: Neue Schlüssel, parallele Gültigkeit, Umschlüsselung, Funktionstest und Rücknahme des Altmaterials werden geplant.
4. Schritt 4 – Vernichtung nachweisen: Abhängigkeiten, Aufbewahrungsfristen, Backups und sichere Löschung werden vor der Vernichtung geprüft.

Praxisbezug: Erstellung eines Rotationsplans für einen Plattformschlüssel mit Rückfall- und Nachweisschritten.

Secrets und privilegierte Zugangsdaten

Secrets werden weder in Quellcode noch in ungeschützten Konfigurationen abgelegt und erhalten einen kontrollierten Lebenszyklus.

1. Schritt 1 – Secrets identifizieren: Passwörter, Tokens, private Schlüssel, Application Credentials und Recovery-Codes werden vollständig erfasst.
2. Schritt 2 – Ablage absichern: Geeignete Secret Stores, Verschlüsselung, Zugriffsrollen und Auditierung werden festgelegt.
3. Schritt 3 – Ausgabe minimieren: Logs, Shell-Historien, Tickets, Backups und Pipeline-Artefakte werden auf unbeabsichtigte Offenlegung geprüft.
4. Schritt 4 – Rotation und Widerruf planen: Kompromittierung, Personalwechsel, Ablauf und Notfall führen zu definierten Austauschverfahren.

Praxisbezug: Überprüfung eines Beispiel-Deployments auf unsichere Secrets und Entwicklung eines Bereinigungsplans.

Verschlüsselung ruhender Daten

Verschlüsselung ruhender Daten wird für Volumes, Backups, Objektablagen, Datenbanken und administrative Endgeräte differenziert umgesetzt.

1. Schritt 1 – Datenorte erfassen: Produktivdaten, Replikate, Snapshots, Backups, temporäre Dateien und Logs werden berücksichtigt.
2. Schritt 2 – Verschlüsselungsebene wählen: Datenträger-, Backend-, Volume- oder Anwendungsebene wird nach Bedrohungsmodell ausgewählt.
3. Schritt 3 – Schlüsselzuordnung prüfen: Mandantentrennung, Rotation, Backup und Wiederherstellung des Schlüsselmaterials werden sichergestellt.
4. Schritt 4 – Wirksamkeit testen: Unberechtigter Direktzugriff, Restore und Schlüsselwechsel werden kontrolliert geprüft.

Praxisbezug: Bewertung mehrerer Datenklassen und Auswahl einer passenden Verschlüsselungsebene.

Verschlüsselung von Kommunikationswegen

TLS und geschützte Tunnel sichern API-, Management-, Storage- und Mandantenverkehr gegen Mithören und Manipulation.

1. Schritt 1 – Verbindungen inventarisieren: Externe und interne APIs, Datenbanken, Message Queue, Storage, Monitoring und Verwaltungszugriffe werden erfasst.
2. Schritt 2 – Zertifikatsmodell wählen: Interne PKI, Zertifikatsprofile, Namen, Laufzeiten und Vertrauensketten werden definiert.
3. Schritt 3 – Sichere Parameter setzen: Protokollversionen, Cipher, Clientauthentifizierung und Zertifikatsprüfung werden verbindlich konfiguriert.
4. Schritt 4 – Ablauf und Fehler testen: Erneuerung, abgelaufenes Zertifikat, falsche Vertrauenskette und Namensfehler werden kontrolliert simuliert.

Praxisbezug: Erstellung einer Zertifikats- und Kommunikationsmatrix für zentrale Plattformdienste.

Tag 3: Air Gap, Softwareversorgung und Offline-Betrieb

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

Air-Gap-Architektur und Vertrauensgrenzen

Air-Gapped-Betrieb trennt die Plattform technisch und organisatorisch von externen Netzen und schafft kontrollierte Transferzonen.

1. Schritt 1 – Trennungsumfang definieren: Internet, Unternehmensnetze, Fernwartung, mobile Geräte und externe Dienste werden einzeln bewertet.
2. Schritt 2 – Transferpunkte planen: Import- und Exportstationen, Quarantäne, Prüfbereiche und sichere Übergabe werden als separate Zonen vorgesehen.
3. Schritt 3 – Interne Dienste bereitstellen: DNS, Zeit, Zertifikate, Registry, Paketspiegel und Dokumentation werden ohne externe Abhängigkeit geplant.
4. Schritt 4 – Ausnahmepfade kontrollieren: Temporäre Verbindungen und Notfallzugriffe erhalten technische Sperren, Vier-Augen-Freigabe und Protokollierung.

Praxisbezug: Entwurf einer Air-Gap-Zonenarchitektur mit Transfer- und Quarantänebereich.

Offline-Softwareversorgung und lokale Repositories

Alle benötigten Artefakte müssen vollständig, vertrauenswürdig und versionsgenau in die getrennte Umgebung überführt werden.

1. Schritt 1 – Bedarf manifestieren: Container-Images, Pakete, Charts, Firmware, Signaturen und Abhängigkeiten werden in einem Manifest erfasst.
2. Schritt 2 – Quelle verifizieren: Herkunft, Prüfsumme, Signatur, Lizenz und Sicherheitsstatus werden außerhalb der Zielumgebung geprüft.
3. Schritt 3 – Transfer durchführen: Freigegebenes Medium, manipulationssichere Verpackung, Übergabeprotokoll und Quarantäneprüfung werden eingesetzt.
4. Schritt 4 – Lokale Bereitstellung prüfen: Registry, Paketspiegel und Artefaktablage werden auf Vollständigkeit, Zugriff und Wiederherstellbarkeit getestet.

Praxisbezug: Erstellung eines Artefaktmanifests und eines kontrollierten Transferprotokolls.

Wechseldatenträger und kontrollierter Datentransfer

Wechseldatenträger sind ein zentraler Angriffs- und Abflussweg und benötigen einen streng geregelten Lebenszyklus.

1. Schritt 1 – Medien zulassen: Freigegebene Typen, eindeutige Kennzeichnung, Eigentümer und zulässiger Zweck werden festgelegt.
2. Schritt 2 – Inhalt prüfen: Malwareprüfung, Dateitypen, Prüfsummen, Signaturen und Genehmigung werden vor dem Import kontrolliert.
3. Schritt 3 – Transfer protokollieren: Quelle, Ziel, Inhalt, Zeitpunkt, beteiligte Personen und Prüfergebnis werden dokumentiert.
4. Schritt 4 – Medium bereinigen: Sichere Löschung, Rückgabe, Quarantäne oder Vernichtung erfolgen nach definiertem Verfahren.

Praxisbezug: Durchspielen eines Import- und Exportprozesses mit Vier-Augen-Prinzip und Prüfsummen.

Betrieb ohne externe Abhängigkeiten

Offline-Betrieb erfordert lokale Ersatzdienste, angepasste Zeitplanung und ein belastbares Verfahren für Informationen und Updates.

1. Schritt 1 – Externe Abhängigkeiten finden: Lizenzprüfung, Telemetrie, Zeit, DNS, Zertifikatsprüfung, Images und Dokumentation werden auf Online-Zwang untersucht.
2. Schritt 2 – Lokale Alternativen bereitstellen: Interne NTP-, DNS-, PKI-, Registry-, Repository- und Wissensdienste werden geplant.
3. Schritt 3 – Informationsfluss organisieren: Sicherheitsmeldungen, Releaseinformationen und technische Dokumente werden kontrolliert in die Umgebung übertragen.
4. Schritt 4 – Notfallfähigkeit testen: Wiederanlauf, Zertifikatsablauf, Repository-Ausfall und fehlende Online-Dienste werden regelmäßig simuliert.

Praxisbezug: Bewertung einer Beispielplattform auf verdeckte Online-Abhängigkeiten und Definition lokaler Ersatzdienste.

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.

Tag 4: Schwachstellen, Incident und Compliance

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

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.

Sicherheitsvorfall und forensische Erstmaßnahmen

Bei Sicherheitsverdacht müssen Eindämmung, Beweissicherung und Wiederherstellung koordiniert werden, ohne Spuren unnötig zu verändern.

1. Schritt 1 – Verdacht qualifizieren: Quelle, betroffene Identität, Systeme, Zeitfenster und beobachtete Indikatoren werden dokumentiert.
2. Schritt 2 – Zugriff begrenzen: Konten, Tokens, Netzwerkpfade oder Workloads werden risikoorientiert isoliert, ohne unnötig Daten zu vernichten.
3. Schritt 3 – Beweise sichern: Logs, API-Aktivität, Konfigurationsstände, Snapshots und Zeitbezug werden kontrolliert gesammelt.
4. Schritt 4 – Wiederherstellung vorbereiten: Vertrauenswürdige Baseline, Schlüsselrotation, Neuaufbau und verstärktes Monitoring werden geplant.

Praxisbezug: Tabletop-Übung zu kompromittierten Administratorzugängen mit Eindämmungs- und Nachweisplan.

Compliance-Mapping und Kontrollkatalog

Technische und organisatorische Maßnahmen werden in einen prüfbaren Kontrollkatalog mit Verantwortlichkeit und Evidenz überführt.

1. Schritt 1 – Anforderungen zerlegen: Norm-, Gesetzes-, Kunden- oder interne Vorgaben werden in konkrete prüfbare Kontrollen übersetzt.
2. Schritt 2 – Kontrollen zuordnen: Identität, Härtung, Logging, Backup, Change, Incident und physische Sicherheit werden den Anforderungen zugeordnet.
3. Schritt 3 – Eigentümer benennen: Umsetzung, Betrieb, Überwachung und Nachweis erhalten klar getrennte Verantwortlichkeiten.
4. Schritt 4 – Prüfzyklus festlegen: Frequenz, Stichprobe, Methode, akzeptierte Abweichung und Nachbesserung werden definiert.

Praxisbezug: Aufbau einer Kontrollmatrix für Zugriffsschutz, Protokollierung, Patchen und Wiederherstellung.

Auditnachweise und revisionsfähige Dokumentation

Nachweise müssen aktuell, vollständig, manipulationsgeschützt und einer konkreten Kontrolle zuordenbar sein.

1. Schritt 1 – Evidenz definieren: Konfigurationsauszug, Protokoll, Ticket, Freigabe, Scanbericht oder Testergebnis wird je Kontrolle festgelegt.
2. Schritt 2 – Erzeugung standardisieren: Quelle, Zeitraum, Filter, Exportformat und verantwortliche Stelle werden reproduzierbar beschrieben.
3. Schritt 3 – Integrität sichern: Zeitstempel, Zugriffsschutz, Versionierung und gegebenenfalls Signatur schützen Nachweise vor Veränderung.
4. Schritt 4 – Abweichung verfolgen: Feststellung, Risiko, Maßnahme, Frist und Wirksamkeitsprüfung werden bis zum Abschluss nachgehalten.

Praxisbezug: Zusammenstellung eines kleinen Auditpakets für Berechtigungsprüfung, Patchstand und Restore-Test.

Tag 5: SCS, Interoperabilität und Souveränitä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.

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.

Praxislabor

• Erstellung eines kompakten Bedrohungsmodells mit Schutzwerten, Bedrohungen und priorisierten Kontrollen.
• Entwurf einer Schlüsselarchitektur für verschlüsselte Volumes und Dienstzertifikate.
• Entwurf einer Air-Gap-Zonenarchitektur mit Transfer- und Quarantänebereich.
• Entwicklung eines Offline-Updatepakets mit Manifest, Prüfsummen, Freigabe und Einspielreihenfolge.
• Erstellung einer Zuordnung zwischen Plattformfunktionen und SCS-Zielen.
• Entwicklung eines Anforderungskatalogs für eine souveräne On-Premises-Cloud.

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.