Documentation Oracle Cloud Infrastructure

Authentification et autorisation des utilisateurs Microsoft Entra ID (MS-EI) pour les bases de données Oracle sur Oracle Exadata Database Service on Dedicated Infrastructure

Une base de données Oracle Database peut être configurée pour permettre aux utilisateurs Microsoft Azure de Microsoft Entra ID de se connecter à l'aide de l'authentification SSO.

Rubrique parent : Guides pratiques

A propos de l'autorisation des utilisateurs Microsoft Entra ID (MS-EI) pour les bases de données Oracle sur Oracle Exadata Database Service on Dedicated Infrastructure

Les utilisateurs d'Oracle Exadata Database Service on Dedicated Infrastructure peuvent être gérés de manière centralisée dans un service MS-EI.

L'intégration d'Oracle Database avec MS-EI est prise en charge pour les bases de données sur site et la plupart des plates-formes Oracle OCI DBaaS.

Les instructions de configuration de MS-EI utilisent le terme "Oracle Database" pour inclure ces environnements.

Ce type d'intégration permet à l'utilisateur MS-EI d'accéder à une instance Oracle Exadata Database Service on Dedicated Infrastructure. Les utilisateurs et les applications MS-EI peuvent se connecter à l'aide des informations d'identification SSO (accès avec connexion unique) MS-EI pour obtenir un jeton d'accès MS-EI OAuth2 à envoyer à la base de données.

L'administrateur crée et configure l'inscription de l'application (inscription d'application) de l'instance Oracle Exadata Database Service on Dedicated Infrastructure avec MS-EI. L'administrateur crée également des rôles d'application pour l'inscription de l'application de base de données dans MS-EI et affecte ces rôles aux utilisateurs, groupes et applications MS-EI. Ces rôles d'application seront mis en correspondance avec des schémas et rôles globaux de base de données. Un principal MS-EI affecté à un rôle d'application sera mis en correspondance avec un schéma ou un rôle global de base de données. Un schéma global Oracle peut également être mis en correspondance exclusivement avec un utilisateur MS-EI. Lorsque le principal est un utilisateur invité ou un principal de service, il peut uniquement être mis en correspondance avec le schéma de base de données via un rôle d'application MS-EI. Un rôle global Oracle ne peut être mappé qu'avec un rôle d'application MS-EI.

Les outils et les applications mis à jour pour prendre en charge les jetons MS-EI peuvent authentifier les utilisateurs directement auprès de MS-EI et transmettre le jeton d'accès à la base de données à l'instance Oracle Exadata Database Service on Dedicated Infrastructure. Vous pouvez configurer des outils de base de données existants tels que SQL*Plus pour utiliser un jeton MS-EI à partir d'un emplacement de fichier ou obtenir le jeton directement à partir de MS-EI. Lorsque vous utilisez un utilitaire pour obtenir le jeton à transmettre au pilote client de base de données via un emplacement de fichier, les jetons MS-EI peuvent être extraits à l'aide d'outils tels que Microsoft PowerShell ou la CLI Azure et placés dans un emplacement de fichier. Un jeton d'accès à la base de données MS-EI OAuth2 est un jeton de support avec un délai d'expiration. Le pilote client Oracle Database vérifie que le jeton est dans un format valide et qu'il n'a pas expiré avant de le transmettre à la base de données. La portée du jeton est définie sur la base de données. Les rôles d'application affectés au principal Azure AD sont inclus dans le jeton d'accès. L'emplacement du répertoire du jeton MS-EI ne doit disposer que des droits d'accès suffisants pour que l'utilisateur puisse écrire le fichier de jeton dans l'emplacement et que le client de base de données puisse extraire ces fichiers (par exemple, l'utilisateur de processus doit simplement disposer des droits d'accès en lecture et en écriture). Etant donné que le jeton autorise l'accès à la base de données, il doit être protégé dans le système de fichiers.

Les utilisateurs MS-EI peuvent demander un jeton en tant que client enregistré avec l'enregistrement de l'application MS-EI en utilisant des méthodes telles que les suivantes :

  • Saisie des identifiants MS-EI dans un écran d'authentification MS-EI avec ou sans authentification à plusieurs facteurs

Oracle Exadata Database Service on Dedicated Infrastructure prend en charge les flux d'authentification MS-EI suivants :

  • Flux interactif (code d'autorisation), qui est utilisé lorsqu'un navigateur peut être utilisé pour saisir les informations d'identification de l'utilisateur
  • les informations d'identification client, destinées aux applications qui se connectent en leur nom (et non en tant qu'utilisateur final) ;
  • l'authentification OBO (au nom de), soit quand une application demande un jeton d'accès au nom d'un utilisateur connecté pour l'envoyer à la base de données.
  • ROPC est également pris en charge pour les environnements de test et de développement

Oracle Exadata Database Service on Dedicated Infrastructure accepte les jetons représentant les principaux MS-EI suivants :

  • Utilisateur MS-EI, utilisateur inscrit dans la location MS-EI
  • un utilisateur invité, inscrit en tant qu'utilisateur invité dans la location MS-EI ;
  • un service, soit l'application inscrite se connectant à la base de données en son nom avec le flux d'informations d'identification client (cas d'emploi de pool de connexions).

Configuration de l'intégration d'Oracle Database pour Microsoft Entra ID (MS-EI)

L'intégration de MS-EI à l'instance Oracle Database nécessite que la base de données soit inscrite auprès de MS-EI afin que la base de données puisse demander la clé publique MS-EI.

Pour plus d'informations sur la configuration de MS-EI, la configuration de la base de données et la configuration du client de base de données, reportez-vous aux sections suivantes :

Rubrique parent : Authentification et autorisation des utilisateurs d'ID Microsoft Entra pour les bases de données Oracle sur Oracle Exadata Database Service on Dedicated Infrastructure

Prérequis pour l'authentification Microsoft Entra ID (MS-EI)

Passez en revue les prérequis pour l'intégration d'Oracle Database avec MS-EI.

L'intégration de MS-EI à Oracle Database sur Oracle Exadata Database Service on Dedicated Infrastructure nécessite :

  1. Oracle Database avec la version 19.18 ou supérieure.
  2. Connectivité à la base de données sur le port TLS 2484. Les connexions non TLS ne sont pas prises en charge.
  3. Connectivité réseau sortante à MS-EI afin que la base de données puisse demander la clé publique MS-EI.
  4. Oracle Database à inscrire auprès de MS-EI.
  5. Les utilisateurs et les applications qui doivent demander un jeton MS-EI doivent également être en mesure d'avoir une connectivité réseau à MS-EI. Vous devez peut-être configurer un paramètre de proxy pour la connexion.
  6. Pour les déploiements Oracle Exadata Database Service on Dedicated Infrastructure, les paramètres de proxy HTTP de votre environnement doivent autoriser la base de données à utiliser MS-EI.

    Ces paramètres sont définis par l'administrateur de parc lors de la création de l'infrastructure Oracle Exadata Database Service on Dedicated Infrastructure, comme décrit dans Procédure de création d'une ressource d'infrastructure Exadata cloud.

    Remarque

    La configuration réseau, y compris le proxy HTTP, ne peut être modifiée que jusqu'à ce que l'infrastructure Exadata présente l'état Activation requise. Une fois activé, vous ne pouvez plus modifier ces paramètres.

    La configuration d'un proxy HTTP pour une infrastructure Exadata déjà provisionnée nécessite une demande de service (SR) dans My Oracle Support. Pour plus d'informations, reportez-vous à Création d'une demande d'assistance dans My Oracle Support.

Prérequis réseau pour l'authentification Microsoft Entra ID (MS-EI)

Avant de vous servir de l'authentification Azure AD sur des bases de données dans Exadata Cloud Infrastructure, vous devez utiliser le service Networking pour ajouter une passerelle de service, une règle de routage et une règle de sécurité sortante au réseau cloud virtuel et aux sous-réseaux sur lesquels résident vos ressources de base de données.

  1. Créez une passerelle de service dans le réseau cloud virtuel sur lequel résident vos ressources de base de données en suivant les instructions de Tâche 1 : créer la passerelle de service dans la documentation OCI.
  2. Après avoir créé la passerelle de service, ajoutez une règle de routage et une règle de sécurité sortante à chaque sous-réseau (dans le réseau cloud virtuel) sur lequel résident les ressources de base de données afin que ces ressources puissent utiliser la passerelle pour recourir à l'authentification Azure AD :
    1. Accédez à la page Détails du sous-réseau correspondante.
    2. Dans l'onglet Informations sur le sous-réseau, cliquez sur le nom de la table de routage du sous-réseau pour afficher la page Détails de la table de routage correspondante.
    3. Dans la table des règles de routage existantes, vérifiez s'il existe déjà une règle avec les caractéristiques suivantes :
      • Destination : 0.0.0.0/0
      • Type de cible : passerelle NAT
      • Cible : nom de la passerelle NAT que vous venez de créer dans le réseau cloud virtuel

      Si une telle règle n'existe pas, cliquez sur Ajouter des règles de routage et ajoutez une règle possédant ces caractéristiques.

    4. Revenez à la page Détails du sous-réseau.
    5. Dans la table Listes de sécurité du sous-réseau, cliquez sur le nom de la liste de sécurité du sous-réseau pour afficher la page Détails de la liste de sécurité correspondante.
    6. Dans le menu latéral, sous Ressources, cliquez sur Règles sortantes.
    7. Dans la table des règles sortantes existantes, vérifiez s'il existe déjà une règle avec les caractéristiques suivantes :
      • Type de destination : CIDR
      • Destination : 0.0.0.0/0
      • Protocole IP : TCP
      • Plage de ports source : 443
      • Plage de ports de destination : Tout
    8. Si une telle règle n'existe pas, cliquez sur Ajouter des règles sortantes et ajoutez une règle possédant ces caractéristiques.

Configuration de TLS pour utiliser les jetons Microsoft Entra ID (MS-EI)

Lorsque vous envoyez des jetons MS-EI du client de base de données au serveur de données, une connexion TLS doit être établie.

Le portefeuille TLS avec le certificat de base de données pour l'instance de service ExaDB-D doit être stocké à l'emplacement WALLET_ROOT. Créez un répertoire tls semblable à ce qui suit : WALLET_ROOT/<PDB GUID>/tls.

Lors de la configuration de TLS entre le serveur et le client de base de données, plusieurs options sont à envisager.

  • Utilisation d'un certificat de serveur de base de données auto-signé ou d'un certificat de serveur de base de données signé par une autorité de certification connue
  • TLS unidirectionnelle (TLS), ou TLS mutuelle ou bidirectionnelle (mTLS)
  • Client avec ou sans portefeuille

Certificat auto-signé

L'utilisation d'un certificat auto-signé est une pratique courante pour les ressources informatiques en interne car vous pouvez créer ces certificats vous-même gratuitement. La ressource (dans ce cas, le serveur de base de données) dispose d'un certificat auto-signé pour s'authentifier auprès du client de base de données. Le certificat auto-signé et le certificat racine sont stockés dans le portefeuille du serveur de base de données. Pour que le client de base de données puisse reconnaître le certificat de serveur de base de données, une copie du certificat racine est également nécessaire sur le client. Ce certificat racine auto-créé peut être stocké dans un portefeuille côté client ou installé dans la banque de certificats par défaut du système client (Windows et Linux uniquement). Une fois la session établie, le client de base de données vérifie que le certificat envoyé par le serveur de base de données a été signé par le même certificat racine.

Autorité de certification connue

L'utilisation d'une autorité de certification racine connue présente certains avantages du fait que le certificat racine est probablement déjà stocké dans la banque de certificats par défaut du système client. Aucune étape supplémentaire n'est requise pour que le client stocke le certificat racine s'il s'agit d'un certificat racine courant. L'inconvénient est que cela a généralement un coût.

TLS unidirectionnelle

Dans une session TLS standard, seul le serveur fournit un certificat au client pour s'authentifier. Le client n'a pas besoin d'avoir un certificat client distinct pour s'authentifier auprès du serveur (semblable au mode d'établissement des sessions HTTPS). La base de données requiert un portefeuille pour stocker le certificat de serveur, mais la seule chose dont le client a besoin est le certificat racine utilisé pour signer le certificat de serveur.

TLS bidirectionnelle (également appelée TLS mutuelle, mTLS)

Avec mTLS, le client présente un certificat d'identité au serveur, et vice versa. Dans la plupart des cas, le même certificat racine signe ces deux certificats afin que le même certificat racine puisse être utilisé avec le serveur de base de données et le client pour authentifier l'autre certificat. Le protocole mTLS est parfois utilisé pour authentifier l'utilisateur car l'identité de l'utilisateur est authentifiée par le serveur de base de données via le certificat. Cela n'est pas nécessaire pour transmettre des jetons IAM, mais peut être utilisé lors de la transmission de jetons IAM.

Client avec portefeuille

Lors de l'utilisation de mTLS, le portefeuille client est obligatoire pour stocker le certificat client. Toutefois, le certificat racine peut être stocké dans le même portefeuille ou dans la banque de certificats par défaut du système.

Client sans portefeuille

Les clients peuvent être configurés sans portefeuille lors de l'utilisation de TLS dans les conditions suivantes : 1) la configuration de TLS unidirectionnelle est effectuée lorsque le client ne dispose pas de son propre certificat et 2) le certificat racine qui a signé le certificat de serveur de base de données est stocké dans la banque de certificats par défaut du système. Le certificat racine s'y trouve probablement déjà si le certificat de serveur est signé par une autorité de certification courante. S'il s'agit d'un certificat auto-signé, le certificat racine doit être installé dans la banque de certificats par défaut du système pour éviter l'utilisation d'un portefeuille client.

Pour plus d'informations sur la configuration de TLS entre le client de base de données et le serveur de base de données, y compris les options décrites ci-dessus, reportez-vous aux sections suivantes :

Si vous choisissez d'utiliser des certificats autosignés et pour des tâches supplémentaires liées au portefeuille, reportez-vous aux sections suivantes :