Contrôle d'accès dans une base de données autonome avec intelligence artificielle sur une infrastructure Exadata dédiée

Contrôle de l'accès des utilisateurs Oracle Cloud

Vous pouvez contrôler l'accès des utilisateurs Oracle Cloud de votre location aux ressources en nuage qui composent votre déploiement d'une base de données d'intelligence artificielle autonome sur une infrastructure Exadata dédiée.

Vous utilisez le service Gestion des identités et des accès (IAM) pour vous assurer que les utilisateurs du nuage ont accès à la création et à l'utilisation uniquement des types appropriés de ressources de base de données autonome sur l'IA pour effectuer leurs tâches. Pour mettre en place des contrôles d'accès pour les utilisateurs Oracle Cloud, vous devez définir des politiques qui accordent à des groupes d'utilisateurs spécifiques des droits d'accès spécifiques à des types de ressource spécifiques dans des compartiments spécifiques.

Le service GIA fournit plusieurs types de composant pour vous aider à définir et à mettre en oeuvre une stratégie d'accès sécurisée pour les utilisateurs Oracle Cloud :

compartiment : collection de ressources connexes. Les compartiments sont des composants essentiels d'Oracle Cloud Infrastructure qui permettent d'organiser et d'isoler vos ressources en nuage.
Groupe : Ensemble d'utilisateurs qui ont tous besoin du même type d'accès à un jeu de ressources ou à un compartiment donné.
Groupe dynamique : Type spécial de groupe contenant les règles de correspondance que vous définissez. Ainsi, l'appartenance peut changer de manière dynamique lors de la création ou de la suppression de ressources correspondantes.
Politique : Groupe d'énoncés spécifiant qui peut accéder à quelles ressources, et comment. L'accès est accordé au niveau du groupe et du compartiment, ce qui signifie que vous écrivez un énoncé de politique qui donne à un groupe spécifique un type d'accès spécifique à un type de ressource spécifique dans un compartiment spécifique.

Énoncés de politique

L'outil principal que vous utilisez pour définir le contrôle d'accès des utilisateurs en nuage est la politique, une ressource IAM (Gestion des identités et des accès) contenant des énoncés de politique qui spécifient l'accès en termes de "Qui", "Comment", "Quel" et "Où".

Le format d'un énoncé de politique est le suivant :

Allow 
  group <group-name> 
  to <control-verb> 
  <resource-type> 
  in compartment <compartment-name>

group <group-name> spécifie "Qui" en fournissant le nom d'un groupe IAM existant, une ressource IAM à laquelle des utilisateurs en nuage individuels peuvent être affectés.
to <control-verb> indique le paramètre "comment" à l'aide de l'un des verbes de contrôle prédéfinis suivants :
- inspect : possibilité de lister les ressources du type indiqué, sans accès aux informations confidentielles ou aux métadonnées définies par l'utilisateur pouvant faire partie de cette ressource.
- read : inspect plus la possibilité d'obtenir les métadonnées spécifiées par l'utilisateur et la ressource elle-même.
- use : read plus la possibilité d'utiliser des ressources existantes, mais pas de les créer ni de les supprimer. En outre, "utiliser" implique des opérations différentes selon le type de ressource.
- manage : Toutes les autorisations pour le type de ressource, y compris la création et la suppression.
Dans le contexte de la fonction d'infrastructure dédiée, un administrateur de parc peut utiliser manage bases de données conteneur autonomes, alors qu'un administrateur de base de données peut seulement les utiliser use pour créer des bases de données intelligentes autonomes.
<resource-type> indique le paramètre "quoi" à l'aide d'un type de ressource prédéfini. Les valeurs de resource-type pour les ressources d'infrastructure dédiées sont les suivantes :
- exadata-infrastructures
- autonomous-container-databases
- autonomous-databases
- autonomous-backups
Comme les ressources d'infrastructure dédiée utilisent des ressources de réseau, certains des énoncés de politique que vous créez font référence à la valeur de resource-type virtual-network-family. De plus, vous pouvez créer des énoncés de politique qui font référence à la valeur resource-type tag-namespaces si le marquage est utilisé dans votre location.
in compartment <compartment-name> indique "Où" en fournissant le nom d'un compartiment IAM existant, une ressource IAM dans laquelle les ressources sont créées. Les compartiments sont des composants essentiels d'Oracle Cloud Infrastructure, qui organisent et isolent les ressources en nuage.

Pour les détails des politiques pour Autonomous AI Database, voir Politiques IAM pour Autonomous AI Database sur une infrastructure Exadata dédiée.

Pour plus d'informations sur le fonctionnement du service GIA et de ses composants et sur leur utilisation, voir Aperçu du service de gestion des identités et des accès pour Oracle Cloud Infrastructure. Pour obtenir des réponses rapides aux questions courantes sur GIA, voir la FAQ sur le service de gestion des identités et des accès.

Meilleures pratiques pour planifier et établir des contrôles d'accès

Lors de la planification et de la mise en place de vos contrôles d'accès pour la fonction d'infrastructure dédiée, il est conseillé d'appliquer les meilleures pratiques ci-dessous.

Créez un VCN distinct qui contient uniquement des sous-réseaux privés. Dans presque tous les cas, les bases de données autonomes d'IA créées sur une infrastructure dédiée hébergent des données sensibles qui sont normalement accessibles uniquement à partir du réseau privé de l'entreprise. Même les données partagées avec les partenaires, les fournisseurs, les consommateurs et les clients sont mises à leur disposition au moyen de canaux réglementés et sécurisés.

Par conséquent, l'accès réseau que vous fournissez à ces bases de données doit être privé. Pour ce faire, créez un VCN qui utilise des sous-réseaux privés et un RPV IPSec ou FastConnect pour la connexion au réseau privé de votre société. Pour plus d'informations sur la définition de ce type de configuration, voir Scénario B : Sous-réseaux privés avec un RPV dans la documentation sur Oracle Cloud Infrastructure.

Pour plus d'informations sur la sécurisation de la connectivité réseau à vos bases de données, voir Méthodes de sécurisation du réseau dans la documentation sur Oracle Cloud Infrastructure.
Créez au moins deux sous-réseau. Vous devez créer au moins deux sous-réseaux : un pour les ressources de grappe de machines virtuelles Exadata autonome et de base de données conteneur autonome et un pour les ressources associées aux clients et aux applications de la base de données d'intelligence artificielle autonome.
Créez au moins deux compartiments. Vous devez créer au moins deux compartiments : un pour l'infrastructure Exadata, la grappe de machines virtuelles Exadata autonome et les ressources de base de données conteneur autonome, et un pour les ressources de base de données autonome sur intelligence artificielle.
Créez au moins deux groupes. Vous devez créer au moins deux groupes : un pour les administrateurs de parc et un pour les administrateurs de base de données.

Contrôle de l'accès des clients

Le contrôle d'accès client est mis en oeuvre dans Autonomous AI Database en contrôlant le contrôle d'accès réseau et les connexions client.

Contrôle d'accès au réseau

Vous définissez le contrôle d'accès réseau aux bases de données autonomes d'IA lorsque vous configurez le déploiement dédié d'Oracle Autonomous AI Database sur une infrastructure Exadata dédiée. La façon de le faire dépend du fait que le déploiement est effectué sur Oracle Public Cloud ou Exadata Cloud@Customer :

Dans Oracle Public Cloud, vous définissez le contrôle d'accès au réseau à l'aide des composants du service de réseau. Vous créez un réseau en nuage virtuel (VCN) contenant des sous-réseaux privés dans lesquels vos bases de données autonomes d'IA sont accessibles par réseau. Vous créez également des règles de sécurité pour autoriser un type donné de trafic entrant ou sortant pour les adresses IP d'un sous-réseau.

Pour des informations détaillées sur la création de ces ressources, exécutez Laboratoire 1 : Préparer le réseau privé pour la mise en oeuvre d'OCI dans Oracle Autonomous AI Database Dedicated for Fleet Administrators.
Dans Exadata Cloud@Customer,, vous définissez des contrôles d'accès réseau en spécifiant un réseau client au sein de votre centre de données et en l'enregistrement dans une ressource de réseau en grappe de machines virtuelles au sein de la ressource d'infrastructure Exadata.

Acheminement des paquets en confiance zéro (ZPR)

S'applique à : Oracle Public Cloud seulement

Le routage ZPR (Zero Trust Packet Routing) pour Oracle Cloud Infrastructure protège les données sensibles contre les accès non autorisés au moyen de politiques de sécurité basées sur l'intention que vous écrivez pour les ressources, telles qu'une grappe de machines virtuelles Exadata autonome à laquelle vous affectez des attributs de sécurité.

Les attributs de sécurité sont des étiquettes que ZPR utilise pour identifier et organiser les ressources. ZPR applique la stratégie au niveau du réseau chaque fois que l'accès est demandé, indépendamment des modifications potentielles de l'architecture du réseau ou des erreurs de configuration. ZPR repose sur les règles de groupe de sécurité de réseau (NSG) et de liste de contrôle de sécurité (SCL) existantes. Pour qu'un paquet atteigne une cible, il doit passer toutes les règles NSG et SCL et la politique ZPR. La demande est abandonnée si une règle ou une politique NSG, SCL ou ZPR n'autorise pas le trafic.

Vous pouvez sécuriser les réseaux avec ZPR en trois étapes :

Créez des artefacts ZPR, à savoir des espaces de noms d'attribut de sécurité et des attributs de sécurité.
Écrivez des politiques ZPR pour connecter des ressources à l'aide d'attributs de sécurité. ZPR utilise un langage ZPL (ZPR Policy Language) et applique des restrictions sur l'accès aux ressources définies. En tant que client d'une base de données d'IA autonome sur une infrastructure Exadata dédiée, vous pouvez écrire des politiques basées sur ZPL dans votre location pour vous assurer que les données des méthodes AVMC ne sont accessibles que par les utilisateurs et les ressources autorisés.
Affecter des attributs de sécurité aux ressources pour activer les politiques ZPR.

Note :

Évitez d'entrer des informations confidentielles lors de l'affectation de descriptions, de marqueurs, d'attributs de sécurité ou de noms conviviaux à des ressources en nuage au moyen de la console Oracle Cloud Infrastructure, de l'API ou de l'interface de ligne de commande.

Pour plus d'informations, voir Introduction au routage de paquets sans confiance.

Vous disposez des options suivantes pour appliquer les attributs de sécurité ZPR à une grappe de machines virtuelles autonome :

Appliquez les attributs de sécurité lorsque vous provisionnez une grappe de machines virtuelles autonome. Pour plus d'informations, voir Créer une grappe de machines virtuelles Exadata autonome.
Appliquez les attributs de sécurité à une ressource AVMC existante. Pour plus d'informations, voir Configurer l'acheminement de trousse sans confiance (ZPR) pour une grappe de machines virtuelles autonome.

Vous devez au préalable définir les politiques IAM suivantes pour pouvoir ajouter des attributs de sécurité ZPR à une grappe de machines virtuelles autonome :

allow group <group_name>
to { ZPR_TAG_NAMESPACE_USE, SECURITY_ATTRIBUTE_NAMESPACE_USE }
in tenancy

allow group <group_name>
to manage autonomous-database-family
in tenancy

allow group <group_name>
to read security-attribute-namespaces
in tenancy

Listes de contrôle d'accès (ACL)

Pour plus de sécurité, vous pouvez activer des listes de contrôle d'accès dans les déploiements dédiés d'Oracle Public Cloud et d'Exadata Cloud@Customer. Une liste de contrôle d'accès fournit une protection supplémentaire à votre base de données en n'autorisant que les clients ayant des adresses IP spécifiques à s'y connecter. Vous pouvez ajouter des adresses IP individuellement ou par blocs CIDR. Les adresses IP/CIDR basées sur IPv4 et IPv6 sont prises en charge. Cela vous permet de formuler une politique de contrôle d'accès détaillé en limitant l'accès réseau de votre base de données d'IA autonome à des applications ou à des clients spécifiques.

Vous pouvez créer une liste de contrôle d'accès lors du provisionnement de la base de données ou à tout autre moment ultérieur. Par ailleurs, vous pouvez modifier une liste de contrôle d'accès à tout moment. L'activation d'une liste de contrôle d'accès avec une liste vide d'adresses IP rend la base de données inaccessible. Voir Définir la liste de contrôle d'accès pour une base de données autonome d'IA dédiée pour plus de détails.

Notez ce qui suit concernant l'utilisation d'une liste de contrôle d'accès avec Autonomous AI Database :

La console du service Base de données d'IA autonome n'est pas soumise aux règles de liste de contrôle d'accès.
Les services Oracle Application Express (APEX), RESTful, SQL Developer Web et Performance Hub ne sont pas soumis aux LCA.
Lors de la création d'une base de données d'IA autonome, si la définition d'une liste de contrôle d'accès échoue, le provisionnement de la base de données échoue également.
La mise à jour d'une LCA n'est autorisée que si la base de données est à l'état Disponible.
La restauration d'une base de données ne remplace pas les LCA existantes.
Le clonage d'une base de données, complète avec métadonnées, aura les mêmes paramètres de contrôle d'accès que la base de données source. Vous pouvez apporter des modifications si nécessaire.
La sauvegarde n'est pas soumise aux règles de liste de contrôle d'accès.
Lors de la mise à jour d'une LCA, toutes les opérations de base de données conteneur autonome sont autorisées, mais pas les opérations de base de données d'intelligence artificielle autonome.

Pare-feu d'application Web (WAF)

Pour les contrôles de réseau avancés au-delà des listes de contrôle d'accès, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée prend en charge l'utilisation du pare-feu d'application Web (WAF). Le service WAF protège les applications contre le trafic Internet malveillant ou indésirable. Le service WAF peut protéger tout point d'extrémité accessible sur Internet en appliquant systématiquement des règles aux applications d'un client. Le service WAF vous permet de créer et de gérer des règles pour les menaces Internet, notamment les attaques par script intersites (XSS), l'injection de code SQL et d'autres vulnérabilités définies par OWASP. Les règles d'accès permettent de réduire l'accès en fonction de la zone géographique ou de la signature de la demande. Voir Introduction aux politiques de pare-feu d'application Web pour savoir comment configurer le service WAF.

Contrôle des connexions de clients

Oracle Autonomous AI Database sur une infrastructure Exadata dédiée met en oeuvre le contrôle de connexion client avec l'authentification basée sur un certificat TLS 1.2 et TLS 1.3 standard pour authentifier une connexion de client. Toutefois, TLS 1.3 n'est pris en charge que sur Oracle Database 23ai ou une version ultérieure.

Par défaut, Autonomous AI Database utilise des certificats auto-signés. Toutefois, vous pouvez installer votre certificat côté serveur signé par une autorité de certification à partir de la console Oracle Cloud Infrastructure (OCI). Pour utiliser votre propre certificat, vous devez d'abord le créer à l'aide du service de certificats pour Oracle Cloud Infrastructure (OCI), comme illustré dans la rubrique Création d'un certificat. Ces certificats doivent être signés et être dans le format PEM, c'est-à-dire que leur extension de fichier ne doit être que .pem, .cer ou .crt. Pour plus de détails, consultez Gestion des certificats dans une base de données dédiée à l'IA autonome.

Contrôle de l'accès des utilisateurs de base de données

Oracle Autonomous AI Database sur une infrastructure Exadata dédiée configure les bases de données que vous créez pour utiliser la fonction de gestion des utilisateurs standard d'Oracle AI Database. Il crée un compte d'utilisateur administrateur, ADMIN, utilisé pour créer des comptes d'utilisateur supplémentaires et fournir des contrôles d'accès aux comptes.

La gestion des utilisateurs standard fournit un ensemble robuste de fonctions et de contrôles, tels que des privilèges de système et d'objet, des rôles, des profils d'utilisateur et des politiques de mot de passe, qui permettent de définir et de mettre en oeuvre une stratégie d'accès sécurisée pour les utilisateurs de base de données. Voir Créer et gérer des utilisateurs de base de données pour des instructions détaillées.

Pour des informations de base sur la gestion des utilisateurs standard, voir Comptes d'utilisateur dans Concepts relatifs à Oracle AI Database. Pour des informations et des conseils détaillés, voir Managing Security for Oracle Database Users in Oracle Database 19c Security Guide ou Oracle Database 26ai Security Guide.

Si votre stratégie d'accès utilisateur à la base de données exige plus de contrôles que ceux fournis par la gestion standard des utilisateurs, vous pouvez configurer vos bases de données autonomes d'IA pour utiliser l'un des outils suivants afin de répondre à des exigences plus rigoureuses.

Outil	Description
Database Vault	Oracle Database Vault est préconfiguré et prêt à l'emploi dans les bases de données autonomes sur l'IA. Vous pouvez utiliser ses contrôles de sécurité performants pour limiter l'accès aux données applicatives à des utilisateurs de base de données privilégiés, ce qui réduit les risques de menaces internes et externes et permet de respecter les exigences de conformité communes. Pour plus de détails, consultez la section Protection des données dans Fonctions de sécurité de la base de données autonome sur l'IA.
Service de gestion des identités et des accès pour Oracle Cloud Infrastructure (GIA)	Vous pouvez configurer Autonomous AI Database pour utiliser l'authentification et l'autorisation du service de gestion des identités et des accès (IAM) pour Oracle Cloud Infrastructure afin de permettre aux utilisateurs IAM d'accéder à une base de données autonome d'IA avec des données d'identification IAM. Reportez-vous à la section Utiliser l'authentification du service de gestion des identités et des accès (IAM) avec la base de données autonome d'IA pour utiliser cette option avec votre base de données.
Jetons d'accès Azure OAuth2	Vous pouvez gérer de manière centralisée les utilisateurs d'Oracle Autonomous AI Database sur une infrastructure Exadata dédiée dans un service Microsoft Azure Active Directory (Azure AD) à l'aide de jetons d'accès Azure `oAuth2`. Ce type d'intégration permet à l'utilisateur Azure AD d'accéder à une instance Oracle Autonomous AI Database sur une infrastructure Exadata dédiée. Les utilisateurs et les applications Azure AD peuvent se connecter avec les données d'authentification unique Azure AD pour obtenir un jeton d'accès `OAuth2` Azure AD à envoyer à la base de données. Pour plus d'informations sur l'intégration de Microsoft Azure Active Directory à vos bases de données, voir Authentifier et autoriser les utilisateurs Microsoft Azure Active Directory pour Autonomous AI Database.
Microsoft Active Directory (CMU-AD)	Si vous utilisez Microsoft Active Directory en tant que référentiel d'utilisateurs, vous pouvez configurer vos bases de données autonomes d'IA pour authentifier et autoriser les utilisateurs de Microsoft Active Directory. Cette intégration peut vous permettre de consolider votre référentiel d'utilisateurs tout en mettant en œuvre une stratégie d'accès rigoureuse aux utilisateurs de base de données, que vous utilisiez la gestion standard des utilisateurs, Database Vault, Real Application Security ou Virtual Private Database. Pour plus d'informations sur l'intégration de Microsoft Active Directory à vos bases de données, voir Microsoft Active Directory avec Base de données autonome d'IA.
Kerberos	Kerberos est un système d'authentification de tierce partie approuvé qui repose sur des clés secrètes partagées. Il suppose que la tierce partie est sécurisée et offre des fonctionnalités d'authentification unique, un stockage centralisé des mots de passe, une authentification par lien de base de données et une sécurité améliorée du PC. Pour ce faire, il utilise un serveur d'authentification Kerberos. La prise en charge de Kerberos dans Autonomous AI Database offre les avantages de l'authentification unique et de l'authentification centralisée des utilisateurs Oracle. Pour plus d'informations, voir Authentifier les utilisateurs d'Autonomous AI Database avec Kerberos.
Kerberos avec CMU-AD	L'authentification Kerberos peut être configurée en plus de CMU-AD pour fournir l'authentification CMU-AD Kerberos aux utilisateurs de Microsoft Active Directory. Pour fournir une authentification CMU-AD Kerberos aux utilisateurs de Microsoft Active Directory, vous pouvez activer l'authentification Kerberos au-dessus de CMU-AD en réglant `type` à `CMU` tout en activant l'authentification externe, comme illustré dans l'exemple décrit sous Activer l'authentification Kerberos sur Autonomous AI Database.
Real Application Security et base de données virtuelle privée	Oracle Real Application Security (RAS) fournit un modèle déclaratif permettant d'appliquer des politiques de sécurité qui englobent non seulement les objets d'affaires protégés, mais également les principaux (utilisateurs et rôles) autorisés à exploiter ces objets. RAS est plus sécurisé, évolutif et rentable que son prédécesseur, Oracle Virtual Private Database. Avec Oracle RAS, les utilisateurs d'une application sont authentifiés au niveau de celle-ci et dans la base de données. Quel que soit le chemin d'accès aux données, les politiques de sécurité des données sont appliquées dans le noyau de la base de données en fonction de la session native de l'utilisateur final dans la base de données. Les privilèges affectés à l'utilisateur contrôlent les types d'opération (sélection, insertion, mise à jour et suppression) pouvant être appliqués aux rangées et aux colonnes des objets de base de données. Pour plus d'informations sur Oracle RAS, voir Présentation d'Oracle Database Real Application Security dans le Oracle Database 19c Real Application Security Administrator's and Developer's Guide ou le Oracle Database 26ai Real Application Security Administrator's and Developer's Guide. Oracle Autonomous AI Database sur une infrastructure Exadata dédiée prend également en charge Oracle Virtual Private Database (VPD), prédécesseur du service Oracle RAS. Si vous connaissez et utilisez déjà Oracle VPD, vous pouvez le configurer et l'utiliser avec vos bases de données autonomes d'IA. Pour plus d'informations sur les bases de données virtuelles privées, voir Utilisation du service Oracle Virtual Private Database pour contrôler l'accès aux données dans le Guide sur la sécurité d'Oracle Database 19c ou le Guide sur la sécurité d'Oracle Database 26ai.

Gestion des accès avec privilèges (PAM)

La sécurité d'Oracle concernant l'accès des utilisateurs et la gestion des privilèges dans l'ensemble de ses produits et services est documentée dans Oracle Access Control.

Autonomous AI Database sur une infrastructure Exadata dédiée est conçue pour isoler et protéger les services à la clientèle et les données de base de données contre les accès non autorisés. La base de données autonome sur l'IA sépare les fonctions entre le client et Oracle. Le client contrôle l'accès aux schémas de base de données. Oracle contrôle l'accès à l'infrastructure et aux composants logiciels gérés par Oracle.

Autonomous AI Database sur une infrastructure Exadata dédiée est conçue pour sécuriser les données en vue d'une utilisation autorisée par le client et pour protéger les données contre un accès non autorisé, ce qui inclut la prévention de l'accès aux données du client par les membres du personnel d'Oracle Cloud Ops. Les mesures de sécurité conçues pour protéger contre l'accès non autorisé à l'infrastructure Exadata, aux machines virtuelles autonomes et aux données de base de données Oracle comprennent les éléments suivants :

Les données Oracle Database sont protégées par des clés TDE d'Oracle.
Le client contrôle l'accès aux clés de chiffrement TDE et peut choisir de stocker ces clés dans un système externe de gestion des clés Oracle Key Vault.
Oracle Database Vault est préconfiguré pour empêcher les utilisateurs privilégiés d'accéder aux données des clients dans les bases de données autonomes sur l'IA.
Les clients peuvent choisir d'approuver l'accès des opérateurs au moyen de l'inscription au service de contrôle de l'accès des opérateurs.
Tous les accès des opérateurs sont basés sur l'authentification multifacteur matérielle de niveau 3 FIPS 140-2, mise en oeuvre avec un matériel YubiKey mis en oeuvre avec des appareils approuvés par Oracle.
Toutes les actions d'opérateur sont enregistrées au niveau de la commande et peuvent être envoyées au service de journalisation OCI ou à un client SIEM en temps quasi réel.
Le contrôle d'accès aux opérations d'Oracle garantit que les comptes d'utilisateur utilisés par le personnel d'exploitation et de soutien d'Oracle Cloud pour surveiller et analyser la performance ne peuvent pas accéder aux données des bases de données autonomes d'IA. Le personnel d'exploitation et de soutien d'Oracle Cloud n'a pas accès aux données de vos bases de données autonomes d'IA. Lorsque vous créez une base de données conteneur autonome, le service Base de données d'IA autonome sur une infrastructure Exadata dédiée permet et configure la fonction de contrôle des opérations d'Oracle Database Vault pour empêcher les utilisateurs communs d'accéder aux données des bases de données d'IA autonomes créées dans la base de données conteneur.
Vous pouvez confirmer que Operations Control est actif en entrant cet énoncé SQL dans une base de données d'IA autonome :
```
SELECT * FROM DBA_DV_STATUS;
```
Le statut APPLICATION CONTROL indique que le contrôle des opérations est actif.

Note :
Le contrôle des opérations était auparavant appelé contrôle d'application.

Le module d'authentification enfichable est également mis en oeuvre avec Database Vault pour la protection des données, comme décrit dans Fonctions de sécurité d'Autonomous AI Database.