접근제어 모델(정책) 유형에는 4가지가 있다.
| 4가지 주요 접근 통제 정책 |
임의적 접근제어(DAC) | 사용자의 신분/접근 규칙에 기반하는 접근제어 |
| 강제적 접근제어(MAC) | 주체 및 객체의 보안 분류 등급에 기반하는 접근제어 | |
| 역할 기반 접근제어(RBAC) | 주체에 대한 행위나 역할에 기반하는 접근제어 | |
| 속성 기반 접근제어(ABAC) | 동적인 환경과 주체와 객체의 속성에 기반하는 접근제어 |
이 게시글에서는 첫번째, 두번째를 다음 게시글에서는 세번째, 네번째를 다뤄보려고 한다.
1. 임의적 접근제어(DAC)
임의적 접근제어 정의
내 맘대로 권한 부여 느낌...
| Discretionary Access Control == Identity-based Access Control | |
| 용어 정의 | 접근을 요청하는 사용자의 신분 및 접근 규칙에 기반 |
| Discretionery | 객체 소유자의 판단에 따라 임의적으로 권한을 줄 수 있으므로 임의적 |
임의적 접근제어 특징
| 장점 | 필요에 따라 접근제어 가능 (융통적) |
| 대체적으로 구현 용이하고 간단하게 사용 가능 | |
| 객체별로 세분화된 접근제어 가능 | |
| 단점 | 객체 소유자 임의로 접근을 허용하므로 다른 모델에 비해 보안상 취약 |
| 임의적이기 때문에 정보에 대한 엄격한 접근제어가 어려움 | |
| 다른 주체의 신분을 도용한 중대한 결함 발생 가능성 존재 (사용자 권한을 탈취당하면 소유자가 소유하고 있는 모든 객체의 접근 권한을 가질 수 있게 되므로 치명적) (ex. root 권한 탈취 시 시스템을 완벽하게 장악 가능) |
|
| Trojarn Horse 공격에 취약 트로이 목마 악성코드를 통해 모든 시스템이 제어 가능해져버리게 된다는 단점 존재 |
임의적 접근제어 예시
- 윈도우에서 사용자 계정 : 사용자별로 객체 생성 및 정보 접근 권한 설정 가능
- 데이터베이스 관리자가 사용자 A에게는 고객 정보를 수정할 수 있는 권한을 부여하고 사용자 B에게는 동일한 테이블에 대한 읽기 전용 권한을 부여하는 경우
- 각 부서 관리자가 자신의 부서에 관련된 데이터에 대한 엑세스를 제한하고 다른 부서의 사용자가 그 데이터에 접근하는 것을 방지
2. 임의적 접근제어(DAC) 모델
접근제어 행렬
- 모든 주체와 객체에 대한 권한 관계를 2차원 배열로 표현 (개념적 표현)
- 실제 시스템 구현 시 권한 목록, 접근제어 목록으로 구현
권한 목록 (주체가 가진 권한 목록)
- 주체에 대한 접근 가능한 객체를 리스트 형태 (객체, 권한)으로 구현하는 주체 중심의 모델
- 주체가 접근할 수 있는 객체가 많아지면 탐색 시간 증가(리스트의 길이가 길어지므로 순회할 때 시간 소요)
- 객체에 대한 권한 정보를 보유하는 토큰 존재
접근제어 목록 (객체에 대한 접근제어 목록)
- 객체에 대한 권한을 가지고 있는 주체를 리스트 형태 (주체, 권한)로 구현하는 객체 중심 모델
- 권한 목록과 마찬가지로 한 객체에 대해 여러 주체가 권한 부여 받았을 경우 순회 시간 길어져 탐색 시간 증가
3. 강제적 접근제어(MAC)
강제적 접근제어 개념
마치 계급제 같다...
| Mandatory Access Control == Rule Based Access Control | |
| 용어 정의 | 주체 및 객체의 보안 분류 등급에 기반 |
| 미리 정해진 정책에 의거(주체가 가진 접근 권한 && 객체에 부여할 수 있는 허용 등급) | |
| 중앙 집권적인 관리자에 의해 강제적으로 주체&객체 등급 부여 (보안 규칙에 따라 수정 가능) | |
| 낮은 보안 수준의 주체는 높은 보안 수준의 객체 정보에 접근을 제한함으로써 구현 | |
강제적 접근제어 특징
- 주체/객체 수에 관련 없이 접근 규칙의 수(등급의 개수)가 최대로 정해지므로 통제 용이
- 보안 등급 및 규칙은 관리자만 수정 가능
- 기밀성이 강조되는 조직에서 사용
| 장점 | 관리자에 의한 중앙 집중식 관리&보안 규칙에 따른 통제 |
| DAC보다 높은 보안성 제공 | |
| 단점 | 모든 접근에 대한 보안 등급 정의해서 개발, 구현하기까지 어려움 존재 |
| 많은 관리적 부담으로 상업적인 환경에서 적용 어려움 |
강제적 접근제어 예시
높은 보안 수준을 요구하는 객체에 낮은 보안 수준을 가진 주체가 접근 불가능!!
- 온라인 카페에서 브론즈/실버/골드/다이아몬드/플레티넘 등급에 따라 게시판1은 골드 이상 허용, 게시판2는 플레티넘 이상 허용되는 경우
중앙 집권적인관리에 의해 보안성이 높은 편!!
- 군인 계급에 따라 군사 기밀 등급이 차등 부여되는 경우
4. 강제적 접근제어(MAC) 모델
Bell-LaPadula(BLP) 모델 (정보의 기밀성에 중점)
상위까지 도달했으면 상위 정보 유출(하위 단계로 배포)을 막아야지 느낌.....
- 정보의 기밀성 보호에 중점을 둔 최초의 수학적 모델
- 주체와 객체의 보안 수준을 등급으로 구분하여 전형적인 MAC를 사용한 경우
- 마찬가지로 높은 보안 수준에서 낮은 보안 수준으로 정보가 흐르는 것을 차단
| 단순 보안 속성 | 보안 수준이 낮은 주체는 보안 수준이 높은 객체에 대한 읽기 권한 없음 |
| 주체의 등급 >= 객체의 등급 (객체 읽기 가능 조건) | |
| 접근할 수 있으려면 적어도 하한 마지노선 존재 상위 문서 읽기 금지, 하위 문서 읽기 허락 |
|
| 성형 보안 속성 | 보안 수준이 높은 주체는 보안 수준이 낮은 객체에 대한 쓰기 권한 없음 |
| 주체의 등급 <= 객체의 등급 (객체 기록 가능 조건) | |
| 높은 등급의 사용자가 낮은 등급으로 정보 유출할 가능성 방지 | |
| 자신의 등급보다 낮을 경우 정보를 추가적으로 수정할 수 없도록 (등급 높을 수록 자기들끼리만 오리지널 정보를 알고 있으려는 경향) (그러나 낮은 등급 주체에는 높은 객체 읽기는 불가능하나 쓰기는 가능) 상위 문서 쓰기 허락, 하위 문서 쓰기 금지 |
| 장점 | 권한이 없는 사용자의 정보 차단 |
| 정보의 기밀성 보장 | |
| 단점 | 보안 수준이 낮은 주체가 보안 수준이 높은 객체의 정보 변경 가능 (성형 보안 속성 때문) |
| 정보의 무결성 보장 불가 |
Biba 모델 (정보의 무결성에 중점)
나보다 높은 곳 읽기는 가능하나 수정은 불가 느낌...
- BLP 모델의 단점인 무결성을 보장하는 최초의 수학적 모델
- 정보가 상위에서 하위로 흐른다는 개념
- 기밀성보다는 정보의 불법적인 변경을 방지하기 위해 사용
| 단순 무결성 속성 | 보안 수준이 높은 주체는 보안 수준이 낮은 객체에 대한 읽기 권한 없음 |
| 주체의 등급 <= 객체의 등급 (객체 읽기 가능 조건) | |
| 상위 문서 읽기 허락, 하위 문서 읽기 금지 | |
| 성형 무결성 속성 | 보안 수준이 낮은 주체는 보안 수준이 높은 객체에 대한 쓰기 권한 없음 |
| 주체의 등급 >= 객체의 등급 (객체 기록 가능 조건) | |
| 신뢰할 수 있는 중요한 정보들이 신뢰성이 약한 정보들과 결합하여 원래의 비밀 등급이 깨지는 것을 방지 | |
| 상위 문서 쓰기 금지, 하위 문서 쓰기 허락 |
'Information Security' 카테고리의 다른 글
| [DB보안] 빅데이터의 정의와 속성에 따른 처리 과정 및 보안 이슈 (0) | 2024.06.10 |
|---|---|
| [DB보안] 접근제어 모델(정책) 유형 4가지 (2) : 역할기반, 속성기반 접근제어 (0) | 2024.06.03 |
| [DB보안] 데이터베이스 접근제어 설계 및 구축 (0) | 2024.06.03 |
| [DB보안] 데이터베이스 암호화 설계, 구축, 운영 및 MySQL DBMS 암호화 (0) | 2024.05.28 |
| [DB보안] 암호화의 개념, 종류, 데이터베이스 암호화 방식 (0) | 2024.05.28 |
