Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vérification des données sur Amazon QLDB

Avec AmazonQLDB, vous pouvez être sûr que l'historique des modifications apportées aux données de votre application est exact. QLDButilise un journal transactionnel immuable, appelé journal, pour le stockage des données. Le journal suit chaque modification apportée à vos données enregistrées et conserve un historique complet et vérifiable des modifications au fil du temps.

QLDButilise la fonction de hachage SHA -256 avec un modèle basé sur l'arbre de Merkle pour générer une représentation cryptographique de votre journal, connue sous le nom de résumé. Le condensé agit comme une signature unique de l'historique complet des modifications de vos données à un moment donné. Vous utilisez le résumé pour vérifier l'intégrité des révisions de votre document par rapport à cette signature.

Dans quel type de données pouvez-vous vérifier QLDB ?

DansQLDB, chaque registre contient exactement un journal. Un journal peut comporter plusieurs volets, qui sont des partitions du journal.

Un bloc est un objet qui est inscrit dans le volet journal lors d'une transaction. Ce bloc contient des objets d'entrée, qui représentent les révisions du document résultant de la transaction. Vous pouvez vérifier une révision individuelle ou un bloc de journal complet dansQLDB.

Le schéma suivant illustre cette structure de journal.

Le diagramme montre que les transactions sont enregistrées dans le journal sous forme de blocs contenant des entrées de révision de documents. Cela montre également que chaque bloc est enchaîné par hachage aux blocs suivants et possède un numéro de séquence pour spécifier son adresse dans le brin.

Pour plus d'informations sur le contenu des données d'un bloc, consultezContenu du journal sur Amazon QLDB.

Que signifie l'intégrité des données ?

L'intégrité des données QLDB signifie que le journal de votre registre est en fait immuable. En d'autres termes, vos données (en particulier, chaque révision de document) sont dans un état dans lequel les conditions suivantes sont vraies :

Comment fonctionne la vérification ?

Pour comprendre le fonctionnement de la vérification sur AmazonQLDB, vous pouvez décomposer le concept en quatre éléments de base.

Hachage

QLDButilise la fonction de hachage cryptographique SHA -256 pour créer des valeurs de hachage de 256 bits. Un hachage agit comme une signature unique et de longueur fixe de toute quantité arbitraire de données d'entrée. Si vous modifiez une partie de l'entrée, ne serait-ce qu'un seul caractère ou un seul bit, le hachage de sortie change complètement.

Le schéma suivant montre que la fonction de hachage SHA -256 crée des valeurs de hachage totalement uniques pour deux QLDB documents qui ne diffèrent que d'un chiffre.

La fonction de hachage SHA -256 est unidirectionnelle, ce qui signifie qu'il n'est pas mathématiquement possible de calculer l'entrée lorsqu'une sortie est donnée. Le schéma suivant montre qu'il n'est pas possible de calculer le QLDB document d'entrée lorsqu'on lui donne une valeur de hachage en sortie.

Les entrées de données suivantes sont hachées à des QLDB fins de vérification :

Digest

Un résumé est une représentation cryptographique de l'intégralité du journal de votre registre à un moment donné. Un journal est uniquement en ajout, et les blocs de journal sont séquencés et hachés de la même manière que les blockchains.

Vous pouvez demander un résumé pour un registre à tout moment. QLDBgénère le résumé et vous le renvoie sous forme de fichier de sortie sécurisé. Vous utilisez ensuite ce résumé pour vérifier l'intégrité des révisions de documents qui ont été validées à un moment antérieur. Si vous recalculez les hachages en commençant par une révision et en terminant par le résumé, vous prouvez que vos données n'ont pas été modifiées entre les deux.

Arbre Merkle

À mesure que la taille de votre registre augmente, il devient de plus en plus inefficace de recalculer la chaîne de hachage complète du journal à des fins de vérification. QLDButilise un modèle d'arbre de Merkle pour remédier à cette inefficacité.

Un arbre Merkle est une structure de données arborescente dans laquelle chaque nœud de feuille représente le hachage d'un bloc de données. Chaque nœud autre qu'une feuille est un hachage de ses nœuds enfants. Couramment utilisé dans les chaînes de blocs, un arbre Merkle vous aide à vérifier efficacement de grands ensembles de données grâce à un mécanisme de preuve d'audit. Pour plus d'informations sur les arbres Merkle, consultez la page Wikipédia sur les arbres Merkle. Pour en savoir plus sur les preuves d'audit Merkle et pour un exemple de cas d'utilisation, consultez How Log Proofs Work sur le site de transparence des certificats.

L'QLDBimplémentation de l'arbre Merkle est construite à partir de la chaîne de hachage complète d'un journal. Dans ce modèle, les nœuds foliaires sont l'ensemble de tous les hachages de révision de documents individuels. Le nœud racine représente le résumé de l'intégralité du journal à un moment donné.

À l'aide d'une preuve d'audit Merkle, vous pouvez vérifier une révision en vérifiant uniquement un petit sous-ensemble de l'historique des révisions de votre registre. Pour ce faire, vous devez parcourir l'arbre depuis un nœud de feuille donné (révision) jusqu'à sa racine (résumé). Le long de ce chemin de traversée, vous hachez de manière récursive des paires de nœuds frères pour calculer leur hachage parent jusqu'à ce que vous terminiez avec le condensé. Cette traversée a une complexité temporelle en ce qui concerne log(n) les nœuds de l'arbre.

Preuve

La preuve en est la liste ordonnée des hachages de nœuds qui est QLDB renvoyée pour un condensé et une révision de document donnés. Il comprend les hachages requis par un modèle d'arbre Merkle pour enchaîner le hachage du nœud feuille donné (une révision) au hachage racine (le condensé).

La modification de données validées entre une révision et un résumé rompt la chaîne de hachage de votre journal et rend impossible la génération d'une preuve.

Exemple de vérification

Le schéma suivant illustre le modèle d'arbre de QLDB hachage Amazon. Il montre un ensemble de hachages de blocs qui s'enroulent jusqu'au nœud racine supérieur, qui représente le condensé d'un fil de journal. Dans un registre comportant un journal à un seul brin, ce nœud racine est également le condensé de l'ensemble du registre.

Supposons que le nœud A soit le bloc contenant la révision du document dont vous souhaitez vérifier le hachage. Les nœuds suivants représentent la liste ordonnée des hachages QLDB fournie dans votre preuve : B, E, G. Ces hachages sont nécessaires pour recalculer le condensé à partir du hachage A.

Pour recalculer le résumé, procédez comme suit :

La vérification est réussie si votre résumé recalculé correspond à la valeur attendue. À partir d'un hachage de révision et d'un résumé, il n'est pas possible de rétroconcevoir les hachages dans une preuve. Par conséquent, cet exercice prouve que votre révision a bien été écrite à cet emplacement de journal par rapport au condensé.

Quel est l'impact de la suppression des données sur la vérification ?

Sur AmazonQLDB, une DELETE instruction ne supprime logiquement un document qu'en créant une nouvelle révision qui le marque comme supprimé. QLDBprend également en charge une opération de rédaction de données qui vous permet de supprimer définitivement les révisions de document inactives dans l'historique d'un tableau.

L'opération de rédaction supprime uniquement les données utilisateur dans la révision spécifiée et laisse inchangées la séquence du journal et les métadonnées du document. Une fois qu'une révision est expurgée, les données utilisateur de la révision (représentées par la data structure) sont remplacées par un nouveau dataHash champ. La valeur de ce champ est le hachage Amazon Ion de la data structure supprimée. Pour plus d'informations et un exemple d'opération de rédaction, consultezRédaction de révisions de documents.

Par conséquent, le registre conserve l'intégrité globale de ses données et reste vérifiable cryptographiquement par le biais des opérations de vérification existantes. API Vous pouvez toujours utiliser ces API opérations comme prévu pour demander un condensé (GetDigest), demander une preuve (GetBlockou GetRevision), puis exécuter votre algorithme de vérification à l'aide des objets renvoyés.

Recalculer un hachage de révision

Si vous envisagez de vérifier une révision individuelle d'un document en recalculant son hachage, vous devez vérifier de manière conditionnelle si la révision a été expurgée. Si la révision a été supprimée, vous pouvez utiliser la valeur de hachage fournie dans le dataHash champ. S'il n'a pas été expurgé, vous pouvez recalculer le hachage en utilisant le champ. data

En effectuant cette vérification conditionnelle, vous pouvez identifier les révisions expurgées et prendre les mesures appropriées. Par exemple, vous pouvez enregistrer les événements de manipulation de données à des fins de surveillance.

Commencer à utiliser la vérification

Avant de pouvoir vérifier les données, vous devez demander un résumé à partir de votre registre et l'enregistrer pour plus tard. Toute révision de document validée avant le dernier bloc couvert par le résumé peut être vérifiée par rapport à ce résumé.

Ensuite, vous demandez une preuve à Amazon QLDB pour une révision éligible que vous souhaitez vérifier. À l'aide de cette preuve, vous appelez un client API pour recalculer le résumé, en commençant par le hachage de votre révision. Tant que le résumé précédemment enregistré est connu et fiable à l'extérieurQLDB, l'intégrité de votre document est prouvée si le hachage du résumé recalculé correspond au hachage du résumé enregistré.

Pour obtenir step-by-step des guides sur la façon de demander un résumé à partir de votre registre, puis de vérifier vos données, consultez ce qui suit :