Minimally Viable Cloud Governance

Wednesday, February 14, 2024   Chris Farris   AWS CloudSecurity Technology Azure GCP Governance
Akershus Fortress - Oslo Norway - Feb 2024

You are multi-cloud whether you like it or not.

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?

Minimally Viable Cloud Governance

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:

  • Cost management
    Ensuring that cloud spending is optimized, reducing wasteful spending, and understanding how cloud costs align with products and the application portfolio.
  • Security Baseline
    Establishing a standard set of security practices in the cloud, aligned with corporate policy and regulatory requirements.
  • Identity Baseline
    How people access the cloud for administrative purposes and how resources can authenticate with each other falls under the Identity component of Cloud Governance.
  • Resource Consistency
    A consistent playbook for deploying resources in the cloud saves time and prevents builders from reinventing the wheel. Tagging resources with ownership and service helps triage security and operational incidents.
  • Deployment Acceleration
    The process by which applications and cloud resources are consistently deployed in a safe and cost-effective manner.

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:

  • Define the Right to Use
  • Manage Tenancy
  • Manage Identity
  • Manage Connectivity
  • Audit & CSPM

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

Define “Right to Use”

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:

  • Who needs to approve the use of the non-primary cloud provider?
    • Security?
    • Finance?
    • Enterprise Architecture?
    • Procurement/Legal/Risk Management?
  • Do your engineers know how to start this process?
  • How does cost allocation work? A non-preferred provider will have fewer discounts. Who is responsible for the additional costs?
  • How long will the process take?
    • Is asking a question of Security or Legal a black box with no defined SLAs or any idea for the project managers how long it will take?

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?

Manage Tenancy

This governance strategy ensures that all your resources are in a known place and there aren’t “shadow clouds” lurking in your organization.

Manage Identity

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.

Manage Connectivity

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.

Audit & CSPM

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.

Checklist for AWS

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:

  1. Create an email distribution list for the main AWS Account
    1. Ensure your Cloud team and security team are members.
    2. If your mail provider supports plus addressing, you can use the same list for all child accounts.
  2. Create an official AWS Organization.
    1. Open a new AWS Account to act as the Organization Management Account & consolidated billing payer
    2. Put MFA on the root user for this account
    3. Enable AWS Organizations and enable All Features.
  3. Enable AWS IAM Identity Center in that organization
    1. Bind the Identity Center to your organization’s primary source of identity. You can find instructions for GCP and Azure AD.
    2. Create a Permission Set with full administrative privileges and assign it to your cloud engineering team.
    3. You’ve now avoided creating IAM Users
  4. Create a dedicated Security (and possibly logging) Account
    1. Configure a Cross-Account Audit role from the security account to the other accounts. This can be done via AWS CloudFormation StackSets.
  5. Enable Organizational CloudTrail
    1. Create an S3 Bucket in the Security or Logging account
    2. Create a CloudTrail in the Organizational Management Account, select “All Regions” and “Apply to the entire Organization”
    3. Congrats - all future accounts will have audit logging enabled from the moment of account creation to its final closure.
  6. Establish a set of core Service Control Policies to be applied at the root of the organization
  7. Create a Sandbox Account for developers to experiment in.
    1. Access to the Sandbox should leverage the AWS Identity Center and be tied into your existing access request process
    2. Consider a tool like AWS Nuke to regularly clean up the sandbox for cost-recovery purposes.
  8. Establish an account strategy.
    1. Are accounts provided on a per-team or per-application/service basis?
    2. Production should be in a different account from downstream environments. How many accounts does each team or application/service get?
    3. What’s the naming convention?

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

Checklist for GCP

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:

  1. Setup a Google Domain
    1. Create a Cloud Identity Free subscription.
    2. Unless you’re using Google Workspace for email, disable GMail. Your MX records don’t point to Google; having that service available will only confuse your users.
  2. Configure Google to use your corporate IDP for authentication.
  3. There are quite a few settings under Security you want to review, especially if you’re skipping step 2 above:
    1. Enable 2 Factor Authentication
    2. Allow Users to recover their own account if they have a recovery email or phone set
    3. Advanced Protection Program is a feature I’ve not (yet) experimented with.
    4. Configure password complexity and expiration
    5. Configure API access for Google Services
    6. Configure Re-authentication Settings for GCP
  4. Set up Google Domain Organization Units.
    1. If Google Workspace is not common:
      Create an OU for Google Workspace users - Only members of this OU are granted access to the Workspace suite of tools.
    2. If Google Workspace or other Google services are common:
      Create an OU for Google Cloud - Only members of this OU are granted access to GCP.
  5. Review the Alerting Rules Google provides for your domain.
  6. Enable GCP and set up the Google Organization
    1. The Google Cloud Setup wizard will establish the basic Google groups, logging, and billing.
    2. The setup will offer to create Organization Policies. You can accept the defaults to be applied to the entire organization, then override any specific policies on a per-folder or per-project basis.
  7. Ensure GCP Audit Logs are fed to your SIEM by setting up a PubSub topic in your Logging Project and applying the Log Sink at the Organization (not project or folder) level.
  8. Create a group in Google Identity for your security team. In the GCP Console, ensure that group has IAM permissions at the Organization level with the following permissions:
    1. Security Viewer
    2. Organization Viewer
    3. Viewer
    4. Billing Account Viewer
  9. Establish a Folder and Project Strategy
    1. Are projects provided on a per-team or per-application/service basis?
    2. Production should be in a different project from downstream environments. How many projects does each team or application/service get?
    3. What’s the naming convention?
    4. Are project folders based on the team/application or by the environment, prod/non-prod? IAM Access can be applied to folders granting team access to all their projects, or Organization Policies can be applied to folders locking down how production operates compared to non-production.

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.

Checklist for Azure

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.

  1. Create an account with Microsoft
    1. Create an account at your domain from the Azure Portal Login
    2. Prove you’re a human
    3. Wait an hour or two for your account to propagate (I’m not sure why, but that’s been my experience).
    4. Login, and you’ll have an M365 set up.
    5. Secure your account at the My Account site.
  2. Enable Azure AD (now known as Entra ID)
  3. Create a Tenant Root Management Group
  4. Grant Security Team Audit Access
    1. Create and Azure AD / Entra ID Group for AzureSecurityAudit and add core security persons
    2. Create a Role Assignment to grant Reader permissions on the Tenant Root Group to the AzureSecurityAudit group.
    3. On the Billing Scopes page, select the billing scope used for Azure and then on the IAM Tab, grant the AzureSecurityAudit Group Billing account reader
    4. In Entra ID, Assign the members of AzureSecurityAudit the Global Reader Role for visibility to Azure AD. (You cannot always assign Entra ID Roles to Groups).
  5. Go to Azure Monitor
    1. Setup a Diagnostic setting to capture the Activity Logs for the Entra ID Tenant
    2. Setup a Diagnostic setting to capture the Activity Logs from each Subscription

Conclusion

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.