Documentation Oracle Cloud Infrastructure

Réplication de clés secrètes

Découvrez comment répliquer des clés secrètes entre les régions.

Vous pouvez répliquer des clés secrètes d'une région à l'autre pour les raisons suivantes :

  • Récupération après sinistre : la réplication des secrets garantit leur accessibilité en cas de perturbations régionales. Les systèmes dotés de fonctions de secours, de basculement et de permutation peuvent avoir besoin de clés secrètes à la disposition des systèmes de secours.
  • Disponibilité : si vous utilisez une clé secrète dans plusieurs régions, la réplication de la clé secrète dans des régions supplémentaires facilite l'accès à la clé secrète et sa mise à jour dans les régions où elle est nécessaire. Veillez à respecter les consignes de sécurité de votre organisation concernant l'utilisation d'une clé secrète dans plusieurs régions.

Fonctionnement de la réplication

Lorsque vous créez une clé secrète dans un coffre, vous avez la possibilité de la répliquer dans 3 autres régions au maximum. Vous pouvez également activer la réplication après avoir créé une clé secrète en la modifiant. Lorsque vous créez des répliques d'une clé secrète, vous indiquez la région cible, le coffre cible dans cette région et la clé de cryptage à utiliser pour la clé secrète. Les clés secrètes de réplique et les versions de clé secrète utilisent les mêmes OCID que les versions de clé secrète et de clé secrète source. Les secrets de réplique sont comptés avec les secrets source aux fins des limites régionales de votre location sur les secrets.

Lorsque vous activez la réplication, OCI réplique les éléments suivants :

  • Le contenu secret
  • Métadonnées et paramètres de la clé secrète
  • Versions des clés secrètes

La réplique est en lecture seule et elle ne peut pas être modifiée. Lorsque vous modifiez ou supprimez une clé secrète source, l'opération de modification ou de suppression est également appliquée aux répliques de la clé secrète. La désactivation de la fonctionnalité sur une clé secrète comportant des répliques supprime les répliques. Vous pouvez également supprimer des répliques individuellement tout en conservant la clé secrète source en modifiant la clé secrète source.

Vous pouvez utiliser des demandes de travail pour surveiller la progression des opérations de réplication inter-région. Pour plus d'informations sur l'utilisation des demandes de travail avec le service de clé secrète, reportez-vous à Demandes de travail secrète.

Utilisez les instructions suivantes pour gérer les répliques de clé secrète :

Important

Les clés secrètes ne sont pas automatiquement répliquées lors de la réplication de coffre. Vous devez gérer la réplication de clé secrète au niveau de la ressource de clé secrète. Pour plus d'informations sur la réplication de coffre, reportez-vous à Réplication de coffres et de clés.

Transfert d'écriture pour les opérations de mise à jour sur les clés secrètes de réplique

Vous pouvez éventuellement activer le transfert en écriture pour les clés secrètes répliquées à l'aide de l'API ou de l'interface de ligne de commande. Alors que les clés secrètes répliquées sont en lecture seule, le transfert d'écriture vous permet de cibler une clé secrète répliquée pour une opération d'écriture et de l'appliquer automatiquement en premier à la clé secrète source, puis via des mises à jour asynchrones, à toutes les répliques de la clé secrète source.

Par exemple, si vous disposez d'une clé secrète source dans la région Est des Etats-Unis (Ashburn) qui est répliquée dans la région Est du Japon (Tokyo), vous pouvez cibler la clé secrète de réplique dans la région Est du Japon (Tokyo) pour une mise à jour. La demande de mise à jour est ensuite transmise à la clé secrète source dans l'est des Etats-Unis (Ashburn) et exécutée automatiquement sur cette clé secrète. Une fois la clé secrète source mise à jour, la demande de mise à jour est automatiquement appliquée à toutes les répliques de la clé secrète source, y compris la réplique dans l'est du Japon (Tokyo).

Limites

Les limitations suivantes s'appliquent à la fonctionnalité de transfert d'écriture pour assurer la sécurité des secrets :

  • Vous ne pouvez pas utiliser le transfert en écriture pour les opérations suivantes :

    • programmation d'une suppression de clé secrète
    • annulation d'une suppression de clé secrète
    • mise à jour de la configuration de réplication de la clé secrète source
  • Lorsque vous créez une clé secrète, vous pouvez activer le transfert en écriture, mais vous ne pouvez pas indiquer le coffre d'une région distante pour contenir la clé secrète source à l'aide de la fonctionnalité de transfert en écriture.
  • Etant donné que l'opération d'écriture se produit de manière asynchrone et que les mises à jour sont d'abord appliquées à la clé secrète source, attendez-vous à un délai entre le démarrage de la mise à jour sur la réplique et la fin de la mise à jour dans la région de la réplique. Vous pouvez surveiller la progression de la mise à jour à l'aide de demandes de travail. Pour plus d'informations sur l'utilisation des demandes de travail avec le service de clé secrète, reportez-vous à Demandes de travail secrète.
  • L'entité qui demande la mise à jour dans la région de la réplique doit être autorisée à effectuer la mise à jour dans la région de la clé secrète source et dans la région où réside la réplique.
  • Vous ne pouvez pas activer le transfert en écriture dans la console OCI. Utilisez les API CreateSecret et UpdateSecret ou les commandes de l'interface de ligne de commande pour ces opérations afin d'activer le transfert en écriture. Dans les API, définissez isWriteForwardEnabled sur true pour activer la fonctionnalité.

Stratégie IAM requise

Utilisez les informations sur les droits d'accès de cette section pour permettre aux utilisateurs ou aux principaux de ressource de configurer la réplication inter-région des clés secrètes.

Droits d'accès requis pour configurer la réplication

Pour créer ou mettre à jour une configuration de réplication de clé secrète (replicationConfig), un utilisateur ou un principal de ressource doit disposer du droit d'accès SECRET_REPLICATE_CONFIGURE. Elle est incluse sous le verbe manage secrets.

Pour créer une clé secrète avec réplication activée, assurez-vous que vous ou le principal de ressource disposez de tous les droits d'accès suivants :

  • SECRET_CREATE, KEY_ENCRYPT, KEY_DECRYPT, VAULT_CREATE_SECRET (pour l'utilisation de l'API CreateSecret ou la création de clés secrètes dans la console ou d'autres interfaces).
  • SECRET_REPLICATE_CONFIGURE

Pour mettre à jour (ou supprimer) une configuration de réplication, assurez-vous que vous ou le principal de ressource disposez de toutes les autorisations suivantes :

  • SECRET_UPDATE (pour l'utilisation de l'API UpdateSecret ou la mise à jour des clés secrètes dans la console ou d'autres interfaces).
  • SECRET_REPLICATE_CONFIGURE

Exemple de règle

L'exemple de stratégie suivant comporte des instructions couvrant toutes les ressources nécessaires pour activer la réplication inter-région pour les clés secrètes nouvelles ou existantes :

Allow group Admins to manage secrets in compartment CompartmentName # for granting SECRET_CREATE, SECRET_UPDATE, SECRET_REPLICATE_CONFIGURE
Allow group Admins to use keys in compartment CompartmentName       # for granting KEY_ENCRYPT, KEY_DECRYPT
Allow group Admins to use vaults in compartment CompartmentName     # for granting VAULT_CREATE_SECRET
Remarque

Les verbes d'authentification de l'exemple de stratégie (manage secrets, use keys, use vaults) contiennent également d'autres droits d'accès non répertoriés dans cette rubrique. Consultez les détails des combinaisons de verbe et de type de ressource lors de l'écriture de stratégies IAM pour les clés secrètes.

Droits d'accès requis par les principaux de ressource pour autoriser la réplication de clé secrète inter-région

Lorsque la réplication est activée sur une clé secrète, vous devez fournir à son principal de ressource les droits d'accès appropriés dans le contexte de la région cible pour que la réplication se produise.

Configuration d'un groupe dynamique

Nous vous recommandons de configurer un groupe dynamique pour les clés secrètes que vous allez répliquer afin de faciliter la gestion des stratégies. Voici un exemple de règle de correspondance :

All {resource.type = 'vaultsecret', resource.compartment.id = '<compartment ID>'}

Pour plus d'informations sur les règles de correspondance de groupe dynamique, reportez-vous à Ecriture de règles de correspondance pour définir des groupes dynamiques.

Ecriture de la stratégie

La réplication de clé secrète requiert que le principal de ressource vaultsecret appartenant à votre clé secrète dispose des droits d'accès permettant de créer et de gérer la clé secrète de réplique dans la région cible. Ces droits d'accès sont SECRET_CREATE, KEY_ENCRYPT, KEY_DECRYPT, VAULT_CREATE_SECRET et SECRET_REPLICATE.

SECRET_REPLICATE est un droit d'accès utilisé uniquement pour la fonctionnalité de réplication inter-région. Lorsqu'elle est accordée, SECRET_REPLICATE autorise un principal de ressource vaultsecret à créer une réplique dans la région cible.

Exemple de stratégie pour le principal de ressource vaultsecret

Allow dynamic-group VaultSecretDG to use secret-replication in compartment CompartmentName # for granting SECRET_REPLICATE
Allow dynamic-group VaultSecretDG to manage secrets in compartment CompartmentName         # for granting SECRET_CREATE
Allow dynamic-group VaultSecretDG to use vaults in compartment CompartmentName             # for granting VAULT_CREATE_SECRET
Allow dynamic-group VaultSecretDG to use keys in compartment CompartmentName               # for granting KEY_ENCRYPT, KEY_DECRYPT
Remarque

  • Les verbes d'authentification de l'exemple de stratégie (manage secrets, use keys, use vaults) contiennent également des droits d'accès supplémentaires non répertoriés dans cette rubrique. Consultez les détails des combinaisons de verbe et de type de ressource lors de l'écriture de stratégies IAM pour les clés secrètes.
  • Ces droits d'accès doivent être accordés dans le contexte de la région cible. Par exemple, si vous limitez l'accès à l'aide de la variable de contexte d'ID de coffre, assurez-vous que la variable indiquée est l'ID de coffre de la région cible.
  • Si votre compartiment ou votre clé secrète utilise des balises définies, veillez à accorder également le droit d'accès use tag-namespaces au groupe dynamique coffre-fort.