Documentation Oracle Cloud Infrastructure

Configuration des fonctionnalités d'Oracle Database pour Exadata Cloud Infrastructure

Cette rubrique explique comment configurer Oracle Multitenant, le cryptage de tablespace et les pages de grande taille à utiliser avec votre instance Exadata Cloud Infrastructure.

Utilisation d'Oracle Multitenant sur une instance Exadata Cloud Infrastructure

Lorsque vous créez une instance Exadata Cloud Infrastructure utilisant Oracle Database 12c ou version ultérieure, un environnement Oracle Multitenant est créé.

L'architecture colocative permet à une base de données Oracle de fonctionner comme une base de données Conteneur colocative contenant zéro, une ou plusieurs bases de données pluggables. Une base de données pluggable est une collection portable de schémas, d'objets de schéma et d'objets non-schéma qui apparaît sous la forme d'une base de données non Conteneur pour un client Oracle Net Services. Toutes les bases de données Oracle utilisant des versions antérieures à Oracle Database 12c sont des bases de données non Conteneur.

Afin d'utiliser le cryptage transparent des données Oracle dans une base de données pluggable, vous devez créer et activer une clé de cryptage maître pour la base de données pluggable.

Dans un environnement colocatif, chaque base de données pluggable possède sa propre clé de cryptage maître qui est stockée dans un fichier de clés unique utilisé par tous les conteneurs.

Vous devez exporter et importer la clé de cryptage maître pour toutes les bases de données pluggables cryptées que vous connectez à la base de données Conteneur de votre instance Exadata Cloud Infrastructure.

Si la base de données pluggable source est cryptée, vous devez exporter la clé de cryptage maître, puis l'importer.

Vous pouvez exporter et importer toutes les clés de cryptage maître TDE qui appartiennent à la base de données pluggable en exportant puis en important les clés de cryptage maître TDE à partir d'une base de données pluggable. L'export et l'import de clés de cryptage maître TDE prennent en charge les opérations de déconnexion et de connexion de base de données pluggable. Au cours de la déconnexion et de la connexion d'une base de données pluggable, toutes les clés de cryptage maître TDE qui lui appartiennent, ainsi que les métadonnées, sont impliquées.

Reportez-vous à "Export et import de clés de cryptage maître TDE pour une base de données pluggable" dans le guide de sécurité avancée Oracle Database pour la version 19, 18, 12.2 ou 12.1.

Reportez-vous à "ADMINISTER KEY MANAGEMENT" dans la référence de langage SQL Oracle Database pour la version 19, 18, 12.2 ou 12.1.

Procédure pour déterminer si une clé de cryptage doit être créée ou activée pour la base de données pluggable

  1. Appelez SQL*Plus et connectez-vous à la base de données en tant qu'utilisateur SYS disposant de privilèges SYSDBA.

  2. Définissez le conteneur sur la base de données pluggable :

    SQL> ALTER SESSION SET CONTAINER = pdb;

  3. Interrogez V$ENCRYPTION_WALLET comme suit : 

    SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

    Si la colonne STATUS contient la valeur OPEN_NO_MASTER_KEY, vous devez créer et activer la clé de cryptage maître.

Procédure de création et d'activation de la clé de cryptage maître dans une base de données pluggable

  1. Définissez le conteneur sur la base de données pluggable :

    SQL> ALTER SESSION SET CONTAINER = pdb;

  2. Créez et activez une clé de cryptage maître dans la base de données pluggable en exécutant la commande suivante :

    SQL> ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'tag' FORCE KEYSTORE IDENTIFIED BY keystore-password WITH BACKUP USING 'backup_identifier';

    Dans la commande précédente :

    • keystore-password est le mot de passe du fichier de clés. Par défaut, le mot de passe du fichier de clés est défini sur la valeur du mot de passe d'administration spécifié lors de la création de la base de données.
    • La clause facultative USING TAG 'tag' peut être utilisée pour associer une balise à la nouvelle clé de cryptage maître.
    • La clause WITH BACKUP et la clause facultative USING 'backup_identifier' peuvent être utilisées pour créer une sauvegarde du fichier de clés avant de créer la clé de cryptage maître.

    Reportez-vous également à ADMINISTER KEY MANAGEMENT dans la référence de langage SQL Oracle Database pour la version 19, 18 ou 12.2.

    Remarque

    Pour activer les opérations de gestion des clés lorsque le fichier de clés est en cours d'utilisation, Oracle Database 12c version 2 (et versions ultérieures) inclut l'option FORCE KEYSTORE avec la commande ADMINISTER KEY MANAGEMENT. Cette option est également disponible pour Oracle Database 12c version 1 avec le package de patches d'octobre 2017 (ou ultérieur).

    Si le package de patches d'octobre 2017 (ou ultérieur) n'est pas installé sur la base de données Oracle Database 12c version 1, vous pouvez effectuer les étapes suivantes :

    1. Fermez le fichier de clés.
    2. Ouvrez le fichier de clés basé sur un mot de passe.
    3. Créez et activez une clé de cryptage maître dans la base de données pluggable en utilisant ADMINISTER KEY MANAGEMENT sans l'option FORCE KEYSTORE.
    4. Mettez à jour le fichier de clés pour la connexion automatique en utilisant ADMINISTER KEY MANAGEMENT avec l'option CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE.

  3. Interrogez à nouveau V$ENCRYPTION_WALLET afin de vérifier que la colonne STATUS est définie sur OPEN : 

    SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

  4. Interrogez V$INSTANCE et notez la valeur présente dans la colonne HOST_NAME, qui identifie le serveur de base de données contenant les fichiers de clés récemment mis à jour : 

    SQL> SELECT host_name FROM v$instance;

  5. Copiez les fichiers de clés mis à jour sur tous les autres serveurs de base de données.

    Pour distribuer le fichier de clés mis à jour, vous devez effectuer les actions suivantes sur chaque serveur de base de données qui ne contient pas les fichiers de clés mis à jour :

    1. Connectez-vous au conteneur racine et interrogez V$ENCRYPTION_WALLET. Notez l'emplacement du fichier de clés présent dans la colonne WRL_PARAMETER : 

      SQL> SELECT wrl_parameter, status FROM v$encryption_wallet;

    2. Copiez les fichiers de clés mis à jour.

      Vous devez copier tous les fichiers de clés mis à jour à partir d'un serveur de base de données déjà mis à jour. Utilisez l'emplacement de fichier de clés observé dans la colonne WRL_PARAMETER de V$ENCRYPTION_WALLET.

    Ouvrez le fichier de clés mis à jour :
    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open FORCE KEYSTORE IDENTIFIED BY keystore-password CONTAINER=all;
    Remarque

    Pour activer les opérations de gestion des clés lorsque le fichier de clés est en cours d'utilisation, Oracle Database 12c version 2 (et versions ultérieures) inclut l'option FORCE KEYSTORE avec la commande ADMINISTER KEY MANAGEMENT. Cette option est également disponible pour Oracle Database 12c version 1 avec le package de patches d'octobre 2017 (ou ultérieur).

    Si le package de patches d'octobre 2017 (ou ultérieur) n'est pas installé sur la base de données Oracle Database 12c version 1, vous pouvez effectuer les étapes suivantes :

    1. Fermez le fichier de clés avant de copier les fichiers de clés mis à jour.
    2. Copiez les fichiers de clés mis à jour.
    3. Ouvrez le fichier de clés mis à jour en utilisant ADMINISTER KEY MANAGEMENT sans l'option FORCE KEYSTORE.

  6. Interrogez GV$ENCRYPTION_WALLET pour vérifier que la colonne STATUS est définie sur OPEN dans toutes les instances de base de données : 

    SQL> SELECT wrl_parameter, status, wallet_type FROM gv$encryption_wallet;

Procédure d'export et d'import d'une clé de cryptage maître

  1. Exportez la clé de cryptage maître.
    1. Appelez SQL*Plus et connectez-vous à la base de données pluggable.

    2. Exécutez la commande suivante :

      SQL> ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "secret" TO 'filename' IDENTIFIED BY keystore-password;
  2. Importez la clé de cryptage maître.
    1. Appelez SQL*Plus et connectez-vous à la base de données pluggable.

    2. Exécutez la commande suivante :

      SQL> ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "secret" FROM 'filename' IDENTIFIED BY keystore-password;

Gestion du cryptage de tablespace

Par défaut, tous les tablespaces que vous créez dans une base de données Exadata sont cryptés.

Toutefois, les tablespaces créés en même temps que la base de données peuvent ne pas être cryptés par défaut.

  • Pour les bases de données qui utilisent Oracle Database 12c version 2 ou ultérieure, seuls les tablespaces USERS créés en même temps que la base de données sont cryptés. Aucun autre tablespace n'est crypté, y compris les tablespaces autres que USERS dans les éléments suivants :
    • Conteneur racine (CDB$ROOT)
    • Base de données pluggable prédéfinie (PDB$SEED)
    • Première base de données pluggable, créée en même temps que la base de données
  • Pour les bases de données qui utilisent Oracle Database 12c version 1 ou Oracle Database 11g, aucun des tablespaces créés en même temps que la base de données n'est crypté.

Pour plus d'informations sur l'implémentation du cryptage de tablespace dans Exadata et sur son impact sur divers scénarios de déploiement, reportez-vous à Comportement du cryptage de tablespace Oracle Database dans Oracle Cloud.

Création de tablespaces cryptés

Les tablespaces créés par l'utilisateur sont cryptés par défaut.

Par défaut, les tablespaces créés à l'aide de la commande SQL CREATE TABLESPACE sont cryptés avec l'algorithme AES128. Vous n'avez pas besoin d'inclure la clause USING 'encrypt_algorithm' pour utiliser le cryptage par défaut.

Vous pouvez indiquer un autre algorithme pris en charge en incluant la clause USING 'encrypt_algorithm' dans la commande CREATE TABLESPACE. Les algorithmes pris en charge sont AES256, AES192, AES128 et 3DES168.

Gestion du cryptage de tablespace

Vous pouvez gérer le fichier de clés logiciel (également appelé portefeuille Oracle dans Oracle Database 11g) et la clé de cryptage maître, et déterminer si le cryptage est activé par défaut.

Gestion de la clé de cryptage maître

Le cryptage de tablespace utilise une architecture à deux niveaux reposant sur les clés pour crypter (et décrypter) les tablespaces de façon transparente. La clé de cryptage maître est stockée dans un module de sécurité externe (fichier de clés logiciel). Cette clé de cryptage maître sert à crypter la clé de cryptage de tablespace, qui sert à son tour à crypter et à décrypter les données du tablespace.

Lorsqu'une base de données est créée sur une instance Exadata Cloud Service, un fichier de clés logiciel local est créé. Le fichier de clés est local sur les noeuds de calcul et protégé par le mot de passe d'administration indiqué lors du processus de création de la base de données. Le fichier de clés logiciel pour la connexion automatique est ouvert systématiquement au démarrage de la base de données.

Vous pouvez modifier (par rotation) la clé de cryptage maître à l'aide de l'instruction ADMINISTER KEY MANAGEMENT SQL. Par exemple : 

SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY USING TAG 'tag'
IDENTIFIED BY password WITH BACKUP USING 'backup';
keystore altered.

Reportez-vous à "Gestion de la clé de cryptage maître TDE" dans le guide de sécurité avancée Oracle Database pour la version 19, 18, 12.2 ou 12.1, ou à "Définition et réinitialisation de la clé de cryptage maître" dans le guide de l'administrateur de sécurité avancée Oracle Database pour la version 11.2.

Contrôle du cryptage de tablespace par défaut

Le paramètre d'initialisation ENCRYPT_NEW_TABLESPACES contrôle le cryptage par défaut des nouveaux tablespaces. Dans les bases de données Exadata, ce paramètre est défini par défaut sur CLOUD_ONLY.

Les valeurs de ce paramètre sont les suivantes.

Valeur Description
ALWAYS Lors de leur création, les tablespaces sont cryptés de manière transparente avec l'algorithme AES128, sauf si un autre algorithme est spécifié dans la clause ENCRYPTION.
CLOUD_ONLY Les tablespaces créés dans une base de données Exadata sont cryptés de manière transparente avec l'algorithme AES128, sauf si un autre algorithme est indiqué dans la clause ENCRYPTION. Pour les bases de données non cloud, les tablespaces sont cryptés uniquement si la clause ENCRYPTION est indiquée. ENCRYPTION est la valeur par défaut.
DDL Lors de leur création, les tablespaces ne sont pas cryptés de manière transparente par défaut. Ils sont cryptés uniquement si la clause ENCRYPTION est indiquée.
Remarque

Avec Oracle Database 12c version 2 (12.2) ou ultérieure, vous ne pouvez plus créer de tablespace non crypté dans une base de données Exadata. Un message d'erreur est renvoyé si vous définissez ENCRYPT_NEW_TABLESPACES sur DDL et que vous exécutez une commande CREATE TABLESPACE sans spécifier de clause ENCRYPTION.

Gestion des pages de grande taille

Les pages de grande taille présentent des avantages considérables en matière de performances pour Oracle Database sur les systèmes pourvus de grandes quantités de mémoire. Oracle Database sur une instance Exadata Cloud Infrastructure fournit des paramètres de configuration qui utilisent par défaut les pages de grande taille. Cependant, vous pouvez effectuer des ajustements manuels afin d'optimiser la configuration des pages de grande taille.

Les pages de grande taille sont une fonctionnalité intégrée au noyau Linux 2.6. L'activation des pages de grande taille permet au système d'exploitation de prendre en charge des pages de mémoire volumineuses. L'utilisation des pages de grande taille peut améliorer les performances du système en réduisant la quantité de ressources de mémoire et d'UC système requises pour gérer les tables de pages Linux, qui stockent les correspondances entre les adresses de mémoire physique et virtuelle. Pour les bases de données Oracle, l'utilisation des pages de grande taille peut réduire considérablement le nombre d'entrées de table de pages associées à la mémoire SGA.

Sur les instances Exadata Cloud Infrastructure, une page standard est de 4 Ko, tandis qu'une page de grande taille est par défaut de 2 Mo. Par conséquent, une base de données Oracle sur un système de base de données Exadata avec une mémoire SGA de 50 Go requiert 13 107 200 pages standard pour héberger la mémoire SGA, mais seulement 25 600 pages de grande taille. Vous aboutissez ainsi à un nombre bien plus faible de tables de pages, ce qui nécessite moins de mémoire pour le stockage et moins de ressources d'UC pour l'accès et la gestion.

Réglage de la configuration des pages de grande taille

La configuration des pages de grande taille pour les bases de données Oracle est un processus en deux étapes :

  • Au niveau du système d'exploitation, la quantité globale de mémoire allouée aux pages de grande taille est contrôlée par l'entrée vm.nr_hugepages dans le fichier /etc/sysctl.conf. Ce paramètre est appliqué sur chaque noeud de calcul de l'environnement. Il est fortement recommandé de définir un paramètre cohérent entre tous les noeuds de calcul. Pour modifier l'allocation des pages de grande taille, vous pouvez exécuter la commande suivante sur chaque noeud de calcul en tant qu'utilisateur root : 

    # sysctl -w vm.nr_hugepages=value

    où value représente le nombre de pages de grande taille à allouer.

    Sur les instances Exadata Cloud Infrastructure, chaque page de grande taille est de 2 Mo par défaut. Par conséquent, pour allouer 50 Go de mémoire aux pages de grande taille, vous pouvez exécuter la commande suivante : 

    # sysctl -w vm.nr_hugepages=25600
  • Au niveau de la base de données Oracle, l'utilisation des pages de grande taille est contrôlée par la valeur du paramètre d'instance USE_LARGE_PAGES. Ce paramètre s'applique à chaque instance de base de données dans une base de données incluse dans un cluster. Oracle vous recommande vivement de définir un paramètre cohérent sur toutes les instances de base de données associées à une base de données. Les options suivantes sont disponibles :
    • TRUE : indique que l'instance de base de données peut utiliser les pages de grande taille si elles sont disponibles. Pour toutes les versions d'Oracle Database ultérieures à la version 11.2.0.3, Oracle affecte autant de mémoire SGA que possible à l'aide des pages de grande taille. Lorsque toutes les pages de grande taille ont été allouées, les pages de mémoire standard sont utilisées.
    • FALSE : indique que l'instance de base de données n'utilise pas les pages de grande taille. Ce paramètre n'est généralement pas recommandé si les pages de grande taille sont disponibles.
    • ONLY : indique que l'instance de base de données doit utiliser les pages de grande taille. Avec ce paramètre, l'instance de base de données ne parvient pas à démarrer si les pages de grande taille ne peuvent pas contenir l'intégralité de la mémoire SGA.

Si vous effectuez des ajustements au niveau du système d'exploitation ou de la base de données Oracle, assurez-vous que la configuration globale fonctionne.

Afin de consulter une présentation générale des pages de grande taille et d'obtenir plus d'informations sur leur configuration, reportez-vous à Référence de l'administrateur Oracle Database pour les systèmes d'exploitation Linux et UNIX pour la version 19, 18, 12.1 ou 11.2. Reportez-vous également à USE_LARGE_PAGES dans la référence Oracle Database pour la version 12.2, 12.1 ou 11.2.