Utiliser l'authentification Azure Active Directory avec le service de base de données de base

Vous pouvez configurer Oracle Database dans le service de base de données de base pour l'utilisation de l'authentification et de l'autorisation Microsoft Azure Active Database afin de permettre aux utilisateurs Azure AD d'accéder à la base de données à l'aide des données d'identification Azure AD.

Rubriques connexes

À propos de l'intégration d'Azure AD au service de base de données de base

Il est possible de configurer une base de données Oracle Database dans une instance du service de base de données de base pour permettre aux utilisateurs Microsoft Azure Active Directory (Azure AD) de se connecter à l'aide de jetons d'accès Azure OAuth2.

Pour plus d'informations sur l'autorisation des utilisateurs Azure AD, l'architecture, les mappages d'utilisateurs, les cas d'utilisation et le processus d'intégration, voir Présentation de l'autorisation des utilisateurs Microsoft Azure AD pour une instance Oracle Database dans le Guide de sécurité d'Oracle Database.

Conditions requises

Les préalables suivants sont requis pour l'authentification Azure AD dans le service de base de données de base.

Chacun d'eux est décrit en détail dans les rubriques suivantes.

Paramètres de réseau

Avant d'utiliser l'authentification Azure AD dans des bases de données, vous devez utiliser le service de réseau pour ajouter une passerelle de service, une règle de routage et une règle de sécurité de trafic sortant au réseau en nuage virtuel (VCN) et aux sous-réseaux où résident vos ressources de base de données. Effectuez les étapes suivantes pour configurer la connectivité sortante vers Azure AD à l'aide d'une passerelle NAT.

  1. Créez une passerelle NAT dans le VCN où résident vos ressources de base de données en suivant les instructions sous Créer la passerelle de service.
  2. Après avoir créé la passerelle de service, ajoutez une règle de routage et une règle de sécurité de trafic sortant à chaque sous-réseau (dans le VCN) où résident les ressources de base de données afin que ces ressources puissent utiliser la passerelle pour obtenir une clé publique de votre instance Azure AD afin d'utiliser l'authentification Azure AD :
    1. Allez à la page Détails du sous-réseau associée au sous-réseau.
    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.
    3. Dans la table des règles de routage existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
      • Destination : 0.0.0.0/0
      • Type de cible : Passerelle NAT
      • Cible : Nom de la passerelle de service que vous venez de créer dans le VCN

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

    4. Retournez à 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é.
    6. Dans le menu latéral, sous Ressources, cliquez sur Règles de trafic sortant.
    7. Dans la table des règles de trafic sortant existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
      • Type de destination : CIDR
      • Destination : 0.0.0.0/0
      • Protocole IP : TCP
      • Intervalle de ports sources : 443
      • Intervalle de ports de destination : Tout
    8. Si une telle règle n'existe pas, cliquez sur Ajouter des règles de trafic sortant et ajoutez une règle de trafic sortant avec ces caractéristiques.

Configuration TLS

Lors de l'envoi de jetons Azure AD du client de base de données au serveur de base de données, une connexion TLS doit être établie. Le portefeuille TLS doté du certificat de base de données pour l'instance du service de base de données de base doit être stocké dans l'emplacement WALLET_ROOT. Créez un répertoire tls qui ressemble à : WALLET_ROOT/<PDB GUID>/tls

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

  • 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.
  • Authentification TLS unidirectionnelle (TLS) ou authentification TLS mutuelle ou bidirectionnelle (mTLS).
  • Client avec ou sans portefeuille.

Certificat auto-signé : L'utilisation d'un certificat auto-signé est une pratique commune pour les ressources informatiques en interne, car vous pouvez les créer vous-même et gratuitement. La ressource (ici, le serveur de base de données) aura un certificat auto-signé pour s'authentifier auprès du client de base de données. Le certificat auto-signé et le certificat racine seront 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 du serveur de base de données, une copie du certificat racine sera également nécessaire sur le client. Ce certificat racine créé automatiquement peut être stocké dans un portefeuille côté client ou installé dans le magasin de certificats par défaut du système client (Windows et Linux uniquement). Lorsque la session est é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 bien connue : L'utilisation d'une autorité de certification racine connue présente certains avantages dans la mesure où le certificat racine est probablement déjà stocké dans le magasin de certificats par défaut du système client. Aucune étape supplémentaire n'est requise pour le client pour le stockage du certificat racine si celui-ci est un certificat racine commun. L'inconvénient est que généralement, cela représente un coût.

TLS unidirectionnel : Dans la session TLS standard, seul le serveur fournit un certificat au client pour lui permettre de s'authentifier. Le client n'a pas besoin de disposer d'un certificat client distinct pour s'authentifier auprès du serveur (comme pour l'établissement des sessions HTTPS). Alors que la base de données nécessite un portefeuille pour stocker le certificat du serveur, la seule chose dont le client a besoin est le certificat racine utilisé pour signer le certificat du serveur.

TLS bidirectionnel (également appelé TLS mutuel, mTLS) : Dans mTLS, le client et le serveur disposent tous deux de certificats d'identité qui sont présentés l'un à l'autre. Dans la plupart des cas, le même certificat racine aura signé ces deux certificats de sorte que le même certificat racine puisse être utilisé avec le serveur et le client de base de données pour authentifier l'autre certificat. mTLS est parfois utilisé pour authentifier l'utilisateur puisque l'identité de l'utilisateur est authentifiée par le serveur de base de données au moyen du certificat. Cela n'est pas nécessaire pour transmettre des jetons Azure AD, mais peut être utilisé lors de la transmission de jetons Azure AD.

Client avec un portefeuille : Un portefeuille de client est obligatoire lors de l'utilisation de mTLS pour stocker le certificat de client. Toutefois, le certificat racine peut être stocké dans le même portefeuille ou dans le magasin 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. L'authentification TLS unidirectionnelle est configurée lorsque le client ne dispose pas de son propre certificat et
  2. Le certificat racine qui a signé le certificat du serveur de base de données est stocké dans le magasin de certificats par défaut du système. Le certificat racine est probablement déjà présent si le certificat du serveur est signé par une autorité de certification commune. S'il s'agit d'un certificat auto-signé, le certificat racine doit être installé dans le magasin de certificats par défaut du système pour éviter l'utilisation d'un portefeuille de client.

Pour plus de détails sur la configuration de TLS entre le client de base de données et le serveur de base de données, notamment les options décrites ci-dessus, voir Configuration de l'authentification TLS.

Si vous choisissez d'utiliser des certificats auto-signés et pour d'autres tâches liées au portefeuille, consultez le guide de référence de l'interface de ligne de commande orapki dans le Guide de sécurité d'Oracle Database. Voir Gestion des éléments d'infrastructure à clé publique.

Configurer le service de base de données de base pour l'intégration à Azure AD

L'intégration du service de base de données de base à Azure AD nécessite que la base de données soit enregistrée dans Azure AD pour pouvoir demander la clé publique Azure AD.

Pour configurer le service de base de données de base pour l'intégration à Azure AD, vous devez d'abord terminer les préalables dans la section Préalables, puis suivre les instructions de la section Configuration de l'instance Oracle Database pour l'intégration de Microsoft Azure AD du Guide de sécurité d'Oracle Database.

Mapper des schémas et des rôles Oracle Database

Les utilisateurs Azure AD seront mappés à un schéma de base de données et éventuellement à un ou plusieurs rôles de base de données.

Pour plus d'informations sur les options de mappage des schémas et des rôles Oracle Database aux utilisateurs Azure AD, voir la section Mappage des schémas et des rôles Oracle Database dans le Guide de sécurité d'Oracle Database.

Configurer des connexions de client à Azure AD

Il existe de nombreuses façons de configurer un client pour qu'il se connecte à une instance du service de base de données de base à l'aide de jetons Azure AD.

Pour plus d'informations sur la configuration des connexions de client Azure AD, voir Configuration des connexions de client Azure AD à Oracle Database dans le Guide de sécurité d'Oracle Database.

Tester l'accessibilité du point d'extrémité Azure

Vous pouvez vous assurer que votre instance de base de données de base peut accéder au point d'extrémité Azure AD en exécutant un test de connexion.

Pour plus d'informations sur le test de la connexion, voir Test de l'accessibilité du point d'extrémité Azure dans le guide de sécurité d'Oracle Database.

Fichiers de suivi utilisés pour le dépannage des connexions

Vous pouvez utiliser des fichiers de suivi pour dépanner les connexions de client au service de base de données de base à l'aide d'Azure AD.

Pour plus d'informations sur les fichiers de suivi et la définition du traçage client pour l'authentification par jeton, voir Fichiers de suivi pour le dépannage des connexions de client à Oracle Database à l'aide d'Azure AD dans le Guide de sécurité d'Oracle Database.