Always Encrypted avec enclaves sécurisées

  • Article

S’applique à : SQL Server 2019 (15.x) et versions ultérieures - Windows uniquement Azure SQL Database

Always Encrypted avec enclaves sécurisées étend les fonctionnalités de calcul confidentiel d’Always Encrypted avec le chiffrement sur place et des requêtes confidentielles plus riches. Always Encrypted avec enclaves sécurisées est disponible dans SQL Server 2019 (15.x) et versions ultérieures et dans Azure SQL Database.

Introduit dans Azure SQL Database en 2015 et dans SQL Server 2016 (13.x), Always Encrypted protège la confidentialité des données sensibles contre les programmes malveillants et les utilisateurs non autorisés à haut privilège. Il s'agit des Administrateurs de bases de données (DBA), des administrateurs informatiques, administrateurs cloud, ou toute autre personne ayant un accès légitime aux instances de serveur, au matériel, etc. mais qui ne devrait pas avoir accès à une partie ou à la totalité des données réelles.

Sans les améliorations présentées dans cet article, Always Encrypted protège les données en les chiffrant côté client et en ne permettant jamais aux données ou aux clés de chiffrement correspondantes d'apparaître en texte en clair dans le moteur de base de données. Par conséquent, la fonctionnalité sur les colonnes chiffrées à l’intérieur de la base de données est extrêmement limitée. Les seules opérations que le moteur de base de données peut effectuer sur des données chiffrées sont les comparaisons d'égalité (disponibles uniquement avec le chiffrement déterministe). Toutes les autres opérations, notamment les opérations de chiffrement (chiffrement de données initial ou rotation de clés) et/ou les requêtes riches (par exemple, les critères spéciaux), ne sont pas prises en charge à l’intérieur de la base de données. Les utilisateurs doivent déplacer les données hors de la base de données pour effectuer ces opérations côté client.

Always Encrypted avec enclaves sécurisées résout ces limitations en autorisant des calculs sur les données de texte en clair à l’intérieur d’une enclave sécurisée côté serveur. Une enclave sécurisée est une région protégée de la mémoire au sein du processus Moteur de base de données. L’enclave sécurisée apparaît comme une zone opaque pour le reste de Moteur de base de données et les autres processus de l’ordinateur d’hébergement. Il n’existe aucun moyen d’afficher les données ou le code à l’intérieur de l’enclave depuis l’extérieur, même avec un débogueur. Ces propriétés font de l’enclave sécurisée un environnement d’exécution approuvé capable d’accéder de manière sécurisée aux clés de chiffrement et aux données sensibles en clair, sans compromettre la confidentialité des données.

Always Encrypted utilise des enclaves sécurisées, comme illustré dans le diagramme suivant :

flux de données

Lors de l'analyse d'une instruction Transact-SQL soumise par une application, le moteur de base de données détermine si l'instruction contient des opérations sur des données chiffrées nécessitant l'utilisation de l'enclave sécurisée. Pour de telles instructions :

  • Le pilote client envoie les clés de chiffrement de colonne requises pour les opérations à l’enclave sécurisée (sur un canal sécurisé) et envoie l’instruction pour exécution.

  • Lors du traitement de l'instruction, le moteur de base de données délègue les opérations cryptographiques ou les calculs sur les colonnes chiffrées à l'enclave sécurisée. Si nécessaire, l’enclave déchiffre les données et effectue des calculs sur du texte en clair.

Pendant le traitement des instructions, les données et les clés de chiffrement des colonnes ne sont pas exposées dans un texte en clair dans le moteur de base de données en dehors de l'enclave sécurisée.

Pilotes clients pris en charge

Pour utiliser Always Encrypted avec enclaves sécurisées, une application doit utiliser un pilote client qui prend en charge la fonctionnalité. Configurez l'application et le pilote client pour permettre les calculs et l'attestation d'enclave (voir la section Attestation d'enclave sécurisée ci-dessous). Pour plus d’informations, notamment la liste des pilotes clients pris en charge, consultez Développer des applications à l’aide d’Always Encrypted.

Technologies d’enclave prises en charge

Always Encrypted prend en charge les technologies d'enclave (ou types d'enclave) suivantes :

Le type d'enclave disponible pour votre base de données dépend du produit SQL qui l'héberge (Azure SQL Database ou SQL Server) et (dans le cas d'Azure SQL Database) de la configuration de votre base de données.

  • Dans SQL Server 2019 (15.x) et versions ultérieures, Always Encrypted prend en charge les enclaves de sécurité basée sur la virtualisation. (Les enclaves Intel SGX ne sont pas prises en charge.)

  • Dans Azure SQL Database, une base de données peut utiliser une enclave Intel SGX ou une enclave de sécurité basée sur la virtualisation, en fonction du matériel sur lequel la base de données est configurée pour s'exécuter :

    • Les bases de données utilisant la configuration matérielle de la série DC (disponible avec le modèle d'achat vCore) utilisent des enclaves Intel SGX.
    • Les bases de données utilisant une configuration autre que la série DC avec le modèle d'achat vCore et les bases de données utilisant le modèle d'achat DTU peuvent être configurées pour utiliser des enclaves de sécurité basée sur la virtualisation.

    Remarque

    Les enclaves de sécurité basée sur la virtualisation sont disponibles dans toutes les régions Azure SQL Database sauf : Jio Inde Centre.

Reportez-vous à la section Considérations de sécurité pour obtenir des informations importantes sur le niveau de protection offert par chaque type d'enclave.

Attestation d’enclave sécurisée

L'attestation d'enclave est un mécanisme de défense en profondeur qui permet de détecter les attaques impliquant la falsification du code de l'enclave ou de son environnement par des administrateurs malveillants.

L'attestation d'enclave permet à une application cliente d'établir la confiance avec l'enclave sécurisée de la base de données à laquelle l'application est connectée, avant que l'application n'utilise l'enclave pour traiter des données sensibles. Le processus d'attestation vérifie que l'enclave est une enclave de sécurité basée sur la virtualisation ou Intel SGX authentique et que le code qui s'exécute à l'intérieur est la bibliothèque d'enclave authentique signée par Microsoft pour Always Encrypted. Pendant l'attestation, le pilote client de l'application et le moteur de base de données communiquent avec un service d'attestation externe à l'aide d'un point de terminaison spécifié par le client.

Always Encrypted peut utiliser l'un des deux services d'attestation :

Pour activer Always Encrypted avec enclaves sécurisées pour votre application, vous devez définir un protocole d'attestationdans la configuration du pilote client dans votre application. Une valeur de protocole d'attestation détermine si 1) l'application cliente utilisera l'attestation et, le cas échéant, 2) elle spécifie le type de service d'attestation qu'elle utilisera. Le tableau ci-dessous présente les protocoles d'attestation pris en charge pour les combinaisons valides de produits SQL et de types d'enclaves :

Produit d'hébergement Type d'enclave Protocoles d'attestation pris en charge
SQL Server 2019 (15.x) et versions ultérieures Enclaves de sécurité basée sur la virtualisation SGH, aucune attestation
Azure SQL Database Enclaves SGX (bases de données de série DC) Microsoft Azure Attestation
Azure SQL Database Enclaves de sécurité basée sur la virtualisation Pas d'attestation

Quelques points importants à souligner :

  • L'attestation des enclaves de sécurité basée sur la virtualisation dans SQL Server 2019 (15.x) et les versions ultérieures nécessite SGH. Vous pouvez également utiliser les enclaves de sécurité basée sur la virtualisation sans attestation (les pilotes client les plus récents sont nécessaires).
  • Avec les enclaves Intel SGX (dans les bases de données de la série DC) dans Azure SQL Database, l'attestation est obligatoire et nécessite Microsoft Azure Attestation.
  • Les enclaves de sécurité basée sur la virtualisation dans Azure SQL Database ne prennent pas en charge l'attestation.

Pour plus d’informations, consultez l’article suivant :

Terminologie

Clés prenant en charge les enclaves

Always Encrypted avec enclaves sécurisées introduit le concept des clés prenant en charge l’enclave :

  • Clé principale de colonne prenant en charge les enclaves : une clé principale de colonne avec la propriété ENCLAVE_COMPUTATIONS spécifiée dans l’objet de métadonnées de la clé principale de colonne à l’intérieur de la base de données. L’objet de métadonnées de la clé principale de colonne doit également contenir une signature valide des propriétés des métadonnées. Pour plus d’informations, consultez CREATE COLUMN MASTER KEY (Transact-SQL).
  • Clé de chiffrement de colonne prenant en charge l’enclave : clé de chiffrement de colonne qui est chiffrée avec une clé principale de colonne prenant en charge l’enclave. Seules les clés de chiffrement de colonne prenant en charge les enclaves peuvent être utilisées pour les calculs à l’intérieur de l’enclave sécurisée.

Pour plus d’informations, consultez Gérer des clés pour Always Encrypted avec enclaves sécurisées.

Colonnes prenant en charge les enclaves

Une colonne prenant en charge l’enclave est une colonne de base de données qui est chiffrée avec une clé de chiffrement de colonne prenant en charge l’enclave.

Fonctionnalités de calcul confidentiel pour les colonnes prenant en charge les enclaves

Les deux principaux avantages d’Always Encrypted avec enclaves sécurisées sont le chiffrement sur place et les requêtes confidentielles riches.

Chiffrement sur place

Le chiffrement sur place autorise des opérations de chiffrement sur les colonnes de base de données à l’intérieur de l’enclave sécurisée, sans déplacer les données hors de la base de données. Le chiffrement sur place améliore les performances et la fiabilité des opérations cryptographiques. Vous pouvez effectuer un chiffrement sur place à l’aide de l’instruction ALTER TABLE (Transact-SQL).

Les opérations de chiffrement sur place prises en charge sont les suivantes :

  • Chiffrement d’une colonne de texte en clair avec une clé de chiffrement de colonne prenant en charge les enclaves.
  • Rechiffrement d'une colonne chiffrée prenant en charge les enclaves pour :
    • Effectuer la rotation d’une clé de chiffrement de colonne (rechiffrer la colonne avec une nouvelle clé de chiffrement de colonne prenant en charge les enclaves).
    • Changer le type de chiffrement d’une colonne prenant en charge les enclaves, par exemple remplacer le chiffrement déterministe par le chiffrement aléatoire.
  • Déchiffrement des données stockées dans une colonne prenant en charge les enclaves (conversion de la colonne en colonne de texte en clair).

Le chiffrement sur place est autorisé avec les chiffrements déterministe et aléatoire, à condition que les clés de chiffrement de colonne impliquées dans une opération de chiffrement prennent en charge les enclaves.

Requêtes confidentielles

Remarque

SQL Server 2022 (16.x) ajoute une prise en charge supplémentaire des requêtes confidentielles avec les opérations JOIN, GROUP BY et ORDER BY sur des colonnes chiffrées.

Les requêtes confidentielles sont des requêtes DML qui impliquent des opérations sur des colonnes prenant en charge les enclaves effectuées à l’intérieur de l’enclave sécurisée.

Les opérations prises en charge dans les enclaves sécurisées sont les suivantes :

Opération Azure SQL Database SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Opérateurs de comparaison Prise en charge Prise en charge Prise en charge
BETWEEN (Transact-SQL) Prise en charge Prise en charge Prise en charge
IN (Transact-SQL) Prise en charge Prise en charge Prise en charge
LIKE (Transact-SQL) Prise en charge Prise en charge Prise en charge
DISTINCT Prise en charge Prise en charge Prise en charge
Joins Prise en charge Prise en charge Seules les jointures de boucles imbriquées sont prises en charge
SELECT - Clause ORDER BY (Transact-SQL) Prise en charge Prise en charge Non prise en charge
SELECT - GROUP BY- Transact-SQL Prise en charge Prise en charge Non pris en charge

Remarque

Les opérations ci-dessus à l'intérieur d'enclaves sécurisées nécessitent un chiffrement aléatoire. Le chiffrement déterministe n’est pas pris en charge. La comparaison d'égalité reste l'opération disponible pour les colonnes en utilisant le chiffrement déterministe.

Le niveau de compatibilité de la base de données doit être défini sur SQL Server 2022 (160) ou plus.

Dans Azure SQL Database et dans SQL Server 2022 (16.x), les requêtes confidentielles utilisant des enclaves sur une colonne de chaîne de caractères (char, nchar) requièrent que la colonne utilise un classement de code de caractère binaire (_BIN2) ou un classement UTF-8. Dans SQL Server 2019 (15.x), un classement _BIN2 est requis.

Pour en savoir plus, reportez-vous à Exécuter des instructions Transact-SQL à l'aide d'enclaves sécurisées.

Index sur des colonnes prenant en charge les enclaves

Vous pouvez créer des index non cluster sur des colonnes prenant en charge les enclaves à l’aide du chiffrement aléatoire pour accélérer l’exécution des requêtes DML confidentielles utilisant l’enclave sécurisée.

Pour garantir qu’un index sur une colonne chiffrée à l’aide d’un chiffrement aléatoire n’entraîne pas la fuite de données sensibles, les valeurs de clés dans la structure des données d’index (B-tree) sont chiffrées et triées en fonction de leur valeurs de texte en clair. Le tri par la valeur de texte en clair est également utile pour traiter les requêtes à l’intérieur de l’enclave. Lorsque l'exécuteur de requêtes du moteur de base de données utilise un index sur une colonne chiffrée pour des calculs à l'intérieur de l'enclave, il recherche dans l'index des valeurs spécifiques stockées dans la colonne. Chaque recherche peut impliquer plusieurs comparaisons. L’exécuteur de requête délègue chaque comparaison à l’enclave, qui déchiffre une valeur stockée dans la colonne et la valeur de clé de l’index chiffré à comparer, il effectue la comparaison sur du texte en clair et retourne le résultat de la comparaison à l’exécuteur.

La création d’index sur des colonnes qui utilisent le chiffrement aléatoire et ne prennent pas en charge les enclaves n’est toujours pas prise en charge.

Un index sur une colonne utilisant un chiffrement déterministe est trié en fonction du texte chiffré (pas du texte en clair), que la colonne prenne ou non en charge les enclaves.

Pour plus d’informations, consultez Créer et utiliser des index sur des colonnes à l’aide d’Always Encrypted avec enclaves sécurisées. Pour obtenir des informations générales sur le fonctionnement de l'indexation dans le moteur de base de données, reportez-vous à l'article intitulé Indexes cluster et non cluster décrits.

Récupération de la base de données

En cas de défaillance d'une instance SQL Server, ses bases de données peuvent être laissées dans un état à partir duquel les fichiers de données peuvent contenir des modifications dues à des transactions incomplètes. Lorsque l’instance est démarrée, elle exécute un processus appelé récupération de base de données, qui implique la restauration de chaque transaction incomplète trouvée dans le journal des transactions pour garantir que l’intégrité de la base de données est préservée. Si une transaction incomplète a apporté des modifications à un index, ces modifications doivent également être annulées. Par exemple, certaines valeurs clés de l'index peuvent devoir être supprimées ou réinsérées.

Important

Microsoft recommande fortement d'activer la Récupération de base de données accélérée (ADR) pour votre base de données avant de créer le premier index sur une colonne prenant en charge les enclaves avec un chiffrement aléatoire. ADR est activé par défaut dans Azure SQL Database, mais pas dans SQL Server 2019 (15.x) et versions ultérieures.

Avec le processus de récupération de base de données traditionnel (qui suit le modèle de récupération ARIES), pour annuler une modification apportée à un index, SQL Server doit attendre qu’une application fournisse la clé de chiffrement de colonne pour la colonne de l’enclave, ce qui peut prendre un certain temps. La récupération de base de données accélérée (ADR) réduit notablement le nombre d’opérations d’annulation qui doivent être reportées parce qu’une clé de chiffrement de colonne n’est pas disponible dans le cache au sein de l’enclave. Par conséquent, elle augmente sensiblement la disponibilité de la base de données en réduisant au minimum le risque de blocage d’une nouvelle transaction. Lorsque l'ADR est activé, SQL Server peut encore avoir besoin d'une clé de chiffrement de colonne pour terminer le nettoyage des anciennes versions de données. Toutefois, il le fait en arrière-plan, sans impact sur la disponibilité de la base de données ou sur les transactions des utilisateurs. Vous pouvez voir des messages d'erreur dans le journal des erreurs, indiquant l'échec des opérations de nettoyage en raison d'une clé de chiffrement de colonne manquante.

Considérations de sécurité

Les considérations de sécurité suivantes s’appliquent à Always Encrypted avec enclaves sécurisés.

  • Les enclaves de sécurité basée sur la virtualisation permettent de protéger vos données contre les attaques à l'intérieur de la machine virtuelle. Toutefois, elles n'offrent aucune protection contre les attaques utilisant des comptes système privilégiés provenant de l'hôte. Les enclaves Intel SGX protègent les données contre les attaques provenant à la fois du SE invité et du SE hôte.
  • Il est recommandé d'utiliser l'attestation d'enclave si elle est disponible dans votre environnement et si vous souhaitez protéger vos données contre les attaques d'utilisateurs disposant d'un accès administrateur au niveau du système d'exploitation sur la machine hébergeant votre base de données. Si vous utilisez l'attestation, vous devez vous assurer que le service d'attestation et sa configuration sont gérés par un administrateur de confiance. En outre, les deux services d'attestation pris en charge proposent des stratégies et des modes d'attestation différents, dont certains effectuent une vérification minimale de l'enclave et de son environnement, et sont conçus pour les tests et le développement. Respectez scrupuleusement les instructions spécifiques à votre service d’attestation pour vérifier que vous utilisez les configurations et les stratégies recommandées pour vos déploiements de production.
  • Le chiffrement d'une colonne à l'aide d'un chiffrement aléatoire avec une clé de chiffrement de colonne activée par l'enclave peut entraîner la fuite de l'ordre des données stockées dans la colonne, étant donné que ces colonnes prennent en charge les comparaisons de plage. Par exemple, si une colonne chiffrée contenant les salaires des employés a un index, un administrateur de base de données malveillant pourrait analyser l’index pour trouver la valeur de salaire chiffrée maximale et identifier une personne touchant le salaire maximal (en supposant que le nom de la personne n’est pas chiffré).
  • Si vous utilisez Always Encrypted pour protéger des données sensibles contre un accès non autorisé des administrateurs de bases de données, ne partagez pas les clés principales des colonnes ou les clés de chiffrement des colonnes avec les administrateurs de bases de données. Un administrateur de base de données peut gérer des index sans avoir directement accès aux clés, en utilisant le cache des clés de chiffrement de colonne au sein de l’enclave.

Considérations relatives à la continuité d'activité, à la récupération d'urgence et à la migration des données

Lors de la configuration d’une solution à haute disponibilité ou de reprise d’activité après sinistre pour une base de données à l’aide d’Always Encrypted avec enclaves sécurisées, vérifiez que tous les réplicas de base de données peuvent utiliser une enclave sécurisée. Si une enclave est disponible pour le réplica principal, mais pas pour le réplica secondaire, toute instruction qui tente d’utiliser la fonctionnalité d’Always Encrypted avec enclaves sécurisées échoue après le basculement.

Quand vous copiez ou migrez une base de données à l’aide d’Always Encrypted avec enclaves sécurisées, vérifiez que l’environnement cible prend toujours en charge les enclaves. Sinon, les instructions qui utilisent des enclaves ne fonctionneront pas sur la copie ou la base de données migrée.

Voici les considérations spécifiques à prendre en compte :

  • SQL Server

    • Quand vous configurez un groupe de disponibilité Always On, vous devez vérifier que chaque instance de SQL Server qui héberge une base de données dans le groupe de disponibilité prend en charge Always Encrypted avec enclaves sécurisées et a une enclave et une attestation configurées.
    • Lors de la restauration d’un fichier de sauvegarde d’une base de données qui utilise la fonctionnalité d’Always Encrypted avec enclaves sécurisées sur une instance de SQL Server qui n’a pas d’enclave configurée, l’opération de restauration réussit et toutes les fonctionnalités qui ne reposent pas sur l’enclave sont disponibles. Toutefois, toutes les instructions suivantes utilisant la fonctionnalité de l’enclave échouent, et les index sur des colonnes prenant en charge des enclaves à l’aide d’un chiffrement aléatoire ne sont plus valides. La même chose est valable lors de l’attachement d’une base de données utilisant Always Encrypted avec enclaves sécurisées sur l’instance pour laquelle l’enclave n’est pas configurée.
    • Si votre base de données contient des index sur des colonnes prenant en charge les enclaves avec un chiffrement aléatoire, veillez à activer la récupération de base de données accélérée (ADR) dans la base de données avant de créer une sauvegarde de base de données. ADR garantit que la base de données, notamment les index, est disponible immédiatement après la restauration de la base de données. Pour plus d’informations, consultez Récupération de la base de données.

  • Azure SQL Database

    • Lors de la configuration de la géoréplication active, vérifiez qu’une base de données secondaire prend en charge les enclaves sécurisées si la base de données primaire les prend en charge.

Dans SQL Server et Azure SQL Database, quand vous migrez votre base de données à l’aide d’un fichier bacpac, veillez à supprimer tous les index des colonnes prenant en charge les enclaves à l’aide d’un chiffrement aléatoire avant de créer le fichier bacpac.

Limitations connues

Always Encrypted avec enclaves sécurisées résout certaines limitations d’Always Encrypted en prenant en charge le chiffrement sur place et les requêtes confidentielles riches avec index, comme cela est expliqué dans Fonctionnalités de calcul confidentiel pour les colonnes prenant en charge les enclaves.

Toutes les autres limitations d'Always Encrypted énumérées dans Limitations s'appliquent également à Always Encrypted avec enclaves sécurisées.

Les limitations suivantes sont spécifiques à Always Encrypted avec enclaves sécurisées :

  • Il est impossible de créer des index cluster sur des colonnes prenant en charge les enclaves à l’aide d’un chiffrement aléatoire.
  • Les colonnes prenant en charge les enclaves utilisant un chiffrement aléatoire ne peuvent pas être des colonnes de clé primaire, ni être référencées par des contraintes de clé étrangères ou des contraintes de clé unique.
  • Dans SQL Server 2019 (15.x) (cette limitation ne s'applique pas à Azure SQL Database ou SQL Server 2022 (16.x)), seules les jointures de boucles imbriquées (avec des index, le cas échéant) sont prises en charge sur les colonnes compatibles aux enclaves avec un chiffrement aléatoire. Pour plus d’informations sur les différences entre les produits, consultez Requêtes confidentielles.
  • Les opérations de chiffrement sur place ne peuvent pas être combinées avec d'autres modifications des métadonnées de la colonne, à l'exception des modifications d'un classement au sein de la même page de codes et possibilité d'accepter la valeur Null. Par exemple, vous ne pouvez pas chiffrer, rechiffrer ou déchiffrer une colonne ET changer un type de données de la colonne dans une seule instruction Transact-SQL ALTER TABLE/ALTER COLUMN. Utilisez deux instructions distinctes.
  • L’utilisation de clés prenant en charge les enclaves pour les colonnes dans des tables en mémoire n’est pas prise en charge.
  • Les expressions qui définissent des colonnes calculées ne peuvent pas effectuer de calculs sur des colonnes prenant en charge les enclaves avec un chiffrement aléatoire (même si les calculs font partie des opérations prises en charge listées dans les requêtes confidentielles).
  • Les caractères d’échappement ne sont pas pris en charge dans les paramètres de l’opérateur LIKE sur les colonnes avec enclave utilisant un chiffrement aléatoire.
  • Les requêtes avec l’opérateur LIKE ou un opérateur de comparaison avec un paramètre de requête utilisant l’un des types de données suivants (qui deviennent des objets volumineux après chiffrement) ignorent les index et effectuent des analyses de table.
    • nchar[n] et nvarchar[n], si n est supérieur à 3967.
    • char[n], varchar[n], binary[n], varbinary[n], si n est supérieur à 7935.
  • Limitations d'outils :
    • Les seuls magasins de clés pris en charge pour le stockage des clés principales de colonne prenant en charge l’enclave sont le Magasin de certificats Windows et Azure Key Vault.
    • Pour déclencher une opération de chiffrement sur place via ALTER TABLE/ALTER COLUMN, vous devez émettre l'instruction à l'aide d'une fenêtre Requête dans SSMS ou Azure Data Studio, ou vous pouvez écrire votre propre programme qui émet l'instruction. Actuellement, la cmdlet Set-SqlColumnEncryption du module SqlServer PowerShell et l'Assistant Always Encrypted de SQL Server Management Studio ne prennent pas en charge le chiffrement sur place. Déplacez les données hors de la base de données pour les opérations cryptographiques, même si les clés de chiffrement des colonnes utilisées pour les opérations sont activées par l'enclave.
  • Lorsque vous restaurez une base de données activée pour l’enclave de sécurité basée sur la virtualisation, il est essentiel de reconfigurer les paramètres de l’enclave de sécurité basée sur la virtualisation.

Étapes suivantes

Voir aussi