| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1002 - Account Management | ||
| Id | 632024c2-8079-439d-a7f6-90af1d78cc65 | ||
| 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: ACF1002 / Microsoft Managed Control 1002 Category: Access Control Title: Account Management - Identifying Account Types Ownership: Customer, Microsoft Description: The organization: Identifies and selects the following types of information system accounts to support organizational missions/business functions: customer accounts, staff accounts, Microsoft federated accounts, service accounts, Windows local accounts, Windows local administrator accounts; Requirements: Azure accounts are only provided to Microsoft personnel supporting Azure services. Accounts with permissions to internal Azure assets and resources are not provisioned to customers. Azure uses Active Directory (AD) to manage access to implement Role-Based Access Control (RBAC) using AD groups. Microsoft personnel are assigned unique corporate network (CorpNet) AD accounts as part of a standard onboarding to Microsoft. These CorpNet accounts, known as a user's alias, do not have access to any Azure domains by default. For personnel supporting Azure services, a user account within each Azure domain ties to the user's CorpNet account using his or her unique CorpNet alias. This alias is consistent across all a user's accounts in all Microsoft domains, including Azure. CorpNet and Azure access are provisioned and managed using separate account management tools. Azure utilizes OneIdentity for both identifier and security group management. Azure utilizes the Global Management Environment (GME) and Azure Management Environment (AME) domains for access to Azure. Each domain is specific to the environment. As an example, John Doe's alias is jdoe, with accounts jdoe@redmond.gbl for access to CorpNet and jdoe@ame.gbl for access to Azure Commercial. Below are the different account types that Azure utilizes. Standard Access All personnel with standard access to Azure are granted system metadata read access used for regular troubleshooting, release management, and other maintenance and monitoring activities. Standard access provides permissions to key Azure tools, services, SharePoint sites, documentation, and a variety of dashboards. For instance, a user with standard access may have the need to review service-specific logs within Azure to identify and diagnose issues. These accounts are considered unprivileged due to the lack of write access. Any additional permissions above standard access requires elevation of access via the Azure Just in Time (JIT) tool, described below. Elevated Access All personnel must use JIT when interactive elevated access is required in the Azure production environment. Except in the case of an approved exception as described below, there is no standing or persistent elevated access to the Azure production environment. The primary exception is emergency elevated access, described below. In scenarios where JIT does not yet support management of elevated access, standing access may exist; these gaps in JIT support are identified and tracked as an exception, which requires approval. Software deployment via automated means (i.e., not using an interactive login) does not require interactive login to a resource that is accessed via JIT. In this case, a service team member submits a job (e.g., Pull Request in Azure DevOps), and another team member reviews, approves, and then the safe deployment system deploys. Elevated Access – Emergency Access Azure maintains emergency access accounts with elevated access for use in the scenario that the JIT service is not available. These accounts have persistent elevated access to perform maintenance activities if JIT is unable to provide temporary elevated access. These accounts are carefully managed, only to be used in emergencies, and have notifications associated with their use. Whenever such an account is utilized, a Severity 2 incident ticket is generated that requires the service that owns the resource to investigate and determine whether the access is valid. Network Device Accounts Access to network devices is managed through the Authentication, Authorization, and Accounting (AAA) system, which is configured to allow a specific role-based level of access to Azure Networking network devices via specific AD security groups managed by Azure Networking. There are no user accounts or groups configured in the AAA system, as account and security group access is managed and inherited from the Active Directory infrastructure, with AAA acting as its own directory for the leveraged accounts. The AAA system provides automated mechanisms to support accounts in use for network device access, including integration with network devices for administration access control, and allows for centralized control and auditing of administrative actions in the environment. Service Accounts Non-user, non-interactive service accounts are used to run relevant services. Service accounts are not used for interactive logins. For example, software deployment via automated means does not require interactive login to a resource that would normally be accessed via JIT. In this example, a service team member submits a job, such as a Pull Request in Azure DevOps, and another team member reviews and approves, at which point the Azure Safe Deployment Practices (SDP) automatically deploys. Group, Anonymous, and Temporary Accounts Group or shared accounts are not utilized within Azure unless necessary, where a local account cannot be deleted or disabled or is necessary for emergency access. For accounts tracked as approved exceptions, the credentials are stored in an approved secret management store, which tracks and monitors access to the credentials and ensures group or shared account usage is uniquely attributable to the user accessing it. This is accomplished by associating the secret store logs with the group or shared account usage. When a user accesses the credentials in the secret management store, that user is uniquely identified, ensuring non-repudiation and attributing user activity to the shared account. |
||
| 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 |
|