Microsoft Entra ID에서 응급 액세스 계정 관리
관리자는 다른 사용자의 계정에 로그인하거나 이 계정을 활성화 수 없기 때문에 Microsoft Entra 조직에서 실수로 계정이 잠기는 것을 방지하는 것이 중요합니다. 조직에서 둘 이상의 응급 액세스 계정을 만들어 우발적인 관리 액세스 부족에 따른 영향을 완화할 수 있습니다.
응급 액세스 계정에는 높은 권한이 부여되고 특정 개인에게 할당되지 않습니다. 응급 액세스 계정은 일반 관리 계정을 사용할 수 없는 '비상' 시나리오의 긴급한 상황으로 제한됩니다. 응급 계정 사용은 절대적으로 필요한 경우에만 사용한다는 목표를 유지하는 것이 좋습니다.
이 문서에서는 Microsoft Entra ID에서 응급 액세스 계정을 관리하는 지침을 제공합니다.
응급 액세스 계정은 왜 사용하나요?
조직은 다음과 같은 상황에서 응급 액세스 계정을 사용해야 할 수도 있습니다.
- 사용자 계정이 페더레이션되고, 페더레이션이 현재 셀 네트워크 중단 또는 ID 공급자 중단으로 인해 사용할 수 없습니다. 예를 들어, 사용자 환경에서 ID 공급자 호스트가 중단된 경우 사용자는 Microsoft Entra ID가 해당 ID 공급자로 리디렉션할 때 로그인하지 못할 수 있습니다.
- 관리자는 Microsoft Entra 다단계 인증을 통해 등록되었고 관리자의 개별 디바이스를 모두 사용할 수 없거나 서비스를 사용할 수 없습니다. 사용자는 역할을 활성화하는 다단계 인증을 완료하지 못할 수도 있습니다. 예를 들어 셀 네트워크 장애로 인해 해당 디바이스에 대해 등록된 단 두 개의 인증 메커니즘인 수신 전화에 응답 및 문자 메시지 수신이 불가능할 수 있습니다.
- 최근 글로벌 관리자 액세스 권한이 있는 사용자가 조직을 떠났습니다. Microsoft Entra ID는 마지막 글로벌 관리자 계정이 삭제되지 않도록 할 수 있으나, 계정이 온-프레미스에서 삭제되거나 비활성화되는 것은 방지할 수 없습니다. 각 상황에서 조직은 계정을 복구하지 못할 수 있습니다.
- 자연 재해 비상 사태와 같이 예기치 않은 상황이 발생하여 휴대폰이나 기타 네트워크를 사용하지 못하는 경우.
응급 액세스 계정 생성
두 개 이상의 응급 액세스 계정을 생성합니다. 이러한 계정은 *.onmicrosoft.com 도메인을 사용하고 온-프레미스 환경에서 페더레이션되거나 동기화되지 않는 클라우드 전용 계정이어야 합니다.
긴급 액세스 계정을 만드는 방법
전역 관리자로 Microsoft Entra 관리 센터에 로그인합니다.
ID>사용자>모든 사용자로 이동합니다.
새 사용자를 선택합니다.
사용자 만들기를 선택합니다.
계정에 사용자 이름을 지정합니다.
계정에 이름을 지정합니다.
계정에 대해 길고 복잡한 암호를 만듭니다.
역할에서 전역 관리자 역할을 할당합니다.
사용 위치에서 적절한 위치를 선택합니다.
만들기를 실행합니다.
이러한 계정을 구성할 때는 다음 요구 사항이 충족되어야 합니다.
- 응급 액세스 계정은 조직의 개별 사용자와 연결되어서는 안 됩니다. 계정이 직원이 제공한 휴대폰, 개별 직원과 함께 이동하는 하드웨어 토큰 또는 기타 직원별 자격 증명과 연결되어 있지 않은지 확인합니다. 이 예방 조치는 개별 직원이 자격 증명이 필요한 경우 접근할 수 없는 인스턴스를 포함합니다. 등록된 모든 디바이스가 Microsoft Entra ID와 통신하는 여러 수단이 있는 안전하고 알려진 위치에 있는지 확인하는 것이 중요합니다.
- 비상 액세스 계정에 강력한 인증을 사용하고 다른 관리 계정과 동일한 인증 방법을 사용하지 않는지 확인합니다. 예를 들어 일반 관리자 계정이 강력한 인증을 위해 Microsoft Authenticator 앱을 사용하는 경우 비상 계정에 FIDO2 보안 키를 사용합니다. 인증 프로세스에 외부 요구 사항이 추가되지 않도록 다양한 인증 방법의 종속성을 고려합니다.
- 디바이스나 자격 증명이 만료되지 않아야 하고 사용 부족으로 인해 자동으로 정리되는 범위에 속하지 않아야 합니다.
- Microsoft Entra Privileged Identity Management에서 전역 관리자 역할 할당을 긴급 액세스 계정에 적용할 수 있는 권한이 아니라 영구적으로 설정해야 합니다.
전화 기반 다단계 인증에서 하나 이상의 계정 제외
암호 손상으로 인한 공격 위험을 줄이기 위해 Microsoft Entra ID에서는 모든 개별 사용자에 대해 다단계 인증을 요구하는 것이 좋습니다. 이 그룹에는 계정이 공격에 노출되면 상당한 영향을 미치는 관리자 및 기타 모든 사용자(예: 회계 담당자)가 포함됩니다.
그러나 응급 액세스 계정 중 하나 이상은 다른 비응급 계정과 동일한 MFA 메커니즘을 갖지 않아야 합니다. 여기에는 타사 다단계 인증 솔루션이 포함됩니다. Microsoft Entra ID 및 기타 연결된 SaaS(software as a service)의 모든 관리자에게 다단계 인증을 요구하는 조건부 액세스 정책이 있는 경우에는 이러한 요구 사항에서 응급 액세스 계정을 제외하고 대신 다른 메커니즘을 구성해야 합니다. 또한 계정에 사용자별 MFA 정책이 없는지 확인해야 합니다.
조건부 액세스 정책에서 하나 이상의 계정 제외
비상 시에는 정책에서 잠재적으로 액세스를 차단하여 문제를 해결하는 것을 원하지 않습니다. 조건부 액세스를 사용하는 경우 모든 조건부 액세스 정책에서 하나 이상의 긴급 액세스 계정을 제외해야 합니다.
참고 항목
Azure 팀은 2024년 7월부터 모든 사용자에 대해 MFA(다단계 인증)를 요구하는 추가 테넌트 수준 보안 조치를 롤아웃하기 시작합니다. 이미 문서화된 대로 응급 액세스 계정에 강력한 인증을 사용합니다. 긴 암호에만 의존하는 대신 FIDO2 또는 인증서 기반 인증(MFA로 구성된 경우)을 사용하도록 이러한 계정을 업데이트하는 것이 좋습니다. 두 방법 모두 MFA 요구 사항을 충족합니다.
페더레이션 지침
일부 조직은 AD 도메인 서비스 및 AD FS 또는 유사한 ID 공급자를 사용하여 Microsoft Entra ID에 페더레이션합니다. 온-프레미스 시스템에 대한 긴급 액세스와 클라우드 서비스에 대한 긴급 액세스는 서로 종속되지 않고 구별되어야 합니다. 다른 시스템에서 비상 액세스 권한이 있는 계정에 대한 인증을 마스터링 및/또는 소싱하면 해당 시스템이 중단될 경우 불필요한 위험이 추가됩니다.
계정 자격 증명을 안전하게 저장
조직은 응급 액세스 계정의 로그인 정보를 안전하게 유지하고 사용이 허가된 사람에게만 알려야 합니다. 일부 고객은 Windows Server AD의 스마트 카드, Microsoft Entra ID의 FIDO2 보안 키를 사용하고 다른 고객은 암호를 사용합니다. 한 응급 액세스 계정에 대한 암호는 일반적으로 두세 개 부분으로 나뉘는데, 각기 다른 종이에 써서 각기 다른 위치에 있는 안전한 내화 금고에 보관합니다.
암호를 사용하는 경우에는 계정에 만료되지 않는 강력한 암호가 있어야 합니다. 이상적으로, 암호는 16자 이상이어야 하고 임의로 생성되어야 합니다.
로그인 및 감사 로그 모니터링
조직은 응급 계정에서 로그인 및 감사 로그 작업을 모니터링 하고 다른 관리자에게 알림을 트리거해야 합니다. 비상 계정에서 작업을 모니터링하는 경우, 이러한 계정이 테스트 또는 실제 응급 상황에서만 사용되는지 확인할 수 있습니다. Azure Log Analytics를 사용하여 로그인 로그를 모니터링할 수 있으며, 비상 계정이 로그인할 때마다 관리자에게 이메일 및 SMS 경고를 트리거할 수 있습니다.
필수 조건
- Azure Monitor로 Microsoft Entra 로그인 로그를 보냅니다.
비상 계정의 개체 ID 가져오기
최소한 사용자 관리자로 Microsoft Entra 관리 센터에 로그인합니다.
ID>사용자>모든 사용자로 이동합니다.
비상 계정을 검색하고 사용자의 이름을 선택합니다.
개체 ID 특성을 복사하여 나중에 사용할 수 있도록 저장합니다.
두 번째 비상 계정에 대해 이전 단계를 반복합니다.
경고 규칙 만들기
적어도 모니터링 기여자로 Azure Portal에 로그인합니다.
모니터링>Log Analytics 작업 영역으로 이동합니다.
작업 영역을 선택합니다.
작업 영역에서 경고>새 경고 규칙을 선택합니다.
리소스에서 구독이 경고 규칙을 연결하려는 구독에 해당되는지 확인합니다.
조건에서 추가를 선택합니다.
신호 이름에서 사용자 지정 로그 검색을 선택합니다.
검색 쿼리에서 다음 쿼리를 입력하여 두 개의 비상 계정에 대한 개체 ID를 삽입합니다.
참고 항목
포함하려는 각 추가 비상 계정에 대해 다른 "or UserId == "ObjectGuid""를 쿼리에 추가합니다.
샘플 쿼리:
// Search for a single Object ID (UserID) SigninLogs | project UserId | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
// Search for multiple Object IDs (UserIds) SigninLogs | project UserId | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
// Search for a single UserPrincipalName SigninLogs | project UserPrincipalName | where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
경고 논리에서 다음을 입력합니다.
- 기준: 결과 수
- 연산자: 보다 큼
- 임계값: 0
평가 기준에서 쿼리를 실행할 기간에 대한 기간(분)과 쿼리를 실행할 빈도에 대한 빈도(분)를 각각 선택합니다. 빈도는 기간보다 작거나 같아야 합니다.
완료를 선택합니다. 이제 이 경고의 월별 예상 비용을 볼 수 있습니다.
경고에서 알림을 받을 사용자의 작업 그룹을 선택합니다. 작업 그룹 하나를 만들려면 작업 그룹 만들기를 참조하세요.
작업 그룹의 멤버로 전송 되는 이메일 알림을 사용자 지정 하려면 작업 사용자 지정에서 작업을 선택합니다.
경고 세부 정보에서 경고 규칙 이름을 지정하고 설명(선택 사항)을 추가합니다.
이벤트의 심각도 수준을 설정합니다. 중요(심각도 0)로 설정하는 것이 좋습니다.
생성 시 규칙 사용에서는 예로 설정된 상태로 둡니다.
잠시 동안 경고를 해제하려면 경고 표시 안 함 확인란을 선택하고, 경고를 다시 표시하기 전에 대기 시간을 입력한 후 저장을 선택 합니다.
경고 규칙 만들기를 클릭합니다.
작업 그룹 만들기
작업 그룹 만들기를 선택합니다.
작업 그룹 이름 및 짧은 이름을 입력합니다.
구독 및 리소스 그룹을 확인합니다.
작업 유형에서 이메일/SMS/푸시/음성을 선택합니다.
작업 이름(예: 전역 관리자에게 알림)을 입력합니다.
작업 유형을 이메일/SMS/푸시/음성으로 선택합니다.
세부 정보 편집을 선택하여 구성하려는 알림 방법을 선택하고 필요한 연락처 정보를 입력한 후 확인을 선택하여 세부 정보를 저장합니다.
트리거할 추가 작업을 추가합니다.
확인을 선택합니다.
정기적으로 계정 유효성 검사
응급 액세스 계정을 사용하고 응급 액세스 계정의 유효성을 검사하도록 직원을 교육할 때에는 최소한 다음 단계를 일정한 간격으로 수행하세요.
- 보안 모니터링 직원이 계정 검사 작업이 진행 중임을 알고 있는지 확인합니다.
- 이 계정을 사용할 수 있는 응급 비상 프로세스가 문서화되어 있고 최신 상태인지 확인합니다.
- 응급 상황 시, 이 단계를 수행해야 하는 관리자와 보안 담당자가 해당 프로세스에 대한 교육을 받도록 합니다.
- 응급 액세스 계정의 계정 로그인 정보(특히 암호)를 업데이트한 다음, 응급 액세스 계정이 로그인할 수 있고 관리 작업을 수행할 수 있는지 확인합니다.
- 사용자가 개별 사용자의 디바이스 또는 개인 정보에 MFA 또는 SSPR(셀프 서비스 암호 재설정)을 등록하지 않았는지 확인합니다.
- 로그인 또는 역할 활성화 중에 사용할 수 있도록 디바이스에 대한 다단계 인증에 계정이 등록된 경우 응급 상황에서 디바이스를 사용해야 하는 모든 관리자가 디바이스에 액세스할 수 있어야 합니다. 또한 디바이스가 공통 오류 모드를 공유하지 않는 두 개 이상의 네트워크 경로를 통해 통신할 수 있는지 확인합니다. 예를 들어 디바이스는 시설의 무선 네트워크 및 휴대 전화 공급자 네트워크 모두를 통해 인터넷과 통신할 수 있습니다.
다음 단계는 정기적인 간격으로 수행하고 주요 변경 사항이 있는 경우에도 수행해야 합니다.
- 최소 90일 간격
- 업무 변동, 사직 또는 신규 채용과 같이 최근 IT 직원에 변동이 있는 경우
- 조직의 Microsoft Entra 구독이 변경된 경우