cloud Funktionsbaustein: Cloud-Infrastrukturfeedback

Eigenschaft	Wert
Kennung	DArch-FBS-CLI
Hauptfähigkeit	Infrastruktur und IT-Betrieb
Geschäftsfähigkeit	Betriebsinfrastruktur
Version	0.2 (13.05.2026)
GovStack-Bezug	Cloud Infrastructure Building Block
Referenzplattform	Deutsche Verwaltungscloud (DVC)

summarize 1 Management Summaryfeedback

Der Baustein „Cloud-Infrastruktur" stellt eine Plattform bereit, auf der IaaS-, PaaS- und SaaS-Angebote für den Betrieb von Basis-, Querschnitts- und Fachanwendungen genutzt werden können. Die Bereitstellung von Betriebsleistungen erfolgt hochgradig automatisiert und zu großen Teilen über Virtualisierung in Software abgebildet. Behörden, die Cloud-Infrastruktur aufbauen oder beschaffen, müssen drei unterschiedlich verbindliche Regelwerke gleichzeitig beachten: BSI-Vorgaben (teilweise gesetzlich verbindlich), Deutschland-Stack-Architekturprinzipien (politisch verbindlich über IT-Rahmenplanung) und GovStack-Spezifikationen (internationale Referenz).

1.1 Wertversprechenfeedback

Die Deutsche Verwaltungscloud (DVC) bildet das souveräne Cloud-Fundament der öffentlichen Verwaltung in Deutschland. Mit den DVC-Betriebsplattformen und Basisdiensten entsteht eine gemeinsame Grundlage für eine einfache und schnelle Entwicklung sowie den sicheren Betrieb souveräner Cloud-Services.

1.2 Kundenerwartungenfeedback

• Hochverfügbare, skalierbare Betriebsumgebung für Anwendungen
• Einfache Administration über Self-Service-Portal
• BSI-Grundschutz-konforme Infrastruktur ohne eigenen Aufbau

1.3 Zielgruppenfeedback

Behörden und Institutionen aller Ebenen, die Anwendungen in einer souveränen Cloud-Umgebung betreiben oder betreiben lassen.

1.4 Betrieb und Finanzierungfeedback

Der Betrieb der Cloud-Infrastruktur erfolgt als föderiertes Modell mit zentraler Koordination. Das ITZBund betreibt die Bundescloud, govdigital koordiniert den DVC-Verbund aus kommunalen und landeseigenen Rechenzentren. Behörden beziehen Leistungen über Self-Service-Portale oder Rahmenverträge, ohne eigene Cloud-Infrastruktur vorhalten zu müssen.

Aspekt	Details
Betriebsszenario	Föderierter Multi-Cloud-Verbund: ITZBund (Bundescloud), govdigital (DVC-Verbund), landeseigene Rechenzentren. Koordination über DVC-Betriebsplattformen mit einheitlicher Governance.
Kostenstruktur	Plattformaufbau und Weiterentwicklung aus zentralem Bundeshaushalt (IT-Konsolidierung). Betriebskosten nutzungsbasiert über EVB-IT Cloud-Rahmenverträge. Open-Source-Basis (SCS) reduziert Lizenzkosten.
Finanzierungsmodell	Mischfinanzierung: zentrale Investitionsmittel für Plattformaufbau, nutzungsbasierte Umlagefinanzierung im laufenden Betrieb. EfA-Förderung für Stack-konforme Dienste.
Vertriebskanäle	DVC: Marktplatz Deutschland digital · VITD-Produktkatalog ITZBund · Portal der Deutschland-Architektur

1.5 Ansprechpartnerfeedback

Rolle	Organisation
Projektleitung	???
Fachverantwortung	???
Betriebsdienstleister	govdigital

1.6 Typische Szenarienfeedback

Verwaltungen bestellen Cloud-Ressourcen (Compute, Storage, Netzwerk), um Fachanwendungen betreiben zu lassen. Die Provisionierung erfolgt automatisiert über Self-Service-Portale oder Infrastructure-as-Code.

Status

Die DVC ist in Konzeption. Einzelne Cloud-Lösungen existieren (z. B. Bundescloud, ITZBund), sind jedoch noch nicht als Multi-Cloud-Plattform nutzbar.

description 2 Beschreibungfeedback

Der Baustein umfasst die drei Cloud-Service-Modelle Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Er adressiert die Bereitstellung virtualisierter Rechen-, Speicher- und Netzwerkressourcen, Laufzeitumgebungen und fertiger Anwendungen für die Bundesverwaltung. Die Deutsche Verwaltungscloud (DVC) ist die zentrale Referenzplattform des Bundes.

Der Baustein unterliegt drei Regelwerken mit unterschiedlicher Verbindlichkeit:

Regelwerk	Rechtsstatus	Hauptfokus
BSI (Mindeststandards + IT-Grundschutz)	Teilweise gesetzlich verbindlich (§ 44 BSIG)	Informationssicherheit
Deutschland-Stack	Politisch verbindlich über IT-Rahmenplanung und Vergabe	Nationale Architektur und Souveränität
GovStack	Freiwillige internationale Referenz	Wiederverwendbare Building Blocks

BSI-Mindeststandards nach § 44 Abs. 1 BSIG definieren ein verbindliches Mindestniveau für die Informationssicherheit. Sie gelten für Einrichtungen der Bundesverwaltung gemäß § 29 Abs. 1 BSIG sowie für Körperschaften, Anstalten und Stiftungen des öffentlichen Rechts auf Bundesebene. Der IT-Grundschutz ist formal eine Methodik, faktisch aber verbindlich für Bundesbehörden seit UP Bund 2021.

Der Deutschland-Stack ist die nationale souveräne Technologie-Plattform für die Digitalvorhaben in Deutschland. Er ist nicht direkt rechtsverbindlich, erzeugt Verbindlichkeit aber über IT-Rahmenplanung, EfA-Förderung (Einer-für-Alle), OZG-Umsetzung und Vergaberecht.

GovStack ist eine Initiative der Bundesregierung, der GIZ (Gesellschaft für Internationale Zusammenarbeit), der Regierung von Estland und der ITU (International Telecommunication Union). Die Spezifikationen sind formal freiwillig, gewinnen aber über die Integration in den D-Stack an Relevanz.

menu_book 3 Terminologiefeedback

Die folgende Tabelle definiert die zentralen Fachbegriffe des Bausteins. Die Terminologie orientiert sich an den BSI-Standards, der DVC-Strategie und den GovStack-Spezifikationen.

Begriff	Definition
IaaS	Infrastructure as a Service, Bereitstellung virtualisierter Rechen-, Speicher- und Netzwerkressourcen
PaaS	Platform as a Service, Bereitstellung von Laufzeitumgebungen, Datenbanken und Middleware
SaaS	Software as a Service, Bereitstellung fertiger Anwendungen für Endnutzende
DVC	Deutsche Verwaltungscloud, Multi-Cloud-Plattform des Bundes
ISMS	Informationssicherheits-Managementsystem gemäß BSI-Standard 200-1 / ISO 27001
C5	Cloud Computing Compliance Criteria Catalogue des BSI
SCS	Sovereign Cloud Stack, Open-Source-Referenzimplementierung auf Basis von OpenStack und Kubernetes
OSCAL	Open Security Controls Assessment Language (NIST), Format für maschinenlesbare Compliance-Profile
Landing Zone	Vorkonfigurierte Cloud-Umgebung mit eingebauter Governance (BSI-Grundschutz, Netzwerktrennung, IAM)
Multi-Tenancy	Mandantenfähigkeit mit strikter Trennung der Ressourcen und Daten
CTK	Compliance Test Kit, automatisierte Konformitätstests für GovStack Building Blocks

settings 4 Kernfunktionalitätenfeedback

Die Kernfunktionalitäten decken die Bereitstellung, den Betrieb und die Absicherung von Cloud-Ressourcen ab. Sie bilden die Grundlage für alle auf der Cloud-Infrastruktur gehosteten Dienste des Deutschland-Stacks.

4.1 Ressourcenbereitstellungfeedback

Compute, Storage und Netzwerk werden automatisiert provisioniert. Self-Service-Portale ermöglichen Mandanten die Bestellung von Ressourcen ohne manuelle Tickets. Infrastruktur-as-Code (IaC) über Terraform, OpenTofu oder Pulumi stellt reproduzierbare Umgebungen sicher.

Diese IaC-Werkzeuge nutzen Resource Provider (Ressourcenanbieter), die über APIs direkt mit den Cloud-Diensten kommunizieren. Ein Resource Provider übersetzt die deklarative Beschreibung einer Ressource (z. B. eine VM oder ein Kubernetes-Cluster) in konkrete API-Aufrufe gegen OpenStack, Kubernetes oder andere Plattformen. IaC ist ein zentraler Bestandteil von GitOps und wird über die CI/CD-Pipelines des Bausteins Entwicklung und Bereitstellung ausgerollt.

4.2 Mandantenfähigkeitfeedback

Multi-Tenancy mit strikter Trennung der Mandanten auf Netzwerk-, Compute- und Storage-Ebene ist Pflicht. Ressourcenkontingente und Quotierung verhindern, dass einzelne Mandanten die Plattform monopolisieren. Abrechnungsmodelle je Mandant ermöglichen verursachungsgerechte Kostenzuordnung.

4.3 Skalierbarkeit und Verfügbarkeitfeedback

Horizontale und vertikale Skalierung erfolgt automatisiert über Kubernetes Horizontal Pod Autoscaler oder Cloud-native Autoscaling-Gruppen. Hochverfügbarkeit wird durch Redundanz auf Rechenzentrumsebene sichergestellt. Geo-Redundanz und Disaster Recovery sind gemäß BSI-Standard 200-4 (BCMS) zu planen.

4.4 Container-Orchestrierungfeedback

Eine Kubernetes-basierte Container-Plattform bildet die PaaS-Schicht. Service Mesh (z. B. Istio) und Ingress-Management steuern den internen und externen Datenverkehr. CI/CD-Pipeline-Integration ermöglicht automatisierte Deployments über den Baustein Entwicklung und Bereitstellung.

shield 5 Querschnittsanforderungenfeedback

Die Querschnittsanforderungen leiten sich aus drei Regelwerken ab: BSI-Vorgaben (gesetzlich), D-Stack-Prinzipien (architektonisch) und GovStack-Spezifikationen (international). Sie gelten für alle Cloud-Dienste des Bausteins. Detaillierte Darstellungen der Sicherheitsvorgaben finden sich unter Sicherheit und Compliance und IT-Grundschutz und IT-Grundschutz++.

5.1 BSI-Vorgaben (gesetzliche Schicht)feedback

Das BSI veröffentlicht zwei Arten von Vorgaben mit unterschiedlicher Rechtswirkung. Mindeststandards nach § 44 Abs. 1 BSIG definieren ein verbindliches Mindestniveau, das nicht unterschritten werden darf. Der IT-Grundschutz (BSI-Standards 200-1 bis 200-4 und IT-Grundschutz-Kompendium) liefert die Methodik für ein ISMS.

BSI-Standard	Inhalt	Relevanz für Cloud
200-1	ISMS-Anforderungen, Aufgaben der Leitungsebene	Pflicht für jeden Cloud-Betreiber
200-2	Drei Absicherungsvarianten: Basis, Standard, Kern	Standard-Absicherung als Pflicht-Stufe für Behörden
200-3	Risikoanalyse	Bei hohem/sehr hohem Schutzbedarf (z. B. personenbezogene Daten)
200-4	Business Continuity Management (BCMS), ISO 22301	Disaster Recovery und Geo-Redundanz
C5	Cloud Computing Compliance Criteria Catalogue	Pflicht-Kriterienkatalog für Cloud-Anbieter der Verwaltung

Das IT-Grundschutz-Kompendium umfasst 113 Bausteine in 10 Schichten (ISMS, ORP, CON, OPS, DER, APP, SYS, IND, NET, INF). Für Cloud-Infrastruktur sind insbesondere die Schichten OPS (Betrieb), SYS (Systeme) und NET (Netze) relevant.

BSI-Standard 200-2 beschreibt drei Absicherungsvarianten mit unterschiedlichem Aufwand:

Variante	Zielgruppe	Zeitrahmen	Beschreibung
Basis-Absicherung	Schneller Einstieg, kleine Behörden	6–9 Monate	Mindestmaßnahmen für grundlegenden Schutz
Kern-Absicherung	Fokus auf kritische Assets	variabel	Schutz der wichtigsten Geschäftsprozesse und IT-Systeme
Standard-Absicherung	Vollständige ISMS-Umsetzung	9–15 Monate	Pflicht-Stufe für Behörden und Mittelstand

Die Standard-Absicherung ist für Cloud-Betreiber in der Bundesverwaltung die Regel. Bei hohem oder sehr hohem Schutzbedarf (z. B. personenbezogene Daten, VS-NfD) wird die Kern-Absicherung durch eine Risikoanalyse nach BSI 200-3 ergänzt.

IT-Grundschutz++ ist die für 2025/2026 modernisierte Variante: schlanker, risikobasierter und maschinenlesbar über OSCAL (Open Security Controls Assessment Language). Das Regelwerk wird gegenüber dem Kompendium geschärft, sodass es nur noch lösungsunabhängige Anforderungen an Zielobjekte beschreibt. Die Umsetzung soll nach dem Stand der Technik erfolgen. OSCAL macht ISMS-Prüfungen scriptbar, sodass automatisierte Prüfungen gegen reale Konfigurationen möglich werden. Details beschreibt die Seite IT-Grundschutz und IT-Grundschutz++.

Die für Cloud relevanten Technischen Richtlinien des BSI:

TR	Inhalt
TR-02102-1	Kryptographische Verfahren und Schlüssellängen
TR-02103	X.509-Zertifikate, CRL/OCSP
TR-03107-1	Ende-zu-Ende-Verschlüsselung für Verwaltungsverfahren
TR-03116-4	Schlüsselverwaltung für eGov
TR-03124	eID-Client (Online-Ausweisfunktion / nPA)

Diese TRs konkretisieren, was „Stand der Technik" für Behörden bedeutet.

Geltungsbereich: Praktisch alle Bundesbehörden sind seit UP Bund 2021 gebunden. Die meisten Landesverwaltungen folgen über Landesgesetze (z. B. Sächsisches Informationssicherheitsgesetz). Für Kommunen entsteht die Pflicht über Landesrecht und die NIS2-Umsetzung. KRITIS-Betreiber unterliegen eigenen BSI-Meldepflichten.

5.2 Deutschland-Stack-Prinzipien (architektonische Schicht)feedback

Das BMDS definiert acht Gestaltungsprinzipien, die für Cloud-Infrastruktur zu konkreten Architekturvorgaben werden:

Prinzip	Auswirkung auf Cloud-Infrastruktur
Technisches Fundament	Wiederverwendbare, modulare Bausteine auf Basis offener Standards
Offene Standards und Open-Source	SCS (Sovereign Cloud Stack) als Referenz, OpenStack und Kubernetes als Basis
Interoperabilität	Standardisierte APIs, Portabilität zwischen DVC-Betreibern
Europäische Souveränität	Datenhaltung in deutschen Rechenzentren, keine Abhängigkeit von außereuropäischen Hyperscalern
Effizienzsteigerung	Einheitliche, interoperable Systeme für medienbruchfreie Abläufe
Stärkung der Digitalwirtschaft	Ökosystem der offenen Innovation für Cloud-Anbieter
Konsolidierung	DVC als zentrales Angebot statt behördeneigener Insellösungen
Integration bestehender Ansätze	GovStack, Euro-Stack und Interoperable Europe werden integriert

Der achte Punkt ist für die Einordnung entscheidend: Der D-Stack subsumiert GovStack, statt parallel dazu zu existieren.

Verbindlichkeit entsteht über vier Hebel: IT-Rahmenplanung des Bundes (D-Stack-Konformität als Bewertungskriterium), EfA-Förderung (nur für Stack-konforme Dienste), OZG-Umsetzung (BundID-Integration als Pflicht) und Vergaberecht (EVB-IT Cloud mit Souveränitätskriterien).

Die heute identifizierbaren Basiskomponenten des D-Stacks. Der Bund stellt diese Dienste erstmals selbst bereit, damit Länder und Kommunen sie nachnutzen können:

Bereich	Komponente	Funktion
Infrastruktur	DVC, SCS	Multi-Cloud-Plattform, Open-Source-Referenzimplementierung
Identität	BundID → DeutschlandID, EUDI-Wallet (ab 2026)	Zentrale digitale Identität
IAM	Identity-Access-Management (SID)	Zugriffsteuerung für Cloud-Dienste
Zustellung	FIT-Connect, Bundespostfach	Sichere Antragsübermittlung
Register	NOOTS, Registermodernisierung	Once-Only-Prinzip
Verzeichnisse	PVOG, DVDV	Routing und Behördenverzeichnis
Datenmodelle	FIM	Semantische Standardisierung
Portal	Bundesportal	Zentraler Zugang für Bürgerinnen und Bürger

Verbindliche Vorgaben für zentrale Komponenten wie die BundID gelten vor allem im Kontext des OZG. Für die Einbindung in Fachverfahren existieren bislang keine vergleichbaren Regelungen. Die Architekturprinzipien stehen, die normative Tiefe für Fachverfahren fehlt noch.

5.3 GovStack-Anforderungen (internationale Schicht)feedback

Damit eine Komponente als GovStack-konform gilt, muss sie vier Kriterien erfüllen:

Kriterium	Bedeutung
Autonomous	Eigenständiger, wiederverwendbarer Dienst oder Dienstverbund
Generic	Flexibel über Anwendungsfälle und Sektoren hinweg einsetzbar
Interoperable	Kombinierbar und vernetzbar mit anderen Building Blocks
Iterative Evolvability	Weiterentwickelbar im laufenden Betrieb

Die neun grundlegenden Building Blocks sind: Identity Verification, Payments, Consent, Digital Registries, Messaging, Information Mediation, Registration, Scheduler und Workflow. Mit GovSpecs 2.0 (2025–2027) erweitert GovStack den Katalog und ergänzt Service-Design-Guides und AI-Readiness-Features.

Kommunikation zwischen Building Blocks und Anwendungen erfolgt ausschließlich über offene APIs. Ziel ist ein zentrales API-Gateway als sicherer und einheitlicher Zugangspunkt für alle Endpunkte.

GovStack verwendet RFC-2119-Schreibweise (MUST / SHOULD / MAY) für technische Pflichtstandards:

Anforderung	Verbindlichkeit
Alle Service-APIs als OpenAPI-3.1-Spezifikation	MUST
Datenmodelle als JSON Schema	MUST
Compliance Test Kit (CTK) für jedes Building Block	MUST
JSON Schemas und OpenAPI-Templates in Git	MUST
Diagramme in textbasiertem Format (Mermaid/PlantUML)	MUST
API-Gateway als zentraler Zugangspunkt	MUST
RBAC für alle Zugriffe	MUST

5.4 Information Mediatorfeedback

Das Information-Mediator-Konzept basiert auf der estnischen X-Road und definiert einen zentralen Vermittlerdienst. Ein zentraler Betreiber übernimmt den Betrieb des Gesamtsystems. Richtlinien und vertragliche Vereinbarungen für das Onboarding werden erstellt, Vertrauensdienste (Trust Services) intern aufgebaut oder von Dritten beschafft. Zeitstempelstellen müssen gemäß Spezifikation gebündeltes Zeitstempeln (Batched Time Stamping) unterstützen.

Die Service Registry ermöglicht es Building Blocks, ihre Dienste zu registrieren, und anderen Building Blocks, diese Dienste zu finden und zu konsumieren. In Deutschland übernehmen drei Komponenten gemeinsam die Rolle des Information Mediator: FIT-Connect (Zustellung), DVDV (Verzeichnis) und PVOG (Routing).

GovStack spezifiziert keine konkreten Algorithmen, sondern verweist auf „Stand der Technik". Die algorithmische Konkretisierung erfolgt über die BSI-Richtlinien (TR-02102-1). Die Spezifikationen sind formal nicht bindend, gewinnen Verbindlichkeit aber über die Integration in den D-Stack und über EU-Kompatibilität, weil GovSpecs eIDAS- und DSGVO-Konformität unterstützen.

5.5 Sicherheitsanforderungen für Cloud-Betriebfeedback

Die folgende Tabelle vergleicht die drei Regelwerke über alle relevanten Aspekte:

Aspekt	BSI	Deutschland-Stack	GovStack
Rechtsstatus	Mindeststandards: § 44 BSIG; Grundschutz: UP-Bund-verbindlich	Politisch, über IT-Rahmenplanung und Vergabe	Freiwillig, Referenzcharakter
Hauptzielgruppe	Alle Behörden (Bund/Land/Kommune) + KRITIS	Bund, Länder, Kommunen	LMICs international + EU-Stacks
Fokus	Informationssicherheit	Nationale Architektur und Souveränität	Wiederverwendbare Building Blocks
Normative Tiefe	Sehr hoch (113 Bausteine + TRs)	Gering (Prinzipien + Basiskomponenten)	Mittel (Specs + APIs + CTKs)
Maschinenlesbarkeit	Grundschutz++ (OSCAL)	Im Aufbau	OpenAPI 3.1 + JSON Schema + CTK
Sicherheitsstandards	TR-02102, TR-03107, ISO 27001, BSI 200-x	Erbt von BSI	RBAC, IAM-Suite, API-Gateway, Cross-Cutting Requirements
Verschlüsselung	TR-02102-1 (TLS 1.3, RSA-OAEP-256, AES-GCM)	Erbt von BSI	„Stand der Technik"
Datenmodelle	FIM (über IT-Planungsrat)	FIM als Stack-Komponente	JSON Schema, OpenAPI 3.1
Identität	TR-03124 (nPA)	BundID / DeutschlandID + EUDI-Wallet	Identity Building Block (eIDAS-kompatibel)
BCM / Resilienz	BSI 200-4 (Pflicht)	Nicht spezifisch	Implizit in NFRs
C5-Konformität	BSI C5 Pflicht-Kriterienkatalog	Pflicht für Cloud-Anbieter	Nicht spezifiziert
Zero Trust	Zero-Trust-Eckpunkte	Architekturprinzip	Implizit

5.6 Architektur-Rahmenwerkefeedback

Die Querschnittsanforderungen werden durch fünf Architektur-Rahmenwerke operationalisiert. Diese Rahmenwerke übersetzen die normativen Vorgaben in konkrete Entwurfsmuster und Vorgehensmodelle für den Aufbau und Betrieb von Cloud-Diensten.

Zero-Trust-Architektur definiert das Sicherheitsparadigma für alle Cloud-Dienste des Bausteins. Kein Zugriff wird implizit als vertrauenswürdig behandelt. Stattdessen erfolgt eine kontinuierliche Verifikation aller Identitäten, Geräte und Workloads nach dem Prinzip „Never trust, always verify". Die regulatorischen Vorgaben des Bundes sind in den Zero-Trust-Eckpunkten festgelegt, die technische Umsetzung erfolgt über die sechs Säulen Identity, Devices, Networks, Applications, Data und Visibility.

Cloud Adoption Framework (CAF) beschreibt den strukturierten Weg von der Cloud-Strategie über Migration bis zum produktiven Betrieb. Die sechs Phasen Strategie, Planung, Landing Zone, Migration, Governance und Optimierung bilden einen iterativen Kreislauf. Das CAF operationalisiert die organisatorische Transformation für Behörden, die Cloud-Infrastruktur aufbauen oder beschaffen.

Well-Architected Framework (WAF) bewertet Cloud-Workloads entlang von fünf Qualitätssäulen: Sicherheit, Betriebsexzellenz, Zuverlässigkeit, Leistungseffizienz und Kostenoptimierung. Jeder D-Stack-Baustein sollte gegen diese Säulen bewertet werden. Das WAF liefert die ingenieursmäßige Blaupause, um die BSI-Anforderungen in konkrete Architekturentscheidungen zu überführen.

Cloud-Native-Architektur beschreibt die Referenzarchitektur für Anwendungen, die auf der Cloud-Infrastruktur betrieben werden. Containerisierung mit Docker, Orchestrierung mit Kubernetes und CI/CD-Pipelines bilden das technische Fundament. Der Ansatz ermöglicht kürzere Release-Zyklen, bessere Skalierbarkeit und resilientere Architekturen als klassische monolithische Systeme.

Microservices-Architektur beschreibt den Blueprint für den Bau verteilter Systeme im Verwaltungskontext. Fachliche Funktionen werden in eigenständige Dienste aufgeteilt, die über APIs und Message Buses kommunizieren. Dieser Ansatz erleichtert die schrittweise Modernisierung monolithischer Fachanwendungen und erlaubt eine unabhängige Skalierung einzelner Fachdomänen.

checklist 6 Funktionale Anforderungenfeedback

Die funktionalen Anforderungen beschreiben die Leistungsmerkmale, die der Baustein im Kontext des Deutschland-Stacks bereitstellen muss. Sie leiten sich aus den DVC-Anforderungen, dem BSI C5 und dem GovStack Cloud Infrastructure Building Block ab.

Anforderung	Beschreibung	Priorität
IaaS-Bereitstellung	Automatisierte Provisionierung von Compute, Storage und Netzwerk über Self-Service	REQUIRED
PaaS-Bereitstellung	Kubernetes-basierte Container-Plattform mit Service Mesh	REQUIRED
Multi-Tenancy	Strikte Mandantentrennung auf Netzwerk-, Compute- und Storage-Ebene	REQUIRED
C5-Konformität	Einhaltung des BSI C5-Kriterienkatalogs	REQUIRED
Souveräne Datenhaltung	Betrieb in deutschen Rechenzentren, keine außereuropäischen Zugriffe	REQUIRED
Infrastructure as Code	Terraform/OpenTofu-Unterstützung für reproduzierbare Umgebungen	REQUIRED
Landing Zones	Vorkonfigurierte Governance-Umgebungen mit BSI-Grundschutz und IAM	RECOMMENDED
SCS-Kompatibilität	Kompatibilität mit Sovereign Cloud Stack für Portabilität	RECOMMENDED
OSCAL-Export	Export von Compliance-Profilen im OSCAL-Format (Grundschutz++)	GEPLANT
GovStack-CTK	Compliance Test Kit für Cloud Infrastructure Building Block	GEPLANT

database 7 Datenstrukturenfeedback

Der Baustein verwaltet Infrastrukturressourcen, Mandantenkonfigurationen und Compliance-Nachweise. Die Datenhaltung erfolgt über die Cloud-Management-Schicht (z. B. OpenStack, Kubernetes API).

Entität	Attribute	Speicherort
Mandant (Tenant)	Tenant-ID, Name, Kontingente, Abrechnungsmodell, Organisationseinheit	Cloud-Management-DB
Ressource	Ressource-ID, Typ (Compute/Storage/Network), Status, Mandant-Ref	IaaS-Orchestrator
Workload	Namespace, Deployment, Pods, Resource Limits	Kubernetes API
Compliance-Profil	OSCAL-Profil, BSI-Bausteine, C5-Kriterien, Prüfstatus	Compliance-Store
Audit-Event	Timestamp, Actor, Action, Ressource-Ref, Result	SIEM / Event-Store

api 8 Service-Schnittstellenfeedback

Die Service-Schnittstellen ermöglichen die Provisionierung und Verwaltung von Cloud-Ressourcen. Sie folgen den GovStack-Vorgaben (OpenAPI 3.1) und den DVC-Interoperabilitätsanforderungen.

IaC-Werkzeuge wie Terraform, OpenTofu und Pulumi greifen über Resource Provider auf dieselben Cloud-APIs zu. Resource Provider abstrahieren die plattformspezifischen API-Aufrufe, sodass Infrastruktur deklarativ beschrieben und versioniert in Git verwaltet werden kann. Diese Schnittstellen bilden die Grundlage für GitOps-Workflows, in denen Infrastrukturänderungen denselben Review- und Deployment-Prozess durchlaufen wie Anwendungscode im Baustein Entwicklung und Bereitstellung.

API	Zweck	Standard
OpenStack API	IaaS-Provisionierung (Compute, Storage, Network)	OpenStack API
Kubernetes API	Container-Orchestrierung und Workload-Management	Kubernetes API v1
Terraform / OpenTofu Provider	IaC-Resource-Provider für Cloud-Dienste	OpenTofu Registry
Pulumi Provider	IaC-Resource-Provider in TypeScript, Python, Go, C#	Pulumi Registry
OIDC / OAuth 2.0	Authentifizierung und Autorisierung	RFC 6749, OpenID Connect
Prometheus / OpenTelemetry	Monitoring und Observability	OpenTelemetry

account_tree 9 Interne Workflowsfeedback

Der Baustein ist in die Betriebs- und Sicherheitsinfrastruktur des Deutschland-Stacks eingebettet. Die folgenden Abhängigkeiten zeigen die Einbettung in das Gesamtsystem.

Abhängigkeiten im Deutschland-Stack:

• Identity-Access-Management (SID): OIDC-basierte Authentifizierung und RBAC für alle Cloud-Zugriffe
• Zero-Trust-Governance: Policy Enforcement auf Netzwerk- und Workload-Ebene
• PKI: TLS-Zertifikate für Verschlüsselung in Transit
• Detektion und Reaktion: SIEM-Anbindung und SOC-Integration
• Entwicklung und Bereitstellung: CI/CD-Pipelines für automatisierte Deployments

9.1 Vorgehen für Behördenfeedback

Behörden, die Cloud-Infrastruktur aufbauen oder beschaffen, sollten in drei Schritten vorgehen:

Schritt 1: BSI-Pflicht erfüllen. Schutzbedarfsfeststellung nach BSI 200-2, ISMS aufbauen nach 200-1, Standard-Absicherung mit Grundschutz-Bausteinen umsetzen. Bei hohem Schutzbedarf zusätzliche Risikoanalyse nach 200-3. BCMS nach 200-4 planen. Kryptographie strikt nach TR-02102-1. Cloud-Anbieter müssen C5 erfüllen.

Schritt 2: D-Stack-Komponenten nutzen. Cloud-Betrieb gegen DVC und SCS prüfen. IAM über den Baustein Identity-Access-Management (SID) anbinden. Offene Standards und Open-Source bevorzugen. Landing Zones mit BSI-Grundschutz-Governance einrichten.

Schritt 3: GovStack-Anschlussfähigkeit sicherstellen. APIs in OpenAPI 3.1 spezifizieren, Datenmodelle als JSON Schema, Infrastrukturcode in Git. Architektur entlang der Building-Block-Logik denken. API-Gateway als zentralen Zugangspunkt einrichten.

library_books 10 Weiterführende Informationen und Quellenfeedback

Dieser Abschnitt bündelt die normativen Quellen und verwandten Seiten. Die BSI-Vorgaben und D-Stack-Prinzipien werden auf den Vorgaben-Seiten vertieft, die hier verlinkt sind.

10.1 BSI-Quellenfeedback

• BSI IT-Grundschutz
• BSI Mindeststandards
• BSI Technische Richtlinien
• BSI C5-Kriterienkatalog

10.2 D-Stack und DVCfeedback

• Deutschland-Stack (BMDS)
• Deutsche Verwaltungscloud-Strategie (DVS)
• Sovereign Cloud Stack (SCS)

10.3 GovStackfeedback

• GovStack Specifications
• GovStack Cloud Infrastructure Building Block
• GovSpecs 2.0 Strategy 2025–2027

10.4 Verwandte Seiten im Portalfeedback

• Sicherheit und Compliance – Übersicht aller Sicherheitsvorgaben
• IT-Grundschutz und IT-Grundschutz++ – BSI-Standards 200-x, Kompendium, OSCAL
• Zero-Trust-Eckpunkte – Zero-Trust-Architektur des Bundes
• Digitale Souveränität – Souveränitätsanforderungen und Anwendungsfälle
• Nationale IT-Architekturrichtlinie – IT-Rahmenplanung und Landing Zones
• Rechtlich-organisatorischer Rahmen – eIDAS, OZG, DSGVO

10.5 Architektur-Rahmenwerkefeedback

• Zero-Trust-Architektur – Sicherheitsparadigma für Cloud-Dienste
• Cloud Adoption Framework – Adoptionsprozess von Strategie bis Betrieb
• Well-Architected Framework – Qualitätssäulen für Cloud-Workloads
• Cloud-Native-Architektur – Containerisierung, Kubernetes und CI/CD
• Microservices-Architektur – Verteilte Systeme und Domain-Driven Design

10.6 Verwandte Bausteinefeedback

• Identity-Access-Management (SID) – IAM für Cloud-Zugriffe
• Zero-Trust-Governance – Policy Enforcement
• PKI – Zertifikate für TLS und mTLS
• Detektion und Reaktion – SIEM und SOC
• Entwicklung und Bereitstellung – CI/CD-Pipelines
• Digitale Brieftasche (DBT) – EUDI-Wallet für Cloud-Identitäten
• Nutzerkonto (BundID) – Zentrale digitale Identität
• Nachweisdatenabruf (NOOTS) – Once-Only-Registerzugriff
• Datenaustausch (FIT-Connect) – Sichere Datenübermittlung
• Netze – Netzinfrastruktur der Verwaltung
• IT-Service-Management – ITSM-Prozesse
• Integrationsplattform – Middleware und Servicebus