Understanding How Casbin Matching Works in Detail

이 포스트에서는 Casbin 라이브러리를 사용한 RBAC의 설계와 구현에 대해 설명하겠습니다. 다양한 리소스 계층과 상위 레벨에서 권한을 상속받는 역할을 다루는 SaaS 플랫폼의 경우, Casbin은 고성능 대안을 제공합니다.

RBAC 소개

RBAC은 개인이 가진 역할에 따라 리소스에 대한 접근을 제한하는 방법입니다. 계층적 RBAC가 어떻게 작동하는지 더 잘 이해하기 위해, 다음 섹션에서 Azure의 RBAC 시스템을 살펴보고 비슷한 시스템을 구현해 보겠습니다.

Azure의 계층적 RBAC 이해하기

Azure 계층

Azure의 모든 리소스에 대해 Owner라는 역할이 있습니다. 가령, 저에게 구독 수준에서 Owner 역할이 할당되었다면, 그 말은 저가 해당 구독 아래의 모든 리소스 그룹과 리소스의 Owner라는 의미입니다. 만약 저가 리소스 그룹 수준에서 Owner라면, 그 말은 저가 그 리소스 그룹 아래의 모든 리소스의 Owner라는 의미입니다.

이 이미지는 저가 구독 수준에서 Owner 접근 권한을 가지고 있음을 보여줍니다. 구독 Owner

이 구독 아래의 리소스 그룹의 IAM을 확인하면, 저가 구독에서 Owner 접근 권한을 상속받았음을 볼 수 있습니다. RG Owner

그래서, 이것이 Azure의 RBAC가 계층적인 방식입니다. 대부분의 엔터프라이즈 소프트웨어는 리소스 레벨의 계층적 특성 때문에 계층적 RBAC를 사용합니다. 이 튜토리얼에서는 Casbin을 사용하여 비슷한 시스템을 구현해 보겠습니다.

Casbin은 어떻게 작동하나요?

구현에 들어가기 전에, Casbin이 무엇인지 그리고 고수준에서 어떻게 작동하는지 이해하는 것이 중요합니다. 이 이해는 각 역할 기반 접근 제어(RBAC) 시스템이 특정 요구 사항에 따라 다르기 때문에 필요합니다. Casbin의 작동 방식을 이해함으로써, 우리는 모델을 효과적으로 미세 조정할 수 있습니다.

ACL이란 무엇인가요?

ACL은 접근 제어 목록을 의미합니다. 이는 사용자가 행동에 매핑되고 행동이 리소스에 매핑되는 방법입니다.

모델 정의

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

request_definition은 시스템의 쿼리 템플릿입니다. 예를 들어, alice, write, data1 요청은 "주체 Alice가 객체 'data1'에 'write' 작업을 수행할 수 있나요?"로 해석될 수 있습니다.
policy_definition은 시스템의 할당 템플릿입니다. 예를 들어, alice, write, data1이라는 정책을 생성함으로써, Alice라는 주체에게 'data1'이라는 객체에 대해 'write'라는 동작을 수행할 수 있는 권한을 부여하게 됩니다.
policy_effect는 정책의 효과를 정의합니다.
matchers 섹션에서는 r.sub == p.sub && r.obj == p.obj && r.act == p.act라는 조건을 사용하여 요청이 정책과 일치하는지 확인합니다.

이제 Casbin 편집기에서 모델을 테스트해 봅시다

편집기를 열고 위의 모델을 모델 편집기에 붙여넣습니다.

다음을 정책 편집기에 붙여넣습니다:

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

그리고 다음을 요청 편집기에 붙여넣습니다:

alice, read, data1

결과는 다음과 같을 것입니다:

true

ACL 모델, 정책, 그리고 요청 일치의 시각적 표현

acl

RBAC이란 무엇인가요?

RBAC은 Role-Based Access Control의 약자입니다. RBAC에서는 사용자에게 리소스에 대한 역할이 할당되며, 역할은 임의의 동작을 포함할 수 있습니다. 그런 다음 요청은 사용자가 리소스에 대해 동작을 수행할 권한이 있는지 확인합니다.

모델 정의

간단한 예제 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

role_definition은 요청 객체와 정책 객체를 비교하는 데 그래프를 사용하는 그래프 관계 빌더입니다.

이제 Casbin 편집기에서 모델을 테스트해 봅시다

편집기를 열고 위의 모델을 모델 편집기에 붙여넣습니다.

다음을 정책 편집기에 붙여넣습니다:

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

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

그리고 다음을 요청 편집기에 붙여넣습니다:

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

결과는 다음과 같을 것입니다:

true
false
true
true
false

RBAC 모델, 정책, 그리고 요청 일치의 시각적 표현

rbac

g - 역할에서 동작으로의 매핑 테이블은 역할을 동작에 매핑하는 그래프를 가지고 있습니다. 이 그래프는 정책에서 보여주는 것처럼, 간선의 목록으로 코드화될 수 있으며, 이는 그래프를 표현하는 일반적인 방법입니다:

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

정보

p는 == 연산자를 사용하여 비교할 수 있는 일반 정책을 나타냅니다. g는 그래프 기반 비교 함수입니다. g, g2, g3, ... 등과 같이 숫자 접미사를 추가하여 여러 그래프 비교자를 정의할 수 있습니다.

계층적 RBAC이란 무엇인가요?

계층적 RBAC에서는 리소스 유형이 하나 이상 있으며 리소스 유형 간에 상속 관계가 있습니다. 예를 들어, "subscription"은 한 유형이고 "resourceGroup"은 다른 유형입니다. Subscription 유형의 sub1은 ResourceGroup 유형의 여러 resourceGroups (rg1, rg2)를 포함할 수 있습니다.

리소스 계층과 유사하게, 역할과 행동에는 두 가지 유형이 있습니다: Subscription 역할과 행동, 그리고 ResourceGroup 역할과 행동. Subscription 역할과 ResourceGroup 역할 사이에는 임의의 관계가 있습니다. 예를 들어, Subscription Role sub-owner를 고려해 보세요. 이 역할은 ResourceGroup Role rg-owner에 의해 상속되며, 이는 저가 Subscription sub1에서 sub-owner 역할을 할당받으면 자동으로 rg1 and rg2에서 rg-owner 역할도 얻게 된다는 것을 의미합니다.

모델 정의

계층적 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)

role_definition은 요청 객체와 정책 객체를 비교하는 그래프를 사용하는 그래프 관계 빌더입니다.

이제 Casbin 편집기에서 모델을 테스트해 보겠습니다

편집기를 열고 위의 모델을 Model 편집기에 붙여넣습니다.

다음을 Policy 편집기에 붙여넣습니다:

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 편집기에 붙여넣습니다:

alice, rg-read, rg1

결과는 다음과 같을 것입니다:

true

RBAC 모델, 정책, 그리고 요청 일치의 시각적 표현

hrbac

g - Role to (Action, Role) Mapping 테이블은 역할을 행동, 역할 매핑에 매핑하는 그래프를 가지고 있습니다. 이 그래프는 정책에서 보여지는 것처럼, 그래프를 표현하는 일반적인 방법인 엣지의 목록으로 코드화될 수 있습니다:

// 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 - Sub to RG Mapping 테이블은 subscription을 resourceGroup에 매핑하는 그래프를 가지고 있습니다:

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

Subject Matching 시각적 표현

hrbac-sub-match

Action Matching 시각적 표현

hrbac-act-match

Object Matching 시각적 표현

hrbac-obj-match

정보

요청이 Casbin에 제출되면, 이 일치가 모든 정책에 대해 발생합니다. 적어도 하나의 정책이 일치하면, 요청의 결과는 참입니다. 어떤 정책도 요청과 일치하지 않으면, 결과는 거짓입니다.

결론

이 튜토리얼에서는 다양한 인증 모델이 어떻게 작동하는지 그리고 이를 Casbin을 사용하여 어떻게 모델링할 수 있는지에 대해 배웠습니다. 이 튜토리얼의 두 번째 부분에서는 이를 데모 Spring Boot 애플리케이션에 구현하고 Casbin을 사용하여 API를 보호하는 방법을 구현하겠습니다.