Como proteger endpoints do SAP CPI com SAP API Management: Spike Arrest, Quota e governança de APIs

1. Introdução

Em muitas organizações, endpoints de integração no SAP CPI conectam sistemas SAP, legados, aplicações externas ou partners. O problema começa quando esses endpoints ficam expostos sem uma camada consistente de governança, controle de tráfego, monitoramento e políticas de segurança.

2. O problema: endpoints do CPI expostos diretamente

Sistema externo
↓
Endpoint SAP CPI
↓
iFlow
↓
Backend SAP / Não SAP

Quando o CPI vira a face pública do consumo, aparecem riscos operacionais e de segurança:

• Picos de tráfego que degradam disponibilidade.
• Sem identidade do consumidor: difícil segmentar/limitar por aplicação.
• Controles inconsistentes entre iFlows.
• Maior exposição do runtime: o iFlow vira superfície direta.
• Menor rastreabilidade por produto/aplicação.
• Achados DAST e observações de segurança.
• Risco de performance/disponibilidade sob abuso.

3. Padrão recomendado: SAP API Management na frente do CPI

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

O API Management atua como fachada governada. As responsabilidades ficam claras:

• API Management protege, governa, limita e monitora.
• CPI transforma, roteia, orquestra e executa a integração.

4. O que é um API Proxy

No SAP API Management, um API Proxy é a API publicada para consumidores. O target pode ser um endpoint de iFlow do CPI, um serviço SAP, uma API externa ou um backend. Neste padrão, o target típico é um endpoint do CPI.

5. Policies-chave para proteger uma API

Policy	Propósito	Exemplo de uso
Spike Arrest	Limitar rajadas/picos	Proteger o runtime do CPI contra “burst traffic”
Quota	Limitar consumo total por período	Cap diário/mensal por app ou produto
Verify API Key	Identificar apps consumidoras	Exigir API key por aplicação registrada
OAuth v2.0 / Verify Access Token	Validar tokens OAuth	Acesso baseado em scopes e clientes
Verify JWT	Validar tokens JWT	Validar assinatura/claims antes do CPI
Access Control	Permitir/bloquear IPs e ranges	Restringir B2B a IPs conhecidas
XML Threat Protection	Mitigar ameaças comuns em XML	Endpoints SOAP/XML/iDocs com limites seguros
Message Validation	Validar estrutura da mensagem	Rejeitar payload fora de contrato antes do CPI
Assign Message	Modificar headers/params/payload	Normalizar headers e remover campos não permitidos
Service Callout	Chamar serviços externos	Token endpoints ou validadores controlados

6. Diferença entre Spike Arrest e Quota

Spike Arrest controla picos/rajadas. Quota limita consumo total em um período. São complementares:

• Spike Arrest em 30 requests/min evita “milhares em segundos”.
• Quota em 3.000 requests/dia limita abuso acumulado.

7. Exemplo 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 requisições por minuto. Evite depender de headers enviados pelo cliente para identificadores ou peso da mensagem sem validação prévia: o cliente pode manipular. Para identificar por consumidor, use um valor confiável: app registrada (API key), OAuth client id, ou consumer id gerenciado.

8. Como o API Management ajuda frente a achados de DAST?

Ferramentas DAST frequentemente apontam exposição e falta de controles. O API Management ajuda a mitigar achados relacionados a:

• Ausência de rate limiting.
• Excesso de requests.
• Falta de controle por consumidor.
• Endpoint exposto diretamente.
• Falta de monitoramento/analítica.
• Validação insuficiente de tráfego entrante.
• Risco de payloads maliciosos.
• Falta de governança de APIs.

Importante: API Management não substitui validações funcionais dentro do iFlow. O CPI deve continuar validando payload/contrato, regras de negócio, logs seguros e tratamento de erros. A arquitetura madura combina proteção perimetral no API Management e validação funcional no CPI.

9. Relação com Clean Core

Esse padrão se alinha a Clean Core porque:

• Evita acoplamento direto desnecessário ao CPI.
• Adiciona camada de governança sem alterar o core.
• Mantém integrações desacopladas e evolutivas.
• Facilita monitoramento e operação.
• Permite policies homogêneas sem duplicar lógica em cada iFlow.
• Suporta estratégia API-first com contratos estáveis.

10. Boas práticas recomendadas

• Não expor endpoints do CPI diretamente para consumidores externos críticos.
• Publicar APIs via API Management.
• Usar OAuth, JWT ou API Key conforme o nível de segurança requerido.
• Configurar Spike Arrest para rajadas.
• Configurar Quota para consumo acumulado.
• Adicionar Access Control quando aplicável.
• Usar XML Threat Protection para XML/iDocs/SOAP.
• Manter monitoramento e analítica habilitados.
• Documentar consumers, produtos e policies.
• Separar segurança/governança da lógica funcional do iFlow.
• Validar internamente o payload no CPI.

11. Conclusão

SAP API Management não substitui SAP CPI; complementa. Quando bem combinados, CPI e API Management permitem expor integrações de forma mais segura, governada e escalável, ajudando a responder auditorias, testes DAST e necessidades operacionais com melhor rastreabilidade, controle e resiliência.

12. Se isso soa familiar

Na Picasso Tech and Services ajudamos empresas a desenhar, proteger e modernizar integrações SAP com SAP Integration Suite, SAP CPI e SAP API Management, combinando arquitetura, segurança e automação para construir soluções robustas e prontas para crescimento.