KR20060047551A

KR20060047551A - 네트워크 검역을 제공하기 위한 방법 및 시스템

Info

Publication number: KR20060047551A
Application number: KR1020050035183A
Authority: KR
Inventors: 아시윈 팔레카; 칼빈 춘-환 최; 엘리오트 디. 레위스; 하칸 버크; 르주보미르 브라딕; 나렌드라 씨. 기드와니; 티모시 엠. 모레; 비베크 피. 카마스
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-04-27
Filing date: 2005-04-27
Publication date: 2006-05-18
Also published as: JP2005318615A; EP1592168A1; US20050267954A1

Abstract

유효성이 검증되지 않거나 손상된 상태를 갖는 기기들이 네트워크 자원들을 액세스하는 것을 확실하게 제한시키는 시스템 및 방법이 제공된다. 클라이언트 기기 상에 위치한 검역 조정 클라이언트(QCC)는 복수의 검역 정책 클라이언트로부터 건강 문장들을 획득한다. QCC는 이런 문장들을 패키지화하여, 그 패키지를 검역 시행 클라이언트(QEC)에게 제공한다. QEC는 네트워크 액세스를 위한 요청과 함께 그 패키지를 검역 시행 서버에 전송한다. QES는 그 패키지를 검역 조정 서버(QCS)로 전달하고, QCS는 그 패키지를 분해하여 그 각각의 건강 문장을 대응하는 검역 정책 서버(QPS)로 전달한다. QPS는 그 건강 문장의 유효성을 검증하여 QCS에게 그 결과를 통지한다. 클라이언트가 유효한 건강 문장을 제공하였다면, QES는 클라이언트가 네트워크를 액세스하는 것을 허가한다.

검역 시행 서버, 검역 조정 서버, 검역 정책 서버, 검역 시행 클라이언트, 검역 조정 클라이언트, 검역 정책 클라이언트

Description

네트워크 검역을 제공하기 위한 방법 및 시스템{SYSTEM AND METHODS FOR PROVIDING NETWORK QUARANTINE}

도 1a는 본 발명이 실시되는 예시적인 네트워크 환경을 개괄적으로 나타낸 도면.

도 1b는 본 발명이 상주하는 예시적인 컴퓨터 시스템을 개괄적으로 나타낸 블럭도.

도 2는 본 발명의 컴포넌트들에 대한 개략도.

도 3은 본 발명의 실시예에 따른 건강 목록표를 획득하기 위한 방법을 나타낸 도면.

도 4는 본 발명의 실시예에 대한 소프트웨어 컴포넌트들을 나타낸 도면.

도 5는 본 발명의 실시예에 따라 클라이언트가 서버와 통신하는 방법를 나타낸 도면.

도 6은 본 발명의 실시예에 대한 컴포넌트들의 대화 방법을 예시적으로 나타낸 도면.

도 7은 본 발명의 실시예에 따른 클라이언트/서버 아키텍처를 나타낸 도면.

도 8은 본 발명의 한 실시예를 DHCP를 사용하여 나타낸 도면.

도 9는 본 발명의 한 실시예를 IPsec을 사용하여 나타낸 도면.

도 10은 본 발명의 한 실시예를 한 클라이언트를 지원하는 다수의 DHCP 서버들을 사용하여 나타낸 도면.

<도면의 주요 부분에 대한 부호의 설명>

110 : 네트워크

111 : 컴퓨터

210 : 클라이언트

220 : 정책 서버

230 : 검역 서버

240 : 정해진 서버

520 : 검역 정책 서버(QPS)

530 : 검역 조정 서버(QCS)

540 : 검역 시행 서버(QES)

410a, 410b, 410c : 검역 정책 클라이언트(QPC)

420 : 검역 조정 클라이언트(QCC)

430a, 430b, 430c : 검역 시행자 클라이언트(QEC)

[문헌 1] 미국 가출원 제60/565,525호 (2004년 4월 27일 출원)

본 발명은 일반적으로 네트워크 액세스 관리에 관한 것으로, 더 상세하게는 클라이언트들에게 네트워크 자원들에 대한 액세스를 허용하기 전에, 클라이언트들의 보안 상태를 검사하는 것에 관한 것이다.

컴퓨터 네트워크에서, 클라이언트, 서버 및 피어(peer)는, 인가되지 않은 사용자가 파일, 프린터, 다른 컴퓨터, 또는 네트워크 상에서 액세스될 수 있는 임의의 것 등과 같은 네트워크 자원들에 대한 액세스를 획득하지 않을 것을 보장하기 위하여, 통상적으로 신뢰 모델 및 메커니즘을 사용한다. 이러한 신뢰 모델 및 메커니즘은 악의를 갖지 않는 사용자들을 식별하는 데에 사용된다. 그러나, 사용자의 기기는 사용자 스스로도 모르게 네트워크에 위험을 부과할 수 있다. 예를 들어, 기기는 바이러스를 포함하거나, 또는 사용자가 알지 못하는 보안상의 공백을 가질 수 있다. 따라서, 사용자가 얼마나 악의를 갖지 않는지에 상관없이, 사용자의 기기의 비보안 상태는 보안 결함이 치료될 때까지 네트워크로부터 격리되어야만 한다. 이러한 보안 문제는 3개의 네트워크 환경, 즉 동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol, DHCP), 가상 사설 네트워크(Virtual Private Networks, VPN) IEEE 802.1X 및 IP 보안 프로토콜(Internet Protocol Security, IPsec)에 대한 특정한 애플리케이션을 갖는다.

DHCP는 서버가 특정 시간 동안 클라이언트에 IP 어드레스를 할당 또는 "임대(lease)"할 수 있게 해 주는 인터넷 프로토콜(IP) 할당 규약이다. DHCP 클라이언트가 네트워크에 최초로 접속할 때, 그 DHCP 클라이언트는 DHCP DISCOVER 패킷을 브로드캐스트한다. 로컬 세그먼트 상의 DHCP 서버는 그 브로드캐스트를 인터셉트 하고, 클라이언트에게 네트워크 액세스를 제공하는 데에 필요한 IP 어드레스 및 기타 정보를 포함하는 DHCP OFFER 패킷을 리턴한다. 클라이언트는 수개의 상이한 서버로부터 다수의 DHCP OFFER 패킷을 수신할 수 있으므로, 클라이언트는 서버들 중에서 하나를 선택하여, 명시적인 선택된 서버를 식별하는 DHCP REQUEST 패킷을 브로드캐스트해야 한다. 선택된 서버는 임대가 최종 승인되었음을 클라이언트에게 알리는 DHCPACK를 리턴할 것이다. 어떤 이유로 인해 (예를 들어, 기간이 만료되거나 다른 클라이언트가 그 임차권(lease)을 할당하는 것으로 인해), 그러한 제공이 더 이상 유효하지 않은 경우, 선택된 서버는 반드시 DHCPNAK 메시지로 응답해야 한다. 이에 의해, 클라이언트는 다른 DHCPDISCOVER 패킷을 발송하여, 프로세스를 다시 시작하게 될 것이다.

클라이언트가 소정의 다른 수단(예를 들어, 수동 구성)을 통해 네트워크 어드레스를 획득한 경우, 그 클라이언트는 DHCPINFORM 요청 메시지를 사용하여 다른 로컬 구성 파라미터를 획득할 수 있다. DHCPINFORM 메시지를 수신하는 서버들은 해당 클라이언트에 적합한 임의의 로컬 구성 파라미터를 사용하여 DHCPACK 메시지를 구성한다. 클라이언트가 임차권을 갖게 된 후, 그 임차권은 임대기간의 만료 전에 다른 DHCP REQUEST 메시지를 통하여 갱신되어야 한다. 클라이언트가 임대기간이 만료되기 전에 임차권의 사용을 종료하는 경우, 그 클라이언트는 DHCP RELEASE 메시지를 서버에 발송하여, 다른 노드들이 그 임차권을 사용할 수 있게 한다. 서버가 임대기간의 만료시까지 클라이언트로부터 아무것도 수신하지 않으면, 서버는 그 임차권이 갱신되지 않을 것으로 표시하여 다른 클라이언트들이 사용할 수 있게 한다.

종래의 DHCP 제공 시스템에서, DHCP 서버는 네트워크 액세스를 요청하고 있는 클라이언트들이 검증된 보증서(credentials)를 갖는지를 보장하기 위한 인증 프로시저를 수행할 수 있다. 예를 들어, 클라이언트에게 DHCP OFFER를 제공하기 전에, 한 조직의 근거리 네트워크(LAN) 상에 있는 DHCP 서버는, 사용자가 LAN에 액세스하도록 인가 받았음을 증명하기 위한 액세스 코드를 요구한다. 인증 프로시저는 인가받지 않거나 악의를 갖는 사용자가 네트워크 자원에 대한 액세스를 획득하는 것을 방지한다. 그러나, 종래의 인증 프로시저는 보안되지 않거나, 심지어는 악의를 갖는 기기들이 네트워크에 액세스하는 것을 방지하지 않는다. 사용자는 네트워크에 액세스하기 위한 유효한 인가를 가질 수 있지만, 그 사용자의 기기는 바이러스에 감염되거나 보안 공백을 포함할 수 있는데, 이것은 기기가 네트워크에 대한 액세스를 허가받기 전에 정정되어야만 한다.

불량한 보안 상태를 갖는 기기가 네트워크에 위험을 부과하는 다른 환경은 VPN이다. VPN은 인터넷과 같은 공유 또는 공중 네트워크를 통한 링크들을 포함하는 사설 네트워크(private network)의 확장이다. VPN은 포인트-투-포인트 사설 링크의 특성을 에뮬레이트하는 방식으로, 공유 또는 공개 인터네트워크를 통하여 2개의 컴퓨터 간에서 데이타를 송신할 수 있게 해 준다. 가상 사설 네트워크를 구성 및 생성하는 동작은 가상 사설 네트워킹으로 알려져 있다. 포인트-투-포인트 링크를 에뮬레이트 하기 위하여, 데이타는 공유 또는 공중 중계 인터네트워크(transit internetwork)를 횡단하여 최종 목적지에 도달할 수 있게 해 주는 라우팅 정보를 제공하는 헤더와 함께 캡슐화 또는 랩핑된다(wrapped). 사설 링크를 에뮬레이트하기 위하여, 송신되는 데이타는 비밀성을 위하여 암호화된다. 공유 또는 공중 네트워크 상에서 인터셉트되는 패킷들은 암호키 없이는 해독될 수 없다. 개인 데이타(private data)가 캡슐화되는 접속의 부분은 터널로 알려져 있다. 개인 데이타가 암호화되는 접속의 부분은 VPN 접속으로 알려져 있다.

또한, VPN은 인증 프로토콜을 사용한다. 네트워크 액세스 서버(NAS)는 원격의 VPN 클라이언트에게 세션 ID와 임의의 챌린지 스트링을 포함하는 챌린지(challenge)를 송신한다. 원격 클라이언트는 사용자 이름과, 암호화된 형태의 챌린지 스트링, 세션 ID 및 MD4-해시 패스워드를 리턴해야 한다. 패스워드의 MD4 해시를 사용하는 설계는, 서버가 비암호화된(clear-text) 패스워드 대신에 해시된 패스워드를 저장할 수 있게 해 주기 때문에, 추가 레벨의 보안을 제공한다. 그러나, 전술한 바와 같이, 종래의 인증 프로시저는 보안되지 않거나 심지어는 악의를 갖는 기기들이 네트워크에 액세스하는 것을 방지하지 않는다. VPN 클라이언트는 유효한 인증을 제공할 수 있지만, 그 VPN 클라이언트 기기 자체는 바이러스에 감염되거나, 보안 공백을 포함할 수 있는데, 이것은 기기가 VPN에 대한 액세스를 허가받기 전에 정정되어야만 한다.

사용자 인증이 불충분한 또다른 환경은 IPsec의 사용이다. IPsec는 비밀성을 보장하기 위한 2개의 기능, 즉 데이타 암호화와 데이타 무결성(integrity)을 정의한다. IPsec는 암호화없이 소스 인증 및 무결성을 제공하기 위한 인증 헤더(AH)와, 암호화와 함께 인증 및 무결성을 제공하기 위한 ESP(Encapsulating Security Payload)를 사용한다. IPsec를 사용하면, 발신자와 수신자만이 비밀키를 알게 된다. 인증 데이타가 유효한 경우, 수신자는 해당 통신이 발신자로부터 온 것이며 중계시에 변경되지 않았다는 것을 알게 된다.

IPsec는 TCP/IP 스택 하의 한 계층으로서 볼 수 있다. 이러한 계층은 각 컴퓨터 상의 보안 정책과, 발신자와 수신자 간에 협상된 보안 제휴(security association)에 의해 제어된다. 정책은 필터 및 관련된 보안 태도의 세트로 구성된다. 패킷의 IP 어드레스, 프로토콜 및 포트 번호가 필터에 일치하는 경우, 그 패킷은 관련 보안 거동에 속하게 된다. 최초의 그러한 패킷은 발신자와 수신자 간의 보안 제휴에 관한 협상을 트리거한다. 인터넷 키 교환(Internet Key Exchange, IKE)이 이러한 협상을 위한 표준 프로토콜이다. IKE 협상 동안, 2개의 컴퓨터는 인증 및 데이타 보안 방법에 동의하고, 상호 인증을 수행한 후, 후속하는 데이타 암호화를 위한 공유키를 생성한다.

보안 제휴가 확립된 후, 원격 수신기에 전송하는 패킷에 대해 데이타 보안 처리를 적용하여, 각 컴퓨터에 대한 데이타 전송이 진행될 수 있다. 이러한 처리는 단순히 전송되는 데이타의 무결성을 보장하는 것일 수도 있고, 또는 전송되는 데이타를 암호화하는 것일 수도 있다. IP 페이로드에 대한 데이타 무결성 및 데이타 인증은 IP 헤더와 전송 계층 헤더(transport header) 사이에 위치된 인증 헤더에 의해 제공될 수 있다. 인증 헤더는 인증 데이타와 순차 번호를 포함하며, 이들은 발신자를 검증하고, 메시지가 중계시에 수정되지 않았음을 보장하고, 재전송된 공격(replay attack)을 방지하기 위해 함께 사용될 수 있다.

그러나, 전술한 바와 같이, 종래의 인증 프로시저는 보안되지 않은, 심지어는 악의를 갖는 기기들이 네트워크에 액세스하는 것을 방지하지 않는다. 컴퓨터는 유효한 인증을 제공할 수 있지만, 그 기기 자체는 바이러스에 감염되거나, 보안 공백을 포함할 수 있는데, 이것은 기기가 다른 컴퓨터의 네트워크 자원들에 대한 액세스를 허가받기 전에 정정되어야만 한다.

IEEE 802.1x는 802.11 무선 네트워크 및 유선 이더넷 네트워크에 대하여 인증된 네트워크 액세스를 제공하는 포트 기반의 네트워크 액세스 제어를 위한 표준이다. 포트 기반의 네트워크 액세스 제어는 근거리 교환망(Switched local area network)기반의 물리적 특징을 이용하여, LAN 포트에 접속한 장치들을 인증하고, 인증 프로세스가 실패한 경우에는 해당 포트로의 액세스를 금지한다.

포트 기반의 네트워크 액세스 제어 대화 과정 동안, LAN 포트는 2가지 역할, 즉 인증자(autheticator) 또는 탄원자(supplicant) 중 하나를 취한다. 인증자의 역할을 하는 경우, LAN 포트는 사용자가 그 포트를 통해 액세스될 수 있는 서비스에 액세스하는 것을 허용하기 전에 인증을 시행한다. 탄원자의 역할을 하는 경우, LAN 포트는 인증자의 포트를 통해 액세스될 수 있는 서비스들에 대한 액세스를 요청한다. 별도의 엔티티(entity)일 수도 있고 인증자와 같이 위치할 수도 있는 인증 서버는, 인증자를 대신하여 탄원자의 보증서를 검사한다. 그 다음, 인증 서버는 인증자에 응답하여, 탄원자가 그 인증자의 서비스에 액세스하도록 허가받았는지를 나타낸다.

인증자의 포트 기반 네트워크 액세스 제어는 하나의 물리적인 LAN 포트를 통 하여 LAN에 대한 2개의 논리적인 액세스 포인트를 정의한다. 제1의 논리적 액세스 포인트인 비제어된 포트는 컴퓨터의 인증 상태에 무관하게 인증자와 LAN 네트워크 상의 다른 컴퓨터들 간의 데이타 교환을 허용한다. 제2의 논리적 액세스 포인트인 제어된 포트는 인증된 LAN 사용자와 인증자 간의 데이타 교환을 허용한다. IEEE 802.1x는 RADIUS(Remote Authentication Dial-In User Service)와 같은 표준 보안 프로토콜을 사용하여, 집중식의 사용자 식별, 인증, 동적 키 관리 및 계정 처리(accounting)을 제공한다.

따라서, 본 기술 분야에서는, 클라이언트가 보안되어 자신의 보안 상태를 증명할 수 있을 때까지는, 그 클라이언트에게 네트워크 액세스를 제공하지 않을 것을 보장하는 방법 및 시스템이 필요하다.

이상을 고려하여, 본 발명은 검역 정책을 시행하는 서버와 대화하기 위한 것으로서, 네트워크 프로토콜을 통하여 서버와 통신하기 위한 적어도 하나의 시행 클라이언트, 및 적어도 하나의 정책 클라이언트로부터 적어도 하나의 건강 문장(statement of health)을 획득하는 조정 클라이언트를 포함하는 네트워크 검역 클 라이언트를 제공하며, 여기에서 조정 클라이언트는 적어도 하나의 정책 클라이언트가 조정 클라이언트와 통신할 수 있게 하는 인터페이스를 공표하며, 또한 적어도 하나의 건강 문장을 건강 목록 문장으로 조합하여, 적어도 하나의 시행 클라이언트에 그 건강 목록 문장을 제공한다. 본 발명의 일 실시예에서, 적어도 하나의 시행 클라이언트는 건강 목록 문장을 사용하여, 서버로부터 네트워크 자원들에 대한 액세스를 획득한다. 본 발명의 특징을 유지하면서, 적어도 하나의 시행 클라이언트는 동적 호스트 제어 프로토콜 및 가상 사설 네트워크 클라이언트, IPsec 클라이언트 중 하나이다. 조정 클라이언트는 적어도 하나의 정책 클라이언트에 의해 제공된 인터페이스를 통하여 적어도 하나의 정책 클라이언트와 통신한다. 조정 클라이언트 및 시행 클라이언트는 컴퓨터의 운영 체제에 포함될 수 있다.

본 발명의 다른 실시예는 네트워크 검역 정책을 시행하기 위한 것으로서, 네트워크 프로토콜을 통하여 적어도 하나의 클라이언트와 통신하기 위한 적어도 하나의 시행 서버, 및 시행 서버로부터 적어도 하나의 건강 문장을 포함하는 건강 목록 문장을 수신하고 적어도 하나의 정책 서버에 질의하여 적어도 하나의 건강 문장을 검증하기 위한 조정 서버를 포함하는 네트워크 검역 서버를 포함한다. 각각의 건강 문장이 검증되는 경우, 조정 서버는 적어도 하나의 시행 서버에 네트워크 자원들에 대한 적어도 하나의 클라이언트 액세스를 인가할 것을 지시한다. 각각의 건강 문장이 검증되지 않는 경우, 조정 서버는 적어도 하나의 시행 서버에 적어도 하나의 정책 서버로부터 획득된 검역 정책을 시행할 것을 지시한다. 본 발명의 특징을 유지하면서, 조정 서버는, 적어도 하나의 정책 서버가 조정 서버와 통신할 수 있게 하는 인터페이스를 공표한다. 조정 서버는 적어도 하나의 정책 서버에 의해 제공되는 인터페이스를 통하여 적어도 하나의 정책 서버와 통신한다.

본 발명의 다른 실시예에서는, 정책 클라이언트가 검역 클라이언트와 통신할 수 있게 해 주기 위한 것으로서, 정책 클라이언트를 검역 클라이언트에 바인딩하기 위한 바인드 콜(bind call) 및 검역 클라이언트에게 검역 정책의 변경을 알리는 통지 콜(notification call)을 포함하는 애플리케이션 프로그래밍 인터페이스가 제공된다.

본 발명의 또 다른 실시예에서는, 검역 클라이언트가 정책 클라이언트와 통신할 수 있게 해 주기 위한 것으로서, 정책 클라이언트로부터 건강 문장을 획득할 수 있게 해 주는 겟 콜(get call)을 포함하는 애플리케이션 프로그래밍 인터페이스가 제공된다.

본 발명의 또 다른 실시예에서는, 정책 서버가 검역 서버와 통신할 수 있게 해 주기 위한 것으로서, 정책 클라이언트를 검역 클라이언트에 바인딩하기 위한 바인드 콜, 및 건강 문장이 유효함을 알리기 위한 응답 콜(response call)을 포함하는 애플리케이션 프로그래밍 인터페이스가 제공된다.

본 발명의 또 다른 실시예에서는, 검역 서버가 정책 서버와 통신할 수 있게 해 주기 위한 것으로서, 정책 서버에 의해 건강 문장을 검증하기 위한 검증 콜(validate call)을 포함하는 애플리케이션 프로그래밍 인터페이스가 제공된다.

본 발명의 또 다른 실시예에서, 네트워크 검역 관리를 위한 방법은, 네트워크 자원을 요청하는 클라이언트로부터 획득된 건강 문장을 원격지에 위치하는 동적 호스트 제어 프로토콜(DHCP) 서버로부터 수신하는 단계(건강 문장은 클라이언트의 시스템 상태를 반영함); 건강 문장을 검증하는 단계; 건강 문장이 유효한 경우, DHSP 서버에 요청을 인가할 것을 지시하는 단계; 및 건강 문장이 유효하지 않은 경우, DHCP 서버에 요청을 인가하지 않고 클라이언트를 검역소에 위치시킬 것을 지시하는 단계를 포함한다.

본 발명의 또다른 특성 및 이점들은, 첨부 도면을 참고로 하는 이하의 실시예에 관한 상세한 설명으로부터 분명하게 알 수 있을 것이다.

본 명세서에 포함되어 그 일부를 형성하는 첨부 도면들은 본 발명의 여러가지 양태를 나타내며, 상세한 설명과 함께 본 발명의 원리를 설명하는 역할을 한다.

본 발명이 특정의 바람직한 실시예들과 관련하여 설명되지만, 본 발명을 이러한 실시예들로 국한하려는 의도는 없다. 반대로, 첨부된 특허청구범위에 정의된 본 발명의 취지 및 범위 내에 포함되는 모든 변형, 변경 및 등가물을 포괄하도록 의도된다.

유사한 참조번호들이 유사한 구성요소를 나타내고 있는 도면들을 보면, 본 발명은 적합한 컴퓨팅 환경 내에서 구현되는 것으로서 도시되어 있다. 아래의 설명은 본 발명의 실시예들에 기초하는 것이며, 여기에 명시적으로 설명되지 않은 다른 실시예들과 관련하여 본 발명을 제한하는 것으로 해석되어서는 안된다.

이하의 상세한 설명에서, 본 발명은 다르게 표시되지 않는 한, 하나 이상의 컴퓨팅 장치에 의해 수행되는 연산들의 기호적 표현과 동작들을 참조하여 설명된 다. 이와 같이, 종종 컴퓨터에 의해 실행되는 것으로서 언급되는 이러한 동작 및 연산은 컴퓨팅 장치의 프로세싱 유닛에 의하여 구조화된 형태의 데이타를 나타내는 전기적 신호들을 조작하는 것을 포함한다 것으로 이해될 것이다. 이러한 조작은 데이타를 변환하고, 컴퓨팅 장치의 시스템 메모리 내에 이 데이타를 저장하는 것으로, 이것은 본 기술 분야의 숙련된 기술자들에 의하여 잘 이해될 수 있는 방식으로 장치의 동작을 재구성 또는 변경한다. 데이타가 유지되는 데이타 구조는, 데이타의 포맷에 의해 정의되는 특정한 속성들을 갖는 메모리의 물리적 위치이다. 그러나, 본 발명이 이러한 문맥으로 설명되긴 하지만, 제한하려는 의도는 없으며, 본 기술 분야의 숙련된 기술자라면 이하에 설명되는 다양한 동작 및 연산이 하드웨어로도 구현될 수 있음을 알 수 있을 것이다.

본 발명이 사용될 수 있는 네트워크화된 환경의 일례가 도 1a를 참조하여 설명될 것이다. 예시적인 네트워크는 구름으로 표시된 네트워크(111)를 통하여 서로 통신하는 수개의 컴퓨터(110)를 포함한다. 네트워크(111)는 라우터, 게이트웨이, 허브 등과 같은 공지된 다수의 컴포넌트를 포함할 수 있으며, 컴퓨터(110)가 유선 및/또는 무선 매체를 통해 통신할 수 있게 해 준다. 네트워크(111)를 통하여 서로 대화할 때, 컴퓨터들 중 하나 이상은 다른 컴퓨터들에 대하여 클라이언트, 네트워크 서버, 검역 서버 또는 피어의 역할을 할 수 있다. 따라서, 본 발명의 다양한 실시예는 클라이언트, 네트워크 서버, 검역 서버, 피어 또는 이들의 조합에서 구현될 수 있지만, 여기에 포함되어 있는 특정 예들이 모든 유형의 컴퓨터들을 언급하고 있는 것은 아니다.

도 1b는 본 발명이 구현될 수 있는 적합한 컴퓨팅 환경(100)의 일례를 도시한 것이다. 컴퓨팅 시스템 환경(100)은 적합한 컴퓨팅 환경의 일례일 뿐이며, 본 발명의 용도 또는 기능성의 범위에 어떠한 제한을 가하기 위한 것은 아니다. 컴퓨팅 환경(100)은 예시적인 컴퓨팅 환경(100) 내에 도시되어 있는 컴포넌트들 중의 어느 하나 또는 그들의 조합에 관련된 어떠한 종속성 또는 조건을 갖는 것으로 해석되어서는 안된다.

본 발명은 다양한 기타의 일반 목적 또는 특수 목적 컴퓨팅 시스템 환경 또는 구성에 적용될 수 있다. 본 발명에서 사용되기에 적합한 공지된 컴퓨팅 시스템, 환경 및 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 휴대형 또는 랩탑 장치들, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋탑 박스, 프로그래밍가능한 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템 또는 장치 중 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 포함되지만, 이들로 제한되는 것은 아니다.

본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 문맥으로 설명된다. 일반적으로, 프로그램 모듈은 특정 태스크(task)를 수행하거나 특정 추상 데이타 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이타 구조 등을 포함한다. 본 발명은 통신 네트워크를 통하여 링크된 원격 프로세싱 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서도 구현될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체 둘다에 위치될 수 있다.

도 1b를 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은, 본 발명의 문맥 내에서 클라이언트, 네트워크 서버, 검역 서버 또는 피어로서 동작할 수 있는 컴퓨터(110)의 형태로 된 일반 목적 컴퓨팅 장치를 포함한다.

컴퓨터(110)의 컴포넌트로는 프로세싱 유닛(120), 시스템 메모리(130) 및 시스템 메모리(130)를 프로세싱 유닛(120)에 연결시키는 것을 포함하여 여러 시스템 컴포넌트를 연결시키는 시스템 버스(121)가 있을 수 있지만, 이것으로 제한되는 것은 아니다. 시스템 버스(121)는 메모리 버스 또는 메모리 제어기, 주변 장치 버스 및 다양한 버스 아키텍처들 중 임의의 것을 사용하는 로컬 버스를 포함하는 몇몇 유형의 버스 구조들 중 임의의 것일 수 있다. 예를 들어, 그러한 아키텍처로는 상업 표준 아키텍처(ISA:Industry Standard Associsate) 버스, 마이크로 채널 아키텍처(MCA:Micro Channel Architecture) 버스, 강화된 ISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Associate) 로컬 버스, 및 메자닌 버스로도 알려진 PCI(Peripheral Component Interconnect) 버스가 있지만, 이것으로 제한되는 것은 아니다.

컴퓨터(110)는 일반적으로 다양한 컴퓨터-판독가능 매체를 포함한다. 컴퓨터-판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 사용가능한 매체일 수 있고, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체를 둘 다 포함한다. 예를 들어, 컴퓨터-판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터-판독가능 명령어, 데이타 구조, 프로그램 모듈 또는 다른 데이타와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분리형 및 비분리형 매체 둘 다를 포함한다. 컴퓨터 저장 매체로는, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 다른 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 다른 자기 저장 장치, 또는 요청된 정보를 저장하는 데 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 다른 매체가 있을 수 있지만, 이것으로 제한되는 것은 아니다. 통신 매체는 일반적으로, 컴퓨터-판독가능 명령어, 데이타 구조, 프로그램 모듈 또는 다른 데이타를 반송파 또는 다른 전송 매커니즘과 같은 변조된 데이타 신호로 구현하며, 임의의 정보-전달 매체를 포함한다. "변조된 데이타 신호"라는 용어는 정보를 신호로 인코딩하는 방법으로 설정 또는 변경된 특징들 중 하나 이상을 갖는 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접-유선 접속과 같은 유선 매체, 및 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하지만, 이것으로 제한되는 것은 아니다. 상술된 것들 중 임의의 조합도 컴퓨터-판독가능 매체의 범위 내에 포함된다.

시스템 메모리(130)는 판독 전용 메모리(ROM:131) 및 랜덤 액세스 메모리(RAM:132)와 같은 휘발성 및 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 동작 개시와 같이, 컴퓨터(110) 내의 구성요소들 사이에서 정보의 전송을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(133:BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 즉시 액세스가능하거나 현재 프로세싱 유닛(120)에 의해 동작 중인 데이타 및 프로그램 모듈을 포함한다. 예를 들면, 도 1b 는 운영 체제(134), 애플리케이션 프로그램들(135), 다른 프로그램 모듈들(136) 및 프로그램 데이타(137)를 도시하지만, 이것으로 제한되는 것은 아니다.

컴퓨터(110)는 또한, 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예를 들면, 도 1b는 비분리형, 비휘발성 자기 매체로부터 판독하거나 그곳에 기록하는 하드 디스크 드라이브(141), 분리형, 비휘발성 자기 디스크(152)로부터 판독하거나 그곳에 기록하는 자기 디스크 드라이브(151), 및 CD ROM 또는 다른 광 매체와 같은 분리형 비휘발성 광 디스크(156)로부터 판독하거나 그곳에 기록하는 광 디스크 드라이브(155)를 도시한다. 예시적인 컴퓨팅 환경(100)에 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체로는, 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM(solid state RAM), 고체 상태 ROM(solid state ROM) 등이 있지만, 이것으로 제한되는 것은 아니다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 비분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

도 1b에서 도시되고 상술된 드라이브 및 그에 관련된 컴퓨터 저장 매체는 컴퓨터-판독가능 명령어, 데이타 구조, 프로그램 모듈 및 다른 데이타를 컴퓨터(110)에 제공한다. 도 1b에서, 예를 들면, 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램들(145), 다른 프로그램 모듈들(146) 및 프로그램 데이타(147)를 저장하는 것으로서 도시된다. 이러한 컴포넌트들은 운영 체제(134), 애플리케이션 프로그램들(135), 다른 프로그램 모듈들(136) 및 프로그램 데이타(137)와 동일할 수도 있고 상이할 수도 있음을 유념한다. 운영 체제(144), 애플리케이션 프로그램들(145), 다른 프로그램 모듈들(146) 및 프로그램 데이타(147)는 적어도 그들이 다른 복사본이라는 것을 나타내기 위해 상이한 번호를 부여받는다.

사용자는 키보드(162), 및 주로 마우스, 트랙볼 또는 터치 패드라고 지칭되는 포인팅 장치(161)와 같은 입력 장치를 통해 명령 및 정보를 컴퓨터(110)에 입력할 수 있다. 다른 입력 장치(도시되지 않음)로는, 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너 등이 있을 수 있다. 이러한 입력 장치 및 그 외의 입력 장치는 종종, 시스템 버스(121)에 연결되어 있는 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터(191) 외에, 컴퓨터(110)는 또한, 주변장치 출력 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 다른 주변 출력 장치를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 또 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 도 1b에는 메모리 저장 장치(181)만이 도시되어 있지만, 일반적으로 퍼스널 컴퓨터(110)와 관련하여 상술된 구성요소들의 다수 또는 전부를 포함한다. 도 1b에 도시된 논리 접속은 근거리 통신망(LAN:171) 및 광대역 통신망(WAN:173)를 포함하지만, 다른 네트워크도 포함할 수 있다. 그러한 네트워크 환경은 사무실, 기업형 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한다.

LAN 네트워크 환경에서 사용될 때, 퍼스널 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용될 때, 컴퓨터(110)는 일반적으로 모뎀(172), 또는 인터넷과 같은 WAN(173) 상의 통신을 설립하기 위한 다른 수단을 포함한다. 내장 또는 외장일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적절한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 퍼스널 컴퓨터(110)에 관련하여 도시된 프로그램 모듈, 또는 그 일부는 원격 메모리 저장 장치(181)에 저장될 수 있다. 예를 들면, 도 1b는 원격 애플리케이션 프로그램들(185)을 메모리 장치(181) 상에 상주하는 것으로서 도시할 수 있다. 보여진 네트워크 접속은 예시적인 것이며, 컴퓨터들 간의 통신 링크를 설립하는 다른 수단이 사용될 수 있음을 이해할 것이다.

다음의 설명에서, 본 발명은 달리 설명되지 않는 한, 하나 이상의 컴퓨터에 의해 수행되는 액션, 및 동작의 기호 표현을 참조하여 설명된다. 그러한 것으로서, 때때로 컴퓨터-실행되는 것으로 지칭되는 그러한 액션 및 동작은 컴퓨터의 프로세싱 유닛에 의한, 구조화된 형태의 데이타를 나타내는 전자 신호의 조작을 포함한다는 것을 이해할 것이다. 이 조작은 데이타를 변형하거나, 그것을 컴퓨터의 메모리 시스템 내의 위치에 유지하는데, 이것은 본 분야에 숙련된 기술자들이 잘 알고 있는 방법으로 컴퓨터의 동작을 재구성하거나 변경하는 것이다. 데이타 포맷에 의해 정의된 특정 속성을 갖는, 데이타가 유지되는 데이타 구조는 메모리의 물리적 위치이다. 그러나, 본 발명은 상술된 문맥에서 설명되고 있지만, 본 분야에 숙련된 기술자들이 이후에 설명되는 다양한 액션 및 동작이 하드웨어에서도 구현될 수 있음을 이해하는 것과 같이, 제한적인 것이 아니다.

도 2를 참조하면, 본 발명의 일 실시예는 적어도 3개의 컴퓨터 즉, 클라이언트(210), 정책 서버(policy server:220) 및 검역 시행 서버(quarantine enforcement server:QES)(230)를 포함한다. 클라이언트(210) 와 QES(230) 기기 사이의 2가지 버전의 대화(interaction)가 존재하는데, 하나는 건강 문장(SoHs:Statement of Healths)들의 목록 및 SoH 응답(SoH Response)들을 포함하고, 다른 하나는 건강 목록표(BoH:Bill of Health)를 포함한다. 본 발명의 또 다른 실시예는 클라이언트가 정책 서버(220)로부터 다운로드된 정책에 따르게 하는 데 필요한 소프트웨어 및 패치 업데이트를 클라이언트(210)에게 제공하기 위한 수리 서버(fix-up sever:240)를 더 포함한다.

정책 서버(220)는 관리자가 클라이언트가 운영 체제(OS) 버전, 안티-바이러스 서명 버전 등을 검사하기를 원하는 조사 정책(inspection policy)을 포함한다. 정책 서버의 예로는 Window® Update Server(WUS) 및 안티-바이러스 서명 업데이트 서버가 있다. 정책 서버는 또한, 클라이언트가 클라이언트를 올바른 구성 예를 들면, 패치, 안티-바이러스 업데이트 등으로 변경할 필요가 있는 정보를 변경한다. 네트워크는 복수의 정책 서버를 포함할 수 있다. 즉, 패치에 대한 하나의 정책 서버, 및 안티-바이러스 서비스에 대한 또 다른 정책 서버가 있을 수 있다. 클라이 언트 조사 정책 및 구성을 위해 관리자는 정책 서버 상의 이에 대한 정책을 변경할 수 있다. 정책 서버는 클라이언트에 조사 정책을 다운로드하고, 정책 관리자가 정책 서버에 구성해 놓은 변경 사항들을 반영한다. 정책 서버는 QES(230)가 클라이언트(210)로부터의 SoH가 유효하다는 것을 검사하게 한다.

정책 관리자는 정책 서버(220) 상에서 클라이언트에게 적용될 정책을 설정한다. 이 정책은 클라이언트(210)에게 다운로드 및 적용된다. 클라이언트(210)가 네트워크 자원 예를 들어, DHCP, 802.1X 등을 요청할 때, 클라이언트(210)는 그 요청과 함께 SoHs 목록을 공급한다. QES(230)는 이 SoHs를 검증하고, 정책 서버(220)에 접속하여 예상된 클라이언트 정책을 획득하고, 네트워크 자원에 대한 응답 및 SoH 응답들을 리턴한다. 네트워크 관리자는 QES(230) 상에서 검역 정책을 구성할 수 있다. 클라이언트(210) 상의 사용자는 기기가 검역상의 이유로 네트워크 자원을 이용하지 못함을 알게되고, 클라이언트가 그 문제를 해결하기 위해 해야하는 것에 관한 더 상세한 정보을 보내줄 것을 요청할 수 있다. 사용자는 지원 정보를 요청할 수도 있다.

클라이언트(210)는 하나 이상의 정책 서버와 통신할 수 있다. 즉, 클라이언트는 예를 들어, 패치에 대한 WUS 서버, 및 안티-바이러스 서명 서버와 같은 복수의 상이한 정책 서버들로부터 정책 및 구성을 획득할 수 있다. 클라이언트(210)는 또한, 하나 이상의 QES(230)와 통신하여 네트워크 자원을 요청한다. 클라이언트는 검역되는 경우, 사용자에게 시스트레이(systray)에 벌룬(balloon) 및 아이콘을 디스플레이한다. 사용자는 검역 상태에 관한 상세사항을 요청할 수 있다. 이것은 어느 정책이 최신인지를 포함한다. 사용자는 검역에 관한 지원 정보를 보기를 요청할 수 있다. 클라이언트(210)는 DHCP 디스커버, 리퀘스트, 802.1X 인증, VPN 인증 및 IPsec IKE 교환을 포함하는 네트워크 자원을 요청한다. 클라이언트(210)는 자신의 SoH 목록을 공급하고, QES(230)는 그 SoH 목록을 검증하여 네트워크 자원으로의 얼마나 많은 액세스가 주어지는지를 결정한다. QES는 네트워크 자원으로의 전체 액세스, 또는 네트워크 자원으로의 제한된 액세스를 이용하여 네트워크 자원에 대한 요청에 응답한다.

QES(230)는 클라이언트로부터 예를 들어, DHCP 요청, 802.1X 인증 요청, IPsec SA 요청 등의 네트워크 요청을 수신한다. 이 네트워크 요청의 일부로서, 클라이언트(210)는 하나 이상의 SoH를 송신한다. 각각의 유형의 정책에 대해서는 하나의 SoH가 있다. 예를 들면, 패치에 대한 건강 상태를 설명하는 하나의 SoH가 있고, 안티-바이러스에 대한 건강 상태를 설명하는 또 다른 SoH가 있다. QES(230)는 필요시, 그 특정 유형의 정책에 대한 정책 서버와 통신함으로써 각각의 SoH를 검증한다. 클라이언트(210)는 2가지 경우 즉, 복수의 유형의 QES(230)(예를 들어, 802.1X RADIUS 서버 및 DCHP 서버)가 배치될 때, 및 클라이언트(210)와 QES(230) 간의 프로토콜이 하나의 유형의 복수의 QES를 지원할 때(예를 들어, DHCP가 복수의 DHCP QES가 응답할 수 있는 DHCP 디스커버에게 브로드캐스트를 송신함), 둘 이상의 QES(230)와 통신한다. 네트워크 관리자는 클라이언트 기기로부터의 SoH를 검증하기 위해 사용하는 정책 서버에 대한 QES(230)뿐만 아니라, 그 검증이 성공 또는 실패할 때의 액세스의 양을 구성할 수 있다.

수리 서버(240)는 기기의 상태를 정정하는 데, 즉, 기기의 상태를 변경하기 위한 정보를 제공하여 검역되지 않게 하는 데 사용될 수 있는 임의의 서버일 수 있다. 정보는 소프트웨어 또는 구성 정보일 수 있다. 검역된 기기는 비-검역된 기기와 통신할 수 없기 때문에, 수리 서버는 검역된 네트워크로부터 사용가능하다. 수리 서버는 보통, 검역되지 않은 기기와 통신하는 데 사용가능할 것이다. 예를 들면, 수리 서버의 예로는, (1) www.windowsupdate.com{여기서, 마이크로소프트가 윈도우 OS 보안 업데이트를 배포하고 클라이언트 업데이트 서비스 및 WUS 클라이언트가 이 위치로부터 보안 업데이트를 다운로드할 수 있다. 윈도우 업데이트가 수리 서버로서 사용되면, 인터넷은 직접적으로 또는 브라우저 프록시를 통해 검역된 기기에 액세스가능할 필요가 있다}, (2) SMS 서버{여기로부터 SMS 클라리언트가 구성 정보, 스크립트 및 소프트웨어를 다운로드한다}, (3) 도메인 제어기{여기에서, 클라이언트 기기에 구성을 배치할 다양한 방법을 갖는다. 이 방법들 중 하나가 사용되면, 도메인 제어기는 수리 서버가 되며, 검역된 기기에 의해 액세스가능해질 필요가 있다}가 있지만, 이것으로 제한되는 것은 아니다.

도 3은 클라이언트(210), 정책 서버(220), QES(230) 및 수리 서버(240) 간 대화들에 대해 나타낸다. 단계(310)에서, 클라이언트는 클라이언트의 보안 및 소프트웨어 상태를 나타내는 SoH 목록을 QES에 송신한다. 단계(320)에서, 클라이언트가 BoH를 포함하는 SoH 응답을 수신하면, 클라이언트는 종료되고 검역을 종료할 수 있다. 그러나, SoH 응답이 BoH를 포함하지 않으면, 단계(330)에서, 클라이언트는 정책 서버로부터 정책 업데이트를 다운로드한다. 이 정책에 기초하여, 단계 (340)에서, 클라이언트는 수리 서버로부터 필요한 업데이트를 다운로드한다. 클라이언트는 단계(350)에서 시스템 건강 검사들을 실행하여, 새로운 SoH 목록을 생성한다. 프로세스는 단계(310)로 되돌아가서 BoH 획득을 재시도한다.

도 4를 참조하면, 클라이언트 기기는 3개의 소프트웨어 컴포넌트 즉, 검역 정책 클라이언트(Quarantine Policy Client:QPC)(410), 검역 조정 클라이언트(Quarantine Coordination Client:QCC)(420) 및 검역 시행자 클라이언트(Quarantine Enforcer Client:QEC)(430)를 포함한다. 클라이언트 기기는 하나 이상의 QPS 예를 들어, QPC(410a), QPC(410b) 및 QPC(410c)를 포함할 수 있다. 각각의 QPC는 하나 이상의 정책 서버(440)와 통신하고 네트워크에 정책 및 구성을 제공한다. QPC는 정책 서버(440)가 제공하는 정책 및 구성의 유형을 이해해야 하기 때문에, 하나 이상의 정책 서버(440)를 제공하는 동일한 엔티티에 의해 공급된다. 각각의 QPC는 SoH를 QCC(420)에 공급한다. QPC는 또한, 자신의 SoH가 변경될 때 QCC(420)를 공지한다. 예를 들어, QPC는 그 정책 서버(440)와 통신하기 때문에, 정책 서버(440)는 요구된 구성 및 조사 요구 사항을 변경할 수 있다. QPC(410)는 이 새로운 정책을 실행하고 다른 SoH를 생성할 것이다. 다양한 QPC로부터 SoH를 수집하는 단일 QCC가 있다. QCC(420)는 QPC가 사용가능(예를 들어, 기기 부팅)하지 않는 경우에 이 SoH를 캐싱한다. QCC(420)는 QEC로부터 수요가 있는 즉시, SoH 목록을 하나 이상의 QEC(430)에 제공한다.

클라이언트 기기는 하나 이상의 QEC, 예를 들어, DHCP에 대한 QEC(430), IPsec에 대한 QEC(430b), 802.1X에 대한 QEC(430c)를 포함할 수 있다. 각각의 QEC 는 QES(450)와 통신한다. QEC(430)는 보통, 네트워크 자원에 대해 요구를 생성하는 프로토콜을 사용하여 통신하는 기존의 컴포넌트이다. 검역은 QEC(430)를 통해 클라이언트의 건강 상태에 관한 정보를 QES 프로토콜에 전달함으로써 획득되는 자원을 제한함으로써 구현되는데, 이 프로코콜의 예로는 DHCP, IEEE 802.1X 및 VPN에 대한 PEAP, 및 IPsec이 있다. DHCP에 대하여, DHCP 프로토콜은 SoH 목록을 전달한다. QEC(430)가 네트워크 요구를 생성할 필요가 있을 때, QCC(420)로부터 SoH 목록을 획득한다.

도 5를 참조하면, 클라이언트(560)는 QCS(530)에게 목록을 전달하는 프로토콜-특정 검역 시행 서버(QES:540)에 SoH 목록을 송신함으로써 검역 서버(QS:510)와 통신할 수 있다. QS(510)는 하나 이상의 정책 서버(550)와 통신하여 검역 정책 서버(QPS:520)에 대한 정책 업데이트를 획득할 수 있다. QCS(530)는 BoH가 하나 이상의 QPS(520)에게 BoH 목록을 송신하여 SoH를 검증함으로써 발행되어야 하는지를 결정할 수 있다. QPS(520)는 SoH 응답을 QCS(530)에게 송신하고, QCS(530)는 그것을 적절한 QES(540)에 제공하고, QES(540)는 그것을 클라이언트(560)에게 송신한다. BoH가 발행되면, QCS(530)는 SoH 응답과 함께 BoH를 포함한다.

도 6은 본 발명의 일 실시예의 대한 컴포넌트들의 대화 방법을 예시적으로 나타낸다. 단계(601)에서, QPC는 업데이트된 정책을 클라이언트에 다운로드한다. 다운로드된 정책은 QPC의 유형 예를 들어, 패치 클라이언트 또는 안티-바이러스 클라이언트에 특정적이다. 단계(602)에서, QPC는 QCC에게 QPC 정책에 관한 정책 변경을 통지한다. 단계(603)에서, QCC는 하나 이상의 QEC에게 정책의 변경을 통지한 다. 단계(604)에서, QEC는 QCC로부터의 SoH 목록을 요구한다. 단계(605)에서, QCC는 하나 이상의 QPC로부터의 SoH 전부를 요구한다. 단계(606)에서, 각각의 QPC는 그 SoH를 송신한다. 단계(607)에서, QCC는 SoH 목록을 QEC에 전송한다. 단계(608)에서, QEC는 SoH 목록을 QS의 QES에 전달하고, BoH를 요구한다. QES는 단계(609)에서 SoH의 검증을 요구한다. QCS는 SoH를 수신하고, 검증을 위해 각각의 SoH를 적절한 QPS에 전송한다. QPS가 현재 정책을 갖고 있지 않으면, 단계(611)에서 정책 서버로부터 그것을 다운로드한다. QPS는 SoH를 검증하고, 단계(612)에서, 그 결과를 SoH 응답으로서 QCS에 전송한다. QCS는 SoH 응답을 수집하고 단계(613)에서 그것을 QES에 전송하여, 단계(614)에서 QES가 SoH 응답을 그들의 공유된 프로토콜에 따라 적절한 QEC에 전송할 수 있다. SoH가 검증되면, QCS는 또한, SoH 응답과 함께 BoH를 포함한다.

또한, 도 7을 참조하면, 전체 아키텍처는 클라이언트로서 동작하는 컴포넌트, 및 서버로서 동작하는 컴포넌트를 포함한다(클라이언트 및 서버 컴포넌트는 동일한 기기 상에 있을 수 있고, 예를 들어, IPsec은 피어에게 요구를 생성할 때 클라이언트일 수 있고 피어로부터 요구를 수용할 때 서버일 수 있음을 유념한다). QPC는 기기의 상태를 획득하고 그것을 변경할 수 있다. 즉, QPC는 관리자가 기기를 "건강 양호(healthy)" 또는 "건강 비양호(unhealthy)" 하다고 결정한, 그 기기의 상태 정보를 획득한다. QPC는 QCC에게 SoH를 제공한다. QCC는 QEC가 클라이언트의 SoH를 필요할 때를 위한 정보를 저장한다. QEC가 네트워크 요구를 생성할 필요가 있을 때마다, QCC로부터 SoH를 획득하고 그것을 QEC의 QES에 송신한다. QES 는 SoH를 QCS에 전달한다. QCS는 SoH를 올바른 QPS에 전달한다. 정책 서버/QPS는 기기의 상태를 검사하고, 클라이언트 기기가 "건강 양호(healthy)" 또는 "건강 비양호(unhealthy)" 한지를 QCS에게 알린다. QEC 및 QES는 예를 들어, VPN, DHCP 및 IPsec과 같은 네트워크 자원으로의 액세스를 허용하거나 허용하지 않을 수 있는 다양한 기술이다. QES 컴포넌트는 QCS가 클라이언트 기기가 "건강 양호(healthy)" 아니면 "건강 비양호(unhealthy)"인 것으로 결정하는 것에 따라 네트워크 자원을 제공 또는 거부하고, 시행이 수행되어야 할지 수행되지 말아야 할지에 관한 정책 결정은 QPS로부터 그 결과를 로그하도록 선택할 수 있지만, QPS로부터의 결과에 상관없이 성공을 리턴할 수 있다.

모든 QPS가 매칭되는 QPC를 갖는 것이 요구되지는 않는다. QCS는 QCS에게 "바인드(bind)" 호출을 하는 모든 QPS를 호출한다. SoH가 QPS에 사용가능하지 않으면, 빈 SoH가 전달되고, 빈 SoH 응답이 리턴된다. 네트워크 자원을 공급 또는 거부하는 네트워크 기술인 QES 외에, QES는 또한, 독립형 검역 서버일 수 있다. 이 역할에서, 검역 서버 QES는 QPC의 "건강 상태"를 수용하고, 다양한 SoH를 검증하하고, QES가 클라이언트 기기의 상태를 검증하는 데 자신의 QPS를 사용할 필요 없이, 다른 QEC/QES에 의해 사용될 수 있는 BoH를 QCC에 리턴할 수 있다.

QPC와 정책 서버 사이에서 사용된 프로토콜은 QPC 및 정책 서버에 의존한다(WUS는 자신의 프로토콜을 정의함). QCC와 QCS 사이에서 사용된 프로토콜은 SoH 및 SoH 응답 버퍼를 전달한다. 프로토콜은 시행자 프로토콜을 통해 전달된다. QEC와 QES 사이에서 사용된 프로토콜은 시행자 기술에 의존한다. DHCP QEC/QES는 DHCP 프로토콜을 사용한다. SoH 및 SoH 응답은 DHCP 벤더 옵션을 통해 전달된다. PEAP QEC/QES는 PEAPv2 프로토콜을 사용한다. SoH 및 SoH 응답은 PEAP TLV를 통해 전달된다. SoH 및 SoH 응답은 또한, XML로서 SOAP를 통해 전달될 수 있다.

도 8을 참조하면, 본 발명의 일 실시예에서, QEC/QES는 DHCP를 사용하여 통신한다. DHCP 검역은 기기에 디폴트 게이트웨이 주소를 제공하지 않지만, DHCP, DNS 및 패치 서버(예를 들면, WUS)와 같은 선택된 기기에 정적 라우트를 제공한다. 그것은 또한, 255.255.255.255에 공급된 IP 주소에 대한 넷마스크(netmask)를 설정하여, 일반 로컬 서브넷에는 어떤 라우트도 존재하지 않는다. 따라서, 애플리케이션이 허용된 주소가 아닌 임의의 다른 IP주소에 송신하려고 하면, TCP/IP 스택에서 목적지 도달 불가 에러가 발생할 것이다. DHCP 서버는 관리된 기기이기 때문에, 기기 내에 QPS를 포함할 수 있다.

QPC 및 QPS/정책 서버(850) 예를 들어, SMS 또는 WUS는 클라이언트(810)에 대한 정책을 서버(860)로부터 클라이언트(810)로 전송할 수 있다. QPC(820)는 업데이트를 위해 서버를 소정의 간격으로 폴링(poll)할 것이다. QPC(820)는 기기의 "건강 상태"가 변할때마다, 그 SoH를 QCC(830)에 발행할 것이다. QCC(830)는 QPC(820) 각각으로부터 SoH 목록으로 SoH를 수집할 것이다. QCC(830)는 모든 QEC에게 SoH가 변경되었음으로 통지한다. QEC(DHCP 클라이언트)(840)는 IP 주소 또는 IP 주소의 갱신을 요구하기 원할 때, QPC로부터 SoH 목록을 획득하고 QCC(830)를 통해 SoH 캐시를 획득하고, 하나 이상의 DHCP 옵션을 사용하여 QES(DHCP 서버:890)에 그것을 전달한다. QES(DHCP 서버:890)는 SoH 목록을 각각의 SoH를 올바른 QPS(870)에 전달하는 QCS(880)에 제공한다. 각각의 QPS(870)는 그 정책 서버(850)에 컨택트하여, 클라이언트에 대한 SoH가 그 클라이언트에 대해 올바르고 현재 통용중이라는 것 예를 들어, 이 클라이언트에 설치될 패치가 없다는 것을 검증할 수 있다. 클라이언트가 현재 통용중이고 올바르면, QPS(870)는 QCS(880)에 성공을 리턴한다. QPS가 QCS(880)에게 성공을 리턴하면, QCS(880)는 QES(DHCP 서버:890)에 성공을 리턴한다. QES(DHCP 서버:890)는 BoH를 포함하여 QEC(DHCP 클라이언트:840)에 올바른 DHCP 옵션을 리턴한다.

도 9를 참조하면, 본 발명의 일 실시예에서, QEC/QES는 IPsec 프로토콜을 사용하여 통신한다. IPsec 검역 시행은 검역 중, 클라이언트 기기로부터의 IPsec SA를 거절 설정함으로써 작용한다. 검역 중이 아닌 기기는 검역 중인 기기로부터 IPsec SA를 수락하지 않을 것이다. 검역 시스템은 몇몇 기기 및 장치를 면제할 방법이 필요하다. 검역 클라이언트는 단지 몇몇 OS 상에서 지원되거나, 다른 OS를 실행하는 기기는 항상 검역되거나, 네트워크 관리자는 이 기기가 정책 검사를 실행하지 않을 것이지만 여전히 비 검역 기기에 전달하도록 허용될 것임을 수용해야 한다.

IPsec 클라이언트가 다른 클라이언트로부터 직접 네트워크 자원을 요청하기 때문에, 피어 IPsec 클라이언트는 QPS를 직접적으로 사용할 수 없다. QCC는 검역 서버 QEC를 이용하여 IPsec이 IKE를 변경하지 않고 IKE 내의 피어로 전달할 수 있는 X.509 인증이 될 BoH를 획득하여야 한다.

QPC 및 QPC/정책 서버(예를 들면, SMS 또는 WUS)(960)는 클라이언트(920)에 대한 정책을 서버(970)로부터 클라이언트(910)까지 통신할 수 있다. QPC(920)는 업데이트를 위해 정책 서버를 규칙적인 간격으로 폴링할 수 있다. 기기의 "건강 상태"가 변경될 때마다, QPC(920)는 QCC(930)에게 자신의 SoH 발표할 수 있다. QCC(930)는 각각의 QPC로부터의 SoH를 SoH의 리스트로 모을 수 있다. QCC(930)는 SoH가 변경될 때마다 모든 QEC에게 통지한다. 이러한 통지를 수신하고 있는 QS QEC(940)는 SoH를 획득하고 이를 QS의 QES(976)에 송신한다. 검역 서버 QES(976)는 각 SoH에 정정된 QPS(972)를 전달하는 QCS(974)에 SoH 리스트를 제공한다. 각 QPS는 자신의 정책 서버(960)를 접촉하여 클라이언트에 대한 SoH가 정정되고 그 클라이언트에 유통되고 있는지, 예를 들면 이러한 클라이언트에 어떠한 패치도 설치되지 않았는지 검사할 수 있다. 클라이언트가 정정되고 유통되고 있다면, QPS(972)는 QCS(974)로 성공을 리턴한다. 모든 QPS가 QCS(974)에게 성공을 리턴한다면, QCS(974)는 검역 서버 QES(976)에 성공을 리턴한다. 검역 서버 QES(976)는 QCS(974)가 이 QCS로 성공을 리턴했다면 QS QEC(940)에게 BoH를 리턴한다. 그 다음 QS QEC(940)는 이 BoH를 캐싱할 QCC(930)에 BoH를 리턴한다. 그 다음 QCC(930)는 모든 시행자에게 BoH가 변경되었다는 통지를 송신한다. IPsec이 피어로의 IKE SA를 구축하라는 요청을 받았을 때, QEC(IPsec)(950)는 BoH 캐쉬로부터 BoH를 획득하고 이를 피어(980)의 QES(IPsec)(984)에 전달한다. QES(IPsec)(984)는 이 BoH를 검사할 QCS(982)에 이 BoH를 전달하고 (검사되면) 그 다음 원격 IKE 통신을 수락할 QES(IPsec)(984)에 성공을 리턴한다.

본 발명의 다른 실시예에서, 시스템은 VPN 시행을 이용한다. 클라이언트가 검역되어 VPN 서버를 통하여 도달될 수 있는 서버들이 DNS, DHCP 및 수리 서버가 된다면, VPN 시행은 VPN 서버 상에서 IP 필터링을 실행함으로써 동작한다. SoH 및 SoH 응답의 검역 교환은 임의의 요구되는 사용자 또는 기기 인증 이후의 PEAPv2에 연속된 새로운 EAP 방법 없이 EAP 교환으로서 수행된다. 모든 EAP 세션은 PEAP 세션이 내장된 EAP 인증을 포함하는 PEAP 세션 및 EAP 검역 세션이 완료될 때까지 완료되지 않을 수 있다. 모든 EAP 세션은 PEAPv2 세션이 성공적으로 완료된다면 성공적으로 완료된다. PEAPv2 세션은 모든 내장된 EAP 방법이 성공적으로 완료된다면 성공적으로 완료된다. 내장된 EAP 방법이 실행되는 순서는 성공적으로 실행되어야 하는 EAP 방법 및 그 순서로 구성되는 RADIUS 서버에 의해 구동된다. 클라이언트 PEAP는 RADIUS 서버에 의하여 요청될 수 있는 내장된 EAP 방법으로 구성될 수 있다.

본 발명의 또 다른 실시예에서, 시스템은 IEEE 802.1X 시행을 이용한다. 하와이에서의 IEEE 802.1X 시행은 IEEE 802.1X에 수송되는 EAP에서 수송되는 PEAPv2 프로토콜을 이용한다. NAS를 통해 도달될 수 있는 서버만이 DNS, DHCP 및 수리 서버가 되도록 클라이언트가 검역되어야 한다면, IEEE 802.1X 시행은 NAS(이더넷 스위치 또는 무선 액세스 포인트) 상에 IP 필터를 놓음으로써 동작한다.

도 10을 참조하면, 본 발명의 다른 실시예가 기술된다. 이러한 실시예에서, 네트워크는 클라이언트에게 네트워크 자원으로의 액세스를 제공하는 복수의 DHCP 서버를 포함한다. 각 DHCP 서버(1030)는 상술하였던 QES를 포함한다. 네트워크(1020)는 상술하였던 QCS 및 QPS를 포함하는 RADIUS(Remote Authentication Dial- in User Service) 서버(1040)를 더 포함한다. 그러므로, 이 실시예에서 검역 조정 및 정책 관리는 모든 네트워크(1020)에 대하여 하나의 RADIUS 서버를 중심으로 위치된다. 클라이언트(1010)가 DHCP 서버(1030) 상으로부터의 네트워크 자원으로의 액세스를 요청할 때, DHCP의 QES 서버는 RADIUS 서버(1040)의 QCS 및 QPS에 의존하여 건강 상태를 인증한다. RADIUS 서버(1040)가 클라이언트가 제공하는 건강 상태를 검사한다면, DHCP 서버(1030)는 네트워크에 대한 클라이언트 액세스를 인가한다. 건강 상태가 검사되지 않았다면, DHCP 서버(1030)는 RADIUS 서버(1040)가 제공한 정책에 따라서 클라이언트를 검역 과정에 위치시킨다.

네트워크 하부구조 지원을 제공하는 DNS 서버는 검역된 기기 및 비-검역된 기기들에 액세스해야할 필요가 있다. 네트워크 관리자는 인터넷 플럭시 서버가 검역된 기기에 액세스할 수 있도록 하여 이들 기기 인터넷에 액세스할 수 있도록 선택할 수 있다.

본 발명의 구조는 다음을 포함하는 복수의 QPC를 지원한다. (1) AV가 실행되는지 여부, AV 버전, AV가 사용되고 있는 특정한 버전, AV가 실시간으로 검사되는지 여부 등에 대한 SoH를 바이러스 방지 QPC, (2) 파일 또는 레지스트리 엔트리가 존재하는지 존재하지 않는지 검사하는 QPC, 이는 ICF와 같은 OS 구성 및 ICS 구성에 말웨어(malware)가 설치되는지 여부 등을 검사하도록 한다. (3) 각 프로세스를 구축하는 TCP/IP 접속의 개수를 검사하는 QPC. 그 다음 이 QPC는 다수의 접속을 여는 애플리케이션을 가지는 클라이언트를 검역할 수 있다. 이러한 유형의 행위는 서버 또는 피어-투-피어 애플리케이션을 제외하고 정정될 가능성이 적다. QPC를 구비하지 않는 QPS를 지원할 가능성도 있다. 이는 네트워크 행위 검사가 클라이언트가 검역되어야 하는지에 대한 입력을 제공하도록 한다.

상술한 소프트웨어 컴포넌트에 의해 공표된 인터페이스를 액세스하는 데에 이용되는 프로그래밍 모델이 이제 기술된다. 검역 시행 시스템은 QPC와 QCC 간의 클라이언트 상의 공용 API 및 QPS와 QCS 간의 서버측의 공용 API를 가진다. 각 API는 COM 인터페이스이며 원격적인 호출이 불가능하다. 두 API 모두 초기화에 보안되하거나 스크립팅(scripting)에 보안된다고 표시되지 않는다. 클라이언트 API는 동기식이고 서버 API는 비동기식이다. QEC와 QCC 및, QES와 QCS 간에 이용되는 추가적인 COM API가 존재한다.

Quarantine Coordination Client <- Quarantine Enforcement Client (IQuarEnforcementClientBinding)

이 인터페이스는 QCC에 의해 공표된다. 이는 QPC에 의해 이용된다. 이 인터페이스는 LocalSystem 및 NetworkService에 대해 ACL된다. 이는 QPC가 검역 플랫폼과 통신하하는 주 엔트리 포인트이다.. 이는 전역 인터페이스 테이블을 통하여 QPC에 의해 액세스된다. 이는 QCC 서비스와의 내부-프로세스 통신을 담당한다. QCC 서비스가 실행되고 있지 않다면 COM은 서비스를 시작하도록 구성될 수 있다. QPC는 QCC 서비스가 업그레이드를 할 수 없는 경우에 QCC 서비스가 실행할 때까지 QCCQPC->Bind를 폴링한다.

Initialize (QEC_ID, QECQCC CLSID, QEC_READ CLSID, QECQCCIF). 이 API가 런타임에 호출되어 QPC는자신의 QPCQCC 인터페이스를QCC에 공급한다. Product GUID는 모든 버전의 제품에 동일해야 한다. 가능하다면 다른 버전의 제품은 또한 동일한 QPC_ID/QPS_ID를 이용하고, 버전에 대한 것을 SoH에 추가하여야 한다. 그렇지 않다면 새로운 버전은 다른 QPC_ID/QPS_ID이지만 동일한 Product GUID가 이용되어야 한다. QPCQCC CLSID는 COM 오브젝트에 대한 CLSID이며 QPCQCC 인터페이스를 구현하는 인터페이스를 지원해야한다. QPC는 CoCreateInstance(QPCQCC Class GUID, QPCQCC IF GUID, &object)를 이용하여 QPCQCCIF를 생성하여야 한다. QPC_READ CLSID는 QPC_READ 인터페이스의 CLSID이다. 이러한 인터페이스는 QPC로부터의 정보의 질의를 지원한다.

Uninitialize (QEC_ID). 이 API는 QPC를 종료할 때 런타임에 호출된다. QPC는 이 호출을 하기 이전에 QCC상에 어떠한 특출난 호출도 가지지 않음을 확인해야 하며 일단 이 호출이 생성되었다면 QCC에 더 이상의 임의의 호출을 생성하지 않아야 한다. QPC는 이 호출이 생성될 때까지 QPCQCC 및 QPC_READ IF를 훼손하지 않아야 한다. 일단 QPCQCC 및 QPC_READ로의 모든 호출이 리턴되면 QCC는 이 호출을 리턴할 수 있다. QPC는 호출의 바인딩을 해제 시켰다면 QPCQCC 및 QPC_READ로의 임의의 호출은 실패되어야 한다.

NotifySoHChange (QPC_ID). 이 API는 QCC에게 QPC에 의해 수용되는 SoH 상태가 변경됨을 알린다.

QuerySystemQuarantineState (QPC_ID, *Q/NQ/Probation, *ProbationTime). 이 API는 QPC가 현재 클라이언트 검역 상태를 질의할 수 있도록 한다.

이 인터페이스는 QEC에 의한 사용을 위해 QCC에 의해 공표된다. 이 인터페이스는 LocalSystem 및 NetworkService에 대해서만 ACL된다. 이 인터페이스는 QCC에 의해 공표되며 QEC에 의해 사용된다. 이는 전역 인터페이스 테이블을 통해 QEC에 의해 액세스된다. 이는 QEC가 QCC와 통신하는 데에 이용되는 주 엔트리 포인트이다.

Initialize (QEC_ID, QECQCC CLSID, QEC_READ CLSID, QECQCCIF). 이 API는 런타임에 호출되어 QEC는 자신의 QECQCC 인터페이스를 QCC에 제공한다. QECQCC CLSID는 QECQCC 타입의 인터페이스를 공표할 수 있다. QECQCCIF는 QECQCC_Class_GUID로부터 획득되는 인터페이스이다.

Uninitialize (QEC_ID). 이 API는 QEC가 종료되고 QECQCC 인터페이스가 더이상 사용되지 않아야 할 때 런타임 중에 호출된다.

QuerySoHs (QEC_ID, ConnectionState IF). 이 API는 QEC가 QES에 공급될 SoH의 리스트를 필요로할 때 QEC에 의해 호출된다. SoH 버퍼 포맷은 QEC가 이해하지 못할 수 있으며 QES로 투명성있게 전달되어야 한다. ConnectionState IF는 QEC에의해 할당되고 QCC에 전달된 다음 필요하다면 QPC에 전달된다. QCC 및 QPC는 트랜잭션에 대한 정보를 설정하고 질의할 수 있다. 일단 이 API가 리턴하면 QCC 및 QPC는 ConnectionState IF를 액세스하지 않을 수 있다. 함수는 각 QPC에 대하여 QCC 호출 QuerySoH로 바운딩된 다음 QName에 대한 캐쉬에 이용가능한 추가적인 SoH를 첨부한다. 리턴하기 전에 이 함수는 ConnectionState IF 상에서 TestSoHHash를 호출하여야 한다. 함수가 S_OK를 리턴하면 QuerySoH는 S_FALSE를 리턴하여 어떠한 SoH도 변경되지 않았음을 알려주고, 그렇지 않으면 이 함수는 ConnectionState IF 상에 SetSoHHash를 호출함으로써 SoH Hash를 업데이트한다. QEC는 항상 ConnectionState가 활성화된 검역을 가지는지 여부에 대하여 QuerySoH를 호출하여야 한다. QCC는 QEC가 해야할 검역 작업이 없다면 NO_QUARANTINE_INFORMATION의 상태로 리턴할 수 있다.

QuerySoHResponseQuarantineState (QEC_ID, ConnectionState IF, *Q/NQ). 이 API는 QEC에 의해 호출되어 QCS SoHResponse로부터 검역/비검역 상태를 획득한다.

NotifyConnectionStateUp (QEC_ID, ConnectionState IF). 이 API는 SoHResponse의 리스트가 자신의 QEX에 의해 리턴되고 QEC가 그 응답을 사용할 준비 상태에 있을 때 QEC에 의해 호출된다. SoHResponse의 리스트는 QEC에 의해 설정되었고 그 버퍼 포멧은 QCE가 이해지 않아야 하고 QCC에 투명성있게 전달되어야 한다. SoHResponse는 QES/QEC가 SoHResponses를 전송할 수 없다면 엠티(empty) 상태일 수 있다. ConnectionState IF는 QEC에 의해 할당되고 QCC로 전달된 다음 필요하면 QPC에 전달된다. QCC 및 QPC는 트랜잭션에 대한 정보를 설정하고 질의한다.

NotifyConnectionStateDown (QEC_ID, ConnectionState IF). 이 API는 QEC에 의해 호출되어 QCC에게 접속이 다운 상태로 변경됨을 알리고 QCC는 시스템 검역 상 태를 갱신할 필요가 있을 수 있다.

NotifySoHChangeFailure (QEC_ID). 이 API는 QEC가 NotifySoHChange 상에서 동작하기 실패할 경우 QEC에 의해 호출된다. 그 다음 QCC는 타이머를 시동시키고 타이머가 만료되면 QECQCC->NotifySoHChange를 호출한다.

Quarantine Policy Client <- Quarantine Coordination Client (IQuarPolicyClientCallback)

QPC는 QCC에 의한 사용을 위하여 인터페이스를 공표시킨다. 이 인터페이스는 LocalSystem 및 NetworkService에 ACL되고 원격 액세스는 불가능하다. 이 인터페이스는 QPC에 의해 공표되고 QCC에 의해 사용된다. 이를 호출하는 QCC를 포함하는 임의의 코드는 QPC가 호출자를 사칭할 수 없는 환경을 사용하여야 한다. QPC는 QCC 상에서 Bind 호출을 할 때 QCC가 사용하는 클래스 GUID를 전달하여 QPCQCC 인터페이스 인스턴스를 생성한다.

QuerySoH (QPC_ID, ConnectionStateRead IF). 이 API는 QCC에 의해 호출되어 SoH를 찾기 위해 질의한다. QPC는 ConnectionState->SetSoH를 호출하여 자신의 SoH를 설정해야 한다. QPC가 네트워드마다 다른 SoH를 처리한다면, ConnectionState IF 상에서 QName을 질의하여 정정된 SoH를 리턴하여야 한다.

ProcessSoHResponse (QPC_ID, ConnectionStateRead IF, *QPS_Result). QPC는 QCC로부터의 SoH 응답 인터페이스를 프로세싱한다. ProcessSoHResponse가 호출되어야할 때 QPC가 QCC에 바운딩되지 않았다면 SoHResponse를 버린다. QName은 SoH 응답을 리턴하는 네트워크의 검역 이름이다. SoHResponse는 QES/QEC가 SoHResponse를 전송할 수 없다면 빈 상태일 수 있다. QPS_Result는 자신의 SoHResponse에서의 QPC에 리턴된 QPS로부터 리턴된 HRESULT이다. QPS_Result는 QCC/QEC 로깅 정보로 로깅될 수 있다.

NotifySystemQuarantineStateChange (QPC_ID, Q/NQ). QPC에게 시스템 검역 상태가 변경됨을 통지한다.

QueryStatus (QPC_ID, *State, *Percentage, *MessageID). QPC의 현재 상태 및 이것이 자신의 정책 구성에서의 날짜에 도달할 때 까지 이루어지고 있는 진행을 기술하는 메세지를 제공하므로 이는 SoH이다. State는 진행중, 성공적으로 완료, 완료가 실패됨 중 하나이다. 백분율은 0 내지 100까지이며, 1을 리턴하는 것은 QPC가 %를 지원하지 않음을 의미한다. 메세지는 QPC_READ IF에 이용될 수 있는 MessageID어야 한다.

Quarantine Enforcement Client <- Quarantine Coordination Client (IQuarEnforcementClientCallback)

QEC는 QCC에 의한 사용을 위하여 인터페이스를 공표시킨다. 이 인터페이스는 QEC에 의해 공표되고 QCC에 의해 사용된다. 이 인터페이스는 LocalSystem 및 NetworkService으로 ACL되고 원격 액세스는 불가능하다. QEC가 QCC 상의 Bind를 호출할 때 QCC가 사용하는 클래스 GUID를 전달하여 QECQCC 인터페이스 인스턴스를 생성한다.

NotifySoHChange (QEC_ID). 이 API는 QEC에게 QCC에 의해 수용되는 SoH 상태가 변경됨을 알린다. QEC는 이 호출을 무시되면 안되지만 과부하(busy) 상태라면 호출이 제시되지 않아 무시될 가능성이 있다. QCC는 시스템이 검역 중에 있을 때 간격마다 이 API 호출할 수 있다.

QueryConnectionState (QEC_ID, *Number_IFs, *ConnectionState []). 이 API는 자신의 검역 인터페이스 ID의 리스트에 대하여 QEC를 질의한다. ConnectionState의 포멧은 ConnectionState IF들의 배열이다.

ResetQuarantineState (QEC_ID). 이 API는 QCC가 검역을 활성화 또는 비활성화시킬 때 QCC에 의해 호출된다. QEC는 임의의 검역 구성을 재설정해야한다.

SoHState IF

이 인터페이스는 ConnectionState 및 TransactionState 인터페이스에 의해 이용된다. ConnectionState 및 TransactionState는 이 인터페이스의 인스턴스를 이용하여 SoH의 리스트를 포함하고 SoHResponse의 리스트를 포함한다.

QuerySoHStateRead: 이 API는 QCC 및 QCS에 의해 이용되어 SoHStateRead 인터페이스를 획득한다. SetListOfSoHResponses (SoHResponse): 이 API는 QEC에 의해 이용되어 SoHResponse의 리스트를 설정한다. QueryListOfSoHResponses (*SoHResponse): 이 API는 QES에 의해 이용되어 SoHResponse의 리스트를 질의한다. SetSoHResponse (QPS_ID, SoHResponse): 이 API는 QCS에 의해 이용되어 SoHResponse를 설정한다. . SetListOfSoHs (SoHs): 이 API는 QES에 의해 이용되 어 SoH의 리스트를 설정한다. 트랜잭션 ID는 QCC SoH 외부에서 복사되어야 한다. SoH의 리스트에 QCC SoH가 존재하지 않는다면, 트랜잭션 ID가 생성되고 할당되어야 한다. 이 API는 SoH의 리스트의 임의의 사용 이전에 SoH의 리스트 포멧을 검사해야한다. QueryListOfSoHs (SoHs): 이 API는 QES에 의해 사용되어 자신의 또는 다른 API의 SoH를 찾기 위하여 질의한다. SetSoH (QPS_ID, SoH): 이 API는 QCC에 의해 사용되어 SoH를 설정한다. SetQCSQPS_IDs: 이 API는 QCS SoHResponse로부터 바람직한 QPS_ID들을 설정하는 데에 이용된다. QueryQCSQPS_IDs: 이 API는 QCS SoHResponse에서 바람직한 QPS_ID들을 판독하는 데에 이용된다. SetQCCClientName: 이 API는 QCC SoH로부터 클라이언트 이름을 판독하는 데에 이용된다. QueryQCCClientName: 이 API는 QCC SoH로부터 클라이언트 이름을 판독하는 데에 이용된다. SetQCSClientState: 이 API는 QCS가 결정한 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSClientState: 이 API는 QCS SoHResponse로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCCClientState: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCCClientState: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCCTransactionID: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCCTransactionID: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다.

SetQCSTransactionID: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSTransactionID: 이 API는QCC SoH로부터 클라이언트 상 태를 판독하는 데에 이용된다. SetQCCOSVersion: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCCOSVersion: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCCOSSPVersion: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCCOSSPVersion: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCCProcessorArchitecture: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCCProcessorArchitecture: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCSQPS_Results: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSQPS_Results: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCSQName: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSQName: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCSQCSName: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSQCSName: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCSProbationTime: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSProbationTime: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다. SetQCSURL: 이 API는 QCC SoH에 현재 클라이언트 상태를 설정하는 데에 이용된다. QueryQCSURL: 이 API는 QCC SoH로부터 클라이언트 상태를 판독하는 데에 이용된다.

SoHStateRead IF

이 인터페이스는 ConnectionState 및 TransactionState 인터페이스에 의해 이용된다. 이 인터페이스는 QPC 및 QPS로 전달되어 SoH 및 SoHResponse를 찾기 위해 질의한다.

QuerySoHResponse (QPS_ID, SoH): 이 API는 QCC 및 QPC에 의해 이용되어 자신의 또는 다른 API의 SoHResponse를 찾기 위해 질의한다. QuerySoH (QPS_ID, SoH): 이 API는 QCS 및 QPS에 의해 이용되어 자신의 또는 다른 API의 SoH를 찾기 위해 질의한다.

Connection State for QEC/QCC (IQuarClientConnection)

이 인터페이스는 QEC에 의해 사용되어 검역 상태를 가지는 고유한 네트워크 "인터페이스" 각각의 상태를 관리한다. 이 인터페이스는 LocalSystem 및 NetworkService로 ACL되고 원격 액세스는 불가능하다. 이 인터페이스는 QEC 및 QCC에 공표된다. ConnectionStateRead 인터페이스가 QCC, QEC 및 QPC에 공표된다. 네트워크 "인터페이스"는 물리적 NIC로 매핑될 수 있거나 예를 들면 IPsec과 같은 다른 기기로의 논리 접속에 매핑될 수 있다.

QueryConnectionStateRead: 이 API는 QCC가 ConnectionStateRead를 찾기 위해 질의하도록 한다. QuerySoHState: 이 API는 QEC 및 QCC가 SoHState 인터페이스를 찾기 위해 질의하도록 한다. SetMaxSize: QEC가 자신의 최대 지원되는 SoH 리스트의 크기를 설정하도록 한다. SetQName: QCC는 QCS로부터 QName을 수신하고 ConnectionState IF 상에서 QName을 설정한다. SetQCSName: 이 API는 QCC가 ConnectionState에서 이용되는 현재 QCS를 설정하도록 한다. SetPreferredQPS_IDs: QCC에 의해 이용되어 QCS에 대해 바람직한 QPS_ID를 설정한다. SetURL: QCC에 의해 이용되어 QCS에 대한 URL을 설정한다. SetSoHHash: SoH들의 해쉬가 ConnectionState IF 객체에 저장된다. SetTransactionID (ConnectionState ID, Length): 이 API는 QEC에 의해 사용되어 트랜잭션 ID를 설정한다. QEC는 예를 들면, NIC MAC 주소가 되어야 할 DHCP와 같은 ConnectionState에 대한 ID를 가져와야 한다. SetTransactionID는 무작위 숫자로 이 ID를 해싱하고 8바이트 해쉬를 생성한다. SetQuarantineState (Quarantine_Enable, Quarantine/Probation/Non-quarantine): QCS로부터 리턴되는 QCS->QCC SoH에서의 리턴에 의존하여 검역/비검역 상태를 설정한다. SetProbationTime (ProbationTime): 이 ConnectionState IF에 ProbationTime을 설정한다. 이 API는 QCS/QCC SoH가 시험 시간 및 시험의 검역 상태를 포함하였을 경우에만 호출되어야 한다. ProbationTime은 초단위이다. 이 API는 TestProbationTime에 대한 검사 만료 시간을 저장한다. ProbationTime이 0이라는 것은 ProbationTime이 설정되지 않았음을 의미한다. SetQECInfo (EnumType, QECInfo): EnumType은 QEC에 대한 QEC로부터의 정보를 포함한다. QECInfo는 QEC EnumType에 의존하지만 DHCP QEC (Client IP address, Client MAC address), PEAP QEC, 및 IPsec QEC를 포함한다. Serialize (output buffer, *size): 이 API는 ConnectionState IF 구성을 출력 버퍼에 기록한다.

출력 버퍼는 비관리자(non-admin)가 판독 또는 기록하기 위해 액세스할 수 있는 아무 곳에나 놓여져서는 안된다. Deserialize(*input buffer, size): 이 API는 ConnectionState IF 구성으로 입력 버퍼를 읽어들이다. 이 API는 ConnectionState 정보를 레지스터에 저장 및 복원하기 위해 DHCP QEC에 의해 Serialize와 함께 사용될 수 있다다. 레지스트리 데이타는 관리자에 의해서만 액세스될 수 있어야 한다.

Connection State for QPC (IQuarPolicyClientConnection)

이 인터페이스는 QEC에 의해 사용되어 검역 상태를 갖는 고유한 네트워크 "인터페이스" 마다의 상태를 관리한다. 이 인터페이스는 로컬 시스템 및 네트워크 서비스에 ACL되지만, 원격으로 액세스 불가능하다. 이 인터페이스는 QEC, QCC 및 QPC에게 공표된다. 네트워크 "인터페이스"는 물리적인 NIC에 매핑되거나 예를 들어, IPsec인 또다른 기기로의 논리적인 연결에 매핑될 수 있다. 테이블은 방법들을 목록화하고, 구성요소들은 각각의 방법을 사용한다.

QuerySoHStateRead: 이 API는 QPC가 SoHStateRead 인터페이스를 질의하도록 한다. QueryMaxSize: 최대 크기는 QCC가 반환할 수 있는 SoH 버퍼의 최대 크기를 특정하도록 한다. QueryQName: QName은 SoH들에 질의하고 있는 검역 네임을 특정한다. QEC가 QName을 모르면, ""을 사용해야 한다. QCC는 ""의 QName으로 공개된 SoH 또는 사용된 최종 SoH를 반환해야 한다. QueryQCSName: 안다면, 이 ConnectionState 상의 현재 QCS를 질의한다. QueryPreferredQPS_IDs: QCC에 의해 사용되어, QCS을 위한 바람직한 QPS_ID를 질의한다. QueryURL: QCC에 의해 사용되어, QCS를 위한 URL을 질의한다. TestSoHHash: SetSoH에 의해서 설정된 SoH의 해시는 생성되고 미리 저장된 해시와 비교되며, 해시들이 매칭되면 S_OK가 반환되고, 그렇지 않으면 S_FALSE가 반환된다. QueryTransactionID(*ID): 이 API는 QCC, QEC 및 QPC에 의해 사용되는 SetTransactionID에 의해 설정된 Transaction ID를 반환한다. 로그할 때, 그들은 로그에 이 ID를 추가해야 한다. QueryQECInfo(EnumType, QCEInfo): EnumType은 QEC로부터의 QEC에 대한 정보를 포함한다. QECInfo는 QEC EnumType에 독립적이지만 DHCP QEC(Client IP address, Client MAC address), PEAP QEC, 및 IPsec QEC를 포함한다. QueryQuarnatineState(*Qurantine_Enable, *Qurantine/Probation/Non-Quarantine): 검역/검정 및 비검역의 검역 상태를 반환한다. TestProbationTime(*Passed): 이것은 SetProbationTime이 호출된 이후에 검정 시간이 지났는지의 여부를 반환한다. 검정 시간이 설정되지 않았으면, Passed는 실패를 반환한다. QueryProbationTime(*ProbationTime): 이 ConnectionState IF 상의 검정 시간을 질의한다. 검정시간이 설정되지 않았으면, 0을 반환한다. SetQPCInfo(Info, Length of Info, Size): QPC는 ConnectionState IF 객체에 대한 일부 정보를 저장할 수 있는데, 예를 들어, 이것은 이 검역 인터페이스와 함께 사용되어야 하는 정책 서버 네임/주소를 저장할 수 있다. 정보의 최대 크기는 256 바이트이다. 핸들 또는 포인터는 저장될 수 없다. QueryQPCInfo(*Info, *Length of Info): 이 API는 QPC가 ConnectionState IF를 통해 이전에 저장된 정보를 질의하도록 한다. 반환 버퍼의 크기, 즉 SetQPCInfo를 통해 설정될 수 있는 최대 크기 는 적어도 256 바이트이라고 예상된다.

Quarantine Coordination Client Management IF

QCC는 2개의 관리 인터페이스를 공표한다. 하나는 판독을 위한 것이고, 다른 하나는 기록을 위한 것이다. COM 객체는 단일적이고, Com 글로벌 러닝 테이블(Com global running table) 내에 공표된다. 이것은 모든 WINSTA 인스턴스 내의 netshell.dll에 액세스하는 방식으로 글로벌 테이블 내에 공표된다. 인터페이스는 다음과 같다:

IQuarClientInfo: 이 인터페이스는 모두에게 ACL되지만, 원격으로 액세스 불가능하다. QCC 및 이것을 호출하는 QCC UI를 포함하는 임의의 코드는 QPC가 호출자 역할을 할수 없는 문맥을 사용해야 한다. EnumQPC(*QPC_IDs, *QPC_READ CLSID[]): QPC_READ IF 및 QCC에 등록된 QPC 들의 목록을 열거한다. EnumQEC(*QEC_IDs, *QEC_READ CLSIS[]): QEC_READ IF 및 QCC에 등록된 QEC의 목록을 열거한다. QuerySystemQuarantineState(*Qurantine_Enable, *Quarantine/Probation/Non-quarantine): 시스템의 검역 상태를 질의한다. QueryQPCState(QPC_ID, *bind/unbind, *datetime, *SoH): QPC_ID에 대한 QCC 상태를 질의한다. bind/unbind 상태가 반환된다. API는 SoH가 갱신되고 현재 SoH가 반환된 최종 시간/날짜를 반환한다. QueryQECQuarantineState(QEC_ID, *bind/unbind, *ConnectionState IF []): QEC_ID에 대한 QCC 상태를 질의한다. bind/unbind 상태가 반환된다. 반환될 것이 없으면, QEC에 대한 ConnectionState IF들의 목록이 반환된다. QueryStatus(QPC_ID, LANGID, *State, *Percentage, *MessageID): SoH를 정정할 때 행해지는 진행을 설명하는 메시지, 및 QPC의 현재 상태를 공급한다. 상태는 (1)사용자가 관리자의 도움 또는 웹사이트를 지원을 받아야하는, 검역되지만 갱신이 실패된 상태; (2)검역되고 진행상 갱신된 상태; (3)검역되고 갱신이 모두 성공한 상태 중 하나이다. 백분율은 0 내지 100%이고, -1을 반환한 것은 QPC가 지원하지 않았음을 의미한다. 메시지는 QPC READ_IF와 함께 사용될 수 있는 MessageID이어야 한다. 메시지는 또한 QPC가 QPS_Result에 대한 플러스 텍스트를 수행하는 것에 대한 로컬 텍스트이어야 한다.

IQuarClientConfig: 이 인터페이스는 로컬시스템 및 네트워크 서비스에 ACL되지만, 원격으로 액세스 불가능하다. 이 인터페이스는 API들을 갖지 않는다.

Quarantine Policy Client Management IF

IQuarPolicyClientInfo: 이 인터페이스는 모두에게 ACL되지만, 원격으로 액세스 불가능하다. QCC 및 이것을 호출하는 QCC UI를 포함하는 임의의 코드는 QPC가 호출자 역할을 할수 없는 문맥을 사용해야 한다. QueryFriendlyName(QPC_ID, *MessageID): 이 API는 QPC의 익숙한 네임을 위해 MessageID를 반환한다. QueryQPSResult(QPC_ID, QPS_Result, *MessageID): 이 API는 QPS_RESULT에 대한 MessageID를 반환한다. QueryMessage(QPC_ID, LANGID, MessageID, *Message): 이 API는 MessageID 및 특정화된 LANGID에 대한 유니코드 스트링을 반환한다. LANGID에 대한 스트링이 존재하지 않으면, 디폴트 시스템 LANGID에 대한 스트링이 반환되 어야 한다.

IQuarPolicyClientConfig: 이 인터페이스는 API를 갖지 않는다.

Quarantine Enforcement Client Management IF

IQuarEnforcementClientInfo: 이 인터페이스는 모두에게 ACL되지만, 원격으로 액세스 불가능하다. QueryFriendlyName(QEC_ID, *MessageID): 이 API는 QEC의 익숙한 이름에 대한 MessageID를 반환한다. QueryMessage(QEC_ID, LANGID, MessageID, *Message): 이 API는 MessageID 및 특정화된 LANGID에 대한 유니코드 스트링을 반환한다. LANGID에 대한 스트링이 존재하지 않으면, 디폴트 시스템 LANGID에 대한 스트링이 반환되어야 한다.

IQuarEnforcementClientConfig: 이 인터페이스는 API를 갖지 않는다.

QEC를 초기화하는 동안, QEC는 자신의 QECQCC 인터페이스를 위한 클래스 QUID를 전달하는 QCC 상의 QCCQEC->Bind를 호출한다. Bind 호출을 수신하고 있는 QCC는 QEC를 위한 QECQCC 인터페이스를 생성하고 그것에 대해 질의한다. QPC를 초기화하는 동안, QPC는 자신의 QPCQCC 인터페이스를 위한 클래스 QUID를 전달하는 QCC 상의 QCCQPC->Bind를 호출한다. Bind 호출을 수신하는 QCC는 QPC를 위한 QPCQCC 인터페이스를 생성하고 그것에 대해 질의한다. 추가적으로, QCC는 QECQCC->NofitySoHChange를 사용하여 가능한 SoH 변화를 QEC에게 통지한다.

QPC가 자신의 SoH를 변화시킬 때, 이것은 QCCQPC 인터페이스 상의 NofitySoHChange를 호출함으로써 QCC에게 통지한다. QCC는 함께 저장된 각각의 QEC를 호출하고, 각각의 QECQCC 인터페이스 상의 NofitySoHChange를 호출한다. 각각의 QEC는 검역가능한 임의의 "인터페이스"를 위해 자신의 검역 "인터페이스"를 찾는다. 각각의 이러한 인터페이스에 대해서, QEC는 각각의 검역 "인터페이스"에 대한 ConnectionState IF를 전달함으로써 QCC 상의 QuerySoH를 호출한다. QCC는 매개변수로서 ConnectionState IF와 함께 Bind를 호출하는 각각의 QPC를 위해 QuerySoH를 호출한다. QCC는 그후 QCC 캐시에 홀딩된 올바른 ConnectionState IF에 대한 임의의 SoH들을 추가하고, ConnectionState IF 상에서 사용하기 위해 QEC에게로 SoH들의 목록을 반환한다. QCC는 또한 SoH의 목록이 최종 시간 이후에 변화되었는지를 확인하기 위해 SoH의 목록을 생성한 후 QuerySoH로부터 반환하기 전에 QuerySoHHash를 호출해야 한다. QuerySoHHash가 SoH의 목록이 변화되지 않았음을 의미하는 S_OK를 반환하면, QuerySoH는 S_FALSE를 반환해야 한다. QuerySoHHash가 S_FALSE를 반환하면, SoH의 목록은 바뀐 것이다. QCC는 그후 SoH의 새로운 목록에 저장된 해시를 갱신하기 위해 SetSoHHash를 호출해야 한다. QCC는 또한 SoH의 목록을 생성할 때 QueryMaxSize를 호출해야하며, SoH의 목록을 포함하는 버퍼는 MaxSize 보다 크면 안된다. SoH의 목록은 MaxSize에 맞는 완성된 SoH의 최대 수가 되도록 절단되어야 한다.

SoH의 목록은 QEC에 의해 자신의 QCS에 자신을 송신함으로써 자신을 처리하는 자신의 QES 대응부로 송신된다. QCS가 SoHResponse의 목록을 QES로 전달하면, QEC로 반환된다. SoHResponse의 목록을 수신하는 QEC는 QCCQEC 인터페이스 상의 ProcessSoHResponse를 호출할 것이다. QCC는 SoHResponse의 목록을 분할하고 Bind 를 호출한 각각의 QPC를 위한 ProcessSoHResponse를 호출하며, SoHResponse는 SoHResponse의 목록 내에 있다. Bind를 호출하지 않은 QPC에 대한 임의의 SoHResponse는 삭제될 것이다. QCC가 ProcessSoHResponse 함수를 처리할 때, 그것은 ProcessSoHResponse에게 전달된 ConnectionState IF 상의 수많은 API들을 사용한다. ConnectionState IF는 QEC에 의해 생성 및 관리되며, ProcessSoHResponse가 완성되면, QCC 및 QPC 어느 것도 ConnectionState IF를 사용하지 못한다. QCC는 SetQName을 호출하여 ConnectionState IF 상의 검역 네임을 설정한다. QName은 QCS->QCC SoH의 QCS에 의해 공급된다.

QEC 네트워크 요청 API 인터페이스가 이제 설명된다. QEC가 네트워크 요청을 해야할 때, 송신할 SoH를 얻어야 한다. 그것은 QCC 상의 QuerySoH를 호출하여 이것을 행한다. 상호작용이 NotifySoHChange를 호출함으로써 QPC 보다는 QEC에 의해 초기화된다는 것을 제외하고 인터페이스는 NotifySoHChange와 동일하다.

Quarantine Policy Server <- Quarantine Coordination Server (IQuarPolicyServerBinding)

이 API는 로컬 시스템 및 네트워크 서버에 ACL된다. QPS는 QCS가 사용할 인터페이스를 공표한다. QCS는 CoCreateInstance를 호출하여 이 인터페이스를 얻는다: Initialze(QPS_ID); Uninitialize(QPS_ID); ValidateSoH(QPS_ID, TransactionStateRead IF): 이 API는 QCS에 의해 호출되어 QPS가 자신의 SoH를 검증할 것을 요구한다. QPS는 자신의 SoH를 얻기 위해 TransactionStateRead- >QuerySoH를 호출해야 한다. SoH 버퍼가 비면, TransactionStateRead->OnValidateSoHComplete 내의 SoHResponse 버퍼는 비어있어야 한다. QPS는 이 호출을 즉시 반환하고 검증이 완료되면 TransactionStateRead->OnValidateSoHComplete를 호출해야 한다.

Quarantine Coordination Server <- Quarantine Enforcement Server (IQuarEnforcementServerBinding)

이 인터페이스는 로컬 시스템 및 네트워크 서비스에 ACL된다. 이것은 글로벌 인터페이스 테이블을 통해 QES에 의해 액세스된다. ValidateSoHs(QES_ID, TransactionState IF, ResponseTime): 이 API는 QCS가 SoH의 목록을 검증할 것을 요구하기 위해 QES에 의해 호출된다. QCS는 자신의 SoH를 얻기 위해 TransactionStateRead->QuerySoH를 호출해야 한다. QCS는 SoH 버퍼 포맷을 이해하지 못할 것이므로, SoH 버퍼 포맷은 QCS에 투명하게 전달되어야 한다. 이 호출은 즉시 반환되어야 하며, QCS는 검역 상태 결과로 TransactionState->OnValidateSoHComplete를 호출할 것이다. 응답시간은 결과가 QES에 유용하도록 하기 위해 QCS가 OnValidateSoHComplete를 호출해야 하는 시간이다.

Transaction State for QCS/QES (IQuarServerTransaction)

이 인터페이스는 로컬 시스템 및 네트워크 서비스에 ACL된다. 이 인터페이스는 QES 및 QCS에 공표된다. The TransactionStateRead (See Section Error! Reference source not found.) 인터페이스는 QCS, QES 및 QPS에 공표된다. QueryQCSStateRead(*QCSStateRead IF): 이 API는 QCSStateRead에 인터페이스를 반환한다. QuerySoHState: 이 API는 QES 및 QCS가 SoHState 인터페이스를 질의하도록 한다. SetQESInterfaces(QES_ID, QESTransactionState IF, QES_READ IF): 이 API는 이 TransactionState 인스턴스에 의해 사용되는 QESTransactionState 및 QES_READ 인터페이스를 설정한다. QES는 사용된 후에 이 인터페이스들을 올바르게 역참조해야 한다. SetQCSInterface(QCSTransactionState IF): 이 API는 이 TransactionState 인스턴스에 의해 사용되는 QCSTransactionState 인터페이스를 설정한다. QES는 사용한 후에 이러한 인터페이스들을 올바르게 역참조해야 한다. OnValidateSoHsComplete: QCS는 프로세싱 ValidateSoH들을 완료했을 때 이 인터페이스를 호출할 것이다. 이 함수는 QESTransactionState->OnValidateSoHsComplete를 호출한다. SetQuarantineConfig: 이 API는 QES에 의해 사용되어, 이 ValidateSoH를 위해 사용될 QCS 구성을 특정한다. 이 API는 QES가, 이 요청을 생성한 클라이언트가 검역 판정의 영향을 받는 연결성을 갖지 않는 QCS에 특정하도록 한다. QCS는 로깅 정보에 이 정보를 추가해야 한다. MessageID는 예를 들어 예약, 영역, 도메인 네임 매치, BOOTP 등의 면제 이유에 대한 ID이다. MessageID는 면제가 로깅될 때 로깅된다(logged). SetMaxSize(MaxSize): QES에 의해 사용되어 QCS가 반환하는 SoHResponse의 최대 크기를 특정한다. SetClientName(Client machine/domain name): QCS에 의해 사용되어 로깅하는데 사용되기 위해 QCC SoH로부터 클라이언트 기기/도메인을 설정한다.

SetClientState(Quarantine/Probation/Non-quarantine): QES 또는 QCS에 의해 사용되어, QCC SoH로부터 클라이언트 검역 상태를 설정한다. QCS는 QES가 할수 없을 때만, 이것을 설정해야 한다. SetConnectionState(Up/Down): QES에 의해 사용되어 현재 연결 상태를 설정한다. Clear: 그것이 재사용되면, 객체 상태를 리셋하기 위해 사용될 수 있다.

Transaction State for QPS (IQuarPolicyServerTransaction)

이 인터페이스는 로컬 시스템 및 네트워크 서비스에 ACL된다. 이 인터페이스는 QES, QCS 및 QPS에 공표된다. OnValidateSoHComplete(SoHResponse): QPS는 프로세싱 ValidateSoH를 완료할 때 이 인터페이스를 호출할 것이다. 이 함수는 QCSTransactionState->OnValidateSoHsComplete를 호출한다. 이 함수는 SoHsComplete를 넘겨주면서 TransactionState->SetSoHResponse를 호출한다. API는 SetSoHResponse를 호출하기 전에 SoHResponse를 검증해야 한다. QuerySoHStateRead(SoHStateRead): 이 API를 사용하여 SoHStateRead 인터페이스를 얻는다. QueryClientState(*Quarantine/Probation/non-quarantine): QPS에 의해 사용되어, 클라이언트 검역 상태를 얻을 수 있다. QueryQES(*QES_ID, *QES_READ CLSID): 이 API는 SetQESInterface들을 호출한 QES에 대한 QES_ID 및 QES_READ IF를 반환한다. QueryConnectionState(Up/Down): QCS에 의해 사용되어 현재 연결 상태를 질의한다. QueryQuarnatineConfig: 이 API가 QCS에 의해 사용되어, 이 ConnectionState IF를 위해 사용되도록 QCS 구성을 얻는다. 구성 매개변수는 검역 상태 온/오프/검정중(Quarantine State on/off/probation)을 포함한다. QCS는 QPS가 클라이언트에게 검역되야하며 면제될 수 없는지를 판정해야 한다. 검정 기간: 검정 기간은 검정이 선택된 클라이언트 상태일 때 사용된다. 인에이블링된 검역 로깅: 검역 판정은 로그되어야 하지만 사용자 연결성은 영향을 받지 않는다. 연결성 면제 비-검역아지 클라이언트: SoH를 설정하지 않는 임의의 클라이언트를 면제 시킨다. 실패 URL: 실패할 시에 클라이언트에게 반환될 URL이다. 정규 표현 면제: 기기/도메인 네임 제거를 위해 사용된다. 면제 이유: 거래가 QES로부터 면제된 이유이다. QueryTransactionID(*ID): 이 API는 QCS, QES 및 QPS에 의해 사용된다. 로그할 때, 그들은 로그에 이 ID를 추가해야 한다. QueryMaxSize(*MaxSize): 이 API는 QCS가 QES가 수용할 수 있는 SoHResponse의 목록의 최대 크기를 얻도록 한다. QueryClientName(*Client machine/domain name): QPS에 의해 사용되어 예를 들어 로깅을 위해 클라이언트 기기/도메인 네임을 얻을 수 있다.

Quarantine Coordination Server <- TransactionState (IQuarPolicyServerCallback)

QCS는 TransactionState에 의해 사용될 인터페이스를 공표한다. 이 인터페이스는 로컬시스템 및 네트워크서버에 ACL된다. 이것은 TransactionState->SetQCSInterface API를 사용하여 QCS에 의해 TransactionState 인스턴스에게 주어진다. OnValidateSoHComplete(TransactionState IF, Q/NQ, QPS_Result): 이 API는 OnValidateSoHComplete 상의 TransactionState에 의해 호출된다. QPS_Result는 QPS가 Q/NQ 결과를 반환한 이유를 설명하는 HRESULT이다. QPS가 INVALID_SOH의 HRESULT를 반환하면, QCS는 INVALID_SOH의 HRESULT를 갖는 TransactionState->OnValidateSoHComplete를 호출해야 한다.

Quarantine Enforcement Server <- TransactionState (IQuarEnforcementServerCallback)

OnValidateSoHsComplete(TransactionState IF, Q/NQ): SoHResponse 버퍼 포맷이 QES에게 인식되지 않으므로 QEC에게 투명하게 전달되어야 한다. QPS가 HRESULT INVALID_SOH를 가진 OnValidateSoHComplete를 실패하거나 QCS가 SoH의 목록의 검증을 실패하면, 이것은 INVALID_SOH의 HRESULT를 전달해야 한다.

Quarantine Coordination Server Management IF (QCS)

QCS는 2개의 관리 인터페이스들을 공표하는데, 하나는 판독을 위한 것이고 다른 하나는 기록을 위한 것이다. 기록 인터페이스는 관리자만이 액세스할 수 있다. 판독 인터페이스는 모든 사용자가 액세스할 수 있다. COM 객체는 단일적이고 Com 글로벌 러닝 테이블에 공표된다. 이것은 모든 WINSTA 인스턴스 내의 netshell.dll에 액세스하는 방식으로 글로벌 테이블에 공표된다. 인터페이스들은 다음과 같다: IQuarServerInfo: 이 인터페이스는 모두에게 ACL된다. EnumQPS(*QPS_IDs, *QPS_READ CLSID[]): QCS에 등록된 QPS의 목록을 열거한다. IQuarServerConfig: 이 인터페이스는 로컬시스템 및 네트워크 서비스에게 ACL되지 만, 원격으로 액세스 불가능한다. 이 인터페이스는 API를 갖지 않는다.

Quarantine Policy Server Management IF (QPS)

이 인터페이스는 로컬시스템 및 네트워크 서비스에게 ACL되지만, 원격으로 액세스 불가능한다. IQuarPolicyServerInfo: QueryFriendlyName(QPS_ID, *MessageID): 이 API는 QPS의 익숙한 이름에 대한 MessageID를 반환한다. QueryQPSResult(QPS_ID, QPS_Result, *MessageID): 이 API는 QPS_RESULT에 대한 MessageID를 반환한다. QueryMessage(QPS_ID, LANGID, MessageID, *Message): 이 API는 MessageID 및 특정화된 LANGID에 대한 유니코드 스트링을 반환한다. LANGID에 대한 스트링이 존재하지 않으면, 디폴트 시스템 LANGID에 대한 스트링이 반환되어야 한다. IQuarPolicyServerConfig: 이 인터페이스는 API를 갖지 않는다.

Quarantine Enforcement Server Management IF (QES)

이 인터페이스는 로컬시스템 및 네트워크 서비스에게 ACL되지만, 원격으로 액세스 불가능한다. IQuarEnforcementServerInfo: QueryFriendlyName(QES_ID, *MessageID): 이 API는 QES의 익숙한 이름에 대한 MessageID를 반환한다. QueryMessage(QES_ID, LANGID, MessageID, *Message): 이 API는 MessageID 및 특정화된 LANGID에 대한 유니코드 스트링을 반환한다. LANGID에 대한 스트링이 존재하지 않으면, 디폴트 시스템 LANGID에 대한 스트링이 반환되어야 한다. QueryInfo(EnumType, QESInfo): EnumType은 QES로부터 클라이언트에 대한 정보를 포함한다. QESInfo는 QES에 독립적이지만, DHCP QES(Proposed Client IP address, Lease time, Client MAC address), PEAP QES(RADIUS Attributes)를 포함한다. IQuarEnforcementServerConfig: SetInfo(EnumType, QESInfo): 이 API는 QES를 사용하여 QES 정보를 설정한다.

본 발명의 컴포넌트는 이제 상술된 API들의 관점에서 보다 상세하게 설명될 것이다.

건강 문장은 각각의 QPC로부터의 정보의 집합이다. 각각의 QPC로부터의 정보는 각각의 클라이언트에 의해 확인된 클라이언트의 상태를 설명한다. SoH는 SoH를 파싱(parsing)하는 QCS 컴포넌트에 전달되고 각각의 정보 조각은 검증되기 위해 올바른 QPS로 전달된다. QCC는 각각의 QPC로부터의 정보를 캐싱할 책임이 있다. 각각의 QPC는 그들의 정책 정보가 변경될 때마다 QCC에게 자신의 정보를 공개한다. QCC는 하나 이상의 SoH를 포함하는 단일적인 패킷을 생성한다(항상 QCC SoH가 있음). QCC는 이 단일적인 패킷을 QEC에 공급한다. QEC/QES가 QEC/QES 프로토콜에 필요하면, QEC/QES는 단편화/최적화할 책임이 있다. QCS는 하나 이상의 SoH Response를 포함하는 단일적인 패킷을 생성한다(QCS SoH Response가 항상 있음). QCS는 QES에게 이 단일적인 패킷을 공급한다. QES/QEC가 QES/QEC 프로토콜에 필요하면, QES/QEC는 단편화/최적화할 책임이 있다. QPC 및 QPS는 SoH의 말단에 새로운 정보를 추가함으로써 SoH의 버전을 지정하는 것을 포함한다. SoH의 버전을 지정할 수 없으면, QPC 및 QPS는 새로운 QPC_ID/QPS_ID를 할당할 수 있지만, Bind 호출(후술됨)은 동일한 생산 GUID를 사용해야 한다.

QPC는 확인을 설정하고 자신의 SoH를 QCC에게 공개한다. SoH는 QPS가, 클라이언트가 올바른 상태에 있는지를 확인하기 위해 사용할 수 있는 정보를 포함한다. QPS는 SoH Response 버퍼를 클라이언트에게 반환할 수 있다. 이것은 예를 들어 갱신된 확인을 얻기 위해 서버를 폴링하는 것과 같은, 실패했을 경우에 무엇을 해야할 지를 QPC에게 알리는데 사용된다. 이것은 또한 자신의 정보를 얻는데 사용되어야 할 서버의 이름과 같은 정보를 클라이언트에게 제공하기 위해 사용될 수 있다. QPC는 LocalSystem 또는 NetworkService의 문맥으로 동작하는 서비스 역할을 한다. QCC를 공표하는 COM 인터페이스는 로컬 기기 계정 로컬시스템 및 네트워크서비스에 대해서만 ACL되어야 한다. QCC가 사용자에게 기기가 검역 중인 이유에 대한 정보 및 기기가 검역을 피하도록 하는 진행을 보여주는 사용자 인터페이스(UI)를 디스플레이하도록 QCC를 인에이블링하기 위해, QPC는 정책 서버와 매치하도록 클라이언트를 갱신하는 QPC 진행 및 QCC가 각각의 QPC를 질의하기 위해 상태 API(후술됨)를 공급한다. 네트워킹으로 보안 모드에 있는 기기는 동작중인 QCC를 가지면 안된다. 동작중이면, QEC는 검역 호출을 바이패스한다. 동작중이면, QPC는 검역 호출을 바이패스한다.

QCC는 클라이언트를 위한 멀티플렉스/제어기이다. QCC는 각각의 QPC로부터 SoH 정보를 고르고 SoH를 캐싱한다. 새로운 SoH가 QPC에 의해 공급될 때 캐시가 갱신된다. QPC COM 객체가 기기로부터 삭제될 때, 캐시 내의 엔트리가 삭제된다. 이것은 QPC COM GUID가 QCCQPC->Bind 호출로 전달된 후에 삭제된다(후술됨). QCC는 검역 상태가 변경할 때 QPC에 QPS와 QPC 사이의 통신 채널뿐만 아니라 통지 메 커니즘을 제공한다. QCC는 시스템 검역 상태를 유지하고 각 QPC로부터의 상태 정보를 수집하며 QCC UI에 둘 모두 제공한다. QCC는 QEC에 SoH의 목록을 제공하고, QPC에 SoH Response를 전달한다.

QCC는 QPC에게 상기 서비스들을 제공하기 위하여 QPC에 대한 API를 지원한다. API는 로컬 기기 계정들 LocalSystem 및 NetworkService에 대해서만 ACL된다. 또다른 API는 사용자에게 디스플레이하기 위한 검역 상태 및 기타 상태 정보에 대해 질의하기 위하여 QCC UI에게 이용가능하다. QCC UI는 사용자 문맥 내에서 동작하며 따라서 QCC UI에 대한 QCC API가 모두에 대해 ACL되어야 한다. QCC는 서비스로서 구현되며, 모든 QEC들은 이 서비스에 의존적이다. QCC는 NetworkService로서 동작한다. QPC는 초기화 동안 Bind를 호출하기 위해 시도하며, 만약 QCC가 동작하고 있지 않기 때문에 이 호출이 실패한다면, 주기적으로 Bind를 호출하고자 시도한다. QPC는 SoH가 변경할 때마다 NotifySoHChange를 호출한다. QCC는 각 QEC에 대해 NotifySoHChange를 호출할 것이다. QCC는 시스템이 검역 상태인 한, 주기적인 간격으로 각 QEC에 대해 NotifySoHChange를 호출한다. QCC 및 QCS는 자신들의 정보를 교환하기 위하여, 예를 들어, QCS가 QCC에게 자신이 검역상태인지 아닌지를 알리기 위하여, SoH/SoHResponse 포맷을 사용한다. QCC는 QEC에게 전달하기 위하여 SoH들을 버퍼로 팩한다. QCC 및 QCS는 항상 자신의 SOH를 버퍼 맨 앞에 둘 것이다. QCC 및 QCS는 모든 QPC 및 QPS로부터의 SoH들을 포함할 것이다. 만약 QCC가 QCS로부터 요구된 QPS_ID들의 리스트를 갖는다면, QCC SoH를 삽입한 후에 QCS SoH에 명기된 순서로 SoH들을 삽입해야 한다.

만약 QEC MaxSize가 너무 작으면, QCC가 완전한 SoH들을 MaxSize에 도달할 때까지 부가해야 한다. QEC는 QES/QCS/QPS에 가능한 많은 정보를 전달할 것이다. SoH를 누락하는 것이 검역 정책에 영향을 준다면, 그 다음에 기기들이 검역될 것이나, QCS SoHResponse가 QES/QCS/QPS 서버 상에서 동작하는 QPS들을 위한 QPS_ID들의 목록을 리턴하여 QCC는 재시도의 최소 정보를 제공할 수 있다. QCS가 검정 시간을 갖는 검역 시간을 리턴한다면, QCC는 검정 시간을 ConnectionState IF의 검정 시간(Probation Time)을 저장한다. QCC는 그 다음에 검정 시간의 타이머를 개시한다. 검정 시간이 만료될 때, QCC는 NotifySoHChang를 모든 QES들에게 트리거한다. QEC가 QuerySoH를 호출할 때 QCC는 ConnectionState IF Probation Time을 검사하고, 만약 검정 타임(probation time)이 만료되면 SoH가 변경되든지 변경되지 않든지 SoH의 리스트를 리턴한다. 만약 시스템 상태가 검정이면 검정 타임은 첫번째 ConnectionState Probation Time이 만료될 때까지의 시간이다. 만약 QEC가 QCCQEC->NotifySoHChangeFailure를 호출한다면, QCC는 타이머를 동작시키고 타이머가 만료되면 QECQCC->NotifySoHChange를 호출해야 한다. 만약 QPC가 QuerySystemQuarantineState를 호출한다면, QCC는 단일 시스템 상태를 생성하기 위하여 개개의 ConnectionState 검역(quarantine) 상태들을 결합해야 한다. 개개의 상태들이 다음 순서로 다음 규칙들을 사용하여 결합된다. 검역 상태에 있는 임의의 ConnectionState -> 시스템 상태가 검역; 검역 상태에 있는 ConnectionState가 없고, 검정 상태에 있는 임의의 ConnectionState -> 시스템 상태가 검정; 비검역 상태에 있는 모든 ConnectionState -> 시스템 상태는 검역이 아님. QCC는 서비스 이므로, svchost에서 동작하고 중지될 때 그것의 dll을 모두 언로드(unload)할 것이다. QCC는 QEC로의 호들을 감시하고, 만약 API가 짧은 시간 (X ms)내에 리턴하지 않는다면 QCC 이벤트는 이것을 로그하고 사용된 QPC의 리스트로부터 QPC를 제거하며 그 QPC로부터의 임의의 호들을 무시한다. QCC는 QPC로의 호들을 감시하고, 만약 API가 짧은 시간(X ms) 내에 리턴하지 않으면, QCC 이벤트는 이것을 로그하고 사용된 QEC의 리스트로부터 QEC를 제거한다. 서비스는 재시작 가능하고, QEC 및 QPC는 재시작되는 QCC로부터 복구될 수 있어야 한다.

만약 QCC 또는 임의의 QEC가 죽거나 파괴되면, 시스템은 SoH가 유효하지 않을 때 자동으로 검역을 입력해야 한다. QCCQPC 및 QCCQEC COM 객체들은 QCC 서비스들을 자동-시작하도록 구성된다. QCC는 기기 부팅 시 시작하도록 구성된다. QCC는 QPC로부터 SoH들을 캐쉬한다(QCC SoH를 캐쉬하지 않음). 캐쉬는 서비스를 가로질러 지속되며 시스템은 재시작한다. QCC는 검역 클라이언트가 인에이블되는지 아닌지를 구성하는 레지스트리 파라미터를 가진다. QCC는 레지스트리 파리미터가 설정되면 자동으로 검역 지원을 인에이블 및 디스에이블한다. 검역이 디스에이블되면, QuerySoH들은 (QCC SoH가 없음을 포함하여) SoH가 없음을 리턴한다. QCCQPC->NotifySoHChange는 어떠한 동작도 없이 리턴한다. QCCQEC->ProcessSoHResponse는 QCS SoHResponse를 프로세싱하지만 다른 SoHResponse를 프로세싱하지 않는다. QCC_READ->QueryQuarantineState는 QCS SoHResponse에 있는 검역 상태를 리턴한다. QCS는 정보를 QCS SoHResponse에 있는 QCC에 전송한다. QCS는 이 정보를 캐쉬한다. 정보에 대한 인덱스는 QCS SoHResponse에 있는 QCS GUID이다.

사용자는 기기가 검역인지 아닌지를 알 필요가 있다. 이러한 정보는 두 레벨로 보여진다. 시스템 규모(system wide) - 기기가 검역에 있고 QPC는 실패이다. 그리고 연결 당(per connection) - DHCP, 802.1X 및 VPN에 대하여 이것은 연결 당이고, IPsec에 대하여 이것은 피어 기기로의 연결 당이다. 시스템 규모 정보에 대해 시스템이 검역일 때 시스템 트레이에 아이콘이 디스플레이된다. 정보 텍스트를 갖는 풍선이 디스플레이되며 사용자는 상태 다이얼로그를 얻기 위해 풍선을 클릭한다. 검역 상태 다이얼로그는 QCC_ID의 QPC_ID(0,0,311 및 0)를 갖는 QCC_READ->QueryStatus를 호출한다. QCC는 바인드(Bind)를 호출하지 않은 QPC에 대한 상태 정보를 리턴하기 위하여 이것을 사용한다. 특히, 시스템이 검역이고 QPC에 전달할 수 없었던 QCC에 SoHResponse가 제공된다면 QCC_ID에 대한 QCC_READ->QueryStatus는 검역 클라이언트가 없어진 것을 유의해야 한다. 상태 다이얼로그는 소정 전체 텍스트 및 각 QPC의 상태를 나타내는 QPC 별 메시지를 디스플레이한다. 네트워크 연결 폴더를 디스플레이하기 위한 버튼뿐 아니라 QCS SoH에 있는 URL로부터 웹페이지를 디스플레이하기 위한 버튼이 또한 디스플레이된다. 웹 페이지가 제한된 IE 브라우저에 디스플레이되고, 기본 HTML만이 인에이블되며, 액티브 X, 자바, 기타 스크립트, 링크, DHTML 모두 허용되지 않는다. 검역 상태 정보의 디스플레이(예를 들어, 검역 상태에 있는 기기)는 익스플로러를 동작하고 있는 모든 쌍방향 윈도우 스테이션에서 발생한다. 이것은 빠른 사용자 스위칭을 동작하고 있는 모든 사용자들 및 터미널 서버에 로그한 모든 사용자들에 검역 상태 정보의 디스플레이를 인에 이블한다. 커맨드 라인 유틸리티 netsh는 시스템 규모 검역 정보를 디스플레이한다. 검역 시스템은 또한 netsh를 통해 인에이블 및 디스에이블될 수 있다. QCC는 파일로 추적할 수 있고, 추적을 인에이블/디스에이블하는 것은 netsh를 통한다. QCC는 검역 상태가 변경될때 언제든지 파일을 추적하기 위하여 다음을 로그한다 - 검역/검정/비검역 상태, QPC 바운드, 트랜잭션 ID, QES GUID, QNAME GUID, QECInformation, NIC MAC 주소, IP 주소, QPC로부터의 진단적 정보와 함께 실패한 QPC, 핸들링하지 않은 SoH Response QPS_ID, SoH 및 SoH Response의 내용.

QEC 컴포넌트들은 검역 시행(Quarantine Enforcement)을 제공한다. 많은 가능한 QEC들이 있다 - DHCP, VPN, PEAP 및 IPsec. QEC는 클라이언트의 상태를 증명하기 위하여 BoH나 SoH를 사용한다. DHCP QEC는 SoH를 DHCP 서버에 통신한다. IPsec QEC는 BoH만을 사용한다. QEC는 인터페이스가 도착하거나 갈 때(예를 들어, PnP 이벤트), QCCQEC->NotifyInterfaceStateChange를 호출한다. 인터페이스가 Mediasense 커넥트/디스커넥트를 생성한다면, QEC는 QCCQEC->NotifyInterfaceStateChange를 생성한다. 만약 인터페이스 상의 연결성이 예를 들어, IP 주소, 802.1X 키 등을 변경한다면, QEC는 QCCQEC->NotifyInterfaceStateChange를 생성한다. QEC 및 QES는 SoH의 리스트 및 SoH Response 버퍼의 리스트의 포맷을 이해하지 않는다. QCC가 QECQCC->NotifySoHChange를 호출하면, QEC는 즉시 호를 리턴한다. QEC가 임의의 이유로 NotifySoHChange를 프로세싱할 수 없는지를 안다면, 나중에 프로세싱하기 위하여 통지를 저장하거나 QCCQEC->NotifySoHChangeFailure를 호출하여 NotifySoHChange를 무시할 수 있다. 이러한 경우에, QCC는 타이머를 시작할 것이다. 타이머가 만료되면, QCC는 모든 QEC에 대해 QECQCC->NotifySoHChange를 호출할 것이다.

DHCP QEC는 QCC로부터 SoH의 리스트를 포함하는 버퍼를 획득한다. DHCP 클라이언트는 버퍼를 조각내고, 만약 요구된다면 DHCP Discover, DHCP Request 및 DHCP Inform에서 전송되도록 각 프래그먼트를 DHCP 옵션으로 둔다. 사용된 DHCP 옵션은 마이크로소프트® 판매자 옵션이다. DHCP QEC 및 QES는 SoH의 리스트의 포맷, 개개의 SoH의 포맷을 이해하지 않으며, SoHResponse를 포함하는 버퍼의 포맷 또한 이해하지 않는다.

PEAP QEC는 SoH나 BoS를 사용할 수 있다. 만약 SoH/SoHResponse가 사용된다면, 그들은 서버의 인증 및 SoH/SoHResponse 교환의 보호를 제공하기 위하여 PEAP 터널 내에서 교환되어야 한다. PEAP QEC가 VPN과 함께 사용되고 클라이언트가 정책 서버, 예를 들어, WUS를 사용하도록 구성되지 않으면, QPS는 클라이언트를 실망시킬 것이다. 만약 QPC가 정책 서버에 대한 구성 정보를 필요로 하면, QPS는 이것을 SoHResponse에서 QPC에게 공급해야 하는데, 예를 들어, WUS QPS는 SoHResponse에 WUS 서버 이름을 두어야 한다.

IPsec QEC는 BoH를 사용한다. 이것은 IPsec 시행 검역 시스템이 검역 서버의 전개를 요구한다는 것을 의미한다. 검역 서버는 SoH를 검증하고, SoH가 검증된다면 BoH를 발행한다.

본 발명의 일 실시예에서, 검역 서버는 DHCP 서버이다. DHCP 서버 기기는 DHCP QES, QCS 및 QPS를 포함한다. DHCP QES는 검역 DHCP 옵션을 프로세싱하고, SoH 정보를 수집하며, SoH의 리스트를 생성하고 QCSQES->ValidateSoH를 사용하여 그 리스트를 QCS에 전달한다. QCS는 각 SoH를 나누고, 각 SoH를 올바른 QPS에게 QPCQCS->ValidateSoH를 사용하여 전달한다. QCS는 QCSQPS->OnValidateSoHComplete를 호출하는 QPS에 의해 각 QPS로부터의 결과를 수집하고, TransactionState->OnValidateSoHsComplete를 호출함으로써 DHCP QES에 그 결과를 알린다. DHCP QES는 비검역 DHCP 옵션을 획득하고, 만약 클라이언트가 검역에 놓여질 것이라면, 검역 옵션을 획득하고 동일한 비검역 옵션 대신에 검역 옵션을 사용하며, 고객 클라이언트에 전송되지 않도록 명기된 임의의 옵션들을 삭제한다.

QPS는 필요하다면 정책 서버를 액세스하여 그들의 SoH를 검증한다. 각 QPS는 검역 또는 비검역을 QCS에 리턴한다. QPS는 또한 QCS가 QCC에게 전송할 소정 정보(SoH Response)를 리턴할 수 있으며, QCC는 그것을 QPC에게 전달할 것이다. QEC/QCC는 DHCP Discover 및 DHCP Request에서 SoH를 전달하고 QCS/QES는 이들을 프로세싱하고 DHCP Offer 및 DHCP Ack에서 SoH Response를 전송한다. DHCP 서버는 범주 및 검역 속성을 알아내고 ValidateSoH를 호출하여 연결성 면제 플래그(Connectivity Exempt flag) 등이 알려지기 전에 Transactionstate->SetQuarantineConfig 및 TransactionState->SetConnectivityExempt를 호출한다. DHCP 서버는 다음 들어오는 DHCP 패킷들 - DHCP Discover, DHCP Request 및 DHCP Inform - 에 대해 ValidateSoH를 호출한다. 이것은 QCS가 모든 DHCP 검역 프로세싱을 오버라이딩하도록 허용한다. DHCP 서버는 DHCP Decline 및 DHCP Release에 대하여 ValidateSoH를 호출하지 않는다. DHCP 서버는 클라이언트가 유효한 계약 (lease)을 가지지 않는다면 DHCP Discover 및 DHCP Request에 대해 QCS를 호출하지 않는다. 이것은 DHCP가 IP 주소를 줄 수 없는 클라이언트들에 대한 정보를 QCS가 프로세싱하거나 캐쉬하지 않도록 행해진다.

DHCP 서버 검역이 RQC/RQS 검역과 함께 사용된다면, DHCP 서버에 대한 다음 구성이 적용되어야 한다. 만약 VPN 서버가 VPN 클라이언트에 대한 IP 주소를 획득하기 위해 DHCP 서버를 사용하고 있다면, 개별적인 DHCP 범주가 사용되어야 하고 범주는 디스에이블된 DHCP 검역을 가져야 한다. 만약 VPN 서버가 VPN 클라이언트에 대한 IP 주소를 획득하기 위하여 DHCP 서버를 사용하고 있지 않지만 DHCP 범주는 DHCP 서버로 DHCP 알림 메시지에 대한 DHCP 옵션을 리턴하도록 구성된다면, 개별적인 DHCP 범주가 사용되어야 하고 범주는 디스에이블된 DHCP 검역을 가져야 한다. DHCP 서버는 SoH Response의 리스트를 분해하고, 만약 요구된다면 DHCP Offer 및 DHCP ACK에서 전송되도록 각 프래그먼트를 DHCP 옵션에 둔다. SoH Response는 DHCP NAK에 추가되지 않는다. DHCP 서버는 성능 카운터로서 다음을 추적하고 또한 그것들을 DHCP MMC에 디스플레이한다. 검역에 있는 활성 계약의 수, 비검역에 있는 활성 계약의 수, 검정에 있는 활성 계약의 수, 드롭된 검역 요청의 수. 만약 QCSQES->ValidateSoH들이 QCS에 의해 실패된다면, DHCP 서버는 검역 구성이 인에이블되든지 검정이든지 요청을 드롭해야 한다. 만약 이것이 발생해야 한다면, QES는 마지막 5분 동안 드롭된 요청들의 수와 함께 매 5분마다 이벤트 로그를 생성해야 한다. 만약 OnValidateSoHsComplete가 실패로 완료되면, DHCP 서버는 클라이언트를 검역해야 한다. QCS가 SoHResponse의 리스트에 먼저 QCS SoHResponse를 두어야 하기 때문에 이것은 발생해서는 안 된다. QCS SoHResponse의 최대 크기는 SoHResponse의 리스트에 대한 DHCP MaxSize보다 작도록 정의된다. DHCP 서버는 QCS가 각 ValidateSoH에 대해 사용하는 타임아웃을 명기하기 위한 레지스트리 구성 파라미터를 갖는다. 응답 타임아웃: ValidateSoH를 호출하는 QCS로부터 QPS가 OnValidateSoHComplete를 호출하도록 QCS가 기다리는 밀리세컨드. 이것은 QCSQES->ValidateSloH에서 QCS에 전달된다.

QCS는 SoH의 리스트를 검증하기 위하여 사용된다. SoH의 리스트가 QES로부터 QCS에 제공된다(검역 서버 QES를 포함함). QCS는 SoH의 리스트를 분할하고 각 SoH를 올바른 QPS에 전달한다. 만약 QPS가 SoH에 대해 가용하지 않은 경우 SoH는 드롭되고 무시된다. QCS는 각 QPS로부터 결과들을 수집하고 단일 결과를 생성한다. 이 결과는 검역인지 아닌지를 판정하기 위하여 사용된다. QCS는 검역 발생없이 시스템이 전개되고 테스트되도록 허용하기 위하여 전체 검역/비검역 구성을 갖는다. QCS가 QPS 결과들을 단일 결과로 결합하는 방식은 불리언 방정식을 통한다 : (QPS_ID1 || QPS_ID2) && QPS_ID3. 이것은 QPS_ID1이나 QPS_ID2 둘 중 하나는 비검역을 리턴해야 하고, QPS_ID3는 비검역일 결과에 대하여 비검역을 리턴해야 한다는 것을 의미한다. QCS는 검역 대신에 검정 및 검정 기간을 리턴하도록 구성될 수 있다. QCS는 QPS 결과가 검역일 때 비검역을 리턴하도록 구성될 수 있다. 모든 경우에, QCS는 결과를 감사 파일(audit file)에 두어야 한다. QCS는 또한 각 SoH 검증 요청 및 결과에 대한 로그 정보를 생성하고 로그 결과를 감사 파일에 저장한다. 네트워크 관리자가 검사로부터 QPS를 인에이블하거나 디스에이블하기 위 하여 이 방정식을 변경하는 것은 쉽다. 이것은 특정 검사에 대한 이슈가 발생한 경우 관리자가 쉽게 검사를 디스에이블하도록 허용하는데, 예를 들어, AV 정책 서버 관련 이슈가 존재하는 경우 AV QPS를 쉽게 디스에이블할 수 있다.

QCS가 DHCP QES 및 검역 서버 QES에 의해 사용된다. QCS는 QEC에 의해 아무런 SoH도 제공되지 않을 때조차 QES에 의해 호출된다. 이것은 클라이언트가 검역을 지원하지 않는 경우를 다루기 위해서이다. 이것은 QCS가 이러한 클라이언트들에 대한 정책을 결정하도록 허용한다. QCS는 검역 또는 검역을 지원하지 않는 비검역 클라이언트들을 선택할 수 있다. 그렇게 하는지 하지 않는지에 대한 판정은 네트워크 관리자에 의해 구성가능하여야 한다. QCS는 QPS로부터의 결과를 캐쉬한다. SoH의 리스트가 동일한 경우, SoH Response, 검역/비검역/검정의 동일한 리스트가 디폴트 30초인 짧은 구간의 시간동안 사용된다. 디폴트 시간은 레지스트리 변수를 사용하여 변경될 수 있다. 만약 SoH 의 리스트 캐쉬에 대한 매치가 발견되지 않으면, QCSQPS->Bind를 호출하였던 모든 QPS들이 그들의 SoH와 함께 호출된다(또는 그 QPS_ID에 대한 SoH가 없는 경우 SoH는 호출되지 않음). QCS는 그 후 응답 타임아웃 밀리세턴드 동안 타이머를 동작시킨다. 호출되는 QPS들 중 임의의 것이 OnValidateSoHComplete를 호출하지 않는다면, QCS는 지금까지의 결과와 지금까지의 SoHResponse의 리스트를 갖는 OnValidateSoHsComplete를 호출할 것이다. 그렇지 않으면 가장 마지막 예기된 QPS가 QCSQPS->OnValidateSoHComplete를 호출할 때 QCS는 QESTransactionState->OnValidateSoHsComplete를 호출할 것이다. QCS는 임의의 기타 프로세싱 전에 SoH의 리스트를 검증해야 한다. 만약 검증이 실패하면, QCS는 실패를 갖는 TransactionState->OnValidateSoHsComplete를 호출한다. 상이한 클라이언트들이 QPC에 따라 상이한 SoH를 가질 수 있기 때문에, 캐쉬는 동일한 QPS에 대하여 다수의 SoH를 저장한다. 만약 ValidateSoH 요청이 SoH의 리스트를 갖지 않는다면, QCS는 SoHResponse의 빈 리스트를 클라이언트에 전송한다. QCS는 QES에 전달하기 위하여 응답 정보를 버퍼에 팩(pack)한다. QCS는 GUID인 검역 이름과 함께 구성된다. 이 검역 이름은 QCS SoH Response에서 QCC에 전달된다. QCS는 또한 첫 번째 실행에서 QCS 이름 GUID를 생성하여 그것을 모든 QCS SoH Response에 포함한다. QCC는 상이한 QCS들을 식별하기 위하여 이 GUID를 사용하고, QCS 당 QPS_ID의 바람직한 리스트와 같은 정보를 추적한다.

만약 클라이언트가 상이한 검역 이름을 갖는 둘 이상의 네트워크들에 연결된다면, 각 네트워크 상의 QPS는 상이한 집합의 검사들을가질 수 있고, 따라서 그들의 QPC는 상이한 SoH를 가질 수 있다. 검역 이름이 QPC에 전달되고, QPC는 만약 상이한 정책 서버들에 대한 다수의 SoH를 지원한다면 특정 검역 이름에 대하여 SoH를 발행할 수 있다. 만약 QPC가 단지 하나의 정책 서버만을 다룬다면, 검역 이름 없이 SoH를 발행한다. QCS는 Bind를 호출했던 QPS들에 대해 ValidateSoH들을 호출할 것이지만, 만약 SoH가 SoH의 리스트에 있지 않다면 QPS로의 ValidateSoH 호출은 빈 SoH 버퍼를 포함한다. 이것은 QPC가 인스톨되지 않은 경우에도 QPS가 호출되도록 허용하고 또한 클라이언트 소프트웨어(예를 들어, 네트워크 IDS)를 필요로 하지 않고서 클라이언트를 검사하는 QPS를 지원한다. 이러한 경우의 QPS는 SoH Response를 제공할 수 없으며, 클라이언트의 검역 상태를 판정하기 위하여 외부 정 보 및 TransactionState IF 정보에 의존할 수 없다.

QCS는 QCC SoH로부터 기기 이름을 사용하여 AD에서 기기 객체를 찾아본다. 만약 기기 객체가 존재하면 검역 연결성 면제 변수가 기기 객체에 대해 검사되고, 만약 기기가 검역 연결성 면제라면 QCS에 의해 비검역이 리턴되어야 한다. 검역 면제 변수가 활성 디렉토리에서 컴퓨터 계정 UI에 노출된다. QCS는 모든 기타 QCS 프로세싱(예를 들어, QPSQCS->ValidateSoH 및 QCSQPS->OnValidateSoHComplete의 호출) 후에만 면제를 다룬다. 그 후 QCS는 임의의 면제들을 적용한다. 이것은 QPS가 그들의 QPC에 대한 SoHResponse들을 생성할 수 있다는 것을 의미한다. QPS들은 인스톨 시 QCSQPS->Register를 통해 QCS에 등록된다. 레지스터는 레지스트리 파라미터를 통한다. QCS는 proc 객체 중 하나로서 QPS COM 객체를 생성한다. QCS는 레지스트리 키를 감시하여, 추가되는 경우 새로운 COM 객체들을 생성하고 레지스트리 키로부터 삭제되는 경우 QPS들을 사용하여 중지한다.

DHCP 서버에 대한 QES UI는 QCS에 대한 UI를 포함한다. SetQuarantineConfig를 통해 설정된 구성 파라미터들은 검역 상태 온/오프/검정, 검정 기간, 검역 로깅 인에이블드, 면제 비검역 인지 클라이언트, 실패 URL 및 도메인 이름 예외에 기초한 일반적인 표현이다. 검역 상태 온(Quarantine State On)은 QCS가 SoH들을 검증하는 것을 가능하게 한다. 검역 상태 오프(Quarantine State Off)는 SoH를 QCS가 SoH들을 검증하지 못하게 한다. QCS는 순응하는 상태에 대해 알려지지 않음 및 연결성 상태에 대해 영향받지 않는 연결성을 리턴할 것이다. 검정은 QCS가 SoH들을 검증할 수 있도록 하고 올바른 순응하는 상태를 리턴하 지만 순응하지 않는 클라이언트에 대해 일정 시간 기간 동안 연결성 상태를 검정으로 설정할 것이다. 검정 기간은 클라이언트가 비순응이 될 때 영향받는 연결성을 비순응 클라이언트가 갖지 않는 시간이다.

검역 정책 클라이언트 및 검역 정책 서버(정책 서버를 가짐)는 클라이언트에 대한 검사들의 집합을 구현할 책임이 있다. 검역 정책 서버는 클라이언트 검사의 결과에 대해 판정을 행하고, 클라이언트 검사들이 괜찮은지 아닌지를 검역 조정 서버에 보고할 필요가 있다. 수행된 검사들은 검역 정책 클라이언트에 의존한다. 본 발명의 일 실시예에서, 윈도우즈®에 형성된 QPC만이 WUS일 것이다. WUS는 마이크로소프트® OS 패치를 단지 전개하는 WUS 서버에 대하여 패치 레벨을 단지 검사할 것이다. 만약 QPS가 클라이언트 컴포넌트, 예를 들어, 네트워크 IDS를 요구하지 않고서 클라이언트를 검사할 수 있다면, 시스템이 QPC 없이 QPS를 포함하는 것이 가능하다. 이러한 경우에, QPS는 QPC로부터 SoH를 필요로 하지 않고서 QCS에 검역/비검역으로 응답한다. 그러한 QPS가 사용될 때, QCS는 QPS를 호출하지만 SoH를 제공하지 않는다. 그 후 QPS는 클라이언트 기기가 "비건강"인 것으로 판정할 수 있다.

QPS는 QPC가 접촉해야하는 정책 서버의 주소/이름을 SoHResponse에서 QPC에 리턴하도록 권고된다. QPC는 정책 서버와 자신의 통신을 다루고 요구될 때 통신을 재시도하도록 기대된다. QPS가 SoH를 실패할 때 정책 서버를 이용하여 정책을 검사하기 위하여 SoHResponse에서 QPC에 힌트를 전송하도록 권고된다. QPC는 정책 구성 정보를 획득하기 위하여 그들이 사용하는 정책 서버의 신원을 보장할 책임이 있다. QPC는 SoH 정보를 생성하기 위한 다수의 정책 서버를 지원할 수 있다. 상이한 SoH 정보는 QNamd GUID 별로 추적되어야 한다. 이것은 윈도우즈® 갱신으로부터 갱신을 획득하도록 구성되는 가정 기기에 대해 그러하다. QPC는 ProcessSoHResponse가 호출될 때 그들의 정책 서버로의 연결성이 가용할 것을 기대해서는 안 된다. IP 주소는 ProcessSoHResponse가 호출된 시간에 의하여 구성될 수 없다. QPC는 이것을 위하여 IP 주소 통지 API들을 사용해야 한다. QPS는 TransactionState에서 임의의 정보를 변경시켜서는 안되고, 그것은 단지 질의를 위한 것이다. 이 COM 객체에 대한 임의의 참조 카운트를 증가시켜서는 안 된다. QPS는 ValidateSoH로의 임의의 호를 즉시 리턴해야 하며 이러한 요청들을 내부적으로 큐잉해야 한다. QPS가 정책 서버와 통신할 것을 필요로 하는 경우, 기타 ValidateSoH 요청들과 이러한 통신을 직렬화해서는 안 된다. 만약 QPS가 ValidateSoH를 큐잉할 수 없다면, 호를 즉시 실패해야 하며, QPS는 많은 이러한 요청들을 병렬로 큐잉하고 프로세싱할 수 있도록 기대된다. QPS는 멀티스레드 아파트먼트로서 구현되어야 한다.

QPC 및 QPS는 인터페이스 등을 등록할 때 COM 설치를 위한 정상적인 규칙을 따르도록 요구된다. QPC 및 QPS는 설치 시 QCC 또는 QCS에게 알릴 것을 필요로 하지 않는다. QCC 및 QCS는 QCCQPC 또는 QCSQPS 인터페이스 상의 Bind API가 호출될 때 새로운 QPC 또는 QPS를 사용하여 시작할 것이다. QPS 설치는 다음과 같이 Register 및 Unregister 레지스터 키들을 설정해야 한다. QCS는 QPS가 QCS에게 그것이 설치되고 삭제되는 때를 레지스트리 키를 통해 알려줄 것을 요구한다. 시작 할 때 및 레지스트리 키가 수정될 때 QCS는 각 QPSQCS 인터페이스의 proc 인스턴스로부터 임의의 것을 생성하기 위하여 CoCreateInstance를 사용한다. Regester(QPS_ID, Product GUID, QPSQCS CLSID, QPS_READ CLSID): 이 API는 레지스트리 키로서 구현된다. 설치될 때 QPS는 이 레지스트리 키를 갱신해야 한다. Unregister(QPS_ID): 이 API는 레지스트리 키로서 구현된다. 시스템 상의 QPC나 QPS의 모든 폐기물들을 삭제(un-installation)할 때, 레지스트리에 포함된 모든 COM 등록 정보 및 모든 파일들이 제거되어야 한다.

WUS 클라이언트는 클라이언트가 WUS 서버로부터 설치했어야 하는 패티들의 리스트를 획득한다. WUS 클라이언트는 패치들이 설치되는지 및 WUS 서버나 Windowsupdate.com으로부터 패치를 다운로드하지 않는지를 검사하고, 패치들을 설치한다. WUS는 마지막 동기화 시간의 정보를 차례로 포함하는 기기 레코드와 관련된 서명된 쿠키를 사용하는 클라이언트를 식별한다. WUS는 기기 레코드에 클라이언트의 IP 주소를 유지하지만 이것을 검색을 위해 사용하지는 않는다. QCS 및 QCC는 QPC 및 QPS에게 통신 채널을 제공하고, QPC는 QPS에게 클라이언트를 식별하기 위한 정보를 전송할 수 있으며, QPS에게 상태 정보를 제공할 수 있다. QPS는 요구되면 QPC에게 정보를 제공할 수 있다. WUS에 대하여 만약 클라이언트가 QPS 검사를 실패했다면, QPS는 WUS 클라이언트가 사용할 필요가 있는 WUS 서버 이름을 제공할 수 있다. 이것은 WUS 클라이언트가 WUS 서버에게 제공되도록 허용한다.

상술된 요소들 간의 대화는 도 7을 참조하여 이제 상세화된다. 전체에 걸친 대화 과정은 다음과 같다: QPC는 SoH가 변경될 때는 언제나 QCCQPC- >NotifySoHChange를 사용하여 QCC에게 통지한다. QCC는 SoH들 목록이 변경될 때에 QECQCC->NotifySoHChange를 사용하여 모든 QEC들에게 통지한다. QEC가 SoH들 목록을 필요로 할때, 이것은 QCCQEC->QuerySoHs를 사용하여 QCC로부터 그 목록을 요청한다. QEC는 QEC/QES에 종속적인 메카니즘을 이용하여 SoH 목록을 QES에 전송한다(예를 들면, DHCP는 DHCP 옵션을 사용한다). QCCQPC->Bind를 호출하는 어떤 QPCs 을 위해, QCC는 QPCQCC->QuerySoH를 호출하고, 그 이후에 SoH 캐시로부터 어떤 부가적인 SoH를 추가한다. QCC는 그 이후에 목록을 QEC에게 리턴한다. QES는 SoH들 목록을 QCSQES->ValidateSoHs를 사용하여 QCS에 전달한다. QCS는 SoH들 목록을 분할하여, 각의 SoH를 정확한 QPS에게 QPSQCS->ValidateSoH를 사용하여 전달한다. 각각의 QPS는 클라이언트의 SoH를 검증하고, QCS에게 그 SoH가 정확한지 아닌지 여부를 리턴한다. QPS는 QCS에게 SoHResponse 버퍼에 있는 어떤 정보를 QPC에 전달할 것을 선택적으로 요청한다. QCS는 다른 QPS로부터의 모든 결과들을 수집하고, 하나의 검역/비검역 결과 및 SoHResponse 목록을 생성한다. QCS는 그 자신의 SoHResponse를 이 목록에 추가하고, 결과 및 목록을 QES에게 전달한다. QES는 검역/비검역 결과를 보고, 특정한 시행 방식으로 검역을 시행한다(예를 들면, DHCP는 디폴트 게이트웨이를 지원하지 않는다). QES는 SoHResponse들 목록을 QEC에 전달한다. QEC는 클라이언트들 정보 목록을 QCCQEC->ProcessSoHResponses를 사용하여 QCC에게 전달한다. QCC는 SoHResponse들 목록을 분할하여, 정확한 SoHResponse를 QPCQCC->ProcessSoHResponse를 사용하여 정확한 QPC에게 전달한다. QCC는 그 자신의 SoHResponse를 처리한다. QCC들의 SoHResponse는 검역/금지/비검역 정보를 사 용하여 사용자에게 메시지를 디스플레이한다. QEC/QES를 통한 QCC와 QCS 간의 통신은 마우이 섬(Maui)에서 보호되지 않는다. QPC/QPS 통신은 QPC/QPS에 의해 보호될 수 있지만, 검역 플랫폼의 범주를 벗어난다.

DHCP 클라이언트들은 네트워크 서버(DHCP 서버)로부터 네트워크 자원들을 요청하기 때문에, DHCP 서버는 QPS들을 포함할 수 있다. QPC 및 QPS/정책 서버(예를 들면, SMS 또는 WUS)는 서버로부터의 클라이언트에 관한 정책을 클라이언트에게 통지한다. QPC는 업데이트들이 존재하는지 여부를 알기 위해서, 행정적으로 정의된 시간 간격 마다 서버를 폴링한다(poll). QPC는 기기의 SoH가 변경될 때는 언제나 QCC에게 통지한다. QCC는 SoH가 변경되었을 때는 언제나 모든 QES들에게 통지한다. QEC(DHCP 클라이언트)는 IP 주소 및 IP 주소 갱신을 요청하기 원할 때, QPC들 및 SoH 캐시로부터 SoH를 획득하고, 이것을 DHCP 서버에 하나 또는 그 이상의 DHCP 옵션을 사용하여 전달한다. QES(DHCP 서버)는 SoH들 목록을 QCS에게 전송하고, QCS는 각각의 SoH를 정확한 QPS에 전달한다. 각각의 QPS는 클라이언트의 SoH가 그 클라이언트에 대하여 정확하고 유효하다(예를 들면, 이 클라이언트에게 설치되어야하는 패치가 존재하지 않는다)는 것을 검증하기 위해, 이것의 정책 서버에 접속할 수 있다. 클라이언트가 유효하고 정확하다면, QPS는 성공 메시지를 QCS에게 리턴한다. 모든 QPS가 성공 메시지를 QCS에게 되돌려 준다면, QCS는 성공 메시지를 DHCP 서버에 리턴한다. 그 이후에, DHCP 서버는 정확한 DHCP 옵션을 DHCP 클라이언트에게 리턴한다. DHCP 서버는 발견(Discover),요청(Resquest),정보(Infomation) 메시지를 수신하자 마자 메시지들이 SoH DHCP 옵션을 포함하는지 여 부에 관계없이항상 QCS를 호출할 것이다. 이로써 QCS는 검역하기를 지원하지 않는 클라이언트를 어떻게 처리할 것인지를 결정할 수 있다. DHCP QEC는 검역불가 DHCP 서버와 통신할 때 동작해야 한다. 이로써 클라이언트는 검역 불가 네트워크 상에서 동작할 수 있게 된다.

PEAP QEC 는 검역 가능 RADIUS 서버들과 통신하지 않을 때 동작해야 한다. 이로써 클라이언트는 검역 불가 네트워크 상에서 동작할 수 있게 된다. REAP QEC는 SoH들을 RADIUS QES에 제공할 필요가 있을 때, QuerySoHs를 호출한다. 언제 이런 동작이 발생할지는 PEAP가 실행되고 있는 매체에 따라 좌우된다: VPN : PEAP는 VPN 터널일 셋업될 때 호출된다. VPN은 PEAP를 재실행하지 않는다. 802.1X : PEAP는 802.1X 가 NAS에 대해 인증되거나 재인증될 필요가 있을 때 호출된다. 이런 동작은 통신 과정 동안 수차례 발생할 수 있다. IPsec 클라이언트는 네트워크 자원들을 직접적으로 다른 클라이언트로부터 원할 때, 피어 IPsec 클라이언트는 QPS들을 직접 사용할 수 없다. QCC는 BoH를 획득하기 위해 검역 서버를 사용해야만 한다. BoH는 다른 형태를 취할 수 있다: 커버로스 티켓(Kerberos Ticket)은 요청된 서버와 함께 IPsec을 설정하는데 사용됨; 커버로스 티켓은 집단에서의 멤버쉽 가치(소위 청결한 집단(Clean Group)으로 불림)에 따라 기기에 적용되는 집단 정책 개체(GPO:Group Policy Object)와 관련을 맺을 수 있거나 존재하는 불능 상태가 되지 않는 기기 계정과 밀접한 관련을 맺을 수 있음; IPsec SA를 설정하는데 사용되는 X.509 또는 XRML 인증서. SA의 설정을 관리하는 IPsec 정책들은 BoH와 함께하여 규모가 증가되고, 클라이언트가 더이상 정책을 따르지 않는 경우 처럼 클라이언 트의 상태가 변경된다면 규모는 감소되어야만 한다.

클라이언트가 금지된다면, X.509 및 XRML 인증서는 금지 주기 동안만 유효하다. 클라이언트가 금지되고 청결한 집단들이 커버로스 티켓의 배포를 관리하는데 사용된다면, 두가지 요구 사항이 지원되어야만 한다. 커버로스 티켓은 금지 주기 이상 유효하지 않아야 한다. 클라이언트가 금지가 만료될 때 업데이트된 SoH를 제공하지 않았다면, QES는 클라이언트를 청결한 집단으로부터 제거하기 위해 적절한 단계를 취하여야 한다. QPC 및 QPS/정책 서버(예를 들면, SMS 또는 WUS)는 서버로부터의 클라이언트에 관한 정책을 클라이언트에게 통지할 것이다. QPC는 업데이트들이 존재하는지 여부를 알기 위해서, 시간 간격 마다 서버를 폴링할 것이다(poll). QPC는 기기의 "건강 상태(State of Health)"가 변경될 때는 언제나 QCC에게 공표할 것이다. QCC는 각각의 QPC로부터의 SoH들을 수집하여 SoH들 목록을 만든다. QCC는 SoH가 변경되었을 때는 언제나 모든 QES들에게 통지한다. QS의 클라이언트 QEC는 이 통지를 수신하자 마자 SoH들 목록을 획득하고, 이것을 검역 서버의 QES에게 전송한다. 검역 서버의 QES는 SoH들 목록을 QCS에게 전송하며, QCS가 각각의 SoH를 정확한 QPS에게 전달한다. 각각의 QPS는 클라이언트의 SoH가 그 클라이언트에 대하여 정확하고 유효하다(예를 들면, 이 클라이언트에게 설치되어야하는 패치가 존재하지 않는다)는 것을 검증하기 위해, 이것의 정책 서버에 접속할 수 있다. 클라이언트가 유효하고 정확하다면, QPS는 성공 메시지를 QCS에게 리턴한다. 모든 QPS가 성공 메시지를 QCS에게 되돌려 준다면, QCS는 성공 메시지를 검역 서버의 QES에게 리턴한다. 인증서가 IPsec SA들을 설정하는데 사용된다면, 검역 서버의 QES는 QCS가 성공 메시지를 되돌려 줄때 그 BoH를 QS의 QEC에게 리턴한다. 그 이후에 QS의 QEC는 그 BoH를 QCC에게 리턴하고, QCC는 이것을 캐시로 저장한다. 청결한 집단이 사용된다면, QES는 클라이언트를 청결한 집단에 추가하고, QUAR_SUCCESS를 클라이언트에게 리턴한다.

이것이 특정 클라이언트에 대한 첫번째 검증이라면, 클라이언트는 계속 진행하여 TSS로부터 TGT를 요청한다. 클라이언트가 이미 TGT를 갖고 있고 클라이언트가 정책 검사에 실패한다면, QES는 청결한 집단으로부터 클라이언트를 제거하고 TGS에게 이제 클라이언트는 더이상 정책에 따르지 않는다는 것을 통지한다. TGT가 정책을 순응하지 않아 더이상 유효하지 않으므로, 그 TGT로부터 발행된 어떤 SGT들도 주기를 넘어서 유효하지 않다는 것이 상당히 권고된다. 그 이후에 QCC는 BoH가 변경됨을 알리는 통지를 모든 QES들에게 전송한다. IPsec는 피어마다 IKE SA를 설정하도록 요청받을 때, 이것은 BoH 캐시로부터 BoH를 획득하고 이것을 피어 IPsec에 전달하는데, 인증서가 BoH를 표현하는데 사용되었다면 그러하다. 청결한 집단들이 사용될 때, 클라이언트는 통상적인 방식으로 SGT를 요청할때 TGT를 사용할 것이고, 그 이후에 티켓을 사용하여 SA를 설정할 것이다. 피어 IPsec은 누가 이것을 검증하고 성공 메시지를 피어 IPsec에게 리턴할 것인지, 누가 그 이후에 원격 IKE 통신을 수락할 것인지에 관한 BoH/티켓을 QCS에게 전달한다.

본 발명의 다양한 실시예에 관해 묘사하고 설명하기 위해 상기에 상세화하여 표현하였다. 이것은 소모적인 의도가 아니며, 본 발명은 개시된 자세한 실시예만 국한되지도 않는다. 다양한 수정 및 변경이 상기의 학설로 미루어 보아 가능하다. 논의된 실시예들은 본 발명의 원리들을 최대한 묘사하기 위하여, 당해 기술 분야에서 통상의 지식을 가진 자가 본 발명을 다양한 실시예들에 이용할 수 있고 다양한 수정을 통해 고려된 특정 사용에 알맞게 이용할 수 있도록 실용적인 애플리케이션을 제공하게끔 상세화되었다. 이런 모든 수정 및 변경은 명료하게, 합법적으로, 공정하게 자격이 되는 범위에 따른다고 해석될 때, 첨부된 청구항들에 의해 결정되는 본 발명의 범주 내에서 가능하게 된다.

본 발명에 의해, 유효성이 검증되지 않거나 손상된 상태를 갖는 기기들이 네트워크 자원들을 액세스하는 것을 확실하게 제한시키는 시스템 및 방법이 제공된다.

Claims

검역 정책을 시행하는 서버와 대화하기 위한 네트워크 검역 클라이언트로서,

네트워크 프로토콜을 통해 상기 서버와 통신하기 위한 적어도 하나의 시행 클라이언트, 및

적어도 하나의 정책 클라이언트로부터 적어도 하나의 건강 문장을 획득하기 위한 조정 클라이언트로서, 상기 조정 클라이언트는 상기 적어도 하나의 정책 클라이언트가 상기 조정 클라이언트와 통신을 이루게 하는 인터페이스를 공표하며, 상기 조정 클라이언트는 상기 적어도 하나의 건강 문장을 건강 목록 문장으로 정리하여 상기 적어도 하나의 시행 클라이언트에게 상기 건강 목록 문장을 제공하는 조정 클라이언트

를 포함하는 네트워크 검역 클라이언트.
제1항에 있어서,

상기 적어도 하나의 시행 클라이언트는 상기 건강 목록 문장을 이용하여 상기 서버로부터 네트워크 자원들로의 액세스를 획득하는 네트워크 검역 클라이언트.
제1항에 있어서,

상기 적어도 하나의 시행 클라이언트는 DHCP(Dynamic Host Control Protocol) 클라이언트, VPN(Virtual Private Network) 클라이언트, 및 IPsec 클라 이언트 중 하나인 네트워크 검역 클라이언트.
제1항에 있어서,

상기 조정 클라이언트는 상기 적어도 하나의 정책 클라이언트에 의해 제공된 인터페이스를 통해 상기 적어도 하나의 정책 클라이언트와 통신하는 네트워크 검역 클라이언트.
제1항에 있어서,

상기 조정 클라이언트 및 상기 시행 클라이언트는 컴퓨터의 운영 체제에 포함되는 네트워크 검역 클라이언트.
제1항에 있어서,

상기 적어도 하나의 정책 클라이언트는 적어도 하나의 정책 서버로부터 네트워크 정책을 획득하여, 호스트 컴퓨터가 상기 네트워크 정책을 따르는 것을 나타내는 건강 문장을 생성하는 네트워크 검역 클라이언트.
제1항의 방법을 실행하기 위한 컴퓨터-판독가능 명령어들을 포함하는 컴퓨터-판독가능 매체.
클라이언트가 네트워크 검역 정책을 따르기 위한 방법으로서,

하나 이상의 정책 서버들로부터 정책을 획득하는 단계,

상기 클라이언트가 획득한 정책을 따르는가를 판정하기 위한 시스템 진단을 실행하는 단계,

상기 클라이언트가 상기 획득한 정책을 따르지 않을 경우, 상기 클라이언트의 보안 상태를 정정하는 단계,

건강 문장들의 목록을 생성하는 단계-상기 건강 문장 각각은 상기 클라이언트가 대응하는 정책을 따르는 것을 나타냄-; 및

상기 건강 문장들의 목록을 정당성 검증을 위해 검역 서버로 전송하는 단계

를 포함하는 방법.
제8항에 있어서,

상기 클라이언트의 보안 상태를 정정하는 단계는 수리 서버로부터 소프트웨어 패치를 다운로딩하는 단계를 포함하는 방법.
제8항에 있어서,

상기 건강 문장 각각은 상기 클라이언트가 특정 정책을 따르는가를 판정하는 데 책임을 지고 있는 정책 클라이언트에 의해 생성되는 방법.
제8항에 있어서,

상기 건강 문장들의 목록이 정당한 것으로 검증되면 상기 검역 서버로부터 건강 목록표(bill of health)를 수신하는 단계를 더 포함하고, 상기 건강 목록표는 상기 검역 서버 및 네트워크 상의 다른 컴퓨터에게 상기 클라이언트가 상기 네트워크의 보안 정책을 따른다는 것을 나타내 주는 방법.
제8항에 있어서,

상기 건강 문장들의 목록은 프로토콜 시행 클라이언트에 의해 상기 검역 서버로 전달되고, 상기 프로토콜 시행 클라이언트에 의해 시행된 상기 프로토콜은 DHCP(Dynamic Host Control Protocol) 프로토콜, VPN(Virtual Private Network) 프로토콜, IPsec 프로토콜, 및 IEEE 802.1X 프로토콜 중 하나인 방법.
제8항의 방법을 실행하기 위한 컴퓨터-판독가능 명령어들을 포함하는 컴퓨터-판독가능 매체.
네트워크 검역 정책을 시행하기 위한 네트워크 검역 서버로서,

네트워크 프로토콜을 통해 적어도 하나의 클라이언트와 통신하기 위한 적어도 하나의 시행 서버, 및

상기 시행 서버로부터 적어도 하나의 건강 문장을 포함하는 건강 문장들의 목록을 수신하고 상기 적어도 하나의 건강 문장을 검증하기 위해 적어도 하나의 정책 서버에게 질의하는 조정 서버

를 포함하는 네트워크 검역 서버.
제14항에 있어서,

상기 건강 문장 각각이 검증되면, 상기 조정 서버는 상기 적어도 하나의 시행 서버에게 상기 적어도 하나의 클라이언트가 네트워크 자원들을 액세스하는 것을 인가하도록 지시하는 네트워크 검역 서버.
제14항에 있어서,

상기 건강 문장 각각이 검증되지 않으면, 상기 조정 서버는 상기 적어도 하나의 시행 서버에게 상기 적어도 하나의 정책 서버로부터 획득한 검역 정책을 시행토록 지시하는 네트워크 검역 서버.
제14항에 있어서,

상기 조정 서버는 상기 적어도 하나의 정책 서버가 상기 조정 서버와 통신을이루게 하는 인터페이스를 공표하는 네트워크 검역 서버.
제14항에 있어서,

상기 조정 서버는 상기 적어도 하나의 정책 서버에 의해 제공된 인터페이스를 통해 상기 적어도 하나의 정책 서버와 통신하는 네트워크 검역 서버.
네트워크 검역 관리 방법으로서,

원격 위치된 DHCP(Dynamic Host control Protocol) 서버로부터, 네트워크 자원들을 요청하는 클라이언트로부터 획득한 건강 목록표를 수신하는 단계-상기 건강표는 상기 클라이언트의 시스템 상태를 반영함-,

상기 건강 목록표의 유효성을 검증하는 단계,

건강 문장이 유효한 것으로 검증되면, 상기 DHCP 서버에게 상기 요청을 인가하도록 지시하는 단계. 및

건강 문장이 유효한 것으로 검증되지 않면, 상기 DHCP 서버에게 상기 요청을 인가하지 못하게 하고 상기 클라이언트를 검역 상태로 두도록 지시하는 단계

를 포함하는 방법.
제19항의 방법을 실행하기 위한 컴퓨터-판독가능 명령어들을 포함하는 컴퓨터-판독가능 매체.