Security Control: Identity management

  • Article

Identity Management covers controls to establish a secure identity and access controls using identity and access management systems, 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 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.

For the Azure services that apply, avoid use of local authentication methods and instead use Azure Active Directory to centralize your service authentications.

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.

Azure implementation and additional context:

AWS guidance: AWS IAM (Identity and Access Management) is AWS' default identity and authentication management service. Use AWS IAM to govern your AWS identity and access management. Alternatively, through AWS and Azure Single Sign-On (SSO), you can also use Azure AD to manage the identity and access control of AWS to avoid managing duplicate accounts separately in two cloud platforms.

AWS supports Single Sign-On which allows you to bridge your corporate's third party identities (such as Windows Active Directory, or other identity stores) with the AWS identities to avoid creating duplicate accounts to access AWS resources.

AWS implementation and additional context:

GCP guidance: Google Cloud's Identity and Access Management (IAM) system is Google Cloud's default identity and authentication management service used for Google Cloud Identity accounts. Use Google Cloud IAM to govern your GCP identity and access management. Alternatively, through the Google Cloud Identity and Azure Sigle Sign-On (SSO), you can also use Azure AD to manage the identity and access control of GCP to avoid managing duplicate accounts separately in a mutli-cloud environment.

Google Cloud Identity is the identity provider for all Google services. It supports Single Sign-On which allows you to bridge your corporate's third party identities (such as Windows Active Directory, or other identity stores) with Google Cloud identities to avoid creating duplicate accounts to access GCP resources.

Note: Using Google Cloud Directory Sync. Google provides connector tool that integrates with most enterprise LDAP management systems and synchronizes identities on a schedule. By configuring a Cloud Identity account and sing Google Cloud Directory Sync, you can configure which of your user accounts – including users, groups , and user profiles, aliases and more – will synchronize on a schedule between your local identity management system and your GCP system.

GCP 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

Use Azure AD Identity Protection to detect, investigate, and remediate identity-based risks. To similarly protect your on-premises Active Directory domain, use Defender for Identity.

Note: Follow published best practices for all other identity components, including your on-premises Active Directory and any third party capabilities, and the infrastructures (such as operating systems, networks, databases) that host them.

Azure implementation and additional context:

AWS guidance: Use the following security best practices to secure your AWS IAM:

  • Set up AWS account root user access keys for emergency access as described in PA-5 (Set up emergency access)
  • Follow least privilege principles for access assignments
  • Leverage IAM groups to apply policies instead of individual user(s).
  • Follow strong authentication guidance in IM-6 (Use strong authentication controls) for all users
  • Use AWS Organizations SCP (Service Control Policy) and permission boundaries
  • Use IAM Access Advisor to audit service access
  • Use IAM credential report to track user accounts and credential status

Note: Follow published best practices if you have other identity and authentication systems, e.g., follow the Azure AD security baseline if you use Azure AD to manage AWS identity and access.

AWS implementation and additional context:

GCP guidance: Use the following security best practices to secure to your Google Cloud IAM and Cloud Identity services for your organizations:

  • Set up a super admin account for emergency access by following the recommendations in PA-5 ("Set up emergency access").
  • Create a super admin email address (as the Google Workspace or Cloud Identity super admin account) and this account should be not specific to a particular user in case an emergency recovery is needed.
  • Follow least privilege and separation of duties principles
  • Avoid using super admin account for daily activities
  • Leverage Google Cloud Identity groups to apply policies instead of applying policies to individual user(s).
  • Follow strong authentication guidance as described in IM-6 ("Use strong authentication controls") for all users that have elevated privileges.
  • Use IAM policies to restrict access to resources
  • Use the Organization Policy Service to control and configure constraints on resources
  • Use IAM audit logging within Cloud Audit logs to review privileged activities

Note: Follow published best practices if you have other identity and authentication systems, e.g., follow the Azure AD security baseline if you use Azure AD to manage GCP identity and access.

GCP 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 credentials 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.

Azure implementation and additional context:

AWS guidance: Use AWS IAM roles instead of creating user accounts for resources that support this feature. IAM roles are managed by the platform at the backend and the credentials are temporary and rotated automatically. This avoids creating long-term access keys or a username/password for applications and hard-coded credentials in source code or configuration files.

You may use service-linked roles which are attached with pre-defined permission policies for access between AWS services instead of customizing your own role permissions for the IAM roles.

Note: For services that don't support IAM roles, use access keys but follow the security best practice such as IM-8 Restrict the exposure of credential and secrets to secure your keys.

AWS implementation and additional context:

GCP guidance: Use Google-managed service accounts instead of creating user-managed accounts for resources that support this feature. Google-managed service accounts are managed by the platform at the backend and the service account keys are temporary and rotated automatically. This avoids creating long-term access keys or a username/password for applications and hard-coded hard-coding credentials in source code or configuration files.

Use Policy Intelligence to understand and recognize suspicious activity for service accounts.

GCP 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 services that don't support TLS authentication by default, or support disabling TLS, ensure it is always enabled to support the server/client authentication. Your client application should also be designed to verify server/client identity (by verifying the server’s certificate issued by a trusted certificate authority) in the handshake stage.

Note: Services such as API Management and API Gateway supports TLS mutual authentication.

Azure implementation and additional context:

AWS guidance: Many AWS services support TLS authentication by default. For services that don't support TLS authentication by default, or support disabling TLS, ensure it is always enabled to support the server/client authentication. Your client application should also be designed to verify server/client identity (by verifying the server’s certificate issued by a trusted certificate authority) in the handshake stage.

Note: Services such as API Gateway supports TLS mutual authentication.

AWS implementation and additional context:

GCP guidance: Many GCP services support TLS authentication by default. For services that don't support this by default or support disabling TLS, ensure it is always enabled to support the server/client authentication. Your client application should also be designed to verify server/client identity (by verifying the server’s certificate issued by a trusted certificate authority) in the handshake stage.

Note: Services such as Cloud Load Balancing support TLS mutual authentication.

GCP 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 (customer facing) access through Azure AD single sign-on (SSO), reducing the need for duplicate accounts. Azure AD provides identity and access management to Azure resources (in the management plane, including CLI, PowerShell, the portal), cloud applications, and on-premises applications.

Azure AD also supports SSO for enterprise identities such as corporate user identities, as well as external user identities from trusted third-party and public users.

Azure implementation and additional context:

AWS guidance: Use AWS Cognito to manage acccess to your customer-facing applications workloads through single sign-on (SSO) to allow customers to bridge their third-party identities from different identity providers.

For SSO access to the AWS native resources (including AWS console access or service management and data plane level access), use AWS Sigle Sign-On to reduce the need for duplicate accounts.

AWS SSO also allows you to bridge corporate identities (such as identities from Azure Active Directory) with AWS identities, as well as external user identities from trusted third-party and public users.

AWS implementation and additional context:

GCP guidance: Use Google Cloud Identity to manage access to your customer facing workload application through Google Cloud Identity Single Sign-On, reducing the need for duplicate accounts. Google Cloud Identity provides identity and access management to GCP (in the management plane including Google Cloud CLI, Console access), cloud applications, and on-premises applications.

Google Cloud Identity also supports SSO for enterprise identities such as corporate user identities from Azure AD or Active Directory, as well as external user identities from trusted third-party and public users. GCP 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 FIDO2 security keys. 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.

Azure implementation and additional context:

AWS guidance: AWS IAM supports strong authentication controls through multi-factor authentication (MFA). MFA can be enforced on all users, select users, or at the per-user level based on defined conditions.

If you use corporate accounts from a third-party directory (such as Windows Active Directory) with AWS identities, follow the respective security guidance to enforce strong authentication. Refer to the Azure Guidance for this control if you use Azure AD to manage AWS access.

Note: For third-party applications and AWS services that may have default IDs and passwords, you should disable or change them during initial service setup.

AWS implementation and additional context:

GCP guidance: Google Cloud Identity supports strong authentication controls through multi-factor authentication (MFA). MFA can be enforced on all users, select users, or at the per-user level based on defined conditions. To protect Cloud Identity (and Workspace) super admin accounts, consider using security keys and the Google Advanced Protection Program for maximum security.

If you use corporate accounts from a third-party directory (such as Windows Active Directory) with Google Cloud identities, follow the respective security guidance to enforce strong authentication. Refer to the Azure Guidance for this control if you use Azure AD to manage Google Cloud access.

Use Identity-Aware Proxy to establish a central authorization layer for applications accessed by HTTPS, so you can use an application-level access control model instead of relying on network-level firewalls.

Note: For third-party applications and GCP services that may have default IDs and passwords, you should disable or change them during the initial service setup.

GCP 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: Granular authentication session management controls can also be implemented through Azure AD conditional access policy, such as sign-in frequency and persistent browser session.

Azure implementation and additional context:

AWS guidance: Create IAM policy and define conditions for more granular access controls based on user-defined conditions, such as requiring user logins from certain IP ranges (or devices) to use multi-factor authentication. Condition settings may include single or multiple conditions as well as logics.

Policies can be defined from six different dimensions: identity-based policies, resource-based policies, permissions boundaries, AWS Organizations service control policy (SCP) , Access Control Lists(ACL), and session policies.

AWS implementation and additional context:

GCP guidance: Create and define IAM Conditions for more granular attribute-based access controls based on user-defined conditions, such as requiring user logins from certain IP ranges (or devices) to use multi-factor authentication. Condition settings may include single or multiple conditions as well as logic.

Conditions are specified in the role bindings of a resource's allow policy. Condition attributes are based on the requested resource—for example, its type or name—or on details about the request—for example, its timestamp or destination IP address.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

IM-8: Restrict the exposure of credentials 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: When using a managed identity is not an option, 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.

If you use Azure DevOps and GitHub for your code management platform:

  • 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.

Note: Azure Key Vault provides automatic rotation for supported services. For secrets that cannot be automatically rotated, ensure they are manually rotated periodically and purged when no longer in use.

Azure implementation and additional context:

AWS guidance: When using an IAM role for application access is not an option, ensure that secrets and credentials are stored in secure locations such as AWS Secret Manager or Systems Manager Parameter Store, instead of embedding them into the code and configuration files.

Use CodeGuru Reviewer for static code analysis which can detect the secrets hard-coded in your source code.

If you use the Azure DevOps and GitHub for your code management platform:

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

Note: Secrets Manager provides automatic secrets rotation for supported services. For secrets that cannot be automatically rotated, ensure they are manually rotated periodically and purged when no longer in use.

AWS implementation and additional context:

GCP guidance: When using a Google-managed service account for application access is not an option, ensure that secrets and credentials are stored in secure locations such as Google Cloud's Secret Manager instead of embedding them into the code and configuration files.

Use the Google Cloud Code extension on IDE's (Integrated development environment) such as Visual Studio Code to integrate secrets managed by Secret Manager into your code.

If you use the Azure DevOps or GitHub for your code management platform:

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

Note: Set up rotation schedules for secrets stored in Secret Manager as a best practice.

GCP 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 and configure header-based authentication to allow single sign-on (SSO) access to the applications for remote users, while explicitly validating the trustworthiness of both remote users and devices with Azure AD Conditional Access. If required, use a a third-party Software-Defined Perimeter (SDP) solution which can offer similar functionality.
  • Microsoft Defender for Cloud Apps, which serves a cloud access security broker (CASB) service to monitor and block user access to unapproved third-party SaaS applications.
  • Your existing third-party application delivery controllers and networks.

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

Azure implementation and additional context:

AWS guidance: Follow Azure's guidance to protect your on-premises and non-native cloud applications using legacy authentication by connecting them to:

  • Azure AD Application Proxy, and configure header-based to allow single sign-on (SSO) access to the applications for remote users, while explicitly validating the trustworthiness of both remote users and devices with Azure AD Conditional Access. If required, use a third-party Software-Defined Perimeter (SDP) solution which can offer similar functionality.
  • Microsoft Defender for Cloud Apps, which serves as a cloud access security broker (CASB) service to monitor and block user access to unapproved third-party SaaS applications.
  • Your existing third-party application delivery controllers and networks

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

AWS implementation and additional context:

GCP guidance: Use Google Cloud Identity-Aware Proxy (IAP) to manage access to HTTP-based applications outside of Google Cloud, including applications on-premises. IAP works using signed headers or the Users API within an App Engine standard environment. If required, use third-party Software-Defined Perimeter (SDP) solution which can offer similar functionality.

You also have option to use Microsoft Defender for Cloud Apps which serves as a cloud access security broker (CASB) service to monitor and block user access to unapproved third-party SaaS applications.

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

GCP implementation and additional context:

Customer security stakeholders (Learn more):