다음을 통해 공유

Microsoft Entra ID를 사용하여 복원력 있는 액세스 제어 관리 전략 만들기

  • 아티클

참고 항목

이 문서에 포함된 정보는 문서 게시 날짜에 토론된 문제들에 대한 Microsoft Corporation의 당시 견해를 나타냅니다. Microsoft는 변화하는 시장 상황에 대응해야 하므로 Microsoft의 약정으로 해석되지 않아야 하며, Microsoft는 게시 날짜 이후 제시된 정보의 정확도를 보증하지 않습니다.

다단계 인증 또는 단일 네트워크 위치와 같은 단일 액세스 제어를 사용하여 IT 시스템을 보호하는 조직은 단일 액세스 제어를 사용할 수 없거나 잘못 구성하는 경우 해당 애플리케이션 및 리소스에 대한 액세스 실패에 취약합니다. 예를 들어 자연 재해로 인해 대규모 통신 인프라 또는 회사 네트워크의 대형 세그먼트를 사용할 수 없게 될 수 있습니다. 이러한 중단에 따라 최종 사용자와 관리자가 로그인하지 못할 수도 있습니다.

이 문서에서는 조직이 다음의 시나리오에서 예기치 않은 중단 시 잠금의 위험을 줄이는 복원력을 제공하기 위해 채택해야 하는 전략에 대한 지침을 제공합니다.

  • 조직은 완화 전략 또는 대응 계획을 구현하여 중단 전에 잠금 위험을 줄이는 복원력을 높일 수 있습니다.
  • 조직은 완화 전략과 대응 계획을 수립하여 중단 중에 선택한 애플리케이션과 리소스에 계속 액세스할 수 있습니다.
  • 조직은 중단 후 및 구현된 모든 긴급 상황을 롤백하기 전에 로그와 같은 정보를 보존해야 합니다.
  • 방지 전략 또는 대응 계획을 구현하지 않은 조직은 중단을 처리하기 위해 응급 옵션을 구현할 수 있습니다.

주요 지침

이 문서의 4가지 핵심 사항은 다음과 같습니다.

  • 응급 액세스 계정을 사용하여 관리자 잠금을 방지합니다.
  • 사용자별 MFA 대신 조건부 액세스를 사용하여 MFA를 구현합니다.
  • 여러 조건부 액세스 제어를 사용하여 사용자 잠금을 완화합니다.
  • 각 사용자에 대해 여러 인증 방법 또는 이와 동등한 기능을 프로비전하여 사용자 잠금을 완화합니다.

중단 전

실제 중단을 완화하는 것은 발생할 수 있는 액세스 제어 문제를 처리하는 데 있어 조직의 주요 초점이 되어야 합니다. 완화에는 실제 이벤트에 대한 계획 및 중단되는 동안 액세스 제어와 운영에 영향을 주지 않도록 하는 전략에 대한 구현이 포함됩니다.

복원력 있는 액세스 제어가 필요한 이유

ID는 애플리케이션과 리소스에 액세스하는 사용자의 제어 평면입니다. ID 시스템은 액세스 제어 또는 인증 요구 사항과 같이 사용자가 애플리케이션에 액세스할 수 있는 사용자와 조건을 제어합니다. 예기치 않은 상황으로 인해 사용자가 인증하는 데 하나 이상의 인증 또는 액세스 제어 요구 사항을 사용할 수 없는 경우 조직에서는 다음 문제 중 하나 또는 둘 모두를 경험할 수 있습니다.

  • 관리자 잠금: 관리자가 테넌트 또는 서비스를 관리할 수 없습니다.
  • 사용자 잠금: 사용자가 앱 또는 리소스에 액세스할 수 없습니다.

관리자 잠금 긴급 상황

Microsoft에서는 조직에 전역 관리자 역할이 영구적으로 할당된 두 개의 클라우드 전용 긴급 액세스 계정을 보유하는 것이 좋습니다. 이러한 계정은 높은 권한을 부여받으며 특정 개인에게 할당되지 않습니다. 계정은 일반 계정을 사용할 수 없거나 다른 모든 관리자가 실수로 잠긴 긴급 또는 "중단" 시나리오로 제한됩니다. 이러한 계정은 긴급 액세스 계정 권장 사항에 따라 만들어져야 합니다.

사용자 잠금 완화

사용자 잠금 위험을 완화하려면 여러 제어 기능이 포함된 조건부 액세스 정책을 이용해 사용자가 앱과 리소스에 액세스하는 방법을 선택할 수 있도록 합니다. 예를 들어 사용자가 MFA로 로그인 또는 관리 디바이스에서 로그인 또는 회사 네트워크에서 로그인 중에서 선택할 수 있도록 하여 액세스 제어 중 하나를 사용할 수 없는 경우 계속 작업할 수 있는 다른 옵션이 사용자에게 제공됩니다.

Microsoft 권장 사항

조직의 기존 조건부 액세스 정책에 다음 액세스 제어를 통합합니다.

  • Microsoft Authenticator 앱(인터넷 기반), OATH 토큰(디바이스에서 생성) 및 SMS(전화)와 같이 다양한 통신 채널을 사용하는 각 사용자에 대해 여러 인증 방법을 프로비전합니다.
  • 디바이스 로그인에서 직접 MFA 요구 사항을 충족시키기 위해 Windows 10 디바이스에 비즈니스용 Windows Hello를 배포합니다.
  • Microsoft Entra 하이브리드 조인 또는 Microsoft Intune을 통해 신뢰할 수 있는 디바이스를 사용합니다. 사용자의 MFA 챌린지 없이 신뢰할 수 있는 디바이스 자체에서 정책의 강력한 인증 요구 사항을 충족할 수 있으므로 신뢰할 수 있는 디바이스는 사용자 환경을 개선합니다. 그러면 새 디바이스를 등록할 때와 신뢰할 수 없는 디바이스에서 애플리케이션 또는 리소스에 액세스할 때 MFA가 필요합니다.
  • 고정된 MFA 정책 대신 사용자 또는 로그인이 위험한 상태에 있을 때 액세스를 차단하는 Microsoft Entra ID 보호 위험 기반 정책을 사용합니다.
  • Microsoft Entra 다단계 인증 NPS 확장을 사용하여 VPN 액세스를 보호하는 경우, VPN 솔루션을 SAML 앱으로 페더레이션하고 아래에서 권장하는 대로 앱 범주를 결정하는 것이 좋습니다.

참고 항목

위험 기반 정책에는 Microsoft Entra ID P2 라이선스가 필요합니다.

다음 예제에서는 사용자가 자신의 애플리케이션과 리소스에 액세스할 수 있는 복원력 있는 액세스 제어를 제공하기 위해 만들어야 하는 정책을 설명합니다. 이 예에서는 액세스 권한을 부여하려는 대상 사용자가 있는 AppUsers 보안 그룹, Core 관리자가 있는 CoreAdmins 그룹 및 긴급 액세스 계정이 있는 EmergencyAccess 그룹이 필요합니다. 이 정책 집합 예는 AppUsers에서 선택한 사용자에게 액세스 권한을 부여하거나, 신뢰할 수 있는 디바이스에서 연결하는 경우 선택한 애플리케이션에 액세스하거나, MFA와 같은 강력한 인증을 제공합니다. 응급 계정과 핵심 관리자는 여기서 제외됩니다.

조건부 액세스 완화 정책 집합:

  • 정책 1: 대상 그룹 외부 사람에 대한 액세스 차단
    • 사용자 및 그룹: 모든 사용자 포함. AppUsers, CoreAdmins 및 EmergencyAccess 제외
    • 클라우드 앱: 모든 앱 포함
    • 조건: (없음)
    • 컨트롤 권한 부여: 차단
  • 정책 2: MFA 또는 신뢰할 수 있는 디바이스가 필요한 AppUsers에 액세스 권한 부여
    • 사용자 및 그룹: AppUsers를 포함. CoreAdmins 및 EmergencyAccess 제외
    • 클라우드 앱: 모든 앱 포함
    • 조건: (없음)
    • 컨트롤 권한 부여: 액세스 권한을 부여하고, 다단계 인증을 요구하며, 디바이스에서 규정을 준수하도록 요구합니다. 컨트롤이 여러 개인 경우: 선택한 컨트롤 중 하나가 필요합니다.

사용자 잠금 긴급 상황

조직에서는 대안으로 대응 정책을 만들 수도 있습니다. 대응 정책을 만들려면 비즈니스 연속성, 운영 비용, 재무 비용 및 보안 위험 간의 절충 조건을 정의해야 합니다. 예를 들어 애플리케이션의 하위 세트, 클라이언트의 하위 세트 또는 위치의 하위 세트에 속한 사용자의 하위 세트에만 대응 정책을 활성화할 수 있습니다. 완화 방법이 구현되지 않은 중단 동안 관리자와 최종 사용자는 대응 정책을 통해 애플리케이션 및 리소스에 액세스할 수 있습니다. 관리자가 정책을 활성화해야 할 경우 정책의 잠재적 영향을 모니터링할 수 있도록, 사용하지 않을 때는 보고 전용 모드에서 대체 정책을 사용하도록 설정하는 것이 좋습니다.

중단 동안의 노출을 이해하는 것은 위험을 줄이는 데 도움이 되며 계획 프로세스에서 중요한 부분입니다. 대응 계획을 만들기 위해 먼저 결정해야 하는 조직의 다음 비즈니스 요구 사항은 다음과 같습니다.

  1. 중요 업무용 앱을 사전에 결정: 위험/보안 태세가 낮더라도 액세스 권한을 부여해야 하는 앱은 무엇인가요? 이러한 애플리케이션의 목록을 작성하고, 액세스 제어가 모두 사라지더라도 이러한 애플리케이션이 계속 실행되어야 한다는 것에 대해 다른 모든 이해 관계자(비즈니스, 보안, 법률, 리더십)가 동의해야 합니다. 다음과 같은 범주로 끝날 가능성이 높습니다.
    • 범주 1 중요 업무용 애플리케이션 - 몇 분 이상 사용할 수 없습니다(예: 조직의 매출에 직접 영향을 미치는 앱).
    • 범주 2 중요한 애플리케이션 - 몇 시간 내에 비즈니스에 액세스할 수 있어야 합니다.
    • 범주 3 우선 순위가 낮은 애플리케이션 - 며칠간의 중단에 견딜 수 있습니다.
  2. 범주 1과 2의 애플리케이션에 대해 다음과 같이 허용하려는 액세스 수준 형식을 미리 계획하는 것이 좋습니다.
    • 다운로드 제한과 같이 전체 액세스 또는 제한된 세션을 허용하겠습니까?
    • 전체 애플리케이션이 아닌 일부 애플리케이션에만 액세스를 허용하겠습니까?
    • 정보 근로자 액세스를 허용하고 액세스 제어가 복원될 때까지 관리자 액세스를 차단하겠습니까?
  3. 이러한 앱의 경우 Microsoft에서는 의도적으로 열고 닫을 액세스 경로를 계획하는 것이 좋습니다.
    • 브라우저 전용 액세스를 허용하고 오프라인 데이터를 저장할 수 있는 리치 클라이언트를 차단하겠습니까?
    • 회사 네트워크 내의 사용자에게만 액세스를 허용하고 외부 사용자는 차단하겠습니까?
    • 중단 동안에만 특정 국가 또는 지역의 액세스를 허용하겠습니까?
    • 대체 액세스 제어를 사용할 수 없는 경우 대응 정책, 특히 중요 업무용 애플리케이션에 대한 대응 정책이 실패하거나 성공하도록 하겠나요?

Microsoft 권장 사항

대체 조건부 액세스 정책은 Microsoft Entra 다단계 인증, 타사 MFA, 위험 기반 또는 디바이스 기반 제어를 생략하는 백업 정책입니다. 대체 정책을 사용할 때 예기치 않은 중단을 최소화하려면 정책을 사용하지 않을 때 보고 전용 모드로 유지해야 합니다. 관리자는 조건부 액세스 인사이트 통합 문서를 사용하여 해당 대체 정책의 잠재적 영향을 모니터링할 수 있습니다. 조직에서 대체 계획을 활성화하기로 결정한 경우 관리자는 정책을 사용하고 일반 컨트롤 기반 정책을 사용하지 않도록 설정할 수 있습니다.

Important

사용자에게 보안을 적용하는 정책을 일시적이라도 사용하지 않도록 설정하면 대응 계획이 있는 동안 보안 상태가 저하됩니다.

  • 하나의 자격 증명 유형 또는 하나의 액세스 제어 메커니즘의 중단으로 인해 앱에 대한 액세스에 영향을 주는 경우 일단의 대체 정책을 구성합니다. 타사 MFA 공급자가 요구하는 활성 정책에 대한 백업과 같이 도메인 조인이 컨트롤로 필요한 정책을 보고 전용 상태로 구성합니다.
  • 암호 지침 백서의 사례에 따라 MFA를 요구하지 않을 때 악의적인 작업자의 암호 추측에 대한 위험을 줄입니다.
  • Microsoft Entra SSPR(셀프 서비스 암호 재설정) 및 Microsoft Entra 암호 보호를 배포하여 사용자가 금지하도록 선택한 일반적인 암호와 용어를 사용하지 못하도록 합니다.
  • 특정 인증 수준에 도달하지 못하는 경우 단순히 모든 권한으로 대체하는 대신 앱 내에서 액세스를 제한하는 정책을 사용합니다. 예:
    • 제한된 세션 클레임을 Exchange 및 SharePoint로 보내는 백업 정책을 구성합니다.
    • 조직에서 Microsoft Defender for Cloud Apps를 사용하는 경우 Defender for Cloud Apps를 사용한 다음 읽기 전용 액세스는 허용하지만 업로드는 허용하지 않는 정책으로 대체하는 것이 좋습니다.
  • 중단 시 정책을 쉽게 찾을 수 있도록 해당 정책의 이름을 지정합니다. 정책 이름에 포함되는 요소는 다음과 같습니다.
    • 정책에 대한 레이블 번호
    • 표시할 텍스트 - 이 정책은 응급 상황에만 적용됩니다. 예: 응급 상황에서 사용
    • 적용되는 중단. 예: MFA 중단 중
    • 정책을 활성화해야 하는 순서를 나타내는 시퀀스 번호
    • 적용되는 앱
    • 적용할 제어
    • 필요한 조건

비상 정책의 명명 표준은 다음과 같습니다.

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

다음 예제: 예 A - 중요 업무용 협업 앱에 대한 액세스를 복원하는 대체 조건부 액세스 정책은 일반적인 회사 대체 정책입니다. 이 시나리오에서 조직은 일반적으로 모든 Exchange Online 및 SharePoint Online 액세스에서 MFA를 요구하며, 이 경우 중단되면 고객에 대한 MFA 공급자(Microsoft Entra MFA, 온-프레미스 MFA 공급자 또는 타사 MFA)가 중단된 것입니다. 이 정책은 특정 대상 사용자가 신뢰할 수 있는 회사 네트워크에서 해당 애플리케이션에 액세스할 때만 신뢰할 수 있는 Windows 디바이스에서 이러한 애플리케이션에 액세스할 수 있도록 하여 이러한 중단을 완화합니다. 또한 응급 계정과 핵심 관리자도 이러한 제한에서 제외됩니다. 그러면 대상으로 지정된 사용자는 Exchange Online 및 SharePoint Online에 액세스할 수 있지만, 다른 사용자는 중단으로 인해 애플리케이션에 액세스할 수 없습니다. 이 예에서는 대상 사용자가 있는 CorpNetwork 네트워크 위치와 ContingencyAccess 보안 그룹, Core 관리자가 있는 CoreAdmins 그룹 및 긴급 액세스 계정이 있는 EmergencyAccess 그룹이 필요합니다. 긴급 상황에는 원하는 액세스를 제공하는 4가지 정책이 필요합니다.

예 A - 중요 업무용 협업 앱에 대한 액세스를 복원하는 대체 조건부 액세스 정책:

  • 정책 1: Exchange 및 SharePoint용 도메인 조인 디바이스 필요
    • 이름: EM001 - 응급 상황에서 사용: MFA 중단[1/4] - Exchange SharePoint - Microsoft Entra 하이브리드 조인 필요
    • 사용자 및 그룹: ContingencyAccess 포함. CoreAdmins 및 EmergencyAccess 제외
    • 클라우드 앱: Exchange Online 및 SharePoint Online
    • 조건: 모두
    • 컨트롤 권한 부여: 도메인 조인 필요
    • 상태: 보고 전용
  • 정책 2: Windows 이외의 플랫폼 차단
    • 이름: EM002 - 응급 상황에서 사용: MFA 중단[2/4] - Exchange SharePoint - Windows를 제외한 액세스 차단
    • 사용자 및 그룹: 모든 사용자 포함. CoreAdmins 및 EmergencyAccess 제외
    • 클라우드 앱: Exchange Online 및 SharePoint Online
    • 조건: 디바이스 플랫폼, 모든 플랫폼 포함, Windows 제외
    • 컨트롤 권한 부여: 차단
    • 상태: 보고 전용
  • 정책 3: CorpNetwork 이외의 네트워크 차단
    • 이름: EM003 - 응급 상황에서 사용: MFA 중단[3/4] - Exchange SharePoint - 회사 네트워크를 제외한 액세스 차단
    • 사용자 및 그룹: 모든 사용자 포함. CoreAdmins 및 EmergencyAccess 제외
    • 클라우드 앱: Exchange Online 및 SharePoint Online
    • 조건: 위치, 모든 위치 포함, CorpNetwork 제외
    • 컨트롤 권한 부여: 차단
    • 상태: 보고 전용
  • 정책 4: EAS를 명시적으로 차단
    • 이름: EM004 - 응급 상황에서 사용: MFA 중단[4/4] - Exchange - 모든 사용자에 대한 EAS 차단
    • 사용자 및 그룹: 모든 사용자 포함
    • 클라우드 앱: Exchange Online 포함
    • 조건: 클라이언트 앱: Exchange Active Sync
    • 컨트롤 권한 부여: 차단
    • 상태: 보고 전용

활성화 순서:

  1. 기존 MFA 정책에서 ContingencyAccess, CoreAdmins 및 EmergencyAccess를 제외합니다. ContingencyAccess의 사용자가 SharePoint Online 및 Exchange Online에 액세스할 수 있는지 확인합니다.
  2. 정책 1 사용: 제외 그룹에 속하지 않은 도메인 가입 디바이스의 사용자가 Exchange Online 및 SharePoint Online에 액세스할 수 있는지 확인합니다. 제외 그룹에 속한 사용자가 모든 디바이스에서 SharePoint Online 및 Exchange에 액세스할 수 있는지 확인합니다.
  3. 정책 2 사용: 제외 그룹에 속하지 않은 사용자가 모바일 디바이스에서 SharePoint Online 및 Exchange Online에 액세스할 수 없는지 확인합니다. 제외 그룹에 속한 사용자가 모든 디바이스(Windows/iOS/Android)에서 SharePoint 및 Exchange에 액세스할 수 있는지 확인합니다.
  4. 정책 3 사용: 제외 그룹에 속하지 않은 사용자가 도메인 가입 컴퓨터를 사용하는 경우에도 회사 네트워크에서 SharePoint 및 Exchange에 액세스할 수 없는지 확인합니다. 제외 그룹에 속한 사용자가 모든 네트워크에서 SharePoint 및 Exchange에 액세스할 수 있는지 확인합니다.
  5. 정책 4 사용: 모든 사용자가 모바일 디바이스의 네이티브 메일 애플리케이션에서 Exchange Online에 연결할 수 없는지 확인합니다.
  6. SharePoint Online 및 Exchange Online에 대한 기존 MFA 정책을 사용하지 않도록 설정합니다.

이 다음 예제, 예 B - Salesforce에 대한 모바일 액세스를 허용하는 대응 조건부 액세스 정책에서는 비즈니스 앱의 액세스가 복원됩니다. 이 시나리오에서 고객은 일반적으로 판매 직원이 모바일 디바이스에서 Salesforce(Microsoft Entra ID를 통한 Single Sign-On으로 구성됨)에 액세스하여 규정 준수 디바이스에서만 허용되도록 요구합니다. 이 경우 중단이 발생하면 디바이스의 준수를 평가하는 데 문제가 있으며, 영업팀이 거래를 성사시키기 위해 Salesforce에 액세스해야 하는 중요한 시점에 중단이 발생하는 것입니다. 이러한 대응 정책을 통해 중요한 사용자는 모바일 디바이스에서 Salesforce에 액세스할 수 있으므로 거래를 계속 성사시키고 비즈니스를 중단하지 않을 수 있습니다. 이 예제에서 SalesforceContingency에는 액세스를 유지해야 하는 모든 판매 직원이 포함되며, SalesAdmins에는 Salesforce의 필수 관리자가 포함됩니다.

예 B - 대체 조건부 액세스 정책:

  • 정책 1: SalesContingency 팀에 속하지 않은 모든 사용자 차단
    • 이름: EM001 - 응급 상황에서 사용: 디바이스 준수 중단[1/2] - Salesforce - SalesforceContingency를 제외한 모든 사용자 차단
    • 사용자 및 그룹: 모든 사용자 포함. SalesAdmins 및 SalesforceContingency 제외
    • 클라우드 앱: Salesforce.
    • 조건: 없음
    • 컨트롤 권한 부여: 차단
    • 상태: 보고 전용
  • 정책 2: 모바일 이외의 플랫폼에서 영업 팀 차단(공격 노출 영역을 줄이기 위함)
    • 이름: EM002 - 응급 상황에서 사용: 디바이스 준수 중단[2/2] - Salesforce - iOS 및 Android를 제외한 모든 플랫폼 차단
    • 사용자 및 그룹: SalesforceContingency 포함. SalesAdmins 제외
    • 클라우드 앱: Salesforce
    • 조건: 디바이스 플랫폼, 모든 플랫폼 포함, iOS 및 Android 제외
    • 컨트롤 권한 부여: 차단
    • 상태: 보고 전용

활성화 순서:

  1. Salesforce에 대한 기존 디바이스 규정 준수 정책에서 SalesAdmins 및 SalesforceContingency를 제외합니다. SalesforceContingency 그룹에 속한 사용자가 Salesforce에 액세스할 수 있는지 확인합니다.
  2. 정책 1 사용: SalesContingency에 속하지 않은 사용자가 Salesforce에 액세스할 수 없는지 확인합니다. SalesAdmins 및 SalesforceContingency에 속한 사용자가 Salesforce에 액세스할 수 있는지 확인합니다.
  3. 정책 2 사용: SalesContingency 그룹에 속한 사용자가 Windows/Mac 랩톱에서는 Salesforce에 액세스할 수 없지만 모바일 디바이스에서는 계속 액세스할 수 있는지 확인합니다. SalesAdmin이 모든 디바이스에서 Salesforce에 계속 액세스할 수 있는지 확인합니다.
  4. Salesforce에 대한 기존 디바이스 규정 준수 정책을 사용하지 않도록 설정합니다.

온-프레미스 리소스의 사용자 잠금에 대한 비상 상황(NPS 확장)

Microsoft Entra 다단계 인증 NPS 확장을 사용하여 VPN 액세스를 보호하는 경우, VPN 솔루션을 SAML 앱으로 페더레이션하고 아래에서 권장하는 대로 앱 범주를 결정하는 것이 좋습니다.

MFA를 사용하는 VPN 및 원격 데스크톱 게이트웨이 등의 온-프레미스 리소스를 보호하기 위해 Microsoft Entra 다단계 인증 NPS 확장을 배포한 경우, 긴급 상황에서 MFA를 사용하지 않도록 설정할 준비가 되었는지 미리 고려해야 합니다.

이 경우 NPS 확장을 사용하지 않도록 설정할 수 있습니다. 결과적으로 NPS 서버는 기본 인증만 확인하고 사용자에게 MFA를 강제 적용하지 않습니다.

NPS 확장 사용 안 함:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters 레지스트리 키를 백업으로 내보냅니다.
  • 매개 변수 키가 아닌 "AuthorizationDLLs" 및 "ExtensionDLLs" 레지스트리 값을 삭제합니다.
  • 변경 내용을 적용하려면 IAS(네트워크 정책 서비스) 서비스를 다시 시작합니다.
  • VPN 기본 인증에 성공했는지 확인합니다.

서비스가 복구되고 사용자에게 MFA를 다시 강제 적용할 준비가 되면 NPS 확장 사용:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters 백업에서 레지스트리 키를 가져옵니다.
  • 변경 내용을 적용하려면 IAS(네트워크 정책 서비스) 서비스를 다시 시작합니다.
  • VPN에 대한 기본 인증과 보조 인증이 성공했는지 확인합니다.
  • NPS 서버 및 VPN 로그를 검토하여 응급 기간에 로그인한 사용자를 확인합니다.

페더레이션되었거나 통과 인증을 사용하는 경우에도 암호 해시 동기화 배포

다음 조건에 해당하는 경우에도 사용자 잠금이 발생할 수 있습니다.

  • 조직에서 통과 인증 또는 페더레이션을 통해 하이브리드 ID 솔루션을 사용합니다.
  • 온-프레미스 ID 시스템(예: Active Directory, AD FS 또는 종속 구성 요소)을 사용할 수 없습니다.

온-프레미스 ID 시스템의 가동이 중단되면 암호 해시 동기화를 사용하도록 전환할 수 있으므로 조직에서 복원력을 높이려면 암호 해시 동기화를 사용하도록 설정해야 합니다.

Microsoft 권장 사항

조직에서 페더레이션 또는 통과 인증을 사용하는지 여부에 관계없이 Microsoft Entra Connect 마법사를 사용하여 암호 해시 동기화를 사용하도록 설정합니다.

Important

암호 해시 동기화를 사용하기 위해 사용자를 페더레이션된 인증에서 관리 인증으로 변환할 필요가 없습니다.

중단 중

완화 계획을 구현하도록 선택한 경우 단일 액세스 제어 중단을 자동으로 견딜 수 있습니다. 그러나 대체 계획을 만들도록 선택한 경우 액세스 제어 중단 중에 다음과 같은 대응 정책을 활성화할 수 있습니다.

  1. 특정 네트워크에서 특정 애플리케이션에 대한 액세스 권한을 대상 사용자에게 부여하는 대응 정책을 사용하도록 설정합니다.
  2. 일반 제어 기반 정책을 사용 하지 않도록 설정합니다.

Microsoft 권장 사항

중단 중에 사용되는 완화 또는 대응 정책에 따라 조직에서 암호만 사용하는 액세스 권한을 부여할 수 있습니다. 보호 수단은 신중하게 고려해야 하는 중요한 보안상의 위험이 아닙니다. 조직에서 다음과 같이 수행해야 합니다.

  1. 변경 제어 전략의 일환으로 액세스 제어가 완전히 작동하는 즉시 구현한 모든 긴급 상황을 롤백할 수 있도록 모든 변경 내용과 이전 상태를 문서화합니다.
  2. 악의적인 행위자가 MFA를 사용하지 않는 동안 암호 스프레이 또는 피싱 공격을 통해 암호를 수집하려고 한다고 가정합니다. 또한 이전에 이 기간 동안 시도될 수 있는 리소스에 대한 액세스 권한을 부여하지 않은 암호가 악의적인 작업자에게 이미 있을 수도 있습니다. 임원과 같은 중요한 사용자의 경우 MFA를 사용하지 않도록 설정하기 전에 암호를 다시 설정하여 이 위험을 부분적으로 완화할 수 있습니다.
  3. 모든 로그인 활동을 보관하여 MFA가 사용되지 않는 동안 액세스한 사용자를 식별합니다.
  4. 이 기간에 보고된 모든 위험 검색을 심사합니다.

중단 후

중단이 발생한 서비스가 복원되면 활성화된 대체 계획의 일환으로 변경을 실행 취소합니다.

  1. 일반 정책을 사용하도록 설정합니다.
  2. 대체 정책을 보고 전용 모드로 다시 사용하지 않도록 설정합니다.
  3. 중단 중에 수행되고 문서화된 다른 변경을 롤백합니다.
  4. 응급 액세스 계정을 사용한 경우 응급 액세스 계정 절차의 일환으로 자격 증명을 다시 생성하고 새 자격 증명의 세부 정보를 물리적으로 보호합니다.
  5. 의심스러운 활동의 중단 후 보고된 모든 위험을 계속 심사합니다.
  6. 일련의 사용자를 대상으로 발급된 모든 새로 고침 토큰을 철회합니다. 모든 새로 고침 토큰을 철회하는 것은 중단 중에 사용되는 권한 있는 계정에 중요합니다. 이를 수행하는 경우 복원된 정책의 제어를 다시 인증하고 충족하도록 강제로 적용합니다.

응급 옵션

긴급 상황이 발생했는데 조직에서 이전에 완화 또는 대체 계획을 구현하지 않은 경우 MFA를 강제 적용하는 조건부 액세스 정책을 이미 사용하고 있다면 사용자 잠금 대체 섹션의 권장 사항을 따릅니다. 조직에서 사용자별 MFA 레거시 정책을 사용하는 경우 고려할 수 있는 대안은 다음과 같습니다.

  • 회사 네트워크 아웃바운드 IP 주소가 있으면 회사 네트워크에만 인증할 수 있도록 이를 신뢰할 수 있는 IP로 추가합니다.
  • 아웃바운드 IP 주소의 인벤토리가 없거나 회사 네트워크 내부 및 외부에서 액세스할 수 있어야 하는 경우 0.0.0.0/1 및 128.0.0.0/1을 지정하여 전체 IPv4 주소 공간을 신뢰할 수 있는 IP로 추가할 수 있습니다.

Important

신뢰할 수 있는 IP 주소를 확장하여 액세스 차단을 해제하면 IP 주소와 관련된 위험 검색(예: 불가능한 이동 또는 알 수 없는 위치)이 생성되지 않습니다.

참고 항목

Microsoft Entra 다단계 인증을 위한 신뢰할 수 있는 IP 구성은 Microsoft Entra ID P1 또는 P2 라이선스에서만 사용할 수 있습니다.

자세한 정보