조건부 액세스와 PIM이 실제로 공격을 어떻게 차단하는가?

암호 정책은 추측 공격을 차단한다. 하지만 탈취된 세션 토큰, 피싱된 MFA 프롬프트, 2년간 Global Administrator 권한으로 방치된 관리자 계정에는 아무 것도 할 수 없다. 조건부 액세스와 Privileged Identity Management(PIM)는 Azure AD / Entra ID의 이러한 공백을 실제로 해결하는 두 가지 제어 메커니즘이며, 함께 사용할 때 가장 효과적이다.

조건부 액세스가 내부에서 하는 일

조건부 액세스는 로그인 시점에 평가되는 if-this-then-that 엔진이다. "if" 측면(신호)에는 사용자/그룹 멤버십, 디바이스 규정 준수 상태, 네트워크 위치, 로그인 위험(Identity Protection에서), 액세스할 애플리케이션, 클라이언트 앱 유형(브라우저 대 레거시 프로토콜)이 포함된다. "then" 측면(제어)에는 MFA 필요, 규정 준수 디바이스 필요, 승인된 클라이언트 앱 필요, 액세스 완전 차단 또는 이용약관 동의 필요가 포함된다.

거의 모든 테넌트에서 중요한 정책이 하나 있다: 레거시 인증 차단. POP, IMAP, 구형 SMTP 같은 프로토콜은 최신 MFA 챌린지를 지원하지 않으므로 자격증명 채우기 도구가 가장 먼저 시도하는 대상이다. 차단하기 전에 "Client App = Other clients"로 필터링된 로그인 로그를 확인하라. 기본 인증으로 여전히 인증하는 레거시 스캐너나 구형 복합기가 남아 있을 것이다.

처음부터 갖춰야 할 두 번째 정책: 모든 사용자에게 MFA 필요, break-glass 계정에만 제외 그룹으로 범위 지정. MFA를 "관리자만"으로 범위를 좁히지 마라. 손상된 일반 사용자 계정이 권한 상승이 시작되기 전에 공격자가 발판을 잡는 방식이다.

로그인 위험 대 사용자 위험 — 다른 신호, 다른 대응

Identity Protection(Entra ID P2의 일부)은 두 개의 별도 위험 점수를 생성하며 이 둘을 혼동하기 쉽다:

• 로그인 위험 — 이 특정 인증 시도가 비정상적으로 보인다(불가능한 이동, 익명 IP, 낯선 로그인 속성).
• 사용자 위험 — 이 계정이 정체성 자체와 관련된 이유로 플래그되었다(위반 코퍼스에서 발견된 유출 자격증명, 확인된 손상 활동).

로그인 위험에 대응하는 조건부 액세스 정책은 일반적으로 MFA로 챌린지해야 한다. 실제 사용자가 챌린지를 완료할 수 있으면 통과시킨다. 사용자 위험에 대응하는 정책은 암호 재설정을 강제해야 한다. 왜냐하면 자격증명 자체가 이미 손상되었으면 MFA만으로는 도움이 되지 않기 때문이다.

상시 관리자 액세스가 더 큰 문제인 이유

조건부 액세스가 완벽해도 Global Administrator를 영구적으로 보유한 계정은 디렉토리에서 명백하게 보이는 목표다. 누군가 이를 손상시키면 추가 단계 없이 전체 테넌트 제어를 상속받는다. PIM이 "영구적"이라는 부분을 제거한다.

PIM에서 관리자 역할은 활성이 아닌 적격으로 할당된다. 사용자는 역할을 명시적으로 활성화해야 하며, 이는 필수 정당화, 선택적 승인 워크플로, MFA 재확인, 그리고 일반적으로 1시간에서 8시간의 시간 제한 윈도우를 트리거한다. 이 윈도우가 지나면 역할이 자동으로 비활성화된다. 계정 소유자를 포함한 아무도 적극적으로 사용하지 않는 한 상시 Global Admin을 가지지 않는다.

실제로 사용 가능한 최소 PIM 구성

• Helpdesk Administrator보다 상위 모든 역할: 적격이며 영구적이지 않음.
• Global Administrator와 Privileged Role Administrator: 자가 활성화가 아닌 두 번째 관리자의 승인 필요.
• 활성화 MFA 필수, 예외 없음.
• 최대 활성화 기간 4시간은 사람들이 실제로 별도의 작업 세션에 대해 재활성화하도록 강제하며, 이는 더 깔끔한 감사 추적도 생성한다.
• 모든 적격 할당에 대해 90일마다 액세스 검토 — 계정이 한 프로젝트를 위해 추가되고 제거되지 않는 경우가 있다.

팀이 이것을 잘못하는 곳

가장 흔한 실패는 정책 설계가 아니라 제외 목록이다. "이 앱이 MFA를 지원하지 않으므로 이 사용자들을 제외하라"는 그룹이 계속 늘어나는 조건부 액세스 정책은 결국 테넌트의 절반을 제외한다. 제외를 영구적 버킷이 아니라 소유자와 제거 날짜가 있는 백로그 항목으로 추적하라.

두 번째 실패는 실제로 테스트되지 않은 break-glass 계정이다. 조건부 액세스와 PIM에서 제외된 두 개의 비상 계정, 오프라인 저장된 긴 무작위 암호, 모든 로그인에 대한 알림 — 그리고 누군가는 분기별로 로그인을 시도해서 여전히 작동하는지 확인해야 한다.

조건부 액세스와 PIM은 규정 준수 감사를 위한 체크박스가 아니다. 이들은 피싱된 자격증명이 불편함인지 아니면 전체 테넌트 손상인지의 차이다. Blue Team 구축의 일부로 ID 제어를 매핑하고 있다면, Korra Studio의 Cloud와 Blue Team 세그먼트가 탐지 측면을 다룬다 — Identity Protection 위험 이벤트가 Sentinel에서 실제로 어떻게 보이는지, 그리고 불가능한 PIM 활성화 패턴에 대해 어떻게 알림을 설정할지.