Documentation sur Oracle Cloud Infrastructure

Notes pour l'utilisation des clés gérées par le client avec une base de données d'IA autonome

Fournit des informations et des notes supplémentaires pour l'utilisation des clés gérées par le client avec Autonomous AI Database

Rubrique parent : Gérer les clés de chiffrement sur la base de données d'IA autonome

Attention aux clés de chiffrement gérées par le client lorsque la clé est inaccessible

Une fois que vous êtes passé à des clés gérées par le client, certaines opérations de base de données peuvent être affectées lorsque la clé est inaccessible.

Si la base de données ne peut pas accéder à votre clé pour une raison quelconque, telle qu'une panne de réseau, la base de données autonome d'IA traite l'interruption comme suit :

  • Il y a un délai de grâce de 2 heures pendant lequel la base de données reste opérationnelle.

  • Si la clé n'est pas accessible à la fin de la période de grâce de 2 heures, l'état du cycle de vie de la base de données est réglé à Inaccessible. Dans cet état, les connexions existantes sont supprimées et les nouvelles connexions ne sont pas autorisées.

  • Si Autonomous Data Guard est activé lors de l'utilisation d'Oracle Cloud Infrastructure Vault, pendant ou après la période de grâce de 2 heures, vous pouvez essayer manuellement d'effectuer une opération de basculement. Le basculement automatique d'Autonomous Data Guard n'est pas déclenché lorsque vous utilisez des clés de chiffrement gérées par le client et qu'Oracle Cloud Infrastructure Vault est inaccessible.

    Note

    Seule Oracle Cloud Infrastructure Vault est prise en charge avec Autonomous Data Guard.

  • Si Autonomous Database est arrêté, vous ne pouvez pas démarrer la base de données lorsque les clés sont inaccessibles.

    Dans ce cas, la demande de travail affichée lorsque vous cliquez sur l'onglet Demandes de travail dans la page des détails d'Autonomous Database de la console Oracle Cloud Infrastructure affiche : 

    The Vault service is not accessible. 
Your Autonomous Database could not be started. Please contact Oracle Support.

Attention à l'utilisation des clés de chiffrement gérées par le client lorsque la clé principale est désactivée ou supprimée

Une fois que vous êtes passé aux clés gérées par le client, certaines opérations de base de données peuvent être affectées si la clé principale est désactivée ou supprimée.

  • Pour les opérations de désactivation/suppression de clé pour lesquelles l'état de la clé de chiffrement principale est l'un des suivants :

    Chambre forte de clés État clé
    Service de chambre forte Oracle Cloud Infrastructure (OCI)
    • DISABLING
    • DISABLED
    • DELETING
    • DELETED
    • SCHEDULING_DELETION
    • PENDING_DELETION
    AWS Key Management System (KMS)
    • Disabled
    • PendingDeletion
    Chambre forte de clés Azure
    • DISABLED
    • DELETED
    Oracle Key Vault (OKV)
    • COMPROMISED
    • DEACTIVATED
    • DESTROYED

    La base de données devient inaccessible une fois que l'état du cycle de vie de la clé passe à l'un de ces états. Lorsque la clé se trouve dans l'un de ces états, Autonomous AI Database supprime les connexions existantes et n'autorise pas de nouvelles connexions.

    L'inaccessibilité de la base de données peut prendre jusqu'à 15 minutes après les opérations clés (Autonomous AI Database vérifie le fournisseur de clés à des intervalles de 15 minutes).

  • Si vous désactivez ou supprimez la clé Oracle Cloud Infrastructure Vault utilisée par votre base de données d'intelligence artificielle autonome alors qu'Autonomous Data Guard est activé, Autonomous Data Guard n'effectuera pas de basculement automatique.

    Note

    Seule Oracle Cloud Infrastructure Vault est prise en charge avec Autonomous Data Guard.

  • Si vous activez une clé désactivée, la base de données passe automatiquement à l'état Disponible.

  • Si vous supprimez la clé principale, vous pouvez vérifier l'historique des clés dans la console Oracle Cloud Infrastructure pour rechercher les clés utilisées pour la base de données. L'historique affiche le nom de la clé, ainsi qu'un horodatage d'activation. Si l'une des anciennes clés de la liste d'historique est toujours disponible, vous pouvez restaurer la base de données à l'heure à laquelle la base de données utilisait cette clé, ou vous pouvez cloner à partir d'une sauvegarde pour créer une nouvelle base de données avec cet horodatage.

Pour plus d'informations, voir Voir l'historique des clés de chiffrement gérées par le client sur la base de données autonome d'IA.

Attention à l'utilisation de l'historique et des sauvegardes des clés de chiffrement gérées par le client

Une fois que vous êtes passé à des clés gérées par le client, certaines opérations de base de données peuvent être touchées si la clé principale est pivotée, désactivée ou supprimée et que vous n'avez pas de clé valide pour restaurer vos données à partir d'une sauvegarde enregistrée précédemment ou d'un clone.

  • Il est recommandé de créer une nouvelle clé qui n'a pas été utilisée pour la rotation au cours des 60 derniers jours et d'utiliser cette clé pour la rotation. Vous pouvez ainsi revenir à une sauvegarde si la clé courante est supprimée ou désactivée.

  • Lorsque vous effectuez plusieurs rotations de clé de chiffrement dans les 60 jours, il est recommandé de créer une nouvelle clé pour chaque opération de rotation de clé de chiffrement principale ou de spécifier une clé qui n'a pas été utilisée au cours des 60 derniers jours. Cela permet d'enregistrer au moins une clé que vous pouvez utiliser pour récupérer vos données à partir d'une sauvegarde, dans le cas où une clé de chiffrement principale gérée par le client est désactivée ou supprimée.

Pour plus d'informations, voir Voir l'historique des clés de chiffrement gérées par le client sur la base de données autonome d'IA.

Notes pour les clés gérées par le client dans le service de chambre forte OCI avec Autonomous Data Guard

Autonomous Data Guard est pris en charge lors de l'utilisation de clés gérées par le client avec le fournisseur de clés Oracle Cloud Infrastructure Vault.

Note

Lorsque vous utilisez des clés gérées par Oracle, vous pouvez uniquement passer à des clés gérées par le client à partir de la base de données principale. De même, lorsque vous utilisez des clés gérées par le client, vous pouvez uniquement effectuer une rotation des clés ou passer à des clés gérées par Oracle à partir de la base de données principale. L'option Gérer la clé de chiffrement sous Actions supplémentaires est désactivée sur une base de données de secours.

Notez ce qui suit lorsque vous utilisez Autonomous Data Guard avec une base de données de secours avec des clés gérées par le client :

  • Pour qu'une base de données de secours distante utilise la même clé de chiffrement principale que la clé principale, celle-ci doit être répliquée dans la région distante.

    Les clés de chiffrement gérées par le client ne sont prises en charge qu'avec une seule base de données de secours Autonomous Data Guard inter-région. Les bases de secours inter-régions multiples ne sont pas prises en charge, car Oracle Cloud Infrastructure Vault ne prend en charge que la réplication vers une région distante.

  • La base principale et la base de secours utilisent la même clé. En cas de permutation ou de basculement vers la base de données de secours, vous pouvez continuer à utiliser la même clé.

  • Lorsque vous effectuez la rotation de la clé gérée par le client sur la base de données principale, elle est répercutée sur la base de données de secours.

  • Lorsque vous passez des clés gérées par le client aux clés gérées par Oracle, la modification est répercutée sur la base de données de secours.

  • Lorsque Oracle Cloud Infrastructure Vault est inaccessible, une période de grâce de 2 heures s'écoule avant que la base de données passe à l'état INACCESSIBLE. Vous pouvez effectuer un basculement pendant ou après cette période de grâce de 2 heures.

  • Si vous désactivez ou supprimez la clé de chiffrement principale Oracle Cloud Infrastructure que votre base de données Autonomous AI Database utilise avec des clés gérées par le client alors qu'Autonomous Data Guard est activé, Autonomous Data Guard n'effectue pas de basculement automatique.

  • Les clés de chiffrement gérées par le client ne sont pas prises en charge avec Autonomous Data Guard interlocation.

Voir ce qui suit pour plus d'informations :

Notes pour les clés de chiffrement gérées par le client avec une base de données de secours Autonomous Data Guard interlocation

Lorsque vous ajoutez une base de données de secours interlocation Autonomous Data Guard, des considérations particulières s'appliquent lorsque la base de données principale utilise des clés de chiffrement gérées par le client.

Notes pour les clés de chiffrement avec une base de données de secours interlocation Autonomous Data Guard :

  • Autonomous AI Database prend en charge plusieurs fournisseurs de clés gérées par le client. Seule Oracle Cloud Infrastructure Vault est prise en charge pour une utilisation avec Autonomous Data Guard. Les autres chambres fortes ne sont pas prises en charge pour les clés gérées par le client sur la base de données principale ou de secours lorsque vous ajoutez une base de données de secours Autonomous Data Guard.

  • Vous pouvez ajouter une base de données de secours interlocation Autonomous Data Guard, mais vous devez utiliser la même clé de chiffrement, qu'il s'agisse d'une clé gérée par Oracle ou d'une clé gérée par le client, à la fois dans la location principale et dans la base de données de secours.

  • L'interlocation avec Autonomous Data Guard inter-région n'est prise en charge qu'avec une chambre forte Oracle Cloud Infrastructure Vault répliquée. Par exemple, si vous avez une base de données principale dans region1 dans tenancy1 et que vous voulez créer une base de données de secours inter-région Autonomous Data Guard inter-location dans region2 dans tenancy2, Oracle Cloud Infrastructure Vault doit être répliqué entre region1 et region2 dans tenancy1.

Voir ce qui suit pour plus d'informations :

Notes pour les clés de chiffrement gérées par le client avec des clones actualisables

Répertorie les limitations et les notes relatives à l'utilisation des clés gérées par le client avec des clones actualisables.

Note

L'option d'utilisation de clés gérées par le client avec un clone actualisable n'est disponible que lorsque la base de données source utilise le modèle de calcul ECPU.

Clone actualisable de même région avec source à l'aide de clés de chiffrement gérées par le client Notes

Autonomous AI Database prend en charge l'utilisation de clés de chiffrement gérées par le client avec un clone actualisable dans la même région, comme suit :

  • Lorsque la base de données source utilise des clés gérées par le client, vous pouvez créer un ou plusieurs clones locaux (même région) actualisables. Les clones actualisables utilisent les mêmes clés gérées par le client que la base de données source et ne prennent pas en charge l'option de sélectionner indépendamment une autre clé ou de modifier le type de clé sur les clones actualisables.

  • Tous les fournisseurs de clés gérées par le client pris en charge sont pris en charge pour un même clone actualisable de région, notamment Oracle Cloud Infrastructure Vault, Microsoft Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS) et Oracle Key Vault (OKV).

    Pour plus d'informations, voir À propos du service Master Encryption Key Management sur Autonomous AI Database.

  • Vous pouvez modifier le type de clé ou effectuer une rotation de la clé sur la base de données source lorsque celle-ci comporte un ou plusieurs clones actualisables locaux. Dans ce cas, une fois que la base de données source est passée à un autre type de clé ou que sa clé est tournée, un clone actualisable continue d'utiliser l'ancienne clé existante. Après l'actualisation d'un clone actualisable, celui-ci bascule pour utiliser le nouveau type de clé source ou la clé pivotée.

  • Lors du provisionnement d'un clone actualisable à partir d'une source à l'aide d'une clé gérée par le client, les groupes dynamiques et les politiques doivent couvrir le clone actualisable afin que le clone actualisable puisse également accéder à la clé. Si les groupes dynamiques et les politiques n'incluent pas le clone actualisable, le provisionnement échoue. De même, si la source dispose déjà d'un clone actualisable et passe de clés gérées par Oracle à des clés gérées par le client, le changement échouera si les groupes dynamiques et les politiques n'incluent pas le clone actualisable.

    Pour plus d'informations, voir Préalables à la création d'un clone actualisable.

Pour plus d'informations, voir Créer un clone actualisable pour une instance de base de données du service d'intelligence artificielle autonome.

Clone actualisable inter-régions avec source à l'aide des notes sur les clés de chiffrement gérées par le client

Autonomous AI Database prend en charge l'utilisation de clés de chiffrement gérées par le client avec un clone actualisable inter-région, comme suit :

  • Lorsque la base de données source utilise des clés gérées par le client, vous pouvez créer un clone actualisable inter-région. Le clone actualisable utilise les mêmes clés gérées par le client que la base de données source et ne prend pas en charge l'option de sélectionner indépendamment une autre clé ou de modifier le type de clé sur le clone actualisable.

    Dans ce cas, seule la chambre forte OCI est prise en charge pour le clone actualisable inter-région et la clé de la source doit être répliquée dans la région distante.

  • Le fournisseur de clés gérées par le client pris en charge avec un clone actualisable inter-région est : Oracle Cloud Infrastructure Vault.

    Pour plus d'informations, voir À propos du service Master Encryption Key Management sur Autonomous AI Database.

  • Lorsqu'un clone actualisable inter-région utilise une clé gérée par le client, les groupes dynamiques et les politiques doivent couvrir le clone actualisable. Si les groupes dynamiques et les politiques n'incluent pas le clone actualisable, le provisionnement échoue. De même, si la source dispose déjà d'un clone actualisable et passe de clés gérées par Oracle à des clés gérées par le client, le changement échouera si les groupes dynamiques et les politiques n'incluent pas le clone actualisable.

    Pour plus d'informations, voir Préalables à la création d'un clone actualisable.

Pour plus d'informations, voir Créer un clone actualisable interlocation ou inter-région.

Clone actualisable interlocation avec source à l'aide des notes sur les clés de chiffrement gérées par le client

La base de données Autonomous AI Database ne prend pas en charge l'utilisation de clés de chiffrement gérées par le client avec un clone actualisable interlocation.

Pour plus d'informations, voir Créer un clone actualisable interlocation ou inter-région.

Restaurer la base de données source avec un clone actualisable à l'aide des notes sur les clés de chiffrement gérées par le client

Si une base de données source dispose d'un clone actualisable et que la base de données source est restaurée à partir de sauvegardes, la base de données source commence à utiliser la clé qui était utilisée au moment où la base de données source a été restaurée.

Dans ce cas, considérez les cas suivants :

  • Si le clone actualisable était en retard et que son point d'actualisation était antérieur au point de restauration, ce qui signifie que le clone actualisable avait des données antérieures à la base de données source restaurée, il commencera à utiliser la même clé que la base de données source après la prochaine actualisation (une actualisation recrée le clone actualisable à partir de la base de données source).

  • Si le point d'actualisation du clone actualisable est postérieur au point de restauration, ce qui signifie que le clone actualisable contient des données plus récentes que la base de données source restaurée, le clone actualisable est recréé automatiquement lorsqu'il atteint le même point dans le temps avec les actualisations. À ce moment-là, il devrait commencer à afficher la même clé que la source.

Pour plus d'informations, voir Restaurer et récupérer votre base de données d'IA autonome.

Clone actualisable déconnecté à l'aide des notes sur les clés de chiffrement gérées par le client

Si un clone actualisable avec une base de données source utilisant des clés gérées par le client est déconnecté, le clone actualisable peut se reconnecter à la base de données source. Si, alors que le clone actualisable est déconnecté de la source, la clé de la base de données source change, le clone actualisable bascule pour utiliser la nouvelle clé lorsque le clone actualisable est reconnecté et actualisé.

Notes pour les clés gérées par le client avec chambre forte dans la location distante

Pour utiliser des clés de chiffrement principales gérées par le client avec une chambre forte dans une location distante, notez les points suivants :

Lorsque vous utilisez des clés de chiffrement principales gérées par le client avec une chambre forte dans une location distante, la chambre forte et l'instance de base de données d'intelligence artificielle autonome doivent se trouver dans la même région. Pour modifier la location, dans la page d'authentification, cliquez sur Modifier la location. Après avoir modifié la location, assurez-vous de sélectionner la même région pour la chambre forte et l'instance de base de données autonome avec intelligence artificielle.