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

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

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

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

Pour plus d'informations sur l'autorisation d'utilisateurs Azure AD, l'architecture, les correspondances d'utilisateurs, les cas d'utilisation et le processus d'intégration, reportez-vous à la section Authentification et autorisation d'utilisateurs Microsoft Azure pour les bases de données Oracle AI du guide de sécurité Oracle AI 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 VCN) où 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 d'utiliser l'authentification Azure AD :

    1. Accédez à la page Détails du sous-réseau correspondante.
    2. Dans l'onglet Information sur le sous-réseau, cliquez sur le nom de la table de acheminement du sous‑réseau pour afficher la page Détails de la table de acheminement correspondante.

    3. Dans la table des règles de acheminement 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 VCN

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

    4. Revenez à la page Détails du sous-réseau du sous-réseau.
    5. Dans la table Listes de sécurité du sous‑réseau, cliquez sur le nom de la liste des sécurité du sous-réseau pour afficher sa page Détails de la liste.
    6. Dans le menu latéral, sous Ressources, sélectionnez Règles sortantes.

    7. Dans la table des règles de sortie 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, sélectionnez 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.

Certificat autosigné : l'utilisation d'un certificat autosigné est une pratique courante pour les ressources informatiques en interne car vous pouvez créer ces certificats pour vous-même. 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 certificat connue : l'utilisation d'une autorité de certificat racine connue présente certains avantages du fait que le certificat racine est probablement déjà stocké dans la banque de certificat par défaut de 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 la 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 les 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 : lorsque vous utilisez mTLS pour stocker le certificat client, un portefeuille client est obligatoire. 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'application 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 précédemment, reportez-vous à Configuration de l'authentification Transport Layer Security.

Si vous décidez d'utiliser des certificats auto-signés et pour d'autres tâches liées au portefeuille, reportez-vous au guide orapki de l'interface de ligne de commande (CLI) dans le guide de 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.

Pour configurer Base Database Service en vue de son intégration avec Azure AD, vous devez d'abord remplir les prérequis de la section Prérequis, puis suivre les instructions de la section Configuration de l'intégration d'Oracle AI Database pour Microsoft Azure AD du guide de sécurité Oracle AI Database.

Mettre en correspondance les schémas et les rôles d'Oracle AI Database

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 des schémas et des rôles Oracle AI Database avec les utilisateurs Azure AD, reportez-vous à la section Mise en correspondance des schémas et des rôles Oracle AI Database dans le guide de sécurité Oracle AI 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 des connexions client Azure AD, reportez-vous à la section Configuration des connexions client Azure AD à la base de données Oracle AI du guide de sécurité Oracle AI 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 AI 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 à Fichiers trace pour Le dépannage des connexions client Oracle Database avec Azure AD dans le Guide de sécurité Oracle AI Database.