AzPolicyAdvertizer

last sync: 2025-Apr-29 17:16:02 UTC

Microsoft Managed Control 1028 - Information Flow Enforcement | Regulatory Compliance - Access Control

Azure BuiltIn Policy definition

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
Versioning Versions supported for Versioning: 0
Built-in Versioning [Preview]
Category Regulatory Compliance
Microsoft Learn
Description Microsoft implements this Access Control control
Cloud environments AzureCloud = true
AzureUSGovernment = true
AzureChinaCloud = unknown
Available in AzUSGov The Policy is available in AzureUSGovernment cloud. Version: '1.0.0'
Repository: Azure-Policy f171df5c-921b-41e9-b12b-50801c315475
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)
Compliance
The following 3 compliance controls are associated with this Policy definition 'Microsoft Managed Control 1028 - Information Flow Enforcement' (f171df5c-921b-41e9-b12b-50801c315475)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
NIS2 AM._Asset_Management_9 NIS2_AM._Asset_Management_9 NIS2_AM._Asset_Management_9 AM. Asset Management Human resources security, access control policies and asset management n/a The cybersecurity risk-management measures should therefore also address the physical and environmental security of network and information systems by including measures to protect such systems from system failures, human error, malicious acts or natural phenomena, in line with European and international standards, such as those included in the ISO/IEC 27000 series. In that regard, essential and important entities should, as part of their cybersecurity risk-management measures, also address human resources security and have in place appropriate access control policies. Those measures should be consistent with Directive (EU) 2022/2557. 28
NIS2 BR._Backup_and_Recovery_3 NIS2_BR._Backup_and_Recovery_3 NIS2_BR._Backup_and_Recovery_3 BR. Backup and Recovery Business continuity and crisis management n/a Directive (EU) 2016/1148 of the European Parliament and the Council (4) aimed to build cybersecurity capabilities across the Union, mitigate threats to network and information systems used to provide essential services in key sectors and ensure the continuity of such services when facing incidents, thus contributing to the Union’s security and to the effective functioning of its economy and society. 25
NIS2 DP._Data_Protection_8 NIS2_DP._Data_Protection_8 NIS2_DP._Data_Protection_8 DP. Data Protection Policies and procedures regarding the use of cryptography and, where appropriate, encryption n/a In order to safeguard the security of public electronic communications networks and publicly available electronic communications services, the use of encryption technologies, in particular end-to-end encryption as well as data-centric security concepts, such as cartography, segmentation, tagging, access policy and access management, and automated access decisions, should be promoted. Where necessary, the use of encryption, in particular end-to-end encryption should be mandatory for providers of public electronic communications networks or of publicly available electronic communications services in accordance with the principles of security and privacy by default and by design for the purposes of this Directive. The use of end-to-end encryption should be reconciled with the Member States’ powers to ensure the protection of their essential security interests and public security, and to allow for the prevention, investigation, detection and prosecution of criminal offences in accordance with Union law. However, this should not weaken end-to-end encryption, which is a critical technology for the effective protection of data and privacy and the security of communications. 32
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Preview]: NIS2 32ff9e30-4725-4ca7-ba3a-904a7721ee87 Regulatory Compliance Preview BuiltIn unknown
History none
JSON compare n/a
JSON
api-version=2021-06-01
EPAC