| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1031 - Separation Of Duties | ||
| Id | 6b93a801-fe25-4574-a60d-cb22acffae00 | ||
| Version | 1.0.0 Details on versioning |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this Access Control control | ||
| Additional metadata |
Name/Id: ACF1031 / Microsoft Managed Control 1031 Category: Access Control Title: Separation of Duties - Duty Separation Ownership: Customer, Microsoft Description: The organization: Separates duties as defined in Microsoft Azure Access Control SOP and the Microsoft Azure Software Change and Release Management SOP and Microsoft Azure Hardware Change and Release Management SOP; Requirements: Azure implements separation of duties and least privilege by assigning service team members the permissions to their service team with additional permissions being granted only if necessary for business reasons. Separation of duties within service teams is based on user access functions and is divided among different roles in an appropriate way, with the use of RBAC in Active Directory. Role separation ensures that operations system administrators cannot modify application code and nonessential personnel are restricted from administrative privileges in the production environment. Azure users are assigned to security roles, which have a defined list of available permissions. By default, no accounts have active permissions to the production environment. If an Azure user needs access to the production environment to perform a specific action, they request temporary Just in Time (JIT) access through the JIT portal. Approval is granted either automatically using preconfigured rules or a different Azure user with the access approver role reviews and approves or denies the type of access requested. Access is only provided for a finite time based on the expected duration of the work to be performed. If access is approved, the user is assigned the minimum permissions required to perform the work, and permission is automatically revoked at the end of the specified time. Implementing access control using JIT access via the JIT portal effectively prevents malevolent activity without collusion, as an individual must review and approve the requestor's access request and denies requests that violate separation of duties requirements. Regardless of JIT access, reviews of accounts and all approved access occur quarterly through the Quarterly Access Review (QAR). Emergency access accounts have persistent administrative access, but generate Severity 2 incident tickets when accessed, ensuring that separation of duties is maintained due to the requirement to investigate each use. Exceptions to the JIT and emergency access account procedures are required to be approved prior to being created and utilized on the production network. This small number of accounts has persistent administrative access to the production environment but must follow all account management requirements before being approved and are monitored closely. Azure also establishes separation of duties on critical functions within the Azure production environment to minimize the risk of unauthorized changes to production systems. This is accomplished by separating the responsibilities for requesting, approving, and deploying changes to authorized Azure teams and personnel. Development and testing responsibilities for new software builds or changes to existing software are separated and managed through restricted access to branches within Git and segregated in the development and production environments. Features and changes are developed by the Azure service teams and are reviewed and tested by designated service team members for quality assurance and compatibility with the rest of the platform. |
||
| 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 |
|