Azure Organization Hierarchy
We leverage the Azure Resource Hierarchy to define and enforce global policies across our entire organization.
Management Group Hierarchy
The management group hierarchy allows us to selectively apply policies. The main hierarchy looks like this
`likvid-foundation` this is the root of the hierarchy
├── `likvid-landingzones` landing zones for application teams
└── `likvid-platform` landing zones for platform-level workloads, restriced access only for cloud foundation team
See Application Landing Zones below.
TODO: link to individual landing zone documentation deployed in your foundations from here.
Global Policies
This table describes global policies consistently enforced for all workloads running on Azure.
These policies are assigned to the likvid-foundation management group.
Activity Logs
Global policies enforce auditing of all subscription-level Azure API events. Please see Activity Logs for more details.
Service and Location Restrictions
| Policy | Effect | Description | Rationale |
|---|---|---|---|
| Deny the deployment of classic resources | Deny | Denies deployment of classic resource types under the assigned scope. | Azure classic resources have been deprecated since the introduction of ARM and will be retired soon. We therefore prevent using these resources for new projects. |
| Limit allowed locations for Resources | Deny | Specifies the allowed locations (regions) where Resources can be deployed. | We explicitly restrict allowed resource locations to EU-locations. Only the following locations are allowed - germanywestcentral- westeurope |
| Limit allowed locations for Resource Groups | Deny | Specifies the allowed locations (regions) where Resource Groups can be deployed. | We explicitly restrict allowed locations for deploying resource groups to EU-locations. Only the following locations are allowed - germanywestcentral- westeurope |
Resource Configuration Policies
These policies help ensure Azure resources are deployed in secure configurations.
Note: The cloud foundation team cannot possibly assess, recommend and enforce best practice configurations for every Azure resource. In alignment with our shared responsibility we deploy and enforce these policies on a "best effort" basis to address cross-cutting security concerns and well-known security issues.
🚧 TODO: customize deployed policies and rationales to your organization's individual needs
| Policy | Effect | Description | Rationale |
|---|---|---|---|
| Subnets should have a Network Security Group | Audit | This policy audits the creation of a subnet without a Network Security Group to protect traffic across subnets. | We do allow creation of custom subnets in some landing zones. Requiring explicit configuration of NSGs ensures application teams take explicit responsibility for securing subnet traffic. |
| Audit resource location matches resource group location | Audit | Audit that the resource location matches its resource group location | Diverging resource group and resource locations can create unintended availability risks for deploying and updating resources in case of outages of the resource group location. We monitor and surface this to application teams to make sure they are consciously considering this risk. |
| Enforce recommended guardrails for Azure Key Vault | Deny, Audit | This initiative assignment enables recommended ALZ guardrails for Azure Key Vault. | KeyVaults are critical infrastructure component for secret management used for applications and a variety of Azure Services. Centrally enforcing best-practices guardrails helps us maintain a better security posture for managing secrets. |
| Enforce TLS and SSL configuration on resources without Encryption in transit | Deny, Audit, DeployIfNotExists, Append | Deny or Deploy and append TLS requirements and SSL enforcement on resources without Encryption in transit | Many Azure Services like App Services or Azure Database support minimum required TLS and SSL versions. This policy allows us to monitor compliance to our organization's crypto policies. |
Application Landing Zones
We separate landing zones for applications into two different types based on their network connectivity model. Application teams have to choose up front wether they to connect their networks to on-premise or the public internet. This decision significantly simplifies securing workloads and ensuring a good security both. Mixing both connectivity models is therefore not possible
Online Landing Zones
No special restrictions apply.
🚧 TODO: In advanced stages of your cloud journey you may consider deploying centrally managed WAFs and internet egress solutions.
On-Premise Landing Zones
🚧 TODO: to deploy on-premise connectivity, have a look at the separate kit modules on collie hub provided for this purpose and link it here.
TIP
In the on-premises connectivity model you can typically indirectly connect to the internet via existing infrastructure like proxies or gateways.
Platform Landing Zones
The platform-level management group is further subdivided into the following management groups. This subdivision does currently not affect any policies and is merely used for access control inside the cloud foundation team.
`likvid-foundation` this is the root of the hierarchy
└── `likvid-platform` platform-level workloads, restriced access only for cloud foundation team
├── `likvid-connectivity` connectivity solutions like on-prem connection network hub
├── `likvid-identity` identity management solutions
└── `likvid-management` platform management solutions for deploying our cloud foundation
Compliance Statements
- Service and Location Restrictions: Restricts locations for cloud resources to EU regions only. Restricts list of allowed Azure Services do deny Azure classic resources.
- Resource Configuration Scanning: Audit policies check Azure Key Vault configuration and the SSL/TLS configuration of select Azure services.
- Resource Configuration Policies: Deploy policies enforcing security best-practices for key Azure services
- Subnets
- Azure Key Vault
- SSL/TLS configuration of select Azure services
- Managed Key Vault: Enforce and monitor expiration for secrets and keys and enable deletion protection. This helps ensure application-team managed key vaults are set up and configured according to best practices. Note: Key Vaults are not fully managed by the cloud foundation team, they stay within the application teams responsibility.