Azure security baseline for Azure Active Directory
This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Azure Active Directory. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Active Directory.
When a feature has relevant Azure Policy Definitions they are listed in this baseline, to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.
Note
Controls not applicable to Azure Active Directory, and those for which the global guidance is recommended verbatim, have been excluded. To see how Azure Active Directory completely maps to the Azure Security Benchmark, see the full Azure Active Directory security baseline mapping file.
Network Security
For more information, see the Azure Security Benchmark: Network Security.
NS-6: Simplify network security rules
Guidance: Use Azure Virtual Network Service Tags to define network access controls on network security groups or Azure Firewall configured for your Azure Active Directory resources. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name, like 'AzureActiveDirectory' in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.
Responsibility: Customer
NS-7: Secure Domain Name Service (DNS)
Guidance: Azure Active Directory does not expose its underlying DNS configurations; these settings are maintained by Microsoft.
Responsibility: Microsoft
Identity Management
For more information, see the Azure Security Benchmark: Identity Management.
IM-1: Standardize Azure Active Directory as the central identity and authentication system
Guidance: Use Azure Active Directory (Azure AD) as the default identity and access management service. You should standardize Azure AD to govern your organization’s identity and access management in:
- Microsoft Cloud resources, such as the Azure portal, Azure Storage, Azure Virtual Machine (Linux and Windows), Azure Key Vault, PaaS, and SaaS applications.
- Your organization's resources, such as applications on Azure or your corporate network resources.
Securing Azure AD should be a high priority in your organization’s cloud security practice. Azure AD provides an identity secure score to help you assess identity security posture relative to Microsoft’s best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture.
Note: Azure AD supports external identity that allows users without a Microsoft account to sign in to their applications and resources with their external identity.
Responsibility: Customer
IM-2: Manage application identities securely and automatically
Guidance: Use Managed Identity for Azure Resources for non-human accounts such as services or automation, it is recommended to use Azure-managed identity feature instead of creating a more powerful human account to access or execute your resources. You can natively authenticate to Azure services/resources that supports Azure Active Directory (Azure AD) authentication through pre-defined access grant rule without using credential hard coded in source code or configuration files. You cannot assign Azure managed identities to Azure AD resources but Azure AD is the mechanism to authenticate with managed identities assigned to other service's resources.
Responsibility: Customer
IM-3: Use Azure AD single sign-on (SSO) for application access
Guidance: Use Azure Active Directory to provide identity and access management to Azure resources, cloud applications, and on-premises applications. This includes enterprise identities such as employees, as well as external identities such as partners, vendors, and suppliers. This enables single sign-on (SSO) to manage and secure access to your organization’s data and resources on-premises and in the cloud. Connect all your users, applications, and devices to the Azure AD for seamless, secure access and greater visibility and control.
Responsibility: Customer
Privileged Access
For more information, see the Azure Security Benchmark: Privileged Access.
PA-1: Protect and limit highly privileged users
Guidance: The most critical built-in roles are Azure AD are Global Administrator and the Privileged Role Administrator, as users assigned to these two roles can delegate administrator roles:
Global Administrator: Users with this role have access to all administrative features in Azure AD, as well as services that use Azure AD identities.
Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, as well as within Azure AD Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units.
Note: You may have other critical roles that need to be governed if you use custom roles with certain privileged permissions assigned. And you may also want to apply similar controls to the administrator account of critical business assets.
Azure AD has highly privileged accounts: the users and service principals that are directly or indirectly assigned to, or eligible for, the Global Administrator or Privileged Role Administrator roles, and other highly privileged roles in Azure AD and Azure.
Limit the number of highly privileged accounts and protect these accounts at an elevated level because users with this privilege can directly or indirectly read and modify every resource in your Azure environment.
You can enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD Privileged Identity Management (PIM). JIT grants temporary permissions to perform privileged tasks only when users need it. PIM can also generate security alerts when there is suspicious or unsafe activity in your Azure AD organization.
Responsibility: Customer
PA-3: Review and reconcile user access regularly
Guidance: Review user account access assignments regularly to ensure the accounts and their access are valid, especially focused on the highly privileged roles including Global Administrator and Privileged Role Administrator. You can use Azure Active Directory (Azure AD) access reviews to review group memberships, access to enterprise applications, and role assignments, both for Azure AD roles and Azure roles. Azure AD reporting can provide logs to help discover stale accounts. You can also use Azure AD Privileged Identity Management to create access review report workflow to facilitate the review process.
In addition, Azure Privileged Identity Management can also be configured to alert when an excessive number of administrator accounts are created, and to identify administrator accounts that are stale or improperly configured.
Create an access review of Azure AD roles in Privileged Identity Management (PIM)
Create an access review of Azure resource roles in Privileged Identity Management (PIM)
Responsibility: Customer
PA-6: Use privileged access workstations
Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrators, developers, and critical service operators. Use highly secured user workstations and/or Azure Bastion for administrative tasks. Use Azure Active Directory, Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration including strong authentication, software and hardware baselines, restricted logical and network access.
Responsibility: Customer
PA-7: Follow just enough administration (least privilege principle)
Guidance: Customers can configure their Azure Active Directory (Azure AD) deployment for least privilege, by assigning users to the roles with the minimum permissions needed for users to complete their administrative tasks.
Responsibility: Customer
PA-8: Choose approval process for Microsoft support
Guidance: Azure Active Directory doesn't support customer lockbox. Microsoft may work with customers through non-lockbox methods for approval to access customer data.
Responsibility: Shared
Data Protection
For more information, see the Azure Security Benchmark: Data Protection.
DP-2: Protect sensitive data
Guidance: Consider the following guidance for implementing protection of your sensitive data:
Isolation: A directory is the data boundary by which the Azure Active Directory (Azure AD) services store and process data for a customer. Customers should determine where they want most of their Azure AD Customer Data to reside by setting the Country property in their directory.
Segmentation: The global administrator's role has full control of all directory data, and the rules that govern access and processing instructions. A directory may be segmented into administrative units, and provisioned with users and groups to be managed by administrators of those units, Global administrators may delegate responsibility to other principles in their organization by assigning them to pre-defined roles or custom roles they can create.
Access: Permissions can be applied at a user, group, role, application, or device. The assignment may be permanent or temporal per Privileged Identity Management configuration.
Encryption: Azure AD encrypts all data at rest or in transit. The offering does not allow customers to encrypt directory data with their own encryption key.
To determine how their selected country maps to the physical location of their directory see the 'Where is your data located article'.
As the customer uses various Azure AD tools, features, and applications that interact with their directory, use the article Azure Active Directory – Where is your data located?
Responsibility: Customer
DP-4: Encrypt sensitive information in transit
Guidance: To complement access controls, data in transit should be protected against ‘out of band’ attacks (e.g. traffic capture) using encryption to ensure that attackers cannot easily read or modify the data.
Azure AD supports data encryption in transit with TLS v1.2 or greater.
While this is optional for traffic on private networks, this is critical for traffic on external and public networks. For HTTP traffic, ensure that any clients connecting to your Azure resources can negotiate TLS v1.2 or greater. For remote management, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol. Obsoleted SSL, TLS, and SSH versions and protocols, and weak ciphers should be disabled.
By default, Azure provides encryption for data in transit between Azure data centers.
Responsibility: Customer
DP-5: Encrypt sensitive data at rest
Guidance: To complement access controls, Azure AD encrypts data at rest to protect against ‘out of band’ attacks (such as accessing underlying storage) using encryption. This helps ensure that attackers cannot easily read or modify the data.
Responsibility: Microsoft
Asset Management
For more information, see the Azure Security Benchmark: Asset Management.
AM-1: Ensure security team has visibility into risks for assets
Guidance: Ensure security teams are granted Security Reader permissions in your Azure tenant and subscriptions so they can monitor for security risks using Microsoft Defender for Cloud.
Depending on how security team responsibilities are structured, monitoring for security risks could be the responsibility of a central security team or a local team. That said, security insights and risks must always be aggregated centrally within an organization.
Security Reader permissions can be applied broadly to an entire tenant (Root Management Group) or scoped to management groups or specific subscriptions.
Note: Additional permissions might be required to get visibility into workloads and services.
Responsibility: Customer
Logging and Threat Detection
For more information, see the Azure Security Benchmark: Logging and Threat Detection.
LT-1: Enable threat detection for Azure resources
Guidance: Use the Azure Active Directory (Azure AD) Identity Protection built-in threat detection capability for your Azure AD resources.
Azure AD produces activity logs that are often used for threat detection and threat hunting. Azure AD sign-in logs provide a record of authentication and authorization activity for users, services, and apps. Azure AD audit logs track changes made to an Azure AD tenant, including changes that improve or diminish security posture.
Responsibility: Customer
LT-2: Enable threat detection for Azure identity and access management
Guidance: Azure Active Directory (Azure AD) provides the following user logs that can be viewed in Azure AD reporting or integrated with Azure Monitor, Azure Sentinel or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:
- Sign-ins – The sign-ins report provides information about the usage of managed applications and user sign-in activities.
- Audit logs - Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles and policies.
- Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
- Risky users - A risky user is an indicator for a user account that might have been compromised.
Identity Protection risk detections are enabled by default and require no onboarding process. The granularity or risk data is determined by license SKU.
Responsibility: Customer
LT-4: Enable logging for Azure resources
Guidance: Azure Active Directory (Azure AD) produces activity logs. Unlike some Azure services, Azure AD does not make a distinction between activity and resource logs. Activity logs are automatically available in the Azure AD section of the Azure portal, and can be exported to Azure Monitor, Azure Event Hubs, Azure Storage, SIEMs, and other locations.
Sign-ins – The sign-ins report provides information about the usage of managed applications and user sign-in activities.
Audit logs - Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles and policies.
Azure AD also provides security-related logs that can be viewed in Azure AD reporting or integrated with Azure Monitor, Azure Sentinel or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:
- Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
- Risky users - A risky user is an indicator for a user account that might have been compromised.
Identity Protection risk detections are enabled by default and require no onboarding process. The granularity or risk data is determined by license SKU.
Responsibility: Customer
LT-5: Centralize security log management and analysis
Guidance: We recommend the following guidelines when customers want to centralize their security logs for easier threat hunting and security posture analysis:
Centralize logging storage and analysis to enable correlation. For each log source within Azure AD, ensure you have assigned a data owner, access guidance, storage location, what tools are used to process and access the data, and data retention requirements.
Ensure you are integrating Azure activity logs into your central logging. Ingest logs via Azure Monitor to aggregate security data generated by endpoint devices, network resources, and other security systems. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, and use Azure Storage accounts for long term and archival storage.
In addition, enable and onboard data to Azure Sentinel or a third-party SIEM.
Many organizations choose to use Azure Sentinel for “hot” data that is used frequently and Azure Storage for “cold” data that is used less frequently.
Responsibility: Customer
LT-6: Configure log storage retention
Guidance: Ensure that any storage accounts or Log Analytics workspaces used for storing Azure Active Directory sign-in logs, audit logs, and risk data logs has the log retention period set according to your organization's compliance regulations.
In Azure Monitor, you can set your Log Analytics workspace retention period according to your organization's compliance regulations. Use Azure Storage, Data Lake or Log Analytics workspace accounts for long-term and archival storage.
Responsibility: Customer
LT-7: Use approved time synchronization sources
Guidance: Azure Active Directory (Azure AD) does not support configuring your own time synchronization sources. The Azure AD service relies on Microsoft time synchronization sources, and is not exposed to customers for configuration.
Responsibility: Microsoft
Posture and Vulnerability Management
For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.
PV-1: Establish secure configurations for Azure services
Guidance: Microsoft identity and access management solutions help IT protect access to applications and resources across on-premises and in the cloud. It is important that organizations follow security best practices to ensure their Identity and access management implementation is secure and more resilient to attacks.
Based on your Identity and access management implementation strategy your organization should follow the Microsoft best practice guidance to secure your identity infrastructure.
Organizations that collaborate with external partners should additionally assess and implement appropriate governance, security, and compliance configurations to reduce security risk and protect sensitive resources.
Azure Identity Management and access control security best practices
Securing external collaboration in Azure Active Directory and Microsoft 365
Responsibility: Customer
PV-2: Sustain secure configurations for Azure services
Guidance: Microsoft Secure Score provides organizations a measurement of their security posture and recommendations that can help protect organizations from threats. It is recommended that organizations routinely review their Secure Score for suggested improvement actions to improve their identity security posture.
Responsibility: Customer
PV-8: Conduct regular attack simulation
Guidance: As required, conduct penetration testing or red team activities on your Azure resources and ensure remediation of all critical security findings. Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests are not in violation of Microsoft policies. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.
Responsibility: Shared
Next steps
- See the Azure Security Benchmark V2 overview
- Learn more about Azure security baselines
Feedback
Submit and view feedback for