다음을 통해 공유


조건부 액세스 인증 강도

인증 강도는 사용자가 리소스에 액세스하는 데 사용할 수 있는 인증 방법의 조합을 지정하는 Microsoft Entra 조건부 액세스 제어입니다. 사용자는 허용된 조합으로 인증하여 강도 요구 사항을 충족할 수 있습니다.

예를 들어 인증 강도는 사용자가 피싱 방지 인증 방법만 사용하여 중요한 리소스에 액세스하도록 요구할 수 있습니다. 민감하지 않은 리소스에 액세스하기 위해 관리자는 암호 및 문자 메시지와 같은 덜 안전한 MFA(다단계 인증) 조합을 허용하는 또 다른 인증 강도를 만들 수 있습니다.

인증 강도는 인증 방법에 대한 정책을 기반으로 합니다. 즉, 관리자는 Microsoft Entra ID 페더레이션된 애플리케이션에서 사용할 특정 사용자 및 그룹에 대한 인증 방법의 범위를 지정할 수 있습니다. 인증 강도는 중요한 리소스 액세스, 사용자 위험 및 위치와 같은 특정 시나리오에 따라 이러한 방법의 사용을 추가로 제어할 수 있습니다.

필수 조건

  • 조건부 액세스를 사용하려면 테넌트에 Microsoft Entra ID P1 라이선스가 있어야 합니다. 이 라이선스가 없는 경우 평가판을 시작할 수 있습니다.

인증 강도에 대한 시나리오

인증 강도는 고객이 다음과 같은 시나리오를 해결하는 데 도움이 될 수 있습니다.

  • 중요한 리소스에 액세스하려면 특정 인증 방법이 필요합니다.
  • 사용자가 애플리케이션 내에서 중요한 작업을 수행할 때 특정 인증 방법이 필요합니다(조건부 액세스 인증 컨텍스트와 함께).
  • 사용자가 회사 네트워크 외부의 중요한 애플리케이션에 액세스할 때 특정 인증 방법을 사용하도록 요구합니다.
  • 위험이 높은 사용자에게는 더 안전한 인증 방법이 필요합니다.
  • 리소스 테넌트에 액세스하는 게스트 사용자에게 특정 인증 방법을 요구합니다(테넌트 간 설정과 함께).

기본 제공 및 사용자 지정 인증 강도

관리자는 인증 강도 필요 컨트롤을 사용하여 조건부 액세스 정책을 만들어 리소스에 액세스하기 위한 인증 강도를 지정할 수 있습니다. 다단계 인증 강도, 암호 없는 MFA 강도피싱 방지 MFA 강도의 세 가지 기본 제공 인증 강도 중에서 선택할 수 있습니다. 허용하려는 인증 방법 조합에 따라 사용자 지정 인증 강도를 만들 수도 있습니다.

권한 부여 컨트롤에 구성된 인증 강도가 있는 조건부 액세스 정책의 스크린샷.

기본 제공 인증 강도

기본 제공 인증 강점은 Microsoft에서 미리 정의한 인증 방법의 조합입니다. 기본 제공 인증 강도는 항상 사용할 수 있으며 수정할 수 없습니다. Microsoft는 새로운 방법을 사용할 수 있게 되면 기본 제공 인증 강도를 업데이트합니다.

예를 들어 기본 제공 피싱 방지 MFA 강도 인증 강도는 다음을 조합할 수 있습니다.

  • 비즈니스용 Windows Hello 또는 플랫폼 자격 증명
  • FIDO2 보안 키
  • Microsoft Entra 인증서 기반 인증(다단계)

피싱 방지 다단계 인증에 대한 인증 강도의 정의를 보여 주는 스크린샷

다음 표에는 각 기본 제공 인증 강도에 대한 인증 방법의 조합이 나와 있습니다. 이러한 조합에는 사용자가 등록해야 하는 메서드와 관리자가 인증 방법 또는 레거시 MFA 설정에 대한 정책에서 사용하도록 설정해야 하는 메서드가 포함됩니다.

  • MFA 강도: 다단계 인증 필요 설정을 충족하는 데 사용할 수 있는 동일한 조합 집합입니다.
  • 암호 없는 MFA 강도: MFA를 충족하지만 암호가 필요하지 않은 인증 방법이 포함됩니다.
  • 피싱 방지 MFA 강도: 인증 방법과 로그인 화면 간의 상호 작용이 필요한 메서드를 포함합니다.
인증 방법 조합 MFA 강도 암호 없는 MFA 강도 피싱 방지 MFA 강도
FIDO2 보안 키
비즈니스용 Windows Hello 또는 플랫폼 자격 증명
인증서 기반 인증(다단계)
Microsoft Authenticator(휴대폰 로그인)
임시 액세스 패스(일회성 사용 및 여러 사용)
사용자가 소유한 항목과 암호1
페더레이션된 단일 요소와 사용자에게1이 있는 항목
페더레이션된 다단계
인증서 기반 인증(단일 요소)
SMS 로그인
암호
페더레이션된 단일 요소

1사용자가 가지고 있는 것은 문자 메시지, 음성, 푸시 알림, 소프트웨어 OATH 토큰 또는 하드웨어 OATH 토큰과 같은 방법 중 하나입니다.

다음 API 호출을 사용하여 모든 기본 제공 인증 강도의 정의를 나열할 수 있습니다.

GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?$filter=policyType eq 'builtIn'

사용자 지정 인증 강도

조건부 액세스 관리자는 액세스 요구 사항에 정확하게 맞게 사용자 지정 인증 강도를 만들 수도 있습니다. 자세한 내용은 사용자 지정 조건부 액세스 인증 강도 만들기 및 관리를 참조하세요.

제한 사항

  • 인증에 대한 인증 강도의 영향: 조건부 액세스 정책은 초기 인증 후에만 평가됩니다. 따라서 인증 강도는 사용자의 초기 인증을 제한하지 않습니다.

    기본 제공 피싱 저항 MFA 인증 강도를 사용한다고 가정해 보겠습니다. 사용자는 여전히 암호를 입력할 수 있지만 피싱 방지 방법(예: FIDO2 보안 키)을 사용하여 로그인해야 계속 진행할 수 있습니다.

  • 지원되지 않는 권한 부여 컨트롤 조합: 다단계 인증 필요인증 강도 부여 컨트롤을 동일한 조건부 액세스 정책에서 함께 사용할 수 없습니다. 그 이유는 기본 제공 다단계 인증 인증 강도가 다단계 인증 허용 제어 필요와 동일하기 때문입니다.

  • 지원되지 않는 인증 방법: 이메일 일회성 패스(게스트) 인증 방법은 현재 사용 가능한 조합에서 지원되지 않습니다.

  • 비즈니스용 Windows Hello: 사용자가 비즈니스용 Windows Hello를 기본 인증 방법으로 로그인하는 경우 비즈니스용 Windows Hello를 포함하는 인증 강도 요구 사항을 충족하는 데 사용할 수 있습니다. 그러나 사용자가 기본 인증 방법으로 다른 방법(예: 암호)으로 로그인하고 인증 강도에 비즈니스용 Windows Hello가 필요한 경우 사용자에게 비즈니스용 Windows Hello로 로그인하라는 메시지가 표시되지 않습니다. 사용자는 세션을 다시 시작하고, 로그인 옵션을 선택하고, 인증 강도에 필요한 방법을 선택해야 합니다.

알려진 문제

  • 인증 강도 및 로그인 빈도: 리소스에 인증 강도와 로그인 빈도가 필요한 경우 사용자는 두 가지 요구 사항을 서로 다른 두 번 충족할 수 있습니다.

    예를 들어 리소스에 1시간 로그인 빈도와 함께 인증 강도에 대한 암호(FIDO2)가 필요하다고 가정해 보겠습니다. 사용자가 24시간 전에 리소스에 액세스하기 위해 PASSKEY(FIDO2)로 로그인했습니다.

    사용자가 비즈니스용 Windows Hello를 사용하여 Windows 디바이스의 잠금을 해제하면 리소스에 다시 액세스할 수 있습니다. 어제의 로그인은 인증 강도 요구 사항을 충족하며, 오늘날의 디바이스 잠금 해제는 로그인 빈도 요구 사항을 충족합니다.

자주 묻는 질문(FAQ)

인증 방법의 인증 강도 또는 정책을 사용해야 하나요?

인증 강도는 인증 방법 정책을 기반으로 합니다. 인증 방법 정책은 사용자 및 그룹이 Microsoft Entra ID에서 사용할 수 있는 인증 방법의 범위를 지정하고 구성하는 데 도움이 됩니다. 인증 강도는 중요한 리소스 액세스, 사용자 위험 및 위치와 같은 특정 시나리오에 대한 메서드의 또 다른 제한을 허용합니다.

예를 들어 Contoso라는 조직의 관리자가 사용자가 푸시 알림 또는 암호 없는 인증 모드로 Microsoft Authenticator를 사용하도록 허용하려고 하는 경우를 가정합니다. 관리자는 인증 방법 정책의 Authenticator 설정으로 이동하고, 관련 사용자에 대한 정책 범위를 지정하고, 인증 모드Any로 설정합니다.

Contoso의 가장 중요한 리소스의 경우 관리자는 암호 없는 인증 방법으로만 액세스를 제한하려고 합니다. 관리자는 기본 제공 암호 없는 MFA 강도 인증 강도를 사용하여 새 조건부 액세스 정책을 만듭니다.

결과적으로 Contoso의 사용자는 Authenticator의 암호 및 푸시 알림을 사용하거나 Authenticator(전화 로그인)만 사용하여 테넌트의 대부분의 리소스에 액세스할 수 있습니다. 그러나 테넌트 사용자가 중요한 애플리케이션에 액세스하는 경우 Authenticator(전화 로그인)를 사용해야 합니다.