운영체제 보안 기술 동향

[ntower]

운영체제 보안 기술 동향

김정녀* 윤이중** 조현숙***

인터넷과 같은 네트워크 환경에서 유닉스가 가지는 개방성은 중요한 특성이지만 컴퓨터 내의 정보보호를 향상시키기 위한 도구는 현재 표준 유닉스에서는 매우 부족한 실정이다. 이에, 기존 유닉스 시스템의 취약점을 보완하는 패치 버전이나 업그레이드를 통한 임시 방편적인 방법보다는 원천적으로 새로운 Secure OS의 필요성이 대두되고 있다. 본 고에서는 Secure OS의 개념을 소개하고 필요성을 기술하며, 미국 정부에서 주도하고 있는 Secure OS 개발 현황을 소개한다. ▧

I. 서 론

Secure Oerating System(이하 Secure OS)이란 컴퓨터 운영체제 상에 내재된 보안상의 결함으로 인하여 발생할 수 있는 각종 해킹으로부터 시스템을 보호하기 위하여 기존의 운영체제 내에 보안 기능을 추가한 운영체제를 말한다. Secure OS는 시스템 사용자에 대한 식별 및 인증, 강제적 접근 통제, 임의적 접근 통제, 해킹 대응 등의 보안 기능 요소들을 갖추어야 한다. 미국을 비롯한 정보보호 기술 선진국에서는 일반 기업은 물론 정부 차원에서 Secure OS 개발에 적극적으로 나서고 있다.

인터넷과 같은 네트워크 환경에서 유닉스가 가지는 “개방성”은 중요한 특성이지만 컴퓨터 내의 정보보호를 향상시키기 위한 도구는 현재의 표준 유닉스에서는 매우 부족한 실정이다. 이에, 기존 유닉스 시스템의 취약점을 보완하는 패치 버전이나 업그레이드를 통한 임시 방편적인 방법보다는 원천적으로 새로운 Secure OS의 필요성이 대두되고 있다.

본 고에서는 Secure OS와 시큐어 커널의 개념을 소개하고 Secure OS의 필요성을 기술하며, 미국 정부에서 주도하고 있는 Secure OS 개발 현황을 소개하고, 민간 업체에서 개발되어 상용제품으로 사용되고 있는 제품 현황을 소개한다.

II. Secure OS 개념

1. Secure OS 기본 기능

시스템에 대한 보안은 기본적으로 구조를 변경하지 않고 여러 가지 방법으로 개선될 수 있으나 아주 민감한 정보를 보호하고자 한다면, 강력한 개발 전략과 특별한 시스템 구조가 요구된다. 보안 커널 방법은 일반 운영체제에 내재되어 있는 보안 문제점을 해결하기 위하여 운영체제를 설계하는 방법을 말한다. 그 기본 기능으로는 강제적인 접근 제어와 신뢰할 수 있는 경로, 그리고 보호된 경로 등을 들 수 있다. 여기에서 접근 제어는 운영체제 내에서 자원 사용의 주체가 되는 사용자 또는 프로세스가 객체인 파일, 파일 시스템, 디스크 등을 접근할 때 신분이나 규칙에 의하여 해당 객체에 대한 접근을 통제하는 것을 말한다.

¡ 강제적인 접근 제어(Mandatory Access Control)

운영체제의 강제적인 접근 제어 기능이란 단지 접근 제어 정책만을 말하지 않고, 다음과 같이 그 이외의 몇 가지를 포함한다.

¡ 접근 제어 정책(Access Control Policy): 운영체제 제어 하에서 주체가 객체를 어떻게 접근할 것인가를 지정하는 정책

¡ 인증 사용 정책(Authentication Usage Policy): 사용자 인증에 사용되는 사용자 인증 메커니즘

¡ 암호 사용 정책(Cryptographic Usage Policy): 데이터를 저장, 전송할 때 보호하기 위하여 사용되는 암호 메커니즘

¡ 추가 사용 정책: 이는 운영체제 커널 내의 각 서브시스템이 특정하게 사용하는 정책으로 예를 들자면 라우터를 위한 네트워크 사용 정책이 있다. 이는 외부 네트워크로 보내지기 전에 터널링 모드에서 IPSEC ESP를 이용하여 보호되는 민감한 네트워크 트래픽(Sensitive Network Traffic)을 지정하는 것을 말하며, 그 이외에도 IPSEC ESP를 위한 암호 알고리즘을 들 수 있다.

나. 신뢰할 수 있는 경로와 보호된 경로(Trusted Path & Protected Path)

¡ 신뢰할 수 있는 경로(Trusted Path): 신뢰할 수 있는 소프트웨어와 함께 상호 동작하는 사용자를 허가하는 메커니즘으로 운영체제의 제어하에서 주체가 객체를 어떻게 접근할 것인가를 지정한다. 이는 사용자의 신뢰할 수 있는 소프트웨어를 속이는 악의적인 응용 프로그램을 막을 수 있다. 예를 들면, 패스워드를 변경하거나, 접근 권한을 변경하는 등의 보안 관리 기능을 수행 할 때 신뢰성 있는 경로가 설정되어야 한다.

¡ 보호된 경로(Protected Path): 소프트웨어 요소 사이의 상호 보증할 수 있는 채널을 말한다. 중요한 시스템 기능을 보호하기 위해서 필요하며, 운영체제에서 더 간단하고 효율적인 방법으로 직접 제공할 수 있다.

2. 응용 수준에서 제공하는 일반적인 접근 제어 예제

가. 응용 공간 접근 제어

응용 공간의 접근 제어 메커니즘을 수행자(enforcer) 요소와 결정자(decider) 요소로 구분하여 해당 주체가 특정 메커니즘에 의해 보호되는 객체를 액세스하려고 할 때, 수행자가 결정자 요소를 호출하면서 정책 결정을 위한 입력 매개변수를 공급한다. 이에 따라 해당 결과의 정책을 수행한다. 결정자 요소는 정책 결정을 위해 외부 정책 데이터베이스나 현재 시간과 같은 시스템 정보를 이용한다.

응용 공간의 접근 제어의 문제점은 다음과 같다. 첫째는 악의 있는 에이전트가 접근 제어 메커니즘 내의 임의의 요소를 부정적으로 변경하거나, 결정하기 위한 입력을 변경할 수 있다면 접근 제어 메커니즘을 파괴할 수 있음을 알 수 있다. 그러므로 임의의 요소나 입력이 단일 파일 내에 존재한다면, 운영체제 보안 메커니즘으로 그 파일의 무결성을 보호해야 한다. 그러나 운영체제 내의 강제적 보안 메커니즘은 수행자 요소에 의해 중재되는 보호된 객체에 대한 모든 접근을 안전하게 한다. 둘째는 신뢰할 수 있는 경로가 필요하다. 정책 결정 입력의 무결성을 유지한다고 해도, 허가된 사용자가 악의 있는 소프트웨어를 실행하면, 객체의 보안 속성 또는 정책 데이터베이스의 규칙을 변경할 수 있다는 것이다. 즉 사용자에 의해 확실한 인증 없이 발생될 수 있는 접근에 대해 안전하도록 운영체제 내에 신뢰할 수 있는 경로 메커니즘을 요구하게 된다. 셋째는 보호된 경로가 필요하다. 임의의 요소나 외부의 결정 입력 주체 등이 단일 응용 프로그램 내에 존재하지 않는다면 보호된 경로 메커니즘이 요구된다.

나. 응용 공간 암호

응용에 의한 서비스, 알고리즘, 세션 또는 키의 사용을 나타내는 토큰 호출의 안전이 보장되지 않는다. 패스워드와 같은 적당한 토큰 사용 시도가 그 토큰을 호출한 결과와 같지 않을 수가 있다. 악의 있는 응용 프로그램은 호출하는 응용에 대해 암호화된 토큰을 흉내낼 수 있다. 이는 운영체제 내의 강제적인 보안 기능과 보호된 경로 기능으로 해결할 수 있다. 강제적인 보안 기능은 악의적인 소프트웨어 또는 사용자의 우회, 변경을 막기 위해 암호 토큰을 호출하는 응용 프로그램을 보호할 수 있다. 또한 보호된 경로 기능은 호출하는 응용 프로그램인 암호 토큰을 흉내낼 수 없게 한다.

암호 토큰의 오용은 허가되지 않은 응용에 의한 서비스, 알고리즘, 세션 또는 키의 사용을 말하는데, 호출자를 식별하기 위해서는 운영체제의 지원없이 암호 토큰이 사용자의 동작을 더 이상 요구 할 수 없다. 암호 토큰이 사용자 동작에 의한 직접적인 물리 인터페이스를 갖지 않는다면, 악의 있는 소프트웨어가 그 토큰을 가로채고, 인증 정보를 얻을 수 있다. 또한 사용자가 알지 못하게 그 암호 토큰을 동작시킨다. 이에 대한 해결책으로 강제적인 보안, 신뢰할 수 있는 경로와 보호된 경로 등을 들 수 있다. 신뢰할 수 있는 경로는 동작을 위한 물리 인터페이스의 분리 필요를 없애며, 보호된 경로는 호출자를 식별하기 위한 암호 토큰을 인정하고, 서비스, 암고리즘, 세션 그리고 키 등의 사용을 위한 fine-grain 제어를 허가한다. 강제적인 보안은 fine-grain 제어를 제공하는 데 사용한다.

3. 구체적인 예제

가. 이동 코드(Mobile Code)

World Wide Web의 보안은 악의 있는 이동 코드로부터의 위협을 막기 위해 개발되었으나 보안을 위한 운영체제의 지원이 없이는 해당 시스템이 취약할 수 밖에 없다. 보통 이를 해결하기 위한 노력으로 Secure JAVA를 개발한다. 지역 파일 시스템을 접근하는 실제 프로그램인 Postscript 문서를 보여주는 Postscript viewer 와 같이 신뢰할 수 없는 데이터 상에서 동작하는 helper 응용은 덜 유연한 동작 모드에서 실행되거나, 운영체제에 의해 주의 깊게 허용해야 한다.

나. 커버로스(Kerberos)

MIT의 Athena Project에서 개발된 네트워크 인증 서비스로 인증 서비스, 네트워크 기밀성과 무결성 서비스를 지원한기 위해 세션 키 설정을 지원한다.

문제점은 악의 있는 소프트웨어가 사용자에 대한 클라이언트 편의 인증 프로그램을 가로챌 수 있다면, 사용자의 패스워드를 얻을 수 있다. 그 경우에 클라이언트 워크스테이션 운영체제 내에 신뢰할 수 있는 경로 메커니즘으로 공격을 예방할 수 있으며, 네트워크의 보호된 경로의 지원과 조합으로 사용자와 서버 응용 프로그램 사이의 신뢰할 수 있는 경로를 제공하는 데 사용할 수 있다. 다른 문제점은 악의적인 소프트웨어가 파일 또는 암호 토큰에 대하여 접근하는 것을 들 수 있는데 이는 강제적인 보안 메커니즘을 이용하여 보호할 수 있다.

다. 네트워크 보안 프로토콜(Network Security Protocoles)

보통 네트워크 보안 프로토콜은 IPSEC과 SSL을 들 수 있다.

¡ IPSEC 네트워크 보안 프로토콜: IP 계층에 인증, 무결성 그리고 비밀성 서비스를 제공하는 것으로 IPSEC에 의한 키관리 서버와 응용 공간 암호를 제공하는데 이는 운영체제 내의 강제적인 보안 메커니즘이 요구된다.

¡ SSL: 키와 암호 알고리즘을 위한 인증, 무결성, 비밀성 서비스, 그리고 교섭 서비스를 제공하는 네트워크 보안 프로토콜로 커널의 변경 없이 응용 공간에 구현하는 프로토콜이다. 이도 역시 운영체제 내의 강제적인 보안 메커니즘이 요구된다.

이렇듯 안전한 채널을 제공하는 IPSEC과 SSL을 사용한다고 하여도 공격자가 말단의 호스트 중 하나를 통과하거나, 비보호 데이터를 직접 접근할 수 있다면, IPSEC, SSL에 의해 제공되는 보호는 단지 사람들의 눈을 속이는 것일 뿐이다.

라. 침입 차단(Firewalls)

네트워크 침입 차단 시스템은 두 네트워크 사이의 신뢰할 수 있는 경계를 정하기 위한 메커니즘이다. 이는 프록시 서버(Proxy Server) 를 보호하기 위해서는 bastion host들의 운영체제 내에서 강제적인 보안 메커니즘이 통과하는 것을 제한되게 하여 프록시 서버를 안전하게 하는 데 사용되며, bastion host 의 강제적인 보안 메커니즘은 부정적인 변경에 대해 프록시 서버를 보호하는 데 사용된다. 그러나 악의 있는 내부자에 대해서는 보호가 불가능하므로 내부 호스트의 강제적인 보안 메커니즘으로 악의적인 내부자를 제한할 수 있다. 또한 내부자가 악의 있는 소프트웨어를 실행하는 것에 대한 보호는 불가능하므로, 내부 호스트 운영체제 내에 강제적인 보안 메커니즘으로 제한하여야 한다.

4. 주요 기능 효과

가. 강제적인 보안

¡ 응용 프로그램의 우회를 방지하고 부정 변경을 막을 수 있다.

¡ 허가되지 않은 암호 요소의 사용에 대한 보호가 가능하다.

¡ 다른 사용자 응용 프로그램으로부터 암호 요소가 고립되거나 허가된 사용자에 의해 실행되는 신뢰할 수 없는 응용 프로그램의 고립이 가능하다.

¡ 초기 키와 암호 요소의 코드 및 데이터 보호가 가능하다.

나. 신뢰할 수 있는 경로

¡ 초기 키의 설정을 보호할 수 있다.

¡ 암호 요소의 오용에 대한 보호가 가능하다.

¡ 보호된 경로

¡ 악의 있는 소프트웨어가 암호 요소를 흉내낼 수 없도록 한다.

¡ 클라이언트를 식별하기 위한 암호 요소를 실행한다.

5. 시스템 보안

단일 기술의 보안 해결책으로는 전체 시스템의 완전한 보안 기능을 제공할 수는 없다. 즉 특정 응용의 보안 기능 없이 고도의 보안 운영체제 기술만 가지고는 완벽한 시스템 보안이 될 수 없다는 것으로, 예를 들자면 전자상거래 시스템에서는 각 트랜잭션에서 전자 서명을 요구하므로 보안 운영체제 기술 뿐만이 아닌 응용 수준의 보안 기술도 요구된다는 것이다.

그러므로 가장 좋은 시스템 보안 해결책은 보안 운영체제 기능에 의해 보호되는 트랜잭션 단위의 응용 공간 암호 메커니즘이다. 다만 운영체제 내에 은밀한 채널(covert channel) 기능은 심각한 기술적 도전이므로, 감사추적 및 탐지 메커니즘에 의한 감사 추적 로그와 침입 센서 등의 기술 개발이 중요시 되고 있다.

III. Secure OS 개발 현황

1. 미국의 개발 현황

미국의 경우 국가정보 기반구조 구축과 국방용으로 정부기관과 군사기관들이 사용하기 위해 정부 차원에서 기술개발을 진행중이며 NSA(National Security Agency) 주도 하에 1994년까지 Secure OS 개발 타당성 조사를 마치고, 1995년부터 Secure OS를 개발하고 있다.

가. 연도별 주요 성과 및 사업 목표

¡ 1995년

- Synergy 프로젝트의 초기 보급용 프로토타입 개발을 완료하였고 공동연구를 위해 NIST 및 각 대학들에 배포하였다.

- 네트워크 보안 서비스 프로토타입의 초기 단계 구현으로 네트워크를 통한 두 호스트간의 기본적인 접근제어 기술을 구현하였다.

- 인터넷 보안 관련 키관리 프로토콜을 Synergy 네트워크 보안 서버에 이식하였다.

- 직무 기반 접근 제어(Role Based Access Control) 구현을 시작하였다.

¡ 1996년

- Synergy 프로젝트의 두번째 소프트웨어를 보급하였다.

- 보안, 보증(Assurance), 생산성, 가용성 그리고 분산 및 실시간 운영체제 환경에 대한 이식성을 높혔다.

- 보안 관리와 Synergy 요소들을 좀더 개선된 버전으로 개발하고 데모하였다.

- 계속적인 Synergy 구조에 대한 연구와 연구 결과의 기술 이전을 성공적으로 하였다.

- 상업적 기업과 국방성과 같은 정부기관의 보안 요구사항을 만족시킬 수 있는 Synergy 시스템 개발을 위해 상업적 생산업체들과의 공동으로 연구하였다.

¡ 1997년

- 네트워크를 거치는 보안 서비스를 관리할 수 있는 보안 서버를 데모하였다.

- 완전한 암호 서버 프로토타입을 데모하였다.

- 교섭(negotication) 서버 프로토타입을 완료하였고 데모하였다.

- 사용자가 좀더 친숙하게 운영체제에 접근할 수 있도록 하기 위한 윈도우 시스템을 사용한 데모를 하였다.

¡ 1998~1999년 여름

- Synergy의 후속 과제로 Fluke 마이크로 커널에 보안 기능을 강화한 Flask(Fluke Security Kernel) 연구 과제가 수행되었다. Flask 시스템의 목표는 다양한 보안 정책을 수용할 수 있는 유연성(Flexibility)을 제공하는 데 있다.

¡ 1999년 9월 ~

- Secure Linux 개발을 수행하고 있다. Flask Security Architecture를 Linux 커널에 통합하여 구현하는 중이다.

- 1999년 9월에 구현을 시작하여 2000년 6월에 공식 release할 예정이었으나 아직 release 안되고 있는 상황이다.

2. 민간 업체 개발 현황

Secure OS는 정보기관이나 국방관련 기관 뿐만 아니라 금융기관, 정부기관, 병원, 정보통신 회사 등 정보보호가 중요시되는 기관을 주요시장으로 하고 있으며 각급 기관들이 인터넷 등을 통한 외부 사이트와의 접속으로 인해 보안 위협 및 Secure OS의 필요성이 대두되고 있다.

IV. Secure OS 개발 사례

Secure OS 개발 사례는 III장에서와 같이 미국 등 각 선진국의 정부 및 민간 업체에서 많이 이루어지고 있으나 Secure OS의 특성상 공개되는 것을 꺼려하므로 미국 정부 주도하의 몇 가지 개발 사례를 제외하고는 그 기술적인 내용을 분석하기가 힘들었다. 그 중 통합 커널의 경우에는 UNICOS MLS 를 들고, 마이크로 커널의 경우에는 미국 정부 주도 하의 Synergy와 Flask 프로젝트의 Secure OS와 EROS 운영체제의 개발 사례를 분석하였다.

1. 통합 커널- UNICOS MLS

CRAY 사의 Secure OS로 Cray UNICOS 9.0 기반의 운영체제에 다중 수준의 보안 기능을 추가하였다. 이는 TCSEC 의 B2 등급을 만족하여 참조 모니터(Reference Monitor) 개념으로 구현하였다.

가. 네 가지의 보안 개념 만족

¡ 허가되지 않은 시스템 접근을 방지

¡ 허가되지 않은 데이터 객체 접근을 방지

¡ 시스템 자원의 과다한 사용을 방지

¡ 시스템 무결성의 손실을 방지

나. 보안 정책

¡  BL&P(Bell & LaPadula) 보안 모델 적용

- MAC을 사용하기 위해 simple security property 적용

- MAC을 사용하기 위해 *_property 적용

- DAC 을 사용하기 위해 discretionaty security property 적용

¡ Login 정책

- Trusted login

- SecureID 카드를 사용하여 Remote login을 할 수 있게 한다.

다. MLS 특징

¡ 객체의 계층적 보안 등급: 주체가 접근할 객체들은 다음 (그림 1)과 같이 계층적인 보안 등급을 갖는다.

¡ 객체의 컴파트먼트(Compartment or Category): 주체가 접근할 객체들의 집합인 부서 또는 범주라고 하는 비계층적인 컴파트먼트를 갖는다. 이는 다음 (그림 2)와 같다.

¡ MLS 특징

2. Synergy(DTOS)

미국 NSA 주도 하에 개발되었던 차세대 운영체제 개발로 강력하고 유연성 있는 보안 통제 기능을 갖는 Synergy 프로젝트 중의 일부이다. 1997년 7월에 완료되었고 그 설계 원칙은 유연성(Flexibility), 투명성(Transparency), 모듈성(Modularity) 그리고 계층적 보안(Layered Security) 이다.

¡ 유연성: 위협 환경에 따라 구성 가능한 보안 서비스, 메커니즘에 독립적인 보안 서비스 그리고 일반 보안 API 내에 캡슐화된 보안 서비스/메커니즘

¡ 투명성: 운영체제 기반 구조에 통합된 보안, 자동적으로 시작되는 보안 서비스 그리고 자동화된 보안 관리 기능

¡ 모듈성: 독립적으로 평가될 수 있는 모듈로 분해된 구조, 모듈간에 잘 정의된 인터페이스 및 상호독립성 그리고 모듈의 구성에 대해 판단할 수 있는 능력

¡ 계층적 보안: 가능한 많은 위협을 처리할 수 있는 기본 시스템 구성 요소 그리고 다른 TCB 구성 요소 상에 최소한으로 증명된 의무

가. 주 타스크

¡ 안전한 마이크로 커널 프로토타입 개발: 유연한 보안 메커니즘을 제공하는 많은 다른 환경에서 안전한 시스템을 위한 기반이 될 마이크로 커널 개발, 보안 메커니즘에 의한 성능 감소를 최소화한다.

¡ 마이크로 커널을 위한 보증 기술 연구 수행: 정책 유연성 목표를 지원하기 위한 유연성 있는 보안 정책 모델을 개발하고 분리된 시스템 요소 개별 분석을 위한 구체적인 접근 방식 개발한다. 또한 시스템 내의 정보 흐름을 분석하는 새로운 기술을 개발한다.

나. Synergy 구조

Synergy 구조는 마이크로 커널 기반 구조인 (그림 4)로 보안 정책 서버, 암호 서브시스템, 인증 서브시스템으로 구성된 보안 서비스 서브시스템으로 구성되어 있으며, 구성 가능한 네트워크 및 파일 서비스 구조를 가지고 있다. 마이크로 커널 기반 구조를 사용하는 이유는 위에서 언급한 Synergy 설계 원칙을 만족시키기 위한 것이다. 메커니즘과 정책간의 분리를 강조함으로써 유연성을 제공할 수 있다. 또한 마이크로 커널에 의해 많은 위협을 투명하게 처리할 수 있다. 또한 orthogonal 서버로 운영체제를 분해함으로서 모듈성을 제공하며, 마이크로 커널이 운영체제 서버의 활동들을 제한함으로써 계층화된 보안을 제공할 수 있다.

보안 정책 서버는 강제적 접근 통제(MAC)을 제공하기 위한 것이며, MAC의 세부항목(마이크로 커널, 파일 서비스, 네트워크 서비스, 응용)으로부터 정책 시행자를 분리 시키므로써 MAC 정책이 변경되었을 경우, 변경된 부분만을 재평가함으로써 비용을 줄일 수 있다.

암호 서브시스템은 암호 기능을 제공하기 위한 것으로 암호사용 정책과 암호 메커니즘에 대한 내용을 다룬다. 암호알고리즘의 세부 항목(파일 서비스, 네트워크 서비스, 응용)으로부터 클라이언트를 분리 시키므로써 암호 기능의 변경 시에 비용을 줄일 수 있다.

다. DTOS 구조

DTOS 의 접근 방법은 모든 커널 동작을 통제하는 일반적인 메커니즘을 제공하므로써 커널 엔티티를 통하여 정의된 많은 정책을 허용하는 것이다. 이 방법의 이점은 상위 계층에서 보안 특성이 침투 당하더라도 방어하는 다른 계층을 제공할 수 있다는 것이다. 예를 들면, KeyKOS/ KeySAFE 및 TrustedMach 는 서버 계층의 단일 보안 유지가 실패하면 침입자에게 금지된 많은 오퍼레이션을 수행할 수 있는 기회를 제공한다. 이것을 전체 보안을 파괴하는 결과를 초래할 수도 있다.

이 이외에도 커널 기반 구조를 채택하므로써 얻을 수 있는 이점으로는 안전한 서버와 응용 내에서 보안 기능을 쉽게 개발할 수 있으며, KeyKOS/KeySAFE나 TrustedMach 처럼 특정 보안정책에 국한되지 않고 일반적인 모드 커널 엔티티의 보호를 위한 단일 모델을 제공할 수 있다.

보안정책의 유연성과 Localization의 지원을 위해 DTOS구조는 다음 (그림 5)와 같이 보안정책 시행과 보안정책 의사결정 간에 엄격한 분리를 제공한다. 그리고 DTOS 커널은 모든 커널 내의 동작을 클라이언트의 접근통제에 대한 보안 서버로부터 허가 여부를 참조하여 보안 정책을 시행한다.

라. DTOS 프로토타입

¡ Secure computing Corporation에서 개발: 수정된 Mach 커널과 외부 보안 서버

¡ 두 개의 새로운 제어 메커니즘을 추가

- IPC 제어: 포트 권한 처리를 위한 통제 확장 기능 제공하여 정책 기반 제어 수행을 위해 포트 권한을 이전하는 데 사용한다.

- 객체 서비스 제어: 개별 객체 서비스를 통해 제어하는 정책 기반 제어를 정하는 포트 권한 능력을 확인하며 모든 커널 객체에 관계된 개별 서비스 제어 기능을 제공한다.

¡ 커널에 두 개의 새로운 인터페이스 추가

- 보안 서버: Mach 커널과 보안 서버 사이의 새로운 인터페이스를 구현하였고, 수행 메커니즘과 보안 정책 결정을 엄격하게 분리하였으며 단일 시스템 요소 내의 보안 정책을 지역화하였다.

¡ 커널 제어 메커니즘

클라이언트 타스크가 커널 객체 서비스에 서비스를 요구하면 커널 객체 서버가 서비스를 초기화하기 전에 접근 가능한가 허용을 확인하여 성공적이면 서비스를 초기화한다. 물론 허용을 확인할 때는 커널 접근 벡터 캐쉬로부터 요구자의 식별과 허가 정보를 받는다. 이러한 모든 것들은 포트를 이용하여 IPC로 이루어진다.

¡ 외부 객체 서버 제어

커널 바깥에 있는 외부 객체 서버의 경우에는 위의 경우에서 처럼 보안 서버를 통하지 않고 클라이언트 타스크가 요구하는 서비스에 의해 Access vector cache 의 정보를 이용하여 사용자를 식별하고 permission 정보를 이용하여 사용 허가를 확인한다. 이에 따라 외부 객체 서버 타스크에서 서비스 요구를 받아 처리한다.

 3. Flask(Fluke Security Kernel)

Flask 과제는 Synergy 과제의 후속으로 미국 Utah 대학의 Flux 프로젝트에서 개발된 Fluke (Flux u-kernel Environment) 마이크로 커널 프로토타입에 보안 기능을 강화하는 프로젝트이다. Flask 연구 과제는 DTOS(Distributed Trusted Operating System) 연구 과제와 DTMach (Distributed Trusted Mach) 연구 과제와 연속성을 띠고 있으며 그 목표와 보안구조에 있어서 상당한 유사성을 가지고 있다. Utah 대학 Flux 팀과 미국방부(DoD) 협력 하에 개발되었으며 DARPA에 의해 일부 지원되고 DoA와 AFRL에 의해 관리되었다.

가. Flask의 연구 목표

¡ 다양한 보안 정책을 수용할 수 있는 유연성 지원

- 보안 정책에 의해 통제되는 고수준 함수들이 사용하는 저수준 객체들에 대한 적절한 접근 통제가 이루어져야 한다.

- 접근 권한이 보안정책과 정확히 일치해야 한다.

- 정책은 동적이어야 한다.

¡ 정책 수행 메커니즘 자체 및 수행 메커니즘과 보안 정책 사이의 문제에 중점을 두고 보안 정책의 유연성을 부여한다.

나. Flask 연구 목적

¡ 보안 정책 유연성(Flexibility)

¡ 응용 프로그램 투명성(Application Transparency)

¡ 높은 보안 수준(Defense-in-depth)

¡ 쉬운 보증(Ease of assurance)

¡ 관련 정책 변화에 따른 최소한의 코드 변환

다. 보안 구조 요구사항

¡ 객체들에 대한 모든 접근을 중재할 수 있는 주체와 객체간의 분리

¡ 객체에 대한 접근을 시도하는 주체에 대한 안전한 신분확인기능 제공

라. Fluke 구조

Fluke 구조는 다음 (그림 6)과 같다. Fluke의 특징 중의 하나는 내포 프로세스 모델이 적용되었다는 것이다. 기존의 유닉스 시스템에서는 부모 프로세스와 자식 프로세스간의 연계성이 미약하고 자식 프로세스가 소유하는 자원은 부모 프로세스와 독립적으로 운용 가능하게 되어 있으나 Fluke에서는 자식 프로세스가 소유하는 모든 자원에 대한 통제권을 부모 프로세스가 가진다. 또한 자식 프로세스에 대한 모든 서비스는 부모 프로세스를 통하여 이루어진다. 부모 프로세스가 통제 가능한 자원은 코드, 데이커, 힙(Heap), 스택(stack), 스래드(thread) 등을 포함한다.

라. Flask 구조

기본적인 Flask 구조는 (그림 7)과 같이 파일 관리자, 프로그램 관리자 등과 같은 객체 관리자(object manager)와 보안 서버(Security Server)로 구성된다. 객체 관리자는 시스템의 제어 동작을 제공하고 보안 서버는 특정 보안 정책에 대한 보안 결정을 담당한다. 객체 관리자는 그러한 보안 결정에 대한 수행을 담당한다. 특정 보안 정책이 요구되어 보안 정책에 대한 변경 사항이 필요하다 하더라도 객체 관리자는 보안 정책에 대해 독립적으로 운영되면 보안 서버만이 특정 보안 정책을 반영하기 위해 변경될 수 있다.

마. Flask 설계 및 구현

Flask 프로토타입은 Fluke 마이크로 커널 기반 운영체제로부터 파생되었다. Flask 구조가 마이크로 커널 기반의 시스템에 국한된 것은 아니지만 마이크로 커널 기반 시스템은 보안, 보증성 및 유연성 관점에 대한 장점이 있다. 마이크로 커널에 대한 해결되지 않은 성능 논쟁에도 불구하고 이러한 장점으로 인해 많은 시험이 이루어졌다. 마이크로 커널의 보안 기능 수행 메커니즘은 많은 위협들에 대하여 마이크로 커널이 직접 처리할 수 있고 서버의 보안 취약점이 발생할 경우에도 강도 높은 보호 수준(defense in-depth)을 제공한다. 마이크로 커널은 각 객체 관리자들이 상호작용을 함에 따라 발생 가능한 보안상의 문제점으로 인해 각 객체 관리자간의 상호신뢰에 제한을 둔다. Flask를 구성하는 각 요소별 기능 및 특징은 나중에 다른 문서로 자세히 기술하겠다.

4. EROS(Extremely Reliable Operating System)

EROS 는 마이크로 커널 기반의 빠른 capability 시스템이다. 이는 단일 수준의 스토리지 모델의 Capability 기반의 마이크로 커널 기반으로 KyeKOS로 알려진 GNOSYS 구조의 세번째 구현결과물이다. TymShare, Inc. 에 의해 만들어 졌다.

GNOSYS의 목표는 안전한 시분할을 지원하며 상호 배타적인 사용자들 사이에 제어된 공동 작업을 지원하는 것이다.

첫번째 GNOSYS 컨널은 PL/1 응용 코드의 370 어셈블러 언어로 구현이 되었으며, 두번째 GNOSYS 커널은 1980년 후반에 모토롤라 88000을 위한 C 언어로 재구현되었다. 세번째 GNOSYS 는 X86 시스템을 위한 C++ 코드로 재구현되었다.

가. Capabilities

Capability란 객체식별자와 그 객체에 대한 허가된 동작(인터페이스)의 집합으로 구성된 쌍(pair)으로 예를 들자면 Unixdptj 파일 디스크립터와 같다. Capability system은 각 프로세스가 capabilities를 소유하고 Capability에 의해 허가된 동작만을 수행할 수 있다.

여기에서 보안은 다음 세 가지 조건에 의해 보증이 된다. 첫째는 capabilities는 위조할 수 없으나, 변경은 가능하다. 둘째는 프로세스가 허가된 인터페이스 사용에 의해서만 capabilities를 얻을 수 있다는 것이다. 마지막으로 capabilities 는 그것을 갖도록 허가된 프로세스에게만 주어진다. 이에 따라 Protection Domain 이란 개념을 갖는 이는 한 서브시스템에 접근 가능한 Capability 들의 집합을 말한다.

나. EROS 구조

¡ 커널

- 커널은 소량의 primitive capability 타입들로 구현된다. 예를 들자면 numbers, nodes, data pages, capabilities pages, processes, entry and resume capabilities, 그리고 소수의 기타 커널 서비스들로 구현되어 있다.

- 또한 시스템 서비스 모음을 갖는다. Non-privileged 응용에 의해 구현되었으며 파일, 디렉토리 그리고 메모리 객체와 같은 고수준의 추상을 제공한다.

EROS 기본 추상화 및 구현 기술은 상용 하드웨어 상에서 효율적인 Capability 개념을 구현한 시스템 기술이다. 리눅스와 비교한 마이크로 벤치마크 성능 측정에서도 약간 나은 것으로 보이며 사용자 수준의 폴트 핸들링과 사용자 수준의 스토리지 할당도 성능에 무리를 주지 않는 것을 볼 수 있다. 현재 EROS 시스템은 펜티엄 하드웨어 상에 동작하고 있으며 시스템의 다양한 enhacement 작업을 진행중이며 EROS 상용 결과물은 개발중이다.

V. 결 론

본 고에서는 Secure OS의 기술 동향을 소개하였다. 미국을 비롯한 정보보호 기술 선진국의 경우 단일 시스템 내부에서의 보안성 강화는 물론 네트워크, 데이터베이스 등의 정보자원 보호에 대한 총체적인 솔루션을 제공하기 위해 노력하고 있으며 그 노력은 일반 기업체는 물론 정부 차원에서도 활발하게 진행되고 있다. 또한 미국의 경우, 정보보호의 기반이 되는 운영체제 보안 기술은 Synergy 연구 과제의 핵심임 DTOS 개발의 명맥을 이어 Flask 프로젝트의 형태로 지속적이고 활발하게 이루어졌으며 최근 들어 리눅스에 보안 서버를 이식하는 작업을 진행하고 있다. 이러한 동향에 힘입어 우리나라에서도 Secure OS 기술의 적극적인 연구와 개발이 요구된다. 추후에는 리눅스를 기반으로 Secure OS 기술을 개발하는 현황을 소개할 예정이다.

<참 고 문 헌>

[1]   Peter A. Loscocco, Wtephen D. Dmalley, Patric A. Muckelbauer, Ruth C. Taylor, S.Jeff Truner, John F. Farrel, The Inevitablility of Failure: The Flawed Assumption of Security in Modern Computing Environments, National Security Agency, 1997.

[2]   Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, Dave, Anderson, and Jay Lepreau, The Flask Security Architecture : System Support for diverse Security Policies, Proceeding of the 8^th USENIX Security Symposium, 1999.

[3]   UNICOS Multilevel Security(MLS) Features User’s Guide, SG-21111 10.0, http://rcs21.urz.tu-dresden.de:80/ebt-bin/nph-dweb/dynaweb…/@Generic__BookTextVie

[4]   http://www.hpcc.gov/pubs/blue97/nsa/secureos.html

[5]   http://www.cs.utah.edu/flux/fluke/html/linux.html

[6]   DOD 5200.28-STD. Department of Defense Trusted Computer System Eval‎udation Criteria, December 1985.

[7]   D.Ferraolo and R, Kuhn, Role-Based Access Control, Proceeding of the 15^th National Computer Security Conference, 1992.

[8]   S. Garfinkel. Web Security and Commerce. O’Reilly & Associates, Cambridge, 1997.

[9]   R. Graubart. Operating System Support for Trusted Applications, Proceedings of the 15^th National Computer Security Conference, 1992.

[10]  M. Harrison et al., Protection in Operating Systems. Communications of ACM 19(8), August 1976.

[11]  Secure Computing Corporation. Assurance in the Fluke Microkernel:: Formal Security Policy Model, Technical report MD A904-97-C-3047 CDRL A003, March 1998.

운영체제 보안 기술 동향.docx