Most organizations have a preferred cloud provider. This is the provider where they have the most engineering expertise, have negotiated the best discounts, and have built the paved road experience.
But any organization of any size is going to be multicloud. Google Workspace users will have GCP Projects created to support AppScripts and Service Accounts. AWS customers may have Azure AD to support their Office 365 subscriptions. And with mergers and acquisitions, cloud engineers don’t get to decide the tech stacks of the companies management chooses to buy.
The various providers have their strengths and weaknesses. Azure is an obvious choice for companies with primarily Windows workloads, but with OpenAI becoming the dominant player in Generative AI, it makes sense to deploy supporting infrastructure in Azure. Google has always had a leg up on big data, and Big Query is still a popular tool for querying large datasets. AWS has a dizzying array of services and is the undisputed leader in serverless and managed applications.
What’s your organization’s strategy when an engineering team says they need to use a non-preferred provider?
Cloud Governance is the policies and standards an organization adopts to facilitate the safe and cost-effective use of cloud services. Cloud Governance typically includes five disciplines:
There are significant differences between cloud providers in the tactics and technology used for cloud governance. Tools available in Azure do not automatically translate to AWS or GCP. Organizations typically focus on their primary cloud provider and ignore the risk and governance aspects of the other two.
This blog post covers the basic things you should do to minimally govern each major cloud provider. This Minimal Viable Cloud Governance Strategy consists of:
Defining the process for using the non-preferred cloud provider is vital. Teams shouldn’t be allowed to go outside of the primary cloud governance framework without some form of review and approval. Managing the Tenancy & Identity for each provider
This topic transcends each cloud provider and is one of the most critical to establish. When a team has a pressing reason to use the non-preferred cloud provider, how do they go about doing it? Establishing this process at the outset will help prevent shadow cloud, where the team just goes out and sets up a new cloud account outside the visibility of finance, security, and legal.
This is a cultural question for your organization, and there are no explicit answers here. However, things that need to be considered are:
Clearly documenting the criteria and process for using the non-preferred provider is critical to your overall cloud governance strategy.
Once that is done, what must you do to onboard the non-preferred providers?
This governance strategy ensures that all your resources are in a known place and there aren’t “shadow clouds” lurking in your organization.
This governance strategy manages how people access your cloud tenant. You want to ensure your organization owns the identities and they are tied to your HR processes to ensure access is revoked upon departure or role change.
With your primary cloud provider, you probably already have a strategy for staff and services to securely access resources in your VPCs or VNETs. These network routes may not exist when you move into an alternate cloud provider. Without a plan to extend your global cloud network into these alternate clouds, builders will put resources on the public internet (perhaps allow-listed to your VPN or offices).
All three providers offer an IPSec tunneling option. Azure and GCP support shared VPCs. Depending on the use case for the alternate cloud provider, your network team probably needs to allocate IP Addresses and ensure connectivity.
The final aspect of a minimal cloud governance strategy is ensuring the security team has visibility into these alternate clouds. Typically, this includes providing a read-only access role to your cloud security engineers and deploying some form of Cloud Security Posture Monitoring.
Be careful with the CSPM tools. They typically focus on the core cloud services - Compute (Hosts & Containers), Storage, and Networking. These services don’t have much business-value differentiation and, thus are probably running in your primary cloud provider. The common CSPM tools may not cover what you want to use an alternate provider for. This means manual inspection and a good threat modeling exercise (possibly as part of the Right to Use) should be part of your minimum viable cloud governance strategy.
With AWS, teams can create AWS accounts with only an email address and a credit card. These accounts are owned by the person who created them, and only that root email address can officially communicate with AWS about the account. To avoid shadow AWS sprawl, you want to do the following:
Finally, you want to search for shadow AWS accounts in your organization. AWS doesn’t usually offer a list of accounts using your domain name. You can use a search of the expense reporting system for payments to AWS, or you can do an email subject search for: Amazon Web Services Invoice Available
With Google, members of your organization can create consumer accounts using their organization’s email address. These free consumer accounts leverage the free consumer terms and have all the negative privacy implications you’d expect.
For Google identities to be managed by your organization, they must be part of a Google Domain. The Google Domain defines the human identity component of GCP. It’s tied to Google Workspace (Docs/Sheets/Drive) and other Google services like Analytics or YouTube. There are two types of Google Domain users - Google Workspace users and Cloud Identity users. Workspace users have access to the Google Workspace suite of services and have a monthly license cost. Cloud Identity Users are free, and while they don’t provide access to Google’s collaboration tools, they can be used for GCP and other Google services.
Users with access to manage the Google Domain are called “Super Admins” and have access to the portal at admin.google.com. These users should have MFA enabled and account recovery processes set up.
The minimal things you want to do for GCP are:
Finally, you will want to review the Unmanaged Users in your domain, and on-board them to your organization. These may have been created as shadow-it accounts for using Google Workspace. These users should be on-boarded into the OU that allows Google Workspace, and then a review of the business justification for using Workspace should be conducted.
The predominance of Active Directory, Windows, and Office 365 means the chances of your organization having some Azure presence. However, even if an Azure AD tenant is created for your organization, there are still things you want to do to ensure the Azure Cloud resources are properly governed.
In the immortal words of Ian Malcolm in Jurassic Park: “Life finds a way” and so do developers. By establishing the basics for the three major cloud providers you’ve taken a significant step in supporting your builders when they need to use one of your company’s non-preferred cloud provider. You can’t protect what you don’t know you have, and establishing these processes will reduce the risk of “shadow cloud” and ensure security, finance, and governance knows what is being done in all cloud providers.