KR20080045195A - 일관된 애플리케이션 인식 방화벽 횡단 제공 - Google Patents

Abstract

본 발명의 구현들은 방화벽을 통해 액세스 가능하게 되는 다양한 리소스들에 쉽게 적응될 수 있는 통신 프레임워크에 관한 것이다. 일반적으로, 게이트웨이 서버에서의 통신 프레임워크는 광범위한 리소스 및/또는 네트워크 액세스 정책들에 따라 요청된 리소스로의 특정한 접속을 제공할 수 있다. 일 예에서, 클라이언트는 방화벽 뒤의 특정 리소스로의 접속을 요청한다. 통신 프레임워크는 접속을 인증하고, 예를 들어, 클라이언트가 적절한 리소스 특징들을 사용중인 것을 판정할 때까지 접속을 검역한다. 적절하게 인증되면, 통신 프레임워크는, 통신 스택의 애플리케이션층에서 요청된 리소스로의 직접 접속을 용이하게 하는 적절하게 식별된 프로토콜 플러그인 프로세서로의 접속의 제어를 전할 수 있다.

방화벽, 리소스, 프레임워크, 게이트웨이 서버, 클라이언트, 프로토콜

Description

일관된 애플리케이션 인식 방화벽 횡단 제공{PROVIDING CONSISTENT APPLICATION AWARE FIREWALL TRAVERSAL}

컴퓨터화된 시스템들이 인기를 늘려감에 따라, 대규모 및 소규모 네트워크들에서 컴퓨터 시스템들의 파일들을 분배하고 리소스들을 처리할 필요가 있다. 일반적으로, 컴퓨터 시스템들 및 관련된 장치들은 다양한 이유들, 예를 들면, 개인적인 전자 메시지들 교환, 상품 판매, 회계 정보 제공, 등으로 네트워크를 통해 정보를 통신한다. 그러나, 컴퓨터 시스템들 및 그들의 관련된 애플리케이션들이 점차 더욱 정교해짐에 따라, 데이터 및 리소스들(예를 들면, "장치", "애플리케이션", 또는 "애플리케이션 컴포넌트")를 공유하는 것과 관련된 네트워크 상의 문제들도 증가하였다는 것을 이해할 것이다.

네트워크 내에서 리소스들을 관리하기 위한 일부 현재의 방식들은, 로컬 설치된 리소스들을 갖지 않는 하나 이상의 클라이언트들과 리소스들을 공유하는 집중화 게이트웨이 서버(centralized gateway server)를 포함할 수 있는 집중화 컴퓨팅 시나리오들을 포함한다. 그러한 한 예는 클라이언트 컴퓨터 시스템이 게이트웨이 서버나 로컬 인트라넷에 로그인하거나, 또는 네트워크 방화벽(network firewall)을 통해 로그인하는 것을 허용하는 집중화 게이트웨이 서버를 포함한다. 그 후, 클라이언트 컴퓨터는 보안 접속을 이용하여 방화벽을 통해 관심 데이터 및 리소스들에 액세스할 수 있다.

방화벽의 일 예에서, 클라이언트 컴퓨터 시스템은 "VPN"(Virtual Private Network), "RAS"(Remote Access Server), 또는 다른 관련된 유형의 방화벽 횡단(firewall traversal) 접속을 이용하여 클라이언트 컴퓨터 시스템에서의 네트워크층으로부터 서버 컴퓨터 시스템에서의 대응하는 네트워크층으로 방화벽을 통해 터널링할 수 있다. 이와 같은 터널링 방화벽 횡단 접속은 일반적으로, 게이트웨이 서버에서의 인증을 위해, 클라이언트가 "SSL"(Secure Socket layer) 또는 "TLS"(Transport Layer Security) 암호화 메커니즘들을 이용하여 암호화된 정보를 교환하는 HTTP 메커니즘인 보안 하이퍼텍스트 전송 프로토콜("HTTPS")을 이용하는 것을 포함한다. 게이트웨이 서버가 방화벽 통과를 허용한 후, 클라이언트 컴퓨터 시스템은, 예를 들면 소정의 리소스와 상호 작용하기 위한 하나 이상의 소켓들을 이용함으로써, 방화벽 뒤의 리소스들 모두를 액세스할 수 있다.

클라이언트에서의 애플리케이션층과 서버에서의 애플리케이션층을 접속하는 것과 같은 다른 방화벽 횡단 솔루션에서, 클라이언트는 또한 관심 리소스와 연관된 프로토콜 프로세서를 콜아웃(call-out)할 필요가 있을 수 있다. 이 경우의 프로토콜 프로세서는 본질적으로는, RPC/HTTPS 통신 스택으로의 플러그인(즉, "프로토콜 프로세서 플러그인")으로서 통상적으로 제3자 개발자에 의해 설계되기도 하는 "API"(Application Program Interface)이다. 특정 종류의 리소스나 애플리케이션 프로그램과의 통신을 위해 구성되는 것 이외에, 프로토콜 프로세서 플러그인은 또한 소정의 리소스(또는 "애플리케이션")를 이용하기 위한 특정 네트워크 정책들을 포함하도록 설계되는 것이 통상적이다. 따라서, 로그인하고, 프로토콜 프로세서 플러그인에 의해 요구되는 어떤 요구된 레벨들의 인증을 통과하고 나서야, 클라이언트 컴퓨터 시스템은 서버 컴퓨터 시스템에서의 요청된 리소스와 정보를 교환할 수 있다. 예를 들어, 클라이언트는 마우스 및 키보드 이벤트들을 송신할 수 있으며, 이들은 그 후 적절한 리소스에 중계된다. 리소스는 그 후 그 이벤트들을 처리하고, 이 처리의 결과들을 로컬 디스플레이를 위해 클라이언트에 리턴한다.

불행하게도, 이들 다양한 유형들의 횡단 솔루션들로 인해 가능하게 되는 편리함들 중 일부에도 불구하고, 제3자 개발자의 관점에서 이 유형들의 통신을 구현하기 어렵게 만들 수 있는 많은 비효율적인 것들이 있을 수 있다. 예를 들면, 애플리케이션층들이 아닌, 네트워크층들 간의 네트워크 접속을 이용하는 경우, 클라이언트는 로컬 네트워크 동작들을 효과적으로 불능으로 할 수 있다. 예를 들어, 네트워크층들 간에 이루어진 접속 터널은 다른 유형들의 네트워크 접속들을 이용하면 이용 가능하게 될 네트워크 리소스들의 어떤 유형들을 불능으로 할 수 있어, 예를 들면, 클라이언트는 로컬 영역 네트워크 프린터, 로컬 네트워크 가능 음악 또는 비디오 스트리밍 장치, 등에 액세스 불능으로 될 수 있다.

다른 문제는, 모든 인터넷 트래픽이 클라이언트 컴퓨터 시스템이 접속되는 서버 컴퓨터 시스템을 통해 지향된다는 것이다. 따라서, 클라이언트가 VPN을 이용하여 회사 방화벽에 접속되어 있고, 클라이언트가 외부 뉴스 기초 웹사이트를 요청한다면, 뉴스 기초 웹사이트는 클라이언트 컴퓨터 시스템으로 연결되기 전에 회사 방화벽을 통과할 것이다. 또 다른 문제는, 복합 또는 상태기반(stateful) 프로토 콜들에 대해서는 실시하기 어려운 것이 보통인 패킷 검사 및 필터링만을 행할 수 있다는 것이다.

대안적으로는, 애플리케이션층 유형의 접속에 관한 문제는, 높은 레벨에서 서버 게이트웨이를 통과하는 애플리케이션 프로토콜을 제어할 수 있는 프로토콜 프로세서 플러그인들을 제3자 개발자들이 개발하는 것이 어려울 수 있다는 개념을 포함한다. 특히, 애플리케이션층 접속이 클라이언트가 다른 네트워크들에 동시에 접속하는 것을 허용할 수 있는 한편 - 각각의 접속은 네트워크 ID(identity)가 아닌 애플리케이션 신원에 기초하기 때문 -, 이러한 종류의 통합(integration)은 개발자(들)가 클라이언트가 액세스할 수 있기를 바라는 각각의 개별 리소스 또는 애플리케이션마다 상이한 프로토콜 프로세서 플러그인을 개발자가 생성할 필요도 있을 것이라는 것을 의미할 수 있다. 이것은 각각의 상이한 프로토콜 프로세서가 또한 추가적인 고유 액세스 정책들을 포함할 필요가 있을 수 있으므로 또 다른 문제들을 발생시킬 수 있다. 그러한 액세스 정책들은, 예를 들면, 어떻게, 언제, 사용자, 또는 심지어 한 클래스의 사용자들이 특정 리소스에 로그인(또는 액세스)하도록 허용되어야 하는지, 또는 그러한 허용의 여부를 포함할 수 있다.

따라서, 예를 들면, 애플리케이션층 접속들을 구현하고 있는 개발자는, 게이트웨이 서버에 대하여 한 종류의 액세스 정책을 구현하고 "RDP"(Remote Desktop Protocol)를 이용하는 한 프로토콜 프로세서 플러그인을 작성하는 것과 동시에, 게이트웨이 서버에서 또 다른 액세스 정책들을 구현하고 "SMB"(Server Message Block) 프로토콜을 이용하는 다른 프로토콜 프로세서 플러그인을 작성할 수 있다. 잠재적으로 고유한 액세스 정책들을 갖는 것 이외에, 각각의 프로토콜 프로세서는 또한, 다른 다양한 관리 및 진단 툴들을 위하여 이용되는 별도의 고유 스크립트들을 가질 수 있다. 따라서, 개발자들이 방화벽을 통해 액세스 가능하게 되기를 원하는 상이한 관심 리소스들의 각각에 대하여 일일이 상이한 플러그인들, 네트워크 정책들, 및 관련된 진단 스크립트들을 지속적으로 작성해나가는 것은 흔한 일일 것이다.

이것은 특히 서버 및/또는 리소스가 그 수명 동안 경험할 수 있는 다양한 코드 버전들을 고려하는 경우에, 개발자들 및 네트워크 관리자들에게 비슷하게 상당히 복잡한 일이 될 수 있다. 예를 들면, 클라이언트 컴퓨터 시스템이 서버와의 통신 이전에, 통신이 인터셉트되지 않거나 소정의 다른 방식으로 손상되기 쉬워지지 않을 것을 보장할 수 있는 특정 리소스나 애플리케이션 특징들을 설치하지 않았을 경우가 있다. 그러나, 현재의 보안 인증 프로토콜들 및 프로토콜 프로세서 플러그인들은 이러한 종류의 제한들을 고려하지 않는 것이 정상이다. 오히려, 이 문제들은 접속된 리소스에 의해 나중에 처리될 수 있으며, 이는 통신 에러들, 및 드롭되거나 인터셉트된 접속들을 야기시킬 수 있고, 심지어는 최악의 경우 게이트웨이 서버를 손상시킬 수 있다. 특히, 현재의 액세스 정책 제어들은 네트워크 및/또는 리소스 관리자들에게 입도성 제어(granular control)를 쉽게 제공하지 못한다.

따라서, 현재의 클라이언트/서버 통신들에는, 취급될 수 있는 많은 비효율적인 면들이 있다.

발명의 개요

본 발명의 실시예들은 개발자들이 용이하게 클라이언트/서버 애플리케이션 접속들을 제공할 수 있는 표준화된 플랫폼을 제공하도록 구성된 시스템들, 방법들, 및 컴퓨터 프로그램 제품들과 관련된 업계의 하나 이상의 문제들을 해결한다. 특히, 본 발명의 일 실시예는 방화벽을 통하여 통신 스택의 애플리케이션 레벨에서 원격 클라이언트 및 임의의 서버 리소스를 효율적이고 확실하게 접속하도록 구성된 보안 통신 프레임워크를 포함한다. 통신 프레임워크는 개발자에 의해 반드시 독립적으로 개발되어야 하는 것은 아닌 각종 적절한 액세스 정책들을 고려하여 접속을 조성할 수 있다. 또한, 통신 프레임워크는 클라이언트가 최소의 소프트웨어 패치를 설치하지 않고서는 리소스에 접속하지 않을 것을 확실히 하기 위하여 이용될 수 있는 어떤 검역 기능들(qurantine functions)을 더 포함할 수 있다.

예를 들면, 통신 프레임워크 내에 적어도 원격 프로시저 호출층 및 보안 하이퍼텍스트 전송 프로토콜층을 갖는 게이트웨이 서버에서, 본 발명의 일 실시예에 따른 방법은 클라이언트로부터의 접속 요청을 수신하는 단계를 포함할 수 있다. 일반적으로, 접속 요청은 클라이언트가 접속하기를 원하는 리소스를 식별할 수 있다. 상기 방법은 또한 클라이언트가 최소의 특징 세트를 지원하는지 여부를 판정하기 위하여 클라이언트와의 접속을 검역(quarantining)하는 단계를 포함할 수 있다. 또한, 상기 방법은 식별된 리소스의 리소스 유형에 기초하여 프로토콜 프로세서 플러그인을 식별하는 단계, 및 식별된 프로토콜 프로세서 플러그인에 클라이언트와의 접속을 포워딩하는 단계를 포함할 수 있다.

또한, 클라이언트가 게이트웨이 서버 방화벽을 통해 리소스를 액세스하는 클라이언트 컴퓨터 시스템에서, 본 발명의 일 실시예에 따른 방법은 게이트웨이 서버에서의 접속을 위한 요청을 송신하는 것을 포함할 수 있다. 일반적으로, 상기 요청은 대응 클라이언트 리소스와 접속할 서버 리소스를 식별할 수 있다. 상기 방법은 또한 클라이언트 리소스에서 이용 가능한 최소 특징 세트에 대한 요청을 게이트웨이 서버로부터 수신하는 것을 포함할 수 있다. 또한, 상기 방법은 버전 응답을 게이트웨이 서버에 송신하는 것을 포함할 수 있으며, 여기에서 응답은 클라이언트에서 지원된 특징들의 세트를 나타낸다. 더욱이, 클라이언트 관점으로부터의 방법은 게이트웨이 서버에서의 통신 스택의 애플리케이션층에 접속하는 것을 포함할 수 있다. 이와 같이, 클라이언트 리소스는 서버 리소스와 연관된 프로토콜 프로세서 플러그인과 데이터를 통신할 수 있다.

이 개요는 이하에서 상세한 설명부에 보다 상세히 설명되어 있는 간략한 형태의 개념들의 선택을 도입하기 위하여 제공된다. 이 개요는 청구된 본 발명의 주제의 주요 특징들 또는 본질적인 특징들을 식별하기 위한 것이 아니며, 청구된 본 발명의 주제의 범위를 결정하는 것을 보조하기 위해 이용되는 것도 아니다.

본 발명의 추가의 특징들 및 장점들은 후속하는 설명부에서 설명될 것이고, 부분적으로는 설명부로부터 자명할 것이거나, 본 발명의 실시에 의해 학습될 수 있다. 본 발명의 특징들 및 장점들은 첨부된 청구범위에서 특별히 지적된 수단들 및 조합들에 의하여 구현 및 획득될 수 있다. 본 발명의 이러한 및 다른 특징들은 이하의 상세한 설명부 및 첨부된 청구범위들로부터 더욱 자명해질 것이거나, 이후에 설명된 바와 같이 본 발명의 실시에 의해 학습될 수 있다.

본 발명의 상기 및 다른 장점들 및 특징들이 획득될 수 있는 방식을 기술하기 위하여, 간략히 전술된 본 발명의 더욱 특별한 설명이 첨부도면들에 예시되어 있는 특정 실시예들을 참조하여 이루어질 것이다. 이 도면들은 본 발명의 전형적인 실시예들만 설명하고 따라서 그 범위를 제한하는 것으로 간주되지 않는다는 것을 이해하면서, 본 발명은 첨부도면들을 이용하여 추가적인 특수성 및 세부성을 갖고 설명될 것이다.

도 1a는 클라이언트 컴퓨터 시스템이 본 발명의 일 실시예에 따라 방화벽을 통과하기 위하여 게이트웨이 서버 통신 프레임워크와 통신하는 시스템의 개략도를 도시한다.

도 1b는 클라이언트 컴퓨터 시스템이 본 발명의 일 실시예에 따라 특정 리소스와 통신하는, 도 1a에 도시된 시스템의 개략도를 도시한다.

도 2는 방화벽을 통과하고, 통신 프레임워크에 의해 제공된 네트워크 정책들에 따라 특정 리소스와 통신하기 위한 클라이언트 시스템 및 게이트웨이 서버 관점으로부터의 방법들의 흐름도들을 도시한다.

본 발명의 실시예들은 개발자들이 클라이언트/서버 애플리케이션 접속들을 제공할 수 있는 표준화된 플랫폼을 제공하도록 구성된 시스템들, 방법들, 및 컴퓨터 프로그램 제품들에 이른다. 특히, 본 발명의 일 실시예는 방화벽을 통하여 통 신 스택의 애플리케이션 레벨에서 임의의 서버 리소스와 원격 클라이언트를 효율적으로 보안 접속하도록 구성된 보안 통신 프레임워크를 포함한다. 통신 프레임워크는 반드시 개발자에 의해 독립적으로 개발될 필요는 없는 각종의 적절한 액세스 정책들을 고려하여 접속을 조성할 수 있다. 또한, 통신 프레임워크는 클라이언트가 최소 소프트웨어 패치를 설치하지 않고서는 리소스에 접속하지 않을 것을 확실하게 하기 위하여 이용될 수 있는 특정의 검역 기능들을 더 포함할 수 있다.

이들 및 다른 특징의 결과로서, 본 발명의 양태들에 따른 통신 프레임워크는 점대점(point-to-point) 애플리케이션 프로토콜들을 확장하고, 그로 인하여 게이트웨이들에 영향을 주는 능력을 간략화한다. 예를 들어, 본 발명의 양태들은, 어떤 리소스들이 어떻게, 언제, 및 누구에 의해 액세스될 수 있는지에 대한 특정의 관리를 제공할 수 있는 게이트웨이 서버에서의 애플리케이션 인식 프로토콜 프로세서 플러그인들에 대한 클라이언트 노출을 고려한다. 액세스 정책의 대부분이 통신 프레임워크에 포함되어 있으므로, 입도성 구성(granular configuration) 및 통과 정책들은 프로토콜 프로세서 플러그인 개발자에 의해 쉽게 구현될 수 있고, 프로토콜 프로세서 플러그인들의 개발을 더 간단하고 더 효율적으로 되게 할 수 있다. 더욱이, 본 발명의 양태들에 따른 통신 프레임워크는 어떤 특징들을 지원하는 클라이언트들만 우선 게이트웨이 서버 방화벽을 통하여 터널링할 수 있고, 결국은 리소스로의 채널을 설정할 수 있을 것을 보장한다.

예비적인 사항으로서, 여기에 기술된 구조들 및 흐름도들은 본 발명의 양태들에 따라 이용될 수 있는 다수의 "API"(Applicaiton Program Interfaces)를 참조 한다. 클라이언트 측 및 게이트웨이 서버 측으로부터의 통신 프레임워크와 함께 사용될 수 있는 API들의 수는 임의의 실시예에 따라 변화할 수 있다. 예를 들어, 일 실시예에서는, 적어도 2 개의 클라이언트 API들, 및 적어도 4 개의 게이트웨이 서버 API들이 존재할 수 있다.

클라이언트 측으로부터, 예를 들면, 하나의 클라이언트 API는 클라이언트 프로토콜 프로세서 플러그인들이 터널들을 생성 및 찾게 하고, 채널들을 생성하며, 리소스 서버들에 트래픽을 송신하게 하는 "코어 API"를 포함할 수 있다. 코어 API는 또한 리소스 액세스 정책들에 따라 비디폴트 크리덴셜들(non-default credentials)을 수집하기 위한 추가의 API들을 포함할 수 있다. 제2 클라이언트 API는 "구성(configuration) API"를 포함할 수 있다. 구성 API는 클라이언트 프로토콜 프로세서 플러그인들이 게이트웨이 서버들(예를 들면, 게이트웨이 서버명, 허가 유형, 등)로의 접속을 위한 구성 정보를 저장 및 로드하게 하고 클라이언트 어댑터 단계를 제어하게 할 수 있다.

서버 측으로부터, 하나의 게이트웨이 서버 API는 또한, 게이트웨이 서버 프로토콜 프로세서 플러그인들로 하여금, 채널들을 생성하고 트래픽을 클라이언트로부터 게이트웨어 서버로 또는 그 역으로 포워딩하기 위한 클라이언트 요청을 서비스하도록 해주는 "코어 API"를 포함할 수 있다. 제2 API, 즉 "구성 API"는 서버 프로토콜 지속 데이터를 위한 공통 저장소를 제공할 수 있다. 제3 API, 즉 "정책 API"는, 사용자가 채널 생성 동안 특정한 리소스 서버에 접속하는 것이 허가되어 있는지 여부를 판정하기 위하여 게이트웨이 서버 프로토콜 프로세서 플러그인들이 사용할 수 있는 네트워크 및 리소스 액세스 정책들로의 인터페이스를 제공할 수 있다. 제4 API, 즉 "런타임 상태 및 제어(runtime status and control) API"는 에지 상의 관리 툴들이 사용(usage)을 모니터링하고, 부정한 사용자들에 속하는 터널들을 셧다운하는 것과 같이, 런타임 상태를 변경시키도록 할 수 있다.

이들은 본 발명의 일반적인 원리들에 따라 사용될 수 있는 API들의 특정한 유형들의 예들이다. 이 API들의 기능들은 이하의 도면들에서의 일반적인 참조로 설명된다. 예를 들면, 도 1a는 클라이언트 컴퓨터 시스템(100)이 게이트웨이 서버(150)에서 방화벽 뒤에 위치된 특정 리소스(예를 들면, 애플리케이션 또는 관련된 컴포넌트)와 통신을 시도하는 본 발명의 일 실시예의 개략도를 도시한다. 이러한 통신의 발생을 위하여, 클라이언트(100) 및 게이트웨이 서버(150)는, 통신 프레임워크(107)의 컨텍스트 내에서 통신 및/또는 동작할 수 있는 (즉, 프레임워크로 "플러그인"할 수 있는) API들(예를 들면, 위에서 언급한 것들)의 세트를 포함하는 유사하게 구성된 프로토콜 프로세서 플러그인(예를 들면, 115a-b)을 결국 이용할 것이다.

이하의 설명부 및 청구범위로부터 더욱 완전히 이해되는 바와 같이, 통신 프레임워크(107)는 각종 컴포넌트들, 프로세싱 모듈들, 툴들, 인덱스들, 등을 포함하는 특징이 풍부한(feature-rich) 데이터 구조(예를 들면, 4개의 전술된 API들 포함)이다. 일반적으로, 통신 프레임워크(107)는, 통신 프레임워크(107)와 인터페이스하고, 통신 프레임워크(107)에 제공된 특징들 및 정책들을 따로 개발 또는 작성할 필요없이 이들을 이용하는 프로토콜 프로세서 플러그인(예를 들면, 115a-b, 117)을 개발자가 쉽게 설계할 수 있도록 설계 및/또는 구성된다.

특히, 도 1a는 통신 프레임워크(107)가, 게이트웨이 서버(150)에서의 각종 소프트웨어 컴포넌트들과 네트워크(135)에서의 물리적 경계 사이의 인터페이싱을 위해 이용되는 통신 스택(113)을 포함하는 것을 도시한다. 일반적으로, 게이트웨이 서버(150)는 모든 인바운드 및 아웃바운드 인터넷 트래픽을 통과시키는 대형 조직의 방화벽 뒤의(fire-walled) 인터넷 서버와 같은 임의의 네트워크 에지 서버를 포함할 수 있다. 예를 들면, 홈 오피스 위치로부터 오피스 위치의 리소스에 연결하기를 원하는 조직 내의 작업자는 방화벽 뒤의 리소스에 액세스하기 전에 게이트웨이 서버(150)를 통해 접속할 것이다.

이와 같이, 통신 프레임워크(107)는 특정 리소스에 액세스하기 위하여 이용될 수 있는, 방화벽 뒤의 리소스들과의 인터페이싱을 위한 임의의 수의 컴포넌트들 및 모듈들을 포함할 수 있다. 예를 들면, 도 1a는 통신 프레임워크(107)에서의 통신 스택(113)의 일 실시예가 "HTTPS(secure Hyper Transfer Protocol)" 층(105b)뿐만 아니라, 플러거블(pluggable) 전송층(110b)을 포함하는 것을 도시한다. 일 실시예에서, 플러거블 전송층(110b)(및 층(110a))은 "RPC(Remote Procedure Call)" 층(110b)이어서, 층(105a-b) 및 층(110a-b)은 또한 함께 "HTTPS/RPC"로 호칭될 수 있다. 이와 같이 사용되는 경우, HTTPS층(105b)은 임의의 SSL 또는 TLS 암호화/인코딩을 해독 또는 디코드하는 한편, 플러거블 전송층(110b)은 클라이언트(100)에서의 대응하는 플러거블 층(110a)에서 만들어진 임의의 랩핑(wraping)(예를 들면, RPC)을 언팩한다.

물론, 통신 스택(113)에는 임의의 수의 추가적인 또는 대안적인 층들이 포함될 수 있는데, 이들은 전형적인 7층 "OSI(Operating System Interconnect)" 모델의 일부이거나 상호 관련될 수 있다. 예를 들어, HTTPS/플러거블 전송층(105b/110b)은 이 실시예에서는 층들의 최소 세트로서 간략하게 도시되지만, 이것이 본 발명의 양태들을 달성하는 유일한 방법은 아니다. 다른 실시예에서, 예를 들면, 개발자는 HTTPS를 생략하고, 또한 보안 접속을 통하여 클라이언트와 게이트웨이 애플리케이션 층들을 연결하는 SSL 및/또는 "TCP(Transmission Control Protocol)" 솔루션에 기초한 다른 접속 메커니즘을 이용할 수 있다. 따라서, HTTPS/플러거블 전송, 특히 HTTPS/RPC 세트가 방화벽 횡단 솔루션 엘리먼트들을 제공하는 가능한 방법 중의 하나에 지나지 않는다.

특히, HTTPS 및 RPC와 같은 플러거블 전송층의 한 가지 장점은, RPC와 같은 일부 프로토콜들은 HTTP의 이전 버전들(예를 들면, HTTP 버전 1.0)과 역호환 가능(backwards compatible)하다는 것이다. 따라서, HTTPS/RPC 세트를 이용하는 개발자는 방화벽 횡단 솔루션의 이 엘리먼트가 더 오래된 서버들, 또는 트래픽의 더욱 통상적인 HTTP 유형으로 트래픽의 유형들을 제한하는 서버들에서 더욱 쉽게 채용될 수 있는 것을 발견할 수 있다.

어쨌든, 도 1a는 또한 "횡단 API(traversal Application Interface)"(160)가 스택(113)의 HTTPS/플러거블 전송 번들의 최상부에 층을 이루는 것을 도시한다. 횡단 API(160)는 클라이언트(100)와 적절한 프로토콜 프로세서 플러그인 간의 적절한 접속을 생성하고, 접속 내에 적절한 네트워크 정책들이 구현되는 것을 확실히 하기 위한 임의의 수의 컴포넌트들 및 모듈들(예를 들면, 전술된 "코어 API", "구성 API", 정책 API", 및/또는 "런타임 상태 및 제어 API" 중 하나 이상)을 포함할 수 있다. 예를 들면, 횡단 API(160)는 액세스 정책 컴포넌트(170)(예를 들면, "정책 API"), 및 관리 툴 컴포넌트(175)(예를 들면, "구성 API", 및/또는 "런타임 상태 및 제어 API")를 포함하며, 이들은 더욱 상세하게 후술된 다수의 기능들을 위하여 참조될 수 있다. 그러나, 더욱 일반적으로, 횡단 API(160)는 특정의 리소스와의 통신을 위하여 이용되는 하나 이상의 프로토콜 프로세서 플러그인들과 통신 스택(113) 내의 HTTPS/플러거블 전송 번들 간의 심(shim)으로서 기능할 수 있다.

예를 들어, 도 1a는 게이트웨이 서버(150) 또한 적어도 프로토콜 프로세서 플러그인들(115b 및 117)을 포함하는 것을 도시한다. 일반적으로, 프로토콜 프로세서 플러그 인은 제3 개발자에 의해 개발된 인터페이스인데, 이는 한 편으로는 통신 프레임워크(107)의 범위 내에서 상호작용할 수 있고, 다른 한 편으로는 통신 프레임워크(107)를 통하여 수신된 데이터를 특정 리소스에 전달한다. 또한, 프로토콜 프로세서 플러그인은 리소스, 또는 리소스들의 클래스에 관련된 플러그인의 "유형"에 관하여 정의될 수 있다. 예를 들면, 통상의 인터페이스를 통하여 상호작용하는 오피스 애플리케이션들의 세트는 한 유형의 애플리케이션을 구성할 수 있는 한편, 상이한 인터페이스를 통하여 상호작용하는 데이터 베이스 프로그램은 상이한 유형의 애플리케이션 또는 리소스를 구성할 수 있다. 또한, 프린터들 또는 디스크 드라이브들과 같은 하드웨어는 통신을 위한 다른 유형의 인터페이스들을 갖는 또 다른 리소스들을 구성할 수 있다. 이와 같이, 리소스를 제공하는 개발자는 또한 그 주어진 리소스에 대한 고유의 프로토콜 프로세서 플러그 인도 작성할 수 있다.

그러나, 개발자는 또한, 클라이언트가 요청된 리소스와 통신할 수 있도록, 클라이언트에 대하여 대응하는 프로토콜 프로세서 플러그 인을 제공할 필요가 있을 것이다. 따라서, 예를 들면, 도 1a는 또한 클라이언트(100)가 HTTPS 층(105a) 및 플러거블 전송층(110a)을 마찬가지로 포함하는 통신 스택(103)을 갖는 것을 도시한다. 일반적으로, 플러거블 전송층(110a)은 적절한 프로토콜(예를 들면, RPC 층을 이용하는 경우 RPC 프로토콜)에 따라 임의의 아웃고잉 메시지들(예를 들면, 130)을 랩핑하기 위하여 이용되는 한편, HTTPS 층(105a)은, 예를 들면 SSL 또는 TLS 암호화 또는 인코딩을 이용하여 아웃고잉 메시지들을 암호화 또는 인코드하기 위하여 이용된다. 클라이언트의 HTTPS/플러거블 전송 번들의 상부에 층을 이루는 것은 프로토콜 프로세서 플러그인(115a)이다.

일반적으로, 프로토콜 프로세서 플러그인(115a)은 접속 터널, 및 게이트웨이 서버(150)에서의 적절한 리소스와 대응하는 채널(터널 내부의)을 생성하기 위해 필요한 임의의 인터페이스들(예를 들면, "코어 API", 및/또는 "구성 API"), 리소스들 또는 컴포넌트들을 포함한다. 따라서, 프로토콜 프로세서 플러그인(115a)은 적어도 프로토콜 프로세서 플러그인(115b)과 상보적이다. 예를 들면, 도 1a는 프로토콜 프로세서 플러그인(115a)이 클라이언트(100)가 로컬 사용중인 리소스(즉, 리소스(120a))의 유형에 대응하는 어떤 유형(즉, "유형 A")을 가지고 있고, 따라서, 동일한 호출들, 인코딩, 등을 이용하여 상보적인 프로토콜 프로세서 플러그인과 통신할 수 있는 것을 도시한다.

이러한 방침들을 따라서, 도 1a는 통신 스택(103)이 리소스(120a)(예를 들면, 애플리케이션 프로그램, 컴포넌트, 또는 심지어는 다른 API)를 포함하는 것을 추가로 도시한다. 예를 들어, 클라이언트는 게이트웨이 서버(150)에서의 방화벽 뒤에 위치된 데이터베이스의 작업 버전과 동기하는 로컬 컴퓨터 시스템 상의 데이터베이스 애플리케이션을 오픈업한다. 어떤 경우들에서는, 리소스(120a)가 애플리케이션의 완전한 버전일 수 있지만, 리소스(120a)는 단순히 게이트웨이 서버(150)로부터 스트림된 데이터가 어떤 방식으로 디스플레이되도록 해주는 애플리케이션의 소프트웨어 컴포넌트일 수도 있다. 따라서, 이 경우, 리소스(120a)와 같은 컴포넌트들은 클라이언트(100)가 게이트웨이 서버(150)의 리소스와 직접 접속하는 것을 가능하게 하는 리소스들의 최소 세트를 제공한다.

예를 들어, 도 1a는 클라이언트(100)가 리소스(120a)를 이용하여 리소스(120b)와의 접속을 요청(130)하는 것을 도시한다. 그렇게 하기 위하여, 클라이언트(100)는, 원하는 리소스(즉, 리소스(120a))에 대하여 적절한 유형(즉, "유형 A")인 적절한 프로토콜 프로세서 플러그인(즉, 115a)을 갖는 통신 스택(103)을 개시한다. 그 후 클라이언트(100)는 통신 스택(103)을 통해 게이트웨이 서버(150)에 접속 요청 메시지(130)를 송신한다. 특히, 프로토콜 프로세서 플러그인(115a)은 인증 정보(예를 들면, 사용자명 및 패스워드, 클라이언트 ID(identification), 디지털 서명들), 리소스(120b)에 대한 특정한 호출, 및 횡단 API(160)에서 요청될 수 있는 임의의 네트워크 정책 정보를 갖는 아웃고잉 메시지(130)를 준비한다. 프로토콜 프로세서 플러그인(115a)은 그 후 플러거블 전송층(110a)에서 패키지되고, HTTPS 층(105)(즉, TLS 또는 SSL을 경유하여)에서 암호화되며, 그 후 네트워크(135)를 통해 송신될 메시지(130)를 송신한다.

통신 프레임워크(107)는 그 후 메시지(130)를 수신하고, 초기 언팩 및 해독하는 기능들을 수행한다. 예를 들어, HTTPS 층(105b)은 임의의 SSL 또는 TLS 인코딩을 해독하고, 플러거블 전송층(110b)은 임의의 적절한 인코딩(예를 들면, RPC 인코딩)으로부터 메시지를 언팩한다. 횡단 API(160)는 그 후 메시지(130) 내의 인증 정보를 조사하고, 상당한 입도의 액세스 정책들에 기초하여, 클라이언트(100)가 요청된 접속에 대하여 허가되어 있는지 여부를 판정할 수 있다. 특히 일 실시예에서, 액세스 정책의 입도성(granularity)은, 액세스 정책들을 적어도 두 개의 독립된 세트들, 즉 우선 클라이언트가 서버(150)에 대하여 네트워크 접속을 하는 것이 허가되어 있는지 여부를 판정하기 위한 네트워크 액세스 정책; 및 클라이언트가 접속 터널을 생성하는 것이 허용되어 있더라도, 요청된 리소스와 접속 채널을 가지는 것도 허가되어 있는지 여부를 판정하기 위한 리소스 액세스 정책으로 구별하는 것에 기초한다. 이러한 액세스 정책(네트워크 또는 리소스) 허가는, 예를 들면, 통상적인 사용자명들 및 패스워드들을 인증하는 것, "클라이언트 헬스"를 식별하는 것, 등(예를 들면, 더욱 상세히 후술되는 검역 특징)과 같이, 네트워크 및/또는 애플리케이션/리소스 관리자가 원하는 임의의 수의 고려사항들에 기초하도록 구성될 수 있다.

네트워크 액세스 정책들의 일부 예들은 클라이언트(100)에서의 사용자가 요청된 리소스와 연관된 허가 그룹의 일부인지 여부에 대한 제한들을 포함한다. 네 트워크 액세스 정책들의 세트는 또한, 특정의 서버 접속들을 마케팅 부서 내의 한 그룹으로만 제한하거나, 일반적인 서버 접속 터널들의 수를 어떤 최대의 수로 제한하거나, 방화벽 뒤의 어떤 서버로의 액세스를 제한하고(하루의 횟수, 특정 사용자들, 등으로), 또는 액세스를 주어진 서버 상의 특정한 포트들로만 제한하도록 구성될 수 있다. 클라이언트가 서버(150)에 접속하기 전에 "스마트카드"를 제시할 것을 요구하도록 또 다른 네트워크 액세스 정책들이 구성될 수도 있다.

유사한 방침들을 따라서, 리소스 액세스 정책들의 세트는, 하나의 리소스로의 접속 채널들의 수를 제한하고(사용자가 이미 방화벽을 통하여 서버에 접속되었어도), 일반적으로 모든 리소스들을 제한하고/거나 심지어 리소스들 및/또는 접속들을 하루 중 어느 시간 동안만 사용자들의 특정 그룹들로 제한하도록 구성될 수 있다. 적어도 부분적으로는 네트워크 액세스 정책들 및 리소스 액세스 정책들이 개별화된 기준에 따라 독립적으로 구성될 수 있으므로, 액세스 정책 컴포넌트(170)는 네트워크 및/또는 리소스 관리자에게 게이트웨이 서버(150)에서의 인증 및 액세스 여과(access filtration)에 대한 훨씬 더 입도성이 좋은 제어를 제공할 수 있다.

특히, 두 정책 클래스들(즉, 리소스 액세스 정책들 및 네트워크 액세스 정책들)은, 네트워크 및/또는 애플리케이션/리소스 관리자(들)이, 특히 그들 간의 액세스 레벨들의 특정 세트에 동의하는 경우, 그들의 정책을 매우 독립적으로 규정 및 전개하도록 해주는 "액세스의 레벨들(levels-of-access)"을 통하여 링크될 수 있다. 예를 들면, 사용자는 특정한 사용자명 및 패스워드를 제공하는 경우 하루의 어떤 시간에 리소스들의 하나의 세트를 액세스할 수 있지만, 또한 스마트카드를 제시하지 않고는 하루의 다른 시간에 리소스들의 동일한 세트를 액세스할 수 없다. 유사하게, 사용자는, 사용자가 임의의 형태의 인증을 제시하는지 여부와 무관하게, 하루의 다른 시간, 또는 아마도 주말 시간 동안에, 중복되지 않는(non-overlapping) 리소스들의 다른 세트를 액세스할 수 있다.

또한, 서버에서의 접속 터널들의 최대 수에 대한 특정한 제한을 가지는 하루의 어떤 시간 동안 사용자가 서버(150)에 액세스하는 것을 완전히 차단하거나; 또는 특정한 시간 동안 하나의 내부 서버 뒤의 리소스의 한 버전에 접속하지만 다른 서버에 호스트된 동일 리소스의 다른 버전에는 접속하지 않도록 하기 위한 네트워크 및 리소스 액세스 정책들의 조합이 이용될 수 있다. 물론, 액세스 정책 컴포넌트(170)의 네트워크 및 리소스 액세스 정책들 내의 독립적인 기준에 의해 제공된 제어의 이 입도성 레벨은 단순히 기저 레벨로부터 더욱 관리형 레벨로 사용자의 액세스 레벨을 변경시킴으로써 더욱 수정될 수 있다.

여하튼, 도 1a는 또한 통신 프레임워크(107)는, 예를 들면 통신 프레임워크(107)가 통신하도록 구성된 임의의 수의 하나 이상의 특징들을 요청하는 메시지(140)로 응답하는 것을 도시한다. 특히, 본 발명의 실시예들은, 전술된 바와 같이, 리소스들 또는 특징들의 최소의 세트(예를 들면, 특정 리소스 버전들, 프로토콜들 또는 컴포넌트들의 세트들, 소프트웨어 패치들, 등)를 갖는 클라이언트들만이 주어진 서버 리소스에 접속하는 것이 허용되는 것을 통신 프레임워크(107)가 보장하는 가능성 있는 검역 특징을 네트워크 액세스 정책의 일부로서 더 포함할 수 있 다.

대안의 실시예들에서, 통신 프레임워크(107)가 클라이언트(100)에 의해 지원되지 않는 특징들을 단순히 턴오프하여, 클라이언트는 그러한 지원되지 않는 특징들과 어느 시점에 통신을 시도하지 않는다. 예를 들면, 리소스(120b)의 개발자는, 클라이언트(100)도 대응하는 리소스(들), 특징(들) 또는 특징 업데이트(들)의 최소 세트를 갖지 않는다면, 클라이언트(100)(또는 리소스 액세스 정책에 의해 식별된 사용자들의 클래스 내의 클라이언트들)에 의해 액세스(또는 사용)되지 않아야 하는 다수의 특징들 또는 특징 업데이트들을 이 리소스에 제공하였을 수 있다. 이 리소스들, 특징들 및/또는 관련된 특징 업데이트들은 기능적일 수 있지만, 보안 관련될 수도 있으므로, 개발자가 실시하는 데 중요할 수 있다. 따라서, 일 실시예에서, 통신 프레임워크(107)는, 클라이언트(100)와의 그러한 특징 협상들이 확인 또는 인증될 때까지, 요청된 접속을 단순히 검역소에 둘 수 있다.

그 후, 클라이언트(100)는, 예를 들면, 클라이언트(100)가 어느 특징을 실행중인지 또는 실행하도록 준비되어 있는 지를 검출함으로써 메시지(140)를 처리하여, 응답을 준비한다. 예를 들면, 도 1b는 클라이언트(100)가, 이와 같은 임의의 식별된 지원되는 특징들을 나타내는 메시지(145)로 응답하는 것을 도시한다. 그 후, 횡단 API(160)는 응답(145)을 액세스 정책 컴포넌트(170) 내의 정보와 비교하여, 이 클라이언트 지원된 특징들이 네트워크 접속, 또는 요청된 리소스로의 채널을 설정하기에 적합한지 여부, 또는 상이한 특징들(또는 동일 특징들의 상이한 버전들)이 필요한지 여부를 판정할 수 있다. 일 실시예에서, 게이트웨이 서버(150) 로의 접속을 위하여 상이한 특징들이 필요하다면(즉, 클라이언트(100)가 충분히 업데이트되지 않거나, 특정의 요구된 특징들을 갖지 않음), 횡단 API(160)는 단순히 접속을 드롭할 수 있거나, 에러 메시지를 송신할 수 있거나, 또는 클라이언트(100)가 특징을 다운로드할 수 있는 네트워크 위치를 가리키는 메시지를 송신할 수 있다. 다른 실시예에서, 전술된 바와 같이, 통신 프레임워크(107)는 단순히 클라이언트(100)가 또한 지원하지 않는 게이트웨이 서버(150) 특징들을 턴오프한다.

메시지(145)가 특징들의 적절한 세트를 나타내고(그러한 특징들이 요구될 수 있는 경우), 클라이언트(100)가 요청된 서버측 리소스를 액세스하는 것이 허가되어 있다면, 횡단 API(160)는 그 리소스에 대한 적절한 프로토콜 프로세서 플러그인으로 접속을 전송하기 시작할 수 있다. 예를 들어, 횡단 API(160)는, 리소스(120b)가 특정의 프로토콜 프로세서 플러그인을 요구하는지 여부, 또는 리소스(120b)가 리소스들의 더 넓은 클래스의 일부인지 여부를 판정하기 위하여 요청 중인 리소스의 "유형"을 먼저 볼 수 있다. 특히, 도 1b는 프로토콜 프로세서 플러그인(115b)이 적어도 리소스들(120b 및 123)과 연관되어 있는 한편, "유형 B" 프로세서인 프로토콜 프로세서 플러그인(117)은 적어도 리소스들(125 및 127)과 연관되는 것을 도시한다. 일반적으로, 적절한 프로토콜 프로세서 플러그 인을 판정하는 이 조치는, 각각의 프로토콜 프로세서 플러그인이 설치시 등록할 시스템 레지스트리를 리뷰함으로써 행해질 수 있다.

여하튼, 도 1b는 횡단 API(160)가, "유형 A" 프로세서이며, 요청된 리소스(120b)와 연관된 프로토콜 프로세서 플러그인(115b)을 식별하는 것을 도시한다. 그 후, 횡단 API(160)는 클라이언트(100)와 프로토콜 프로세서 플러그인(115b) 간의 채널의 제어를 핸드오프한다. 이와 같이, 클라이언트(100)에서의 프로토콜 프로세서 플러그인(115a) 및 게이트웨이 서버(150)에서의 프로토콜 프로세서 플러그인(115b)은 이제 스택들(103 및 113)의 각각의 애플리케이션층들에서 각각 접속되므로, 접속의 이 채널을 통하여 데이터를 교환(예를 들면, 155)하는 것이 가능하다. 특히, 통신 프레임워크(107)는, 특정 리소스로의 접속을 위한 터널 내의 하나 이상의 채널들이, 각각의 통신 스택들의 네트워크 층들에 의해 다루어지는 네트워크 접속이 아니라, 대응하는 클라이언트 및 게이트웨이 서버 프로토콜 프로세서 플러그인들을 이용할 수 있게 해준다.

접속 터널을 통한 이 채널들의 제어는 클라이언트(100)가, 액세스될 수 있는 임의의 추가적인 리소스들을 식별하는 것뿐만 아니라, 초기에 요청된 리소스(즉, 리소스(120b))와의 추가적인 채널들을 생성하는 것을 허용할 수 있다. 예를 들면, 클라이언트(100)는 통신 프레임(107)을 통하여 동일한 리소스와의 복수의 채널들을 접속 터널 내에 생성할 수 있고, 또한 리소스(123)와 같이, 리소스(120b)를 위한 것과 동일한 프로토콜 프로세서 플러그인과 연관된 다른 리소스들에 추가적인 채널들(뿐만 아니라 다른 터널들 및 대응하는 하나 이상의 다른 채널들)을 제공할 것을 횡단 API(160)에게 요청할 수 있다. 어떤 실시예들에서, 클라이언트(100)는 또한 다른 리소스(예를 들면 125)와의 통신에 따라 다른 프로토콜 프로세서 플러그인(예를 들면, 117)을 식별할 것을 통신 프레임워크(107)에 요청할 수도 있다. 여하튼, 접속 제어는 적어도 부분적으로는 액세스 정책 컴포넌트(170) 및/또는 관리 툴 컴 포넌트(175)(또는 "툴 컴포넌트(175)")를 통해 관리된다.

일반적으로, 툴 컴포넌트(175)는 임의의 수의 인터페이스들을 포함할 수 있다(예를 들면, "코어 API", "구성 API", "정책 API", 및/또는 "런타임 상태 및 제어 API" 중 임의의 하나 이상). 관리 툴 컴포넌트(175)는 또한, 예를 들면, 게이트웨이 서버(150)의 관리자에 의해 액세스될 수 있는 임의의 스크립트들, 데이터 테이블들, 및 관련된 기능들을 포함할 수도 있다. 예를 들면, 특정의 프로토콜 프로세서 플러그인에 대한 네트워크 정책에 영향을 미치거나, 통신 프레임워크(107)를 통한 접속들의 수를 분석하기를 원하는 네트워크 관리자는 툴 컴포넌트(175)에 의해 제공된 사용자 인터페이스(도시하지 않음)를 오픈할 수 있다.

그 후, 네트워크 관리자는 일반 인터넷 사용을 모니터하고, 런타임 상태를 변경시키고, 부정한 사용자들에 속한 임의의 터널들을 셧다운하고, 방화벽 횡단 접속들의 수를 제한하고, 그러한 접속을 이루기 위하여 사용된 암호화의 유형들을 선언할 수 있다. 네트워크 관리자는 또한 본 명세서에 걸쳐 기술된 것들과 같은 이들 및 다른 네트워크 설정들 또는 정책들 중 임의의 것을 변경시킬 수 있다. 네트워크 관리자는 또한, 어느 사용자들이 어느 유형의 리소스들에 액세스하는 것이 허용되는 지, 어느 리소스들이 이용 가능한 지, 그 리소스들이 언제 방화벽 외부에서 액세스될 수 있는 지, 및 그 사용자들에 의해 어느 서버들이 액세스될 수 있는 지를 설정하기 위하여 인터페이스를 사용할 수 있다.

프로토콜 프로세서 플러그인의 개발자는 또한 컴포넌트(175) 내의 이 툴들을 액세스할 수 있다. 특히, 개발자는 액세스를 위한 프로토콜 프로세서 플러그인을 작성하고 그 프로토콜 프로세서 플러그인에서 사용하기 위한 각종 디폴트 네트워크 정책들을 설정할 수 있다. 예를 들어, 프로토콜 프로세서 플러그인의 개발자는 관리 툴들(175) 내의 또 다른 인터페이스와 상호작용하도록 프로토콜 프로세서 플러그인을 설계하고 최소 리소스 또는 특징 요건들을 설정할 수 있다. 따라서, 도 1a-1b는 통신 프레임워크(107)와 관련하여 사용될 수 있는 다수의 컴포넌트들, 툴들, 및 개략도들을 도시하는데, 이들은 방화벽 설정 내의 리소스들에 대한 입도성이 좋고, 보안되며, 알맞은 액세스를 제공하도록 구성된다.

본 발명의 실시예들은 또한 특정한 결과를 달성하기 위한 하나 이상의 단계들을 포함하는 방법들에 관하여 기술될 수 있다. 예를 들면, 도 2는 방화벽을 통하여 특정 리소스로의 접속(예를 들면, 채널)을 생성하기 위한 클라이언트(100) 및 게이트웨이 서버(150)의 관점으로부터의 방법들의 흐름도를 도시한다. 도 2의 단계들은 이하에서 도 1a 내지 1b를 참조하여 설명된다.

특히, 도 2는 클라이언트(100)의 관점으로부터의 방법이 게이트웨이 서버에 접속 요청을 송신하는 단계(200)를 포함하는 것을 도시한다. 단계(200)는 게이트웨이 서버에서의 접속에 대한 요청을 송신하는 것을 포함하는데, 여기에서 요청은 대응 클라이언트 리소스와 접속시킬 서버 리소스를 식별한다. 예를 들면, 클라이언트(100)는 리소스(120b)에 액세스하기 위하여 프로토콜 프로세서 플러그인(115a)을 갖는 통신 스택(103)을 인스턴스화한다. 그 후, 클라이언트(100)는 인증 정보뿐만 아니라, 리소스(120b)에 액세스하기 위한 요청을 포함하는 메시지(130)를 준비하여 송신하고, 메시지(130)를 게이트웨이 서버(150)에 송신한다.

또한, 도 2는 게이트웨이 서버(150)의 관점으로부터의 방법이 리소스에 대한 클라이언트 요청을 수신하는 단계(210)를 포함하는 것을 도시한다. 단계(210)는 클라이언트 접속을 위한 클라이언트 요청을 수신하는 것을 포함하며, 여기에서 클라이언트 요청은 클라이언트가 접속을 원하는 리소스를 식별한다. 예를 들어, 게이트웨이 서버(150)는 메시지(130)를 수신한다. 그 후, 게이트웨이 서버(150)는 HTTPS층(105b)에서 메시지(130)를 디코드하고, 플러거블 전송층(110b)에서 임의의 다른 프로토콜 패키징을 언팩하며, 거기에 포함된 임의의 인증 정보를 평가한다. 네트워크 액세스 정책과 충돌하는 것과 같이, 인증 정보가 정확하지 않으면, 게이트웨이 서버(150)는 단순히 접속을 부정할 수 있다. 대안적으로, 방화벽을 통한 접속을 위한 최소의 기준(예를 들면, 적절한 사용자명 및 패스워드)을 만족시키는 것과 같이, 인증 정보가 정확하다면, 게이트웨이 서버(150)는 특징들의 특정 세트 - 또한 네트워크 또는 리소스 액세스 정책에 따라서 - 가 클라이언트(100)로부터 식별될 때까지 접속을 검역할 수 있다.

따라서, 예를 들어, 도 2는 또한 게이트웨이 서버(150)의 관점으로부터의 방법이 접속을 검역하는 단계(220)를 포함하는 것을 도시한다. 단계(220)는 클라이언트가 하나 이상의 특징들의 최소 세트를 설치하였는 지를 판정하기 위하여 클라이언트와의 접속을 검역하는 것을 포함한다. 예를 들면, 도 1a는 메시지(130) 수신시, 통신 프레임워크(107)가 하나 이상의 응답 메시지들(140)을 송신하는 것을 도시한다. 이 때 반드시 접속을 허용하는 것이 아니라, 프로토콜 프로세서 플러그인(115a)에 대한 버전과 같이, 클라이언트(100)에서 지원된 특징들, 클라이언 트(100) 및 서버(150)가 상호 지원하는 접속 특징들, 또는 결국 접속에서 이용될 수 있는 임의의 다른 리소스 컴포넌트들(120a)(또는 대응하는 특징들, 특징 업데이트들, 등)을 식별하기 위한 추가 정보를 응답 메시지(140)가 요청한다.

따라서, 도 2는 클라이언트(100)의 관점으로부터의 방법이 특징들의 최소 세트에 대한 요청을 수신하는 단계(230)를 포함하는 것을 도시한다. 단계(230)는 리소스에 대하여 클라이언트에 의해 지원되는 하나 이상의 특징들의 최소 세트에 대한 게이트웨이 서버로부터의 요청을 수신하는 것을 포함한다. 예를 들면, 클라이언트(100)는 통신 스택(103)에서 메시지(140)를 수신하고, 예를 들어, 임의의 스크립트들을 실행하거나, 서버(150)에 의해 요청된 임의의 다른 리소스들 또는 리소스 특징들을 포함하는, 요청된 특징들에 대한 임의의 시스템 레지스트리 정보를 체크함으로써, 프로토콜 프로세서 플러그인(115a)에서 메시지(140)를 처리한다. 특히, 프로토콜 프로세서 플러그인(115a)은 그 자체의 특징 정보, 또는 리소스(120a)에 대한 특징 정보, 또는 클라이언트(100)에서의 다른 소프트웨어 컴포넌트 또는 리소스(비도시)에 대한 특징 정보를 식별한다.

또한, 도 2는 클라이언트(100)의 관점으로부터의 방법은 특징 응답을 게이트웨이 서버에 송신하는 단계(240)를 포함하는 것을 도시한다. 단계(240)는 지원되는 특징 응답을 게이트웨이 서버에 송신하는 것을 포함하는데, 상기 지원되는 특징 응답은 클라이언트에 의해 지원되는 특징들을 나타낸다. 예를 들어, 도 1b는 클라이언트(100)가 응답 메시지(145)를 송신하는 것을 도시하는데, 이것은, 예를 들면, 요청된 소프트웨어 버전이 존재하는 것과 같이, 클라이언트(100)에 의하여 지원되 는 하나 이상의 특징들의 세트를 나타낸다.

도 2는 또한 게이트웨이 서버(150)의 관점으로부터의 방법이 적절한 프로토콜 프로세서 플러그인을 식별하는 단계(250)를 포함하는 것을 도시한다. 단계(250)는 식별된 리소스의 리소스 유형에 기초하여 프로토콜 프로세서 플러그인을 식별하는 것을 포함한다. 예를 들면, 횡단 API(160)는 프로토콜 프로세서 플러그인(115b)은 "유형 A" 플러그인이고, 클라이언트(100)에서의 프로토콜 프로세스(115a)에서 발견된 것과 동일 유형이며, 게이트웨이 서버(150)에서의 요청된 리소스(120b)와 연관되는 것을 식별한다.

도 2는 게이트웨이 서버(150)의 관점으로부터의 방법은 프로토콜 프로세서 플러그인으로 접속을 포워딩하는 단계(260)를 포함한다. 단계(260)는 식별된 프로토콜 프로세서 플러그인에 클라이언트와의 접속을 포워딩하는 것을 포함한다. 예를 들면, 도 1b에 도시된 바와 같이, 횡단 API(160)가 프로토콜 프로세서 플러그인(115b)이 적절하며, 클라이언트(100)에 의해 제공된 정보가 특정의 리소스 액세스 정책에 따르는 것을 식별하면, 횡단 API(160)는 요청된 접속의 제어를 프로토콜 프로세서 플러그인(115b)에 보낸다. 일반적으로, 이것은 클라이언트(100)에서의 프로토콜 프로세서(115a)와 게이트웨이 서버(150)에서의 프로토콜 프로세서 플러그인(115b) 사이에 하나의 터널 - 및 터널 내에 하나 이상의 채널들 - 을 설정하는 것을 포함할 수 있다. 클라이언트(100)에서의 프로토콜 프로세서 플러그인(115a) 및 게이트웨이 서버에서의 프로토콜 프로세서 플러그인(115b)은 그 후 이 터널 및 대응하는 하나 이상의 채널들을 통하여 네트워크 스택들(103 및 113)의 애플리케이 션층들에서 직접 통신할 수 있다.

따라서, 도 2는 또한 클라이언트(100)의 관점으로부터의 방법은 게이트웨이 서버에서의 프로토콜 프로세서 플러그인으로 접속하는 단계(270)를 포함하는 것을 도시한다. 단계(270)는 게이트웨이 서버에서의 통신 스택의 애플리케이션층으로 접속하는 것을 포함하여, 클라이언트 리소스는 서버 리소스와 연관된 프로토콜 프로세서 플러그인과 데이터를 통신한다. 예를 들면, 프로토콜 프로세서 플러그인들(115a-b)은 직접 방화벽을 통하여 통신하고 있고, 네트워크 정책에 따라 접속은 핸드오프되어 있으므로, 클라이언트(100)는 방화벽을 통하여 리소스(120b)와 통신하기에 충분한 입구만을 획득한다. 따라서, 클라이언트(100)는 방화벽 뒤의 모든 리소스들에 자유롭게 액세스하지 않는다. 그럼에도 불구하고, 전술된 바와 같이, 클라이언트(100)는 동일한 리소스, 리소스의 상이한 인스턴스들, 또는 클라이언트(100)가 통신 프레임워크(107)를 통하여 식별하는 것이 허용되는 다른 리소스들로의 추가적인 채널들 또는 접속들을 개시할 수 있다.

따라서, 전술된 방법들 및 개략도들은 통신 프레임워크(107)가 개발자들에 의해 개발된 각종 플러그인들을 이용하여 특정 리소스들에 대한 액세스를 제공할 수 있는 다수의 방법들을 제공한다. 특히, 통신 프레임워크(107)는 프로토콜 프로세서 플러그인 개발 및 실시를 간략화시키기 위하여 이용될 수 있는 다수의 액세스 정책들(네트워크 및 리소스), 툴들, 및 컴포넌트들을 제공한다. 예를 들어, 개발자는 특정 리소스 액세스 정책들을 실행하거나, 특정의 진단 툴들을 실행하기 위하여 프로토콜 프로세서 플러그인 스크립트들을 독립적으로 개발하는 것을 회피할 수 있는데, 이는 그 툴들이 이미 통신 프레임워크(107)에 포함되어 있기 때문이다. 오히려, 개발자가 임의의 주어진 리소스가 방화벽을 넘어 액세스 가능하게 되는 것을 의도한다면, 개발자는 클라이언트 및 서버에서 사용하기 위한 프로토콜 프로세서 플러그인을 개발할 필요만 있다.

유사하게, 네트워크 관리자는 많은 경우들에서 새로운 네트워크 접속 액세스 정책들을 독립적으로 작성해야 하는 것을 회피할 수 있는데, 이는 그러한 액세스 정책들이 이미 통신 프레임워크에서 발견될 수 있고, 따라서 용이하게 구성 또는 인에이블/디스에이블되기 때문이다. 따라서, 여기에 개시된 특징들은 개발자들과 네트워크 관리자들의 의무를 어느 정도 간략화시키고, 관리의 부담을 강건한 통신 프레임워크에 옮길 수 있다.

본 발명의 실시예들은 이하에 더 상세히 설명되는 바와 같이, 각종 컴퓨터 하드웨어를 포함하는 전용 또는 범용 컴퓨터를 포함할 수 있다. 특히, 본 발명의 범위 내의 실시예들은 또한 저장되어 있는 컴퓨터 실행 가능 명령어들 또는 데이터 구조들을 운반하거나 갖기 위한 컴퓨터 판독 가능 매체를 포함한다. 이러한 컴퓨터 판독 가능 매체는 범용 또는 전용 컴퓨터에 의해 액세스될 수 있는 임의의 이용 가능 매체일 수 있다. 제한이 아닌 예로서, 이러한 컴퓨터 판독 가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광디스크 저장 장치, 자기 디스크 저장 장치 또는 다른 자기 저장 장치, 또는 컴퓨터 실행 가능 명령어들 또는 데이터 구조들의 형태로 원하는 프로그램 코드 수단을 운반 또는 저장하기 위하여 이용될 수 있고 범용 또는 전용 컴퓨터에 의하여 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다.

네트워크 또는 다른 통신 접속(배선되거나, 무선이거나, 또는 배선 또는 무선의 조합)을 통해 컴퓨터에 정보가 전송 또는 제공될 때, 컴퓨터는 접속을 컴퓨터 판독 가능 매체로서 적절히 본다. 따라서, 임의의 그러한 접속은 컴퓨터 판독 가능 매체로 적절이 용어가 정의된다. 상기의 조합들도 컴퓨터 판독 가능 매체의 범위 내에 포함될 수 있다.

컴퓨터 실행 가능 명령어들은, 예를 들면, 범용 컴퓨터, 전용 컴퓨터, 또는 전용 처리 장치가 특정의 기능 또는 기능들의 그룹을 수행하게 하는 명령어들 및 데이터를 포함한다. 본 발명의 주제는 구조적인 특징들 및/또는 방법적인 단계들에 특정한 언어로 기술되었지만, 첨부된 청구범위에 정의된 주제는 전술된 특정한 특징들 또는 단계들에 반드시 한정되는 것은 아니라는 것이 이해되어야 한다. 오히려, 전술된 특정한 특징들 및 단계들은 청구범위를 구현하는 예시적인 형태들로서 개시된다.

본 발명은 그 취지 또는 본질적인 특성들로부터 벗어나지 않고 다른 특정한 형태들로 구현될 수 있다. 상기 실시예들은 모든 측면들에서 제한적인 것이 아닌 예시적인 것으로서만 간주되어 진다. 따라서, 본 발명의 범위는 이전의 설명에 의해서가 아니라 첨부된 청구범위에 의해 나타내어진다. 청구범위의 균등의 의미 및 범위 내에 있는 모든 변화들이 그 범위 내에 포함되는 것이다.

Claims (20)

1. 클라이언트 컴퓨터 시스템이 방화벽을 통해 게이트웨이 서버에 있는 리소스를 액세스하는 컴퓨터화된 환경 내의 게이트웨이 서버에서 - 상기 게이트웨이 서버는 방화벽을 통하여 애플리케이션층 접속을 제공함 - ,

   클라이언트로부터 접속 요청을 수신하는 단계 - 상기 접속 요청은 상기 클라이언트가 접속을 원하는 리소스를 식별함 - ;

   상기 클라이언트가 하나 이상의 특징들의 최소 집합을 설치하였는지 여부를 판정하기 위해 상기 클라이언트와의 접속을 검역하는 단계;

   상기 식별된 리소스의 리소스 유형에 기초하여 프로토콜 프로세서 플러그인을 식별하는 단계; 및

   상기 클라이언트와의 접속을 상기 식별된 프로토콜 프로세서 플러그인에 포워딩하는 단계

   를 포함하는 방법.
2. 제1항에 있어서, 하나 이상의 액세스 정책들과 비교된 상기 클라이언트 요청에 제공된 인증 정보에 기초하여 상기 클라이언트를 인증하는 단계를 더 포함하는 방법.
3. 제2항에 있어서, 상기 게이트웨이 서버에 설치된 통신 프레임워크로부터 상 기 하나 이상의 액세스 정책들을 식별하는 단계를 더 포함하는 방법.
4. 제1항에 있어서, 상기 접속을 상기 식별된 프로토콜 프로세서 플러그인에 포워딩하는 단계는, 상기 서버에서의 상기 프로토콜 프로세서 플러그인에 대한 접속 터널의 채널의 제어를 제공하는 단계를 포함하는 방법.
5. 제4항에 있어서,

   상기 클라이언트로부터 상이한 리소스에 대한 상이한 접속 요청을 수신하는 단계; 및

   상기 동일한 접속 터널을 통해 상기 클라이언트와 상기 상이한 리소스 사이에 상이한 접속 채널을 설정하는 단계

   를 더 포함하는 방법.
6. 제4항에 있어서,

   상기 리소스에 대하여 상이한 접속 요청을 수신하여, 상기 클라이언트, 또는 상기 클라이언트 및 상기 방화벽 외부의 하나 이상의 상이한 클라이언트들 중 어느 하나로부터 동일한 리소스에 대한 복수의 접속들이 요청되게 하는 단계를 더 포함하는 방법.
7. 제6항에 있어서, 상기 상이한 접속 요청을 하는 클라이언트에 대하여 상기 식별된 프로토콜 프로세서 플러그인으로의 상이한 채널의 제어를 제공하는 단계를 더 포함하는 방법.
8. 제6항에 있어서,

   입도성 액세스 정책(granular access policy) 설정으로부터 상기 상이한 접속 요청이 부적절한 것을 식별하는 단계; 및

   상기 상이한 접속 요청을 거부하는 단계

   를 더 포함하는 방법.
9. 제8항에 있어서, 상기 액세스 정책은 상기 클라이언트가 상기 서버에 접속하는 것이 허가되어 있는지 여부를 판정하기 위한 네트워크 액세스 정책, 및 상기 클라이언트가 서버 접속을 통하여 상기 요청된 리소스에 대한 채널 생성을 위해 액세스하는지 여부를 판정하기 위한 리소스 액세스 정책을 포함하는 방법.
10. 제8항에 있어서, 상기 액세스 정책 설정은 하루 중 어느 시간 동안 상기 리소스에 대한 상기 클라이언트의 액세스를 제한하는 표시를 포함하며, 상기 상이한 접속 요청은 상기 하루 중 어느 시간 외에 있는 방법.
11. 제8항에 있어서, 상기 액세스 정책 설정은 방화벽 뒤의 리소스 서버의 특정 포트에서의 상기 리소스에 대한 상기 클라이언트의 액세스를 제한하는 표시를 포함 하며, 상기 상이한 접속 요청은 상기 리소스 서버의 상기 특정 포트에서의 리소스로의 접속을 요청하는 방법.
12. 제8항에 있어서, 상기 액세스 정책 설정은 상기 게이트웨이 서버에서의 상기 방화벽을 통한 접속 터널들의 수를 제한하는 네트워크 액세스 정책이어서, 상기 상이한 접속 요청은 상기 제한을 초과하는 새로운 접속 터널의 생성을 요구하는 방법.
13. 제8항에 있어서, 상기 액세스 정책 설정은 상기 클라이언트 요청이 스마트카드를 갖는 클라이언트에 의해 이루어질 것을 요구하며, 상기 상이한 접속 요청은 상기 클라이언트가 상기 스마트카드를 갖지 않은 것을 표시하는 방법.
14. 제8항에 있어서, 상기 액세스 정책 설정은 동일한 리소스에 대한 액세스를 허가된 클래스의 사용자들로 제한하며, 상기 상이한 접속 요청은 상기 허가된 클래스의 사용자들 중의 멤버가 아닌 상이한 사용자로부터 발생되는 방법.
15. 클라이언트가 게이트웨이 서버 방화벽을 통해 리소스에 액세스하는 컴퓨터화된 환경 내의 클라이언트 컴퓨터 시스템에서 - 상기 게이트웨이 서버는 방화벽을 통하여 애플리케이션층 접속을 제공함 - ,

    게이트웨이 서버에서의 접속에 대한 요청을 송신하는 단계 - 상기 요청은 대 응하는 클라이언트 리소스와 접속할 서버 리소스를 식별함 - ;

    상기 게이트웨이 서버로부터 상기 클라이언트에 의해 지원된 하나 이상의 특징들의 최소 세트에 대한 요청을 수신하는 단계;

    상기 게이트웨이 서버에 특징 응답을 송신하는 단계 - 상기 특징 응답은 상기 요청된 하나 이상의 특징들의 세트 중 어느 것이 상기 클라이언트에 의해 지원되는지 여부를 나타냄 - ; 및

    상기 게이트웨이 서버에서의 통신 스택의 애플리케이션층에 접속하여, 상기 클라이언트 리소스가 상기 서버 리소스와 연관된 프로토콜 프로세서 플러그인과 데이터를 통신하게 하는 단계

    를 포함하는 방법.
16. 제15항에 있어서, 상기 접속에 대한 요청과 함께 인증 정보를 송신하는 단계를 더 포함하며, 상기 인증 정보는 상기 클라이언트가 스마트카드를 갖는 것에 대한 표시를 포함하는 방법.
17. 제15항에 있어서, 애플리케이션층에 접속하는 단계는,

    상기 애플리케이션층에서 상기 게이트웨이 서버의 방화벽을 통한 접속 터널을 설정하는 단계; 및

    상기 요청된 리소스에 대한 접속 터널 내의 한 접속 채널을 설정하는 단계

    를 더 포함하는 방법.
18. 제15항에 있어서,

    상기 리소스에 대한 상이한 접속 요청을 상기 게이트웨이 서버에 송신하는 단계; 및

    상기 게이트웨이 서버에서의 접속에 대한 요청으로부터 생성된 채널과는 상이한 채널을 통하여 상기 프로토콜 프로세서 플러그인과 통신하는 단계

    를 더 포함하는 방법.
19. 제15항에 있어서,

    상기 프로토콜 프로세서 플러그인과 연관된 상이한 리소스에 대한 상이한 접속 요청을 송신하는 단계; 및

    상기 프로토콜 프로세서 플러그인을 통하여 상기 상이한 리소스와 통신하여, 상기 프로토콜 프로세서 플러그인이 상기 게이트웨이 서버에서의 복수의 리소스들과 상기 클라이언트 간의 복수의 접속 채널들을 다루게 하는 단계

    를 더 포함하는 방법.
20. 클라이언트 컴퓨터 시스템이 방화벽을 통하여 게이트웨이 서버에서의 리소스에 액세스하는 컴퓨터화된 환경 내의 게이트웨이 서버에서 - 상기 게이트웨이 서버는 통신 프레임워크 내에 적어도 보안 하이퍼텍스트 전송 프로토콜층 및 원격 프로시저 호출층을 가짐 - , 실행시, 상기 게이트웨이 서버에서의 하나 이상의 처리들 이,

    클라이언트로부터 접속 요청을 수신하는 단계 - 상기 접속 요청은 상기 클라이언트가 접속하기를 원하는 리소스를 식별함 - ;

    상기 클라이언트가 하나 이상의 특징들의 최소 세트를 설치하였는지 여부를 판정하기 위하여 상기 클라이언트와의 접속을 검역하는 단계;

    상기 식별된 리소스의 리소스 유형에 기초하여 프로토콜 프로세서 플러그인을 식별하는 단계; 및

    상기 식별된 프로토콜 프로세서 플러그인에 상기 클라이언트와의 접속을 포워딩하는 단계

    를 포함하는 방법을 수행하도록 하는 컴퓨터 실행가능 명령어들이 저장되어 있는 컴퓨터 프로그램 제품.

Images