속성 기반 접근통제
더 많은 작업
- Attribute-Based Access Control, ABAC; 속성 기반 접근통제
- 주체·객체·행위·환경의 속성을 정책에 대입해 요청마다 허용 여부를 계산하는 접근통제 방식
RBAC는 "인사팀이면 급여 시스템을 본다"처럼 역할 하나로 권한을 정한다. 그런데 현실의 요구는 "인사팀이면서, 해당 지사 소속이고, 개인정보 교육을 이수했고, 회사 관리 기기로, 업무 시간에 접속할 때만"처럼 여러 조건이 겹친다. 이를 역할로만 표현하려면 조건 조합마다 역할을 만들어야 해서 역할 수가 폭발한다. ABAC는 조건을 역할로 미리 굳히지 않고, 요청이 들어올 때 속성 값을 모아 정책을 평가한다. NIST는 SP 800-162(2014, 2019년 개정 반영)에서 ABAC의 정의와 고려 사항을 정리했다.
| 속성 범주 | 의미 | 예 |
|---|---|---|
| 주체(subject) 속성 | 접근을 요청하는 사람·프로세스의 특성 | 부서, 직급, 보안 인가 등급, 교육 이수 여부, 국적 |
| 객체(object·resource) 속성 | 보호 대상의 특성 | 데이터 분류 등급, 소유 부서, 프로젝트명, 생성일 |
| 행위(action) | 요청하는 작업 | 읽기, 쓰기, 삭제, 승인, 다운로드 |
| 환경(environment) 조건 | 주체·객체와 무관하게 요청 시점에 바뀌는 상황 | 시각, 위치, 위협 수준, 기기 보안 상태 |
NIST SP 800-162는 환경 조건의 예로 시각, 위치, 위협 수준을 들며, 정책은 보통 보호할 객체의 관점에서 작성한다고 설명한다.
| 자연어 정책 | 평가식 |
|---|---|
| 의료진은 자기 진료과 환자의 기록만, 병원 내부망에서 읽을 수 있다. | 주체.직종 = 의사 AND 주체.진료과 = 객체.진료과 AND 행위 = 읽기 AND 환경.네트워크 = 내부 |
| 기밀 문서는 인가 등급이 같거나 높은 정규직만 근무 시간에 내려받을 수 있다. | 주체.등급 ≥ 객체.등급 AND 주체.고용형태 = 정규직 AND 행위 = 다운로드 AND 환경.시각 ∈ 근무시간 |
| 프로젝트 태그가 같은 저장소만 접근한다. | 주체.프로젝트 = 객체.태그.Project |
XACML(eXtensible Access Control Markup Language)은 OASIS가 만든 XML 기반 정책 언어이자 처리 모델로, ABAC 구현의 대표 표준이다. 정책 집행 구성 요소를 네 지점으로 나눈다.
| 구성 요소 | 역할(NIST SP 800-162 정의 요약) |
|---|---|
| PAP(Policy Administration Point, 정책 관리 지점) | 정책을 만들고, 관리하고, 시험하고, 저장소에 저장하는 인터페이스 |
| PDP(Policy Decision Point, 정책 결정 지점) | 적용할 정책을 평가해 허용·거부를 계산한다. 정책끼리 충돌하면 메타 정책에 따라 조정한다. |
| PEP(Policy Enforcement Point, 정책 집행 지점) | 주체의 요청을 가로채 PDP에 묻고, 결정을 실제로 집행한다. |
| PIP(Policy Information Point, 정책 정보 지점) | PDP가 판단에 필요한 속성 값을 가져오는 출처(인사 DB, 디렉터리, 자산 DB, 기기 관리 시스템) |
이 밖에 속성을 모으고 처리 순서를 조정하는 컨텍스트 핸들러(context handler)가 있다. 요청 흐름과 제로 트러스트 아키텍처의 대응 관계는 정책 결정 지점 문서에서 자세히 다룬다.
| 구분 | RBAC | ABAC |
|---|---|---|
| 표현력 | 역할 하나로 결정. 여러 조건 조합은 역할을 늘려야 함 | 속성 조합으로 세밀한 조건 표현 |
| 역할 폭증(role explosion) | 생기기 쉬움 | 해결. 조건을 역할로 만들 필요 없음 |
| 사전 등록 | 대상 시스템에 사용자·역할을 미리 등록해야 함 | 속성만 공유되면 처음 보는 주체도 평가 가능(조직 간 공유에 유리) |
| 동적 조건 | 시간·위치 반영이 어려움 | 환경 조건으로 자연스럽게 반영 |
| 감사·검토 | "이 사람이 무엇에 접근 가능한가"를 역할 목록으로 쉽게 답함 | 속성과 정책을 모두 계산해야 답할 수 있어 검토가 어려움 |
| 구현 부담 | 낮음 | 속성 정의·품질 관리, 정책 작성·시험, 성능 부담이 큼 |
NIST SP 800-162도 RBAC가 위치나 교육 이수 같은 다중 조건 결정을 쉽게 지원하지 못해 소수 인원짜리 임시 역할을 양산하게 되는 현상을 역할 폭증이라 부른다. 반면 ABAC는 속성 값이 틀리거나 오래되면 결정도 틀린다. 속성을 누가 관리하고 얼마나 믿을 수 있는지가 ABAC 성패를 가른다. 실무에서는 RBAC로 큰 틀을 잡고 ABAC 조건으로 좁히는 혼합 방식이 흔하다.
클라우드 IAM은 자원에 붙인 태그와 주체의 속성을 비교하는 조건을 지원해 ABAC를 구현한다. 마이크로소프트 Azure ABAC는 Azure RBAC 역할 할당에 속성 조건을 덧붙이는 방식으로, 예를 들어 "Project=Cascade 태그가 붙은 블롭만 읽기 허용" 같은 조건을 건다. 이렇게 하면 프로젝트마다 역할을 새로 만들지 않고 태그만 붙여 권한 범위를 나눌 수 있다. 단, 태그를 바꿀 수 있는 권한이 곧 접근 범위를 바꿀 수 있는 권한이 되므로 태그 수정 권한을 엄격히 통제해야 한다.
- 주체·객체·행위·환경 속성으로 판단하면 ABAC이다. 시간·위치 조건이 사람별 속성과 섞여 나오면 ABAC를 고른다.
- 역할 폭증 문제의 해결책으로 ABAC가 나온다.
- PDP는 결정, PEP는 집행, PIP는 속성 제공, PAP는 정책 관리이다. 순서와 역할을 바꿔 묻는 문제가 많다.
- ABAC의 약점은 복잡성과 속성 품질 의존, 그리고 "누가 무엇에 접근할 수 있는가" 검토가 어렵다는 점이다.
- 클라우드 태그 기반 정책에서는 태그 수정 권한이 사실상 접근 권한이다.