DAC·MAC·RBAC·ABAC 비교: 접근통제 모델의 선택 기준

1장 개념과 보호 목표#

접근통제 모델은 누가 어떤 자원에 어떤 행위를 할 수 있는지 정하는 규칙입니다. DAC는 소유자의 재량, MAC는 중앙 보안 등급과 정책, RBAC는 역할, ABAC는 주체·자원·행위·환경 속성을 기준으로 판단합니다.

2장 원리와 구분#

RBAC는 직무별 권한을 묶어 관리하기 좋지만 역할이 과도하게 늘어나면 운영이 복잡해집니다. ABAC는 소속, 문서 분류, 접속 기기와 시간 같은 조건을 결합할 수 있지만 속성의 신뢰성과 정책 충돌을 관리해야 합니다. RBAC의 계층·제약을 이용하면 권한 상속과 직무 분리를 표현할 수 있습니다.

직무 분리는 정적 제약과 동적 제약으로 나눌 수 있습니다. 정적 제약은 한 사람이 충돌하는 역할을 동시에 갖지 못하게 하고, 동적 제약은 같은 거래에서 작성과 승인 같은 행위를 함께 수행하지 못하게 합니다. 인사 변경과 일시적 대행에 따른 권한 갱신도 정책 테스트에 포함해야 합니다.

3장 비교와 판단 기준#

모델	판단 기준	주요 운영 과제
DAC	소유자의 접근 권한 부여	공유 확대·중앙 정책과의 결합
MAC	보안 등급·중앙 규칙	등급 관리·신뢰 주체
RBAC	역할과 권한	역할 폭증·상속·직무 분리
ABAC	주체·자원·환경 속성	속성 신뢰·정책 충돌·검증

4장 정책 변경 권한이 모델의 중요한 차이다#

접근통제는 누가 무엇을 할 수 있는지뿐 아니라 누가 그 허용을 바꿀 수 있는지를 정합니다. DAC의 소유자 재량, MAC의 강제 정책, RBAC의 역할, ABAC의 속성을 이 축으로 읽으면 이름을 외우는 것보다 실무 구성이 선명해집니다. 상위 제한과 여러 모델의 결합도 가능합니다.

flowchart TB
 P["접근 판단"] --> D["DAC: 소유자의 허용"]
 P --> M["MAC: 조직의 강제 정책"]
 P --> R["RBAC: 역할의 권한"]
 P --> A["ABAC: 속성과 맥락의 조건"]

5장 DAC에서 공유는 편리하지만 위임 범위를 관리한다#

문서 소유자가 다른 사용자에게 읽기 권한을 줄 수 있는 서비스는 DAC 관점으로 설명할 수 있습니다. 하지만 조직은 외부 공유·민감 등급·재공유·링크 만료를 제한할 수 있습니다. 소유자라는 이유로 회사의 모든 제한을 해제할 권한이 있는 것은 아닙니다.

공유 권한의 부여·회수·복사본·그룹 가입을 기록합니다. 링크 소유만으로 접근하는 기능과 지정 사용자 인증을 요구하는 기능은 다른 위험을 갖습니다. 실제 업무에 맞는 위임 범위를 선택합니다.

6장 MAC의 등급은 관리자 직급과 다르다#

조직의 정책으로 주체와 데이터의 보안 등급·범주를 관리합니다. 등급을 누가 부여하고 바꿀 수 있는지, 데이터가 다른 등급으로 이동하는 절차가 무엇인지 중요합니다. 단순한 관리자·일반 사용자 구분과 같다고 설명하지 않습니다.

등급이 있는 정책도 잘못된 라벨이나 신뢰 주체의 오류를 막는 추가 절차가 필요합니다. 정책이 어떤 정보 흐름을 제한하는지와 제품의 실제 집행 기능을 구분해 봅니다.

7장 RBAC에서 사용자·역할·권한의 관계#

사용자에게 역할을 부여하고 역할에 기능 권한을 연결하면 직무 변경에 대응하기 쉽습니다. 개별 계정마다 같은 권한을 반복하는 대신 역할을 관리합니다. 역할 계층과 직무 분리의 조건을 사용할 때는 어떤 권한이 합쳐지는지 확인합니다.

flowchart LR
 U["사용자"] --> R["청구 담당자 역할"]
 R --> P["청구서 조회·허용된 수정"]
 P --> O["대상 청구서의 조직·상태 검증"]

역할만으로 모든 객체 접근을 허용하면 다중 고객의 경계를 놓칠 수 있습니다. 기능 권한과 해당 객체의 소속·소유 조건을 결합합니다.

8장 역할 폭증이 생기는 상황#

고객사·국가·부서·등급별 조합을 전부 다른 역할로 만들면 수가 빠르게 늘 수 있습니다. 어떤 역할이 왜 존재하는지와 검토·회수의 책임이 흐려집니다. 안정된 직무는 역할로, 변하는 대상 조건은 속성으로 표현하는 결합을 검토합니다.

역할 수가 적다는 지표만으로 좋은 설계라고 판단하지 않습니다. 넓은 역할 하나로 묶어 불필요한 권한을 주는 문제도 있기 때문입니다. 정책이 필요한 업무 경계를 정확히 표현하는지가 중요합니다.

9장 ABAC의 네 가지 속성 축#

주체의 부서·역할, 자원의 조직·등급, 행위의 조회·수정, 환경의 시간·단말 상태 등을 조합할 수 있습니다. 각 속성이 어디에서 왔고 누가 갱신하는지 확인해야 합니다. 사용자가 요청 본문에 보낸 부서를 신뢰하는 신원 속성으로 쓰면 정책을 스스로 바꿀 수 있습니다.

속성	신뢰할 근거의 예	실패할 수 있는 조건
주체 조직	검증된 신원·계정 저장소	오래된 소속·조작된 요청
자원 조직	서버 저장소의 실제 자원	클라이언트의 임의 지정
단말 상태	관리 체계의 최근 신호	오래된 검사·누락
행위	서버가 해석한 요청 기능	경로·메서드 우회

10장 다중 고객의 청구서 접근 예제#

현재 사용자는 조직 A의 청구 담당자입니다. 청구서가 조직 B 소유라면 역할이 맞아도 거부해야 합니다. 객체의 조직을 서버에서 조회하고 신원의 조직과 대조합니다. 요청 URL에 A라고 썼다는 사실만으로 청구서의 실제 소속을 판단하지 않습니다.

조건 1: 사용자가 청구 담당자인가?
조건 2: 청구서가 같은 조직에 속하는가?
조건 3: 요청 행위와 필드를 허용하는가?
조건 4: 예외·만료·상태 조건을 충족하는가?

11장 기본 거부와 정책 충돌#

필요 속성이 없거나 판단할 수 없는 경우의 결과를 정합니다. 오류나 누락을 무제한 허용으로 바꾸는 경로를 피하고, 허용·거부 규칙이 충돌할 때 어떤 우선순위를 쓰는지 문서화합니다. 제품마다 해석 규칙이 다를 수 있습니다.

긴급 예외에는 대상·범위·승인자·만료·기록을 둡니다. 임시 허용이 정책 바깥의 영구 관리자 통로가 되지 않게 정기 검토와 회수를 수행합니다.

12장 정책 검증은 허용과 거부를 함께 시험한다#

정상 사용자·정상 조직·허용 행위는 성공해야 합니다. 다른 조직·회수 역할·누락 속성·만료 예외·다른 메서드는 기대한 대로 실패해야 합니다. 정책 캐시와 세션 때문에 변경이 늦게 반영되는지도 확인합니다.

판단 이유와 사용한 신뢰 속성을 조사할 수 있게 기록하되 비밀·민감정보를 과도하게 로그에 남기지 않습니다. 정책의 이름보다 실제 집행과 증거가 접근통제의 효과를 보여 줍니다.

13장 적용 사례와 운영 방법#

재무 담당자는 지급 요청을 작성하고 다른 승인자가 승인하도록 권한을 나눕니다. 관리자 역할이라도 민감 자료 접근은 별도 조건으로 제한할 수 있습니다. 권한을 UI 버튼에서 숨기는 데 그치지 말고 서버의 실제 요청 처리 지점에서 검증합니다.

14장 역할과 속성을 조합해 정책의 복잡도를 줄인다#

DAC는 소유자의 재량, MAC는 조직이 강제하는 보안 정책, RBAC는 역할과 권한, ABAC는 주체·자원·행위·환경 속성에 기반합니다. 모델을 선택할 때는 누가 정책을 바꿀 수 있는지와 판단에 어떤 정보가 필요한지부터 비교합니다. 하나의 서비스가 반드시 한 모델만 사용해야 하는 것은 아닙니다.

RBAC는 직무 중심의 권한을 설명하기 쉽지만 고객사·지역·데이터 등급마다 역할을 만들면 역할 수가 폭증할 수 있습니다. ABAC는 맥락을 표현하기 좋지만 속성의 출처·최신성·누락 처리와 정책 충돌을 통제해야 합니다. 관리자가 입력한 부서 정보와 사용자가 요청 본문에 넣은 부서 정보를 같은 신뢰 수준으로 사용해서는 안 됩니다.

15장 다중 고객 SaaS의 정책을 읽어 보기#

청구 담당자는 자기 조직의 청구서만 열람할 수 있다고 가정합니다. 역할은 청구 담당자, 자원 속성은 소속 조직, 환경 조건은 필요한 경우 관리 단말로 표현할 수 있습니다. 서버는 토큰의 신뢰할 수 있는 조직 정보와 실제 청구서의 조직을 비교합니다. 화면에서 버튼을 숨기는 작업은 서버 인가의 대체가 아닙니다.

정책 시험에는 허용 사례 외에 다른 조직·누락된 속성·퇴사 계정·만료된 예외를 포함합니다. 기본 거부, 예외 승인과 만료, 판단 이유의 기록을 함께 갖추면 감리와 장애 조사에서도 정책을 설명하기 쉬워집니다.

16장 적용 전 확인할 사항#

권한 부여·변경·회수 책임자를 정한다
기본 거부와 최소 권한을 적용한다
역할 상속·예외 정책·속성 변경을 테스트한다

17장 자주 묻는 질문#

RBAC와 ABAC를 함께 사용할 수 있나요?#

역할로 기본 권한을 정하고 속성으로 추가 조건을 평가하는 방식이 가능합니다. 두 정책의 결합 규칙과 거부 우선순위를 명확히 해야 합니다.

ABAC가 RBAC보다 항상 좋은가요?#

직무가 단순하고 안정적인 환경에서는 RBAC가 관리하기 쉬울 수 있습니다. 필요한 맥락과 정책 관리 능력에 맞춰 선택하거나 역할과 속성을 결합합니다.

소유자가 공유 권한을 줄 수 있으면 모든 권한을 바꿔도 되나요?#

DAC에도 조직의 상위 제한이 적용될 수 있습니다. 민감도·외부 공유·권한 위임 범위를 제한하고 변경 이력을 확인해야 합니다.