한국어
Logto에서 RBAC를 분석하는 방법: 포괄적인 실제 사례
이 기사에서는 Logto의 역할 기반 접근 제어 (RBAC)를 정안하는 범위한 지침을 제공하며, 온라인 서점 사례를 통해 핵심 사용자 역할, 범위, 프론트엔드 및 백엔드 애플리케이션에 Logto의RBAC기능을 통합하는 방법을 탐색합니다.
Sijie
Developer
Developer
이 기사에서는 Logto의 역할 기반 접근 제어 (RBAC)를 정안하는 범위한 지침을 제공하며, 온라인 서점 사례를 통해 핵심 사용자 역할, 범위, 프론트엔드 및 백엔드 애플리케이션에 Logto의RBAC기능을 통합하는 방법을 탐색합니다.
접근 제어 및 보안은 현대 애플리케이션의 필수적인 측면이며, 사용자가 자원에 적절한 접근 권한을 가지고 있는지 확인합니다. Logto의 역할 기반 접근 제어 (RBAC)는 개발자에게 애플리케이션의 접근 제어와 보안을 관리하는 효과적인 방법을 제공합니다. 이 기사에서는 실제 예제를 사용하여 Logto의 RBAC 구현의 강력한 기능을 탐색하고, 이러한 개념을 프로젝트에 이해하고 적용하는 데 도움이 됩니다.
프론트엔드와 백엔드 코드 스니펫을 모두 검토하면, 애플리케이션 스택에 Logto의 RBAC를 통합하는 데 대한 포괄적인 시각을 얻을 수 있습니다. 이 기사를 마칠 때쯤에는 Logto의 RBAC 기능을 활용하여 프로젝트의 보안 및 접근 제어를 강화하는 데 잘 준비되어 있을 것입니다.
Logto의 RBAC 기능을 효과적으로 보여주기 위해, 우리는 실제 예시를 사용할 것입다: BookHarber, 온라인 서점. BookHarber는 고객과 직원을 위해 광범위한 기능을 제공하며, 이는 원활하고 안전한 쇼핑 경험을 보장합니다.
BookHarber의 주요 기능은 다음과 같습니다:
BookHarber 생태계에서 우리는 다음과 같은 몇 가지 주요 사용자 역할을 식별할 수 있습니다.
BookHarber에 대해 Logto의 RBAC 시스템을 효과적으로 구현하기 위해, 우리는 다양한 REST API에 대응하는 범위를 설계해야 합니다. 범위는 각 API 엔드포인트에 대해 특정 역할이 가지는 접근 레벨을 정의하는 권한입니다. 적절한 범위를 각 사용자 역할에 할당함으로써, 우리는 사용자가 그들의 역할에 관련된 행동과 자원에만 접근 권한을 가지도록 할 수 있습니다.
다음 REST API에 대해 범위를 설계해봅시다:
create:categories: POST /categorieswrite:categories: PUT /categories/:iddelete:categories: DELETE /categories/:idlist:categories: GET /categoriescreate:books: POST /bookswrite:books: PUT /books/:iddelete:books: DELETE /books/:idlist:books: GET /booksread:books: GET /books/:idlist:customers: GET /customerswrite:customers: PUT /customers/:iddelete:customers: DELETE /customers/:idread:customers: GET /customers/:idcreate:orders: POST /orderslist:orders: GET /ordersread:orders: GET /orders/:idwrite:orders: PUT /orders/:idcreate:events: POST /eventswrite:events: PUT /events/:idlist:events: GET /eventsdelete:events: DELETE /events/:idread:orderTracks: GET /orders/:id/trackscreate:orderTracks: POST /orders/:id/trackswrite:orderTracks: PUT /orders/:id/tracks/:trackIdcreate:tickets: POST /ticketslist:tickets: GET /ticketsread:tickets: GET /tickets/:idwrite:tickets: PUT /tickets/:id이제 각 REST API에 대해 적절한 범위를 정의했으므로, 이 범위들을 BookHarber 생태계의 관련 사용자 역할에 할당할 수 있습니다:
| 범위 | 손님 | 고객 | 상점 관리자 | 책 관리자 | 고객 서비스 에이전트 | 제3자 물류 공급자 | 마케팅 직원 |
|---|---|---|---|---|---|---|---|
| create:categories | ✓ | ✓ | |||||
| write:categories | ✓ | ✓ | |||||
| delete:categories | ✓ | ✓ | |||||
| list:categories | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| create:books | ✓ | ✓ | |||||
| write:books | ✓ | ✓ | |||||
| delete:books | ✓ | ✓ | |||||
| list:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| read:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| list:customers | ✓ | ✓ | |||||
| write:customers | ✓ | ||||||
| delete:customers | ✓ | ||||||
| read:customers | ✓ | ✓ | |||||
| create:orders | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| list:orders | ✓ | ||||||
| read:orders | ✓ | ✓ | |||||
| write:orders | ✓ | ||||||
| create:events | ✓ | ✓ | |||||
| write:events | ✓ | ✓ | |||||
| list:events | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| delete:events | ✓ | ✓ | |||||
| read:orderTracks | ✓ | ✓ | ✓ | ||||
| create:orderTracks | ✓ | ✓ | |||||
| write:orderTracks | ✓ | ✓ | |||||
| create:tickets | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| list:tickets | ✓ | ✓ | |||||
| read:tickets | ✓ | ✓ | |||||
| write:tickets | ✓ | ✓ |
REST API 디자인 및 RBAC의 상황에서 "list"와 "read" 범위 간의 차이점을 더욱 명확하게 설명하기 위해, 온라인 서점인 BookHarber와 관련된 실제 사례를 고려해 봅시다.
BookHarber에는 두 종류의 사용자가 있다고 가정해 보겠습니다: 고객과 고객 서비스 에이전트. 고객은 주문을 작성할 수 있고, 고객 서비스 에이전트는 고객이 주문을 도와야 합니다. 이 시나리오에서 orders API 리소스에 "list"와 "read" 범위가 어떻게 적용되는지 살펴보겠습니다.
list:orders 범위는 사용자가 사용 가능한 모든 주문의 목록을 볼 수 있게 합니다. BookHarber의 상황에서, 이 범위는 상점 관리자나 시스템 내 전체 주문에 대해 개요를 숙지해야 하는 다른 직원들에게 유용할 수 있습니다. 그러나 고객 서비스 에이전트는 개별 고객이 그들의 특정한 주문에 대한 도움을 받는 것이기 때문에 전체 주문 목록에는 접근할 수 없어야 합니다.read:orders 범위는 사용자가 ID에 의해 특정 주문에 대한 세부 정보를 볼 수 있게 합니다. BookHarber의 경우, 이 범위는 특정 고객의 주문에 대한 정보에 접근해야 하는 고객 서비스 에이전트에게 이상적입니다. 고객이 지원 티켓을 열면, 고객 서비스 에이전트는 티켓에 제공된 주문 ID를 사용하여 해당 주문의 세부 정보에 접근하고 볼 수 있습니다.많은 애플리케이션에서는, 사용자가 해당하는 "read" 또는 "list" 범위를 명시적으로 허가하지 않아도 자신의 자원에 접근하는 것이 일반적입니다. 이는 사용자가 이러한 자원의 소유자로 간주되기 때문이며, 자연스럽게 자신의 자원에 접근할 수 있어야 합니다. 우리의 BookHarber 사례에서, 고객은 주문을 생성할 수 있지만, "read:orders" 또는 "list:orders" 범위를 가지고 있지 않습니다.
소유권 개념은 REST API에서 특정 자원에 대한 접근 제어를 정의하는 데 중요한 역할을 합니다. 사용자가 항상 자신의 자원에 접근할 수 있다는 것을 인정함으로써, 우리는 불필요한 권한을 부여하지 않고 더 효율적이고 안전한 접근 제어를 구현할 수 있습니다. BookHarber의 사례에서 이는, 고객들이 추가적인 범위를 필요로하지 않고도 여전히 자신의 주문을 보고 관리할 수 있다는 것을 의미합니다.
이 작동 방식을 보여주기 위해, GET /orders 엔드포인트를 생각해 봅시다:
list:orders 범위를 가지고 있다면 (예: 상점 관리자나 직원들), 그들은 시스템 내의 모든 주문을 볼 수 있습니다. 이는 그들에게 그들의 역할에 필요한 주문 데이터에 대한 포괄적인 보기를 제공합니다.list:orders 범위를 가지고 있지 않다면 (예: 일반 고객들), 시스템은 사용자가 소유한 주문만 반환합니다. 이는 고객들이 불필요한 권한을 부여받지 않게 하면서도 주문 정보에 계속 접근할 수 있도록 보장합니다.이 소유주 기반 접근 제어를 구현함으로써, API는 다른 사용자 역할에 적절한 접근 레벨을 제공하면서 보안을 유지하고 개별화된 사용자 경험을 조성할 수 있습니다. BookHarber의 시나리오에서, 소유 모델은 고객이 "read:orders" 또는 "list:orders" 범위가 필요 없이도 주문 정보에 접근할 수 있게 하며, 이는 접근 제어 디자인을 단순화하고 전반적인 사용자 경험을 향상시킵니다.
Logto의 콘솔에서 구성을 완료하려면 다음 단계를 따르십시오:
https://api.bookharber.com**로 새 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 시스템은 접근 제어 요구를 충족시키는 유연하고 효과적인 해결책을 제공합니다.