역할 기반 접근 제어

역할 기반 접근 제어 (RBAC)는 사용자의 역할에 따라 권한을 부여하는 방법입니다. 다음과 같은 시나리오에서 RBAC를 고려해 보세요:

다양한 접근 필요가 있는 여러 사용자가 있는 경우: RBAC는 관리자, 편집자, 뷰어와 같은 역할에 따라 사용자가 다양한 권한을 필요로 할 때 이상적입니다.
권한 관리를 단순화해야 하는 경우: 개별적으로 권한을 설정하는 대신 역할을 할당하여 대규모 사용자 그룹을 관리하는 데 효율적입니다.
앱이 다양한 부서나 팀에 서비스를 제공하는 경우: 서로 다른 그룹이 리소스에 대한 다양한 수준의 접근을 필요로 하는 시나리오에서 유용합니다.

역할 기반 접근 제어가 작동하는 방식 이해하기

권한은 API 리소스에 접근할 수 있는 인가를 의미합니다. 실제 세계에서는 주문, 제품, 문서와 같은 엔티티가 리소스로 지정될 수 있으며, 다양한 작업이 할당될 수 있습니다.

주문을 편집하고, 문서를 읽고, 제품을 삭제할 수 있는 권한의 예는 다음과 같습니다:

위 그림은 리소스 https://api-1.store.io의 권한 read:item이 리소스 https://api-2.store.io의 권한 read:item과 다름을 보여줍니다.

API 리소스가 제공되지 않으면, 권한은 "OIDC 용"으로 처리됩니다. 이는 일반적으로 RBAC에서 원하는 것이 아닙니다.

Logto에서 API 권한 구성에 대해 알아보세요.

역할은 사용자에게 할당할 수 있는 권한의 그룹입니다. 또한, 서로 다른 API에 대해 정의된 권한을 집계하는 방법을 제공하여, 사용자에게 개별적으로 권한을 할당하는 것보다 권한을 추가, 제거 또는 조정하는 것이 더 효율적입니다.

다음은 두 개의 리소스에 대한 여러 권한을 가진 order_admin 역할의 예입니다:

역할 간에 권한이 중복되어도 괜찮습니다.

Logto에서 역할 구성에 대해 알아보세요.

온라인 서점을 관리한다고 가정해 봅시다. 여기서는 시연 목적으로 접근 제어 모델을 크게 단순화합니다.

모델은 주문과 제품이라는 두 개의 주요 API 리소스로 나뉩니다. 이들은 아래와 같은 리소스 지표를 가지고 있습니다:

각 리소스에 대해 읽기, 쓰기, 삭제로 권한을 분리하고 싶습니다. 그래서 총 여섯 개의 권한을 정의합니다:

https://api.store.io/orders
- 권한 read:order
- 권한 write:order
- 권한 delete:order
https://api.store.io/products
- 권한 read:product
- 권한 write:product
- 권한 delete:product

다음은 이 모델의 설명입니다:

두 가지 유형의 관리자를 두고 싶습니다: 주문 관리자와 제품 관리자:

그래서 두 가지 역할, order_admin과 product_admin을 만들고, 다음과 같은 권한을 부여합니다:

order_admin
- https://api.store.io/orders
  - read:order, write:order, delete:order
- https://api.store.io/products
  - read:product
product_admin
- https://api.store.io/products
  - read:product, write:product, delete:product

다음은 이 두 역할의 설명입니다:

사용자에게 order_admin과 product_admin을 모두 할당해도 괜찮습니다. 그러면 사용자는 방금 정의한 여섯 개의 모든 권한을 갖게 됩니다.

주문 관리자는 제품 관리자와 read:product 권한을 공유하며, 사용자가 보유한 최종 권한은 할당된 역할에서 모든 권한의 합집합입니다.

CIAM 102: 인가 (Authorization) & 역할 기반 접근 제어 (RBAC)