← Blog técnico

Integración SAP

Cómo proteger endpoints de SAP CPI con SAP API Management: Spike Arrest, Quota y gobierno de APIs

SAP Cloud Integration (CPI) ejecuta la integración. SAP API Management gobierna, protege, publica y monitorea el acceso a esa integración. Si hoy expones endpoints CPI a terceros y estás recibiendo observaciones de seguridad (DAST), abuso de tráfico o falta de rate limiting, esta separación de responsabilidades es un patrón de arquitectura práctico.

2026-05-2812 minPicasso Tech and Services
SAP CPIAPI ManagementSeguridadClean Core

1. Introducción

En muchas organizaciones, los endpoints de integración en SAP CPI conectan sistemas SAP, legacy, aplicaciones externas o partners. El problema aparece cuando esos endpoints quedan expuestos sin una capa consistente de gobierno, control de tráfico, monitoreo y políticas de seguridad.

2. El problema: endpoints CPI expuestos directamente

Sistema externo
↓
Endpoint SAP CPI
↓
iFlow
↓
Backend SAP / No SAP

Cuando CPI queda como la cara pública del consumo, aparecen riesgos operativos y de seguridad:

  • Exceso de peticiones en corto tiempo (picos o ráfagas).
  • Falta de control por consumidor: no hay una identidad de aplicación estandarizada.
  • Políticas heterogéneas: cada iFlow termina “inventando” su control.
  • Mayor exposición del runtime: el iFlow se vuelve superficie directa.
  • Menor trazabilidad de consumo por aplicación/producto.
  • Observaciones DAST o findings en revisiones de seguridad.
  • Riesgo de performance/disponibilidad por abuso o mal uso.

3. El patrón recomendado: SAP API Management delante de CPI

Sistema externo
↓
SAP API Management
↓ Policies: OAuth / API Key / Spike Arrest / Quota / Access Control
↓
SAP CPI iFlow
↓
Backend

API Management actúa como una fachada gobernada. La separación de responsabilidades es simple, pero poderosa:

  • API Management protege, gobierna, limita y monitorea.
  • CPI transforma, enruta, orquesta y ejecuta la integración.

Esta división evita que cada iFlow se convierta en un mini gateway. También facilita aplicar estándares (seguridad y gobierno) sin tocar la lógica funcional.

4. Qué es un API Proxy

En SAP API Management, un API Proxy es la API expuesta hacia consumidores. El target puede ser un endpoint de un iFlow CPI, un servicio SAP, una API externa o un backend. Para este patrón, el target típico es un endpoint CPI.

Diseño recomendado: el proxy define contrato y políticas, mientras CPI se concentra en orquestación y transformación.

5. Policies clave para proteger una API

Estas policies suelen aparecer cuando un endpoint CPI empieza a ser consumido por terceros, integraciones B2B o múltiples aplicaciones internas:

Policy Propósito Ejemplo de uso
Spike Arrest Limitar ráfagas/picos de tráfico Evitar golpes súbitos que degradan el runtime CPI
Quota Limitar consumo acumulado por periodo Cap por día/mes por aplicación o producto
Verify API Key Identificar aplicaciones consumidoras Requerir API key por app registrada
OAuth v2.0 / Verify Access Token Validar tokens OAuth Acceso basado en scopes y cliente OAuth
Verify JWT Validar tokens JWT Validación de firma/claims antes de CPI
Access Control Permitir/bloquear IPs o rangos Restringir integraciones B2B a IPs conocidas
XML Threat Protection Mitigar amenazas comunes en XML Proteger APIs SOAP/XML/iDocs ante payloads maliciosos
Message Validation Validar estructura del mensaje Rechazar requests fuera de contrato antes de CPI
Assign Message Modificar headers/parámetros/payload Normalizar headers, remover información no permitida
Service Callout Llamar servicios externos desde el proxy Validadores, token endpoints, lookups controlados

6. Diferencia entre Spike Arrest y Quota

Spike Arrest controla picos o ráfagas. Quota limita consumo total en un periodo. Ambas se complementan:

  • Con Spike Arrest en 30 requests/min, evitas que un consumidor mande miles de llamadas en segundos.
  • Con Quota en 3,000 requests/día, reduces abuso acumulado durante el día.

7. Ejemplo técnico de Spike Arrest

<SpikeArrest async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Rate>30pm</Rate>
    <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

30pm significa 30 peticiones por minuto. Una recomendación práctica: evita depender de headers enviados por el cliente para identificar al consumidor (Identifier) o para asignar peso (MessageWeight) si no están previamente validados; pueden manipularse.

Si necesitas identificar por cliente, usa un valor confiable: una aplicación registrada (API key), OAuth client id, o consumer id controlado por tu plataforma.

8. ¿Cómo ayuda API Management frente a observaciones DAST?

Una herramienta DAST suele reportar hallazgos de “exposición” y “abuso potencial” cuando detecta endpoints sin control. API Management ayuda a mitigar, de forma estructurada, hallazgos relacionados con:

  • Falta de rate limiting.
  • Exceso de requests.
  • Ausencia de control por consumidor.
  • Endpoint expuesto directamente.
  • Falta de monitoreo/analítica de consumo.
  • Validación insuficiente de tráfico entrante.
  • Riesgo de payloads maliciosos.
  • Falta de gobierno de APIs.

Aclaración importante: API Management no reemplaza las validaciones internas del iFlow. CPI debe seguir validando estructura, reglas funcionales, manejo seguro de logs y errores de negocio. La arquitectura madura combina protección perimetral en API Management y validación funcional dentro de CPI.

9. Relación con Clean Core

Este patrón está alineado con Clean Core porque:

  • Evita acoplamientos directos innecesarios hacia CPI.
  • Agrega una capa externa de gobierno sin modificar el core.
  • Mantiene integraciones desacopladas y evolutivas.
  • Facilita monitoreo, observabilidad y operación.
  • Permite políticas homogéneas sin “copiar/pegar seguridad” en cada iFlow.
  • Favorece una estrategia API-first con contratos estables.

10. Buenas prácticas recomendadas

  • No exponer endpoints CPI directamente cuando hay consumidores externos críticos.
  • Publicar APIs a través de API Management.
  • Usar OAuth, JWT o API Key según el nivel de seguridad requerido.
  • Configurar Spike Arrest para ráfagas.
  • Configurar Quota para consumo acumulado.
  • Agregar Access Control cuando aplique.
  • Usar XML Threat Protection si se reciben XML/iDocs/SOAP.
  • Mantener monitoreo y analítica habilitados.
  • Documentar consumers, productos y políticas.
  • Separar seguridad/gobierno de la lógica funcional del iFlow.
  • Validar internamente el payload en CPI.

11. Conclusión

SAP API Management no sustituye a SAP CPI; lo complementa. Cuando se combinan correctamente, CPI e API Management permiten exponer integraciones de forma más segura, gobernada y escalable. Este enfoque ayuda a responder auditorías, pruebas DAST y necesidades de operación empresarial, mejorando trazabilidad, control y resiliencia.

12. Si esto te suena familiar

En Picasso Tech and Services ayudamos a las empresas a diseñar, proteger y modernizar sus integraciones SAP mediante SAP Integration Suite, SAP CPI y SAP API Management, combinando arquitectura, seguridad y automatización para construir soluciones robustas y preparadas para crecimiento.

¿Tu empresa necesita proteger endpoints SAP CPI o modernizar su arquitectura de integración?

Hablemos.

Contactar a Picasso Tech and Services