مشاركة عبر

Security Control v3: Identity management

  • مقالة

Identity Management covers controls to establish a secure identity and access controls using Azure Active Directory, including the use of single sign-on, strong authentications, managed identities (and service principals) for applications, conditional access, and account anomalies monitoring.

IM-1: Use centralized identity and authentication system

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Security Principle: Use a centralized identity and authentication system to govern your organization's identities and authentications for cloud and non-cloud resources.

Azure Guidance: 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-2: Protect identity and authentication systems

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Security Principle: 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

Azure Guidance: 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-3: Manage application identities securely and automatically

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/A AC-2, AC-3, IA-4, IA-5, IA-9 N/A

Security Principle: 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.

Azure Guidance: 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-4: Authenticate server and services

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
N/A IA-9 N/A

Security Principle: 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.

Azure Guidance: 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-5: Use single sign-on (SSO) for application access

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
12.5 IA-4, IA-2, IA-8 N/A

Security Principle: 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.

Azure Guidance: 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-6: Use strong authentication controls

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Security Principle: 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 Guidance: 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 Azure 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-7: Restrict resource access based on conditions

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Security Principle: 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.

Azure Guidance: 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.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-8: Restrict the exposure of credential and secrets

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Security Principle: Ensure that application developers securely handle credentials and secrets:

  • Avoid embedding the credentials and secrets into the code and configuration files
  • Use key vault or a secure key store service to store the credentials and secrets
  • Scan for credentials in source code.

Note: This is often governed and enforced through a secure software development lifecycle (SDLC) and DevOps security process.

Azure Guidance: Ensure that secrets and credentials are stored in secure locations such as Azure Key Vault, instead of embedding them into the code and configuration files.

  • Implement Azure DevOps Credential Scanner to identify credentials within the code.
  • For GitHub, use the native secret scanning feature to identify credentials or other form of secrets within the code.

Clients such as Azure Functions, Azure Apps services, and VMs can use managed identities to access Azure Key Vault securely. See Data Protection controls related to the use of Azure Key Vault for secrets management.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

IM-9: Secure user access to existing applications

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 N/A

Security Principle: In a hybrid environment, where you have on-premises applications or non-native cloud applications using legacy authentication, consider solutions such as cloud access security broker (CASB), application proxy, single sign-on (SSO) to govern the access to these applications for the following benefits:

  • Enforce a centralized strong authentication
  • Monitor and control risky end-user activities
  • Monitor and remediate risky legacy applications activities
  • Detect and prevent sensitive data transmission

Azure Guidance: Protect your on-premises and non-native cloud applications using legacy authentication by connecting them to:

  • Azure AD Application Proxy in conjunction with header-based authentication for publishing legacy on-premises applications to remote users with single sign-on (SSO) while explicitly validating the trustworthiness of both remote users and devices with Azure AD Conditional Access. If required, use third-party Software-Defined Perimeter (SDP) solution which can offer similar functionality.
  • Your existing third-party application delivery controllers and networks
  • Microsoft Defender for Cloud Apps, using it as a cloud access security broker (CASB) service to provide controls for monitoring a user's application sessions and blocking actions (for both legacy on-premises applications and cloud software as a service (SaaS) applications).

Note: VPNs are commonly used to access legacy applications, they often have only basic access control and limited session monitoring.

Implementation and additional context:

Customer Security Stakeholders (Learn more):