Seguridad de conexiones en Oracle Integration 3: identidad, confianza TLS y red

Una conexión de Oracle Integration puede alcanzar el servidor y aun así carecer de permisos para la operación. Puede tener credenciales correctas y fallar porque el certificado del destino no es de confianza, o porque el agente no alcanza el servicio de identidad. Son tres causas distintas, y cada una se corrige en un lugar diferente.

Este artículo separa esas condiciones (dirección de la llamada, autenticación, confianza TLS y conectividad del agente) y propone un registro por conexión que permite revisarlas y renovarlas sin depender de una sola persona. El alcance es Oracle Integration 3.

Dirección de la llamada y responsables

El punto de partida es un inventario con aplicación de origen, destino, operación y dirección de cada llamada. En el REST Adapter, una conexión trigger recibe solicitudes que inician una integración y una conexión invoke llama a un servicio externo; sus configuraciones de seguridad no son intercambiables. La documentación de conexiones por rol describe esa separación y aclara que la configuración del agente no corresponde al rol trigger.

Una integración que recibe una solicitud y luego escribe en otro sistema contiene dos relaciones de confianza, que se aprueban por separado. Una identidad válida para entrar a OIC no justifica, por sí misma, acceso administrativo en el destino de la llamada posterior.

Recomendamos asignar a cada conexión un propietario operativo, además del desarrollador que la creó. Ese responsable conoce qué integraciones la usan y qué cambios requieren coordinación con el equipo del sistema externo. Incluir el ambiente en el nombre de la conexión reduce el riesgo de alterar producción durante una revisión de permisos.

Políticas de autenticación por tipo de acceso

La política debe ser compatible con el adaptador y con el servicio consumido. Para un proceso que actúa con identidad propia, OAuth Client Credentials es adecuado si el proveedor lo admite; una llamada en nombre de una persona requiere el flujo correspondiente. Oracle describe los patrones OAuth del REST Adapter y remite a la documentación del proveedor para elegir.

El registro de la aplicación OAuth debe ser independiente de la cuenta de cualquier persona, y los alcances autorizados deben quedar documentados por el propietario del destino. Usar una cuenta administrativa para superar una prueba de conexión crea una excepción que luego heredan todas las integraciones que reutilizan esa conexión.

Si el destino sólo admite autenticación básica, corresponde una cuenta técnica con permisos delimitados, HTTPS y una política explícita de cambio de contraseña. Hay un matiz documentado: en REST, probar una conexión invoke con autenticación básica no valida las credenciales. La guía de creación de conexiones indica que la validación requiere invocar una API idempotente.

Confianza e identidad en TLS

Conviene distinguir dos objetos. Un certificado de confianza permite validar al servidor externo; un certificado de identidad permite al cliente identificarse cuando el destino exige autenticación mutua (mTLS). Para el REST Adapter, Oracle separa la carga de certificados públicos para SSL unidireccional de la carga de un almacén JKS con clave privada para SSL bidireccional, según la guía de certificados para servicios externos.

Ambos objetos no tienen el mismo nivel de sensibilidad. La clave privada y las contraseñas del almacén requieren acceso restringido, y cada conexión debe tener registrado el alias que usa. La cadena de certificados se solicita al administrador del destino, junto con su procedimiento de renovación; un archivo de origen no identificado no debería instalarse.

También debe precisarse en qué tramo se valida el certificado. La conexión entre el agente y Oracle Integration es distinta de la conexión entre el agente y una aplicación interna. Para agregar confianza en el host del agente, Oracle documenta la importación en su almacén y el reinicio posterior en Install a Certificate on the Agent Host.

Cuando el REST Adapter accede por agente a un endpoint con mTLS, aplica un procedimiento específico de autenticación mutua: la identidad se configura en el host del agente y la conexión activa SSL bidireccional. La configuración de alias de una conexión directa no es trasladable, porque Oracle indica que ese campo no está soportado en este escenario.

Connectivity Agent: superficie y operación

El Connectivity Agent inicia la comunicación con Oracle Integration mediante solicitudes salientes y consulta el trabajo pendiente; no requiere puertos de entrada en el sistema local, según la descripción oficial del agente. El host, en cambio, sí necesita salida hacia los servicios de OIC y alcance hacia las aplicaciones internas autorizadas.

Oracle Integration 3 autentica el agente con OAuth 2.0, a diferencia de la autenticación básica que admitía Generation 2. En consecuencia, las reglas de salida deben incluir el servicio de identidad además del servicio de integración. En una migración, una regla que funcionaba con el agente anterior no garantiza conectividad con el nuevo.

El agente debe instalarse con privilegios mínimos y con acceso restringido a su directorio. El archivo preconfigurado InstallerProfile.cfg contiene parámetros OAuth, incluidos el identificador y el secreto del cliente, y debe tratarse como material sensible. La guía de instalación explica su asociación con el grupo y exige eliminar la clave de instalación al terminar.

La operación del host también requiere responsables: actualizaciones, supervisión del proceso, acceso a diagnósticos y, cuando corresponde, configuración de proxy. La disponibilidad del agente depende de un entorno administrado por la organización, no por el proveedor de OIC, y así debe reflejarse en el modelo de soporte.

Gobierno de credenciales y renovaciones

Los secretos pertenecen a los campos de seguridad del adaptador y no deben repetirse en mapeos, ejemplos o notas de soporte. Para flujos OAuth personalizados, el REST Adapter ofrece parámetros vinculados a campos de seguridad ofuscados, en lugar de valores literales en las solicitudes. Las capturas usadas en soporte requieren la misma revisión.

Una renovación es un cambio operativo con dependencias conocidas. La secuencia recomendada es identificar las integraciones afectadas, obtener la nueva credencial por el canal autorizado, probarla con permisos equivalentes en un ambiente controlado, confirmar la ejecución real después del cambio y retirar la credencial anterior según las condiciones del proveedor.

El inventario de certificados registra vencimiento, emisor, alias y responsable de la renovación; el de clientes OAuth agrega el administrador del registro y el procedimiento de revocación. Ninguno de los dos contiene el secreto: su función es localizar y gobernar la credencial, no duplicarla.

Verificación previa a la activación

La prueba debe recorrer el camino completo y permitir distinguir fallas de red, de confianza y de autorización. Incluye una operación permitida y una comprobación negativa: la identidad no debe obtener acceso fuera de su función. La evidencia se conserva sin contraseñas, tokens ni datos de negocio innecesarios.

• Rol de la conexión (trigger o invoke) y propietario de cada endpoint confirmados.
• Política del adaptador validada para el tipo de acceso elegido.
• Confianza TLS revisada en el componente que ejecuta la llamada.
• Salidas del agente hacia OIC y hacia el servicio de identidad comprobadas.
• Operación segura ejecutada para confirmar credenciales y permisos.
• Responsables y procedimiento de renovación registrados antes de activar.

Xterra Engine realiza revisiones de seguridad de conexiones en Oracle Integration a partir de este inventario, conexión por conexión.