Una volta che un team accetta di aver bisogno di un'integrità dei registri verificabile in modo indipendente, la domanda successiva è operativa, non crittografica: la gestiamo noi o la facciamo gestire a qualcun altro? Entrambi i modelli producono la stessa prova — una radice di Merkle ancorata a una chain pubblica che chiunque può verificare. Ciò che cambia è chi detiene le chiavi, dove risiedono i dati e chi tiene il cercapersone. Questa guida espone i compromessi affinché arriviate alla trattativa già sapendo quale modello fa al caso vostro.
I due modelli in un paragrafo ciascuno
Self-hosted significa che la piattaforma di integrità gira all'interno della vostra infrastruttura — il vostro cluster Kubernetes, il vostro account cloud o data center, il vostro key management service. La gestite voi; il fornitore concede in licenza il software e vi assiste. Gestito significa che il fornitore esegue la piattaforma come istanza dedicata e single-tenant sulla propria infrastruttura, e voi vi integrate tramite API. In entrambi i casi il bersaglio dell'ancoraggio è la stessa chain pubblica, e le prove sono verificabili da terze parti in entrambi i modelli.
L'istinto secondo cui il self-hosted è «più sicuro» e il gestito è «più facile» è troppo grossolano per decidere. La vera scelta si gioca su quattro assi concreti, e per la maggior parte delle organizzazioni uno o due di essi prevalgono.
I quattro assi che decidono davvero
Valutate la vostra situazione su ciascuno di essi. Se anche solo uno è un vincolo rigido, di norma risolve la questione da solo:
- Residenza dei dati — se una norma o un contratto impone che i dati dei registri non lascino mai il vostro ambiente o una giurisdizione specifica, il self-hosted elimina del tutto la questione. Il gestito può spesso soddisfare la residenza con istanze dedicate regionali, ma diventa una clausola da negoziare anziché un dato architetturale.
- Custodia delle chiavi — chi detiene la chiave di firma è il vero confine di sicurezza. Il self-hosted la mantiene nel vostro KMS sotto il vostro IAM. Il gestito la custodisce per vostro conto in un KMS isolato e single-tenant. Se «dobbiamo essere l'unica parte che possa mai detenere la chiave» è irrinunciabile, ciò indirizza verso il self-hosted.
- Capacità operativa — il self-hosted significa gestire un signer in alta disponibilità, occuparsi della rotazione delle chiavi e del pinning dei pacchetti di prova. Se non disponete di un platform team con capacità in eccesso, il gestito trasforma quegli obblighi nell'SLA di qualcun altro.
Cosa riflette la differenza di prezzo
I due modelli hanno prezzi diversi perché la struttura di costo è diversa, non perché uno sia uno sconto sull'altro. Il gestito include l'infrastruttura, l'uptime e il lavoro operativo. Il self-hosted è una licenza su software che eseguite su hardware che già pagate.
Il self-hosted ha un prezzo di listino più alto proprio perché non include le operazioni che vi assumete in proprio — e perché chi lo richiede è in genere chi ha i mandati più stringenti su residenza e custodia. Se il vostro driver è puramente il costo, il gestito è quasi sempre il minor costo totale di possesso, una volta che mettete onestamente a prezzo il vostro lavoro operativo.
Come scorre la decisione nella pratica
Per la maggior parte dei team il percorso è breve. Percorrete gli assi nell'ordine e fermatevi al primo vincolo rigido:
Una banca regolamentata con una politica «i dati restano nel nostro tenant» approda al self-hosted prima ancora che il costo entri nella conversazione. Una scale-up del settore sanitario che desidera la garanzia di integrità senza tirare su un altro servizio in alta disponibilità approda al gestito e negozia un BAA. La maggior parte delle organizzazioni rientra in uno di questi due casi; sono le situazioni intermedie quelle in cui una conversazione vera aiuta.
Quale profilo si addice a quale modello
Come mappa di massima — non come regola — i profili regolamentati tendono a raggrupparsi così:
- Il self-hosted si addice a — grandi banche, enti pubblici e qualunque organizzazione con mandati assoluti di residenza dei dati o di custodia esclusiva delle chiavi e un platform team capace.
- Il gestito si addice a — scale-up fintech e sanitarie, team di audit e compliance e chiunque voglia la garanzia senza dover gestire un altro servizio stateful.
- Entrambi vanno bene per — aziende mid-market con requisiti moderati — qui la decisione è davvero una questione di costo e preferenza, e un pilota la risolve più in fretta.
Portate la risposta, non la domanda
Poiché entrambi i modelli sono solo su preventivo, la conversazione più rapida è quella in cui conoscete già i vostri vincoli di residenza e di custodia delle chiavi e la vostra capacità operativa. Con queste tre risposte in mano, il modello di deployment è di solito ovvio nel giro di una frase, e la discussione che resta riguarda volumi e tempistiche anziché architettura. Se siete genuinamente indecisi tra i due, un pilota circoscritto sull'istanza gestita è il modo più economico per capire di cosa avete davvero bisogno prima di impegnarvi a gestirlo voi stessi.
Entrambi i modelli producono la stessa prova. La scelta non riguarda la crittografia — riguarda chi detiene la chiave, dove risiedono i dati e chi tiene il cercapersone.