B Utilisation d'OKM avec le cryptage transparent des données (TDE) d'Advanced Security

Cette annexe décrit l'utilisation d'OKM avec le cryptage transparent des données (TDE) pour gérer le chiffrement ou le déchiffrement d'informations sensibles de base de données. Cette solution vous permet de gérer les clés de chiffrement pour la base de données Oracle à l'aide de la même technologie de chiffrement que celle utilisée dans les lecteurs de bande Oracle StorageTek.

Le cryptage transparent des données (TDE), une fonction d'Oracle Database 11gR2, fournit des services de chiffrement et de déchiffrement de base de données pour :

• Les produits Oracle Database

• Oracle Real Application Clusters (Oracle RAC)

• Oracle Data Guard

• Oracle Exadata Database Machine

• Oracle Recovery Manager (RMAN)

• Oracle Data Pump

Cette annexe suppose que vous êtes familiarisé avec TDE. Reportez-vous au document Oracle Advanced Security Transparent Data Encryption Best Practices, disponible à l'adresse URL suivante :

http://www.oracle.com/us/products/database/twp-transparent-data-encryption-bes-130696.pdf

Présentation du cryptage transparent des données (TDE)

Figure B-1 présente un cluster OKM comprenant des bases de données Oracle avec le cryptage transparent des données (TDE). Reportez-vous à Chapitre 1, "Introduction" pour plus d'informations sur les composants de base du cluster OKM.

Figure B-1 Cluster OKM avec TDE

TDE fournit des services de chiffrement utilisant une approche de clé à deux niveaux pour le chiffrement de colonne TDE et le chiffrement de tablespace TDE. Une clé de chiffrement principale est utilisée dans le premier niveau pour chiffrer la table du deuxième niveau ou les clés de chiffrement de données de tablespace stockées au sein de la base de données.

TDE stocke la clé de chiffrement principale dans un module de sécurité externe (Oracle Wallet ou HSM). Il s'agit d'une pratique de sécurité recommandée qui est essentielle au maintien du niveau de sécurité le plus élevé contre les différentes menaces. L'utilisation d'OKM pour le stockage sécurisé des clés de chiffrement principales de TDE est l'approche recommandée.

Avec TDE configuré pour utiliser OKM, OKM crée et protège la clé de chiffrement principale AES256. OKM protège les clés via la réplication (plusieurs copies à travers le cluster) et via des sauvegardes d'OKM lui-même.

Reportez-vous au document OKM Disaster Recovery Guide pour plus d'informations sur la planification de la récupération après sinistre.

Fournisseur PKCS#11 d'OKM

Un fournisseur PKCS#11 est disponible pour Oracle Solaris et Oracle Linux et a été certifié pour interfacer TDE avec OKM. Ce fournisseur se nomme "pkcs11_kms". TDE peut être configuré pour utiliser le fournisseur pkcs11_kms via son support intégré pour les modules HSM (Hardware Security Module).

Le fournisseur pkcs11_kms interagit avec OKM pour les opérations de création de clé et de récupération de clé. Les applications consommateur PKCS#11, comme TDE, peuvent utiliser le fournisseur pkcs11_kms afin d'obtenir des clés à utiliser pour les fonctions de chiffrement et de déchiffrement. Ces applications identifient les objets de clé à l'aide d'une étiquette qu'elles définissent. TDE génère cette étiquette lorsque la clé principale est créée. Le fournisseur pkcs11_kms transmet cette étiquette à OKM où elle est conservée en tant que métadonnées sur l'unité de données. Dans OKM, les clés sont associées à des unités de données et cette relation est toujours 1:1 pour le fournisseur pkcs11_kms. Chaque fois qu'une nouvelle clé principale est créée, une unité de données avec l'étiquette de la clé est créée avec l'objet de clé correspondant.

Pour plus d'informations, reportez-vous à la section "Localisation des clés principales TDE dans OKM".

Authentification de TDE auprès d'OKM

Une entité qui interagit avec OKM doit s'authentifier, que ce soit un utilisateur administratif qui se connecte, un lecteur de bande qui récupère un composant de clé ou un consommateur PKCS#11 comme Oracle TDE.

TDE s'authentifie auprès d'OKM par le biais du jeton spécifique configuré pour utiliser le fournisseur pkcs11_kms. Ce jeton utilise l'authentification par mot de passe et les certificats X.509 pour l'authentification mutuelle de chaque partie dans la session, en particulier l'instance de base de données Oracle et le noeud de cluster OKM. Vous devez configurer TDE pour transmettre correctement ces informations d'identification au jeton PKCS#11.

Pour obtenir des instructions de configuration, reportez-vous au document Oracle Advanced Security Transparent Data Encryption Best Practices, mentionné au début de cette annexe.

Gestion des informations d'authentification

OKM vous permet de gérer les informations d'authentification des agents à l'aide du fournisseur pkcs11_kms. Vous pouvez réinitialiser les phrases de passe des agents et activer, désactiver ou supprimer des agents en fonction de vos stratégies.

Si une faille de sécurité est détectée, vous pouvez désactiver l'agent spécifique de sorte que les récupérations de clé soient refusées, tout en autorisant les autres agents régissant d'autres applications ou périphériques à conserver leur accès.

Si vous réinitialisez la phrase de passe d'un agent, supprimez ensuite le répertoire de profil dans le répertoire dans lequel le fournisseur pkcs11_kms stocke sa configuration d'emplacement (par exemple, l'emplacement identifié par le répertoire KMSTOKEN_DIR).

Equilibrage de charge et basculement

Le fournisseur pkcs11_kms est informé du cluster OKM via l'utilisation des services de cluster OKM, d'un équilibreur de charge et de la logique de basculement du cluster. Le fournisseur pkcs11_kms conserve de manière transparente la connaissance côté client du cluster OKM en émettant périodiquement des opérations de découverte du cluster. Les modifications du réseau et du cluster OKM ou de la disponibilité des KMA sont gérées par l'agent pour le compte du fournisseur pkcs11_kms et de TDE. La charge des opérations de génération et de récupération de clé de PKCS#11 est équilibrée à travers les KMA du cluster OKM.

Pour optimiser davantage les performances de récupération de clé, les agents peuvent être configurés pour être associés aux KMA via l'utilisation des sites OKM. Cette fonction permet la définition de sites selon la topologie réseau. Généralement, les KMA et les agents au sein d'un site ont une latence réseau faible par rapport aux KMA et agents membres via une connexion WAN.

Lorsqu'un segment réseau ou KMA n'est pas disponible, la logique de basculement au sein de l'agent choisit un autre KMA pour terminer l'opération. TDE n'est pas conscient des basculements, les opérations de gestion de clés sont donc très fiables. Le basculement préfère les KMA au sein du même site que l'agent.

Vous pouvez utiliser l'utilitaire kmscfg(1M) pour régler la fréquence de découverte et les propriétés de basculement de l'agent. Reportez-vous à la page de manuel kmscfg pour plus d'informations.

Eléments à prendre en compte pour la planification

La section suivante traite de différents sujets de planification :

• Remarques sur Oracle Database

• Remarques sur les performances et la disponibilité d'OKM

• Planification de la récupération après sinistre

• Planification du réseau

• Planification de la gestion de clés.

Remarques sur Oracle Database

OKM est compatible avec les configurations d'Oracle Database suivantes :

• Instance unique, Oracle RAC à un noeud

• Architecture de haute disponibilité Oracle Database

  • Oracle RAC

    Oracle Database avec Oracle RAC (Oracle Real Application Clusters) est certifié avec OKM. Chaque noeud du système Oracle RAC nécessite un fournisseur pkcs11_kms configuré qui sera utilisé par TDE. Tous les noeuds doivent partager le même ID d'agent OKM pour l'authentification. Avec Oracle RAC, la topologie réseau utilise un réseau public et privé. Le réseau privé utilisé pour le trafic de noeud à noeud d'Oracle RAC peut être partagé avec le réseau de service OKM pour une meilleure isolation du trafic de récupération de clé. En fonction de la configuration de ce réseau privé, cela exclut vraisemblablement le basculement d'agent sur des KMA hors du réseau privé, comme des KMA sur un site distant.

    Reportez-vous à la section "Intégration d'OKM et TDE" pour obtenir les conditions requises pour le stockage partagé avec Oracle RAC et les fichiers de configuration du fournisseur pkcs11_kms.

  • Cluster étendu Oracle RAC

    Dans cette configuration, les KMA au sein du cluster OKM doivent se trouver sur le réseau avec les noeuds Oracle RAC afin de minimiser le temps de récupération.

  • Oracle Exadata Database Machine

    Reportez-vous à la section "Oracle RAC" ci-dessus.

• Oracle Data Guard

  Toutes les bases de données secondaires accèdent au même cluster OKM utilisé par la base de données principale.

• Plusieurs instances de base de données

  Lorsque vous exécutez plusieurs instances de base de données indépendantes sur un hôte, un jeton PKCS#11 doit être configuré pour chaque instance. Cela revient à créer un agent OKM pour chaque instance de base de données et à authentifier l'agent auprès d'OKM via le jeton. Exécutez l'outil kmscfg pour effectuer cette tâche.

  Lorsque vous exécutez plusieurs instances de base de données sous le même utilisateur de système d'exploitation, mais que vous utilisez des agents différents, vous devez définir la variable d'environnement KMSTOKEN_DIR sur un emplacement différent à chaque fois que vous invoquez l'utilitaire kmscfg. Reportez-vous à la section "Configuration d'OKM for TDE" pour plus d'informations sur l'utilitaire kmscfg.

  Pour plus d'informations sur l'exécution de plusieurs bases de données sur le même hôte, reportez-vous au document Oracle Advanced Security Transparent Data Encryption Best Practices, mentionné au début de cette annexe.

• Oracle RMAN

• Oracle Data Pump

Remarques sur les performances et la disponibilité d'OKM

Les récupérations de clé pour TDE par le biais du jeton pkcs11_kms prennent généralement entre 100-200 millisecondes par accès de KMA. Lors d'un basculement, le temps de réponse est un multiple du nombre de tentatives de basculement.

Les opérations de sauvegarde et de transfert de clé d'OKM sont des activités qui utilisent beaucoup de ressources et peuvent avoir un impact sur les performances de base de données OKM. Effectuez la planification soigneusement pour déterminer où et quand effectuer des sauvegardes d'OKM.

Les sauvegardes d'OKM étant effectuées à l'échelle du cluster, elles peuvent être effectuées sur des KMA qui ne servent pas les instances d'Oracle Database. De la même manière, les opérations de transfert de clé se font également à l'échelle du cluster et peuvent être effectuées sur n'importe quel KMA. Par conséquent, il est recommandé de choisir un KMA qui ne sert pas des instances occupées d'Oracle Database.

Planification de la récupération après sinistre

Pour plus d'informations sur la planification de la récupération après sinistre d'OKM, reportez-vous au document OKM Disaster Recovery Guide,, ainsi qu'aux publications relatives à Oracle Database.

Les décisions de la planification de la récupération après sinistre influent sur l'exercice de planification du réseau. Le répertoire de configuration du fournisseur pkcs11 est un nouvel élément à prendre en considération pour la planification de la récupération après sinistre. Prenez en considération les scénarios de récupération pour cette zone de stockage afin d'éviter de devoir reconfigurer un jeton pkcs11_kms, en particulier lorsqu'il est partagé entre les noeuds d'une instance Oracle RAC.

Planification du réseau

La configuration du cluster OKM doit être planifiée selon les serveurs Oracle Database et la stratégie de récupération après sinistre de l'entreprise. Les options de mise en réseau d'OKM sont très flexibles et incluent des interfaces multiréseau utilisées par le réseau de service et de gestion OKM. Reportez-vous au document OKM System Assurance Guide pour plus d'informations.

Planification de la gestion de clés

La planification de la gestion de clés doit s'occuper du cycle de vie des clés et des stratégies de sécurité de l'entreprise. Ces considérations mènent naturellement à des discussions sur la conservation des données.

• Reportez-vous à la section "Transition d'état" pour plus d'informations sur les phases de gestion de clés NIST SP-800 et les états de clé OKM correspondants.

• Reportez-vous à la section "Ressaisie de clé due à l'expiration de clé basée sur la stratégie OKM" pour plus d'informations sur un problème qui peut se produire lorsqu'une stratégie de clés n'est pas définie pour une période suffisamment longue.

Remarques sur la stratégie de clés

Toutes les clés principales de TDE sont des clés AES 256 bits générées par OKM. Les KMA peuvent contenir une carte PCIe Sun Crypto Accelerator 6000, un HSM certifié FIPS 140-2 de niveau 3. Lorsque les KMA disposent de ce module HSM, leurs clés sont créées par lui. Sinon, les opérations de chiffrement utilisent le fournisseur de jeton du logiciel Solaris Crypto Framework. Pour plus d'informations, reportez-vous à la section "Stratégies de clés".

Cycle de vie des clés

Le cycle de vie des clés est l'élément de configuration principal en ce qui concerne les décisions de la planification de la stratégie de clés. Les périodes de la phase opérationnelle du cycle de vie de la clé doivent être choisies en fonction des besoins de conservation des données et de la fréquence à laquelle les clés principales de TDE seront ressaisies. Reportez-vous à la section "Cycle de vie des clés" pour plus d'informations.

Remarque:

Le DDL du TDE prend en charge la spécification de différentes tailles de clé pour la clé principale tout comme les boîtes de dialogue de chiffrement de schéma au sein d'OKM. Seules les clés AES 256 bits peuvent être utilisées avec OKM.

Période de chiffrement de la stratégie de clés

La période de chiffrement de la stratégie de clés définit la durée d'utilisation de la clé à l'état "protéger et traiter" (chiffrer et déchiffrer) du cycle de vie. Cette période doit correspondre à la période de temps d'utilisation de la clé principale avant qu'elle ne soit ressaisie (par exemple, un an maximum pour PCI).

Durée de validité de la stratégie de clés

La durée de validité de la stratégie de clés est le temps restant alloué pour l'utilisation de la clé principale pour déchiffrer des données au cours de l'état "traiter uniquement" (déchiffrer uniquement) du cycle de vie de la clé. La longueur de cette période doit être conforme aux conditions requises de conservation des données pour les données protégées par la clé principale de TDE. Cette valeur est généralement un nombre d'années correspondant à la stratégie de l'entreprise concernant la conservation des données (par exemple, une période de conservation de sept ans pour les dossiers fiscaux américains).

Le taux de génération des nouvelles clés ne doit pas être concerné par le TDE car les opérations de ressaisie de clés ne seront vraisemblablement pas fréquentes. Toutefois, si cela devient un souci, envisagez d'allonger la période de chiffrement de la stratégie de clés et d'effectuer des opérations de ressaisie de clés moins fréquentes. Vous pouvez également augmenter le paramètre de configuration de taille de pool de clés d'OKM pour ordonner aux KMA de conserver un pool plus grand de clés disponibles.

Plusieurs stratégies de clés peuvent être définies pour être utilisées avec différents types de bases de données, selon vos besoins.

Contrôle de l'accès aux clés par le biais des groupes de clés

Il peut s'avérer nécessaire de contrôler l'accès aux clés gérées par OKM lorsque plusieurs instances de base de données ou plusieurs agents accèdent au cluster OKM à différentes fins.

Tous les agents OKM sont affectés à au moins un groupe de clés (une affectation de groupe de clés par défaut est requise), ce qui les autorisent à avoir accès aux clés au sein de ces groupes. Le groupe de clés par défaut de l'agent est le seul groupe de clés au sein duquel l'agent d'un fournisseur pkcs11_kms créera des clés.

Envisagez d'utiliser plusieurs groupes de clés lorsque les clés principales n'ont pas besoin d'être partagées entre les hôtes ou les instances de base de données. Un exemple consiste à utiliser un groupe de clés pour les instances de base de données de production et un autre groupe de clés pour les bases de données de développement/test, de sorte que l'isolement soit garanti. Les agents dans le groupe de clés de la base de données de test seront bloqués par OKM s'ils tentent d'utiliser une clé principale d'une base de données de production. Une telle tentative sera également marquée dans le journal d'audit de l'OKM et peut être un indicateur d'une erreur de configuration susceptible de perturber une base de données de production.

TDE offre également l'isolement des clés principales via leur convention de nommage d'étiquette de clé. Dans la spécification de PKCS#11, les étiquettes de clés n'ont pas besoin d'être uniques. Toutefois, OKM applique des étiquettes uniques, peu importe le groupe de clés, de sorte que l'étendue de l'espace de noms d'étiquette soit globale pour un cluster OKM. Si un conflit d'étiquette survient entre deux clés principales différentes pour deux instances de base de données différentes, la première étiquette créée est toujours renvoyée. Tout agent tentant d'accéder à une clé qui partage une étiquette identique appartenant à un autre groupe de clés sera refusé par OKM. Cela est détecté durant une opération de ressaisie de clé et la solution consiste à effectuer des opérations de ressaisie de clé jusqu'à ce qu'une nouvelle étiquette non conflictuelle soit générée.

Remarques relatives à la destruction des données et des clés

Pour se conformer aux exigences de conservation des données, la destruction des données peut commencer par la destruction des clés principales de TDE. Le moment et la façon dont ces clés doivent être détruites est un élément de planification important. OKM s'occupe de cela et du suivi des sauvegardes d'OKM, qui incluent ces clés. La gestion des sauvegardes d'OKM est à la fois un élément de planification de la récupération après sinistre et un élément de planification de la destruction de clés.

Intégration d'OKM et TDE

Cette section décrit comment installer et configurer pkcs11_kms et le cluster OKM pour l'utilisation avec TDE

Configuration système requise

Les versions minimales suivantes sont prises en charge lors de l'utilisation d'OKM avec TDE :

Oracle Key Manager

Oracle Key Manager 2.4.1 fonctionnant avec la version 13 du schéma de réplication

Les plates-formes de gestion OKM prises en charge pour l'interface graphique utilisateur et la CLI sont documentées dans les notes de version du produit OKM, qui incluent des considérations spécifiques pour les plates-formes Oracle Solaris et Microsoft Windows.

pkcs11_kms

• Oracle Solaris 11 Express avec SRU 12

• Oracle Solaris 11 pkcs11_kms, x86 ou SPARC, 32 ou 64 bits

• Oracle Solaris 10 Update 10 pkcs11_kms patch 147441-03 pour x86 ou patch 147159-02 pour SPARC, 32 ou 64 bits

• Oracle Enterprise Linux (OEL) version 5.5.

• Oracle Database 11.2.0.2 sur une plate-forme pkcs11_kms prise en charge et patch obligatoire 12626642.

Installation d'OKM

Le processus d'installation du cluster OKM est décrit dans le document OKM Installation Guide. Généralement, l'installation d'OKM implique les services professionnels Oracle, pour aider à la planification, l'installation et la configuration des choix de services. En outre, il est recommandé d'impliquer votre équipe de sécurité dans le processus de planification.

Après avoir établi un cluster OKM opérationnel, suivez les étapes d'administration d'OKM décrites dans les sections de configuration de cette annexe.

Installation de pkcs11_kms

Vous devez installer et configurer le fournisseur PKCS#11 d'OKM, pkcs11_kms, sur le(s) serveur(s) de base de données d'Oracle. Une distribution de pkcs11_kms est disponible pour chacune des plates-formes suivantes :

• Oracle Solaris 11 ou Solaris 11 Express

• Oracle Solaris 10 Update 10

• Oracle Enterprise Linux

Installation de pkcs11_kms pour Oracle Solaris 11 ou Solaris 11 Express

Procédez comme suit pour installer pkcs11_kms :

1. Affichez la version du package pkcs_kms :

   #> pkg info -r pkcs11_kms
   

   Vérifiez le résultat de cette commande.

2. Pour Solaris 11, entrez la commande suivante :

   #> pkg install system/library/security/pkcs11_kms
   

   Pour Solaris 11 Express, entrez la commande suivante :

   #> pkg install system/library/security/crypto/pkcs11_kms 
   

3. Installez le fournisseur dans le Solaris Crypto Framework.

   # cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
   

   Remarque:

   Les guillemets simples sont significatifs. Voir cryptoadm(1M).

4. Entrez la séquence de commandes suivante pour vérifier l'installation :

   # cryptoadm list -m -v \
   provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
   

   Remarque:

   Le message 'no slots presented' (aucun emplacement présenté) s'affiche jusqu'à ce que kmscfg soit exécuté.

Installation de pkcs11_kms pour Oracle Solaris 10 Update 10

La distribution de pkcs est installée en tant que "SUNWpkcs11kms" dans les installations Solaris 10 Update 10.

• Les systèmes SPARC nécessitent le patch Solaris 147159-03 ou une version ultérieure.

• Les systèmes x86 nécessitent le patch Solaris 147441-03 ou une version ultérieure.

Pour télécharger les patches Solaris, accédez à l'adresse URL suivante :

https://patchstatus.us.oracle.com/patchstatus/

Procédez comme suit pour installer pkcs11_kms :

1. Entrez la commande suivante pour installer le package pkcs11_kms pour la plate-forme matérielle :

   # pkgadd [-d path to parent dir of package] SUNWpkcs11kms
   

2. Installez le fournisseur dans le Solaris Crypto Framework.

   # cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
   

   Remarque:

   Les guillemets simples sont significatifs. Voir cryptoadm(1M).

Installation de pkcs11_kms pour Oracle Enterprise Linux

pkcs11_kms est distribué en tant que "patch" 13245560 sur le site My Oracle Support, à l'adresse URL suivante :

http://www.myoraclesupport.com

Connectez-vous et cliquez sur l'onglet Patches et mises à jour. Cherchez ensuite directement l'ID du patch spécifique ou recherchez le produit Oracle Key Manager et la version Oracle Key Manager 2.5.

pkcs11_kms est distribué en tant que package RPM. Utilisez les commandes du gestionnaire de packages RPM pour installer ce logiciel.

Par exemple :

# rpm -i pkcs11kms-1.0.0-1.x86_64.rpm 

Désinstallation de pkcs11_kms

Les commandes suivantes désinstallent pkcs11_kms.

Désinstallation de pkcs11_kms pour Oracle Solaris 11

Pour désinstaller pkcs11_kms, entrez les commandes suivantes :

# cryptoadm uninstall \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
# pkg uninstall system/library/security/pkcs11_kms

Désinstallation de pkcs11_kms pour Oracle Solaris 10 Update 10

Pour désinstaller pkcs11_kms, entrez la commande suivante :

# pkgrm SUNWpkcs11kms

Désinstallation de pkcs11_kms pour Oracle Enterprise Linux

Lorsqu'il est fourni avec Oracle Database, le fournisseur pkcs11_kms sera désinstallé par le biais des étapes de désinstallation du produit Oracle Database. S'il est désinstallé par un autre moyen, suivez les procédures inverses pour l'installation à l'aide de rpm.

Par exemple :

# rpm -e pkcs11kms-1.0.0-1.x86_64.rpm

Configuration d'OKM for TDE

La section suivante couvre la configuration de TDE.

Configuration d'Oracle Database TDE

Chaque serveur de base de données Oracle doit exécuter la version 11.2.0.2 ou une version ultérieure sur une plate-forme pkcs11_kms prise en charge. Le patch obligatoire 12626642 doit être installé. Ce patch est disponible à l'adresse URL suivante :

https://updates.oracle.com/download/12626642.html

Une fois installé, le fichier de bibliothèque partagée (pkcs_kms.so) doit être configuré pour l'accès de TDE. Le chemin d'accès à la bibliothèque est spécifique au système d'exploitation :

• /usr/lib/security/pkcs11_kms.so.1 (Solaris uniquement, 32 bits)

• /usr/lib/security/amd64/pkcs11_kms.so.1 (Solaris uniquement, 64 bits)

• /usr/lib64/pkcs11_kms.so.1 (Linux uniquement, 64 bits)

Configuration du cluster OKM pour TDE

La liste suivante résume les tâches requises pour configurer le cluster OKM pour TDE :

• Ces tâches supposent qu'un cluster OKM opérationnel est configuré avec les utilisateurs administratifs et rôles appropriés.

• Tous les KMA dans le cluster OKM doivent exécuter OKM 2.4.1 et la version de 13 de Replication au minimum.

1. Définissez la stratégie de clés.

   Voir :

   • "Stratégies de clés"

   • "Remarques sur la stratégie de clés".

2. Définissez la définition de groupe.

   Affectez la stratégie de clés au groupe de clés et un nom pratique au groupe.

   Voir :

   • "Groupes de clés"

   • "Contrôle de l'accès aux clés par le biais des groupes de clés"

3. Configurez le ou les agents.

   Voir :

   • "Fournisseur PKCS#11 d'OKM".

   • "Menu Agent List (Liste des agents)"

4. Associez chaque agent à un groupe de clés par défaut.

   Reportez-vous à la section "Menu Key Group Assignment to Agents (Affectation de groupes de clés à des agents)".

ID d'agent

L'ID d'agent peut être n'importe quel élément significatif pour la configuration et doit correspondre à l'utilisateur Oracle pour l'instance de base de données à associer à l'agent.

Phrase de passe

Choisissez une phrase de passe forte car elle sera également configurée sur l'hôte Oracle pour l'authentification auprès d'OKM par le biais des instructions DDL qui ouvrent le portefeuille (par exemple, le jeton pkcs11_kms). Reportez-vous à la section "Création d'un agent" pour plus d'informations sur les exigences de phrase de passe.

L'indicateur OneTimePassphrase doit être défini sur "false" (faux) pour autoriser l'authentification par mot de passe à chaque fois que le "portefeuille" du TDE doit être ouvert, ainsi que depuis plusieurs noeuds Oracle RAC qui partagent un ID d'agent commun. Pour une sécurité maximale, il peut être défini sur la valeur par défaut "true" (vrai), mais fonctionnera uniquement dans une configuration Oracle Database à un seul noeud et non dans Oracle RAC. Lorsque OneTimePassphrase est défini sur true (vrai), le certificat X.509 de l'agent est renvoyé uniquement lorsque l'agent s'authentifie avec succès la première fois Le fournisseur pkcs11_kms stocke la clé privée du certificat X.509 de manière sécurisée dans un fichier PKCS#12 protégé par une phrase de passe. Le certificat X.509 et la clé privée correspondante sont ensuite utilisés pour les transactions d'agent avec OKM. Reportez-vous à kmscfg(1M) pour les autres informations stockées par le fournisseur pkcs11_kms.

Groupe de clés

Affectez l'agent au(x) groupe(s) de clés défini(s) pour TDE. Le fournisseur pkcs11_kms prend uniquement en charge le groupe de clés par défaut pour les opérations de création de clé, notamment les opérations de ressaisie de clé. Tout groupe de clés supplémentaire autre que celui par défaut et associé à l'agent autorisera uniquement les récupérations de clé à partir des clés dans ces groupes. Cette capacité doit être exploitée dans des scénarios de base de données en lecture seule/déchiffrement seul, tels que la prise en charge d'une base de données secondaire qui ne générera jamais de clé principale, mais qui a uniquement besoin de pouvoir accéder aux clés principales.

Configuration de pkcs11_kms pour TDE

Le fournisseur pkcs11_kms doit être configuré sur les noeuds Oracle Database qui nécessiteront les clés principales TDE. Procédez comme suit pour configurer le fournisseur pkcs11_kms :

1. Remarques relatives à l'utilisateur du système d'exploitation :

   Configurez l'agent et le fournisseur pkcs11_kms à l'aide du compte utilisateur Oracle Database. Cela ne nécessite pas de privilèges particuliers pour l'utilisateur du système d'exploitation. Lorsqu'un hôte prend en charge "plusieurs répertoires d'origine Oracle Home", la configuration du jeton pkcs11_kms doit se conformer à chaque compte utilisateur de propriétaire du logiciel Oracle Database. Reportez-vous au document Oracle Database Installation Guide 11g Release 2 pour plus d'informations.

2. L'utilitaire kmscfg crée une configuration d'emplacement par utilisateur à la fois. Il est possible de définir des configurations d'emplacement supplémentaires pour un utilisateur individuel, mais une seule sera active par processus.

   Mise en garde:

   L'emplacement par défaut du répertoire de configuration d'emplacement du fournisseur PKCS#11 de KMS est /var/kms/$USER sous Solaris 11 Express et /var/user/$USER/kms sous Solaris 11 SRU5. Si vous prévoyez de mettre à niveau votre système Solaris 11 Express vers Solaris 11 SRU5, vous devez d'abord enregistrer votre configuration d'emplacement ailleurs.

   Par exemple :

   # cd /var/kms/$USER

   # tar cvf ~/save_my_okm_config.tar .

   Après la mise à niveau, restaurez votre configuration d'emplacement dans le nouvel emplacement. Par exemple :

   # mkdir -p /var/user/$USER/kms

   # cd /var/user/$USER/kms

   # tar xvf ~/save_my_okm_config.tar

   Si vous ne sauvegardez pas les données de pcks11_kms avant la mise à niveau, vos données seront perdues et la clé principale utilisée par la base de données Oracle pour les données chiffrées ne sera pas disponible.

   L'utilitaire kmscfg stocke les données de configuration et d'exécution dans un répertoire de configuration KMS dans un des chemins suivants :

   • /var/user/$USER/kms (Solaris 11)

   • /var/kms/$USER (Solaris 10u10 et Solaris 11 Express)

   • /var/opt/kms/$USER (Oracle Enterprise Linux)

   Ce répertoire est remplacé par la variable d'environnement $KMSTOKEN_DIR dans l'emplacement choisi par le client.

   Lorsque kmscfg est exécuté, un nom de "profil" est fourni. Ce nom est utilisé pour le sous-répertoire d'exécution spécifique à l'agent créé au sein du répertoire de configuration décrit ci-dessus.

3. Reportez-vous à la page de manuel kmscfg pour l'emplacement par défaut de ses configurations d'emplacement. Les configurations d'emplacement peuvent être contrôlées à l'aide de la variable d'environnement KMSTOKEN_DIR pour définir un emplacement alternatif de système de fichiers et de configuration d'emplacement.

   Pour Oracle RAC, où l'agent doit être partagé entre les noeuds Oracle RAC, utilisez la variable d'environnement KMSTOKEN_DIR pour ordonner à kmscfg de créer le profil à l'aide du chemin de système de fichiers approprié. Si la variable d'environnement KMSTOKEN_DIR est définie, elle doit être définie de manière permanente pour le shell dans un fichier de configuration de shell (comme .bashrc), de sorte qu'elle soit toujours définie avant que la base de données n'effectue des opérations PKCS#11.

4. Allouez de l'espace de stockage du système de fichiers pour les informations de configuration et d'exécution de l'emplacement. Si vous prévoyez d'utiliser Oracle RAC, définissez le profil dans un emplacement de système de fichiers partagés avec des droits qui sont accessibles en lecture et en écriture par chaque utilisateur du noeud Oracle RAC.

5. Allouez les conditions requises d'espace pour permettre à chaque journal d'agent de croître. Le fichier journal est automatiquement créé et constitue un outil de dépannage utile. L'espace consommé par le fichier KMSAgentLog.log peut être géré à l'aide d'un outil tel que logadm(1M) sous Solaris ou logrotate(8) sous Oracle Enterprise Linux. L'allocation de 10 Mo au répertoire de profil de chaque agent est suffisante pour la plupart des configurations.

6. Initialisez un fournisseur pkcs11_kms à l'aide l'utilitaire kmscfg. Dans cette étape, vous définissez un profil pour l'agent OKM qui sera ensuite associé à un jeton pkcs11_kms.

    # kmscfg 
    Profile Name: oracle
    Agent ID: oracle
    KMA IP Address: kma1
   

   A ce stade, vous avez défini un emplacement pkcs11 et vous pouvez vérifier l'authentification avec OKM.

   1. Sur les systèmes Solaris, vérifiez l'authentification à l'aide de la commande cryptoadm(1M). Notez que le champ d'indicateur affiche CKF_LOGIN_REQUIRED dans l'exemple suivant, indiquant que l'emplacement n'est pas encore configuré avec un jeton authentifié.

      solaris> cryptoadm list -v \ 
      provider='/usr/lib/security/$ISA/pkcs11_kms.so.1' 
      Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1 
      Number of slots: 1  
      Slot #1 
      Description: Oracle Key Management System 
      Manufacturer: Oracle Corporation 
      PKCS#11 Version: 2.20 
      Hardware Version: 0.0 
      Firmware Version: 0.0 
      Token Present: True 
      Slot Flags: CKF_TOKEN_PRESENT 
      Token Label: KMS 
      Manufacturer ID: Oracle Corporation 
      Model: 
      Serial Number:
      Hardware Version: 0.0
      Firmware Version: 0.0
      UTC Time:
      PIN Min Length: 1
      PIN Max Length: 256
      Flags: CKF_LOGIN_REQUIRED
      

   2. Vérifiez que le jeton pkcs11_kms peut s'authentifier auprès du cluster OKM.

      Cet exemple utilise Oracle Solaris pktool(1), un utilitaire qui n'est pas disponible pour les plates-formes Linux.

      solaris> pktool inittoken currlabel=KMS
      Enter SO PIN:
      Token KMS initialized.
      

      Le SO (abréviation de PKCS#11 pour un responsable de la sécurité) vous invite à saisir la phrase de passe secrète de l'agent, comme établie dans une étape précédente par l'administrateur OKM qui a créé l'agent.

   3. Sur les systèmes Solaris, vérifiez que le jeton est initialisé à l'aide de la commande cryptoadm(1M) de Solaris Crypto Framework ou de l'utilitaire pktool(1). Notez que l'indicateur du jeton affiché par la sortie de cryptoadm est désormais CKF_TOKEN_INITIALIZED :

      solaris> cryptoadm list -v \
      provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
       Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1
       Number of slots: 1
       Slot #1
       Description: Oracle Key Management System
       Manufacturer: Oracle Corporation
       PKCS#11 Version: 2.20
       Hardware Version: 0.0
       Firmware Version: 0.0
       Token Present: True
       Slot Flags: CKF_TOKEN_PRESENT
       Token Label: KMS
       Manufacturer ID: Oracle Corporation
       Model:
       Serial Number:
       Hardware Version: 0.0
       Firmware Version: 0.0
       UTC Time:
       PIN Min Length: 1
       PIN Max Length: 256
       Flags: CKF_LOGIN_REQUIRED CKF_TOKEN_INITIALIZED
      

   4. Sur les systèmes Solaris, utilisez l'utilitaire pktool(1) pour vérifier le statut des jetons visibles de PKCS#11 :

      glengoyne> pktool tokens
      Flags: L=Login required  I=Initialized  X=User PIN expired  S=SO PIN expired
      Slot ID  Slot Name     Token Name                  Flags
      -------  ---------     ----------                  -----
      1        Sun Crypto    Softtoken      Sun Software PKCS#11 softtoken
      2        Oracle Key Management System              KMS  L
      glengoyne>
      

      Il indique que la connexion au jeton est toujours requise. La signification des indicateurs dans la sortie de pktool peut être indiquée comme suit :

      glengoyne> pktool tokens -h
      Usage:
         pktool -?    (help and usage)
         pktool -f option_file
         pktool subcommand [options...]
      

      où les sous-commandes peuvent être :

         tokens
         * flags shown as: L=Login required  I=Initialized  
           E=User PIN expired  S=SO PIN expired
      glengoyne>
      

   5. Sur les systèmes Solaris, exécutez l'utilitaire pktool(1) pour vous connecter au jeton et vous authentifier avec le KMA du cluster OKM spécifié à l'étape kmscfg(1) et la phrase de passe créé par un administrateur OKM pour l'agent. Cette phrase de passe est fournie avec l'invite PIN du responsable de la sécurité :

      glengoyne> pktool inittoken currlabel=KMS
      Enter SO PIN:
      Token KMS initialized.
      

   6. Sur les systèmes Solaris, exécutez l'utilitaire pktool(1) pour vérifier le statut du jeton et qu'il est désormais initialisé :

      glengoyne> pktool tokens
      Flags: L=Login required  I=Initialized  X=User PIN expired  S=SO PIN expired
      Slot ID  Slot Name   Token Name                    Flags
      -------  ---------   ----------                    -----
      1        Sun Crypto  Softtoken         Sun Software PKCS#11 softtoken
      2        Oracle Key Management System              KMS   LI
      

   7. Sur les systèmes Solaris, exécutez la commande cryptoadm(1M) pour vérifier que le jeton pkcs11_kms est initialisé en demandant à voir les mécanismes qu'il prend en charge :

      glengoyne> cryptoadm list -m -p  provider=/usr/lib/security/'$ISA'/pkcs11_kms.so.1
      Mechanisms:
      CKM_AES_KEY_GEN
      CKM_AES_CBC
      CKM_AES_CBC_PAD
      glengoyne>
      

      Sur les systèmes Solaris, utilisez l'utilitaire pktool(1) pour créer et répertorier les clés via le fournisseur pkcs11_kms comme suit :

       # pktool genkey token=KMS keytype=aes keylen=256
         label=MyKey-test1
       # pktool list token=KMS objtype=key
       # pktool list token=KMS objtype=key label=MyKey-test1
      

      Vous pouvez voir les clés dans le système OKM par le biais de l'interface graphique utilisateur d'OKM Manager ou de la CLI d'OKM.

   Remarque:

   Pour Solaris, kmscfg(1) par défaut crée une seul configuration d'emplacement par utilisateur à la fois.

   Vous pouvez définir des configurations d'emplacement supplémentaires, mais une seule sera active par processus. Pour ce faire, utilisez la variable KMSTOKEN_DIR pour définir un emplacement alternatif de système de fichiers et de configuration d'emplacement.

   Le répertoire par défaut pour Solaris 11 est /var/user/$USERNAME/kms, mais vous pouvez créer vos propres schémas de nommage. Une pratique recommandée peut être

   /var/user/$USERNAME/$AGENTID-$CLUSTER/

   Cette convention de nommage permet à Solaris d'avoir plusieurs combinaisons emplacement-agent-cluster en fonction de divers scénarios d'utilisation.

   Pour certaines configurations PKCS#11, un emplacement alternatif est recommandé, par exemple, TDE avec Oracle RAC (reportez-vous à la section relative à la configuration de TDE ci-dessus), de sorte que chaque noeud partage les métadonnées du fournisseur pkcs11_kms.

7. Pour configurer TDE pour utiliser des portefeuilles à ouverture automatique, suivez les instructions décrites dans le document Oracle Advanced Security Transparent Data Encryption Best Practices, mentionné au début de cette annexe.

Opérations continues

Les sections suivantes décrivent les tâches opérationnelles récurrentes d'OKM et TDE.

Migration des clés principales depuis le portefeuille Oracle

L'ancien portefeuille doit être conservé et une nouvelle clé principale sera générée par OKM et protégée par le système de gestion de clés.

Reportez-vous au document Oracle Advanced Security Transparent Data Encryption Best Practices, mentionné au début de cette annexe.

TDE génère une étiquette de clé unique qui identifie chaque clé principale. Les valeurs de clés actuelles ne sont jamais exposées en texte simple jusqu'à ce qu'elles soient transmises du jeton pkcs11_kms au TDE. La clé "créée" sera retirée d'un pool de clés AES 256 bits à l'état actif (répliqué en toute sécurité sur plusieurs KMA). Cette clé sera ensuite associée à une stratégie de clés d'OKM conformément à l'agent spécifique utilisé par le jeton PKCS#11. OKM gère ensuite la clé conformément au cycle de vie de clé dicté par la stratégie.

Opération de ressaisie de clé

L'administrateur Oracle Database doit effectuer des opérations de ressaisie de clé avant que le cycle de vie de la clé ne le dicte. Sinon, la base de données ne démarre pas.

Reportez-vous aux différents documents relatifs à Oracle Database et TDE pour le DDL utilisé pour effectuer cette opération. La ressaisie de clé peut également être effectuée à l'aide d'Oracle Enterprise Manager.

Ressaisie de clé due à l'expiration de clé basée sur la stratégie OKM

Lorsqu'une clé atteint l'état post-opérationnel, chaque récupération de clé par TDE déclenche un avertissement dans les journaux d'audit OKM indiquant qu'une clé post-opérationnelle a été récupérée. La présence de ces messages d'audit est une indication qu'il est temps de ressaisir la clé de chiffrement principale de l'instance de base de données. Le message d'audit OKM identifie l'agent spécifique et la clé qui est récupérée afin de faciliter l'identification de l'instance Oracle Database et de la clé de chiffrement principale qui a atteint l'état post-opérationnel. La notification par le biais de notifications SNMP v3 ou de déroutements SNMP v2 peut être configurée dans OKM pour prendre en charge l'automatisation de ce processus.

Le fournisseur pkcs11_kms tentera d'informer ses consommateurs PKCS#11 que la clé a atteint l'état post-opérationnel. Cela se fait en définissant l'attribut "CKA_ENCRYPT" de PKCS#11 sur false (faux) pour la clé principale.

Oracle Database 11gR2 continue actuellement d'utiliser une clé pour chiffrer les données après l'expiration de sa période de chiffrement. Vous pouvez constater ce comportement lorsque l'erreur suivante s'affiche dans le journal d'alertes :

HSM heartbeat died. Likely the connection has been lost. PKCS11 function C_EncryptInit returned
PKCS11 error code: 104
HSM connection lost, closing wallet

Si cette erreur est rencontrée, l'administrateur de base de données doit effectuer les actions suivantes :

1. Définir la variable d'environnement suivante pour l'utilisateur associé au jeton pkcs11_kms (généralement le profil de l'utilisateur Oracle) :

   # export PKCS11_KMS_ALLOW_ENCRYPT_WITH_DEACTIVATED_KEYS=1
   

2. Redémarrer la base de données.

3. Ressaisir la clé principale pour l'instance de base de données.

Pour éviter l'erreur décrite ci-dessus, il est recommandé d'utiliser une période de chiffrement très longue dans la stratégie de clés associée aux agents Oracle Database. Vous pouvez également modifier le comportement du fournisseur pkcs11_kms pour désactiver la vérification de l'état de la clé. Pour ce faire, définissez la variable d'environnement décrite dans l'étape 1 ci-dessus. Une fois cette variable définie, le HSM peut être ouvert.

Malgré cela, TDE continue d'utiliser la clé et de ne pas effectuer d'opération de ressaisie de clé automatique. Les administrateurs OKM qui observent les avertissements d'audit de récupération de clé post-opérationnelle doivent informer un administrateur de base de données qu'il est temps de ressaisir la clé principale de leur instance de base de données.

Conversion depuis une autre solution HSM

Contactez le support technique Oracle pour obtenir les étapes spécifiques requises pour effectuer la conversion d'une solution HSM d'un autre fournisseur vers OKM.

Destruction de clé

Avant de détruire des clés qui ont atteint la phase post-opérationnelle, l'administrateur OKM doit vérifier que la clé n'est plus utilisée.

Les administrateurs OKM sont responsables de la destruction régulière des clés dans la phase post-opérationnelle. La suppression des clés par le biais du fournisseur kcs11_kms n'est pas prise en charge par OKM et constitue une opération restreinte réservée aux utilisateurs OKM auxquels le rôle Opérateur a été attribué. Lorsqu'une clé a été détruite, toute tentative de récupération de celle-ci échoue, y compris les requêtes C_FindObjects de PKCS#11.

Transfert de clés en faveur d'Oracle RMAN et/ou Oracle Data Pump

L'utilisation d'Oracle RMAN et/ou Oracle Data Pump peut nécessiter la capacité de fournir la clé principale à un autre cluster OKM, peut-être à un site de récupération après sinistre ou avec un partenaire. Les opérations de transfert de clé d'OKM prennent rapidement cela en charge à l'aide des services sécurisés d'importation et d'exportation de clés. Reportez-vous à la section "Transfert de clés" pour plus d'informations.

Procédez comme suit :

1. Etablissez les partenaires de transfert de clés entre les clusters OKM source et cible.

2. Identifiez les clés principales de TDE à exporter en faveur des sauvegardes Oracle RMAN ou des données chiffrées exportées à l'aide d'Oracle Data Pump.

3. Exportez les clés depuis le cluster OKM source. Cela crée un fichier d'exportation de clés sécurisé.

4. Transmettez le fichier de clés exporté au partenaire de transfert.

5. Le partenaire de transfert cible importe les clés dans leur cluster OKM.

Exécutez la restauration Oracle RMAN ou l'importation Oracle Data Pump pour recréer l'instance de base de données qui nécessite les clés. Cela nécessite les étapes de configuration nécessaires à l'utilisation de TDE avec OKM à l'emplacement d'importation. L'opération de restauration ou d'importation accède ensuite à l'OKM pour obtenir les clés principales universelles requises pour déchiffrer la colonne ou les clés de tablespace utilisées par l'instance de base de données.

Gestion

Une fois le système actif, utilisez les instructions suivantes pour gérer et contrôler efficacement la solution.

Attestation, audit et contrôle

Oracle donne les conseils suivants :

• Consultez et contrôlez l'historique actif OKM de l'agent TDE pour aider à détecter les problèmes.

• Les auditeurs peuvent utiliser des événements d'audit OKM pour attester que TDE accède à ses clés principales à partir du cluster OKM.

• Configurez le gestionnaire SNMP pour OKM.

• Explorez l'utilisation de la CLI d'OKM pour générer des rapports spécifiques à l'entreprise.

Localisation des clés principales TDE dans OKM

Vous pouvez localiser les clés principales TDE au sein d'OKM à l'aide de l'outil de gestion de l'interface graphique utilisateur ou à l'aide de la CLI. TDE génère des étiquettes de clé principale et OKM utilise l'attribut External Tag (Balise externe) d'une unité de données pour stocker cette valeur. La génération de clés principales TDE (y compris les opérations de ressaisie de clé) crée toujours un nouvel objet d'unité de données et un nouvel objet de clé au sein du cluster OKM.

Pour localiser une clé principale TDE, procédez comme suit :

1. Lancez une requête sur les unités de données OKM et filtrez la liste à l'aide d'un filtre ExternalTag (Balise externe) : "ExternalTag" commence par "ORACLE.TDE". Toutes les étiquettes de clé TDE commencent par cette chaîne et cela générera donc une liste des unités de données OKM créées par TDE. Chaque unité de données OKM aura une clé principale TDE unique associée. Ces clés peuvent être consultées à l'aide de l'interface graphique d'OKM pour examiner leur état de cycle de vie et d'autres propriétés, comme le groupe de clés, le statut d'importation/exportation et les sauvegardes OKM qui contiennent des clés détruites. Ces clés peuvent également être consultées à l'aide de la CLI d'OKM. Par exemple :

   >okm listdu --kma=acme1 --user=joe \
   --filter="ExternalTag=ORACLE.TDE"
   

2. Lorsque plusieurs instances d'Oracle Database partagent un cluster OKM, un administrateur OKM peut identifier les clés qui correspondent à une base de données particulière à l'aide d'une requête sur les événements d'audit de l'agent qui correspond à l'instance de base de données. Ces événements d'audit peuvent être consultés à l'aide de l'interface graphique utilisateur d'Oracle. Filtrez l'historique d'audit de l'agent à l'aide du filtre : "Operation equals CreateDataUnit". Cela génère une liste des événements d'audit correspondant aux créations de clés principales TDE. Les détails des événements d'audit fournissent les informations nécessaires pour identifier les unités de données spécifiques des clés principales. Ces événements d'audit peuvent également être consultés à l'aide de la CLI d'OKM. Par exemple :

   >okm listauditevents --kma=acme1 --user=joe \
   --filter="Operation=CreateDataUnit"
   

Dépannage

Cette section décrit les conditions d'erreur qui peuvent être rencontrées lors de l'utilisation d'OKM avec TDE.

Impossible de récupérer la clé principale

Oracle Database signale l'une des erreurs suivantes lorsque la clé principale ne peut pas être récupérée :

• ORA-28362

• ORA-06512

Si ces erreurs sont rencontrées, effectuez les étapes de diagnostic suivantes pour identifier le problème :

1. Examinez le fichier $ORACLE_BASE/diag/rdbms/$SID/$SID/trace/alert_$SID.log. Ce fichier consigne les messages de succès/d'échec liés aux instructions DDL de "modification" utilisées pour accéder au portefeuille de chiffrement.

2. Examinez le fichier KMSAgentLog.log dans le répertoire de configuration de pkcs11_kms ($KMSTOKEN_DIR/KMSAgentLog.log).

3. Vérifiez le statut général d'OKM. Vérifiez ce qui suit :

   • Les KMA sont-ils actifs ?

   • Les KMA sont-ils verrouillés ?

   • Le pool de clés est-il arrivé à expiration ?

   • Pannes d'ILOM/ELOM du KMA

   • Messages de la console du KMA

4. Vérifiez le statut du jeton pkcs11_kms, comme montré précédemment.

5. Vérifiez le statut de l'agent en examinant les événements d'audit OKM pour cet agent afin de vous assurer qu'il est inscrit et activé.

6. Vérifiez la connectivité réseau de l'hôte Oracle Database vers les noeuds OKM.

7. Contactez le support technique Oracle. Vous serez peut-être invité à fournir un ou plusieurs vidages système de KMA.

Perte du répertoire de configuration de pkcs11_kms

Utilisez la procédure suivante pour récupérer un profil de jeton pkcs11_kms perdu ou endommagé :

1. Suivez les étapes de configuration décrites dans "Configuration d'OKM for TDE".

2. Solaris uniquement - Renseignez à nouveau les métadonnées du jeton, à l'aide du filtre d'unité de données suivant avec l'OKM : "ExternalTag" commence par "ORACLE.TDE".

3. Solaris uniquement - Enregistrez les résultats de cette liste dans un fichier (par exemple, "du.lst"), puis réexécutez le script de shell suivant :

   for label in `awk '{print $2}' < du.lst `
   do
   pktool list token=KMS objtype=key label="${label}"
   done
   

Erreur indiquant qu'aucun emplacement n'est disponible.

Le client obtient des erreurs "No Slots Available" (Aucun emplacement disponible) lors de l'émission d'une opération PKCS#11.

1. Assurez-vous que l'utilitaire kmscfg a été exécuté avec succès.

2. Assurez-vous que le fournisseur pkcs11_kms a été correctement installé et configuré.

Erreur CKA_GENERAL_ERROR

Le client obtient l'erreur CKA_GENERAL_ERROR lorsqu'il tente de récupérer des clés.

1. Vérifiez que l'agent dispose d'un groupe de clés par défaut dans le cluster OKM.

2. Consultez le fichier $KMSTOKEN_DIR/KMSAgentLog.log pour plus d'informations.

Erreur indiquant l'échec de l'ouverture du fichier PKCS#12

L'erreur "Could not open PKCS#12 file" (Echec de l'ouverture du fichier PKCS#12) apparaît dans le fichier $KMSTOKEN_DIR/KMSAgentLog.log.

1. Sélectionnez les événements d'audit dans le cluster OKM pour déterminer si la phrase de passe de l'agent a été modifiée récemment.

2. Supprimez le répertoire <profile-name> sous $KMSTOKEN_DIR.