| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1007 - Account Management | ||
| Id | 17200329-bf6c-46d8-ac6d-abf4641c2add | ||
| 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 | ||
| Additional metadata |
Name/Id: ACF1007 / Microsoft Managed Control 1007 Category: Access Control Title: Account Management - Modifying Accounts Ownership: Customer, Microsoft Description: The organization: Creates, enables, modifies, disables, and removes information system accounts in accordance with Microsoft Azure Security Policy; Requirements: Azure personnel are assigned unique corporate network (CorpNet) Active Directory (AD) accounts by Core Services Engineering and Operations (CSEO) as part of a standard onboarding to Microsoft. All Azure access requests and approvals leverage these CorpNet identifiers and are managed through OneIdentity, which is an automated workflow management tool that tracks the process for account request, approval, creation, modification, and deletion. New user accounts refer to accounts of existing Microsoft users using their unique CorpNet identifiers, known as aliases, who require access to Azure resources. Standard Access permits authorized users persistent access to a service’s documentation, work items, source code, telemetry, reports, and KPIs, and to submit and/or process deployment jobs using dual-key. Service team approvers create, enable, modify, disable, and remove this access using OneIdentity. Elevated access to the Azure production environment is primarily either dual-key (one user submits, another reviews and approves or rejects) for automation or uses Just In Time (JIT) approvals for interactive user access. JIT provides personnel elevated access for a defined period to resolve live site or deployment incidents. Azure has automated the JIT access request process through the JIT portal by defining policies for access provisioning and revocation. Service teams must define a JIT policy indicating which users may request JIT elevation, the duration of that elevation, and the scope of elevation. The default duration is eight (8) hours, with a maximum of seven (7) days. JIT policy changes are dual-key. The user initiates the access request by logging into the JIT portal and submitting the JIT access request. The access request submitted through the JIT portal is first adjudicated by system policies, then further evaluated against policies defined by the service that owns the resource – which could immediately deny the request, approve the request if conditions are met, or route the request to appropriate team members based on workflow configured in the service team policy, which is also dual-key. Barring any approved exceptions – including those approved due to lack of JIT support, the only persistent elevated access permitted to the Azure production environment is JIT break glass access, which alerts the resource owner when invoked. Azure account authorizers review accounts quarterly. Additionally, when a user is promoted or transferred to another group, the account authorizers review and modify or revoke as necessary user role and access rights according to the access policies. Furthermore, OneIdentity automatically terminates access depending on the rules configured for the project and the new manager’s approval if not manually approved after transfer. The user is required to resubmit a request for access when that individual’s access is close to expiring. For additional protection, Azure Security Monitoring (ASM) and SCUBA monitor service team operating systems for unexpected account creations. This includes monitoring for if an administrator or privileged role is added to an Azure subscription at the operating system layer, intended to prevent persistent access from bypassing the JIT process. When a user leaves the company, their manager or their manager’s work-on-behalf will submit the user’s resignation in the Employee Central system. Subsequently, an automatic notification is sent to the HR Administrator and the user. The user’s resignation includes the user’s last working day. If the last working day needs to be changed, the user’s manager or HR administrator will take the action to change the date in the HR database. The last working day information automatically flows to the HR database to ensure accounts tied to their CorpNet credentials are disabled on the user’s last working day. On the user’s last day, referred to as the termination date, access is shut off automatically since the Manager Self-Service (MSS) system is tied to the SAP systems; the user’s status switches to inactive and they are removed from payroll and benefits. If the user is leaving for a competitor, their access to the environment and buildings is terminated within forty-eight (48) hours. OneIdentity disables any user accounts daily if no HR record exists within the MSS system, such as after termination, or if the accounts have been inactive over one hundred and eight (180) days. Accounts that have been disabled for fifteen (15) days after one hundred and eight (180) days of inactivity are deleted. Accounts can also be requested for disabling via OneIdentityand MyAccess. |
||
| 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 |
|