[컴퓨터보안] 6. 접근 제어

1. 접근 제어 개념과 정책

접근 제어(Access Control)

어떤 주체가 어떤 자원에 어떤 작업을 수행할 수 있는지를 정책에 따라 판단하고, 허용되지 않은 접근을 차단하는 기능이다

예를 들어 성적 관리 시스템에서 학생은 자신의 성적을 조회할 수 있지만, 성적을 수정하는 작업은 허용되지 않을 수 있다

접근 제어에서는 단순히 시스템에 들어올 수 있는지만 확인하는 것이 아니라, 개별 자원에 대해 허용할 작업을 구분한다

1.1 인증, 인가, 집행의 구분

앞에서 정리한 사용자 인증은 접근 제어에 필요한 신원을 확인하는 역할을 한다. 접근 제어에서는 여기에 정책과 집행 방식을 구분하여 이해해야 한다

구분	핵심 질문	예시
인증(Authentication)	누구인가?	비밀번호로 Alice의 신원을 확인한다
인가(Authorization)	무엇을 할 수 있는가?	Alice에게 보고서 읽기를 허용한다
집행 메커니즘(Enforcement Mechanism)	정책을 어떻게 적용하는가?	파일 접근 요청을 검사하고 쓰기를 차단한다

1.1.1 정책과 메커니즘

접근 제어 정책(Access Control Policy)

어떤 접근을 허용하거나 거부할지 정하는 규칙과 기준이다

집행 메커니즘(Enforcement Mechanism)

접근 요청에 정책을 적용하여 실제로 접근을 허용하거나 차단하는 수단이다

예를 들어 “학생은 성적을 수정할 수 없다”는 정책이고, 학생의 수정 요청을 검사하여 거부하는 프로그램은 집행 메커니즘이다

1.2 접근 제어와 다른 보안 기능의 관계

접근 제어는 인증, 권한 정보 관리, 감사와 연결된다

기능	역할
인증 기능	접근을 요청하는 주체의 신원을 확인한다
인가 데이터베이스	접근 허용 여부를 판단하는 데 필요한 권한과 정책 정보를 보관한다
접근 제어 기능	신원과 권한 정보를 바탕으로 자원 접근을 통제한다
감사(Auditing)	접근 시도와 처리 결과 등을 기록, 검토한다
보안 관리자	인증 정보와 접근 제어 정책 등을 관리한다

일반적인 흐름은 다음과 같다

1. 사용자의 신원을 인증한다
2. 인증된 주체가 자원에 대한 작업을 요청한다
3. 접근 제어 기능이 관련 정책과 권한을 확인한다
4. 요청을 허용하거나 거부한다
5. 관련 활동을 감사 기록으로 남긴다

감사 기록은 사후 조사와 이상 행위 탐지에 활용할 수 있지만, 접근을 직접 차단하는 기능과는 구분된다

1.3 주체, 객체, 접근 권한

접근 제어는 주체, 객체, 접근 권한의 관계로 표현할 수 있다.

1.3.1 주체

주체(Subject)

객체에 접근하거나 작업을 수행하는 능동적인 실체이다

사용자를 대신하여 실행되는 프로세스가 대표적인 예다. 사용자가 파일을 열면 실제로는 해당 사용자의 권한으로 실행되는 프로세스가 접근을 요청한다

UNIX와 같은 파일 권한 체계에서는 접근 요청자를 다음 범주로 구분할 수 있다

범주	의미
소유자(Owner)	해당 객체를 소유한 사용자
그룹(Group)	객체에 연결된 그룹에 속하는 사용자
기타 사용자(World/Others)	소유자와 해당 그룹 범주에 속하지 않는 사용자

1.3.2 객체

객체(Object)

접근 제어의 대상이 되는 자원이다

파일, 디렉터리, 메모리 영역, 장치 등이 객체가 될 수 있다. 프로세스도 다른 프로세스가 종료하거나 제어하는 대상이 될 때는 객체로 취급할 수 있다

따라서 주체와 객체는 역할에 따른 구분이며, 어떤 실체가 항상 한쪽 역할만 가지는 것은 아니다

1.3.3 접근 권한

접근 권한(Access Right)

주체가 객체에 대해 수행하도록 허용된 작업의 종류이다

권한	의미
읽기(Read)	객체의 내용을 읽는다
쓰기(Write)	객체에 데이터를 기록하거나 변경한다
실행(Execute)	프로그램 등을 실행한다
삭제(Delete)	객체를 삭제한다
생성(Create)	새로운 객체를 만든다
검색(Search)	객체나 경로를 탐색한다

같은 권한 이름도 객체의 종류에 따라 의미가 달라질 수 있다. 예를 들어 파일의 읽기와 디렉터리의 읽기는 동일한 작업이 아니다

1.4 접근 제어 요청의 표현

접근 요청은 기본적으로 다음 세 요소로 나타낼 수 있다

$(\text{주체},\text{작업},\text{객체})$

예를 들어 다음 요청은 Alice가 보고서 파일에 쓰기를 시도한다는 뜻이다

$(\text{Alice},\text{Write},\text{Report})$

접근 제어 기능은 이 조합이 정책상 허용되는지 판단한다. 정책에 따라 시간이나 접속 위치 같은 추가 조건도 고려할 수 있다

1.5 대표적인 접근 제어 정책

1.5.1 재량적 접근 제어

재량적 접근 제어(Discretionary Access Control, DAC)

요청자의 신원과 접근 규칙을 바탕으로 접근을 통제하며, 권한을 가진 주체가 다른 주체에게 접근 권한을 부여할 수 있는 방식이다

예를 들어 파일 소유자가 다른 사용자에게 해당 파일의 읽기 권한을 부여할 수 있다

핵심은 개별 주체·객체에 대한 권한 설정과 권한 부여의 재량이다

1.5.2 강제적 접근 제어

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

주체의 보안 인가 수준과 객체의 보안 레이블 등을 비교하여, 시스템이 정한 정책에 따라 접근을 통제하는 방식이다

일반 사용자가 객체의 소유자라고 하더라도, 자신의 판단만으로 시스템의 강제 정책을 우회할 수 없다

1.5.3 역할 기반 접근 제어

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

사용자에게 부여된 역할과 그 역할에 연결된 권한을 바탕으로 접근을 통제하는 방식이다

예를 들어 학생, 교수, 학사 담당자라는 역할을 만들고 각 역할에 필요한 권한을 연결한다

1.5.4 속성 기반 접근 제어

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

주체, 객체, 환경 등의 속성을 정책 규칙과 함께 평가하여 접근을 통제하는 방식이다

예를 들어 “인사팀 소속 직원은 업무시간에 사내망에서 인사 문서를 읽을 수 있다”는 정책을 표현할 수 있다

이때 부서, 문서 종류, 시간, 접속망이 판단에 사용되는 속성이다

1.6 접근 제어 정책 비교

방식	주요 판단 기준	예시
DAC	신원과 개별 접근 권한	파일 소유자가 Alice에게 읽기 권한 부여
MAC	보안 레이블과 인가 수준	기밀 등급에 따라 문서 접근 제한
RBAC	사용자의 역할	학사 담당자 역할에 성적 처리 권한 부여
ABAC	주체·객체·환경 등의 속성	부서·시간·접속 위치를 함께 검사

여러 정책의 결합

네 방식이 반드시 서로 배타적인 것은 아니다. 하나의 시스템에서 여러 정책을 함께 적용할 수 있으며, ABAC 규칙으로 DAC·MAC·RBAC의 개념을 표현할 수도 있다

---

2. MAC과 Bell-LaPadula, Biba 모델

2.1 강제적 접근 제어의 기본 원리

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

주체와 객체에 부여한 등급, 레이블을 시스템의 정책에 따라 비교하여 접근을 통제하는 방식이다. 일반 사용자는 자신의 재량만으로 강제 정책을 변경하거나 우회할 수 없다

여러 보안 등급을 구분하는 다단계 보안(Multilevel Security) 환경에서 활용할 수 있다

예를 들어 보안 등급을 다음처럼 정할 수 있다

$\text{Top Secret}>\text{Secret}>\text{Confidential}>\text{Restricted}>\text{Uncleared}$

다만 등급이 높다고 모든 작업이 허용되는 것은 아니다. 읽기와 쓰기에 적용되는 규칙은 모델의 보호 목적에 따라 달라진다

모델	주요 보호 목적
Bell–LaPadula(BLP)	기밀성
Biba	무결성

2.2 Bell–LaPadula 모델의 목적

Bell–LaPadula 모델

높은 보안 등급의 정보가 낮은 등급으로 유출되는 것을 방지하기 위한 기밀성 중심의 접근 제어 모델이다

다단계 보안과 MAC을 설명하는 대표적인 형식 모델이며, 미국 국방부의 보안 평가 기준인 TCSEC와도 관련된다

주체와 객체의 보안 등급을 다음과 같이 표시한다

표기	의미
$s$	주체(Subject)
$o$	객체(Object)
$L(s)$	주체의 보안 등급
$L(o)$	객체의 보안 등급

2.3 BLP의 읽기 규칙: No Read Up

단순 보안 속성(Simple Security Property, ss-property)

주체는 자신과 같거나 낮은 보안 등급의 객체만 읽을 수 있다

읽기가 허용되는 등급 조건은 다음과 같다

$L(o)\le L(s)$

이를 상위 등급 읽기 금지(No Read Up)라고 한다

예를 들어 주체의 등급이 Secret이면 다음과 같다

객체의 등급	읽기
Top Secret	금지
Secret	등급 조건 충족
Confidential	등급 조건 충족

낮은 등급의 주체가 높은 등급의 정보를 읽으면 기밀이 노출되므로 이를 제한한다

2.4 BLP의 쓰기 규칙: No Write Down

스타 속성(Star Property, *-property)

주체는 자신과 같거나 높은 보안 등급의 객체에만 쓸 수 있다

쓰기가 허용되는 등급 조건은 다음과 같다

$L(o)\ge L(s)$

이를 하위 등급 쓰기 금지(No Write Down)라고 한다

주체의 등급이 Secret이면 다음과 같다

객체의 등급	쓰기
Top Secret	등급 조건 충족
Secret	등급 조건 충족
Confidential	금지

높은 등급의 정보를 읽은 주체가 이를 낮은 등급의 문서에 기록하면 기밀이 유출될 수 있으므로, 아래 등급으로 쓰는 것을 제한한다

2.4.1 BLP의 정보 흐름

읽기에서는 객체 → 주체, 쓰기에서는 주체 → 객체로 정보가 이동한다

BLP의 두 규칙을 적용하면 정보는 기본적으로 낮은 보안 등급에서 높은 보안 등급으로, 또는 같은 등급 안에서 흐른다

그림 1. BLP의 상위 등급 읽기 금지와 하위 등급 쓰기 금지

그림의 왼쪽 읽기 화살표는 사용자가 접근하려는 대상을 가리킨다. 따라서 이를 그대로 정보의 이동 방향으로 해석하면 안 된다

2.5 BLP의 한계

BLP는 기밀성 보호를 목적으로 하므로 정보의 정확성이나 신뢰성을 자체적으로 보장하지 않는다

예를 들어 낮은 등급의 주체가 높은 등급의 객체에 거짓 정보를 기록하더라도, 위의 등급 규칙만으로는 이를 막지 못할 수 있다. 또한 쓰기 권한에 수정이나 삭제까지 포함한다면 데이터 훼손 문제가 발생할 수 있다. 실제 허용 여부는 다른 권한과 정책에도 달려 있다

BLP가 보장하는 범위

기밀이 아래로 유출되지 않는 것과 데이터가 올바르게 유지되는 것은 다른 문제다. BLP의 기밀성 규칙만으로 무결성이 보장되지는 않는다

2.6 Biba 모델의 목적

Biba 모델

신뢰도가 낮은 정보나 주체가 높은 무결성 수준의 정보를 오염시키는 것을 방지하기 위한 무결성 중심의 접근 제어 모델이다

여기서는 엄격한 무결성 정책의 읽기·쓰기 규칙을 다룬다

표기	의미
$I(s)$	주체의 무결성 등급
$I(o)$	객체의 무결성 등급

무결성 등급은 정보나 주체의 신뢰 수준을 나타낸다. BLP의 보안 등급이 나타내는 기밀성과는 구분해야 한다

예를 들어 다음과 같은 등급을 생각할 수 있다

$\text{높은 신뢰 수준}>\text{중간 신뢰 수준}>\text{낮은 신뢰 수준}$

2.7 Biba의 읽기 규칙: No Read Down

단순 무결성 속성(Simple Integrity Property, si-property)

주체는 자신과 같거나 높은 무결성 등급의 객체만 읽을 수 있다

읽기가 허용되는 등급 조건은 다음과 같다

$I(o)\ge I(s)$

이를 하위 등급 읽기 금지(No Read Down)라고 한다

중간 무결성 등급의 주체를 예로 들면 다음과 같다

객체의 무결성 등급	읽기
높음	등급 조건 충족
중간	등급 조건 충족
낮음	금지

낮은 신뢰도의 정보를 읽고 이를 처리 결과에 반영하면 주체나 그 출력의 신뢰성이 훼손될 수 있으므로 이를 제한한다

2.8 Biba의 쓰기 규칙: No Write Up

스타 무결성 속성(Star Integrity Property, *-integrity property)

주체는 자신과 같거나 낮은 무결성 등급의 객체에만 쓸 수 있다

쓰기가 허용되는 등급 조건은 다음과 같다

$I(o)\le I(s)$

이를 상위 등급 쓰기 금지(No Write Up)라고 한다

객체의 무결성 등급	중간 등급 주체의 쓰기
높음	금지
중간	등급 조건 충족
낮음	등급 조건 충족

낮은 신뢰도의 주체가 높은 무결성 등급의 문서를 수정하면 신뢰할 수 없는 내용이 섞일 수 있으므로 이를 제한한다

2.8.1 Biba의 정보 흐름

읽기는 높은 등급의 객체에서 주체로, 쓰기는 주체에서 낮은 등급의 객체로 이루어질 수 있다. 따라서 정보는 기본적으로 높은 무결성 등급에서 낮은 무결성 등급으로, 또는 같은 등급 안에서 흐른다

그림 2. Biba의 하위 무결성 등급 읽기 금지와 상위 등급 쓰기 금지

2.8.2 호출 속성

호출 속성(Invocation Property)은 주체가 다른 주체의 실행을 요청하는 경우에도 무결성 등급을 적용한다

엄격한 Biba 정책에서는 주체 $s_1$이 $s_2$를 호출하려면 다음 조건을 만족해야 한다

$I(s_1)\ge I(s_2)$

즉, 낮은 무결성의 주체가 높은 무결성의 주체를 호출하여 영향을 주는 것을 제한한다

2.9 Biba의 한계

Biba는 무결성을 보호하지만 기밀성은 자체적으로 보장하지 않는다

높은 무결성 등급의 정보를 낮은 등급으로 전달하는 것이 허용될 수 있으므로, 그 정보가 기밀이라면 별도의 기밀성 정책이 필요하다. 또한 무결성 등급과 접근 규칙이 있다고 해서 모든 데이터의 내용이 사실임을 자동으로 검증하는 것은 아니다

2.10 BLP와 Biba의 비교

비교 항목	BLP	Biba
보호 목적	기밀성	무결성
등급의 의미	정보의 민감도·보안 수준	정보·주체의 신뢰 수준
읽기 금지	위로 읽기 금지	아래로 읽기 금지
쓰기 금지	아래로 쓰기 금지	위로 쓰기 금지
읽기 조건	$L(o)\le L(s)$	$I(o)\ge I(s)$
쓰기 조건	$L(o)\ge L(s)$	$I(o)\le I(s)$
등급 간 정보 흐름	낮음 → 높음	높음 → 낮음
자체적으로 보장하지 않는 것	무결성	기밀성

등급 조건 충족과 최종 접근 허용의 구분

표의 조건은 각 모델의 등급 규칙을 통과한다는 의미다. 실제 접근에는 별도의 접근 권한이나 다른 정책도 적용될 수 있다. 또한 BLP와 Biba의 ‘높은 등급’은 서로 다른 기준이므로 혼동하면 안 된다

---

3. Clark–Wilson, Chinese Wall 모델과 MAC의 한계

3.1 Clark–Wilson 모델의 목적

Clark–Wilson 모델

사용자가 데이터를 임의로 변경하지 못하도록 하고, 허가된 처리 절차와 업무 분리를 통해 데이터의 무결성을 유지하는 접근 제어 모델이다

금융 거래처럼 데이터가 정해진 업무 규칙에 따라 변경되어야 하는 환경을 생각할 수 있다

핵심은 단순히 “누가 데이터를 수정할 수 있는가?”뿐 아니라, “누가 어떤 절차를 통해 수정할 수 있는가?”를 통제하는 것이다

3.2 객체에 대한 직접 접근 제한

사용자에게 중요한 데이터의 직접 수정 권한을 주면, 정상적인 업무 절차를 거치지 않고 값을 변경할 수 있다

예를 들어 송금 담당자가 계좌 잔액을 직접 수정할 수 있다면, 실제 송금 없이 잔액만 변경하는 문제가 발생할 수 있다

Clark–Wilson 모델에서는 보호 대상 데이터를 허가된 프로그램과 처리 절차를 통해 변경하도록 한다

접근 방식	예시
직접 수정	사용자가 계좌 잔액을 원하는 값으로 변경
통제된 절차를 통한 수정	송금 프로그램이 조건을 검사하고 출금, 입금을 처리

3.3 올바르게 구성된 트랜잭션

데이터가 유효한 상태에서 다른 유효한 상태로 변경되도록, 필요한 검사와 변경 순서를 정해 놓은 처리 절차이다

예를 들어 송금은 한 계좌의 잔액만 바꾸는 작업이 아니다

1. 송금 요청과 수행 권한을 확인한다
2. 잔액 등 필요한 조건을 검사한다
3. 출금 계좌와 입금 계좌에 변경을 반영한다
4. 관련 기록을 남기고 결과를 확인한다

이처럼 업무 규칙을 지키는 절차를 통해 데이터를 변경하여 무결성을 유지한다

3.4 업무 분리 원칙

부정행위나 오류를 줄이기 위해 중요한 업무의 여러 단계를 서로 다른 담당자에게 나누어 맡기는 원칙이다

한 사람이 업무의 실행과 검증을 모두 담당하면 자신의 부정행위를 숨기기 쉬워질 수 있다

3.4.1 송금 업무 예시

업무	담당자	역할
송금 처리	담당자 A	송금 요청에 따라 거래를 수행한다
송금 검증	담당자 B	거래의 정당성과 처리 결과를 확인한다
회계 처리	담당자 C	거래를 장부와 계정에 반영한다

시스템은 담당자별로 수행 가능한 작업을 제한하고, 정해진 절차를 거쳐 송금 업무가 완료되도록 한다

처리 절차와 업무 분리의 결합

절차가 정해져 있어도 한 사람이 실행·검증·기록을 모두 통제하면 부정을 은폐할 수 있다. 허가된 처리 절차와 담당자의 분리를 함께 적용하는 것이 중요하다

3.5 Clark–Wilson 모델의 한계

통제 절차와 담당자를 늘리면 다음과 같은 부담이 생길 수 있다

한계	설명
처리 복잡성 증가	여러 단계의 검사와 승인 등을 관리해야 한다
처리 지연	검증과 담당자 간 인계에 시간이 필요할 수 있다
구현·운영 부담	절차와 권한 관계를 정확하게 설계하고 유지해야 한다
오류·중단 가능성	절차나 연계 시스템에 문제가 생기면 업무가 중단될 수 있다

이는 반드시 오류가 증가한다는 뜻이 아니라, 절차가 복잡해지면서 추가적인 운영 위험이 생길 수 있다는 의미다

3.6 Chinese Wall 모델의 목적

Chinese Wall 모델

이해충돌이 발생하는 조직들의 민감한 정보를 동일한 주체가 함께 접근하지 못하도록 통제하는 모델이다. Brewer–Nash 모델이라고도 한다

여러 고객사의 정보를 취급하는 컨설팅 회사나 금융기관을 예로 들 수 있다

한 직원이 경쟁 관계인 두 회사의 비공개 정보를 모두 열람하면, 한 회사의 정보가 다른 회사의 업무에 사용되는 이해충돌이 발생할 수 있다

3.7 접근 이력에 따른 이해충돌 방지

Chinese Wall 모델에서는 어떤 정보에 이미 접근했는지가 이후 접근 가능 범위에 영향을 준다

예를 들어 다음과 같이 이해충돌 집합을 정했다고 하자

이해충돌 집합	포함된 회사
은행 분야	은행 A, 은행 B
제조 분야	제조사 C, 제조사 D

직원이 은행 A의 민감한 정보에 접근했다면 다음처럼 통제할 수 있다

이후 접근 대상	판단
은행 A	같은 회사의 정보이므로 다른 조건을 만족하면 접근 가능
은행 B	같은 이해충돌 집합의 경쟁 회사이므로 제한
제조사 C	다른 이해충돌 집합이므로 다른 조건을 만족하면 접근 가능

따라서 은행 A의 정보를 봤다고 해서 모든 다른 회사의 정보가 차단되는 것은 아니다. 같은 이해충돌 집합 안에서 서로 다른 회사의 정보를 함께 취급하는 것을 제한한다

3.7.1 MAC·DAC과의 관계

Chinese Wall 모델은 다음 특성을 결합한 방식으로 설명할 수 있다

• 사용자가 임의로 우회할 수 없는 이해충돌 방지 규칙
• 개별 데이터에 대한 접근 권한 설정

개별 접근 권한이 있더라도 이해충돌 규칙에 위배되면 접근을 제한할 수 있다

고정 등급과 접근 이력의 차이

BLP·Biba는 등급 간 관계를 중심으로 접근을 판단한다. Chinese Wall은 과거에 접근한 정보가 이후 접근 판단에 영향을 준다는 점이 특징이다

3.8 모델별 보호 목적 비교

모델	주요 목적	핵심 통제 방식
BLP	기밀성 보호	보안 등급에 따른 읽기·쓰기 제한
Biba	무결성 보호	무결성 등급에 따른 읽기·쓰기 제한
Clark–Wilson	업무 데이터의 무결성 유지	통제된 트랜잭션과 업무 분리
Chinese Wall	이해충돌 방지	정보 접근 이력에 따른 접근 제한

이 모델들은 서로 다른 문제를 해결하므로, 모두를 같은 등급 비교 규칙으로 이해하면 안 된다

3.9 MAC의 장점

MAC은 공통 정책에 따라 접근을 통제하므로, 많은 사용자와 데이터를 일관된 기준으로 관리하는 데 도움이 된다

장점	설명
일관된 정책 적용	개별 사용자의 판단보다 시스템 정책을 우선한다
대규모 관리	등급과 레이블을 기준으로 다수의 주체·객체를 관리할 수 있다
임의 공유 제한	사용자가 권한을 임의로 확장하여 정책을 우회하는 것을 제한한다

3.10 MAC의 한계와 구현 시 고려 사항

3.10.1 유연성의 한계

등급에 따른 고정된 규칙만으로는 예외적인 업무나 복잡한 협업 요구를 표현하기 어려울 수 있다

다만 높은 등급의 사용자가 모든 작업을 할 수 있다는 뜻은 아니다. BLP의 상위 주체도 낮은 등급 객체에 쓰는 것은 제한된다

3.10.2 등급 변경 문제

주체나 객체의 등급이 바뀌면 기존 권한뿐 아니라 이미 읽거나 복사한 정보도 고려해야 한다

예를 들어 높은 보안 등급의 정보를 읽은 프로세스의 등급을 낮추면, 이후 낮은 등급의 객체로 정보를 내보낼 위험이 생길 수 있다. 따라서 등급 변경의 허용 조건과 전환 절차를 별도로 정해야 한다

3.10.3 작업 의미의 구체화

정책에서 사용하는 읽기, 쓰기 등의 작업을 실제 시스템 동작과 연결해야 한다

고려 사항	확인할 내용
쓰기	생성·수정·추가·삭제 중 무엇을 포함하는가?
파일 삭제	파일 내용과 디렉터리 항목 중 무엇을 변경하는가?
디렉터리 읽기	목록 조회와 내부 파일 내용 읽기를 어떻게 구분하는가?
디렉터리 삭제	내부 객체와 접근 경로에 어떤 영향을 주는가?

추상 규칙과 실제 구현의 연결

‘읽기’와 ‘쓰기’의 의미를 모호하게 정의하면, 규칙을 적용하더라도 의도한 보호가 이루어지지 않을 수 있다. 각 연산이 어떤 객체와 정보 흐름에 영향을 주는지 구체적으로 정해야 한다

---

4. DAC과 접근 행렬, 보호 도메인

4.1 재량적 접근 제어의 기본 원리

재량적 접근 제어(Discretionary Access Control, DAC)

주체의 신원과 접근 규칙에 따라 접근을 통제하며, 권한을 가진 주체가 다른 주체에게 자원의 접근 권한을 부여할 수 있는 방식이다

예를 들어 파일 소유자가 다른 사용자에게 읽기 권한을 부여하거나 회수할 수 있다

개별 주체와 객체에 맞게 권한을 설정할 수 있으므로 유연하지만, 권한이 어떻게 부여되고 전파되는지도 관리해야 한다

4.2 접근 행렬

접근 행렬(Access Matrix)

행은 주체, 열은 객체, 각 항목은 해당 주체가 해당 객체에 대해 가진 권한의 집합을 나타내는 구조이다

접근 행렬을 (A)라고 하면 다음과 같이 표현한다

$A[s,o]=\text{주체 }s\text{가 객체 }o\text{에 대해 가진 권한 집합}$

주체 (s)가 객체 (o)에 작업 (\alpha)를 요청하면 다음 조건을 확인한다

$\alpha \in A[s,o]$

4.2.1 접근 행렬 예시

주체＼객체	File 1	File 2	File 3	File 4
User A	Own, Read, Write	—	Own, Read, Write	—
User B	Read	Own, Read, Write	Write	Read
User C	Read, Write	Read	—	Own, Read, Write

예를 들어 User B는 File 3에 쓰기 권한만 가진다. 쓰기 권한이 있다고 해서 읽기 권한까지 자동으로 주어지는 것은 아니다. 또한 Own은 소유·권한 관리에 관한 권한이며, 표에서는 Read, Write와 별도로 표시한다

4.3 접근 행렬의 저장 방식

큰 시스템의 접근 행렬에는 빈 항목이 많을 수 있다. 따라서 전체 행렬을 그대로 저장하는 대신, 객체별 목록, 주체별 목록, 권한 항목별 테이블로 표현할 수 있다

4.3.1 접근 제어 목록

접근 제어 목록(Access Control List, ACL)

객체를 기준으로, 어떤 주체가 어떤 권한을 가지는지 기록한 목록이다. 접근 행렬의 열에 해당한다

앞의 File 1에 대한 ACL은 다음과 같다

주체	File 1에 대한 권한
User A	Own, Read, Write
User B	Read
User C	Read, Write

ACL은 “이 객체에 누가 접근할 수 있는가?”를 확인하기에 적합하다

4.3.2 역량 목록

역량 목록(Capability List)

주체를 기준으로, 접근할 수 있는 객체와 해당 객체에 대한 권한을 기록한 목록이다. 접근 행렬의 행에 해당한다

User B의 역량 목록은 다음과 같다

객체	권한
File 1	Read
File 2	Own, Read, Write
File 3	Write
File 4	Read

역량 목록은 “이 주체가 어떤 객체에 무엇을 할 수 있는가?”를 확인하기에 적합하다

실제 역량 기반 시스템에서는 주체가 객체 참조와 권한을 임의로 위조하거나 변경하지 못하도록 보호해야 한다

4.3.3 인가 테이블

인가 테이블(Authorization Table)

접근 권한을 주체, 접근 모드, 객체의 항목으로 나열한 테이블이다

주체	접근 모드	객체
User A	Own	File 1
User A	Read	File 1
User A	Write	File 1
User B	Read	File 1
User B	Write	File 3

권한 하나를 하나의 행으로 기록하는 방식이며, 적절한 인덱스를 사용하면 주체별, 객체별로 조회할 수 있다

4.3.4 표현 방식 비교

구조	정리 기준	확인하기 쉬운 질문
접근 행렬	주체 × 객체	주체와 객체 사이에 어떤 권한이 있는가?
ACL	객체별	이 객체에 누가 접근할 수 있는가?
역량 목록	주체별	이 주체는 무엇에 접근할 수 있는가?
인가 테이블	권한 항목별	어떤 주체·작업·객체 조합이 허용되는가?

그림 3. 같은 접근 행렬을 객체별 ACL과 주체별 역량 목록으로 표현한 예

4.4 확장 접근 행렬

접근 행렬의 객체는 파일에 한정되지 않는다. 주체, 프로세스, 장치도 제어 대상인 객체로 포함할 수 있다

객체 종류	권한 예시
파일	Read, Write, Execute
프로세스	Wakeup, Stop
디스크 드라이브	Seek
주체	Owner, Control

주체를 객체로 표현하면 다른 주체의 권한을 관리하는 권한도 행렬 안에 나타낼 수 있다

4.4.1 Owner와 Control

권한	이 모델에서의 의미
Owner	해당 객체에 관한 다른 주체의 권한을 부여·회수하는 등 관리한다
Control	대상 주체의 행에 기록된 권한을 조회하거나 제거할 수 있다

예를 들어 $A[S_1,S_3]$에 control이 있으면, (S_1)은 (S_3)의 권한 항목을 관리하는 일부 작업을 수행할 수 있다

4.4.2 복사 플래그

복사 플래그(Copy Flag)

특정 권한을 다른 주체에게 전달할 수 있는지를 나타내는 표시이다. 권한 뒤에 *를 붙여 표현한다

예를 들어 다음 항목은 (S_1)이 (F_1)을 읽을 수 있으며, 그 읽기 권한을 다른 주체에게 전달할 수도 있다는 뜻이다

$A[S_1,F_1]=\{{\mathrm{read}}^{\ast }\}$

권한을 전달할 때는 복사 플래그를 함께 주거나, 플래그 없이 사용 권한만 줄 수 있다

사용 권한과 재전달 권한

read는 읽기 권한이고, read*는 읽기 권한을 다른 주체에게 전달할 수 있는 권한까지 포함한다. 또한 여기서 *는 복사 플래그이며, BLP의 스타 속성과는 다른 의미다

그림 4. 주체, 파일, 프로세스, 장치와 권한 복사를 표현한 확장 접근 행렬

4.5 접근 행렬의 변경 명령

접근 행렬은 고정된 표가 아니다. 권한 부여·회수, 주체와 객체의 생성, 삭제에 따라 변경된다. 명령을 실행하는 주체를 $S_0$, 권한을 받을 주체를 $S$, 대상 객체를 $X$, 접근 권한을 $\alpha$라고 하자

4.5.1 권한 전달·부여·삭제·조회

명령	필요한 권한	수행 결과
Transfer	$A[S_0,X]$에 ${\alpha }^{\ast }$존재	$A[S,X]$에 $\alpha$ 또는 ${\alpha }^{\ast }$ 추가
Grant	$A[S_0,X]$에 owner 존재	$A[S,X]$에 $\alpha$ 또는 ${\alpha }^{\ast }$ 추가
Delete	$S$에 대한 control 또는 $X$에 대한 owner	$A[S,X]$에서 $\alpha$ 제거
Read	$S$에 대한 control 또는 $X$에 대한 owner	$A[S,X]$의 권한 집합 조회

Transfer는 자신이 가진 복사 가능한 권한을 전달하는 것이고, Grant는 객체의 소유 권한을 바탕으로 권한을 부여하는 것이다

이 표의 Transfer는 수신자 항목에 권한을 추가하며, 전달자의 기존 권한을 제거하는 연산은 포함하지 않는다. 또한 이 표의 Read는 파일 내용을 읽는 명령이 아니라 접근 행렬 항목을 조회하는 명령이다

4.5.2 객체와 주체의 생성·삭제

명령	모델상 필요한 권한	행렬 변경
Create Object $X$	별도 사전 조건 없음	$X$의 열 추가, 생성자에게 owner 부여
Destroy Object $X$	$X$에 대한 owner	$X$의 열 삭제
Create Subject $S$	별도 사전 조건 없음	$S$의 행과 객체로서의 열 추가, 생성자에게 owner, (S) 자신에게 control 부여
Destroy Subject $S$	$S$에 대한 owner	$S$의 행과 열 삭제

주체는 다른 주체의 제어 대상도 될 수 있으므로, 생성할 때 행과 열을 모두 추가한다

여기서 “별도 사전 조건 없음”은 이 추상 모델의 명령 규칙상 조건이 없다는 의미다. 실제 운영체제에서 누구나 계정이나 객체를 무제한 생성할 수 있다는 뜻은 아니다

4.6 접근 제어 기능의 집행

실제 요청은 자원을 관리하는 시스템 구성 요소를 거쳐 처리된다

요청 대상	집행 구성 요소 예시
파일	파일 시스템
메모리의 페이지·세그먼트	메모리 주소 변환 하드웨어
프로세스	프로세스 관리자
터미널·장치	터미널·장치 관리자
특권 명령 등	명령어 처리 하드웨어
접근 권한 변경	접근 행렬 모니터

일반 자원 접근에서는 권한 정보를 확인하고, 권한 변경 요청에서는 변경을 요청할 자격이 있는지 먼저 검사한다

접근 행렬 자체를 누구나 수정할 수 있다면 접근 제어가 무력화되므로, 권한 정보의 변경 경로도 보호해야 한다

4.7 보호 도메인

보호 도메인(Protection Domain)

실행 주체가 사용할 수 있는 객체와 권한의 범위를 정의하는 보호 환경이다

사용자는 시스템 외부의 사람이며, 실제 연산은 프로세스나 모듈 등이 수행한다. 보호 도메인은 이러한 실행 단위에 적용할 권한 범위를 표현한다

도메인은 다음 정보를 포함하거나 연관될 수 있다

• 접근 가능한 이름 공간
• 사용자 ID와 그룹 ID
• 보유한 객체 참조와 역량 목록
• 객체별 접근 권한

예를 들어 같은 사용자의 프로그램이라도, 특정 파일만 읽을 수 있는 제한된 도메인에서 실행할 수 있다

4.7.1 보호 도메인의 집행 수단

수단	역할
언어의 타입 시스템	허용되지 않은 객체 사용이나 연산을 제한한다
메모리 관리 장치(MMU)	프로세스 등의 메모리 접근 범위를 통제한다
컴파일러·코드 검사	실행 코드가 정해진 보호 범위를 벗어나지 않도록 제한한다
소프트웨어 결함 격리(SFI)	소프트웨어 검사·계측으로 코드의 메모리 접근 등을 제한한다

보호 도메인은 권한을 정의하는 개념이고, 실제 강제에는 이러한 메커니즘이 필요하다

4.8 DAC의 장점과 한계

구분	내용
장점: 유연성	주체와 객체에 맞게 개별 권한을 설정할 수 있다
한계: 권한 검토의 어려움	권한 부여와 전파가 누적되면 보안 정책 위반 여부를 확인하기 어려워진다
한계: 관리 구조의 증가	주체·객체·권한 항목이 많아지면 저장과 관리 부담이 커진다
한계: 성능 부담	자료구조와 조회 방식에 따라 권한 검사 비용이 증가할 수 있다

DAC에서는 개별 공유를 쉽게 설정할 수 있지만, 전체 시스템에서 누가 어떤 권한을 갖게 되었는지 지속적으로 검토해야 한다

---

5. UNIX 파일 접근 제어와 ACL

5.1 UNIX의 접근 제어 대상

UNIX는 파일뿐 아니라 장치와 통신 자원 등에도 접근 제어를 적용한다

자원	예시
파일 시스템 자원	일반 파일, 디렉터리, 장치 파일
프로세스 간 통신 자원	UNIX 도메인 소켓, 이름 있는 파이프, 파일 매핑을 통한 공유 메모리
네트워크 자원	TCP·UDP 포트
기타 시스템 기능	System V IPC, 커널 모듈 적재

모든 자원이 동일한 이름 공간과 권한 규칙을 사용하는 것은 아니다. 예를 들어 System V IPC는 별도의 이름 공간을 사용한다

5.2 inode와 디렉터리

inode(Index Node)

파일의 속성, 소유자, 접근 권한, 데이터 위치 등 관리에 필요한 정보를 보관하는 파일 시스템 자료구조이다

파일 시스템은 inode 테이블을 관리하며, 파일 사용 시 필요한 inode 정보를 메모리에서 관리한다

5.2.1 파일 이름과 inode의 관계

디렉터리는 파일 이름과 해당 inode 번호의 연결을 저장한다

구분	주요 역할
디렉터리 항목	파일 이름을 inode 번호와 연결
inode	파일의 속성과 데이터 위치 등 관리

여러 이름이 하나의 inode를 가리킬 수 있다. 하드 링크(Hard Link)가 대표적인 예다

따라서 서로 다른 파일 이름이 반드시 서로 다른 파일 내용을 의미하지는 않는다. inode는 파일 시스템 안에서 식별하므로, 서로 다른 파일 시스템의 같은 inode 번호는 별개의 객체다

디렉터리는 계층적인 트리 형태로 구성되며, 파일과 하위 디렉터리를 포함할 수 있다

5.3 사용자·그룹과 프로세스의 신원

UNIX는 사용자와 그룹을 숫자 식별자로 구분한다

식별자	의미
UID(User ID)	사용자 식별자
GID(Group ID)	그룹 식별자

사용자는 기본 그룹과 추가 그룹에 속할 수 있으며, 프로세스는 접근 권한 판단에 필요한 신원 정보를 가진다

5.3.1 실제 ID와 유효 ID

식별자	의미
실제 UID(RUID)	프로세스의 실제 사용자 신원
유효 UID(EUID)	접근 권한 판단 등에 사용하는 사용자 신원
실제 GID(RGID)	프로세스의 실제 그룹 신원
유효 GID(EGID)	접근 권한 판단 등에 사용하는 그룹 신원

일반적인 파일 접근 권한 판단에서는 유효 신원과 그룹 정보가 중요하다. 실제 ID와 유효 ID는 같을 수도 있지만, 특수 권한을 가진 프로그램에서는 달라질 수 있다

5.4 기본 파일 권한

파일은 소유자 UID, 소유 그룹 GID, 권한 비트를 가진다

기본 권한은 다음 세 범주에 각각 설정한다

• 소유자(Owner)
• 소유 그룹(Group)
• 기타 사용자(Others)

각 범주에는 읽기, 쓰기, 실행 권한이 있으므로, 기본 접근 권한은 총 9비트다

권한	문자	숫자
읽기	r	4
쓰기	w	2
실행	x	1
권한 없음	-	0

예를 들어 다음 권한을 생각할 수 있다

rw-r-----

범주	권한	숫자
소유자	읽기·쓰기	6
그룹	읽기	4
기타	없음	0

따라서 숫자로는 640이다

기본 권한에 SetUID, SetGID, Sticky 비트를 더하면 총 12개의 보호 비트가 된다. 파일 종류를 나타내는 비트는 이 12비트와 구분한다

5.5 파일과 디렉터리에서 권한의 의미

같은 r, w, x라도 객체가 파일인지 디렉터리인지에 따라 의미가 달라진다

권한	일반 파일	디렉터리
읽기 r	파일 내용을 읽는다	내부 항목의 이름을 나열한다
쓰기 w	파일 내용을 변경한다	항목의 생성·삭제·이름 변경 등을 허용한다
실행 x	실행 가능한 파일을 실행한다	디렉터리를 탐색하고 내부 경로를 조회한다

디렉터리 안의 항목을 생성하거나 삭제하려면 일반적으로 해당 디렉터리의 쓰기와 실행 권한이 함께 필요하다

파일 쓰기와 파일 삭제의 차이

파일 내용 수정은 파일의 쓰기 권한과 관련되지만, 파일 이름을 디렉터리에서 제거하는 작업은 상위 디렉터리의 권한과 관련된다. 따라서 읽기 전용 파일도 디렉터리 권한에 따라 삭제될 수 있다

5.6 기본 권한의 선택 방식

전통적인 권한 검사는 요청자에게 적용되는 범주를 선택한 뒤, 그 범주에 필요한 권한이 있는지 확인한다

1. 요청자가 파일 소유자이면 소유자 권한을 적용한다
2. 소유자가 아니고 파일의 그룹에 속하면 그룹 권한을 적용한다
3. 둘 다 아니면 기타 사용자 권한을 적용한다

세 범주의 권한을 모두 합쳐서 사용하는 것은 아니다

예를 들어 소유자의 읽기 권한이 없고 기타 사용자에게 읽기가 허용되어 있어도, 소유자가 기타 사용자 권한으로 다시 판단받는 방식은 아니다

5.7 SetUID와 SetGID

5.7.1 SetUID

SetUID(Set User ID)

실행 파일에 설정되면, 실행 시 프로세스의 유효 UID를 해당 파일의 소유자 UID로 설정하는 특수 비트이다

일반 사용자가 실행한 프로그램이라도, 특정 작업을 수행하는 동안 파일 소유자의 권한이 필요할 수 있다

예를 들어 비밀번호 변경 프로그램은 일반 사용자가 직접 수정할 수 없는 인증 정보 파일을 정해진 절차에 따라 갱신해야 한다

5.7.2 SetGID

SetGID(Set Group ID)

실행 파일에 설정되면, 실행 시 프로세스의 유효 GID를 해당 파일의 소유 그룹 GID로 설정하는 특수 비트이다

비트	실행 시 변화
SetUID	EUID가 실행 파일의 소유자 UID로 설정
SetGID	EGID가 실행 파일의 소유 그룹 GID로 설정

이는 사용자 계정 자체를 변경하거나, 모든 권한을 무조건 더하는 방식이 아니다. 프로세스의 유효 신원이 달라지는 것이다

5.8 Sticky 비트

Sticky 비트

공유 디렉터리에서 사용자가 다른 사용자의 파일을 임의로 삭제하거나 이름을 변경하지 못하도록 제한하는 특수 비트이다

Sticky 비트가 설정된 디렉터리에서는 일반적으로 다음 주체가 해당 항목을 삭제하거나 이름을 변경할 수 있다

• 해당 파일의 소유자
• 디렉터리의 소유자
• 필요한 특권을 가진 프로세스

이때도 필요한 디렉터리 접근 권한 등 다른 조건을 만족해야 한다

대표적인 사용 목적은 여러 사용자가 파일을 생성할 수 있는 공유 임시 디렉터리의 보호다

Sticky 비트가 파일 내용의 읽기·쓰기를 직접 차단하는 것은 아니다

5.9 슈퍼유저

슈퍼유저(Superuser)

전통적인 UNIX에서 일반적인 접근 제어 제한을 광범위하게 우회할 수 있는 특권 사용자이다. 대표적으로 UID 0인 root가 있다

시스템 관리에 필요하지만, 침해되거나 잘못 사용되면 영향 범위가 크다. 또한 실제 시스템에서는 추가 보안 정책이나 권한 분리 메커니즘이 적용될 수 있으므로, 모든 보호 장치를 무조건 우회한다고 일반화해서는 안 된다

5.10 확장 ACL

기본 소유자, 그룹, 기타 권한만으로는 특정 사용자와 여러 그룹에 서로 다른 권한을 부여하기 어렵다

확장 ACL(Extended Access Control List)

기본 파일 권한에 더하여 이름으로 지정한 사용자와 그룹에 개별 권한을 설정할 수 있는 접근 제어 목록이다

여러 UNIX 계열 시스템은 ACL을 지원하며, setfacl 같은 명령으로 설정할 수 있다. 세부 ACL 형식은 시스템에 따라 다를 수 있다

5.10.1 ACL 예시

user::rw-
user:joe:rw-
group::r--
mask::rw-
other::---

항목	의미
user::rw-	파일 소유자의 권한
user:joe:rw-	지정 사용자 joe의 권한
group::r--	파일 소유 그룹의 권한
mask::rw-	그룹 클래스에 적용되는 권한 상한
other::---	기타 사용자의 권한

5.11 ACL 마스크의 역할

ACL 마스크(Mask)

지정 사용자, 소유 그룹, 지정 그룹의 ACL 항목에 대해 실제로 사용할 수 있는 권한의 상한을 정하는 값이다

유효 권한은 다음처럼 계산한다.

$\text{유효 권한}=\text{ACL 항목의 권한}\cap \text{마스크}$

예를 들어 joe의 항목이 rw-이고 마스크가 r--이면 다음과 같다

• rw-\cap r--=r--

joe에게 쓰기 권한이 기록되어 있어도 실제로는 읽기만 가능하다

ACL 항목	마스크 적용
파일 소유자	적용하지 않음
지정 사용자	적용
파일 소유 그룹	적용
지정 그룹	적용
기타 사용자	적용하지 않음

확장 ACL과 그룹 권한 표시

이 형태의 확장 ACL에서는 일반 권한 표시에 나타나는 그룹 클래스 비트가 마스크에 대응한다. 따라서 그룹 부분이 rw-로 보여도 소유 그룹의 실제 권한은 r--일 수 있다

앞의 예시에서는 다음과 같다

대상	유효 권한
소유자	rw-
joe	rw-
소유 그룹	r--
기타	---

그림 5. 확장 ACL의 개별 권한과 그룹 클래스에 적용되는 마스크

5.12 ACL을 이용한 접근 판단

ACL 접근 검사는 크게 두 단계로 볼 수 있다

1. 요청자의 신원에 맞는 ACL 항목을 결정한다
2. 마스크 등을 반영한 권한이 요청 작업을 허용하는지 확인한다

앞의 예시에 사용된 형태에서는 다음 순서로 판단한다

순서	확인 대상	권한 적용
1	파일 소유자인가?	소유자 항목
2	일치하는 지정 사용자 항목이 있는가?	해당 항목과 마스크
3	소유 그룹 또는 지정 그룹에 속하는가?	일치하는 그룹 권한을 합치고 마스크 적용
4	위에 해당하지 않는가?	기타 사용자 항목

일치하는 지정 사용자 항목에 필요한 권한이 없다고 해서, 이후 그룹이나 기타 사용자 권한으로 다시 허용받는 것은 아니다

---

6. 역할 기반 접근 제어(RBAC)

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

권한을 역할에 연결하고, 사용자에게 역할을 할당하여 접근을 통제하는 방식이다

역할은 조직에서 수행하는 직무나 책임을 나타낸다. 예를 들어 대학 시스템에서는 학생, 교수, 학사 담당자 등의 역할을 정의할 수 있다

역할	권한 예시
학생	자신의 수강 내역, 성적 조회
교수	담당 과목의 성적 입력
학사 담당자	학적 정보 관리

사용자별로 모든 권한을 직접 설정하는 대신, 업무에 필요한 권한을 역할 단위로 관리한다

한 사용자에게 여러 역할을 할당할 수 있고, 같은 역할을 여러 사용자에게 할당할 수도 있다

6.1 RBAC의 구성 요소

구성 요소	의미
사용자(Users)	시스템을 이용하는 주체
역할(Roles)	직무·책임에 따라 정의한 권한의 묶음
권한(Permissions)	특정 객체에 특정 작업을 수행할 수 있는 권한
세션(Sessions)	사용자가 할당받은 역할 중 일부를 활성화하는 실행 문맥

권한은 단순히 “읽기”만을 뜻하지 않고, 어떤 객체에 대한 어떤 작업인지를 함께 나타낸다

$\text{권한}=(\text{작업},\text{객체})$

예를 들어 “성적 테이블 읽기”와 “성적 테이블 수정”은 서로 다른 권한이다

6.1.1 사용자 할당과 권한 할당

관계	의미
사용자 할당(UA, User Assignment)	사용자와 역할의 연결
권한 할당(PA, Permission Assignment)	역할과 권한의 연결

역할의 권한을 변경하면 그 역할을 통해 접근하는 사용자들에게 변경 사항을 반영할 수 있다. 사용자의 직무가 바뀌면 해당 사용자의 역할 할당을 조정한다

6.2 세션과 역할 활성화

역할 활성화(Role Activation)

사용자에게 할당된 역할 중에서 특정 세션에서 사용할 역할을 선택하는 것이다

예를 들어 Alice에게 교수와 학과장 역할이 모두 할당되어 있어도, 일반적인 성적 입력 세션에서는 교수 역할만 활성화할 수 있다

구분	의미
할당된 역할	사용자가 사용할 자격이 있는 역할
활성화된 역할	현재 세션에서 실제로 사용하는 역할

한 사용자는 여러 세션을 가질 수 있으며, 각 세션은 한 사용자에게 연결된다. 세션마다 활성화하는 역할은 다를 수 있다

계층과 제약을 잠시 제외하면, 세션에서 사용할 수 있는 권한은 활성화된 역할들의 권한을 합친 집합으로 볼 수 있다

역할 할당과 활성화의 구분

사용자에게 역할이 할당되어 있다고 해서 모든 세션에서 그 역할을 항상 사용하는 것은 아니다. 필요한 역할만 활성화하면 불필요한 권한 사용을 줄일 수 있다

6.3 접근 행렬로 표현한 RBAC

RBAC의 권한 관계는 두 단계로 표현할 수 있다

행렬	행	열	항목의 의미
사용자–역할 행렬	사용자	역할	역할 할당 여부
역할–객체 행렬	역할	객체	해당 역할의 접근 권한

6.3.1 사용자–역할 할당 예시

사용자	학생	교수	학사 담당자
Alice	—	할당	—
Bob	할당	—	—
Carol	—	—	할당

6.3.2 역할별 권한 예시

역할	수강 내역	담당 과목 성적	학적 정보
학생	본인 정보 읽기	본인 성적 읽기	본인 정보 읽기
교수	담당 과목 정보 읽기	입력·수정	—
학사 담당자	업무상 조회	별도 정책 적용	관리

사용자가 요청한 작업을 허용할지는 활성 역할과 그 역할에 연결된 권한 등을 확인하여 판단한다

6.4 RBAC 참조 모델

RBAC 모델은 역할 계층과 제약 조건의 포함 여부에 따라 구분한다

모델	기본 구성	역할 계층	제약 조건
RBAC₀	포함	없음	없음
RBAC₁	포함	있음	없음
RBAC₂	포함	없음	있음
RBAC₃	포함	있음	있음

• RBAC₀: 사용자·역할·권한·세션으로 구성된 기본 모델
• RBAC₁: 기본 모델에 역할 계층 추가
• RBAC₂: 기본 모델에 제약 조건 추가
• RBAC₃: 역할 계층과 제약 조건을 모두 결합

RBAC₁과 RBAC₂는 각각 다른 기능을 추가한 모델이다. 번호가 증가할 때 앞선 모델의 모든 기능을 순서대로 포함하는 구조는 아니다

그림 6. RBAC 참조 모델의 관계와 사용자, 역할, 권한, 세션의 연결

6.5 역할 계층

역할 계층(Role Hierarchy, RH)

역할 사이에 권한 상속 관계를 정의한 구조이다. 상위 역할은 하위 역할의 권한을 상속한다

예를 들어 일반 엔지니어에게 필요한 공통 권한을 기본 역할에 두고, 생산 엔지니어와 품질 엔지니어가 이를 상속하도록 할 수 있다

역할	권한 구성 예시
Engineer 1	프로젝트 1의 기본 엔지니어 권한
Production Engineer 1	Engineer 1 권한 + 생산 업무 권한
Quality Engineer 1	Engineer 1 권한 + 품질 업무 권한
Project Lead 1	생산·품질 엔지니어 역할의 권한 상속

하나의 상위 역할이 여러 하위 역할을 상속할 수 있으므로, 역할 계층은 단순한 트리보다 복잡한 구조가 될 수 있다

6.5.1 계층과 조직도의 구분

역할 계층은 권한 상속 관계를 나타낸다. 실제 조직의 직급이나 보고 체계와 반드시 같을 필요는 없다. 또한 MAC의 등급과도 다르다. BLP에서는 높은 보안 등급이라고 모든 쓰기가 허용되는 것은 아니지만, RBAC 계층은 하위 역할의 권한을 상위 역할이 상속하는 관계다

그림 7. 공통 권한과 직무별 권한을 상속하는 역할 계층의 예

6.6 제약 조건

RBAC 제약 조건(Constraints)

조직의 보안 정책을 반영하기 위해 역할의 할당·활성화·권한 연결 등에 추가하는 제한 조건이다

대표적인 제약으로 상호 배타적 역할, 수 제한, 선행 역할이 있다

6.7 상호 배타적 역할

상호 배타적 역할(Mutually Exclusive Roles)

업무 분리를 위해 한 사용자가 함께 맡거나 활성화할 수 없도록 제한한 역할들이다

예를 들어 송금 요청자와 승인자 역할을 분리하여, 한 사람이 자신의 송금을 승인하지 못하도록 할 수 있다

6.7.1 정적·동적 업무 분리

구분	제한 시점	예시
정적 업무 분리	역할 할당 시	한 사용자에게 요청자와 승인자를 동시에 할당하지 않음
동적 업무 분리	세션의 역할 활성화 시	두 역할을 할당받아도 같은 세션에서 동시에 활성화하지 못함

정적 제약은 보유 가능한 역할 조합을 제한하고, 동적 제약은 동시에 사용할 역할 조합을 제한한다

권한 할당에도 제약을 두어, 특정 권한이 상호 배타적인 역할들에 중복 부여되지 않도록 할 수 있다

역할 이름만 나눈 것으로는 부족하다

요청자·승인자 역할을 따로 만들어도 한 사람이 둘을 동시에 사용할 수 있다면 업무 분리가 무력화될 수 있다. 역할 할당과 활성화에 필요한 제약을 함께 설정해야 한다

6.8 수 제한

수 제한(Cardinality)

역할과 관련된 사용자 수나 역할 수 등에 최댓값을 설정하는 제약이다

예를 들어 다음 정책을 정의할 수 있다

제한 대상	예시
역할에 할당되는 사용자 수	최고 책임자 역할은 최대 1명
사용자에게 할당되는 역할 수	한 사용자는 최대 3개 역할 보유
세션에서 활성화하는 역할 수	한 세션에서는 최대 2개 역할 활성화

핵심은 역할의 내용뿐 아니라 역할 관계의 수량도 통제한다는 점이다

6.9 선행 역할

선행 역할(Prerequisite Roles)

특정 역할을 할당받기 전에 다른 지정 역할을 먼저 보유해야 한다는 제약이다

예를 들어 프로젝트 책임자 역할을 부여하려면 먼저 엔지니어 역할을 보유해야 한다고 정할 수 있다

이는 역할 계층과 다르다

구분	의미
역할 계층	어떤 역할의 권한을 상속하는가?
선행 역할	역할을 할당받기 위해 어떤 역할을 먼저 가져야 하는가?

선행 역할 조건만으로 권한 상속이 자동으로 정의되는 것은 아니다

6.10 RBAC의 관리상 특징

RBAC는 사용자와 권한을 역할을 통해 연결하므로, 같은 업무를 수행하는 사용자가 많을 때 관리에 도움이 된다

관리 상황	처리 방식
신규 직원 배치	업무에 맞는 역할 할당
부서·직무 변경	기존 역할 회수 및 새 역할 할당
업무 권한 변경	해당 역할의 권한 수정
부정행위 방지	상호 배타적 역할 등 제약 적용

다만 역할을 지나치게 세분화하거나 계층·제약을 잘못 설정하면 관리가 복잡해지고 과도한 권한이 생길 수 있다. 따라서 실제 업무와 필요한 권한에 맞게 역할을 설계해야 한다

---

7. 속성 기반 접근 제어(ABAC)

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

접근 요청과 관련된 주체, 객체, 작업, 환경의 속성을 정책 규칙에 따라 평가하여 접근을 통제하는 방식이다

예를 들어 다음 정책을 정의할 수 있다

• “인사팀 직원은 업무시간에 사내망에서 인사 문서를 읽을 수 있다”

이 정책은 사용자의 신원이나 역할뿐 아니라 소속 부서, 문서 종류, 요청 작업, 접속 시간과 위치를 함께 고려한다

7.1 속성의 종류

속성(Attribute)

접근 제어 판단에 사용하는 주체·객체·환경 등의 특성을 나타내는 정보이다

7.1.1 주체 속성

주체는 객체에 접근하거나 시스템 상태를 변경하는 능동적인 실체다

주체 속성은 해당 주체의 신원과 특성을 나타낸다

속성 예시	의미
이름, 식별자	요청자의 신원
소속	부서나 기관
인가 수준	접근할 수 있는 보안 수준
역할	업무상 책임이나 직무

역할도 주체 속성으로 사용할 수 있다. 따라서 ABAC가 역할 정보를 전혀 사용하지 않는 방식은 아니다

7.1.2 객체 속성

객체는 정보를 포함하거나 전달받는 접근 제어 대상이다

속성 예시	의미
유형(Type)	문서, 이미지, 데이터베이스 등
소유자(Owner)	객체를 소유한 주체
분류(Classification)	공개, 기밀 등 정보 분류
소속 프로젝트	객체가 관련된 업무나 프로젝트

예를 들어 같은 사용자라도 문서의 분류나 소유 부서에 따라 서로 다른 접근 결과가 나올 수 있다

7.1.3 환경 속성

환경 속성은 접근이 발생하는 운영·기술·상황적 조건을 나타낸다

속성 예시	의미
시간	업무시간 여부
접속 위치	사내·외부 접속 여부
접속망	사내망 등 허용된 네트워크인지 여부
장치 상태	관리되는 장치인지 등의 조건

사용자와 객체가 같더라도 환경이 달라지면 접근 결과가 바뀔 수 있다

7.1.4 요청 작업

읽기, 쓰기, 삭제처럼 어떤 작업을 요청했는지도 함께 평가한다

예를 들어 문서 읽기는 허용하면서 수정과 삭제는 제한할 수 있다

7.2 속성을 이용한 정책 표현

ABAC 정책은 여러 속성을 논리적 조건으로 결합하여 표현할 수 있다

앞의 인사 문서 정책을 간단히 나타내면 다음과 같다

$\begin{array}{rl}\text{허용 조건}=& (\text{주체 부서}=\text{인사팀})\\ & \wedge (\text{객체 유형}=\text{인사 문서})\\ & \wedge (\text{작업}=\text{읽기})\\ & \wedge (\text{업무시간})\\ & \wedge (\text{접속망}=\text{사내망})\end{array}$

이 예시는 모든 조건을 만족할 때 읽기를 허용하도록 정의한 것이다

7.2.1 접근 판단 예시

요청 상황	조건 평가	결과
인사팀 직원, 업무시간, 사내망, 인사 문서 읽기	모두 만족	허용
인사팀 직원, 업무시간, 외부망, 인사 문서 읽기	접속망 조건 불충족	이 규칙으로는 허용되지 않음
개발팀 직원, 업무시간, 사내망, 인사 문서 읽기	부서 조건 불충족	이 규칙으로는 허용되지 않음
인사팀 직원, 업무시간, 사내망, 인사 문서 삭제	작업 조건 불충족	이 규칙으로는 허용되지 않음

실제 최종 결정은 다른 규칙과 기본 처리 정책까지 함께 적용하여 내려야 한다

정책 조건과 기본 처리

어떤 허용 규칙을 만족하지 않았다는 사실만으로 전체 정책의 최종 결과가 자동으로 정해지는 것은 아니다. 다른 규칙과의 결합 방식, 일치하는 규칙이 없을 때의 처리 방식도 정의해야 한다

7.3 ABAC의 접근 제어 과정

7.3.1 요청 접수

주체가 객체에 대해 특정 작업을 요청한다

예를 들어 Alice가 인사 문서의 읽기를 요청한다

7.3.2 정책과 속성 확인

접근 제어 메커니즘은 판단에 필요한 정보를 확인한다

확인 대상	내용
접근 제어 정책	적용할 규칙
주체 속성	신원, 소속, 인가 수준 등
객체 속성	유형, 소유자, 분류 등
환경 조건	시간, 접속 위치, 네트워크 등
요청 작업	읽기, 쓰기, 삭제 등

7.3.3 접근 결정과 집행

수집한 속성을 규칙과 비교하여 접근 결과를 결정하고, 그 결과를 실제 요청에 적용한다

• 결정(Decision): 정책을 평가하여 허용 여부를 판단한다
• 집행(Enforcement): 결정에 따라 자원 접근을 허용하거나 차단한다

속성을 확인하고 결정을 내려도 실제 자원 접근 경로에서 그 결과를 적용하지 않으면 접근 제어가 이루어지지 않는다

7.4 다른 접근 제어 방식과의 관계

ABAC는 속성과 규칙을 조합하여 DAC·MAC·RBAC의 접근 제어 개념을 표현할 수 있다

표현할 개념	속성과 규칙의 활용 예시
DAC	객체 소유자와 소유자가 부여한 권한을 확인
MAC	주체의 인가 수준과 객체의 보안 분류를 비교
RBAC	주체의 역할과 그 역할에 허용된 작업을 확인

예를 들어 RBAC의 역할 조건에 “업무시간이며 사내망에서 접속했는가?”라는 환경 조건을 추가할 수 있다

다만 ABAC를 사용한다고 해서 다른 모델의 정책이 자동으로 구현되는 것은 아니다. 해당 정책의 의미에 맞는 규칙을 정확하게 정의해야 한다

7.5 ABAC의 장점과 한계

7.5.1 장점

장점	설명
유연성	다양한 주체·객체·환경 조건을 조합할 수 있다
높은 표현력	복잡한 업무 정책을 세밀한 조건으로 나타낼 수 있다
상황 반영	시간과 접속 환경 등의 변화에 따라 판단할 수 있다
여러 정책 개념의 표현	DAC, MAC, RBAC의 개념을 규칙에 반영할 수 있다

모델상 속성 조합의 수가 고정되어 있지는 않지만, 실제 구현에서는 처리 비용과 관리 가능성을 고려해야 한다

7.5.2 한계

주요 부담은 속성 조회와 조건 평가에 필요한 비용이다

접근 요청마다 주체와 객체의 여러 속성을 조회하고 복잡한 조건을 평가하면 성능에 영향을 줄 수 있다. 또한 규칙이 많아질수록 정책의 일관성을 확인하기 어려워지고, 잘못되거나 오래된 속성 정보가 접근 판단에 영향을 줄 수 있다

속성 정보의 신뢰성

접근 판단에 사용하는 부서·인가 수준·객체 분류 등을 사용자가 임의로 바꿀 수 있다면 정책을 우회할 수 있다. 속성의 출처와 변경 권한도 보호해야 한다

7.6 XACML과 활용 환경

XACML(eXtensible Access Control Markup Language)

속성에 기반한 접근 제어 정책과 요청·응답 등을 표현하기 위한 표준 언어 및 처리 구조이다

웹 서비스 분야에서는 XACML 등을 통해 속성 기반 정책을 표현하고 적용하는 기술이 발전해 왔다

클라우드 서비스처럼 다양한 사용자와 자원이 여러 조건으로 연결되는 환경에서도 ABAC를 활용할 수 있다

ABAC는 접근 제어 모델이고, XACML은 이를 표현, 구현하는 데 사용할 수 있는 수단이라는 점을 구분해야 한다

7.7 접근 제어 방식의 최종 비교

방식	주요 기준	핵심 특징
DAC	신원과 개별 권한	권한을 가진 주체의 재량에 따른 공유
MAC	보안 레이블과 인가 수준	시스템의 강제 정책 적용
RBAC	역할	직무별 권한 관리와 역할 할당
ABAC	주체·객체·작업·환경 속성	다양한 조건을 규칙으로 결합