Microsoft Entra 조건부 액세스 기준선: 잠금 위험을 줄이는 단계적 배포 순서

2025년 10월 1일부터 Azure CLI, PowerShell, 인프라-as-코드(IaC), REST API의 create·update·delete 작업에도 MFA가 요구된다(읽기 작업은 제외)(Kaine Cohen, Conditional Access policies). 이 글은 Microsoft Entra 조건부 액세스(Conditional Access, 이하 CA) 정책의 단계적 배포 순서와 각 단계의 판단 근거를 정리한다.

개요

CA 정책은 report-only → 파일럿 → 전체의 단계를 거쳐 적용되며, break-glass 계정은 모든 정책에서 제외된다. Microsoft는 이 전이를 약 4주에 걸쳐 진행하도록 권장하지만, 조직 규모와 레거시 클라이언트 비율에 따라 실제 소요 기간은 달라질 수 있다.

적용 환경·전제조건

라이선스 요구

커스텀 CA 정책은 Entra ID P1 라이선스가 필요하다. Business Premium 또는 Microsoft 365 E3 / E5 / F3에 포함된다. 위험 기반(risk-based) 정책, 즉 의심 사인인에 반응하는 정책은 Entra ID P2(E5 또는 스탠드올론 애드온)를 요구한다.

관리 표면

Azure portal, Entra admin centre, Intune admin centre를 포함해 관리 표면에서 MFA가 요구된다. 2025년 10월 1일부터는 Azure CLI, PowerShell, IaC, REST API의 create·update·delete 작업에도 MFA가 요구되며, 읽기 작업은 제외된다.

Break-glass 계정

배포 전 break-glass 계정을 설계해야 한다. 권장 구성은 다음과 같다.

• .onmicrosoft.com 도메인의 클라우드 전용 Global Admin 계정 두 개
• 오프라인에 보관하는 장문자 고유 자격증명
• 일반 관리자 로그인과 다른 phishing-resistant 인증 방법
• 모든 CA 정책에서 제외
• 로그인 활동에 대한 알림

레거시 프로토콜

레거시 프로토콜(Legacy Auth)은 MFA와 장치 점검을 수행할 수 없다.

기술 절차·판단 근거

세 단계 진행: report-only → 파일럿 → 전체

출처가 설명한 CA 정책들은 동일한 진행 순서를 따른다: report-only 모드로 활성화하고, 파일럿 그룹에서 확인한 후 전체 대상에 적용한다. 즉시 on으로 전환하지 않는 것이 권고된다. break-glass 계정은 이 모든 정책에서 제외되므로, 어떤 정책도 break-glass 계정의 접근을 완전히 차단하지 않는다.

레거시 프로토콜 전용 차단

MFA-for-all 정책이 레거시 프로토콜을 부수 효과로 차단하지만, 전용 차단 정책을 별도로 두면 명시적이고 감사 가능하며, MFA로 통제하지 않는 앱까지 커버한다.

Phishing-resistant MFA 인증 강도

Push 알림과 SMS는 피싱에 취약하므로 "MFA가 있으면 된다"는 기준이 여기서는 부족하다. CA 정책의 인증 강도 기준은 Phishing-resistant MFA로 설정해야 한다. 해당 방식은 passkeys / FIDO2, Windows Hello for Business, certificate-based auth이다.

MFA 등록 잠금

비밀번호가 피싱으로 유출된 후, 공격자가 해당 계정에 자신의 MFA 방법을 등록하려고 시도할 수 있다. 이 행위를 차단하기 위해, 출처는 Register security information 액션에 MFA 요구(기존 MFA 방법을 보유한 사용자의 경우)와 신뢰 네트워크 또는 compliant device 조건을 결합하는 정책을 권고한다.

광역 기준선: 앱 제외 없음

대상 범위는 모든 리소스를 앱 제외 없이 적용하는 것이 Microsoft 자체 권장 사항이다. 각 제외 항목은 저권한 간극이 되며, 공격자의 우회 경로로 활용될 수 있다.

Security Defaults 전환

기존 Security Defaults를 사용 중이라면, 비활성화 시점과 MFA 커버 유지를 동일한 변경에서 처리해야 한다.

• Microsoft의 "upgrade from Security Defaults" managed policies로 MFA를 이관하거나, 핵심 MFA 정책을 즉시 적용
• 예상치 못한 잠금을 유발할 수 있는 추가 정책(policies 5 through 7)은 report-only로 전환 후 수 주 관찰
• 확인 후 강제 적용

운영상 영향

Push 알림과 SMS 기반 MFA는 피싱에 취약하다. CA 정책의 인증 강도가 Phishing-resistant MFA 기준(passkeys / FIDO2, Windows Hello for Business, certificate-based auth)으로 설정되지 않으면, 피싱으로 MFA가 우회되어 정책의 실질적 효력이 약화될 수 있다.

앱 제외 항목이 존재하면 해당 앱이 저권한 간극이 되어 공격자의 우회 경로로 활용될 수 있다.

탐지·대응

즉시 수행

• 라이선스 확인: 커스텀 CA는 Entra ID P1, risk-based 정책은 P2
• Break-glass 계정 설정: .onmicrosoft.com 도메인의 두 개 클라우드 전용 Global Admin 계정, 오프라인 보관 장문자 고유 자격증명, 일반 관리자 로그인과 다른 phishing-resistant 방법, 모든 정책에서 제외, 로그인 활동 알림
• CA 정책을 report-only 모드로 활성화하고 즉시 on으로 전환하지 않기
• 레거시 프로토콜 전용 차단 정책 검토: MFA·장치 점검 불가 프로토콜에 대한 명시적·감사 가능한 차단

지속적 운영

• Break-glass 계정 로그인 활동 알림: 모든 CA 정책에서 제외된 계정의 사인인 활동에 대한 알림
• Report-only 기간 로그 분석: 어떤 사용자·앱·장치가 차단 대상에 해당하는지 사전 파악

장기 대응

• Phishing-resistant MFA 인증 강도 설정: passkeys/FIDO2, Windows Hello for Business, certificate-based auth
• MFA 등록 잠금 정책: Register security information 액션에 MFA 요구 + 신뢰 네트워크 또는 compliant device
• 전체 리소스 대상, 앱 제외 없는 광역 기준선 운영
• Security Defaults 비활성화 시점과 MFA 정책 강제 전환을 동일한 변경에서 처리, 추가 정책은 report-only 후 수 주 관찰

한계 및 참고자료

본 가이드의 사실적 근거는 단일 출처에 기반하며, 독립적 교차 검증이 수행되지 않았다. Security Defaults 전환 맥락에서 report-only 관찰 대상이 되는 policies 5 through 7의 개별 정책 정의(대상 사용자, 조건, 액션)는 증거에 명시적으로 나열되지 않아, 해당 정책들의 구체적 조건은 출처 원문 전체를 참조해야 확인 가능하다. 또한 위험 기반 정책의 세부 동작(예: 어떤 시그널이 고위험 사인인으로 분류되는지)는 증거에 포함되지 않았다. 출처에 언급된 '약 4주' 일정은 단일 2차 출처의 언급이며, 조직 규모와 레거시 클라이언트 비율에 따라 실제 소요 기간이 달라질 수 있다.

참고자료

• Conditional Access policies: what exactly are they, and where do you start?

함께 읽으면 좋은 글

• BraZetsu가 감염된 Windows 호스트를 거래 자산으로 바꾸는 구조: 초기 접근 브로커와 AI 강화 지하마켓
• CVE-2026-85216: MISP 2.5.45 이하의 LDAP·LinOTP 인증 우회 취약점 점검 가이드
• CVE-2026-81578 대응 가이드: PaperCut NG/MF 중요 기능 인증 누락 KEV 점검

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.