본문 바로가기

ReBAC

(2)
[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가 등장..