Multi-Cloud Security Reality Check
Security continues to be top of mind for enterprises: what security considerations should you be thinking about when stepping into the multi-cloud universe? Leveraging multiple cloud service providers (CSP) to host an application is not a new phenomenon for enterprises. The rate at which CSPs release new security features to keep your applications secure from hackers, unauthorized use/access and other risks make it easy to architect security solutions that are not properly scoped for your application. Furthermore, a CSP may have a service offering that is appealing to your app dev team, but doesn’t fit into the security framework of the company. In this article we will review three considerations that should be part of your multi-cloud security strategy.
Identity and Access Management (IAM) is a fundamental concept of cloud security. Cloud IAM done right allows individuals and infrastructure to access the cloud resources they need while keeping everyone else out. When you are committed to a single cloud provider, you are allowing the provider to handle the details of generation, expiration, and automatic rotation of credentials. Conversely, if you have a service in GCP calling another service in AWS, now you must export long-living credentials from AWS to GCP and maintain a secure process to ensure the credentials are rotated. This sounds like a divorce waiting to happen.
To intensify matters, each cloud service provider handles IAM very differently when it comes to defaults, evaluation logic, and jargon. When you deploy a virtual machine in AWS it has no default access to any other cloud resources. GCP takes a different approach by assigning a default service account which has an Editor role. AWS gives you the ability to look at the car, but GCP allows you to drive off with the car. You need to be critical of these different approaches, otherwise you could end up exposing data and infrastructure unintentionally.
We can all agree with the cloud providers that encryption is critical to get right. However, each provider has a different perspective on encryption. Since encryption is a hot topic and broad in nature, let’s focus on encryption at rest and encryption in transit.
Encryption at rest refers to where your data is stored. For example, you can configure a managed database to have the underlying disk encrypted. GCP always encrypts the disk volume by default. As such you cannot turn off encryption, control how the encryption happens, or what keys are used for encryption. In contrast, AWS allows you to encrypt your database at rest using a Customer Managed Keys (CMK) or an AWS managed key within Key Management Services (KMS).
Encryption in transit refers to securing the communication channel so that no third party can view or modify the traffic as it travels from sender to the receiver. Both AWS and GCP highly encourage teams to encrypt data in transit. However, GCP makes it a bit easier to do this by enabling a single setting in the console or CLI. In AWS you need to complete a few steps to enable this functionality. Given the legal ramifications for leaving data unencrypted in the cloud, make sure data is properly encrypted when traversing cloud providers.
As enterprises continue to develop secure business applications in the cloud, a common topic of discussion is who can deploy their application the fastest and be first to the market. The only way to achieve such speed and agility is through automation. Many teams develop automation that does not have security built into its foundation. Bill Gates said that “Automation applied to an inefficient operation will magnify the inefficiency.” Leveraging automated tools to enforce security and compliance controls allows enterprises to achieve compliance at speed and at scale.
Automation reduces the opportunity for teams to make security mistakes, because teams don’t have to manually configure security groups, networks, encrypted volumes, user access, firewalls, DNS names, log rotation, etc. Automation allows you to mitigate vulnerabilities in real-time, while the tooling also supports remediation functions to resolve issues. Finding the right tool or product to synchronize infrastructure configuration across platforms is key.
Build guardrails, not roadblocks
In closing, a multi-cloud security strategy is a daunting task that must be handled delicately like brain surgery. The juice must really be worth the squeeze otherwise you could be the next breach. Security cannot be an afterthought as you plan. Architecting and designing a multi-cloud environment must incorporate security each step of the way. This means having the right people and tooling in place to support this initiative. The goal should always be to build guardrails, not roadblocks.