KR101722631B1 - 프록시를 사용하여 자원들에의 보안 액세스 - Google Patents

Abstract

자원들을 인증하고 액세스하기 위한 방법이 제공된다. 클라이언트 디바이스는 기업 자원과 같은 자원에 액세스하기 위한 요청을 프록시 디바이스에 송신할 수 있다. 프록시 디바이스는 자원과 연관된 하나 이상의 서버들과 인증할 수 있다. 인증 동안, 프록시 디바이스는 클라이언트 디바이스에 의해 제어되는 서명에 대한 요청을 수신할 수 있다. 이에 응답하여, 프록시 디바이스는 서명을 위한 요청을 클라이언트 디바이스에 송신할 수 있다. 요청은 또한 인증 세션 동안 교환된 (또는 교환될) 인증 정보의 데이터 구조를 식별하는 콘텍스트 정보를 포함할 수 있다. 만일 클라이언트 디바이스가 콘텍스트 정보를 검증하면, 클라이언트 디바이스는 요청된 서명을 송신할 수 있다.

Description

프록시를 사용하여 자원들에의 보안 액세스{SECURED ACCESS TO RESOURCES USING A PROXY}

[1] 본 출원은 "SECURED ACCESS TO RESOURCES USING A PROXY"라는 명칭으로 2013년 5월 3일에 출원된 미국출원번호 제13/886,845호의 우선권을 주장한다.

[2] 본원에서 설명된 양상들은 일반적으로 클라이언트 디바이스가 프록시 디바이스를 사용하여 자원들에 보안적으로 액세스하기 위한 접근법들을 제공하는 것에 관한 것이다.

[3] 통상적으로, 공중 네트워크들에 연결된 클라이언트 디바이스들은 가상 사설 네트워크(VPN)들을 사용하여 사설 네트워크들에 연결된다. VPN에서, 단순히 투명 파이프(transparent pipe)로서 작용하는 프록시 디바이스는 클라이언트 디바이스와 사설 네트워크 간의 필수 연결을 제공할 수 있다. 통상적인 VPN들의 다양한 문제점들이 존재한다. 첫째, 클라이언트 디바이스가 사설 네트워크들상의 자원들에 직접 액세스할 수 있기 때문에 클라이언트 디바이스에 다수의 트러스트(trust)가 추가된다. 둘째, 클라이언트 디바이스는 자원 및/또는 사설 네트워크의 통신 프로토콜을 위하여 구성되어야 한다. 셋째, 프록시 디바이스는 클라이언트 디바이스의 활동들을 제어하거나 또는 모니터링할 수 없다.

[4] 하기의 설명은 본원에 설명된 다양한 양상들의 간략화된 요약을 제시한다. 이러한 요약은 포괄적인 개요가 아니며, 중요하거나 핵심적인 엘리먼트들을 식별하거나, 청구항들의 범위를 서술하고자 할 의도도 아니다. 하기의 요약은 단순히 후에 제시되는 상세한 설명에 대한 도입부로서 간략화된 형태로 일부 개념들을 제시한다.

[5] 앞서 설명된 종래 기술에 대한 한계들을 극복하고 본 명세서를 읽어서 이해할 때 명백하게 될 다른 한계들을 극복하기 위하여, 본원에서 설명된 양상들은 방법을 수행하도록 구성된 시스템, 장치 및/또는 컴퓨터 판독가능 매체에 관한 것이며, 방법은 클라이언트 디바이스로부터의 자원에 대한 요청을 프록시 디바이스에서 수신하는 단계, 프록시 디바이스로부터 자원 관리 디바이스로 자원에 대한 요청을 송신하는 단계를 포함한다. 프록시 디바이스와 자원 관리 디바이스 사이의 인증 세션이 개시될 수 있다. 프록시 디바이스는 클라이언트 디바이스가 서명을 제공하기 위한 요청을 생성할 수 있으며, 클라이언트 디바이스가 서명을 제공하기 위한 요청은 (1) 프록시 디바이스와 자원 관리 디바이스 사이에서 사전에 교환된 인증 정보 및 (2) 프록시 디바이스에 의해 자원 관리 디바이스에 송신될 인증 정보 중 적어도 하나의 데이터 구조를 식별하는 콘텍스트 정보를 포함할 수 있다. 프록시 디바이스는 예컨대 클라이언트 디바이스가 콘텍스트 정보를 검증한 경우에 클라이언트 디바이스로부터의 서명을 수신할 수 있다. 서명은 클라이언트 디바이스의 스마트 카드로부터 제공될 수 있다. 프록시 디바이스는 자원 관리 디바이스에 서명을 송신할 수 있다.

[6] 일부 실시예들에서, 방법은 인증 세션을 개시한 이후에, 클라이언트 디바이스로부터, 클라이언트 디바이스에게 이용가능한 보안 인증서들의 리스트를 프록시 디바이스에서 수신하는 단계를 더 포함할 수 있다. 인증 세션에 대한 보안 인증서가 선택될 수 있다. 게다가, 클라이언트 디바이스가 서명을 제공하기 위한 요청은 선택된 보안 인증서의 식별을 포함할 수 있다.

[7] 방법은 자원 관리 디바이스에 서명을 송신한 이후에, 서명에 대응하는 세션 키를 프록시 디바이스에서 수신하는 단계를 더 포함할 수 있다. 프록시 디바이스는 자원 관리 디바이스로부터, 요청된 자원을 획득하기 위하여 세션 키를 사용할 수 있다. 프록시 디바이스는 요청된 자원을 클라이언트 디바이스에 송신할 수 있다.

[8] 일부 양상들에서, 인증 세션은 SSL 인증을 포함하며, 데이터 구조를 식별하는 콘텍스트 정보는 인증 세션 동안 프록시 디바이스와 자원 관리 디바이스 사이에서 사전에 교환된 SSL 인증 메시지들을 포함할 수 있다. 다른 양상들에서, 인증 세션은 케베로스(Kerberos) 인증을 포함할 수 있으며, 데이터 구조를 식별하는 콘텍스트 정보는 케베로스 데이터 구조를 식별하는 정보를 포함할 수 있다. 예컨대, 케베로스 데이터 구조는 추상 구문 표기법(Abstract Syntax Notation) 1을 포함할 수 있다. 부가적으로 또는 대안적으로, 데이터 구조를 식별하는 콘텍스트 정보는 케베로스 인증을 위하여 사용된 케베로스 도메인, 클라이언트 디바이스와 연관된 케베로스 원이름, 인증 세션을 위해 사용된 키 분배 센터의 식별자, 요청된 티켓의 유효 기간, 및 인증 세션 동안 세팅되었던 케베로스 플래그들 중 적어도 하나를 포함할 수 있다.

[9] 일부 실시예들에서, 콘텍스트 정보는 인증 세션과 연관된 타임스탬프를 식별할 수 있다. 부가적으로 또는 대안적으로, 콘텍스트 정보는 인증 세션의 프로토콜 타입을 식별할 수 있다. 일부 양상들에서, 프록시 디바이스는 프로세서 및 컴퓨터-실행가능 명령들을 저장한 메모리를 포함하며, 컴퓨터-실행가능 명령들은 프로세서에 의해 실행될 때 프록시 디바이스로 하여금 앞서 설명된 방법 단계들을 수행하도록 할 수 있다.

[10] 시스템, 장치 및/또는 컴퓨터 판독가능 매체는 자원에 대한 요청을 클라이언트 디바이스로부터 프록시 디바이스로 송신하는 단계를 포함하는 방법을 수행하도록 구성될 수 있다. 클라이언트 디바이스는 클라이언트 디바이스가 서명을 제공하기 위한 요청을 프록시 디바이스로부터 수신할 수 있다. 클라이언트 디바이스가 서명을 제공하기 위한 요청은 (1) 프록시 디바이스와 요청된 자원과 연관된 자원 관리 디바이스 사이에서 사전에 교환된 인증 정보 및 (2) 프록시 디바이스에 의해 자원 관리 디바이스에 송신될 인증 정보 중 적어도 하나의 데이터 구조를 식별하는 콘텍스트 정보를 포함할 수 있다. 클라이언트 디바이스는 데이터 구조를 검증할 수 있으며, 데이터 구조를 검증하는 것에 응답하여, 클라이언트 디바이스는 보안 인증서에 대응하는 서명을 프록시 디바이스에 송신할 수 있다. 보안 인증서는 클라이언트 디바이스에 연결된 스마트 카드상에 저장될 수 있다. 방법은 요청에 응답하여, 클라이언트 디바이스에게 이용가능한 하나 이상의 보안 인증서들을 포함하는 리스트를 클라이언트 디바이스로부터 프록시 디바이스로 송신하는 단계를 더 포함할 수 있다. 클라이언트 디바이스가 서명을 제공하기 위한 수신된 요청은 하나 이상의 보안 인증서들을 포함하는 리스트로부터 선택된 보안 인증서의 식별을 포함할 수 있다.

[11] 이들 및 추가 양상들은 이하에서 더 상세히 논의되는 개시내용들의 장점과 함께 인식될 것이다.

[12] 본원에서 설명된 양상들 및 이의 장점들은 유사한 참조 부호들이 유사한 특징들을 표시하는 첨부 도면들을 고려하여 이하의 상세한 설명을 참조함으로서 더 완전하게 이해될 수 있다.
[13] 도 1은 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 컴퓨터 시스템 아키텍처를 도시한다.
[14] 도 2는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 원격-액세스 시스템 아키텍처를 도시한다.
[15] 도 3은 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 가상화(하이퍼바이저) 시스템 아키텍처를 도시한다.
[16] 도 4는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 클라우드-기반 시스템 아키텍처를 도시한다.
[17] 도 5는 예시적인 기업 모빌리티 관리 시스템을 도시한다.
[18] 도 6은 다른 예시적인 기업 모빌리티 관리 시스템을 도시한다.
[19] 도 7은 클라이언트, 프록시, 자원(들) 및/또는 인증 서비스(들)를 가진 예시적인 시스템을 도시한다.
[20] 도 8은 클라이언트 및 프록시의 예시적인 상세 도면을 도시한다.
[21] 도 9a는 프록시를 사용하여 자원들에 대한 보안 액세스를 인증하고 그리고/또는 제공하기 위한 예시적인 방법 단계들의 흐름도이다.
[22] 도 9b는 프록시를 사용하여 자원들에 대한 보안 액세스를 인증하고 그리고/또는 제공하기 위한 추가의 예시적인 방법 단계들의 흐름도이다.
[23] 도 9c는 프록시를 사용하여 자원들에 대한 보안 액세스를 인증하고 그리고/또는 제공하기 위한 다른 추가의 예시적인 방법 단계들의 흐름도이다.

[24] 다양한 실시예들의 이하의 설명에서는 실시예의 일부분을 형성하며, 본원에서 설명된 양상들이 실시될 수 있는 예시적인 다양한 실시예들이 도시되는 앞서 식별된 첨부 도면들을 참조한다. 본원에서 설명된 범위로부터 벗어나지 않고, 다른 실시예들이 활용될 수 있고 구성 및 기능이 수정될 수 있다는 것이 이해되어야 한다. 다양한 양상들은 다른 실시예들을 가능하게 하며 다양한 상이한 방식들로 실시되거나 또는 수행될 수 있다.

[25] 이하에서 상세히 설명된 요지에 대한 총론으로서, 본원에서 설명된 양상들은 모바일 컴퓨팅 디바이스들의 관리 모바일 애플리이션(managed mobile application)들을 사용하여 기업 컴퓨팅 시스템의 자원들에 대한 원격 액세스를 제어하는 것에 관한 것이다. 액세스 관리자는 기업 자원들에 대한 액세스를 요청하는 모바일 애플리케이션이 자체적으로 정확하게 식별되었고 모바일 컴퓨팅 디바이스에 설치된 이후 나중에 변경되지 않았는지의 여부를 결정하는 검증 프로세스(validation process)를 수행할 수 있다. 이러한 방식으로, 액세스 관리자는 기업 자원에 대한 액세스를 요청하는 모바일 애플리케이션이 신뢰성이 있을 수 있고 그 기업 자원들을 보호하기 위하여 사용되는 보안 메커니즘들을 회피하는 것을 시도하지 않음을 보장할 수 있다. 결과적으로, 기업과 연관된 개인들은 자신들의 개인 모바일 디바이스들로 기업 자원들을 유리하게 활용할 수 있다.

[26] 본원에서 사용되는 어법 및 전문용어가 설명을 위한 것이며 제한으로서 간주되지 않아야 한다는 것이 이해되어야 한다. 오히려, 본원에서 사용되는 문구들 및 용어들은 그들의 가장 넓은 해석 및 의미가 부여되어야 한다. "포함하는" 및 "구성하는" 및 이의 변형들의 사용은 이후에 리스트되는 항목들 및 이의 균등물들 뿐만아니라 추가 항목들 및 이의 균등물들을 포함하는 것으로 의미된다. "장착되는", "연결되는", "커플링되는", "포지셔닝되는", "연동되는"이라는 용어들 및 유사한 용어들의 사용은 직접적으로 및 간접적으로 장착하는, 연결하는, 커플링하는, 포지셔닝하는 및 연동하는 것을 포함하는 것으로 의도된다.

[27] 컴퓨팅 아키텍처

[28] 컴퓨터 소프트웨어, 하드웨어 및 네트워크들은 특히 스탠드얼론(standalone), 네트워크화, 원격-액세스(원격 데이크탑으로도 알려짐), 가상화 및/또는 클라우드-기반 환경들을 비롯하여 다양한 상이한 시스템 환경들에서 활용될 수 있다. 도 1은 스탠드얼론 및/또는 네트워크화 환경에서, 본원에서 설명된 하나 이상의 예시적인 양상들을 구현하기 위하여 사용될 수 있는 시스템 아키텍처 및 데이터 프로세싱 디바이스의 일례를 예시한다. 다양한 네트워크 노드들(103, 105, 107 및 109)은 광역 통신망(WAN)(101), 예컨대 인터넷을 통해 상호 연결될 수 있다. 사설 인트라넷들, 기업 네트워크들, LAN들, 도시권 통신망(MAN), 무선 네트워크들, 개인 네트워크(PAN)들 등을 포함하는 다른 네트워크들이 또한 또는 대안적으로 사용될 수 있다. 네트워크(101)는 예시적 목적이며, 더 적은 수의 컴퓨터 네트워크들로 또는 더 많은 수의 컴퓨터 네트워크들로 대체될 수 있다. 근거리 통신망(LAN)은 임의의 공지된 LAN 토폴로지 중 하나 이상을 가질 수 있으며, 이더넷과 같은 다양한 상이한 프로토콜들 중 하나 이상을 사용할 수 있다. 디바이스들(103, 105, 107, 109) 및 다른 디바이스들(도시안됨)은 트위스트 페어 와이어들, 동축 케이블, 광섬유들, 라디오 파들 또는 다른 통신 매체를 통해 네트워크들 중 하나 이상의 네트워크에 연결될 수 있다.

[29] 본원에서 사용되고 도면들에 도시된 바와같은 "네트워크"란 용어는 원격 저장 디바이스들이 하나 이상의 통신 경로들을 통해 함께 커플링되는 시스템들 뿐만아니라 가끔씩 저장 능력을 가지는 이러한 시스템들에 커플링될 수 있는 스탠드-얼론 디바이스들을 지칭한다. 결과적으로, 용어 "네트워크"는 "물리적 네트워크" 뿐만아니라 "콘텐츠 네트워크"를 포함하며, "콘텐츠 네트워크"는 모든 물리적 네트워크들에 걸쳐 상주하는 데이터로 구성되며, 단일 엔티티로 여겨질 수 있다.

[30] 컴포넌트들은 데이터 서버(103), 웹 서버(105) 및 클라이언트 컴퓨터들(107, 109)을 포함할 수 있다. 데이터 서버(103)는 본원에서 설명된 하나 이상의 예시적인 양상들을 수행하기 위한 제어 소프트웨어 및 데이터베이스들의 전체 액세스, 제어 및 관리를 제공한다. 데이터 서버(103)는 웹 서버(105)에 연결될 수 있으며, 웹 서버(105)를 통해 사용자들은 요청된 데이터와 상호작용하여 이 데이터를 획득한다. 대안적으로, 데이터 서버(103)는 그 자체적으로 웹 서버로서 작용할 수 있고 인터넷에 직접 연결될 수 있다. 데이터 서버(103)는 네트워크(101)(예컨대, 인터넷)를 통해, 직접 또는 간접 연결을 통해 또는 일부 다른 네트워크를 통해 웹 서버(105)에 연결될 수 있다. 사용자들은 웹 서버(105)에 의해 호스팅되는 하나 이상의 외부적으로 노출된 웹 사이트들을 통해 데이터 서버(103)에 연결하기 하여 원격 컴퓨터들(107, 109)을 사용하여, 예컨대 웹 브라우저들을 사용하여 데이터 서버(103)와 상호작용할 수 있다. 클라이언트 컴퓨터들(107, 109)은 데이터 서버(103)에 저장된 데이터에 액세스하기 위하여 데이터 서버(103)와 협력하여 사용될 수 있거나 또는 다른 목적들을 위해 사용될 수 있다. 예컨대, 클라이언트 디바이스(107)로부터, 사용자는 기술분야에서 공지된 인터넷 브라우저를 사용하여 또는 컴퓨터 네트워크(예컨대, 인터넷)를 통해 웹 서버(105) 및/또는 데이터 서버(103)와 통신하는 소프트웨어 애플리케이션을 실행함으로써 웹 서버(105)에 액세스할 수 있다.

[31] 서버들 및 애플리케이션들은 동일한 물리적 머신들상에서 결합될 수 있고, 개별적인 가상 또는 논리 어드레스들을 보유할 수 있거나 또는 개별 물리 머신들상에 상주할 수 있다. 도 1은 사용될 수 있는 네트워크 아키텍처의 단지 하나의 예를 예시하며, 당업자는, 본원에서 추가로 설명되는 바와같이, 사용된 특정 네트워크 아키텍처 및 데이터 프로세싱 디바이스들이 변경될 수 있으며, 이들이 제공하는 기능이 부차적이라는 것을 인식할 것이다. 예컨대, 웹 서버(105) 및 데이터 서버(103)에 의해 제공되는 서비스들은 단일 서버상에서 결합될 수 있다.

[32] 각각의 컴포넌트(103, 105, 107, 109)는 임의의 타입의 공지된 컴퓨터, 서버 또는 데이터 프로세싱 디바이스일 수 있다. 데이터 서버(103)는 예컨대 레이트 서버(rate server)(103)의 전체 동작을 제어하는 프로세서(111)를 포함할 수 있다. 데이터 서버(103)는 RAM(113), ROM(115), 네트워크 인터페이스(117), 입력/출력 인터페이스들(119)(예컨대, 키보드, 마우스, 디스플레이, 프린터 등) 및 메모리(121)를 더 포함할 수 있다. I/O(119)는 데이터 또는 파일들을 판독하고, 기록하며, 디스플레이하며 그리고/또는 프린트하기 위한 다양한 인터페이스 유닛들 및 드라이브들을 포함할 수 있다. 메모리(121)는 데이터 프로세싱 디바이스(103)의 전체 동작을 제어하기 위한 운영체제 소프트웨어(123), 본원에서 설명된 양상들을 수행하도록 데이터 서버(103)에 명령하기 위한 제어 로직(125), 및 본원에서 설명된 양상들과 함께 사용될 수 있거나 또는 본원에서 설명된 양상들과 함께 사용되지 않을 수 있는 2차 기능, 지원 기능 및/또는 다른 기능을 제공하는 다른 애플리케이션 소프트웨어(127)를 추가로 저장할 수 있다. 제어 로직은 또한 데이터 서버 소프트웨어(125)로서 본원에서 지칭될 수 있다. 데이터 서버 소프트웨어의 기능은 제어 로직으로 코딩된 규칙들에 기초하여 자동적으로 만들어지거나 또는 사용자가 시스템내에 입력을 제공함으로써 수동적으로 만들어지거나 또는 사용자 입력(예컨대, 질의들, 데이터 업데이트들 등)에 기초한 자동 프로세싱의 조합으로 만들어진 동작들 또는 결정들을 지칭할 수 있다.

[33] 제 1 데이터베이스(129) 및 제 2 데이터베이스(131)를 포함하는 메모리(121)는 또한 본원에서 설명된 하나 이상의 양상들의 수행시에 사용되는 데이터를 저장할 수 있다. 일부 실시예들에서, 제 1 데이터베이스는 (예컨대, 개별 테이블, 보고 등으로서) 제 2 데이터베이스를 포함할 수 있다. 즉, 시스템 설계에 따라, 정보는 단일 데이터베이스에 저장될 수 있거나 또는 상이한 논리적, 가상적 또는 물리적 데이터베이스들로 분리될 수 있다. 디바이스들(105, 107, 109)은 디바이스(103)와 관련하여 설명된 것과 유사한 또는 상이한 아키텍처를 가질 수 있다. 당업자는 본원에서 설명된 데이터 프로세싱 디바이스(103)(또는 디바이스들(105, 107, 109))의 기능이 예컨대 다수의 컴퓨터들에 걸쳐 프로세싱 로드를 분배하기 위하여, 즉 지리적 위치, 사용자 액세스 레벨, 서비스 품질(QoS) 등에 기초하여 트랜잭션(transaction)들을 분리하기 위하여, 다수의 데이터 프로세싱 디바이스들에 걸쳐 분산될 수 있다는 것을 인식할 것이다.

[34] 하나 이상의 양상들은 본원에서 설명되는 바와같이 컴퓨터-사용가능 또는 판독가능 데이터 및/또는 컴퓨터-실행가능 명령들로, 예컨대 하나 이상의 컴퓨터들 또는 다른 디바이스들에 의해 실행되는 하나 이상의 프로그램 모듈들로 구현될 수 있다. 일반적으로, 프로그램 모듈들은 컴퓨터 또는 다른 디바이스의 프로세서에 의해 실행될 때 특정 태스크(task)들을 수행하거나 또는 특정 추상 데이터 타입들을 구현하는 루틴들, 프로그램들, 객체들, 컴포넌트들, 데이터 구조들 등을 포함한다. 모듈들은 실행을 위해 나중에 컴파일링되는 소스 코드 프로그래밍 언어로 쓰여질 수 있거나 또는 HTML 또는 XML와 같은 (그러나, 이에 제한되지 않음) 스크립팅 언어(scripting language)로 쓰여질 수 있다. 컴퓨터 실행가능 명령들은 비휘발성 저장 디바이스와 같은 컴퓨터 판독가능 매체상에 저장될 수 있다. 하드 디스크들, CD-ROM들, 광 저장 디바이스들, 자기 저장 디바이스들 및/또는 이들의 임의의 조합을 포함하는 임의의 적절한 컴퓨터 판독가능 저장 매체가 활용될 수 있다. 더욱이, 본원에서 설명된 바와 같은 데이터 또는 이벤트들을 나타내는 다양한 전송(비-저장) 매체는 금속 와이어들, 광섬유들, 및/또는 무선 전송 매체(예컨대, 에어(air) 및/또는 공간)와 같은 신호-전도 매체(signal-conducting media)를 통해 이동하는 전자기 파들의 형태로 소스와 목적지사이에서 이동될 수 있다. 본원에서 설명된 다양한 양상들은 방법, 데이터 프로세싱 시스템 또는 컴퓨터 프로그램 제품으로서 구현될 수 있다. 따라서, 다양한 기능들은 소프트웨어, 펌웨어 및/또는 하드웨어 또는 하드웨어 균등물들, 예컨대 집적회로들, 필드 프로그램가능 게이트 어레이(FPGA)들 등으로 전체적으로 또는 부분적으로 구현될 수 있다. 특정 데이터 구조들이 본원에서 설명된 하나 이상의 양상들을 더 효과적으로 구현하기 위하여 사용될 수 있으며, 이러한 데이터 구조들은 본원에서 설명된 컴퓨터 실행가능 명령들 및 컴퓨터-사용가능 데이터의 범위내에 있는 것으로 고려된다.

[35] 도 2를 추가로 참조하면, 본원에서 설명된 하나 이상의 양상들은 원격-액세스 환경에서 구현될 수 있다. 도 2는 본원에서 설명된 하나 이상의 예시적인 양상들에 따라 사용될 수 있는 예시적인 컴퓨팅 환경(200)의 범용 컴퓨팅 디바이스(201)를 포함하는 예시적인 시스템 아키텍처를 도시한다. 범용 컴퓨팅 디바이스(201)는 클라이언트 액세스 디바이스들에 가상 머신들을 제공하도록 구성된 단일-서버 또는 멀티-서버 데스크탑 가상화 시스템(예컨대, 원격 액세스 또는 클라우드 시스템)에서 서버(206a)로서 사용될 수 있다. 범용 컴퓨팅 디바이스(201)는 랜덤 액세스 메모리(RAM)(205), 판독-전용 메모리(ROM)(207), 입력/출력(I/O) 모듈(209) 및 메모리(215)를 비롯하여 서버 및 이와 연관된 컴포넌트들의 전체 동작을 제어하기 위한 프로세서(203)를 가질 수 있다.

[36] I/O 모듈(209)은 마우스, 키패드, 터치 스크린, 스캐너, 광 판독기, 및/또는 스타일러스(또는 다른 입력 디바이스(들)) ― 이를 통해 범용 컴퓨팅 디바이스(201)의 사용자는 입력을 제공할 수 있음 ―를 포함할 수 있으며, 또한 오디오 출력을 제공하기 위한 스피커 및 문자, 시청각 및/또는 그래픽 출력을 제공하기 위한 비디오 디스플레이 디바이스 중 하나 이상을 포함할 수 있다. 소프트웨어는 본원에서 설명된 바와 같은 다양한 기능들을 수행하기 위하여 범용 컴퓨팅 디바이스(201)를 특수 목적 컴퓨팅 디바이스로 구성하기 위한 명령들을 프로세서(203)에 제공하도록 메모리(215) 및/또는 다른 스토리지내에 저장될 수 있다. 예컨대, 메모리(215)는 컴퓨팅 디바이스(201)에 의해 사용된 소프트웨어, 예컨대 운영체제(217), 애플리케이션 프로그램들(219) 및 연관된 데이터베이스(221)를 저장할 수 있다.

[37] 컴퓨팅 디바이스(201)는 단말들(240)(또한 클라이언트 디바이스들로 지칭됨)과 같은 하나 이상의 원격 컴퓨터들에의 연결들을 지원하는 네트워크화 환경에서 동작할 수 있다. 단말들(240)은 범용 컴퓨팅 디바이스(103 또는 201)와 관련하여 앞서 설명된 엘리먼트들 모두 또는 많은 엘리먼트들을 포함하는, 퍼스널 컴퓨터들, 모바일 디바이스들, 랩탑 컴퓨터들, 태블릿들 또는 서버들일 수 있다. 도 2에 도시된 네트워크 연결들은 근거리 통신망(LAN)(225) 및 광역 통신망(WAN)(229)을 포함하나, 또한 다른 네트워크들을 포함할 수 있다. LAN 네트워킹 환경에서 사용될 때, 컴퓨팅 디바이스(201)는 네트워크 인터페이스 또는 어댑터(223)를 통해 LAN(225)에 연결될 수 있다. WAN 네트워킹 환경에서 사용될 때, 컴퓨팅 디바이스(201)는 모뎀(227), 또는 컴퓨터 네트워크(230)(예컨대, 인터넷)와 같이 WAN(229)를 통해 통신들을 설정하기 위한 다른 광역 네트워크 인터페이스를 포함할 수 있다. 도시된 네트워크 연결들이 예시적이며 컴퓨터들 사이에 통신 링크를 설정하는 다른 수단이 사용될 수 있다는 것이 인식될 것이다. 컴퓨팅 디바이스(201) 및/또는 단말들(240)은 또한 배터리, 스피커, 및 안테나들(도시안됨)과 같은 다양한 다른 컴포넌트들을 포함하는 모바일 단말들(예컨대, 모바일 폰들, 스마트폰들, PDA들, 노트북들 등)일 수 있다.

[38] 본원에서 설명된 양상들은 또한 다수의 다른 범용 또는 특수 목적 컴퓨팅 시스템 환경들 또는 구성들로 운용가능할 수 있다. 본원에서 설명된 양상들과 함께 사용하기에 적합할 수 있는 다른 컴퓨팅 시스템들, 환경들 및/또는 구성들의 예들은 퍼스널 컴퓨터들, 서버 컴퓨터들, 핸드-헬드 또는 랩탑 디바이스들, 멀티프로세서 시스템들, 마이크로프로세서-기반 시스템들, 셋톱 박스들, 프로그램가능 가전제품들, 네트워크 PC들, 미니컴퓨터들, 메인프레임 컴퓨터들, 앞의 시스템들 또는 디바이스들 중 임의의 것을 포함하는 분산형 컴퓨팅 환경들 등을 포함하나 이들에 제한되지 않는다.

[39] 도 2에 도시된 바와같이, 하나 이상의 클라이언트 디바이스들(240)은 하나 이상의 서버들(206a-206n)(일반적으로 본원에서 "서버(들)(206)"로 지칭됨)과 통신할 수 있다. 일 실시예에서, 컴퓨팅 환경(200)은 서버(들)(206)와 클라이언트 머신(들)(240) 사이에 설치된 네트워크 어플라이언스(appliance)를 포함할 수 있다. 네트워크 어플라이언스는 클라이언트/서버 연결들을 관리할 수 있으며, 일부 경우들에서 복수의 백엔드 서버들(206) 사이의 클라이언트 연결들을 로드 밸런싱할 수 있다.

[40] 클라이언트 머신(들)(240)은 일부 실시예들에서 단일 클라이언트 머신(240) 또는 클라이언트 머신들(240)의 단일 그룹으로 지칭될 수 있는 반면에, 서버(들)(206)는 단일 서버(206) 또는 서버들(206)의 단일 그룹으로 지칭될 수 있다. 일 실시예에서, 단일 클라이언트 머신(240)은 2개 이상의 서버(206)와 통신하는 반면에, 다른 실시예에서 단일 서버(206)는 2개 이상의 클라이언트 머신(240)과 통신한다. 또 다른 실시예에서, 단일 클라이언트 머신(240)은 단일 서버(206)와 통신한다.

[41] 일부 실시예들에서, 클라이언트 머신(240)은 이하의 비-포괄적인 용어들, 즉 클라이언트 머신(들); 클라이언트(들); 클라이언트 컴퓨터(들); 클라이언트 디바이스(들); 클라이언트 컴퓨팅 디바이스(들); 로컬 머신; 원격 머신; 클라이언트 노드(들); 엔드포인트(들) 또는 엔드포인트 노드(들) 중 어느 하나로 참조될 수 있다. 일부 실시예들에서, 서버(206)는 이하의 비-포괄적인 용어들, 즉 서버(들); 로컬 머신; 원격 머신; 서버 팜(들) 또는 호스트 컴퓨팅 디바이스(들) 중 어느 하나로 참조될 수 있다.

[42] 일 실시예에서, 클라이언트 머신(240)은 가상 머신일 수 있다. 가상 머신은 임의의 가상 머신일 수 있는 반면에, 일부 실시예들에서, 가상 머신은 타입 1 또는 타입 2 하이퍼바이저(hypervisor), 예컨대 Citrix Systems, IBM, VMware에 의해 개발된 하이퍼바이저 또는 임의의 다른 하이퍼바이저에 의해 관리되는 임의의 가상 머신일 수 있다. 일부 양상들에서, 가상 머신은 하이퍼바이저에 의해 관리될 수 있는 반면에, 양상들에서 가상 머신은 서버(206)상에서 실행되는 하이퍼바이저 또는 클라이언트(240)상에서 실행되는 하이퍼바이저에 의해 관리될 수 있다.

[43] 일부 실시예들은 서버(206)상에서 원격적으로 실행되는 애플리케이션 또는 다른 원격적으로 위치한 머신에 의해 생성되는 애플리케이션 출력을 디스플레이하는 클라이언트 디바이스(240)를 포함한다. 이들 실시예들에서, 클라이언트 디바이스(240)는 애플리케이션 윈도우, 브라우저 또는 다른 출력 윈도우의 출력을 디스플레이하기 위하여 가상 머신 클라이언트 에이전트 프로그램 또는 애플리케이션을 실행할 수 있다. 일례에서 애플리케이션은 데스크탑인 반면에, 다른 예들에서 애플리케이션은 데스크탑을 생성하거나 또는 제시하는 애플리케이션이다. 데스크탑은 로컬 및/또는 원격 애플리케이션들이 통합될 수 있는 운영체제의 인스턴스(instance)에 대한 사용자 인터페이스를 제공하는 그래픽 쉘(graphical shell)을 포함할 수 있다. 본원에서 설명된 바와같은 애플리케이션들은 운영체제(그리고, 또한 선택적으로 데스크탑)의 인스턴스가 로드된 후 실행되는 프로그램들이다.

[44] 일부 실시예들에서, 서버(206)는 서버(206)상에서 실행되는 애플리케이션에 의해 생성되는 디스플레이 출력을 제시하기 위하여 클라이언트상에서 실행되는 씬-클라이언트(thin-client) 또는 원격-디스플레이 애플리케이션에 데이터를 송신하기 위하여 원격 프리젠테이션 프로토콜 또는 다른 프로그램을 사용한다. 씬-클라이언트 또는 원격-디스플레이 프로토콜은 프로토콜들의 이하의 비-포괄적인 리스트, 즉 플로리다, 포트 로더데일에 위치한 Citrix Systems, Inc.에 의해 개발된 ICA(Independent Computing Architecture) 프로토콜 또는 워싱턴 레드몬드에 위치한 Microsoft Corporation에 의해 제조된 RDP(Remote Desktop Protocol) 중 어느 하나일 수 있다.

[45] 원격 컴퓨팅 환경은 예컨대 클라우드 컴퓨팅 환경에서 서버들(206a-206n)이 서버 팜(206)으로 논리적으로 함께 그룹핑되도록 2개 이상의 서버(206a-206n)를 포함할 수 있다. 서버 팜(206)은 지리적으로 분산된 반면에 함께 논리적으로 그룹핑되는 서버들(206) 또는 서로 근접하게 배치되는 반면에 함께 논리적으로 그룹핑되는 서버들(206)을 포함할 수 있다. 일부 실시예들에서, 서버 팜(206) 내의 지리적으로 분산된 서버들(206a-206n)은 WAN(광역), MAN(대도시) 또는 LAN(지역)을 사용하여 통신할 수 있으며, 여기서 상이한 지리적 지역들은 상이한 대륙들; 상이한 대륙 지역들; 상이한 국가들; 상이한 주들; 상이한 도시들; 상이한 캠퍼스들; 상이한 방들; 또는 전술한 지리적 위치들의 임의의 조합으로 특징지워질 수 있다. 일부 실시예들에서 서버 팜(206)은 단일 엔티티로서 관리될 수 있는 반면에, 다른 실시예들에서 서버 팜(206)은 다수의 서버 팜들을 포함할 수 있다.

[46] 일부 실시예들에서, 서버 팜은 실질적으로 유사한 타입의 운영체제 플랫폼(예컨대, WINDOWS, UNIX, LINUX, iOS, ANDROID, SYMBIAN 등)을 실행하는 서버들(206)을 포함할 수 있다. 다른 실시예들에서, 서버 팜(206)은 제 1 타입의 운영체제 플랫폼을 실행하는 하나 이상의 서버들의 제 1 그룹 및 제 2 타입의 운영체제 플랫폼을 실행하는 하나 이상의 서버들의 제 2 그룹을 포함할 수 있다.

[47] 서버(206)는 필요에 따라 임의의 타입의 서버로서, 예컨대 파일 서버, 애플리케이션 서버, 웹 서버, 프록시 서버, 어플라이언스, 네트워크 어플라이언스, 게이트웨이, 애플리케이션 게이트웨이, 게이트웨이 서버, 가상화 서버, 전개 서버, SSL VPN 서버, 방화벽, 웹 서버, 애플리케이션 서버로서, 또는 마스터 애플리케이션 서버, 액티브 디렉토리를 실행하는 서버, 또는 방화벽 기능, 애플리케이션 기능 또는 로드 밸런싱 기능을 제공하는 애플리케이션 가속 프로그램을 실행하는 서버로서 구성될 수 있다. 다른 서버 타입들이 또한 사용될 수 있다.

[48] 일부 실시예들은 클라이언트 머신(240)으로부터의 요청들을 수신하며, 제 2 서버(106b)에 요청을 포워드하며 그리고 제 2 서버(106b)로부터의 응답으로 클라이언트 머신(240)에 의해 생성되는 요청에 응답하는 제 1 서버(106a)를 포함한다. 제 1 서버(106a)는 클라이언트 머신(240)이 이용할 수 있는 애플리케이션들의 목록 뿐만아니라 애플리케이션들의 목록내에서 식별되는 애플리케이션을 호스팅하는 애플리케이션 서버(206)와 연관된 어드레스 정보를 획득할 수 있다. 이후, 제 1 서버(106a)는 웹 인터페이스를 사용하여 클라이언트의 요청에 대한 응답을 제시할 수 있으며, 식별된 애플리케이션에 대한 액세스를 클라이언트(240)에 제공하기 위하여 클라이언트(240)와 직접 통신할 수 있다. 하나 이상의 클라이언트들(240) 및/또는 하나 이상의 서버들(206)은 네트워크(230), 예컨대 네트워크(101)를 통해 데이터를 전송할 수 있다.

[49] 도 2는 예시적인 데스크탑 가상화 시스템의 고레벨 아키텍처를 도시한다. 도시된 바와같이, 데스크탑 가상화 시스템은 하나 이상의 클라이언트 액세스 디바이스들(240)에 가상 데스크탑들 및/또는 가상 애플리케이션들을 제공하도록 구성된 적어도 하나의 가상화 서버(206)를 포함하는, 단일-서버 또는 멀티-서버 시스템 또는 클라우드 시스템일 수 있다. 본원에서 사용되는 바와같이, 데스크탑은 하나 이상의 애플리케이션들이 호스팅되고 그리고/또는 실행되는 그래픽 환경 또는 공간을 지칭한다. 데스크탑은 로컬 및/또는 원격 애플리케이션들이 통합될 수 있는 운영체제의 인스턴스에 대한 사용자 인터페이스를 제공하는 그래픽 쉘을 포함할 수 있다. 애플리케이션들은 운영체제(그리고 선택적으로 또한 데스크탑)의 인스턴스가 로드된 이후에 실행되는 프로그램들을 포함할 수 있다. 운영체제의 각각의 인스턴스는 물리적(예컨대, 디바이스당 하나의 운영체제) 또는 가상적(예컨대, 단일 디바이스상에서 실행되는 OS의 많은 인스턴스들)일 수 있다. 각각의 애플리케이션은 로컬 디바이스상에서 실행될 수 있거나 또는 원격적으로 위치한 디바이스(예컨대 원격 디바이스)상에서 실행될 수 있다.

[50] 도 3을 추가로 참조하면, 컴퓨터 디바이스(301)는 가상화 환경의 가상화 서버, 예컨대, 단일-서버, 멀티-서버 또는 클라우드 컴퓨팅 환경으로서 구성될 수 있다. 도 3에 예시된 가상화 서버(301)는 도 2에 예시된 서버(206)의 하나 이상의 실시예들 또는 다른 공지된 컴퓨팅 디바이스로서 전개될 수 있거나 그리고/또는 이에 의해 구현될 수 있다. 가상화 서버(301)에 포함된 것은 하나 이상의 물리적 디스크들(304), 하나 이상의 물리적 디바이스들(306), 하나 이상의 물리적 프로세서들(308) 및 하나 이상의 물리적 메모리들(316)을 포함할 수 있는 하드웨어 계층이다. 일부 실시예들에서, 펌웨어(312)는 물리적 메모리(316)의 메모리 엘리먼트 내에 저장될 수 있고, 물리적 프로세서들(308) 중 하나 이상에 의해 실행될 수 있다. 가상화 서버(301)는 물리적 메모리(316)의 메모리 엘리먼트에 저장되고 물리적 프로세서들(308) 중 하나 이상에 의해 실행될 수 있는 운영체제(314)를 더 포함할 수 있다. 또한, 하이퍼바이저(302)는 물리적 메모리(316)의 메모리 엘리먼트에 저장될 수 있고 물리적 프로세서들(308) 중 하나 이상에 의해 실행될 수 있다.

[51] 물리적 프로세서들(308) 중 하나 이상의 프로세서상에서 실행시키는 것은 하나 이상의 가상 머신들(332A-C)(일반적으로 332)일 수 있다. 각각의 가상 머신(332)은 가상 디스크(326A-C) 및 가상 프로세서(328A-C)를 가질 수 있다. 일부 실시예들에서, 제 1 가상 머신(332A)은, 가상 프로세서(328A)를 이용하여, 툴 스택(tools stack)(324)을 포함하는 제어 프로그램(320)을 실행할 수 있다. 제어 프로그램(320)은 제어 가상 머신, Dom0, Domain 0, 또는 시스템 운영 및/또는 제어용으로 사용되는 다른 가상 머신으로서 지칭될 수 있다. 일부 실시예들에서, 하나 이상의 가상 머신(332B-C)은, 가상 프로세서(328B-C)를 이용하여, 게스트 운영체제(330A-B)를 실행시킬 수 있다.

[52] 가상화 서버(301)는 가상화 서버(301)와 통신하는, 하드웨어의 하나 이상의 피스(piece)들을 구비하는 하드웨어 계층(310)을 포함할 수 있다. 일부 실시예들에서, 하드웨어 계층(310)은 하나 이상의 물리적 디스크들(304), 하나 이상의 물리적 디바이스들(306), 하나 이상의 물리적 프로세서들(308) 및 하나 이상의 메모리(216)를 포함할 수 있다. 물리적 컴포넌트들(304, 306, 308 및 316)은 예컨대, 앞서 설명된 컴포넌트들 중 임의의 컴포넌트를 포함할 수 있다. 물리적 디바이스들(306)은 예컨대, 네트워크 인터페이스 카드, 비디오 카드, 키보드, 마우스, 입력 디바이스, 모니터, 디스플레이 디바이스, 스피커들, 광 드라이브, 저장 디바이스, 범용 직렬 버스 연결, 프린터, 스캐너, 네트워크 엘리먼트(예컨대, 라우터, 방화벽, 네트워크 어드레스 번역기, 로드 밸런서, VPN(virtual private network) 게이트웨이, DHCP(Dynamic Host Configuration Protocol) 라우터 등), 또는 가상화 서버(301)에 연결되거나 이와 통신하는 임의의 디바이스를 포함할 수 있다. 하드웨어 계층(310)의 물리적 메모리(316)는 임의의 타입의 메모리를 포함할 수 있다. 물리적 메모리(316)는 데이터를 저장할 수 있고, 일부 실시예들에서 하나 이상의 프로그램들, 또는 실행 가능한 명령들의 세트를 저장할 수 있다. 도 3은 펌웨어(312)가 가상화 서버(301)의 물리적 메모리(316) 내에 저장된 실시예를 예시한다. 물리적 메모리(316)에 저장된 프로그램 또는 실행 가능한 명령들은 가상화 서버(301)의 하나 이상의 프로세서들(308)에 의해 실행될 수 있다.

[53] 가상화 서버(301)는 또한 하이퍼바이저(302)를 포함할 수 있다. 일부 실시예들에서, 하이퍼바이저(302)는 가상화 서버(301) 상의 프로세서들(308)에 의해 실행되어 임의의 개수의 가상 머신들(332)을 생성 및 관리하는 프로그램일 수 있다. 하이퍼바이저(302)는 가상 머신 모니터 또는 플랫폼 가상화 소프트웨어로 지칭될 수 있다. 일부 실시예들에서, 하이퍼바이저(302)는 컴퓨팅 머신 상에서 실행되는 가상 머신들을 모니터링하는 하드웨어 및 실행 가능한 명령들의 임의의 조합일 수 있다. 하이퍼바이저(302)는 타입 2 하이퍼바이저일 수 있고, 여기서 운영체제(314) 내에서 실행되는 하이퍼바이저는 가상화 서버(301) 상에서 실행될 수 있다. 이후, 가상 머신들이 하이퍼바이저보다 상위 레벨에서 실행된다. 일부 실시예들에서, 타입 2 하이퍼바이저는 사용자의 운영체제의 컨텍스트 내에서 실행되어, 타입 2 하이퍼바이저는 사용자의 운영체제와 상호 작용을 한다. 다른 실시예들에서, 가상화 환경의 하나 이상의 가상화 서버들(201)은 대신에 타입 1 하이퍼바이저(도시안됨)를 포함할 수 있다. 타입 1 하이퍼바이저는 하드웨어 계층(310) 내의 자원들 및 하드웨어에 직접 액세스함으로써 가상화 서버(301) 상에서 실행될 수 있다. 즉, 타입 2 하이퍼바이저(302)는 도시된 바와 같이 호스트 운영체제(314)를 통해 시스템 자원에 액세스하지만, 타입 1 하이퍼바이저는 호스트 운영체제(314) 없이 모든 시스템 자원들에 직접 액세스할 수 있다. 타입 1 하이퍼바이저는 가상화 서버(301)의 하나 이상의 물리적 프로세서들(308) 상에서 직접 실행될 수 있고, 물리적 메모리(316)에 저장된 프로그램 데이터를 포함할 수 있다.

[54] 일부 실시예들에서, 하이퍼바이저(302)는 운영체제(330) 또는 제어 프로그램(320)이 시스템 자원들에 직접 액세스하도록 시뮬레이션하는 임의의 방식으로 가상 머신들(332) 상에서 실행되는 운영체제들(330) 또는 제어 프로그램들(320)에 가상 자원을 제공할 수 있다. 시스템 자원들은 물리적 디바이스들(306), 물리적 디스크들(304), 물리적 프로세서들(308), 물리적 메모리(316) 및 가상화 서버(301) 하드웨어 계층(310)에 포함된 임의의 다른 컴포넌트를 포함할 수 있으나 이에 제한되는 것은 아니다. 하이퍼바이저(302)는 가상 하드웨어를 에뮬레이트하고, 물리적 하드웨어를 파티셔닝하고, 물리적 하드웨어를 가상화하고, 그리고/또는 컴퓨팅 환경들에 대한 액세스를 제공하는 가상 머신을 실행시키기 위해 사용될 수 있다. 또 다른 실시예들에서, 하이퍼바이저(302)는 가상화 서버(301) 상에서 실행되는 가상 머신(332)에 대한 메모리 파티셔닝 및 프로세서 스케쥴링을 제어한다. 하이퍼바이저(302)는 켈리포니아 팔로 알토에 위치한 VMWare, Inc.에 의해 제조된 것들; 그 개발이 오픈 소스 Xen.org 커뮤니티에 의해 감독되는 오픈 소스 상품인 XEN 하이퍼바이저; 마이크로소프트에 의해 제공되는 vHyperV, VirtualServer 또는 virtual PC 하이퍼바이저들 또는 기타 하이퍼바이저를 포함할 수 있다. 일부 실시예들에서, 가상화 서버(301)는, 게스트 운영체제들이 실행될 수 있는 가상 머신 플랫폼을 생성하는 하이퍼바이저(302)를 실행시킨다. 이들 실시예들에서, 가상화 서버(301)는 호스트 서버로서 지칭될 수 있다. 이러한 가상화 서버의 예로서 플로리다, 포트 로더데일에 위치한 Citrix Systems, Inc.에 의해 제공되는 XEN SERVER를 들 수 있다.

[55] 하이퍼바이저(302)는 게스트 운영체제(330)가 실행되는 하나 이상의 가상 머신들(332B-C)(일반적으로 332)을 생성할 수 있다. 일부 실시예들에서, 하이퍼바이저(302)는 가상 머신 이미지를 로드하여 가상 머신(332)을 생성할 수 있다. 다른 실시예들에서, 하이퍼바이저(302)는 가상 머신(332) 내에서 게스트 운영체제(330)를 실행시킬 수 있다. 또 다른 실시예에서, 가상 머신(332)은 게스트 운영체제(330)를 실행시킬 수 있다.

[56] 가상 머신들(332)을 생성하는 것에 추가하여, 하이퍼바이저(302)는 적어도 하나의 가상 머신(332)의 실행을 제어할 수 있다. 다른 실시예들에서, 하이퍼바이저(302)는 가상화 서버(301)에 의해 제공되는 적어도 하나의 하드웨어 자원(예컨대, 하드웨어 계층(310) 내에서 이용가능한 임의의 하드웨어 자원)의 추상화로 하나 이상의 가상 머신(332)을 제시할 수 있다. 다른 실시예들에서, 하이퍼바이저(302)는 가상 머신들(332)이 가상화 서버(301)에서 이용가능한 물리적 프로세서들(308)에 액세스하는 방식을 제어할 수 있다. 물리적 프로세서들(308)에 대한 액세스를 제어하는 것은, 가상 머신(332)이 프로세서(308)에 대한 액세스를 가져야 하는지 여부 및 물리적 프로세서 기능들이 가상 머신(332)에 어떻게 제공되는지를 결정하는 것을 포함할 수 있다.

[57] 도 3에 도시된 바와 같이, 가상화 서버(301)는 하나 이상의 가상 머신들(332)을 호스팅 또는 실행할 수 있다. 가상 머신(332)은, 프로세서(308)에 의해 실행될 때 물리적 컴퓨터의 동작을 모방하여, 가상 머신(332)이 물리적 컴퓨팅 디바이스와 매우 유사하게 프로그램들 및 프로세스들을 실행할 수 있도록 하는 실행 가능한 명령들의 세트이다. 도 3은 가상화 서버(301)가 3 개의 가상 머신들(332)을 호스팅하는 실시예를 예시하고 있으나, 다른 실시예들에서, 가상화 서버(301)는 임의의 개수의 가상 머신들(332)을 호스팅할 수 있다. 하이퍼바이저(302)는, 일부 실시예들에서, 각각의 가상 머신(332)에 물리적 하드웨어, 메모리, 프로세서 및 그 가상 머신(332)이 이용할 수 있는 다른 시스템 자원들의 고유한 가상 뷰(unique virtual view)를 제공한다. 일부 실시예들에서, 고유한 가상 뷰는 가상 머신 퍼미션(permission)들, 하나 이상의 가상 머신 식별자에 대한 정책 엔진(policy engine)의 애플리케이션, 가상 머신에 액세스하는 사용자, 가상 머신 상에서 실행되는 애플리케이션들, 가상 머신에 의해 액세스되는 네트워크들 또는 다른 임의의 원하는 기준 중 하나 이상에 기초할 수 있다. 예컨대, 하이퍼바이저(302)는 하나 이상의 비보안(unsecure) 가상 머신들(332) 및 하나 이상의 보안 가상 머신들(332)을 생성할 수 있다. 비보안 가상 머신들(332)은 보안 가상 머신들(332)이 액세스하도록 허락될 수 있는 자원들, 하드웨어, 메모리 위치들 및 프로그램들에 액세스하는 것이 차단될 수 있다. 다른 실시예들에서, 하이퍼바이저(302)는 각각의 가상 머신(332)에게 물리적 하드웨어, 메모리, 프로세서 및 가상 머신(332)이 이용할 수 있는 다른 시스템 자원들에 대한 실질적으로 유사한 뷰를 제공할 수 있다.

[58] 각각의 가상 머신(332)은 가상 디스크(326A-C)(일반적으로 326) 및 가상 프로세서(328A-C)(일반적으로 328)를 포함할 수 있다. 가상 디스크(326)는, 일부 실시예들에서, 가상화 서버(301)의 하나 이상의 물리적 디스크들(304) 또는 가상화 서버(301)의 하나 이상의 물리적 디스크들(304)의 일부분에 대한 가상화된 뷰(virtualized view)이다. 물리적 디스크들(304)에 대한 가상화된 뷰는 하이퍼바이저(302)에 의해 생성, 제공 및 관리될 수 있다. 일부 실시예들에서, 하이퍼바이저(302)는 각각의 가상 머신(332)에 물리적 디스크들(304)의 고유한 뷰를 제공한다. 따라서, 이들 실시예들에서, 각각의 가상 머신(332)에 포함된 특정 가상 디스크(326)는 다른 가상 디스크들(326)과 비교하여 고유할 수 있다.

[59] 가상 프로세서(328)는 가상화 서버(301)의 하나 이상의 물리적 프로세서들(308)의 가상화된 뷰일 수 있다. 일부 실시예들에서, 물리적 프로세서들(308)의 가상화된 뷰는 하이퍼바이저(302)에 의해 생성, 제공 및 관리될 수 있다. 일부 실시예들에서, 가상 프로세서(328)는 적어도 하나의 물리적 프로세서(308)와 실질적으로 전부 동일한 특징들을 가진다. 다른 실시예들에서, 가상 프로세서(308)는 물리적 프로세서(308)의 수정된 뷰(modified view)를 제공하며, 따라서 가상 프로세서(328)의 특징들 중 적어도 일부는 대응하는 물리적 프로세서(308)의 특징들과 상이하다.

[60] 도 4를 추가로 참조하면, 본원에서 설명된 일부 양상들은 클라우드 기반의 환경에서 구현될 수 있다. 도 4는 클라우드 컴퓨팅 환경(또는 클라우드 시스템)(400)의 예를 예시한다. 도 4에서 알 수 있는 바와 같이, 클라이언트 컴퓨터들(411-414)은 클라우드 관리 서버(410)와 통신하여 클라우드 시스템의 컴퓨팅 자원들(예컨대, 호스트 서버들(403), 저장 자원들(404) 및 네트워크 자원들(405))에 액세스할 수 있다.

[61] 관리 서버(410)는 하나 이상의 물리적 서버 상에서 구현될 수 있다. 특히, 관리 서버(410)는, 예컨대, 플로리다, 포트 로더데일에 위치한 Citrix Systems, Inc.의 CLOUDSTACK 또는 OPENSTACK을 실행시킬 수 있다. 관리 서버(410)는 클라우드 하드웨어 및 소프트웨어 자원들, 예컨대 호스트 컴퓨터들(403), 데이터 저장 디바이스들(404), 네트워킹 디바이스들(405)을 포함하는 다양한 컴퓨팅 자원들을 관리할 수 있다. 클라우드 하드웨어 및 소프트웨어 자원들은 사설 및/또는 공중 컴포넌트들을 포함할 수 있다. 예컨대, 클라우드는 사설 네트워크를 통해 그리고/또는 하나 이상의 특정 고객들 또는 클라이언트 컴퓨터들(411-414)에 의해 사용될 사설 클라우드로서 구성될 수 있다. 다른 실시예들에서, 공중 클라우드들 또는 하이브리드 공중-사설 클라우드들은 개방형 또는 하이브리드 네트워크들을 통해 다른 고객들에 의해 사용될 수 있다.

[62] 관리 서버(410)는 클라우드 운영자들 및 클라우드 고객들이 클라우드 시스템과 상호 작용할 수 있도록 하는 사용자 인터페이스들을 제공하도록 구성될 수 있다. 예컨대, 관리 서버(410)는 API들의 세트 및/또는 하나 이상의 클라우드 운영자 콘솔 애플리케이션들(예컨대, 웹-기반 스탠드얼론 애플리케이션들)에, 클라우드 운영자들이 클라우드 자원들을 관리하고, 가상화 계층을 구성하고, 고객 계정들을 관리하고 그리고 다른 클라우드 운영 태스크들을 수행할 수 있도록 하는 사용자 인터페이스들을 제공할 수 있다. 관리 서버(410)는 또한, 사용자 인터페이스들이 클라이언트 컴퓨터(411-414)를 통해 최종 사용자(end user)로부터의 클라우드 컴퓨팅 요청들 예컨대, 클라우드 내에서 가상 머신들을 생성, 수정 또는 제거하기 위한 요청들을 수신하도록 구성되면서, API들의 세트 및/또는 하나 이상의 고객 콘솔 애플리케이션을 포함할 수 있다. 클라우드 컴퓨터들(411-414)은 인터넷 또는 다른 통신 네트워크를 통해 관리 서버(410)에 연결할 수 있고, 관리 서버(410)에 의해 관리되는 컴퓨팅 자원들 중 하나 이상의 자원에 대한 액세스를 요청할 수 있다. 클라이언트 요청들에 응답하여, 관리 서버(410)는 클라이언트 요청들에 기초하여 클라우드 시스템의 하드웨어 계층의 물리적 자원들을 선택 및 공급하도록 구성된 자원 관리자를 포함할 수 있다. 예컨대, 관리 서버(410) 및 클라우드 시스템의 추가적인 컴포넌트들은 네트워크(예컨대, 인터넷)를 통해 클라이언트 컴퓨터들(411-414)에서 고객들에 대한 가상 머신들 및 이들의 동작 환경들(예컨대, 하이퍼바이저들, 저장 자원들, 네트워크 엘리먼트들에 의해 제공되는 서비스 등)을 제공, 생성 및 관리하도록 구성되어, 고객에게 연산 자원(computational resource)들, 데이터 저장 서비스들, 네트워크 기능들 및 컴퓨터 플랫폼 및 애플리케이션 지원을 제공할 수 있다. 클라우드 시스템들은 또한, 보안 시스템들, 개발 환경들, 사용자 인터페이스들 등을 포함하는 다양한 특정 서비스들을 제공하도록 구성될 수 있다.

[63] 특정 클라이언트들(411-414)은 예컨대 동일한 최종 사용자들 또는 동일한 회사 또는 조직과 연계된 상이한 사용자들을 대신하여 가상 머신들을 생성하는 상이한 클라이언트 컴퓨터들과 관련될 수 있다. 다른 예들에서, 특정 클라이언트들(411-414)은 예컨대 상이한 회사들 또는 조직들과 연계된 사용자들과는 관련되지 않을 수 있다. 관련되지 않은 클라이언트들의 경우에, 어느 한 사용자의 가상 머신들 또는 스토리지에 대한 정보는 다른 사용자들에게 숨겨질 수 있다.

[64] 이제 클라우드 컴퓨팅 환경의 물리적 하드웨어 계층을 참조하면, 가용 존(availability zone)들(401-402)(또는 존(zone)들)은 물리적 컴퓨팅 자원들의 콜로케이트된 세트(collocated set)를 지칭할 수 있다. 존들은 컴퓨팅 자원들의 전체 클라우드의 다른 존들로부터 지리적으로 떨어져 있을 수 있다. 예컨대, 존(401)은 캘리포니아에 위치한 제 1 클라우드 데이터센터일 수 있고, 존(402)은 플로리다에 위치한 제 2 클라우드 데이터센터일 수 있다. 관리 서버(410)는 가용 존들 중 하나에, 또는 떨어진 위치에 위치할 수 있다. 각각의 존은, 게이트웨이를 통해, 관리 서버(410)와 같은, 존 외부에 있는 디바이스들과 인터페이싱하는 내부 네트워크를 포함할 수 있다. 클라우드의 최종 사용자들(예컨대, 클라이언트들(411-414))은 존들 사이를 구분할 수 있거나, 구분할 수 없을 수 있다. 예컨대, 최종 사용자들은 특정 메모리량, 프로세싱 전력 및 네트워크 능력들을 갖는 가상 머신의 생성을 요청할 수 있다. 관리 서버(410)는 사용자의 요청에 응답할 수 있으며, 가상 머신이 존(401) 또는 존(402)의 자원들을 사용하여 생성되었는지의 여부를 사용자가 알 필요 없이 가상 머신을 생성하기 위한 자원들을 할당할 수 있다. 다른 예들에서, 클라우드 시스템은 최종 사용자들이, 가상 머신들(또는 다른 클라우드 자원들)이 특정 존에 또는 존 내의 특정 자원들(403-405) 상에 할당되는 것을 요청하도록 할 수 있다.

[65] 이러한 예에서, 각각의 존(401-402)은 다양한 물리적 하드웨어 컴포넌트들(또는 컴퓨팅 자원들)(403-405), 예컨대, 물리적 호스팅 자원들(또는 프로세싱 자원들), 물리적 네트워크 자원들, 물리적 저장 자원들, 스위치들, 및 클라우드 컴퓨팅 서비스들을 고객들에게 제공하기 위해 사용될 수 있는 추가적인 하드웨어 자원들의 어레인지먼트(arrangement)를 포함할 수 있다. 클라우드 존(401-402)의 물리적 호스팅 자원들은, 앞서 설명된 가상화 서버들(301)과 같은 하나 이상의 컴퓨터 서버들(403)을 포함할 수 있고, 이 서버들은 가상 머신 인스턴스들을 생성 및 호스팅하도록 구성될 수 있다. 클라우드 존(401 또는 402)의 물리적 네트워크 자원들은 방화벽들, 네트워크 어드레스 번역기들, 로드 밸런서들, VPN(virtual private network) 게이트웨이들, DHCP(Dynamic Host Configuration Protocol) 라우터들 등과 같은 네트워크 서비스를 클라우드 고객들에게 제공하도록 구성된 하드웨어 및/또는 소프트웨어를 포함하는 하나 이상의 네트워크 엘리먼트들(405)(예컨대, 네트워크 서비스 제공자들)을 포함할 수 있다. 클라우드 존(401-402)의 저장 자원들은 저장 디스크들(예컨대, SSD(solid state drive)들, 자기 하드 디스크들 등) 및 다른 저장 디바이스들을 포함할 수 있다.

[66] 도 4에 도시된 예시적인 클라우드 컴퓨팅 환경은 또한 (예컨대, 도 1 내지 도 3에 도시된 바와 같은) 가상화 계층과, 가상 머신들을 생성 및 관리하고 클라우드의 물리적 자원들을 이용하여 고객들에게 다른 서비스들을 제공하도록 구성된 추가적인 하드웨어 및/또는 소프트웨어 자원들을 포함할 수 있다. 가상화 계층은 도 3에서 앞서 설명된 바와같은 하이퍼바이저들과, 네트워크 가상화들, 저장 가상화들 등을 제공하는 다른 컴포넌트들을 포함할 수 있다. 가상화 계층은 물리적 자원 계층과 별개의 계층으로 될 수 있거나, 물리적 자원 계층과 동일한 하드웨어 및/또는 소프트웨어 자원들의 일부 또는 전부를 공유할 수 있다. 예컨대, 가상화 계층은 가상화 서버(403)들 각각에 설치된 하이퍼바이저와 물리적 컴퓨팅 자원들을 포함할 수 있다. 공지된 클라우드 시스템, 예컨대 WINDOWS AZURE (워싱턴 레드몬드에 위치한 Microsoft Corporation), AMAZON EC2 (워싱턴 시애틀에 위치한 Amazon.com Inc.), IBM BLUE CLOUD (뉴욕 아몽크에 위치한 IBM Corporation) 등이 대안적으로 사용될 수 있다.

[67] 기업 모빌리티 관리 아키텍처

[68] 도 5는 BYOD 환경에서 사용하기 위한 기업 모빌리티 기술 아키텍처(500)를 나타낸다. 아키텍처는 모바일 디바이스(502)의 사용자가 모바일 디바이스(502)를 사용하여 기업 자원 또는 개인 자원에 액세스하고, 모바일 디바이스(502)를 개인적 용도로 사용하도록 한다. 사용자는 기업에 의해 사용자에게 제공된 모바일 디바이스(502) 또는 사용자에 의해 구매된 모바일 디바이스(502)를 이용하여 이와 같은 기업 서비스들(508) 또는 기업 자원들(504)에 액세스할 수 있다. 사용자는 단지 비지니스용으로 또는 비지니스 및 개인용으로 모바일 디바이스(502)를 활용할 수 있다. 모바일 디바이스는 iOS 운영체제, 및 안드로이드 운영체제 등을 실행할 수 있다. 기업은 모바일 디바이스(504)를 관리하기 위한 정책들을 구현하는 것을 선택할 수 있다. 이 정책들은 모바일 디바이스가 식별되거나, 보안 또는 보안 검증되고 기업 자원들에 대해 선택적으로 또는 전체적으로 액세스할 수 있도록 방화벽 또는 게이트웨이를 통해 주입될 수 있다. 정책들은 모바일 디바이스 관리 정책들, 모바일 애플리케이션 관리 정책들, 모바일 데이터 관리 정책들, 또는 모바일 디바이스, 애플리케이션 및 데이터 관리 정책들의 일부 조합일 수 있다. 모바일 디바이스 관리 정책들의 애플리케이션을 통해 관리되는 모바일 디바이스(504)는 등록 디바이스로서 지칭될 수 있다.

[69] 모바일 디바이스의 운영체제는 관리 파티션(managed partition)(510) 및 비관리 파티션(unmanaged partition)(512)으로 분리될 수 있다. 관리 파티션(510)은 관리 파티션 상에서 실행되는 애플리케이션들 및 관리 파티션에 저장되는 데이터를 보안하기 위한 정책들이 자신에 적용되게 할 수 있다. 관리 파티션상에서 실행되는 애플리케이션들은 보안 애플리케이션들일 수 있다. 보안 애플리케이션들은 이메일 애플리케이션들, 웹 브라우징 애플리케이션들, SaaS(software-as-a-service) 액세스 애플리케이션들, 윈도우즈 애플리케이션 액세스 애플리케이션들 등일 수 있다. 보안 애플리케이션들은 보안 네이티브 애플리케이션들(514), 보안 애플리케이션 런처(518)에 의해 실행되는 보안 원격 애플리케이션들(522), 보안 애플리케이션 런처(518)에 의해 실행되는 가상화 애플리케이션들(526) 등일 수 있다. 보안 네이티브 애플리케이션들(514)은 보안 애플리케이션 래퍼(wrapper)(520)에 의해 래핑될 수 있다. 보안 애플리케이션 래퍼(520)는 보안 네이티브 애플리케이션이 디바이스상에서 실행될 때 모바일 디바이스(502)상에서 실행되는 통합 정책들을 포함할 수 있다. 보안 애플리케이션 래퍼(520)는 보안 네이티브 애플리케이션(514)의 실행시 요청된 태스크를 완료하기 위하여 보안 네이티브 애플리케이션(514)이 요구할 수 있는, 기업에서 호스팅되는 자원들을 모바일 디바이스(502)상에서 실행되는 보안 네이티브 애플리케이션(514)에게 알려주는 메타-데이터를 포함할 수 있다. 보안 애플리케이션 런처(518)에 의해 실행되는 보안 원격 애플리케이션들(522)은 보안 애플리케이션 런처 애플리케이션(518) 내에서 실행될 수 있다. 보안 애플리케이션 런처(518)에 의해 실행되는 가상화 애플리케이션(526)은 모바일 디바이스(502)상의 자원들, 기업 자원들(504) 등을 활용할 수 있다. 보안 애플리케이션 런처(518)에 의해 실행되는 가상화 애플리케이션들(526)에 의해 모바일 디바이스(502)상에서 사용되는 자원들은 사용자 상호작용 자원들, 프로세싱 자원들 등을 포함할 수 있다. 사용자 상호작용 자원들은 키보드 입력, 마우스 입력, 카메라 입력, 촉각 입력, 오디오 입력, 시각 입력, 제스처 입력 등을 수집하여 전송하기 위하여 사용될 수 있다. 프로세싱 자원들은 사용자 인터페이스를 제시하고, 기업 자원들(504)로부터 수신된 데이터를 프로세싱하는 것 등을 수행하기 위하여 사용될 수 있다. 보안 애플리케이션 런처(518)에 의해 실행되는 가상화 애플리케이션들(526)에 의해 기업 자원들(504)에서 사용되는 자원들은 사용자 인터페이스 생성 자원들, 프로세싱 자원들 등을 포함할 수 있다. 사용자 인터페이스 생성 자원들은 사용자 인터페이스를 어셈블리하고, 사용자 인터페이스를 수정하며, 사용자 인터페이스를 리프레시하는 것 등을 수행하기 위하여 사용될 수 있다. 프로세싱 자원들은 정보를 생성하고, 정보를 판독하며, 정보를 업데이트하며, 정보를 삭제하는 것 등을 수행하기 위하여 사용될 수 있다. 예컨대, 가상화 애플리케이션은 GUI와 연관된 사용자 상호작용들을 기록하고, 이들을 서버 애플리케이션에 통신할 수 있으며, 여기서 서버 애플리케이션은 서버상에서 동작하는 애플리케이션에 대한 입력으로서 사용자 상호작용 데이터를 사용할 것이다. 이러한 어레인지먼트에서, 기업은 서버측상의 애플리케이션 뿐만아니라 애플리케이션과 연관된 데이터, 파일들 등을 유지하는 것을 선택할 수 있다. 기업이 모바일 디바이스상에서 전개하기 위하여 일부 애플리케이션들을 보안함으로써 본원의 원리들에 따라 그 일부 애플리케이션들을 "결집(mobilize)시키는" 것을 선택할 수 있는 반면에, 이러한 어레인지먼트는 또한 특정 애플리케이션들을 위해 선택될 수 있다. 예컨대, 일부 애플리케이션들이 모바일 디바이스상에서 사용하기 위하여 보안될 수 있는 반면에, 다른 애플리케이션들은 모바일 디바이스상에서 전개하기 위하여 준비되거나 또는 전용될 수 없으며, 따라서 기업은 가상화 기술들을 통해 준비되지 않은 애플리케이션들에의 모바일 사용자 액세스를 제공하는 것을 선택할 수 있다. 다른 예로서, 기업은 모바일 디바이스에 대한 애플리케이션을 커스터마이징(customizing)하는 것이 매우 어렵거나 또는 그렇지 않은 경우에 바람직하지 않을 대량 및 복합 데이터 세트들을 가진 대규모 복합 애플리케이션들(예컨대, 자료 자원 계획 애플리케이션들)을 가질 수 있으며, 따라서, 기업은 가상화 기술들을 통해 애플리케이션에의 액세스를 제공하는 것을 선택할 수 있다. 또 다른 예로서, 기업은 심지어 보안된 모바일 환경에서 조차 기업이 너무 민감하게 생각할 수 있는 고보안 데이터(예컨대, 인적 자원 데이터, 고객 데이터, 엔지니어링 데이터)를 유지하는 애플리케이션을 가질 수 있으며, 따라서 기업은 이러한 애플리케이션들 및 데이터에 대한 모바일 액세스를 허용하기 위하여 가상화 기술들을 사용하는 것을 선택할 수 있다. 기업은 서버측에서 동작하는 것이 더 적절한 것으로 여겨지는 애플리케이션들에 대한 액세스를 허용하기 위하여, 가상화 애플리케이션 뿐만아니라 모바일 디바이스상의 완전하게 보안된 그리고 완전하게 기능적인 애플리케이션들을 제공하는 것을 선택할 수 있다. 일 실시예에서, 가상화 애플리케이션은 보안 저장 위치들 중 하나의 위치에 있는 모바일 폰상에 일부 데이터, 파일들 등을 저장할 수 있다. 기업은 예컨대 다른 정보를 허용하지 않으면서 특정 정보가 폰상에 저장되도록 하는 것을 선택할 수 있다.

[70] 본원에서 설명된 바와같은 가상화 애플리케이션와 관련하여, 모바일 디바이스는 GUI들을 제시하고 이후 GUI와의 사용자 상호작용들을 기록하도록 설계되는 가상화 애플리케이션을 가질 수 있다. 애플리케이션은 애플리케이션과의 사용자 상호작용들로서 서버측 애플리케이션에 의해 사용될 사용자 상호작용들을 서버에 통신할 수 있다. 이에 응답하여, 서버측상의 애플리케이션은 새로운 GUI를 모바일 디바이스에 다시 전송할 수 있다. 예컨대, 새로운 GUI는 정적 페이지, 동적 페이지, 애니메이션 등일 수 있다.

[71] 관리 파티션상에서 실행되는 애플리케이션들은 안정화된 애플리케이션들일 수 있다. 안정화된 애플리케이션들은 디바이스 관리자(524)에 의해 관리될 수 있다. 디바이스 관리자(524)는 안정화된 애플리케이션들을 모니터링하고 문제점들을 검출하여 제거하기 위한 기술들을 활용할 수 있는데, 이러한 문제점들은 그 문제점들을 검출하여 제거하는데 상기 기술들이 활용되지 않았다면 불안정한 애플리케이션을 유발하였을 것이다.

[72] 보안 애플리케이션들은 모바일 디바이스의 관리 파티션(510)의 보안 데이터 컨테이너(528)에 저장된 데이터에 액세스할 수 있다. 보안 데이터 컨테이너에서 보안된 데이터는 보안 래핑된 애플리케이션들(514), 보안 애플리케이션 런처(518)에 의해 실행되는 애플리케이션들, 보안 애플리케이션 런처(518)에 의해 실행되는 가상화 애플리케이션들(526) 등에 의해 액세스될 수 있다. 보안 데이터 컨테이너(528)에 저장된 데이터는 파일들, 데이터베이스들 등을 포함할 수 있다. 보안 데이터 컨테이너(528)에 저장된 데이터는 보안 애플리케이션들(532) 사이에서 공유되는 특정 보안 애플리케이션(530)에 한정된 데이터 등을 포함할 수 있다. 보안 애플리케이션에 한정된 데이터는 보안 범용 데이터(534) 및 고보안 데이터(538)를 포함할 수 있다. 보안 범용 데이터는 AES 128-비트 암호화 등과 같은 고강화 암호화를 사용할 수 있는 반면에, 고보안 데이터(538)는 AES 256-비트 암호화와 같은 초고강화 암호화를 사용할 수 있다. 보안 데이터 컨테이너(528)에 저장된 데이터는 디바이스 관리자(524)로부터의 커맨드의 수신시에 디바이스로부터 제거될 수 있다. 보안 애플리케이션들은 듀얼-모드 옵션(540)을 가질 수 있다. 듀얼 모드 옵션(540)은 비보안 모드에서 보안 애플리케이션을 동작하기 위한 옵션을 사용자에게 제시할 수 있다. 비보안 모드에서, 보안 애플리케이션들은 모바일 디바이스(502)의 비관리 파티션(512)상의 비보안 데이터 컨테이너(542)에 저장된 데이터에 액세스할 수 있다. 비보안 데이터 컨테이너에 저장된 데이터는 개인 데이터(544)일 수 있다. 비보안 데이터 컨테이너(542)에 저장된 데이터는 또한 모바일 디바이스(502)의 비관리 파티션(512)상에서 실행되는 비보안 애플리케이션들(548)에 의해 액세스될 수 있다. 비보안 데이터 컨테이너(542)에 저장된 데이터는 보안 데이터 컨테이너(528)에 저장된 데이터가 모바일 디바이스(502)로부터 제거될 때 모바일 디바이스(502)상에서 유지될 수 있다. 기업은 사용자에 의해 소유되거나 또는 라이센싱되거나 또는 제어되는 개인 데이터, 파일들 및/또는 애플리케이션들(개인 데이터)을 남기거나 또는 그렇지 않은 경우에 보존하면서 기업에 의해 소유되거나 라이센싱되거나 또는 제어되는 선택된 또는 모든 데이터, 파일들 및/또는 애플리케이션들(기업 데이터)을 모바일 디바이스로부터 제거하는 것을 원할 수 있다. 이러한 동작은 선택적 지움(selective wipe)으로서 지칭될 수 있다. 본원에서 설명된 양상들에 따라 기업 및 개인 데이터가 배열되는 경우에, 기업은 선택적 지움을 수행할 수 있다.

[73] 모바일 디바이스는 기업의 기업 자원들(504) 및 기업 서비스들(508)에, 공중 인터넷(548) 등에 연결할 수 있다. 모바일 디바이스는 가상 사설 네트워크 연결들을 통해 기업 자원들(504) 및 기업 서비스들(508)에 연결할 수 있다. 가상 사설 네트워크 연결들은 특정 애플리케이션들(550), 특정 디바이스들, 모바일 디바이스상의 특정 보안 영역들 등(552)에 특정적일 수 있다. 예컨대, 폰의 보안 영역에 래핑된 애플리케이션들 각각은 애플리케이션 특정 VPN에의 액세스가 가능한 경우에 사용자 또는 디바이스 속성 정보와 함께 애플리케이션과 연관된 속성들에 기초하여 승인될 수 있도록 애플리케이션 특정 VPN를 통해 기업 자원들에 액세스할 수 있다. 가상 사설 네트워크 연결들은 마이크로소프트 교환 트래픽, 마이크로소프트 액티브 디렉토리 트래픽, HTTP 트래픽, HTTPS 트래픽, 애플리케이션 관리 트래픽 등을 전달할 수 있다. 가상 사설 네트워크 연결들은 싱글-사인-온 인증 프로세스(single-sign-on authentication process)들(554)을 지원하고 인에이블할 수 있다. 싱글-사인-온 프로세스들은 사용자로 하여금 인증 크리덴셜들의 단일 세트를 제공하도록 할 수 있으며, 이후 인증 크리덴셜들은 인증 서비스(558)에 의해 검증된다. 이후, 인증 서비스(558)는 사용자가 각각의 개별 기업 자원(504)에 인증 크리덴셜들을 제공하는 것을 필요로 하지 않고 다수의 기업 자원들(504)에 대한 사용자 액세스를 승인할 수 있다.

[74] 가상 사설 네트워크 연결들은 액세스 게이트웨이(560)에 의해 설정 및 관리될 수 있다. 액세스 게이트웨이(560)는 모바일 디바이스(502)에 기업 자원들(504)을 전달하는 것을 관리하고, 가속시키며 그리고 개선하는 성능 강화 특징들을 포함할 수 있다. 액세스 게이트웨이는 또한 모바일 디바이스(502)로부터 공중 인터넷(548)으로 트래픽을 재-라우팅할 수 있으며, 따라서 모바일 디바이스(502)가 공중 인터넷(548)상에서 실행되는 공개적으로 이용가능한 비보안 애플리케이션들에 액세스하도록 할 수 있다. 모바일 디바이스는 트랜스포트 네트워크(562)를 통해 액세스 게이트웨이에 연결할 수 있다. 트랜스포트 네트워크(562)는 유선 네트워크, 무선 네트워크, 클라우드 네트워크, 근거리 통신망, 도시권 통신망, 광역 통신망, 공중 네트워크, 사설 네트워크 등일 수 있다.

[75] 기업 자원들(504)은 이메일 서버들, 파일 공유 서버들, SaaS 애플리케이션들, 웹 애플리케이션 서버들, 윈도우즈 애플리케이션 서버들 등을 포함할 수 있다. 이메일 서비스들은 교환 서버들, Lotus Notes 서버들 등을 포함할 수 있다. 파일 공유 서버들은 ShareFile 서버들 등을 포함할 수 있다. SaaS 애플리케이션들은 Salesforce 등을 포함할 수 있다. 윈도우즈 애플리케이션 서버들은 로컬 윈도우즈 운영체제 등 상에서 실행되는 것으로 의도된 애플리케이션들을 제공하도록 구축된 일부 애플리케이션 서버를 포함할 수 있다. 기업 자원들(504)은 전제-기반 자원(premise-based resource)들, 클라우드 기반 자원들 등일 수 있다. 기업 자원들(504)은 직접적으로 또는 액세스 게이트웨이(560)를 통해 모바일 디바이스(502)에 의해 액세스될 수 있다. 기업 자원들(504)은 트랜스포트 네트워크(562)를 통해 모바일 디바이스(502)에 의해 액세스될 수 있다. 트랜스포트 네트워크(562)는 유선 네트워크, 무선 네트워크, 클라우드 네트워크, 근거리 통신망, 도시권 통신망, 광역 네트워크, 공중 네트워크, 사설 네트워크 등일 수 있다.

[76] 기업 서비스들(508)은 인증 서비스들(558), 위협 검출 서비스(564), 디바이스 관리 서비스들(524), 파일 공유 서비스들(568), 정책 관리자 서비스들(570), 소셜 통합 서비스들(572), 애플리케이션 제어기 서비스(574) 등을 포함할 수 있다. 인증 서비스들(558)은 사용자 인증 서비스들, 디바이스 인증 서비스들, 애플리케이션 인증 서비스들, 데이터 인증 서비스들 등을 포함할 수 있다. 인증 서비스들(558)은 인증서들을 사용할 수 있다. 인증서들은 기업 자원들(504) 등에 의해 모바일 디바이스(502)상에 저장될 수 있다. 모바일 디바이스(502)상에 저장된 인증서들은 모바일 디바이스상의 암호화된 위치에 저장될 수 있으며, 인증서는 인증할 때 등에 사용하기 위해 모바일 디바이스(502)상에 일시적으로 저장될 수 있다. 위협 검출 서비스들(564)은 침입 검출 서비스들, 비허가 액세스 시도 검출 서비스들 등을 포함할 수 있다. 비허가 액세스 시도 검출 서비스들은 디바이스들, 애플리케이션들, 데이터 등에 액세스하기 위한 비허가 시도들을 포함할 수 있다. 디바이스 관리 서비스들(524)은 구성, 프로비저닝, 보안, 지원, 모니터링, 보고 및 해체 서비스들을 포함할 수 있다. 파일 공유 서비스들(568)은 파일 관리 서비스들, 파일 저장 서비스들, 파일 컬래버레이션 서비스들 등을 포함할 수 있다. 정책 관리 서비스들(570)은 디바이스 정책 관리자 서비스들, 애플리케이션 정책 관리자 서비스들, 데이터 정책 관리자 서비스들 등을 포함할 수 있다. 소셜 통합 서비스들(572)은 접촉 통합 서비스들, 컬래버레이션 서비스들, 페이스북, 트위터 및 LinkedIn 등과 같은 소셜 네트워크와의 통합 등을 포함할 수 있다. 애플리케이션 제어기 서비스들(574)은 관리 서비스들, 프로비저닝 서비스들, 전개 서비스들, 할당 서비스들, 철회 서비스들, 래핑 서비스들 등을 포함할 수 있다.

[77] 기업 모빌리티 기술 아키텍처(500)는 애플리케이션 스토어(578)를 포함할 수 있다. 애플리케이션 스토어(578)는 비-래핑된 애플리케이션들(580), 사전-래핑된 애플리케이션들(582) 등을 포함할 수 있다. 애플리케이션들은 애플리케이션 제어기(574)로부터 애플리케이션 스토어(578)에 파퓰레이트될 수 있다. 애플리케이션 스토어(578)는 액세스 게이트웨이(560), 공중 네트워크(548) 등을 통해 모바일 디바이스(502)에 의해 액세스될 수 있다. 애플리케이션 스토어는 사용자 인터페이스를 사용할 때 이해하기 쉽고 용이하도록 제공될 수 있다. 애플리케이션 스토어(578)는 소프트웨어 전개 키트(584)에 대한 액세스를 제공할 수 있다. 소프트웨어 전개 키트(584)는 본 상세한 설명에서 이전에 설명된 바와같이 애플리케이션을 래핑함으로써 사용자에 의해 선택된 애플리케이션들을 보안하는 능력을 사용자에게 제공할 수 있다. 이후, 소프트웨어 전개 키트(584)를 사용하여 래핑된 애플리케이션은 애플리케이션 제어기(574)를 사용하여 애플리케이션 스토어(578)에서 파퓰레이트함으로써 모바일 디바이스(502)에게 이용가능하게 만들어질 수 있다.

[78] 기업 모빌리티 기술 아키텍처(500)는 관리 및 분석 능력(588)을 포함할 수 있다. 관리 및 분석 능력(588)은 자원들이 어떻게 사용되는지, 자원들이 얼마나 자주 사용되는지 등에 관한 정보를 제공할 수 있다. 자원들은 디바이스들, 애플리케이션들, 데이터 등을 포함할 수 있다. 자원들이 어떻게 사용되는지는 어떤 디바이스들이 어떤 애플리케이션들을 다운로드하는지, 어떤 애플리케이션들이 어떤 데이터에 액세스하는지 등을 포함할 수 있다. 자원들이 얼마나 자주 사용되는지는 애플리케이션들이 얼마나 자주 다운로드되었는지, 데이터의 특정 세트가 애플리케이션에 의해 얼마나 많은 횟수로 액세스되었는지 등을 포함할 수 있다.

[79] 도 6은 다른 예시적인 기업 모빌리티 관리 시스템(600)이다. 도 5를 참조하여 앞서 설명된 모빌리티 관리 시스템(500)의 일부 컴포넌트들은 간략화를 위해 생략되었다. 도 6에 도시된 시스템(600)의 아키텍처는 도 5를 참조로 하여 앞서 설명된 시스템(500)의 아키텍처와 많은 측면에서 유사하고, 앞서 언급되지 않은 추가적인 특징들을 포함할 수 있다.

[80] 이 경우, 좌측은 클라이언트 에이전트(604)를 가진 등록 모바일 디바이스(602)를 나타낸다. 클라이언트 에이전트(604)는 원격 또는 모바일 디바이스상에서 실행되는 에이전트를 포함할 수 있다. 클라이언트 에이전트(604)는 원격 디바이스들에 대한 클라우드 자원들을 포함하는 게이트웨이 서버(606)와 상호작용할 수 있다. 게이트웨이 서버(606)는 우측 위쪽에 도시된 것과 같은 다양한 기업 자원들(608) 및 서비스들(609), 예컨대 익스체인지(Exchange), 쉐어포인트(Sharepoint), PKI 자원들, 케베로스 자원들, 인증서 발행 서비스에 액세스하기 위하여 사용될 수 있다. 상세히 도시되지는 않았지만, 모바일 디바이스(602)는 또한 애플리케이션들을 선택하여 다운로드하기 위한 기업 애플리케이션 스토어(StoreFront)와 상호 작용할 수 있다.

[81] 클라이언트 에이전트(604)는, HDX/ICA 디스플레이 원격 프로토콜을 이용하여 액세스되는, 기업 데이터 센터에서 호스팅되는 윈도우즈 앱들/데스크탑들에 대한 UI(사용자 인터페이스) 매개자(intermediary)로서 동작할 수 있다. 클라이언트 에이전트(604)는 또한 모바일 디바이스(602) 상의 네이티브 애플리케이션들, 예컨대 네이티브 iOS 또는 안드로이드 애플리케이션들의 설치 및 관리를 지원한다. 예컨대, 앞의 도면에 도시된 관리 애플리케이션(610)(메일, 브라우저, 래핑 애플리케이션)은 모두 디바이스 상에서 국부적으로 실행되는 네이티브 애플리케이션들이다. 클라이언트 에이전트(604) 및 모바일 애플리케이션 관리 프로토콜(이후 간략하게 "MAMP"), 예컨대 본 아키텍처의 MDX(mobile experience technology)는 기업 자원들/서비스들(608)에 대한 연결 및 SSO(single sign on)와 같은 정책 기반 관리 능력들 및 사양들을 제공하기 위해 동작한다. 클라이언트 에이전트(604)는 기업, 예컨대 게이트웨이 서버(606) 컴포넌트들에 대한 주요 사용자 인증을 처리한다. 클라이언트 에이전트(604)는 모바일 디바이스(602)상의 MAMP 관리 애플리케이션들(610)의 행위를 제어하기 위하여 게이트웨이 서버(606)로부터 정책들을 획득한다.

[82] 네이티브 애플리케이션들(610)과 클라이언트 에이전트(604) 사이의 보안 IPC 링크들(612)은 클라이언트 에이전트가 각각의 애플리케이션을 "래핑"하는 MAMP 프레임워크(614)에 의해 시행될 정책들을 적용하도록 하는 관리 채널을 나타낸다. 모바일 디바이스(602)상의 MAMP-인에이블링 애플리케이션은 직접 링킹(direct linking) 또는 래핑 프로세스에 의해 MAMP를 통합할 수 있다. 따라서, MAMP는 모바일 디바이스(602)상의 애플리케이션들을 관리하기 위하여 사용될 수 있다. 간략화를 위하여, MAMP는 애플리케이션을 관리하기 위한 프로토콜을 설명하기 위하여 본원에서 사용된다. 그러나, 서버로부터 정보를 수신하여 모바일 애플리케이션 또는 모바일 디바이스(602)상의 진단을 수행할 수 있는 임의의 에이전트들을 비롯하여, 모바일 디바이스(602)상의 애플리케이션들을 관리할 수 있는, 모바일 디바이스상의 에이전트를 제공하는 임의의 프로토콜이 사용될 수 있다. IPC 채널(612)은 또한 기업 자원들(608)에 대한 연결 및 SSO를 인에이블하는 크리덴셜 및 인증 정보를 클라이언트 에이전트(604)가 적용하도록 한다. 마지막으로, IPC 채널(612)은 MAMP 프레임워크(614)가 클라이언트 에이전트(604)에 의해 구현되는 사용자 인터페이스 기능들, 예컨대 온라인 및 오프라인 인증을 인보크하도록 한다.

[83] 클라이언트 에이전트(604)와 게이트웨이 서버(606) 사이의 통신들은 근본적으로 각각의 네이티브 관리 애플리케이션(610)을 래핑하는 MAMP 프레임워크(614)로부터 관리 채널을 확장한다. MAMP 프레임워크(614)는 클라이언트 에이전트(604)로부터 정책 정보를 요청하며, 클라이언트 에이전트(604)는 차례로 게이트웨이 서버(606)로부터 정책 정보를 요청한다. MAMP 프레임워크(614)는 인증을 요청하며, 클라이언트 에이전트(604)는 게이트웨이 서버(606)(이는 또한 NetScaler Access Gateway로서 공지됨)의 게이트웨이 서비스 부분에 로그인한다. 이하에서 더 완전히 설명되는 바와같이, 클라이언트 에이전트(604)는 또한 로컬 데이터 볼트(vault)들(616)에 대한 암호화 키들을 유도하기 위한 입력 자료를 생성하거나 또는 PKI 보호 자원들에 직접 인증을 인에이블할 수 있는 클라이언트 인증서들을 제공할 수 있는 서비스들을 게이트웨이 서버(606)상에서 지원할 것을 호출할 수 있다.

[84] 더 상세히, MAMP 프레임워크(614)는 각각의 관리 애플리케이션(610)을 래핑한다. 이는 명시적 구축 단계를 통해 또는 구축후 프로세싱 단계를 통해 통합될 수 있다. MAMP 프레임워크(614)는 애플리케이션(610)의 제 1 론치시 클라이언트 에이전트(604)와 "페어링"하여, 보안 IPC 채널을 초기화하고 그 애플리케이션에 대한 정책을 획득할 수 있다. MAMP 프레임워크(614)는 국부적으로 적용하는 정책의 관련 부분들, 예컨대 로컬 OS 서비스들이 어떻게 사용될 수 있는지 또는 로컬 OS 서비스들이 애플리케이션(610)과 어떻게 상호작용할 수 있는지를 한정하는 억제 정책들 중 일부 및 클라이언트 에이전트 로그인 종속성들을 시행할 수 있다.

[85] MAMP 프레임워크(614)는 인증 및 내부 네트워크 액세스를 용이하게 하기 위하여 보안 IPC 채널(612)을 통해 클라이언트 에이전트(604)에 의해 제공된 서비스들을 사용할 수 있다. 사설 및 공유 데이터 볼트들(616)(컨테이너들)의 키 관리는 또한 관리 애플리케이션들(610)과 클라이언트 에이전트(604) 간의 적절한 상호작용들에 의해 관리될 수 있다. 볼트들(616)은 온라인 인증 이후에만 이용가능하게 만들어질 수 있거나 또는 정책에 의해 허용되는 경우에 오프라인 인증 이후에 이용가능하게 만들어질 수 있다. 볼트들(616)의 첫번째 사용은 온라인 인증을 요구할 수 있으며, 오프라인 액세스는 온라인 인증이 다시 요구되기 전에 최대 정책 리프레시 기간으로 제한될 수 있다.

[86] 내부 자원들에의 네트워크 액세스는 액세스 게이트웨이(606)를 통해 개별 관리 애플리케이션들(610)로부터 직접 발생할 수 있다. MAMP 프레임워크(614)는 각각의 애플리케이션(610) 대신에 네트워크 액세스를 조정하는 것을 담당한다. 클라이언트 에이전트(604)는 온라인 인증 이후에 획득된 적절한 시간 제한된 2차 크리덴셜들을 제공함으로써 이들 네트워크 연결들을 용이하게 할 수 있다. 리버스 웹 프록시 연결들 및 엔드-투-엔드 VPN-스타일 터널들(618)과 같은 다수의 네트워크 연결 모드들이 사용될 수 있다.

[87] 메일 및 브라우저 관리 애플리케이션들(610)은 특별한 상태를 가지며, 임의적 래핑된 애플리케이션들이 일반적으로 이용가능하지 않을 수 있는 시설들을 사용할 수 있다. 예컨대, 메일 애플리케이션은 전체 AG 로그온을 요구하지 않고 연장된 시간 기간 동안 그 메일 애플리케이션이 익스체인지에 액세스하도록 하는 특별한 백그라운드 네트워크 액세스 메커니즘을 사용할 수 있다. 브라우저 애플리케이션은 상이한 종류의 데이터를 분리하기 위하여 다수의 사설 데이터 볼트들을 사용할 수 있다.

[88] 이러한 아키텍처는 다양한 다른 보안 특징들의 통합을 지원한다. 예컨대, 일부 경우들에서, 게이트웨이 서버(606)(자신의 게이트웨이 서비스들을 포함함)는 AD 패스워드들을 검증할 필요가 없을 것이다. 일부 상황들에서 AD 패스워드가 일부 사용자들에 대한 인증 인자로서 사용될 수 있는지는 기업의 재량으로 맡겨질 수 있다. 상이한 인증 방법들은 사용자가 온라인인 경우 또는 오프라인인 경우에 (즉, 네트워크에 연결되거나 또는 연결되지 않는 경우에) 사용될 수 있다.

[89] 스텝 업(step up) 인증은 게이트웨이 서버(606)가 강한 인증을 요구하는 높게 분류된 데이터에 대해 액세스하도록 허용되는 관리 네이티브 애플리케이션들(610)을 식별할 수 있고 비록 이것이, 재인증이 이전의 약한 로그인 레벨 이후에 사용자에 의해 요구되는 것을 의미할지라도, 적절한 인증을 수행한 이후에만 이들 애플리케이션들에 대한 액세스가 허용되도록 하는 것이 특징이다.

[90] 이러한 솔루션의 다른 보안 특징은 모바일 디바이스(602)상의 데이터 볼트들(616)(컨테이너들)의 암호화이다. 볼트들(616)은 파일들, 데이터베이스들, 및 구성들을 포함하는 모든 온-디바이스 데이터가 보호되도록 암호화될 수 있다. 온라인 볼트들의 경우에 키들이 서버(게이트웨이 서버(606))에 저장될 수 있으며, 오프-라인 볼트들의 경우에 키들의 로컬 복사본이 사용자 패스워드에 의해 보호될 수 있다. 데이터가 보안 컨테이너(616)에서 디바이스(602)상에 국부적으로 저장될 때, AES 256 암호화 알고리즘이 최소로 활용되는 것이 바람직하다.

[91] 다른 보안 컨테이너 특징들이 또한 구현될 수 있다. 예컨대, 애플리케이션(610)내에서 발생하는 모든 보안 이벤트들이 로깅되어 백엔드에 보고되는 로깅 특징이 포함될 수 있다. 데이터 지움이 지원될 수 있고, 예컨대 애플리케션(610)이 탬퍼링(tampering)을 검출하면 연관된 암호화 키들이 랜덤 데이터로 쓰여질 수 있으며, 따라서 사용자 데이터가 파괴된 파일 시스템상에는 힌트가 남겨지지 않는다. 스크린샷 보호(screenshot protection )는 임의의 데이터가 스크린샷들에 저장되는 것을 애플리케이션이 방지할 수 있는 다른 특징이다. 예컨대, 키 윈도우의 은폐 특성은 YES로 세팅될 수 있다. 이는 스크린상에 현재 디스플레이되고 있는 모든 콘텐츠가 은폐되도록 할 수 있으며, 따라서 임의의 콘텐츠가 정상적으로 상주할 블랭크 스크린샷을 초래한다.

[92] 로컬 데이터 전달은 예컨대 임의의 데이터가 애플리케이션 컨테이너 외부로 국부적으로 전달되는 것을 방지함으로써, 예컨대 임의의 데이터를 복사하거나 또는 이를 외부 애플리케이션에 송신함으로써 방지될 수 있다. 키보드 캐시 특징은 민감한 텍스트 필드들에 대한 자동보정 기능을 디스에이블하도록 동작할 수 있다. SSL 인증 검증은 동작가능할 수 있으며, 따라서 애플리케이션은 그것이 키체인에 저장되는 대신에 서버 SSL 인증서를 상세하게 검증한다. 암호화 키 생성 특징은 (오프라인 액세스가 요구되는 경우에) 디바이스상의 데이터를 암호화하기 위하여 사용되는 키가 사용자에 의해 공급되는 패스프레이즈(passphrase)를 사용하여 생성되도록 사용될 수 있다. 이는 오프라인 액세스가 요구되지 않는 경우에 서버측에서 랜덤하게 생성되어 저장되는 다른 키들과 XOR 연산될 수 있다. 키 유도 함수들은 사용자 패스워드로부터 생성된 키들이 키의 암호 해시를 생성하는 것보다 오히려 KDF들(키 유도 함수들, 특히 PBKDF2)을 사용하도록 동작할 수 있다. 후자는 무차별 대입 공격(brute force attack) 또는 디렉토리 공격에 취약한 키를 만든다.

[93] 추가로, 하나 이상의 초기화 벡터들이 암호화 방법들에서 사용될 수 있다. 초기화 벡터는 동일한 암호화된 데이터의 다수의 복사본들이 상이한 암호 텍스트 출력을 초래하도록 할 것이며, 따라서 리플레이 및 암호해독 공격들이 방지된다. 이는 또한 데이터를 암호화하기 위하여 사용되는 특정 초기화 벡터가 알려지지 않은 경우에 암호화 키가 도난당했을지라도 공격자가 임의의 데이터를 암호해독하는 것을 방지할 것이다. 추가로, 인증 및 이후 암호해독이 사용될 수 있으며, 여기서 사용자가 애플리케이션 내에서 인증된 이후에만 애플리케이션 데이터가 암호해독된다. 다른 특징은 필요할 때만 (디스크가 아니라) 메모리에서 유지될 수 있는, 메모리내의 민감 데이터와 관련될 수 있다. 예컨대, 로그인 크리덴션들은 로그인 이후에 메모리로부터 지워질 수 있으며, 암호화 키들 및 목적-C 인스턴스 변수들 내의 다른 데이터가 저장되지 않는데, 왜냐하면 이들 데이터는 용이하게 참조될 수 있기 때문이다. 대신에, 메모리는 이들을 위해 수동으로 할당받을 수 있다.

[94] 인액티비티 타임아웃(inactivity timeout)이 구현될 수 있으며, 여기서 인액티비티의 정책-정의된 기간 이후에 사용자 세션이 종료된다.

[95] MAMP 프레임워크(614)로부터의 데이터 누출은 다른 방식들로 방지될 수 있다. 예컨대, 애플리케이션(610)이 배경으로 될 때, 메모리는 미리 결정된(구성가능) 시간 기간 이후에 클리어(clear)될 수 있다. 배경화 될 때, 전경화 프로세스(foregrounding process)를 고정시키기 위하여 애플리케이션의 마지막으로 디스플레이된 스크린에서 스탭샵이 취해질 수 있다. 스크린샵은 컨피덴셜 데이터를 포함할 수 있고 따라서 클리어되어야 한다.

[96] 다른 보안 특징은 하나 이상의 애플리케이션들에 액세스하기 위해 AD(active directory)(622) 패스워드를 사용하지 않고 OTP(one time password)(620)를 사용하는 것과 관련된다. 일부 경우들에서, 일부 사용자들은 그들의 AD 패스워드를 알지못하며(또는 그들의 AD 패스워드를 알도록 허용되지 않으며) 따라서 이들 사용자들은 OTP(620)를 사용하여, 예컨대 SecurID와 같은 하드웨어 OTP 시스템을 사용하여 인증할 수 있다(OTP들은 또한 Entrust 또는 Gemalto와 같은 상이한 벤더들에 의해 제공될 수 있다). 일부 경우들에서, 사용자가 사용자 ID로 인증한 이후에, 텍스트가 OTP(620)와 함께 사용자에게 송신된다. 일부 경우들에서, 이는 프롬프트가 단일 필드인 경우에 단지 온라인 사용을 위해서만 구현될 수 있다.

[97] 오프라인 패스워드는 기업 정책을 통해 오프라인 사용이 허락되는 애플리케이션들(610)에 대한 오프라인 인증을 위하여 구현될 수 있다. 예컨대, 기업은 StoreFront가 이러한 방식으로 액세스되는 것을 원할 수 있다. 이러한 경우에, 클라이언트 에이전트(604)는 사용자가 맞춤형 오프라인 패스워드를 세팅할 것을 요구할 수 있으며, AD 패스워드는 사용되지 않는다. 게이트웨이 서버(606)는 표준 윈도우즈 서버 패스워드 복잡성 요건들이 수정될 수 있을 지라도 이 요건들에 의해 기술되는 것과 같은 최소 길이, 캐릭터 클래스 구성(character class composition) 및 패스워드들의 수명에 대해 패스워드 표준들을 제어하고 시행하기 위한 정책들을 제공할 수 있다.

[98] 다른 특징은 (MAMP 마이크로 VPN 특징을 통해 PKI 보호 웹 자원들에 액세스하기 위한) 2차 크리덴셜들로서 특정 애플리케이션들(610)에 대한 클라이언트측 인증서를 인에이블하는 것과 관련된다. 예컨대, @WorkMail과 같은 애플리케이션은 이러한 인증서를 활용할 수 있다. 이러한 경우에, ActiveSync 프로토콜를 사용한 인증서-기반 인증이 지원될 수 있으며, 여기서 클라이언트 에이전트(604)로부터의 인증서는 게이트웨이 서버(606)에 의해 리트리브되고 키체인으로 사용될 수 있다. 각각의 관리 애플리케이션은 게이트웨이 서버(606)에서 정의되는 라벨에 의해 식별되는 하나의 연관된 클라이언트 인증서를 가질 수 있다.

[99] 게이트웨이 서버(606)는 관련된 관리 애플리케이션들이 내부 PKI 보호 자원들을 인증하도록 클라이언트 인증서들을 발행하는 것을 지원하기 위하여 기업 특수 목적 웹 서비스와 상호작용할 수 있다.

[100] 클라이언트 에이전트(604) 및 MAMP 프레임워크(614)는 내부 PKI 보호 네트워크 자원들을 인증하기 위한 클라이언트 인증서들을 획득하여 사용하는 것을 지원하도록 시행될 수 있다. 예컨대 보안 및/또는 분리 요건들의 다양한 레벨들을 매칭시키기 위하여 2개 이상의 인증서가 지원될 수 있다. 인증서들은 메일 및 브라우저 관리 애플리케이션들에 의해, 궁극적으로 임의적 래핑된 애플리케이션들에 의해 사용될 수 있다 (MAMP 프레임워크가 https 요청들을 중재하는 것이 타당한 웹 서비스 스타일 통신 패턴들을 이들 애플리케이션들이 사용하는 경우에).

[101] iOS상에서의 MAMP 클라이언트 인증서 지원은 각각의 사용 기간 동안 각각의 관리 애플리케이션에서 PKCS 12 BLOB (Binary Large Object)를 iOS 키체인에 임포트(import)하는 것에 의존할 수 있다. MAMP 클라이언트 인증서 지원은 사설 인-메모리 키 스토리지(private in-memory key storage)를 가진 HTTPS 구현을 사용할 수 있다. 클라이언트 인증서는 iOS 키체인에서 결코 제시되지 않을 것이며 그리고 강하게 보호되는 "온라인-전용" 데이터 값을 잠재적으로 제외하고 지속되지 않을 것이다.

[102] 상호 SSL은 또한 모바일 디바이스(602)가 기업에게 인증될 것을 요구함으로써 추가 보안을 제공하도록 구현될 수 있으며, 이와 반대의 경우도 마찬가지다. 게이트웨이 서버(606)에 인증하기 위한 가상 스마트 카드들이 또한 구현될 수 있다.

[103] 제한된 그리고 전체 케베로스(Kerberos) 지원 둘다가 추가 특징들일 수 있다. 전체 지원 특징은 AD 패스워드 또는 신뢰성 있는 클라이언트 인증서를 사용하여 AD(622)에 대해 전체 케베로스 로그인을 수행하고 HTTP 교섭 인증 챌린지(challenge)들에 응답하기 위하여 케베로스 서비스 티켓들을 획득하는 능력과 관련된다. 제한된 지원 특징은 AGEE에서의 강제 위임(constrained delegation)과 관련되며, 여기서 AGEE는 케베로스 프로토콜 전환을 인보크하는 것을 지원하며, 따라서 이는 HTTP 교섭 인증 챌린지들에 응답하여 (강제 위임 대상인) 케베로스 서비스 티켓들을 획득하여 사용할 수 있다. 이러한 메커니즘은 리버스 웹 프록시(CVPN으로도 지칭됨) 모드에서 그리고 http(https가 아님) 연결들이 VPN 및 마이크로 VPN 모드에서 프록시될 때 작동한다.

[104] 다른 특징은 애플리케이션 컨테이너 로킹 및 지움과 관련되며, 이는 자일-브레이크(jail-break) 또는 루팅 검출시 자동적으로 발생하며 관리 콘솔로부터의 푸시 커맨드(pushed command)로서 발생할 수 있으며 그리고 애플리케이션(610)이 실행되지 않을 때 조차 원격 지움 기능을 포함할 수 있다.

[105] StoreFront 및 앱 제어기의 멀티-사이트 아키텍처 또는 구성이 지원될 수 있으며, 이는 사용자들로 하여금 실패의 경우에 여러 상이한 위치들 중 하나의 위치로부터 서비스받도록 한다.

[106] 일부 경우들에서, 관리 애플리케이션들(610)은 API(예시적인 OpenSSL)를 통해 인증서 및 개인 키에 액세스하도록 허용될 수 있다. 기업의 신뢰성 있는 관리 애플리케이션들(610)은 애플리케이션의 클라이언트 인증서 및 개인 키를 사용하여 특정 공개 키 동작들을 수행하도록 허용될 수 있다. 따라서, 예컨대, 애플리케이션이 브라우저와 같이 동작하며 인증서 액세스가 요구되지 않을 때, 애플리케이션이 "나는 누구인가"에 대한 인증서를 판독할 때, 애플리케이션이 보안 세션 토큰을 구축하기 위하여 인증서를 사용할 때, 그리고 애플리케이션이 중요한 데이터에 대한 디지털 서명(예컨대, 트랜잭션 로그)을 위해 또는 일시적 데이터 암호화를 위해 개인 키들을 사용할 때, 다양한 사용의 경우들이 식별되어 처리될 수 있다.

[107] 프록시를 사용한 자원들에 대한 보안 액세스

[108] 도 7은 클라이언트 디바이스(705), 프록시 디바이스(710), 자원(들)(720) 및/또는 인증 서비스(들)(715)를 가진 예시적인 시스템을 도시한다. 도 8은 클라이언트 디바이스(705) 및 프록시 디바이스(710)의 예시적인 상세 도면을 도시한다. 이들 엘리먼트들은 본원에서 설명된 하나 이상의 양상들을 구현할 수 있다. 이들 양상들의 간략한 요약이 이하에서 제공된 추가 예들과 함께 지금 제공될 것이다. 클라이언트 디바이스(705)는 프록시 디바이스(710)를 사용하여 하나 이상의 자원들(720) 및/또는 인증 서비스들(715)과 통신할 수 있다. 일부 양상들에서, 클라이언트 디바이스(705)는 자원들(720) 및/또는 인증 서비스들(715)과 직접 통신하도록 구성되지 않을 수 있다. 예컨대, 클라이언트 디바이스(705) 및 자원들(720)은 상이한 인증 및/또는 통신 프로토콜들을 사용할 수 있다. 프록시 디바이스(710)는 이들 상이한 프로토콜들 사이에서 전환될 수 있다. 부가적으로 또는 대안적으로, 프록시 디바이스(710)는 이하의 예들에서 설명되는 바와같이 추가 장점들을 제공할 수 있다.

[109] 클라이언트 디바이스(705)는 문서들, 이메일들, 서비스들, 파일들 등과 같은 자원들(720)에 대한 요청을 프록시 디바이스(710)에 송신할 수 있다. 프록시 디바이스(710)는 자원(720)에 요청을 포워드할 수 있으며, 이에 응답하여 프록시 디바이스(710)와 자원(720) 사이의 인증이 개시될 수 있다. 인증동안 하나 이상의 시점들에서, 자원들(720)은 예컨대 클라이언트 인증서로부터 서명을 요청할 수 있다. 프록시 디바이스(710)는 클라이언트 인증서에 대해 직접 액세스하지 못할 수 있으며, 따라서 프록시 디바이스(710)는 예컨대 클라이언트 디바이스(705)가 클라이언트 인증서에 대한 액세스를 제어하는 경우에 인증 프로세스에서 클라이언트 디바이스(705)를 수반할 수 있다. 예컨대, 프록시 디바이스(710)는 클라이언트 디바이스(705)가 클라이언트 인증서(또는 클라이언트 인증서에 포함된 개인 키)를 사용하여 인증 메시지를 서명하거나 또는 암호해독하거나 또는 특정 보안 인증서의 사용자에 의한 선택 또는 이용가능한 보안 인증서들의 리스트를 리턴(return)할 것을 요청할 수 있다.

[110] 프록시 디바이스(710)는 프록시 디바이스(710)와 자원/인증 서버 사이의 인증 세션을 식별하는 콘텍스트 정보를 클라이언트 디바이스(705)에 제공할 수 있다. 예컨대, 이하의 예들에서 더 상세히 설명되는 바와같이, 콘텍스트 정보는 프록시 디바이스(710)와 자원(720) 사이에서 그리고/또는 프록시 디바이스(710)와 인증 서비스(715) 사이에서 교환되는 (또는 교환될) 인증 정보의 데이터 구조를 식별할 수 있다. 클라이언트 디바이스(705)는 프록시 디바이스(710)와 자원/인증 서버 간의 인증 세션을 검증하거나 또는 그렇지 않은 경우 확인하기 위하여 콘텍스트 정보를 사용할 수 있다. 일단 콘텍스트 정보가 검증되면, 클라이언트 디바이스(705)는 요청된 서명을 프록시 디바이스(710)에 제공할 수 있으며, 프록시 디바이스(710)는 자원(720) 및/또는 인증 서비스(715)와의 인증을 완료할 수 있다. 이후, 프록시 디바이스(710)는 클라이언트 디바이스(705)에 의해 요청된 자원을 리트리브하고 이를 클라이언트 디바이스(705)에 제공할 수 있다.

[111] 클라이언트 디바이스(705)는 엔드 포인트 디바이스, 클라이언트 컴퓨터들(107 또는 109), 단말들(240), 클라이언트 컴퓨터들(411-414), 모바일 디바이스(502), 모바일 디바이스(602), 또는 임의의 다른 디바이스 중 임의의 것을 포함할 수 있다. 예컨대, 모바일 디바이스는 스마트폰, 태블릿 등 중 임의의 것을 포함할 수 있다. 클라이언트 디바이스(705)상에서 하나 이상의 애플리케이션들이 실행될 수 있다. 애플리케이션은 보호 자원(protected resource), 예컨대 기업 자원에 액세스하기를 원할 수 있으며, 그 애플리케이션(또는 다른 애플리케이션들)에 포함된 모듈이 이들 보호 자원들에 대한 액세스를 용이하게 할 수 있다. 예컨대, 도 8를 참조하면, 클라이언트 디바이스(705)상에서 실행되는 애플리케이션은 자원에 대한 요청(예컨대, HTTP 요청)을 MAMP 프레임워크(805)에 송신할 수 있으며, MAMP 프레임워크(805)는 프록시 디바이스(710)와의 통신들을 용이하게 할 수 있다. 일부 양상들에서, MAMP 프레임워크(805)는 클라이언트 디바이스(705)상에서 권한이 부여된 애플리케이션(privileged application)으로서 실행될 수 있다. MAMP 프레임워크(805)는 이전에 설명된 바와같이 MAMP 프레임워크(614)에 의해 제공된 기능들의 전부 또는 일부를 포함할 수 있다.

[112] 클라이언트 디바이스(705)는 또한 인증 목적들을 위해 서명하기 위하여 사용될 수 있는 하나 이상의 클라이언트 인증서들을 저장하는 키 스토어(815)에의 액세스를 용이하게 하는 PKOperation SDK 모듈(810)을 가질 수 있다. 예컨대, 클라이언트 디바이스(705)는 클라이언트 디바이스(705)의 사용자를 나타내는 클라이언트 인증서에 대한 액세스를 허가하거나 또는 이 클라이언트 인증서를 소유할 수 있다. 일부 양상들에서, 인증서는 기업-발행 인증서일 수 있다. 인증서는 암호 모듈을 가진 물리적 스마트 카드에 구속될 수 있다. 다시 말해서, 암호 시크릿은 스마트 카드에 국한될 수 있다. 사용자는 스마트 카드 보호 인증서에 액세스하도록 클라이언트 디바이스(705)에 허가할 수 있다. 대안적으로, 인증서는 가상 스마트 카드에 구속될 수 있으며, 이 가상 스마트 카드는 키를 보호하기 위하여 하드웨어 및/또는 소프트웨어 모듈들을 사용할 수 있다. 클라이언트 디바이스(705) 및/또는 클라이언트 디바이스(705)의 제거가능 하드웨어 모듈은 인증서 및 개인 키를 저장하도록 프로비저닝 프로세스(provisioning process)에 의해 허가될 수 있다. 사용자는 클라이언트 인증 개인 키를 수반하는 동작들을 허가하기 위하여 클라이언트 디바이스(705)를 사용하여 PIN 코드를 입력하도록 요구될 수 있다. 클라이언트 디바이스(705)와 별개인 다른 외부 디바이스(예컨대, 다른 스마트폰)는 인증서를 제어할 수 있으며, 클라이언트 디바이스(705)는 외부 디바이스에 의해 제어되는 인증서에 액세스하기 위하여 맞춤형 판독기 인터페이스를 활용할 수 있다.

[113] 일부 실시예들에서, 클라이언트 인증서 및/또는 개인 키는 클라이언트 디바이스(705) 또는 물리적 스마트 카드에 국한될 수 있다. 따라서, 클라이언트 디바이스(705)는 키의 제어를 유지할 수 있다. 만일 키를 사용한 인증이 요구되면, 클라이언트 디바이스(705)는 인증 프로세스에 연관될 필요가 없을 수 있다. 이는 인증 개인 키로 수행되는 동작들이 클라이언트 디바이스(705)가 의도한 동작들임을 클라이언트 디바이스(705)가 확신하도록 한다. 일부 조직들은 특정 동작들에 대한 부인방지(non-repudiation)를 실현하기 위하여 스마트 카드들을 사용할 수 있으며, 이는 조직 의해 발행된 인증서를 전적으로 사용할 수 있는 권한을 사용자들이 갖을 것을 요구할 수 있다. 예컨대, 문서 서명은 명시적인 사용자 권한을 요구할 수 있는 반면에, 특정 시스템들에 대한 인증은 명시적인 사용자 권한을 요구하지 않을 수 있다. 이러한 확실성을 제공하기에 적절한 메커니즘(들)은 액세스되고 있는 자원의 성질, 수반되는 프록시 디바이스, 및 클라이언트 디바이스(705)가 동작하는 방법에 의존할 수 있다.

[114] 프록시 디바이스(710)는 서버(예컨대, 서버들(201, 206, 301, 410)), 컴퓨팅 디바이스, 액세스 게이트웨이(560), 게이트웨이 서버(606), 또는 임의의 다른 디바이스 중 하나 이상을 포함할 수 있다. 프록시 디바이스(710)는 클라이언트 디바이스(705)와 기업 자원들 또는 다른 네트워크들 사이의 통신들을 용이하게 할 수 있다. 예컨대, 클라이언트 디바이스(705)의 사용자는 인증을 요구하는 기업 자원들에 액세스하기를 원할 수 있으며, 프록시 디바이스(710)는 액세스를 중재할 수 있다. 클라이언트 디바이스(705)는 예컨대 클라이언트 디바이스(705)가 자원들에 직접 액세스할 수 없는 경우에 자원에 액세스하기 위하여 프록시 디바이스(710)를 사용할 수 있다. 예컨대, 클라이언트 디바이스(705)는 기업 자원들에 의해 활용되는 프로토콜을 위해 구성되지 않을 수 있다. 일부 양상들에서, 기업 자원은 인증을 위하여 PKINIT를 사용하여 케베로스를 구현할 수 있으나, 클라이언트 디바이스(705)는 PKINIT를 사용하여 케베로스를 구현하지 않을 수 있다. 유사하게, 기업 자원은 클라이언트 인증서 인증을 사용하여 SSL을 구현할 수 있으나, 클라이언트 디바이스(705)는 클라이언트 인증서 인증을 사용하여 SSL을 구현하지 않을 수 있다. 대신에, 클라이언트 디바이스(705) 및 프록시 디바이스(710)는 표준 컴포넌트들을 가지고 공지된 인증 프레임워크들에 적합한 프로토콜을 사용하여 통신할 수 있다. 프록시 디바이스(710)는 자원에 대한 제 1 프로토콜(예컨대, 케베로스 또는 SSL)과 클라이언트 디바이스(705)에 대한 제 2 상이한 프로토콜(예컨대, HTTP 또는 HTTPS)사이에서 전환될 수 있다. 프록시 디바이스(710)를 활용함으로써, 클라이언트 디바이스들은 기업 자원에 의해 사용되는 복잡하거나 또는 상이한 프로토콜을 이해하고 동작시킬 필요가 없을 수도 있다. 이들 예들에서, 프록시 디바이스(710)는 클라이언트 역할을 할 수 있다. 그러나, 프록시 디바이스(710)는 클라이언트 인증서 개인 키를 제어하지 않을 수도 있다.

[115] 프록시 디바이스(710)는 예컨대 클라이언트 디바이스(705)가 자원들에 직접 액세스하도록 허락되지 않는 경우에, 클라이언트 디바이스(705)의 액세스 능력들이 제한되는 경우 및/또는 프록시 디바이스(710)가 성능을 개선하거나 또는 바람직한 인터페이스를 제공함으로써 액세스를 강화하는 경우에 다른 환경들의 자원들에 대한 액세스를 용이하게 하기 위하여 사용될 수 있다. 프록시 디바이스(710)는 또한 강화된 보안을 용이하게 할 수 있다. 예컨대, 케베로스 자원 인증은 케베로스 KDC들(예컨대, 액티브 디렉토리 도메인 제어기들)로부터 서비스 티켓들을 획득하는 것을 요구할 수 있다. 그러나, KDC들 그 자체는 일부 클라이언트 디바이스들에게 직접 액세스가능하지 않아야 하는 민감 기업 자원들을 포함할 수 있다. 이들 경우들에서, 케베로스 인증은 신뢰성 있는 프록시 디바이스(710)의 사용을 요구할 수 있다. 다른 예로서, 프록시 디바이스(710)는 기업의 DMS 네트워크에서 전개되는 강화된 통신 게이트웨이(hardened communication gateway)일 수 있다. 추가 보안 장점들을 제공하기 위하여, 프록시 디바이스(710)는 마치 프록시 디바이스(710)가 존재하지 않았던 것처럼 클라이언트 디바이스(705)와 기업 자원들 사이의 통신 흐름을 투명 엔드(transparent end)가 끝내도록 하는 것보다 오히려, 기업 자원들에 프록싱되고 있는 통신들을 검사할 수 있을 것이다. 즉, 프록시 디바이스(710)는 클라이언트 디바이스(705)가 어떤 자원들을 사용중인지그리고 클라이언트 디바이스(705)가 어떤 프로토콜들을 활용하고 있는지의 지식을 가질 수 있다. 이하의 예들에서 더 상세히 논의되는 바와같이, 프록시 디바이스(710)는 또한 프록시 디바이스(710)와 인증 서비스(715) 및/또는 자원(720) 사이의 인증 세션의 하나 이상의 양상들을 식별하는 콘텍스트 정보를 클라이언트 디바이스(705)에 제공할 수 있다. 클라이언트 디바이스(705)는 이러한 콘텍스트 정보를 사용하여 서명을 요구하는 프록시 디바이스(710)에 의해 제공되는 데이터를 서명해야 하는지를 결정할 수 있다.

[116] 도 8을 참조하면, 프록시 디바이스(710)는 하드웨어 모듈 및/또는 소프트웨어 모듈일 수 있는 패킷 엔진(820)을 포함할 수 있다. 패킷 엔진(820)은 클라이언트 디바이스(705) 및/또는 자원과의 통신들을 용이하게 할 수 있다. 프록시 디바이스(710)는 또한 세션 캐시(825)를 포함할 수 있다. 이하의 예들에서 추가로 설명되는 바와같이, 세션 캐시(825)는 프록시 디바이스(710)와 하나 이상의 자원들 또는 자원들을 저장한 서버들 사이의 통신들을 가능하게 하기 위하여 (예컨대, 케베로스 세션들을 위한) 세션 키 및/또는 티켓을 저장할 수 있다. 프록시 디바이스(710)는 클라이언트 디바이스(705)와 함께 인증을 관리하여 예컨대 클라이언트 디바이스(705)로부터 서명을 획득하도록 구성된 클라이언트-측 인증 모듈(830)을 포함할 수 있다. 케베로스 인증을 위하여, 클라이언트-측 인증 모듈(830)은 공개 키 형태의 케베로스 인증 프로토콜(예컨대, PKINIT 프로토콜)의 클라이언트 측을 구현하는 PKINIT 모듈(이는 라이크와이즈 데몬(likewise daemon)으로 지칭될 수 있음)을 포함할 수 있다. 예컨대, 이는 케베로스의 개방 소스 구현들로부터 이용가능한 키나이트 커맨드 라인 프로그램(kinit command line program)일 수 있다.

[117] 프록시 디바이스(710)는 또한 클라이언트 인증 개인 키에 액세스하기 위한 세부사항들을 추출하기 위하여 클라이언트-측 인증 모듈(830)에 의해 사용되는 라이브러리 모듈(835)(예컨대, PKOperation 프록시 SDK(835))를 포함할 수 있다. 케베로스에 대하여, 스마트 카드들에 구속된 클라이언트 인증서들에 액세스하기 위한 PKCS#11 API 규격을 구현하는 PKOperation 프록시 SDK(835)가 사용될 수 있다. PKOperation 프록시 SDK(835)는 PKCS#11의 부분들을 구현하고, 클라이언트 디바이스(705)에 대해 리모팅될 수 있는 형태로 관련 인증서 동작들을 패키징할 수 있다. PKCS#11 API를 사용함으로써, MIT와 같은 표준 케베로스 구현을 포함할 수 있는 케베로스 구현은 수정될 필요가 없다. 이는 예컨대 보안 픽스(fix)들이 케베로스 제품에 대해 만들어지는 경우에 그 케베로스 제품을 유지하는 것을 더 쉽게 만든다. 패킷 엔진(820), 세션 캐시(825), 클라이언트-측 인증 모듈(830) 및 PKOperation 프록시 SDK(835)는 하드웨어 및/또는 소프트웨어 모듈들을 포함할 수 있으며, 이들이 수행할 수 있는 동작들은 이하의 예들에서 더 상세히 설명될 것이다. 일부 양상들에서, 프록시 디바이스(710)는 하나 이상의 프로세서 및 컴퓨터-실행가능 명령들을 저장한 메모리를 포함할 수 있으며, 컴퓨터-실행가능 명령들은 프로세서에 의해 실행될 때, 프록시 디바이스(710)로 하여금 패킷 엔진(820), 세션 캐시(825), 클라이언트-측 인증 모듈(830) 및 PKOperation 프록시 SDK(835)를 제공하고 그리고/또는 패킷 엔진(820), 세션 캐시(825), 클라이언트-측 인증 모듈(830) 및 PKOperation 프록시 SDK(835)의 동작들을 수행하도록 한다.

[118] 클라이언트 디바이스(705) 및 프록시 디바이스(710)는 HTTP 프레임워크와 같은 표준 프레임워크를 사용하여 통신할 수 있다. 일부 양상들에서, 이하의 예들에서 설명되는 바와같이, 클라이언트 디바이스(705) 및 프록시 디바이스(710)는 하나 이상의 인증 메시지들을 교환할 수 있다. 이들은 HTTP 상태 코드들, 예컨대 인증 및/또는 챌린지-응답(challenge-response) 메시지들을 요청하기 위한 HTTP 401 코드들을 교환할 수 있다. 일부 실시예들에서, 만일 401 인증 챌린지를 수신하는 클라이언트 디바이스(705)가 클라이언트 개인 인증서들의 보안 교환을 지원하지 않으면, 클라이언트 디바이스(705)는 클라이언트 디바이스(705)가 이해하지 못하는 인증 챌린지로서 401 메시지를 인식할 수 있다. 클라이언트 디바이스(705)는 적절한 에러 핸들링 행위(error handling behavior)에 반응하여, 예컨대 클라이언트 디바이스(705)가 클라이언트 개인 인증서들의 보안 교환을 지원하지 않기 때문에 동작이 완료되지 않을 수 있다는 메시지를 사용자에게 디스플레이할 수 있다. 공개 키 동작 리모팅(remoting)을 지원하기 위한 HTTP 레벨 인코딩은 비교적 단순할 수 있다. 패킷 엔진(820) 및 MAMP 프레임워크(805)는 HTTP 레벨 인코딩을 프로세싱할 수 있다. 통신들은 RFC 4559에서 설명된 HTTP 교섭 인증 방식과 유사한 구조일 수 있으며, RFC 4559는 그 전체가 인용에 의해 본원에 통합된다. 베이스 64 인코딩 블로브(base64 encoded blob)들은 WWW-인증 및/또는 허가 헤더들을 사용하여 클라이언트 디바이스와 프록시 디바이스 사이에서 송수신되어 교환될 수 있다. 블로브들은 개별 PKOperation SDK들(810, 835)에 의해 각각의 디바이스에서 생성되어 프로세싱될 수 있다.

[119] 일부 실시예들에서, 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이의 통신 경로에 있는, HTTP 인식 컴포넌트들은 인증 프로세스와 인터페이싱하지 않을 수 있다. 예컨대, 클라이언트 디바이스(705)와 프록시 디바이스(710)사이의 HTTP 프록시 서버는 다른 클라이언트 디바이스들 및/또는 사용자들로부터의 요청들을 송신하기 위하여 프록시 디바이스(710)에 대한 연결이 재사용되지 않아야 함을 알 수 있다. 게다가, 프록시 디바이스(710)로부터 리턴된 임의의 HTTP 데이터의 캐싱은 데이터가 다른 클라이언트 디바이스에 송신되지 않도록 정확하게 스코프(scope)되어야 한다.

[120] 일부 양상들에서, 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이의 인증은 표준 인증 프레임워크, 예컨대 웹 인증 또는 맞춤형 메커니즘을 가진 GSSAPI(Generic Security Services Application Program Interface)을 활용할 수 있다. 객체들은 프록시 디바이스(710)로부터 클라이언트 디바이스(705)로 전송될 수 있다. 클라이언트 디바이스(705)는 객체들을 프로세싱하고, 이들을 표준 암호 메커니즘들, 예컨대 이름 체크(name check)를 가진 인증 경로 검증에 의해 검증할 수 있다.

[121] 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이의 특수 통신 채널이 생성될 수 있다. 예컨대, 특수 통신 채널은 인증서 동작 요청들 및 결과들을 중계하기 위하여 사용될 수 있다. 특수 통신 채널을 활용하는 것은 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이의 표준 SSL 채널에 의해 제공되는 것을 초과하여 초과 암호 보호를 제공할 수 있다. 이는 리모팅되고 있는 암호 동작들의 입력들 및 출력들의 민감도가 주어질 때 적절할 수 있다. 일부 예들에서, 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이에서의 Diffie-Hellman 키 교환이 발생할 수 있다. 교환은 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이에 상호 인증을 제공할 수 있다. 일부 실시예들에서, 상호 인증은 클라이언트 디바이스(705)에 의한 자원 액세스 요청 전에 사전에 설정되었을 수도 있다. 그 전체가 인용에 의해 본원에 통합되는 RFC5929에서 설명된 채널 바인딩(channel binding)은 외부 SSL 세션에 특수 통신 채널을 암호 링크하기 위하여 사용될 수 있다. 도 8를 참조하면, PK 동작 페이로드들과 같은 데이터에 대한 특수 통신 채널을 셋업하면, 클라이언트 디바이스(705)와 패킷 엔진(820) 사이에서 다수의 교환들이 활용될 수 있다. 이는 PKOperation SDK(810) 및 PKOperation 프록시 SDK(835)를 제외하고 모든 것에 불투명할 수 있다.

[122] 특수 통신 채널을 통해 초과 보호를 제공하는 하나의 이유는 SSL이 프록시 디바이스(710)의 전방에 있는 오프로드 디바이스와 같은 네트워킹 디바이스에 의해 종결될 수 있기 때문이다. 오프로드 디바이스들은 예컨대 SSL 연결들에 수반되는 CPU 집약적 동작들을 가속시키기 위한 특수 하드웨어를 사용함으로써 SSL 연결 프로세싱을 위해 최적화될 수 있다. 하드웨어 모듈은 또한 연방 정부 정보 처리 표준(Federal Information Processing Standard)(예컨대, FIPS-140)과 같은 상업적으로 중요한 암호 프로세싱 표준들을 만족하도록 보증될 수 있다. 초과 보호를 제공하기 위한 다른 이유는 통신들을 디코딩하기 위하여 검사 디바이스에 SSL 인증서 키에 대한 액세스가 부여될 수 있기 때문이다. 검사 디바이스는 예컨대 신뢰성 있는 네트워크 존 외부로 컨피덴셜 정보를 송신하는 시도들 또는 신뢰성 없는 또는 비허가된 서버들과 통신하는 시도들을 검출함으로써 보안 정책들을 따르는 네트워크 트래픽을 모니터링하도록 설계된 보안 디바이스를 포함할 수 있다. 이들 검사 디바이스들 중 일부는 암호화된 통신 채널들의 사용에 의해 검사 프로세스가 저지되는 것을 방지하기 위하여 SSL 연결 핸드셰이크(handshake)들 동안 다수의 서버들을 가장하도록 구성될 수 있다. 특수 통신 채널을 사용하면, 오프로드 디바이스 및/또는 검사 디바이스에게 민감 데이터가 불필요하게 그리고/또는 부적절하게 노출되는 것을 방지할 수 있다. 따라서, 스마트 카드 균등 클라이언트 인증서들을 사용하여 예상된 부인 방지 특성들이 보호될 수 있다. 예컨대, 특수 통신 채널은 서명될 데이터가 암호해독된 데이터의 누설들 및/또는 외부 디바이스에 의해 수정되는 것을 방지할 수 있다.

[123] 특수 통신 채널은 많은 방식들로 구현될 수 있다. 예컨대, 이전에 논의된 바와같이, 표준 HTTP 인증 프로토콜내에서 동작하는 맞춤형 GSSAPI 메커니즘이 활용될 수 있다. 이러한 구현은 여러 비-배타적인 장점들을 제공한다. 첫째, 프록시 디바이스(710)는 요청된 자원 액세스를 완료하기 위하여 자원 및/또는 인증 서버에 대한 인증이 요구되는 것을 표준 방식(예컨대, HTTP)으로 클라이언트 디바이스(705)에 표시할 수 있다. 둘째, 임의적 바이너리 프로토콜은 필요한 경우에 다수의 라운드(round)들을 사용하여 클라이언트 디바이스(705)와 프록시 디바이스(710) 사이에서 수행될 수 있다. 셋째, 구현은 (예컨대, GSSAPI 레벨에서) 표준 방식으로 데이터를 전송하기 위하여 보안 통신 메커니즘들이 교섭되어 적용되도록 한다. 일부 구현들에서, 표준 HTTP 인증 프로토콜내에서 동작하는 맞춤형 GSSAPI 메커니즘은 또한 GSSAPI의 플랫폼 구현이 추가된 맞춤형 메커니즘, 예컨대 MICROSOFT NegoEx 메커니즘과 함께 사용되도록 할 수 있다.

[124] 도 7를 참조하면, 하나 이상의 인증 서비스(715)(또는 인증 서비스(715)를 실행하는 서버)가 존재할 수 있다. 인증 서비스(715)는 케베로스 또는 SSL을 포함하는 하나 이상의 타입들의 인증을 구현할 수 있다. 본원에서 설명된 양상들은 클라이언트 인증서 개인 키 동작들을 수반하는 임의의 인증 프로토콜에 대하여 구현될 수 있다. 예컨대, 케베로스의 경우에, 인증 서버는 티켓 승인 티켓들 및/또는 세션 티켓을 포함하는 티켓들을 발행하는 과업이 주어질 수 있다. 인증 서버는 하나 이상의 채널을 통해 프록시 디바이스(710)와 통신할 수 있다. 게다가, 하나 이상의 채널들은 프록시 디바이스(710)와 통신하기 위하여 클라이언트 디바이스(705)에 의해 사용되는 통신 프로토콜과 상이한 통신 프로토콜을 사용할 수 있다. 일부 양상들에서, 인증 서비스들(715)은 본원에서 설명된 양상들의 구현에도 불구하고 변경되지 않은 채 유지될 수 있다. 다시 말해서, 인증 서비스들(715)은 통상적인 인프라스트럭처에 존재할 수 있다. 인증 서비스들(715)은 예컨대 앞서 논의된 인증 서비스들(558)을 포함할 수 있다.

[125] 하나 이상의 자원들(720)(또는 자원들(720)을 저장한 서버들)이 존재할 수 있다. 자원(720)은 프록시 디바이스(710)와 통신하기 위하여 인증 서버가 사용하는 것과 동일하거나 또는 상이한 프로토콜들 중 하나 이상의 프로토콜을 사용하여 프록시 디바이스(710)와 통신할 수 있다. 일부 양상들에서, 자원들은 본원에서 설명된 양상들의 구현에도 불구하고 변경되지 않은 채 유지될 수 있다. 다시 말해서, 자원들은 통상적인 인프라스트럭처에 존재할 수 있다. 자원들의 비-제한적인 예들은 파일 자원들, 웹 자원들, 메일 자원들, 쉐어포인트(sharepoint) 자원들 등을 포함할 수 있으나 이에 제한되지 않는다. 이들 자원들은 SQL(Structure Query Language) 데이터베이스들, RPC(remote procedure call) 서버들, DCOM(Distributed Component Object Module) 서버들, SOAP(Simple Object Access Protocol) 웹 서비스들, REST(Representational State Transfer) 웹 서비스들, 및 인증을 위하여 GSSAPI 또는 유사한 보안 프레임워크를 사용할 수 있는 다른 독점 자원들을 포함할 수 있다. 이들 자원들 중 하나 이상의 자원은 자원들과 동일한 네트워크 또는 다른 보호 네트워크의 컴퓨터들과 같은 내부 디바이스들에 의해 직접 액세스될 수 있다. 자원들은 앞서 언급된 기업 서비스들(508 및/또는 609) 및/또는 기업 자원들(504, 508 및/또는 608)을 포함할 수 있다. 게다가, 자원들은 도 2에 예시된 서버들(206)과 같은 하나 이상의 서버들상에 저장될 수 있다. 자원들을 멀티-티어 시스템(multi-tier system)을 통해 액세스될 수 있다. 프록시 디바이스(710)는 프론트-엔드 서버와 통신할 수 있으며, 프론트-엔드 서버는 차례로 백-엔드 서버와 통신할 수 있다(그리고 요청하는 사용자로서 인증할 수 있다). 위임이 자유로운 케베로스는 이러한 타입의 시스템에 대하여 사용될 수 있으며, 프록시 디바이스(710)는 사용자에게 포워드되는 TGT를 프론트-엔드-서버에 적용할 수 있다.

[126] 도 9a-c는 프록시를 사용하여 자원들에 대한 보안 액세스를 인증하고 그리고/또는 제공하기 위한 예시적인 방법 단계들의 흐름도들이다. 도 9a-c는 클라이언트 디바이스(705), 프록시 디바이스(710), 인증 서비스(들)(715) 및/또는 자원(들)(720) 중 하나에 의해 수행되고 있는 각각의 단계를 예시한다. 그러나, 방법 단계들은 클라이언트 디바이스(705), 프록시 디바이스(710), 인증 서비스(들)(715), 자원(들)(720) 및/또는 이들의 조합 중 임의의 것에 의해 수행될 수 있다. 이전에 논의된 바와같이, 자원들(720) 및 인증 서비스들(715)은 동일한 서버(또는 서버들의 그룹)에 의해 제공될 수 있다. 대안적으로, 자원들(720) 및 인증 서비스들(715)은 상이한 서버들(또는 서버들의 그룹)에 의해 제공될 수 있다. 간략화를 위하여, 방법 단계들 중 일부는 단일 자원/인증 서비스 엔티티(예컨대, 서버 또는 서버들의 그룹)에 의해 수행되는 것으로 도 9a-c에 예시된다. 그러나, 인증 서비스들은 인증 서버(또는 인증 서버들의 그룹)에 의해 제공될 수 있으며, 자원들은 상이한 서버(또는 서버들의 그룹)에 의해 제공될 수 있다.

[127] 단계(902)에서, 사용자는 클라이언트 디바이스(705)로 인증될 수 있다. 예컨대, 사용자는 클라이언트 디바이스(705)에 로그인하기 위하여 사용자이름 및/또는 패스워드와 같은 크리덴셜들을 제공할 수 있다.

[128] 단계(904)에서, 클라이언트 디바이스(705)는 프록시 디바이스(710)를 인증할 수 있다. 부가적으로 또는 대안적으로, 단계(906)에서, 프록시 디바이스(710)는 클라이언트 디바이스(705)를 인증할 수 있다. 다시 말해서, 클라이언트 디바이스(705) 및 프록시 디바이스는 상호 인증을 수행할 수 있다. 인증을 수행하기 위하여, 클라이언트 디바이스(705)는 서버 인증을 가진 SSL을 사용하여 프록시 디바이스(710)에 연결될 수 있다. 프록시 디바이스(710)는 프록시 디바이스(710)에 대한 액세스를 허가하기 전에 프록시 디바이스(710)에 인증할 것을 클라이언트 디바이스(705) 및/또는 클라이언트 디바이스(705)의 사용자에게 요청할 수 있다. 일부 양상들에서, 클라이언트 디바이스(705)는 이러한 인증을 위하여 기업 클라이언트 인증서를 사용할 수 있다. 기업 클라이언트 인증서는 이하의 예들에서 더 상세히 설명되는 바와같이 문서들 및/또는 인증 메시지들을 서명하기 위하여 클라이언트 디바이스(705)에 의해 사용되는 동일한 인증서일 수 있다. 대안적으로, 기업 클라이언트 인증서는 상이한 인증서를 포함할 수 있다. 예컨대, 클라이언트 디바이스(705)는 상이한 목적을 위하여 각각 사용되는 다수의 인증서들을 가질 수 있다. 만일 물리적 스마트 카드가 사용되면, 다수의 인증서들은 스마트 카드 또는 상이한 스마트 카드들상에 저장될 수 있다.

[129] 유사하게, 클라이언트 디바이스(705)는 프록시 디바이스(710)가 알려진 신뢰성있는 엔티티임을 설정하기 위하여 프록시 디바이스(710)의 인증을 요청할 수 있으며, 프록시를 통해 위임된 인증에 의해 사용자가 인증되고 있는 자원들의 식별을 요청할 수 있다. 클라이언트 디바이스(705)는 또한 예컨대 SSL 핸드셰이크의 부분으로서 디바이스가 이용할 수 있는 클라이언트 인증서를 사용하거나 또는 SSL 연결 내에서, 예컨대 HTTP 상에서 개별 사용자 인증 프로토콜을 실행함으로써 프록시 디바이스(710)에게 클라이언트 디바이스(705)의 사용자를 인증할 수 있다. 자원들(720)은 또한 자원들(720)에 대한 액세스가 프록시 디바이스(710)에 의해 예컨대 자원 액세스 프로토콜을 사용함으로써 중재되고 있음을 알기를 원할 수 있다. 따라서, 상호 인증은 또는 식별은 모든 3개의 엔티티들, 클라이언트 디바이스(705)/사용자, 프록시 디바이스(710) 및 자원들(720)에 대하여 수행될 수 있다.

[130] 3개의 엔티티들 중 하나 이상의 엔티티의 인증 및/또는 식별한 이후에, 클라이언트 디바이스(705)는 하나 이상의 자원들, 예컨대 웹 자원들, (예컨대, 네트워크 파일 서버로부터의) 기업 자원들, 또는 프록시에 의해 액세스될 수 있으나 클라이언트 인증서에 기초하여 사용자 인증을 요구할 수 있는 다른 자원들에 대한 요청을 프록시 디바이스(710)에 송신할 수 있다. 자원에 대한 요청은 HTTP, HTTPS 또는 클라이언트 디바이스에 의해 지원되는 임의의 다른 액세스 프로토콜을 통해 클라이언트 디바이스(705)에 의해 송신될 수 있다. 프록시 디바이스(710)는 클라이언트 디바이스(705)에 의해 사용되는 액세스 프로토콜(예컨대, HTTP 또는 HTTPS)로부터 자원에 의해 사용되는 액세스 프로토콜로 전환되거나 또는 브리지(bridge)할 수 있다. 전환 이후에, 프록시 디바이스(710)는 단계(910)에서 자원 및/또는 인증 서비스에 요청을 포워드할 수 있거나 또는 그렇지 않은 경우에 요청된 자원에 액세스하는 것을 시도할 수 있다.

[131] 단계(912)에서, 자원은 프록시 디바이스(710)로부터 인증을 요청할 수 있다. 예컨대, 자원은 수행될 인증의 타입(예컨대, SSL, 도메인-기반 인증, 예컨대 케베로스 등)을 표시할 수 있다. 인증의 타입에 기초하여, 자원은 인증 챌린지(예컨대, 케베로스 인증을 위한 401 교섭 메시지 또는 SSL 인증을 위한 클라이언트 챌린지)를 송신할 수 있다. 케베로스 인증을 위하여, PKINIT 프로토콜이 사용될 수 있으며, 프록시 디바이스(710)는 케베로스 영역(예컨대, MICROSOFT 액티브 디렉토리 도메인)에 대한 클라이언트 인증서에 의해 식별된 사용자를 인증하기 위하여 PKINIT 프로토콜에서 클라이언트의 역할을 수행할 수 있다. 자원 서버는 HTTP 401 교섭과 같은 케베로스 인증 챌린지를 생성할 수 있다. (예컨대, 클라이언트 인증서를 사용한) SSL 인증을 위하여, 프록시 디바이스(710)는 프록시 디바이스(710)가 사용자의 클라이언트 인증서 및/또는 키에 대해 액세스함을 자원에 나타낼 수 있다. 프록시 디바이스(710)는 케베로스 인증에서 처럼 특정 도메인 대신에 자원과 함께 직접 인증하는 것을 시도할 수 있다. 부가적으로 또는 대안적으로, 프록시 디바이스(710)는 요청된 자원에 액세스하는 것을 시도하기 전에 인증이 요구됨을 알 수 있다. 어떤 경우든지, 프록시는 자원과 관련된 인증 프로토콜 상호작용들을 결정하여 개시할 수 있다. 이들 상호작용들은 자원에 의해 신뢰된 인증 서비스를 실행하는 인증 서버와 같은 추가 엔티티들을 수반할 수 있다.

[132] 단계(914)에서, 프록시 디바이스(710)는 자원(또는 자원을 가진 서버)과 보안 통신 세션을 개시하기 위하여 사용될 수 있는 세션 키가 이용가능함을 결정할 수 있다. 세션 키는 자원 또는 인증 서비스와의 이전 인증 세션에 기초하여 프록시 디바이스(710)에 의해 사전에 획득되어 프록시 디바이스에 저장되었을 수도 있다(예컨대, 캐싱되었을 수도 있다). 케베로스 인증을 위하여, 세션 키는 케베로스 티켓, 예컨대 티켓 승인 티켓(TGT) 또는 다른 시간-제한된 티켓과 함께 저장될 수 있다. 도 8를 참조하면, 케베로스 인증을 위하여, 프록시 디바이스(710)의 패킷 엔진(820)은 자신의 케베로스 인증 응답 로직을 인보크할 수 있는데, 이는 세션 캐시(825)내의 자원(예컨대, 웹 자원)에 대한 서비스 티켓이 사전에 존재하는지를 알기 위하여 체크한다. 일부 양상들에서, 클라이언트-측 인증 모듈(830)은, 체크에 응답하여, 클라이언트 인증서 인증이 요구되고 그리고/또는 지원되는 것을 프록시 디바이스(710)가 아는 경우에 PKINIT를 인보크할 수 있다. SSL 인증을 위하여, 세션 키는 이전 SSL 연결, 예컨대 SSL 세션을 재개하기 위하여 사용될 수 있다. 세션 키(및/또는 티켓)이 이용가능한 경우에(단계(914): Y), 프록시 디바이스(710)는 이하의 예들에서 더 상세히 설명되는 바와같이 세션 키(및/또는 티켓)을 사용하여 단계(954)로 계속될 수 있다(요청된 자원을 획득할 수 있다).

[133] 제 1 시간 인증을 위하여, 세션 캐시는 비어있을 수 있다(예컨대, 유효 세션 키 및/또는 티켓을 저장하지 않는다)(단계(914): N). 따라서, 프록시 디바이스(710)는 자원과의 인증을 개시할 수 있다. 도 8를 참조하면, 케베로스 인증을 위하여, 패킷 엔진(820)은 TGT를 획득하기 위하여 클라이언트-측 인증 모듈에 내부 PKINIT 커맨드를 발행할 수 있다. 인증을 위하여, 프록시 디바이스(710)는 자신이 클라이언트 디바이스(705)에 의해 액세스가능한 클라이언트 인증서에 기초하여 하나 이상의 클라이언트 인증서들 및/또는 서명들을 필요로 함을 결정할 수 있다. 이들 인증서들 및/또는 서명들은 프록시 디바이스(710)에 의해 직접 액세스하는 것이 가능하지 않을 수 있다. 도 8를 참조하면, 클라이언트-측 인증 모듈(830)은 클라이언트 디바이스(705)로부터의 인증서들을 획득하기 위하여 내부 P11 겟 인증서 커맨드와 같은 커맨드를 PKOperation 프록시 SDK(835)에 송신할 수 있다. 클라이언트-측 인증 모듈(830)은 PKINIT에 대해 적절한 클라이언트 인증서들을 찾는 방식으로서 표준 PKCS#11 라이브러리 인터페이스와 같은 공개-키 암호 표준(PKCS)를 지원하는 케베로스 클라이언트 구현을 통합할 수 있다. PKOperation 프록시 SDK(835)는 PKINIT 특징을 지원하기 위하여 PKCS#11 API 기능들의 관련 서브세트를 구현할 수 있다.

[134] 단계(916)에서, 프록시 디바이스(710)는 클라이언트 디바이스(705)에게 이용가능하고 그리고/또는 액세스가능한 인증서들의 리스트에 대한 요청을 클라이언트 디바이스(705)에 송신할 수 있다. 요청은 HTTP 헤더로 인코딩될 수 있다. 예컨대, 요청은 인증이 요구됨을 표시하고 인증을 위해 클라이언트 디바이스(705)에 챌린징(challenging)하는 HTTP의 401 상태 코드로 인코딩될 수 있다. 도 8를 참조하면, 프록시 SDK(835)는 인증 요청들(예컨대, PK 동작 요청들)이 클라이언트 디바이스(705)에 전송되게 하고 클라이언트 디바이스(705)가 요청에 응답하는 경우에 결과들을 수신하기 위하여, 프록시 SDK(835)가 사용할 수 있는 패킷 엔진(820)에 대해 맞춤형 인터페이스를 요구할 수 있다. 만일 인증서 요청들이 리모팅될 필요가 있으면, 프록시 SDK(835)가 (적절한 암호화/무결성 레퍼들을 가진) 바이너리 구조로 요청을 인코딩할 수 있으며, 패킷 엔진(820)에 제출할 수 있다. 패킷 엔진(820)은 맞춤형 인증 챌린지를 가진 HTTP 401 응답이 WWW-인증 헤더로 인코딩된 바이너리 구조를 포함하는 초기 HTTP 요청에 응답하여 클라이언트 디바이스(705)에 송신되는 것을 야기할 수 있다.

[135] 일부 양상들에서, 프록시 디바이스(710)는 클라이언트 디바이스(705)로부터 인증들의 리스트에 대한 요청에 응답하는 응답을 수신하지 않을 수 있다. 특히, 클라이언트 디바이스(705)가 인증서 (예컨대, PK 동작) 요청에 응답할 것이라는 보장이 없다. 예컨대, 클라이언트 디바이스(705)는 기능을 멈추거나 또는 그렇지 않은 경우에 요청에 응답하지 않을 수도 있다. 게다가, 클라이언트 디바이스(705)는 (예컨대, 키스토어(815)를 언로크(unlock)하기 위하여 PIN을 입력하도록 사용자에게 요청함으로써) 동작을 위한 사용자 승락을 획득하는 것을 시도하였을 수도 있으나 승낙은 거절될 수 있다. 클라이언트 디바이스(705)가 클라이언트 인증서들의 리스트를 리턴하지 않는 상황들을 처리하기 위하여, 프록시 디바이스(710)(예컨대, 프록시 SDK(835) 컴포넌트)는 타임아웃을 사용하여 결국 인증 요청 동작을 포기할 수 있다. 프록시 디바이스(710)는 이들 환경들에서 적절한 에러 코드를 리턴할 수 있다. PKINIT 로그온 동안, PKINIT 로그인이 성공하거나 실패하거나 또는 포기될 때까지 또는 타임아웃이 경과할 때까지 여러 PK 동작이 디바이스에 송신될 수 있다.

[136] 단계(918)에서, 클라이언트 디바이스(705)는 프록시 디바이스(710)로부터 인증서 리스트 요청을 수신할 수 있으며, 이에 응답하여, 클라이언트 디바이스(705)에게 이용가능하거나 또는 그렇지 않은 경우에 액세스가능한 인증서들을 식별할 수 있다. 예컨대, 도 8를 참조하면, 클라이언트 디바이스(705)의 MAMP 프레임워크(805)는 프록시 디바이스(710)로부터 맞춤형 인증 챌린지를 가진 메시지(예컨대, HTTP 401 요청)를 수신할 수 있다. 이를 인증서 요청(예컨대, PK 동작 "인증" 프로토콜)으로서 인식할 때, MAMP 프레임워크(805)는 수신된 헤더 포맷으로부터의 메시지를 디코딩하고 메시지의 바이너리 구조를 PKOperation SDK(810)에 전달할 수 있다. PKOperation SDK(810)는 이용가능한 클라이언트 인증서(들)의 지식을 가질 수 있다. 이전에 언급한 바와같이, 클라이언트 인증서들은 물리적 스마트 카드, 가상 스마트 카드 등의 형태를 가질 수 있다. PKOperation SDK(810)는 (임의의 암호화/무결성 래퍼들을 프로세싱하는 것을 비롯하여) 요청을 디코딩할 수 있으며, 이를 적절한 내부 핸들러(handler)에 디스패치(dispatch)할 수 있다. 핸들러는 요청을 프로세싱하고 이용가능한 인증서들의 리스트를 생성할 수 있다. 인증서들의 리스트는 예컨대 적절한 키 사용 표시자를 가진 인증서들만을 포함하도록, 요청되고 있는 동작에 대한 검색 능력에 따라 필터링될 수 있다. 인증서들의 리스트는 단지 하나의 인증서가 유지될 때까지 필터링될 수 있다. 예컨대, 리스트는 동작을 위해 사용되어야 하는 인증서를 고르기 위하여 클라이언트 디바이스(705)의 사용자에게 UI를 제시함으로써 추가로 필터링될 수 있다. 리스트는 동작 결과를 나타내는 바이너리 구조를 가질 수 있다. PKOperation SDK(810)는 여전히 바이너리 구조를 가질 수 있는 인증서들의 리스트를 MAMP 프레임워크(805)에 리턴할 수 있거나 또는 리스트가 생성될 수 없는 경우에 에러 상태를 시그널링할 수 있다.

[137] 도 9b를 참조하면, 단계(924)에서, 클라이언트 디바이스(705)는 이용가능한 인증서들의 리스트를 포함하는 메시지를 프록시 디바이스(710)에 송신할 수 있다. 일부 양상들에서, 메시지는 HTTP 또는 HTTPS 메시지로서 송신될 수 있다. 예컨대, MAMP 프레임워크(805)는 프록시 디바이스로부터 원래 HTTP 요청을 다시 할 수 있으나 이용가능한 인증서들의 리스트를 포함하는 요청에 첨부된 맞춤형 허가 헤더를 사용할 수 있다. 송신 전에, 메시지는 암호화/무결성 래퍼로 시일링될 수 있으며 그리고/또는 HTTP 헤더에 맞도록 인코딩될 수 있다.

[138] 단계(926)에서, 프록시 디바이스(710)는 클라이언트 디바이스(705)로부터 메시지를 수신할 수 있다(그리고, 필요한 경우에 암호해독/디코딩할 수 있다). 도 8를 참조하면, 패킷 엔진(820)은 클라이언트 디바이스(705)로부터 수신된 HTTP 요청이 프록시 디바이스(810)에 의해 송신된 원래 인증서 요청의 재송신임을 인식할 수 있다. 패킷 엔진(820)은 허가 헤더로부터 클라이언트-측 인증 모듈(830)을 통해 프록시 SDK(835)에 데이터의 바이너리 구조를 제출할 수 있다. 프록시 SDK(835)는 (암호화/무결성 래퍼를 포함하는) 바이너리 구조를 언팩(unpack)할 수 있으며, 언팩된 데이터를 클라이언트-측 인증 모듈(830)에 리턴할 수 있다. 다음으로, 프록시 디바이스(710)는 자원/인증 서버로 프록시 디바이스(710)를 인증하기 위하여 사용할 인증서(인증서들의 리스트 중 인증서), 예컨대 (즉, 자원/인증 서버로 프록시 디바이스(710)를 인증하기 위하여) 인증 세션에 적합한 인증서를 선택할 수 있다. 일부 실시예들에서, 케베로스 및 SSL 표준들은 예상되거나 또는 요구되는 키 용도(들)를 특정할 수 있다. 예컨대, 만일 인증 세션이 케베로스 인증을 포함하면, 프록시 디바이스(710)는 케베로스 티켓들을 획득할 필요가 있을 수 있으며, 케베로스 티켓들을 획득하기에 적합한 인증서를 선택할 수 있다. 만일 클라이언트 디바이스(705)가 단계(924)에서 다수의 인증서들을 리턴하였다면, 프록시 디바이스(710)는 인증서들의 리스트로부터 선택할 사용자 입력을 찾는 클라이언트 디바이스에 선택 요청을 송신할 수 있다.

[139] 프록시 디바이스(710) 및 자원은 인증 세션 동안 메시지들을 교환하는 것을 계속할 수 있다. 인증 세션 동안 하나 이상의 시점들에서, 프록시 디바이스(710)는 클라이언트 디바이스(705)의 서명, 예컨대 개인 키를 사용하여 암호 동작을 수행하도록 요구될 수 있다. 개인 키는 프록시 디바이스(710)에게 직접 이용가능하지 않을 수도 있다. 대신에, 개인 키는 클라이언트 디바이스(705)의 제어하에서 유지될 수 있으며, 프록시 디바이스(710)에 직접 노출되지 않는다. 프록시 디바이스(710)는 서명 (예컨대, 개인 키)을 획득하기 위하여 특수 통신 채널을 통해 클라이언트 디바이스(705)와 상호작용할 수 있다.

[140] 단계(928)에서, 프록시 디바이스(710)는 클라이언트 디바이스(705)로부터 선택된 인증서에 대응하는 서명에 대한 요청을 생성할 수 있다. 프록시 디바이스(710)는 또한 서명된 데이터의 피스(piece)를 생성할 수 있다. 케베로스 인증을 위하여, 데이터의 피스는 선택된 인증서를 사용하는 인증 서비스 요청(AS_REQ) 메시지를 포함할 수 있다. AS_REQ 메시지에는 클라이언트 디바이스(705)에 송신될 서명에 대한 요청이 선택적으로 포함될 수 있다. 프록시 디바이스(710)는 클라이언트 디바이스가 서명을 제공하기 전에 인증 콘텍스트의 전체 세부사항들을 확인할 필요가 있는 경우에 미서명 AS_REQ 메시지를 클라이언트 디바이스(705)에 송신할 수 있다. 프록시 디바이스(710)는 클라이언트와 프록시 디바이스들 및/또는 케베로스 인증 구현 간의 통신 프로토콜이 AS_REQ 메시지를 클라이언트 디바이스(705)에 송신하는 것을 지원하지 않는 경우에 AS_REQ 메시지를 클라이언트 디바이스(705)에 송신하지 않을 수 있다. 이하의 예들에서 논의되는 바와같이, 프록시 디바이스(710)는 일단 AS_REQ 메시지가 클라이언트 디바이스(705)에 의해 서명되었다면 인증을 위하여 인증 서비스(715) 및/또는 자원(720)에 서명된 AS_REQ 메시지를 송신할 수 있다.

[141] 단계(930)에서, 프록시 디바이스(710)는 서명을 위한 요청에 포함될 인증 콘텍스트 정보를 결정할 수 있다. 일부 양상들에서, 콘텍스트 정보는 크기 또는 포맷에 의해 제한되지 않을 수 있다. 예컨대, 프록시 디바이스(710)는 BLOB(Binary Large Object)로서 콘텍스트 정보를 송신할 수 있다. 일반적으로, 콘텍스트 정보는 프록시 디바이스(710)와 자원/인증 서버 간의 인증 세션을 식별하는 정보를 포함할 수 있다. 이하의 예들에서 더 상세히 설명되는 바와같이, 클라이언트 디바이스(705)는 프록시 디바이스(710)와 자원/인증 서버 사이의 인증 세션을 검증하거나 또는 그렇지 않은 경우에 확인하기 위하여 콘텍스트 정보를 사용할 수 있다.

[142] 콘텍스트 정보의 콘텐츠의 예들이 지금 제공될 것이다. 콘텍스트 정보는 프록시 디바이스(710)와 자원/인증 서버 사이에서 사전에 교환된 인증 정보의 데이터 구조를 식별할 수 있다. 예컨대, 만일 프록시 디바이스(710) 및 자원이 인증 메시지들을 이미 교환하였고 현재 인증 중에 있으면, 콘텍스트 정보는 교환된 인증 메시지들의 전부 또는 일부분을 포함할 수 있다. 부가적으로 또는 대안적으로, 콘텍스트 정보는 미래에 프록시 디바이스(710)에 의해 자원/인증 서버에 송신될 인증 정보의 데이터 구조를 식별할 수 있다. 케베로스 인증에서, 예컨대 콘텍스트 정보는 프록시 디바이스(710)에 의해 자원/인증 서버에 송신될 AS_REQ 메시지의 전부 또는 일부분을 포함할 수 있다.

[143] 콘텍스트 정보는 인증 세션과 연관된 타임스탬프 정보를 포함할 수 있다. 타임스탬프는 프록시 디바이스(710)에 의해 결정되는 현재의 시간을 식별할 수 있다. 케베로스/PKINIT를 위해, 인증 서비스(715) 및/또는 자원(720)은 인증 동안 타임스탬프를 검증할 수 있다. 일반적으로, 타임스탬프는 인증 서비스(715) 및/또는 자원(720)에 의해 결정된 현재의 시간의 상당히 엄격한 허용오차 내에 (예컨대, X 초내에) 있어야 한다. 타임스탬프가 인증 서비스(715) 및/또는 자원(720)으로 프록시 디바이스(710)를 인증하기 위하여 사용되기 때문에, 타임스탬프는 또한 클라이언트 디바이스(705)에 의한 검증을 위하여 사용될 수 있다. 클라이언트 디바이스(705) 및 프록시 디바이스(710)가 프록시 디바이스(710) 및 인증 서비스(715)와 시간적으로 밀접하게 동기화되지 않을 수 있기 때문에 보다 큰 허용오차 임계치(예컨대, X+Y 초)가 클라이언트 디바이스(705)에 의해 사용될 수 있다. 클라이언트 디바이스(705)는 인증 세션이 최근에 (예컨대, 마지막 분(minute), 마지막 날(day) 등내에) 이루어졌음을 검증하기 위하여 타임스탬프 정보를 사용할 수 있다.

[144] 콘텍스트 정보는 프록시 디바이스(710) 및 자원/인증 서버에 의해 사용되고 있는 인증 프로토콜의 타입을 식별할 수 있다. 예컨대, 만일 케베로스 인증이 사용되면, 콘텍스트 정보는 일반적으로 케베로스를 식별하거나 또는 케베로스의 PKINIT 특징이 사용되고 있는 경우에 PKINIT/케베로스를 식별할 수 있다. 일례로서, "sign-for-PKINIT"이 사용될 수 있다. 콘텍스트 정보는 또한 서명 또는 특정 프록시 디바이스(710) 구현을 요청하는 애플리케이션을 식별할 수 있다. 예컨대, "sign-for-PKINIT-by-NetScaler" 또는 "sign-for-PKINIT-by-XenApp"가 사용될 수 있다. 만일 SSL 인증이 사용되면, 콘텍스트 정보는 SSL을 식별할 수 있다. 일례로서, "sign-for-SSL-client-authentication"가 사용될 수 있다. 콘텍스트 정보는 또한 프록시 디바이스(710)가 어떤 SSL 인증 동작(예컨대, 동작 1, 동작 2 등)을 수행중인지를 식별할 수 있고 프록시 디바이스(710)가 어떤 자원을 인증중인지를 식별할 수 있다.

[145] 콘텍스트 정보는 클라이언트 디바이스(705)에 의해 제공되는 인증서들의 리스트로부터 프록시 디바이스(710)가 선택한 인증서를 식별할 수 있다(예컨대, 단계(926)). 선택된 인증서를 제공함으로써, 클라이언트 디바이스(705)는 프록시 디바이스(710) 및 자원에 의해 사용되고 있는 인증 프로토콜의 타입을 알 수 있을 것이다.

[146] 콘텍스트 정보는 인증 세션의 데이터 구조, 예컨대 케베로스 데이터 구조 또는 SSL 데이터 구조를 식별할 수 있다. 예컨대, 케베로스 인증 세션은 프록시 디바이스(710)가 콘텍스트 정보를 통해 식별할 수 있는 ASN.1(Abstract Syntax Notation 1) 구조들을 포함할 수 있다. 특히, 서명될 AS_REQ의 부분일 수 있는 AuthPack는 클라이언트 디바이스(705)가 인식할 수 있는 잘-정의된 ASN.1 구조를 가질 수 있다. SSL 인증을 위해, 데이터 구조는 인증 검증 구조를 포함할 수 있다.

[147] 콘텍스트 정보는 클라이언트 디바이스(705)가 인증 세션을 검증하기 위하여 사용할 수 있는 정보의 특정 피스들을 포함할 수 있다. 정보의 특정 피스들은 또한 인증 세션의 데이터 구조를 식별하기 위하여 사용될 수 있다. 예컨대, 만일 인증 세션이 케베로스 인증을 포함하면, 콘텍스트 정보는 예컨대 케베로스 인증과 연관된 체크섬(checksum), 케베로스 인증을 위하여 사용되는 케베로스 도메인(예컨대, 특정 인증 서버가 서빙하는 영역), 클라이언트 디바이스(705)와 연관된 케베로스 원이름(예컨대, 클라이언트 디바이스(705)에 할당된 사용자 이름), 인증 세션을 위하여 사용되는 키 분배 센터(KDC)의 식별자, 요청된 티켓(예컨대, TGT 티켓 또는 세션 티켓)의 유효 기간 및 인증 세션 동안 (예컨대, 프록시 디바이스(710)와 자원/인증 서버 사이에서 어느 정도까지만 교환되는 인증 메시지들에 기초하여) 세팅된 케베로스 플래그들을 포함할 수 있다. 클라이언트 디바이스(705)가 검증할 수 있는 예시적인 플래그는 결과적인 티켓이 다른 디바이스에 포워드될 수 있다는 것을 표시할 수 있는 "포워드가능" 플래그이다. 이전에 논의한 바와같이, 클라이언트 디바이스(705)에 의해 서명되고 자원/인증 서버에 송신될 AS_REQ 메시지의 전부 또는 일부분이 클라이언트 디바이스(705)에 송신될 수 있다.

[148] SSL 인증을 위하여, 정보의 특정 피스들 단독으로는 클라이언트 디바이스(705)가 프록시 디바이스(710)와 자원/인증 서비스 간의 SSL 인증 세션의 콘텍스트를 식별하도록 하기에는 충분하지 않을 수 있다. 예컨대, 정보의 특정 피스들은 SSL 인증이 프록시 디바이스(710)와 자원 사이에서 송수신된 패킷들의 전체 시리즈(series)의 해시(hash)들을 생성하기 때문에 클라이언트 디바이스(705)에게는 랜덤한 데이터로 보일 것이다. 따라서, 일부 실시예들에서, SSL 인증을 위한 콘텍스트 정보는 클라이언트 디바이스(705)로부터 서명을 요구하기 전에 프록시 디바이스(710)와 자원 사이의 전체 (또는 거의 전체) 인증 대화(conversation)를 포함할 수 있다. 다시 말해서, SSL 동작들(예컨대, 핸드셰이크 메시지들)의 전부는 클라이언트 디바이스(705)에 제공될 수 있다. 프록시 디바이스(710)는 수행되는 SSL 동작들의 누적 다이제스트(cumulative digest)를 생성한다. 따라서, 클라이언트 디바이스(705)는 클라이언트 디바이스(705)가 검사하기를 원하는 핸드셰이크의 임의의 부분을 검사할 수 있으며, 따라서 클라이언트 디바이스(705)는 자원의 아이덴티티가 액세스되고 있음을 확인하고 핸드셰이크가 적격임을 확인할 수 있다. 일부 양상들에서, 프록시 디바이스(710)는 인증서 동작 인터페이스를 통해 클라이언트 디바이스(705)에 전체 SSL 핸드셰이크 프로세스를 위임할 수 있다. 핸드셰이크가 완료될 때, 클라이언트 디바이스(705)는 클라이언트와 프록시 사이의 특수 통신 채널에 대하여 키 교환으로 보호되는 마스터 시크릿을 적용할 수 있다.

[149] 단계(932)에서, 클라이언트 디바이스(705)는 프록시 디바이스(710)로부터 서명에 대한 요청을 수신하고 그에 포함된 콘텍스트 정보를 추출할 수 있다. 예컨대, 클라이언트 디바이스(705)는 요청 메시지를 디코딩 및/또는 암호해독할 수 있다. 콘텍스트 정보의 예들은 앞서 리스트되었다. 단계(934)에서, 클라이언트 디바이스(705)는 콘텍스트 정보를 검증하는 것을 시도할 수 있다. 클라이언트 디바이스(705)는 프록시 디바이스(710)와 자원/인증 서버 사이의 인증 세션이 유효함을 검증하기 위하여 콘텍스트 정보를 사용할 수 있다. 예컨대, 클라이언트 디바이스(705)는 프록시 디바이스(710)가 자원/인증 서버와 통신중임을 그리고 이들 사이에서 이루어지고 있는 통신의 타입을 결정하기 위하여 콘텍스트 정보를 사용할 수 있다. 클라이언트 디바이스(705)는 예컨대 액세스되고 있는 자원이 의도된 자원이고, 요청되고 있는 암호 동작이 예상된 프로토콜의 부분이며 암호 동작의 결과들이 프록시 디바이스(710)와 자원 사이의 특정 프로토콜 상호작용 부분이거나 또는 이 부분으로서만 유용하게 사용될 것임을 클라이언트 디바이스(705)가 스스로 확신하도록 하기에 충분한, 프록시의 인증 콘텍스트 또는 자원 인증 프로토콜의 관련 부분(또는 이의 전부)에 대해 알게 될 수 있다. 예컨대, 클라이언트 디바이스(705)는 데이터(또는 첨부된 데이터)가 예상 인증 프로토콜(예컨대, 케베로스, SSL 등)의 구조에 의해 사용되는 알-알려진 구조에 대응하도록 보장하기 위하여, 클라이언트 디바이스(705)가 서명하도록 요청받은 데이터(예컨대, 케베로스 인증을 위한 AS_REQ 메시지)를 검사할 수 있다. 데이터는 또한 클라이언트 디바이스(705)에 의해 검증될 수 있는 특정 데이터 엘리먼트들을 잠재적으로 포함할 수 있다. 부가적으로 또는 대안적으로, 클라이언트 디바이스(705)는 클라이언트 디바이스(705)가 서명을 제공하기 전에 데이터에서 인식가능하고 그리고/또는 검증가능한 예상 구조를 찾을 수 있다.

[150] 만일 콘텍스트 정보가 검증되지 않으면(단계(934): N), 클라이언트 디바이스(705)는 콘텍스트 정보가 검증될 수 없다는 것을 표시하는 메시지를 송신할 수 있다. 예컨대, 클라이언트 디바이스(705)는 요청된 서명을 포함하지 않는 응답을 송신할 수 있다. 케베로스 인증을 위하여, 검증은 타임스탬프가 클라이언트 디바이스(705)에 의해 세팅된 허용오차 임계치 밖에 있는 경우에 실패할 수 있다. SSL 및 케베로스 인증을 위하여, 클라이언트 디바이스(705)는 다수의 이유들 중 임의의 이유 때문에 실패할 수 있는 인증/자원 서버 인증서에 대하여 인증서 체인 검증(certificate chain validation)을 수행할 수 있다. 케베로스에 대한 인증서 체인 검증은 (AS_REQ에 대한 답신인 AS_REP를 처리하는) 개별 PK 동작 단계를 요구할 수 있다. SSL를 위하여, 체인 검증은 프록시 디바이스(710)와 자원 간의 SSL 인증 메시지들의 관련 부분이 클라이언트 디바이스(705)에 송신되는 경우에 가능할 수 있다.

[151] 일부 양상들에서, 클라이언트 디바이스(705)는 프록시 디바이스(710)에 의해 사전에 제공된 콘텍스트 정보에 기초하여 클라이언트 디바이스(705)가 검증할 수 없는 경우에 프록시 디바이스(710)로부터 추가 콘텍스트 정보를 요청할 수 있다. 만일 프록시 디바이스(710)가 추가 콘텍스트 정보를 제공하는 것을 결정하면, 프록시 디바이스(710)는 단계(930)로 리턴하여, 클라이언트 디바이스에 제공할 추가 콘텍스트 정보를 찾을 수 있다. 추가 콘텍스트 정보는 상이한 타입의 콘텍스트 정보일 수 있다. 예컨대, 만일 프록시 디바이스(710)가 선택한 인증서를 식별하는 정보를 프록시 디바이스(710)가 사전에 제공하였다면, 프록시 디바이스(710)는 프록시 디바이스(710)와 자원/인증 서버 사이에서 교환되는 인증 메시지들(예컨대, 케베로스 인증 세션 동안 세팅된 케베로스 플래그들 또는 SSL 인증 세션 동안 교환된 핸드셰이크 메시지들)로부터 특정 정보를 제공할 수 있다. 서명 없이 메시지를 송신하는 것 대신에, 클라이언트 디바이스(705)는 프록시 디바이스의 서명 요청에 응답하지 않을 수 있다.

[152] 단계(938)에서, 프록시 디바이스(710)는 서명이 이용가능하지 않다는 것을 표시하는 메시지를 생성하고 이 메시지를 자원/인증 서버에 포워드할 수 있다. 단계(970)에서, 자원/인증 서버는 프록시가 인증되지 않았음을 결정할 수 있고, 이에 응답하여 인증 세션을 종료할 수 있다. 다시 말해서, 자원/인증 서버는 세션 키(또는 케베로스의 경우에 티켓)를 프록시에 제공하지 않을 수 있다.

[153] 콘텍스트 정보는 검증될 수 있다(단계(934): Y). 케베로스 인증을 위하여, 예컨대 수신된 타임스탬프가 클라이언트 디바이스의 현재의 시간의 허용오차내에 있고 그리고/또는 수신된 AuthPack의 체크섬이 (AS_REQ이 콘텍스트 정보로서 적용되는 경우에) 클라이언트 디바이스에 의해 컴퓨팅된 체크섬과 매칭되는 경우에 검증은 성공할 수 있다. 만일 콘텍스트 정보가 검증되면, 단계(942)에서, 클라이언트 디바이스(705)는 단계(926)에서 프록시 디바이스(710)에 의해 선택되었을 수 있는 인증서를 사용하여 프록시 디바이스(710)에 의해 제공된 데이터를 서명할 수 있다. 예컨대, 케베로스 인증을 위해, 만일 프록시 디바이스(710)가 서명되지 않은 AS_REQ 메시지를 클라이언트 디바이스(705)에 제공하였다면 (예컨대, 단계(930)에서), 클라이언트 디바이스(705)는 AS_REQ 메시지를 서명할 수 있다. 이전에 언급한 바와같이, 서명되지 않은 AS_REQ 를 제공하는 것은 선택적이다. 대안으로서, 케베로스 및 SSL 인증을 위하여, 프록시 디바이스(710)에 의해 제공된 데이터는 서명이 컴퓨팅될, 옥텟(octet)들의 시퀀스와 같은 데이터의 임의의 청크(chunk)를 포함할 수 있다. 데이터를 서명한 이후에, 클라이언트 디바이스(705)는 단계(944)에서 서명을 가진 메시지 및/또는 서명된 데이터를 프록시 디바이스(710)에 송신할 수 있다.

[154] 단계(946)에서, 프록시 디바이스(710)는 메시지를 수신하고 그리고 서명 및/또는 서명된 데이터를 추출할 수 있다. 이하에서 더 상세히 논의되는 바와같이, 예컨대, (옥텟들의 다른 시퀀스일 수 있는) 서명은 프록시 디바이스에 리턴될 수 있고, 프록시 디바이스에 의해 자원 또는 인증 서비스에 송신되기에 적절한 인증 메시지에 삽입될 수 있다. 도 8를 참조하면, 패킷 엔진(820)은 메시지를 수신하고 이 메시지를 프록시 SDK(835)에 포워드할 수 있다. 프록시 SDK(835)는 클라이언트-측 인증 모듈(830)에 서명을 제공할 수 있다.

[155] 단계(948)에서, 프록시 디바이스(710)는 서명을 포함하는 인증 메시지를 자원/인증 서버에 송신할 수 있다. 인증 메시지는 단계(912)에서 자원/인증 서버에 의해 송신된 인증서에 대한 요청에 응답할 수 있다. 일반적으로, 인증 메시지는 클라이언트 디바이스(705)에 의해 요청된 자원들을 획득하기 위하여 프록시 디바이스(710)에 대한 세션 키를 획득하기 위하여 사용될 수 있다. 케베로스 인증에서, 예컨대, 인증 메시지는 프록시 디바이스(710)가 자원과의 보안 통신 세션 동안 티켓들을 획득하기 위하여 사용할 수 있는 세션 키 및 티켓, TGT를 획득하기 위하여 사용되는 AS_REQ 메시지를 포함할 수 있다. 만일 프록시 디바이스(710)가 클라이언트 디바이스(705)로부터, 서명된 AS_REQ 메시지를 수신하였다면, 프록시 디바이스(710)는 서명된 AS_REQ 메시지를 자원/인증 서버에 포워드할 수 있다. 만일 프록시 디바이스(710)가 서명을 개별적으로 수신하였다면, 프록시 디바이스(710)는 AS_REQ 메시지를 생성하여 서명을 AS_REQ 메시지에 첨부할 수 있다. 일부 양상들에서, AS_REQ 메시지는 RFC 4556에서 설명된 바와같이 PA-PK-AS-REQ 포맷으로 인코딩될 수 있으며, RFC 4556는 그 전체가 인용에 의해 본원에 통합된다.

[156] 단계(950)에서, 자원/인증 서버는 인증 메시지를 수신하고, 인증 메시지가 유효 서명을 가지는지의 여부를 결정할 수 있다. 만일 서명이 유효하지 않으면, 자원/인증 서버는 이전에 논의된 단계(970)를 수행할 수 있다(예컨대, 프록시 디바이스(710)가 인증되지 않고 그리고/또는 프록시 디바이스(710)와의 인증 세션을 종료함을 결정할 수 있다).

[157] 단계(952)에서, 만일 서명이 유효하면(단계(950): Y), 자원/인증 서버는 세션 키를 생성하고 그리고/또는 세션 키를 프록시 디바이스(710)에 송신할 수 있다. 케베로스 인증에서, 자원/인증 서버는 또한 티켓, 예컨대 TGT 또는 서비스 티켓을 프록시 디바이스(710)에 송신할 수 있다. 세션 키 및/도는 티켓은 프록시 디바이스(710) 및/또는 클라이언트 디바이스(705)가 암호해독할 수 있는 다른 키를 사용하여 캡슐화될 수 있다. 일부 양상들에서, 메시지는 케베로스 AS_REP 메시지로서 송신될 수 있다.

[158] 단계(953)에서, 프록시 디바이스(710)는 세션 키 및/또는 티켓을 수신하고, 세션 키 및/또는 티켓을 저장(예컨대, 캐싱)할 수 있다. 이들은 추후 사용을 위하여 캐싱될 수 있다. 예컨대, 세션 키 및/또는 티켓은 클라이언트 디바이스(705)가 추가 자원들을 요청한 경우 미래에 사용될 수 있다. 도 9a를 참조하면, 프록시 디바이스(710)는 프록시 디바이스(710)가 클라이언트 디바이스(705)에 대한 자원을 획득할 필요가 있을 때 단계(914)에서 세션 키가 이용가능함을 결정할 수 있다. 도 8를 참조하면, 케베로스 인증을 위하여, 클라이언트-측 인증 모듈(830)은 사용자 세션들 동안 TGT들 및/또는 서비스 티켓들 및 이들의 대응하는 세션 키들을 케베로스 티켓 캐시에 파퓰레이트(populate)할 수 있다.

[159] 일부 실시예들에서, 프록시 디바이스(710)는 자원/인증 서버로부터 수신된 세션 키 및/또는 티켓을 가진 메시지를 암호해독할 키를 갖지 못할 수 있다. 대신에, 클라이언트 디바이스(705)는 예컨대 클라이언트 디바이스(705)가 프록시 디바이스(710)를 전체적으로 신뢰하지 않는 경우에 키에 대한 액세스를 제어할 수 있다. 이들 실시예들에서, 프록시 디바이스(710) 및 클라이언트 디바이스(705)는 세션 키 및/또는 티켓을 포함하는 캡슐화된 메시지를 암호해독하기 위하여 (예컨대, 추가 인증 동작에서) 메시지들의 추가 세트를 선택적으로 교환할 수 있다. 교환은 단계(953)에서 프록시 디바이스(710)가 세션 키 및/또는 티켓을 암호해독하고 저장하는 대신에 이루어질 수 있다.

[160] 예컨대, 케베로스 인증을 위해, PKINIT는 RFC 4556의 단락 3.2.3.1에서 설명되는 바와같이 TGT 세션 키를 래핑(wrapping)하기 위한 AS 답신 키를 교섭하기 위하여 Diffie-Hellman 키 교환을 사용할 수 있으며, RFC 4556는 그 전체가 인용에 의해 본원에 통합된다. 대안적으로, 공개 키 암호화는 RFC 4556의 단락 3.2.3.2에서 설명되는 바와같이 인증서의 공개 RSA 키에 의해 생성되는 AS 답신 키를 암호화하기 위하여 KDC에 의해 활용될 수 있다. 이는 프록시 디바이스(710)가 답신 키를 암호해독하도록 클라이언트 디바이스(705)에게 요청하게 할 수 있다. 이들 예들에서, 클라이언트 디바이스(705)는 클라이언트 디바이스(705)가 추가 티켓들을 요청하기 위하여 TGT의 임의의 사용을 제어하도록 하는 (그리고, 원하는 경우에 또한 이들 서비스 티켓들의 사용을 제어하도록 하는) TGT 세션 키와 같이 답신 키 및 자신이 보호하는 다른 키들을 유지하는 것을 선택할 수 있다. 따라서, 단계(953)에서 프록시 디바이스(710)가 세션 키 및/또는 티켓을 저장하는 것 대신에, 클라이언트 디바이스(705)는 세션 키 및/또는 티켓을 저장할 수 있다. 이는 클라이언트 디바이스(705)가 프록시 디바이스(710)에 대해 완전히 신뢰하는 것이 아니라 적당히 신뢰하는 경우에 적절할 수 있다.

[161] 공개 키 암호화를 사용하는 것에 대한 추가의 상세한 설명이 지금 설명될 것이다. 만일 RSA 공개 키 암호화가 AS 답신 키를 리턴하기 위하여 사용되면, 프록시 디바이스(710)는 KRB-AS-REP 답신 메시지의 encKeyPack 필드와 같이 자원으로부터 수신되는 세션 키 및/또는 티켓을 가진 답신 메시지의 데이터 필드에서, 서브-구조의 클라이언트 디바이스(705)로부터 인증서 개인 키 암호해독을 요청할 수 있다. 클라이언트 디바이스(705)에 의한 암호해독으로부터 발생하는 블로브는 RFC 3852의 단락 5.1에서 정의되는 서명된 데이터 구조일 수 있으며, RFC 3852는 그 전체가 인용에 의해 본원에 통합된다. 서명 데이터 구조는 RFC4556의 단락 3.2.3.2 에서 정의되는 바와같이 ReplyKeyPack 구조를 포함하는 콘텐츠 필드 및 콘텐츠 타입 id-pkinit-rkeyData를 가질 수 있다. 서명된 데이터에 대한 서명 필드는 클라이언트 디바이스(705)가 인증서 경로 검증을 수행하여 KDC의 아이덴티티를 확인하도록 하는 KCD의 인증서를 포함할 수 있다. 따라서, 만일 RSA-공개 키 교환이 사용되면, 클라이언트 디바이스(705)는 프록시 디바이스(710)가 인증중인 KDC의 아이덴티티를 완전히 검증하는 능력을 가질 수 있다. 만일 Diffie-Hellman 키 교환이 사용되면, 프록시 디바이스(710)는 KDC의 인증서를 보고 경로 검증을 수행할 수 있다. 프록시 디바이스(710)는 키 교환을 완료할 때 클라이언트 디바이스(705)를 수반할 필요가 없을 수 있다.

[162] 대안적으로, 클라이언트 디바이스(705)는 프록시 디바이스(710)에 대해 높은 신뢰성을 가질 수 있으며, 프록시 디바이스(710)로 하여금 세션 키 및/또는 티켓을 포함하는 메시지를 암호해독하도록 할 수 있다. 이들 실시예들에서, 프록시 디바이스는 메시지를 암호해독하고, 단계(953)와 관련하여 앞서 설명된 바와같이 세션 키 및/또는 티켓을 저장할 수 있다. 예컨대, 프록시 디바이스(710)는 Diffie-Hellman 키 교환을 제어하여, 프록시 디바이스(710)로 하여금 추가 클라이언트 디바이스(705) 지원 없이 (예컨대, TGT와 연관된) 세션 키를 복원하도록 할 수 있다. 이러한 경우에, 프록시 디바이스(710)는 프록시 디바이스(710)가 TGT의 완전한 제어를 실시할 수 있기 때문에 클라이언트 디바이스(705)에 의한 자유로운 위임 퍼미션들을 승인받을 수 있다.

[163] 대안적으로 또는 부가적으로, 프록시 디바이스는 세션 키 및/또는 티켓을 획득하기 위하여 마이크로소프트 액티브 디렉토리 환경을 활용할 수 있다. 마이크로소프트 액티브 디렉토리 환경에서, 프록시 디바이스(710)는 프록시 디바이스(710)가 도메인 제어기로부터 사용자의 패스워드 해시(예컨대, NTLM 크리덴셜들) 를 수신하도록 하는 PKINIT 프로세스의 확장을 지원할 수 있다. 이는 프록시 디바이스(710)가 NTLM 인증 챌린지들 뿐만아니라 케베로스 인증 챌린지들에 응답하도록 한다. 만일 클라이언트 디바이스가 (이전에 설명된 바와같이) TGT 세션 키에 대한 제어를 유지하기 위하여 AS 답신 키를 보유하지 않는다면, NTLM 패스워드 해시를 복원하기 위하여 프록시 디바이스(710)와 클라이언트 디바이스(705) 사이의 추가 상호작용이 요구되지 않을 수 있는데, 왜냐하면 NTLM 패스워드 해시는 TGT 세션 키를 전달하기 위하여 사용되는 동일한 AS 답신 키로 암호화될 수 있기 때문이다.

[164] 단계(954)에서, 프록시 디바이스(710)는 세션 키를 사용하여, 요청된 자원을 획득할 수 있다. 단계(956)에서, 서버 또는 다른 데이터베이스는 세션 키에 기초하여, 요청된 자원을 제공할 수 있다. 케베로스 인증을 위하여, 자원/인증 서버는 단계(952)에서 TGT 및 연관된 세션 키를 제공하였을 수도 있다. 이러한 예에서, 프록시 디바이스(710)는 TGT를 사용하여, 요청된 자원에 대한 추가 케베로스 서비스 티켓들을 획득함으로써 클라이언트 디바이스(705)의 사용자를 대신하여 인라인 인증을 수행할 수 있다. 도 8를 참조하면, 클라이언트-측 인증 모듈(830)은 프록싱된 HTTP 요청을 자원에 대해 재시도하기 위하여 PKINIT 및 케베로스 티켓 페칭(fetching)이 성공하였는지를 패킷 엔진(820)에 시그널링할 수 있다. 이는 세션 키/티켓 캐시가 파퓰레이트될 때 수행될 수 있다. 패킷 엔진(820)은 자원을 획득하기 위하여 서비스 티켓 및 세션 키로부터 생성된 적절한 케베로스 바이너리 구조(AP_REQ)를 포함하는 허가 헤더를 첨부할 수 있다. 이전에 논의한 바와같이, 클라이언트 디바이스(705)는 프록시 디바이스(710)를 완전히 신뢰하지 않을 수 있다. 이들 예들에서, 클라이언트 디바이스(705)는 TGT 세션 키를 계속 소유할 수 있으며, 개인 자원들에 대한 서비스 티켓들을 요청할 때 클라이언트 디바이스(705)와 상호작용하도록 프록시 디바이스(710)에 요구할 수 있다. 이러한 방식으로, 클라이언트 디바이스(705)는 자신을 위하여 프록시 디바이스(710)에 의해 액세스되고 있는 자원들의 아이덴티티의 가시성(visibility)을 보장할 수 있다.

[165] 단계(958)에서, 일단 프록시 디바이스(710)가 자원을 획득하면, 프록시 디바이스(710)는 클라이언트 디바이스(705)에 자원을 송신할 수 있다. 단계(960)에서, 클라이언트 디바이스(705)는 요청된 자원을 수신할 수 있으며, 예컨대 기업 데이터 또는 서비스들과 같은 데이터 또는 서비스들에 액세스함으로써 수신된 자원을 원하는대로 사용할 수 있다. 앞서 논의된 바와같이, 클라이언트 디바이스(705)상의 데이터 또는 서비스들을 보호하기 위하여, 데이터 또는 서비스들은 데이터 볼트들(616)로 암호화될 수 있다.

[166] 일부 실시예들에서, 클라이언트 디바이스(705)는 (예컨대, 프록시 디바이스(710)를 통과하는) VPN 터널, 또는 다른 타입의 통신 채널을 사용하여 쉐어포인트와 같은 자원(720)과 통신할 수 있다. 프록시 디바이스(710)가 (예컨대, 도 9a에 예시된 단계(914)에서) 자원(720)으로부터 자원 인증 챌린지를 수신하는 것 대신에, 클라이언트 디바이스(705)는 VPN 터널을 통해 챌린지를 수신할 수 있다. 클라이언트 디바이스(705)는 프록시 디바이스(710)가 인증을 돕도록 하기 위하여 프록시 디바이스(710)와 제 2 병렬 대화를 설정할 수 있다(또는 이전에 설정된 채널을 통해 프록시 디바이스와 통신할 수 있다). 이는 클라이언트 디바이스(705)가 케베로스 인증과 같은 특정 타입들의 인증을 수행하는 기능들을 갖지 않을 수 있기 때문에 유리하다. 제 2 병렬 대화 동안, 클라이언트 디바이스(705)는 자원 인증 챌린지를 프록시 디바이스(710)에 제시할 수 있다. 이후, 프록시 디바이스(710)는 인증 서비스(715)(예컨대, 케베로스 인증의 경우에 KCD)와 통신할 수 있으며, 클라이언트 디바이스(705)가 자원을 액세스하는데 필요한 세션 키(그리고, 케베로스 인증의 경우에 케베로스 티켓)를 획득할 수 있다. 이 시점에서, 클라이언트 디바이스(705), 프록시 디바이스(710) 및 인증 서비스(715) 사이에서 수행되는 단계들은 예컨대 도 9a-c를 참조로 하여 이전에 논의된 단계들(914, 916, 918, 924, 926, 928, 930, 932, 934, 936, 938, 970, 942, 944, 946, 948, 950, 952, 및/또는 953) 중 임의의 단계를 포함할 수 있다. 프록시 디바이스(710)가 인증 서비스(715)로부터 세션 키 및/또는 티켓을 수신한 이후에, 프록시 디바이스(710)는 클라이언트 디바이스와 프록시 디바이스 사이의 보안 통신 채널을 통해 키 및/또는 티켓을 클라이언트 디바이스(705)에 리턴할 수 있다. 이제, 클라이언트 디바이스(705)는 세션 키 및/또는 티켓을 사용하여 자원(720)으로부터 수신된 자원 인증 챌린지에 응답하여 요청된 자원을 획득할 수 있다. 대안적으로, 프록시 디바이스(710)가 클라이언트 디바이스(705)에 키 및/또는 티켓을 리턴하는 것 대신에, 프록시 디바이스(710)는 자체적으로 자원 인증 챌린지에 대한 응답을 구성하여 인증 응답을 클라이언트 디바이스(705)에 송신할 수 있다. 클라이언트 디바이스(705)는 요청된 자원을 획득하기 위하여 응답을 자원(720)에 포워드할 수 있다.

[167] 도 9a-c에 예시된 단계들은 이메일들 또는 다른 문서 타입들과 같은 문서들을 서명하는 것 및/또는 인증서 개인 키에 의해 보호되는 데이터를 암호해독하는 것에 적용될 수 있다. 문서들을 서명하는 예에서, 프록시 디바이스(710)는 본원에서 설명된 콘텍스트 정보로서 서명될 문서를 클라이언트 디바이스(705)에 제공할 수 있다.

[168] 도 9a-c에 예시된 단계들은 또한 데스크탑 및/또는 애플리케이션 가상화와 같은 가상화 환경에 적용될 수 있다. 가상화 환경에서, 클라이언트 디바이스(705)는 가상화 애플리케이션, 예컨대 도 6에 예시된 클라이언트 에이전트(604) 또는 원격 디스플레이 연결을 설정하기 위하여 사용되는 임의의 다른 클라이언트 애플리케이션(예컨대, CITRIX ICA, CITRIX RDP 등)을 실행할 수 있다. 이전에 언급한 바와같이, 클라이언트 디바이스(705)는 물리적 또는 가상적 스마트 카드에 저장된 키와 같은 개인 인증서를 계속해서 보안할 수 있다.

[169] 프록시 디바이스(710)는 애플리케이션 또는 데스크탑 가상화 서버, 예컨대 도 3에 예시된 가상화 서버(301)의 부분을 포함하거나 또는 이 부분일 수 있다. 이러한 서버들은 애플리케이션들을 실행할 수 있으며, 기업 자원들과 같은 자원들과 통신할 수 있다. 가상화 환경에서 프록시 디바이스(710)와 클라이언트 디바이스(705) 간의 통신들은 디스플레이 리모팅 프로토콜, 예컨대 CITRIX ICA 프로토콜 또는 CITRIX RDP 프로토콜을 통해 처리될 수 있다. 자원은 앞서 언급된 기업 자원들(504, 508 및/또는 608) 및/또는 기업 서비스들(508 및/또는 609)을 포함할 수 있다.

[170] 일부 실시예들에서, 도 9a-c에 예시된 단계들은 가상화 환경들을 위해 사용될 수 있다. 대안적으로, 일부 변화들이 이루어질 수 있다. 클라이언트 디바이스(705)와 프록시 디바이스(710) 간의 HTTP 통신들은 디스플레이 리모팅 프로토콜, 예컨대 CITRIX ICA 프로토콜 또는 CITRIX RDP 프로토콜을 활용하는 통신들로 대체될 수 있다. PKOp 프록시 SDK(835)는 제 3 자 애플리케이션을 포함할 수 있다. 따라서, 앞서 설명된 PKOperation 프록시 SDK(835)에 의해 수행되는 단계들은 제 3자 애플리케이션에 의해 수행될 수 있다. 일부 양상들에서, 프록시 디바이스(710)는 이들 단계들을 수행하기 위하여 제 3 자 애플리케이션을 호출할 수 있다.

[171] 예시적인 가상화 실시예들이 지금 설명될 것이다. 가상화 서버가 OS, 예컨대 마이크로소프트 윈도우즈를 실행하는 표준 OS 케베로스 구현이 사용될 수 있다. 예컨대, 케베로스 보안 서비스 제공자(케베로스 SSP) 인증 패키지(SSP/AP)가 사용될 수 있다. LsaCallAuthenticationPackage 및 KERB_CERTIFICATE_LOGON를 포함하는(그러나, 이에 제한되지 않음), 케베로스 SSP에 대한 다양한 프로그래밍 인터페이스들이 활용될 수 있다. 스마트 카드 균등 클라이언트 인증서들은 맞춤형 크리덴셜 제공자 및 맞춤형 키 저장 제공자(KSP)와 함께 이전에 논의된 PKINIT 케베로스 로그온 프로토콜을 인보크하기 위하여 사용될 수 있다. KSP는 개인 키, 예컨대 AuthPack 구조의 체크섬으로 서명될 수 있는 PKINIT의 특정 프로토콜 엘리먼트들에 노출될 수 있다. 부가적으로, 케베로스 SSP는 암호 동작들을 인보크하기 위하여 OS API들, 예컨대 서명을 생성할 때의 초기 단계인 체크섬을 컴퓨팅하기 위하여 사용되는 해시 API를 사용할 수 있다. 케베로스 SSP에 의해 수행된 해시 API 호출을 인터셉팅(intercepting)함으로써, 서명들이 계산될 프로토콜 엘리먼트들이 보여질 수 있다. 해시 API 호출들은 케베로스 SSP가 PKINIT를 수행하는 신뢰성 있는 LSASS 프로세스에 로드되는 맞춤형 SSP를 사용하여 인터셉팅될 수 있다.

[172] 이전에 논의한 바와같이, 서명될 엘리먼트들은 RFC4556의 단락 3.2.1에서 설명된 AuthPack 구조를 포함할 수 있다. 게다가, 프로토콜 엘리먼트는 ASN.1 바이너리 인코딩 규칙들을 따르는 구조와 같은 일부 적격 구조를 가질 수 있다. 부가적으로, 구조는 현재 시간을 나타내는 타임스탬프를 포함할 수 있으며, 따라서 클라이언트 디바이스(705)가 현재 시간의 클라이언트 디바이스의 자체의 지식에 대하여 기본 검증 체크를 수행하도록 할 수 있다. 실제로 가능성이 있을 수 있는 시간 변화량들을 고려하기 위하여, 클라이언트 디바이스(705)는 예컨대 인증 서버(예컨대, KDC)가 허용하는 것보다 더 넓은 변화 허용범위를 허용하기를 원할 수 있다. 예컨대, 클라이언트 디바이스(705)는 KDC가 허용할 수 있는 5분보다 오히려 그 자체의 시간 값 중 24시간내에 있는 시간 값을 받아들일 수 있다.

[173] 일부 실시예들에서, KSP는 인증서 서명 동작을 인보크하기 전에 케베로스 SSP에서 준비되었을 수도 있는 KRB-REQ-BODY 바이너리 구조를 신뢰성 있게 설치할 수 있으며, 이는 결국에 KSP를 호출한다. 만일 이러한 구조가 예컨대 스택 워크(stack walk)로부터 다시 케베로스 SSP로 설치될 수 있으면, AuthPack의 전체 검증이 가능할 수 있다. 대안적으로, 케베로스 SSP에 의해 수행되는 OS 해시 API 호출들을 인터셉팅함으로써, AuthPack 구조를 준비하기 위한 부분으로서 KRB-REQ_BODY의 체크섬을 컴퓨팅하기 위하여, KRB-REQ-BODY 구조가 직접 보여질 수 있다. 이후, 구조의 복사본은 PK 동작 요청의 부분으로서 프록시 디바이스(710)에 의해 클라이언트 디바이스(705)에 송신될 수 있다. 유사하게, AuthPack 구조는 서명 구성의 부분으로서 해시 API에게 보여질 수 있다. 이전에 논의한 바와같이, 클라이언트 디바이스(705)와 프록시 디바이스(710) 간의 특수 통신 채널은 맞춤형 GSS-API 메커니즘을 포함할 수 있다. 가상화 실시예에서, 특수 통신 채널은 디스플레이 리모팅 프로토콜의 가상 채널내에 있을 수 있다. 예컨대, SSPI 가상 채널이 사용될 수 있다. 일부 양상들에서, 만일 SSPI 교섭이 인증 그 자체를 완료하는 것을 실패하면, 디스플레이 리모팅 프로토콜에 의해 지원되는 다른 인증 방법들이 대신 사용될 수 있다.

[174] 일부 실시예들에서, 본원에서 설명된 양상들은 CITRIX XenAPP 및/또는 XenDesktop에 적용될 수 있다. XenApp 및 XenDesktop은 스마트 카드 판독기 인터페이스(예컨대, PC/SC)를 리모팅하는 스마트 카드 가상 채널을 사용하여 스마트 카드 리모팅을 지원할 수 있다. 본원에서 설명된 양상들은 윈도우즈 로그온을 위하여 PC/SC 리모팅을 대신할 수 있다. 스마트 카드는 예컨대 문서들을 서명하기 위하여 스마트 카드를 사용하는 애플리케이션들을 지원하기 위하여, 일단 세션이 설정되었으면 액세스될 수 있다. 이는 XA/XD에 의해 사용되는 스마트 카드 API 후크들이 윈도우즈 로그온 프로세스들(예컨대, winlogon.exe, logonui.exe 등)에 적용되는 것이 아니라 보통 다른 프로세스들에 계속해서 적용되도록 그 스마트 카드 API 후크들을 적절히 구성함으로써 실현될 수 있다.

[175] 클라이언트 디바이스(705)의 관점에서, 리모팅되는 인증서 동작들은 특정 형태의 PKINIT(예컨대, "sign-for-PKINIT-from-XenApp")과 연관될 수 있으며, PKINIT를 위하여 사용되는 스마트 카드 콘텍스트는 종결시에 즉시 릴리스(release)될 수 있으며, 따라서 애플리케이션은 필요한 경우에 추가 PIN 프롬프트들을 야기한다. 부가적으로 또는 대안적으로, 스마트 카드 콘텍스트는 프록시 디바이스(710) 또는 다른 디바이스 또는 서버에 대한 클라이언트 인증서 인증을 사용하여 SSL을 수행하기 위하여 예컨대 클라이언트 디바이스(705)에 의해 PKINIT 요청전에 사용되었을 수도 있다. 이러한 방식으로, 단일 PIN 프롬프트는 프록시 디바이스(710)를 식별하는 중계 서버에 대해 클라이언트 서버(705)에 의한 인증이 (이러한 서비스를 수행할 수 있는 복수의 디바이스들로부터의) 자원 액세스 동작들을 위해 사용되도록 하기에 충분할 수 있다. 이후, 선택된 프록시 디바이스(710)는 클라이언트 디바이스(705)에 의한 명시적 PIN 캐싱을 요구하지 않고 그리고 추가 PIN 프롬프트 없이 PKINIT를 수행할 수 있다. 애플리케이션 또는 데스크탑 가상화 서버들에 대한 도메인 로그인의 경우에, 통상적인 원격 스마트 카드 인증 방법들에 비하여 현저한 성능 개선이 달성될 수 있다. 게다가, 이는 가상 스마트 카드에 대한 전체 판독기 및 스마트 카드 인터페이스를 구현할 필요성 없이 달성될 수 있다.

[176] 앞서 설명된 양상들에 대한 다양한 수정들이 이루어질 수 있다. 각각의 엔티티(클라이언트 디바이스(705), 프록시 디바이스(710), 인증 서비스(715) 및/또는 자원(720))는 다른 엔티티들의 활동들을 알게 될 수 있다. 예컨대, 각각의 엔티티에게는 다른 엔티티들 중 하나 이상의 엔티티에 대한 식별자들이 제공될 수 있다. 식별자들은 도 9a-c와 관련하여 앞서 설명된 메시지 교환들 중 임의의 교환 동안 제공될 수 있다. 예컨대, 프록시 디바이스(710)는 프록시 디바이스(710)가 자원/인증 서버에 송신하는 정보 패킷들내에 클라이언트 디바이스(705)를 식별하는 정보를 주입할 수 있다. 프록시 디바이스(710)는 또한 프록시 디바이스(710)가 클라이언트 디바이스(705)에 송신하는 정보 패킷들내에 자원/인증 서버를 식별하는 정보를 주입할 수 있다. 유사한 방식으로, 클라이언트 디바이스(705)의 타입(예컨대, PC, 태블릿, 스마트폰 등)이 다른 엔티티들에 제공될 수 있다. 일부 양상들에서, RFC 6113에 설명된 바와같은 케베로스 프로토콜 확장들(예컨대, MS-KILE)은 다른 엔티티들에게 이용가능한 엔티티들의 활동들을 수행하도록 레버리지될 수 있으며, RFC6113는 그 전체가 인용에 의해 본원에 통합된다. 자원(720)에 식별 정보를 제공함으로써, 자원(720)은 데이터에 액세스하고 그리고/또는 또한 데이터에 대한 액세스를 제한하는 사람을 결정할 수 있다.

[177] 케베로스의 경우에, 네트워크 서비스 인증 동안 2개의 주요 식별자들을 제공하는 것이 일부 구현들(예컨대, 윈도우즈 서버(2012) 구현)에서 가능하다. 프록시 디바이스(710)는 마이크로소프트 케베로스 프로토콜 확장 도큐멘테이션(Microsoft Kerberos Protocol Extensions documentation)(MS-KILE) 및 RFC 6113에 설명된 바와같이 TGS 교환을 "방호(armor)"하기 위하여 자기 자신의 케베로스 아이덴티티(예컨대, TGT)를 사용할 수 있다. 이러한 기술은 RFC 6113에 또한 설명된 FAST로 지칭된다. 사용자/클라이언트 디바이스(705) 및 프록시 디바이스(710)에 대한 복합 아이덴티티가 생성될 수 있다. 윈도우즈 서버(2012)에서, 이러한 복합 아이덴티티는 ACL들이 머신 아이덴티티 및 다른 클레임들을 검사하는 능력을 가진 윈도우즈 ACL 프레임워크 최상부에서 동작하는 자원들에 노출될 수 있다. 윈도우즈 서버(2012) 구현이 설명되었지만, 당업자는 상이한 운영체제들을 사용하는 임의의 다른 구현들이 활용될 수 있음을 인식할 것이다.

[178] 프록시 디바이스(710)는 클라이언트 디바이스(705)의 아이덴티티를 반영할 수 있는, 클라이언트 디바이스(705) 그 자체에 관한 정보(다른 수단으로부터 알려진 경우에 예컨대 SSL에 의한 프록시 디바이스(710)에의 디바이스 인증서 인증) 또는 클라이언트 디바이스(705)로부터 프록시 디바이스(710)로의 인증 또는 자원 액세스 프로세스 동안 학습될 수 있는 디바이스의 다른 관련 속성들, 예컨대 디바이스의 타입, OS, 버전 또는 보안 포스처(posture)를 또한 적용하기 위하여 범용 클레임 메커니즘들을 사용할 수 있다.

[179] 앞서 설명된 양상들에 대한 다른 수정들은 클라이언트 인증서를 사용하는 동작들을 사용자에게 통지하기 위하여 사용자 경험을 조절하는 것을 포함할 수 있다. 프록시 디바이스(710)가 클라이언트 디바이스(705)에 제공하는 정보는 사용자에게 디스플레이될 수 있다. 다른 예에서, 디스플레이는 클라이언트 디바이스(705)가 로그온 프로세스의 도중에 있다는 것을 표시할 수 있으며, 로그온 프로세스는 또한 클라이언트 인증서를 활용할 수 있다. 예컨대, 클래스 1 판독기들을 사용하는 스마트 카드들에 대한 PIN 프롬프트가 또한 디스플레이될 수 있다. 수행될 동작을 충실히 표현하는 더 상세한 디스플레이들이 사용자에게 제공될 수 있다. 예컨대, 클라이언트 인증서를 사용하여 문서들을 서명하기 위하여, 문서는 검토를 위해 사용자에게 디스플레이될 수 있다. 수행될 트랜잭션의 적절한 요약 표시자가 또한 디스플레이될 수 있다. 스마트 카드 판독기 클래스들 중 임의의 클래스, 예컨대 클래스 4에서 상세한 디스플레이들이 활용될 수 있다. 일부 실시예들에서, 클라이언트 디바이스(705)는 스마트 카드 판독기를 시뮬레이트할 수 있다(또는 물리적 스마트 카드와 상호작용하는 경우에 이러한 판독기를 사용하여 지원할 수 있다).

[180] 사용자와의 불필요한 상호작용들이 방지될 수 있다. 예컨대, 리모팅된 인증서 동작들의 범위는 적절하게 그룹핑될 수 있으며(예컨대, 결속될 수 있으며), 따라서 동일한 그룹(예컨대, 동일한 자원 인증 프로토콜을 사용하는 동작들의 그룹)의 부분인 다수의 동작들은 동일한 그룹의 부분인 것으로 인식될 수 있으며, 논리 그룹이 생성될 수 있다. 일부 양상들에서, 동일한 그룹 내의 동작들에 대한 하나의 정보 디스플레이 또는 프롬프트가 사용자에게 디스플레이될 수 있다. 개략적으로 말하면, 이러한 논리 그룹핑은 통상적인 물리적 스마트 카드들의 경우에 스마트 카드 콘텍스트를 획득하고 릴리스하는 것에 대응한다.

[181] 비록 요지가 구성적 특징들 및/또는 방법적 동작들에 특정한 언어로 설명되었을지라도, 첨부된 청구항들에서 정의된 요지가 반드시 앞서 설명된 특정 특징들 또는 동작들로 제한되는 것이 아니라는 것이 이해되어야 한다. 오히려, 앞서 설명된 특정 특징들 및 동작들은 하기의 청구항들의 예시적인 구현들로서 설명된다.

Claims (20)

1. 인증 방법으로서,
   프록시 디바이스를 자원 관리 디바이스에 대하여 인증하기 위한 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이의 인증 세션 동안에, 클라이언트 디바이스가 서명을 제공하도록 하기 위한 요청을 상기 프록시 디바이스에 의해 생성하는 단계 ― 상기 클라이언트 디바이스가 서명을 제공하도록 하기 위한 요청은 (1) 상기 인증 세션 동안에 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이에서 사전에 교환된 인증 정보, 및 (2) 상기 인증 세션 동안에 상기 프록시 디바이스에 의해 상기 자원 관리 디바이스에 송신될 인증 정보 중 적어도 하나를 식별하는 콘텍스트 정보를 포함함 ―;
   상기 클라이언트 디바이스로부터의 상기 서명을 상기 프록시 디바이스에서 수신하는 단계; 및
   상기 서명을 상기 프록시 디바이스로부터 상기 자원 관리 디바이스로 송신하는 단계를 포함하는, 인증 방법.
2. 제 1항에 있어서,
   상기 클라이언트 디바이스가 이용 가능한 상기 클라이언트 디바이스로부터의 보안 인증서들의 리스트를 상기 프록시 디바이스에서 수신하는 단계; 및
   상기 인증 세션에 대한 보안 인증서를 선택하는 단계를 더 포함하며;
   상기 클라이언트 디바이스가 서명을 제공하도록 하기 위한 요청은 선택된 보안 인증서의 식별을 포함하는, 인증 방법.
3. 제 1항에 있어서, 상기 자원 관리 디바이스에 상기 서명을 송신한 이후에, 상기 서명에 대응하는 세션 키를 상기 프록시 디바이스에서 수신하는 단계를 더 포함하는, 인증 방법.
4. 제 3항에 있어서, 요청된 자원을 상기 자원 관리 디바이스로부터 획득하기 위하여 상기 프록시 디바이스에 의해 상기 세션 키를 사용하는 단계를 더 포함하는, 인증 방법.
5. 제 4항에 있어서, 상기 요청된 자원을 상기 프록시 디바이스로부터 상기 클라이언트 디바이스로 송신하는 단계를 더 포함하는, 인증 방법.
6. 제 1항에 있어서, 상기 인증 세션은 SSL 인증을 포함하며, 상기 콘텍스트 정보는 상기 인증 세션 동안에 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이에서 사전에 교환된 SSL 인증 메시지들을 포함하는, 인증 방법.
7. 제 1항에 있어서, 상기 인증 세션은 케베로스(Kerberos) 인증을 포함하며, 상기 콘텍스트 정보는 케베로스 데이터 구조를 식별하는 정보를 포함하는, 인증 방법.
8. 제 7항에 있어서, 상기 케베로스 데이터 구조는 추상 구문 표기법(Abstract Syntax Notation) 1을 포함하는, 인증 방법.
9. 제 1항에 있어서, 상기 인증 세션은 케베로스 인증을 포함하며, 상기 콘텍스트 정보는, 상기 케베로스 인증을 위하여 사용된 케베로스 도메인, 상기 클라이언트 디바이스와 연관된 케베로스 원이름, 상기 인증 세션을 위해 사용된 키 분배 센터의 식별자, 요청된 티켓의 유효 기간, 및 상기 인증 세션 동안 세팅되었던 케베로스 플래그들 중 적어도 하나를 포함하는, 인증 방법.
10. 제 1항에 있어서, 상기 콘텍스트 정보는 상기 인증 세션과 연관된 타임스탬프를 식별하는, 인증 방법.
11. 제 1항에 있어서, 상기 콘텍스트 정보는 상기 인증 세션의 프로토콜 타입을 식별하는, 인증 방법.
12. 제 1항에 있어서, 상기 서명은 상기 클라이언트 디바이스의 스마트 카드로부터 제공되는, 인증 방법.
13. 프록시 디바이스로서,
    프로세서; 및
    컴퓨터-실행가능 명령들을 저장한 메모리를 포함하며;
    상기 컴퓨터-실행가능 명령들은, 상기 프로세서에 의해 실행될 때, 상기 프록시 디바이스로 하여금,
    프록시 디바이스를 자원 관리 디바이스에 대하여 인증하기 위한 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이의 인증 세션 동안에, 클라이언트 디바이스가 서명을 제공하도록 하기 위한 요청을 생성하고 ― 상기 클라이언트 디바이스가 서명을 제공하도록 하기 위한 요청은 (1) 상기 인증 세션 동안에 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이에서 사전에 교환된 인증 정보, 및 (2) 상기 인증 세션 동안에 상기 프록시 디바이스에 의해 상기 자원 관리 디바이스에 송신될 인증 정보 중 적어도 하나를 식별하는 콘텍스트 정보를 포함함 ―;
    상기 클라이언트 디바이스로부터 상기 서명을 수신하며; 그리고
    상기 서명을 상기 자원 관리 디바이스에 송신하도록 하는, 프록시 디바이스.
14. 제 13항에 있어서, 상기 메모리는 컴퓨터-실행가능 명령들을 저장하며,
    상기 컴퓨터-실행가능 명령들은 상기 프로세서에 의해 실행될 때, 상기 프록시 디바이스로 하여금, 상기 자원 관리 디바이스에 상기 서명을 송신한 이후에, 상기 서명에 대응하는 세션 키를 수신하도록 하는, 프록시 디바이스.
15. 제 14항에 있어서, 상기 메모리는, 컴퓨터-실행가능 명령들을 저장하며,
    상기 컴퓨터-실행가능 명령들은 상기 프로세서에 의해 실행될 때, 상기 프록시 디바이스로 하여금, 요청된 자원을 상기 자원 관리 디바이스로부터 획득하기 위하여 상기 세션 키를 사용하도록 하는, 프록시 디바이스.
16. 제 13항에 있어서, 상기 인증 세션은 SSL 인증을 포함하며, 상기 콘텍스트 정보는 상기 인증 세션 동안에 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이에서 사전에 교환된 SSL 인증 메시지들을 포함하는, 프록시 디바이스.
17. 제 13항에 있어서, 상기 인증 세션은 케베로스 인증을 포함하며, 상기 콘텍스트 정보는 케베로스 데이터 구조를 식별하는 정보를 포함하는, 프록시 디바이스.
18. 인증 방법으로서,
    클라이언트 디바이스가 서명을 제공하도록 하기 위한 프록시 디바이스로부터의 요청을 상기 클라이언트 디바이스에서 수신하는 단계 ― 상기 클라이언트 디바이스가 서명을 제공하도록 하기 위한 요청은 (1) 상기 프록시 디바이스를 자원 관리 디바이스에 대하여 인증하기 위한 상기 프록시 디바이스와 상기 자원 관리 디바이스 사이의 인증 세션 동안에, 요청된 자원과 연관된 상기 자원 관리 디바이스와 상기 프록시 디바이스 사이에서 사전에 교환된 인증 정보, 및 (2) 상기 인증 세션 동안에 상기 프록시 디바이스에 의해 상기 자원 관리 디바이스에 송신될 인증 정보 중 적어도 하나를 식별하는 콘텍스트 정보를 포함함 ―;
    상기 클라이언트 디바이스에 의해 상기 콘텍스트 정보를 검증하는 단계; 및
    상기 콘텍스트 정보를 검증하는 것에 응답하여, 보안 인증서에 대응하는 서명을 상기 클라이언트 디바이스로부터 상기 프록시 디바이스로 송신하는 단계를 포함하는, 인증 방법.
19. 제 18항에 있어서, 상기 보안 인증서는 상기 클라이언트 디바이스에 연결된 스마트 카드상에 저장되는, 인증 방법.
20. 제 18항에 있어서,
    요청에 응답하여, 상기 클라이언트 디바이스가 이용 가능한 하나 이상의 보안 인증서들을 포함하는 리스트를 상기 클라이언트 디바이스로부터 상기 프록시 디바이스로 송신하는 단계를 더 포함하며;
    상기 클라이언트 디바이스가 서명을 제공하도록 하기 위한 수신된 요청은 하나 이상의 보안 인증서들을 포함하는 리스트로부터 선택된 보안 인증서의 식별을 포함하는, 인증 방법.

Images