Cloud-Souveränität nach C3A: Open Source im IAM als Lösung?

Das BSI hat mit dem C3A erstmals definiert, was „digitale Souveränität“ im Cloud-Kontext wirklich bedeutet. Wer die sechs Kriterien liest, stellt fest: Open Source erfüllt die meisten davon strukturell – nicht als Versprechen, sondern als technische Eigenschaft. Doch ein detaillierter Blick ist notwendig.

„Souverän“ ist in der Cloud-Branche das neue „sicher“ – ein Begriff, den inzwischen fast jeder Anbieter für sich beansprucht, ohne dass er nachprüfbar war. Das hat sich geändert.

Am 27. April 2026 veröffentlichte das Bundesamt für Sicherheit in der Informationstechnik den Kriterienkatalog C3A – Criteria enabling CloudComputing Autonomy. Das Dokument ist nicht regulatorisch verpflichtend, aber es ist schnell zum Referenzrahmen geworden: für Vergabeverfahren, Risikobeurteilungen und strategische Cloud-Entscheidungen in Unternehmen und Behörden.

Bei genauerem Hinsehen wird deutlich: Die dort formulierten Anforderungen beschreiben nicht zufällig das, womit Open-Source-Lösungen strukturell punkten. Digitale Souveränität nicht über Zertifikate, sondern als Architekturprinzip.

Was der C3A misst – und warum Open Source strukturell antwortet

Der C3A ergänzt den bestehenden BSI-Katalog C5: Während C5 beantwortet, ob ein Cloud-Dienst technisch sicher ist, fragt C3A: Kann dieser Dienst auch selbstbestimmt genutzt werden? Ein hochsicheres System, das ich nicht verlassen, nicht einsehen und dessen Bedingungen ich nicht verhandeln kann, ist aus Souveränitätsperspektive eine Abhängigkeit – keine Lösung.

Der Katalog strukturiert diese Frage in sechs Bereiche, die sog. Sovereignty Objectives (SOV) – deutsch: Souveränitätsziele:

‍

 SOV-1: Strategische Souveränität: Unter welchem Recht operiert der Anbieter? Greift z. B. der US CLOUD  Act?

SOV-2: Datensouveränität: Kontrolle über Speicherort, Verarbeitung und Zugriff auf eigene Daten

SOV-3: Operationale Souveränität:  Kann der Betrieb des Dienstes eigenständig fortgeführt werden?

SOV-4: Technologische Souveränität: Offene Standards, Nachvollziehbarkeit, keine versteckten  Abhängigkeiten

SOV-5: Wirtschaftliche Souveränität: Gestaltungsspielraum bei Vertragskonditionen und Preismodellen

SOV-6: Personalwirtschaftliche Souveränität: Aufbau eigener Kompetenzen, kein reines Abhängigkeitsverhältnis

‍

Open Source löst diese Anforderungen nicht durch bessere Verträge, sondern durch Architektur. Einsehbarer Code, freie Wahl des Betreibers, offene Standards, wechselbare Anbieter – das sind keine Features, die nachträglich hinzugefügt werden können. Es ist eine Frage des Grundmodells. Proprietäre Lösungen können einzelne C3A-Kriterien durch Exit-Klauseln oder zertifizierte Betriebe erfüllen. Open Source ist keine Garantie für SOV-4, aber eine wesentliche Voraussetzung für eine vollständig unabhängige Auditierbarkeit. Geschlossener Quellcode schließt diese Form der Auditierbarkeit grundsätzlich aus.

Für Identity & Access Management (IAM)-Systeme gilt das im Besonderen. Authentifizierungsflüsse, Rollenvergaben und Zugangsdaten sind der Nervenstrang jeder Infrastruktur – wenn diese Schicht nicht transparent und portierbar ist, ist der gesamte Stack souveränitätskritisch.

Wo es im Betrieb konkret schwierig wird

Keycloak ist das meistgenutzte quelloffene IAM-Fundament und erfüllt strukturell, was C3A fordert: OpenID Connect, OAuth 2.1,SAML 2.0, Kubernetes-Operator, horizontale Skalierung. Aber der Teufel steckt im Betrieb – an sehr konkreten Stellen.

SOV-3 – Operationale Souveränität: Keycloak veröffentlicht rund zwanzig Updates pro Jahr, unterstützt dabei in der Regel nur die aktuelle Version. Prüfung, Freigabe und Rollout jedes Updates – inklusive Regressionstests und Rollback-Planung – müssen intern organisiert werden. Allein das entspricht in produktiven Umgebungen mindestens einer Vollzeitstelle. Die Infinispan-Konfiguration für Hochverfügbarkeit kommt obendrauf: Cache-Replikation und Session-Handling unter Last verlangen präzises Finetuning, Fehler zeigen sich erst, wenn es zu spät ist.

SOV-4 – Technologische Souveränität: Die enorme Konfigurationstiefe von Keycloak ist Stärke und Risiko zugleich, denn Keycloak ist von Entwicklern für Entwickler gebaut. Falsch konfigurierte Auth-Flows erzeugen MFA-Schlupflöcher; ein fehlerhafter Browser-Flow kann im schlimmsten Fall alle Nutzer aussperren. Souveränität im Sinne von SOV-4 ist nur gewährleistet, wenn die Konfiguration tatsächlich verstanden und dokumentiert ist – eine Keycloak-Instanz, die niemand im Haus vollständig überblickt, erfüllt das Kriterium nicht.

SOV-6 – Personalwirtschaftliche Souveränität: Keycloak bietet von Haus aus kein natives SCIM, keine automatisierten Lifecycle-Workflows für On- und Offboarding, keine Rezertifizierung und keine zeitlich begrenzte Rechtevergabe. Das Need-to-Know-Prinzip – DSGVO-Pflicht und C3A-Voraussetzung – lässt sich nur eingeschränkt umsetzen. Erweiterungen sind möglich, erzeugen aber ihrerseits Wartungsaufwand und Abhängigkeiten.

Das Praxis-Dilemma

Keycloak erfüllt die Souveränitätskriterien strukturell – aber eine selbst betriebene Instanz ist in der Enterprise-Praxis selten vollständig  gehärtet, konsistent gewartet und mit dem nötigen Funktionsumfang ausgestattet. Souveränität auf dem Papier ist keine Souveränität im Betrieb.

‍

Der Sweet Spot ist deshalb nicht „selbst betreiben oder proprietär kaufen“, sondern ein dritter Weg: ein Keycloak-Kern, der die strukturellen Souveränitätseigenschaften sichert, kombiniert mit Enterprise-Reife in Betrieb, Lifecycle-Management und Funktionsumfang. Commercial Open Source – die strukturelle Offenheit von Open Source, ohne den vollen operativen Aufwand. Nicht zu verwechseln mit einem reines Keycloak Hosting durch einen Drittanbieter, der die aktuelle Keycloak Version gehostet zu verfügung stellt. Denn das macht das Problem in der Regel nur noch größer, da man noch weniger eigene Kontrolle über die Software hat, aber dennoch die Verantwortung „der Community“ selbst tragen muss. Commercial Open Source geht weiter und bringt wichtige (Betriebs-)Erweiterungen und übernimmt die Verwantwortung für den Open Source Kern. Vollständig prüfbar.

Fazit

Der C3A ist kein Regulierungshammer. Er ist ein Spiegel – er macht sichtbar, was viele Organisationen spüren, aber selten messen konnten. Open Source ist die strukturelle Antwort auf seine Kriterien. Die entscheidende Frage ist nicht „Open Source oder nicht“, sondern: Ist der Open-Source-Kern auch enterprise-tauglich betrieben? Souveränität bedeutet nicht, alles selbst zu bauen. Sie bedeutet, keine strukturellen Abhängigkeiten einzugehen – und trotzdem professionell zu arbeiten.

Für Ihren nächsten Schritt

→    C3A-PDF des BSI herunterladen und intern diskutieren –vor allem die Bereiche SOV-3 und SOV-4

→    Identity- und Access-Management als erstes Prüffeld nehmen: Ist Ihr IAM portierbar und auditierbar?

→    Bei Ausschreibungen C3A-Konformität explizit als Kriterium aufnehmen

Dieser Beitrag basiert auf dem offiziellen BSI-Dokument C3A – Criteria enabling Cloud Computing Autonomy, veröffentlicht am 27. April 2026 unter Creative-Commons-Lizenz CC-BY-ND 4.0. Alle zitierten Kriterien entstammen dem englischsprachigen Original.

‍