## 배경 [이전 기사](/ciam-101-intro-authn-sso/)에서는 신원인증 (AuthN)과 권한부여 (AuthZ), 그리고 신원, 조직, 테넌트 등 일부 머리아픈 용어들의 개념을 소개했습니다. 조직과 테넌트는 신원을 그룹화 하는데 유용하지만, 이는 절대민주주의를 초래합니다: 이 시스템에서 모두가 모든 것을 할 수 있습니다. 유토피아는 아직 미스터리이므로, 접근의 거버넌스를 살펴봅시다: 권한 부여 (AuthZ). ### 왜 권한 부여가 필요한가요? 권한 부여 (AuthZ)는 "당신은 무엇을 할 수 있나요?"라는 질문에 대답합니다. Notion은 좋은 예입니다. 각자 소유한 페이지에 대해 개인용으로 두거나, 친구와 공유하거나, 또는 일반 대중에게 공개하도록 선택할 수 있습니다. 또는, 온라인 서점에서는 모든 사람들이 모든 책을 볼 수 있도록 하고, 고객들은 자신의 주문만 볼 수 있도록 하고, 판매자들은 자신의 상점에서의 책만 관리할 수 있도록 하고 싶을 것입니다. AuthZ와 AuthN은 복잡한 비즈니스 모델의 필수 구성 요소입니다. 둘은 종종 함께 가며, AuthZ는 사용자의 접근을 검증하고, AuthN는 신원을 인증합니다. 둘 다 안전한 시스템에 필수적입니다. ## 기본 권한 부여 모델 가장 일반적인 AuthZ 모델 중 하나는 다음과 같습니다: **IDENTITY**가 **RESOURCE**에서 **ACTION**을 수행하면, **ACCEPT** 또는 **DENY**. Notion 예제에서, 모델은 **PERSON**이 **PAGE**에서 **VIEW**를 수행합니다. 페이지가 비공개인 경우: - 당신의 **PAGE**에서 **VIEW**를 수행하면 **ACCEPT**를 받게 됩니다. - 다른 모든 사람들은 당신의 **PAGE**에서 **VIEW**를 수행하면 **DENY**를 받아야 합니다. 합의에 기반하여, 업계는 역할 기반 접근 제어 (RBAC), 속성 기반 접근 제어 (ABAC) 등 다양한 권한 부여 기술을 개발했습니다. 오늘날, 우리는 [NIST RBAC 모델](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Level 1: Flat RBAC에 중점을 둘 것입니다. ## 역할 기반 접근 제어 NIST RBAC 모델은 다양한 시나리오에 대한 유연성과 적응성을 제공하기 위해 여러 가지를 열어두었습니다. Logto는 현재 Level 1 정의를 "Resource"라는 추가 개념 (즉 API Resource)과 함께 채택하고 있습니다. 서점 예제를 확장해 보겠습니다. 많은 고객들이 있지만 판매자는 한 명뿐이라고 가정해 봅시다: - 고객들은 책을 보고 주문할 수 있으며, 자신의 주문을 볼 수 있습니다. - 판매자는 책을 보고, 생성하고, 삭제할 수 있으며, 고객의 주문을 관리할 수 있습니다. ### 리소스 정의 Logto에서, 리소스 (즉 API 리소스)는 일반적으로 일련의 엔티티 또는 항목을 나타냅니다, 왜냐하면 지시자로 유효한 URL을 사용해야하기 때문입니다. 따라서 우리는 두 가지 리소스를 정의합니다: - 책: `https://api.bookstore.io/books` - 주문: `https://api.bookstore.io/orders` URL 형식을 강제하는 이점 중 하나는 이것이 당신의 API 서비스의 실제 주소에 매핑될 수 있게 하므로, 시스템의 다른 구성 요소와 통합할 때 읽기 쉽고 인식하기 쉬워집니다. 🤔 리소스는 비즈니스의 필요에 따라 나눠져야 합니다. 완전한 방법은 없으며, 결정은 사례별로 내려져야 합니다. 이 기사에서의 책과 주문을 나누는 예는 마이크로서비스에는 적합할 수 있지만, 단일 아키텍처에는 적합하지 않을 수 있습니다. ### 권한 정의 리소스의 개념을 소개했기 때문에, Logto에서는 권한이 반드시 리소스에 속해야 하며, 역으로, 리소스는 권한을 가질 수 있도록 강제합니다. 리소스에 몇 가지 권한을 추가해 보겠습니다: - 책: `read`, `create`, `delete` - 주문: `read`, `read:self`, `create:self`, `delete` 권한의 이름에 대한 요구사항은 없지만, 우리는 아래와 같은 규칙을 가지고 있습니다: ``` [:] ``` ``은 권한을 설명하기 위해 필요하며, `:`은 일반적인 대상, 즉 리소스의 모든 엔티티 또는 항목을 설명하기 위해 생략될 수 있습니다. 예를 들면: - 리소스 책에 있는 권한 `read`는 임의의 책을 읽는 행위를 의미합니다. - 리소스 주문에 있는 권한 `create:self`는 현재 사용자 소유의 주문을 생성하는 행위를 의미합니다. ### 역할 정의 간단히 말해서, 역할은 권한의 그룹입니다. `customer`와 `seller`라는 두 개의 역할을 만들고 아래와 같이 그들에게 권한을 할당합시다: ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` 당신은 권한-역할 할당이 다대다 관계임을 알아차렸을 것입니다. ### 사용자에게 역할 할당 역할-권한 할당과 마찬가지로, 사용자-역할 할당도 다대다 관계입니다. 따라서, 당신은 단일 사용자에게 여러 역할을 할당할 수 있고, 단일 역할을 여러 사용자에게 할당할 수 있습니다. ### 도트 연결 여기 Logto의 Level 1 RBAC 모델에 대한 완전한 관계도가 있습니다: ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` RBAC 모델에서, 권한은 항상 "긍정적"입니다, 즉 권한 부여 판단은 간단합니다: 사용자가 권한이 있다면, 수락; 그렇지 않다면, 거절. 앨리스가 `seller` 역할을 가지고 있고, 밥과 캐롤이 `customer` 역할을 가지고 있다고 가정해 봅시다. 우리는 먼저 자연어로 행동을 설명하고, 그것들을 표준 권한 부여 형식인 **IDENTITY**이 **RESOURCE**에서 **ACTION**을 수행함으로 변환하고, 결론을 내리겠습니다. - 앨리스는 판매를 위해 새 책을 추가하고 싶어합니다: - 사용자 앨리스는 리소스 책 (`https://api.bookstore.io/books`)에서 `create`를 수행합니다. - 앨리스는 그들의 역할 `seller`에 따라 책의 권한 `create`가 할당되어 있으므로, 결과는 ✅ **ACCEPT**입니다. - 앨리스는 모든 주문을 보고 판매가 그들의 기대에 부합하는지 확인하고 싶어합니다: - 사용자 앨리스는 리소스 주문 (`https://api.bookstore.io/orders`)에서 `read`를 수행합니다. - 앨리스는 그들의 역할 `seller`에 따라 주문의 권한 `read`가 할당되어 있으므로, 결과는 ✅ **ACCEPT**입니다. - 밥은 책 목록을 둘러보고 구매하고 싶은 책이 있는지 확인하고 싶어합니다. - 사용자 밥은 리소스 책 (`https://api.bookstore.io/books`)에서 `read`를 수행합니다. - 밥은 그들의 역할 `customer`에 따라 책의 권한 `read`가 할당되어 있으므로, 결과는 ✅ **ACCEPT**입니다. - 밥은 캐롤의 주문을 보고 싶어합니다. - 이것은 누군가 다른 사람의 주문이므로, `Orders`의 `read:self` 권한은 여기서 작동하지 않습니다. - 사용자 밥은 리소스 주문 (`https://api.bookstore.io/order`)에서 `read`를 수행합니다. - 밥은 주문의 권한 `read`가 없으므로, 결과는 ❌ **DENY**입니다. ### 기타 RBAC 레벨 NIST RBAC 모델에는 네 개의 레벨이 있습니다: - Flat RBAC - Hierarchical RBAC - Constrained RBAC - Symmetric RBAC 관심이 있으시다면 [논문](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)을 참조하십시오. Logto는 현재 Level 1 구현을 가지고 있고, 커뮤니티 피드백에 기반하여 더 높은 레벨로 진행할 것입니다. 더 높은 레벨이 귀하의 필요에 부합한다면 망설이지 않고 알려주십시오! ## 실제 사례 이론 외에도, 우리는 모델이 예상대로 작동하도록 완성하기 위해 아직 무거운 기술 작업을 마무리 해야합니다: - 클라이언트 및 인증 서버 개발 - RBAC를 위한 데이터베이스 설계 - 다른 서비스 간의 검증 - 보안 및 개방형 표준 준수 - 역할, 권한, 리소스 관리 및 할당 당황하지 마십시오. 우리는 이것을 고려해 두고, 그 위에 모든 것을 테마로 지원하였습니다. [🔐 RBAC 레시피](https://docs.logto.io/docs/recipes/rbac/)를 확인하여 Logto에서 RBAC를 어떻게 사용하는지 알아보십시오. ## 마무리 메모 RBAC는 대부분의 경우에 대한 강력한 접근 관리 모델이지만, 만능제는 없습니다. 우리는 아직 일부 질문들이 있습니다: - 더 높은 레벨의 RBAC가 필요한가요? - RBAC는 다른 권한 부여 모델과 어떻게 비교되나요? - 다른 조직들 사이에 권한 부여 모델을 어떻게 정의합니까? 🔥 계속 지켜봐 주세요. CIAM 103에서 만나뵙겠습니다!