Service and Location Restrictions

⭐️🛬 Landing ZoneBasic policies on cloud resources restrict access to incompliant cloud services and cloud regions (geographic locations).

Building a cloud Landing Zone is a proven pattern to establish the guardrails that allow a cloud foundation team to offer a great deal of freedom while staying in control. Policies that constrain what resources your customers can deploy on the cloud are the most fundamental type of guardrail a landing zone can put in place.

There are two fundamental approaches to establishing these policies: whitelisting and blacklisting. Whitelisting starts from the assumption that all types of resources are forbidden unless explicitly allowed in a whitelist. Blacklisting starts from the opposite assumption that all types of resources are allowed unless explicitly forbidden on a blacklist. Both approaches require a certain amount of maintenance as the demands of internal customers change and cloud providers evolve their service offerings.

💡 In contrast to resource whitelisting, the blacklisting approach favors agility by empowering application teams to use cloud services within their own responsibility. For many organizations, this is the better default when a primary motivation for cloud adoption is to increase IT agility. The Cloud Foundation team establishes guardrails by blacklisting known incompliant services.

Cloud platforms offer different types of mechanisms to implement these policies. The most common mechanisms are

  • Location-based policies can forbid the deployment of resources in a particular cloud location or region. For example, your organization may want to restrict deployment to certain geographic regions in order to comply with data privacy regulations.

  • Resource- or service type-based policies can forbid the use of certain types of cloud services. Motivations to enforce these restrictions include services that do not meet required regulatory standards or carry a high risk (e.g. security issues due to misconfiguration, bill-shock) associated with them. They are also useful to enforce a Cloud Zones concept.

  • Quota-based policies are mostly relevant to private cloud platforms. They enable private cloud operators to protect the stability of their platforms and can also substitute missing platform functionality for implementing location- or resource-based policies. An example of this substitution is setting a resource quota to zero, effectively blacklisting customer projects from using it. A motivating use case for this can be a storage pool that’s dedicated to a Database as a Service platform offered as part of a In-house PaaS Service Integration.

  • IAM-based policies are an implementation alternative when a resource-based policy mechanism is not available. Never granting the required IAM permissions to create a type of resource (or actively denying its creation) effectively creates a blacklist for the resource.

Proven Patterns for Implementing Cloud Resource Policies

The myriad of cloud services and the technical abilities to implement resource black listing of most cloud platforms are endless. This can make it difficult for cloud foundation teams to find the right balance between establishing important guard rails, while not getting lost in the details.

Multi-Cloud Security and Compliance

Check out meshcloud’s comprehensive guide to “Multi-Cloud Security and Compliance” as an introduction to challenges of defining your compliance strategy and building compliant landing zones.

Read the Guide

Start Coarse, Go Fine

Start out with the most basic policies before going more fine granular. A cloud foundation evolves and you will have to plan for supporting this evolution anyway. In practice, this means starting with basic restrictions before going into details.

In which geographies do you plan to leverage cloud services? Unless you have explicit guidance from compliance stakeholders, start with allowing only your “home” geography. This can be where your organization is headquartered. For example, if you’re a US company blacklist all non-US regions in the cloud.

💡 In contrast to the general advice to favor blacklisting, location-based restrictions often make more sense to implement as a whitelist.

Restrict access to typical “shared services”. Some cloud services like those required to implement On-Premise Network Connection (e.g. AWS Transit Gateway, Azure ExpressRoute) should not be available to your application teams. Put those on a blacklist as they should be provided and controlled centrally by the cloud foundation team.

Define Your Shared Responsibility Model

The Shared Responsibility Model Alignment is the most important asset for establishing your cloud foundation’s philosophy. If you’re taking a “hands-off” approach that empowers application teams with a lot of freedom in exchange for a larger chunk of “residual responsibility”, you will have to spend less time evaluating all possible cloud services for blacklisting. On the other hand, if your cloud foundation aims to take a lot of responsibility from application teams’ shoulders, you will have to design and evaluate guardrails more consciously.

One of the cornerstones of the cloud foundation operating model is that legal and compliance stakeholders have more than just a seat at the table. They are part of the cloud foundation team. In contrast to other operating models where compliance stakeholders have a guiding and consulting role (”providing paper”), cloud foundation teams should take it in their responsibility to actually codify this guidance into technical policies (“providing automated policy”).

Leverage Infrastructure-as-Code and Resource Hierarchy

The policies and guardrails established by your cloud foundation team will have to evolve. By leveraging a Resource Hierarchy you can easily define policies at a central location and have them inherit to a large number of cloud tenants. Infrastructure-as-code also helps maintaining the set of policies and establishing a proper change management for the inevitable evolution of your policy definitions.

  • GCP Fabric FAST

    Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand.

    Learn More open in new window
  • GCP CFT - Example Foundation

    A good amount of reasonable default policies are rolled out via Terraform. They match the best practices provided by GCPs Cloud Foundation Toolkit.

    Learn More open in new window
  • Azure LZ accelerator - ES

    Assign different policies and initiatives based on Microsoft Cloud Adaption Framework. Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc.

    Learn More open in new window
  • Azure LZ Terraform module - ES

    Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand.

    Learn More open in new window
  • Azure CAF Terraform Modules

    Assign different policies and initiatives based on Microsoft Cloud Adaption Framework. Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc.

    Learn More open in new window
  • AWS Control Tower with Account Factory

    AWS Control Tower sets up 20 preventive guardrails (implemented by SCPs) and 3 detective guardrails (implemented by AWS Config). Those are the “Mandatory” guardrails enabled by default that we see are reasonable, such as disallowing deletion of the log archive bucket, disallowing changes to AWS IAM roles set up by CT and CloudFormation, etc. There are also more guardrails available that are not enabled by default, which are “Elective” and “Strongly Recommended” guardrails. Newly provisioned accounts with Account Factory inherit guardrails from their parent OU.

    Learn More open in new window
  • AWS Control Tower with AFT

    Accounts provisioned through AFT also inherit all guardrails from their parent OU which is covered by CT. Additional policies can be applied through AFT customization framework.

    Learn More open in new window
  • AWS Landing Zone Accelerator

    Reasonable guardrails are applied to the default domains Infrastructure, Security and Quarantine. It is easy to also define additional guardrails or to define them for additional, custom OUs.

    Learn More open in new window
  • collie-cli

    Deploy any policy via the terraform-based Landing Zone Construction Kit framework. Collie provides a workflow for documenting compliance controls and compliance statements that lay out what policies are in effect in your landing zone and how they help implement compliance controls.

    Learn More open in new window
Last Updated: