Jeder große Cloud-Anbieter hat versucht, Ihnen einen verwalteten Ledger-Dienst zu verkaufen. AWS hatte QLDB (jetzt tot). Microsoft hat Azure Confidential Ledger. Das Verkaufsargument ist immer dasselbe: Wir kümmern uns um die Kryptographie, Sie bekommen manipulationssichere Datensätze. Es klingt nach einem gelösten Problem. Doch in der Architektur verbirgt sich eine Falle — und sie wird erst sichtbar, wenn Sie versuchen, diese Nachweise außerhalb der Cloud zu verwenden, die sie erstellt hat.
Das Versprechen vs. das Kleingedruckte
Verwaltete Cloud-Ledger bieten tatsächlich echte kryptographische Integrität. Sie hashen Ihre Daten, verketten Blöcke und stellen Quittungen aus. Die Mathematik stimmt. Aber der Verifizierungspfad führt über die API des Cloud-Anbieters. Ihr Nachweis ist nur so zugänglich wie der Service-Endpoint des Anbieters.
Wenn ein Auditor Evidenz verlangt, können Sie ihm keine Quittung überreichen und sagen „Verifizieren Sie es selbst.“ Sie müssen sagen: „Melden Sie sich in unserem Azure-Portal an, navigieren Sie zu diesem Endpoint, authentifizieren Sie sich mit diesen Anmeldedaten und rufen Sie diese API auf.“ Das ist keine unabhängige Verifizierung — das ist anbietervermittelte Verifizierung.
Drei Wege, wie Lock-in Integrität untergräbt
Das Lock-in-Problem manifestiert sich auf drei konkrete Weisen, die das Wertversprechen verwalteter Ledger aushöhlen:
- Verifizierungsabhängigkeit: Dritte Prüfer, Regulierer und Partner benötigen Cloud-Anmeldedaten, um Ihre Daten zu validieren. Das erzeugt Reibung, Sicherheitsbedenken und einen Single Point of Failure.
- Dienstabschaltungsrisiko: AWS hat QLDB nach 6 Jahren abgeschaltet. Jeder verwaltete Ledger trägt dieses Risiko. Wenn der Dienst stirbt, werden Ihre Nachweise unzugänglich — möglicherweise genau dann, wenn Sie sie am dringendsten brauchen.
- Multi-Cloud-Unmöglichkeit: Wenn Sie über AWS und Azure hinweg arbeiten (wie viele Unternehmen), deckt kein einzelner Cloud-Ledger beide ab. Sie enden mit fragmentierter Integrität — einige Datensätze auf einer Cloud nachweisbar, andere auf einer anderen, keiner universell verifizierbar.
Die wahren Kosten intransparenter Verifizierung
Das Lock-in-Problem ist nicht nur architektonischer Natur — es hat direkte Geschäftskosten. Wenn Verifizierung Plattformzugang erfordert, wird jede Integritätsprüfung zu einer Abhängigkeitskette: Authentifizierung, Netzwerkkonnektivität, API-Verfügbarkeit und Abonnementstatus.
Bei Incident Response, Streitbeilegung oder regulatorischer Prüfung bringt diese Abhängigkeitskette Latenz und Risiko genau im falschen Moment ein. Die Frage verschiebt sich von „Können wir beweisen, dass diese Daten nicht verändert wurden“ zu „Können wir alle auf der richtigen Plattform authentifizieren, um es zu prüfen.“
Wie herstellerunabhängige Verifizierung aussieht
Die Alternative sind Nachweise, die auf Infrastruktur leben, die kein einzelnes Unternehmen kontrolliert. Öffentliche Blockchains bieten dies: Sobald eine Merkle-Root On-Chain verankert ist, kann sie von jedem mit einem Browser und Block-Explorer verifiziert werden.
Kombiniert mit inhaltsadressiertem Speicher wie IPFS für Manifeste und Metadaten entsteht ein Verifizierungspfad, der nicht von der API, dem Abonnement oder der Fortexistenz eines Anbieters abhängt. Der Nachweis ist der Nachweis — kein Verweis auf den Dienst eines Anbieters.
Wann Lock-in am gefährlichsten ist
Cloud-Ledger-Lock-in ist in diesen Szenarien besonders gefährlich:
- Regulatorische Prüfungen — Wenn ein Regulierer Evidenz für Datenintegrität verlangt, muss der Nachweis unabhängig verifizierbar sein — nicht abhängig davon, dass Ihr Cloud-Abonnement aktiv und Ihre API-Schlüssel gültig sind.
- Streitigkeiten zwischen mehreren Parteien — Wenn zwei Parteien sich über den Inhalt eines Datensatzes uneinig sind, muss der Nachweis neutral sein. Wenn er im Cloud-Konto einer Partei liegt, hat die andere keinen Grund, ihm zu vertrauen.
- Langzeitarchivierung — Regulatorische Aufbewahrungsanforderungen erstrecken sich über 7-10+ Jahre. Kein Cloud-Dienst hat eine Erfolgsbilanz garantierter Verfügbarkeit in diesem Zeitrahmen. QLDB existierte 6 Jahre.
Integrität statt Bequemlichkeit wählen
Verwaltete Cloud-Ledger sind bequem. Sie integrieren sich nahtlos in bestehende Cloud-Infrastruktur. Aber Bequemlichkeit ist die falsche Optimierung für Integrität. Der ganze Sinn manipulationssicherer Datensätze ist, dass der Nachweis feindliche Bedingungen überstehen muss — einschließlich der Bedingung, dass der Dienstanbieter den Markt verlässt. Wenn Ihr Integritätsnachweis die fortgesetzte Kooperation eines Dritten erfordert, ist er kein Nachweis. Er ist ein Versprechen.
Wenn Ihr Nachweis der Datenintegrität erfordert, dass die API des Anbieters läuft, ist es kein Nachweis — es ist ein Versprechen. Versprechen verfallen. Mathematik nicht.