정보보안 - Access Control

접근 제어 정책
❖ 의무적 접근 제어(MAC) -> 관리자가 정책에 근거해서 접근 내용을 결정하는것 
▪ 보안 레이블과 보안 허가 사이의 비교에 기반함
▪ 의무적: 리소스에 접근할 수 있는 사람이 타인에게 전달할 수 없음 -> 최소한의 규칙을 구현
▪ 중앙집중식 보안 관리: 규칙은 보안 전문가에 의해 생성되며, 운영자에 의해 설정되고, 운영 체제에 의해 실행됨
▪ 또한 규칙 기반 접근 제어로 알려짐
❖ 임의 접근 제어(DAC) ->신원 사용자 중심의 접근 방식
▪ 객체에 대한 접근을 주체가 속한 그룹의 신원에 기반하여 어떻게 제한할지에 대함
▪ 객체의 소유자가 접근 가능 여부를 결정함
❖ 역할 기반 접근 제어(RBAC) -> 역할별로 그룹핑해서 관리
▪ 사용자 역할에 기반함
❖ 속성 기반 접근 제어 -> cloud에서 사용하는
▪ 사용자, 자원 및 현재 환경의 속성에 기반함

 

 

db에서 많이 사용

임의 접근 제어 Discretionary Access Control 
❖ 종종 접근 행렬을 사용하여 제공됨
▪ 각 항목은 지정된 주체의 그 객체에 대한 접근 권한을 명시함
▪ 한 차원(행)에 주체를 나열함: 능력 티켓(목록)
▪ 다른 차원(열)에 객체를 나열함: 접근 제어 목록
❖ 접근 행렬은 종종 희소함
❖ 행 또는 열로 분해할 수 있음

 

UNIX 파일 접근 제어
❖ 현대의 UNIX 시스템은 ACL을 지원함
▪ 추가적인 사용자/그룹 및 관련 rwx 권한을 어떤 수량이든 명시할 수 있음
❖ UNIX 파일 접근 제어
▪ 12개의 보호 비트
• 파일 소유자, 그룹의 구성원 및 모든 다른 사용자를 위한 읽기, 쓰기, 실행 권한을 지정하는 9개
• SetUID, SetGID를 지정하는 2개
• 스티키 비트(디렉토리의 소유자만 제거, 삭제 등을 할 수 있음) 1개
▪ 소유자 ID, 그룹 ID 및 보호 비트는 파일의 inode의 일부임
▪ “사용자 ID 설정”(SetUID) 또는 “그룹 ID 설정”(SetGID)
• 시스템은 실제 사용자의 권한에 추가하여 파일 소유자/그룹의 권한을 일시적으로 사용함
• 일반적으로 접근할 수 없는 파일/자원에 대한 접근을 허용하는 특권 프로그램을 가능하게 함
▪ 스티키 비트
• 디렉토리에 있을 때, 이름 변경/이동/삭제를 소유자로 제한함
❖ 접근이 필요할 때
▪ 가장 적절한 ACL을 선택함
▪ 소유자, 명시된 사용자, 소유/명시된 그룹, 기타
▪ 접근을 위한 충분한 권한이 있는지 확인함

 

역할 기반 접근 제어
❖ ‘역할’에 기반한 접근, 신원에 기반한 접근이 아님
▪ 1970년대 다중 사용자, 다중 프로그래밍 환경에서의 보안 처리 요구 사항을 충족시키기 위해 제안된 방법
▪ 사용자와 역할 간의 다대다 관계
▪ 역할은 종종 정적임
❖ 역할-객체 접근 행렬

RBAC 모델
❖ 역할 기반 모델
▪ 회사에서 개인의 역할에 의한 접근 제어
▪ 사용자가 적절한 역할에 할당되고, 그 역할이 적절한 접근 권한에 할당될 때만 특정 모드에서 정보에 접근할 수 있는 방법
❖ 작업 기반 모델
▪ 조직 내 개별 작업에 의한 접근 제어
❖ 격자 기반 모델
▪ 역할에 할당된 민감도 수준에 의한 접근 제어
▪ 주체와 객체에 보안 등급 부여

 

항목              MAC                                                 DAC                                         RBAC

특징	주체와 객체 클래스를 비교하여 접근 권한을 부여하는 접근 제어	주체의 신원에 따라 접근 권한을 부여하는 접근 제어	주체와 객체 사이에 역할을 할당하는 방법으로 임의적 및 의무적 접근 제어의 약점을 보완
접근 허가 시스템	시스템	데이터 소유자	중앙 권한
접근 결정	보안 레이블	신원	역할
정책	엄격	유연	유연
장점	중앙집중화, 안정적	유연함, 구현하기 쉬움	관리하기 쉬움
단점	구현 및 관리가 어렵고 비용이 높음	트로이 목마에 취약, 신원 도용 통제 방법 없음	-
적용 가능성	Firewall	ACL	HIPAA (건강보험 책임 및 준수법)

 

속성 기반 접근 제어 -> RBAC 클라우드에 적용을 시킨것
❖ 리소스와 주체의 속성에 대한 조건을 표현하는 인가를 정의
▪ 각 리소스는 속성을 가짐 (예: 그것을 생성한 주체)
▪ 단일 규칙이 생성자에 대한 소유권 특권을 명시
❖ 비교적 최근의 것으로, 이 모델을 클라우드 서비스에 적용하는 데 상당한 관심이 있음
❖ 강점: 유연성과 표현력

속성 유형
❖ 주체 속성
▪ 주체는 객체 사이에 정보를 흐르게 하거나 시스템 상태를 변경시키는 활동적인 실체임
▪ 속성은 주체의 신원과 특성을 정의함: 이름, 조직, 직급
❖ 객체 속성
▪ 객체(또는 자원)는 정보를 포함하거나 받는 수동적인 정보 시스템 관련 실체임
▪ 객체는 접근 제어 결정을 내리는 데 활용될 수 있는 속성을 가짐: 제목, 저자, 날짜
❖ 환경 속성
▪ 정보 접근이 발생하는 운영, 기술적, 심지어 상황적 환경이나 맥락을 설명함
• 현재 날짜
• 현재 바이러스/해커 활동
• 네트워크 보안 수준
• 자원이나 주체와 관련 없음
▪ 이러한 속성들은 대부분의 접근 제어 정책에서 대체로 무시되어 왔음

샘플 ABAC 시나리오

1.주체가 객체에 대한 접근을 요청함
2.접근 제어는 일련의 규칙에 의해 관리됨 (2a): 주체의 속성(2b), 객체의 속성(2c) 및 환경의 속성(2d)을 평가함
3.접근 제어가 인증된 경우 주체에게 객체에 대한 접근을 허가함

 

여러개 한번에 쓰는것 가능

 

Identity, Credential, and Access Management (ICAM)
❖ 디지털 신원, 자격 증명 및 접근 제어를 관리하고 구현하기 위한 종합적인 접근 방식