Ogni grande cloud provider ha provato a venderti un servizio ledger gestito. AWS aveva QLDB (ora morto). Microsoft ha Azure Confidential Ledger. Il pitch e sempre lo stesso: noi gestiamo la crittografia, tu ottieni record a prova di manomissione. Sembra un problema risolto. Ma c'e una trappola nascosta nell'architettura — e diventa visibile solo quando provi a usare queste prove al di fuori del cloud che le ha create.
La promessa vs. le clausole in piccolo
I ledger cloud gestiti forniscono vera integrita crittografica. Eseguono l'hash dei tuoi dati, concatenano i blocchi e rilasciano ricevute. La matematica e reale. Ma il percorso di verifica passa attraverso l'API del cloud provider. La tua prova e accessibile solo quanto l'endpoint del servizio del vendor.
Quando un auditor chiede evidenze, non puoi consegnargli una ricevuta e dire "verificala tu stesso". Devi dire: "Accedi al nostro portale Azure, vai a questo endpoint, autenticati con queste credenziali e chiama questa API." Questa non e verifica indipendente — e verifica mediata dal vendor.
Tre modi in cui il lock-in mina l'integrita
Il problema del lock-in si manifesta in tre modi concreti che erodono la proposta di valore dei ledger gestiti:
- Dipendenza dalla verifica: auditor terzi, regolatori e partner necessitano di credenziali cloud per validare i tuoi dati. Questo crea attrito, preoccupazioni di sicurezza e un singolo punto di fallimento.
- Rischio di discontinuita del servizio: AWS ha chiuso QLDB dopo 6 anni. Ogni ledger gestito porta questo rischio. Quando il servizio muore, le tue prove diventano inaccessibili — potenzialmente proprio quando ne hai piu bisogno.
- Impossibilita multi-cloud: se operi su AWS e Azure (come fanno molte aziende), nessun singolo ledger cloud copre entrambi. Ti ritrovi con integrita frammentata — alcuni record dimostrabili su un cloud, altri su un altro, nessuno universalmente verificabile.
Il vero costo della verifica opaca
Il problema del lock-in non e solo architetturale — ha costi di business diretti. Quando la verifica richiede accesso alla piattaforma, ogni controllo di integrita diventa una catena di dipendenze: autenticazione, connettivita di rete, disponibilita dell'API e stato della sottoscrizione.
Nella risposta agli incidenti, nella risoluzione delle controversie o negli esami regolamentari, questa catena di dipendenze introduce latenza e rischio esattamente nel momento sbagliato. La domanda si sposta da "possiamo dimostrare che questo dato non e stato alterato" a "riusciamo a far autenticare tutti sulla piattaforma giusta per verificare".
Com'e la verifica vendor-neutral
L'alternativa e una prova che risiede su un'infrastruttura che nessuna singola azienda controlla. Le blockchain pubbliche forniscono questo: una volta che una radice Merkle e ancorata on-chain, e verificabile da chiunque con un browser e un block explorer.
Combinata con archiviazione content-addressed come IPFS per manifesti e metadati, questo crea un percorso di verifica che non dipende dall'API di alcun vendor, dalla sottoscrizione o dalla sua continuita operativa. La prova e la prova — non un puntatore al servizio di un vendor.
Quando il lock-in conta di piu
Il lock-in dei ledger cloud e particolarmente pericoloso in questi scenari:
- Esami regolamentari — Quando un regolatore richiede evidenza di integrita dei dati, la prova deve essere verificabile indipendentemente — non dipendere dalla tua sottoscrizione cloud attiva e dalle tue chiavi API valide.
- Controversie tra piu parti — Quando due parti non concordano sul contenuto di un record, la prova deve essere neutrale. Se risiede nell'account cloud di una parte, l'altra parte non ha motivo di fidarsi.
- Archiviazione a lungo termine — I requisiti di conservazione regolamentare si estendono per 7-10+ anni. Nessun servizio cloud ha un track record di disponibilita garantita su quel periodo. QLDB e durato 6.
Scegliere l'integrita rispetto alla comodita
I ledger cloud gestiti sono comodi. Si integrano perfettamente con l'infrastruttura cloud esistente. Ma la comodita e l'ottimizzazione sbagliata per l'integrita. Lo scopo dei record a prova di manomissione e che la prova deve sopravvivere a condizioni avverse — inclusa la condizione in cui il fornitore del servizio esce dal mercato. Se la tua prova di integrita richiede la cooperazione continua di una terza parte, non e realmente una prova. E una promessa.
Se la tua prova di integrita dei dati richiede che l'API del vendor sia attiva, non e una prova — e una promessa. Le promesse scadono. La matematica no.