Logto에서 RBAC를 분석하는 방법: 포괄적인 실제 사례

서론#

접근 제어 및 보안은 현대 애플리케이션의 필수적인 측면이며, 사용자가 자원에 적절한 접근 권한을 가지고 있는지 확인합니다. Logto의 역할 기반 접근 제어 (RBAC)는 개발자에게 애플리케이션의 접근 제어와 보안을 관리하는 효과적인 방법을 제공합니다. 이 기사에서는 실제 예제를 사용하여 Logto의 RBAC 구현의 강력한 기능을 탐색하고, 이러한 개념을 프로젝트에 이해하고 적용하는 데 도움이 됩니다.

프론트엔드와 백엔드 코드 스니펫을 모두 검토하면, 애플리케이션 스택에 Logto의 RBAC를 통합하는 데 대한 포괄적인 시각을 얻을 수 있습니다. 이 기사를 마칠 때쯤에는 Logto의 RBAC 기능을 활용하여 프로젝트의 보안 및 접근 제어를 강화하는 데 잘 준비되어 있을 것입니다.

BookHarber 소개: 온라인 서점 사례#

Logto의 RBAC 기능을 효과적으로 보여주기 위해, 우리는 실제 예시를 사용할 것입다: BookHarber, 온라인 서점. BookHarber는 고객과 직원을 위해 광범위한 기능을 제공하며, 이는 원활하고 안전한 쇼핑 경험을 보장합니다.

BookHarber의 주요 기능은 다음과 같습니다:

1. 책 탐색 및 구매: 사용자는 다양한 장르와 작가의 동양 모음에서 쉽게 책을 검색하여 구매할 수 있습니다.
2. 주문 관리 및 물류 추적: 등록된 고객은 주문을 관리하고, 배송을 추적하고, 구매에 대한 업데이트를 받을 수 있습니다.
3. 특별한 제안 및 휴일 활동: BookHarber는 고객을 참여시키고보상하는 특별한 이벤트 및 휴일 동안 고유한 할인 및 프로모션을 제공합니다.
4. 고객 지원: 고객은 부담이나 문제를 해결하기 위해 지원 티켓을 열 수 있으며, BookHarber 직원으로부터 즉시 도움을 받을 수 있습니다.
5. 고객 관리: 다양한 역할을 가진 직원들이 플랫폼의 다양한 측면을, 예를 들어 고객 계정, 주문 처리, 문제 해결 등을 관리할 수 있는 능력을 가지고 있습니다.

역할#

BookHarber 생태계에서 우리는 다음과 같은 몇 가지 주요 사용자 역할을 식별할 수 있습니다.

1. 손님: 웹사이트를 검색하고, 책을 찾아보며, 특별한 제안을 볼 수 있는 등록되지 않은 사용자들.
2. 고객: 책을 구매하고, 주문을 관리하며, 물류를 추적하고, 지원 티켓을 열 수 있는 등록된 사용자들.
3. 상점 관리자: 전체 관리와 플랫폼 운영을 총괄하는 직원들. 전체 접근 권한이 있습니다.
4. 책 관리자: 책과 카테고리 관리를 담당하는 직원들.
5. 고객 서비스 에이전트: 지원 티켓에 응답하는 직원들.
6. 제3자 물류 공급자: 주문의 배송과 추적을 관리하는 외부 파트너들.
7. 마케팅 직원: BookHarber를 홍보하며, 특별한 제안과 이벤트를 관리하는 직원들.

BookHarber REST API를 위한 범위 설계#

BookHarber에 대해 Logto의 RBAC 시스템을 효과적으로 구현하기 위해, 우리는 다양한 REST API에 대응하는 범위를 설계해야 합니다. 범위는 각 API 엔드포인트에 대해 특정 역할이 가지는 접근 레벨을 정의하는 권한입니다. 적절한 범위를 각 사용자 역할에 할당함으로써, 우리는 사용자가 그들의 역할에 관련된 행동과 자원에만 접근 권한을 가지도록 할 수 있습니다.

다음 REST API에 대해 범위를 설계해봅시다:

1. 카테고리 API:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. 책 API:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. 고객 API:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. 주문 API:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. 이벤트 API:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. 주문 추적 API:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. 티켓 API:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

역할에 범위 할당#

이제 각 REST API에 대해 적절한 범위를 정의했으므로, 이 범위들을 BookHarber 생태계의 관련 사용자 역할에 할당할 수 있습니다:

"list"와 "read" 범위 간의 차이 이해#

REST API 디자인 및 RBAC의 상황에서 "list"와 "read" 범위 간의 차이점을 더욱 명확하게 설명하기 위해, 온라인 서점인 BookHarber와 관련된 실제 사례를 고려해 봅시다.

BookHarber에는 두 종류의 사용자가 있다고 가정해 보겠습니다: 고객과 고객 서비스 에이전트. 고객은 주문을 작성할 수 있고, 고객 서비스 에이전트는 고객이 주문을 도와야 합니다. 이 시나리오에서 orders API 리소스에 "list"와 "read" 범위가 어떻게 적용되는지 살펴보겠습니다.

1. List 범위: "list" 범위는 사용자가 시스템 내의 엔터티 콜렉션에 접근할 수 있도록 허용합니다. 예를 들어, list:orders 범위는 사용자가 사용 가능한 모든 주문의 목록을 볼 수 있게 합니다. BookHarber의 상황에서, 이 범위는 상점 관리자나 시스템 내 전체 주문에 대해 개요를 숙지해야 하는 다른 직원들에게 유용할 수 있습니다. 그러나 고객 서비스 에이전트는 개별 고객이 그들의 특정한 주문에 대한 도움을 받는 것이기 때문에 전체 주문 목록에는 접근할 수 없어야 합니다.
2. Read 범위: "read" 범위는 사용자에게 주어진 ID를 가진 단일 엔터티에 접근하는 권한을 주고 있습니다. 예를 들어, read:orders 범위는 사용자가 ID에 의해 특정 주문에 대한 세부 정보를 볼 수 있게 합니다. BookHarber의 경우, 이 범위는 특정 고객의 주문에 대한 정보에 접근해야 하는 고객 서비스 에이전트에게 이상적입니다. 고객이 지원 티켓을 열면, 고객 서비스 에이전트는 티켓에 제공된 주문 ID를 사용하여 해당 주문의 세부 정보에 접근하고 볼 수 있습니다.

소유권 이해: 고객이 자신의 주문에 대한 "read" 또는 "list" 범위를 필요로하지 않는 이유#

많은 애플리케이션에서는, 사용자가 해당하는 "read" 또는 "list" 범위를 명시적으로 허가하지 않아도 자신의 자원에 접근하는 것이 일반적입니다. 이는 사용자가 이러한 자원의 소유자로 간주되기 때문이며, 자연스럽게 자신의 자원에 접근할 수 있어야 합니다. 우리의 BookHarber 사례에서, 고객은 주문을 생성할 수 있지만, "read:orders" 또는 "list:orders" 범위를 가지고 있지 않습니다.

소유권 개념은 REST API에서 특정 자원에 대한 접근 제어를 정의하는 데 중요한 역할을 합니다. 사용자가 항상 자신의 자원에 접근할 수 있다는 것을 인정함으로써, 우리는 불필요한 권한을 부여하지 않고 더 효율적이고 안전한 접근 제어를 구현할 수 있습니다. BookHarber의 사례에서 이는, 고객들이 추가적인 범위를 필요로하지 않고도 여전히 자신의 주문을 보고 관리할 수 있다는 것을 의미합니다.

이 작동 방식을 보여주기 위해, GET /orders 엔드포인트를 생각해 봅시다:

1. 사용자가 list:orders 범위를 가지고 있다면 (예: 상점 관리자나 직원들), 그들은 시스템 내의 모든 주문을 볼 수 있습니다. 이는 그들에게 그들의 역할에 필요한 주문 데이터에 대한 포괄적인 보기를 제공합니다.
2. 사용자가 list:orders 범위를 가지고 있지 않다면 (예: 일반 고객들), 시스템은 사용자가 소유한 주문만 반환합니다. 이는 고객들이 불필요한 권한을 부여받지 않게 하면서도 주문 정보에 계속 접근할 수 있도록 보장합니다.

이 소유주 기반 접근 제어를 구현함으로써, API는 다른 사용자 역할에 적절한 접근 레벨을 제공하면서 보안을 유지하고 개별화된 사용자 경험을 조성할 수 있습니다. BookHarber의 시나리오에서, 소유 모델은 고객이 "read:orders" 또는 "list:orders" 범위가 필요 없이도 주문 정보에 접근할 수 있게 하며, 이는 접근 제어 디자인을 단순화하고 전반적인 사용자 경험을 향상시킵니다.

Logto 콘솔에서 설정 구성#

Logto의 콘솔에서 구성을 완료하려면 다음 단계를 따르십시오:

1. React를 위한 Single Page Application (SPA) 생성: React 애플리케이션을 위한 SPA를 Logto 콘솔에서 설정합니다.
2. API 리소스 생성: 식별자 **https://api.bookharber.com**로 새 API 리소스를 추가합니다.
3. 리소스에 대한 범위 정의: 새로 생성된 API 리소스 아래에 필요한 범위를 생성합니다.
4. 역할 생성 및 범위 할당: 애플리케이션에 대한 사용자 역할을 정의하고, 각 역할에 적절한 범위를 할당합니다.
5. 사용자에게 역할 할당: 각 사용자가(직원들을 특히) 그들의 역할에 근거한 정확한 권한을 가지도록 애플리케이션의 사용자들에게 관련 역할을 할당하십시오.

범위를 사용하여 API 보호#

우리의 예시 프로젝트인 BookHarber에서, 우리는 백엔드 서비스에 Express를, 프론트엔드 웹페이지에 React를 사용하고 있습니다. 이 섹션에서는 이러한 인기 있는 기술들에 Logto의 RBAC 기능을 어떻게 통합할 수 있는지에 대한 간략한 개요를 제공합니다.

전체 문서: https://docs.logto.io/docs/recipes/rbac/protect-resource

프론트엔드#

React 애플리케이션에서 Logto를 초기화하려면, 여기서 제공하는 문서를 따르십시오: https://docs.logto.io/docs/recipes/integrate-logto/react/

기본 설정 외에도, 설정에서 "리소스"와 "범위"를 지정해야 합니다:

Logto를 사용하여 API 요청을 하는 방법에 대한 예시입니다:

백엔드#

API를 보호하려면, 이를 참조하십시오: https://docs.logto.io/docs/recipes/protect-your-api/

예제 코드(https://docs.logto.io/docs/recipes/protect-your-api/node)에 추가로, 우리는 범위 유효성 검사를 추가할 필요가 있습니다:

결론#

Logto의 RBAC 시스템은 현대 애플리케이션의 접근 제어와 보안을 관리하는 강력한 도구입니다. Logto의 RBAC 기능을 활용하면, 사용자들이 그들의 역할에 따라 적절한 자원에 접근하도록 보장할 수 있으며, 민감한 데이터와 기능을 무단 접근으로부터 보호할 수 있습니다.

이 기사에서는 온라인 서점인 BookHarber의 실제 예제를 탐색하고, 범위를 설계하는 방법, 그것들을 사용자 역할에 할당하는 방법, 그리고 이러한 기능들을 애플리케이션의 프론트엔드와 백엔드에 구현하는 방법을 보여 주었습니다.

이러한 개념과 기술들을 프로젝트에 적용함으로써, 애플리케이션의 보안 및 접근 제어를 향상시킬 수 있으며, 원활하면서도 보안이 강화된 사용자 경험을 제공할 수 있습니다. 전자상거래 플랫폼, 콘텐츠 관리 시스템, 또는 역할 기반 접근 제어가 필요한 다른 프로젝트에서 작업하고 있다면, Logto의 RBAC 시스템은 접근 제어 요구를 충족시키는 유연하고 효과적인 해결책을 제공합니다.