infiltr8 Lab

RBAC·ABAC·ACL 접근제어 모델 비교 분석

2026-10-08 · ##인증·인가 ##접근제어-개념

이 글은 공개된 1차 자료(NIST 표준·용어집)와 독립 분석 글을 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장·표를 그대로 옮기지 않았으며, 정확한 정의 문구는 하단 References의 원문을 직접 확인하세요.

Security · 인증·인가 · 접근제어 개념 [정보성]

접근제어 사고가 어긋나는 자리는 대개 모델 자체가 아니라 “권한을 무엇에 묶느냐”의 선택입니다. 자원에 직접 묶으면 세밀하지만 자원이 늘수록 관리가 무너지고, 역할에 묶으면 깔끔하지만 조건이 많아지면 역할이 폭발하며, 속성에 묶으면 유연하지만 정책이 복잡해집니다. 세 모델의 차이를 알면 “우리 환경에는 어느 조합이 맞는가”를 설계 목표인 최소권한에 맞춰 고를 수 있습니다. 이 글은 그 판단의 바탕이 되는 확립된 정의를 정리한 교과서적 정리본입니다.

세 모델의 핵심 — 권한을 어디에 붙이는가

ACL (접근제어 목록, Access Control List)

ACL은 자원마다 “누가 어떤 접근 모드로 들어올 수 있는지”를 열거하는 목록입니다. NIST 용어집은 RFC 4949를 인용해, 자원에 접근이 허용된 시스템 개체를 열거하고 각 개체에 부여된 접근 모드를 명시하는 방식으로 접근제어를 구현하는 메커니즘이라고 정의합니다. 파일·폴더·데이터베이스·네트워크 자원 같은 자원 단위로 개별 사용자나 그룹에 권한을 직접 붙입니다.

장점은 세밀함(fine-grained)입니다. 자원 하나하나에 정확히 누가 접근하는지 지정할 수 있습니다. 단점은 확장성입니다. 자원이 수천 개로 늘면 관리해야 할 접근 항목이 수만 개로 불어나 유지보수 부담이 급증합니다.

RBAC (역할 기반 접근제어, Role-Based Access Control)

RBAC에서 권한은 역할(role)에만 연결되고, 사용자는 역할을 배정받음으로써(또는 역할 계층을 통해 상속함으로써) 권한을 얻습니다. NIST는 역할을 본질적으로 권한의 묶음이라고 설명하며, 사용자는 오직 역할을 통해서만 권한을 받는다고 정리합니다.

RBAC에는 세 가지 기본 규칙이 있습니다.

  1. 역할 배정(Role assignment) — 활성화된 역할이 있어야 트랜잭션을 실행할 수 있습니다.
  2. 역할 인가(Role authorization) — 사용자는 자신에게 인가된 역할만 활성화할 수 있습니다.
  3. 트랜잭션 인가(Transaction authorization) — 활성 역할이 허용한 트랜잭션만 실행할 수 있습니다.

여기서 역할(role)은 그룹(group)과 다릅니다. 그룹은 권한의 묶음이 아니라 사용자의 묶음입니다. RBAC는 권한을 역할에 연결하고, 세션(session) 개념을 통해 사용자가 배정받은 역할 중 일부만 활성화할 수 있게 합니다. 이 세션 개념은 전통적인 그룹에는 없는 특징입니다.

RBAC의 대표적 약점은 “역할 폭발(role explosion)“입니다. 접근 권한이 지역·테넌트·디바이스·고객 등급 같은 조건에 의존하기 시작하면, 조건 조합마다 역할을 새로 만들어야 하므로 역할 수가 관리 불가능하게 늘어납니다. 그래서 RBAC는 직무가 안정적이고 잘 정의된 내부 도구나 엔터프라이즈 관리자 패널처럼 사용자군이 예측 가능한 환경에 잘 맞습니다.

ABAC (속성 기반 접근제어, Attribute-Based Access Control)

ABAC는 속성(attribute)을 정책에 대조해 접근을 판단합니다. NIST SP 800-162(2014년 ITL Bulletin으로 요지 공개)는 ABAC를, 주체·객체·요청 연산과 (경우에 따라) 환경 조건에 연결된 속성들을 정책·규칙·관계에 대조해 일련의 연산 수행 인가를 결정하는 논리적 접근제어 방법론으로 정의합니다.

속성은 다음 범주로 나뉩니다.

  • 주체(subject) 속성 — 접근을 요청하는 사용자·프로세스의 특성.
  • 객체/자원(object) 속성 — 접근 대상의 특성.
  • 요청 연산(operation) 속성 — 수행하려는 동작의 특성.
  • 환경 조건(environment conditions) — 시각·위치·디바이스 상태 등 상황에 따라 선택적으로 평가됩니다. NIST 정의는 이를 “경우에 따라(in some cases)“로 두므로, 항상 필수인 동급 속성이라기보다 상황에 따라 더해지는 요소로 이해하는 편이 정확합니다.

ABAC의 강점은 새 역할을 만들지 않고도 조건부 접근을 자연스럽게 다룬다는 점입니다. 멀티테넌트·파트너 생태계·규제 환경·지역 기반 제한에 잘 맞습니다. 약점은 정책이 논리식으로 커지면서 복잡해지고 디버깅이 어려워진다는 점으로, 그만큼 더 나은 정책 관리 도구가 필요합니다.

granularity 스펙트럼과 조합

세 모델은 세밀함과 확장성을 다른 지점에서 교환합니다.

  • ACL — 자원 단위로 가장 세밀하지만 자원이 많아지면 확장성이 떨어집니다.
  • RBAC — 역할 단위라 표준화가 쉽지만 조건이 많아지면 역할이 폭발합니다.
  • ABAC — 가장 유연하고 동적이지만 복잡도라는 비용을 치릅니다.

실무에서 성숙한 시스템은 한 모델만 고르지 않고 여러 모델을 층층이 조합하는 경우가 많습니다. 한 독립 분석은 이를 “RBAC가 넓은 권한 범위를 정의하고, ABAC가 그 경계 조건을 정의한다”는 식으로 설명합니다. 즉 RBAC로 역할의 넓은 권한을 잡고, ABAC나 ACL로 세밀한 경계와 예외를 처리하는 다층 구조입니다.

RBAC 표준의 구성요소 (명명 주의)

RBAC는 2004년 INCITS 359-2004로 표준화됐습니다. 이 표준은 네 가지 구성요소로 이루어집니다.

  • Core RBAC — 최소 요소 집합.
  • Hierarchical RBAC — 역할 계층(상위 역할이 하위 역할의 권한을 상속).
  • Static Separation of Duty(SSD, 정적 직무분리) — 사용자-역할 배정 단계의 제약.
  • Dynamic Separation of Duty(DSD, 동적 직무분리) — 한 세션 내 활성 역할에 대한 제약.

⚠️명명 주의: 2000년에 발표된 통합 표준 제안 논문은 RBAC를 flat·hierarchical·constrained·symmetric이라는 누적적 “레벨(levels)“로 서술한 반면, 최종 INCITS 359-2004 표준과 NIST FAQ는 위의 Core·Hierarchical·SSD·DSD “구성요소(components)“로 제시합니다. 둘 다 “네 가지”라는 수는 같지만 가리키는 항목이 다르므로, 어느 판본을 말하는지 구분하는 편이 안전합니다. 이 글의 네 항목은 INCITS 359-2004 표준 기준입니다.

참고로 RBAC의 계보는 Ferraiolo와 Kuhn이 1992년 범용 RBAC 모델을 처음 제안한 데서 시작해, 1995년 Ferraiolo·Cugini·Kuhn의 확장을 거쳐, 2000년 Sandhu·Ferraiolo·Kuhn이 단일 표준을 향한 통합안을 내놓았고, 2004년 INCITS 359-2004로 채택되는 흐름입니다.

최소권한 — 모델이 아니라 설계 목표

최소권한(Principle of Least Privilege)은 특정 접근제어 모델이 아니라, 세 모델 모두가 지향하는 설계 목표입니다.

정의는 1차 자료에 따라 표현이 조금 다르며, 둘 다 정본으로 취급됩니다.

  • CNSSI 4009-2022 / NIST SP 800-12 Rev.1 판본은 사용자(또는 사용자를 대신하는 프로세스)의 접근 권한을 배정된 작업 수행에 필요한 최소한으로 제한하는 보안 원칙이라고 정의합니다.
  • NIST SP 800-53 Rev.5(및 SP 800-171 Rev.3) 판본은 각 개체가 자신의 기능 수행에 필요한 최소한의 시스템 자원과 인가만 받도록 보안 아키텍처를 설계하는 원칙이라고 정의합니다.

NIST SP 800-53 Rev.5의 통제 조문 AC-6(Least Privilege)은 조직이 배정한 업무 수행에 필요한, 인가된 접근만 허용하도록 최소권한 원칙을 적용하라고 규정합니다. 여기서 핵심은 최소권한이 사용자뿐 아니라 프로세스에도 적용된다는 점입니다. 사용자를 대신해 동작하는 프로세스도 임무·업무에 필요한 수준보다 높은 권한으로 돌아가지 않아야 하며, 이 원칙은 개발·구현·운영 전 단계에 걸쳐 적용됩니다.

세 모델에서 최소권한이 적용되는 지점은 다음과 같이 정리됩니다. 이는 AC-6 조문과 각 모델 정의를 종합한 해석입니다.

  • ACL — 자원별 권한을 꼭 필요한 주체와 접근 모드로만 한정합니다.
  • RBAC — 역할을 최소 권한 묶음으로 설계하고, SSD/DSD(직무분리)로 한 사용자가 과도한 권한을 축적하는 것을 막습니다.
  • ABAC — 속성과 환경 조건으로 접근 경계를 동적으로 좁힙니다.

결론 — 남는 교훈

세 모델은 “권한을 무엇에 묶느냐”라는 한 가지 질문에 대한 서로 다른 답입니다. ACL은 자원에, RBAC는 역할에, ABAC는 속성에 묶습니다. 어느 하나가 항상 우월한 것이 아니라, 환경의 세밀함 요구와 확장성 요구가 교차하는 지점에서 선택이 갈립니다. 그리고 어떤 모델을 고르든 그 위에 얹히는 공통 목표는 최소권한입니다. 모델은 도구이고 최소권한은 그 도구로 달성하려는 방향이라는 점 — 이 구분이 접근제어 설계에서 반복해서 쓰이는 사고방식입니다.

References / 참고자료

  1. NIST CSRC, “Role Based Access Control FAQs” — RBAC 정의·기본 규칙·역할 대 그룹·구성요소·계보의 1차 근거. https://csrc.nist.gov/Projects/role-based-access-control/faqs
  2. Vincent Hu 외, NIST, “Attribute Based Access Control (ABAC) Definition and Considerations” (ITL Bulletin, 2014-03; SP 800-162 요지) — ABAC 정의와 속성 범주. https://csrc.nist.gov/pubs/itlb/2014/03/attribute-based-access-control-abac-definition-and/final
  3. NIST CSRC Glossary, “least privilege” — 최소권한의 두 정본 정의(사용자·프로세스 판본=CNSSI 4009-2022·SP 800-12r1 / 아키텍처·각 개체 판본=SP 800-53r5·SP 800-171r3). https://csrc.nist.gov/glossary/term/least_privilege
  4. NIST CSRC Glossary, “access control list” — RFC 4949 기반 ACL 정의. https://csrc.nist.gov/glossary/term/access_control_list
  5. NIST SP 800-53 Rev.5, “AC-6 Least Privilege”(STIG Viewer 미러) — 최소권한 통제 조문과 프로세스 적용. https://www.stigviewer.com/controls/nist-800-53/AC-6
  6. Sandhu·Ferraiolo·Kuhn, NIST, “The NIST Model for Role-Based Access Control: Towards A Unified Standard” — RBAC 계보와 레벨 명명의 근거. https://www.nist.gov/publications/nist-model-role-based-access-control-towards-unified-standard
  7. Kundan Singh, Security Boulevard/LoginRadius, “RBAC vs ABAC vs PBAC vs ACL vs DAC” — 모델별 강약점·역할 폭발·ABAC 복잡도·조합 전략. https://securityboulevard.com/2026/02/rbac-vs-abac-vs-pbac-vs-acl-vs-dac/
  8. WorkOS, “RBAC vs ACL” — granularity와 관리 트레이드오프·사용 시점. https://workos.com/blog/rbac-vs-acl

이 글은 위 공개 자료를 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장·표를 그대로 옮기지 않았으며, 정확한 정의 문구와 세부 사항은 원문을 참고하세요.