10 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OWASP Authorization Cheat Sheet — Permission Model, ABAC vs RBAC, Least Privilege | official-doc | https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html |
|
|
|
2026-06-08 | 2026-06-08 |
OWASP Authorization Cheat Sheet — Permission Model, ABAC vs RBAC
Layer:
raw/official-docs/— OWASP Foundation Authorization Cheat Sheet. feature-authentication-authorization-contract 의 permission model axis (permission-centric RBAC vs role-only RBAC vs ABAC) 결정의 1차 근거. 주의: 이 파일은 기존 raw/official-docs/security-authorization-cheatsheet-owasp 와 동일 URL 이지만, 다른 섹션 (permission model, ABAC/RBAC 선택 축) 에 초점. 기존 파일은 deny-by-default / 401-403 분리에 집중.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-authentication-authorization-contract | permission-centric RBAC (role→permission mapping) 채택 결정 — ABAC 대비 trade-off, role-only RBAC 대비 least-privilege 강화 근거 |
출처 / Source
- 원본 URL: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
- 보조 URL (deprecated Access Control sheet): https://owasp.deteact.com/cheat/cheatsheets/Access_Control_Cheat_Sheet.html
- 아카이브 URL: (미수집)
- 저자 / 조직: OWASP Foundation (Cheat Sheet Series — 커뮤니티 합의)
- 발행일: rolling docs
- 마지막 확인일: 2026-06-08
왜 저장했는지 / Why archived
OWASP Authorization Cheat Sheet 는 "Prefer Attribute and Relationship Based Access Control over RBAC" 를 명시하며 ABAC/ReBAC 를 권장한다. 이는 permission-centric RBAC 채택 결정에 대한 counterclaim 이므로 반드시 record 해야 함. 동시에 "Enforce Least Privileges" 원칙과 "Permission Based Access Control" 의 permission-as-string abstraction 모델도 grounding.
핵심 인용 / Key quotes (verbatim)
[§Prefer Attribute and Relationship Based Access Control over RBAC] "Although RBAC has a long history and remains popular among software developers today, ABAC and ReBAC should typically be preferred for application development."
[§RBAC definition] "Access is granted or denied based upon the roles assigned to a user. Permissions are not directly assigned to an entity; rather, permissions are associated with a role and the entity inherits the permissions of any roles assigned to it."
[§ABAC definition] Access decisions based on "assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies" (NIST SP 800-162).
[§ABAC advantages — fine-grained] "ABAC can incorporate environmental and other dynamic attributes, such as time of day, type of device used, and geographic location."
[§ABAC advantages — robustness] "Reduces missed or improper role checks in complex systems" (paraphrase from cheatsheet advantages list)
[§ABAC advantages — speed] Addresses "role explosion" and HTTP header size limitations.
[§Enforce Least Privileges] "Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job."
[§Enforce Least Privileges] "Least Privileges must be applied both horizontally and vertically."
[§Permission Based Access Control — from deprecated Access Control Cheatsheet, archived at owasp.deteact.com] "The key concept in Permission Based Access Control is the abstraction of application actions into a set of permissions. A permission may be represented simply as a string based name, for example 'READ'. Access decisions are made by checking if the current user has the permission associated with the requested application action."
[§Permission Based Access Control — user-permission relationship] "A straightforward grant connecting user to permission" (direct) OR "Permissions granted to intermediate entities like user groups, where membership inherits those permissions" (indirect/role-mediated).
[§Permission Based Access Control — domain classes] "For systems offering granular domain-level controls, permissions may be organized into classes. Each domain object associates with a class that specifies its applicable permissions. For instance, a 'DOCUMENT' class might include 'READ,' 'WRITE,' and 'DELETE' permissions."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OWASP-PM-C1 | OWASP 는 application 개발에서 ABAC 와 ReBAC 를 RBAC 보다 일반적으로 선호해야 한다고 권장 | [§Prefer ABAC] "Although RBAC has a long history and remains popular among software developers today, ABAC and ReBAC should typically be preferred for application development." | official-reference |
access control model 선택 결정 | RBAC 가 항상 부적합하다는 것은 아님 — "should typically" 이므로 조건부 권고 |
| OWASP-PM-C2 | RBAC 에서 permission 은 entity 에 직접 할당되지 않고 role 에 연결되며, entity 는 role 을 통해 permission 을 상속 | [§RBAC definition] "Permissions are not directly assigned to an entity; rather, permissions are associated with a role and the entity inherits the permissions of any roles assigned to it." | official-reference |
role-only RBAC 의 특성 정의 | permission-centric RBAC (role→permission mapping) 에서 permission 이 별도 도메인 객체로 관리되는 것이 바람직하다는 것은 아님 |
| OWASP-PM-C3 | Permission Based Access Control 의 핵심 개념은 application action 을 permission 집합으로 추상화하는 것. permission 은 단순 string ("READ") 으로 표현 가능하며, 요청된 action 에 연결된 permission 을 현재 user 가 보유하는지 검사 | [§Permission Based Access Control] "The key concept in Permission Based Access Control is the abstraction of application actions into a set of permissions. A permission may be represented simply as a string based name, for example 'READ'. Access decisions are made by checking if the current user has the permission associated with the requested application action." | official-reference |
application action → permission string 추상화 패턴. worklog:close 형식 permission 설계 근거 |
permission 이 string 이어야 한다는 것은 아님 — 구현 세부사항. OWASP 는 추상화 패턴만 권고 |
| OWASP-PM-C4 | permission 과 user 의 관계는 (1) 직접 연결 (user → permission) 또는 (2) role/group 을 통한 간접 연결 (user → role → permission) 두 가지 | [§Permission Based Access Control] "A straightforward grant connecting user to permission (direct) OR Permissions granted to intermediate entities like user groups, where membership inherits those permissions (indirect)." | official-reference |
permission-centric RBAC 에서 role 이 permission bundle 역할을 한다는 설계의 정합성 | role 이 MUST 라는 것은 아님 — 직접 permission 할당도 허용 |
| OWASP-PM-C5 | Least Privileges 는 horizontally and vertically 모두 적용되어야 함. 같은 level 이라도 다른 직무는 다른 resource access 필요 (horizontal), 상위 level 은 비례적으로 더 많은 privilege (vertical) | [§Enforce Least Privileges] "Least Privileges must be applied both horizontally and vertically." | official-reference |
permission 설계에서 role 이 최소 필요 permission 만 포함하도록 강제하는 설계 근거 | 구체적 role-permission 매핑 규칙을 직접 정의하는 것은 아님 |
| OWASP-PM-C6 | ABAC 의 장점: 시간, 디바이스 종류, 지리적 위치 같은 동적 환경 속성 을 반영 가능 — RBAC 는 이를 직접 지원 못함 | [§ABAC advantages] "ABAC can incorporate environmental and other dynamic attributes, such as time of day, type of device used, and geographic location." | official-reference |
ABAC 가 RBAC/permission-centric RBAC 보다 표현력 우위인 시나리오 | permission-centric RBAC 가 ABAC 의 일부 기능을 대체할 수 없다는 것. 단지 동적 속성 지원 측면 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
OWASP-PM-C1: OWASP 가 일반적 application 개발에서 ABAC/ReBAC 를 RBAC 보다 선호 권장OWASP-PM-C3: permission-as-string abstraction 패턴의 OWASP 정당화OWASP-PM-C5: least-privilege 의 horizontal + vertical 적용 의무
- 이 자료가 증명하지 않는 것:
- "RBAC 가 production 에서 항상 실패한다" — 단지 ABAC 를 generally prefer
- permission-centric RBAC (role→permission bundle) 가 role-only RBAC 보다 낫다는 것 — OWASP 는 이 세분화를 직접 논하지 않음
worklog:close같은resource:action네이밍 convention — OWASP 는 naming 을 직접 권고하지 않음
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 이 프로젝트의 sample-portfolio fixture 가 "동적 환경 속성" (시간, 위치 등) 을 필요로 하지 않는다면, permission-centric RBAC 는 OWASP C1 의 "generally prefer ABAC" 에 대한 합리적 반박 근거가 있음
- role explosion 이 실제로 발생할 규모인지 (small system 에서는 RBAC 도 충분함)
메모 / Notes
- OWASP 는 "should typically be preferred" 라는 표현을 사용 — 절대적 금지가 아니라 조건부 권고
- 단순 CRUD + 소수 role 환경 (이 프로젝트: sample-portfolio fixture) 에서는 RBAC 가 ABAC 보다 구현/테스트 단순도 측면에서 실용적
- permission-centric RBAC 는 ABAC 와 role-only RBAC 의 중간점: role 은 permission bundle 로 표현되고, permission check 는 role 이 아닌 permission 으로 수행 → OWASP ABAC 권고에 근접하면서도 구현 복잡도는 낮게 유지
Related / 관련
- raw/official-docs/security-authorization-cheatsheet-owasp — 동일 URL, deny-by-default / 401-403 축
- raw/official-docs/spring-security-authorization-architecture — Spring enforcement layer
- raw/branch-notes/feature-authentication-authorization-contract