Documentation Oracle Cloud Infrastructure

Remarques relatives à l'utilisation de clés gérées par le client avec Autonomous Database

Fournit des informations supplémentaires et des remarques relatives à l'utilisation de clés gérées par le client avec Autonomous Database

Rubrique parent : Gestion des clés de cryptage sur Autonomous Database

Attention pour les clés de cryptage 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 coupure de réseau, Autonomous Database gère la coupure comme suit :

  • La base de données reste opérationnelle pendant un délai de grâce de 2 heures.

  • Si la clé n'est pas accessible à la fin du délai de grâce de 2 heures, l'état de cycle de vie de la base de données est défini sur 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 le délai 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 cryptage gérées par le client et qu'Oracle Cloud Infrastructure Vault est inaccessible.

    Remarque

    Seul Oracle Cloud Infrastructure Vault est pris 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 sur la page de détails d'Autonomous Database de la console Oracle Cloud Infrastructure présente les éléments suivants : 

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

Mise en garde relative à l'utilisation de clés de cryptage gérées par le client lorsque la clé maître est désactivée ou supprimée

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 si la clé maître est désactivée ou supprimée.

  • Pour les opérations de désactivation/de suppression de clé où l'état de la clé de cryptage maître est l'un des suivants :

    Key Vault Etat de la clé
    Oracle Cloud Infrastructure (OCI) Vault
    • DISABLING
    • DISABLED
    • DELETING
    • DELETED
    • SCHEDULING_DELETION
    • PENDING_DELETION
    Système de gestion des clés AWS
    • Disabled
    • PendingDeletion
    Coffre-fort de clés Azure
    • DISABLED
    • DELETED
    Oracle Key Vault (OKV)
    • COMPROMISED
    • DEACTIVATED
    • DESTROYED

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

    La base de données devenant inaccessible peut prendre jusqu'à 15 minutes après les opérations de clé (Autonomous 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 instance Autonomous Database lorsque Autonomous Data Guard est activé, Autonomous Data Guard n'effectue pas de basculement automatique.

    Remarque

    Seul Oracle Cloud Infrastructure Vault est pris 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é maître, vous pouvez consulter l'historique de clé dans la console Oracle Cloud Infrastructure afin de rechercher les clés utilisées pour la base de données. L'historique vous indique le nom de la clé, ainsi qu'un horodatage d'activation. Si l'une des anciennes clés de la liste de l'historique est toujours disponible, vous pouvez restaurer la base de données vers l'heure où elle utilisait cette clé, ou la cloner à partir d'une sauvegarde pour créer une base de données avec cet horodatage.

Reportez-vous à Affichage de l'historique des clés de cryptage gérées par le client sur Autonomous Database pour plus d'informations.

Mise en garde relative à l'utilisation de sauvegardes et de l'historique des clés de cryptage 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 affectées en cas de rotation, de désactivation ou de suppression de la clé maître, et si vous ne disposez pas d'une clé valide pour restaurer les données à partir d'une sauvegarde précédente ou d'un clone.

  • Il est recommandé de créer une 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. Cela garantit que vous pouvez revenir à une sauvegarde si la clé en cours est supprimée ou désactivée.

  • Lorsque vous effectuez plusieurs rotations de clé de cryptage sur une période de 60 jours, il est recommandé de créer une clé pour chaque opération de rotation de clé de cryptage maître ou d'indiquer 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 les données à partir d'une sauvegarde, au cas où une clé de cryptage maître gérée par le client serait désactivée ou supprimée.

Reportez-vous à Affichage de l'historique des clés de cryptage gérées par le client sur Autonomous Database pour plus d'informations.

Remarques relatives aux clés gérées par le client dans OCI Vault 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.

Remarque

Lorsque vous utilisez des clés gérées par Oracle, vous pouvez uniquement passer aux 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 basculer vers des clés gérées par Oracle à partir de la base de données principale. L'option Gérer la clé de cryptage sous Actions supplémentaires est désactivée sur une base de données de secours.

Lorsque vous utilisez Autonomous Data Guard avec une base de données de secours avec des clés gérées par le client, tenez compte des points suivants :

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

    Les clés de cryptage 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. Plusieurs bases de données de secours inter-région ne sont pas prises en charge, car Oracle Cloud Infrastructure Vault ne prend en charge la réplication que vers une seule 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 une rotation de la clé gérée par le client sur la base de données principale, cette opération est répercutée sur la base de données de secours.

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

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

  • Si vous désactivez ou supprimez la clé de cryptage maître Oracle Cloud Infrastructure que votre instance Autonomous 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 cryptage gérées par le client ne sont pas prises en charge avec Autonomous Data Guard sur plusieurs locations.

Pour plus d'informations, reportez-vous à :

Remarques concernant les clés de cryptage gérées par le client avec des clones actualisables

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

Remarque

L'option permettant d'utiliser des 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 utilisant des clés de cryptage gérées par le client - Remarques

Autonomous Database prend en charge l'utilisation de clés de cryptage 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 des clones actualisables locaux (même région). 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 permettant 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és 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, reportez-vous à A propos du traitement des clés de cryptage maître sur Autonomous 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 basculée vers un autre type de clé ou que sa clé est pivotée, un clone actualisable continue d'utiliser l'ancienne clé existante. Une fois qu'un clone actualisable est actualisé, il bascule pour utiliser le nouveau type de clé source ou la clé pivotée.

  • Lorsque vous provisionnez un clone actualisable à partir d'une source à l'aide d'une clé gérée par le client, les stratégies et les groupes dynamiques doivent couvrir le clone actualisable afin que le clone actualisable puisse également accéder à la clé. Si les stratégies et les groupes dynamiques 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 basculement échoue si les groupes et stratégies dynamiques n'incluent pas le clone actualisable.

    Pour plus d'informations, reportez-vous à Prérequis de création d'un clone actualisable.

Pour plus d'informations, reportez-vous à Création d'un clone actualisable pour une instance d'Autonomous Database.

Clone actualisable inter-région avec source à l'aide de clés de cryptage gérées par le client Notes

Autonomous Database prend en charge l'utilisation de clés de cryptage 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 permettant de sélectionner indépendamment une autre clé ou de modifier le type de clé sur le clone actualisable.

    Dans ce cas, seul OCI Vault est pris 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é par le client pris en charge avec un clone actualisable inter-région est Oracle Cloud Infrastructure Vault.

    Pour plus d'informations, reportez-vous à A propos du traitement des clés de cryptage maître sur Autonomous Database.

  • Lorsqu'un clone actualisable inter-région utilise une clé gérée par le client, les groupes dynamiques et les stratégies doivent couvrir le clone actualisable. Si les stratégies et les groupes dynamiques 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 basculement échoue si les groupes et stratégies dynamiques n'incluent pas le clone actualisable.

    Pour plus d'informations, reportez-vous à Prérequis de création d'un clone actualisable.

Pour plus d'informations, reportez-vous à Création d'une location croisée ou d'un clone actualisable inter-région.

Clone actualisable inter-locations avec source à l'aide de clés de cryptage gérées par le client - Remarques

Autonomous Database ne prend pas en charge l'utilisation de clés de cryptage gérées par le client avec un clone actualisable inter-locations.

Pour plus d'informations, reportez-vous à Création d'une location croisée ou d'un clone actualisable inter-région.

Restaurer la base de données source avec un clone actualisable à l'aide de clés de cryptage gérées par le client Notes

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 en cours d'utilisation 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 est en retard et que son point d'actualisation est antérieur au point de restauration, ce qui signifie que le clone actualisable contient des données antérieures à la base de données source restaurée, il commence à 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 automatiquement recréé lorsqu'il atteint le même point dans le temps avec des actualisations. Il doit alors commencer à afficher la même clé que la source.

Pour plus d'informations, reportez-vous à Restauration et récupération de votre instance Autonomous Database.

Clone actualisable déconnecté à l'aide de clés de cryptage gérées par le client - Notes

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 pendant 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é.

Remarques relatives aux clés gérées par le client avec le coffre dans la location distante

Pour utiliser des clés de cryptage maître gérées par le client avec un coffre dans une location distante, tenez compte des points suivants :

Lorsque vous utilisez des clés de cryptage maître gérées par le client avec un coffre dans une location distante, le coffre et l'instance Autonomous Database doivent se trouver dans la même région. Pour modifier la location, sur la page de connexion, cliquez sur Modifier la location. Après avoir modifié la location, veillez à sélectionner la même région pour l'instance Vault et l'instance Autonomous Database.