| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1636 - Boundary Protection | Isolation Of Security Tools / Mechanisms / Support Components | ||
| Id | 7b694eed-7081-43c6-867c-41c76c961043 | ||
| Version | 1.0.0 Details on versioning |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this System and Communications Protection control | ||
| Additional metadata |
Name/Id: ACF1636 / Microsoft Managed Control 1636 Category: System and Communications Protection Title: Boundary Protection | Isolation Of Security Tools / Mechanisms / Support Components Ownership: Microsoft Description: The organization isolates SecurID systems, Security Incident Management systems, Audit Collection systems, Security scanning systems from other internal information system components by implementing physically separate subnetworks with managed interfaces to other components of the system. Requirements: Azure implements multiple strong logical isolation mechanisms for isolating the customer environment, infrastructure components, and administrative tools, rather than physical isolation. These mechanisms include: * Virtual Layer 2 on Layer 3 routing, which isolates the management plane from the data plane * VLAN isolation, which isolates the Fabric Controller, other devices, and both internal service teams and customers * VM and Host OS code isolates the Host OS from VMs and from one another * Storage account isolation via unique secret keys The Azure security tools, mechanisms, and support components associated with system and security administration are logically isolated in a separate subnet known as the Security Global Infrastructure LAN (GIL). Azure’s Security GIL subnet is part of the greater Global Infrastructure LAN, a logically separated subnet managed by the Azure Networking team. To restrict network traffic for the subnet, ACLs are used for ingress and egress traffic. Access to the Security GIL assets are restricted to only approved system administrators using smart cards and PINs via Jumpboxes, Network Hop Boxes, and Debug Servers. Azure service teams are also logically isolated from one another due to the nature of the Azure cloud, using the same tenant isolation utilized by external customers. Service teams are treated as external customers in their use of Azure – with the exception of the management plane and its supporting teams, services run within standard Azure network security groups that are logically isolated from the rest of Azure. This ensures services including PKI, Geneva Monitoring, Azure Security Monitoring, Service 360, JIT, Key Vault, and more are logically isolated by default. |
||
| Mode | Indexed | ||
| Type | Static | ||
| Preview | False | ||
| Deprecated | False | ||
| Effect | Fixed audit |
||
| RBAC role(s) | none | ||
| Rule aliases | none | ||
| Rule resource types | IF (2) Microsoft.Resources/subscriptions Microsoft.Resources/subscriptions/resourceGroups |
||
| Compliance | Not a Compliance control | ||
| Initiatives usage | none | ||
| History | none | ||
| JSON compare | n/a | ||
| JSON |
|