Quasi ogni organizzazione cloud-native si presenta a una valutazione del livello di evidenza con la stessa frase di apertura: gia loggiamo tutto su CloudTrail, o Stackdriver, o Azure Monitor — cosa ci da Certyo che quelli non danno? E una domanda giusta e merita una risposta strutturale invece che di marketing. La risposta onesta e che i log operativi e le prove di integrita sono categorie diverse di artefatto, progettate per lavori diversi, con proprieta di fiducia strutturalmente incompatibili. Gli stessi dati possono essere in entrambi, ma gli stessi dati non ti danno la stessa difendibilita.
Per cosa sono progettati i log operativi
CloudTrail, Stackdriver e Azure Monitor sono stati costruiti per rispondere a domande come: quale chiamata API ha fatto il nostro servizio alle 03:14 UTC, qual e stata la risposta, quale principale IAM l'ha avviata. Il lavoro e visibilita operativa — debugging, alerting, pianificazione capacita, indagine sicurezza. Sono strumenti eccellenti per quei lavori.
I vincoli di design che li rendono eccellenti per le operazioni li rendono anche inadatti per le prove. I log operativi sono progettati per essere conservati per una finestra, ruotati, riprodotti, indicizzati, interrogati e occasionalmente redatti. Nessuna di quelle operazioni e un problema per il lavoro operativo. Tutte sono problemi per il lavoro di prova.
Tre differenze strutturali che contano al momento dell'audit
Quando un auditor, regolatore o avvocato avversario contesta un record, la conversazione passa dalla visibilita operativa alla difendibilita forense. A quel punto tre differenze strutturali tra log operativi e prova di integrita diventano decisive:
- Stesso dominio di fiducia — i tuoi log CloudTrail sono scritti, conservati e letti da account dentro la tua organizzazione AWS. Il log di audit del log di audit vive nello stesso posto. Un insider determinato con privilegi sufficienti puo mutare il trail e mutare il trail delle mutazioni. La prova richiede un confine di fiducia fuori dal sistema che ha prodotto i dati.
- Mutation-friendly per policy — le finestre di retention dei log fanno scadere i record per design. Le policy di lifecycle spostano i record in storage freddo e alla fine li cancellano. Sono feature per le operazioni e bug per le prove. Un record che non puoi produrre su richiesta al momento dell'audit non e una prova; e un log passato.
- Nessun percorso di verifica per terze parti — quando consegni un export CloudTrail a un auditor, l'auditor deve fidarsi che l'export sia fedele all'originale. Non c'e primitiva crittografica che permetta a un regolatore di verificare l'export contro un riferimento immutabile senza la tua cooperazione. I log operativi sono affermazioni; le prove sono claim verificabili indipendentemente.
Cosa cambia quando l'integrita viene ancorata esternamente
L'ancoraggio esterno — cio che Certyo fa su Polygon — non e un sostituto di CloudTrail. E un artefatto diverso che affronta i tre gap strutturali sopra. I record vengono hashati, accumulati, raggruppati in batch, e la radice Merkle di ogni batch viene scritta su una chain pubblica. Tre proprieta seguono da quel design:
Primo, il confine di fiducia si sposta fuori dal tuo account: la radice Merkle on-chain non puo essere modificata da nessuno, incluso il team che gestisce Certyo. Secondo, l'ancora non e soggetta a policy di retention: persiste indefinitamente come proprieta della chain, non come proprieta del tuo abbonamento. Terzo, la verifica non richiede la tua partecipazione: un regolatore con il record originale e il riferimento on-chain puo confermare indipendentemente che il record e stato ancorato al timestamp originale.
Dove i due artefatti si completano
Il modello mentale corretto non e CloudTrail-o-Certyo. E CloudTrail-e-Certyo, con ogni artefatto che fa il suo lavoro. La pipeline operativa continua a fare cio che fa bene; la pipeline di prove gira accanto, ancorando i record che devono sopravvivere a audit, dispute o contenzioso:
Al momento dell'audit, CloudTrail risponde a "cosa e successo operativamente" e l'ancora di integrita risponde a "e i record risultanti da quelle operazioni sono invariati". I due artefatti rispondono a domande diverse e le risposte si compongono. Un auditor che vede solo CloudTrail ha una storia; un auditor che vede CloudTrail piu un record ancorato ha una storia piu un claim verificabile.
Tre scenari di acquirente dove la distinzione e decisiva
Se la differenza tra log operativi e prove suona accademica, tende a diventare urgente in tre scenari specifici. Sono gli scenari dove la posizione "CloudTrail basta" fallisce sul campo:
- Indagini su minacce interne — Quando un regolatore o assicuratore indaga su possibile manomissione da parte di insider, i log che vivono nello stesso dominio di fiducia dell'attore sospetto non possono essere usati per smentire la manomissione. L'investigatore ha bisogno di un artefatto che l'attore dimostrabilmente non poteva modificare. CloudTrail non raggiunge questa asticella; un'ancora esterna si.
- Dispute pluriennali — Quando una disputa su un record di tre anni fa emerge oggi, la domanda e se il record puo essere prodotto nella sua forma originale. La retention di CloudTrail puo aver fatto scadere la voce. L'ancora di integrita su una chain pubblica non ha finestra di retention. I record che puoi hashare oggi contro l'ancora originale sono ancora verificabili.
- Audit cross-vendor — Quando un auditor deve verificare un record prodotto dal tuo servizio contro record di un partner o controparte, l'auditor non puo chiedere a entrambe le organizzazioni di condividere i loro CloudTrail. Puo chiedere a entrambe di condividere l'hash ancorato e verificare contro lo stesso riferimento on-chain. L'audit cross-vendor e strutturalmente piu facile quando la primitiva di verifica e indipendente da qualsiasi fornitore.
Cosa fare quando l'obiezione emerge in una vendita
La risposta corretta a "usiamo gia CloudTrail" non e argomentare che CloudTrail e cattivo. E eccellente in cio che fa. La risposta corretta e chiedere quale dei tre gap strutturali l'acquirente accetterebbe nello scenario peggiore: un insider determinato che muta il log di audit, una policy di retention che fa scadere un record contestato, un auditor che non puo verificare senza la tua cooperazione. Se la risposta e nessuna, CloudTrail da solo non e lo strumento giusto per quella parte del workload. Per come Certyo gira accanto all'infrastruttura di log esistente, vedi /it/about. Per la primitiva di verifica in dettaglio, vedi /it/blog/blockchain-without-crypto.
CloudTrail ti dice cosa e successo. Un'ancora di integrita permette a una terza parte di verificare che il record di cosa e successo non e cambiato. Stessi dati, proprieta di fiducia strutturalmente diversa. I due artefatti rispondono a domande diverse e ne servono entrambi al momento dell'audit.