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

Lors de la configuration d'une base de données autonome avec intelligence artificielle sur une infrastructure Exadata dédiée, vous devez vous assurer que les utilisateurs du nuage ont accès à des types appropriés de ressources en nuage pour l'exécution de leurs tâches. En outre, vous devez vous assurer que seuls le personnel et les applications autorisés ont accès aux bases de données d'IA autonomes créées sur une infrastructure dédiée. Sinon, vous courez le risque d'une consommation " fugitive " de vos ressources d'infrastructure dédiées ou d'un accès inapproprié aux données critiques.

Avant de commencer à créer et à utiliser les ressources en nuage qui fournissent la fonction d'infrastructure dédiée, vous devez formuler un plan de contrôle d'accès, puis instituer en créant les ressources IAM (Identity and Access Management) et de réseau appropriées. Par conséquent, le contrôle d'accès au sein d'une base de données IA autonome est mis en œuvre à différents niveaux :

• Contrôle d'accès des utilisateurs du nuage Oracle
• Contrôle d'accès client
• Contrôle d'accès d'utilisateur de base de données

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

Vous contrôlez 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 des types appropriés de ressource de base de données d'intelligence artificielle autonome 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 particulier.

• Groupe dynamique : Type spécial de groupe qui contient des ressources correspondant aux règles 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 qui spécifient 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 pour les 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", "Quoi" 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> indique le "Who" en indiquant le nom d'un groupe IAM existant, une ressource IAM à laquelle des utilisateurs individuels du nuage peuvent être affectés.

• à <control-verb> indique le "comment" à l'aide de l'un des verbes de contrôle prédéfinis suivants :

  • inspecter : permet de lister les ressources du type indiqué, sans accéder à des informations confidentielles ou aux métadonnées spécifiées par l'utilisateur qui peuvent faire partie de cette ressource.

  • Lire : inspect plus la possibilité d'obtenir les métadonnées spécifiées par l'utilisateur et la ressource réelle elle-même.

  • utiliser : read plus la possibilité d'utiliser des ressources existantes, mais pas de les créer ou de les supprimer. En outre, "travailler avec" signifie différentes opérations pour différents types de ressource.

  • gérer : Toutes les autorisations pour le type de ressource, notamment la création et la suppression.

  Dans le contexte de la fonction d'infrastructure dédiée, un administrateur de parc peut manage bases de données conteneur autonomes, alors qu'un administrateur de base de données ne peut les use que pour créer des bases de données autonomes basées sur l'IA.

• <resource-type> indique l'élément "What" à 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
  • Bases de données conteneur autonomes
  • autonomous-databases
  • sauvegardes de bases de données autonomes

  Comme les ressources d'infrastructure dédiées utilisent des ressources de réseau, certains des énoncés de politique que vous créez référenceront la valeur de type de ressource virtual-network-family. De plus, vous pouvez créer des énoncés de politique qui font référence à la valeur de type de ressource tag-namespaces si le marquage est utilisé dans votre location.

• dans le compartiment <compartment-name> spécifie "Where" en indiquant 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 isoler les ressources en nuage.

Pour les détails des politiques pour Autonomous AI Database, consultez 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 ne contient que des sous-réseaux privés. Dans presque tous les cas, les bases de données d'IA autonomes créées sur une infrastructure dédiée hébergent des données sensibles à l'entreprise et 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 de votre réseau dans la documentation sur Oracle Cloud Infrastructure.

• Créez au moins deux sous-réseaux. 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 avec 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 et configurez le déploiement dédié d'Oracle Autonomous AI Database sur une infrastructure Exadata dédiée. La façon de procéder dépend du fait que votre déploiement dédié se trouve 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 d'IA autonomes 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 les contrôles d'accès au réseau en spécifiant un réseau client dans votre centre de données et en l'enregistrant dans une ressource de réseau en grappe de machines virtuelles dans la ressource d'infrastructure Exadata.

ZPR (Zero Trust Packet Routing)

S'APPLIQUE À : Oracle Public Cloud seulement

Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) protège les données sensibles contre les accès non autorisés au moyen de politiques de sécurité basées sur les intentions que vous écrivez pour les ressources, telles qu'une grappe de machines virtuelles Exadata autonome (AVMC) à 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 politique 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 existantes de groupe de sécurité de réseau et de liste de contrôle de sécurité. Pour qu'un paquet atteigne une cible, il doit transmettre 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 :

1. Créez des artefacts ZPR, notamment des espaces de noms d'attribut de sécurité et des attributs de sécurité.

2. É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 autonome sur une infrastructure Exadata dédiée, vous pouvez écrire des politiques basées sur un fichier 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.

3. Affectez 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, de l'API ou de l'interface de ligne de commande d'Oracle Cloud Infrastructure.

Pour plus d'informations, voir Démarrage avec le routage de paquets sans confiance.

Vous disposez des options suivantes pour appliquer les attributs de sécurité ZPR à une machine virtuelle autonome :

• Appliquez les attributs de sécurité lorsque vous provisionnez une machine virtuelle autonome. Pour plus d'informations, voir Créer une grappe de machines virtuelles Exadata autonome.

• Appliquez des attributs de sécurité à une ressource AVMC existante. Pour plus d'informations, voir Configurer le routage ZPR (Zero Trust Packet Routing).

Comme préalable, les politiques IAM suivantes doivent être définies pour que l'ajout d'attributs de sécurité ZPR à une machine virtuelle autonome réussisse :

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

Pour plus de sécurité, vous pouvez activer les 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 autorisant uniquement le client ayant des adresses IP spécifiques à se connecter à la base de données. 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. Pour plus de détails, voir Définir la liste de contrôle d'accès pour une base de données dédiée à l'IA autonome.

Notez ce qui suit concernant l'utilisation d'une liste de contrôle d'accès avec une base de données d'intelligence artificielle autonome :

• La console du service Autonomous AI Database n'est pas soumise aux règles de liste de contrôle d'accès.
• Oracle Application Express (APEX), les services RESTful, SQL Developer Web et Performance Hub ne sont pas soumis aux listes de contrôle d'accès.
• 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 liste de contrôle d'accès 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 d'une mise à jour de liste de contrôle d'accès, toutes les opérations de base de données conteneur autonome sont autorisées, mais les opérations de base de données d'intelligence artificielle autonome ne le sont pas.

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 assurant une application des règles uniforme sur les 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 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 de 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 d'accès de l'utilisateur 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 standard des utilisateurs, voir Comptes d'utilisateurs dans Concepts relatifs à Oracle AI Database. Pour des informations et des conseils détaillés, voir Gestion de la sécurité pour les utilisateurs d'Oracle Database dans le guide de sécurité d'Oracle Database 19c ou le guide de sécurité d'Oracle Database 26ai.

Si votre stratégie d'accès d'utilisateur de 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 d'IA autonomes pour qu'elles utilisent 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 avec intelligence artificielle. 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, reportez-vous à la section Protection des données dans Fonctions de sécurité de la base de données d'IA autonome.
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 Oracle Cloud Infrastructure Identity and Access Management (IAM) afin de permettre aux utilisateurs IAM d'accéder à une base de données Autonomous AI Database avec des données d'identification IAM. Reportez-vous à 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 d'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'identification d'authentification unique (SSO) 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 d'IA autonomes pour authentifier et autoriser les utilisateurs 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 Autonomous AI Database.
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 la base de données d'IA autonome offre les avantages de l'authentification unique et de l'authentification centralisée des utilisateurs Oracle. Pour plus d'informations, voir Authentifier les utilisateurs de base de données d'IA autonome avec Kerberos.
Kerberos avec CMU-AD	L'authentification Kerberos peut être configurée au-dessus 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 une base de données IA autonome.
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 Oracle Database 19c Real Application Security Administrator's and Developer's Guide ou 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 d'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 la base de données privée virtuelle, voir Utilisation d'Oracle Virtual Private Database pour contrôler l'accès aux données dans le guide de sécurité d'Oracle Database 19c ou le guide de sécurité d'Oracle Database 26ai.

Gestion des accès privilégiés (PAM)

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

La base de données autonome 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. Une base de données autonome d'IA sépare les tâches 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.

La base de données autonome sur une infrastructure Exadata dédiée est conçue pour aider à sécuriser les données pour une utilisation autorisée par le client et pour aider à 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 (Transparent Data Encryption) 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 des utilisateurs privilégiés d'accéder aux données des clients dans des bases de données autonomes basées 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 FIPS 140-2 de niveau 3, mise en œuvre avec une YubiKey matérielle mise en œuvre 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 système SIEM de client 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 les opérations et le personnel 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. Les opérations et le personnel de soutien d'Oracle Cloud n'ont pas accès aux données de vos bases de données d'IA autonomes. Lorsque vous créez une base de données conteneur autonome, une base de données autonome basée sur une infrastructure Exadata dédiée active 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 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 Autonomous AI Database :

  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 plus tôt 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é de la base de données autonome avec intelligence artificielle.

Contenu connexe

Principales fonctions de sécurité