본문 바로가기

전체 글

 (59)
[Zero Trust - Policy Engine] PDP · PEP · PAP · PIP: 접근 결정의 분리 새벽 2시, 보안팀의 슬랙 채널에 경보가 울렸다. 시니어 엔지니어 계정의 자격증명이 피싱 공격으로 탈취됐다는 신고가 들어왔다. 해당 계정은 프로덕션 DB, 내부 API, CI/CD 파이프라인, 로그 시스템에 접근 권한이 있었다. 대응팀이 해야 할 일은 단순했다. 해당 계정의 접근을 지금 당장 막는 것. 하지만 생각만큼 단순하지 않았다. 그 회사의 접근 제어 로직은 각 서비스에 분산되어 있었다. API 서버는 JWT 클레임을 파싱해서 if claims["role"] == "engineer" 조건을 검사했다. 내부 대시보드는 LDAP 그룹 멤버십을 직접 조회했다. CI/CD 시스템은 자체 권한 테이블을 가지고 있었다. 로그 집계 서비스는 IP 기반 allowlist를 쓰고 있었다. 공통 정책 레이어 같은 것..
[Zero Trust - Authentication] Risk-based AuthN 설계: 개인화된 신뢰 점수는 어떻게 접근 결정을 바꾸는가 Elena는 중견 금융사의 보안 엔지니어다. 회사에 Adaptive MFA를 도입하고 석 달이 지났다. 결과는 기대와 달랐다. 해외 영업팀 세 명이 매주 헬프데스크를 찾아왔다. 도쿄, 싱가포르, 런던에서 로그인할 때마다 Step-up 인증에 걸렸다. 그들에게 해외 출장은 일상이었다. 리스크 엔진에게 그것은 "평균 사용자가 로그인하는 곳이 아닌 위치"였다. 그로부터 두 달 뒤 보안 사고가 발생했다. 인턴 계정이 침해됐다. 공격자는 그 인턴의 패턴을 그대로 따랐다. 월요일부터 금요일, 오전 10시에 사무실 건물 IP에서 로그인했다. 하루에 한두 개 파일씩 조금씩 접근했다. 리스크 점수는 항상 낮은 구간에 머물렀다. 침해는 7주 동안 감지되지 않았다. 두 실패는 같은 원인에서 비롯됐다. 리스크 기준이 개인이 ..
[Zero Trust - Authentication] Adaptive MFA: 리스크 신호로 인증 강도를 결정하는 구조 직원이 피싱 이메일 링크를 클릭했다. 정상 로그인 페이지처럼 생긴 사이트였다. 비밀번호와 TOTP를 입력하자 로그인이 됐다. 인증이 성공하는 순간, 프록시는 서버가 발급한 세션 쿠키를 가로챘다. 세션 쿠키는 "이미 인증된 사용자임을 증명하는 토큰"이다. 이것을 가진 사람은 비밀번호나 TOTP 없이도 해당 서비스에 접속할 수 있다. 이 시간이 오전 9시, 서울이었다. 오전 11시, 같은 계정이 런던에서 접속됐다. 공격자가 탈취한 세션 쿠키를 HTTP 요청에 그대로 심어 보낸 것이다. 서버는 "유효한 세션"이라고만 봤다. 아무 이상을 감지하지 못했다. 두 시간 안에 서울에서 런던으로 이동하는 것은 물리적으로 불가능하다. 그런데 그 판단을 할 수 있는 시스템이 없었다. 정적(Static) MFA는 로그인 시점..
[Zero Trust - Authentication] FIDO2와 Passkey: 피싱이 원천 차단되는 구조 Sarah는 피싱 이메일 링크를 클릭했다. 구글 로그인 페이지처럼 보이는 사이트가 열렸다.도메인이 evil-google-security-alert.com이라는 것을 미처 확인하지 못한 채 서둘러 비밀번호를 입력하고 TOTP 6자리 코드도 넣었다. 그 순간 공격자는 중간 서버에서 그 값을 받아 실제 구글에 그대로 입력했다. 인증이 통과됐다. 비밀번호와 MFA를 모두 갖췄어도 AiTM(Adversary-in-the-Middle) 피싱 앞에선 아무 소용이 없었다. 이 공격이 성립하는 이유는 구조적이다. Sarah가 입력한 값들이 어디서든 재사용 가능하다는 것이다. 비밀번호는 서버에 저장된 해시와 대조하기 위해 전송되는 값이고, TOTP는 30초 유효 기간의 숫자 코드다. 두 값 모두 공격자 서버를 경유해도 원..
[Zero Trust - Device] Hardware Trust: 소프트웨어로 소프트웨어를 증명할 수 없는 이유 이 전 포스트에서 Device Posture를 다뤘다. 에이전트가 OS 버전, EDR 상태, 암호화 여부를 보고하고, 그 신호들이 접근 결정에 반영된다. 그런데 에이전트가 정직하게 보고한다는 한 가지 전제가 있다. 에이전트는 소프트웨어다. 소프트웨어는 교체될 수 있다. OS가 루팅되면 에이전트를 가로채거나 교체하는 것이 가능하다. 더 심각한 경우는 OS보다 아래, 부트로더나 펌웨어 레이어에 악성코드가 자리 잡는 것이다. 이 상태에서 OS는 정상으로 보이고, 에이전트도 정상으로 실행되며, "모든 것이 정상"이라는 보고가 계속 나간다. 이것이 루트킷의 본질이다. 탐지 시스템이 의존하는 레이어보다 아래에서 실행되기 때문에 탐지되지 않는다. 소프트웨어 레이어 안에서 순환 논리가 생긴다. 에이전트의 신뢰를 소프트..
[Zero Trust - Device] Device Posture: 신원은 사람을 증명하지만 기기는 증명하지 않는다 계약직 디자이너 Jake가 프로젝트에 합류했다. 접근 권한이 설정됐고, MFA도 활성화돼 있다. 그는 매일 개인 맥북으로 접속해 작업한다. 그의 신원 확인은 매번 통과한다. 그런데 IT 팀은 이 맥북의 존재를 모른다. MDM에 등록되지 않았고, EDR도 없다. macOS 업데이트는 8개월 전에 멈췄다. 개인 앱 수십 개가 설치돼 있는데, 그 중 하나의 공급업체가 지난달 공급망 공격을 당했다는 사실이 공개됐다. Jake는 모른다. 공격자가 이미 Jake의 맥북에 들어와 있다고 가정하자. 이 시점에서 공격자의 선택지는 두 가지다. 하나는 키 로거로 Jake의 자격증명을 수집한 뒤 다른 기기에서 직접 로그인하는 것. 다른 하나는 Jake의 기기에서 세션 토큰을 탈취해 Jake가 이미 인증된 세션을 가로채는 것..
[Zero Trust - IAM] PAM과 JIT Access: 자격증명이 수명을 가지면 무엇이 달라지는가 시니어 엔지니어가 새벽 3시에 호출을 받았다. 프로덕션 DB 쿼리가 느려지고 있다. 그는 DB 관리자 계정으로 접속해 슬로우 쿼리를 찾아내고 인덱스를 수정한 뒤 잠든다. 작업 시간은 15분이다. 그런데 이 관리자 계정은 그 15분 외에도 항상 살아있다. 24시간, 365일. 그가 자는 동안에도, 휴가 중에도, 퇴사 후 아무도 비밀번호를 바꾸지 않은 6개월 동안에도. 자격증명이 어딘가에서 유출되면 공격자는 DB 전체에 대한 관리자 권한을 즉시 획득한다. 탐지되기 전까지 공격자는 그 엔지니어와 동일한 접근 권한을 갖는다. 이것이 Standing Privilege(상시 권한)의 구조적 문제다. 권한이 실제로 쓰이는 순간은 전체 시간의 극히 일부지만, 자격증명은 항상 켜져 있다. 이 전 포스팅에서 다룬 IGA는..
[Zero Trust - IAM] SCIM 2.0: Zero Trust가 신뢰하는 Identity 데이터는 어떻게 만들어지는가 보안 감사가 끝난 뒤 보고서에서 이런 항목이 나왔다. 8개월 전에 퇴사한 시니어 엔지니어의 Salesforce 관리자 계정이 여전히 활성 상태였다. 그 계정으로 고객 데이터 전체를 export할 수 있는 권한이 붙어 있었다. 실제로 사용된 흔적은 없었지만, "사용된 흔적이 없다"는 것과 "사용되지 않았다"는 것은 다른 말이다. 어떻게 이런 일이 생겼는가. HR에서 퇴사 처리는 했다. IdP(Identity Provider, 사내 계정 원부를 관리하고 다른 서비스에 인증을 제공하는 시스템 — Okta, Azure AD, Google Workspace 같은 것들) 계정도 비활성화했다. 그런데 Salesforce는 자체 사용자 디렉토리를 별도로 관리하는 앱이었고, IdP 비활성화가 Salesforce에 전파되..

티스토리툴바