메뉴 건너뛰기

SayClub.org

정보보안(InfoSec)

접근 통제 정책

미르다테 2024.12.30 16:50 조회 수 : 21

강제적 접근통제 정책에 대한 설명으로 옳지 않은 것은?
①모든 주체와 객체에 보안관리자가 부여한 보안레이블이 부여되며 주체가 객체를 접근할 때 주체와 객체의 보안 레이블을 비교하여 접근허가 여부를 결정한다. 
② 미리 정의된 보안규칙들에 의해 접근허가 여부가 판단되므로 임의적 접근통제 정책에 비해 객체에 대한 중앙 집
중적인 접근통제가 가능하다.
③ 강제적 접근통제 정책을 지원하는 대표적 접근통제 모델로는 BLP(Bell-Lapadula), Biba 등이 있다.
④ 강제적 접근통제 정책에 구현하는 대표적 보안 메커니즘으로 Capability List와 ACL(Access Control List) 등 이 있다


접근통제 정책의 구분

  1. 임의적 접근통제정책(DAC ; Discretionary Access Control)

  2. 강제적 접근통제정책(MAC ; Mandatory Access Control)

  3. 역할기반 접근통제정책(RBAC ; Role-based Access Control)

 

1. 임의적 접근통제정책(DAC)

 (1) DAC의 개념

  데이터의 소유자(owner)가 접근을 요청하는 사용자의 신분 즉 식별자(identity ; ID)에 기초하여 객체에 대해 접근을 제한하는 접근통제 방법이다.

 

 (2) DAC의 특징

  ① 접근 권한을 객체의 소유자가 임의로 지정하는 자율적 정책이다.

  ② 허가된 주체에 의하여 변경 가능한 하나의 주체와 객체간의 관계를 정의한다.

  ③ 접근 통제 목록(ACL ; Access Control List)등을 사용한다.

  ④ 강제적 접근제어 (MAC) 방식을 대체하는 기술은 아니다.

  ⑤ 오렌지북 C-레벨의 요구사항이다.

  ⑥ 장 · 단점

   ㄱ. 장점 : 융통성이 많아 상업적 용도로 사용된다.

   ㄴ. 신분(ID)도용 시 통제 방법이 없다.

 

 (3) DAC의 종류

  ① Identity-Based DAC : 주체와 객체의 ID(Identity)에 따른 접근통제로 유닉스에서 사용한다.

  ② User-Directed : 객체를 소유하고 있는 소유자가 접근 권한을 설정 및 변경할 수 있는 접근 통제이다.

 

 

 

2. 강제적 접근통제정책(MAC)

 (1) MAC의 개념

  강제적인 접근 제한 또는 MAC은 정보시스템 내에서 어떤 주체가 어떤 객체에 접근하려 할 때 양자의 보안레이블(보안등급)을 비교하여 높은 보안을 요하는 정보가 낮은 보안수준의 주체에게 노출되지 않도록 접근을 제한하는 접근통제 방법이다.

 

 (2) MAC의 주요 특징

  ① 접근승인은 보안레벨(level)과 카테고리(category)로 구성되는 보안레이블(Security label)에 의해 제한된다.

  ② 접근정책은 시스템(system)에 의하여 강제적으로 정의되기 대문에 Rule-based 접근통제라고도 한다.

  ③ 오렌지북 B-레벨의 요구사항으로 DAC보다 안전하다.

  ④ 장 · 단점

   ㄱ. 장점 : 보안이 매우 엄격하여 군대와 같은 민감한 정보의 기밀성을 보장하는데 사용된다.

   ㄴ. 단점 : 모든 접근에 대해 보안등급을 정의하고 정책을 확인해야 하기 때문에 개발, 구현이 어렵다.

 

 (3) MAC의 종류

  ① Rule-based MAC : 주체와 객체의 특성에 관계된 특정 규칙에 따른 접근 통제이다.

  ② Administratively-directed MAC : 객체에 접근할 수 있는 시스템 관리자에 의한 통제이다.

  ③ CBP(Compartment-Based Policy) : 일련의 객체 집합을 다른 객체들과 분리하여 통제이다.

  ④ MLB(Multi-Level Policy) : 각 객체별로 지정된 등급만 사용하고, TCSEC(미국방성의 컴퓨터 보안 평가지표)에서 사용되고 있으며 BLP(벨-라파둘라) 수학적 모델로 표현이 가능하다.

 

 

 

3. 역할기반 접근통제정책(RBAC)

 (1) RBAC의 개념

  주체가 적절한 역할(role)에 할당되고 역할에 적합한 접근권한이 할당된 경우만 객체에 접근할 수 있는 비임의적 접근제어(Non DAC) 방식으로 전통적인 DAC와 MAC의 대체 수단으로 사용된다.

 

 (2) RBAC의 주요 특징

  ① 주체의 역할이나 임무에 따라 객체의 접근 권한을 제어하는 방식이다.

  ② 조직의 기능 변화나 인사이동에 따른 관리적업무의 효율성을 꾀할 수 있다.

  ③ 역할에 따라 설정된 권한만 할당하기에 보안 관리를 아주 단순하고 편리하게 할 수 있다.

  ④ 알 필요성 원칙, 최소권한 원칙, 직무분리 원칙이 지켜진다.

  ⑤ 금융기관, 정부나 공공기관에서 효과적으로 사용된다.

  ⑥ 오렌지북 C- 레벨의 요구사항이다.

 

 (3) RBAC의 종류

  ① Task-based Non DAC : 해당 업무에 해당하는 것만 접근가능하다.

  ② Latticed-based Non DAC : 역할에 할당된 민감도 레벨에 의해 접근이 결정되고, 관련된 정보로만 접근할 수 있도록 통제된다.

 

※ 1. Orange Book(미국 국방부 컴퓨터 시스템 평가기준 ; TCSEC)

 ① 시스템 즉 운영체제에 대한 신뢰 수준을 정의한 문서

 ② 시스템 보안 평가 기준 중 최초로 수용된 평ㅇ가 기준

 ③ 네트워크를 고려하지 않은 단일 시스템 보안 평가 기준

 

 

 

접근통제 정책 정리

  강제적  MAC 임의적  DAC  역할기반 RBAC
 접근권한 부여자  시스템  데이터소유자  Central Authority
 접근여부 결정기준  보안 레이블  신분  역할
 정책  경직  유연  유연
 오렌지 북  B-레벨  C-레벨  C-레벨
 장점  안전/중앙집중관리  구현이 용이  다양한 접근권한
 단점  구현, 비용, 성능문제  신분위장  X

 

 

 

접근통제 보안모델

 (1) 개요

  보안모델이란 조직에서 보안 정책을 실제로 구현하기 위한 이론적 모델로 수학적 검증을 통과한 모델이다. 수학적 모델이란 명백하고, 실행가능하고, 쉽게 이해하고, 보안정책의 반영이 용이한 장점이 있다.

 

 보안모델  주요 특징
 Bell-LaPadula (벨라파둘라)  기밀성을 목적으로 하는 최초의 수학적 보안모델
 Biba (비바)  무결성을 목적으로 하는 최초의 수학적 보안모델
 Clark and Wilson (클락윌슨)  무결성 유지 정책을 이용한 상업용 보안모델
 Brewer Nash (만리장성)  이해 충돌 회피를 위한 보안모델

 

----------------------------------------------------------------------------------------------------------------------------------

 

접근 통제

운영체제에서 접근 통제(Access Control)은 디렉터리나 파일, 네트워크 소켓 같은 시스템 자원을 적절한 권한을 가진 사용자나 그룹이 접근하고 사용할 수 있게 통제하는 것을 의미합니다.

접근 통제에서는 시스템 자원을 객체(Object)라고 하며 자원에 접근하는 사용자나 프로세스는 주체(Subject)라고 정의합니다.

즉 /etc/passwd 파일은 객체이고 이 파일에 접근해서 암호를 변경하는 passwd 라는 명령어는 주체이며 아파치 웹 서버의 설정 파일인 /etc/httpd/conf/httpd.conf 는 객체이며 웹 서버 프로그램인 /sbin/httpd 는 주체가 됩니다.

 

임의 접근 통제(DAC)

임의 접근 통제(DAC;Discretionary Access Control)는 시스템 객체에 대한 접근을 사용자나 또는 그룹의 신분을 기준으로 제한하는 방법입니다.

사용자나 그룹이 객체의 소유자라면 다른 주체에 대해 이 객체에 대한 접근 권한을 설정할 수 있습니다.

여기서 임의적이라는 말은 소유자는 자신의 판단에 의해서 권한을 줄 수 있다는 의미이며 구현이 용이하고 사용이 간편하기 때문에 전통적으로 유닉스나 윈도우등 대부분의 운영체제의 기본 접근 통제 모델로 사용되고 있습니다.

임의적 접근 통제는 사용자가 임의로 접근 권한을 지정하므로 사용자의 권한을 탈취당하면 사용자가 소유하고 있는 모든 객체의 접근 권한을 가질 수 있게 되는 치명적인 문제가 있습니다.

특히 root 계정은 모든 권한을 갖고 있으므로 root 권한을 탈취하면 시스템을 완벽하게 장악할 수 있으며 권한 탈취시 많이 사용되는 것은 아래에서 설명할 유닉스의 구조적인 2가지 보안 취약점입니다.

 

setuid/setgid 문제

사용자들의 암호는 /etc/shadow 에 저장되어 있으며 루트만 읽고 쓸수 있습니다.

하지만 사용자들은 passwd 명령어를 실행하여 자신의 암호를 변경할 수 있고 이때 /etc/shadow 파일이 수정됩니다.

상대방 호스트가 동작하는지 확인하기 위해 사용하는 ping 은 ICMP(Internet Control Message Protocol) 패킷을 사용하므로 루트 권한이 필요하지만 일반 사용자도 ping 명령어를 사용하여 상대 호스트의 이상 여부를 확인할 수 있습니다.
 

 

유닉스 계열의 운영 체제는 실행 파일의 속성에 setuid(set user ID upon execution)또는 setgid(set group ID upon execution) 비트라는 것을 설정할 수 있으며 이 비트가 설정되어 있을 경우 해당 프로그램을 실행하면 실행 시점에 설정된 사용자(setuid), 또는 그룹(setgid) 권한으로 동작합니다.

 

이를 확인해 보기 위해 대표적인 setuid 비트가 붙은 프로그램인 ping 과 passwd 의 권한을 확인해 봅시다.

$ ls -l /bin/ping /usr/bin/passwd -rwsr-xr-x 1 root root 44168 May 8 2014 /bin/ping -rwsr-xr-x 1 root root 54256 May 17 08:37 /usr/bin/passwd

Copy

TODO: s 진하게 표시

ls -l 실행 결과

 

파일의 사용자 퍼미션 부분의 's' 표시는 setuid 비트이며 그룹 퍼미션 부분에 's' 표시가 있을 경우 setgid 비트로 passwd 와 ping 은 setuid 비트가 설정되어 있고 소유자가 root 인 것을 알수 있습니다.

즉 passwd 나 ping 는 실행시 root 사용자로 전환되므로 root 만 가능한 동작(예: /etc/passwd 파일 수정)을 수행할 수 있습니다.

 

 

배포판의 종류와 버전에 따라 ping 에 setuid 비트가 붙지 않았을 수도 있습니다.

 

하지만 setuid 비트가 붙은 프로그램에 보안 취약점이 있을 경우 root 로 구동중이었으므로 공격자가 손쉽게 루트 권한을 획득할 수 있는 문제가 있습니다.

이 때문에 setuid 비트는 필요하지만 유닉스 시스템의 주요 보안 취약점이었으며 시스템 관리자의 골칫 덩어리이었습니다.

 

리눅스 시스템에 있는 setuid 비트(4000)와 setgid 비트(2000)이 붙은 모든 프로그램은 다음 명령어로 찾을 수 있습니다.

$ find /bin /usr/bin /sbin -perm -4000 -o -perm -2000 |xargs ls -l

Copy

setuid/setgid 비트 프로그램 검색

 

잘 알려진 포트 daemon 문제

잘 알려진 포트(well-known port) 는 특정한 쓰임새를 위해서 "인터넷 할당 번호 관리기관"(IANA; Internet Assigned Numbers Authority)에서 할당한 TCP 및 UDP 포트 번호들의 일부로 1024 미만의 포트 번호를 사용하고 있습니다.

예로 웹에 사용되는 http(80), 메일 전송에 사용되는 smtp(25), 파일 전송에 사용되는 ftp(20, 21) 등이 잘 알려진 포트입니다.

전통적으로 잘 알려진 포트는 루트만이 사용할 수 있으므로 데몬 서비스는 모두 루트의 권한으로 기동됩니다.

보안 문제는 여기에서 발생하며 루트로 구동되었으므로 만약 서비스 데몬이 보안 취약점이 있거나 잘못된 설정이 있을 경우 서비스 데몬을 통해서 공격자는 루트 권한을 획득하게 될 위험이 있으며 이때문에 웹 서버등은 구동한 후에 자식 프로세스를 생성(fork 시스템 콜)한 후에 쉘이 없는 사용자 계정으로 전환해서 동작하고 있습니다.

 

예로 아파치 웹 서버(User/Group 지시자)와 nginx(user 지시자)는 아래와 같이 구동할 사용자를 지정하고 있습니다.

## 아파치 웹 서버 User apache Group apache ## nginx user nginx;

Copy

웹 서버 사용자 전환

위와 같이 사용자 전환을 하지만 부모 프로세스는 계속 루트로 구동되어 있으므로 1024 미만의 포트를 사용하는 데몬 프로세스에 대한 보안 대책이 필요하게 됩니다.

 

그러나 1024 미만의 포트를 일반 사용자가 쓸 수 있게 하거나 root 가 아닌 별도의 계정에게만 허용하는 것은 전통적인 유닉스의 동작 방식에 어긋나며 커널 수정이나 기타 유틸리티의 대폭 수정이 필요하며 운영자의 혼란을 유발하므로 좋은 방법이 아닙니다.

 

강제 접근 통제(MAC)

강제 접근 통제(MAC; Mandatory Access Control)는 미리 정해진 정책과 보안 등급에 의거하여 주체에게 허용된 접근 권한과 객체에게 부여된 허용 등급을 비교하여 접근을 통제하는 모델입니다.

높은 보안을 요구하는 정보는 낮은 보안 수준의 주체가 접근할 수 없으며 소유자라고 할 지라도 정책에 어긋나면 객체에 접근할 수 없으므로 강력한 보안을 제공합니다.

 

MAC 정책에서는 루트로 구동한 http 서버라도 접근 가능한 파일과 포트가 제한됩니다. 즉 취약점을 이용하여 httpd 의 권한을 획득했어도 /var/www/html, /etc/httpd 등의 사전에 허용한 폴더에만 접근 가능하며 80, 443, 8080 등 웹 서버에 사전에 허용된 포트만 접근이 허용되므로 ssh로 다른 서버로 접근을 시도하는등 해킹으로 인한 이차 피해가 최소화 됩니다.

단점으로는 구현이 복잡하고 어려우며 모든 주체와 객체에 대해서 보안 등급과 허용 등급을 부여하여야 하므로 설정이 복잡하고 시스템 관리자가 접근 통제 모델에 대해 잘 이해하고 있어야 합니다.

위로