abac (2) 썸네일형 리스트형 [Zero Trust - Policy Engine] OPA와 Cedar: 두 정책 언어가 같은 문제를 다르게 정의한 이유 외부 감사가 시작됐다. 감사팀은 간단한 질문을 던졌다."현재 프로덕션 데이터베이스에 접근 가능한 사람 전체 목록을 주세요." 담당 엔지니어는 그 질문에 즉시 답할 수 없었다. 프로덕션 DB 접근 권한은 세 가지 경로로 나뉘어 있었다.첫째는 사용자 서비스의 JWT 클레임에서 db_admin 역할을 확인하는 로직둘째는 내부 배포 도구가 LDAP 그룹 멤버십을 직접 조회하는 방식셋째는 데이터 분석 플랫폼이 자체 권한 테이블을 관리하는 구조세 군데를 각각 쿼리하고, 중복을 걸러내고, 이미 퇴사한 계정이 혹시 남아있지는 않은지 수동으로 확인하는 데 이틀이 걸렸다.문제는 감사팀이 다음 질문을 이어서 던진다는 것이다."이 중에서 지난 90일간 실제로 접근한 사람은 몇 명이고, 접근 권한이 있지만 한 번도 쓰지 않은 .. [Zero Trust - IAM] RBAC의 구조적 한계와 ABAC·ReBAC의 설계 차이 Alice는 마케팅팀 소속 직원이다. 오늘 새벽 3시, 브라질 IP에서 접속했다. 지난주에 피싱 메일을 클릭한 이력이 있다. 이 사람에게 고객 데이터 CSV 다운로드를 허용해야 하는가? 대부분의 시스템은 이 질문에 대답하지 못한다. "Alice는 마케팅팀 역할을 갖고 있고, 마케팅팀은 고객 데이터에 접근할 수 있다"는 사실만 알 뿐이다. 새벽 3시라는 사실도, 브라질 IP라는 사실도, 피싱 클릭 이력도 접근 결정에 개입하지 않는다. 이것이 Role-Based Access Control(RBAC)의 한계이고, 이 한계를 메우려는 시도가 ABAC, ReBAC로 이어진 흐름이다. 각 모델은 "접근을 어떻게 결정할 것인가"라는 질문에 서로 다른 방식으로 대답한다.RBAC — 역할이라는 단순한 약속RBAC가 등장.. 이전 1 다음