Le valutazioni del livello di evidenza spendono tempo sproporzionato sulla chain — Polygon vs Ethereum vs chain privata, finalita, gas, neutralita del fornitore. Queste domande contano, ma non sono la domanda di sicurezza portante. La domanda portante e: chi controlla le chiavi che firmano i record prima che siano hashati e ancorati? Un KMS — Key Management Service, il sistema che custodisce e usa chiavi crittografiche per tuo conto, con AWS KMS, Azure Key Vault e HashiCorp Vault come prodotti comuni — e cio che risponde a quella domanda. Se il KMS e compromesso, la blockchain piu forte del mondo ancorera fedelmente record gia sbagliati. La chain e un testimone; il KMS e l'autore. Questo post e per architetti di sicurezza che devono pensare con chiarezza a dove vive il vero confine di fiducia.
Perche la chain non e il confine di sicurezza
Il lavoro di una radice Merkle ancorata e dimostrare che un batch specifico di record e esistito in un momento specifico e non e cambiato da allora. E eccellente in quel lavoro. Cio che non puo fare e dimostrare che i record erano corretti nel momento in cui sono stati creati. L'ancoraggio e integrita nel tempo, non autenticita all'origine.
La domanda di autenticita all'origine si risponde con la firma — tipicamente un record viene firmato con una chiave privata controllata dal sistema o dalla persona che l'ha creato, e il record firmato e cio che viene hashato e ancorato. Se la chiave di firma e compromessa, qualunque cosa venga firmata e dimostrabilmente creata dal possessore della chiave, indipendentemente dal fatto che il possessore sia chi dice di essere. La chain non vede questa distinzione. Ancora cio che le viene dato.
Tre modalita di guasto che la chain non intercetta
Se il KMS e il confine di sicurezza, la domanda diventa quali guasti relativi al KMS risultano in record ancorati-ma-sbagliati. Tre modalita compaiono coerentemente nelle revisioni di sicurezza:
- Compromissione della chiave — un attaccante ottiene la chiave di firma e crea record che sembrano legittimi. La chain li ancora fedelmente. Il recupero forense richiede di identificare la finestra di compromissione e revocare tutti i record ancorati firmati durante quella finestra. L'ancora di integrita dimostra che esistevano; non dimostra che fossero autentici.
- Migrazione di custodia chiavi — il tuo team ruota da un KMS a un altro, o migra tra fornitori cloud, e la rotazione non preserva la catena di attestazioni che lega chiavi vecchie e nuove. I record firmati con la chiave vecchia restano verificabili, ma la narrazione di audit richiede documentazione esplicita del lignaggio delle chiavi. Senza di essa, il gap e sfruttabile in contenzioso.
- Estrazione chiave da insider — un operatore privilegiato estrae il materiale di chiave stesso, non solo la capacita di firmare. I record successivi creati con la chiave estratta sono indistinguibili dagli autentici a livello di chain. La difesa sono chiavi supportate da HSM che non possono essere estratte, non rilevamento dopo il fatto.
Perche self-hosted con il tuo KMS e strutturalmente diverso
La scelta architetturale tra livelli di evidenza gestiti e self-hosted viene spesso inquadrata come domanda operativa: chi gestisce il cluster. La lente del KMS la riformula come domanda di sicurezza: chi controlla le chiavi. In un servizio di evidenza gestito, il KMS del fornitore firma i record per tuo conto. Il fornitore non puo leggere i record, ma la compromissione del fornitore e la tua compromissione. In un deployment self-hosted, le chiavi vivono nel tuo KMS — AWS KMS nel tuo account, Azure Key Vault nel tuo tenant, HashiCorp Vault nel tuo cluster, o un HSM nel tuo data center. Una compromissione del fornitore non e la tua compromissione.
Non e una preferenza astratta. Per workload regolamentati sotto HIPAA, PCI-DSS, FedRAMP, o qualsiasi framework che definisca la custodia delle chiavi come obiettivo di controllo, la domanda di quale KMS e la risposta a un requisito di compliance, non una preferenza di deployment. La SKU self-hosted esiste perche la risposta di audit "le mie chiavi sono nel mio KMS" e materialmente diversa da "il KMS del mio fornitore firma i record per mio conto".
Come Certyo si integra con il KMS che gia gestisci
La realta operativa e che la maggior parte delle organizzazioni regolamentate ha gia una strategia KMS e non ne vuole una nuova. Certyo e progettato per integrarsi con le opzioni standard invece di introdurne una propria. I punti di integrazione sono ben definiti indipendentemente da quale KMS gestisce l'organizzazione:
AWS KMS, Azure Key Vault, GCP Cloud KMS e HashiCorp Vault sono tutti supportati via API di firma standard. Le chiavi supportate da HSM sono supportate via PKCS#11 per ambienti che richiedono custodia fisica delle chiavi. L'integrazione e configurabile per tenant, quindi workload diversi all'interno dello stesso deployment Certyo possono usare strategie di firma diverse — un workflow di routine puo usare chiavi software mentre un workflow ad alto rischio usa chiavi HSM, e la chain ancora entrambi indistintamente.
Tre workload dove la scelta di KMS e decisiva
La scelta di KMS conta di piu per alcuni workload che per altri. Il pattern e coerente: piu alto e il requisito di garanzia sull'autenticita, piu il KMS domina l'analisi di sicurezza:
- Record clinici sanitari — Quando un record clinico viene successivamente contestato — l'allergia e stata annotata prima della prescrizione, o retro-datata dopo l'evento avverso — la domanda e chi l'ha creato e se l'identita di chi crea puo essere impersonata. Chiavi supportate da HSM con provenienza attestata da hardware sono la difesa piu pulita. L'ancora di chain dimostra che il record e esistito al timestamp; la firma fatta da HSM dimostra l'identita.
- Transazioni finanziarie ad alto rischio — Bonifici, eventi di settlement e record di pagamento soggetti a dispute beneficiano della separazione dei compiti imposta a livello di chiave. La firma a due chiavi con catene di custodia separate rende la compromissione da insider materialmente piu difficile. La chain ancora il risultato; lo schema di firma multi-chiave e cio che rende il risultato affidabile.
- Difesa e operazioni classificate — I workload che non possono accettare alcun fornitore nel percorso di custodia delle chiavi richiedono HSM completamente air-gapped senza interfacce di gestione remota. Certyo self-hosted con HSM on-prem e una delle poche architetture di livello di evidenza che supporta questa postura. Le chiavi non lasciano mai hardware controllato dall'organizzazione operante; l'ancora di chain e l'unico artefatto che attraversa il confine.
Come valutare un fornitore sulla strategia KMS
Quando esamini qualsiasi fornitore di livello di evidenza, le domande giuste non riguardano la chain. Riguardano le chiavi. Dove vivono le chiavi di firma di default? Si puo richiedere al fornitore di usare il KMS dell'acquirente? La custodia HSM e disponibile, e tramite quale standard? Cosa succede ai record ancorati se una chiave viene compromessa — si possono marcare-revocare record specifici senza invalidare il resto? Un fornitore che risponde a queste domande con chiarezza capisce cosa sia davvero il suo livello di evidenza. Un fornitore che pivota indietro alla selezione della chain sta vendendo un testimone senza autore. Per le topologie di deployment che preservano la sovranita del KMS, vedi /it/about. Per il malinteso sui record on-chain, vedi /it/blog/records-not-on-blockchain. Per il rischio di concentrazione nel livello chain, vedi /it/blog/evidence-layer-concentration-risk.
La chain e un testimone; il KMS e l'autore. Se l'autore e compromesso, il testimone racconta comunque una storia fedele — e la storia e sbagliata. La sicurezza del livello di evidenza vive nel KMS, non nella chain.