Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Blockchain avec AWS
  3. Mise en œuvre de Quantum Ledger Database
Extrait - Blockchain avec AWS Développez votre chaîne de blocs avec les services web d'Amazon
Extraits du livre
Blockchain avec AWS Développez votre chaîne de blocs avec les services web d'Amazon Revenir à la page d'achat du livre

Mise en œuvre de Quantum Ledger Database

Introduction

Les avantages des chaînes de blocs sans leur caractère distribué, c’est ce que propose Amazon avec Quantum Ledger Database (QLDB). De prime abord, on peut se demander à quoi ça sert. Nous avons parlé de l’inviolabilité et du non-reniement des chaînes de blocs, deux de leurs caractéristiques clés. Il existe de nombreux cas d’usage qui les nécessitent, sans pour autant avoir besoin de décentraliser la base de données.

Prenons par exemple le cas d’une base de données d’employés, permettant de suivre leurs carrières au sein d’une même entreprise. Pas besoin, a priori, de décentraliser cette base de données. En revanche, ne pas pouvoir effectuer de modification une fois les données enregistrées semble être une bonne idée. Un système comme QLDB démontre alors tout son intérêt.

Dans les pages qui suivent, nous allons parcourir les détails de la mise en œuvre de QLDB, tant d’un point de vue de la gestion d’un registre, de sa création à sa sécurisation, que de celui de son accès au travers d’une application cliente. Nous alternerons donc entre l’interface de la console AWS et celle de Visual Studio que nous utiliserons comme IDE pour développer une application simple d’accès...

Préparation de l’environnement de développement

Nous avons vu dans le précédent chapitre comment configurer le client et les connexions pour utiliser les différents services AWS dont nous aurons besoin. Il est aussi nécessaire de préparer un environnement de développement pour pouvoir créer une application cliente.

Nous allons ici utiliser Visual Studio et le langage C# pour développer une interface utilisateur. Si vous développez dans un autre langage avec un autre IDE, les principes décrits ci-après s’appliqueront, à la syntaxe près dont vous pourrez trouver des exemples dans la documentation fournie par Amazon (https://docs.aws.amazon.com/qldb/latest/developerguide/getting-started-driver.html), pour Java, node.js et python, en plus de C#.

La connexion d’une application cliente à un registre QLDB se fait grâce à un pilote (driver) qui fournit une couche d’abstraction de l’API QLDB. Cette dernière permet de faire passer des commandes au moteur de registre et d’en récupérer les résultats, tout en gérant sessions, transactions et erreurs. Ce pilote s’appuie aussi sur les librairies Amazon Ion nécessaires à la manipulation des documents stockés dans un registre QLDB.

Enfin, Amazon a rendu open source ce pilote dont vous trouverez, pour les plus...

Créer et gérer un registre

Avant de créer un registre, commençons par repréciser ce dont il s’agit. Nous avons vu la structure d’un tel registre au chapitre précédent dans la section Registre et Quantum Ledger Database. Le premier point important à retenir est qu’Amazon QLDB (Quantum Ledger DataBase) est avant tout une base de données. Cela signifie qu’au même titre que Microsoft SQL Server, Oracle Database ou IBM Db2 Database, elle permet de stocker des informations de façon à pouvoir les interroger et y faire des opérations diverses.

Cependant, QLDB n’est pas un système de gestion de base de données (SGBD) au sens relationnel. En effet, QLDB ne permet pas de gérer des données au sens où on l’entend généralement dans le monde des SGBDR, mais des documents dont les formats ne sont pas définis strictement comme peut l’être celui d’une table composée de colonnes (attributs) et de lignes (tuples).

Ensuite, point important, QLDB est une base de données serverless. Cela signifie que lors de sa création, un registre est réparti sur plusieurs machines virtuelles automatiquement au sein d’une zone de disponibilité (AV, Availability Zone) et répliqué parmi plusieurs AV au sein d’une même région pour garantir une haute disponibilité. Cela signifie aussi que la montée en charge est gérée de façon automatique par le système sans qu’il soit possible d’intervenir manuellement sur celle-ci. Il s’agit d’un avantage qui peut se transformer en inconvénient lorsqu’il s’agira de rechercher les causes possibles de baisses de performances si elles devaient survenir. À garder en tête.

Au moment de l’écriture de ce livre, l’interface n’a pas été traduite en français. Tous les noms de menus, d’options et d’écrans sont donc en anglais dans les pages qui suivent.

1. Créer un registre

La création d’un registre est une opération d’une simplicité extrême depuis la console AWS. Depuis la console QLDB :

 Vérifiez la région dans laquelle vous souhaitez créer...

Créer tables et index

On associe souvent à base de données les termes tables et index. En effet, depuis que les SGBDR ont fait irruption dans le monde de l’informatique, ils ont structuré nos données. Qui dit table, dit ligne ou enregistrement, et qui dit colonne dit attribut. Mais pas dans QLDB.

Comme nous l’avons vu précédemment, QLDB est une base de documents. Cela signifie que les « données » qui sont stockées dans les tables n’ont pas besoin de suivre un schéma précis. Au sein d’une même table, chaque document peut donc avoir un schéma différent, même si en pratique cela n’est pas recommandé. Cela signifie cependant que le schéma d’un document peut évoluer au fil du temps ou des besoins. Cela rend aussi la structure d’une base QLDB très souple, et de fait pas toujours très optimisée pour des accès concurrents hautement transactionnels, mais ce n’est pas, a priori, un des cas d’usage d’un registre.

Dans la mesure où la structure d’une table n’est pas stricte, la création d’un tel objet est réduite à sa portion congrue, une seule ligne de code.

1. Tables

Il n’existe pas de méthode graphique pour créer une table. Sa création se fait donc au travers de l’éditeur...

Gestion des documents

Les tables de QLDB stockent donc des documents et non des données sous forme tabulaire. Ces documents ont un format particulier : Amazon Ion. Amazon Ion est un format typé et hiérarchique offrant une représentation texte au format JSON et une représentation binaire efficace en termes de stockage, de transmission et de parcours.

Les spécifications techniques d’Amazon Ion se trouvent sur GitHub à l’adresse http://amzn.github.io/ion-docs/docs/spec.html. Elles décrivent en détail les différents types de caractères. En voici un aperçu pour bien comprendre la richesse potentielle des documents Amazon Ion stockés dans QLDB.

  • null : la valeur null générique indiquant une absence de valeur. Attention, null et 0 ou null et "" (chaîne vide) ne sont pas synonymes.

  • bool : valeur booléenne, vraie ou fausse.

  • int : nombre entier signé de taille arbitraire, codé pour minimiser l’espace utilisé.

  • float : nombre réel à virgule flottante codé en binaire (format IEEE-754 à 32 ou 64 bits).

  • decimal : nombre réel à virgule flottante, conservant la précision décimale (les spécifications techniques de l’implémentation de ce type se trouvent ici : http://speleotrove.com/decimal/decarith.html).

  • timestamp : date et heure, avec ou sans décalage dû au fuseau horaire (format IETF https://www.ietf.org/rfc/rfc3339.txt).

  • string : texte au format Unicode.

  • symbol : séquence de caractères au format Unicode référencée par un identifiant, permettant d’optimiser l’espace.

  • blob : objet binaire dont le format est géré par le créateur, permettant de stocker, par exemple, des images, des vidéos ou des sons.

  • clob : objet binaire dont le format est attendu comme étant du texte, donc interprété comme tel, comme s’il s’agissait d’un type string.

  • struct : collection de paires nom/valeur, sans ordre particulier. Elle est délimitée par des accolades { }.

  • list : collection ordonnée de paires nom/valeur. Elle est délimitée par des crochets [ ].

  • sexp : expression symbolique, c’est-à-dire...

Gestion du journal

Nous avons vu au chapitre précédent, dans la section Du journal de transactions à la base de données journal, la place centrale du journal des transactions d’un registre QLDB. Pour rappel, dans un SGBDR classique, toute transaction impacte les données puis est écrite dans le journal des transactions. Dans un registre QLDB, la transaction est écrite dans le journal des transactions en premier, enchaînée aux précédentes par un mécanisme de chaîne de blocs, puis dans la base de données. C’est ce mécanisme d’enregistrement et d’enchaînement des transactions qui fait la spécificité et l’immutabilité d’un registre QLDB.

Le journal revêt alors une importance toute particulière quand il s’agit, par exemple, de retracer l’historique d’une transaction, dans le cadre de traçabilité d’un produit ou de vérification d’un titre de propriété. Cette partie va nous permettre de comprendre les arcanes du journal, de l’interroger et de l’exporter à des fins d’audit.

1. Métadonnées

Avant de regarder la structure du journal et de l’interroger, arrêtons-nous quelques instants sur les métadonnées associées à tout document. Rappelons-nous tout d’abord qu’une des particularités d’un registre est de n’autoriser que des ajouts. Les modifications et les suppressions ne sont rendues possibles que par l’ajout d’une nouvelle transaction indiquant que le document a respectivement été modifié ou supprimé.

Afin de pouvoir suivre ces opérations et de garantir l’immutabilité des données qui se trouvent dans chaque document, QLDB s’appuie sur les métadonnées de chaque document. À chaque table est associée une vue dite « validée » (committed en anglais pour faire référence à l’instruction COMMIT qui permet de valider une transaction) qui permet d’accéder à ses métadonnées.

On accède à la vue validée d’une table en préfixant le nom de cette dernière par _ql_committed_. Nous interrogeons...

Sécurité du registre et des documents

La sécurité est un sujet qui, si on souhaite le traiter de bout en bout, nécessite qu’on lui consacre un livre entier. Amazon Web Services, comme tous les acteurs du cloud public, prend la sécurité à cœur et promeut une approche en profondeur. Il est en effet nécessaire de sécuriser toutes les couches réseau et applicatives, ainsi que prévoir les attaques zero-day (ces sujets sont traités en détail dans le livre du même auteur, Cloud privé, hybride et public disponible aux Éditions ENI, https://www.editions-eni.fr/livre/cloud-prive-hybride-et-public-quel-modele-pour-quelle-utilisation-un-etat-de-l-art-et-des-bonnes-pratiques-9782409012426).

Dans un paradigme d’application privée s’exécutant sur un cloud public, ce qui est notre cas avec un registre QLDB que nous souhaitons sécuriser, tant au niveau de ses accès que de ses autorisations, la charge de la sécurité est répartie entre AWS et le client. AWS assure la sécurité des infrastructures physiques et logiques sous-jacentes, le client celle de ses données et de ses utilisateurs. 

images/03EXP024.png

Figure 19 - Partage des fonctions de sécurité entre AWS et le client

Il est important de noter que les données d’un registre QLDB sont chiffrées par défaut, à la fois pendant leur transit entre le serveur et le client et aussi sur les disques assurant leur stockage. Le chiffrage est assuré par TLS pendant les transferts et AWS KMS pendant le stockage. Il n’est pas possible de chiffrer les données avec ses propres clés.

Il reste donc du ressort du développeur et de l’administrateur du registre d’assurer la sécurité d’accès au réseau, au registre et aux données de ce dernier.

Tout utilisateur ayant besoin d’accéder à un registre QLDB doit être authentifié par AWS et donc soit posséder un compte racine AWS ou un compte utilisateur IAM, soit utiliser un rôle IAM.

Si vous n’êtes pas totalement familier avec le service Identity and Access Management, vous pouvez vous reporter à la documentation en ligne et en français de ce service disponible à l’adresse...

Avantages et inconvénients de QLDB

Vous avez sans doute, au fil des pages, remarqué de nombreuses différences entre QLDB et les systèmes de gestion de base de données relationnels traditionnels, ainsi que ses avantages et ses inconvénients. Voici un récapitulatif qui vous permettra de déterminer si QLDB permet de répondre à vos besoins de stockage sous forme de registre.

1. Avantages

  • Base de données sans serveur, totalement répliquée et sécurisée, autorisant une montée en charge quasi infinie.

  • Structure souple permettant de stocker tout type de données, y compris des objets binaires complexes, dans un environnement sans schéma à prédéfinir.

  • Journal des transactions fondé sur une chaîne de blocs permettant de mettre en œuvre les principes d’inviolabilité et d’immutabilité.

  • Mise en œuvre du verrouillage optimiste qui évite les étreintes mortelles et augmente la vitesse des transactions.

  • Audit du journal rendu possible avec la fonction history et l’interrogation des versions des documents insérés et mis à jour.

  • Grande simplicité et versatilité.

2. Inconvénients

  • Système de sécurité très limité et peu granulaire, puisqu’il n’est pas possible de limiter l’accès...