Wissensraum · Deep Dive 18 von 27
Drei Infrastrukturmodelle, drei Souveränitätslogiken, drei Risikoprofile
Was dieser Deep Dive Ihnen zeigt
Wie Edge, Cloud und Fog Computing aufgebaut sind, was «digitale Souveränität» in jedem Modell konkret bedeutet – und wie die drei Architekturen unter NIS2, DORA und AI Act sicherheitstechnisch zu bewerten sind.
Die Frage, wo Daten verarbeitet werden, ist keine technische Detailfrage. Sie ist eine Governance-Frage. Seit DORA, NIS2 und dem AI Act ist sie zusätzlich eine regulatorische Frage – mit Konsequenzen für Auditfähigkeit, Haftung und Marktzugang.
In der Praxis arbeiten die meisten Unternehmen mit einer Mischform aus drei Infrastrukturmodellen: Cloud, Edge und Fog. Die Begriffe werden häufig unscharf verwendet. Dieser Deep Dive klärt, was jedes Modell architektonisch bedeutet, welche Souveränitätsfragen es aufwirft und wie die drei Modelle unter IT-Sicherheitsaspekten zu gewichten sind.
Cloud Computing verlagert Rechenleistung, Speicher und Anwendungen in entfernte Rechenzentren, die von Drittanbietern betrieben werden. Der Nutzer greift über das Internet zu. Die Infrastruktur gehört dem Provider; der Kunde mietet Kapazität.
Die drei Servicemodelle: IaaS (Infrastructure as a Service – virtuelle Maschinen, Speicher, Netzwerk), PaaS (Platform as a Service – Entwicklungsumgebungen, Datenbanken), SaaS (Software as a Service – fertige Anwendungen wie CRM, ERP, E-Mail). Je höher die Abstraktionsebene, desto weniger Kontrolle hat der Kunde über die darunterliegende Schicht.
Die vier Bereitstellungsmodelle: Public Cloud (geteilte Infrastruktur, z.B. AWS, Azure, Google Cloud), Private Cloud (dedizierte Infrastruktur für ein Unternehmen), Hybrid Cloud (Kombination aus beidem) und Multi-Cloud (mehrere Public-Cloud-Anbieter parallel). Jedes Modell verschiebt die Kontrollgrenze anders.
Souveränität in der Cloud bedeutet: Wer kontrolliert den Zugang zu den Daten? Wer entscheidet über Verschlüsselung, Standort, Portabilität? In einer Public Cloud ist die Antwort klar: Der Provider kontrolliert die Infrastruktur. Der Kunde kontrolliert – bestenfalls – die Konfiguration.
Das Problem ist nicht die Cloud an sich. Das Problem ist die Asymmetrie: Der Kunde ist auf Vertragsklauseln angewiesen, um Rechte durchzusetzen, die er technisch nicht erzwingen kann. Wo liegen die Schlüssel? Wer hat Root-Zugang? Was passiert bei einem US-Subpoena, wenn der Provider amerikanischem Recht unterliegt?
Einordnung
Der EU Data Act (ab September 2025) und der CLOUD Act (US) stehen in direktem Konflikt. Ein europäisches Unternehmen, das Daten bei einem US-Hyperscaler speichert, unterliegt de facto zwei Rechtsordnungen – ohne dass eine die andere ausschließt. DORA Art. 28–30 verlangt deshalb explizit dokumentierte Exit-Strategien und Vertragsklauseln für ICT-Drittanbieter.
Europäische Alternativen (Gaia-X, Sovereign Cloud Stack, STACKIT, OVHcloud) adressieren die Souveränitätsfrage architektonisch – durch europäische Rechenzentren, offene Standards und transparente Governance. Ihr Marktanteil liegt derzeit bei unter 10% des europäischen IaaS-Marktes. Die Abhängigkeit von den drei US-Hyperscalern (AWS, Azure, Google Cloud – zusammen ca. 70% Marktanteil in Europa) ist strukturell.
Cloud-Sicherheit folgt dem Shared Responsibility Model: Der Provider sichert die Infrastruktur, der Kunde sichert seine Daten und Konfigurationen. In der Praxis entsteht hier eine gefährliche Lücke: Viele Unternehmen gehen davon aus, dass «in der Cloud» gleichbedeutend ist mit «sicher». Die häufigsten Cloud-Sicherheitsvorfälle – offene S3-Buckets, falsch konfigurierte IAM-Rollen, unverschlüsselte Datenbankexporte – sind Konfigurationsfehler auf Kundenseite.
NIS2 Art. 21 verlangt von wesentlichen und wichtigen Einrichtungen Maßnahmen zur Sicherheit der Lieferkette – einschließlich Cloud-Provider. Das bedeutet: Nicht nur den eigenen Perimeter sichern, sondern die gesamte Abhängigkeitskette dokumentieren, bewerten und überwachen.
Edge Computing verarbeitet Daten dort, wo sie entstehen – an der «Kante» des Netzwerks: in Fabriken, Fahrzeugen, Filialen, medizinischen Geräten, Sensoren. Statt Daten in ein zentrales Rechenzentrum zu schicken, läuft die Verarbeitung lokal oder in unmittelbarer Nähe der Datenquelle.
Typische Edge-Architekturen umfassen: On-Device Computing (Verarbeitung direkt auf dem Endgerät – Smartphone, Kamera, Industriesensor), Edge Server (lokale Server in Filialen, Produktionshallen oder Basisstationen), Near-Edge (regionale Rechenzentren, die näher am Nutzer liegen als die zentrale Cloud, aber nicht direkt am Gerät).
Der Treiber ist Latenz. Autonome Fahrzeuge, Echtzeitqualitätskontrolle in der Fertigung, chirurgische Robotik – diese Anwendungen tolerieren keine 50-Millisekunden-Rundreise in ein Cloud-Rechenzentrum. Die Entscheidung muss lokal fallen, in Echtzeit.
Am Edge verschiebt sich die Souveränitätsfrage fundamental: Die Daten verlassen das Gerät oder die Anlage nicht. Das ist der größte Souveränitätsvorteil des Edge-Modells – und gleichzeitig seine größte operative Herausforderung.
Wer kontrolliert das Edge-Gerät? In der Industrie häufig: der Hersteller, nicht der Betreiber. Firmware-Updates, Diagnoseprotokolle, Telemetriedaten – vieles davon fließt an den Gerätehersteller zurück, ohne dass der Betreiber Einblick hat. Digitale Souveränität am Edge bedeutet daher nicht nur «die Daten bleiben hier», sondern: Wer hat die Kontrolle über die Software, die auf dem Gerät läuft?
Edge-Souveränität ist nicht Datenlokalisierung. Sie ist die Frage, wer den Code kontrolliert, der über die Daten entscheidet.
Edge-Computing multipliziert die Angriffsoberfläche. Statt eines zentralen Rechenzentrums mit physischer Zugangskontrolle, redundanten Firewalls und 24/7-SOC-Überwachung gibt es tausende verteilte Geräte – in Fabrikhallen, im öffentlichen Raum, in Fahrzeugen. Jedes Gerät ist ein potenzieller Angriffspunkt.
Die typischen Edge-Sicherheitsprobleme: veraltete Firmware (Patches werden nicht eingespielt), Standardpasswörter (nie geändert), fehlende Verschlüsselung der lokalen Speicher, physischer Zugang durch Dritte, ungesicherte Kommunikationskanäle zwischen Edge und Cloud.
Unter DORA ist das besonders relevant für Finanzinstitute, die Edge-Geräte einsetzen – Geldautomaten, POS-Terminals, IoT-Sensoren in Gebäudeüberwachung. Jedes dieser Geräte muss in das ICT-Asset-Inventar aufgenommen und in die Resilienztests einbezogen werden.
Fog Computing ist kein drittes, gleichrangiges Paradigma neben Cloud und Edge. Es ist eine Architekturentscheidung, die beide verbindet. Der Begriff wurde 2012 von Cisco geprägt und beschreibt eine Zwischenschicht: Rechenkapazität, die näher am Edge liegt als die Cloud, aber leistungsfähiger ist als das einzelne Edge-Gerät.
Fog-Knoten – typischerweise Gateway-Server, industrielle Controller, lokale Cluster – aggregieren Daten von Edge-Geräten, filtern, vorverarbeiten und leiten nur relevante Ergebnisse an die Cloud weiter. Die Fog-Schicht entscheidet: Was wird lokal verarbeitet? Was muss in die Cloud? Was wird verworfen?
Typische Einsatzszenarien: Smart-City-Infrastruktur (Verkehrssteuerung, Umweltsensoren), industrielle IoT-Plattformen (Predictive Maintenance über hunderte Maschinen), Gesundheitswesen (lokale Aggregation von Patientendaten vor Cloud-Analyse).
Im Fog-Modell entsteht eine gestufte Souveränität: Die Rohdaten bleiben am Edge. Die aggregierten Daten liegen im Fog-Knoten. Nur verdichtete Ergebnisse gehen in die Cloud. Das ermöglicht eine differenzierte Kontrolle – theoretisch. In der Praxis hängt die Souveränität davon ab, wer die Fog-Schicht betreibt.
Wenn der Fog-Knoten ein Gateway des Cloud-Providers ist (z.B. AWS Greengrass, Azure IoT Edge), verschiebt sich die Kontrollgrenze: Der Provider kontrolliert nicht nur die Cloud, sondern auch die Vorverarbeitungslogik. Die Souveränitätsfrage lautet dann nicht mehr «Wo liegen die Daten?», sondern: «Wer kontrolliert die Filterlogik, die entscheidet, was in die Cloud geht?»
Einordnung
Fog Computing ist regulatorisch ein blinder Fleck. NIS2 und DORA adressieren Cloud-Abhängigkeiten und ICT-Drittanbieter – aber die Fog-Schicht fällt häufig zwischen die Kategorien. Sie ist weder «Cloud» im Sinne der Vertragsklauseln noch «eigene Infrastruktur» im Sinne der Assetinventare. Diese Grauzone ist ein Risiko.
Fog-Knoten erben die Sicherheitsprobleme beider Welten: die Angriffsoberfläche des Edge (physisch zugänglich, dezentral, heterogen) und die Abhängigkeiten der Cloud (Software-Supply-Chain, Provider-Lock-in, Konfigurationskomplexität). Gleichzeitig sind sie Aggregationspunkte – wer einen Fog-Knoten kompromittiert, hat Zugang zu den verdichteten Daten vieler Edge-Geräte.
Die Sicherheitsarchitektur muss deshalb drei Dinge leisten: Isolation der Fog-Knoten untereinander (Lateral Movement verhindern), Ende-zu-Ende-Verschlüsselung auf allen drei Ebenen (Edge → Fog → Cloud), und unabhängiges Monitoring der Fog-Schicht – nicht über die Cloud des Providers, sondern über eigene Kanäle.
| Dimension | Cloud | Edge | Fog |
|---|---|---|---|
| Datenhoheit | Beim Provider (vertraglich geregelt) | Beim Betreiber (technisch kontrolliert) | Geteilt (abhängig vom Fog-Betreiber) |
| Angriffsoberfläche | Konzentriert, aber hochwertig | Verteilt, physisch exponiert | Aggregationspunkte, hybrid |
| Latenz | Hoch (10–200 ms) | Minimal (<5 ms) | Mittel (5–30 ms) |
| Auditfähigkeit | Abhängig vom Provider | Eigene Kontrolle, aber Skalierungsproblem | Komplex: zwei Schichten, zwei Verantwortlichkeiten |
| Vendor Lock-in | Hoch (APIs, Datenformate, Vertragsbindung) | Mittel (Hardware-Abhängigkeit) | Hoch, wenn Fog = Provider-Gateway |
| Regulatorische Zuordnung | Klar (ICT-Drittanbieter) | Klar (eigene Infrastruktur) | Unklar (Grauzone) |
| Exit-Fähigkeit | Kritisch (Datenmigration, Formatbindung) | Gut (Daten lokal) | Variabel |
Ausgangssituation
Ein Schweizer MedTech-Unternehmen betreibt IoT-Sensoren in Kliniken (Edge), aggregiert die Daten über herstellereigene Gateways (Fog) und speichert Auswertungen in einer europäischen Cloud-Instanz. Im DORA-Audit für einen Bankenkunden wird die gesamte Datenverarbeitungskette geprüft.
Was sich zeigt
Die Cloud-Instanz ist sauber dokumentiert: europäischer Standort, AES-256, vertragliche Exit-Klauseln. Die Edge-Geräte sind im Assetinventar. Aber die Fog-Gateways – herstellereigene Hardware mit proprietärer Firmware – tauchen in keinem Inventar auf. Weder als ICT-Asset noch als Drittanbieter-Abhängigkeit.
Die Konsequenz
Der Gateway-Hersteller überträgt Telemetriedaten an Server in Singapur – technisch notwendig für Firmware-Updates, vertraglich nirgends geregelt. Die Fog-Schicht – das Bindeglied zwischen Edge und Cloud – war der einzige Punkt in der Architektur, an dem Daten den europäischen Rechtsraum verließen. Im Audit ein Finding der Kategorie «kritisch».
Warum das typisch ist
Fog-Komponenten werden häufig als «Infrastruktur» klassifiziert, nicht als «ICT-Drittanbieter». Sie fallen durch das Raster der gängigen Inventarisierung. Genau dort – in der Schicht, die niemand prüft – entstehen die Befunde, die Transaktionen verzögern.
Der Begriff «digitale Souveränität» wird politisch so inflatär verwendet, dass er operativ fast unbrauchbar geworden ist. Für Unternehmen, die unter NIS2, DORA oder dem AI Act stehen, lässt er sich auf drei konkrete Fragen reduzieren:
Kontrolle: Können Sie jederzeit auf Ihre Daten zugreifen, sie exportieren und den Anbieter wechseln? DORA Art. 28 verlangt dokumentierte Exit-Strategien. Der Data Act schreibt Interoperabilität und Portabilität vor. Wenn die Antwort «theoretisch ja, praktisch in 18 Monaten» lautet, ist die Souveränität nominal.
Transparenz: Wissen Sie, welche Sub-Auftragnehmer Ihre Daten verarbeiten, wo die Server physisch stehen und welchem Rechtsregime der Provider unterliegt? NIS2 Art. 21 verlangt Sicherheit der Lieferkette. Transparenz ist die Voraussetzung.
Entscheidungsfähigkeit: Können Sie bei einem Vorfall – Ausfall, Breach, regulatorische Änderung – innerhalb definierter Zeiträume reagieren, ohne auf die Mitwirkung des Providers angewiesen zu sein? DORA-Resilienztests prüfen genau das.
Digitale Souveränität ist kein Standortlabel. Sie ist die Fähigkeit, bei einem Ausfall, einem Breach oder einer regulatorischen Änderung handlungsfähig zu bleiben – ohne auf die Mitwirkung Dritter angewiesen zu sein.
Kein Modell ist per se sicherer als die anderen. Die Sicherheit hängt nicht von der Architekturentscheidung ab, sondern von der Governance über die Architekturentscheidung. Trotzdem lassen sich strukturelle Unterschiede benennen:
Cloud bietet die höchste Professionalität in der Basisinfrastruktur – physische Sicherheit, Redundanz, Patch-Management werden von spezialisierten Teams mit Budgets betrieben, die kein einzelnes Unternehmen aufbringen kann. Das Risiko liegt in der Konfigurationsverantwortung des Kunden und in der Abhängigkeit vom Provider.
Edge bietet die höchste Datenlokalisierung, aber die größte Angriffsoberfläche. Jedes Gerät ist ein potenzieller Eintrittspunkt. Das Risiko ist nicht der einzelne kompromittierte Sensor – es ist die Kettenreaktion über hunderte oder tausende Geräte mit identischer Firmware.
Fog liegt dazwischen und erbt die Risiken beider Seiten. Der zusätzliche Risikofaktor: Fog-Knoten sind Aggregationspunkte. Wer sie kontrolliert, kontrolliert den Datenfluss zwischen Edge und Cloud. In der Sicherheitsbewertung ist die Fog-Schicht deshalb nicht das Mittelfeld – sie ist der kritischste Punkt der Gesamtarchitektur.
Praxis-Impuls
Stellen Sie Ihrem IT-Team drei Fragen: (1) Haben wir ein vollständiges Inventar aller Fog-Komponenten – Gateways, Controller, lokale Aggregatoren – und sind sie als ICT-Assets oder Drittanbieter-Abhängigkeiten klassifiziert? (2) Wissen wir, welche Daten die Fog-Schicht an welche Ziele weiterleitet – einschließlich Telemetrie an Hersteller? (3) Können wir die Fog-Schicht unabhängig vom Cloud-Provider überwachen? Wenn eine dieser Fragen mit «nein» beantwortet wird, haben Sie einen blinden Fleck in Ihrer Sicherheitsarchitektur.
Die europäische Cloud-Abhängigkeit von US-Hyperscalern ist dokumentiert und politisch anerkannt. Gaia-X – 2019 als europäische Antwort gestartet – ist mittlerweile ein Standardisierungsprojekt, kein marktfähiges Produkt. Die Sovereign-Cloud-Initiativen einzelner Mitgliedstaaten (Frankreich: SecNumCloud, Deutschland: Sovereign Cloud Stack) schaffen Insellösungen, keinen Kontinent.
Am Edge sieht es anders aus: Europäische Industrieunternehmen – Siemens, Bosch, ABB – sind im Edge-Computing führend, weil ihre Kunden (Automobil, Fertigung, Energie) Echtzeit-Verarbeitung vor Ort brauchen. Hier liegt ein struktureller Souveränitätsvorteil, der regulatorisch noch nicht eingeholt ist.
Im Fog-Bereich dominieren die Plattformen der Cloud-Provider: AWS Greengrass, Azure IoT Edge, Google Cloud IoT Core (eingestellt 2023, das Ökosystem hat sich seitdem fragmentiert – Alternativen wie Azure IoT Hub und AWS IoT Core füllen die Lücke). Wer Fog über einen Hyperscaler betreibt, zementiert die Cloud-Abhängigkeit auf einer zusätzlichen Ebene.
Regulatorisch hat die EU 2024–2026 die Instrumente geschaffen: Der Data Act erzwingt Portabilität und Interoperabilität. NIS2 erzwingt Lieferkettentransparenz. DORA erzwingt Exit-Fähigkeit und Drittanbieter-Governance. Der AI Act verlangt Erklärbarkeit und Nachvollziehbarkeit – die nur möglich sind, wenn klar ist, wo die Inferenz stattfindet (Cloud? Edge? Fog?). Die Instrumente existieren. Was fehlt, ist die operative Umsetzung in den Unternehmen.
Was bleibt
Cloud ist kein Standort, sondern ein Kontrollmodell. Die entscheidende Frage ist nicht «wo liegen die Daten», sondern «wer kontrolliert den Zugang, die Verschlüsselung, die Exit-Fähigkeit». DORA und der Data Act machen diese Frage prüfbar.
Edge ist der Souveränitätsvorteil – und das Sicherheitsproblem. Daten bleiben lokal, aber tausende verteilte Geräte mit identischer Firmware sind ein systemisches Risiko. Wer Edge betreibt, braucht ein Sicherheitskonzept, das Skalierung denkt.
Fog ist der blinde Fleck. Die Zwischenschicht zwischen Edge und Cloud fällt regulatorisch und operativ durch das Raster. Wer Fog-Gateways nicht als ICT-Assets inventarisiert und nicht als Drittanbieter-Abhängigkeit bewertet, hat ein nicht dokumentiertes Risiko in der Mitte seiner Architektur.
Digitale Souveränität ist operativ, nicht rhetorisch. Sie misst sich an drei Dingen: Kann ich meine Daten jederzeit exportieren? Weiß ich, wer sie verarbeitet? Kann ich bei einem Vorfall handeln, ohne auf Dritte zu warten? Alles andere ist Standortmarketing.