Choosing a Trust Profile for Hosting Sensitive Workloads on IBM Cloud

5 min read

As financial companies migrate workloads to the cloud, additional considerations come into play when considering the most sensitive workloads.

Moving to cloud has many benefits in terms of efficiency and cost reduction, but the move can also increase data security because Communication Service Providers (CSPs) can often deliver more secure environments than in-house I.T. teams due to economy of scales. Most large banks now have some policies on moving to a number of different cloud providers to suit different needs.

For sensitive workloads (e.g., payment systems), CISO’s perceptions may be that on-premises will provide more isolation and protection. They also have to consider consequences for meeting applicable regulations. The risk profile of these workloads is increased due to the increase in impact relative to other workloads.

Risk profile and technical assurance

Security controls assurance means that you rely on policy, process and controls definition (and their execution) to help mitigate any risks. Technical assurance means that you rely on hardware or software to mitigate risks.

A basic example of this could be how patching is performed. Security controls assurance would mean that there is a well-defined and monitored process that requires vulnerabilities to be patched within specific time frames. Technical assurance, in contrast, would ensure that no vulnerable library can be deployed after the time frame specified by the policy.

A combination of controls assurance and technical assurance can ensure the risk profile of workloads are acceptable both by the enterprise CISO and external certification or regulatory bodies.

Looking more closely at risk challenges

Certain workloads do have a different risk profile based on the sensitivity of the data involved. Some typical risks that CISOs often consider in relation to cloud are as follows:

  • Can cloud meet strict regulatory needs related to these types of workloads?
  • Does the multi-tenant nature of cloud mean that a breach in one service impacts sensitive workloads?
  • By what means is data leakage prevented and visible through lineage?
  • Is there increased risk associated with cloud admins who may have access to data?
  • Will there be issues with location of data and impact on legal regulations?

How IBM Cloud helps meet these challenges

IBM Cloud for Financial Services controls align with many of the regulations applicable to financial workloads. Financial Services (FS) validation of controls ensures clients have reduced cost in validating the security and risk with cloud, and it provides an ecosystem of ISVs that can be incorporated into a financial institution’s architecture that also comply with those controls. The FS Cloud reference architecture provides a secure landing that is designed to meet the risk profile of financial institutions.

Focusing on the typical needs for clients developing financial and payment systems, IBM Cloud provides a number of technical assurance capabilities in terms of isolation and data encryption.

IBM Cloud isolation capabilities

The following are some specific threats typically considered in relation to isolation of sensitive workloads on cloud:

  • Can any external attacker reach any endpoints other than secure authenticated ones?
  • Can workloads be reached by any other client or unapproved connection deployed in the same multi-tenant cloud?
  • Can availability or reliability of workloads be impacted by any other client?

Deployment on Red Hat Openshift on IBM Cloud with VPC provides the necessary isolation building blocks to protect against these threats:

Deployment on Red Hat Openshift on IBM Cloud with VPC provides the necessary isolation building blocks to protect against these threats:

The architecture above shows how VPCs can be configured in dedicated cloud accounts with dedicated hypervisors. These can be used to host sensitive workloads to achieve the necessary isolation and eliminate potential attacks from lateral movement. Some regulations require physical isolation to protect specifically against VM escapes, and this configuration will satisfy those requirements. A shared hypervisor can be used for less sensitive workloads, if the risk profile allows, in order to reduce costs and administration.

To summarise, this configuration reduces the risk of network vulnerabilities through misconfigured network policies, ensures no VM escape threats can be exploited and may assist in discussions with regulators on validating isolation of these workloads. Other workloads can be hosted in shared VPC to manage costs and administration overhead.

Many additional capabilities are available to further segment and isolate traffic, including VPC-level constructs like security groups and ACLs or Kubernetes constructs like network policies and namespaces. See the IBM Cloud docs for more details.

Data encryption and isolation capabilities

In addition to the isolation of workloads, sensitive financial systems may also require technical assurance on data encryption and isolation linked to those workloads. The architecture below depicts connecting to those backend IBM Cloud Databases (ICD) over a virtual private endpoint (VPE) to ensure no risk from man-in-the-middle attacks:

The architecture below depicts connecting to those backend IBM Cloud Databases (ICD) over a virtual private endpoint (VPE) to ensure no risk from man-in-the-middle attacks:

The IBM Cloud plan allows one to assign dedicated compute for database runtimes. Volume-level encryption with customer-owned encryption keys is supported, preventing any access to the data at rest with those customer-owned keys (see IBM Cloud BYOK and KYOK).

Where physical isolation is not enforced via a dedicated hypervisor, financial regulations are satisfied by encryption of data before it is written to the storage medium (i.e., via application-level encryption). The approach partitions the data and protects it from access by another other party, including IBM.

Application-level encryption can be applied in various ways beyond embedding the logic into the application. IBM Cloud offers the following options:

  • Some database runtimes like MongoDB natively support client-side encryption, which is supported in IBM Cloud Databases v4.2. 
  • Specialized client-side encryption proxies like Baffle Shield can be configured. This guide shows how to configure Baffle with IBM Cloud Hyperprotect DBaaS or IBM Cloud Databases.

IP-based allow listings on database runtimes allow for restricting network-level access to the VPC of the workload.

Other isolation capabilities

In contrast to IBM Cloud Databases, which primarily rely on process assurance for privileged access to customer data, IBM Cloud Hyper Protect DBaaS is an alternative that has a different risk profile and offers technical assurance for access to customer data by privileged users. LinuxONE technology provides built-in data encryption with excellent vertical scalability and performance for sensitive workloads.

Wherever IAM-based access is used, IAM Trusted Profiles should be used to manage access control between Cloud Services to eliminate the need to manage and rotate API keys.

IBM Cloud also provides capabilities to bring your own encryption keys to the cloud to provide additional assurance that IBM admins have no access to the data at rest. See IBM Cloud BYOK and KYOK docs for managing your own encryption keys.

Conclusion

Moving to cloud is a priority for many enterprises (including financial institutions) considering the skills shortage in IT and cybersecurity and the benefits of economies of scale to be had in cloud.

IBM Cloud provides various isolation mechanism and encryption options to achieve the desired risk profile for highly sensitive data and workloads.

Check out data protection for Hyperprotect DBaaS with Baffle.

Read the IBM Cloud guide on customer-owned encryption keys.

Be the first to hear about news, product updates, and innovation from IBM Cloud