본문으로 건너뛰기

Casbin 매칭 동작 상세 이해

· 약 6분

이 글은 Casbin 라이브러리를 사용하여 RBAC를 설계하고 구현하는 방법을 설명합니다. 리소스 계층 구조와 권한을 상속하는 역할이 있는 SaaS 플랫폼의 경우, Casbin은 성능이 좋은 옵션입니다.

RBAC 소개​

RBAC은 사용자가 보유한 역할에 기반하여 접근을 제한합니다. 계층적 RBAC이 어떻게 작동하는지 보기 위해 Azure의 RBAC을 살펴본 후 Casbin에서 유사한 것을 구현합니다.

Azure의 계층적 RBAC​

Azure Hierarchy

Azure에서는 Owner 역할이 다양한 범위(scope)에 적용됩니다. 구독(subscription) 수준에서 Owner 권한을 가지고 있다면, 해당 구독 하위의 모든 리소스 그룹 및 리소스에 대한 Owner 권한을 갖게 됩니다. 리소스 그룹 수준에서 Owner 권한을 가지고 있다면, 해당 그룹 내의 모든 리소스에 대한 Owner 권한을 갖게 됩니다.

아래 이미지는 구독 수준의 Owner 접근 권한을 보여줍니다. Subscription Owner

해당 구독 하위의 리소스 그룹에 대한 IAM(Identity and Access Management)을 확인하면 상속된 Owner 접근 권한을 확인할 수 있습니다. RG Owner

이것이 Azure의 RBAC가 계층적인 방식입니다. 많은 시스템이 유사한 계층 구조를 사용합니다. 이 튜토리얼에서는 Casbin으로 비교 가능한 모델을 구현합니다.

Casbin 작동 방식​

Casbin의 구성 요소(request, policy, matcher, effect)를 이해하면 RBAC 모델을 설계하고 조정하기가 더 쉬워집니다.

ACL이란 무엇인가?​

**ACL (Access Control List)**은 사용자를 작업(action)에, 작업을 리소스에 매핑합니다.

Model 정의​

최소화된 ACL 모델:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
  1. request_definition — 요청 형식을 정의합니다. 예: alice, write, data1은 "Alice가 data1을 쓸 수 있는가?"라는 의미입니다.
  2. policy_definition — 정책 형식을 정의합니다. 예: 정책 alice, write, data1은 Alice에게 data1 쓰기 권한을 부여합니다.
  3. policy_effect — 여러 일치하는 정책이 결합되는 방식(예: allow-override)을 정의합니다.
  4. matchers — 충족되어야 하는 조건: r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Casbin 에디터에서 시도해 보기​

Casbin editor를 열고 위의 모델을 Model 에디터에 붙여넣으세요.

다음 내용을 Policy 에디터에 붙여넣으세요:

p, alice, read, data1
p, bob, write, data2

그리고 다음 내용을 Request 에디터에 붙여넣으세요:

alice, read, data1

결과는 다음과 같습니다:

true

ACL 모델, 정책 및 요청 매칭의 시각적 표현​

acl

RBAC이란 무엇인가?​

**RBAC (Role-Based Access Control)**은 사용자에게 역할을 할당하며, 역할은 리소스에 대한 권한을 가집니다. 요청은 사용자의 역할이 리소스에 대한 작업을 허용하는지 확인합니다.

Model 정의​

간단한 RBAC 모델:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj
  1. role_definition — 그래프 관계(예: 역할-역할 또는 사용자-역할을 위한 g)를 정의합니다. matcher는 이를 사용하여 역할과 권한을 해석합니다.

Casbin 에디터에서 시도해 보기​

editor를 열고 위의 모델을 붙여넣으세요.

다음 내용을 Policy 에디터에 붙여넣으세요:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

그리고 다음 내용을 Request 에디터에 붙여넣으세요:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

결과는 다음과 같습니다:

true
false
true
true
false

RBAC 모델, 정책 및 요청 매칭의 시각적 표현​

rbac

g (역할-작업) 관계는 그래프입니다. 정책에서는 가장자리(edges)로 작성되며, 예를 들어 다음과 같습니다:

g, reader, read
g, owner, read
g, owner, write
정보

p는 일반적인 정책(==와 비교)입니다. g는 그래프 관계입니다. 접미사를 사용하여 g2, g3 등을 추가로 정의할 수 있습니다.

계층적 RBAC​

계층적 RBAC에서는 상속 관계가 있는 여러 resource types(예: Subscription → ResourceGroup)이 존재합니다. 구독 sub1에는 리소스 그룹 rg1, rg2가 포함될 수 있습니다. 마찬가지로, 구독 수준 역할/작업과 리소스 그룹 수준 역할/작업이 있으며 그 사이에 상속 관계가 있습니다. 예를 들어, 구독 역할 sub-owner는 리소스 그룹 역할 rg-owner로 상속될 수 있습니다. 즉, sub1에 대해 sub-owner 권한을 가지고 있다면, 실질적으로 rg1 및 rg2에 대해 rg-owner 권한을 가지게 됩니다.

Model 정의​

최소화된 계층적 RBAC 모델:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)

여기서 g는 역할/작업을 연결하고 g2는 리소스를 연결합니다(예: 구독을 리소스 그룹에 연결).

Casbin 에디터에서 시도해 보기​

에디터를 열고 위의 모델을 붙여넣으세요.

Policy editor에 다음 내용을 붙여넣으세요:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

그리고 Request editor에 다음 내용을 붙여넣으세요:

alice, rg-read, rg1

결과는 다음과 같습니다:

true

RBAC 모델, 정책 및 요청 매칭의 시각적 표현​

hrbac

g 엣지(역할 → 작업, 역할 → 역할)는 정책에서 다음과 같이 작성할 수 있습니다:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

g2 엣지는 구독을 리소스 그룹에 매핑합니다:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

주체 매칭 시각적 표현​

hrbac-sub-match

작업 매칭 시각적 표현​

hrbac-act-match

객체 매칭 시각적 표현​

hrbac-obj-match

정보

Casbin은 요청을 모든 정책에 대해 평가합니다. 최소한 하나의 정책이 일치하면 결과는 true이고, 그렇지 않으면 false입니다.

결론​

이 튜토리얼에서는 ACL, RBAC 및 계층형 RBAC을 Casbin으로 표현하는 방법을 보여 주었습니다. 후속 편에서는 Spring Boot 앱에서 이를 구현하고 Casbin으로 API를 보호하는 방법을 다루겠습니다.

Comments are powered by giscus and GitHub Discussions. They load from giscus.app and GitHub only after you click the button below.