Uso de la autenticación de Azure Active Directory con Base Database Service

Puede configurar Oracle AI Database en Base Database Service para utilizar la autenticación y autorización de Microsoft Azure Active Database y permitir que los usuarios de Azure AD accedan a la base de datos con credenciales de Azure AD.

Acerca de la integración de Azure AD con Base Database Service

Se puede configurar Oracle AI Database en una instancia de Base Database Service para que los usuario de Microsoft Azure Active Directory (Azure AD) se conecten mediante token de acceso OAuth2 de Azure.

Para obtener más información sobre cómo autorizar usuarios, la arquitectura, las asignaciones a usuarios y el proceso de integración de Azure AD, consulte Authenticating and Authorizing Microsoft Azure Users for Oracle AI Databases en la Guía de seguridad de la instancia de Oracle AI Database.

Requisitos previos

Los siguientes requisitos son necesarios para la autenticación de Azure AD en Base Database Service.

Cada uno de ellos se describe en detalle en los siguientes temas.

Configuración de red

Antes de utilizar la autenticación de Azure AD en las bases de datos, debe utilizar el servicio Networking para agregar un gateway de servicio, una regla de ruta y una regla de seguridad de salida a la red virtual en la nube (VCN) y las subredes en las que residen los recursos de base de datos. Realice los siguientes pasos para configurar la conectividad saliente a Azure AD mediante un gateway de NAT.

  1. Para crear un gateway de NAT en la VCN en la que residen los recursos de base de datos, siga las instrucciones de Creación del gateway de servicio.

  2. Después de crear el gateway de servicio, agregue una regla de ruta y una regla de seguridad de salida a cada subred (en la VCN), en la que residan las instancias de base de datos, de modo que estos recursos puedan utilizar el gateway para obtener una clave pública de Azure AD de su instancia para utilizar su autenticación en Azure AD:

    1. Vaya a la página Detalles de la subred de la subred.
    2. En el separador Información de subredes, haga clic en el nombre de la Tabla de ruta de la subredes para mostrar su página Detalles de tabla de ruta.

    3. En la tabla de Reglas de Ruta existentes, compruebe si ya hay una regla con las siguientes características:

      • Destination: 0.0.0.0/0 (Destino):
      • Tipo de destino: gateway de NAT
      • Destino: nombre del Gateway de servicio que acabará de crear en la VCN

      Si dicha regla no existe, seleccione Agregar reglas de ruta y agregue una regla de ruta con estas características.

    4. Vuelva a la página Detalles de la subred de la subred.
    5. En la tabla Listas de seguridad de La subred, haga clic en el nombre de su lista de seguridad para mostrar su página Detalles de Lista de seguridad.
    6. En el menú lateral, en Recursos, seleccione Reglas de salida.

    7. En la tabla de Reglas de salida existentes, compruebe si ya hay una regla con las siguientes características:

      • Tipo de destino: CIDR
      • Destination: 0.0.0.0/0 (Destino):
      • Protocolo IP: TCP
      • Rango de puertos de origen: 443
      • Rango de puertos de destino: todos
    8. Si dicha regla no existe, seleccione Agregar reglas para la salida y agregue una regla de entrada con estas características.

Configuración de TLS

Al enviar tokens de Azure AD desde el cliente de base de datos al servidor de base de datos, se debe establecer una conexión TLS. La cartera TLS con el certificado de base de datos para la instancia de Base Database Service se debe almacenar en la ubicación WALLET_ROOT. Cree un directorio tls para que tenga el siguiente aspecto: WALLET_ROOT/<PDB GUID>/tls

Al configurar TLS entre el cliente y el servidor de base de datos, hay varias opciones que se deben tener en cuenta.

Certificado autofirmado: el uso de una certificación autofirmado es una práctica habitual para el recurso de TI interno, ya que puede crearlos usted mismo y de forma gratuita. El recurso (en nuestro caso, el servidor de base de datos) tendrá un certificado autofirmado para autenticarse en el cliente de base de datos. El certificado autofirmado y el certificado raíz se almacenarán en la cartera del servidor de base de datos. Para que el cliente de base de datos pueda reconocer el certificado del servidor de base de datos, también se necesitará una copia del certificado raíz en el cliente. Este certificado raíz creado automáticamente se puede almacenar en una cartera del cliente o se puede instalar en el almacén de certificados por defecto del sistema cliente (solo Windows y Linux). Cuando se establece la sesión, el cliente de base de datos comprobará que el certificado enviado por el servidor de base de datos ha sido firmado por el mismo certificado raíz.

Una autoridad de certificado conocida: el uso de una autoridad de certificado raíz conocida tiene algunas ventajas, ya de que es muy probable que el certificado raíz ya está almacenado en el almacén de certificado por defecto de sistema cliente. No hay ningún paso adicional necesario para que el cliente almacene el certificado raíz si es un certificado raíz común. La desventaja es que esto suele tener un costo asociado.

TLS unidireccionales: en la sesión TLS estándar, solo el servidor proporciona un certificado al cliente para autenticarse. El cliente no necesita tener un certificado de cliente independiente para autenticarse en el servidor (proceso similar a cómo se establecen las sesiones HTTPS). Aunque la base de datos necesita una cartera para almacenar el certificado del servidor, lo único que debe tener el cliente es el certificado raíz utilizado para firmar el certificado del servidor.

TLS bidireccional (también denominada TLS mutua, mTLS): en mTLS, tanto el cliente como los servidores tienen certificados de identidad que se presentan unos a otros. En la mayoría de los casos, el mismo certificado raíz firmará ambos certificados, por lo que el mismo certificado raíz se puede utilizar con el servidor de base de datos y el cliente para autenticar el otro certificado. mTLS se utiliza a veces para autenticar al usuario, ya que el servidor de base de datos autentica la identidad del usuario mediante el certificado. Esto no es necesario para transferir tokens de Azure AD, pero se puede utilizar al transferir tokens de Azure AD.

Cliente con una cartera: es obligatoria la cartera de cliente cuando el certificado de cliente se utiliza mTLS para almacenarlo. Sin embargo, el certificado raíz se puede almacenar en la misma cartera o en el almacén de certificados por defecto del sistema.

Un cliente sin cartera: los cliente se pueden configurar sin cartera al utilizar TLS en estas condiciones:

  1. Se está configurando TLS unidireccional donde el cliente no tiene su propio certificado, y

  2. el certificado raíz que firmó el certificado del servidor de base de datos se almacena en el almacén de certificados por defecto del sistema. Es probable que el certificado raíz ya exista si el certificado de servidor está firmado por una autoridad de certificación común. Si se trata de un certificado autofirmado, el certificado raíz se deberá instalar en el almacén de certificados por defecto del sistema para evitar el uso de una cartera de cliente.

Para obtener detalles sobre cómo configurar TLS entre el cliente de base de datos y la base de datos del servidor, incluidas las opciones descritas previamente, consulte Configuración de autenticación de seguridad de capa de transporte.

Si opta por utilizar certificados autofirmados y para obtener más información sobre las tareas relacionadas con las carteras, consulte orapki Command Line Interface (CLI) Reference Guide in the Database Security Guide. Consulte Gestión de elementos de infraestructura de claves públicas (PKI).

Configuración de Base Database Service para la integración con Azure AD

La integración de Base Database Service con Azure AD requiere que la base de datos se registre con Azure AD para que la base de datos pueda solicitar la clave pública de Azure AD.

Para configurar Base Database Service para la integración con Azure AD, primero debe cumplir los requisitos en la secciones Requisitos y, a continuación, seguir las instrucciones de la Sección Configuración del Oracle AI Database para Microsoft Azure AD Integration de la Guía de seguridad de la base de datos Oracle AI.

Asignar esquemas y roles de Oracle AI Database

Los usuarios de Azure AD se asignarán a un esquema de base de datos y, opcionalmente, a uno o más roles de base de datos.

Para obtener más información sobre las opciones para la asignación de esquemas y roles de la instancia de Oracle AI Database a usuarios de la instancia de Azure AD, consulte el apartado Asignación a esquemas y roles de la instancia de Oracle AI Database en la guía de seguridad de la instancia de Oracle AI Database.

Configuración de conexiones de cliente a Azure AD

Existen numerosas formas de configurar un cliente para conectarse a una instancia de Base Database Service mediante tokens de Azure AD.

Para obtener más información sobre cómo configurar conexiones de cliente Azure AD, consulte la sección Configuración de Conexiones de Cliente de Azure AD a las Bases de Datos de Oracle AI en la Guía de Seguridad de Oracle AI Database.

Prueba de la accesibilidad del punto final de Azure

Puede asegurarse de que la instancia de base de datos base puede acceder al punto final de Azure AD ejecutando una prueba de conexión.

Para obtener más información sobre cómo probar la conexión, consulte la sección Prueba de la accesibilidad del punto final de Azure en la guía de seguridad de Oracle AI Database.

Archivos de rastreo utilizados para solucionar problemas de conexiones

Puede utilizar archivos de rastreo para solucionar problemas de conexiones de cliente de Base Database Service con conexiones de Azure AD.

Para obtener más información sobre el rastreo y el establecimiento del rastreo del cliente para la autenticación del token, consulte Trace Files for Troubleshooting Oracle Database Client Connections with Azure AD en la Guía del usuario de Oracle AI Database Security Guide.