Présentation de la gestion des coffres, des clés et des clés secrètes

Le service Key Management stocke et gère les clés dans des coffres pour un accès sécurisé aux ressources.

Le service Key Management (KMS) Oracle Cloud Infrastructure (OCI) est un service cloud qui fournit une gestion et un contrôle centralisés des clés de cryptage pour les données stockées dans OCI.

OCI KMS effectue les opérations suivantes :

  • Simplifie la gestion des clés en stockant et en gérant de manière centralisée les clés de cryptage.
  • Protège les données au repos et en transit en prenant en charge divers types de clé de cryptage, notamment les clés symétriques et les clés asymétriques.
  • Répond aux exigences de sécurité et de conformité avec plusieurs options de création et de stockage des clés. Les fonctionnalités à cet effet incluent : l'import de clés vers OCI ("Apportez vos propres clés" ou BYOK), la création de clés dans OCI et le stockage de clés en externe ("Bloquez vos propres clés" ou HYOK) à l'aide de la gestion des clés externes. Key Management prend en charge les modules de sécurité HSM certifiés FIPS 140-2 niveau 3 pour le stockage et la protection des clés de chiffrement.
  • Intègre le cryptage à d'autres services OCI tels que le stockage, la base de données et Fusion Applications pour protéger les données stockées dans ces services.

Concepts relatifs à la gestion des clés et des clés secrètes

Découvrez les concepts liés à la gestion des coffres et des clés pour accéder aux coffres, aux clés et aux clés secrètes, et les gérer.

Coffres
Les coffres sont des entités logiques dans lesquelles le service Key Management crée et stocke de manière durable les clés de coffre et les clés secrètes. Le type de coffre dont vous disposez détermine les fonctions et fonctionnalités, telles que le degré d'isolements du stockage, l'accès à l'administration et le cryptage, l'évolutivité et la possibilité de sauvegarder. Le type de coffre a également une incidence sur la tarification. Vous ne pouvez pas modifier le type d'un coffre après sa création.
Le service Key Management propose différents types de coffre pour répondre aux besoins et au budget de votre organisation. Tous les types de coffre garantissent la sécurité et l'intégrité des clés de cryptage et des clés secrètes stockées dans les coffres. Un coffre privé virtuel est une partition isolée sur un module de sécurité HSM. Les autres coffres partagent les mêmes partitions sur le module de sécurité HSM.
Par défaut, les coffres privés virtuels comprennent 1 000 versions de clé. Si vous n'avez pas besoin du degré d'isolement ou de la possibilité de sauvegarder le coffre, vous n'avez pas besoin d'un coffre privé virtuel. Sans coffre privé virtuel, vous pouvez gérer les coûts en payant les versions de clé individuellement, selon vos besoins. (Les versions de clé sont prises en compte dans votre limite de clés et vos coûts. Une clé de coffre contient toujours au moins une version de clé active. De même, une clé secrète possède toujours au moins une version de clé secrète. Toutefois, les limites de clés secrètes s'appliquent à la location et non au coffre.)

Pour les clients qui ont la conformité réglementaire de stocker des clés en dehors du cloud Oracle ou de tout environnement cloud tiers, OCI KMS offre désormais une fonctionnalité appelée External Key Management Service (External KMS). Dans KMS externe, vous pouvez stocker et contrôler les clés de cryptage maître (en tant que clés externes) sur un système de gestion de clés tiers hébergé en dehors d'OCI. Vous pouvez ensuite utiliser ces clés pour crypter les données dans Oracle. Vous pouvez également désactiver vos clés à tout moment. Avec les clés réelles résidant dans le système de gestion des clés tiers, vous créez uniquement des références de clé (associées au matériel de clé) dans OCI.

OCI KMS offre le KMS dédié, qui est une ressource de partition HSM à locataire unique et gérée par le client en tant que service. Il vous permet d'avoir un meilleur contrôle en possédant la partition HSM et les clés chiffrées et les utilisateurs de la partition. Dans une configuration KMS dédiée, le cluster HSM est fourni avec trois partitions HSM par défaut, qui sont synchronisées automatiquement. Vous pouvez gérer les clés et les utilisateurs dans les modules de sécurité HSM intégrés aux instances de calcul OCI via les utilitaires client et les bibliothèques PKCS #11. KMS dédié prend uniquement en charge les clés protégées par HSM et ne prend pas en charge les clés protégées par logiciel. Pour les opérations cryptographiques, la solution prend en charge le chiffrement symétrique et asymétrique à l'aide des algorithmes AES, RSA et ECDSA.

Le service Vault désigne les coffres comme des ressources Oracle Cloud Infrastructure.
Clés
Les clés sont des entités logiques qui représentent une ou plusieurs versions de clé, chacune contenant du matériel cryptographique. Le matériel cryptographique d'une clé de coffre est généré pour un algorithme spécifique qui vous permet d'utiliser la clé pour le cryptage ou la signature numérique. Lorsqu'elle est utilisée pour le chiffrement, une clé ou une paire de clés crypte et décrypte les données, protégeant les données où elles sont stockées ou pendant leur transit. Avec une clé symétrique AES, la même clé chiffre et décrypte les données. Avec une clé asymétrique RSA, la clé publique chiffre les données et la clé privée décrypte les données.
Vous pouvez utiliser les clés AES dans le cryptage et le décryptage, mais pas dans la signature numérique. Cependant, les clés RSA peuvent être utilisées non seulement pour chiffrer et déchiffrer les données, mais aussi pour signer numériquement les données et vérifier l'authenticité des données signées. Vous pouvez utiliser les clés ECDSA dans la signature numérique, mais pas pour chiffrer ou déchiffrer les données.
Lorsqu'elle est traitée par un algorithme de cryptage, une clé indique comment transformer le texte brut en texte crypté lors du cryptage et comment transformer le texte crypté en texte brut pendant le décryptage. Lorsqu'elle est traitée dans le cadre d'un algorithme de signature, la clé privée d'une clé asymétrique et d'un message produisent ensemble une signature numérique qui va avec le message en transit. Lorsqu'elle est traitée dans le cadre d'un algorithme de vérification de signature par le destinataire du message signé, le message, la signature et la clé publique de la même clé asymétrique confirment ou refusent l'authenticité et l'intégrité du message.
Conceptuellement, le service Key Management reconnaît trois types de clé de cryptage : les clés de cryptage maître, les clés d'encapsulage et les clés de cryptage de données.
Les algorithmes de cryptage pris en charge par le service Key Management pour les clés de cryptage maître de coffre sont AES, RSA et ECDSA. Vous pouvez créer des clés de cryptage maître AES, RSA ou ECDSA à l'aide de la console, de la CLI ou de l'API. Lorsque vous créez une clé de cryptage maître, le service Key Management peut générer la clé en interne ou l'importer à partir d'une source externe. (La prise en charge de l'importation du matériel de clé dépend de l'algorithme de chiffrement du matériel de clé.) Lorsque vous créez des clés de cryptage maître de coffre, vous les créez dans un coffre, mais l'emplacement de stockage et de traitement d'une clé dépend de son mode de protection.
Les clés de cryptage maître Vault peuvent avoir l'un des deux modes de protection suivants : HSM ou logiciel. Une clé de chiffrement principale protégée par un HSM est stockée sur un HSM et ne peut pas être exportée à partir du HSM. Toutes les opérations cryptographiques impliquant la clé se produisent également sur le module HSM. Pendant ce temps, une clé de chiffrement principale protégée par un logiciel est stockée sur un serveur et peut donc être exportée à partir du serveur pour effectuer des opérations cryptographiques sur le client plutôt que sur le serveur. Lorsqu'elle est au repos, la clé protégée par logiciel est chiffrée par une clé racine sur le HSM. Pour une clé protégée par logiciel, tout traitement lié à la clé se produit sur le serveur. Le mode de protection d'une clé a une incidence sur la tarification et ne peut pas être modifié une fois la clé créée.
Une fois que vous avez créé votre première clé de cryptage maître symétrique, vous pouvez utiliser l'API pour générer les clés de cryptage de données que le service Key Management vous renvoie. Notez qu'une clé de cryptage de données doit avoir une force de cryptage égale ou supérieure à la clé de cryptage maître utilisée pour la créer. Certains services peuvent utiliser une clé de cryptage maître symétrique pour générer leurs propres clés de cryptage de données.
La clé d'encapsulage est un type de clé de cryptage qui est inclus par défaut avec chaque coffre. Une clé d'encapsulation est une clé de chiffrement asymétrique de 4096 bits basée sur l'algorithme RSA. Les paires de clés publique et privée ne sont pas prises en compte dans les limites de service. Ils n'engagent pas non plus de frais de service. Vous utilisez la clé publique comme clé de cryptage de clé lorsque vous devez encapsuler les informations de clé pour l'import dans le service Key Management. Vous ne pouvez pas créer, supprimer ou effectuer une rotation des clés d'encapsulage.
Le service Key Management reconnaît les clés de cryptage maître comme des ressources Oracle Cloud Infrastructure.
Versions de clé et rotations
Une version de clé est automatiquement affectée à chaque clé de cryptage maître. Lorsque vous effectuez une rotation de clé, le service Key Management génère une nouvelle version de clé. Le service Key Management peut générer les informations de clé de la nouvelle version ou vous pouvez les importer.
La rotation périodique des clés limite la quantité de données cryptées ou signées par une version de clé. Si une clé est compromise, la rotation des clés réduit les risques. Un identificateur unique affecté par Oracle à la clé, appelé OC ID (Oracle Cloud ID), reste le même lors des rotations, mais la version de clé permet à Key Management d'effectuer une rotation de clés de façon transparente pour répondre à vos exigences de conformité.
Bien que vous ne puissiez pas utiliser une ancienne version de clé pour le cryptage après rotation d'une clé, celle-ci reste disponible pour décrypter toutes les données utilisées pour le cryptage. Si vous effectuez une rotation de clé asymétrique, la clé publique ne peut plus être utilisée pour chiffrer les données, mais la clé privée reste disponible pour déchiffrer les données chiffrées par la clé publique. Lorsque vous effectuez une rotation d'une clé asymétrique utilisée dans la signature numérique, vous ne pouvez plus utiliser la version de clé privée pour signer les données, mais la version de clé publique reste disponible pour vérifier la signature numérique des données précédemment signées par l'ancienne version de clé privée.
Pour les clés symétriques, vous n'avez pas besoin de suivre quelle version de clé a été utilisée pour crypter les données car le texte de cryptage de la clé contient les informations dont le service a besoin à des fins de décryptage. Toutefois, grâce aux rotations de clés asymétriques, vous devez suivre la version de clé utilisée pour chiffrer ou signer les données. Avec les clés asymétriques, le texte de chiffrement de la clé ne contient pas les informations dont le service a besoin pour le décryptage ou la vérification.
Avec les clés symétriques AES, chaque version de clé compte comme une version de clé lors du calcul de l'utilisation des limites de service. Toutefois, avec les clés asymétriques RSA et ECDSA, chaque version de clé compte deux pour le calcul de l'utilisation par rapport aux limites de service, car une clé asymétrique possède à la fois une clé publique et une clé privée. (Les clés asymétriques sont également appelées paires de clés.)
Rotation automatique des touches
Remarque

Cette fonctionnalité n'est disponible que pour les coffres privés.

Le service Key Management d'OCI vous permet de programmer la rotation automatique des clés pour une clé de cryptage dans un coffre privé virtuel. Lorsque vous configurez la rotation automatique, vous définissez la fréquence de rotation et la date de début du calendrier de rotation. Pour la fréquence, vous avez choisi un intervalle de rotation compris entre 60 et 365 jours. KMS prend en charge la rotation automatique des clés HSM et logicielles, et prend en charge la rotation automatique des clés symétriques et asymétriques. Notez qu'une clé doit être à l'état "enabled" pour configurer la rotation automatique.

Caractéristiques et exigences de la rotation automatique des clés :
  • Vous pouvez mettre à jour le calendrier de rotation d'une clé après avoir activé la rotation automatique, si nécessaire.
  • Vous pouvez faire pivoter une clé à la demande (effectuer une rotation manuelle) lorsque la rotation automatique de la clé est activée.
  • Vous pouvez suivre les activités de rotation automatique des clés pour une clé, y compris le dernier statut de rotation et le dernier message d'état, les mises à jour de l'intervalle de rotation et la prochaine date de début de rotation.
  • Vous pouvez envoyer une notification d'événement en cas d'échec d'une rotation de clé.

Notification d'événement de rotation automatique : pour recevoir des notifications d'événement de rotation de clé automatique, vous devez configurer le service OCI Events. Après chaque rotation de clé, KMS envoie une notification sur l'état de rotation et des messages d'erreur, le cas échéant. Le service OCI Events vous permet d'utiliser des règles d'événement pour appeler une fonction, que vous pouvez utiliser pour l'automatisation. Par exemple, vous pouvez utiliser des fonctions pour automatiser les tâches suivantes :

  • Recrypter les données avec une nouvelle version de clé
  • Suppression d'une ancienne version de clé
  • Répartir la partie publique des clés asymétriques pour la signature ou la vérification des données

Pour plus d'informations, reportez-vous à Création d'une règle Events et à Présentation de Functions.

Modules de sécurité matérielle
Lorsque vous créez la clé de cryptage maître symétrique AES avec le mode de protection HSM, le service Key Management stocke la version de la clé dans un module de sécurité HSM (Hardware Security Module) pour fournir une couche de sécurité physique, (Lorsque vous créez une clé secrète, ses versions sont encodées en base64 et cryptées par une clé de cryptage maître, mais ne sont pas stockées dans le HSM.) Une fois les ressources créées, le service conserve des copies de n'importe quelle version de clé ou de clé secrète donnée dans l'infrastructure de service afin d'assurer la résilience face aux pannes matérielles. Les versions de clé des clés protégées par HSM ne sont stockées nulle part ailleurs et ne peuvent pas être exportées à partir d'un HSM.
Lorsque vous créez une clé de chiffrement principale asymétrique RSA ou ECDSA avec le mode de protection HSM, le service Key Management stocke la clé privée dans un HSM et n'autorise pas son export à partir du HSM. Toutefois, vous pouvez télécharger la clé publique.
Le service Key Management utilise des modules de sécurité HSM qui respectent la certification de sécurité de niveau 3 FIPS 140-2. Cette certification signifie que le matériel HSM est inaltérable, qu'il possède des garanties physiques pour l'intégrité, qu'il requiert l'authentification basée sur une identité et qu'il supprime les clés du dispositif lorsqu'il détecte une altération.
Cryptage d'enveloppe
La clé de cryptage de données utilisée pour crypter vos données est elle-même cryptée avec une clé de cryptage maître. Ce concept est appelé cryptage d'enveloppe. Les services Oracle Cloud Infrastructure n'ont pas accès aux données en texte brut sans interaction avec le service Key Management et sans accès à la clé d'encodage maître protégée par Oracle Cloud Infrastructure Identity and Access Management (IAM). A des fins de décryptage, des services intégrés tels qu'Object Storage, Block Volume et File Storage stockent uniquement la forme cryptée de la clef de cryptage des données.
Clés secrètes
Les informations d'identification telles que les mots de passe, les certificats, les clés SSH ou les jetons d'authentification que vous utilisez avec les services Oracle Cloud Infrastructure. Le stockage des clés secrètes dans un coffre permet plus de sécurité qu'un stockage dans un autre emplacement, par exemple dans des fichiers de configuration ou du code. Vous pouvez extraire les clés secrètes à partir du service Key Management lorsque vous en avez besoin pour accéder aux ressources ou à d'autres services.
Vous pouvez créer des clés secrètes à l'aide de la console, de l'interface de ligne de commande ou de l'API. Le contenu d'une clé secrète est importé dans le service à partir d'une source externe. Le service Vault stocke les clés secrètes dans des coffres.
Le service Key Management prend en charge les clés secrètes en tant que ressources Oracle Cloud Infrastructure.
Versions de clé secrète
Une version de clé secrète est automatiquement affectée à chaque clé secrète. Lorsque vous effectuez la rotation d'une clé secrète, vous indiquez le nouveau contenu de la clé secrète au service Key Management pour qu'il génère une nouvelle version. La rotation régulière du contenu de clé secrète permet de réduire l'impact si une clé secrète est exposée. Un OCID (Oracle Cloud ID) unique d'une clé secrète reste le même lors des rotations, mais la version d'une clé secrète permet à Key Management Service d'effectuer des rotations du contenu de clé secrète de façon à répondre à vos règles ou à Vos exigences de conformité. Bien que vous ne puissiez pas utiliser le contenu d'une ancienne version de clé secrète après rotation si une règle est configurée pour empêcher sa réutilisation, la version de clé secrète reste disponible et son état de rotation n'est pas "En cours". Pour plus d'informations sur les versions de clé secrète et leurs états de rotation, reportez-vous à Versions de clé secrète et états de rotation.
Bundles secrets
Un groupe de clés secrètes de coffre se compose du contenu de la clé secrète, des propriétés de la clé secrète et de la version de la clé secrète (comme le numéro de version ou l'état de rotation), ainsi que des métadonnées contextuelles fournies par l'utilisateur pour la clé secrète. Lorsque vous effectuez une rotation de clé secrète, vous créez une version de clé secrète qui inclut également une nouvelle version de package de clé secrète.

Régions et domaines de disponibilité

Le service Vault est disponible dans toutes les régions commerciales d'Oracle Cloud Infrastructure. Reportez-vous à A propos des régions et des domaines de disponibilité pour obtenir la liste des régions disponibles, ainsi que les emplacements associés, les identificateurs de région, les clés de région et les domaines de disponibilité.

Toutefois, contrairement à d'autres services Oracle Cloud Infrastructure, le service Vault ne dispose pas d'une adresse régionale pour toutes les opérations d'API. Le service dispose d'une adresse régionale pour le service de provisionnement qui gère les opérations permettant de créer, de mettre à jour et de répertorier des coffres. Pour les opérations permettant de créer, de mettre à jour et de répertorier des clés, les adresses de service sont distribuées dans plusieurs clusters indépendants. Les adresses de service pour les clés secrètes sont encore davantage distribuées dans différents clusters indépendants.

Dans la mesure où le service Vault dispose d'adresses publiques, vous pouvez utiliser directement les clés de cryptage de données générées par le service pour les opérations cryptographiques dans les applications. Toutefois, si vous voulez utiliser les clés de cryptage maître avec un service intégré à Vault, vous pouvez le faire uniquement lorsque le service et le coffre contenant la clé existent tous les deux dans la même région. Différentes adresses existent pour les opérations de gestion des clés, les opérations de cryptage des clés, les opérations de gestion des clés secrètes et les opérations d'extraction des clés secrètes. Pour plus d'informations, reportez-vous à la documentation relative à l'API Oracle Cloud Infrastructure.

Le service Vault gère des copies des coffres et de leur contenu afin de les conserver durablement et de permettre au service Vault de produire des clés ou des clés secrètes sur demande, même lorsqu'un domaine de disponibilité n'est pas disponible. Cette réplication est indépendante de toute réplication inter-région qu'un client peut configurer.

Pour les régions comportant plusieurs domaines de disponibilité, le service Vault conserve des copies des clés de cryptage dans tous les domaines de disponibilité de la région. Les régions comportant plusieurs domaines de disponibilité disposent d'un rack pour chaque domaine de disponibilité, ce qui signifie que la réplication s'effectue sur trois racks au total dans ces régions, où chaque rack appartient à un domaine de disponibilité différent. Dans les régions avec un seul domaine de disponibilité, le service Vault gère les copies de clé de cryptage dans les domaines de pannes.

Pour les clés secrètes, dans les régions comportant plusieurs domaines de disponibilité, le service Vault distribue des copies secrètes sur deux domaines de disponibilité différents. Dans les régions avec un seul domaine de disponibilité, le service Vault distribue les copies sur deux domaines de pannes différents.

Chaque domaine de disponibilité comporte trois domaines de pannes. Les domaines de pannes offrent une haute disponibilité et une tolérance aux pannes. En effet, le service Vault peut distribuer les ressources sur différents matériels physiques d'un domaine de disponibilité donné. Le matériel physique lui-même dispose également d'alimentations indépendantes et redondantes qui empêchent une coupure de courant dans un domaine de pannes d'affecter d'autres domaines de pannes.

Tout cela permet au service Vault de produire des clés et des clés secrètes sur demande, même lorsqu'un domaine de disponibilité est indisponible dans une région comportant plusieurs domaines de disponibilité ou lorsqu'un domaine de pannes est indisponible dans une région comportant un seul domaine de disponibilité.

Accès privé à Vault

Le service Vault prend en charge l'accès privé à partir des ressources Oracle Cloud Infrastructure dans un réseau cloud virtuel via une passerelle de service. La configuration et l'utilisation d'une passerelle de service sur un réseau cloud virtuel permettent aux ressources (comme les instances auxquelles les volumes cryptés sont attachés) d'accéder aux services Oracle Cloud Infrastructure publics tels que le service Vault sans les exposer au réseau Internet public. Aucune passerelle Internet n'est requise et les ressources peuvent se trouver dans un sous-réseau privé et utiliser uniquement des adresses IP privées. Pour plus d'informations, reportez-vous à Accès aux services Oracle : passerelle de service.

Identificateurs de ressource

Le service Vault prend en charge des coffres, des clés et des clés secrètes en tant que ressources Oracle Cloud Infrastructure. La plupart des types de ressource Oracle Cloud Infrastructure possèdent un identificateur unique affecté par Oracle appelé ID Oracle Cloud (OCID). Pour plus d'informations sur le format OCID et d'autres façons d'identifier vos ressources, reportez-vous à Identificateurs de ressource..

Méthodes d'accès à Oracle Cloud Infrastructure

Vous pouvez accéder à Oracle Cloud Infrastructure en saisissant votre compte cloud.

Vous pouvez accéder à Oracle Cloud Infrastructure (OCI) à l'aide de la console (interface Web), de l'API REST ou de l'interface de ligne de commande OCI. Les instructions d'utilisation de la console, de l'API et de l'interface de ligne de commande sont incluses dans les rubriques de cette documentation. Pour obtenir la liste des kits SDK disponibles, reportez-vous à Kits Software Development et interface de ligne de commande.

Pour accéder à la console, vous devez utiliser un navigateur pris en charge. Pour accéder à la page de connexion à la console, ouvrez le menu de navigation en haut de cette page et sélectionnez Console Infrastructure. Vous êtes invité à saisir votre locataire cloud, votre nom utilisateur et votre mot de passe.

Authentification et autorisation

Chaque service d'Oracle Cloud Infrastructure s'intègre à IAM à des fins d'authentification et d'autorisation pour toutes les interfaces (console, kit SDK ou CLI, et API REST).

Un administrateur d'une organisation doit configurer des groupes , des compartiments et desstratégies qui déterminent quelles utilisateurs peuvent accéder à quels services et quelles ressources, ainsi qu'à quels types d'accès. Par exemple, les stratégies indiquent qui peut créer les utilisateurs, créer et gérer le réseau cloud, créer les instances, créer les buckets, télécharger les objets, etc. Pour plus d'informations, reportez-vous à Gestion des domaines d'identité. Afin d'obtenir des détails spécifiques sur l'élaboration de stratégies pour chacun des différents services, reportez-vous à Référence de stratégie.

Si vous êtes un utilisateur standard (pas un administrateur) et que vous avez besoin des ressources Oracle Cloud Infrastructure de l'entreprise, demandez à un administrateur de configurer pour vous un ID utilisateur. L'administrateur peut confirmer les compartiments que vous pouvez utiliser.

Limites relatives aux ressources Vault

Connaissez la limite du service Vault et son utilisation des ressources avant de commencer à les utiliser.

Pour obtenir la liste des limites applicables et des instructions permettant de demander une augmentation de limite, reportez-vous à Limites de service. Pour définir des limites propres aux compartiments sur une ressource ou une famille de ressources, les administrateurs peuvent utiliser des quotas de compartiment.

Pour obtenir des instructions sur l'affichage de votre niveau d'utilisation par rapport aux limites de ressource de la location, reportez-vous à Visualisation de l'utilisation, des quotas et des limites de service. Vous pouvez également consulter l'utilisation de chaque coffre par rapport aux limites de clé en affichant le nombre de clés et de versions de clé dans les détails du coffre.