Understanding Security of Integration Flow Development
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.
With the timing of this post, would I be right to assume that this is SAP's official response to the issue highlighted by Ariel M. Bravo Ayala in the below post?
Hi Eng Swee,
It might not be the case, but it feels like it is. Also, this confirms that in a development CPI account, there isn't even a single secure credential. Worrisome.
As I´ve mentioned, I've found that it is possible to capture the credentials of an individual consuming a CPI endpoint.
Regarding credentials that are stored in CPI's so-called "secure store", to be honest I'm not too worried about it. As I mentioned in my comment on your post, from my experience in various organisations, someone with developer access to the PI/CPI system would already have a very high likelihood to know those credentials via other means. Those that need to worry would be the CPI developers storing their personal Gmail credentials (like you pointed out), if they use CPI to play around.
As to your other concern about sniffing the details of users consuming a CPI endpoint (I'll try to verify this), that might indeed be a little more worrisome, but only just a little. In the past with PI, a PI developer would already know the credentials of a PI system user since they have to provide it to an external system who wants to consume a PI endpoint. It's just that now, CPI's identity management is based on SAP Cloud Identity Management, so it is possible that an external system registers their own user directly on SAP Cloud without the CPI developer knowing those credentials. But I feel to be able to extract such details for production systems would require quite a coordinated effort - a CPI developer would need to deploy malicious code on the specific integration flows on the production tenant. Not to say that the risk is not there, but not sure what's the likelihood of it happening. And what would a CPI developer gain with those credentials, if he/she already has more powerful access to deploy such malicious code?
Anyway, to mitigate this, we have been enforcing certificate-based authentication for external systems consuming our CPI endpoints - this eliminates the requirement to have a P/S-user (and their credentials).
Headers… it is allways a header…
To my eyes, the problem is not even thinking about productive environments. Reason being, is that the SUser is going to be likely registered in multiple SAP services (including productive environments). If a scatterbrained by any means hits/test an endpoint in CPI (link, redirections, own will?) in, lets say a development environment, his password can be compromissed. Sure, this is the case of any sort of phishing but in this particular case, you would be calling an “inoffensive” iFlow in your own tenant.
The way to go. I have not followed the updates in this regard, Is it the case that it is not yet possible to use self-signed certificates? The cost and bureocracy of getting a new one is a barrier for development systems. You can still use the provided by SAP, but I dislike the idea of one cert to all, or am I missing somehting?
Hi Eng Swee,
Did you allowed "the" header in the runtime configuration of the iFlow? At least two weeks ago I tested and worked. Who knows, maybe it is just a "feature" for pseudo principal-propagation 😉
Regarding the other two points, I agree with the S-User approach you´ve proposed. I guess that the customer i've been working on they are not that mature yet in these regards. it would be really nice for SAP to provide a way to sign some certificates as C4C does.
Yes, "Runtime Configuration" did it! Thanks for the tip. I rarely use that section so totally missed it out. And you are right, the header containing the basic authentication details are accessible.
I agree this is a potential security loophole, and it is something that SAP could (and should) fix!
Gayathri Narayana , is this something that you can help to feedback to the development team?
I'm not familiar with the C4C signing functionality, but if you look at it from a vendor-agnostic perspective - wouldn't it be better that the public certificate of a sender system be independent (by using independent CA for signing) of which receiver system it is connecting to? It is quite common for a sender system to use the same certificate for connecting to multiple systems.