접근통제 모델과 권한 관리
최소권한·직무분리와 DAC·MAC·RBAC·ABAC 및 대표 보안모델을 학습한다.
1. 접근통제의 구성
접근통제는 주체가 객체에 어떤 연산을 수행할 수 있는지 결정하고 집행하는 과정이다.
주체(사용자·프로세스)
│ 접근 요청
▼
정책 결정 지점
신원·역할·속성·객체·환경 확인
│ 허용/거부
▼
정책 집행 지점
│
▼
객체(파일·DB·API·장비)
│
▼
감사 로그
- 주체: 접근하려는 사용자·서비스·프로세스
- 객체: 보호 대상 자원
- 권한: 읽기·쓰기·실행·삭제·승인 등
- 정책: 허용 여부를 결정하는 규칙
2. 최소권한과 직무분리
- 최소권한: 업무 수행에 필요한 최소한의 권한만 부여
- Need to Know: 업무상 필요한 정보만 접근
- 직무분리: 요청·승인·실행·검토를 한 사람이 모두 수행하지 않도록 분리
- 이중통제: 중요한 작업을 두 사람 이상이 함께 확인
- 권한분리: 일반 계정과 관리자 계정을 구분
변경 요청자 ─X─► 자기 승인
│
▼
승인자 → 작업자 → 검증자
직무분리는 부정뿐 아니라 실수와 단일 실패 지점을 줄인다.
3. DAC
임의적 접근통제(DAC)는 자원 소유자가 다른 주체에게 권한을 부여·회수할 수 있는 모델이다.
- 파일 소유권과 ACL
- 사용자 재량에 따라 권한 위임 가능
- 유연하지만 권한 확산과 잘못된 공유 위험이 있음
소유자 Alice
├─ Bob: read
└─ Carol: read, write
4. MAC
강제적 접근통제(MAC)는 중앙 정책과 보안등급·범주에 따라 접근을 통제한다. 사용자가 임의로 정책을 바꾸기 어렵다.
주체 등급: Secret
객체 등급: Confidential
중앙 정책이 읽기·쓰기 가능 여부 결정
군사·고보안 환경처럼 분류등급을 엄격히 적용하는 데 적합하다.
5. RBAC
역할 기반 접근통제는 사용자에게 역할을 부여하고 역할에 권한을 연결한다.
사용자 ─► 역할 ─► 권한 ─► 자원
김대리 ─► 회계담당 ─► 전표조회·등록
박과장 ─► 회계승인 ─► 전표승인
장점:
- 조직 업무와 권한을 연결하기 쉬움
- 인사이동 시 역할 변경으로 권한 관리 가능
- 역할 계층과 직무분리 정책 적용 가능
위험:
- 역할이 지나치게 세분화되는 역할 폭발
- 실제 업무와 역할 설계가 어긋남
- 예외 권한이 누적됨
6. ABAC
속성 기반 접근통제는 주체·객체·행동·환경의 속성을 조합해 정책을 평가한다.
허용 조건:
사용자.부서 = 문서.소유부서
AND 사용자.직급 >= 문서.필요직급
AND 접속시간 = 업무시간
AND 관리단말 = true
세밀하고 동적인 정책에 유리하지만 속성 품질, 정책 충돌, 설명 가능성을 관리해야 한다.
7. 접근통제 모델 비교
| 모델 | 결정 기준 | 장점 | 주의 |
|---|---|---|---|
| DAC | 소유자와 ACL | 유연함 | 권한 확산 |
| MAC | 중앙 등급·범주 | 강한 통제 | 유연성 낮음 |
| RBAC | 업무 역할 | 조직 관리에 적합 | 역할 설계 필요 |
| ABAC | 다수 속성과 조건 | 정교한 동적 정책 | 정책 복잡성 |
실제 시스템은 여러 모델을 조합할 수 있다.
8. 대표 보안모델
Bell-LaPadula
기밀성 중심 모델이다.
No Read Up : 상위 기밀정보를 읽지 못함
No Write Down: 하위 등급에 써서 정보가 유출되는 것을 방지
Biba
무결성 중심 모델이다.
No Read Down : 낮은 무결성 정보를 읽어 오염되는 것을 방지
No Write Up : 낮은 무결성 주체가 높은 무결성 객체를 변경하지 못함
Clark-Wilson
상업적 무결성 모델로 잘 구성된 트랜잭션, 직무분리, 감사 가능성을 강조한다.
무결성 제약 데이터
│
└─ 인증된 변환 절차만 변경
│
└─ 감사 기록·직무분리
Chinese Wall
이해상충을 방지하기 위해 한 기업의 민감정보에 접근한 사용자가 경쟁 기업의 민감정보에 접근하지 못하도록 동적으로 제한한다.
9. 권한 생명주기
입사·계정 생성
↓
업무 역할에 따른 권한 부여
↓
사용·감사
↓
이동·휴직·프로젝트 종료 시 변경
↓
정기 재검토·불필요 권한 회수
↓
퇴사·계정 비활성화·폐기
JML(Joiner-Mover-Leaver) 관점에서 계정·권한을 관리해야 한다.
- 공유계정 최소화
- 휴면·미사용 계정 정리
- 특권계정 별도 관리
- 긴급권한은 시간 제한과 사후 검토
- 서비스 계정의 소유자·용도·키 회전 관리
10. 권한 검토와 감사
권한 검토에서는 다음을 확인한다.
- 현재 업무에 필요한가
- 상충 권한이 동시에 부여되었는가
- 관리자·DBA 등 특권이 과도한가
- 장기 미사용 권한인가
- 직접 부여와 역할 상속이 중복되는가
- 누가 승인했고 언제 만료되는가
로그는 사용자 ID, 대상, 작업, 시간, 결과, 출처를 남기되 비밀번호·비밀키·민감 원문을 포함하지 않는다.
11. 접근 행렬과 권한 표현
파일A DB테이블 배포기능
사용자U read - -
역할개발자 read/write select -
역할운영자 read select deploy
행 중심으로 저장하면 주체별 capability, 열 중심으로 저장하면 객체별 ACL에 가깝다. 실제 유효 권한은 사용자 직접권한, 소속 역할, 그룹, 거부 규칙, 자원 속성, 시간·위치 조건을 결합해 계산한다.
12. 역할 설계와 직무분리
- Static SoD: 상충 역할을 동시에 부여하지 못하게 함
- Dynamic SoD: 역할은 보유할 수 있어도 같은 세션·같은 거래에서 동시에 활성화하지 못하게 함
- Maker-Checker: 작성자와 승인자를 분리
- Dual control: 민감 작업을 두 명 이상의 독립 승인으로 수행
지급 요청 생성 역할 + 지급 최종 승인 역할 = 상충 역할
RBAC에서 예외를 사용자 직접권한으로 계속 붙이면 role explosion과 권한 추적 어려움이 생긴다. 공통 직무는 역할, 예외·환경 조건은 ABAC 정책으로 분리하는 방식을 고려한다.
13. 정책 결합과 명시적 거부
ABAC 정책이 여러 개면 permit-overrides, deny-overrides, first-applicable 등 결합 알고리즘에 따라 결과가 달라진다. 보안 민감 자원에서는 일반적으로 명시적 거부와 기본 거부를 분명히 한다.
요청: user.department=Finance, action=export, time=23:30
정책1: Finance는 export 허용
정책2: 22:00~06:00 export 거부
deny-overrides → 최종 거부
14. PAM·JIT와 권한 생명주기
관리자 권한은 상시 부여보다 다음 흐름이 안전하다.
요청 → 승인 → 시간 제한 JIT 권한 발급 → 세션 기록 → 자동 회수 → 사후 검토
PAM은 비밀 보관, 체크아웃, 세션 프록시·녹화, 명령 통제, 회전을 결합할 수 있다. 퇴사 계정만 보는 것이 아니라 휴면·고아 계정, 공유 계정, 만료되지 않는 API 키, 과도한 서비스 계정 권한을 함께 점검한다.
확인 문제
- ACL과 capability의 관점 차이는?
- Static SoD와 Dynamic SoD의 차이는?
- deny-overrides에서 허용 정책과 거부 정책이 모두 맞으면?
- JIT 관리자 권한의 핵심은?
- role explosion을 줄이는 방법은?