Microsoft Azure
| wdt_ID | AID | ASB ID | Domain | Recommendation | Guidance | Procedure | References |
|---|---|---|---|---|---|---|---|
| 1 | 1 | NS-1 | Network Security | Establish network segmentation boundaries | Ensure that your virtual network deployment aligns to your enterprise segmentation strategy defined in the GS-2 security control. Any workload that could incur higher risk for the organization should be in isolated virtual networks. Examples of high-risk workload include: - An application storing or processing highly sensitive data. - An external network-facing application accessible by the public or users outside of your organization. - An application using insecure architecture or containing vulnerabilities that cannot be easily remediated. To enhance your enterprise segmentation strategy, restrict or monitor traffic between internal resources using network controls. For specific, well-defined applications (such as a 3-tier app), this can be a highly secure "deny by default, permit by exception" approach by restricting the ports, protocols, source, and destination IPs of the network traffic. If you have many applications and endpoints interacting with each other, blocking traffic may not scale well, and you may only be able to monitor traffic. | Create a virtual network (VNet) as a fundamental segmentation approach in your Azure network, so resources such as VMs can be deployed into the VNet within a network boundary. To further segment the network, you can create subnets inside VNet for smaller sub-networks. Use network security groups (NSG) as a network layer control to restrict or monitor traffic by port, protocol, source IP address, or destination IP address. You can also use application security groups (ASGs) to simplify complex configuration. Instead of defining policy based on explicit IP addresses in network security groups, ASGs enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. | Azure Virtual Network concepts and best practices: https://docs.microsoft.com/azure/virtual-network/concepts-and-best-practices Add, change, or delete a virtual network subnet: https://docs.microsoft.com/azure/virtual-network/virtual-network-manage-subnet How to create a network security group with security rules: https://docs.microsoft.com/azure/virtual-network/tutorial-filter-network-traffic Understand and use application security groups: https://docs.microsoft.com/azure/virtual-network/network-security-groups-overview#application-security-groups |
| 2 | 2 | NS-2 | Network Security | Secure cloud services with network controls | Secure cloud services by establishing a private access point for the resources. You should also disable or restrict access from public network when possible. | Deploy private endpoints for all Azure resources that support the Private Link feature, to establish a private access point for the resources. You should also disable or restrict public network access to services where feasible. For certain services, you also have the option to deploy VNet integration for the service where you can restrict the VNET to establish a private access point for the service. | Understand Azure Private Link: https://docs.microsoft.com/azure/private-link/private-link-overview |
| 3 | 3 | NS-3 | Network Security | Deploy firewall at the edge of enterprise network | Deploy a firewall to perform advanced filtering on network traffic to and from external networks. You can also use firewalls between internal segments to support a segmentation strategy. If required, use custom routes for your subnet to override the system route when you need to force the network traffic to go through a network appliance for security control purpose. At a minimum, block known bad IP addresses and high-risk protocols, such as remote management (for example, RDP and SSH) and intranet protocols (for example, SMB and Kerberos). | Use Azure Firewall to provide fully stateful application layer traffic restriction (such as URL filtering) and/or central management over a large number of enterprise segments or spokes (in a hub/spoke topology). If you have a complex network topology, such as a hub/spoke setup, you may need to create user-defined routes (UDR) to ensure the traffic goes through the desired route. For example, you have option to use an UDR to redirect egress internet traffic through a specific Azure Firewall or a network virtual appliance. | How to deploy Azure Firewall: https://docs.microsoft.com/azure/firewall/tutorial-firewall-deploy-portal Virtual network traffic routing: https://docs.microsoft.com/azure/virtual-network/virtual-networks-udr-overview |
| 4 | 4 | NS-4 | Network Security | Deploy intrusion detection/intrusion prevention systems (IDS/IPS) | Use network intrusion detection and intrusion prevention systems (IDS/IPS) to inspect the network and payload traffic to or from your workload. Ensure that IDS/IPS is always tuned to provide high-quality alerts to your SIEM solution. For more in-depth host level detection and prevention capability, use host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution in conjunction with the network IDS/IPS. | Use Azure Firewall’s IDPS capability on your network to alert on and/or block traffic to and from known malicious IP addresses and domains. For more in-depth host level detection and prevention capability, deploy host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution, such as Microsoft Defender for Endpoint, at the VM level in conjunction with the network IDS/IPS. | Azure Firewall IDPS: https://docs.microsoft.com/azure/firewall/premium-features#idps Microsoft Defender for Endpoint capability: https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/overview-endpoint-detection-response |
| 5 | 5 | NS-5 | Network Security | Deploy DDOS protection | Deploy distributed denial of service (DDoS) protection to protect your network and applications from attacks. | Enable DDoS standard protection plan on your VNet to protect resources that are exposed to the public networks. | Manage Azure DDoS Protection Standard using the Azure portal: https://docs.microsoft.com/azure/virtual-network/manage-ddos-protection |
| 6 | 6 | NS-6 | Network Security | Deploy web application firewall | Deploy a web application firewall (WAF) and configure the appropriate rules to protect your web applications and APIs from application-specific attacks. | Use web application firewall (WAF) capabilities in Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) to protect your applications, services and APIs against application layer attacks at the edge of your network. Set your WAF in "detection" or "prevention mode," depending on your needs and threat landscape. Choose a built-in ruleset, such as OWASP Top 10 vulnerabilities, and tune it to your application. | How to deploy Azure WAF: https://docs.microsoft.com/azure/web-application-firewall/overview |
| 7 | 7 | NS-7 | Network Security | Simplify network security configuration | When managing a complex network environment, use tools to simplify, centralize and enhance the network security management. | Use the following features to simplify the implementation and management of the NSG and Azure Firewall rules: - Use Microsoft Defender for Cloud Adaptive Network Hardening to recommend NSG hardening rules that further limit ports, protocols and source IPs based on threat intelligence and traffic analysis result. - Use Azure Firewall Manager to centralize the firewall policy and route management of the virtual network. To simplify the firewall rules and network security groups implementation, you can also use the Azure Firewall Manager ARM (Azure Resource Manager) template. | Adaptive Network Hardening in Microsoft Defender for Cloud: https://docs.microsoft.com/azure/security-center/security-center-adaptive-network-hardening Azure Firewall Manager: https://docs.microsoft.com/azure/firewall-manager/overview Create an Azure Firewall and a firewall policy - ARM template https://docs.microsoft.com/azure/firewall-manager/quick-firewall-policy |
| 8 | 8 | NS-8 | Network Security | Detect and disable insecure services and protocols | Detect and disable insecure services and protocols at the OS, application, or software package layer. Deploy compensating controls if disabling insecure services and protocols are not possible. | Use Azure Sentinel’s built-in Insecure Protocol Workbook to discover the use of insecure services and protocols such as SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, Unsigned LDAP Binds, and weak ciphers in Kerberos. Disable insecure services and protocols that do not meet the appropriate security standard. Note: If disabling insecure services or protocols is not possible, use compensating controls such as blocking access to the resources through network security group, Azure Firewall, or Azure Web Application Firewall to reduce the attack surface. | Azure Sentinel insecure protocols workbook: https://docs.microsoft.com/azure/sentinel/quickstart-get-visibility#use-built-in-workbooks |
| 9 | 9 | NS-9 | Network Security | Connect on-premises or cloud network privately | Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment. | For lightweight connectivity between site-to-site or point-to-site, use Azure virtual private network (VPN) to create a secure connection between your on-premises site or end-user device to the Azure virtual network. For enterprise-level high performance connection, use Azure ExpressRoute (or Virtual WAN) to connect Azure datacenters and on-premises infrastructure in a co-location environment. When connecting two or more Azure virtual networks together, use virtual network peering. Network traffic between peered virtual networks is private and is kept on the Azure backbone network. | Azure VPN overview: https://docs.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpngateways What are the ExpressRoute connectivity models: https://docs.microsoft.com/azure/expressroute/expressroute-connectivity-models Virtual network peering: https://docs.microsoft.com/azure/virtual-network/virtual-network-peering-overview |
| 10 | 10 | NS-10 | Network Security | Ensure Domain Name System (DNS) security | Ensure that Domain Name System (DNS) security configuration protects against known risks: - Use trusted authoritative and recursive DNS services across your cloud environment to ensure the client (such as operating systems and applications) receive the correct resolution result. - Separate the public and private DNS resolution so the DNS resolution process for the private network can be isolated from the public network. - Ensure your DNS security strategy also includes mitigations against common attacks, such as dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, and so on. | Use Azure recursive DNS or a trusted external DNS server in your workload recursive DNS setup, such as in VM's operating system or in the application. Use Azure Private DNS for private DNS zone setup where the DNS resolution process does not leave the virtual network. Use a custom DNS to restrict the DNS resolution which only allows the trusted resolution to your client. Use Azure Defender for DNS for the advanced protection against the following security threats to your workload or your DNS service: - Data exfiltration from your Azure resources using DNS tunneling - Malware communicating with command-and-control server - Communication with malicious domains as phishing and crypto mining - DNS attacks in communication with malicious DNS resolvers You can also use Azure Defender for App Service to detect dangling DNS records if you decommission an App Service website without removing its custom domain from your DNS registrar. | Azure DNS overview: https://docs.microsoft.com/azure/dns/dns-overview Secure Domain Name System (DNS) Deployment Guide: https://csrc.nist.gov/publications/detail/sp/800-81/2/final Azure Private DNS: https://docs.microsoft.com/azure/dns/private-dns-overview Azure Defender for DNS: https://docs.microsoft.com/azure/security-center/defender-for-dns-introduction Prevent dangling DNS entries and avoid subdomain takeover: https://docs.microsoft.com/azure/security/fundamentals/subdomain-takeover |
| 11 | 11 | DP-1 | Data Protection | Discover, classify, and label sensitive data | Establish and maintain an inventory of the sensitive data, based on the defined sensitive data scope. Use tools to discover, classify and label the in- scope sensitive data. | Use tools such as Azure Purview, Azure Information Protection and Azure SQL Data Discovery and Classification to centrally scan, classify and label the sensitive data that reside in the Azure, on-premises, Microsoft 365, and other locations. | Data classification overview: https://docs.microsoft.com/azure/cloud-adoption-framework/govern/policy-compliance/data-classification Label your sensitive data using Azure Purview: https://docs.microsoft.com/azure/purview/create-sensitivity-label Tag sensitive information using Azure Information Protection: https://docs.microsoft.com/azure/information-protection/what-is-information-protection How to implement Azure SQL Data Discovery: https://docs.microsoft.com/azure/sql-database/sql-database-data-discovery-and-classification Azure Purview data sources: https://docs.microsoft.com/azure/purview/purview-connector-overview#purview-data-sources |
| 12 | 12 | DP-2 | Data Protection | Monitor anomalies and threats targeting sensitive data | Monitor for anomalies around sensitive data, such as unauthorized transfer of data to locations outside of enterprise visibility and control. This typically involves monitoring for anomalous activities (large or unusual transfers) that could indicate unauthorized data exfiltration. | Use Azure Information protection (AIP) to monitor the data that has been classified and labeled. Use Azure Defender for Storage, Azure Defender for SQL and Azure Cosmos DB to alert on anomalous transfer of information that might indicate unauthorized transfers of sensitive data information. Note: If required for compliance of data loss prevention (DLP), you can use a host based DLP solution from Azure Marketplace or a Microsoft 365 DLP solution to enforce detective and/or preventative controls to prevent data exfiltration. | Enable Azure Defender for SQL: https://docs.microsoft.com/azure/azure-sql/database/azure-defender-for-sql Enable Azure Defender for Storage: https://docs.microsoft.com/azure/storage/common/storage-advanced-threat-protection?tabs=azure-security-center Azure Purview data insights: https://docs.microsoft.com/azure/purview/concept-insights |
| 13 | 13 | DP-3 | Data Protection | Encrypt sensitive data in transit | Protect the data in transit against 'out of band' attacks (such as traffic capture) using encryption to ensure that attackers cannot easily read or modify the data. Set the network boundary and service scope where data in transit encryption is mandatory inside and outside of the network. While this is optional for traffic on private networks, this is critical for traffic on external and public networks. | Enforce secure transfer in services such as Azure Storage, where a native data in transit encryption feature is built in. Enforce HTTPS for workload web application and services by ensuring that any clients connecting to your Azure resources use transportation layer security (TLS) v1.2 or later. For remote management of VMs, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol. Note: Data in transit encryption is enabled for all Azure traffic traveling between Azure datacenters. TLS v1.2 or later is enabled on most Azure PaaS services by default. | Double encryption for Azure data in transit: https://docs.microsoft.com/azure/security/fundamentals/double-encryption#data-in-transit Understand encryption in transit with Azure: https://docs.microsoft.com/azure/security/fundamentals/encryption-overview#encryption-of-data-in-transit Information on TLS Security: https://docs.microsoft.com/security/engineering/solving-tls1-problem Enforce secure transfer in Azure storage: https://docs.microsoft.com/azure/storage/common/storage-require-secure-transfer?toc=/azure/storage/blobs/toc.json#require-secure-transfer-for-a-new-storage-account |
| 14 | 14 | DP-4 | Data Protection | Enable data at rest encryption by default | To complement access controls, data at rest should be protected against 'out of band' attacks (such as accessing underlying storage) using encryption. This helps ensure that attackers cannot easily read or modify the data. | Many Azure services have data at rest encryption enabled by default at the infrastructure layer using a service-managed key. Where technically feasible and not enabled by default, you can enable data at rest encryption in the Azure services, or in your VMs for storage level, file level, or database level encryption. | Understand encryption at rest in Azure: https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#encryption-at-rest-in-microsoft-cloud-services Data at rest double encryption in Azure: https://docs.microsoft.com/azure/security/fundamentals/encryption-models Encryption model and key management table: https://docs.microsoft.com/azure/security/fundamentals/encryption-models |
| 15 | 15 | DP-5 | Data Protection | Use customer-managed key option in data at rest encryption when required | If required for regulatory compliance, define the use case and service scope where customer-managed key option is needed. Enable and implement data at rest encryption using customer-managed key in services. | Azure also provides encryption option using keys managed by yourself (customer-managed keys) for certain services. However, using customer-managed key option requires additional operational efforts to manage the key lifecycle. This may include encryption key generation, rotation, revoke and access control, etc. | Encryption model and key management table: https://docs.microsoft.com/azure/security/fundamentals/encryption-models Services that support encryption using customer-managed key: https://docs.microsoft.com/azure/security/fundamentals/encryption-models#supporting-services How to configure customer managed encryption keys in Azure Storage: https://docs.microsoft.com/azure/storage/common/storage-encryption-keys-portal |
| 16 | 16 | DP-6 | Data Protection | Use a secure key management process | Document and implement an enterprise cryptographic key management standard, processes, and procedures to control your key lifecycle. When there is a need to use customer-managed key in the services, use a secured key vault service for key generation, distribution, and storage. Rotate and revoke your keys based on the defined schedule and when there is a key retirement or compromise. | Use Azure Key Vault to create and control your encryption keys life cycle, including key generation, distribution, and storage. Rotate and revoke your keys in Azure Key Vault and your service based on the defined schedule and when there is a key retirement or compromise. When there is a need to use customer-managed key (CMK) in the workload services or applications, ensure you follow the best practices: - Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your key vault. - Ensure keys are registered with Azure Key Vault and implement via key IDs in each service or application. If you need to bring your own key (BYOK) to the services (i.e., importing HSM-protected keys from your on-premises HSMs into Azure Key Vault), follow the recommended guideline to perform the key generation and key transfer. Note: Refer to the below for the FIPS 140-2 level for Azure Key Vault types and FIPS compliance level. - Software-protected keys in vaults (Premium & Standard SKUs): FIPS 140-2 Level 1 - HSM-protected keys in vaults (Premium SKU): FIPS 140-2 Level 2 - HSM-protected keys in Managed HSM: FIPS 140-2 Level 3 | Azure Key Vault overview: https://docs.microsoft.com/azure/key-vault/general/overview Azure data encryption at rest--Key Hierarchy: https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#key-hierarchy BYOK(Bring Your Own Key) specification: https://docs.microsoft.com/azure/key-vault/keys/byok-specification |
| 17 | 17 | DP-7 | Data Protection | Use a secure certificate management process | Document and implement an enterprise certificate management standard, processes and procedures which includes the certificate lifecycle control, and certificate policies (if a public key infrastructure is needed). Ensure certificates used by the critical services in your organization are inventoried, tracked, monitored, and renewed timely using automated mechanism to avoid service disruption. | Use Azure Key Vault to create and control the certificate lifecycle, including creation/import, rotation, revocation, storage, and purge of the certificate. Ensure the certificate generation follows the defined standard without using any insecure properties, such as insufficient key size, overly long validity period, insecure cryptography and so on. Setup automatic rotation of the certificate in Azure Key Vault and Azure service (if supported) based on the defined schedule and when there is a certificate expiration. If automatic rotation is not supported in the front application, use a manual rotation in Azure Key Vault. Avoid using self-signed certificate and wildcard certificate in your critical services due to the limited security assurance. Instead, you can create public signed certificate in Azure Key Vault. The following CAs are the current partnered providers with Azure Key Vault. - DigiCert: Azure Key Vault offers OV TLS/SSL certificates with DigiCert. - GlobalSign: Azure Key Vault offers OV TLS/SSL certificates with GlobalSign. Note: Use only approved Certificate Authority (CA) and ensure the known bad CA root/intermediate certificates and certificates issued by these CAs are disabled. | Get started with Key Vault certificates: https://docs.microsoft.com/azure/key-vault/certificates/certificate-scenarios Certificate Access Control in Azure Key Vault: https://docs.microsoft.com/azure/key-vault/certificates/certificate-access-control |
| 18 | 18 | DP-8 | Data Protection | Ensure security of key and certificate repository | Ensure the security of the key vault service used for the cryptographic key and certificate lifecycle management. Harden your key vault service through access control, network security, logging and monitoring and backup to ensure keys and certificates are always protected using the maximum security. | Secure your cryptographic keys and certificates by hardening your Azure Key Vault service through the following controls: - Restrict the access to keys and certificates in Azure Key Vault using built-in access policies or Azure RBAC to ensure the least privileges principle are in place for management plane access and data plane access. - Secure the Azure Key Vault using Private Link and Azure Firewall to ensure the minimal exposure of the service - Ensure separation of duties is place for users who manages encryption keys not have the ability to access encrypted data, and vice versa. - Use managed identity to access keys stored in the Azure Key Vault in your workload applications. - Never have the keys stored in plaintext format outside of the Azure Key Vault. - When purging data, ensure your keys are not deleted before the actual data, backups and archives are purged. - Backup your keys and certificates using the Azure Key Vault. Enable soft delete and purge protection to avoid accidental deletion of keys. - Turn on Azure Key Vault logging to ensure the critical management plane and data plane activities are logged. | Azure Key Vault overview: https://docs.microsoft.com/azure/key-vault/general/overview Azure Key Vault security best practices: https://docs.microsoft.com/azure/key-vault/general/best-practices Use managed identity to access Azure Key Vault: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-nonaad |
| 19 | 19 | IM-1 | Identity Management | Use centralized identity and authentication system | Use a centralized identity and authentication system to govern your organization's identities and authentications for cloud and non-cloud resources. | Azure Active Directory (Azure AD) is Azure's identity and authentication management service. You should standardize on Azure AD to govern your organization's identity and authentication in: - Microsoft cloud resources, such as the Azure Storage, Azure Virtual Machines (Linux and Windows), Azure Key Vault, PaaS, and SaaS applications. - Your organization's resources, such as applications on Azure, third-party applications running on your corporate network resources, and third-party SaaS applications. - Your enterprise identities in Active Directory by synchronization to Azure AD to ensure a consistent and centrally managed identity strategy. Note: As soon as it is technically feasible, you should migrate on-premises Active Directory based applications to Azure AD. This could be an Azure AD Enterprise Directory, Business to Business configuration, or Business to consumer configuration. | Tenancy in Azure AD: https://docs.microsoft.com/azure/active-directory/develop/single-and-multi-tenant-apps How to create and configure an Azure AD instance: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-access-create-new-tenant Define Azure AD tenants: https://azure.microsoft.com/resources/securing-azure-environments-with-azure-active-directory/ Use external identity providers for an application: https://docs.microsoft.com/azure/active-directory/b2b/identity-providers |
| 20 | 20 | IM-2 | Identity Management | Protect identity and authentication systems | Secure your identity and authentication system as a high priority in your organization's cloud security practice. Common security controls include: - Restrict privileged roles and accounts - Require strong authentication for all privileged access - Monitor and audit high risk activities | Use the Azure AD security baseline and the Azure AD Identity Secure Score to evaluate your Azure AD identity security posture, and remediate security and configuration gaps. The Azure AD Identity Secure Score evaluates Azure AD for the following configurations: -Use limited administrative roles - Turn on user risk policy - Designate more than one global admin - Enable policy to block legacy authentication - Ensure all users can complete multi-factor authentication for secure access - Require MFA for administrative roles - Enable self-service password reset - Do not expire passwords - Turn on sign-in risk policy - Do not allow users to grant consent to unmanaged applications Note: Follow published best practices for all other identity components, including the on-premises Active Directory and any third party capabilities, and the infrastructures (such as operating systems, networks, databases) that host them. | What is the identity secure score in Azure AD: https://docs.microsoft.com/azure/active-directory/fundamentals/identity-secure-score Best Practices for Securing Active Directory: https://docs.microsoft.com/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory |
| 21 | 21 | IM-3 | Identity Management | Manage application identities securely and automatically | Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credential to ensure the security of the identities. | Use Azure managed identities, which can authenticate to Azure services and resources that support Azure AD authentication. Managed identity credentials are fully managed, rotated, and protected by the platform, avoiding hard-coded credentials in source code or configuration files. For services that don't support managed identities, use Azure AD to create a service principal with restricted permissions at the resource level. It is recommended to configure service principals with certificate credentials and fall back to client secrets for authentication. | Azure managed identities: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview Services that support managed identities for Azure resources: https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities Azure service principal: https://docs.microsoft.com/powershell/azure/create-azure-service-principal-azureps Create a service principal with certificates: https://docs.microsoft.com/azure/active-directory/develop/howto-authenticate-service-principal-powershell |
| 22 | 22 | IM-4 | Identity Management | Authenticate server and services | Authenticate remote servers and services from your client side to ensure you are connecting to trusted server and services. The most common server authentication protocol is Transport Layer Security (TLS), where the client-side (often a browser or client device) verifies the server by verifying the server’s certificate was issued by a trusted certificate authority. Note: Mutual authentication can be used when both the server and the client authenticate one-another. | Many Azure services support TLS authentication by default. For the services supporting TLS enable/disable switch by the user, ensure it's always enabled to support the server/service authentication. Your client application should also be designed to verify server/service identity (by verifying the server’s certificate issued by a trusted certificate authority) in the handshake stage. | Enforce Transport Layer Security (TLS) for a storage account: https://docs.microsoft.com/azure/storage/common/transport-layer-security-configure-minimum-version?tabs=portal#use-azure-policy-to-enforce-the-minimum-tls-version |
| 23 | 23 | IM-5 | Identity Management | Use single sign-on (SSO) for application access | Use single sign-on (SSO) to simplify the user experience for authenticating to resources including applications and data across cloud services and on-premises environments. | Use Azure AD for workload application access through Azure AD single sign-on (SSO), obviating the need for multiple accounts. Azure AD provides identity and access management to Azure resources (management plane including CLI, PowerShell, portal), cloud applications, and on-premises applications. Azure AD supports SSO for enterprise identities such as corporate user identities, as well as external user identities from trusted third-party and public users. | Understand application SSO with Azure AD: https://docs.microsoft.com/azure/active-directory/manage-apps/what-is-single-sign-on |
| 24 | 24 | IM-6 | Identity Management | Use strong authentication controls | Enforce strong authentication controls (strong passwordless authentication or multi-factor authentication) with your centralized identity and authentication management system for all access to resources. Authentication based on password credentials alone is considered legacy, as it is insecure and does not stand up to popular attack methods. When deploying strong authentication, configure administrators and privileged users first, to ensure the highest level of the strong authentication method, quickly followed by rolling out the appropriate strong authentication policy to all users. Note: If legacy password-based authentication is required for legacy applications and scenarios, ensure password security best practices such as complexity requirements, are followed. | Azure AD supports strong authentication controls through passwordless methods and multi-factor authentication (MFA). - Passwordless authentication: Use passwordless authentication as your default authentication method. There are three options available in passwordless authentication: Windows Hello for Business, Microsoft Authenticator app phone sign-in, and FIDO 2Keys. In addition, customers can use on-premises authentication methods such as smart cards. - Multi-factor authentication: Azure MFA can be enforced on all users, select users, or at the per-user level based on sign-in conditions and risk factors. Enable Azure MFA and follow Microsoft Defender for Cloud identity and access management recommendations for your MFA setup. If legacy password-based authentication is still used for Azure AD authentication, be aware that cloud-only accounts (user accounts created directly in Azure) have a default baseline password policy. And hybrid accounts (user accounts that come from on-premises Active Directory) follow the on-premises password policies. For third-party applications and services that may have default IDs and passwords, you should disable or change them during initial service setup. | How to enable MFA in Azure: https://docs.microsoft.com/azure/active-directory/authentication/howto-mfa-getstarted Introduction to passwordless authentication options for Azure Active Directory: https://docs.microsoft.com/azure/active-directory/authentication/concept-authentication-passwordless Azure AD default password policy: https://docs.microsoft.com/azure/active-directory/authentication/concept-sspr-policy#password-policies-that-only-apply-to-cloud-user-accounts Eliminate bad passwords using Azure AD Password Protection: https://docs.microsoft.com/azure/active-directory/authentication/concept-password-ban-bad Block legacy authentication: https://docs.microsoft.com/azure/active-directory/conditional-access/block-legacy-authentication |
| 25 | 25 | IM-7 | Identity Management | Restrict resource access based on conditions | Explicitly validate trusted signals to allow or deny user access to resources, as part of a zero-trust access model. Signals to validate should include strong authentication of user account, behavioral analytics of user account, device trustworthiness, user or group membership, locations and so on. | Use Azure AD conditional access for more granular access controls based on user-defined conditions, such as requiring user logins from certain IP ranges (or devices) to use MFA. Azure AD Conditional Access allows you to enforce access controls on your organization’s apps based on certain conditions. Define the applicable conditions and criteria for Azure AD conditional access in the workload. Consider the following common use cases: - Requiring multi-factor authentication for users with administrative roles - Requiring multi-factor authentication for Azure management tasks - Blocking sign-ins for users attempting to use legacy authentication protocols - Requiring trusted locations for Azure AD Multi-Factor Authentication registration - Blocking or granting access from specific locations - Blocking risky sign-in behaviors - Requiring organization-managed devices for specific applications Note: A granular authentication session management can also be used to through Azure AD conditional access policy for controls such as sign-in frequency and persistent browser session. | Azure Conditional Access overview: https://docs.microsoft.com/azure/active-directory/conditional-access/overview Common Conditional Access policies: https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-policy-common Conditional Access insights and reporting: https://docs.microsoft.com/azure/active-directory/conditional-access/howto-conditional-access-insights-reporting Configure authentication session management with Conditional Access: https://docs.microsoft.com/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime |
| AID |