CIAM 102 : 권한 부여 및 역할 기반 액세스 제어

배경#

이전 기사에서는 신원인증 (AuthN)과 권한부여 (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 모델 Level 1: Flat RBAC에 중점을 둘 것입니다.

역할 기반 접근 제어#

서점 예제를 확장해 보겠습니다. 많은 고객들이 있지만 판매자는 한 명뿐이라고 가정해 봅시다:

• 고객들은 책을 보고 주문할 수 있으며, 자신의 주문을 볼 수 있습니다.
• 판매자는 책을 보고, 생성하고, 삭제할 수 있으며, 고객의 주문을 관리할 수 있습니다.

리소스 정의#

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

권한의 이름에 대한 요구사항은 없지만, 우리는 아래와 같은 규칙을 가지고 있습니다:

<action>은 권한을 설명하기 위해 필요하며, :<target>은 일반적인 대상, 즉 리소스의 모든 엔티티 또는 항목을 설명하기 위해 생략될 수 있습니다. 예를 들면:

• 리소스 책에 있는 권한 read는 임의의 책을 읽는 행위를 의미합니다.
• 리소스 주문에 있는 권한 create:self는 현재 사용자 소유의 주문을 생성하는 행위를 의미합니다.

역할 정의#

간단히 말해서, 역할은 권한의 그룹입니다. customer와 seller라는 두 개의 역할을 만들고 아래와 같이 그들에게 권한을 할당합시다:

당신은 권한-역할 할당이 다대다 관계임을 알아차렸을 것입니다.

사용자에게 역할 할당#

역할-권한 할당과 마찬가지로, 사용자-역할 할당도 다대다 관계입니다. 따라서, 당신은 단일 사용자에게 여러 역할을 할당할 수 있고, 단일 역할을 여러 사용자에게 할당할 수 있습니다.

도트 연결#

여기 Logto의 Level 1 RBAC 모델에 대한 완전한 관계도가 있습니다:

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

관심이 있으시다면 논문을 참조하십시오.

Logto는 현재 Level 1 구현을 가지고 있고, 커뮤니티 피드백에 기반하여 더 높은 레벨로 진행할 것입니다. 더 높은 레벨이 귀하의 필요에 부합한다면 망설이지 않고 알려주십시오!

실제 사례#

이론 외에도, 우리는 모델이 예상대로 작동하도록 완성하기 위해 아직 무거운 기술 작업을 마무리 해야합니다:

• 클라이언트 및 인증 서버 개발
• RBAC를 위한 데이터베이스 설계
• 다른 서비스 간의 검증
• 보안 및 개방형 표준 준수
• 역할, 권한, 리소스 관리 및 할당

당황하지 마십시오. 우리는 이것을 고려해 두고, 그 위에 모든 것을 테마로 지원하였습니다. 🔐 RBAC 레시피를 확인하여 Logto에서 RBAC를 어떻게 사용하는지 알아보십시오.

마무리 메모#

RBAC는 대부분의 경우에 대한 강력한 접근 관리 모델이지만, 만능제는 없습니다. 우리는 아직 일부 질문들이 있습니다:

• 더 높은 레벨의 RBAC가 필요한가요?
• RBAC는 다른 권한 부여 모델과 어떻게 비교되나요?
• 다른 조직들 사이에 권한 부여 모델을 어떻게 정의합니까?