# 작성 배경
최근에 권한관리 체계에 대한 조사를 할 일이 있어 어떻게 권한관리를 하면 좋을지 방법적인 부분에 대해서 조사해본 내용을 개인적인 흐름에 따라 풀어보고자 글을 작성하게되었는데 이 글은 다음의 사람들을 위한 글입니다.
1. 아직 RBAC / ABAC 같은 용어를 접해보지 않았다면 그런 사람들을 위한 똑같은 초심자 입장에서의 정리
2. Open Fga에 대한 간략한 소개
#목차
1. RBAC에서 ReBAC을 접하기 까지
2. RBAC 표준
3. Open FGA
1. RBAC(Role-Based Access Control) 에서 ReBAC(Relation-Based Access Control)을 접하기 까지
1-1) RBAC (역할기반)
누가 어떤 리소스에 접근할 수 있는지를 체계적으로 제어하기 위해 권한관리 시스템이 필요해지는데 가장 흔하게 접할 수 있는 것이 RBAC입니다.
특별히 권한관리에 대해서 어떤 방법론을 찾아보지 않았어도
"아 , 권한관리? 구현해봐야겠다"
라고 생각해서 구현하게 되면 자연히 구현되는 방식이 딱 RBAC일 것이고 RBAC라고 굳이 명명하지 않아도 흔히 접할 수 있는 방식이 RBAC 일 것입니다.
핵심 컨셉은 다음과 같습니다
"역할에 따라 유저에게 권한을 준다. "
여러가지 권한관리에 대한 용어는 정말 많지만 이 글에선 권한관리에 대한 시작점과 기초를 RBAC로 하고자 합니다.
RBAC의 기본 구성 요소
- User(사용자): 시스템을 이용하는 주체
- Role(역할): 특정 작업 범위를 정의한 집합 예: 관리자, 일반 사용자, 에디터 등
- Permission(권한): 특정 리소스에 대해 수행할 수 있는 행위 예: article:read, article:edit
- Resource(자원): 접근 대상이 되는 실제 리소스 예: 문서, 게시글, API 엔드포인트 등
RBAC의 한계는 결국 수 많은 분기문(역할 폭발) 이 일어나서 관리에 어려움이 있다는 점입니다.
처음 => if 관리자?
나중 => If 팀장 인데 어디어디 팀장이고 어쩌고 저쩌고 이런 케이스가 엄청나게 많아짐
1-2) RBAC => ABAC
RBAC를 접하고 나서 본격적으로 권한관리 방법에 대해서 찾아보다가 자연히 생각하게 된건 "큰 곳은 어떻게 관리하지?" 였습니다.
그래서 바로 생각해본게 AWS 의 IAM 관리 방식이였고 거기서 접하게 된 키워드가 ABAC 였는데,
ABAC은 더 유연하게 누가, 무엇에, 어떤 상황에서, 어떤 조건으로 접근할 수 있는지를 정의하게 됩니다.
ABAC가 가지는 RBAC보다 나은 이점
- 확장 : 새로운 리소스에 액세스 시키기위해 기존 정책을 업데이트 할 필요가없음 (ABAC는 정책을 사람이나 리소스에 붙은 "속성"으로 제어하기 때문에 속성값만 일치하면 됨)
- 게임(LOL)으로 비유하자면 RBAC에서는 탑 라인에는 탑에서 사용하는 챔피언만 갈 수 있다 라고 한다면 ABAC에서는 탑 라인이라는 태그를 만들어두면 앞으로 새로운 챔피언이 나오면 탑 라인이라는 태그만 추가하면됨
- 정책 수 : 정책을 잘 만들어두면 추후에 각 직무에 대한 서로 다른 정책을 생성할 필요가없어서 정책수가 적어짐
- 동적 대응 : 이미 어떤 경우에 대한 정책을 만들어 두었다면 거기에 새로운 프로젝트를 넣는건 굉장히 쉬움
- 추가로 AWS에서 설명하는 ABAC 문서도 첨부합니다
ABAC 권한 부여를 통한 속성 기반 권한 정의 - AWS Identity and Access Management
ABAC 권한 부여를 통한 속성 기반 권한 정의 ABAC(속성 기반 액세스 제어)는 속성을 기준으로 권한을 정의하는 권한 부여 전략입니다. AWS에서는 이 속성을 태그라고 합니다. IAM 엔터티(IAM 사용자 또
docs.aws.amazon.com
1-3) ABAC => ReBAC (* ABAC => ReBAC이라고 표현해놓았지만 제가 접한 개념의 흐름이지 상관관계를 의미하는건 아닙니다! )
ReBAC은 관계 기반 권한 정책으로 가장 마지막에 접한 개념이기도 합니다!
ReBAC의 경우는 RBAC에서 ABAC로 넘어갈때처럼 어라 다음거가 있을거 같은데? 해서 생각해본게 아니고 링크드인에서 접한
라는 당근 테크 블로그 글에서 접하게 된 키워드였습니다.
권한관리방법 이 어떤식으로 진화해와서 어떤 걸 사용하는지에 대한 흐름이 잘 정리되어있는 글이라 생각합니다.
구글의 Zanzibar (Google이 자사 모든 서비스Google Docs, YouTube, Drive 등 의 권한 관리를 위해 만든 전 세계적 분산 권한 시스템) 역시 ReBAC을 기초로 하고 있으며 관계 기반으로 권한을 관리합니다.
이미지를 보면 명확할 것 같아 zanzibar.academy에서 제공하는 예시 이미지를 첨부합니다.
Zanzibar: A Global Authorization System - Presented by Auth0
Zanzibar handles authorization for all of Google’s products, allows teams to specify their unique authorization models, globally replicates authorization data, and responds to access checks blazing fast.
zanzibar.academy
ReBAC의 핵심
- 표현력 : 지금까지 살펴본 RBAC / ABAC 중에서 관계에 대한 가장 풍부한 표현력을 가짐
- 관계(Relationship): 주체와 객체 사이의 연결
예: owner, member, shared_with, parent, manager_of, colleague_of - 정책(Policy): 관계 기반으로 정의된 접근 허용 규칙
- 그래프 구조: 모든 관계는 그래프 형태로 구성되어, 트래버싱(relationship traversal)이 가능
2. RBAC 표준
NIST 라는 곳을 아시나요? 저는 이번에 RBAC에 대해서 찾아보면서 처음 접했습니다.
미국 국가표준기술연구소(NIST)인데요
"The NIST Model for Role-Based Access Control: Towards A Unifed Standard" 라는 논문을 통해 RBAC 표준과 레벨에 대해 명세합니다. (논문 링크 : https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=916402 )
논문에 따르면 RBAC 레벨 1~4까지 나와있는데
1~4레벨의 명세는 대략 다음과 같습니다.
Level 1: 플랫 RBAC (Flat RBAC) 가장 기본적인 RBAC 형태입니다. 사용자는 역할을 통해 권한을 얻습니다. 사용자-역할, 권한-역할 할당은 다대다(many-to-many) 관계를 지원해야 합니다. (한 사용자가 여러 역할, 한 역할에 여러 사용자 가능) 사용자-역할 검토 기능이 필요합니다. (특정 사용자의 역할 확인, 특정 역할의 사용자 확인) 사용자는 동시에 여러 역할의 권한을 사용할 수 있어야 합니다. (한 번에 한 역할만 활성화하는 방식은 제외)
Level 2: 계층형 RBAC (Hierarchical RBAC) 플랫 RBAC 기능에 더해 역할 계층 구조 지원이 추가됩니다. 역할 간의 상하 관계(상속 관계)를 정의합니다. (예: '팀장' 역할은 '팀원' 역할의 모든 권한을 포함) 수학적으로 부분 순서(partial order) 관계를 따릅니다. 일반 계층(General): 임의의 복잡한 계층 구조 지원 (Level 2a) 제한된 계층(Limited): 트리(Tree)나 역트리(Inverted Tree) 같은 단순 구조만 지원 (Level 2b)
Level 3: 제약된 RBAC (Constrained RBAC) 계층형 RBAC 기능에 더해 직무 분리(Separation of Duty, SOD) 제약 조건 시행이 추가됩니다. SOD는 한 사람이 너무 많은 권한을 갖거나 이해 상충이 발생하는 것을 막기 위한 중요한 보안 원칙입니다. (예: 구매 요청 역할과 구매 승인 역할을 한 사람이 동시에 가질 수 없도록 제한)
Level 4: 대칭적 RBAC (Symmetric RBAC) 제약된 RBAC 기능에 더해 권한-역할 검토 기능이 추가됩니다. (Level 1의 사용자-역할 검토와 대칭) 특정 권한이 어떤 역할에 할당되었는지, 특정 역할이 어떤 권한을 가지고 있는지 효율적으로 검토할 수 있어야 합니다. 이 검토 기능의 성능은 사용자-역할 검토와 비슷해야 합니다.
3. Open FGA
Fine-Grained Authorization | OpenFGA
Relationship-based access control made fast, scalable, and easy to use.
openfga.dev
https://www.cncf.io/projects/openfga/
OpenFGA
Presented by: Infosys November 7, 2024 566 views
www.cncf.io
마지막으로 어짜피 RBAC에서 시작하면 동일한 문제로 ABAC로 갈것이고 , 나중엔 ReBAC이 될거 같은데 이에 대한 도움을 받을 수 있는 도구는 없을까? 하고 생각해보게 되었는데 거기에서 발견하게된게 OpenFga였습니다.
CNCF라는 곳을 아시나요?
저는 쿠버네티스는 알았어도 CNCF는 이번에 처음 들어봤습니다.
CNCF(Cloud Native Computing Foundation)는 클라우드 네이티브 기술의 발전과 확산을 목표로 하는 비영리 재단으로. 리눅스 재단(The Linux Foundation) 산하에 있다고 합니다.
"클라우드 네이티브 컴퓨팅을 보편적이고 지속 가능하게 만드는 것"이 이들이 가지고 있는 핵심 목표중 하나로 이 재단에서 쿠버네티스나 프로메테우스 등의 오픈 클라우드 네이티브 생태계를 지속적으로 지원하고 관리한다고 하네요
Open FGA역시 여기에 속해있으며 구글의 Zanzibar에 영감을 받았다고 합니다.
서버형 서비스로 도커로 풀(pull)받아서 띄우고 사용하게 되면
이런 프론트 화면을 통해 정책을 정의하고 Assertions을 넣어서 어떤식으로 권한을 가지고 있는지 등의 검토도 가능합니다.
Open FGA를 사용하면 얻게 되는 이점은 다음과 같습니다.
1. 개발 생산성 향상: 개발자는 복잡한 권한 로직 구현에 신경 쓰는 대신, OpenFGA SDK를 사용하여 간단한 API 호출(check, listObjects 등)만으로 권한 검사를 수행할 수 있습니다. 핵심 비즈니스 로직 개발, 정책 정의에만 신경쓸 수 있습니다.
2. 중앙 집중식 권한 관리
여러가지 프로젝트 들을 Open FGA 를 통해 중앙 시스템으로 분리시키고 거기에서 집중 관리할 수 있습니다.
3. 확장성
구글의 Zanzibar를 기반으로 만들어져있으며 Zanzibar는 ReBAC을 기초로하니 추후의 확장성에도 용이합니다.
4. 검토
RBAC표준의 레벨 4에 해당하는 내용중 하나가 검토인데 API 기능을 통해 List의 권한을 조회하거나 스크린샷과 같이 시각적으로도 활용이 가능합니다.
https://play.fga.dev/sandbox/?store=github
Auth0 Fine-Grained Authorization
play.fga.dev
스크린샷에 나오는 부분들을 해보고 싶다면 해당 링크에서 이것저것 만져볼수있습니다.
물론 처음부터 고생하면서 만들고 진화시켜나아가는 것도 좋은 경험이겠지만 잘 만들어져있는 오픈소스를 사용하고 공부하면서 설계에 대한 직 간접적인 인사이트를 얻을 수 있지 않을까 생각합니다.
부디 인증 인가, 권한관리와 관련해서 비슷한 고민을 하거나 찾아보고 있는 분들에게 개략적으로 이런것들이 있으니 이걸 더 파봐야겠다 하는 선택으로 넘어가기전에 간단하게 볼 수 있는 키워드 묶음 글이 되었으면 하는 바램입니다.