Oracle Integration Cloud OIC: Security
Security is Primo to any service on Cloud. Every company will explore the different ways to provide security to their applications & databases on cloud.
In this blog we will see the different points and ways of providing security to OIC (Oracle Integration Cloud) i.e.,
1. Instance Access
Accessing an OIC Instance provisioned is the first step.
Access to Instance: This is nothing but how companies can decide on whether their OIC Instance should be accessible via Public Internet or only from a specific Network. This can be achieved using Network Access on the OIC Instance as shown below.
RBAC (Role Based Access Control): This is nothing but providing access to users based on their roles i.e.,
For tenancies with Identity Domains follow the below snippet to give access
The above snippets explain how to provide access to OIC Instance access & Role based access for a specific user.
Now, users can access & login to the OIC Instance based on the roles assigned to them.
2. Third Party Invocation
Now let us see how to provide security when external applications invoke the OIC Integration.
Securing Integration endpoint: Let us say we have built an integration which is to be invoked by external applications. Your Integration endpoint comprises of
If you do not want to expose your OIC Instance Name or Namespace. Then you can try one of the two possible solutions i.e.,
a. Custom OIC Endpoint — i.e., building an OIC endpoint with a domain name of customer’s choice. Creating and using custom endpoint is explained here.
b. OCI APIGW — i.e., keeping your OIC Integration endpoint as backend to OCI APIGW. This is explained here.
3. Invocation Channel
By default OIC instance is provisioned on Public cloud i.e., anyone who invokes an Integration in OIC the traffic comes via Public Internet.
Inbound to OIC
Securing Invocation Channel: Let us say we want to restrict the traffic to OIC and don’t want it to happen directly over Public Internet.
You can restrict that using the above architecture i.e., by following the below steps:
- Incoming traffic will be analyzed by WAF & Firewall.
- Analyzed traffic reaches Load Balancer whose backend will be Private API Gateway.
- Private API Gateway will have OIC as backend. APIGW allows traffic only from Load Balancer.
- Allowed List/Network Access on OIC as shown above will have APIGW IP only.
Outbound to OIC
Securing Invocation Channel: Let us say we want to restrict the outbound traffic to OIC and don’t want it to happen directly over Public Internet.
OIC Connectivity Agent: The suggested approach till the time I am writing this blog is to use OIC Agent which is explained here (follow this link to know how to configure OIC3 Agent).
4. Authentication
Every Integration created in OIC Instance need to be authenticated to Invoke.
a. Basic Auth: the ideal approach is to create a Service Account for external parties.
b. OAuth: this can be used if you want external parties to do token-based authentication. Follow this link to create OAuth for REST API calls.
c. 2-Way SSL: this is a must for most of the customers where client & server verifies their identity before exchange of data. This video explains the 2-way SSL concept easily. OIC supports 2-Way SSL for Outbound communications where OIC is the client (2-Way SSL is not supported if you are using OIC Agent). For Inbound as OIC is the server. So, it doesn’t support 2-Way SSL for inbound. If you want 2-Way SSL for Inbound to OIC then you need to use it with a combination of OCI APIGW i.e., by having OCI APIGW as frontend to OIC Integrations. This documentation of Oracle explains on how to achieve 2-Way SSL with OIC (Inbound/Outbound).
You can also use OAuth in combination with APIGW where you can add one more layer of Authentication on APIGW i.e., via JWT and that is clearly explained here.
5. Data
Encryption: most of the customers or their security teams ask for data encryption.
a. Incoming Data: Encryption of data interfacing to OIC is client’s responsibility and if any transformations are required on data and decryption required then private key is to be shared by client.
b. Staging Data: Once the data is interfaced in OIC, it can be encrypted using PGP encryption where we store the keys in OCI Vault to use them for encryption. In OIC we can encrypt data at data field level and file level.
c. Outgoing Data: Data outbound to OIC can be encrypted using PGP encryption which end user will be decrypting using the private key.
Also, the data saved in the OIC Instance via Activity Streams will pertain to the instance and it will be within customer’s control only.
This concludes the security aspect of Integrations & OIC in general. But we have an embedded SFTP server of 500GB for free with every OIC instance. So, let us see how to secure that.
OIC SFTP
Now if your customer wants to access OIC SFTP server to use it as any other SFTP server. Then they would ideally not come through OIC Integration invocation rather they will access the SFTP server directly.
a. Access: The SFTP access can be given per user where each user has a specific folder/directory created and others won’t have access.
b. Authentication: Users can login to the OIC SFTP server using Basic Auth or SSH when trying to access it as an SFTP client. If you want to access via REST Client you can use OAuth additionally as explained here.
c. Invocation Channel: Restriction access via Access Control List or Network Access done on OIC Instance won’t be applicable for OIC SFTP. You can still restrict it by keeping OIC SFTP as backend to OCI Load Balancer and restrict traffic on OCI Load Balancer Allowed List as explained here (when trying to access it as SFTP Client). If you want access it as REST Client you can follow the method of APIGW as explained above for normal Integrations.
!!Happy Reading!!
