Contrôle de l'accès dans le service de base de données autonome 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'Autonomous Database sur une infrastructure Exadata dédiée.

Vous utilisez le service Gestion des identités et des accès (IAM) pour vous assurer que vos utilisateurs du nuage ont accès à la création et à l'utilisation des types appropriés de ressources Autonomous Database 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 gérer (manage) des 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 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 plus de détails sur la politique pour Autonomous Database, voir Politiques IAM pour Autonomous 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 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éseaux. Vous devez créer au moins deux sous-réseaux : un pour les ressources de grappe de machines virtuelles Exadata et de base de données conteneur autonome et un pour les ressources associées aux clients et aux applications de base de données autonome.
Créez au moins deux compartiments. Vous devez créer au moins deux compartiments : un pour les ressources d'infrastructure Exadata, de grappe de machines virtuelles Exadata autonome et de base de données conteneur autonome et un pour les ressources de base de données autonome.
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 Database en contrôlant le contrôle d'accès au réseau et les connexions de 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 lorsque vous configurez le déploiement dédié d'Oracle Autonomous Database. Pour ce faire, vous devez savoir si 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 sont accessibles par le 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 le Laboratoire 1 : Préparer un réseau privé pour la mise en oeuvre d'OCI dans Oracle Autonomous Database dédié aux administrateurs de parc.
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é.
Écrire des politiques ZPR pour connecter des ressources à l'aide d'attributs de sécurité. ZPR utilise un langage ZPR Policy Language (ZPL) et applique des restrictions sur l'accès aux ressources définies. En tant que client d'infrastructure Autonomous Database 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 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 Autonomous Database à 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édiée pour plus de détails.

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

La console du service de base de données 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 Autonomous Database, 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 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 d'Autonomous Database ne sont pas autorisées.

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 Database 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 uniformément 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 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 Database met en oeuvre le contrôle de connexion client avec l'authentification standard basée sur des certificats TLS 1.2 et TLS 1.3 pour authentifier une connexion client. Toutefois, TLS 1.3 n'est pris en charge que sur Oracle Database 23ai ou une version ultérieure.

Par défaut, les bases de données autonomes utilisent 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 créer le certificat à l'aide du service de certificats pour Oracle Cloud Infrastructure (OCI), comme indiqué dans 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 doit être .pem, .cer ou .crt uniquement. Pour plus de détails, consultez Gestion des certificats dans Autonomous Database dédié.

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

Oracle Autonomous Database configure les bases de données que vous créez pour l'utilisation de la fonction de gestion des utilisateurs standard d'Oracle 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 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 23ai Security Guide.

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

Outil	Description
Database Vault	Oracle Database Vault est préconfigurée et prête à l'utilisation dans Autonomous Database. 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 d'informations, voir Protection des données dans Caractéristiques de sécurité d'Autonomous Database.
Service de gestion des identités et des accès pour Oracle Cloud Infrastructure (GIA)	Vous pouvez configurer Autonomous 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 Autonomous Database avec des données d'identification IAM. Reportez-vous à la section Utiliser l'authentification avec le service de gestion des identités et des accès (IAM) avec Autonomous Database 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 Database 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 Database. 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 Database.
Microsoft Active Directory (CMU-AD)	Si vous utilisez Microsoft Active Directory en tant que référentiel d'utilisateurs, vous pouvez configurer vos Autonomous Database 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 rigoureuse d'accès des 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 avec vos bases de données, voir Utiliser Microsoft Active Directory avec une base de données autonome.
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 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 Autonomous 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 l'authentification CMU-AD Kerberos aux utilisateurs de Microsoft Active Directory, vous pouvez activer l'authentification Kerberos en plus de CMU-AD en réglant `type` à `CMU` tout en activant l'authentification externe, comme illustré dans l'exemple présenté sous Activer l'authentification Kerberos sur Autonomous 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 Oracle Database 23ai Real Application Security Administrator's and Developer's Guide. Oracle Autonomous Database 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. 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 23ai.

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 Database sur une infrastructure Exadata dédiée est conçu pour isoler et protéger les services clients et les données de base de données contre les accès non autorisés. Autonomous Database 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 Database sur une infrastructure Exadata dédiée est conçu pour protéger les données pour une utilisation autorisée par le client et pour aider à protéger les données contre les accès non autorisés, ce qui inclut la prévention de l'accès aux données de client par les membres du personnel des opérations Oracle Cloud. Les mesures de sécurité conçues pour protéger contre l'accès non autorisé aux données de l'infrastructure Exadata, des machines virtuelles autonomes et de la base de données Oracle sont les suivantes :

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 Autonomous Database.
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 des opérations 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 Autonomous Database. Le personnel d'exploitation et de soutien d'Oracle Cloud n'a pas accès aux données de vos Autonomous Database. Lorsque vous créez une base de données conteneur autonome, Autonomous Database 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 Autonomous Database créées dans la base de données conteneur.
Vous pouvez confirmer que le contrôle des opérations est actif en entrant cet énoncé SQL dans une base de données Autonomous 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 auparavant appelé contrôle d'application.

PAM est également mis en oeuvre avec Database Vault pour la protection des données, comme indiqué dans Fonctions de sécurité d'Autonomous Database.