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.

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.

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.

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.

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. 

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.

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.