CHECKLISTE · EUROPÄISCHE CLOUD UND SOUVERÄNITÄT
Checkliste für die Migration in eine europäische Cloud und digitale Souveränität
Haken Sie diese Prüfungen der Reihe nach ab, von der Bestandsaufnahme bis zur Stilllegung, und hängen Sie jede Antwort an eine Datei. Ein Lauf von StackToIT schreibt eine Souveränitätsdatei, die 13 Dimensionen einer Umgebung festhält: In der AWS-Umgebung mit 13 Ressourcen hinter dieser Seite braucht eine Dimension Nachweise, zwei sind beobachtet und zehn bewertet die Engine gar nicht. Die nicht bewerteten sind kein Urteil, sondern Ihre Prüfungen. Souveränität ist eine Position, die Sie dokumentieren, und diese Liste zeigt, wo jeder Teil davon festgehalten ist.
Die 13 Dimensionen der Souveränitätsdatei und was jede schließt
Aus assurance/sovereignty.md eines Laufs vom 4. November 2026 mit zwei Anwendungen, die eine Souveränitätsstufe angeben. Die Zustände sind die Worte des Laufs.
| Dimension | Zustand im Lauf | Was sie schließt |
|---|---|---|
| Datenstandort | Nachweis erforderlich | Setzen Sie die STACKIT-Region bewusst; der Lauf nahm für die Preise eu01 an, weil keine Eingabe eine wählte. Halten Sie fest, wohin Backups und Replikate gehen. |
| Rechtskette (Jurisdiktion) | Nicht bewertet | Eine Frage nach Rechtssitz und rechtlichem Zugriff auf Anbieter, Eigentümer und Betreiber. Die Datei überlässt sie einer externen Klärung; halten Sie fest, wer sie beantwortet hat. |
| Betreiberzugriff | Nicht bewertet | Halten Sie fest, welches Personal des Anbieters oder von Unterauftragnehmern unter welchen Bedingungen Ressourcen und Daten erreichen kann. |
| Schlüsselkontrolle | Nicht bewertet | Halten Sie fest, wer die Schlüssel der Daten hält. Der Lauf hat in der Quelle keinen kundenverwalteten Schlüssel beobachtet; das spiegelt wider, was die Engine liest, und ist kein Beweis, dass keiner genutzt wird. |
| Identitätskette | Hier nicht bewertet; Entscheidung erforderlich, wo die Quelle Workload-Identitäten nennt | Entscheiden Sie, wie jeder Workload seine STACKIT-Identität bekommt (siehe den Identitätsleitfaden). |
| Telemetriekette | Nicht bewertet | Halten Sie fest, wohin Logs, Metriken und Traces gehen und wer das Ziel betreibt. |
| Backupkette | Nicht bewertet | Bestätigen Sie Zeitplan und Aufbewahrung, die der Entwurf schreibt, und den Ort der Backups. |
| Lieferkette | Beobachtet | Die Quell-Provider und die STACKIT-Provider-Version des Entwurfs sind aufgeführt; Registries, Build-Kette und Herkunft der Module sind Ihre Sache. |
| Verarbeitung durch Dritte | Nicht bewertet | Listen Sie jeden SaaS- und verwalteten Dienst auf, der die Daten berührt und nicht im Terraform steht. |
| Offene Schnittstellen | Nicht bewertet | Halten Sie fest, welche Schnittstellen, auf die Sie sich stützen, offene Standards sind und ob das STACKIT-Ziel sie beibehält. |
| Datenportabilität | Nicht bewertet | Halten Sie Exportformat und Pfad je zustandsbehafteter Einheit fest. |
| Anwendungskopplung | Nicht bewertet | Durchsuchen Sie den Anwendungscode nach SDKs und Protokollen der Quelle; die Engine liest Infrastruktur, keinen Code. |
| Ausstiegsfähigkeit | Beobachtet | Als einzige Tatsache steht, dass der Entwurf providerspezifisches Terraform ist. Schreiben Sie den Ausstiegspfad je Abhängigkeit selbst. |
Die Datei gibt an, dass sie technische Nachweise und Lücken dokumentiert, keine rechtliche Konformität bescheinigt und keine Punktzahl nennt. Souveränität ist nicht gleich Datenresidenz: Die Region eines Dienstes ist eine Tatsache über den Dienst, nicht über den Workload.
Woher die Anforderung kommt
Links: die Anwendung Billing, wie die Anwendungsdatei sie beschreibt. Rechts: der Abschnitt zur Anforderung in der Souveränitätsdatei.
business_criticality: critical
availability:
rto: 30m
rpo: 5m
downtime_tolerance: 15m
data:
classification: confidential
sovereignty:
tier: mandatory## Requirement
Sovereignty requirement: CUSTOMER INPUT.
The applications file states a sovereignty tier or constraints for the applications listed. They are quoted as written; no dimension below is judged against them in this build.
| Application | Sovereignty tier | Constraints |
|---|---|---|
| billing | mandatory | NOT_PROVIDED |
| shop | preferred | NOT_PROVIDED |Zitiert, wie geschrieben
Die Datei zeigt die Stufe jeder Anwendung, wie Sie sie geschrieben haben, und hält fest, dass in diesem Stand keine Dimension daran gemessen wird. Die Stufe ist eine Aufzeichnung, kein Testergebnis.
Jede Dimension zeigt weiter „nicht angegeben“
Die Einträge je Dimension unter dem Abschnitt zeigen die Anforderung als nicht angegeben, obwohl die Tabelle die Stufen nennt. Lesen Sie die Tabelle, nicht die Zeile je Dimension.
Die Klassifizierung reist mit den Daten
Die Datei zum Datenumzug wiederholt Klassifizierung, RPO und tolerierte Ausfallzeit neben jeder zustandsbehafteten Einheit: die Datenbank von Billing als confidential mit 5m und 15m.
Bestandsaufnahme
Allgemeine Praxis, an die Dateien eines Laufs gebunden. Anforderung klären und festlegen, wo das Werkzeug läuft.
Anwendungsdatei mit Stufe und Klassifizierung je Anwendung schreiben
Nutzen Sie die Stufenwerte, die die Datei akzeptiert, sowie Verantwortliche, RTO und RPO jeder Anwendung. Souveränitätsdatei und Datei zum Datenumzug wiederholen sie. Prüfen: applications.yaml, assurance/sovereignty.md.
Die Bewertung auf einem Rechner unter Ihrer Kontrolle ausführen, bei Bedarf offline
Die Dokumentation hält fest, dass assess die Quelle lokal liest, nichts hochlädt und im Offline-Modus keine ausgehenden Anfragen sendet. Prüfen: die Konsolenausgabe und die Betriebsnotizen, ein Vermerk zu Rechner und verwendeten Optionen.
Die zulässigen Regionen benennen
STACKIT dokumentiert zwei Regionen, eu01 in Deutschland und eu02 in Österreich, mit je mindestens drei Availability Zones, und gibt an, die Infrastruktur werde in eigenen Rechenzentren in Deutschland und Österreich betrieben. Prüfen: Seite zu den STACKIT-Regionen, Ihre Richtlinie.
Dienste ohne STACKIT-Gegenstück auflisten
Einheiten der Klassen REDESIGN, CONTAINERIZE oder MANUAL_REVIEW sind die Stellen, an denen eine Abhängigkeit außerhalb des Ziels bleiben oder neu gebaut werden kann. Prüfen: engineering/architect-report.md.
Entwurf
Die Dimensionen in Entscheidungen übersetzen.
Region in den Variablen setzen
Der Entwurf hat eine Regionsvariable, und der Lauf nahm für die Preise eu01 an, als keine gewählt war. Prüfen: terraform/variables.tf, die Souveränitätsdatei.
Namensauflösung entscheiden
Der Entwurf setzt für die Netzwerke standardmäßig die Adressen des STACKIT DNS Resolvers statt der öffentlichen Resolver 1.1.1.1, 8.8.8.8 und 9.9.9.9. Prüfen Sie seinen Status in der STACKIT-Dokumentation und behalten oder ändern Sie ihn. Prüfen: Souveränitätsdatei, Datenstandort.
Die Identität jedes Workloads entscheiden
Bilden Sie Maschinenidentitäten auf Service Accounts ab und wählen Sie die Rollen selbst; STACKIT dokumentiert, dass Service Accounts standardmäßig keinen Zugriff haben. Prüfen: assurance/identity-transition.md.
Anbieternachweise je Dienst sammeln
Der Lauf führt 10 Frameworks für die 7 STACKIT-Dienste seines Entwurfs, 70 Zeilen: 2 zeigen vorhandene Anbieternachweise, 3 verlangen eigene Kontrollen und 65 verlangen eine externe Prüfung des Anbieterdokuments. Prüfen: assurance/compliance-evidence.md; jede Zeile gilt 90 Tage ab ihrer Prüfung.
Aufbau
Den Entwurf übernehmen und anpassen, bevor etwas ausgerollt wird.
Provider-Versionen fixieren und per Lock-Datei festschreiben
Der Lauf markiert Quell-Provider ohne Eintrag in der Lock-Datei und schreibt den Entwurf für eine STACKIT-Provider-Version. Checken Sie Lock-Dateien ein. Prüfen: terraform/terraform.tf, der Provider-Hinweis im Bericht.
Den State schützen
Der Entwurf deklariert kein Backend, und der Provider schreibt Geheimnisse wie Datenbankpasswörter im Klartext in den State. Nutzen Sie ein verschlüsseltes Backend mit eingeschränktem Lesezugriff. Prüfen: terraform/README.md, Sicherheits-Checkliste.
Backup-Standardwerte bestätigen
Der Entwurf schreibt für PostgreSQL Flex einen täglichen Backup-Zeitplan um 02:00 Uhr und 32 Tage Aufbewahrung, weil die Quellwerte nicht sichtbar waren; 32 Tage sind das STACKIT-Minimum. Prüfen: terraform/data.tf.
Den Provider ohne langlebigen Schlüssel authentifizieren
Die README empfiehlt Workload Identity Federation statt eines Service-Account-Keys. Prüfen: terraform/README.md.
Daten
Daten mit einer selbst gewählten Methode übertragen und den Ausstieg offen halten.
Eine Methode je zustandsbehafteter Einheit wählen
Der Plan definiert die Methoden und wählt keine; das Verfahren steht auf unbekannt, bis Sie antworten. Prüfen: migration/data-movement.md.
Klassifizierung und RPO neben jeder Einheit festhalten
Sie stammen aus der Anwendungsdatei und gehen in den Umzugsplan ein. Prüfen: migration/data-movement.md.
Das Aufräumen der Kopien planen
Dump-Dateien, Schlüssellisten und der Zugriff des Umzugsrechners stehen als Aufräumschritte für die Zeit nach der Abnahme im Plan. Prüfen: die Aufräumschritte in execution-plan.json.
Offene Protokolle für den Ausstieg bevorzugen
Objektspeicher mit S3-API lässt sich mit den Werkzeugen hinaus kopieren, mit denen er hinein kopiert wurde. Prüfen: die Klasse jedes Buckets in assessment.json.
Cutover
Umschalten, entscheiden und die Quelle bis zur Entscheidung behalten.
Eine Resilienz-Absicht je Einheit wählen
Der Lauf hält RTO und RPO wie angegeben fest und lässt die Absicht je Einheit offen, weil er eine Architektur nicht gegen eine unbekannte Anforderung resilient nennt. Prüfen: assurance/resilience.md.
Umschaltung und Rollback proben
Eine GO-oder-ROLLBACK-Entscheidung steht vor der Stilllegung der Quelle. Prüfen: die Rollback-Entscheidung im Plan.
Den Cutover je Einstiegspunkt bestätigen
Jede Umschaltung nennt die Clients und Adressen, die sie ändert. Prüfen: die Cutover-Schritte in der Migrationsplan-Datei unter migration/.
Nachbereitung
Die Nachweise aktuell halten.
Den Lauf als Nachweis aufbewahren und prüfen
Bewahren Sie den Ordner des Laufs bei den Migrationsunterlagen auf und prüfen Sie ihn mit dem verify-Befehl, der ihn gegen sein Manifest prüft und die Artefakte auf Widersprüche untersucht. Führen Sie die Bewertung erneut aus, sobald sich die Quelle vor dem Cutover geändert hat. Prüfen: manifest.json.
Quellidentitäten, Schlüssel und Kopien stilllegen
Die Stilllegung folgt erst auf die GO-Entscheidung. Prüfen: die Stilllegungsschritte des Plans.
Die Nachweise des Anbieters erneut lesen
Die Compliance-Datei lässt eine Zeile 90 Tage ab ihrer Prüfung gelten. Prüfen Sie ihr Datum und die Fakten-Seite des Anbieters vor einem Audit erneut.
Fragen, die Compliance-Teams stellen
Bescheinigt StackToIT, dass eine Migration souverän ist?
Nein. Die Souveränitätsdatei hält fest, dass sie technische Nachweise und Lücken aufführt, keine Punktzahl nennt und rechtliche Schlüsse einer externen Klärung überlässt. Die Stufe, die Sie angeben, wird zitiert, wie sie geschrieben ist.
Warum sind so viele Dimensionen nicht bewertet?
Weil die Eingabe Infrastrukturcode ist. Rechtskette, Betreiberzugriff, Schlüsselbesitz, Telemetrie, Backups und Anwendungskopplung sind keine Tatsachen einer Terraform-Datei; deshalb sagt der Lauf „nicht bewertet“, statt zu raten.
Wo nennt STACKIT seine Standorte?
Die Fakten-Seite von STACKIT nennt 7 Rechenzentren in Deutschland und Österreich und sagt, die Infrastruktur werde ausschließlich in eigenen europäischen Rechenzentren dort betrieben. Die Regionen-Dokumentation nennt eu01 als Deutschland und eu02 als Österreich.
Deckt der Anbieternachweis meinen Workload ab?
Die Compliance-Datei sagt, Anbieternachweise beschreiben die eigenen Kontrollen des Anbieters und machen keinen Workload konform mit einem Framework. Ihre Kontrollen und eine externe Prüfung entscheiden das.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.