Azure Cloud Foundation Acceptance Criteria

Acceptance criteria are generally a list of prerequisites that must be met for a project or program to be deemed complete. Because they specify the parameters and demands that the implementers must meet, acceptance criteria are frequently referred to as the “definition of done“.

This article will lay out the “Azure Cloud Foundation Acceptance Criteria” for each cloud component. These criteria are based on industry best practices, and any company can use these criteria to improve their existing cloud landing zone or to set up a new tenant from which their clients can consume services.

When I create these criteria, the service limits of Azure are as follows:

We can have 10,000 Management Group per Azure Active Directory Tenant

There are no limitations of subscriptions per Management Group

We can have 980 Resource Groups per subscriptions

Maximum of 50 tags can be configured per subscription

More details can be found here.  Now, let’s take a closer look at each component, beginning with the Management Group and the subscription.  Here we go…!!

Management Group & Subscription

Platform and landing zone must be separated and be on their own MG

Landing Zone sub-MGs can be either grouping of App name or commercial apps for example we can group all web-based apps as “Online Apps” and all commercial apps as “Business Apps” or if any apps meant for corporate employees that can be kept under “Corp Apps” MG

Subsequently underneath “Online Apps”, “Business Apps” and “Corp Apps” we can have 3 or 4 subscriptions for each app for its Dev, Test, Non-Prod and Prod is an ideal approach

Underneath the sub-MG of Platform, we can have separate subscriptions for each division as security, shared services, connectivity, identity and so on

It is recommended to build different MGs for sandbox and inactive apps, with subscriptions under each.

Access Control: RBAC

Apply POLP to all roles and elevation should happen using Just in Time strategy using PIM

Evaluate roles for new subscriptions when created

When possible, roles are applied to the subscription scope

Focus only on granular access even if it requested via PIM

Assign roles to AD or AAD groups, rather than assigning roles to individuals.

Built-in roles should be preferred. Custom roles should be thoroughly tested to ensure POLP

I’m not insisting that everyone utilize the same roles, but here are some of the most typical ones in an Azure LZ-based service provider organization.

Networking

First, separate workstations from servers and other potentially risky assets.

Places and things of a like kind can be categorized into groups.

Third, always keep production assets separate from non-production ones.

Align with the triple-A organization strategy of the landing zone design

Segment the App environment network based on the app architecture, e.g. if the app is 3 tier, then it is recommended to create at least 3 segments inside subscription

Having a buffer of at least five IP addresses per subnet is a requirement.

VNet to VNet communication either in single or multiple subscription, multiple is preferred approach but if the peering is in hub and spoke model, we can have better security control

Use network security gateways (NSGs) and application security gateways (ASGs) to secure east-west traffic across all subnets (micro-segmentation)

Azure WAN in managed Hub & Spoke is better than VNet Hub & Spoke, but before taking a decision check out its limits

Name resolution using Azure’s Private DNS with a private resolver is recommended.

An external DNS from authorized registrars is preferable for use in the public sphere.

Shared Services MG’s subscription is where DNS settings should be made.

Azure WAN setup may be found in the Connectivity section of the Shared Services subscription.

All connectivity such as P2P VPN, ExpressRoute should be configured in Connectivity subscription

DR should mimic the same and connectivity should be with the help of Azure WAN

Each app subscription for webservices can have its own App Gateway set up as an LB.

For external access to an application (webservices), the front door is the recommended service.

Azure Load balancers can be used for more than just HTTP and HTTPS.

Bastion Host

Bastion host should be kept in the shared services subscription

Bastion host users must not access all applications environment at a same time, environment isolation should be ensured

Production bastion host users must not have admin access to any resources in Cloud, it must be ensured via PIM only

Infra as a Code

All deployments should be made via Infra as a Code

All deployments should be implemented via DevOps Pipelines

Standardized tools should be adopted across the enterprise, and projects. We should avoid adopting large number of tools for automation unless necessary

Deployments using the Azure Portal (ARM) or other ad hoc processes should be done by exception only

Backup and Restoration

Cloud security relies on the zero trust model—never trust, always verify. The 3-2-1 rule—three copies of data (production and two backups) on two media and one copy offshore, separate from production—is a core principle.

Single sign-on, multi-factor authentication and role-based access to isolate and control data access.

Should be stored in a immutable storage with strong encryption

Anomaly detection and alerts to identify and isolate infections of historical and current backups.

Easy identification of last good-known-copies with audit trails and the ability to automatically block downloads of infected content.

Guardrails, Policies & Governance

CIS Benchmark 1.4, Azure Security Benchmark v3 (ASB), and more than 90+ Enterprise Scale Landing Zone Policies are three policies that must be adhered to (not all, only applicable policies) for any Cloud Foundation projects or other existing Azure Landing Zones.

Not to worry too much; I have already compiled CIS Benchmark 1.3 in addition to Azure Security Benchmark v3 (ASB) of defender and more than 90+ Enterprise Scale Landing Zone Policies in a spreadsheet. This spreadsheet would assist any organization in meeting the majority of the typical standards for their corporate governance. You can download it individually by clicking the hyperlink above and consolidate it by yourself, or alternatively, you can download an already consolidated spreadsheet using this link straightaway.

I have already discussed this criterion in a more in-depth manner in this article; I won’t spend much time on it here. If you’re interested in learning more about policy-driven governance, please open this article, scroll down, and check out the policy-driven governance section.

Conclusion

This article will not focus on a number of other components such as Tagging, CI/CD, Automation, Provisioning, Policy as a Code, FinOps, Patch Management, and so on because either they are not required ones or there are tools available on the market that can perform these tasks more effectively than we can configure them natively.