ABAC

속성 기반 접근 제어 모델

ABAC(Attribute-Based Access Control)는 사용자·리소스·환경 속성을 조합해서 접근 허용 여부를 판단하는 모델. RBAC보다 유연하지만 복잡하고, 실무에선 RBAC + ABAC 혼용이 많다.

RBAC
인가보안권한

개념

ABAC는 속성(attribute) 조합으로 접근을 판단하는 모델이다. "어떤 역할을 가졌는가"가 아니라 "어떤 속성을 만족하는가"가 기준이다. 사용자 속성, 리소스 속성, 환경 속성 등을 조건식으로 엮어서 허용/거부를 결정한다.

왜 필요한가

RBAC는 단순하지만 조건이 세밀해지면 역할이 폭발한다. "engineering 부서의 시니어가, 업무 시간 안에, 자기가 만든 리소스만 수정 가능"을 RBAC로 표현하려면 새 역할을 끝없이 찍어내야 한다. ABAC는 이런 조건을 속성 조합으로 직접 표현한다.

어떤 속성을 보나

  • 사용자 속성 — 부서, 직급, 소속 팀, 국적
  • 리소스 속성 — 소유자, 분류(public/internal/secret), 민감도
  • 환경 속성 — 시간, IP, 접속 위치, 디바이스 종류

예시

user.department == "engineering"
AND resource.owner == user.id
AND time.hour >= 9 AND time.hour <= 18
→ allow

세 가지 축을 모두 동시에 체크한다. RBAC로는 이 조건 하나만 해도 새 역할을 파야 하는데, ABAC는 정책 한 줄이면 끝난다.

RBAC vs ABAC

RBAC ABAC
기준 역할 속성 조합
복잡도 단순 복잡
유연성 낮음 높음
디버깅 역할만 보면 됨 조건식 추적 필요
적합한 경우 역할이 명확한 시스템 조건이 세밀한 시스템

대표 도구

  • OPA (Open Policy Agent) — Rego 언어로 속성 조합 정책 작성
  • AWS Cedar — AWS가 만든 정책 언어
  • XACML — 오래된 XML 기반 표준 (현업에선 거의 안 씀)

실무에서는

  • RBAC을 기본으로 쓰고, 세밀한 제어가 필요한 부분만 ABAC를 섞는 혼합이 흔함
  • "팀장 역할은 RBAC으로, 리소스 소유자 체크는 ABAC으로" 같은 분업

더 보기

  • RBAC — 역할 기반 모델
  • OPA — 정책을 앱 밖으로 빼는 엔진 (ABAC 구현에 자주 사용)
  • 멀티테넌트-RBAC-설계 — 테넌트 격리가 필요한 경우

Related

sunshinemoon · 2026