실무에서의 RBAC: 애플리케이션을 위한 안전한 권한 부여 구현하기

애플리케이션을 위한 안전하고 확장 가능한 권한 부여 시스템을 구현하는 데 어려움을 겪고 있나요? 역할 기반 접근 제어(RBAC)는 사용자 권한 관리를 위한 업계 표준이지만, 제대로 구현하기는 어려울 수 있습니다. 이 튜토리얼은 실제 콘텐츠 관리 시스템(CMS) 예제를 사용하여 탄탄한 RBAC 시스템을 구축하는 방법을 보여줍니다.

이 가이드를 따르면 다음을 배울 수 있습니다:

• ✨ 정밀한 제어를 제공하는 세분화된 권한 설계 및 구현 방법
• 🔒 의미 있는 역할로 권한을 조직하는 모범 사례
• 👤 리소스 소유권을 효과적으로 처리하는 기술
• 🚀 권한 부여 시스템을 확장 가능하고 유지 보수 가능하게 만드는 방법
• 💡 실제 CMS 예제를 통한 실용적 구현

이 튜토리얼의 전체 소스 코드는 GitHub에서 확인할 수 있습니다.

RBAC의 기본 이해하기#

역할 기반 접근 제어는 단순히 사용자에게 권한을 할당하는 것 이상의 의미가 있습니다. 이것은 보안과 유지 보수성의 균형을 맞추는 구조화된 권한 부여 접근 방식을 만드는 것입니다.

RBAC란 무엇인가에 대해 더 알아볼 수 있습니다.

다음은 구현하는 동안 따라야 할 주요 원칙입니다:

세분화된 권한 설계#

세분화된 권한을 통해 시스템에서 사용자가 수행할 수 있는 작업에 대한 정밀한 제어가 가능합니다. "admin" 또는 "user"와 같은 포괄적인 접근 수준 대신, 리소스에 대해 사용자가 수행할 수 있는 구체적인 작업을 정의합니다. 예를 들어:

• read:articles - 시스템 내 모든 기사 보기
• create:articles - 새 기사 작성
• update:articles - 기존 기사 수정
• publish:articles - 기사 게시 상태 변경

리소스 소유권 및 접근 제어#

리소스 소유권은 우리의 CMS 권한 부여 설계에서 기본 개념입니다. RBAC는 서로 다른 역할이 수행할 수 있는 작업을 정의하는 반면, 소유권은 접근 제어에 개인적인 차원을 추가합니다:

• 작성자는 자신이 작성한 기사에 자동으로 접근할 수 있습니다
• 이러한 자연스러운 소유 모형은 작성자가 항상 자신의 콘텐츠를 보고 편집할 수 있도록 합니다
• 시스템은 기사 작업을 처리할 때 역할 권한 또는 소유권을 둘 다 확인합니다
• 예를 들어, update:articles 권한이 없어도 작성자는 여전히 자신의 기사를 편집할 수 있습니다
• 이 설계는 추가 역할 권한의 필요성을 줄이면서 보안을 유지합니다

이중 계층 접근 방식(역할 + 소유권)은 더 직관적이고 안전한 시스템을 만듭니다. 퍼블리셔와 어드민은 역할 권한을 통해 모든 콘텐츠를 여전히 관리할 수 있으며, 작성자는 자신의 작업에 대한 통제권을 유지합니다.

안전한 API 설계하기#

CMS의 핵심 기능을 API 엔드포인트 통해 설계해 보겠습니다:

API에 대한 접근 제어 구현하기#

각 엔드포인트에 대해 두 가지 접근 제어 측면을 고려해야 합니다:

1. 리소스 소유권 - 사용자가 이 리소스를 소유하고 있는가?
2. 역할 기반 권한 - 사용자의 역할이 이 작업을 허용하는가?

각 엔드포인트에 대한 접근을 다음과 같이 처리할 것입니다:

확장 가능한 권한 시스템 만들기#

우리의 API 접근 요구 사항에 따라 다음과 같은 권한을 정의할 수 있습니다:

이 권한들은 소유하지 않은 리소스에 접근할 때만 필요하다는 점을 유념하세요. 기사 소유자는 자동으로:

• 자신의 기사 보기(read:articles 불필요)
• 자신의 기사 편집(update:articles 불필요)
• 자신의 기사 삭제(delete:articles 불필요)

효과적인 역할 구축#

이제 API와 권한을 정의했으므로 이러한 권한을 논리적으로 그룹화하는 역할을 만들 수 있습니다:

참고: 작성자는 역할 권한과 관계없이 자신의 기사에 대한 읽기/수정/삭제 권한을 자동으로 가집니다.

각 역할은 특정 책임을 염두에 두고 설계되었습니다:

• 어드민: CMS의 모든 제어권을 가지며, 모든 기사 작업을 포함합니다
• 퍼블리셔: 콘텐츠 검토 및 게시 관리에 초점을 맞춥니다
• 작성자: 콘텐츠 제작 전담

이 역할 구조는 명확한 책임 분리를 만듭니다:

• 작성자는 콘텐츠 제작에 중점을 둠
• 퍼블리셔는 콘텐츠 품질 및 가시성을 관리
• 어드민은 전체 시스템 제어 유지

Logto에서 RBAC 구성하기#

시작하기 전에, Logto Cloud에서 계정을 생성하거나 Logto OSS 버전을 사용하여 자체 호스팅된 Logto 인스턴스를 사용할 수 있습니다.

하지만 이 튜토리얼에서는 간단하게 Logto Cloud를 사용하겠습니다.

애플리케이션 설정하기#

1. Logto Console에서 "Applications"로 이동하여 새 React 애플리케이션을 만듭니다
   • 애플리케이션 이름: Content Management System
   • 애플리케이션 유형: 전통적인 웹 애플리케이션
   • 리디렉션 URI: http://localhost:5173/callback

API 리소스 및 권한 구성하기#

1. Logto Console에서 "API Resources"로 이동하여 새 API 리소스를 만듭니다
   • API 이름: CMS API
   • API 식별자: https://api.cms.com
   • API 리소스에 권한 추가
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

역할 만들기#

Logto Console에서 Roles로 이동하여 CMS에 대한 다음 역할을 만듭니다

• Admin
  • 모든 권한 부여
• Publisher
  • read:articles, list:articles, publish:articles 권한 부여
• Author
  • create:articles 권한 부여

사용자에게 역할 지정하기#

Logto Console의 "User management" 섹션으로 이동하여 사용자를 생성합니다.

사용자 세부 정보의 "Roles" 탭에서 사용자에게 역할을 할당할 수 있습니다.

우리의 예제에서는 다음 역할을 가진 3명의 사용자를 만듭니다:

• Alex: Admin
• Bob: Publisher
• Charlie: Author

Logto RBAC와 프론트엔드 통합하기#

이제 우리는 Logto에서 RBAC를 설정했으므로, 프론트엔드에 통합할 수 있습니다.

먼저, Logto Quick Starts를 따라 애플리케이션에 Logto를 통합하세요.

우리의 예제에서는 React를 사용하여 설명합니다.

애플리케이션에 Logto를 설정한 후, Logto가 작동하기 위한 RBAC 구성을 추가해야 합니다.

이미 로그인한 상태라면 변경 사항이 적용되도록 로그아웃 후 다시 로그인하세요.

사용자가 Logto로 로그인하고 위에서 지정한 API 리소스에 대한 액세스 토큰을 요청하면, Logto는 사용자의 역할과 관련된 스코프(권한)를 액세스 토큰에 추가합니다.

useLogto 훅의 getAccessTokenClaims를 사용하여 액세스 토큰에서 스코프를 얻을 수 있습니다.

userScopes를 사용하여 사용자가 리소스에 접근할 권한이 있는지 확인할 수 있습니다.

Logto RBAC와 백엔드 통합하기#

이제, Logto RBAC를 백엔드에 통합할 차례입니다.

백엔드 권한 부여 미들웨어#

먼저, 사용자 권한을 확인하고 사용자가 로그인 되었는지 검증하며 특정 API에 접근할 필요한 권한이 있는지 확인하는 미들웨어를 백엔드에 추가해야 합니다.

보시다시피, 이 미들웨어에서 프론트엔드 요청이 유효한 액세스 토큰을 포함하는지 확인하고, 액세스 토큰의 수신자가 우리가 Logto Console에서 생성한 API 리소스와 일치하는지 검증합니다.

API 리소스를 검증하는 이유는, 우리의 API 리소스가 실제로 CMS 백엔드의 리소스를 나타내며, 모든 CMS 권한이 이 API 리소스와 관련되어 있기 때문입니다.

이 API 리소스가 Logto에서 CMS 리소스를 나타내므로, 프론트엔드 코드에서 백엔드에 API 요청을 할 때 해당 액세스 토큰을 포함합니다:

이제 requireAuth 미들웨어를 사용하여 API 엔드포인트를 보호할 수 있습니다.

API 엔드포인트 보호하기#

특정 권한을 가진 사용자만 접근할 수 있는 API의 경우, 미들웨어에서 직접 제한을 추가할 수 있습니다. 예를 들어, 기사 생성 API는 create:articles 권한이 있는 사용자만 접근할 수 있어야 합니다:

권한 및 리소스 소유권을 모두 확인해야 하는 API의 경우, hasScopes 함수를 사용할 수 있습니다. 예를 들어, 기사 목록 API에서는 list:articles 권한이 있는 사용자는 모든 기사에 접근할 수 있으며, 작성자는 자신이 생성한 기사에 접근할 수 있습니다:

이제 RBAC 구현을 완료했습니다. 전체 소스 코드를 확인하여 전체 구현을 볼 수 있습니다.

CMS RBAC 구현 테스트하기#

이제 방금 생성한 세 사용자를 사용하여 CMS RBAC 구현을 테스트해 봅시다.

먼저, 각각 Alex와 Charles로 로그인하여 몇 가지 기사를 만듭니다.

Alex는 Admin 역할을 가졌기 때문에 모든 기사를 작성하고, 삭제하고, 업데이트하고, 게시하며, 볼 수 있습니다.

Charles는 Author 역할을 가졌기 때문에 자신의 기사를 작성하고, 소유한 기사만 보고, 업데이트하고, 삭제할 수 있습니다.

Bob은 Publisher 역할을 가졌으며, 모든 기사를 보고 게시할 수 있지만, 작성하거나 업데이트하거나 삭제할 수는 없습니다.

결론#

축하합니다! 애플리케이션에 견고한 RBAC 시스템을 구현하는 방법을 배웠습니다.

다중 테넌트 애플리케이션을 구축하는 것과 같은 복잡한 시나리오에 대해서는 Logto가 포괄적인 조직 지원을 제공합니다. 조직 전체의 접근 제어를 구현하는 방법을 배우기 위해 다중 테넌트 SaaS 애플리케이션 빌드: 설계에서 구현까지의 완벽한 가이드를 확인해 보세요.

행복한 코딩 되세요! 🚀