Souveränes und vertrauliches Deployment: VPC, On-Premises, Air-Gapped und TEEs
Fragen Sie die meisten Teams, wo ihre KI läuft, und Sie bekommen eine einzige Antwort: die Cloud, oder On-Premises, oder, wenn sie vorsichtig sind, air-gapped. Eine Topologie, einmal gewählt, auf alles angewandt. Das ist eine saubere Entscheidung, und für ein unreguliertes Geschäft meist in Ordnung.
Nur ist in einem regulierten Unternehmen eine einzige Deployment-Topologie entweder verschwenderisch oder gefährlich, und oft beides zugleich. Die Deployment-Topologie ist keine Wahl, die Sie einmal fürs ganze System treffen. Sie ist eine Routing-Regel nach Datensensitivität, und sie muss geschlossen fehlschlagen. Wählen Sie eine Topologie für alles, überzwängen Sie entweder günstige, unsensible Arbeit, indem Sie sie in einen nie gebrauchten Air-Gap sperren, oder, weit schlimmer, Sie lassen regulierte Daten irgendwohin fließen, wohin sie nie durften, weil dieser Ort für etwas anderes bequem war. Das richtige Modell ist ein Spektrum von Topologien und eine Regel, die jede Last in die am wenigsten exponierte Umgebung routet, die ihre Datenklasse erlaubt.
Es gibt auch einen neueren Punkt auf diesem Spektrum, den die meisten Referenzarchitekturen überspringen, und er löst den schwersten Fall: wie man regulierte Daten auf Infrastruktur verarbeitet, die man physisch nicht kontrolliert, ohne sie preiszugeben, mit Confidential Computing und Trusted Execution Environments. Dort wird es wirklich interessant.
Das Topologiespektrum, nach Sensitivität geroutet
Denken Sie an Deployment als Leiter abnehmender Exponierung und an Datensensitivität als das, was bestimmt, wie weit Sie für jede Last hinaufsteigen müssen.
Am exponierungstoleranten Ende steht ein selbst mitgebrachtes Cloud-Konto, das Elastizität und die geringste Betriebslast bietet, zum Preis, dass Daten Ihr Konto Richtung Modellregion verlassen, wenn Sie es erlauben. Darüber hält ein regionsgebundenes VPC Daten in Ihrem eigenen Cloud-Perimeter und Ihrer geforderten Residenzzone, wofür Sie Grenze und Routing betreiben. Höher noch gibt On-Premises volle physische Kontrolle, wenn Regeln externe Verarbeitung ganz verbieten, und übergibt Ihnen dafür Kapazitätsplanung und GPU-Betrieb. Ganz oben entfernt eine air-gapped Umgebung den Egress-Pfad vollständig für die sensibelste Arbeit, und Sie zahlen diese Isolation mit manuellen, bewussten Modell-Updates und Betriebsabläufen.
Der Fehler ist, diese Leiter als Menü zu lesen und eine Sprosse für die ganze Organisation zu wählen. Es ist kein Menü. Es ist eine Routing-Tabelle. Sie klassifizieren die Daten, die eine Last trägt, und die Klassifizierung sagt Ihnen die niedrigste Sprosse, auf der diese Last laufen darf. Ein einzelner Geschäftsprozess überspannt regelmäßig Klassen: Ein Schritt liest eine regulierte Akte und gehört hoch auf die Leiter, ein anderer entwirft eine generische Benachrichtigung und darf unten sitzen. Das Routing geschieht also pro Schritt, nicht einmal fürs System, und derselbe Prozess kann in einem Lauf zwei Topologien berühren.
Confidential Computing: regulierte Daten verarbeiten, die Sie nicht vollständig isolieren können
Hier ist der Fall, den die klassische Leiter schlecht behandelt. Manchmal brauchen Sie die Elastizität oder die Spezialhardware einer Infrastruktur, die Ihnen physisch nicht gehört, aber die Daten sind zu sensibel, um sie dem Betreiber dieser Infrastruktur zu zeigen. Der Air-Gap sagt nein. Das VPC sagt "vertraut den Betreibenden eures Cloud-Anbieters". Keines befriedigt, wenn das Bedrohungsmodell die Plattform selbst einschließt.
Das adressiert Confidential Computing, und der Mechanismus ist ein Trusted Execution Environment, ein TEE. Ein TEE ist eine hardwaregestützte Enklave, in der Daten entschlüsselt und verarbeitet werden, während sie überall sonst verschlüsselt bleiben: im Speicher hält die Enklave sie in einem Bereich, den das Host-Betriebssystem, der Hypervisor und der Cloud-Betreiber physisch nicht lesen können. Die Daten sind nicht nur ruhend und in Übertragung geschützt, den beiden Zuständen, die alle längst absichern, sondern in Nutzung, dem Zustand, der historisch die Lücke war. Die Last läuft, die regulierten Daten werden verarbeitet, und der Betreiber der Maschine hatte nie die Möglichkeit, sie zu sehen.
Zwei Eigenschaften machen daraus ein Control statt einer Behauptung. Die Enklave wird von der CPU-Hardware erzwungen, nicht von einer Softwarekonfiguration, die eine privilegierte Betreiberin abschalten könnte. Und Remote Attestation lässt Sie kryptografisch verifizieren, bevor Sie irgendwelche Daten senden, dass der Code in der Enklave genau der erwartete ist und wirklich in einem echten TEE läuft. Sie vertrauen nicht der Zusage des Betreibers, dass Ihre Daten geschützt sind. Sie verifizieren die Enklave, geben dann die Daten frei, und die Verifikation ist eine Signatur, die Sie als Nachweis behalten können.
Für eine regulierte Organisation rahmt das eine früher binäre Entscheidung neu. Die alte Frage lautete "Hardware besitzen oder Daten preisgeben". Confidential Computing fügt eine dritte Antwort für einen konkreten, wertvollen Teil der Lasten hinzu: auf Hardware laufen, die Ihnen nicht gehört, über Daten, die Sie sonst nicht preisgeben könnten, weil die Umgebung attestiert und der Betreiber kryptografisch ausgesperrt ist. Es ersetzt On-Premises oder Air-Gap in den extremsten Fällen nicht. Es erweitert die Reichweite der Souveränität an Orte, an die sie zuvor nicht kam.
Souveränitäts-Routing, das geschlossen fehlschlägt
Ein Spektrum von Topologien ist nur so sicher wie die Regel, die Lasten darauf verteilt, und die Eigenschaft, die diese Regel verteidigbar macht, ist eine bestimmte: Sie schlägt geschlossen fehl.
Die Routing-Policy klassifiziert Daten nach Sensitivität und bindet jede Klasse an die Topologien, auf denen sie laufen darf. Regulierte und personenbezogene Daten bleiben standardmäßig in Ihrem Perimeter, ob dieser ein regionsgebundenes VPC, On-Premises, ein Air-Gap oder eine attestierte Enklave ist. Nur ausdrücklich unsensible Lasten dürfen ein Modell in einer externen Region erreichen, und nur wenn eine Policy dieser Klasse das Verlassen erlaubt hat. Entscheidend ist, was bei Unsicherheit geschieht: Ist eine Klassifizierung mehrdeutig, behandelt das System die Daten als sensibel und behält sie in der am stärksten geschützten Umgebung, die ihre möglichen Klassen zulassen. Die Voreinstellung schützt Sie. Sie zu lockern verlangt eine bewusste, protokollierte Entscheidung, kein Versäumnis.
Das ist der Unterschied zwischen "Ihre Daten verlassen nie Ihre Mauern" als Marketingzeile und als Architektur. Als Architektur wird Egress standardmäßig verweigert und nur per expliziter Policy erlaubt, pro Datenklasse, pro Schritt, jede Lockerung festgehalten. Eine Fehlkonfiguration öffnet nicht still eine Tür, weil die Tür geschlossen ist, solange nicht etwas sie bewusst öffnet. Fail-closed ist der ganze Grund, warum eine Aufsicht der Souveränitätsaussage glauben kann, denn es heißt, der Fehlermodus des Systems ist Überprotektion, nicht Abfluss.
DORA und Residenz sind die Treiber, nicht der Papierkram
Nichts davon ist Engineering um seiner selbst willen. Es ist die Gestalt, die regulatorische Pflicht erzwingt, und zwei Pflichten treiben sie besonders.
Datenresidenz ist die unmittelbare. Regeln, die verlangen, dass bestimmte Daten in einer Jurisdiktion bleiben, machen aus "wo läuft das Modell?" eine Rechtsfrage mit physischer Antwort. Ein regionsgebundenes VPC, ein On-Premises-Cluster oder eine attestierte Enklave in der richtigen Jurisdiktion sind keine Vorliebe; so erfüllen Sie eine Regel, die eine bequeme Standardregion verletzen würde. Regime operationeller Resilienz wie DORA drücken in dieselbe Richtung: Sie kümmern sich um Konzentrationsrisiko und darum, ob Sie einen kritischen Prozess laufend und prüfbar halten können, und genau das liefert eine geroutete, anbieterunabhängige, überall deploybare Haltung, eine fest verdrahtete Einzeltopologie nicht. Ist Ihr Deployment eine Routing-Regel, die Ihnen gehört, statt der Voreinstellung eines Anbieters, können Sie einer Aufsicht sowohl zeigen, wo regulierte Daten bleiben, als auch, wie der Prozess überlebt, wenn ein Anbieter oder eine Region unbrauchbar wird.
Die Frage für Ihr nächstes Architektur-Review lautet also nicht "Cloud oder On-Premises?". Sie lautet: was ist für jede Datenklasse in diesem Prozess die am wenigsten exponierte Umgebung, in der sie laufen darf, routet das System sie dort standardmäßig hin, und schlägt es geschlossen fehl, wenn es unsicher ist? Können Sie das pro Datenklasse beantworten, und hat Confidential Computing Ihre Reichweite auf die Lasten erweitert, die früher eine unmögliche Wahl erzwangen, haben Sie eine Souveränitätsarchitektur. Lautet Ihre Antwort eine Topologie für alles, haben Sie die Hoffnung, dass nichts Sensibles je den bequemen Weg nimmt.
Wenn Sie Ihre Datenklassen auf erlaubte Topologien abbilden und finden wollen, wo eine attestierte Enklave die Antwort ändert, buchen Sie einen Termin und bringen Sie uns den Prozess mit den jurisdiktionell sensibelsten Daten mit.