While hybrid and multi-cloud are terms often thrown around interchangeably in technology, there is one major distinction between the two infrastructures. multi-cloud implies using more than one public cloud, like AWS, Azure, GCP, and quite often some on-premise resources as well. However, what it doesn’t imply is that orchestration exists between these resources, causing them all to function as one single unit. Why? Because that would, in fact, make it a hybrid cloud. Unlike hybrid clouds where as far as the user is concerned, it’s all just one single platform, multi-clouds are more about silos and specialization. This is quite simply because some clouds are better at meeting certain requirements than others and vice-versa.
How so? A good example would be an organization where one team prefers AWS (Amazon Web Services) for its simplicity and ease of use while another team uses Google Cloud for its AI and Machine Learning capabilities. In addition to performance requirements, multi-clouds are also selected based on economics, regulatory compliance, and the need to avoid vendor lock-in.
There’s a downside to the multi-cloud approach, mostly revolving around authentication, authorization, and security. Users generally don’t care where data resides as long as they have access to it but what we often forget is it gets a lot more complicated with a multi-cloud setup. Different public clouds have different network risk profiles, like AWS, that use a default deny configuration as opposed to Microsoft Network Security Groups, that by default allow some traffic within a subnet.
This is why moving data through our multi-cloud exposes us to “multi-risks” that can cause “multi-problems.” Additionally, cross-cloud access is a complicated subject since data relationships, identities, hierarchy, and ownerships all need to be considered. With Google Cloud, for example, all resources have a “parent” except the organization at the top of the hierarchy. Similarly, different clouds have different “relationships” between data and resources that need to be fully understood before any real risk assessment can be made.
Here are 3 security considerations to think about if presently deploying or moving to a multi-cloud environment.
Multi Cloud IAM can be split up into the process of authenticating identities and then managing access. All three major public clouds (AWS, Microsoft Azure, and Google Cloud) have a slightly different process of authentication. While Microsoft Azure and Google Cloud let you access multiple projects with one account, AWS requires multiple sets of credentials to access different organizations.
AWS manages access differently as it lets you create policies that can not only grant highly specific access to all resource types but can be assigned directly to “roles.” In AWS, a role refers to an IAM entity with permission to make service requests. In contrast, Google Cloud uses “projects,” where each project has three pre-defined roles (read, edit and own) as well as custom ones that can be assigned accordingly. Azure, on the other hand, has a unique concept called “resource groups” that all resources deployed in azure need to be a part of. Each resource group has a number of roles that you can choose from.
Compliance is another major issue that multi-cloud users face, and this is often because of the pretty stringent requirements they are expected to follow for cloud security. Regulatory bodies are notorious for having specific requirements. Getting all the different pieces of your multi-cloud puzzle to jump through those hoops can be a daunting task for anyone.
Employing a platform that continuously monitors your environment helps ensure conformance to all major mandates, like GDPR, HIPAA, PCI, ISO, and it is a good way to escape a lot of manual work.
Incidentally, even the nature and geographic location of your cloud servers can have an adverse effect on your cloud compliance, as quite a few mandates have specific geographic requirements pertaining to associated jurisdictions. Continuous monitoring platforms, in addition to increasing operational efficiency by taking away the heavy lifting associated with compliance, also feature “mandate-specific” reports to ensure geographic sovereignty.
Finally, it’s important to remember that in a multi-cloud or hybrid cloud environments, it’s not just about where your data resides, but where it ends up as well. As organizations rapidly expand to deal with never-ending amounts of data, it becomes increasingly difficult to keep track of how this data travels.
While one of the biggest advantages of a cloud environment is without a doubt, scalability, it inadvertently happens to be a major drawback in this case. This is because infinitely adding resources to address customer demands can have all kinds of implications, especially with regard to how your data “moves.” Unpredictable data movement can be a nightmare for security teams, and again, public clouds just don’t have the tools to properly address this issue.
This is where continuous monitoring platforms step in once again, and not only ensure geographic sovereignty as described above, but also monitor movement between geographic locations to ensure no compliance breaches occur.
Most public cloud providers will tell you that it’s perfectly safe to migrate all your precious cargo over to their unlimited resource fields. The services they offer, however, are far from “unlimited” and often cannot be used to monitor 3rd party resources. Additionally, managing multiple clouds requires specialized platforms to ensure compliance, access management, authentication, and overall security.
Choosing a platform that does all of the above and more will save on having to deal with a plethora of different solutions, and then getting them all to work together. Deploying multiple applications that don’t naturally integrate with each other also makes it increasingly difficult to set standards in terms of mitigating security threats.