AzPolicyAdvertizer

last sync: 2025-Apr-25 19:39:43 UTC

Microsoft Managed Control 1202 - Access Restrictions For Change | Regulatory Compliance - Configuration Management

Azure BuiltIn Policy definition

Source Azure Portal
Display name Microsoft Managed Control 1202 - Access Restrictions For Change
Id 40a2a83b-74f2-4c02-ae65-f460a5d2792a
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 Configuration Management 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 40a2a83b-74f2-4c02-ae65-f460a5d2792a
Additional metadata Name/Id: ACF1202 / Microsoft Managed Control 1202
Category: Configuration Management
Title: Access Restrictions For Change
Ownership: Customer, Microsoft
Description: The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system.
Requirements: Azure service teams define, document, approve, and enforce logical access restrictions associated with changes by using role-based access control (RBAC) enforced by Active Directory (AD). All accounts created in support of Azure are role-based. Service team personnel request access to, and if approved, are placed in the appropriate security groups according to their roles for supporting the system and using the principles of least privilege. Access to the production environment is only allowed to members of specific security groups after approval. A subset of service team personnel has gone through the approval process for read-only access to production, used during critical incident escalations. Segregation of duties is established on critical functions within the Azure production environment, to minimize the risk of unauthorized changes to production systems. Access to make changes to the production environment is limited to authorized members in the service teams. Temporary elevated access to the production environment via JIT by other teams may be granted for specific issue handling or troubleshooting purposes. To support segregation of duties and prevent unauthorized changes to production, Azure implements segregated environments. Development and testing responsibilities for new software builds or changes to existing software are segregated and managed through restricted access to branches within Azure DevOps and segregated development and test environments. Features and changes are developed by the service teams, reviewed by designated service team members and tested by the service team members for quality assurance and compatibility with the rest of the platform. Azure maintains logical and physical separation between the development, test, and production environments. The development, test and production environments run on different clusters in separate network segments. Test and production clusters reside in separate network segments, which are accessed through distinct test and production Jumpboxes, Debug servers, and Network Hop Boxes. Access to test and production Jumpboxes, Debug servers, and Network Hop Boxes is restricted to authorized personnel. Transfer of software to the production environment is controlled by a version control system (VCS). Deployment of software bits to production is controlled through approvals and on qualifying production entry criteria. Production deployments use approved software builds and images, and do not contain development tools and utilities. The test data resides in a segregated environment with access restricted to authorized individuals based on job responsibilities. Production data is not used for testing purposes in a way that affects customer service. Physical access to servers and network devices is restricted to authorized personnel through the physical access protections in place at the datacenters and Government Cloud Collaboration Centers (GC3s). Privileged Access Workstation (PAW) The Azure environment has additional logical restrictions such as requiring two separate accounts for users who wish to access a PAW and perform administration or implement changes within the environment.
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 1 compliance controls are associated with this Policy definition 'Microsoft Managed Control 1202 - Access Restrictions For Change' (40a2a83b-74f2-4c02-ae65-f460a5d2792a)
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
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