Behörden und öffentliche Einrichtungen modernisieren IT unter besonderen Rahmenbedingungen: Datenschutz, Datensouveränität, formale Beschaffung, lange Lebenszyklen und hohe Anforderungen an Nachvollziehbarkeit. Gleichzeitig steigt der Druck, Fachverfahren zu digitalisieren, Schnittstellen zu öffnen und stabile Online-Dienste bereitzustellen.

In diesem Beitrag geht es um praxistaugliche Architektur- und Betriebsansätze für Public Sector IT: von BSI IT‑Grundschutz über souveräne Cloud/On‑Prem bis hin zu DevOps- und Plattform-Standards, die auditierbar und langfristig betreibbar sind.

Rahmenbedingungen im Public Sector: was den Unterschied macht

Datensouveränität und internationale Datenflüsse

Je nach Schutzbedarf sind Anforderungen an Datenlokation, Zugriffsmöglichkeiten und Vertragsklauseln zentral. Praktisch relevant sind u. a.:

DSGVO-konforme Verarbeitung und Auftragsverarbeitung,

Datenhaltung in Deutschland/EU und klare Betreiber-/Subunternehmerketten,

Risikobewertung internationaler Datenzugriffe (Schrems II).

BSI IT‑Grundschutz und Schutzbedarfsorientierung

Der BSI IT‑Grundschutz ist häufig die Leitplanke für Sicherheitsmaßnahmen:

BSI IT‑Grundschutz: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html

Wichtig ist der praktische Transfer: Schutzbedarf ermitteln, Bausteine ableiten, Maßnahmen priorisieren, Evidenzen erzeugen (Dokumentation, Protokolle, Tests).

Vergabe, EVB‑IT und Planbarkeit

Public Sector Projekte brauchen klare Leistungszuschnitte und nachvollziehbare Deliverables. EVB‑IT spielt dabei häufig eine Rolle:

EVB‑IT: https://www.cio.bund.de/Web/DE/IT-Beschaffung/EVB-IT-und-BVB/evb-it-und-bvb_node.html

Erfolgsfaktor: technische Roadmap so strukturieren, dass sie in Vergabelose, Milestones und nachweisbare Arbeitspakete passt – ohne die Architektur zu fragmentieren.

Open Source als Strategie (nicht als Dogma)

Open Source wird oft bevorzugt: Transparenz, geringerer Lock-in, langfristige Wartbarkeit. Entscheidend ist aber das Betriebsmodell: Updates, Security Advisories, Ownership und Support müssen geregelt sein.

Souveräne Cloud, Private Cloud und Hybrid: sinnvolle Zielbilder

„Souverän“ bedeutet nicht automatisch „On-Prem“. Häufig ist ein hybrides Zielbild sinnvoll, das Schutzbedarf und Betriebsrealität verbindet.

Private Cloud / On‑Prem Plattformen

Geeignet bei hohem Schutzbedarf, Abhängigkeit von Spezialhardware oder wenn Daten/Netze strikt segmentiert sein müssen:

Virtualisierung/Private Cloud (z. B. VMware/OpenStack),

Kubernetes/Plattformbetrieb im eigenen Rechenzentrum,

klare Automatisierung (Provisionierung, Patching, Backups).

Der Betrieb wird deutlich robuster, wenn Infrastruktur reproduzierbar ist:

Infrastructure as Code

Rechenzentrum & Datacenter

Souveräne Anbieter und Managed Plattformen

Für viele Workloads sind souveräne Provider oder deutsche Rechenzentren ein guter Kompromiss – sofern Betreiberkette, Verträge, Logging und Zugriffskontrollen sauber geregelt sind. Wichtig ist weniger der Name als:

Datenlokation und Subunternehmertransparenz,

IAM/Key Management,

Nachweisbarkeit (Audit-Logs, Reports),

Exit-Strategie und Portabilität.

Hybrid als Praxisstandard

Typisches Muster: Fachverfahren und besonders schützenswerte Daten bleiben On‑Prem; weniger kritische Workloads (Portale, Kollaboration, Analyse) laufen in einer souveränen Cloud. Entscheidend ist eine saubere Integration: Identitäten, Netz, Logging, Monitoring, Backup/Restore.

Security & Compliance: so wird es umsetzbar

Secure Development Lifecycle und Change Safety

Security entsteht nicht erst beim Pen-Test, sondern im Engineering-Prozess:

Code Reviews und Quality Gates,

Dependency-/Vulnerability-Scanning,

IaC/Policy Checks,

nachvollziehbare Freigaben und Deployments.

Das passt thematisch zu:

Security & Compliance Beratung

CI/CD-Pipeline-Aufbau

VS‑Umgebungen und Netzsegmentierung

Bei VS‑NfD und höher werden Separation und kontrollierte Datenflüsse zentral: getrennte Netze, strengere Zugriffsmodelle, zusätzliche Freigaben, dokumentierte Betriebsprozesse. Hier lohnt es sich, Standards (z. B. Baselines) früh festzuzurren, damit Projekte nicht in Sonderfällen ertrinken.

Betrieb: Observability, Runbooks, Patch- und Incident-Prozesse

Langfristige Betreibbarkeit ist im Public Sector besonders wichtig, weil Systeme oft über Jahre wachsen. Bewährte Bausteine:

zentrales Monitoring/Logging und definierte Alarmierung,

Runbooks und Übergaben als Standard (Wissenssicherung),

planbares Patch- und Wartungsmodell,

Incident-Prozess mit Rollen und Kommunikationswegen.

Weiterführend:

Monitoring & Observability

Dokumentation & Runbooks

Wartung & Patch Management

SLA, SLO & Incident Response

Typische Projekte und realistische Quick Wins

Häufige Projektmuster

Plattform-/Kubernetes-Betrieb im Rechenzentrum mit standardisiertem Deployment

Migration einzelner Dienste in eine souveräne Cloud (hybrid, schrittweise)

Grundschutz-orientierte Gap-Analyse mit Maßnahmenplan und Nachweisführung

Aufbau von CI/CD und IaC unter formalen Change- und Freigabeprozessen

Quick Wins (ohne „Großprojekt“)

Standard-Baseline (Hardening, Logging, Monitoring-Agent) automatisiert ausrollen

Git als verbindlicher Change-Kanal (kein „Hotfix per Hand“)

zentrales Logging inkl. Retention und Zugriffskonzept

Runbooks für die kritischsten Services

Open Source und Beschaffung: Governance ist Teil der Technik

Open Source ist im Public Sector häufig strategisch gewünscht, bringt aber operative Pflichten mit sich. Damit „Open Source“ nicht zu einem Support‑Risiko wird, sind diese Punkte praxiserprobt:

Komponentenübersicht: Welche Libraries/Images sind im Einsatz (SBOM), welche Versionen, welche Update‑Quelle?

Patch-/Update‑Prozess: definierte Zyklen und Verantwortlichkeiten (inkl. EOL‑Behandlung).

Lizenz- und Security‑Bewertung: keine ad‑hoc Einbindung unbekannter Komponenten ohne Review.

Beschaffungsfähigkeit: Für kritische Bausteine (z. B. Plattform, Monitoring, CI/CD) ist geklärt, wie Support, Betrieb und SLA‑Themen abgedeckt werden.

Gerade in Umgebungen mit langen Laufzeiten ist diese Governance entscheidend, um Standardisierung und Nachhaltigkeit zu sichern.

FAQ

Was bedeutet „souveräne Cloud“ in der Praxis?

Nicht nur Datenlokation, sondern auch Betreiberkette, Zugriffsmöglichkeiten, Audit‑Logs und Exit‑Fähigkeit. Souveränität entsteht durch Verträge, technische Controls und ein belastbares Betriebsmodell.

Passt Open Source zu Vergabe- und Supportanforderungen?

Ja, wenn Support/Ownership klar geregelt sind: Versionsstrategie, Patch‑Prozess, Lizenzprüfung und ggf. kommerzieller Support für kritische Komponenten. Ohne Governance wird Open Source sonst zum Betriebsrisiko.

Wie startet man ohne großes Transformationsprojekt?

Mit einer Baseline: automatisiertes Hardening, zentrales Logging/Monitoring, Runbooks und ein klarer Change‑Kanal (Git/PR). Das schafft schnell Betreibbarkeit und reduziert Risiken.

Fazit

Public Sector IT ist erfolgreich, wenn Datensouveränität, Sicherheit und Beschaffungsrealität in ein betreibbares Zielbild übersetzt werden. Mit klaren Standards (Grundschutz-orientiert), reproduzierbarer Infrastruktur, sauberem Betriebsmodell und integrierten Controls wird Modernisierung planbar – ohne Sicherheit oder Nachvollziehbarkeit zu kompromittieren.

IT für Behörden & Public Sector