Contrôle d'accès dans Autonomous Database on Dedicated Exadata Infrastructure

Contrôle d'accès d'utilisateur Oracle Cloud

Vous contrôlez l'accès dont disposent les utilisateurs Oracle Cloud de votre location aux ressources cloud qui constituent votre déploiement d'Autonomous Database on Dedicated Exadata Infrastructure.

Utilisez le service Identity and Access Management (IAM) pour vous assurer que les utilisateurs cloud disposent d'un accès permettant de créer et d'utiliser uniquement les types appropriés de ressource Autonomous Database pour effectuer leur travail. Afin d'instituer des contrôles d'accès pour les utilisateurs cloud, définissez des stratégies qui accordent à des groupes spécifiques d'utilisateurs des droits d'accès spécifiques sur des types de ressource spécifiques dans des compartiments spécifiques.

Le service IAM fournit plusieurs types de composant pour vous aider à définir et à implémenter une stratégie d'accès utilisateur cloud sécurisé :

Compartiment : ensemble de ressources associées. Les compartiments représentent un composant fondamental d'Oracle Cloud Infrastructure pour l'organisation et l'isolement des ressources cloud.
Groupe : ensemble d'utilisateurs qui ont tous besoin du même type d'accès à un ensemble de ressources ou à un compartiment spécifique.
Groupe dynamique : type spécial de groupe contenant les ressources qui correspondent aux règles que vous définissez. Par conséquent, l'appartenance peut changer de façon dynamique à mesure que des ressources correspondantes sont créées ou supprimées.
Stratégie : groupe d'instructions qui indiquent 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 une instruction de stratégie qui accorde à un groupe donné un type d'accès donné à un type de ressource donné dans un compartiment donné.

Instructions de stratégie et de stratégie

L'outil principal utilisé pour définir le contrôle d'accès des utilisateurs cloud est la stratégie. Il s'agit d'une ressource IAM (Identity and Access Management) contenant des instructions de stratégie qui spécifient l'accès en termes de personnes, de procédures, de quoi et d'endroit.

Le format d'une instruction de stratégie est le suivant :

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

group <group-name> indique "qui" en fournissant le nom d'un groupe IAM existant, ressource IAM à laquelle des utilisateurs cloud individuels peuvent être affectés.
to <control-verb> indique "comment" utiliser l'un des verbes de contrôle prédéfinis suivants :
- inspect : possibilité de répertorier les ressources d'un type donné, sans accéder aux informations confidentielles ou aux métadonnées spécifiées par l'utilisateur pouvant figurer dans ces ressources.
- read : accès inspect plus possibilité d'obtenir les métadonnées spécifiées par l'utilisateur et la ressource elle-même.
- use : accès read plus capacité à utiliser des ressources existantes, mais pas à les créer ni à les supprimer. Ici, "utiliser" implique différentes opérations pour différents types de ressource.
- manage : tous les droits d'accès au type de ressource, création et suppression comprises.
Dans le cadre de la fonctionnalité d'infrastructure dédiée, un administrateur de parc peut gérer (manage) des bases de données Conteneur Autonomous, tandis qu'un administrateur de base de données peut uniquement les utiliser (use) pour créer des bases de données autonomes.
<resource-type> indique "quoi" à l'aide d'un type de ressource prédéfini. Les valeurs de type des ressources d'infrastructure dédiée sont les suivantes :
- exadata-infrastructures
- autonomous-container-databases
- autonomous-databases
- autonomous-backups
Etant donné que les ressources d'infrastructure dédiée utilisent des ressources de réseau, certaines instructions de stratégie que vous créez font référence à la valeur de type de ressource virtual-network-family. Vous pouvez également créer des instructions de stratégie qui font référence à la valeur de type de ressource tag-namespaces si le balisage 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 constituent un composant fondamental d'Oracle Cloud Infrastructure pour l'organisation et l'isolement des ressources cloud.

Afin d'obtenir les détails de stratégie pour Autonomous Database, reportez-vous à Stratégies IAM pour Autonomous Database on Dedicated Exadata Infrastructure.

Pour plus d'informations sur le fonctionnement du service IAM et de ses composants, ainsi que sur leur utilisation, reportez-vous à Présentation d'Oracle Cloud Infrastructure Identity and Access Management. Pour obtenir des réponses rapides aux questions courantes sur IAM, reportez-vous à la FAQ Identity and Access Management.

Meilleures pratiques pour la planification et la mise en place de contrôles d'accès

Lorsque vous planifiez et mettez en place les contrôles d'accès pour la fonctionnalité d'infrastructure dédiée, vous devez tenir compte des meilleures pratiques suivantes.

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 pour l'entreprise et 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 via des 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 limité à votre société. A cette fin, vous pouvez créer un réseau cloud virtuel qui utilise des sous-réseaux privés, et un VPN IPSec ou FastConnect pour la connexion au réseau privé de l'entreprise. Pour plus d'informations sur l'établissement d'une telle configuration, reportez-vous à Scénario B : sous-réseaux privés avec un VPN dans la documentation Oracle Cloud Infrastructure.

Pour plus d'informations sur la sécurisation de la connectivité réseau à vos bases de données, reportez-vous à Moyens de sécuriser le réseau dans la documentation Oracle Cloud Infrastructure.
Création d'au moins deux sous-nets Vous devez créer au moins deux sous-réseaux : un pour les ressources de cluster de machines virtuelles Exadata Autonomous et de base de données Conteneur Autonomous, et un pour les ressources associées aux clients et aux applications d'Autonomous Database.
Créez au moins deux compartiments. Vous devez créer au moins deux compartiments : un pour les ressources d'infrastructure Exadata, de cluster de machines virtuelles Exadata Autonomous et de base de données Conteneur Autonomous, et un pour les ressources Autonomous Database.
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 d'accès client

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

Contrôle d'accès réseau

Vous définissez le contrôle d'accès réseau aux bases de données autonomes lorsque vous configurez votre déploiement dédié d'Oracle Autonomous Database. La façon dont vous procédez dépend de l'emplacement du déploiement dédié, entre Oracle Public Cloud et Exadata Cloud@Customer :

Sur Oracle Public Cloud, vous définissez le contrôle d'accès réseau à l'aide des composants du service Networking. Vous créez un réseau cloud virtuel (VCN) contenant des sous-réseaux privés dans lesquels vos bases de données autonomes sont accessibles par le réseau. De plus, créez des règles de sécurité pour autoriser un type particulier de trafic vers ou depuis les adresses IP d'un sous-réseau.

Pour obtenir des informations détaillées sur la création de ces ressources, suivez l'atelier pratique sur la préparation des réseaux privés pour l'implémentation d'OCI dans Oracle Autonomous Database Dedicated pour les administrateurs de parc.
Sur Exadata Cloud@Customer, définissez les contrôles d'accès réseau en indiquant un réseau client dans votre centre de données et en l'enregistrant dans une ressource de réseau de cluster de machines virtuelles au sein de la ressource d'infrastructure Exadata.

Zero Trust Packet Routing (ZPR)

S'APPLIQUE À : Oracle Public Cloud uniquement

Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) protège les données sensibles contre tout accès non autorisé via des stratégies de sécurité basées sur les intentions que vous écrivez pour les ressources, telles qu'un cluster de machines virtuelles Exadata Autonomous auquel vous affectez des attributs de sécurité.

Les attributs de sécurité sont des libellés que ZPR utilise pour identifier et organiser les ressources. ZPR applique la stratégie au niveau du réseau à chaque demande d'accès, quelles que soient les modifications ou les erreurs de configuration potentielles de l'architecture réseau. ZPR est basé sur les règles de groupe de sécurité réseau et de liste de contrôle de sécurité existantes. Pour qu'un paquet atteigne une cible, il doit passer toutes les règles NSG et SCL et la stratégie ZPR. La demande est supprimée si une règle ou stratégie 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é.
Ecrivez des stratégies ZPR pour connecter des ressources à l'aide d'attributs de sécurité. ZPR utilise un langage de stratégie ZPR (ZPL) et applique des restrictions sur l'accès aux ressources définies. En tant que client Autonomous Database on Dedicated Exadata Infrastructure, vous pouvez écrire des stratégies basées sur le ZPL dans votre location pour vous assurer que les données des AVMC sont accessibles uniquement par les utilisateurs et les ressources autorisés.
Affectez des attributs de sécurité aux ressources pour activer les stratégies ZPR.

Remarques :

Evitez de saisir des informations confidentielles lorsque vous affectez des descriptions, des balises, des attributs de sécurité ou des noms conviviaux aux ressources cloud via la console Oracle Cloud Infrastructure, l'API ou l'interface de ligne de commande.

Pour plus d'informations, reportez-vous à la section Getting Started with Zero Trust Packet Routing.

Vous disposez des options suivantes pour appliquer les attributs de sécurité ZPR à un composant AVMC :

Appliquez les attributs de sécurité lorsque vous provisionnez un composant AVMC. Pour plus d'informations, reportez-vous à Création d'un cluster de machines virtuelles Exadata Autonomous.
Appliquer les attributs de sécurité à une ressource AVMC existante. Pour plus d'informations, reportez-vous à la section Configure Zero Trust Packet Routing (ZPR) for an AVMC.

Vous devez au préalable définir les stratégies IAM suivantes pour ajouter les attributs de sécurité ZPR à une instance AVMC :

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

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

Pour renforcer la sécurité, vous pouvez activer les listes de contrôle d'accès dans les déploiements dédiés Oracle Public Cloud et 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 possédant des adresses IP spécifiques à se connecter à la base de données. Vous pouvez ajouter des adresses IP individuellement ou dans des blocs CIDR. Les adresses IP/CIDR basés sur IPv4 et IPv6 sont pris en charge. Vous pouvez ainsi formuler une stratégie de contrôle d'accès détaillée en limitant l'accès réseau de votre instance Autonomous Database à des applications ou 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 à n'importe quel moment par la suite. Vous pouvez également modifier une liste de contrôle d'accès à tout moment. L'activation d'une liste de contrôle d'accès sans adresses IP rend la base de données inaccessible. Pour plus d'informations, reportez-vous à Définition d'une liste de contrôle d'accès pour une base de données autonome dédiée.

Lorsque vous utilisez une liste de contrôle d'accès avec Autonomous Database, tenez compte des points suivants :

La console du service Autonomous 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 le hub de performances ne sont pas soumis aux listes de contrôle d'accès.
Lors de la création d'une instance 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 liste de contrôle d'accès est autorisée uniquement si la base de données présente l'état Disponible.
La restauration d'une base de données n'écrase pas les listes de contrôle d'accès existantes.
Une base de données clonée (clonage complet et de métadonnées) a les mêmes paramètres de contrôle d'accès que la base de données source. Vous pouvez y 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 d'ACL, toutes les opérations de base de données Conteneur Autonomous sont autorisées, mais les opérations Autonomous Database ne sont pas autorisées.

Web Application Firewall (WAF)

Pour les contrôles réseau avancés au-delà des listes de contrôle d'accès, Oracle Autonomous Database prend en charge l'utilisation de Web Application Firewall (WAF). WAF protège les applications du trafic Internet malveillant et indésirable. WAF peut protéger toutes les adresses Internet, en assurant l'exécution cohérente des règles sur les différentes applications d'un client. WAF vous permet de créer et de gérer des règles relatives aux menaces Internet, y compris la génération de scripts inter site (XSS), l'injection SQL et d'autres vulnérabilités définies par OWASP. Les règles d'accès peuvent imposer des limites en fonction de la zone géographique ou de la signature de la demande. Pour connaître les étapes de configuration de WAF, reportez-vous à Introduction aux stratégies Web Application Firewall.

Contrôle de connexion client

Oracle Autonomous Database implémente 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 client. Cependant, TLS 1.3 n'est pris en charge que sur Oracle Database 23ai ou version ultérieure.

Par défaut, Autonomous Database utilise des certificats auto-signés. Toutefois, vous pouvez installer le 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 certificat Oracle Cloud Infrastructure (OCI), comme indiqué dans Création d'un certificat. Ces certificats doivent être signés et au format PEM, c'est-à-dire que leur extension de fichier doit être .pem, .cer ou .crt uniquement. Pour plus de détails, reportez-vous à Gestion des certificats dans Dedicated Autonomous Database.

Contrôle d'accès d'utilisateur de base de données

Oracle Autonomous Database configure les bases de données que vous créez pour l'utilisation de la fonctionnalité de gestion standard des utilisateurs d'Oracle Database. Il crée le compte administrateur ADMIN qui permet de créer des comptes utilisateur supplémentaires et d'établir des contrôles d'accès pour les comptes.

La gestion standard des utilisateurs fournit un ensemble robuste de fonctionnalités et de contrôles, tels que les privilèges système et d'objet, les rôles, les profils utilisateur et les stratégies de mot de passe, permettant de définir et d'implémenter une stratégie d'accès utilisateur de base de données sécurisé dans la plupart des cas. Pour obtenir des instructions détaillées, reportez-vous à Création et gestion d'utilisateurs de base de données.

Pour obtenir des informations de base sur la gestion standard des utilisateurs, reportez-vous à Comptes utilisateur dans Concepts Oracle Database. Pour obtenir des informations détaillées et des instructions, reportez-vous à Gestion de la sécurité pour les utilisateurs Oracle Database dans le guide de sécurité Oracle Database 19c ou le guide de sécurité Oracle Database 23ai.

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

Outil	Description
Database Vault	Oracle Database Vault est préconfiguré et disponible dans les bases de données Autonomous Database. Vous pouvez utiliser ses puissants contrôles de sécurité pour limiter l'accès aux données d'application par des utilisateurs de base de données privilégiés, ce qui réduit le risque de menaces internes et externes, et répond aux exigences de conformité courantes. Pour plus d'informations, reportez-vous à Protection des données dans Fonctionnalités de sécurité d'Autonomous Database.
Oracle Cloud Infrastructure Identity and Access Management (IAM)	Vous pouvez configurer Autonomous Database pour utiliser l'authentification et l'autorisation Oracle Cloud Infrastructure Identity and Access Management (IAM) afin d'autoriser les utilisateurs IAM à accéder à une instance Autonomous Database avec des informations d'identification IAM. Pour utiliser cette option avec votre base de données, reportez-vous à Utilisation de l'authentification Identity and Access Management (IAM) avec Autonomous Database.
Jetons d'accès OAuth2 Azure	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 `oAuth2` Azure. Ce type d'intégration permet à un utilisateur Azure AD d'accéder à une instance Oracle Autonomous Database. Les utilisateurs et les applications Azure AD peuvent se connecter avec les informations d'authentification unique (SSO) Azure AD pour obtenir un jeton d'accès `OAuth2` à envoyer à la base de données. Pour plus d'informations sur l'intégration de Microsoft Azure Active Directory aux bases de données, reportez-vous à Authentification et autorisation des 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 instances Autonomous Database afin d'authentifier et d'autoriser les utilisateurs Microsoft Active Directory. Cette intégration peut vous permettre de consolider votre référentiel d'utilisateurs tout en implémentant une stratégie d'accès utilisateur de base de données rigoureuse, que vous ayez recours à 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 aux bases de données, reportez-vous à Microsoft Active Directory avec Autonomous Database.
Kerberos	Kerberos est un système d'authentification de tiers sécurisé, qui repose sur des clés secrètes partagées. Il suppose que le tiers est sécurisé et offre des fonctions d'accès avec connexion unique, un stockage centralisé des mots de passe, l'authentification des liens de base de données et renforce la sécurité des ordinateurs. Cela est effectué via un serveur d'authentification Kerberos. La prise en charge de Kerberos par Autonomous Database offre les avantages de l'accès avec connexion unique et de l'authentification centralisée des utilisateurs Oracle. Pour plus d'informations, reportez-vous à Authentification d'utilisateurs Autonomous Database avec Kerberos.
Kerberos avec CMU-AD	L'authentification Kerberos peut être configurée sur CMU-AD pour fournir l'authentification Kerberos CMU-AD aux utilisateurs Microsoft Active Directory. Afin de fournir l'authentification Kerberos CMU-AD pour les utilisateurs Microsoft Active Directory, vous pouvez activer l'authentification Kerberos en plus de CMU-AD en définissant `type` sur `CMU` tout en activant l'authentification externe comme indiqué dans l'exemple présenté dans Activation de l'authentification Kerberos sur Autonomous Database.
Real Application Security et Virtual Private Database	Oracle Real Application Security (RAS) fournit un modèle déclaratif qui permet d'appliquer des stratégies de sécurité englobant non seulement les business objects protégés, mais également les principaux (utilisateurs et rôles) disposant de droits sur ces business objects. RAS est plus sécurisé, évolutif et rentable que son prédécesseur, Oracle Virtual Private Database. Avec Oracle RAS, les utilisateurs d'application sont authentifiés au niveau application et dans la base de données. Quel que soit le chemin d'accès aux données, les stratégies 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 le type d'opération (sélection, insertion, mise à jour et suppression) pouvant être effectué sur les lignes et les colonnes des objets de base de données. Pour plus d'informations sur Oracle RAS, reportez-vous à la section Introducing Oracle Database Real Application Security dans le Guide de l'administrateur et du développeur Oracle Database 19c Real Application Security ou Guide de l'administrateur et du développeur Oracle Database 23ai Real Application Security. Oracle Autonomous Database prend également en charge Oracle Virtual Private Database (VPD), le prédécesseur d'Oracle RAS. Si vous connaissez déjà Oracle VPD et que vous l'utilisez, vous pouvez le configurer et l'utiliser avec vos bases de données autonomes. Pour plus d'informations sur Virtual Private Database, reportez-vous à Utilisation d'Oracle Virtual Private Database pour contrôler l'accès aux données dans le guide de sécurité 19c Oracle Database ou le guide de sécurité Oracle Database 23ai.

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

L'état de sécurité d'Oracle concernant la gestion des accès utilisateur et des privilèges sur ses produits et services est documenté dans Oracle Access Control.

Autonomous Database on Dedicated Exadata Infrastructure 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 responsabilités 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 aux composants logiciels et d'infrastructure gérés par Oracle.

Autonomous Database on Dedicated Exadata Infrastructure est conçu pour sécuriser les données en vue d'une utilisation autorisée par le client et pour protéger les données contre tout accès non autorisé, ce qui inclut la prévention de l'accès aux données client par les membres du personnel des opérations Oracle Cloud. Les mesures de sécurité conçues pour protéger contre les accès non autorisés à l'infrastructure Exadata, aux machines virtuelles Autonomous et aux données de base de données Oracle sont les suivantes :

Les données Oracle Database sont protégées par des clés de cryptage transparent des données (TDE) Oracle.
Le client contrôle l'accès aux clés de cryptage TDE et peut choisir de les stocker dans un système de gestion des clés Oracle Key Vault externe.
Oracle Database Vault est préconfiguré pour empêcher les utilisateurs privilégiés d'accéder aux données client dans les instances Autonomous Database.
Les clients peuvent choisir d'approuver l'accès d'opérateur via l'inscription au service Operator Access Control.
Tout l'accès de l'opérateur est basé sur l'authentification multifacteur matérielle FIPS 140-2 niveau 3, implémentée avec un YubiKey matériel implémenté avec des périphériques approuvés par Oracle.
Toutes les actions d'opérateur sont journalisées au niveau de la commande et peuvent être envoyées au service de journalisation OCI ou à un SIEM client en temps quasi réel.
Oracle Operations Access Control garantit que les comptes utilisateur utilisés par le personnel en charge des opérations et du support technique Oracle Cloud pour surveiller et analyser les performances ne peuvent pas accéder aux données des instances Autonomous Database. Le personnel en charge des opérations et du support technique Oracle Cloud n'a pas accès aux données de vos instances Autonomous Database. Lorsque vous créez une base de données Conteneur Autonomous, Autonomous Database on Dedicated Exadata Infrastructure active et configure la fonctionnalité Operations Control d'Oracle Database Vault pour empêcher les utilisateurs communs d'accéder aux données des instances Autonomous Database créées dans la base de données Conteneur.
Vous pouvez vérifier qu'Operations Control est actif en entrant l'instruction SQL suivante dans une instance Autonomous Database :
```
SELECT * FROM DBA_DV_STATUS;
```
Le statut de APPLICATION CONTROL indique que la fonctionnalité Operations Control est active.

Remarques :
Operations Control s'appelait auparavant Application Control.

PAM est également implémenté avec Database Vault pour la protection des données, comme indiqué dans Fonctionnalités de sécurité d'Autonomous Database.