Elena는 중견 금융사의 보안 엔지니어다. 회사에 Adaptive MFA를 도입하고 석 달이 지났다. 결과는 기대와 달랐다.
해외 영업팀 세 명이 매주 헬프데스크를 찾아왔다. 도쿄, 싱가포르, 런던에서 로그인할 때마다 Step-up 인증에 걸렸다. 그들에게 해외 출장은 일상이었다. 리스크 엔진에게 그것은 "평균 사용자가 로그인하는 곳이 아닌 위치"였다.
그로부터 두 달 뒤 보안 사고가 발생했다. 인턴 계정이 침해됐다. 공격자는 그 인턴의 패턴을 그대로 따랐다. 월요일부터 금요일, 오전 10시에 사무실 건물 IP에서 로그인했다. 하루에 한두 개 파일씩 조금씩 접근했다. 리스크 점수는 항상 낮은 구간에 머물렀다. 침해는 7주 동안 감지되지 않았다.
두 실패는 같은 원인에서 비롯됐다. 리스크 기준이 개인이 아닌 집단에 맞춰져 있었다.
Adaptive MFA의 미완성 — 집단 평균의 함정
Adaptive MFA(적응형 다중 요소 인증)는 위치·기기·시간·네트워크 신호를 조합해 리스크를 평가하고 인증 강도를 결정한다. 그런데 그 평가의 기준점은 어디에서 오는가.
"해외 위치"가 +20점인 것은 전체 사용자 집단에서 해외 로그인이 드물기 때문이다. 해외 출장이 잦은 영업 직원에게도 같은 +20점이 적용된다면, 이 신호는 그 사람에게 의미가 없다. 더 나쁜 것은, 이 직원의 계정이 실제로 침해됐을 때 국내에서 로그인하는 공격자가 오히려 낮은 점수를 받는다는 것이다.
"업무 시간 외 접속"이 +10점인 것도 마찬가지다. 야근이 잦은 개발자, 원격 근무자, 다른 시간대의 팀과 협업하는 직원에게 자정 접속은 이상이 아니라 평상시다. 집단 평균이 개인의 "정상"을 덮어쓰면, 리스크 평가는 두 방향으로 동시에 실패한다. 정상 사용자를 차단해 운영 부담을 만들고, 피해자의 행동을 흉내 내는 공격자를 정상으로 분류한다.
Risk-based AuthN(리스크 기반 인증, Risk-based Authentication)이 해결하려는 것은 바로 이 지점이다. 신호의 기준점을 집단에서 개인으로 이동시키는 것. 같은 "도쿄 IP"라도 이 사람에게 정상인가 이상인가를 판단하는 구조를 설계하는 것이다.
개인화된 기준선: 무엇을 측정해야 하는가
개인화된 리스크 평가의 출발점은 "이 사람에게 이것이 정상인가"를 판단할 수 있어야 한다는 요건이다. 이를 위해서는 개인별 행동 기준선(behavioral baseline)이 필요하다.
로그인 타이밍 분포: 단순히 "업무 시간인가"가 아니라, 이 사람의 실제 로그인 시간대 분포를 모델링한다. 오전 8시–10시에 집중 로그인하고 가끔 저녁에도 접속하는 패턴이라면, 새벽 2시 로그인은 집단 기준으로도, 개인 기준으로도 이상이다. 반면 야근 패턴이 정착된 개발자의 자정 로그인은 집단 기준으로는 이상이지만 개인 기준으로는 정상이다.
지리적 패턴: 주요 로그인 위치를 단순 목록이 아닌 이동 패턴으로 학습한다. 서울에서 정기적으로 로그인하고, 분기마다 도쿄와 런던에서 로그인한다면, 도쿄 로그인은 이상이 아니다. 반대로 한 번도 해외에서 접속한 적 없는 사람의 갑작스러운 해외 로그인은 개인 기준에서 강한 이상 신호다.
리소스 접근 패턴: 어떤 시스템에, 어느 규모로, 얼마나 자주 접근하는가. 특정 개발자가 매일 코드 리포지토리와 CI 서버에 접근하지만 HR 시스템에는 거의 접근하지 않는다면, 갑자기 HR 시스템 대량 조회가 발생했을 때 이것은 강한 이상 신호다. HR 담당자의 동일한 행동은 정상이다.
피어 그룹 비교: 같은 역할·팀·직급의 다른 사람들과 비교한다. 새 직원이거나 역할이 바뀐 직후와 같이 개인 이력이 부족할 때 피어 그룹의 기준선이 초기 판단 기준을 제공한다. 어떤 개발자의 행동이 팀 내 다른 개발자들과 뚜렷하게 달라지는 것도 신호가 된다.
이 네 차원의 데이터를 수집하고 기준선으로 변환하는 것이 UEBA(User and Entity Behavior Analytics, 사용자 및 엔터티 행동 분석)의 역할이다. UEBA는 이후 포스팅에서 상세히 다루지만, Risk-based AuthN이 UEBA 없이 개인화된 리스크 평가를 구현하는 것은 사실상 불가능하다. Trust Score 엔진은 UEBA가 만든 기준선 위에서 동작한다.
Trust Score 아키텍처
Trust Score(신뢰 점수)는 현재 접근 요청의 신뢰도를 나타내는 수치다. 높을수록 신뢰할 수 있고, 낮을수록 의심스럽다. 이 점수를 어떻게 계산하느냐의 아키텍처가 시스템의 실제 탐지 효과를 결정한다. 단순히 신호들을 합산하는 것으로 끝나지 않는다.
신호 정규화
다양한 소스에서 수집된 신호들은 측정 단위와 의미가 제각각이다. Trust Score 계산에 투입하기 전에 같은 기준으로 변환(정규화)해야 한다.
위치 신호를 예로 들면, "IP 주소" 자체는 위치 좌표가 아니다. 이것을 지리 위치 정보(geolocation)로 변환하고, 이전 로그인 위치와의 거리를 계산하고, 이동 속도를 산출하는 과정이 필요하다. 그런데 IP 기반 위치 파악의 정확도는 인터넷 서비스 제공자(ISP)와 지역에 따라 크게 다르다. 도시 수준으로 정확한 경우가 있고, 국가 수준 정도만 파악되는 경우도 있다. 정확도가 낮은 데이터를 높은 신뢰도로 처리하면 오탐(false positive)이 늘어난다. 신호 정규화 단계에서 신호값과 함께 신뢰도 가중치를 계산해야 한다.
기기 신호도 마찬가지다. MDM에 등록된 기기 여부, TPM 인증서 존재 여부, EDR 활성화 상태는 각각 다른 강도의 신뢰 신호다. "MDM 등록"과 "TPM 인증서"는 신뢰도가 다르다. TPM 인증서는 하드웨어 수준에서 기기 무결성을 증명하기 때문이다. 이 차이를 점수에 반영해야 한다.
점수 산출 방식: 가중합과 이상 감지 모델
Trust Score 계산에는 두 가지 접근이 실무에서 혼용된다.
가중합(weighted sum): 각 신호에 사전 정의된 가중치를 부여하고 합산한다. 해석 가능성이 높고 감사 추적이 쉽다. "이 로그인의 Trust Score가 45인 이유는 기준 점수(100)에서 기기 미등록(-30점), 업무 시간 외 접속(-10점), 해외 위치(-15점)가 차감됐기 때문"이라고 명확히 설명할 수 있다. 단점은 신호들이 서로 조합됐을 때 생기는 증폭 효과를 표현하기 어렵다는 것이다. "처음 보는 기기 + 해외 IP + 새벽 3시"는 각각의 점수를 단순히 더한 것보다 훨씬 강한 이상 신호인데, 명시적 예외 규칙 없이는 이것을 포착하지 못한다.
이상 감지 모델(anomaly detection): 개인의 과거 행동 분포에서 현재 이벤트가 얼마나 벗어났는지를 통계적으로 계산한다. "이 사람의 평소 로그인 위치들과 비교할 때, 현재 위치는 통계적으로 4.5 표준편차만큼 떨어져 있다(z-score 4.5)"는 식이다. 개인별 기준선을 자동으로 반영하고, 사람이 미리 예측하지 못한 패턴을 감지할 수 있다. 단점은 충분한 이력 데이터가 없으면 기준선이 불안정한 콜드 스타트 문제다 또한 왜 그 점수가 나왔는지 설명하기 어렵다. 감사 추적이 필요한 환경에서는 이것이 규제 준수 문제로 이어질 수 있다.
실제 시스템은 두 방식을 레이어로 쌓는다. 기본 Trust Score는 가중합으로 계산하되, UEBA 기반 이상 감지 모델이 생성한 이상 점수(anomaly score)를 입력 신호 중 하나로 포함한다. 명시적인 규칙 기반 신호들은 가중합에 기여하고, "이 사람의 기준선 대비 이탈 정도"는 별도 신호로 처리되어 동일하게 가중합에 기여하는 방식이다.
감쇠 함수: 최근 이벤트가 더 중요한 이유
과거 이벤트가 현재 Trust Score에 미치는 영향은 시간이 지날수록 줄어들어야 한다. 3일 전 로그인 실패는 30초 전 로그인 실패보다 현재 상황과 관련성이 낮다. 이것을 감쇠 함수(decay function)로 표현한다.
가장 일반적인 형태는 지수 감쇠다. 시간이 지날수록 영향력이 기하급수적으로 줄어드는 방식이다. 영향력이 절반으로 줄어드는 시간인 반감기(half-life)를 짧게 설정할수록 최근 이벤트에 민감하게 반응하고, 길게 설정할수록 장기 패턴을 더 반영한다. 고민감도 리소스 접근 시에는 반감기를 짧게(수 시간), 배경 신뢰 점수 계산에는 길게(수 주) 설정하는 것이 일반적이다.
감쇠 함수는 공격자에 대해서도 의미가 있다. 공격자가 며칠에 걸쳐 조금씩 악의적 활동을 하면, 개별 이벤트는 이상 신호 임계값을 넘지 않는다. 하지만 "최근 N시간"이라는 고정된 시간 구간을 기준으로 이상 점수를 누적 합산하면, "평소보다 조금씩 이상한 이벤트들의 밀도"를 단기 구간에서 포착할 수 있다. 이것이 SIEM(보안 정보·이벤트 관리)이 장기 패턴 분석을 담당하고 Trust Score 엔진에 피드백하는 이유다.
콜드 스타트 문제
새 직원은 행동 이력이 없다. UEBA 기반 기준선이 안정화되려면 보통 2–4주의 관찰 기간이 필요하다. 이 기간을 어떻게 처리하느냐가 콜드 스타트 문제다.
피어 그룹 기준선 대체: 신규 직원이 개발팀 소속이라면, 개발팀 전체의 행동 기준선을 임시로 사용한다. 개인 이력이 쌓이면서 점진적으로 개인 기준선으로 전환한다.
탐지 기준 완화: 기준선이 불안정한 기간에는 이상으로 분류하는 임계값을 높게 잡아 오탐을 줄인다. 이력이 부족한 사용자에게는 더 뚜렷한 이탈이 있어야 이상으로 분류한다. 반대로 말하면, 이 기간에는 탐지 민감도가 낮아진다. 트레이드오프다. 사내 온보딩 프로세스와 연계해서 새 직원의 첫 로그인이 관리자 동행 아래 이루어지도록 하면 이 취약 기간을 보완할 수 있다.
이력 비교가 Trust Score를 결정하는 방식
같은 이벤트가 사람에 따라 다른 Trust Score를 받는다. 이것을 구체적으로 보자.
| 이벤트 | 사람 A (해외 영업) | 사람 B (내근 개발) |
| 도쿄 IP에서 오전 9시 로그인 | 기준선 내 (이상 없음) | 기준선 대비 강한 이탈 |
| 자정에 사무실 IP에서 로그인 | 기준선 대비 이탈 | 기준선 내 (야근 패턴) |
| 처음 보는 기기에서 접속 | 전월 기기 교체 이력 있음 → 낮은 이상 | 2년간 같은 기기 사용 → 높은 이상 |
| HR 시스템 100건 일괄 조회 | 역할 무관 → 강한 이상 | 역할 무관 → 강한 이상 |
사람 A와 B가 동시에 도쿄에서 로그인했다고 가정하자. 집단 기준 리스크 엔진은 둘에게 같은 점수를 부여한다. 개인화된 Trust Score 엔진은 사람 A에게는 이상 없음, 사람 B에게는 강한 이상을 부여한다. 이 차이가 실제 탐지 효과를 결정한다.
개인화의 부작용도 존재한다. 공격자가 타깃의 행동 패턴을 오랫동안 관찰하고 그대로 흉내 낼 수 있다. 앞에서 소개한 인턴 계정 침해 시나리오가 이 경우다. 이 취약점은 두 가지로 대응한다.
- 첫째, 피어 그룹 이탈도를 병행 신호로 사용한다.
공격자가 타깃이 평소 접근하는 파일들만 조금씩 접근해 개인 기준선을 회피하더라도, 그 접근 빈도나 리소스 조합이 같은 역할의 다른 직원들과 비교해 이탈하면 피어 그룹 비교에서 이상이 잡힌다. 개인 기준선과 피어 그룹 기준선은 서로 다른 각도에서 이상을 탐지하기 때문에, 한쪽을 우회해도 다른 쪽에 걸릴 가능성이 높아진다. - 둘째, 리소스 접근 볼륨 이상 감지는 개인 기준선으로도 강하다.
공격자의 목적이 데이터 탈취라면 접근 볼륨이 늘어날 수밖에 없다. 개인 기준선 대비 볼륨 이상은 타이밍·위치 흉내와 무관하게 작동한다.
Policy Engine과의 연결
Trust Score는 독립적으로 접근을 허가하거나 거부하지 않는다. Policy Engine의 PDP(Policy Decision Point, 정책 결정 지점)에 투입되는 상황 속성(context attribute) 중 하나다. 이후 포스팅에서 PDP/PEP/PAP/PIP 아키텍처를 상세히 다루겠지만, 여기서는 Trust Score가 PDP에 어떻게 연결되는지를 먼저 본다.
XACML(eXtensible Access Control Markup Language) 아키텍처에서 PIP(Policy Information Point, 정책 정보 지점)는 정책 결정에 필요한 속성을 수집해 PDP에 제공한다. Trust Score 엔진은 PIP의 역할을 한다. 접근 요청이 들어올 때, PDP는 PIP에 현재 사용자의 Trust Score를 질의하고, 그 값을 정책 조건 평가에 사용한다.
정책 표현의 예시를 보면 Trust Score의 역할이 명확해진다.
# 저민감도 리소스: Trust Score 50 이상이면 허용
permit if:
identity.authenticated == true
AND device.compliant == true
AND trust_score >= 50
# 고민감도 리소스: 75 이상이면 허용, 50–75이면 FIDO2 Step-up 후 허용
permit if:
identity.authenticated == true
AND device.compliant == true
AND trust_score >= 75
AND resource.sensitivity == "high"
permit with obligation(step_up: "fido2") if:
identity.authenticated == true
AND device.compliant == true
AND trust_score >= 50 AND trust_score < 75
AND resource.sensitivity == "high"
deny if:
trust_score < 50
이 구조에서 Trust Score는 이진(허용/거부)이 아닌 연속적인 값으로, 접근 결정을 더 정밀하게 만든다. 같은 리소스라도 현재 신뢰 상태에 따라 허용·조건부 허용·거부로 달라진다. Trust Score가 낮다고 무조건 차단하는 것이 아니라, Step-up 인증을 통해 사용자가 신뢰도를 직접 높일 수 있는 경로를 제공한다.
서비스 계정: 일관성이 신뢰의 근거인 행위자
사람 계정과 서비스 계정은 완전히 다른 기준선을 필요로 한다. 서비스 계정은 자동화 파이프라인, 지속적 통합/배포(CI/CD), 마이크로서비스 간 통신처럼 사람의 개입 없이 동작하는 비인간 행위자를 포함한다.
서비스 계정의 "정상" 패턴은 완벽한 일관성이다. 같은 IP, 같은 시간, 같은 리소스에 같은 빈도로 접근한다. 이것은 강점이면서 동시에 취약점이다.
강점: 완벽한 일관성은 조금의 이탈도 강한 이상 신호가 된다. 사람 계정에서 동일한 크기의 이탈이 주의 수준이라면, 서비스 계정의 같은 이탈은 즉각 조사 대상이다. 탐지 정확도가 사람 계정보다 높다.
취약점: 서비스 계정은 Step-up 인증을 처리할 수 없다. 자격증명이 침해됐는데 공격자가 기존 패턴을 완벽하게 재현한다면, 리스크 기반 탐지는 효과가 없다. 서비스 계정의 보안은 자격증명 자체의 강도와 네트워크 수준 제어(이 계정은 특정 IP 대역에서만 유효)로 보완해야 한다.
서비스 계정에 대한 Trust Score는 다음 두 입력을 혼합한다.
- 패턴 일치율: 현재 접근이 학습된 패턴과 얼마나 일치하는가. 접근 시간·소스 IP·대상 리소스·요청 빈도의 편차를 계산한다. 서비스 계정은 기준선이 좁고 안정적이기 때문에, 작은 편차도 강한 신호가 된다.
- Workload Identity 검증: Cloud IAM의 Workload Identity, SPIFFE(Secure Production Identity Framework For Everyone)/SPIRE 같은 서비스 간 신원 체계가 발급한 단기 인증서를 Trust Score의 직접 신뢰 신호로 활용한다. 인증서가 유효하고 발급 주체가 검증되면 높은 신뢰 점수의 기반이 된다.
세션 내 지속 평가
로그인 시점의 Trust Score는 그 순간만 평가한다. 세션이 이어지는 동안 상황은 계속 바뀐다. 연속 세션 평가는 Zero Trust의 "절대 신뢰하지 말고, 항상 검증하라(Never trust, always verify)" 원칙을 로그인 이후까지 연장하는 메커니즘이다.
재평가를 일으키는 조건은 두 가지다.
- 시간 기반 재평가: 세션 유지 중 일정 주기로 자동 재평가한다. 이 주기는 리소스의 민감도에 따라 다르게 설정한다. 일반 업무용 SaaS는 1 ~ 4시간, 코드 리포지토리는 1시간, 프로덕션 서버·DB 접근은 15 ~ 30분이 일반적이다.
- 이벤트 기반 재평가: 접속 상황의 변화가 감지되는 즉시 발동된다. 위치 변화(Impossible Travel 포함), Device Posture 변화(EDR 비활성화, 취약점 발견), 대용량 데이터 접근 감지, 고위험 작업 시도(프로덕션 배포, 대규모 삭제, 권한 설정 변경)가 이에 해당한다.
재평가 빈도 설계에서 중요한 트레이드오프가 있다. 너무 자주 재평가하면 Trust Score 엔진이 매번 신호를 수집하고 점수를 계산하는 비용이 누적된다. 수천 개 동시 세션이 있는 환경에서 이것은 인프라 비용 문제가 된다. 너무 드물게 재평가하면 세션 탈취나 기기 침해에 대한 반응 속도가 느려진다. 일반적인 절충은 고민감도 리소스 접근 시에만 즉시 재평가를 강제하고, 일반 세션은 이벤트 기반 재평가 방식을 기본으로 사용하는 것이다.
재평가 결과로 Trust Score가 임계값 이하로 떨어졌을 때의 처리도 설계해야 한다. Step-up 인증을 요청할지, 세션을 즉시 종료할지, 아니면 접근 범위를 축소한 상태로 세션을 유지할지. "접근 범위 축소" 방식은 사용자 경험의 단절이 가장 적다. Trust Score가 낮아지면 고민감도 리소스 접근만 차단하고 일반 리소스는 허용하는 방식이다.
Trust Score 시스템 단계별 도입
Trust Score 시스템을 도입할 때 가장 많이 실패하는 지점은 초기 임계값 설정이다. 이 임계값은 실제 데이터 없이는 올바르게 설정하기 어렵다. 조직마다 업무 패턴, 팀 구성, 지리적 분포가 다르기 때문에 다른 조직의 임계값을 그대로 가져와도 안 된다.
1단계 — Detection-only 모드: 처음에는 실제 차단 없이 로깅만 한다. Trust Score를 계산하고 어떤 이벤트가 임계값 미달인지 기록하지만, 실제 Step-up 인증이나 차단은 발동하지 않는다. 2–4주 데이터를 보면서 어떤 계층의 사용자가 오탐을 많이 만드는지, 어떤 신호 조합이 실제 위협과 무관한 이상 점수를 만드는지, 예외 처리가 필요한 패턴은 무엇인지를 파악한다. 이 단계를 건너뛰면 임원 계정 잠금, 영업팀 전원 Step-up 불가 같은 예측 불가 사고가 발생한다.
2단계 — Step-up 활성화: Detection-only에서 수집한 데이터를 바탕으로, 명백히 이상한 패턴 (Impossible Travel, 알려진 악성 IP)에 대해서만 Step-up 인증을 활성화한다. 이 단계에서 오탐 비율을 직접 측정한다. Step-up 인증에서 "이게 나였다"라고 통과하는 비율 대비 실제 이상 접근을 차단하는 비율을 추적한다.
3단계 — 임계값 조정: 오탐(false positive) 비율이 허용 가능한 수준으로 낮아지면, 접근 허용 최소 Trust Score 임계값을 점진적으로 높인다. "허용 수준"은 조직마다 다르다. 금융·의료처럼 미탐(false negative) 비용이 높은 환경은 오탐을 더 감수한다. 일반 기업은 반대 방향으로 조정한다.
4단계 — 차단 활성화: 마지막으로 높은 리스크 구간에서만 완전 차단을 활성화한다. 이 단계도 점진적으로 진행한다. 먼저 보안팀이나 자원자 그룹에게 적용하고, 이상이 없으면 전사로 확대한다.
임계값 설정은 한 번으로 끝나지 않는다. 조직의 업무 패턴이 바뀌고, 공격 기법이 진화하고, 새로운 신호 소스가 추가됨에 따라 재보정이 필요하다. 분기 단위로 오탐·미탐 비율을 리뷰하는 프로세스를 정착시켜야 한다.
또 하나의 실패 패턴이 있다. 재인증 요구가 너무 잦으면 사용자가 습관적으로 승인하게 된다. 앞에서 다룬 MFA Fatigue와 동일한 문제가 Step-up 인증에서도 재현된다. "맥락 없는 보안 요구"는 사용자를 혼란에 빠트리고 피싱 메시지와 구분하기 어렵게 만든다. Step-up 인증 요청 화면에 "이 로그인이 평소와 다른 위치에서 시도됐습니다" 같은 맥락 정보를 함께 표시하면 마찰을 줄이면서 사용자의 자가 확인을 유도할 수 있다.
참고 자료
- NIST SP 800-207 — Zero Trust Architecture, 2020
https://doi.org/10.6028/NIST.SP.800-207 - NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management, 2017
https://pages.nist.gov/800-63-3/sp800-63b.html - CISA — Zero Trust Maturity Model, v2.0, 2023
https://www.cisa.gov/zero-trust-maturity-model - Gilman, Evan & Barth, Doug — Zero Trust Networks: Building Secure Systems in Untrusted Networks, O'Reilly Media, 2017
- OASIS — eXtensible Access Control Markup Language (XACML) Version 3.0, 2013
https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html - SPIFFE Project — Secure Production Identity Framework For Everyone
https://spiffe.io/docs/latest/spiffe-about/overview/ - Kindervag, John — *"No More Chewy Centers: The Zero Trust Model of Information Security"*, Forrester Research, 2010