SAP Cloud Platform Integration (Cloud Integration) allows quite some flexibility when developing integration flows which are executed on runtime nodes of Cloud Integration. This includes for example:
- Modifying messages
- Connecting to external systems
- Encrypting/decrypting messages
- Executing custom scripts
- Developing custom adapters
These tasks are part of the daily work of an integration developer.
While this flexibility is desirable to solve complex integration problems, it comes with the drawback that such functions could also be (accidentally or maliciously) misused by a developer. For example:
- Send decrypted messages to a compromised server (which may be under control of an attacker)
- Access credentials of the tenant
- Crash the runtime node via misbehaving scripts
This is a generic conflict between flexibility and security and it is near impossible for the integration runtime to distinguish between intended valid usages and mis-usages. So, how do we solve this conflict?
- SAP Cloud Platform Integration does its best to isolate tenants from each other. This is protecting different customers of Cloud Integration as well as different tenants (e.g. test vs productive) of the same customer.
- Each tenant can configure it’s own user/role assignments thus controlling the access.
- Integration flows are executed on tenant isolated VMs. I.e. a malicious integration flow can only access data from or impact its own tenant where the integration flow was deployed. Strong sandboxing (see https://blogs.sap.com/2018/02/09/java-sandboxing-at-sap-cp-neo-environment/) isolates his VM from other VMs.
- SAP Cloud Platform Integration protects secrets (like passwords or private keys) from external access
- Secrets are stored encrypted
- Secrets are not visible in UI nor downloadable
- Secrets are not exposed via external APIs
But note that during runtime an integration flow needs to access these secrets, so internal access from the integration flow is possible.
- The tenant owner is responsible for deciding which content (e.g. integration flows or custom adapters) he or she is deploying in the tenant. Be aware that this content can have internal access to your tenant and you should only deploy trusted content.
- The integration developer (and anybody with deploy permissions) is a very powerful persona.
- Think about the actual security requirements of your tenants and be aware of the potential risks.
- Be careful who you grant deployment permissions on your productive systems.
- Consider having reviews of CPI content before it is deployed. Be especially aware of scripts as these have very powerful capabilities.
- Don’t deploy content from untrusted sources.
- Don’t share the same secret credentials between between tenants with different security levels (e.g. test tenant & productive tenant).
- Prefer client certificate based authentication over basic authentication (In this case the private key stays in the sender system and no secret password is transmitted via network).
- Documentation “Identity and Access Management” > section “Authorization for the Integration Developer”
Integration flows offer great flexibility to integration developers which could also be misused. While SAP Cloud Platform Integration ensures strict security between different tenants, the tenant owner is responsible for security inside his own tenant and should be aware of potential risks and how to mitigate them.