Azure 조건부 액세스 MFA 도입: 잠기지 않고 정책 3개 켜는 순서

조건부 액세스(Conditional Access)를 처음 켤 때 가장 흔한 사고는 자기 자신이 잠기는 것입니다. “모든 사용자에게 MFA 필수” 정책을 만들고 저장한 뒤 로그아웃했는데, 관리자 계정에 MFA가 등록돼 있지 않아 다시 들어갈 수 없게 되는 상황입니다.

이 글은 정책 세 개를 만드는 방법이지만, 순서가 내용보다 중요합니다. 비상 계정 준비 → 보고서 전용 모드 검증 → 단계적 활성화 순으로 가야 사고가 안 납니다. 순서대로 정리하겠습니다.

0단계 — 비상 액세스 계정부터 만든다 (필수)

정책을 만들기 전에 반드시 해야 하는 일입니다. Microsoft도 공식적으로 권장하는 구성으로, 모든 조건부 액세스 정책에서 제외되는 계정을 2개 만들어 둡니다.

2개를 만드는 이유 — 하나가 손상되거나 잠겨도 나머지로 복구
클라우드 전용 계정으로 (온프레미스 AD 동기화 계정은 AD 장애 시 같이 막힘)
기본 도메인 사용 (...onmicrosoft.com). 커스텀 도메인은 DNS 문제 시 인증이 막힐 수 있음
전역 관리자 권한 부여, 매우 긴 랜덤 비밀번호를 물리적으로 분리 보관
특정 사용자에게 귀속되지 않는 이름 (break-glass-01 등)

그리고 이 계정의 로그인에 알림을 걸어두세요. 비상 계정은 평소에 절대 쓰이지 않아야 하므로, 로그인 기록이 잡히면 그 자체가 이상 징후입니다.

// Log Analytics에서 실행 - 비상 계정 로그인 감지
SigninLogs
| where UserPrincipalName has "break-glass"
| project TimeGenerated, UserPrincipalName, IPAddress,
          AppDisplayName, ResultType, Location
| sort by TimeGenerated desc

이 쿼리를 경고 규칙으로 만들어 두면 됩니다. 설정 방법은 Azure Monitor 알림 설정 글에 정리해두었습니다.

먼저 알아야 할 것: 보안 기본값과 조건부 액세스는 공존하지 않는다

Entra ID에는 보안 기본값(Security Defaults)이라는 무료 기능이 있습니다. 모든 사용자에게 MFA를 강제하는 단순한 스위치입니다. 조건부 액세스를 쓰려면 이걸 먼저 꺼야 합니다. 둘은 동시에 켤 수 없습니다.

	보안 기본값	조건부 액세스
비용	무료	Entra ID P1 이상
세밀함	전부 아니면 전무	사용자·앱·위치·기기별
예외 처리	불가	가능 (비상 계정 제외 등)
적합한 규모	소규모, 라이선스 없음	예외가 필요한 조직

라이선스가 없다면 보안 기본값을 켜는 것이 정답입니다. 안 켜는 것보다 훨씬 낫습니다. 아래 내용은 P1 이상을 보유한 경우입니다.

정책 1 — 관리자 역할에 MFA 강제

가장 먼저 넣어야 할 정책입니다. 전체 사용자가 아니라 관리자 역할부터 시작하는 이유는, 대상이 적어 문제가 생겨도 수습이 쉽고 보안 효과는 가장 크기 때문입니다. 공격자가 노리는 건 일반 사용자가 아니라 권한 있는 계정입니다.

이름	CA01-Require-MFA-for-Admins
사용자 포함	디렉터리 역할 → 전역 관리자, 보안 관리자, 사용자 관리자, 조건부 액세스 관리자, 권한 있는 역할 관리자 등
사용자 제외	비상 액세스 계정 2개
대상 리소스	모든 클라우드 앱
부여	액세스 권한 부여 → 다단계 인증 필요

제외 항목을 비워두고 저장하면 안 됩니다. 포털이 경고를 띄우지만 무시하고 넘어가는 경우가 많습니다.

정책 2 — 레거시 인증 차단

이 정책이 실질적으로 가장 큰 효과를 냅니다. MFA를 강제해도 레거시 인증 경로가 열려 있으면 우회가 가능하기 때문입니다.

레거시 인증이란 POP3, IMAP, SMTP AUTH, 구형 Office 클라이언트가 쓰는 기본 인증(Basic Authentication) 방식입니다. 사용자명과 비밀번호만 주고받는 구조라 MFA를 지원하지 않습니다. 비밀번호가 유출되면 MFA 정책이 있어도 그대로 뚫립니다. 비밀번호 스프레이 공격의 상당수가 이 경로를 노립니다.

이름	CA02-Block-Legacy-Authentication
사용자 포함	모든 사용자
사용자 제외	비상 액세스 계정 + (필요 시) 서비스 계정
조건 → 클라이언트 앱	Exchange ActiveSync 클라이언트, 기타 클라이언트
부여	액세스 차단

켜기 전에 레거시 인증을 실제로 쓰는 것이 있는지 반드시 확인하세요. 스캐너에서 메일 보내기, 오래된 백업 스크립트, 구형 사내 시스템이 여기에 걸립니다. 확인 없이 차단하면 업무가 멈춥니다.

// 지난 30일간 레거시 인증 사용 현황
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Other clients", "IMAP4", "POP3",
                          "SMTP", "Exchange ActiveSync")
| summarize Attempts = count(),
            Success = countif(ResultType == 0)
          by UserPrincipalName, ClientAppUsed, AppDisplayName
| sort by Attempts desc

이 결과가 비어 있으면 바로 차단해도 됩니다. 뭔가 나오면 해당 시스템을 최신 인증으로 전환하거나, 전환 전까지 그 계정만 제외해두고 기한을 정해 정리하세요.

정책 3 — 위험한 로그인에 MFA 요구

세 번째는 조직 상황에 따라 둘 중 하나를 고릅니다.

선택 A — 신뢰할 수 없는 위치에서 MFA (P1)

사무실 IP를 명명된 위치로 등록하고, 그 밖에서 접속할 때만 MFA를 요구합니다. 사용자 마찰이 적어 도입 저항이 낮습니다.

조건 → 위치: 모든 위치 포함, 신뢰할 수 있는 위치 제외
부여: 다단계 인증 필요

주의할 점은 IP 기반 신뢰는 생각보다 약하다는 것입니다. 사무실 네트워크에 들어온 공격자나, VPN을 통해 사내 IP를 획득한 경우에는 MFA가 면제됩니다. 편의를 위한 타협이라는 걸 인지하고 쓰셔야 합니다.

선택 B — 로그인 위험 기반 (P2)

Entra ID P2가 있다면 이쪽이 훨씬 낫습니다. Identity Protection이 익명 IP, 불가능한 이동, 비정상 토큰 등을 탐지해 위험도를 매기고, 위험할 때만 MFA를 요구합니다.

조건 → 로그인 위험: 중간, 높음
부여: 다단계 인증 필요

“불가능한 이동”은 실무에서 VPN 사용 시 오탐이 자주 납니다. 서울에서 로그인한 직후 VPN으로 미국 IP가 잡히면 위험으로 분류됩니다. 도입 초기에는 위험 탐지 로그를 며칠 지켜보고 임계값을 정하는 편이 좋습니다.

어떤 MFA 방식을 허용할 것인가

“MFA 필요”에 체크하면 끝이 아닙니다. 어떤 두 번째 인증 수단을 허용할지가 실제 보안 수준을 결정합니다. 방식마다 안전성 차이가 큽니다.

방식	피싱 저항	평가
SMS 문자	없음	SIM 스와핑·중간자 공격에 취약. 가능하면 배제
음성 통화	없음	SMS와 동일한 문제
Authenticator 알림 승인	낮음	MFA 피로 공격에 취약 (계속 밀어 승인 유도)
Authenticator + 번호 일치	중간	화면의 숫자를 입력해야 함. 현실적인 기본값
FIDO2 보안 키 / Windows Hello	높음	도메인이 검증되어 피싱 자체가 불가. 관리자 계정에 권장

MFA 피로 공격(MFA Fatigue)이 최근 몇 년간 실제로 자주 성공한 수법입니다. 공격자가 탈취한 비밀번호로 로그인을 계속 시도하면 사용자 휴대폰에 승인 알림이 반복해서 뜹니다. 밤중에 수십 번 울리면 결국 “잘못 눌렀나” 하며 승인하게 됩니다.

번호 일치(Number Matching)는 이걸 막습니다. 로그인 화면에 표시된 두 자리 숫자를 앱에 직접 입력해야 하므로, 화면을 보고 있지 않으면 승인할 수 없습니다. 현재 Microsoft Authenticator에서 기본 동작이지만, 인증 방법 정책에서 켜져 있는지 확인해 두시는 편이 좋습니다.

전역 관리자처럼 권한이 큰 계정에는 FIDO2 보안 키를 별도로 요구하는 정책을 두는 것도 방법입니다. 조건부 액세스의 인증 강도(Authentication Strengths) 기능으로 “피싱 방지 MFA”를 지정하면, 관리자는 보안 키로만 로그인하도록 강제할 수 있습니다.

서비스 계정은 어떻게 처리하나

정책을 켤 때 가장 자주 막히는 게 사람이 아닌 계정입니다. 배치 스크립트, 모니터링 도구, 백업 에이전트가 쓰는 계정에는 MFA를 걸 수 없습니다. 대응은 세 가지입니다.

관리 ID(Managed Identity)로 전환 — 가장 좋은 답입니다. 자격 증명 자체가 없어지므로 MFA 논의가 무의미해집니다. Azure 리소스에서 Azure 리소스로 접근하는 경우 대부분 전환 가능합니다.
서비스 주체 + 인증서 — 외부 시스템이라 관리 ID를 못 쓸 때. 비밀번호 대신 인증서를 쓰고 만료 주기를 관리합니다.
사용자 계정 유지 + 정책 제외 — 최후의 수단. 이 경우 반드시 IP 기반 위치 조건을 걸어 특정 서버에서만 로그인 가능하게 제한하세요. 아무 조건 없이 제외만 하면 그 계정이 조직의 구멍이 됩니다.

3번을 택했다면 제외 목록을 분기마다 재검토하는 일정을 잡아두시길 권합니다. 임시로 넣은 예외가 몇 년째 남아 있는 경우가 흔합니다.

활성화 순서 — 여기서 사고가 갈린다

정책 세 개를 다 만들었어도 바로 “사용”으로 켜면 안 됩니다. 조건부 액세스에는 보고서 전용(Report-only) 모드가 있습니다. 정책을 실제로 적용하지 않으면서 “켰다면 누가 걸렸을지”를 로그로만 남깁니다.

세 정책 모두 보고서 전용으로 생성
최소 1주일 방치 (월요일 배치, 월말 정산 등 주기적 작업을 포함해야 하므로)
로그를 분석해 예상 밖으로 걸리는 대상 확인
필요한 예외를 추가
정책 1 → 정책 2 → 정책 3 순으로 하나씩 활성화
각 활성화 후 최소 하루 관찰

보고서 전용 결과는 이 쿼리로 봅니다.

SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand CA = ConditionalAccessPolicies
| where CA.result in ("reportOnlyFailure", "reportOnlyInterrupted")
| extend PolicyName = tostring(CA.displayName)
| summarize AffectedUsers = dcount(UserPrincipalName),
            Attempts = count()
          by PolicyName, AppDisplayName, ClientAppUsed
| sort by Attempts desc

reportOnlyFailure가 많이 잡히는 앱이 있으면, 그게 실제 활성화 시 업무가 멈추는 지점입니다. 대부분 여기서 몰랐던 서비스 계정이나 오래된 클라이언트가 발견됩니다.

잠겼을 때의 복구 절차

그럼에도 잠겼다면 순서는 이렇습니다.

비상 액세스 계정으로 로그인 — 0단계를 했다면 여기서 끝납니다
Entra 관리 센터 → 조건부 액세스 → 문제 정책을 사용 안 함으로
비상 계정이 없다면 Microsoft 지원에 문의하는 방법뿐입니다. 테넌트 소유권 증빙이 필요하고 시간이 걸립니다

3번까지 가면 그동안 조직 전체가 멈춥니다. 0단계에 5분 쓰는 것과 비교할 수 없습니다.

그다음에 넣을 만한 정책들

세 개가 안정화되면 아래를 순서대로 검토하시면 됩니다.

정책	효과	도입 난이도
Azure 관리(포털·CLI) 접근 시 MFA	인프라 변경 경로 보호	낮음
기기 규정 준수 요구 (Intune 연동)	관리되지 않는 기기 차단	높음 (MDM 선행 필요)
승인된 클라이언트 앱만 허용	모바일에서 데이터 유출 방지	중간
세션 지속 시간 제한	공유 PC 위험 감소	낮음 (사용자 불만 주의)
게스트 사용자에 별도 MFA	외부 협업자 통제	낮음

가장 먼저 추가할 것은 Azure 관리 접근 시 MFA입니다. 대상 리소스에서 “Microsoft Azure Management”를 선택하면 됩니다. 포털·CLI·PowerShell·REST API가 모두 포함되어, 인프라를 바꿀 수 있는 모든 경로가 한 번에 보호됩니다.

정리

비상 액세스 계정 2개를 먼저 만들고 모든 정책에서 제외한다
보안 기본값을 끈다 (조건부 액세스와 공존 불가)
정책 3개를 보고서 전용으로 만들고 1주일 관찰한다
레거시 인증 사용처를 KQL로 확인한 뒤 차단한다
하나씩 순차 활성화하고 각각 하루씩 관찰한다

조건부 액세스는 정책의 내용보다 활성화 절차에서 사고가 납니다. 보고서 전용 모드를 건너뛰고 싶은 유혹이 크지만, 1주일을 아끼려다 하루를 멈추는 경우가 훨씬 비쌉니다.

ID 보안을 이어서 보실 분들께는 Key Vault로 시크릿 관리하기와 Bastion으로 22번 포트 닫기를 권합니다. 계정 보호, 자격 증명 보호, 접근 경로 보호가 각각 다른 층입니다.