본문 바로가기

분류 전체보기

 (59)
[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이 전제하는 신뢰 모델 자체가 현대의 위협 환경과 맞..
[Nginx] Nginx 이벤트 루프와 epoll 기반 I/O 다중화 NGINX 한 대가 초당 수만 건의 요청을 처리하면서도 메모리를 수백 MB 이상 잡아먹지 않는다. 스레드 기반 서버라면 스택만으로 수 GB가 사라지는 상황에서도 NGINX는 그러지 않는다. 이것이 가능한 이유는 하나다. I/O를 기다리지 않기 때문이다. Apache가 연결마다 스레드를 할당하는 구조적 한계를 드러내던 자리에서, NGINX는 OS 커널의 이벤트 알림 메커니즘을 활용해 단 몇 개의 프로세스로 수만 개의 연결을 동시에 관리한다. 이 글에서는 그 원리를 이벤트 루프(Event Loop)와 I/O 다중화(epoll/kqueue)를 중심으로 OS 레벨까지 파헤쳐본다.문제의 시작 - C10K2000년대 초, 웹 트래픽이 폭발적으로 증가하면서 하나의 서버로 동시 접속자 1만 명(10,000 Connec..
[데이터베이스] 데이터베이스 복구 메커니즘 — Redo, Undo, Checkpoint 트랜잭션을 커밋했다. 그런데 그 직후 서버가 죽었다. 데이터는 살아있는가?이 질문에 "그렇다"고 답할 수 있으려면 데이터베이스가 내부적으로 어떤 메커니즘을 갖추고 있는지 이해해야 한다. ACID의 D, Durability(지속성)는 그냥 선언이 아니다. Redo Log, Undo Log, Checkpoint라는 구체적인 구현이 그것을 보장한다.ACID와 복구의 관계ACID에서 Undo, Redo와 직접 연결된 속성은 세 가지다. Atomicity(원자성):트랜잭션은 전부 반영되거나 전혀 반영되지 않아야 한다. 중간 상태로 남으면 안 된다. 트랜잭션 도중 실패했을 때 지금까지의 변경을 모두 되돌려야 하는데, 이것이 Undo Log의 첫 번째 역할이다.Isolation(고립성):트랜잭션이 진행 중인 동안 다..
[MySQL] 트랜잭션 격리가 구현되는 원리 — InnoDB MVCC 데이터베이스를 다루는 개발자라면 트랜잭션 격리 수준을 한 번쯤 공부한다. REPEATABLE READ에서는 Phantom Read가 발생할 수 있고, READ COMMITTED에서는 Non-repeatable Read가 발생한다. 이 정도는 많이 알고 있지만 "왜 그런가"를 설명할 수 있는 사람은 훨씬 적다. 격리 수준은 단순한 설정 플래그가 아니다. 그 아래에는 InnoDB가 데이터를 버전 단위로 관리하는 정교한 메커니즘이 있다. 이것이 MVCC(Multi-Version Concurrency Control)다. MVCC를 이해하면 격리 수준의 동작이 "그냥 그렇게 되는 것"이 아니라 필연적인 결과임을 알게 된다. 그리고 READ COMMITTED와 REPEATABLE READ를 언제 선택해야 하는지, ..
[MySQL] MySQL Primary-Replica: 내부 동작 원리부터 운영까지 이번 글에서는 복제가 내부적으로 어떻게 동작하는지에 대해 네트워크 프로토콜 수준부터 스레드 아키텍처, GTID 복구 메커니즘, 장애 시나리오별 동작, 그리고 실제 운영에서 놓치기 쉬운 함정들까지 깊게 다룬다.Replica 복제는 어떤 방식으로 어떻게 전송되는가1. MySQL 복제는 TCP 위의 이벤트 스트리밍많은 사람들이 복제를 "주기적으로 변경 내역을 가져오는 것"으로 막연하게 이해한다.실제로는 TCP 위에서 동작하는 MySQL 고유의 Binary Protocol로 이벤트를 스트리밍하는 구조다.OSI 계층 관점:Layer 7 (Application) → MySQL Binary Protocol (COM_BINLOG_DUMP_GTID)Layer 6 (Presentation) → 선택적 압축 (zstd /..

티스토리툴바