5. 접근제어 모델 정리

Access Control Models

Risk 노트에서 다룬 4개념(Asset/Threat/Vulnerability/Risk) 다음으로, “그래서 자산을 실제로 어떻게 보호하는가”의 가장 기본이 되는 접근제어 모델을 정리함

DAC (Discretionary Access Control, 임의적 접근제어)

Owner of a resource decides who else can access it (자원의 소유자가 다른 누가 접근할 수 있는지를 스스로 결정)

• 일반 파일시스템 권한(chmod, chown)이 대표 예시
• 유연하지만, 소유자가 실수로 권한을 잘못 주면 그대로 새어나간다는 약점

MAC (Mandatory Access Control, 강제적 접근제어)

Access decided by a central policy, not by the resource owner (자원 소유자가 아니라 중앙 정책이 접근 여부를 강제로 결정)

• 군사/정부 시스템에서 자주 쓰는 보안 등급(Confidential/Secret/Top Secret) 방식이 대표적
• 사용자가 아무리 원해도 정책이 허용하지 않으면 접근 불가 — DAC보다 훨씬 엄격

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

Permissions are assigned to roles, and users are assigned to roles (권한은 역할에 부여되고, 사용자는 그 역할에 배정됨)

• 실무에서 가장 흔히 쓰는 방식 “개발자”, “운영자”, “관리자” 같은 역할 단위로 권한 묶음을 관리
• AWS IAM의 역할(Role) 기반 정책도 이 사상과 맞닿아 있음

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

Access decided dynamically based on attributes (user, resource, environment, time…) (사용자, 자원, 환경, 시간 등 속성을 조합해 그때그때 동적으로 접근 여부 결정)

• “평일 9-6시에만, 사내 IP에서만, 본인 부서 문서만” 같은 세밀한 조건을 표현할 수 있음
• RBAC보다 유연하지만 정책이 복잡해질수록 관리·감사가 어려워짐

네 모델 비교 감각

모델	결정 주체	유연성	관리 복잡도
DAC	자원 소유자	높음	낮음 (그만큼 위험도 큼)
MAC	중앙 정책	낮음	중간
RBAC	역할 정의	중간	중간
ABAC	속성 조합	매우 높음	높음

RAG 문서 노트와의 연결

RAG 개념과 보안에서 다룬 “권한 불일치” 문제를 이 프레임으로 보면, 원본 문서의 접근제어가 보통 RBAC/ABAC인데 벡터DB로 색인하면서 그 모델이 그대로 안 옮겨가는 게 근본 원인임

더 생각해볼 것들

• 우리 조직 시스템 대부분이 RBAC일 텐데, ABAC이 꼭 필요해지는 시점은 언제일까
• DAC 기반 파일시스템 권한 실수가 실제 사고로 이어진 사례를 찾아서 왜 그랬는지 분석해보고 싶음

원본: Risk