🔐 정보 보안에서 **접근 제어(Access Control)**는 '누가(Who) 무엇을(What) 할 수 있는가'를 결정하는 핵심입니다. 수십 년간 사용되어 온 **역할 기반 접근 제어(RBAC)**는 편리했지만, 클라우드와 마이크로서비스 환경에서는 그 복잡성이 폭발적으로 증가하는 한계에 봉착했습니다. 제로 트러스트(Zero Trust) 환경은 **'절대 신뢰하지 않고, 항상 검증한다'**는 원칙을 내세우며, 접근 시점마다 사용자와 환경을 재평가할 것을 요구합니다. 이러한 동적인 요구사항에 최적화된 차세대 접근 제어 모델이 바로 **ABAC(Attribute-Based Access Control)**입니다. ABAC는 단순한 역할 대신, **다양한 속성(Attribute)**을 기반으로 접근을 결정하는 유연하고 정교한 방식입니다.
✨ 핵심 원리: '속성(Attribute)' 기반의 동적 의사 결정
ABAC는 주체(Subject), 객체(Object), 환경(Environment)의 **'속성'**을 기준으로 접근 요청을 평가하고 허용 여부를 동적으로 결정합니다. 이는 RBAC가 '역할'이라는 **정적인 셋(Set)**에 의존하는 것과 근본적으로 다릅니다.
- 속성 (Attribute): 🔑 ABAC의 핵심 구성 요소입니다. 다음 세 가지 범주로 나뉩니다.
- 주체 속성 (Subject Attributes): 접근을 시도하는 사용자나 서비스의 특성 (예: 사용자_소속=재무팀, 사용자_레벨=고급, 사용자_위치=사내망).
- 객체 속성 (Object Attributes): 접근하려는 자원(파일, 데이터베이스 테이블, API)의 특성 (예: 문서_분류=기밀, 데이터_소유자=팀A, API_민감도=높음).
- 환경 속성 (Environment Attributes): 접근이 발생하는 시점의 컨텍스트 (예: 시간대=업무시간, 접근_프로토콜=HTTPS, 네트워크_위치=미국_VPN).
- 정책 (Policy): 🔥 '만약(If) 주체의 속성이 이러하고 객체의 속성이 이러하며 환경 속성이 이러하다면, 접근을 허용/거부한다(Then)'는 형태로 정의된 규칙입니다. 이 정책은 동적으로 평가됩니다.
- Granularity (세분성): ABAC는 수많은 속성의 조합으로 정책을 정의할 수 있어, RBAC보다 훨씬 높은 수준의 세밀한 접근 제어가 가능합니다.

👉 관련 글: 클라우드 보안, 지금 주목받는 핵심 흐름 5가지
🔥 1. RBAC의 한계와 ABAC의 등장 배경
ABAC가 주목받게 된 것은 기존 접근 제어 방식이 현대 컴퓨팅 환경에 적합하지 않기 때문입니다.
- 역할 기반 접근 제어 (RBAC): 🔥 사용자에게 **'역할(Role)'**을 할당하고, 그 역할에 미리 정의된 **'권한(Permission)'**을 부여하는 방식입니다. (예: '회계팀원' 역할은 '재무 문서 읽기' 권한을 갖는다.)
- RBAC의 문제점: 클라우드 환경에서 역할의 수가 폭발적으로 증가합니다 (Role Explosion). 일시적인 조건이나 민감도에 따른 세밀한 제어가 어렵습니다. (예: "이사만 읽을 수 있는 문서"는 가능하지만, "이사 중에서 오후 5시 이후에만 접근 가능한 문서"는 구현이 복잡하거나 불가능합니다.)
- ABAC의 장점: 💡 RBAC의 역할(Role) 자체도 주체의 속성 중 하나로 간주하여 유연하게 포함할 수 있습니다. 정책 정의가 역할 할당보다 쉽고, 속성 값이 변경되면 권한이 자동으로 변경되므로 운영 부담이 줄어듭니다.
- ABAC의 단점: 초기 정책 설계가 복잡하고, 구현을 위해서는 속성 정보를 실시간으로 수집하고 평가할 수 있는 **강력한 정책 관리 시스템(Policy Decision Point)**이 필요합니다.

🧘 2. ABAC의 4대 핵심 구성 요소
ABAC 시스템은 정책을 정의하고 실제로 실행하는 네 가지 핵심 구성 요소(엔진)로 이루어집니다.
- PEP (Policy Enforcement Point): 🧘 접근 요청이 들어왔을 때, 이를 가로채서 접근 제어 여부를 결정해달라고 요청하는 강제 지점입니다. (예: API 게이트웨이, 웹 서버, 데이터베이스 프록시).
- PDP (Policy Decision Point): 🛡️ PEP로부터 요청을 받은 후, **정책(Policy)**과 **속성(Attribute)**을 평가하여 접근을 **허용(Permit)**할지 **거부(Deny)**할지 최종 결정을 내리는 두뇌입니다.
- PIP (Policy Information Point): 🌐 속성 데이터를 실시간으로 조회하여 PDP에 제공하는 정보 공급자입니다. (예: LDAP, Active Directory에서 사용자 속성 조회, 환경 센서에서 위치 정보 조회).
- PAP (Policy Administration Point): 📝 ABAC 정책을 작성, 배포, 관리하는 지점입니다. 정책 언어(XACML 등)를 사용하여 규칙을 정의하고 PDP에 전달합니다.

💪 3. 제로 트러스트(Zero Trust) 환경에서의 ABAC 활용
ABAC는 제로 트러스트 아키텍처의 핵심 제어 엔진으로 활용될 때 그 효과가 극대화됩니다.
- 지속적 검증: 💪 제로 트러스트는 단일 인증이 아닌 접근 시점마다 재검증을 요구합니다. ABAC는 매번 요청 시마다 **환경 속성(시간, 위치, 디바이스 상태)**을 실시간으로 PIP를 통해 받아 PDP에서 평가하므로, 이 지속적 검증 요구사항을 완벽히 충족합니다.
- 컨텍스트 기반 접근: 💡 "특정 사용자가 관리자가 승인한 최신 패치 상태의 디바이스를 사용하여 지정된 업무 시간에만 기밀 문서에 접근을 허용한다"와 같은 다차원적인 컨텍스트 기반 정책을 ABAC는 쉽게 구현합니다.
- 마이크로서비스(MSA) 환경 적용: ⚙️ MSA 환경에서는 수많은 API와 서비스 간의 통신이 발생합니다. ABAC는 각 API 호출에 대해 호출 주체(다른 서비스), 호출 API(객체), 호출 시간(환경) 등의 속성을 기반으로 정교하게 접근을 제어하여, 서비스 간의 측면 이동(Lateral Movement) 공격 위험을 줄입니다.


✅ 요약 및 실전 팁! 💯
| 🏠 모델 | 🚀 제어 기준 | 💡 핵심 역할 |
| RBAC | 역할(Role) | 정적이고 단순한 대규모 조직 관리에 용이 |
| ABAC | 속성(Attribute) | 주체, 객체, 환경 속성을 조합한 동적이고 세밀한 제어 |
| PEP | 정책 강제 지점 | 접근 요청을 가로채서 PDP에 전달 |
| PDP | 정책 결정 두뇌 | 속성과 정책을 평가하여 허용/거부 결정 |
| 제로 트러스트 | 지속적 검증 | ABAC를 활용하여 실시간 컨텍스트 기반 접근 제어 구현 |
📚 출처
- NIST(National Institute of Standards and Technology) ABAC 가이드라인: ABAC의 공식 정의, 구성 요소 및 구현 표준
- XACML(eXtensible Access Control Markup Language) 표준 문서: ABAC 정책 정의 언어 및 프로토콜
- 제로 트러스트 아키텍처(ZTA) 관련 보안 보고서: ABAC와 ZTA의 연관성 및 상호 보완적 역할 분석
ABAC는 단순한 기술 업그레이드를 넘어, 클라우드, 엣지, IoT 환경에서 보안 정책을 '코드'처럼 관리하고 실시간으로 변화하는 컨텍스트에 적응할 수 있게 해주는 차세대 접근 제어 패러다임입니다. 제로 트러스트 구현을 위한 필수 엔진으로서 그 중요성은 앞으로 더욱 커질 것입니다.
👉 함께 보면 도움되는 글: Kubernetes 클러스터 구성과 배포 자동화
Kubernetes 클러스터 구성과 배포 자동화: 대규모 컨테이너 오케스트레이션의 표준
Kubernetes(K8s) 클러스터의 핵심 아키텍처와 구성 요소를 심도 있게 분석합니다. Control Plane(etcd, API Server)과 Worker Node의 역할 분담, YAML 기반의 선언적 배포 자동화, Service 네트워킹 전략(Ingress), 그리
praymeyer2025.tistory.com
'💡 IT 핵심 지식 (Core) > 🔒사이버 보안' 카테고리의 다른 글
| 쿠키·세션·토큰의 보안 차이: 신분증과 보관함 (0) | 2025.12.11 |
|---|---|
| HTTPS는 왜 안전할까? 인증서·암호화 쉽게 정리 (0) | 2025.12.10 |
| OAuth2·JWT 인증 흐름 완전 분석: 현대 웹 서비스의 권한 및 인증 표준 (0) | 2025.11.09 |
| 대칭키 vs 비대칭키 암호화 쉽게 비교: '열쇠를 나누는 방법'의 차이 (0) | 2025.11.08 |
| 비밀번호 대신 쓰는 OTP·토큰 이해하기: '열쇠'를 넘어선 '임시 신분증' (0) | 2025.11.07 |