여러분 「타코스(Tacos)」 드시고 계신가요?

안녕하세요, tacosDB 개발 책임자입니다.

타코스를 너무 좋아해서 타코스에 특화된 사이트 「tacos DB」를 개발하고 있습니다!

tacos DB에서는 WordPress 등을 사용하지 않고, 타코스 가게나 기사를 관리하기 위한 CMS를 풀 스크래치(Full-scratch)로 만들고 있습니다.

CMS가 있으면, 누가, 무엇을, 어디까지 조작할 수 있게 할 것인가가 과제로 떠오르기 쉽습니다.

그리고 최근에는 한 가지 더 생각할 것이 늘어났습니다.

tacos DB는 운영 멤버가 적기 때문에

AI에게 기사를 쓰게 하기

AI에게 점포 정보를 보완하게 하기

AI에게 CMS 입고를 도와달라고 하기

다양한 작업을 AI에게 도와달라고 하고 있습니다.

하지만, 기사만 쓰는 AI에게 모든 조작 권한을 주는 것은 상당히 무섭지 않나요?

이 기사에서는 아래의 내용들을 정리해 보려고 합니다.

• 인증 (Authentication)과 인가 (Authorization)
• ACL / RBAC / ABAC / ReBAC / PBAC 와 같은 인가 모델 (Authorization Model)

참고로, tacos DB에서는 「endpoint를 호출할 수 있는가」는 RBAC + scope로 관리하고, 「그 대상을 정말로 조작해도 되는가」는 usecase의 도메인 규칙 (domain rule)으로 차단하고 있습니다.

인증 (Authentication)과 인가 (Authorization)는 별개의 것입니다.

로그인하여 「당신은 member_123 입니다」라고 확인하는 것이 인증입니다.

그 member_123이 무엇을 해도 되는지 확인하는 것이 인가입니다.

인증과 인가에 대해서는 알기 쉽게 설명해 주는 기사가 많이 있으니 그쪽을 참조해 주세요!

인가 모델에는 몇 가지 종류가 있습니다.

인가 모델	사고방식	적합한 상황	주의점
ACL	사람과 조작을 직접 연결	작은 시스템, 조작 단위로 세밀하게 허가하고 싶은 경우	사람이나 조작이 늘어나면 관리가 힘들다
...

ACL은 Access Control List의 약자입니다.

「이 사람은 이 조작을 할 수 있다」라는 표를 가지는 방식입니다.

MemberA는 점포를 생성할 수 있다

MemberA는 점포를 갱신할 수 있다

MemberB는 점포를 공개할 수 있다

MemberC는 기사를 작성할 수 있다

이런 느낌이죠.

다만, 사용자나 조작이 늘어나면 표가 점점 커집니다.

기능이나 멤버가 적을 때는 괜찮지만, 늘어나면 힘들어집니다.

RBAC는 Role-Based Access Control의 약자입니다.

사람에게 직접 권한을 부여하는 것이 아니라, role에 권한을 부여합니다.

새로운 편집자가 늘어나면, 그 사람에게 ShopSubmitter role을 부여합니다.

tacos DB에서도 member와 role은 member_role을 통해 연결됩니다.

한 명의 member가 여러 개의 role을 가질 수 있는 방침입니다.

ACL보다는 관리하기 쉽지만, 역시 역할(role)이 늘어나면 관리가 힘들어질 것입니다.

ABAC는 Attribute-Based Access Control의 약자입니다.

사용자나 리소스의 속성 (attribute)을 보고 판정합니다.

예를 들어, 다음과 같은 판정입니다.

member.team 이 editor 이고, shop.status 가 draft 라면 조작할 수 있다

편리하지만, 방심하면 「결국 어디서 무엇을 판정하고 있었지?」가 됩니다.

ReBAC는 Relationship-Based Access Control의 약자입니다.

사용자와 리소스의 관계성 (relationship)을 보고 판정합니다.

Google Drive와 같이 「폴더에 권한이 있으면, 그 하위 파일에도 상속된다」는 이미지가 가깝습니다.

강력하지만, 구현은 무거워지기 쉽습니다.

작은 규모의 CMS에서 갑자기 ReBAC를 풀 구현하면, 관리에 불필요한 비용이 발생하게 됩니다.

PBAC는 Policy-Based Access Control의 약자입니다.

policy에 기반하여 「허가할지 여부」를 결정하는 사고방식입니다.

PBAC는 RBAC / ABAC / ReBAC와 완전히 별개라기보다, 그것들을 policy로서 정리하는 사고방식에 가깝습니다.

tacos DB에서는 role의 액세스 범위(access scope)를 role_access_scope.method와 role_access_scope.path_pattern으로 유지하고 있습니다.

CMS endpoint의 HTTP method와 path 문자열로 제어하는 방침입니다.

ER 다이어그램으로 나타내면 다음과 같습니다.

인가 (Authorization) 처리에서는, request의 method와 path를 정규화하고, member id로부터 access scopes를 가져옵니다.

그리고, method pattern과 path pattern이 모두 일치하면 허가합니다.

여기까지 구현하면, AI 작업자에게도 권한을 부여하기 쉬워집니다.

기사를 쓰는 AI에게는 writer.

점포 정보를 입고하는 AI에게는 submitter.

공개 설정을 보는 AI에게는 maintainer.

프롬프트로 "이것은 하지 마세요"라고 말하는 것도 중요합니다.

그 상태에서, AI가 다소 거칠게 동작하더라도, 권한이 없다면 endpoint를 호출할 수 없습니다.

endpoint를 호출할 수 있더라도, 도메인 규칙 (domain rule)에 어긋나면 유스케이스 (usecase) 단계에서 차단됩니다!

이로써 안심하고 AI에게 작업을 맡길 수 있겠네요!

인증 (Authentication)과 인가 (Authorization)는 다르며, 인가 모델에는 ACL / RBAC / ABAC / ReBAC / PBAC가 있습니다.

tacos DB에서는, RBAC를 기본으로 하면서, HTTP method + endpoint path pattern으로 scope를 관리하고 있습니다.

나아가, endpoint를 호출할 수 있는지와 그 대상을 조작해도 되는지를 분리하고 있습니다.

AI에게 무엇이든 부탁할 수 있는 시대이기에 더욱, AI에게 무엇이든 할 수 있는 권한을 주지 말고, 지금까지처럼 최소 권한의 원칙 (Principle of Least Privilege)을 따릅시다!

릴리스한 tacos DB는 아직 게재 점포 수를 늘려가는 중입니다.

점포 정보, 사진, 소개글을 제공해 주시는 분이나, 타코스를 좋아해서 함께 만들어 가실 분들을 모집하고 있습니다.

알고 있는 가게가 있다면, 꼭 문의 양식을 통해 게시해 주세요.