| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1028 - Information Flow Enforcement | ||
| Id | f171df5c-921b-41e9-b12b-50801c315475 | ||
| Version | 1.0.0 Details on versioning |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this Access Control control | ||
| Additional metadata |
Name/Id: ACF1028 / Microsoft Managed Control 1028 Category: Access Control Title: Information Flow Enforcement Ownership: Customer, Microsoft Description: The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on deny-all, approve-by-exception information flow policies. Requirements: Azure enforces approved authorizations for controlling the flow of information within the system and between interconnected systems by using the following features and controls. VLAN Isolation The Azure environment is logically segregated using software Virtual Local Area Networks (VLANs) to separate customer traffic from the rest of the Azure and Microsoft networks. The Azure environment in any datacenter is logically segregated into three primary VLANs – the Universal Fabric Controller (UFC) VLAN, the Fabric Controller (FC) VLAN, and a main VLAN that houses the rest of the components including the VMs and storage. Customer data sits behind the main VLAN and is segregated from other customer’s data. A brief description of each VLAN is below:* UFC VLAN - Used for communication between the UFC and FCs * FC VLAN - Used for communication between FCs and other network devices * Main VLAN - Used for customer VMs and FCs VLANs partition a network such that no communication is possible between VLANs without passing through a router. This prevents a compromised asset from faking traffic from outside its VLAN and from eavesdropping on traffic that is not to or from its VLAN. VLANs and ACLs restrict network communications by source and destination IP addresses, protocols, and port numbers. Communication is permitted from the FC VLAN to the main VLAN but cannot be initiated from the main VLAN to the FC VLAN, protecting the fabric from customers. As the central orchestrator of much the Azure infrastructure, significant controls are in place to mitigate threats to FCs, especially from potentially compromised Azure VMs within customer applications. FCs do not recognize any hardware whose device information such as a MAC address is not pre-loaded in the FC. The DHCP servers on the FC have configured lists of MAC addresses of the assets they are willing to boot. Even if unauthorized assets are connected, they are not incorporated into the Fabric inventory. This reduces the risk of unauthorized assets communicating with the FC and gaining access to the VLAN. Software Load Balancers Access to the Azure environment from outside the cluster is restricted through Software Load Balancers (SLBs). The SLB is a networking device that accepts internet traffic coming into Azure and forwards it to an appropriate internal IP address and port within the Fabric. In the common case where there are several different machines or VMs that can handle a given request, the SLB allocates the connections in a way that balances the load among them. The SLB routing tables are updated as VMs are created, deleted, and moved from one piece of hardware to another. Virtual Filtering Platform (VFP) Filter The Virtual Filtering Platform (VFP) Filter component in the Host OS isolates the Host OS from the Guest VMs and the Guest VMs from one another. It performs filtering of traffic to restrict communication between tenant's assets and the internet based on the customer's service configuration, segregating them from other tenants. The VFP Filter component on the VM allow passage of only those packets called out in the configuration documents of those VMs. Customers must explicitly open ports on their role instances by configuring the port number in their Service Definition file. There is no port that is open by default unless explicitly configured by the customer in the service definition. Once configured, the FC automatically updates the network traffic rule sets on VFP Filter as well as on the SLB to allow external traffic only through the designated ports. In addition, there is a VFP Filter on each customer VM which the customer is responsible for configuring the range of IP addresses authorized to access the customer environment. Firewall For scalability and reliability in a hyperscale environment, Azure does not implement traditional firewall architecture at the perimeter between the external and Azure environments to Azure internal components, but achieves the same effect using a series of firewalls at the OS layer, including a host firewall, hypervisor firewall, and VM firewall. All infrastructure components are assigned IP addresses that are from Dedicated IPs (DIPs) allocated from non-routable address space. Therefore, an attacker on the internet cannot route traffic to those addresses as they do not reach Azure. In the unlikely event the attacker was able to route the traffic to the addresses, the Azure Gateway routers filter all packets addressed to internal addresses so they do not enter the network. The only components that accept traffic directed to Virtual IPs (VIPs) are the Azure software load balancers. Access Control Lists (ACLs) Azure only allows connections and communication which are necessary to allow systems to operate, blocking all other ports, protocols and connections by default, as defined in Microsoft’s Online Services Network Security Standard. Access Control Lists (ACLs) are the preferred mechanism to restrict network communications by source and destination networks, protocols, and port numbers. Approved mechanisms to implement networked-based ACLs include: tiered ingress ACLs on routers managed by Azure Networking, IPSec policies applied to hosts to restrict communications when used in conjunction with tiered ACLs, network firewall rules, and host-based firewall rules. Certain communications as defined in the Firewall Rule and Tiered ACL Guidelines are pre-approved and therefore permitted without requiring further review by online services security. The Firewall Rule and Tiered ACL Guidelines define the ingress and egress ACLs specifying the approved protocols and ports for each key connection point based upon the asset classification of the data. Azure requires all ACLs involving ingress and egress ports other than what is listed within the Firewall Rule and Tiered ACL Guidelines, to obtain approval through the Security Review Process prior to implementation. Applications For data flowing between application components, service teams control input by using an input validation method stipulated by Microsoft’s Security Development Lifecycle (SDL) process, further detailed in the CM and SA families of controls. Input validation testing includes regulating data inputs by size, formation, and structure prior to allowing information to reach the underlying database. The backend services and servers receive only pre-validated inputs from the front-end webservers. The backend is not directly accessible, from an application data flow perspective, in any other method. |
||
| 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 |
|