Utilisation de l'authentification Azure Active Directory avec Base Database Service

Vous pouvez configurer Oracle Database dans Base Database Service de façon à utiliser l'authentification et l'autorisation Microsoft Azure Active Database afin de permettre aux utilisateurs Azure AD d'accéder à la base de données avec leurs informations d'identification Azure AD.

Rubriques connexes

A propos de l'intégration d'Azure AD à Base Database Service

Une base de données Oracle Database dans une instance Base Database Service peut être configurée de sorte à permettre aux utilisateurs Microsoft Azure Active Directory (Azure AD) de se connecter à l'aide de jetons d'accès OAuth2 Azure.

Pour plus d'informations sur l'autorisation des utilisateurs Azure AD, l'architecture, les correspondances d'utilisateur, les cas d'emploi et le processus d'intégration, reportez-vous à la section Présentation de l'autorisation d'utilisateurs Microsoft Azure AD pour une base de données Oracle du guide de la sécurité Oracle Database.

Prérequis

Les prérequis suivants sont à respecter pour l'authentification Azure AD sur Base Database Service.

Chacun de ces éléments est décrit en détail dans les rubriques suivantes.

Paramètres réseau

Avant de vous servir de l'authentification Azure AD sur des bases de données, 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. Effectuez les étapes suivantes pour configurer la connectivité sortante à Azure AD à l'aide d'une passerelle NAT.

  1. Créez une passerelle NAT dans le réseau cloud virtuel sur lequel résident vos ressources de base de données en suivant les instructions de Création de 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é 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 obtenir une clé publique à partir de votre instance Azure AD afin de 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 de service 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 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 avec le certificat de base de données pour l'instance Base Database Service 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 unidirectionnel : 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 bidirectionnel (également appelé TLS mutuel, mTLS) : avec mTLS, le client et le serveur disposent tous deux de certificats d'identité présentés l'un à l'autre. 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 Azure AD mais peut servir lors de cette transmission.

Client avec un portefeuille : lors de l'utilisation de mTLS, un 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. L'authentification TLS unidirectionnelle est configurée lorsque le client ne dispose pas de son propre certificat.
  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 à 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, reportez-vous au guide de référence de l'interface de ligne de commande orapki dans le guide de la sécurité Database. Reportez-vous à Gestion des éléments PKI (Public Key Infrastructure).

Configuration de Base Database Service pour intégration à Azure AD

L'intégration de Base Database Service à Azure AD requiert l'inscription de la base de données auprès d'Azure AD afin que la base de données puisse demander la clé publique Azure AD.

Afin de configurer Base Database Service pour intégration à Azure AD, vous devez d'abord respecter les prérequis de la section Prérequis, puis suivre les instructions de la section Configuration de la base de données Oracle pour l'intégration de Microsoft Azure AD du guide de la sécurité Oracle Database.

Mise en correspondance de schémas et de rôles de base de données Oracle

Les utilisateurs Azure AD seront mis en correspondance avec un schéma de base de données et éventuellement avec des rôles de base de données.

Pour plus d'informations sur les options de mise en correspondance de schémas et de rôles Oracle Database avec des utilisateurs Azure AD, reportez-vous à la section Mise en correspondance de schémas et de rôles de base de données Oracle du guide de la sécurité Oracle Database.

Configuration de connexions client à Azure AD

Vous disposez de plusieurs façons de configurer un client pour la connexion à une instance Base Database Service à l'aide de jetons Azure AD.

Pour plus d'informations sur la configuration de connexions client Azure AD, reportez-vous à la section Configuration de connexions client Azure AD à Oracle Database du guide de la sécurité Oracle Database.

Test de l'accessibilité de l'adresse Azure

Vous pouvez vous assurer que votre instance Base Database peut accéder à l'adresse Azure AD en exécutant un test de connexion.

Pour plus d'informations sur le test de la connexion, reportez-vous à Test de l'accessibilité de l'adresse Azure dans le guide de sécurité Oracle Database.

Fichiers trace utilisés pour le dépannage des connexions

Vous pouvez utiliser des fichiers trace pour dépanner les connexions client Base Database Service avec Azure AD.

Pour plus d'informations sur les fichiers trace et la définition de la fonction de trace client pour l'authentification par jeton, reportez-vous à la section Fichiers trace pour le dépannage des connexions client Oracle Database avec Azure AD du guide de la sécurité Oracle Database.