한국어
실무에서의 RBAC: 애플리케이션을 위한 안전한 권한 부여 구현하기
이 포괄적인 가이드를 통해 애플리케이션에서 역할 기반 접근 제어(RBAC)를 구현하는 방법을 배우세요. 권한 설계, 역할 생성, 리소스 소유권 처리, 실사용 CMS 예제를 통해 안전한 권한 부여 시스템을 구축하는 모범 사례를 발견하세요. 확장 가능하고 유지 보수 가능한 접근 제어를 구현하려는 개발자에게 이상적입니다.
Yijun
Developer
Developer
이 포괄적인 가이드를 통해 애플리케이션에서 역할 기반 접근 제어(RBAC)를 구현하는 방법을 배우세요. 권한 설계, 역할 생성, 리소스 소유권 처리, 실사용 CMS 예제를 통해 안전한 권한 부여 시스템을 구축하는 모범 사례를 발견하세요. 확장 가능하고 유지 보수 가능한 접근 제어를 구현하려는 개발자에게 이상적입니다.
애플리케이션을 위한 안전하고 확장 가능한 권한 부여 시스템을 구현하는 데 어려움을 겪고 있나요? 역할 기반 접근 제어(RBAC)는 사용자 권한 관리를 위한 업계 표준이지만, 제대로 구현하기는 어려울 수 있습니다. 이 튜토리얼은 실제 콘텐츠 관리 시스템(CMS) 예제를 사용하여 탄탄한 RBAC 시스템을 구축하는 방법을 보여줍니다.
이 가이드를 따르면 다음을 배울 수 있습니다:
이 튜토리얼의 전체 소스 코드는 GitHub에서 확인할 수 있습니다.
역할 기반 접근 제어는 단순히 사용자에게 권한을 할당하는 것 이상의 의미가 있습니다. 이것은 보안과 유지 보수성의 균형을 맞추는 구조화된 권한 부여 접근 방식을 만드는 것입니다.
RBAC란 무엇인가에 대해 더 알아볼 수 있습니다.
다음은 구현하는 동안 따라야 할 주요 원칙입니다:
세분화된 권한을 통해 시스템에서 사용자가 수행할 수 있는 작업에 대한 정밀한 제어가 가능합니다. "admin" 또는 "user"와 같은 포괄적인 접근 수준 대신, 리소스에 대해 사용자가 수행할 수 있는 구체적인 작업을 정의합니다. 예를 들어:
read:articles - 시스템 내 모든 기사 보기create:articles - 새 기사 작성update:articles - 기존 기사 수정publish:articles - 기사 게시 상태 변경리소스 소유권은 우리의 CMS 권한 부여 설계에서 기본 개념입니다. RBAC는 서로 다른 역할이 수행할 수 있는 작업을 정의하는 반면, 소유권은 접근 제어에 개인적인 차원을 추가합니다:
update:articles 권한이 없어도 작성자는 여전히 자신의 기사를 편집할 수 있습니다이중 계층 접근 방식(역할 + 소유권)은 더 직관적이고 안전한 시스템을 만듭니다. 퍼블리셔와 어드민은 역할 권한을 통해 모든 콘텐츠를 여전히 관리할 수 있으며, 작성자는 자신의 작업에 대한 통제권을 유지합니다.
CMS의 핵심 기능을 API 엔드포인트 통해 설계해 보겠습니다:
각 엔드포인트에 대해 두 가지 접근 제어 측면을 고려해야 합니다:
각 엔드포인트에 대한 접근을 다음과 같이 처리할 것입니다:
| 엔드포인트 | 접근 제어 로직 |
|---|---|
| GET /api/articles | - list:articles 권한이 있는 모든 사람, 또는 작성자는 자신의 기사를 볼 수 있습니다 |
| GET /api/articles/:id | - read:articles 권한이 있는 모든 사람, 또는 해당 기사의 작성자 |
| POST /api/articles | - create:articles 권한이 있는 모든 사람 |
| PATCH /api/articles/:id | - update:articles 권한이 있는 모든 사람, 또는 해당 기사의 작성자 |
| DELETE /api/articles/:id | - delete:articles 권한이 있는 모든 사람, 또는 해당 기사의 작성자 |
| PATCH /api/articles/:id/published | - publish:articles 권한이 있는 사용자만 |
우리의 API 접근 요구 사항에 따라 다음과 같은 권한을 정의할 수 있습니다:
| 권한 | 설명 |
|---|---|
| list:articles | 시스템 내 모든 기사 목록 보기 |
| read:articles | 모든 기사의 전체 내용 읽기 |
| create:articles | 새 기사 작성 |
| update:articles | 모든 기사 수정 |
| delete:articles | 모든 기사 삭제 |
| publish:articles | 게시 상태 변경 |
이 권한들은 소유하지 않은 리소스에 접근할 때만 필요하다는 점을 유념하세요. 기사 소유자는 자동으로:
read:articles 불필요)update:articles 불필요)delete:articles 불필요)이제 API와 권한을 정의했으므로 이러한 권한을 논리적으로 그룹화하는 역할을 만들 수 있습니다:
| 권한/역할 | 👑 어드민 | 📝 퍼블리셔 | ✍️ 작성자 |
|---|---|---|---|
| 설명 | 전체 콘텐츠 관리를 위한 전체 시스템 접근 | 모든 기사 보기 및 게시 상태 제어 가능 | 시스템에서 새로운 기사 작성 가능 |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
참고: 작성자는 역할 권한과 관계없이 자신의 기사에 대한 읽기/수정/삭제 권한을 자동으로 가집니다.
각 역할은 특정 책임을 염두에 두고 설계되었습니다:
이 역할 구조는 명확한 책임 분리를 만듭니다:
시작하기 전에, Logto Cloud에서 계정을 생성하거나 Logto OSS 버전을 사용하여 자체 호스팅된 Logto 인스턴스를 사용할 수 있습니다.
하지만 이 튜토리얼에서는 간단하게 Logto Cloud를 사용하겠습니다.
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
Logto Console에서 Roles로 이동하여 CMS에 대한 다음 역할을 만듭니다
read:articles, list:articles, publish:articles 권한 부여create:articles 권한 부여
Logto Console의 "User management" 섹션으로 이동하여 사용자를 생성합니다.
사용자 세부 정보의 "Roles" 탭에서 사용자에게 역할을 할당할 수 있습니다.
우리의 예제에서는 다음 역할을 가진 3명의 사용자를 만듭니다:
이제 우리는 Logto에서 RBAC를 설정했으므로, 프론트엔드에 통합할 수 있습니다.
먼저, Logto Quick Starts를 따라 애플리케이션에 Logto를 통합하세요.
우리의 예제에서는 React를 사용하여 설명합니다.
애플리케이션에 Logto를 설정한 후, Logto가 작동하기 위한 RBAC 구성을 추가해야 합니다.
이미 로그인한 상태라면 변경 사항이 적용되도록 로그아웃 후 다시 로그인하세요.
사용자가 Logto로 로그인하고 위에서 지정한 API 리소스에 대한 액세스 토큰을 요청하면, Logto는 사용자의 역할과 관련된 스코프(권한)를 액세스 토큰에 추가합니다.
useLogto 훅의 getAccessTokenClaims를 사용하여 액세스 토큰에서 스코프를 얻을 수 있습니다.
userScopes를 사용하여 사용자가 리소스에 접근할 권한이 있는지 확인할 수 있습니다.
이제, Logto RBAC를 백엔드에 통합할 차례입니다.
먼저, 사용자 권한을 확인하고 사용자가 로그인 되었는지 검증하며 특정 API에 접근할 필요한 권한이 있는지 확인하는 미들웨어를 백엔드에 추가해야 합니다.
보시다시피, 이 미들웨어에서 프론트엔드 요청이 유효한 액세스 토큰을 포함하는지 확인하고, 액세스 토큰의 수신자가 우리가 Logto Console에서 생성한 API 리소스와 일치하는지 검증합니다.
API 리소스를 검증하는 이유는, 우리의 API 리소스가 실제로 CMS 백엔드의 리소스를 나타내며, 모든 CMS 권한이 이 API 리소스와 관련되어 있기 때문입니다.
이 API 리소스가 Logto에서 CMS 리소스를 나타내므로, 프론트엔드 코드에서 백엔드에 API 요청을 할 때 해당 액세스 토큰을 포함합니다:
이제 requireAuth 미들웨어를 사용하여 API 엔드포인트를 보호할 수 있습니다.
특정 권한을 가진 사용자만 접근할 수 있는 API의 경우, 미들웨어에서 직접 제한을 추가할 수 있습니다. 예를 들어, 기사 생성 API는 create:articles 권한이 있는 사용자만 접근할 수 있어야 합니다:
권한 및 리소스 소유권을 모두 확인해야 하는 API의 경우, hasScopes 함수를 사용할 수 있습니다. 예를 들어, 기사 목록 API에서는 list:articles 권한이 있는 사용자는 모든 기사에 접근할 수 있으며, 작성자는 자신이 생성한 기사에 접근할 수 있습니다:
이제 RBAC 구현을 완료했습니다. 전체 소스 코드를 확인하여 전체 구현을 볼 수 있습니다.
이제 방금 생성한 세 사용자를 사용하여 CMS RBAC 구현을 테스트해 봅시다.
먼저, 각각 Alex와 Charles로 로그인하여 몇 가지 기사를 만듭니다.
Alex는 Admin 역할을 가졌기 때문에 모든 기사를 작성하고, 삭제하고, 업데이트하고, 게시하며, 볼 수 있습니다.
Charles는 Author 역할을 가졌기 때문에 자신의 기사를 작성하고, 소유한 기사만 보고, 업데이트하고, 삭제할 수 있습니다.
Bob은 Publisher 역할을 가졌으며, 모든 기사를 보고 게시할 수 있지만, 작성하거나 업데이트하거나 삭제할 수는 없습니다.
축하합니다! 애플리케이션에 견고한 RBAC 시스템을 구현하는 방법을 배웠습니다.
다중 테넌트 애플리케이션을 구축하는 것과 같은 복잡한 시나리오에 대해서는 Logto가 포괄적인 조직 지원을 제공합니다. 조직 전체의 접근 제어를 구현하는 방법을 배우기 위해 다중 테넌트 SaaS 애플리케이션 빌드: 설계에서 구현까지의 완벽한 가이드를 확인해 보세요.
행복한 코딩 되세요! 🚀