Authorization RBAC ABAC Permission
3줄 요약
- Authorization은 인증된 principal이 특정 resource에 특정 action을 해도 되는지 결정하는 절차다.
- RBAC는 role과 permission 묶음으로 권한을 관리하고, ABAC는 owner, 조직, 상태, 시간, MFA, 위험도 같은 속성을 함께 본다.
- 권한 설계는 UI 버튼 숨김이 아니라 서버의 정책 결정, DB 조건, method security, 감사 로그, 실패 테스트로 증명해야 한다.
핵심 정리
- 인증 성공은 “누구인지 확인됨”이고, 인가 성공은 “이 요청의 action을 허용함”이다. 둘은 같은 말이 아니다.
- IDOR는 URL이나 body의 ID를 바꿨을 때 서버가 principal과 resource 관계를 확인하지 않아 생기는 대표 권한 취약점이다.
- Role은 사용자나 직무에 가까운 묶음이고, Permission은 실제 허용 action에 가깝다. role 이름만 늘어나면 정책이 불투명해진다.
- ABAC는
actor, resource, action, context 속성으로 결정한다. 예를 들어 같은 관리자라도 업무 티켓, 조직, MFA 상태, 시간에 따라 허용 여부가 달라질 수 있다.
- URL 권한은 진입 경계이고 method security는 업무 행위 경계다. Service가 여러 진입점에서 호출되면 method security의 가치가 커진다.
- 권한 감사 로그는 거부 이벤트와 변경 이벤트를 나누어 남긴다. 누가, 누구에게, 어떤 권한을, 왜, 언제까지 부여했는지가 복원되어야 한다.
하위 문서 연결
-
- Authentication과 Authorization 분리: 로그인 성공과 resource action 허용을 분리하고 401/403/404 선택 기준을 다룬다.
-
- RBAC Role Permission: role-permission catalog, 최소 권한, role 변경 정책, 권한 폭발을 다룬다.
-
- ABAC와 Resource Ownership: owner, tenant, 상태, 위험도 같은 속성 기반 정책과 IDOR 방어를 다룬다.
-
- Method Security와 API 권한 검사: URL rule을 넘어 Service method 경계에 권한 검사를 배치하는 기준을 다룬다.
-
- 권한 감사 로그와 우회 위험: 권한 변경, break-glass, 고객센터 대리 조회, stale permission cache의 감사 지점을 다룬다.
헷갈리는 지점
- 로그인했으니 자기 데이터만 볼 것이라고 생각하기 쉽다. UI가 자기 데이터 링크만 보여 주기 때문이다.
- 핵심은 공격자가 URL과 body의 ID를 직접 바꿀 수 있다는 점이다.
- 서버는 매 요청마다 principal과 resource 관계를 확인해야 한다.
ADMIN role이 있으면 충분하다고 보기 쉽다. role 이름이 권한을 설명하는 것처럼 보이기 때문이다.
- 핵심은 role이 실제 permission 묶음으로 설명되고 감사될 수 있어야 한다는 점이다.
- 관리자도 billing, user support, security, owner action을 분리하는 편이 안전하다.
- ABAC가 있으면 모든 권한 문제가 자동으로 풀린다고 생각하기 쉽다.
- 핵심은 속성 출처와 정책 테스트가 없으면 ABAC도 디버깅하기 어려운 조건문 묶음이 된다는 점이다.
- client가 보낸 속성을 그대로 쓰면 ABAC가 아니라 공격자 입력을 믿는 것이다.
- 감사 로그를 access log로 대체하기 쉽다.
- 핵심은 감사 로그가 정책 결정의 이유와 변경 근거를 남겨야 한다는 점이다.
- URL, status code, IP만으로는 “왜 허용 또는 거부됐는가”를 복원하기 어렵다.
확인 질문
- 인증과 인가의 차이는 무엇인가?
- 인증은 신원 확인이고, 인가는 특정 resource와 action에 대한 허용 판단이다.
- RBAC와 ABAC는 어떻게 다른가?
- RBAC는 role과 permission 묶음을 기준으로 하고, ABAC는 actor, resource, action, context 속성을 함께 사용한다.
- IDOR 방어의 핵심은 무엇인가?
- ID를 숨기는 것이 아니라 서버가 principal과 resource ownership 또는 tenant 관계를 검증하는 것이다.
- 권한 감사 로그가 남겨야 할 최소 정보는 무엇인가?
- actor, subject, resource, action, result, reason, previous/new permission, approval, trace id다.