Community Cloud im Enterprise-Einsatz: BSI C5, Kooperative RZs und TCO für Verbünde

Die Infrastrukturstrategie regulierter Unternehmen und öffentlicher Träger in Europa steht vor einer tiefgreifenden Bewährungsprobe. Auf der einen Seite drängen Fachabteilungen auf elastische Bereitstellungsmodelle, automatisierte Kubernetes-Plattformen und hochverfügbare Datenräume. Auf der anderen Seite verschärfen Aufsichtsbehörden unter dem Regime von NIS-2, der Finanzmarktverordnung DORA und dem BSI IT-Grundschutz die Anforderungen an Datenlokalität, Drittparteien-Kontrolle und nachweisbare Ausstiegsprozesse.

Wer als einzelnes mittelständisches Institut, kommunaler Versorger oder Klinikträger versucht, diese Anforderungen im vollständigen Alleingang im eigenen Serverraum abzubilden, stößt rasch an wirtschaftliche und personelle Grenzen. Der Aufbau eines georedundanten Tier-3-Rechenzentrums über zwei Brandabschnitte oder Standorte hinweg, flankiert von einem rund um die Uhr besetzten Security Operations Center (SOC) und jährlichen BSI-C5-Audits, überfordert isolierte IT-Budgets regelmäßig.

Gleichzeitig erweist sich die unkritische Auslagerung geschäftskritischer Kernverfahren in globale Public-Cloud-Plattformen für Berufsgeheimnisträger und KRITIS-Betreiber als schwer kalkulierbares Compliance-Risiko. Extraterritoriale Zugriffsbefugnisse nach dem US CLOUD Act und FISA Section 702 lassen sich selbst durch europäische Rechenzentrumsstandorte außereuropäischer Mutterkonzerne juristisch nicht vollständig neutralisieren. Aus diesem strukturellen Spannungsfeld führt das Architekturmodell der Community Cloud.

Architekturprinzip Community Cloud: Warum Branchenverbünde ihre Rechenzentren bündeln

Nach der klassischen Definition des National Institute of Standards and Technology (NIST SP 800-145) bezeichnet eine Community Cloud eine Infrastruktur, die exklusiv für die Nutzung durch eine spezifische Gemeinschaft von Organisationen bereitgestellt wird, welche gemeinsame Anliegen, Sicherheitsanforderungen, Richtlinien und regulatorische Rahmenbedingungen teilen. Anders als in der offenen Public Cloud sind die Nachbarn auf der physischen Hardware hier keine anonymen Dritten, sondern handverlesene Institutionen derselben Domäne.

Dieses Prinzip verändert die Ökonomie und Sicherheit der IT-Bereitstellung von Grund auf. Da sämtliche Teilnehmer eines solchen Konsortiums denselben gesetzlichen Prüfmaßstäben unterliegen, muss die Plattform keine Kompromisse zugunsten eines kleinsten gemeinsamen Nenners eingehen. Vom physischen Zutrittsschutz über die kryptografische Schlüsselverwaltung bis hin zur Aufbewahrungsdauer von Audit-Logs lässt sich der gesamte Stack exakt auf das jeweilige Sektorrecht zuschneiden.

In der europäischen Praxis hat sich dieses kooperative Modell längst vom theoretischen Konzept zum tragenden Fundament systemrelevanter Wirtschaftszweige entwickelt. Im Genossenschafts- und Sparkassensektor betreiben spezialisierte Verbundrechenzentren wie die Atruvia AG oder die Finanz Informatik seit Jahrzehnten hochstandardisierte Gemeinschaftsplattformen, die hunderte rechtlich selbstständige Bankhäuser mit einheitlicher Kernbank-IT, BaFin-konformer Revision und zentraler Cyber-Abwehr versorgen.

Eine vergleichbare Dynamik prägt das Gesundheitswesen sowie die industrielle Fertigung. Wenn regionale Krankenhausverbünde und Universitätskliniken ihre elektronischen Patientenakten, Radiologie-Archive (PACS) und klinischen Informationssysteme über eine dedizierte Health-Community-Cloud nach § 393 SGB V und Artikel 9 DSGVO bündeln, verbleiben sämtliche Gesundheitsdaten innerhalb eines geschlossenen, berufsrechtlich geschützten Verbundnetzes ohne Abfluss in transatlantische Telemetriekanäle.

Auch in der Automobil- und Zulieferindustrie sowie in der öffentlichen Verwaltung setzt sich die kooperative Föderation durch. Im Datenökosystem Catena-X tauschen Fahrzeughersteller und Tier-1-Zulieferer CO2-Nachweise, Batteriepässe und Lieferkettendaten über souveräne, nach Gaia-X-Prinzipien föderierte Cloud-Knoten aus, während kommunale Zweckverbände und Landesrechenzentren behördliche Fachverfahren und souveräne Arbeitsplätze wie openDesk arbeitsteilig für hunderte Kommunen bereitstellen.

Wer eine solche Verbundplattform entwirft, muss daher weit über die bloße Vertragsgestaltung hinausdenken. Die Akzeptanz bei den Informationssicherheitsbeauftragten (CISOs) der beteiligten Häuser steht und fällt mit dem technischen Nachweis, dass jeder einzelne Mandant trotz gemeinsam genutzter Rechenzentrumsflächen, Stromversorgungen und Backbone-Leitungen technisch genauso isoliert agiert wie in einer dedizierten On-Premises-Umgebung.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud Computing Beispiele im Enterprise-Einsatz sowie zu Cloud Computing im Enterprise-Einsatz.

Technischer Deep-Dive: Mandantenisolation via SR-IOV, EVPN-VXLAN und Confidential Computing

Moderne europäische Community Clouds setzen für diese strikte Trennung auf eine mehrschichtige Verteidigungsarchitektur im Infrastruktur-Stack, wie sie etwa im offenen Referenzmodell des Sovereign Cloud Stack (SCS) auf Basis von KVM, OpenStack, Ceph und Kubernetes spezifiziert ist. Jede Schicht des Stacks erzwingt dabei eigene, hardwaregestützte Isolationsgrenzen zwischen den Verbundpartnern.

Netzwerk-Mikrosegmentierung mit EVPN-VXLAN und SmartNIC-Offloading via SR-IOV

Auf der Netzwerkebene bildet eine Spine-Leaf-Fabric mit BGP EVPN (Ethernet VPN) als Control Plane und VXLAN (Virtual Extensible LAN nach IETF RFC 7348) als Datenkapselung das Rückgrat der Mandantentrennung. Jeder Verbundpartner erhält eigene Virtual Routing and Forwarding (VRF) Instanzen sowie eindeutig zugewiesene 24-Bit-VXLAN-Netzwerk-Identifikatoren (VNIs), wodurch sich bis zu 16 Millionen logisch vollständig voneinander getrennte Layer-2- und Layer-3-Segmente realisieren lassen.

Um zu verhindern, dass hochvolumiger Datenverkehr eines Partners die Netzwerklatenzen eines anderen Mandanten beeinträchtigt (Noisy-Neighbor-Effekt) oder über einen kompromittierten Software-Switch im Hypervisor abgegriffen wird, kommen in Enterprise-Umgebungen SmartNICs bzw. Data Processing Units (DPUs) mit Single Root I/O Virtualization (SR-IOV) zum Einsatz. Die physische 100-GbE-Netzwerkkarte präsentiert sich dem PCIe-Bus dabei über isolierte Virtual Functions (VFs).

Jede virtuelle Maschine eines Mandanten bindet ihre zugewiesene Virtual Function per VFIO-Treiber direkt ein und kommuniziert unter Umgehung des Host-Kernels unmittelbar mit der Netzwerkkarten-Hardware. Gleichzeitig werden sämtliche VXLAN-Ver- und Entschlüsselungsoperationen (IPsec oder WireGuard Line-Rate Encryption) sowie zustandsbehaftete Firewall-Regeln direkt auf den ASIC-Prozessoren der DPU ausgeführt, sodass selbst der Hypervisor-Administrator keinen Klartext-Netzwerkverkehr einsehen kann.

„Eine erstklassige Community Cloud ersetzt blindes Vertrauen durch kryptografische Verifikation: Wenn Confidential Computing den Arbeitsspeicher pro Mandant im Prozessor verschlüsselt, bleibt das Bank- oder Patientengeheimnis selbst gegenüber dem Betreiber der gemeinsamen Plattform gewahrt.“

Diese strikte Entkopplung setzt sich auf der Speicherebene nahtlos fort. In einem verteilten Ceph-Storage-Cluster werden für die Teilnehmer getrennte RADOS-Namespaces und dedizierte CRUSH-Regeln definiert, während jede virtuelle Festplatte (RBD-Volume) und jeder Object-Storage-Bucket mittels LUKS2 bzw. Server-Side Encryption mit mandanteneigenen Schlüsseln (Customer-Managed Keys, CMK) verschlüsselt wird, die in einem FIPS-140-3-zertifizierten Hardware Security Module (HSM) der jeweiligen Mitgliedsorganisation liegen.

Wie sich solche hochperformanten Speicher-Fabrics auf Basis von Enterprise-NVMe-Laufwerken ohne proprietäre Storage-Controller aufbauen lassen, zeigen wir detailliert in unserer Architektur-Analyse zur Rechenzentrums-Autarkie mit Ceph und NVMe-over-Fabrics. Auch für Organisationen, die im Zuge eines Konsortialprojekts ihre Virtualisierungsschicht modernisieren wollen, bietet der VMware-Broadcom-Exit-Leitfaden mit Proxmox VE und Ceph konkrete Blaupausen.

Confidential Computing mit AMD SEV-SNP und Intel TDX

Den entscheidenden Durchbruch für kooperative Rechenzentren mit konkurrierenden Wirtschaftsteilnehmern oder streng geschützten Sozial- und Finanzdaten liefert jedoch Confidential Computing auf moderner Server-Hardware. Prozessoren ab der Generation AMD EPYC (Zen 4/5 mit Secure Encrypted Virtualization-Secure Nested Paging, SEV-SNP) sowie Intel Xeon Scalable (ab 4./5. Generation mit Trust Domain Extensions, TDX) schützen Daten erstmals auch während der aktiven Verarbeitung im Arbeitsspeicher (Data-in-Use).

Bei der Initialisierung einer Confidential VM erzeugt ein dedizierter Sicherheitsprozessor auf dem CPU-Die einen flüchtigen, für die Software niemals auslesbaren AES-128- oder AES-256-XTS-Schlüssel. Jede Speicherseite, die die virtuelle Maschine in den physischen DDR5-RAM schreibt, wird in Echtzeit durch die Speichercontroller-Hardware mit diesem mandantenspezifischen Schlüssel chiffriert, während die Nested-Paging-Tabellen zusätzlich die Speicherintegrität gegen Replay- oder Umleitungsangriffe sichern.

Selbst wenn ein Systemadministrator der Betreibergesellschaft oder ein Angreifer mit Root-Rechten auf dem Host-Hypervisor einen kompletten Speicherauszug (Memory Dump) zieht, erhält er lediglich kryptografisches Rauschen. Über eine hardwaregestützte Remote Attestation prüft der Mandant vor der Freigabe seiner geheimen Schlüssel aus dem eigenen HSM automatisch das signierte kryptografische Messprotokoll der CPU und stellt sicher, dass seine Workload auf authentischer, unveränderter Hardware läuft.

Architektur- und Governance-Vergleich: Public, Private und Community Cloud

Für die strategische Einordnung im Vorstand und IT-Prüfungsausschuss lohnt sich die direkte Gegenüberstellung der Bereitstellungsmodelle. Während Public-Cloud-Angebote durch schnelle Skalierbarkeit bei gleichzeitigem Verlust der Jurisdiktionshoheit gekennzeichnet sind und isolierte Private Clouds an hohen Fixkosten pro Standort leiden, kombiniert die Community Cloud die Stärken beider Welten.

Die folgende Bloomberg-Radar-Matrix bewertet die Modelle entlang der fünf maßgeblichen Architektur-, Sicherheits- und Wirtschaftlichkeitskriterien für regulierte Unternehmen:

Ein genauer Blick auf die zweite und dritte Zeile der Matrix zeigt den regulatorischen Kernvorteil. Unter dem BSI-Kriterienkatalog C5 (Cloud Computing Compliance Criteria Catalogue) erfordert ein belastbares Typ-2-Testat nicht nur das Vorhandensein angemessener Sicherheitskontrollen zu einem Stichtag (Typ 1), sondern den lückenlosen Nachweis ihrer operativen Wirksamkeit über einen Prüfungszeitraum von sechs bis zwölf Monaten durch unabhängige Wirtschaftsprüfer.

Gemeinsame BSI-C5-Typ-2-Testierung und DORA-Risikopooling in der Praxis

In einer Community Cloud greift hier das Prinzip der vererbbaren Sicherheitsnachweise (Control Inheritance). Die gemeinsame Trägerplattform übernimmt die vollständige Nachweisführung für die physische Rechenzentrumssicherheit (Domäne PS), das Infrastruktur-Patch- und Änderungsmanagement (OPS), die Netzwerksicherheit der Fabric (COS) sowie die georedundante Datensicherung und Notfallvorsorge (BC).

Für die angeschlossenen Mitgliedsunternehmen verbleiben im Rahmen des Modells geteilter Verantwortung (Shared Responsibility) lediglich die korrespondierenden Anwenderkriterien auf Applikations- und Benutzerebene, etwa die Vergabe der Fachbereichs-Rollen im eigenen Identity Provider. Dadurch sinkt der interne Vorbereitungs- und Prüferaufwand für ISO-27001-, KRITIS- oder §-8a-BSIG-Nachweise bei jedem einzelnen Verbundpartner um bis zu 75 Prozent.

Gleichzeitig adressiert die Konsortialstruktur gezielt die Anforderungen aus Artikel 28 bis 30 der europäischen Verordnung (EU) 2022/2554 (DORA) sowie des EU Data Act (Verordnung (EU) 2023/2854). Finanzinstitute und kritische Dienstleister können ihre Vor-Ort-Inspektionsrechte (Right to Audit) über gepoolte Gemeinschaftsaudits bündeln, statt mit minimaler Verhandlungsmacht vor den Standardverträgen außereuropäischer Konzerne zu kapitulieren.

Vollkostenrechnung über 60 Monate: Isolierter Eigenbetrieb versus Community Cloud

Um den wirtschaftlichen Hebel für den Finanzvorstand (CFO) präzise zu beziffern, betrachten wir ein repräsentatives Konsortium aus zehn mittelständischen Unternehmen, Regionalbanken oder Krankenhäusern. Jedes einzelne Haus benötigt für seine produktiven Fachverfahren, Datenbanken und Container-Plattformen eine Rechenkapazität von 16 physischen Dual-Socket-Servern (insgesamt 1.024 CPU-Kerne) sowie 250 Terabyte hochverfügbaren NVMe-Speicher über zwei getrennte Brandabschnitte.

Entscheidet sich ein einzelnes Haus für den vollständig isolierten Eigenbetrieb auf diesem Sicherheitsniveau, fallen über fünf Jahre (60 Monate) rund 480.000 Euro für Server-, Storage- und Netzwerk-Hardware inklusive Wartung, 420.000 Euro für Colocation-Stellflächen, Redundanz-Strom und Dark-Fiber-Strecken sowie mindestens 900.000 Euro für kommerzielle Virtualisierungs- und Backup-Lizenzen an.

Hinzu kommen die regulatorischen Fixkostenblöcke, die im Alleingang kaum zu komprimieren sind: Ein 24/7-Sicherheitsmonitoring (SOC/SIEM-Bereitschaft) sowie vier dedizierte Infrastruktur-Ingenieure kosten über 60 Monate rund 2,4 Millionen Euro, ergänzt durch 350.000 Euro für wiederkehrende Audits, Penetrationstests und ISMS-Zertifizierungen. In Summe trägt das einzelne Unternehmen im isolierten Eigenbetrieb eine 5-Jahres-TCO von rund 4,55 Millionen Euro (910.000 Euro pro Jahr).

Schließen sich diese zehn Häuser hingegen zu einer Community Cloud auf Basis eines offenen KVM-, OpenStack- und Ceph-Stacks zusammen, ändert sich die Kostenstruktur grundlegend. Durch gemeinsame Rahmenverträge für 160 Serverknoten und 2,5 Petabyte Ceph-Storage sowie den Wegfall teurer Core-Mietlizenzen und eine um 25 Prozent höhere Cluster-Auslastung sinkt der anteilige Hardware- und Flächenbeitrag pro Mitglied auf 620.000 Euro in fünf Jahren.

Der größte Einspareffekt entsteht jedoch durch das Teilen der Betriebs- und Compliance-Fixkosten: Ein erstklassiges 12-köpfiges Gemeinschafts-Betriebs- und 24/7-SOC-Team inklusive zentraler BSI-C5-Typ-2-Prüfung kostet das gesamte Konsortium über fünf Jahre rund 16,5 Millionen Euro, was für jedes der zehn Mitglieder lediglich 1,65 Millionen Euro bedeutet. Zuzüglich 380.000 Euro für lokale Mandanten-Administration und Anbindung sinkt die 5-Jahres-TCO pro Haus auf 2,65 Millionen Euro.

Jedes Mitgliedsunternehmen spart damit über 60 Monate rund 1,90 Millionen Euro (über 41 Prozent Gesamtkostenreduktion) bei gleichzeitig höherer georedundanter Ausfallsicherheit und lückenlosem 24/7-Schutz. Wie sich solche Rechnungen im Vergleich zu Public-Cloud-Mietmodellen verhalten, vertieft unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche: Drei erprobte Betreibermodelle für Verbünde

Wenn ein Branchenverband, eine Einkaufskooperation oder eine Gruppe kommunaler Träger den Aufbau einer Community Cloud beschließt, steht am Anfang die Wahl der passenden gesellschafts- und betriebsrechtlichen Bereitstellungsform. In der europäischen Unternehmenspraxis haben sich drei klar abgegrenzte Sourcing-Pfade bewährt.

Erstens (Eigenbetrieb): Die beteiligten Organisationen gründen eine eigene Trägergesellschaft in Form einer eingetragenen Genossenschaft (eG), einer gemeinsamen GmbH oder eines kommunalen Zweckverbands. Diese Gesellschaft mietet dedizierte Cages in zwei georedundanten Tier-3-Colocation-Rechenzentren an und betreibt den gesamten Open-Source-Stack mit eigenem Personal, was maximale strategische Souveränität und Selbstkostenpreise ohne fremde Gewinnmargen sichert.

Zweitens (Co-Managed): Das Konsortium behält die volle Hoheit über die Architektur-Governance, die Schlüsselverwaltung (HSM) und die Fachverfahren, vergibt jedoch das 24/7-Basis-Management der physischen Server, des Ceph-Speichers und der EVPN-VXLAN-Fabric an einen nach BSI C5 zertifizierten europäischen Infrastruktur-Partner. Über den offenen Sovereign Cloud Stack (SCS) bleibt die technische Austauschbarkeit des Dienstleisters jederzeit gewahrt.

Drittens (Managed Service): Für Verbünde, die ohne Vorlaufzeit für eigene Hardware-Beschaffung starten wollen, stellt ein europäischer Sovereign-Cloud-Provider eine physisch separierte Dedicated Community Zone inklusive fertigem BSI-C5-Typ-2-Testat und 24/7-SOC über einen zentralen Rahmenvertrag bereit. Die Mitglieder profitieren vom ersten Monat an von gebündelten Einkaufskonditionen und einheitlichen Service Level Agreements ohne eigenen Personalaufbau.

Der 4-Phasen-Umsetzungsfahrplan: In 180 Tagen vom Konsortium zum Regelbetrieb

Der Aufbau oder Beitritt zu einer Community Cloud erfordert eine synchronisierte Steuerung von Gesellschaftsrecht, Sicherheitsarchitektur und technischer Migration. Mit einem disziplinierten 4-Phasen-Fahrplan über sechs Monate vermeiden Entscheider langwierige Gremienblockaden und schaffen frühzeitig messbare Ergebnisse.

Phase 1 (Monat 1 bis 2): Konsortialvertrag, Governance-Charta und Mandanten-Sizing

Im ersten Schritt verabschieden die Gründungspartner das gesellschafts- oder vertragliche Rahmenwerk inklusive Stimmrechtsverteilung, Kostenschlüssel (Pay-per-Allocation plus Grundbeitrag) und geordneter Ein- und Austrittsregeln gemäß EU Data Act. Parallel erhebt das Architektur-Gremium die benötigten CPU-, RAM-, IOPS- und Bandbreiten-Profile aller Teilnehmer für die nächsten 36 bis 60 Monate.

Phase 2 (Monat 3 bis 4): Bereitstellung der Dual-Site-Fabric und Härtung der Isolation

Auf Basis der Kapazitätsplanung werden die Compute- und NVMe-Storage-Cluster in zwei mindestens 20 Kilometer voneinander entfernten Rechenzentrumsstandorten aufgebaut und über redundante Dark-Fiber-Strecken gekoppelt. Das Infrastruktur-Team richtet die EVPN-VXLAN-Segmente, das SR-IOV-Offloading sowie die Confidential-Computing-Profile (AMD SEV-SNP bzw. Intel TDX) ein und bindet die Standorte der Mitglieder per redundanten IPsec- oder MPLS-Strecken an.

Phase 3 (Monat 5): Gemeinsames ISMS, HSM-Schlüsselkopplung und Audit-Abnahme

Vor der ersten produktiven Datenübertragung wird das zentrale Informationssicherheits-Managementsystem (ISMS) mitsamt 24/7-SIEM-Korrelation und unveränderbaren WORM-Backup-Tresoren in Betrieb genommen. Externe Penetrationstester prüfen gezielt die Mandantentrennung zwischen den Konsortialpartnern, während die Wirtschaftsprüfer die vererbbare Dokumentationsmatrix (Customer Responsibility Matrix) nach BSI C5 und DORA Art. 28 abnehmen.

Phase 4 (Monat 6): Schrittweises Mandanten-Onboarding und produktiver Lastumzug

Nach erfolgreicher Sicherheitsfreigabe binden die Mitgliedshäuser ihre lokalen Verzeichnisdienste über föderiertes Identity Management (Keycloak mit OpenID Connect und SAML 2.0) sowie ihre eigenen Hardware Security Module an. In gestaffelten Migrationswellen ziehen zunächst Entwicklungs- und Testsysteme und anschließend die kritischen Fachverfahren in die Community Cloud um, begleitet von einem gemeinsamen Disaster-Recovery-Schwenktest.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur Community Cloud

1. Ist die Betreibergesellschaft der Community Cloud vollständig frei von außereuropäischen Durchgriffsrechten?

Prüfen Sie vor Vertragsabschluss nicht nur den geografischen Standort der Serverräume in Deutschland oder der EU, sondern die gesellschaftsrechtliche Eigentümerschaft des gesamten Betreiber- und Subunternehmer-Konstrukts. Nur wenn weder eine US-Muttergesellschaft noch außereuropäische Beherrschungsverträge vorliegen, ist die Plattform rechtssicher gegen Herausgabeverlangen nach dem US CLOUD Act geschützt.

2. Erfolgt die Mandantenisolation auf Hardware- und Kryptografie-Ebene statt nur über Software-Namespaces?

Verlangen Sie im Architektur-Konzept den expliziten Nachweis, wie Netzwerk-, Speicher- und Arbeitsspeicherzugriffe zwischen den Verbundmitgliedern technisch getrennt werden. Für hochsensible Branchenworkloads sollten dedizierte VXLAN-VNIs, verschlüsselte Ceph-Namespaces mit mandanteneigenen HSM-Schlüsseln (BYOK/HYOK) sowie Confidential Computing auf CPU-Ebene verbindlich vorgeschrieben sein.

3. Welche konkreten BSI-C5-Kriterien werden vererbt und wie sieht die Customer Responsibility Matrix aus?

Ein zentrales BSI-C5-Testat entfaltet seinen wirtschaftlichen Wert erst dann, wenn der Betreiber eine präzise Abgrenzungsmatrix bereitstellt, die jedes einzelne Kriterium als vollständig vom Verbund erfüllt oder als geteilte Pflicht ausweist. Klären Sie frühzeitig mit Ihrer internen Revision, wie diese Prüfberichte direkt in Ihre eigene ISO-27001- oder DORA-Nachweisführung übernommen werden.

4. Wie sind Stimmrechte, Preisanpassungen und technische Ausstiegsprozesse im Konsortialvertrag geregelt?

Achten Sie darauf, dass kein einzelner Großmandant oder Dienstleister einseitig über Architekturwechsel oder Gebührenerhöhungen entscheiden kann. Zudem muss der Vertrag im Einklang mit dem EU Data Act und DORA Artikel 28 garantieren, dass jeder Teilnehmer seine virtuellen Maschinen, Container-Images und Datenbestände über offene Standardschnittstellen jederzeit ohne Strafgebühren wieder abziehen kann.

5. Deckt das gemeinsame 24/7-SOC auch branchenspezifische Angriffsvektoren und Notfallübungen ab?

Ein generisches Infrastruktur-Monitoring reicht für KRITIS-Betreiber, Banken oder Kliniken nicht aus. Stellen Sie sicher, dass das gemeinsame Security Operations Center über spezialisierte Erkennungsregeln für Ihre Branchen-Applikationen verfügt und mindestens einmal jährlich gemeinsame Notfall- und Wiederanlaufübungen (inklusive Ransomware-Wiederherstellung aus WORM-Backups) mit allen Verbundpartnern durchführt.

Strategisches Fazit: Kooperative Souveränität als Königsweg für regulierte Branchen

Für den gehobenen Mittelstand, die Finanz- und Gesundheitswirtschaft sowie den öffentlichen Sektor löst die Community Cloud einen jahrzehntelangen Zielkonflikt auf. Organisationen müssen sich nicht länger zwischen der wirtschaftlichen Überforderung eines isolierten Einzel-Rechenzentrums und der regulatorischen Abhängigkeit außereuropäischer Hyperscaler entscheiden.

Indem Unternehmen mit gleichgelagerten Compliance-Anforderungen ihre Infrastruktur auf Basis offener Standards wie KVM, OpenStack, Ceph und Confidential Computing bündeln, verbinden sie kompromisslose Mandantenisolation auf Siliziumebene mit geteilten 24/7-SOC-Kapazitäten, vererbbaren BSI-C5-Testaten und rund 40 Prozent niedrigeren Gesamtkosten über fünf Jahre.

Häufig gestellte Fragen (FAQ) zur Community Cloud im Enterprise-Einsatz