본문 바로가기

전체 글

 (55)
[Zero Trust - Continuous Verification] SIEM 아키텍처: 이벤트의 바다에서 위협 패턴을 찾는 방법 보안 팀이 사후 분석 보고서를 작성하고 있다. 공격자가 처음 침투한 것은 6개월 전이었다. 초기 침투는 스피어 피싱 이메일을 통한 인증 정보 탈취였고, 그 계정으로 VPN에 처음 접속한 시각은 새벽 2시 14분이었다. 이후 공격자는 3개월 동안 내부를 조용히 탐색했다. LDAP 쿼리로 서비스 계정 목록을 수집했고, 관리자 권한이 있는 계정들을 차례로 장악했다. 5개월 차부터는 소량의 데이터를 외부로 반출하기 시작했다. 분석가가 로그를 열어보자 모든 흔적이 있었다. 비정상적인 시간대의 VPN 접속, 평소와 다른 서브넷 스캔, LDAP 열거 패턴, 외부 IP로의 비정기 HTTPS 연결. 개별 이벤트로 보면 하나하나는 이상해 보이지 않았다. 조합해보면 누군가 시스템 안에서 움직이고 있었다는 것이 분명했다. 단..
[PostgreSQL] 프로세스 아키텍처 & 공유 메모리 PostgreSQL은 프로세스인가많은 현대 데이터베이스는 멀티스레드 모델을 채택한다. MySQL의 InnoDB, MongoDB, SQL Server 모두 하나의 프로세스 안에서 여러 스레드가 클라이언트 요청을 처리한다. 그런데 PostgreSQL은 정반대다. 클라이언트가 접속할 때마다 OS 수준의 새로운 프로세스가 fork()되어 그 연결을 전담한다. 이 설계는 1986년 UC Berkeley에서 시작된 POSTGRES 프로젝트의 유산이다. 당시는 POSIX 스레드 표준이 정립되기 전이었고, UNIX 계열 시스템 간에 스레드 API가 통일되어 있지 않았다. 가장 이식성 높은 동시성 단위는 fork() 한 번으로 복제되는 프로세스뿐이었다. 하지만 30년이 지난 지금까지 PostgreSQL이 프로세스 모델을..
[Zero Trust - Policy Engine] Connector와 Gateway: 정책 결정이 실제 트래픽으로 집행되는 방법 보안 감사 중에 이런 질문이 나올 때가 있다."VPN 없이 내부 개발 서버에 접근한다면, 그 연결은 어떻게 만들어지나요? 내부 서버의 포트가 외부에 열려 있는 건가요?" 이 질문이 불편하게 느껴지는 데는 이유가 있다. VPN을 걷어냈다고 선언했다면, 그 자리를 대체하는 것이 무엇인지를 구체적으로 설명할 수 있어야 한다. "Zero Trust를 도입했습니다"라는 말만으로는 충분하지 않다. Vol.11에서 PDP(Policy Decision Point)가 접근 요청에 허용/거부를 결정한다고 설명했다. 앞선 포스팅에서는 OPA와 Cedar가 그 결정을 어떤 언어로 표현하는지를 다뤘다. 그런데 OPA가 allow = true를 반환했다고 해서 사용자의 노트북과 내부 앱 서버 사이에 연결이 저절로 생기지는 않는다..
[Zero Trust - Policy Engine] OPA와 Cedar: 두 정책 언어가 같은 문제를 다르게 정의한 이유 외부 감사가 시작됐다. 감사팀은 간단한 질문을 던졌다."현재 프로덕션 데이터베이스에 접근 가능한 사람 전체 목록을 주세요." 담당 엔지니어는 그 질문에 즉시 답할 수 없었다. 프로덕션 DB 접근 권한은 세 가지 경로로 나뉘어 있었다.첫째는 사용자 서비스의 JWT 클레임에서 db_admin 역할을 확인하는 로직둘째는 내부 배포 도구가 LDAP 그룹 멤버십을 직접 조회하는 방식셋째는 데이터 분석 플랫폼이 자체 권한 테이블을 관리하는 구조세 군데를 각각 쿼리하고, 중복을 걸러내고, 이미 퇴사한 계정이 혹시 남아있지는 않은지 수동으로 확인하는 데 이틀이 걸렸다.문제는 감사팀이 다음 질문을 이어서 던진다는 것이다."이 중에서 지난 90일간 실제로 접근한 사람은 몇 명이고, 접근 권한이 있지만 한 번도 쓰지 않은 ..
[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초 유효 기간의 숫자 코드다. 두 값 모두 공격자 서버를 경유해도 원..

티스토리툴바