Cloud compliance strategies for a multi-cloud world
Cloud computing and compliance don't need to be at odds -- even when an organization uses services from multiple cloud providers. Here's how to meet your compliance goals.
Compliance is never easy, and any cloud computing commitment makes it harder by submerging some applications, data and processes in the infrastructure of a partner. The multi-cloud model, in particular, introduces new dimensions to the compliance challenge that, if not addressed, can put your whole plan at risk.
Your cloud compliance risks will fall into three categories: information security, network security and regulatory compliance. Addressing them is a process. Think goal to conditions to deviations to remediation in a loop, and you'll get the idea.
The starting point in multi-cloud compliance is your current compliance model and tools. The first rule here is to organize your approach into a specific set of targets or goals and then associate your current practices explicitly to each of the goals. That will ensure you cover everything you're covering now, and also preserve as many of your current compliance practices as possible. Security and regulatory compliance are always goals, but many users want to add cost and performance management goals to ensure that they protect their multi-cloud business case.
Multi-cloud is different because there are multiple autonomous hosting domains, one for each cloud and one for your data center. The goal of multi-cloud compliance planning is to harness the compliance tools in each domain to serve a common mission. That means you know what's happening (i.e., cloud monitoring) and you take steps to address any problems that arise. Those are the conditions and deviations pieces of the cloud compliance circle.
You should also note that the nature and location of each public cloud provider in your multi-cloud environment affects issues in cloud regulatory compliance. Presence in a particular country often implies jurisdiction, so be prepared to expand your view of which regulations you'll need to comply with as you engage more cloud providers.
Monitoring is a key aspect in multi-cloud compliance implementation. Multi-cloud monitoring tools are readily available, including Bitnami Stacksmith, New Relic, Stackify Retrace and Ulia. These will assist with information collection. Some monitoring products conduct log analysis, some use system probes and some use application probes.
You can use these products to monitor your own data center hosting environment as well. This gives you the unified compliance strategy most compliance teams will want to see. Application-specific monitoring is especially helpful, since application type determines information type, the basis for most information security and regulatory compliance concerns.
Work with your providers
The way you use monitoring data and your plan targets or goals to drive review and remediation depends on your relationship with your cloud service providers.
There are important questions to ask:
How autonomous are your cloud domains?
Are you treating all of your hosting domains, or even several of them, as independent and parallel environments, or are you treating them as a pool of resources?
Are you consuming basic IaaS-style hosting or a managed cloud service of some sort?
If you use managed cloud services that are autonomous hosting domains, you'll want to harmonize the cloud compliance assurances in your service contract to make each of them equivalent. Next, assemble your contract-related monitoring in a single place, a kind of compliance console. This is by far the easiest and best way to handle multi-cloud compliance where your goal is to simplify the technical steps involved.
Never expose APIs that won't be accessed externally to the hosting domain. What's not exposed need not be provided with special protection.
If you can't harmonize your multi-cloud compliance process by monitoring against a set of consistent contracts, you'll need to harmonize through a monitor or management layer that's built on top of all your hosting domains. The approach there will depend on whether you have managed container services -- usually managed Kubernetes -- in your public clouds or whether you're deploying on virtual machines in the cloud.
Multi-cloud compliance via a harmonizing technical layer will always be easier if you adopt a container approach to application deployment. Kubernetes can be used in the data center, on infrastructure as a service and in conjunction with managed container or Kubernetes services. If you can't migrate to containers or if you mix them with VMs, the same principles will apply -- but you'll want to substitute DevOps tools, such as Chef, Puppet and Ansible, for Kubernetes orchestration.
Each of your clouds is a separate hosting domain, each with its own policies. A unifying monitoring strategy, based on the same kinds of tools cited earlier for contractual harmonization of compliance policies, will work here. If the cloud domains are autonomous and you don't expect to scale or fail over among cloud providers or between a cloud and data center, this common monitoring approach should be enough. You'll want to do this in conjunction with the multi-cloud monitoring tactics described earlier.
If you plan to use your multi-cloud as a resource pool, you'll need to think about creating a companywide policy set to describe how applications and data can be moved. This is sometimes called federation of Kubernetes domains, and it's supported by Google's new Anthos service, as well as by Cloudify, NetApp, Platform9, Rancher and Terraform. Federations are created by layering global policies on top of domain policies.
Policy-controlled domain federation unifies compliance processes across all domains, meaning the entire multi-cloud environment. Once you've either adopted contractual or federation harmonization of compliance, there's one further area to address in multi-cloud compliance, something outside the hosting domains but just as critical: the networking.
Safely expose assets
Every cloud provider will assign internal elements to private IP addresses and then provide a gateway mechanism to map the APIs of components that are accessed externally to a public address space such as the company VPN or the internet. How these assets are exposed is a critical issue in compliance because illicit connections to application assets will surely compromise information security.
Follow a few simple rules to get networking right:
Never expose APIs that won't be accessed externally to the hosting domain. What's not exposed need not be provided with special protection.
Provide access security through API brokers or similar tools when an API is exposed, especially if it is exposed to allow connection with components in another part of the multi-cloud.
Be sure every exposed API is monitored explicitly. This allows its use to be journaled, and it detects any misuse. SD-WAN products with explicit connection control can be a vital element in your network plan, so look closely at your options to ensure the product selected is both capable of cloud hosting and will support explicit connection permission and priority policies.
As a final point in the cloud compliance discussion, remember that there are business and technical reasons to adopt a multi-cloud strategy. It's important to measure these benefits against the increased complexity of multi-cloud deployments, and to ensure that each of your justifications for multi-cloud use is protected by your model of application deployment. Sustaining those benefits can be a multi-cloud compliance goal, too.
Dig Deeper on Cloud infrastructure design and management
