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

Puede configurar Oracle Database en Base Database Service de modo que utilice la autenticación y autorización deMicrosoft Azure Active Database para permitir a los usuarios de Azure AD acceder a la base de datos con credenciales de Azure AD.

Temas relacionados

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

Se puede configurar una instancia de Oracle Database en un servicio de base de datos base para que los usuarios de Microsoft Azure Active Directory (Azure AD) se conecten mediante tokens de acceso OAuth2 de Azure.

Para obtener más información sobre la autorización de usuarios, la arquitectura, las asignaciones de usuarios, los casos de uso y el proceso de integración de Azure AD, consulte la sección Introducción a la autorización de usuarios de Microsoft Azure AD para una instancia de Oracle Database en la Guía de seguridad de Oracle Database.

Requisitos

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.

Valores 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 los recursos de la base de datos de modo que estos recursos puedan utilizar el gateway para obtener una clave pública de la instancia de Azure AD para utilizar la autenticación de Azure AD:
    1. Vaya a la página Detalles de subred de la subred.
    2. En el separador Información de subred, haga clic en el nombre de la Tabla de rutas de la subred para mostrar su página Detalles de tabla de rutas.
    3. En la tabla de Reglas de ruta existentes, compruebe si ya hay una regla con las siguientes características:
      • Destino: 0.0.0.0/0
      • Tipo de destino: gateway de NAT
      • Destino: nombre del gateway de servicio que acaba de crear en la VCN

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

    4. Vuelva a la página Detalles de subred de la subred.
    5. En la tabla Listas de seguridad de la subred, haga clic en el nombre de la lista de seguridad de la subred para mostrar su página Detalles de lista de seguridad.
    6. En el menú lateral, en Recursos, haga clic en 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
      • Destino: 0.0.0.0/0
      • Protocolo IP: TCP
      • Rango de puertos de origen: 443
      • Rango de puertos de destino: todos
    8. Si dicha regla no existe, haga clic en Agregar reglas de salida y agregue una regla de salida 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.

  • Uso de un certificado de servidor de base de datos autofirmado frente a un certificado de servidor de base de datos firmado por una autoridad de certificación comúnmente conocida.
  • TLS unidireccional (TLS) frente a TLS mutua o bidireccional (mTLS).
  • Cliente con o sin cartera.

Certificado autofirmado: el uso de un certificado autofirmado es una práctica común para los recursos de TI internos, 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 certificación conocida: el uso de una autoridad de certificación raíz conocida tiene algunas ventajas, ya que es muy probable que el certificado raíz ya esté almacenado en el almacén de certificados por defecto del 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 tiene normalmente un costo asociado.

TLS unidireccional: 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 el servidor tienen certificados de identidad que se presentan entre sí. 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 una cartera de cliente cuando se utiliza mTLS para almacenar el certificado de cliente. 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 clientes 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 información detallada sobre cómo configurar TLS entre el cliente de base de datos y el servidor de base de datos, incluidas las opciones descritas anteriormente, consulte Configuración de la autenticación de seguridad de capa de transporte.

Si decide utilizar certificados autofirmados y para conocer las tareas adicionales relacionadas con la cartera, consulte la guía de referencia de la interfaz de línea de comandos (CLI) de orapki en la Guía de seguridad de la base de datos. 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 completar los requisitos en la sección Requisitos y, a continuación, seguir las instrucciones de la sección Configuración de la integración de Oracle Database para Microsoft Azure AD de la Guía de seguridad de Oracle Database.

Asignación de esquemas y roles de Oracle 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 asignar esquemas y roles de Oracle Database a usuarios de Azure AD, consulte la sección Asignación de esquemas y roles de Oracle Database en la Guía de seguridad de Oracle 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 la configuración de conexiones de cliente de Azure AD, consulte la sección Configuración de conexiones de cliente de Azure AD a Oracle Database en la Guía de seguridad de Oracle 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 la prueba de la conexión, consulte la sección Prueba de accesibilidad del punto final de Azure en la guía de seguridad de Oracle 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 los archivos de rastreo y la configuración del rastreo de cliente para la autenticación de tokens, consulte la sección Archivos de rastreo para solucionar problemas de conexiones de cliente de Oracle Database con Azure AD en la Guía de seguridad de Oracle Database.