Documentación de Oracle Cloud Infrastructure

Autenticación y autorización de usuarios de Microsoft Entra ID (MS-EI) para bases de datos Oracle en Oracle Exadata Database Service on Dedicated Infrastructure

Se puede configurar una instancia de Oracle Database para que los usuarios de Microsoft Azure de Microsoft Entra ID se conecten mediante autenticación de conexión única.

Tema principal: Guías de procedimientos

Acerca de la autorización de usuarios de Microsoft Entra ID (MS-EI) para bases de datos Oracle en Oracle Exadata Database Service on Dedicated Infrastructure

Los usuarios de Oracle Exadata Database Service on Dedicated Infrastructure se pueden gestionar de forma centralizada en un servicio MS-EI.

La integración de Oracle Database con MS-EI está soportada para bases de datos locales y la mayoría de las plataformas DBaaS de Oracle OCI.

Las instrucciones para configurar MS-EI utilizan el término "Oracle Database" para abarcar estos entornos.

Este tipo de integración permite al usuario de MS-EI acceder a una instancia de Oracle Exadata Database Service on Dedicated Infrastructure. Los usuarios y aplicaciones de MS-EI pueden conectarse con credenciales de inicio de sesión único (SSO) de MS-EI para obtener un token de acceso MS-EI OAuth2 para enviarlo a la base de datos.

El administrador crea y configura el registro de aplicación de la instancia de Oracle Exadata Database Service on Dedicated Infrastructure con MS-EI. El administrador también crea roles de aplicación (aplicación) para el registro de la aplicación de base de datos en MS-EI y los asigna a usuarios, grupos y aplicaciones de MS-EI. Estos roles de aplicación se asignarán a los esquemas y roles globales de base de datos. Un principal MS-EI asignado a un rol de aplicación se asignará a un esquema global de base de datos o a un rol global de base de datos. Un esquema global de Oracle también se puede asignar exclusivamente a un usuario de MS-EI. Cuando el principal es un usuario invitado o un principal de servicio, solo se puede asignar al esquema de base de datos mediante un rol de aplicación MS-EI. Un rol global de Oracle solo se puede asignar a un rol de aplicación MS-EI.

Las herramientas y aplicaciones que se actualizan para admitir tokens MS-EI pueden autenticar usuarios directamente con MS-EI y transferir el token de acceso a la base de datos a la instancia de Oracle Exadata Database Service on Dedicated Infrastructure. Puede configurar herramientas de base de datos existentes como SQL*Plus para utilizar un token MS-EI desde una ubicación de archivo u obtener el token directamente desde MS-EI. Cuando se utiliza una utilidad para obtener que el token se transfiera al controlador de cliente de base de datos a través de una ubicación de archivo, los tokens MS-EI se pueden recuperar mediante herramientas como Microsoft PowerShell o Azure CLI y se pueden colocar en una ubicación de archivo. Un token de acceso a base de datos OAuth2 de MS-EI es un token de portador con un tiempo de caducidad. El controlador de cliente de Oracle Database garantizará que el token tenga un formato válido y que no haya caducado antes de transferirse a la base de datos. El token está incluido en el ámbito de la base de datos. Los roles de aplicación asignados para el principal de Azure AD se incluyen como parte del token de acceso. La ubicación del directorio para el token MS-EI solo debe tener permisos suficientes para que el usuario escriba el archivo de token en la ubicación y el cliente de base de datos recupere esos archivos (por ejemplo, simplemente lectura y escritura por parte del usuario del proceso). Dado que el token permite el acceso a la base de datos, debe estar protegido en el sistema de archivos.

Los usuarios de MS-EI pueden solicitar un token como cliente registrado con el registro de la aplicación MS-EI mediante métodos como los siguientes:

  • Introducción de las credenciales MS-EI en una pantalla de autenticación MS-EI con o sin autenticación multifactor

Oracle Exadata Database Service on Dedicated Infrastructure soporta los siguientes flujos de autenticación MS-EI:

  • Flujo interactivo (código de autorización), que se utiliza cuando se puede utilizar un explorador para introducir las credenciales para el usuario
  • Credenciales de cliente, para aplicaciones que se conectan como ellas mismas (y no como usuario final)
  • On-Behalf-Of (OBO), donde una aplicación solicita un token de acceso en nombre de un usuario conectado para enviarlo a la base de datos
  • ROPC también es compatible con entornos de prueba y desarrollo

Oracle Exadata Database Service on Dedicated Infrastructure acepta tokens que representan los siguientes principales MS-EI:

  • Usuario de MS-EI, que es usuario registrado en el arrendamiento de MS-EI
  • Usuario invitado, que está registrado como usuario invitado en el arrendamiento de MS-EI
  • Servicio, que es la aplicación registrada que se conecta a la base de datos como ella misma con el flujo de credenciales del cliente (caso de uso de pool de conexiones)

Configuración de la Integración de Oracle Database for Microsoft Entra ID (MS-EI)

La integración MS-EI con la instancia de Oracle Database requiere que la base de datos se registre con MS-EI para que la base de datos pueda solicitar la clave pública MS-EI.

Para obtener información sobre la configuración de MS-EI, la configuración de la base de datos y la configuración del cliente de base de datos, consulte:

Tema principal: Autenticación y autorización de usuarios de Microsoft Entra ID (MS-EI) para bases de datos Oracle en Oracle Exadata Database Service on Dedicated Infrastructure

Requisitos previos para la autenticación de Microsoft Entra ID (MS-EI)

Revise los requisitos para integrar Oracle Database con MS-EI.

La integración de MS-EI con Oracle Database en Oracle Exadata Database Service on Dedicated Infrastructure requiere:

  1. Oracle Database será la versión 19.18 o superior.
  2. Conectividad a la base de datos en el puerto TLS 2484. Las conexiones no TLS no están soportadas.
  3. Conectividad de red saliente a MS-EI para que la base de datos pueda solicitar la clave pública MS-EI.
  4. Oracle Database que se registrará con MS-EI.
  5. Los usuarios y aplicaciones que necesitan solicitar un token MS-EI también deben poder tener conectividad de red a MS-EI. Puede que necesite configurar un valor de proxy para la conexión.
  6. Para los despliegues de Oracle Exadata Database Service on Dedicated Infrastructure, la configuración del proxy HTTP en el entorno debe permitir que la base de datos utilice MS-EI.

    El administrador del conjunto define estos valores al crear la infraestructura de Oracle Exadata Database Service on Dedicated Infrastructure, como se describe en Creación de un recurso de infraestructura de Exadata en la nube.

    Nota

    La configuración de red, incluido el proxy HTTP, solo se puede editar hasta que la infraestructura de Exadata tenga el estado Requiere activación. Una vez activada, no puede editar esa configuración.

    La configuración de un proxy HTTP para una infraestructura de Exadata ya aprovisionada necesita una solicitud de servicio (SR) en My Oracle Support. Consulte Creación de una solicitud de servicio en My Oracle Support para obtener más información.

Requisitos previos de redes para la autenticación de Microsoft Entra ID (MS-EI)

Antes de utilizar la autenticación de Azure AD en bases de datos de Exadata Cloud Infrastructure, 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 la base de datos.

  1. Cree un gateway de servicio en la VCN en la que residan los recursos de base de datos siguiendo las instrucciones de la Tarea 1: creación del gateway de servicio de la documentación de OCI.
  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 para que estos recursos puedan 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 NAT 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 para usar tokens de Microsoft Entra ID (MS-EI)

Al enviar tokens MS-EI 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 servicio ExaDB-D debe estar almacenada 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 habitual 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 a sí mismo. 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 IAM, pero se puede utilizar al transferir tokens de IAM.

Cliente con 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 una cartera al utilizar TLS en estas condiciones: 1) TLS unidireccional se está configurando en el caso en que el cliente no tiene su propio certificado y 2) el certificado raíz que ha firmado 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 el servidor de base de datos, incluidas las opciones descritas anteriormente, consulte:

Si decide utilizar certificados autofirmados y para tareas adicionales relacionadas con la cartera, consulte: