Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Verifica dei dati in Amazon QLDB
Importante
Avviso di fine del supporto: i clienti esistenti potranno utilizzare Amazon QLDB fino alla fine del supporto il 31/07/2025. Per ulteriori dettagli, consulta Migrare un Amazon QLDB Ledger ad Amazon Aurora Postgre
Con AmazonQLDB, puoi stare certo che la cronologia delle modifiche ai dati delle tue applicazioni sia accurata. QLDButilizza un registro transazionale immutabile, noto come journal, per l'archiviazione dei dati. Il diario tiene traccia di ogni modifica ai dati impegnati e mantiene una cronologia completa e verificabile delle modifiche nel tempo.
QLDButilizza la funzione hash SHA -256 con un modello basato sull'albero Merkle per generare una rappresentazione crittografica del diario, nota come digest. Il digest funge da firma univoca dell'intera cronologia delle modifiche dei dati a partire da un determinato momento. Il digest viene utilizzato per verificare l'integrità delle revisioni dei documenti relative a tale firma.
Argomenti
- In che tipo di dati puoi verificare? QLDB
- Cosa significa integrità dei dati?
- Come funziona la verifica?
- Esempio di verifica
- In che modo la redazione dei dati influisce sulla verifica?
- Guida introduttiva alla verifica
- Fase 1: Richiedere un digest QLDB
- Fase 2: Verifica dei dati in QLDB
- Risultati della verifica
- Tutorial: verifica dei dati utilizzando un AWS SDK
- Errori comuni di verifica
In che tipo di dati puoi verificare? QLDB
NelQLDB, ogni libro mastro ha esattamente un giornale. Un diario può avere più filoni, che sono partizioni del diario.
Nota
QLDBattualmente supporta solo riviste con un solo filone.
Un blocco è un oggetto che viene inserito nel filamento del journal durante una transazione. Questo blocco contiene oggetti di immissione, che rappresentano le revisioni del documento risultanti dalla transazione. È possibile verificare una singola revisione o un intero blocco del diario in. QLDB
Il diagramma seguente illustra questa struttura del diario.
Il diagramma mostra che le transazioni vengono salvate nel journal come blocchi contenenti le voci di revisione del documento. Mostra anche che ogni blocco è concatenato ad hash ai blocchi successivi e ha un numero di sequenza per specificare il suo indirizzo all'interno del filamento.
Per informazioni sul contenuto dei dati in un blocco, vedere. Contenuti del diario in Amazon QLDB
Cosa significa integrità dei dati?
L'integrità dei dati QLDB significa che il diario del tuo libro mastro è di fatto immutabile. In altre parole, i tuoi dati (in particolare, ogni revisione del documento) si trovano in uno stato in cui sono vere le seguenti condizioni:
-
Esiste nella stessa posizione del diario in cui è stato scritto per la prima volta.
-
Non è stato alterato in alcun modo da quando è stato scritto.
Come funziona la verifica?
Per capire come funziona la verifica in AmazonQLDB, puoi suddividere il concetto in quattro componenti di base.
Hashing
QLDButilizza la funzione hash crittografica SHA -256 per creare valori hash a 256 bit. Un hash funge da firma univoca a lunghezza fissa di qualsiasi quantità arbitraria di dati di input. Se si modifica qualsiasi parte dell'input, anche un singolo carattere o bit, l'hash di output cambia completamente.
Il diagramma seguente mostra che la funzione hash SHA -256 crea valori hash completamente unici per due documenti che differiscono solo di una cifra. QLDB
La funzione hash SHA -256 è unidirezionale, il che significa che non è matematicamente possibile calcolare l'input quando viene fornito un output. Il diagramma seguente mostra che non è possibile calcolare il documento di input quando viene fornito un valore hash di output. QLDB
I seguenti input di dati vengono inseriti con hash a scopo di verifica: QLDB
-
Revisioni del documento
-
Istruzioni PartiQL
-
Voci di revisione
-
Blocchi diario
Digest
Un digest è una rappresentazione crittografica dell'intero diario del registro in un determinato momento. Un diario è di sola aggiunta e i blocchi di journal sono sequenziati e concatenati in hash in modo simile alle blockchain.
Puoi richiedere un riassunto per un libro mastro in qualsiasi momento. QLDBgenera il digest e te lo restituisce come file di output sicuro. Quindi si utilizza tale digest per verificare l'integrità delle revisioni dei documenti eseguite in un momento precedente. Se ricalcola gli hash iniziando con una revisione e terminando con il digest, dimostri che i dati non sono stati alterati nel frattempo.
Albero Merkle
Con l'aumentare delle dimensioni del registro, diventa sempre più inefficiente ricalcolare l'intera catena hash del diario a scopo di verifica. QLDButilizza un modello ad albero Merkle per ovviare a questa inefficienza.
Un albero Merkle è una struttura dati ad albero in cui ogni nodo foglia rappresenta un hash di un blocco di dati. Ogni nodo non foglia è un hash dei suoi nodi figli. Comunemente utilizzato nelle blockchain, un albero Merkle aiuta a verificare in modo efficiente set di dati di grandi dimensioni con un meccanismo a prova di audit. Per ulteriori informazioni sugli alberi Merkle, consulta la pagina Wikipedia di Merkle
L'QLDBimplementazione dell'albero Merkle è costruita a partire dall'intera catena hash di una rivista. In questo modello, i nodi foglia sono l'insieme di tutti gli hash di revisione dei singoli documenti. Il nodo radice rappresenta il riepilogo dell'intero diario a partire da un determinato momento.
Utilizzando una bozza di verifica Merkle, puoi verificare una revisione controllando solo un piccolo sottoinsieme della cronologia delle revisioni del tuo libro mastro. Puoi farlo attraversando l'albero da un determinato nodo fogliare (revisione) alla sua radice (digest). Lungo questo percorso di attraversamento, esegui l'hash ricorsivo di coppie di nodi di pari livello per calcolare l'hash principale fino al termine del digest. Questo attraversamento presenta una complessità temporale dei nodi dell'albero. log(n)
Prova
Una prova è l'elenco ordinato degli hash dei nodi QLDB restituito per un determinato digest e una determinata revisione del documento. Consiste negli hash richiesti da un modello di albero Merkle per concatenare l'hash del nodo foglia specificato (una revisione) all'hash root (il digest).
La modifica dei dati confermati tra una revisione e un digest interrompe la catena di hash del diario e rende impossibile la generazione di una bozza.
Esempio di verifica
Il diagramma seguente illustra il modello di albero QLDB hash di Amazon. Mostra una serie di hash a blocchi che arrivano al nodo principale superiore, che rappresenta il digest di un filone di journal. In un registro con un diario a filamento singolo, questo nodo radice è anche il riepilogo dell'intero registro.
Supponiamo che il nodo A sia il blocco che contiene la revisione del documento di cui desideri verificare l'hash. I seguenti nodi rappresentano l'elenco ordinato di hash QLDB fornito nella dimostrazione: B, E, G. Questi hash sono necessari per ricalcolare il digest dall'hash A.
Per ricalcolare il digest, procedi come segue:
-
Iniziate con l'hash A e concatenatelo con l'hash B. Quindi, esegui l'hash del risultato per calcolare D.
-
Usa D ed E per calcolare F.
-
Usa F e G per calcolare il digest.
La verifica ha esito positivo se il digest ricalcolato corrisponde al valore previsto. Con un hash di revisione e un digest, non è possibile decodificare gli hash in una bozza. Pertanto, questo esercizio dimostra che la revisione è stata effettivamente scritta in questa posizione del diario rispetto al digest.
In che modo la redazione dei dati influisce sulla verifica?
In AmazonQLDB, una DELETE
dichiarazione elimina logicamente un documento solo creando una nuova revisione che lo contrassegna come eliminato. QLDBsupporta anche un'operazione di redazione dei dati che consente di eliminare definitivamente le revisioni inattive dei documenti nella cronologia di una tabella.
L'operazione di redazione elimina solo i dati utente nella revisione specificata e lascia invariati la sequenza del diario e i metadati del documento. Dopo la redazione di una revisione, i dati utente nella revisione (rappresentati dalla data
struttura) vengono sostituiti da un nuovo campo. dataHash
Il valore di questo campo è l'hash Amazon Ion della data
struttura rimossa. Per ulteriori informazioni e un esempio di operazione di redazione, consulta. Redazione delle revisioni dei documenti
Di conseguenza, il registro mantiene l'integrità complessiva dei dati e rimane verificabile crittograficamente attraverso le operazioni di verifica esistenti. API Puoi comunque utilizzare queste API operazioni come previsto per richiedere un digest (GetDigest), richiedere una prova (GetBlocko GetRevision) e quindi eseguire l'algoritmo di verifica utilizzando gli oggetti restituiti.
Ricalcolo dell'hash di revisione
Se intendi verificare la revisione di un singolo documento ricalcolandone l'hash, devi verificare in modo condizionale se la revisione è stata oscurata. Se la revisione è stata redatta, puoi utilizzare il valore hash fornito nel campo. dataHash
Se non è stata oscurata, puoi ricalcolare l'hash utilizzando il campo. data
Eseguendo questo controllo condizionale, puoi identificare le revisioni redatte e intraprendere le azioni appropriate. Ad esempio, è possibile registrare gli eventi di manipolazione dei dati per scopi di monitoraggio.
Guida introduttiva alla verifica
Prima di poter verificare i dati, è necessario richiedere un riepilogo dal registro e salvarlo per utilizzarlo in un secondo momento. Qualsiasi revisione del documento effettuata prima dell'ultimo blocco coperto dal digest è idonea per la verifica rispetto a tale riepilogo.
Quindi, richiedi ad Amazon una prova QLDB di una revisione idonea che desideri verificare. Utilizzando questa prova, chiami un client API per ricalcolare il digest, a partire dall'hash della revisione. Se il digest salvato in precedenza è noto e affidabile anche all'esterno diQLDB, l'integrità del documento è comprovata se l'hash del digest ricalcolato corrisponde all'hash del digest salvato.
Importante
-
Ciò che stai dimostrando in particolare è che la revisione del documento non è stata alterata tra il momento in cui hai salvato questo riassunto e quello in cui hai eseguito la verifica. Puoi richiedere e salvare un digest non appena una revisione che desideri verificare in un secondo momento viene salvata nel diario.
-
Come procedura consigliata, si consiglia di richiedere regolarmente i riassunti e di conservarli lontano dal registro. Determina la frequenza con cui richiedi i riassunti in base alla frequenza con cui esegui le revisioni nel registro.
Per un post dettagliato AWS sul blog che illustra il valore della verifica crittografica nel contesto di un caso d'uso realistico, consulta la verifica crittografica nel mondo reale con Amazon
. QLDB
Per step-by-step guide su come richiedere un riepilogo dal registro e quindi verificare i dati, consulta quanto segue: