← Blog técnico

SAP CPI security governance

SAP CPI: certificados, secretos y ownership de endpoints sin deuda operativa

Muchas incidencias en SAP Integration Suite no empiezan en el payload. Empiezan cuando expira un certificado que nadie vigila, cuando un endpoint cambió fuera del proceso o cuando nadie puede decir quién es dueño real de una credencial en producción.

SAP CPIIntegration SuiteSecurityGovernance

Si una integración depende de certificados, secretos y endpoints, entonces depende también de un modelo de gobierno mínimo. Sin ese modelo, el paisaje parece estable hasta que llega una renovación, un cambio de DNS, una rotación de credenciales o un incidente que obliga a reconstruir decisiones que nunca se documentaron.

1) El inventario mínimo no es “todos los iFlows”: es qué conecta, con qué y bajo qué dueño

Antes de hablar de herramientas, define el inventario operativo por integración:

  • Endpoint: URL, ambiente, sistema dueño y criticidad.
  • Método de autenticación: certificado cliente, basic auth, OAuth, API key o combinación.
  • Artefacto sensible: alias de certificado, credential artifact, keystore entry o parámetro externalizado.
  • Owner: qué equipo aprueba cambios, qué equipo rota credenciales y qué equipo responde incidentes.

La señal de riesgo no es “hay muchas integraciones”. La señal de riesgo es que nadie puede responder esto sin abrir el tenant a mano.

2) Separa ownership técnico de ownership funcional

Un problema frecuente en middleware SAP es mezclar ownership:

  • El negocio es dueño del proceso, pero no del certificado.
  • El partner despliega el iFlow, pero no controla la renovación del endpoint externo.
  • Infraestructura o seguridad emite credenciales, pero no siempre conoce el impacto del cambio.
Regla práctica: por cada endpoint productivo debe existir un owner para el servicio, otro para la credencial y un runbook que explique cómo se coordinan. Si todo depende del “equipo de integración”, el modelo ya es frágil.

3) Externaliza secretos y evita que el repositorio se convierta en inventario sensible

Cuando un endpoint real o una credencial termina embebida en un iFlow o en un ajuste manual de PROD, aparecen dos problemas: drift entre ambientes y dependencia de memoria operativa.

La práctica mínima es:

  • Configurar por ambiente endpoints, aliases y credenciales externas.
  • Nombrar de forma consistente los artefactos sensibles para que DEV, QA y PROD sean comparables.
  • Evitar secretos en documentación operativa; documenta alias, owners y ubicación, no valores.

Esto no vuelve mágico el transporte entre tenants. Solo reduce cambios manuales opacos y hace más defendible el soporte.

4) Certificados: el problema no es la fecha de expiración, es la ausencia de proceso

Un certificado vencido suele ser el síntoma. El problema real es no tener un ciclo explícito:

  1. Inventariar certificados por integración y ambiente.
  2. Monitorear expiración con margen operativo suficiente para renovar sin urgencia.
  3. Probar la cadena y el endpoint renovado fuera de producción.
  4. Registrar qué cambió, cuándo, quién lo aprobó y qué validación quedó como evidencia.

Si el equipo solo se entera cuando falla el handshake, el problema ya no es seguridad: es gobernanza operativa.

5) Tabla mínima de control para soportar cambios sin arqueología

ElementoEvidencia mínima
Endpoint productivoOwner, ambiente, criticidad, ventana de cambio y URL documentada
Credencial o certificadoAlias, método de autenticación, owner de rotación y fecha objetivo de revisión
Cambio recienteTicket o release, responsable y validación posterior al cambio
IncidenteCorrelation ID o evidencia equivalente + runbook de diagnóstico

6) Qué revisar cuando heredas un tenant SAP CPI / Integration Suite

En tenants heredados, una revisión rápida suele encontrar cuatro riesgos repetidos:

  • Aliases huérfanos: nadie sabe si un certificado sigue activo o qué interfaz depende de él.
  • Endpoints mezclados: DEV y PROD difieren sin evidencia clara del porqué.
  • Rotaciones no trazables: hubo cambios, pero no existe cadena de decisión.
  • Dependencia de una persona: solo alguien “que conoce el tenant” sabe dónde tocar.

Ese tipo de revisión no reemplaza SAP ALM, SAP Transport Management ni monitoreo runtime. Es gobierno de middleware para reducir riesgo operativo dentro de su alcance real.

Checklist corto para partners SAP

  • Cada integración crítica tiene endpoint documentado, método de autenticación y owner identificable.
  • Los secretos están externalizados y sus aliases siguen una convención consistente por ambiente.
  • Las renovaciones de certificados dejan evidencia y prueba posterior al cambio.
  • Soporte puede responder “qué cambió” sin depender de memoria oral ni acceso improvisado a producción.

¿Quieres ordenar esto antes de que llegue el próximo incidente?

En el Picasso CPI Governance Assessment revisamos evidencia mínima, ownership, artefactos sensibles y riesgos de drift para que el tenant sea operable sin prometer herramientas que no reemplaza.

Hablar con un arquitecto