O Cloud Connector cria uma conexão de saída controlada da rede interna para o SAP BTP. O valor não é apenas fazer uma chamada funcionar: é impedir que uma integração amplie desnecessariamente a superfície de ataque.
1) Defina o contrato antes de expor um recurso
Documente sistema, host, porta, rota e operação necessários. “Acesso ao SAP” não é escopo: um iFlow deve depender apenas do recurso específico que utiliza, com owner técnico e de negócio.
2) Exponha apenas o mínimo necessário
O mapeamento virtual publica recursos internos selecionados para o subaccount. Evite faixas amplas, rotas curinga e acessos criados “temporariamente”. Cada exposição deve indicar qual interface a usa, qual identidade e quando foi revisada.
| Decisão | Controle mínimo |
|---|---|
| Recurso interno | Host, porta e rota específicos |
| Subaccount | Separação clara por ambiente |
| Autenticação | Conta técnica de menor privilégio |
| Mudança | Owner, evidência e rollback documentados |
3) Separe conectividade, autorização e credenciais
O Cloud Connector alcançar um recurso não significa que o CPI esteja autorizado a usá-lo. Conectividade, usuário técnico, certificados e permissões SAP são controles distintos; tratá-los como um só dificulta explicar incidentes.
4) Desenhe o diagnóstico para produção
Quando um iFlow não alcança o backend, valide na ordem: disponibilidade do conector, subaccount e região corretos, recurso virtual permitido, destination do CPI e autenticação do destino. Os logs devem manter um correlation ID sem expor dados sensíveis.
- Alerte sobre desconexões persistentes, não sobre cada tentativa falha.
- Inclua a dependência do Cloud Connector no runbook de cada interface crítica.
- Teste conectividade e permissões com uma transação representativa antes do go-live.
5) Trate mudanças de rede como mudanças de integração
Uma alteração de proxy, certificado, rota ou rede pode quebrar uma interface mesmo sem mudança no iFlow. Inclua Cloud Connector em janelas de mudança, testes de regressão e plano de rollback.
Checklist para produção
- Recurso, consumidor e owner documentados.
- Exposição restrita ao host, porta e rota necessários.
- Ambientes e credenciais separados.
- Conectividade, autorização e erros controlados testados.
- Monitoramento e runbook com escalonamento definidos.
Com essa disciplina, o Cloud Connector cumpre seu propósito: habilitar integração híbrida sem transformar conectividade em uma permissão ampla e difícil de governar.