Network (15) 썸네일형 리스트형 [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에 전파되.. [Zero Trust - IAM] IAM과 IGA: Privilege Creep이 생기는 이유와 접근 권한 거버넌스 설계 신입 개발자 David가 입사했다. 온보딩 과정에서 필요하다는 이유로 운영 데이터베이스 읽기 권한, 배포 파이프라인 접근 권한, 내부 대시보드 편집 권한을 받았다. 3개월 후 팀이 바뀌었다. 6개월 후 그가 담당하던 프로젝트가 종료됐다. 1년 후 David는 퇴사했다.1년이 지난 시점에서 IAM 시스템에 물어보면 David의 계정은 여전히 활성 상태고 세 개의 시스템 모두 접근 가능하다고 답한다.아무도 권한을 회수하지 않았기 때문이다. 이것이 Privilege Creep — 시간이 지나면서 필요 없어진 권한이 조용히 쌓이는 현상이다.IAM 시스템에 이 문제를 물어보면 답하지 못한다. IAM은 "지금 이 순간 David가 접근 가능한가?"를 판단하도록 설계됐지, "이 권한이 아직도 적절한가?"를 검증하도록.. [Zero Trust - IAM] Google Zanzibar: 2조 개의 권한을 일관성 있게 10ms에 처리하는 설계 Alice가 공유 폴더에서 Bob을 제거했다. 그 직후 Alice는 Charlie에게 새 문서를 폴더로 옮겨달라고 요청했다. 새 문서의 권한은 폴더 권한을 상속한다. 이제 Bob이 그 문서를 열었다. Bob은 볼 수 있는가? "취소가 먼저였으니 안 된다"고 말하기 쉽다. 하지만 분산 시스템에서 "먼저"는 보장되지 않는다. 권한 변경이 아직 전파되지 않은 레플리카에서 체크가 실행되면, Bob은 이미 제거됐음에도 접근할 수 있다. Zanzibar 논문은 이것을 New Enemy Problem이라고 부른다. 이 문제가 단일 서버라면 해결하기 어렵지 않다. 문제는 Google의 규모다. Calendar, Drive, Maps, Photos, YouTube에 걸쳐 2조 개(2 trillion) 이상의 ACL 레코.. [Zero Trust - IAM] RBAC의 구조적 한계와 ABAC·ReBAC의 설계 차이 Alice는 마케팅팀 소속 직원이다. 오늘 새벽 3시, 브라질 IP에서 접속했다. 지난주에 피싱 메일을 클릭한 이력이 있다. 이 사람에게 고객 데이터 CSV 다운로드를 허용해야 하는가? 대부분의 시스템은 이 질문에 대답하지 못한다. "Alice는 마케팅팀 역할을 갖고 있고, 마케팅팀은 고객 데이터에 접근할 수 있다"는 사실만 알 뿐이다. 새벽 3시라는 사실도, 브라질 IP라는 사실도, 피싱 클릭 이력도 접근 결정에 개입하지 않는다. 이것이 Role-Based Access Control(RBAC)의 한계이고, 이 한계를 메우려는 시도가 ABAC, ReBAC로 이어진 흐름이다. 각 모델은 "접근을 어떻게 결정할 것인가"라는 질문에 서로 다른 방식으로 대답한다.RBAC — 역할이라는 단순한 약속RBAC가 등장.. [Zero Trust] VPN을 믿으면 안 되는 이유 — Zero Trust 보안 아키텍처 2020년 3월, VPN 문제는 용량이 아니었다2020년 3월 11일, WHO가 팬데믹을 선언했다. 그 다음 주, 전 세계 수천 개의 기업이 동시에 재택근무로 전환했다. VPN 트래픽은 하룻밤 사이에 폭증했고, 많은 기업의 접속 인프라가 응답을 멈췄다. IT 팀은 VPN 집선 장비를 긴급 증설하고 라이선스를 늘리고 대역폭을 확장했다. 그리고 시스템은 다시 돌아갔다. 그런데 그해 말, 보안 사고가 쏟아졌다. VPN 취약점을 통한 침투, 탈취된 VPN 계정을 이용한 내부망 장악, 재택 엔드포인트에서 시작된 랜섬웨어 확산. Pulse Secure, Fortinet, Citrix 당시 주요 VPN 벤더들의 취약점 목록은 길었다. 용량 문제는 해결됐지만 VPN이 전제하는 신뢰 모델 자체가 현대의 위협 환경과 맞.. 이전 1 2 다음