Редактиране

Споделяне чрез


Configure identification and authentication controls to meet FedRAMP High Impact level with Microsoft Entra ID

Identification and authentication are key to achieving a Federal Risk and Authorization Management Program (FedRAMP) High Impact level.

The following list of controls and control enhancements in the identification and authentication (IA) family might require configuration in your Microsoft Entra tenant.

Control family Description
IA-2 Identification and authentication (organizational users)
IA-3 Device identification and authentication
IA-4 Identifier management
IA-5 Authenticator management
IA-6 Authenticator feedback
IA-7 Cryptographic module authentication
IA-8 Identification and authentication (nonorganizational users)

Each row in the following table provides prescriptive guidance to help you develop your organization's response to any shared responsibilities for the control or control enhancement.

Configurations

FedRAMP Control ID and description Microsoft Entra guidance and recommendations
IA-2 User Identification and Authentication
The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).
Uniquely identify and authenticate users or processes acting for users.

Microsoft Entra ID uniquely identifies user and service principal objects directly. Microsoft Entra ID provides multiple authentication methods, and you can configure methods that adhere to National Institute of Standards and Technology (NIST) authentication assurance level (AAL) 3.

Identifiers

  • Users: Working with users in Microsoft Graph: ID property
  • Service principals: ServicePrincipal resource type : ID property

    Authentication and multifactor authentication

  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • IA-2(1)
    The information system implements multifactor authentication for network access to privileged accounts.

    IA-2(3)
    The information system implements multifactor authentication for local access to privileged accounts.
    multifactor authentication for all access to privileged accounts.

    Configure the following elements for a complete solution to ensure all access to privileged accounts requires multifactor authentication.

    Configure Conditional Access policies to require multifactor authentication for all users.
    Implement Microsoft Entra Privileged Identity Management to require multifactor authentication for activation of privileged role assignment prior to use.

    With Privileged Identity Management activation requirement, privilege account activation isn't possible without network access, so local access is never privileged.

    multifactor authentication and Privileged Identity Management

  • Conditional Access: Require multifactor authentication for all users
  • Configure Microsoft Entra role settings in Privileged Identity Management
  • IA-2(2)
    The information system implements multifactor authentication for network access to non-privileged accounts.

    IA-2(4)
    The information system implements multifactor authentication for local access to nonprivileged accounts.
    Implement multifactor authentication for all access to nonprivileged accounts

    Configure the following elements as an overall solution to ensure all access to nonprivileged accounts requires MFA.

    Configure Conditional Access policies to require MFA for all users.
    Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM) or group policy objects (GPO) to enforce use of specific authentication methods.
    Configure Conditional Access policies to enforce device compliance.

    Microsoft recommends using a multifactor cryptographic hardware authenticator (for example, FIDO2 security keys, Windows Hello for Business (with hardware TPM), or smart card) to achieve AAL3. If your organization is cloud-based, we recommend using FIDO2 security keys or Windows Hello for Business.

    Windows Hello for Business hasn't been validated at the required FIPS 140 Security Level and as such federal customers would need to conduct risk assessment and evaluation before accepting it as AAL3. For more information regarding Windows Hello for Business FIPS 140 validation, see Microsoft NIST AALs.

    See the following guidance regarding MDM policies differ slightly based on authentication methods.

    Smart Card / Windows Hello for Business
    Passwordless Strategy - Require Windows Hello for Business or smart card
    Require device to be marked as compliant
    Conditional Access - Require MFA for all users

    Hybrid Only
    Passwordless Strategy - Configure user accounts to disallow password authentication

    Smart Card Only
    Create a Rule to Send an Authentication Method Claim
    Configure Authentication Policies

    FIDO2 Security Key
    Passwordless Strategy - Excluding the password credential provider
    Require device to be marked as compliant
    Conditional Access - Require MFA for all users

    Authentication Methods
    Microsoft Entra passwordless sign-in (preview) | FIDO2 security keys
    Passwordless security key sign-in Windows - Microsoft Entra ID
    ADFS: Certificate Authentication with Microsoft Entra ID and Office 365
    How Smart Card Sign-in Works in Windows (Windows 10)
    Windows Hello for Business Overview (Windows 10)

    Additional Resources:
    Policy CSP - Windows Client Management
    Plan a passwordless authentication deployment with Microsoft Entra ID

    IA-2(5)
    The organization requires individuals to be authenticated with an individual authenticator when a group authenticator is employed.
    When multiple users have access to a shared or group account password, require each user to first authenticate by using an individual authenticator.

    Use an individual account per user. If a shared account is required, Microsoft Entra ID permits binding of multiple authenticators to an account so that each user has an individual authenticator.

    Resources

  • How it works: Microsoft Entra multifactor authentication
  • Manage authentication methods for Microsoft Entra multifactor authentication
  • IA-2(8)
    The information system implements replay-resistant authentication mechanisms for network access to privileged accounts.
    Implement replay-resistant authentication mechanisms for network access to privileged accounts.

    Configure Conditional Access policies to require multifactor authentication for all users. All Microsoft Entra authentication methods at authentication assurance level 2 and 3 use either nonce or challenges and are resistant to replay attacks.

    References

  • Conditional Access: Require multifactor authentication for all users
  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • IA-2(11)
    The information system implements multifactor authentication for remote access to privileged and nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets [FedRAMP Assignment: FIPS 140-2, NIAP Certification, or NSA approval*].

    *National Information Assurance Partnership (NIAP)
    Additional FedRAMP Requirements and Guidance:
    Guidance: PIV = separate device. Refer to NIST SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials. FIPS 140-2 means validated by the Cryptographic Module Validation Program (CMVP).
    Implement Microsoft Entra multifactor authentication to access customer-deployed resources remotely so that one of the factors is provided by a device separate from the system gaining access where the device meets FIPS-140-2, NIAP certification, or NSA approval.

    See guidance for IA-02(1-4). Microsoft Entra authentication methods to consider at AAL3 meeting the separate device requirements are:

    FIDO2 security keys

  • Windows Hello for Business with hardware TPM (TPM is recognized as a valid "something you have" factor by NIST 800-63B Section 5.1.7.1.)
  • Smart card

    References

  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • NIST 800-63B Section 5.1.7.1
  • **IA-2(12)*
    The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials.

    IA-2 (12) Additional FedRAMP Requirements and Guidance:
    Guidance: Include Common Access Card (CAC), that is, the DoD technical implementation of PIV/FIPS 201/HSPD-12.
    Accept and verify personal identity verification (PIV) credentials. This control isn't applicable if the customer doesn't deploy PIV credentials.

    Configure federated authentication by using Active Directory Federation Services (AD FS) to accept PIV (certificate authentication) as both primary and multifactor authentication methods and issue the multifactor authentication (MultipleAuthN) claim when PIV is used. Configure the federated domain in Microsoft Entra ID with setting federatedIdpMfaBehavior to enforceMfaByFederatedIdp (recommended) or SupportsMfa to $True to direct multifactor authentication requests originating at Microsoft Entra ID to Active Directory Federation Services. Alternatively, you can use PIV for sign-in on Windows devices and later use integrated Windows authentication along with seamless single sign-on. Windows Server and client verify certificates by default when used for authentication.

    Resources

  • What is federation with Microsoft Entra ID?
  • Configure AD FS support for user certificate authentication
  • Configure authentication policies
  • Secure resources with Microsoft Entra multifactor authentication and AD FS
  • New-MgDomainFederationConfiguration
  • Microsoft Entra Connect: Seamless single sign-on
  • IA-3 Device Identification and Authentication
    The information system uniquely identifies and authenticates [Assignment: organization-defined specific and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection.
    Implement device identification and authentication prior to establishing a connection.

    Configure Microsoft Entra ID to identify and authenticate Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined devices.

    Resources

  • What is a device identity?
  • Plan a Microsoft Entra devices deployment
  • Require managed devices for cloud app access with Conditional Access
  • IA-04 Identifier Management
    The organization manages information system identifiers for users and devices by:
    (a.) Receiving authorization from [FedRAMP Assignment at a minimum, the ISSO (or similar role within the organization)] to assign an individual, group, role, or device identifier;
    (b.) Selecting an identifier that identifies an individual, group, role, or device;
    (c.) Assigning the identifier to the intended individual, group, role, or device;
    (d.) Preventing reuse of identifiers for [FedRAMP Assignment: at least two (2) years]; and
    (e.) Disabling the identifier after [FedRAMP Assignment: thirty-five (35) days (see requirements and guidance)]
    IA-4e Additional FedRAMP Requirements and Guidance:
    Requirement: The service provider defines the time period of inactivity for device identifiers.
    Guidance: For DoD clouds, see DoD cloud website for specific DoD requirements that go above and beyond FedRAMP.

    IA-4(4)
    The organization manages individual identifiers by uniquely identifying each individual as [FedRAMP Assignment: contractors; foreign nationals].
    Disable account identifiers after 35 days of inactivity and prevent their reuse for two years. Manage individual identifiers by uniquely identifying each individual (for example, contractors and foreign nationals).

    Assign and manage individual account identifiers and status in Microsoft Entra ID in accordance with existing organizational policies defined in AC-02. Follow AC-02(3) to automatically disable user and device accounts after 35 days of inactivity. Ensure that organizational policy maintains all accounts that remain in the disabled state for at least two years. After this time, you can remove them.

    Determine inactivity

  • Manage inactive user accounts in Microsoft Entra ID
  • Manage stale devices in Microsoft Entra ID
  • See AC-02 guidance
  • IA-5 Authenticator Management
    The organization manages information system authenticators by:
    (a.) Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator;
    (b.) Establishing initial authenticator content for authenticators defined by the organization;
    (c.) Ensuring that authenticators have sufficient strength of mechanism for their intended use;
    (d.) Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators;
    (e.) Changing default content of authenticators prior to information system installation;
    (f.) Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators;
    (g.) Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type].
    (h.) Protecting authenticator content from unauthorized disclosure and modification;
    (i.) Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and
    (j.) Changing authenticators for group/role accounts when membership to those accounts changes.

    IA-5 Additional FedRAMP Requirements and Guidance:
    Requirement: Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 3. Link https://pages.nist.gov/800-63-3
    Configure and manage information system authenticators.

    Microsoft Entra ID supports various authentication methods. You can use your existing organizational policies for management. See guidance for authenticator selection in IA-02(1-4). Enable users in combined registration for SSPR and Microsoft Entra multifactor authentication and require users to register a minimum of two acceptable multifactor authentication methods to facilitate self-remediation. You can revoke user-configured authenticators at any time with the authentication methods API.

    Authenticator strength/protecting authenticator content

  • Achieving NIST authenticator assurance levels with the Microsoft identity platform

    Authentication methods and combined registration

  • What authentication and verification methods are available in Microsoft Entra ID?
  • Combined registration for SSPR and Microsoft Entra multifactor authentication

    Authenticator revokes

  • Microsoft Entra authentication methods API overview
  • IA-5(1)
    The information system, for password-based authentication:
    (a.) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type];
    (b.) Enforces at least the following number of changed characters when new passwords are created: [FedRAMP Assignment: at least fifty percent (50%)];
    (c.) Stores and transmits only cryptographically protected passwords;
    (d.) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization- defined numbers for lifetime minimum, lifetime maximum];
    (e.)** Prohibits password reuse for [FedRAMP Assignment: twenty-four (24)] generations; and
    (f.) Allows the use of a temporary password for system logons with an immediate change to a permanent password.

    IA-5 (1) a and d Additional FedRAMP Requirements and Guidance:
    Guidance: If password policies are compliant with NIST SP 800-63B Memorized Secret (Section 5.1.1) Guidance, the control may be considered compliant.
    Implement password-based authentication requirements.

    Per NIST SP 800-63B Section 5.1.1: Maintain a list of commonly used, expected, or compromised passwords.

    With Microsoft Entra password protection, default global banned password lists are automatically applied to all users in a Microsoft Entra tenant. To support your business and security needs, you can define entries in a custom banned password list. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.

    We strongly encourage passwordless strategies. This control is only applicable to password authenticators, so removing passwords as an available authenticator renders this control not applicable.

    NIST reference documents

  • NIST Special Publication 800-63B
  • NIST Special Publication 800-53 Revision 5 - IA-5 - Control enhancement (1)

    Resource

  • Eliminate bad passwords using Microsoft Entra password protection
  • IA-5(2)
    The information system, for PKI-based authentication:
    (a.) Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information;
    (b.) Enforces authorized access to the corresponding private key;
    (c.) Maps the authenticated identity to the account of the individual or group; and
    (d.) Implements a local cache of revocation data to support path discovery and validation during inability to access revocation information via the network.
    Implement PKI-based authentication requirements.

    Federate Microsoft Entra ID via AD FS to implement PKI-based authentication. By default, AD FS validates certificates, locally caches revocation data, and maps users to the authenticated identity in Active Directory.

    Resources

  • What is federation with Microsoft Entra ID?
  • Configure AD FS support for user certificate authentication
  • IA-5(4)
    The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy [FedRAMP Assignment: complexity as identified in IA-5 (1) Control Enhancement (H) Part A].

    IA-5(4) Additional FedRAMP Requirements and Guidance:
    Guidance: If automated mechanisms that enforce password authenticator strength at creation aren't used, automated mechanisms must be used to audit strength of created password authenticators.
    Employ automated tools to validate password strength requirements.

    Microsoft Entra ID implements automated mechanisms that enforce password authenticator strength at creation. This automated mechanism can also be extended to enforce password authenticator strength for on-premises Active Directory. Revision 5 of NIST 800-53 has withdrawn IA-04(4) and incorporated the requirement into IA-5(1).

    Resources

  • Eliminate bad passwords using Microsoft Entra password protection
  • Microsoft Entra password protection for Active Directory Domain Services
  • NIST Special Publication 800-53 Revision 5 - IA-5 - Control enhancement (4)
  • IA-5(6)
    The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access.
    Protect authenticators as defined in the FedRAMP High Impact level.

    For more information on how Microsoft Entra ID protects authenticators, see Microsoft Entra data security considerations.

    IA-05(7)
    The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys.
    Ensure unencrypted static authenticators (for example, a password) aren't embedded in applications or access scripts or stored on function keys.

    Implement managed identities or service principal objects (configured with only a certificate).

    Resources

  • What are managed identities for Azure resources?
  • Create a Microsoft Entra app and service principal in the portal
  • IA-5(8)
    The organization implements [FedRAMP Assignment: different authenticators on different systems] to manage the risk of compromise due to individuals having accounts on multiple information systems.
    Implement security safeguards when individuals have accounts on multiple information systems.

    Implement single sign-on by connecting all applications to Microsoft Entra ID, as opposed to having individual accounts on multiple information systems.

    What is Azure single sign-on?

    IA-5(11)
    The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements].
    Require hardware token quality requirements as required by the FedRAMP High Impact level.

    Require the use of hardware tokens that meet AAL3.

    Achieving NIST authenticator assurance levels with the Microsoft identity platform

    IA-5(13)
    The information system prohibits the use of cached authenticators after [Assignment: organization-defined time period].
    Enforce the expiration of cached authenticators.

    Cached authenticators are used to authenticate to the local machine when the network isn't available. To limit the use of cached authenticators, configure Windows devices to disable their use. Where this action isn't possible or practical, use the following compensating controls:

    Configure Conditional Access session controls by using application-enforced restrictions for Office applications.
    Configure Conditional Access by using application controls for other applications.

    Resources

  • Interactive logon number of previous logons to cache
  • Session controls in Conditional Access policy: Application enforced restrictions
  • Session controls in Conditional Access policy: Conditional Access application control
  • IA-6 Authenticator Feedback
    The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.
    Obscure authentication feedback information during the authentication process.

    By default, Microsoft Entra ID obscures all authenticator feedback.

    IA-7 Cryptographic Module Authentication
    The information system implements mechanisms for authentication to a cryptographic module for requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.
    Implement mechanisms for authentication to a cryptographic module that meets applicable federal laws.

    The FedRAMP High Impact level requires the AAL3 authenticator. All authenticators supported by Microsoft Entra ID at AAL3 provide mechanisms to authenticate operator access to the module as required. For example, in a Windows Hello for Business deployment with hardware TPM, configure the level of TPM owner authorization.

    Resources

  • For more information, see IA-02 (2 and 4).
  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • TPM Group Policy settings
  • IA-8 Identification and Authentication (Non-Organizational Users)
    The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users).
    The information system uniquely identifies and authenticates nonorganizational users (or processes acting for nonorganizational users).

    Microsoft Entra ID uniquely identifies and authenticates non-organizational users homed in the organizations tenant or in external directories by using Federal Identity, Credential, and Access Management (FICAM)-approved protocols.

    Resources

  • What is B2B collaboration in Microsoft Entra ID?
  • Direct federation with an identity provider for B2B
  • Properties of a B2B guest user
  • IA-8(1)
    The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies.

    IA-8(4)
    The information system conforms to FICAM-issued profiles.
    Accept and verify PIV credentials issued by other federal agencies. Conform to the profiles issued by the FICAM.

    Configure Microsoft Entra ID to accept PIV credentials via federation (OIDC, SAML) or locally via integrated Windows authentication.

    Resources

  • What is federation with Microsoft Entra ID?
  • Configure AD FS support for user certificate authentication
  • What is B2B collaboration in Microsoft Entra ID?
  • Direct federation with an identity provider for B2B
  • IA-8(2)
    The information system accepts only FICAM-approved third-party credentials.
    Accept only FICAM-approved credentials.

    Microsoft Entra ID supports authenticators at NIST AALs 1, 2, and 3. Restrict the use of authenticators commensurate with the security category of the system being accessed.

    Microsoft Entra ID supports a wide variety of authentication methods.

    Resources

  • What authentication and verification methods are available in Microsoft Entra ID?
  • Microsoft Entra authentication methods policy API overview
  • Achieving NIST authenticator assurance levels with the Microsoft identity platform                                     
  • Next steps