직원이 피싱 이메일 링크를 클릭했다. 정상 로그인 페이지처럼 생긴 사이트였다. 비밀번호와 TOTP를 입력하자 로그인이 됐다. 인증이 성공하는 순간, 프록시는 서버가 발급한 세션 쿠키를 가로챘다. 세션 쿠키는 "이미 인증된 사용자임을 증명하는 토큰"이다. 이것을 가진 사람은 비밀번호나 TOTP 없이도 해당 서비스에 접속할 수 있다.
이 시간이 오전 9시, 서울이었다.
오전 11시, 같은 계정이 런던에서 접속됐다. 공격자가 탈취한 세션 쿠키를 HTTP 요청에 그대로 심어 보낸 것이다. 서버는 "유효한 세션"이라고만 봤다. 아무 이상을 감지하지 못했다.
두 시간 안에 서울에서 런던으로 이동하는 것은 물리적으로 불가능하다. 그런데 그 판단을 할 수 있는 시스템이 없었다. 정적(Static) MFA는 로그인 시점만 검증하고 "이 순간 이 인증 요소를 가지고 있는가"를 확인할 뿐, "이 접속이 정상적인 상황에서 이루어지고 있는가"는 판단하지 않는다. 로그인 이후의 세션이 어디서, 어떻게 사용되고 있는지는 관심 밖이다.
문제는 비밀번호나 TOTP 같은 인증 요소 자체가 아니다. 인증이 컨텍스트를 보지 않는다는 것이다.
정적 MFA의 두 가지 실패
정적 MFA가 만드는 실패는 두 방향에서 온다.
하나는 불필요한 마찰이다. 매일 같은 기기, 같은 사무실 Wi-Fi, 업무 시간대에 로그인하는 직원에게 TOTP를 매번 요구하는 것은 실질적인 보안 효과보다 생산성 손실이 크다. 여러 애플리케이션을 쓰는 환경에서 세션 만료마다 코드를 입력하는 피로가 쌓이면 직원들은 보안 정책을 우회하는 방법을 찾기 시작한다.
같은 문제가 Push 알림 기반 MFA에서는 더 직접적인 형태로 나타난다. MFA Fatigue 공격이다. 공격자가 탈취한 비밀번호로 반복해서 로그인을 시도하면 사용자에게 승인 Push 알림이 계속 날아온다. 새벽에 잠을 깨우는 알림을 받거나 평소에도 알림이 많은 환경에 익숙해진 직원은 결국 습관적으로 "승인"을 누른다. 2022년 Uber 침해 사고가 이 방식으로 이루어졌다. 공격자는 직원에게 WhatsApp으로 직접 연락해 "IT팀인데 MFA 알림이 계속 오는 건 시스템 문제입니다, 한 번만 승인해주세요"라고 설득했다.
다른 하나는 충분하지 않은 방어다. 서울에서 TOTP를 정상적으로 통과한 세션이 두 시간 뒤 런던에서 사용되고 있어도 정적 MFA는 이것을 감지하지 못한다. 해외에서 처음 보는 기기로 새벽에 접속할 때, 짧은 시간 안에 로그인 실패가 반복된 직후 성공했을 때도 정상 로그인과 동일하게 취급한다.
리스크가 낮을 때 마찰을 줄이고, 리스크가 높을 때 방어를 강화하는 것
이것이 Adaptive MFA의 출발점이다.
리스크를 구성하는 신호들
Adaptive MFA는 로그인 요청과 세션 진행 중의 컨텍스트에서 리스크 신호를 수집한다. 신호는 크게 네 범주로 나뉜다.
- 위치 기반 신호: 로그인 IP의 지리적 위치, 이전 로그인과의 거리와 이동 속도가 핵심이다. 불가능 이동(Impossible Travel)은 가장 강한 단일 신호다. 두 로그인 사이의 거리를 경과 시간으로 나눠 속도를 계산한다. 비행기 순항 속도(약 900km/h)를 초과하면 물리적으로 불가능한 이동이다. 여기에 더해 Tor exit node, 주요 상업 VPN 서비스 IP 대역, 알려진 고위험 국가 IP 목록도 신호로 포함된다.
- 기기 기반 신호: 이전에 인증된 적 있는 기기인가, 기업 MDM에 등록된 기기인가가 기준이다. Device Posture 상태가 여기서 직접 연결된다. OS 패치 미적용, EDR 비활성화, 디스크 암호화 미설정 기기는 그 자체가 리스크 신호다. TPM 기반 기기 인증서가 있다면 하드웨어 수준에서 기기 무결성이 증명되기 때문에, 반대로 신뢰 신호(Trust Signal)로 활용된다.
- 행동 기반 신호: 사용자의 평소 로그인 시간대와의 차이, 짧은 시간 안에 반복된 로그인 실패 후 성공, 동일 계정의 여러 위치 동시 활성 세션이 여기 속한다. 행동 기반 신호는 단독으로는 낮은 가중치를 갖지만 조합하면 강해진다.
- 네트워크 기반 신호: 기업 내부망인가 외부망인가, 공용 Wi-Fi 여부, 알려진 악성 IP 범위 해당 여부다. 기업 VPN을 경유한 접속은 실제 위치를 마스킹하기 때문에 신호 해석에 예외 처리가 필요하다.
신호의 비선형 조합
신호를 단순 합산하는 방식은 문제를 만든다. "새 기기"는 혼자서는 이상 신호가 아니다. 신입 사원이 첫날 로그인하면 당연히 새 기기다. 그런데 "새 기기 + 해외 위치 + 새벽 3시 + 로그인 실패 3회 후 성공"은 완전히 다른 맥락이다.
아래는 신호별 가중치를 단순화해 표현한 예시다.
| 신호 | 가중치 | 비고 |
| 불가능 이동 | +90 | 단독으로 차단 임계값 도달 |
| 알려진 악성 IP | +50 | |
| 로그인 실패 3회 이상 후 성공 | +30 | 무차별 대입 패턴 |
| 처음 보는 기기 | +15 | 단독으로는 낮음 |
| 해외 IP (비여행 등록 기간) | +20 | |
| 업무 시간 외 접속 | +10 | |
| 기업 관리 기기 (MDM 등록) | -10 | 신뢰 신호 |
| TPM 기기 인증서 존재 | -15 | 신뢰 신호 |
여기서 중요한 것은 신호 조합에 추가 가중치를 부여하는 것이다. "처음 보는 기기(+15) + 해외 IP(+20)"가 단순 합산이면 +35지만, 이 두 신호가 동시에 발생하면 +60으로 처리하는 규칙을 추가할 수 있다. 둘 중 하나만이면 우연의 가능성이 있지만, 동시에 발생하면 정상 사용자 시나리오가 극히 드물기 때문이다.
이 비선형 조합 규칙을 수동으로 정의할 수도 있고, 과거 인시던트 데이터를 학습한 모델로 자동화할 수도 있다. 규칙 기반은 해석 가능성이 높고 감사 추적이 쉽다. 모델 기반은 사람이 발견하지 못한 패턴을 포착하지만, 왜 그 결정이 나왔는지 설명하기 어렵다.
리스크 점수와 Step-up 인증
수집된 신호와 가중치로 계산된 점수를 기반으로, 시스템은 인증 강도를 결정한다.
- 낮은 리스크 구간: 익숙한 기기, 정상 위치, 업무 시간대 로그인. 기존 세션이 유효하면 재인증 없이 진행한다. 마찰을 최소화하는 구간이다.
- 보통 리스크 구간: 처음 보는 기기이거나 위치가 평소와 다소 다르다. Step-up 인증으로 사용자 확인을 추가 요청한다. 이 구간에서는 Push 알림이나 TOTP처럼 상대적으로 가벼운 추가 인증으로 충분하다.
- 높은 리스크 구간: 여러 이상 신호가 겹친다. 이 수준에서는 AiTM 공격이 실행 중일 가능성을 고려해야 한다. TOTP는 실시간으로 가로채어 그대로 중계할 수 있기 때문에 충분하지 않다. 따라서 FIDO2나 하드웨어 키처럼 피싱 저항성이 높은 인증 방식을 요구한다. 더 강한 방식으로 다시 신원을 증명해야 세션을 계속 유지할 수 있다.
- 매우 높은 리스크 구간: 불가능 이동, 여러 계정 동시 공격 패턴, 악성 IP + 처음 보는 기기 + 로그인 실패 반복처럼 복합 이상 징후가 겹친 경우다. Step-up이 아니라 완전 차단이다. 보안 팀 알림과 함께 해당 계정의 모든 활성 세션을 강제 종료한다.
Step-up 인증은 어떻게 동작하는가
Step-up 인증은 이미 인증된 세션이 있는 상태에서 발동된다는 점에서 일반 로그인과 다르다. 사용자가 어떤 리소스를 요청하거나 세션 재평가가 트리거됐을 때, 리스크 엔진이 현재 상황을 평가하고 임계값을 초과하면 세션을 일시 정지한다.
여기서 중요한 점은 "Step-up 인증 완료 후 세션의 유효 기간을 어떻게 처리할 것인가."이다. 강화된 인증으로 갱신된 세션을 기존 세션과 동일하게 오래 유지할지, 아니면 짧은 유효기간을 부여해 고위험 리소스 접근 후 자동으로 재평가를 강제할지다. 고민감도 환경에서는 특권 리소스 접근 시 Step-up 완료 후에도 재평가를 트리거하는 방식을 사용할 수도 있다.
리스크 엔진의 위치
리스크 점수 산출은 어디서 일어나는가. 세 가지 배치 방식이 있다.
IdP 내장 방식: Okta, Azure AD, Google Workspace 같은 IdP가 자체 리스크 엔진을 내장한다. 구현이 단순하고 IdP가 보유한 사용자 히스토리 데이터를 바로 활용할 수 있다. 단점은 유연성이 제한된다 — IdP가 지원하는 신호와 임계값 설정 범위 안에서만 동작한다.
독립 리스크 서비스: 별도 리스크 평가 서비스가 IdP와 연동한다. 더 많은 신호 소스를 통합하고, 점수 계산 로직을 조직에 맞게 커스터마이즈할 수 있다. Vol.11에서 다룰 Policy Engine과 직접 연동해 인증 단계뿐 아니라 매 리소스 접근 시점에도 리스크 점수를 반영하는 구조로 발전한다.
SIEM 연동: SIEM이 축적된 이벤트 로그 기반 이상 패턴을 실시간 신호 기반 리스크 엔진에 피드백한다. 단일 로그인 이벤트 수준에서 잡히지 않는 장기 패턴(예를 들어 특정 계정이 지난 2주간 매일 새벽 4시에 짧게 접속했다는 이상 패턴 )을 리스크 점수에 반영할 수 있다.
예외 처리 설계
리스크 기반 인증은 정상 사용자도 높은 리스크로 오분류할 수 있다. 예외 처리 없이는 운영이 불가능하다.
출장: 해외 출장 중이면 "불가능 이동"이 아니라 "예정된 이동"이다. 출장 신청 시스템과 연동해 여행 기간 동안 위치 기반 리스크를 낮추거나, 출장 전 출장지에서 사용할 기기를 사전 등록하는 방식이 있다.
기업 VPN: VPN을 통한 접속은 실제 위치를 마스킹한다. VPN IP 대역을 신뢰 네트워크로 등록하는 것이 일반적이지만, VPN 자체가 침해된 경우를 대비해 기기 신호와 병행 확인하는 것이 안전하다. "VPN을 통과했으니 안전하다"는 가정은 Castle-and-Moat 사고방식의 잔재다.
신입 사원 온보딩: 새 기기, 새 위치(사무실), 처음 보는 접속 패턴이 동시에 발생한다. 온보딩 기간에는 관리자 동행 등록 프로세스를 거치거나, 별도로 낮은 리스크 구간을 적용하는 정책이 필요하다.
예외 처리의 핵심 원칙은 예외를 구체적이고 기간 제한적으로 만드는 것이다. "이 사용자는 항상 위치 리스크 면제" 같은 영구 예외는 리스크 기반 인증을 사실상 정적 인증으로 퇴행시킨다. 예외에는 이유, 요청자, 승인자, 유효 기간이 명시되어야 하고 주기적으로 재검토해야 한다. 예외 목록이 길어질수록 이 시스템은 조용히 무력화된다.
연속 세션 평가
Adaptive MFA는 로그인 시점의 단발 평가가 아니다. 인증에 성공한 뒤에도 세션이 진행되는 동안 컨텍스트는 계속 바뀔 수 있다. 이 글의 첫 시나리오가 보여준 것처럼 로그인 시점의 인증이 완벽해도, 그 이후 접속 패턴이 달라지면 위협이 된다.
세션 재평가는 두 가지 방식으로 트리거된다.
시간 기반: 일정 주기마다 자동으로 리스크를 재평가한다. 예를 들어, 일반 업무용 애플리케이션은 1시간 마다, 고민감도 리소스(DB, 운영 서버 등)는 30분마다 재평가한다. 인증 강도가 높을수록 세션 유효 시간을 짧게 가져간다.
이벤트 기반: 컨텍스트가 명시적으로 바뀌는 시점에 즉각 트리거한다. 위치 변경 감지, Device Posture 상태 변화, 민감한 리소스 접근 시도, 대용량 데이터 다운로드 감지 등이 트리거 이벤트다.
세션 중 리스크가 상승하는 대표 시나리오:
- 세션 탈취: 로그인 후 다른 국가에서 같은 세션 토큰이 사용됨. 이 글의 프롤로그 시나리오가 바로 이 경우다. 연속 세션 평가가 있었다면 런던 접속 시점에 Impossible Travel을 감지하고 세션을 종료했을 것이다.
- 기기 상태 변화: Device Posture가 non-compliant로 전환됨. EDR이 비활성화됐거나 OS 취약점이 새로 발견된 경우. 로그인 당시에는 정상이었지만 세션 중에 상태가 바뀐다.
- 동시 다중 접속: 동일 계정이 다른 위치에서 동시에 활성화됨. 계정 공유이거나 침해 신호다.
"인증에 성공했다"는 사실은 그 순간의 판단이다. 세션이 이어지는 동안 상황이 바뀌면 그 판단은 더 이상 유효하지 않다. 연속 세션 평가는 Zero Trust의 "Never trust, always verify" 원칙을 로그인 이후까지 연장하는 메커니즘이다.
도입 전 체크포인트
신호 수집 범위 결정
모든 신호를 수집하고 싶지만 데이터 수집에는 프라이버시 규제와 비용이 따른다. GDPR, 국내 개인정보보호법 맥락에서 위치 정보 수집과 행동 프로파일링은 법적 검토가 필요하다. 위치·기기·시간 신호는 비교적 수집이 쉽고 효과적이다. 행동 생체인식(타이핑 패턴, 마우스 이동 패턴)까지 포함하면 정확도는 높아지지만 구현 비용과 법적 민감도가 모두 높아진다.
임계값 설정 전략
초기에는 임계값을 높게 잡아 명백한 이상 징후만 차단하고, 데이터가 쌓이면서 점진적으로 기준을 조이는 것이 현실적이다. false positive가 많으면 직원들이 Step-up 알림에 피로를 느껴 무조건 승인하는 패턴이 생긴다. 앞에서 다룬 MFA Fatigue와 동일한 상황이 된다. false negative가 많으면 실제 위협을 놓친다. 두 오류의 비용을 조직의 위험 허용 범위에 맞게 조정해야 한다.
Detection-only 모드로 시작
Adaptive MFA를 처음 도입할 때는 실제 차단 없이 감지 전용 모드(detection-only mode)로 운영하는 것이 안전하다. 리스크 점수를 계산하고 로그만 쌓는다. 어떤 패턴이 false positive를 만드는지, 어떤 예외 처리가 필요한지 데이터를 보고 판단한 뒤 차단을 활성화한다. 준비 없이 차단 모드로 시작하면 임원 계정 잠금처럼 예상치 못한 운영 사고가 생긴다.
사용자 경험 설계
갑자기 "추가 인증이 필요합니다" 화면이 뜨면 직원들이 당황하거나 피싱으로 의심한다. Step-up 인증 요청 화면에 "이 로그인이 평소와 다른 위치에서 시도됐습니다" 같은 맥락 정보를 함께 표시하면 마찰을 줄이고 직원의 자가 확인을 유도할 수 있다. Step-up 인증에 맥락을 담는 것은 보안과 편의성이 함께 좋아지는 드문 경우다. 맥락 없는 보안 요구가 오히려 사용자를 혼란에 빠트리고, 피싱 메시지와 구분하기 어렵게 만들수 있다.
참고 자료
- Microsoft — Identity Protection risk detections
https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks - NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
https://pages.nist.gov/800-63-3/sp800-63b.html - Krebs, Brian — *"Uber Investigating Breach of Its Computer Systems"*, Krebs on Security, 2022
https://krebsonsecurity.com/2022/09/uber-investigating-computer-systems-breach/ - CISA — More Than a Password: Multi-Factor Authentication Guide
https://www.cisa.gov/mfa