Comunicación segura mediante soporte TLS y mTLS (datos en tránsito)

Oracle GoldenGate protege los datos en tránsito o los datos en movimiento mediante las siguientes funciones:

• Están soportados los protocolos de flujo con autorización HTTP nativa. Incluye una cabecera en la solicitud de establecimiento WebSocket inicial, que es el protocolo de socket web seguro (WSS). El servidor de Oracle GoldenGate comprueba la cabecera de autorización para aprobar o denegar la solicitud en función de si el rol asociado al usuario solicitante es igual o mayor que el rol asignado para las solicitudes de establecimiento de Web Sockets. Oracle GoldenGate soporta la autenticación TLS 1.2 y TLS 1.3. Puede elegir entre diferentes opciones de cifrado TLS y aplicar los conjuntos de cifrado relevantes.

• Las rutas iniciadas por destino admiten la transición de datos cuando se trabaja en zonas desmilitarizadas (DMZ).

Consulte también Protocolos de flujo de ruta de distribución.

Comunicación segura con soporte de TLS y mTLS

El protocolo de seguridad de capa de transporte (TLS) proporciona una comunicación segura a través de una red al garantizar una transmisión de datos segura. El intercambio de datos entre el servidor (instancia GoldenGate) y los clientes, incluida la interfaz web GoldenGate, AdminClient y otras aplicaciones, se autentica y cifra. Utiliza algoritmos criptográficos para cifrar datos, evitando que partes no autorizadas accedan o modifiquen la información que se transmite.

TLS verifica la identidad del servidor para garantizar que la comunicación sea con la parte deseada y no con un actor malicioso. HTTPS y WSS utilizan el protocolo TLS. Las solicitudes HTTPS se realizan a través de llamadas REST-API y WSS se utiliza para el enrutamiento seguro de los archivos de pista mediante la ruta de distribución.

TLS mutua (mTLS) es una extensión del protocolo TLS que agrega una capa adicional de seguridad mediante la autenticación tanto del cliente como del servidor en una sesión de comunicación. Es una mejora de la TLS tradicional, que proporciona una confianza bidireccional, y es una defensa adicional contra ataques suplantados. Durante el establecimiento de comunicación cliente-servidor, server presenta su certificado digital para probar su identidad al client, de modo que el cliente verifica la identidad del servidor. El cliente también presenta su certificado digital para probar su identidad en el servidor, de modo que el servidor verifique la identidad del cliente.

En un despliegue seguro, el proceso de ruta de distribución utiliza mTLS para enviar archivos de pista mediante el protocolo WSS en uno de los siguientes casos:

• Envío de datos de pista del servicio de distribución al servicio de receptor

• Envío de datos de pista mediante la ruta de distribución iniciada de destino, donde el servicio de receptor solicita al servicio de distribución que envíe archivos de pista a través de la red.

El uso de la autenticación del cliente de distribución (DistClient) mediante la presentación del certificado digital DistClient permite la comunicación de red segura mediante mTLS.

Se recomienda un despliegue seguro para Oracle GoldenGate. Requiere el certificado del servidor, la clave privada y el certificado de firma de la autoridad de certificación (certificado de CA). El certificado DistClient, la clave privada y el certificado de firma de la autoridad de certificación (certificado de CA) se pueden aplicar en cualquier momento.

Sin embargo, NGINX se podría utilizar con un despliegue no seguro para seguir proporcionando soporte de TLS para la ruta de distribución. El TLS finalizará en NGINX. El cliente verificará el certificado NGINX. Sin embargo, el certificado de cliente es opcional en la configuración de NGINX por defecto de Oracle GoldenGate.

Consulte Target-initiated Path y Soporte de proxy inverso de Oracle GoldenGate para obtener detalles. Nota: mTLS no está soportado cuando se utiliza un proxy inverso.

Cómo funciona la seguridad de la capa de transporte en un entorno de Oracle: establecimiento de comunicación de TLS

Cuando se inicia una conexión de red a través de la seguridad de capa de transporte, el cliente y el servidor realizan un establecimiento de comunicación TLS antes de la autenticación.

El proceso de establecimiento de comunicación es el siguiente:

1. El cliente y la instancia de Oracle GoldenGate establecen los conjuntos de cifrado y los algoritmos de cifrado utilizados para las transferencias de datos.

2. La instancia de Oracle GoldenGate envía su certificado al cliente y el cliente verifica que el certificado de la instancia de Oracle GoldenGate haya sido firmado por una CA de confianza. Este paso verifica la identidad de la instancia de Oracle GoldenGate.

3. Del mismo modo, si se necesita autenticación de cliente, el cliente envía su certificado a la instancia de Oracle GoldenGate. La instancia de Oracle GoldenGate verifica que el certificado del cliente haya sido firmado por una CA de confianza.

4. El cliente y la instancia de Oracle GoldenGate intercambian información de clave mediante criptografía de clave pública. En función de esta información, cada uno genera una clave de sesión. Una clave la comparten al menos dos partes (normalmente un cliente y una instancia de Oracle GoldenGate) que se utilizan para el cifrado de datos durante una única sesión de comunicación. Las claves de sesión se utilizan normalmente para cifrar el tráfico de red. Un cliente y una instancia de Oracle GoldenGate pueden negociar una clave de sesión al principio de una sesión, y esa clave se utiliza para cifrar todo el tráfico de red entre las partes para esa sesión. Si el cliente y la instancia de Oracle GoldenGate se vuelven a comunicar en una nueva sesión, negocian una nueva clave de sesión. Todas las comunicaciones posteriores entre el cliente y la instancia de Oracle GoldenGate se cifran y descifran mediante esta clave de sesión y el conjunto de cifrado negociado.

El proceso de autenticación es el siguiente: 1. En un cliente, el usuario inicia una conexión de red a Oracle GoldenGate mediante TLS.

1. TLS realiza el establecimiento de comunicación entre el cliente y Oracle GoldenGate.

2. Si el establecimiento de comunicación se realiza correctamente, la instancia GoldenGate verifica que el usuario tenga la autorización adecuada para acceder a la instancia de Oracle GoldenGate.

Cómo utiliza Oracle GoldenGate la seguridad de la capa de transporte para la autenticación

Mediante la funcionalidad de TLS de Oracle GoldenGate para proteger las comunicaciones entre las instancias y los clientes de Oracle GoldenGate, puede hacer lo siguiente:

• Utilizar TLS para cifrar la conexión entre instancias y clientes de Oracle GoldenGate

• Autenticar cualquier cliente o cualquier otra instancia de Oracle GoldenGate en cualquier otra instancia de Oracle GoldenGate configurada para comunicarse a través de TLS.

Después de establecer TLS, la instancia de Oracle GoldenGate tendrá que autenticar el cliente para asegurarse de que tiene los privilegios correctos para enviar la pista. Se utilizan los siguientes modos de autenticación:

• La instancia de Oracle GoldenGate autenticará el cliente mediante el ID de usuario y la contraseña que tenga al menos el rol Operador en el lado de destino. El ID de usuario y la contraseña se almacenan como alias en el cliente. El alias se utiliza al crear la ruta de distribución.

  Consulte Conexión de dos despliegues mediante certificado RootCA externo para obtener más información sobre la configuración de un usuario de rol de operador y, a continuación, utilice este identificador de usuario y alias de contraseña al crear una conexión de ruta de distribución entre despliegues remotos.

• La instancia de Oracle GoldenGate utilizará el certificado de cliente para autenticar la solicitud de cliente, suponiendo que haya un usuario de certificado correspondiente creado en el lado de destino. Para conocer los pasos para crear certificados para el cliente y el servidor, consulte Creación de certificados para despliegues seguros.

• La instancia de Oracle GoldenGate autenticará el cliente mediante OAuth cuando utilice un proveedor de identificación externo (IdP), como IAM. Consulte Delegación de la gestión de usuarios a un proveedor de identidad externo.

Conjuntos de cifrado de TLS

Un conjunto de cifrado especifica un algoritmo para cada una de las siguientes tareas:

• Cambio de claves

• Cifrado masivo

• Código de autenticación de mensaje (MAC)

Se admiten los conjuntos de cifrado por defecto para TLS 1.2 y 1.3, excepto para los cifrados débiles.

Oracle recomienda encarecidamente que utilice TLS 1.3 para cumplir los requisitos de seguridad.

Se admiten los conjuntos de cifrado por defecto para TLS 1.2, excepto para los cifrados débiles.

Ruta iniciada en destino

Las rutas de acceso iniciadas por el destino para microservicios permiten al servicio receptor iniciar una ruta al servicio de distribución en el despliegue de destino y extraer archivos de pista. Esta función permite al servicio de receptor crear una ruta iniciada por el destino para entornos como rutas de zona desmilitarizada (DMZ) o de nube a locales, donde el servicio de distribución del despliegue de Oracle GoldenGate de origen no puede abrir conexiones de red en el entorno de destino al servicio de receptor debido a políticas de seguridad de red.

Si el servicio de distribución no puede iniciar conexiones con el servicio de receptor, pero el servicio de receptor puede iniciar una conexión con el host que ejecuta el servicio de distribución, el servicio de receptor establece una ruta de acceso segura o no segura iniciada por el destino al servicio de distribución mediante un firewall o una zona desmilitarizada (DMZ) que utiliza Oracle GoldenGate para extraer los archivos de pista solicitados. Los puntos finales del servicio de receptor muestran que el servicio de receptor ha iniciado la recuperación de los archivos de pista.

Se crea una ruta de acceso (solo lectura) desde el servicio de receptor del despliegue de destino y tiene la propiedad TARGET_INITIATED. También se puede acceder a esta ruta desde el servicio de distribución. La información de la ruta se almacena en el sistema de destino. Si se pierde la comunicación, el servicio de receptor del host de destino necesita la definición de ruta para reiniciar la conexión. Esta información se comparte con el servicio de distribución cuando la ruta de acceso se está ejecutando. La ruta es efímera en el despliegue de origen. Las rutas efímeras ayudan con la consolidación de la configuración de rutas y con el refuerzo de la iniciación de la conexión de destino a origen.

Cuando la ruta se detiene o se desconecta, el servicio de distribución elimina toda la información de la ruta, incluida la definición de la ruta. Sin embargo, el archivo de punto de control se conserva porque el punto de control se utiliza para decidir si las pistas antiguas se pueden depurar o no. Se recomienda que las pistas antiguas no se depuren a menos que la ruta se suprima intencionalmente.

Temas Relacionados:

• Autenticación con certificados

• Conexión de dos despliegues mediante un certificado RootCA externo

• Adición de una ruta de distribución

Soporte de proxy inverso de Oracle GoldenGate

El proxy inverso permite acceder a microservicios mediante un único puerto (443) en un despliegue. Esto permite encapsular la URL para microservicios a través de un despliegue no seguro. Nota: El proxy inverso es opcional, sin embargo, Oracle recomienda garantizar un acceso sencillo a los microservicios y proporcionar una seguridad mejorada.

Puede ejecutar microservicios en un despliegue no seguro en una dirección de bucle de retorno y delante con un proxy inverso HTTP mediante la instalación de Nginx.

Oracle GoldenGate MA incluye un script denominado ReverseProxySettings que genera un archivo de configuración solo para el servidor proxy inverso de Nginx.

Por ejemplo, el servicio de administración está disponible en http://goldengate.example.com:9001 y el servicio de distribución en http://goldengate.example.com:9002. Con el proxy inverso, a cada uno de los microservicios se puede acceder simplemente desde la única dirección. Por ejemplo, http://goldengate.example.com/distsrvr para el servicio de distribución. La URL es diferente para cada servicio y es por nombre en lugar de por puerto.

Estos valores se utilizan al conectarse al gestor de servicios y son necesarios cuando se activa la autenticación.

Consulte Configuración del proxy inverso de Oracle GoldenGate con NGINX para implementar el proxy inverso de NGINX con Oracle GoldenGate.