KR20010090297A - 보안 정책 시스템 - Google Patents

Abstract

보안 정책 시스템이 개시된다. 본 보안 정책 시스템은 소정의 보안 정책 프로토콜(SPP)에 따라 정책 정보를 요청하는 정책 클라이언트와, 상기 보안 정책 프로토콜(SPP)을 사용하여 상기 정책 클라이언트와 다른 서버들로부터 수신된 질의 메시지를 처리하여 적절한 정책 정보를 요청자에게 제공하는 정책 서버와, 특정 보안 영역의 지역 정책들과 그 보안 영역에 관한 특정 정보들을 저장하는 마스터 파일, 및 정책 정보들을 유지하는 복수 개의 보안 정책 정보 데이터베이스를 포함하여, 호스트와 보안 게이트웨이 사이에서 안전한 통신 설정을 위해 필요한 보안 정책 정보를 제공하는 분산 시스템으로서 동작하는 것을 특징으로 한다.

본 발명에 따르면 보안 영역에 따라 다르게 정의된 정책 정보들에 대한 중앙 집중적인 관리와 협상을 가능하게 한다.

Description

보안 정책 시스템{Sequrity policy system}

본 발명은 보안 정책 시스템에 관한 것으로, 더 상세하게는 보안 영역에 따라 다르게 정의된 정책 정보들에 대한 중앙 집중적인 관리와 협상을 가능하게 하는 보안 정책 시스템에 관한 것이다.

IP(internet protocol) 보안 프로토콜은 RFC(Request For Command)-2409 표준에 의하여 규정된 인터넷 키 교환(Internet Key Exchange: IKE) 방법을 사용하여 키 값을 교환하고, IP 데이터에 대한 인증 및 무결성을 제공하기 위하여 RFC-2402 표준에 의하여 규정된 IP 인증 헤더(Authentication Header: AH)나 RFC-2406 표준에 의하여 규정된 IP ESP(Encapsulating Security Payload) 프로토콜을 사용한다. 인터넷 키 교환 방법을 사용하는 경우에는 발송지(source)와 목적지(destination) 사이에서 키 값을 교환하고 이들 사이에서 교환되는 데이터들에 대한 보안을 수행할 수 있다. IP 보안시스템(IPSec)에서는 각 보안 영역과 보안 시스템이 구현된 제품에 따라 서로 다른 보안 정책을 정의하여 사용한다. 보다 구체적으로, IP 보안시스템(IPSec)은 서로 다른 보안 영역의 통신 상대와 통신하거나 다른 보안 영역을 통하여 통신하는 경우, 각 보안 영역에 따라 자신들 고유의 지역 정책을 사용한다. 따라서, IP 보안시스템(IPSec)을 사용하여 종단 노드들 사이에서 IP 패킷을 송수신하는 경우에 다음과 같은 문제점이 발생할 수 있다.

첫 번째로, 보안 영역들 사이의 정책 요구가 서로 다르다. 통신 경로 상의 보안 게이트웨이나 라우터 필터와 같은 중간 노드에서의 정책 제약이 다르기 때문에 전송된 패킷이 목적지까지 전달되지 않는 경우가 발생될 수 있다는 문제점이 있다. 즉, 통신의 중간 노드들은 자신의 지역적 관리에 따라 패킷을 처리할 수 있으며, 그 내용은 종단 노드들에게 알려질 필요가 없다. 하지만, 패킷의 폐기와 같은 패킷의 전송에 영향을 주는 경우에는 종단노드들에게도 알려져야 한다.

두 번째로, 망의 토폴로지가 복잡함으로 인하여 패킷이 양방향으로 동일한 경로를 따라 전송되고 동일한 정책을 사용하여 보호되는지를 보장할 수 없다는 문제점이 있다. 예를들면, 인터넷에 접속되어 있는 서브넷(subnet)이나 호스트 등이 급증함으로 인하여 IP 패킷이 목적지까지 도달하는데 까지는 다양한 경로가 존재한다. 따라서, 각 경로가 다른 정책을 사용함으로 인하여 패킷이 한 방향으로는 보호되고 반대 방향으로는 보안 서비스를 받지 않은 평문의 패킷으로 리턴될 수 있다.

세 번째로, 종단 노드들 사이에서의 보안 서비스가 복수 개의 SA(Security Association)들로 이루어진 SA 번들(bundle)에 의하여 수행될 수 있는데, 종단 노드에 의하여 하나의 서비스 단위로 정의되어 사용되는 SA 번들 정보가 중간 노드들에게 알려지지 않음에 따라 SA 번들이 개별적인 SA들로 나뉘어져 처리될 수 있다는 문제점이 있다.

또한, IP 보안 프로토콜에 따라 동작하는 종단 노드나 게이트웨이들은 보안 서비스 제공을 위해 협상하고, 만일 협상이 실패하면 수동 중재의 과정을 거친다.하지만, 최근 더 많은 노드가 IP 보안을 구현함에 따라 수동 중재가 여려운 경우가 많다는 문제점이 있다.

본 발명이 이루고자 하는 기술적 과제는 보안 영역에 따라 다르게 정의된 정책 정보들에 대한 중앙 집중적인 관리와 협상을 가능하게 하는 보안 정책 시스템을 제공하는 것이다.

도 1은 본 발명의 실시예에 따른 보안 정책 시스템의 구성 요소들을 도시한 블록도이다.

도 2는 도 1의 보안 정책 시스템의 동작을 설명하기 위한 도면이다.

도 3은 본 발명에 따른 보안 정책 시스템을 IP 보안시스템(IPsec)과 함께 사용하는 실시예를 도시한 도면이다.

도 4는 보안 정책 시스템이 IP 보안시스템(IPSec)과 어떻게 동작하는지를 초기 응용이 수행되는 것부터 필요한 SA 설정까지의 과정을 단계별로 나타낸 도면이다.

도 5는 보안 정책 시스템과 IP 보안시스템(IPSec) 사이에서 교환되는 정보를 나타낸 도면이다.

도 6a는 본 발명에 따른 보안 정책 시스템을 종단간 보안에 적용한 경우의 동작 환경을 나타낸 도면이다.

도 6b는 본 발명에 따른 보안 정책 시스템을 기본적인 가상사설망(VPN)이 지원되는 종단간 보안에 적용한 경우의 동작 환경을 나타낸 도면이다.

도 6c는 본 발명에 따른 보안 정책 시스템을 가상사설망(VPN)이 지원되는 종단간 보안에 적용한 경우의 동작 환경을 나타낸 도면이다.

도 6d는 본 발명에 따른 보안 정책 시스템을 원격 접근(remote access)에 적용한 경우의 동작 환경을 나타낸 도면이다.

상기 과제를 이루기 위하여 본 발명에 따른 보안 정책 시스템은 소정의 보안 정책 프로토콜(SPP)에 따라 정책 정보를 요청하는 정책 클라이언트; 상기 보안 정책 프로토콜(SPP)을 사용하여 상기 정책 클라이언트와 다른 서버들로부터 수신된 질의 메시지를 처리하여 적절한 정책 정보를 요청자에게 제공하는 정책 서버; 특정 보안 영역의 지역 정책들과 그 보안 영역에 관한 특정 정보들을 저장하는 마스터 파일; 및 정책 정보들을 유지하는 복수 개의 보안 정책 정보 데이터베이스;를 포함하여, 호스트와 보안 게이트웨이 사이에서 안전한 통신 설정을 위해 필요한 보안 정책 정보를 제공하는 분산 시스템으로서 동작하는 것을 특징으로 한다.

또한, 상기 정책 서버는, 상기 정책 정보가 상기 클라이언트와 상기 서버에 의해 어떻게 교환되고, 처리되고, 보호되는지를 정의한 소정의 보안 정책 프로토콜(SPP)을 사용하여 상기 정책 클라이언트와 다른 정책 서버들로부터의 질의(Query) 메시지를 수신하여 처리하고 적절한 정책 정보를 요청자에게 제공하는 것이 바람직하다.

또한, 상기 정책 서버는, 요청자에 대한 접근 제한 규칙에 근거하여 정책 정보를 제공하는 것이 바람직하다.

또한, 상기 정책 서버는, 수신된 지역 및 비지역 정보에 의하여 보안 정책 데이터베이스를 유지하는 것이 바람직하다.

또한, 상기 마스터 파일은, 누가 보안 영역을 책임지고 있는지를 가리키는 정보와 마스터 파일 내의 정보의 무결성과 인증을 검증하기 위해 사용되는 공유 키에 대한 포인터를 포함하는 것이 바람직하다.

또한, 상기 보안 정책 데이터베이스는, 특정 보안 영역에 대한 모든 정책들을 포함하며 보안 영역의 마스터 파일로부터 오는 정보와 함께 놓이는 지역 정책 데이터베이스; 다른 보안 영역들로부터 수신된 지역 정책들 및 비지역 외부 정책들을 포함하며 상기 외부 정책들은 정책 결정 처리를 통해 병합되는 캐쉬 데이터베이스; 및 보안 영역의 일부인 모든 호스트들, 보안 게이트웨이들, 그리고 정책 서버들의 리스트를 포함하는 보안 영역 데이터베이스를 포함하는 것이 바람직하다.

또한, 상기 마스터 파일내에 저장되는 특정 정보는, 특정 마스터 파일 내의 정책 정보를 생성, 삭제 및 수정하는 권한이 있는 엔터티를 정의하는 유지자(maintainer) 정보; 상기 유지자(maintainer) 정보에 의해 참조되는 하나 이상의 인증서인 인증서(Certificate) 정보; 특정 보안 영역에 대한 주요 부 정책 서버의 신원을 기술하는 정책 서버 정보; 첨부된 정책들을 갖는 인터페이스 집합을 지정하는 노드 정보; 특정 보안 영역의 정책을 실행하는 호스트와 연관된 인터페이스 집합을 지정하는 게이트웨이 정보; 영역에 속한 노드들, 보안게이트웨이들 및정책 서버들에 의해 보안 영역들을 정의하는 영역 정보; 및 정책들의 순서화된 집합을 나타내는 정책 정보;를 포함하는 것이 바람직하다.

또한, 상기 마스터 파일은, 보안 영역의 일부인 노드들의 리스트. 보안 영역을 보호하기 위한 보안 게이트웨이들의 리스트; 및 보안 게이트웨이들에 의해 실행되는 정책 규칙들과 노드에서 실행되는 정책 규칙들의 리스트;를 포함하는 것이 바람직하다.

또한, 상기 보안정책 프로토콜은, 정책 정보에 대한 특정 요청을 포함하고, SPP 헤더, 하나 이상의 질의 페이로드, 및 필요한 경우에는 0 이상의 레코드 페이로드 전자서명을 포함하는 질의 메시지(SPP-QUERY); 특정 정책 질의에 응답하기 위하여 사용하고, SPP 헤더, 하나 이상의 질의 페이로드, 및 0 이상의 레코드 페이로드 전자서명을 포함하는 응답 메시지(SPP-REPLY); 정책 서버에서/로부터 보안 정책을 업로드/다운로드하기 위하여 사용하고, SPP 헤더, 하나 이상의 레코드 페이로드, 및 서명 페이로드를 포함하는 정책 메시지(SPP-POL); 정책 메시지의 승인에 사용하고, SPP 헤더 및 서명 페이로드를 포함하는 정책 승인 메시지(SPP-POL_ACK); 서버들 사이에서 정책 정보를 교환하기 위하여 정책 서버들에 의하여 사용되고, SPP 헤더, 하나 이상의 레코드 페이로드 및 서명 페이로드를 포함하는 전송 메시지(SPP-XFR); 및 보안 게이트웨이나 모니터링 장치에게 서버의 상태를 알리기 위하여 사용하고, SPP 헤더 및 서명 페이로드를 포함하는 킵얼라이브(KeepAlive) 메시지(SPP-KEEP_ALIVE);를 정의하여 사용하는 것이 바람직하다.

이하 첨부된 도면들을 참조하여 본 발명의 바람직한 실시예들을 상세히 설명하기로 한다.

도 1에는 본 발명의 실시예에 따른 보안 정책 시스템의 주요 구성 요소들을 블록도로써 나타내었다. 도 1을 참조하면, 본 발명의 실시예에 따른 보안 정책 시스템(10)은 각 보안 영역에 대해 정책 정보의 요청에 응답하는 정책 서버(Policy Server: 102), 정책 정보를 요청하는 정책 클라이언트(Policy Client: 104), 보안 영역의 고유 정보를 저장하는 마스터 파일(Master File: 106), 및 보안 정책 데이터베이스(108)를 구비한다. 마스터 파일(106)에는 특정 보안 영역의 지역 정책 정보와 보안 영역에 관한 정보가 저장되어 있다. 여기서, 상기 마스터 파일(106)에 저장된 정책 정보의 순서가 가장 중요하다.

보안 정책 데이터베이스(108)는 보안 정책 시스템(10)의 정책 정보들을 유지한다. 상기 보안 정책 데이터베이스(108)는 지역 정책 데이터베이스(미도시), 캐쉬 데이터베이스(미도시), 및 보안 영역 데이터베이스(미도시)를 구비한다. 지역 정책 데이터베이스는 보안 영역의 마스터 파일 내에 표현되는 정책들을 포함한다. 캐쉬 데이터베이스는 보안정책시스템 교환(exchange)에 의하여 학습된 비지역(non-local) 정책들을 포함한다. 보안 영역 데이터베이스는 보안 영역의 부분들인 호스트, 보안 게이트웨이 등의 목록을 포함한다.

상기와 같은 본 발명의 실시예에 따른 보안 정책 시스템의 동작을 설명한다. 이하에서는 본 발명의 실시예에 따른 보안 정책 시스템과, 상기 보안 정책 시스템(10) 내에 구비되는 정책 서버(102) 및 정책 클라이언트(104) 사이에서 정책 정보를 교환하기 위해 사용되는 보안 정책 프로토콜(SPP: Security PolicyProtocol)과, 상기 보안 정책 프로토콜(SPP)에 의해 교환되는 정책 정보들의 연관성 제거 처리 과정, 및 정책 결정 처리 과정을 설명하기로 한다.

도 2에는 도 1의 보안 정책 시스템의 동작을 설명하기 위한 도면을 나타내었다. 도 2는 수시로 참조된다. 보안 정책 시스템의 정책 서버(202)와 정책 클라이언트(222)는 보안 정책 프로토콜(SPP)을 사용하여 메시지를 교환함으로써 외부로부터의 정책 정보 요청에 응답한다. 먼저, 정책 클라이언트(222)나 다른 정책 서버들 중의 하나는 소정의 보안 정책 프로토콜(SPP)에 따라 정책 서버(202)에게 질의 메시지와 같은 형태의 정책 정보 요청을 발송한다.

정책 서버(202)는 소정의 보안 정책 프로토콜(SPP)에 따라 다른 정책 클라이언트(미도시)와 다른 정책 서버들(미도시)로부터 질의 메시지와 같은 형태의 정책 정보 요청을 수신하여, 그것을 처리하고 요청자의 접근 권한에 따라 적절한 정책 정보를 생성한 후 요청자에게 제공한다. 이때, 정책 서버(202)는 요청자에 대한 접근 제한 규칙에 기초하여 정책 정보를 제공하며, 수신된 지역 및 비지역 정보를 사용하여 보안정책데이터베이스를 유지한다

정책 클라이언트(222)는 외부 응용으로부터의 정책 정보 요청을 수신한 후 정책 정보를 요청하는 질의 메시지를 생성하여 정책 서버에게 송신하고, 정책 서버(202)로부터 제공된 응답(Reply) 메시지 형태의 정책 정보를 수신하여, 외부 응용에 의해 요구되는 적절한 포맷으로 변환하여 상기 외부 응용에게 전달한다. 정책 서버(202)와 정책 클라이언트(222)는 TCP 포트(212, 232)나 UDP 포트(214, 234) 501을 사용하여 메시지를 교환하며, SPP-XFR 메시지는 TCP 포트(212, 232) 만을 사용한다.

한편, 마스터 파일(210)은 보안 영역의 일부인 노드들의 리스트. 보안 영역을 보호하기 위한 보안 게이트웨이(SG)들의 리스트, 보안 게이트웨이들에 의해 실행되는 정책 규칙들과 노드에서 실행되는 정책 규칙들의 리스트들을 포함한다. 즉, 마스터 파일(210)은 누가 보안 영역을 책임지고 있는지를 가리키는 정보와 마스터 파일 내의 정보의 무결성과 인증을 검증하기 위해 사용될 수 있는 공유 키(public key)에 대한 포인터를 포함한다. 즉, 마스터 파일(210)은 특정 보안 영역의 지역 정책 정보들과 그 보안 영역에 관한 보안 영역 정보들을 포함한다. 지역 정책 데이터베이스(206)는 보안정책데이터베이스(204)로부터의 비지역 정책 정보들, 즉, 보안 영역 경계 밖의 정책들과 결합된다. 정보의 저장을 위한 포맷은 적절하게 설계될 수 있다.

또한, 마스터 파일(210)에는 인증서(Certificate) 정보, 유지자(maintainer) 정보, 정책 서버 정보, 노드 정보, 게이트웨이 정보, 영역 정보, 및 정책 정보들을 포함한 특정 정보들이 포함된다. 인증서(Certificate) 정보는 유지자(maintainer) 정보에 의해 참조되는 하나 이상의 인증서를 가리킨다. 이 인증서에서 발견되는 공유 키(public key)에 대응되는 비밀 키(private key)는 마스터 파일에 포함된 정보에 서명하기 위해 사용되고, 공유 키(public key)는 정보의 무결성과 출처의 확실성(authenticity)을 증명하기 위해 사용된다.

유지자(maintainer) 정보는 특정 마스터 파일 내의 정책 정보를 생성, 삭제 및 수정하는 권한이 있는 엔터티를 정의한 것이다. 정책 서버 정보는 특정 보안 영역에 대한 주요 부 정책 서버의 신원을 기술한다. 노드 정보는 첨부된 정책들을 갖는 인터페이스 집합을 지정하며, 보안 영역 내에는 적어도 하나의 노드가 있어야 한다. 게이트웨이 정보는 특정 보안 영역의 정책을 실행하는 호스트와 연관된 인터페이스 집합을 지정한다. 영역 정보는 영역에 속한 노드들, 보안게이트웨이들 및 정책 서버들에 의해 보안 영역들을 정의한다. 정책 정보는 정책들의 순서화된 집합을 나타낸다.

다음으로, 보안 정책 데이터베이스(108)에 대하여 기술한다. 보안 정책 시스템(SPS)에서, 모든 보안 영역은 그 영역에 대한 정책 정보를 포함하는 데이터베이스를 유지해야 한다. 보안 영역들은 하나의 작게는 호스트이거나 크게는 여러 개의 망이 될 수 있다.

보안정책데이터베이스(108)는 지역 정책 데이터베이스(206, 224), 캐쉬 데이터베이스(208, 226), 및 보안 영역 데이터베이스(204)의 3 종류의 논리적 데이터베이스를 구비한다. 이 3가지 데이터베이스들을 따로 구현할 필요가 없으나, 그들 각각에 포함된 정보는 존재해야 한다. 지역 정책 데이터베이스(206, 224)는 특정 보안 영역에 대한 모든 정책들을 포함하며, 보안 영역의 마스터 파일로부터 오는 정보와 함께 놓인다. 캐쉬 데이터베이스(208, 226)는 다른 보안 영역들로부터 수신된 지역 및 비지역 외부 정책들을 포함하며, 정책들은 정책 결정 처리를 통해 병합된다. 보안 영역 데이터베이스(204)는 보안 영역의 일부인 모든 호스트, 보안 게이트웨이, 그리고 정책 서버들의 리스트를 포함한다.

만일, 캐쉬된 항목이 만기가 된 후에 지역 데이터베이스 정책 정보로 캐쉬된정책 정보를 복귀하는 것이 불가능하기 때문에, 지역 정책 데이터베이스와 캐쉬된 데이터베이스는 개별적인 정책들의 집합을 유지해야 한다.

다음으로, 각 보안정책데이터베이스(108)의 기능과 요구사항에 대해 기술한다. 지역 정책 데이터베이스는 지역 정책을 포함하는 데이터베이스로써, 모든 정책 클라이언트와 모든 정책 서버는 이 데이터베이스를 유지한다. 클라이언트의 경우 정책을 미리 결정된 형태로 유지되다가 데이터베이스로 탑재되며, 이 데이터베이스는 "Security Architecture for the Internet protocol"라는 제목의 자료에서 정의된 것과 같을 수 있다.

또한, 지역 정책 데이터베이스는 그 보안 영역에 대해 마스터 파일에서 표현된 정책들을 포함하며, 각 정책 엔트리는 고유 식별자(ID), 만기 시간, 그리고 그 정책 구문에 적용하는 행위 구문을 포함한다. 보안 정책 프로토콜(SPP)에 의한 정책 처리와 관련하여, 구문 부분은 통신 보안 레코드에서 인코드하고, 행위 부분, 즉, IP 보안 관련된 행위는 SA 레코드에서 인코드한다.

한편, 데이터베이스 내의 정책들은 실행 과정에 영향을 미치지 알고 정책들에 대한 효과적인 재순서화와 조직화를 가능하게 하기 위하여 연관성이 제거되는 것이 보다 바람직하다. 정책의 연관성 제거는 외부 정책들의 캐쉬에도 용이하게 사용된다.

캐쉬 데이터베이스는 병합된 지역의 비지역 정책 데이터에 대한 캐쉬를 위한 데이터베이스이며, 모든 정책 클라이언트와 모든 정책 서버는 이 데이터베이스를 유지해야 한다. 비지역 정책들은 정책 클라이언트나 서버에서 미리 정의되지 않는정책들이며, 보안 정책 프로토콜(SPP)에 따른 메시지 교환에 의하여 얻어진다. 비지역 정책들은 지역 데이터베이스 정책들과 정책 결정 처리 과정을 거쳐 병합된다.

결과적으로, 병합된 정책들은 지역 정책들로부터 논리적으로 분리되어야 한다. 그런 후에 캐쉬된 데이터가 동일한 정책 정보에 대한 후속적인 질의 메시지에 응답하기 위해 사용될 수 있다. 각 정책 엔트리는 고유 ID, 만기 시간, 및 그 정책 구문에 적용하는 행위 구문이 뒤에 나오는 단일 정책 구문을 포함하는 것이 바람직하다. 또한, 정책 엔트리의 정책이 복수개의 종단점에서 실행되어야 한다면, 복수개의 정책 구문들을 포함할 수도 있다.

보다 바람직하게는, 정책 엔트리는 Assertion 정보와 Public keying material도 포함한다. Assertion) 정보는 정책 서버와 교환되는 정보 간의 관계를 나타내는 정보이다. Public keying material은 Assertion 정보를 검증하기 위한 것이다.

보안 정책 프로토콜(SPP)에 따른 정책의 처리와 관련하여, 서버 Assertion 정보들은 정책 서버에서 인코드되고, 인증서(certificates)는 인증서 레코드에서 인코드된다. 또한, 보다 바람직하게는, 정책 엔트리는 캐쉬 만료 시간을 포함한다.

또한, 캐쉬 데이터베이스 내의 정책들도 반드시 이상에서 설명한 바와 같은 이유로 연관성을 제거하여야 한다.

다음으로, 보안 영역 데이터베이스에 대하여 기술한다. 모든 정책 서버는 보안 영역에 대한 특성 정보가 저장되는 보안 영역 데이터베이스를 유지해야 한다. 포함되는 정보는 보안 영역 주변에서 정책을 실행하는 각 보안 게이트웨이의 신원을 포함한 리스트와, 보안 영역의 멤버인 노드들의 신원을 나타내는 엔트리이다.

정책 서버는 그들이 호스트에 관한 권한이 있음을 결정하기 위해 이 정보를 사용한다 . 또한, 정책 서버는 정보 수신자가 정책의 신뢰도(authenticity)를 검증하기를 원하는 신뢰 체인(chain of trust)을 침해하지 않고 그들이 보안 정책 프로토콜(SPP) 메시지 교환에 참여할 수 있는 지를 결정할 수 있다.

이제, 보안 정책 프로토콜(SPP)에 대하여 기술한다. 보안 정책 시스템의 정책 클라이언트와 정책 서버가 보안 정책 정보를 교환하기 위해 보안 정책 프로토콜(SPP)이 정의된다. 보안 정책 프로토콜(SPP)의 역할은 다음과 같다

본 발명에 따르면, 정책 클라이언트와 정책 서버간에 정책 정보를 교환하기 위해 사용되는 6가지 보안 정책 프로토콜(SPP) 메시지 타입들을 정의한다. 본 발명에 따르면, 보안 정책 프로토콜(SPP) 메시지를 구성하는 정책 정보를 정의하고, 그 정보의 인코딩 포맷을 정의한다. 또한, 본 발명에 따르면, 보안 정책 시스템 내의 엔터티들이 보안 정책 메시지를 처리하는 방법, 즉 정책 클라이언트와 정책 서버에 의해 정책 정보가 교환되고, 처리되고, 보호되는 방법을 제공한다.

다음은 정책 클라이언트와 정책 서버간에 정책 정보를 교환하기 위해 사용되는 6가지 보안 정책 프로토콜(SPP) 메시지 타입들을 정의함으로써 보안 정책 메시지의 처리 방법에 관한 세부 사항을 기술한다. 본 발명에 따르면 보안정책프로토콜(SPP) 메시지로서 질의 메시지(SPP-QUERY), 응답 메시지(SPP-REPLY), 정책 메시지(SPP-POL), 정책 승인 메시지(SPP-POL_ACK), 전송 메시지(SPP-XFR), 킵얼라이브(KeepAlive) 메시지(SPP-KEEP_ALIVE)를 정의한다.

질의 메시지(SPP-QUERY)는 정책 정보에 대한 특정 요청을 포함한다. 또한, SPP 헤더, 하나 이상의 질의 페이로드, 및 필요한 경우에는 0 이상의 레코드 페이로드 전자서명을 포함한다. 응답 메시지(SPP-REPLY)는 특정 정책 질의에 응답하기 위하여 사용한다. 또한, SPP 헤더, 하나 이상의 질의 페이로드, 및 0 이상의 레코드 페이로드 전자서명을 포함한다. 정책 메시지(SPP-POL)는 정책 서버에서/로부터 보안 정책을 업로드/다운로드하기 위하여 사용한다. 또한, SPP 헤더, 하나 이상의 레코드 페이로드, 및 서명 페이로드를 포함하지만, 질의 페이로드는 포함되지 않는다. 정책 승인 메시지(SPP-POL_ACK)는 정책 메시지의 승인에 사용한다. 또한, SPP 헤더 및 서명 페이로드를 포함한다. 하지만, 질의 페이로드나 레코드 페이로드는 포함되지 않는다. 전송 메시지(SPP-XFR)는 서버들 사이에서 정책 정보를 교환하기 위하여 정책 서버들에 의하여 사용된다. 또한, SPP 헤더, 하나 이상의 레코드 페이로드 및 서명 페이로드를 포함한다. 하지만, 질의 페이로드는 포함되지 않는다. 킵얼라이브(KeepAlive) 메시지(SPP-KEEP_ALIVE)는 보안 게이트웨이나 모니터링 장치에게 서버의 상태를 알리기 위하여 사용한다. 또한, SPP 헤더 및 서명 페이로드를 포함한다. 하지만, 질의 페이로드나 레코드 페이로드는 포함되지 않는다.

또한, 정책 연관성 제거 처리와 관련하여, 정책들이 서로 연관되어 있을 수 있기 때문에 정책 서버가 그들이 마스터 파일에 써있는 대로 정책들을 사용하는 것이 불가능하다. 정책들의 각 셀렉터들(selectors) 값들 간에 교집합이 존재하면, 두개의 정책들은 연관되어 있는 것이다. 연관되어 있는 정책들을 캐쉬하게 되면, 그 캐쉬된 정책들에 근거한 정책 사용을 부정확하게 만들 수 있다. 즉, 대부분의정책 실행자가 특정 패킷의 특성에 일치하는 첫번째 정책 엔트리를 탐색하고 그 이후에 나타나는 정책은 무시되기 때문에 정책 정보가 마스터 파일에서 나타나는 순서는 매우 중요하다.

이로써, 정책 서버와 정책 클라이언트는 정해진 보안 정책 프로토콜(SPP)에 따라 정책 정보를 교환한다. 보안 정책 프로토콜(SPP)은 정책 정보가 클라이언트와 서버에 의해 어떻게 교환되고, 처리되고, 보호되는지를 정의한다.

이하에서는 본 발명에 따른 보안 정책시스템을 IP 보안 서비스를 위한 보안 정책을 지원하는 시스템에 적용한 경우를 설명한다. 본 실시예에서는 IP 보안시스템(IPSec)과의 관계와 IP 보안 정책 시스템의 구조 및 기능에 따른 각 구성 요소의 세부 기능에 대한 정의에 중점을 둔다.

먼저, IP 보안 정책 시스템이 IP 보안시스템(IPSec)에게 제공하는 서비스를 정의한다. 또한, IP 보안 정책 시스템이 IP 보안 정책 시스템에게 서비스를 요청하고 결과를 받는 절차와 그들 사이에 교환되는 정보의 내용을 정의한다. 또한, IP 보안 정책 시스템의 구조를 정의한다. 또한, IP 보안 정책 시스템에서 각 구성 요소들 간에 SPP 메시지의 흐름을 정의한다. 또한, IP 보안 정책 시스템에서 SPP 메시지의 처리와 관련된 세부 기능을 담당하는 기능 모듈들을 정의하고, 그 기능 모듈들의 메시지 처리 절차를 정의한다.

먼저, IP 보안 정책 시스템과의 관계를 기술한다. IP 보안 정책 시스템은 IP 보안시스템(IPSec)에게 IP 보안 정책을 지원하기 위한 용도로 사용되므로, IP 보안 정책 시스렘을 설계함에 있어서 먼저 IP 보안시스템(IPSec)과의 관계를 정의할 필요성이 있다. 이를 위하여 본 절에서는 IP 보안 정책 시스템이 IP 보안시스템(IPSec)에게 제공하는 서비스를 정의하고, IP 보안시스템(IPSec)에게 서비스를 요청하고 결과를 받는 절차와 그들 사이에 교환되는 정보의 내용을 정의한다.

IP 보안시스템(IPSec)에게 제공하는 서비스를 기술한다. IP 보안 정책 시스템은 IP 보안시스템(IPSec)에게 다음과 같은 서비스를 제공한다. 또한, 원하는 통신에 대한 목적지까지의 통신 경로 상에 존재하는 보안 게이트웨이를 알려 준다. 또한, 원하는 통신 경로 상의 보안 게이트웨이나 목적지 호스트의 통신 특성을 알려주며, 원하는 통신 경로 상의 보안 게이트쉐이나 목적지 호스트의 신원을 증명하고, 원하는 통신 경로 상의 보안 게이트웨이가 특정 호스트에 대한 권한을 가짐을 증명한다.

본 발명에 따른 보안 정책 시스템에 의한 서비스 이용 절차는 다음과 같이 정의된다. 도 3에는 본 발명에 따른 보안 정책 시스템(SPS)을 IP 보안시스템(IPsec)과 함께 사용하는 실시예를 도시하였다.

먼저, 응용이 IP 보안에 의해 데이터를 송신하기 위해서는 보안정책시스템에 의한 정책설정, 인터넷 키 교환(IKE)에 의한 키 교환 및 SA 설정이 먼저 이루어져 있다고 가정한다. 도 3을 참조하면, 먼저, 사용자는 finger somebody@H2과 같은 형태의 전송 메시지를 응용을 통해 발송한다. 다음으로, 응용은 시스템 소켓 인터페이스(302)에 대하여 Ssocket_create와 Ssocket_write로 대응한다. 즉, 시스템 소켓 인터페이스(302)는 "finger somebody@H2"에 대한 동작으로써 TCP 또는 UDP 계층의포트 79를 사용한 Ssocket_create와 somebody, H2, 및 Ssocket_id를 사용한 Ssocket_write와 같은 명령어들을 사용한다.

시스템 소켓 인터페이스는 TCP 또는 UDP 계층과 IP 계층을 통하여 전달되고, IPsec 프로토콜 처리부(304)로 전달된다. IPsec 프로토콜 처리부(304)는 상기 명령어들에 응답하여 SPDB(sequrity policy database: 보안정책데이터베이스)(306)에서 패킷의 처리를 위한 해당하는 정책을 검색한다.

다음으로, SPDB(306)는 예를 들면 getassocbysocket()와 같은 함수를 이용하여 SADB(308)에게 SA를 요구한다. SADB(308)는 해당하는 SA가 있으면 이 SA를 IPsec 프로토콜 처리부로 넘겨 주어 IP 보안 처리가 이루어질 수 있도록 한다.

그렇지 않은 경우에는 다음의 단계들이 진행된다. 즉, SPDB(306)에 의해 요구된 SA를 얻기 위해, SADB(308)는 예를들어 PF_KEY API v2함수인 SADB_ACQUIRE를 사용하여 인터넷 키 교환(IKE) 데몬(demon)에 요구한다.

다음으로, IKE(internet key exchange: 인터넷키교환부)(312)는 보안정책시스템(314)으로 제2 호스트(H2)와의 안전한 통신을 위한 정책정보를 요청한다. 보안정책시스템(314)은 시스템 소켓 인터페이스(302)와 보안 정책 프로토콜(SPP) 교환을 수행한다. 보안 정책 프로토콜(SPP) 교환에 의한 정책정보는 SPDB에 저장되도록 구현하는 것도 가능하다.

다음으로, 보안정책시스템(314)은 보안 정책 프로토콜(SPP) 교환에 의한 정책정보를 IKE(312)로 전달한다. IKE(312)는 보안정책시스템(314)으로부터 수신한 정책정보를 이용하여 IKE Phase 1, Phase2 SA를 설정한다. 다음으로, PF_KEY APIv2, 예를 들면 SADB_UPDATE 또는 SADB_ADD를 이용하여 SA 정보를 SADB(308)에 저장한다. 다음으로, 이렇게 얻어진 SA 정보를 이용하여 적절한 IP 보안 프로토콜처리가 이루어지고, 제2 호스트(H2)로 데이터가 네트워크(320)를 통하여 송신된다.

도 4에는 보안 정책 시스템이 IP 보안시스템(IPSec)과 어떻게 동작하는지를 초기 응용이 수행되는 것부터 필요한 SA 설정까지의 과정을 단계별로 나타내었다. 도 4를 참조하면, 먼저, 사용자 응용이 제1 호스트(H1)에서 제2 호스트(H2)로 예를들어 finger somebody@H2와 같은 형태의 메시지의 전송을 시도한다. 제1 호스트(Hl)의 IP 보안시스템(IPsec)은 그 패킷을 넘겨 받아서 보안정책데이터베이스(SPD) 내에서 제1 호스트(Hl)에 관한 정책을 찾는다. 제1 호스트(H1)는 이 통신의 SA가 없으며 필요한 SA 접속을 위해 KMP(Key Management Protocol)를 요구한다. 예를들어, 제1 호스트(H1) 내의 정책클라이언트(PC)는 제1 호스트(Hl)와 제2 호스트(H2) 사이의 통신을 관리하는 정책에 대해 질의 메시지를 넘겨 받는다. 즉, 제1 호스트(Hl)내의 정책 클라이언트(PC)는 SPP 질의 메시지(Q1)를 생성해서, 제1 정책서버(PS1)에게 보낸다. 제1 정책서버(PS1)는 상기 질의 메시지(Q1)를 넘겨 받는다. 제1 정책서버(PS1)의 보안 영역의 데이터베이스는 제2 호스트(H2)에 대한 권한이 없음을 나타내고, 캐쉬된 답변이 있었는지를 검사한다. 위의 실시예에서는 캐쉬된 답변이 없으므로 새로운 SPP 질의 메시지(Q2)를 생성해서 상기 질의 메시지(Q1)와 함께 제2 호스트(H2)에게 보낸다.

다음으로, 제2 보안게이트웨이(SG2)는 SPP 질의 메시지(Q2)를 가로채서 제2 정책서버(PS2)에게 넘긴다. 제2 정책서버(PS2)는 SPP 질의 메시지(Q2)를 넘겨 받는다. 제2 정책서버(PS2)의 보안 영역의 데이터베이스는 제2 호스트(H2)에 대한 권한이 없음을 나타내고, 캐쉬된 답변이 있는지를 검사한다. 위의 실시예에서는 캐쉬된 답변이 없으므로 새로운 SPP 질의 메시지(Q3)를 생성해서 이 질의 메시지와 함께 제2 호스트(H2)에게 보낸다.

다음으로, 제3 보안게이트웨이(SG3)는 SPP 질의 메시지(Q3)를 가로채서 제3 정책서버(PS3)에게 보낸다. 제3 정책서버(PS3)는 SPP 질의 메시지(Q3)를 넘겨 받는다. 제3 정책서버(PS3)의 보안 영역의 데이터베이스는 제2 호스트(H2)에 대한 권한이 없음을 나타내고, 캐쉬된 답변이 있는지를 검사한다. 상기 실시예에서는 캐쉬된 답변이 있다. 캐쉬된 정책은 ESP 전송이 제2 호스트(H2)와 함께 행해져야 하고, ESP 터널이 제3 보안게이트웨이(SG3)와 함께 행해져야 함을 나타낸다.

제3 정책서버(PS3)는 2 개의 메시지를 생성한다. 하나의 메시지는 SA에 필요한 정책, 제3 정책서버(PS3)가 제2 호스트(H2)에 권한이 있음을 나타내는 보안 서버 레코드 및 신원 증명 레코드 내에 제3 정책서버(PS3)의 신원 증명을 포함하는 SPP 응답 메시지이다. 이 응답은 제2 정책서버(PS2)에게 발송된다. 다른 하나의 메시지는 제1 호스트(Hl)와의 SA가 필요할 것이라는 것을 제3 보안게이트웨이(SG3)에게 알리는 SPP 정책 메시지이다.

다음으로, 제2 정책서버(PS2)는 응답(R1)을 넘겨 받는다. 또한, 제2 정책서버(PS2)는 제3 정책서버(PS3)가 제2 호스트(H2)에 권한이 있는지를 검사하고, 제2 정책서버(PS2)의 지역 정책을 검사해서 질의 메시지 내의 정책에 대해 분석한다. 또한, 제2 정책서버(PS2)는 분석된 정책을 캐쉬로 저장하고 두 개의 메시지를 생성한다. 하나는 분석된 정책, 제3 정책서버(PS3)의 보안 서버와 신원증명 레코드 및 정책서버(PS)가 제3 정책서버(PS3)와 제2 정책서버(PS2)의 신원 증명에 대한 권한이 있음을 나타내는 레코드를 포함하는 제1 정책서버(PS1)에 대한 응답(R2)이다. 다른 하나는 제1 호스트(Hl)와의 SA가 필요할 것이라는 것을 제2 보안게이트웨이(SG2)에게 알리는 SPP 정책 메시지이다.

다음으로, 제1 정책서버(PSl)는 응답(R2)을 넘겨 받는다. 제1정책서버(PS1)은 제2 정책서버(PS2)가 제3 정책서버(PS3)에 대한 권한이 있는지 검사하고, 제3 정책서버(PS3)가 제2 호스트(H2)에 대한 권한이 있는지 검사해서 확실한 신뢰 연결을 생성한다. 제1 정책서버(PS1)는 지역 정책을 검사해서 응답에 존재하는 정책에 대해 분석한다. 또한, 제1 정책서버(PS1)는 분석된 정책을 캐쉬로 저장하고 제1 호스트(Hl)에 대한 응답(R3)을 생성한다. 응답(R3)에는 분석된 정책이 포함된다.

다음으로, 정책 클라이언트(PC)는 응답(R3)을 넘겨 받아서 이것에 관해 질의했던 응용에게 응답(R3)을 리턴한다. 이 정책은 SA가 연결되어야 하며, 이 SA들은 특정 순서로 연결되어야 함을 나타낸다.

KMP는 이 정보를 제공 받으며 먼저 제3 정책서버(PS3)와의 SA 접속을 위해 사용할 수 있는 제2 정책서버(PS2)와의 SA 결합을 생성한다. 둘 다 제2 호스트(H2)와의 SA 접속을 위해 사용할 수 있다. 또한, 응용으로부터의 원본메시지는 SA를 사용해서 처리할 수 있다.

다음으로, IP 보안시스템(IPSec)과 교환되는 정보 내용을 기술한다. 도 5에는 보안 정책 시스템과 IP 보안시스템(IPSec) 사이에서 교환되는 정보를 나타내었다. 보안 정책 시스템은 IKE 서버(560)와 같은 외부 응용으로부터 정책정보 요청 인터페이스(미도시)를 통해 정책정보 요청신호를 수신하고, 보안 정책 시스템 내에서 보안 정책 프로토콜(SPP)을 사용하여 메시지를 교환하여 그 요청에 대응되는 정보를 구성한 후 정책정보 전달 인터페이스(미도시)를 통해 전달한다. 이때, 보안 정책 시스템과 외부 응용과의 모든 상호작용은 정책 클라이언트를 통해서 이루어진다.

이제, 정책 정보 요청 인터페이스에 대하여 기술한다. 정책 정보 요청 인터페이스는 외부 응용으로부터 보안 정책 시스템으로 1개 이상의 통신 특성 질의가 요청된다. 통신 특성 질의는 외부 응용이 시도하려는 특정 통신에 필요한 정책정보에 대해 질의하는 것이며 교환될 수 있는 파라미터들은 적어도 소스 주소, 목적지 주소, 및 셀렉터(selector) 데이터를 포함한다.

소스 주소는 단일 IP 주소(unicast)로서 허용되는 값 SRC_IP4_ADDR, SRC_IPV6_ADDR가 있다. 목적지 주소는 단일 IP 주소(unicast)로서 허용되는 값은 DST_IPV4_ADDR, DST_IPV6_ADDR가 있다. 셀렉터(selector) 데이터는 통신 특성을 결정하는 데이터로서 선택적으로 포함될 수 있다. 허용되는 값은 DIRECTION, USER_NAME, SYSTEM_NAME, XPORT_PROTOCOL, SRC_PORT, SRC_PORT_DYNAMIC, DST_PORT, DST_PORT_DYNAMIC, SEC_LABELS, V6CLASS, V6FLOW, V4TOS, ACTION, SRC_PORT_RANGE, 및 DST_PORT_RANGE가 있다.

상기와 같은 본 발명에 의한 보안 정책 시스템은 메시지가 두 호스트 사이에 단말 경로를 통하여 전달될 수 있도록 필요한 보안 게이트웨이 집합을 결정할 수있어야 한다는 것을 고려하였다.

또한, 본 발명에 의한 보안 정책 시스템은 보안 게이트웨이나 호스트의 신원을 증명하는 것을 포함한다. 즉, 호스트가 통신 중인 보안 게이트웨이나 호스트의 신원을 증명할 수 있도록 한다. 또한, 어떠한 특정 호스트를 대표하는 보안 게이트웨이가 실제로 그 호스트로부터 권한을 위임받았는지를 증명한다. 또한, 특정 호스트를 대표하는 게이트웨이가 그 호스트를 대표하는 권한이 있음을 증명할 수 있다. 또한, 본 발명에 따른 보안 정책 시스템은 보안 프로토콜에 대한 변경, 추가 및 수정을 요구할 수 없도록 설계된다. 또한, 본 발명에 따른 보안 정책 시스템은 특정 키 관리 프로토콜에 대하여 독립적이어야 한다는 것을 고려한다. 또한, 본 발명에 따른 보안 정책 시스템은 최소한의 외부 인프라에대한 종속성을 제공한다. 예를들어, 키 분배와 관련하여, 공개 키가 DNS 인프라를 사용해서 분배될 수 있지만 다른 방법을 제한할 수 없도록 한다. 본원 발명에서는 중간 노드의 정책의 영향을 고려한다. 즉, 본 발명의 보안 정책 시스템은 응용이 보안 게이트웨이의 정책 실행의 결과로 영향을 받을 수 있는 다음과 같은 바람직하지 않은 경우를 해결한다.

첫 번째로, 송신측 보안 게이트웨이가 실행한 정책에 대하여 수신측 보안 게이트웨이에 대응되는 정책이 없는 경우이다. 이러한 경우에는 수신측 보안 게이트웨이가 수신한 패킷을 폐기하고 이것을 상대에게 알리지 않는다는 문제점이 있다.

두 번째로, 송신측 보안 게이트웨이가 실행한 정책에 대하여 수신측 보안 게이트웨이는 대응되는 정책을 가지고 있으나 정책이 중복되거나 순서가 다른 경우가 있다. 이러한 경우에는 양측에서 정책을 적용한 결과가 다르게 되어 보안 틈새가발생할 수 있다는 문제점이 있다.

세 번째로, 양측 보안 게이트웨이 노드 상의 정책이 정확히 대응되는 경우에도 패킷이 한 방향으로 동일한 경로를 따라 전송되고 동일한 정책을 사용하여 보호되는지를 보장할 수 없는 경우이다. 이러한 경우에는 패킷이 한 방향으로는 보호되고 반대 방향으로는 보안 서비스를 받지 않은 평문의 패킷으로 리턴될 수 있어 보안 틈새가 발생할 수 있다는 문제점이 있다.

네 번째로, SA 번들로 구성된 응용이 동적으로 SA를 선택하여 사용하는 경우이다. 이러한 경우에는 SA 번들 정보가 중간 노드들에게 알려지지 않음으로써 SA 번들이 부분적으로 동작할 수 있다는 문제점이 있다. 예를들어, 정책이 모든 전송제어프로토콜(Transfer Control Protocol: TCP)을 유지하지 않는다면 보안 게이트웨이가 파일전송프로토콜(File Transfer Protocol: FTP)만의 세션을 지원하는 SA를 생성할 수 없다. 또한, 예를들어, 발송지 또는 목적지 TCP 포트 21을 선택하여 FTP 제어 세션을 유지하는 정책을 가질 수 있는데, 이러한 경우, 데이터 세션 포트번호는 종단 노드만이 알 수 있다는 문제점이 있다. 또한, 보안게이트웨이가 페이로드를 검사하기 위하여 응용에 대한 관련 정보를 가지고 있거나, 응용이 보안게이트웨이에게 세션 포트를 통지하지 않으면, 세션에서 동적으로 선택한 포트를 보안 게이트웨이가 알지 못한다는 문제점이 있다.

상기와 같은 문제점을 해결하기 위하여 본 발명에 따른 보안 정책 시스템은 종단 사이의 통신에 있어서 패킷이 복수의 관리 영역에 결쳐 있는 망을 통과하므로 종단 노드들은 자신의 패킷에 적용된 정책을 알 수 있도록 한다. 또한, 정책의 표현을 유연하고 제조자에 독립적으로 구성한다. 즉, 이러한 정책의 기술은 제조자에 중립적이어야 상대측(peering) IP 보안 노드들이 이해할 수 있으며, SA를 위하여 터널모드 또는 전송 모드에서 어느 한 종단 노드에서 정책을 실행할 수 있다. 또한, 상기 정책은 주소, 트랜스포트, 및 다른 매개 변수들의 범위에 대한 기술을 허용하면서 선택적 제외를 허용하는 다양한 규칙을 수용할 수 있도록 하는 것이 바람직하다.

또한, 본 발명에 따르면, 정책 발견을 위한 메커니즘이 제공되는 것이 바람직하다. 따라서, 본 발명의 실시예에 따른 보안 정책 시스템은 종단 모드가 질의할 수 있고, 자신의 패킷들이 지켜야 하는 정책을 찾을 수 있도록 한다. 예를들어, 클라이언트 노드는 그 응용과 관련된 정책을 질의하고 발견할 수 있도록 한다.

패킷의 안전한 횡단에 적용된 정책과 중간에 거치게 되는 라우터를 식별할 수 있는 Tracerout와 같은 기능을 포함하는 것이 바람직하다. 이로써, 정책기반의 환경에서는 패킷 프로토콜과 세션 특성에 기반하여 서로 다른 터널을 사용하여 횡단하는 경우에도 보안이 이루어진다.

정책 교환과 질의 정보를 위한 메카니즘이 제공되는 것이 바람직하다. 즉, 인터넷 키 교환(Internet Key Exchange: IKE) 방법에 따르면 세션키를 안전하게 교환한다. 하지만, 상대측(peering) 보안 게이트웨이 노드가 정책을 교환할 필요성이 있으며, 종단 노드와 중간 노드도 정책 특유의 정보에 대해 질의할 필요성이 존재한다.

또한, 본 발명에 따르면, 정책 협상이 제공된다. 즉, lP 보안 통신상대가 인터넷 키 교환 방법을 사용하여 정책 정보를 교환할 때 임의의 SA에 패킷을 전송하기 위하여 상대측(peering)노드가 셀렉터(selector)의 집합값에 동의하는 것은 필수적이다. 하지만, 상대측 노드가 어느 한쪽의 정책과 정확히 일치하지 않는다고 추측하는 것은 바람직하지 않다. 따라서, 양쪽 사이에서 교환되는 정책의 교집합에 해당하는 정책을 분할하는 것이 상대측 노드의 요구사항이라고 칭할 수 있다.

또한, 본 발명에 따르면, 정책 결정이 제공된다. 즉, 어떠한 경우는 호스트와 보안 게이트웨이가 통신을 기술하는 셀렉터(selector)들의 집합에는 동의하지만 그런 통신을 보호하기 위해 요구되는 SA 매개변수의 집합에는 동의하지 않는 경우가 있다. 예를들어, 호스트는 최종 목적지에 다다르기 위해 DES에 의한 전송모드로 ESP를 사용하고자 하지만 보안 게이트웨이는 이를 명백하게 금지하는 경우가 있을 수 있다. 이러한 경우, 호스트는 보안 게이트웨이와의 SA 설정을 원하면서 보안 게이트웨이가 호스트를 대신하여 의도한 칙종 목적지와의 SA 설정을 허용할 수 있다. 또한, 그러한 정책이 보안 게이트웨이에 있으면, 그 호스트는 최종 목적지와 통신하는 것이 아닌 위와 같은 것을 구현하는데 동의하는 것을 선택할 수 있다.

또한, 본 발명에 따르면, 정책 실행점에 대해 동적으로 정책정보의 추가 및 삭제를 포함한 정책정보의 변경이 제공된다. 즉, IP 보안에 있어서, 종단 모드는 IP SA와 관련된 정책에 동적으로 영향을 미칠 수 있다. 이는 SA가 상대측 노드들 사이에 직접적 또는 2 개의 게이트웨이 노드 사이인지를 관계하지 않는다. 또한, 종단 노드는 SA로부터 동적으로 정책을 추가 또는 삭제할 수 있어야 한다. 따라서, 응용 특유의 정책을 SA에서 실행하는 것이 어렵다.

또한, 본 발명에 따르면, SA를 위한 정책 번들이 제공된다. 즉, 하나의 정책이 복수개의 SA들과 연관지어질 수 있는 정책 번들이 SA 번들에 요구된다.

또한, 본 발명에 따르면, 실패한 정책에 대해 종단 노드에게 오류 통보를 제공한다. 즉, 패킷이 어떤 정책의 실행에 의해 망의 임의의 노드에서 폐기(drop)될 때 응용은 패킷을 폐기하도록 한 정책을 아는 것이 도움이 된다.

또한, 본 발명에 따르면, 표준화된 거절통지 단계를 포함한다. 이 경우 메시지는 정책 실행 장치의 정책과 식별자(ID) 뿐만 아니라 패킷을 포함하여야 한다.

또한, 본 발명에 따른 보안 정책 시스템은 IP 보안을 기반으로 하는 가상 사설망(Virtual Private Network: VPN)의 구성과 관리를 위한 LDAP 스키마에 적용될 수 있다.

이를 해결하기 위하여, IP 보안 정책 정보를 표준화된 중앙집중형 디렉토리에 저장하고 각 노드에서 이 정보를 이용하여 협상한다. 이로써, 디렉토리 기반의 정책 관리를 수행한다. 본 발명에 따르면, 표준화된 정책 정보를 중앙집중형 디렉토리에 저장하고 저장된 정보를 이용하며, 예를들어, 업체 표준으로 널리 사용되고 있는 LDAP을 사용하는 것이 가능하다.

상술한 바와 같은 본 발명에 따른 보안 정책 시스템(Security Policy System: SPS)은 호스트와 보안 게이트웨이 사이에서 안전한 통신 설정을 위해 필요한 보안 정책 정보를 제공하는 분산 시스템으로서, 보안 영역의 호스트, 서브넷, 망의 보안 정책 정보를 발견, 접근, 처리를 하기 위해 필요한 메카니즘을 제공한다. 보안 정책 프로토콜(SPP)을 사용해서 정책 클라이언트와 서버들은 정보를 교환한다. 이 프로토콜은 클라이언트와 서버에 의해 정책 정보가 어떻게 교환, 처리 및 보호되는지를 정의한다.

보안정책시스템(SPS)의 구조적인 요구사항은 다음과 같다. 게이트웨이의 발견(Discovery)과 관련하여, 메시지가 두 호스트 간에 단일 경로를 통해 전달될 수 있도록 필요한 보안 게이트웨이 집합을 결정한다. 또한, 보안 게이트웨이나 호스트의 신원을 중명할 수 있다. 또한, 어떤 특정 호스트를 대표하는 보안 게이트웨이가 실제로 그 호스트로부터 권한을 위임 받았는지 증명하여야 한다. 즉, 특정 호스트를 대표하는 보안 게이트웨이가 그 호스트를 대표하는 권한이 있음을 증명하여야 한다.

또한, 본 발명에 따르면, 보안 프로토콜의 변경 금지와 관련하여, 보안 정책 시스템은 사용하는 보안 프로토콜에 대한 변경, 추가 및 수정을 요구할 수 없다. 또한, 키 관리 프로토콜에 대한 독립성, 즉, 특정 키 관리 프로토콜에 대해 독립적이어야 한다.

또한, 본 발명에 따르면, 최소한의 외부 인프라에 대한 종속성을 가진다. 예를들면, 키 분배와 관련하여, 공개 키가 DNS 인프라를 사용해서 분배될 수 있지만 다른 방법을 제한할 수 없다.

이제, IP 보안 프로토콜의 동작 환경을 예를들어 설명한다. IP 보안 프로토콜의 동작 환경을 기술하면서 보안 정책 시스템의 동작 환경을 동일한 동작 환경으로 유추 또는 가정하고자 한다. IP 보안 프로토콜인 AH 프로토콜과 ESP 프로토콜이 독립적으로 또는 결합하여 사용될 수 있는데, 많은 가능성 중 몇 개만이 현실적으로 가능하다. 이중 현실적으로 가능한 네 가지 경우를 기술하면 다음과 같다.

첫 번째 경우로서, 본 발명에 따른 보안 정책 시스템은 종단간 보안에 적용될 수 있다. 도 6a에는 본 발명에 따른 보안 정책 시스템을 종단간 보안에 적용한 경우의 동작 환경을 나타내었다. 도 6a를 참조하면, 두 개의 호스트 H1(602)과 H2(606) 사이에 어떠한 IP 보안 게이트웨이 없이, 인터넷 또는 인트라넷(604)에 의해 연결되어진다. 두 호스트(602, 606) 사이에서는 ESP 프로토콜 또는 AH 프로토콜이나 이들 모두가 사용될 수 있으며, 전송모드 또는 터널모드가 적용될 수 있다.

이러한 경우, IP 보안 구현에 의해 다음과 같은 것이 지원되는 것이 요구된다. 전송모드는 AH 프로토콜을 단독으로 사용하는 모드, ESP 프로토콜을 단독 으로 사용하는 모드, 및 ESP 프로토콜을 적용한 후에 AH 프로토콜을 적용(transport adjacency)하는 모드 중에서 선택적으로 사용될 수 있다. 터널모드는 AH 프로토콜을 단독으로 사용하는 모드 또는 ESP 프로토콜을 단독으로 사용하는 모드 중에서 선택적으로 사용할 수 있다.

두 번째 경우로서, 본 발명에 따른 보안 정책 시스템은 기본적인 가상사설망(vertual private network: VPN)이 지원되는 종단간 보안에 적용될 수 있다. 도 6b에는 본 발명에 따른 보안 정책 시스템을 기본적인 가상사설망(VPN)이 지원되는 종단간 보안에 적용한 경우의 동작 환경을 나타내었다. 도 6b를 참조하면, 가장 간단한 가상사설망(VPN)을 지원하는 예로, 제1 게이트웨이(G1: 616)와 제2 게이트웨이(G2: 620)가 IP 보안 프로토콜 스택을 실행하며, 인트라넷안의 호스트는 IP 보안을 지원하는 것이 요구되지 않는다. 이 경우, 게이트웨이(616,620)는 AH 또는 ESP 터널모드만을 지원하는 것이 요구된다.

게이트웨이간 혼합된 터널과 관련하여, 게이트웨이가 AH 터널 또는 ESP 터널만을 지원하는 것이 요구될지라도 가끔 두 IP 보안 프로토콜 기능을 혼합하는 터널이 게이트웨이간 바람직할수도 있다. 개념적으로 혼합된 AH-ESP 터널의 경우에는 하나의 IP 보안 프로토콜이 터널로 지원되고, 다른 하나는 전송 모드로 적용되는 형태이다. 이와 동일한 접근으로 원래의 데이터를 IP 터널링을 한 다음 그것에 전송 인접(transport adjacency) IP 처리를 적용한다.

세 번째 경우로서, 본 발명에 따른 보안 정책 시스템은 가상사설망(VPN)이 지원되는 종단간 보안에 적용될 수 있다. 도 6c에는 본 발명에 따른 보안 정책 시스템을 가상사설망(VPN)이 지원되는 종단간 보안에 적용한 경우의 동작 환경을 나타내었다. 도 6c에 도시한 도면은 첫 번째 경우와 두 번째 경우를 조합한 경우의 동작 환경에 해당하며, 새로운 IP 보안 요구사항은 없다. 다만, 두 번째 경우와의 차이는 호스트가 IP 보안을 지원할 것이 요구된다는 것이다.

바람직하게는, 게이트웨이 사이는 AH 터널모드를 사용하고 호스트사이는 ESP 전송모드를 사용하는 것이다. 증강된 보안 버젼은 게이트웨이 사이에 결합된 ESP 터널을 사용하는 것이다. 이로써, 궁극적인 상대주소가 암호화되어지며 전체 패킷이 인증되어지고 전송 데이타는 이중으로 암호화되어진다.

네 번째 경우로서, 본 발명에 따른 보안 정책 시스템은 원격 접근(Remote access)에 적용될 수 있다. 도 6d에는 본 발명에 따른 보안 정책 시스템을 원격 접근에 적용한 경우의 동작 환경을 나타내었다. 도 6d를 참조하면, 방화벽에 의하여보호되는 조직내의 서버에 접근하기 위해 인터넷을 사용하는 원격지 호스트에 적용된다. 원격지 호스트, 즉, 제1 호스트(Hl: 652)는 PPP 전화 접속을 사용하여 전화선 구간(dial-up segment)을 통하여 인트라넷 또는 인터넷(654)과 접속되고, 다시 제2 게이트웨이(G2: 656)는 인트라넷(658)을 통하여 제2 호스트(H2: 660)와 접속된다. IP 보안 터널은 도시된 바와 같이 원격지 호스트인 제1 호스트(H1: 652)과 방화벽인 제2 게이트웨이(G2: 656)) 사이에서 이루어진다. 즉, 원격지 호스트인 제1 호스트(H1: 652)과 방화벽인 제2 게이트웨이(G2: 656)사이는 터널 모드만이 요구되며 선택은 두 번째 경우와 동일하다. 또한, 호스트들(H1, H2) 사이는 터널 또는 전송 모드가 사용될 수 있으며 첫 번째 경우와 동일한 선택이 사용될 수 있다.

바람직하게는, 제1 호스트(Hl: 652)와 제2 게이트웨이(G2: 656) 사이는 AH 터널을 사용하고, 제1 호스트(H1: 652)과 제2 호스트(H2: 660) 사이는 전송모드를 사용한다. 또한, 원격지 호스트인 제1 호스트(H1: 652)와 제2 게이트웨이(G2: 656) 사이에 결합된 AH-ESP 터널을 생성하는 것이 일반적이다. 이 경우 제1 호스트(Hl: 652)는 단지 하나의 SA 번들을 사용하여 전체 인트라넷을 접근할 수 있다. 반면에, 도 6d와 같은 설정을 사용하였다면 하나의 SA 번들로 하나의 호스트만을 접근할 수 있다.

한편, 보안 정책 시스템은 종단간의 안전한 통신 설정을 위해 같은 보안 영역 내에서 뿐만 아니라 다른 보안 영역의 호스트들, 서브넷 혹은 망들의 정책 정보를 알아내고, 그 정책 정보를 처리하기 위하여 필요한 메커니즘을 제공하는 분산 시스템이다. 즉, 보안 정책 시스템에 의해 다루어지는 정책 정보는 여러 보안 영역을 통과할 수 있다.

또한, 보안 정책 시스템은 종단간의 통신에 관련된 주 보안 게이트웨이와 부 보안 게이트웨이를 발견할 수 있는 자동화된 메커니즘을 제공한다. 또한, 종단간 통신의 경로 상에 있는 보안 게이트웨이의 신원을 검증할 수 있고, 특정 보안 게이트웨이가 특정 호스트에 대한 권한을 가지는지를 검증할 수 있다

본 발명에 따르면, 정책 서버는 보안 정책 프로토콜(SPP)에 따라 정책 클라이언트와 다른 정책 서버들로부터 질의 메시지를 수신하여 처리하고 요청자에 대한 소정의 접근 제한 규칙을 기초로 적절한 정책 정보를 요청자에게 제공한다. 또한, 본 발명에 따르면, 토폴로지의 변화를 수용하고, 상기 정책 서버와 정책 클라이언트는 소정의 보안 정책 프로토콜(SPP)에 따라 작업을 수행하며, 이러한 보안 정책 프로토콜(SPP)은 확장가능하고 유연하게 클라이언트들과 서버들 사이의 복잡한 정책 정보 교환을 허용한다.

따라서, 본 발명에 따르면, 보안 영역에 따라 다르게 정의된 정책 정보들에 대한 중앙 집중적인 관리와 협상을 가능하게 한다.

또한, 상기와 같은 본 발명에 따른 보안 정책 시스템은 개인용 또는 서버급의 컴퓨터내에서 실행되는 프로그램으로 작성 가능하다. 상기 프로그램을 구성하는 프로그램 코드들 및 코드 세그멘트들은 당해 분야의 컴퓨터 프로그래머들에 의하여 용이하게 추론될 수 있다. 또한, 상기 프로그램은 컴퓨터 독취 가능 기록 매체에 저장될 수 있다. 상기 기록 매체는 자기기록매체, 광기록 매체, 및 전파 매체를 포함한다. 또한, 상기 프로그램은 망으로 연결된 기기들내에 분산되어 저장되고 실행될 수 있다.

상술한 바와 같이 본 발명에 따르면 보안 영역에 따라 다르게 정의된 정책 정보들에 대한 중앙 집중적인 관리와 협상을 가능하게 한다.

Claims (9)

1. 통신 네트워크에서 보안을 수행하는 보안 정책 시스템에 있어서,

   소정의 보안 정책 프로토콜(SPP)에 따라 정책 정보를 요청하는 정책 클라이언트;

   상기 보안 정책 프로토콜(SPP)을 사용하여 상기 정책 클라이언트와 다른 서버들로부터 수신된 질의 메시지를 처리하여 적절한 정책 정보를 요청자에게 제공하는 정책 서버;

   특정 보안 영역의 지역 정책들과 그 보안 영역에 관한 특정 정보들을 저장하는 마스터 파일; 및

   정책 정보들을 유지하는 복수 개의 보안 정책 정보 데이터베이스;를 포함하여, 호스트와 보안 게이트웨이 사이에서 안전한 통신 설정을 위해 필요한 보안 정책 정보를 제공하는 분산 시스템으로서 동작하는 것을 특징으로 하는 보안 정책 시스템.
2. 제1항에 있어서, 상기 정책 서버는,

   상기 정책 정보가 상기 클라이언트와 상기 서버에 의해 어떻게 교환되고, 처리되고, 보호되는지를 정의한 소정의 보안 정책 프로토콜(SPP)을 사용하여 상기 정책 클라이언트와 다른 정책 서버들로부터의 질의(Query) 메시지를 수신하여 처리하고 적절한 정책 정보를 요청자에게 제공하는 것을 특징으로 하는 보안 정책 시스템.
3. 제1항에 있어서, 상기 정책 서버는,

   요청자에 대한 접근 제한 규칙에 근거하여 정책 정보를 제공하는 것을 특징으로 하는 보안 정책 시스템.
4. 제1항에 있어서, 상기 정책 서버는,

   수신된 지역 및 비지역 정보에 의하여 보안 정책 데이터베이스를 유지하는 것을 특징으로 하는 보안 정책 시스템.
5. 제1항에 있어서, 상기 마스터 파일은,

   누가 보안 영역을 책임지고 있는지를 가리키는 정보와 마스터 파일 내의 정보의 무결성과 인증을 검증하기 위해 사용되는 공유 키에 대한 포인터를 포함하는 것을 특징으로 하는 보안 정책 시스템.
6. 제1항에 있어서, 상기 보안 정책 데이터베이스는,

   특정 보안 영역에 대한 모든 정책들을 포함하며 보안 영역의 마스터 파일로부터 오는 정보와 함께 놓이는 지역 정책 데이터베이스;

   다른 보안 영역들로부터 수신된 지역 정책들 및 비지역 외부 정책들을 포함하며 상기 외부 정책들은 정책 결정 처리를 통해 병합되는 캐쉬 데이터베이스; 및

   보안 영역의 일부인 모든 호스트들, 보안 게이트웨이들, 그리고 정책 서버들의 리스트를 포함하는 보안 영역 데이터베이스를 포함하는 것을 특징으로 하는 보안 정책 시스템.
7. 제1항에 있어서, 상기 마스터 파일내에 저장되는 특정 정보는,

   특정 마스터 파일 내의 정책 정보를 생성, 삭제 및 수정하는 권한이 있는 엔터티를 정의하는 유지자(maintainer) 정보;

   상기 유지자 정보에 의해 참조되는 하나 이상의 인증서인 인증서(certificate) 정보;

   특정 보안 영역에 대한 주요 부 정책 서버의 신원을 기술하는 정책 서버 정보;

   첨부된 정책들을 갖는 인터페이스 집합을 지정하는 노드 정보;

   특정 보안 영역의 정책을 실행하는 호스트와 연관된 인터페이스 집합을 지정하는 게이트웨이 정보;

   영역에 속한 노드들, 보안게이트웨이들 및 정책 서버들에 의해 보안 영역들을 정의하는 영역 정보; 및

   정책들의 순서화된 집합을 나타내는 정책 정보;를 포함하는 것을 특징으로 하는 보안 정책 시스템.
8. 제1항에 있어서, 상기 마스터 파일은,

   보안 영역의 일부인 노드들의 리스트. 보안 영역을 보호하기 위한 보안 게이트웨이들의 리스트; 및

   보안 게이트웨이들에 의해 실행되는 정책 규칙들과 노드에서 실행되는 정책 규칙들의 리스트;를 포함하는 것을 특징으로 하는 보안 정책 시스템.
9. 제1항에 있어서, 상기 보안정책 프로토콜은,

   정책 정보에 대한 특정 요청을 포함하고, SPP 헤더, 하나 이상의 질의 페이로드, 및 필요한 경우에는 0 이상의 레코드 페이로드 전자서명을 포함하는 질의 메시지(SPP-QUERY);

   특정 정책 질의에 응답하기 위하여 사용하고, SPP 헤더, 하나 이상의 질의 페이로드, 및 0 이상의 레코드 페이로드 전자서명을 포함하는 응답 메시지(SPP-REPLY);

   정책 서버에서/로부터 보안 정책을 업로드/다운로드하기 위하여 사용하고, SPP 헤더, 하나 이상의 레코드 페이로드, 및 서명 페이로드를 포함하는 정책 메시지(SPP-POL);

   정책 메시지의 승인에 사용하고, SPP 헤더 및 서명 페이로드를 포함하는 정책 승인 메시지(SPP-POL_ACK);

   서버들 사이에서 정책 정보를 교환하기 위하여 정책 서버들에 의하여 사용되고, SPP 헤더, 하나 이상의 레코드 페이로드 및 서명 페이로드를 포함하는 전송 메시지(SPP-XFR); 및

   보안 게이트웨이나 모니터링 장치에게 서버의 상태를 알리기 위하여 사용하고, SPP 헤더 및 서명 페이로드를 포함하는 킵얼라이브(KeepAlive) 메시지(SPP-KEEP_ALIVE);를 정의하여 사용하는 것을 특징으로 하는 보안 정책 시스템.