KR20160043044A

KR20160043044A - 대량의 vpn 접속들을 종료시키는 게이트웨이 디바이스

Info

Publication number: KR20160043044A
Application number: KR1020167006550A
Authority: KR
Inventors: 티모시 에스 샴페인; 케빈 피 폭스; 브라이언 에이치 페스카토어; 케네스 원트; 다니엘 머피
Original assignee: 모카나 코포레이션
Priority date: 2013-08-15
Filing date: 2014-08-14
Publication date: 2016-04-20
Also published as: EP3033861A4; US8997208B2; US20150052599A1; JP2016530814A; EP3033861A1; WO2015023887A1

Abstract

VPN 게이트웨이 디바이스는 디바이스들을 실행하는 앱들로부터의 대량의 접속들을 할당, 관리, 종료시켜, 대규모 퍼-앱 VPN 모바일 환경을 가능하게 할 수 있다. 모바일 디바이스 사용자가 모바일 디바이스 상의 앱을 열 때, VPN 게이트웨이는 고유 IP 어드레스를 앱으로 송신한다. 게이트웨이는 또한 앱 연합체 쿠키를 앱으로 송신한다. 앱은 앱 연합체 쿠키를 제 2 앱과 공유한다. VPN 게이트웨이는 그후 제 2 앱에게 동일한 고유 IP 어드레스를 할당한다. 게이트웨이는 그후 포트들의 범위를 제 1 앱으로 송신한다. 앱은 디바이스로부터 VPN 게이트웨이로의 데이터 송신을 위해 포트들의 범위에서의 포트를 이용한다. 게이트웨이는 VPN 을 통해서 제 1 앱으로부터의 데이터 송신을 수신하고 소스 포트에 기초하여 데이터 송신이 제 1 앱으로부터 유래하였다고 결정한다.

Description

대량의 VPN 접속들을 종료시키는 게이트웨이 디바이스{GATEWAY DEVICE FOR TERMINATING A LARGE VOLUME OF VPN CONNECTIONS}

관련 출원들에 대한 상호-참조

본 출원은 Champagne 등에 의해 "METHOD AND SYSTEM FOR REPORTING A JAILBROKEN/ROOTED DEVICE AND TERMINATING MULTIPLE SECURE TUNNEL CONNECTIONS AT A GATEWAY COMPONENT" 란 명칭으로, 2013년 8월 15일 자에 출원되어 계류중인, 본원에 참고로 전체적으로 포함된, 미국 가출원 번호 제 61/866,320호에 대해 U.S.C. § 119(e) 하에서 우선권을 주장한다.

본 발명은 소프트웨어, 컴퓨터 네트워크 통신들, 및 VPN 게이트웨이 구성요소들에 관한 것이다. 좀더 구체적으로, 본 발명은 모바일 디바이스 상의 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 접속들을 생성하는 것에 관한 것이다.

업무를 위해 모바일 디바이스들 및 모바일 앱들을 활용하거나 또는 기업 방화벽 뒤의 서비스들에 액세스하려는 사용자들을 가지는 기업들에서 모바일 보안에 대한 요구가 증대하고 있다. 모바일 디바이스로부터 VPN 게이트웨이로의 VPN 에 제공하는 종래의 소프트웨어가 있지만, 보안의 레벨이 종종 불충분하며 기업-이용가능 앱 사용에 관해 적은 정보를 기업에 제공한다. 이 종래의 시나리오에서, 하나의 VPN 이 모든 기업 앱들로부터 VPN 게이트웨이로의 모든 데이터에 의해 사용된다. 다시 말해서, VPN 은 디바이스 레벨에 있다. 그들의 개인 모바일 디바이스들 상에서 업무-관련된 앱들을 실행하여 보안 터널을 통해서 업무-관련된 또는 기업-관련된 서비스들에 접속할 필요가 있는 증대하는 사용자들의 수를 가정하면, 모바일 디바이스로 그리고 모바일 디바이스로부터 기업 VPN 게이트웨이로 가는 모든 데이터에 대해 단일 VPN 파이프를 가지는 것은, 해커들 및 다른 부정한 행위자들이 데이터를 훔치고 조작하는 것 또는 기업들에 결국 해를 끼칠 수 있는 모바일 디바이스들 상에 악성 소프트웨어를 설치하는 것을 방지하는데 요구되는 보안의 레벨을 제공하지 않는다.

보안의 높은 레벨은 (전체 디바이스는 커녕) 다수의 앱들이 단일 VPN 을 공유하지 않도록 하는, 즉, 디바이스-레벨 보안 VPN 터널을 이용하지 않는 것을 수반할 것이다. 보안의 더 나은 레벨은 각각의 앱이 게이트웨이로의 그의 자신의 전용 VPN, 즉, 보안화되고 그 앱에 대한 데이터를 오직 전송하는 VPN, 또는 앱들의 연합체에 대한 데이터를 오직 전송하는 적어도 VPN 을 갖도록 하는 것일 것이다. 하나의 시나리오에서, 개인 모바일 디바이스 상의 각각의 기업 앱은 (사용자의 고용주, 클라이언트, 공급자, 또는 기타 등등에 의해 동작되는) 기업 게이트웨이에의 그의 자신의 VPN 접속을 갖는다. 더욱이, 기업 VPN 게이트웨이는 많은 VPN 접속들 (예컨대, 수 십만의 VPN들) 을 관리 및 생성할 수 있어야 하며, 각각의 VPN 접속이 사설, 고유 IP 어드레스를 필요로 할 수도 있다는 점을 명심해야 한다. 기업 VPN 게이트웨이는 또한 이 많은 수의 VPN 접속들을 종료시키고 내부 기업 서버들로부터 유입하고 유출하는 트래픽을 관리가능해야 할 것이다.

본 발명의 일 양태에서, 디바이스 상의 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 데이터를 통신하거나 또는 송신하는 방법이 설명된다. 모바일 디바이스 사용자가 모바일 디바이스 상의 앱을 열 때, VPN 게이트웨이는 고유 IP 어드레스를 앱으로 송신한다. 게이트웨이는 또한 앱 연합체 쿠키를 앱으로 송신한다. 앱 ("제 1 앱") 은 제 2 앱과 앱 연합체 쿠키를 공유하며, 여기서, 제 1 및 제 2 앱들은 모바일 디바이스 상의 앱들의 연합체 내에 있다. VPN 게이트웨이는 그후 제 1 앱에 할당된 동일한 고유 IP 어드레스를 제 2 앱에 할당한다. 게이트웨이는 그후 (모바일 디바이스의) 포트들의 범위를 제 1 앱으로 송신한다. 앱은 포트들의 범위에서의 포트를, 디바이스로부터 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 이용한다. 게이트웨이는 VPN 터널을 통해 제 1 앱으로부터의 데이터 송신을 수신하고 그 소스 포트에 기초하여 그 데이터 송신이 제 1 앱으로부터 유래하였다고 결정한다.

다른 실시형태에서, VPN 게이트웨이는 제 2 포트 범위를 제 2 앱으로 송신한다. 제 2 앱은 이 포트 범위에서의 포트를, 데이터를 디바이스로부터 게이트웨이로 송신하기 위한 소스 포트로서 이용한다. 게이트웨이는 소스 포트에 기초하여 그 데이터 송신이 제 2 앱으로부터 유래하였다고 결정한다. 다른 실시형태에서, 고유 IP 어드레스가 동일한 연합체에서의 모든 앱들에 의해 사용되며 이와 같이 연합체에서의 각각의 앱은 그의 자신의 고유 IP 어드레스를 가질 필요는 없으나 게이트웨이와의 그의 자신의 사설 VPN 을 여전히 갖는다. 다른 실시형태에서, 제 1 및 제 2 앱들은 그들이 VPN 게이트웨이 IP 어드레스 및 VPN 게이트웨이 도메인 이름으로 래핑될 때 구성되며, 이에 의해 각각의 앱이 그들이 처음 실행할 때 게이트웨이와 접촉가능하게 한다. 앱들은 또한 그것이 수신하는 연합체 쿠키를 연합체에서의 다른 앱들과 공유하도록 지시받으며, 앱들은 또한 그것이 연합체 쿠키에 대해 요구될 수도 있는 것 또는 그것이 그것이 실행할 때 연합체 쿠키를 제공해야 할 수도 있다는 것을 알고 있다.

본 명세서의 일부를 형성하며 본 발명의 특정 구체예들이 예시적인 방식으로 도시된 첨부된 도면들을 참조한다.
도 1a 는 본 발명의 앱 제어 프로세스의 개관을 도시하는 블록 다이어그램이다.
도 1b 는 본 발명의 앱 제어 프로세스의 대안적인 실시형태를 도시하는 블록 다이어그램이다.
도 2 는 본 발명의 일 실시형태에 따른, 앱 보안 프로그램의 구성요소들을 도시하는 블록 다이어그램이다.
도 3 은 본 발명의 일 실시형태에 따른, 디바이스 상에 앱을 다운로드하기 전에 앱을 보안하는 프로세스를 도시하는 플로우 다이어그램이다.
도 4 는 일 실시형태에 따른, 정책 관리기에서 수행되는 방법의 플로우 다이어그램이다.
도 5 는 일 실시형태에 따른, 핸드셋 또는 모바일 디바이스 상에서 실행하는 보안 랩핑된 앱의 프로세스를 도시하는 플로우 다이어그램이다.
도 6 은 일 실시형태에 따른, 앱 보안 제어 시스템의 시스템 아키텍처 다이어그램이다.
도 7 은 일 실시형태에 따른, 퍼-앱 VPN (per-app VPN) 을 구현하는데 요구되는 모바일 디바이스에서의 구성요소들 및 모듈들을 나타내는 블록도이다.
도 8 은 본 발명의 일 실시형태에 따른, 앱 VPN 을 구현하는 프로세스의 흐름도이다.
도 9 는 본 발명의 여러 컨셉들을 예시하는 네트워크의 구성요소들을 나타내는 블록도이다.
도 10 은 일 실시형태에 따른, 데이터를 기업 서버로부터 특정의 앱으로 되라우팅하는 방법을 결정하기 위해 게이트웨이 디바이스에 의해 실행되는 프로세스의 흐름도이다.
도 11 은 일 실시형태에 따른, VPN 게이트웨이 활성 세션 모니터 스크린을 나타내는 디스플레이의 스크린 샷이다.
도 12a 및 도 12b 는 본 발명의 여러 실시형태들을 구현하기에 적합한 컴퓨팅 시스템의 블록 다이어그램들이다.

애플리케이션 보안 프로세스 및 시스템의 예시적인 실시형태들이 설명된다. 이러한 예들 및 실시형태들은 단지 배경을 부가하여 본 발명의 이해를 돕기 위해 제공된다. 따라서, 본 발명이 본원에서 설명되는 구체적인 세부 사항들 중 일부 또는 모두 없이 실시될 수도 있음을 당업자에게는 자명할 것이다. 다른 경우, 널리 공지된 컨셉들은 본 발명을 불필요하게 흐리지 않도록 자세히 설명되지 않았다. 다음 예들, 예시들, 및 문맥들이 범위 또는 설정에서 한정적인거나 또는 제한적인 것으로 받아들이지 않도록, 다른 애플리케이션들 및 예들이 가능하다. 당업자가 본 발명을 실시하는 것이 가능하도록 이들 실시형태들이 충분히 자세히 설명되었지만, 이들 예들, 예시들, 및 문맥들은 제한적이지 않으며, 다른 실시형태들이 사용될 수도 있으며 본 발명의 정신 및 범위로부터 일탈함이 없이 변화들이 이루어질 수도 있다.

디바이스 소프트웨어 애플리케이션들이 디바이스, 특히, 모바일 디바이스를 감염시키거나 또는 아니면 손상시키는 것을 방지하는 방법들 및 시스템이 여러 도면들에서 설명된다. 스마트폰들, 태블릿 컴퓨터들, 게이밍 디바이스들, 및 휴대형 컴퓨팅 디바이스들과 같은, 다양한 모바일 디바이스들 상에서 종종 사용되는 이들 유형들의 애플리케이션들은 "앱들" 로서 일반적으로 지칭된다. 이들 앱들은 또한 비-모바일 디바이스들, 예컨대, TV들, 컴퓨터들, 자동차들, 및 다른 최근 생겨난 스마트 디바이스 카테고리들 상으로 다운로드될 수도 있다. 설명된 방법들 및 시스템들은 모바일 디바이스들 상에서의 동작에 한정시키려고 의도되지 않는다. 이들 디바이스 프로그램들 또는 앱들은 만연하여 현재 널리 유행하고 있다. 현재, 앱들은 Java 또는 C 로 일반적으로 작성된다. 본원에서 설명되는 방법들 및 시스템들은 작성된 앱들 또는 상이한 플랫폼들에 대해 상이한 언어들로 작성된 앱들에 적용될 수도 있다. 대부분의 앱들은, 모두는 아니지만, 그의 의도된 기능을 수행하기 위해 앱이 필요로 하는 특정의 서비스를 획득하기 위해 모바일 디바이스의 운영 시스템과 통신해야 하며, 이 서비스는 대개 오직 운영 시스템으로부터만 이용가능하다. 이러한 사용되는 서비스의 일반적인 예는 앱이 필요로 할 수도 있는 디바이스의 로케이션을 획득하는 GPS 이다. 그러나, 이러한 노출 때문에, 앱들은 디바이스에 대해 취약성이 있으며 사용자에게 보안 및 프라이버시 위험을 일으킨다. 회사들은 그의 데이터 및 소프트웨어에의 액세스를 제어하고 보안화하기 위해 중앙집중화된 정책을 향상할 수 있기를 원한다. 이것은 또한 최종 사용자들 (즉, 개인들, 가정 사용자들, 및 기타 등등) 에 대해서도 사실이다. 이는 기업 IT 부서들이 법인 데이터의 통제를 유지하는 것을 가능하게 한다. 아래에 설명되는 방법들은 모바일 디바이스들 상으로 다운로드되는 앱들에 대해 보안을 제어하는 중앙집중화된 방법을 제공하며, 여기서 디바이스들은 종업원의 개인 전화 또는 고용주의 전화이므로, 그들 앱들이 보안 위협을 일으키지 않는다. 본 발명의 여러 실시형태들은 또한 그들의 개인 모바일 디바이스들이 악성 소프트웨어로부터 안전하다는 것을 보장하기 위해 부모들 및 개인들에 의해 (즉, 홈 또는 비-작업 환경들에서) 사용될 수도 있으며, 또한 제어들을, 예컨대 사용 시에 적용하는데 이용될 수도 있다. 본 발명의 앱 제어 소프트웨어의 실시형태들은 또한 모바일 디바이스 데이터 보호 및 백-업을 위해 그리고 애플리케이션-레벨 원격 계측 (telemetry) 을 위해 이용될 수도 있다.

도 1a 는 본 발명의 앱 제어 프로세스의 개관을 도시하는 블록도이다. 이는 특정의 구성 또는 환경에 얽매이지 않는 한 프로세스의 일반적인 설명이다. 앱 (102) 은 임의 종류의 엔터티 (개인, 소프트웨어 개발자, 고용주, 등) 일 수도 있는 앱 제공자 (100) 에 의해 제공된다. 이는 일반적으로 보호되지 않으며 앱을 둘러싸는 유일한 보안은 운영 시스템에 의해 제공된다. 일단 로드되면, 디바이스 상에서 앱이 실행하는 방법 상에서 이루어진 유일한 보호 (shield) 및 체킹이, 운영 시스템에 의해 제공된다.

본 발명은 디바이스의 운영 시스템에 의해 제공되지 않는 앱들의 추가적인 보안을 가능하게 한다. 보안 애플리케이션 프로그램 (104) 이 앱 (102) 에 적용된다. 또는 앱 (102) 이 제 3 자 앱 보안 제공자에 의해 제공될 수도 있는 프로그램 (104) 에 입력된다. 일 실시형태에서, 보안 애플리케이션 프로그램 (104) 은 상이한 위치들에 있을 수도 있는 정책 관리기 및 정책 랩퍼 (wrapper) 를 갖는다. 이들은 도 2 에서 더욱 자세히 설명된다. 일단 보안 프로그램 (104) 이 앱 (102) 에 적용되면, 앱은 디바이스가 보호되도록 보안 계층으로 래핑된다. 이는 보안 앱 (106) 으로서 도시된다. 일 실시형태에서, 보안 앱 (106) 이 그후 스마트 전화 또는 태블릿 컴퓨터와 같은 모바일 디바이스 (108) 상으로 다운로드되며, 여기서 보안 앱은 디바이스 (108) 에 대한 손상을 입힐 위험 없이 안전하게 실행한다. 다른 이점은 보안 앱 (106) 이 또한 회사 또는 사용자에게 앱을 제공하는 다른 엔터티, 예컨대 종업원에게 앱을 제공하는 고용주에 의해 관리될 수도 있다는 점이다. 예를 들어, 사용자가 회사를 떠나는 경우, 회사는 디바이스로부터 앱 및 임의의 관련된 데이터를 자동적으로 삭제할 수도 있다. 다른 예에서, 부모가 다른 사람 (예를 들어, 자녀) 에 의해 이용되는 앱들을 제한하거나, 시간의 양, 예를 들어, 하루 10 분을 제한하거나 또는 어떤 웹 사이트들이 앱에 의해 액세스될 수도 있는지를 제한할 수도 있다. 또는, 부모는 앱이 미지의 제 3 자들에게 자녀의 위치를 누설하는 것을 염려한다. 많은 다른 예들이 있을 수도 있다. 언급한 바와 같이, 도 1a 는 앱을 보안화하여 앱을 디바이스 상으로 다운로딩하는 일반적인 프로세스를 나타내려고 의도된 것이다. 이 실시형태에서, 앱 (102) 은 디바이스에 위해를 초래하는 것으로부터, 디바이스 상으로 다운로드된 이후가 아닌, 그 이전에 보안화된다는 점에 유의한다. 다른 실시형태에서, 앱은 디바이스 상으로 다운로드된 이후에 보안화되지만, 운영 시스템과 상호작용할 수 있기 전에 보안화된다.

도 1b 는 대안적인 실시형태를 도시하는 블록도이다. (또한, 앱 제공자에 의해 공급되는) 비보안 앱 (110) 이 모바일 디바이스 (112) 상으로 다운로드된다. 이 실시형태에서, 그러나, 비보안 앱 (110) 의 실제 설치를 차단하는 특수하게 설계된 앱이 디바이스 (112) 상에 있을 수도 있다. 특수 앱 (미도시) 은 비보안 앱 (110) 을 앱 보안 프로그램 (114) 으로 앱 (110) 을 재전송한다. 비보안 앱 (110) 은 보안 정책으로 랩핑되며, 최종 앱은 보안된 앱 (116) 으로 도시된다. 그것은 그후 다운로드되어 특수 앱에 의해 디바이스 (112) 상에 설치되도록 허용된다. 이와 같이, 예를 들어, 앱들에 의해 제기되는 보안 위협들로부터 그녀의 전화를 보호하기를 원하는, 개인 또는 가정 사용자는 앱들이 그녀의 전화 상으로 다운로드되기 전에, 단지 2 개의 예들만 말하자면, 제 3 자 서비스에 의해 또는 그녀의 모바일 전화 사업자에 의해 보안된 (랩핑된) 앱들을 가질 수 있다. 이러한 보안 랩핑은 사용자가 어디로부터 앱을 다운로드하는지에 상관없이 앱에 대해 행해질 수 있음에 유의해야 한다. 또한, 도 1a 및 도 1b 에서, 구성요소들과 소프트웨어 사이의 네트워크 및 접속들이 포괄적으로 도시된다는 점에 유의해야 될 수도 있다. 송신들은 주로 인터넷 (미도시) 을 통하나, 또한 사설 네트워크 또는 양자 모두 내에서 있을 수도 있다.

도 2 는 본 발명의 일 실시형태에 따른, 앱 보안 프로그램의 구성요소들을 도시하는 블록도이다. 일 실시형태에서, 보안 프로그램은 2개의 주요 구성요소들, 즉, 정책 관리기 및 정책 래퍼를 갖는다. 정책 관리기 (202) 는 모바일 디바이스에 대한 보안을 설정하는데 책임이 있는 관리자 또는 다른 개인으로부터의 입력을 수락한다. 그가 하나 이상의 모바일 디바이스들의 보안을 통제하기 때문에 그 사람은 통제자로 지칭될 수도 있다. 보안 정책은 다양한 사용자 인터페이스 화면들을 이용하여 설정될 수도 있다. 지오 펜싱 (geo-fencing) (예를 들어, 앱은 오직 건물 내에서만 이용될 수 있다) 및 다른 것들을 포함한, 수많은 정책들의 예들이 있다. 또한, 앱 보안 프로그램을 제공하는 서비스 제공자 또는 엔터티가 가정 사용자들에게 유용할 수도 있는 디폴트 정책 및 보안 설정들을 제공할 수도 있다. 정책 설정들의 예들이 아래에 설명된다. 정책 입력 (204) 이 정책 관리기 (202) 에 입력된다. 정책 관리기 (202) 는 통제자로부터 입력/설정들을 취하여 정책들 또는 메타 데이터 (206) 를 생성한다. 메타-데이터 (206) 의 포맷 또는 유형은 변할 수 있다. 메타-데이터들은 본질적으로 통제자로부터의 정책 설정들을 반영한다.

메타데이터 (정책들) (206) 은 정책 래퍼 (208) 에 대한 입력으로서 이용될 수도 있다. 일 실시형태에서, 이 프로그램의 구성요소는 정책들을 취하고 그들을 이용하여, 앱을 래핑함으로써 앱 (210) 을 보안화한다. 래퍼 (208) 는 핸드헬드 디바이스 (212) 로부터 앱 (210) 을 수신한다. 일 실시형태에서, 래퍼 (208) 는 전화 (212) 상으로 다운로드된 원래 앱 (214) 대신 앱 (210) 의 복사본을 수신한다 (위의 도 1b 참조). 여기서 핸드헬드 디바이스 (212) 사용자는 앱 제공자 (218) 로부터 비보안 앱 (216) 을 다운로드하려고 시도한다. 도 1a 에서 설명된 시나리오에서, 복사본 대신에 앱 그 자체 상에서 동작할 수도 있다. 이는 마켓 플레이스 또는 앱 스토어가 보안되지 않은 버전과 함께 앱의 보안된 버전을 고객들에게 제공하는 (또는 오직 보안된 버전만을 제공하는) 경우일 수도 있다. 보안 버전 (220) (보안-래핑된 버전) 이 정책 랩퍼 (208) 로부터 디바이스 (212) 로 반환된다.

메타데이터 (206) 는 또한 로컬 정책 파일 (이미 디바이스 상에 있는 기존의 정책) 을 업데이트하는데 이용될 수도 있다. 로컬 정책 파일은 디바이스 (212) 상에 상주하는 정책 파라미터들을 업데이트하는데 이용된다. 예를 들어, "지오펜싱" 의 (즉, 소정의 물리적 영역들로 앱의 이용을 제한하는) 경우에, 통제자에 의해 제어되는 GPS 위치들은 시간이 경과함에 따라 변할 확률이 크다. 이러한 변화가 일어나는 경우, 새로운 정책들이 2 가지의 상이한 방식들로 적용될 수 있다. 하나는 새로운 정책을 발생시켜 그것을 원래의 앱에 적용하는 것이다 (즉, 새로운 정책으로 앱을 랩핑한다). 다른 방식은 정책 내에 암호화된/서명된 정책의 "변하는" 부분을 갖는 로컬 정책 데이터 파일에 기초한 동적 구성을 허용하는 것이다. 예를 들어, IT 종사자는 진단의 목적들으로 디바이스 상에 상주하는 IT 앱을 통해서 직접 디바이스 상에 구성을 오버라이드하는 능력을 원할 수도 있다.

일 실시형태에서, 정책들은 2개의 구성요소들: 고정 부분 및 가변 부분을 갖는다. 고정 부분은 정책 파일 내에 설명된 콘텐츠 (예컨대, "하루 중 소정 시간들에서 GPS 를 보호한다") 이다. 가변 부분은 일반적으로 콘솔을 통해 통제자에 의해 제공된다 (예를 들어, "GPS 가 보호되어야 할 시간들이 언제인가?"). 가변 부분은 새로운 정책을 적용하지 않고 변할 수 있다.

정책 설계자들은 정책의 가변 부분을 선행하여 선택할 수 있으며, 기본적으로 정책 파일 내에 정적으로 모든 데이터 또는 콘텐츠를 "임베딩한다". 이 경우, 콘솔은 정책을 커스터마이즈하는 어떤 방법도 갖지 않는다.

정책 설계자가 정책에 일부 변하는 구성요소를 포함시키도록 선택하는 경우, (콘솔 상의) 변하는 데이터에 변화들이 이루어질 때, 최신 변화들을 반영하기 위해 새로운 데이터 파일이 디바이스로 전송될 수 있다. 이러한 파일은 적절한 정책에 새로운 데이터를 적용하기 위해 디바이스 상에서 앱 보안 코드에 의해 (정책을 우회하는 악의적인 앱을 방지하도록) 암호화/서명되며, 디바이스로 다운로드되어, 이용될 것이다.

이러한 변화들 및 업데이트들은 런타임 (runtime) 에 로컬 정책 업데이트 구성요소 (222) 에 의해 행해질 수도 있다. 이러한 구성요소는 디바이스 (212) 상에 업데이트된 정책 파라미터들을 생성한다. 그후, 래핑된 앱 (220) 은 업데이트된 정책 파라미터들을 이용할 것이다.

일 실시형태에서, 정책 관리기 (202) 및 정책 래퍼 (208) 는 동일한 앱 보안 프로그램 내의 구성요소들이고, 동일한 컴퓨터 상에서 동작할 수도 있다. 다른 실시형태들에서, 관리기 및 래퍼 구성요소들은 별개의 컴퓨터들 상에 있을 수도 있다. 예를 들어, 정책 관리기 (202) 는 하나의 사이트에서 서버 상에 있을 수도 있으며, 정책 래퍼 (208) 는 다른 사이트에서 컴퓨터 상에 있을 수도 있으며 상이한 엔터티 또는 동일한 엔터티에 의해 관리될 수도 있다. 일괄하여, 관리기 및 래퍼는 일 실시형태에서 보안 서비스 제공자에 의해 동작되는 앱 보안 프로그램을 형성한다. 이는 또한 회사와 같은 기업, 고용주, 사업 파트너 등에 의해, 또는 모바일 전화 사업자에 의해 제공될 수도 있다.

도 3 은 본 발명의 일 실시형태에 따른, 디바이스 상으로 앱을 다운로딩하기 전에 앱을 보안화하는 프로세스를 도시하는 흐름도이다. 단계 302 에서, 보안화될 앱의 복사 또는 복제 (clone) 가 디바이스 상에서 이루어진다. 일 실시형태에서, 이는 모바일 디바이스 그 자체 상에서 행해질 수도 있거나, 디바이스 외에서, 예를 들어, 인터넷 상의 구성요소들 상에서, 클라우드에서, 기업의 서버나 사업자의 서버 상에서 행해질 수도 있다. 사용자는 개인, 회사의 종업원, 또는 다른 엔티티일 수도 있다. 당업계에 주지되어 있는 바와 같이, 앱은 다수의 방식들로 획득될 수도 있는데, 가장 전형적으로는 앱 스토어나 앱 마켓으로부터, 또는 앱 개발자나 제공자로부터 직접적으로, 또는 적합한 방식으로 획득될 수 있다. 복사본을 만듦으로써, 원래 앱은 사용자에게 보안 또는 비보안 버전을 이용하는 옵션을 부여하는 것이 보존되며, 또한 앱 제어 프로세스에서 뭔가가 잘못된 경우 앱을 이용하는 사용자의 능력을 보호한다. 일 실시형태에서, 앱은 전화 상으로 아직 다운로드되지 않았음에 유의한다. 일 실시형태에서, 아래에서 설명되는 본 방법들은 별개의 컴퓨팅 디바이스들 상에서 수행된다. 다른 실시형태에서, 프로세스는 프로세스가 모바일 디바이스 상에서 수행될 수도 있으나, 앱은 오직 프로세스가 완료되고 앱이 보안화된 후에 디바이스 상에서 실행된다.

단계 304 에서, 앱이 캡슐화 해제된다. 전부는 아니더라도 대부분의 앱들은 저작자/개발자에 의해 서명된 디지털 서명들을 갖는다. 단계 304 에서, 캡슐화 해제의 일부로서, 디지털 서명이 앱으로부터 제거된다. 이는 당업계에 공지된 기법들을 이용하여 행해질 수도 있다. 앱을 복호화는 것이 이 단계에서 또한 수행될 수도 있다. 이들 및 다른 단계들은 앱 제어 프로그램에 의해 이제 동작될 수도 있는 앱의 코어 객체 코드를 제공한다. 이 동작의 속성 및 세부사항들은 모바일 디바이스의 운영 시스템에 의존할 수도 있다.

(iPhone 용) iOS, (다양한 제조사들로부터의 핸드셋들 상에서 이용되는), Android, Windows Mobile 7, Web O/S, Palm 등과 같은 스마트 폰들용 운영 시스템의 여러 예들이 있다. 단계 306 에서, 코어 객체 코드 앱이 디어셈블되거나 디컴파일되어 실행가능한 객체 코드를 획득할 수도 있다. 예를 들어, 이는 "자연어 코드" (CPU 명령들) 또는 바이트 코드 (Java 또는 .Net 과 같은 가상 머신 명령들) 중 어느 일방일 수 있다. 일 실시형태에서, 이는, 디바이스가 디어셈블리가 가까운 곳에서 iOS 를 구동하는 경우, 어떤 링크들 및 용어들의 위치를 확인하고 대체하는 프로세스보다는 오히려 수정 프로세스일 수도 있다. 그러나, 일반적으로, 앱이 캡슐화 해제된 후에 앱의 객체 코드를 획득하기 위한 디어셈블리 프로세스는 디어셈블러들을 이용하는 것과 같은 당업계에 공지된 기법들을 이용하여 행해질 수도 있다.

단계 308 에서, 앱 객체 코드가 앱 보안 프로그램으로부터의 객체 코드로 증강된다. 예를 들어, 이 객체 코드는 보안 프로그램으로부터의 클래스 파일들로 대체되는 클래스 파일들을 포함할 수도 있다. 객체 코드는 일반적으로 모바일 디바이스 운영 시스템에 대한 인터페이스를 제공한다. 앱 제어 보안 프로그램 객체 코드는 부분적으로는, 상술된 정책/메타 데이터로부터 유도된다. iOS 의 경우에, 객체 코드 교체보다는 '위치확인 및 대체' 프로세스가 일어난다는 점에서 동작이 상이하다. 이것은 iOS 들이 이용하는 인터럽트 접근법을 고려한다. 일반적으로, 앱 보안 프로그램은 어셈블리 언어 코드를 거친다. 위치된 특정 아이템들은 객체 코드 내의 SWI (Software Interrupt) 들이고, 이는 앱 제어 보안 프로그램 계층에 대한 브랜치 (branch) 로 대체되며, 그 다음에, 하기에 설명된 바와 같이, 요청하기, 결과들 향상 등과 같은 어떤 추가적인 액션들을 취할지를 결정할 수도 있다.

단계 310 에서, 객체 코드의 대체 (또는 SWI 들의 대체들) 가 이루어진 후에, 앱 보안 프로그램이 모바일 디바이스 상에서의 실행을 위해 보안 랩핑된 앱을 준비한다. 보안 프로그램에 의해 앱에 대체된 객체 코드는 일반적으로 앱과 모바일 디바이스 운영 시스템 사이의 브릿지 (bridge) 또는 접속을 제공한다. 보안 프로그램 클래스 파일들은 운영 시스템 클래스 파일들 주위를 랩핑하는 것으로 설명될 수도 있다. 앱 보안 프로그램 클래스 파일들은 (통제자로부터의 입력에 의해) 앞서 생성된 정책들에 기초하여 발생된다. 앱은 본질적으로 핸드셋 상에서의 실행을 위해 재연결된다. 모바일 디바이스 운영 시스템 계층에 의해 제공되는 보안뿐만 아니라 앱 보안 프로그램 계층을 이용하기 위해 재연결된다. 즉, 보안 앱이 여전히 운영 시스템의 보안 제공들 (security provisions) 의 대상일 수도 있다. 일 실시형태에서, 앱이 보안화된 것을 반영하기 위해 앱에 대한 아이콘을 변화시키는 것과 같은 소정의 겉모습의 변화들이 또한 앱에 대해 이루어질 수도 있다. 이를 행함으로써, 사용자는 앱 아이콘이 핸드셋 스크린 상에 나타날 경우 앱의 보안 버전이 실행될 것임을 확신할 수 있다. 앱은 이제 본질적으로 보안 프로그램에 의해 리펙토링되거나 (re-factor) 재프로그래밍되었다.

단계 312 에서, 앱은 새로운 키, 예를 들어, 서비스 제공자의 키 또는 보안된 앱을 제공하는 기업의 키로 서명된다. 앱의 리펙토링된, 보안된 버전이 핸드셋 디바이스에 반환된다. 다른 실시형태에서, 앱은 전화 상에서 보안 계층으로 랩핑된다. 단계 314 에서, 일 실시형태에서, 원래, 앱의 비보안 복사본이 핸드셋 디바이스로부터 삭제된다. 이는 앱의 보안 버전이 핸드셋 상으로 다운로드되면 앱의 보안 버전에 의해 행해질 수도 있다. 다른 실시형태들에서, 이것이 행해지지 않고 버전들 양자 모두가 모바일 디바이스 상에 남아 있는다. 이 단계에서, 프로세스가 완료된다.

도 4 는 일 실시형태에 따른 정책 관리기 (202) 에서 수행되는 방법의 흐름도이다. 단계 402 에서, 통제자 또는 다른 보안 정책 개인이 보안 정책들을 정의, 발생, 및 생성하는 것이 가능하게 된다. 이는 수백 또는 수천 개의 모바일 디바이스들 상에 다운로드될 수도 있는 (특히 업무를 위한) 수십 개의 기업 앱들을 이용하는 수백 명의 종업원들에 대한 매우 다양한 모바일 디바이스 보안 정책들을 결정하는 기업에 대한 네트워크 관리자일 수도 있다. 다른 한편에서는, 그녀의 자녀에 의해 새로운 모바일 디바이스 상에 다운로드되는 3 또는 4 개의 앱들에 대해 보안 정책을 설정하는 부모일 수도 있다. 다른 예들은 많은 것들 중에서, GPS 를 이용하여 게임 앱을 방지하거나 진압하는 것, 앱이 대화를 녹음하거나 도청하기 위해 디바이스 상의 마이크를 이용하는 것을 방지하는 것을 포함한다. 어느 경우에나, 통제자는 앱의 카테고리, 앱의 유형과 속성, 저작자, 나이 적합성, 및 다양한 다른 인자들을 고려할 수도 있다. 예를 들어, 악성코드로 분류되거나 디바이스에 보안 위협을 제기할 수도 있는 임의의 다른 앱들을 작성한 동일한 저작자를 갖는다. 동일한 저작자에 의한 다른 앱들이 있는지 여부를 결정할 수도 있다. 이 단계에서 통제자가 어느 규정들을 각각의 앱에 대해 적용할지를 결정한다. 일 실시형태에서, 이것은 통제자에 의해 오프 라인으로 행해진다. 즉, 이는 가정의 컴퓨터 상의 또는 관리자에 의해 이용되는 기업 네트워크 컴퓨터 상의 사용자 인터페이스들을 이용하여 행해질 수도 있는데, 여기서 보안 프로그램 서비스 제공자에 의해 제공되는 보안 템플릿들 (본질적으로 디폴트 템플릿들) 이 이용될 수도 있거나 매우 특정한 규정들이 템플릿들을 이용하여 설정될 수도 있다.

단계 404 에서, 단계 402 에서 입력된 보안 데이터가 실제 정책들을 생성하기 위해 앱 제어 보안 프로그램에 의해 이용된다. 단계 406 에서, 단계 404 에서 생성된 보안 정책들에 관한 통제자로부터의 입력에 기초하여 앱 제어 보안 프로그램 객체 코드가 발생된다. 통제자 또는 서비스 제공자가 또한 필요한 경우 기존의 보안 정책들을 업데이트할 수도 있다. 위에서 설명된 바와 같이, 디어셈블된 앱으로부터 획득된 소정의 원래의 객체 코드를 향상시키는데 객체 코드가 이용될 수도 있다. 향상 코드가 기업 및 최종 사용자를 보호하기 위해 앱에 대한 보안 및 프라이버시 설정들을 조정하도록 삽입된다. 원래 앱의 거동이 변경되며, 이는 통제자가 앱이 어떻게 거동할지를 제어하는 것을 허용한다. 예를 들어, 앱이 깨끗한 (즉, 암호화되지 않은) 민감한 계정 정보를 저장하는 경우, 앱이 생성하는 모든 정보가 암호화된 형태로 저장되고 이는 오직 저장된 영속적인 데이터에 대한 키가 앱에 대해 고유할 것임을 고려하여 오직 그 앱에 의해서만 액세스될 수 있도록 거동이 변화될 수 있다. 많은 경우들에서, 코드가 특정의 이용 시나리오에 대해 최적화되기 때문에, 향상 코드가 앱들 성능을 향상시킬 수 있다.

도 5 는 일 실시형태에 따른 핸드셋 또는 모바일 디바이스 상에서 실행되는 보안 랩핑된 앱의 프로세스를 도시하는 흐름도이다. 단계 502 에서, 디바이스 상에서 앱을 실행하는 경우 또는 앱을 실행하기 바로 전에 앱의 거동이 변경되거나 수정된다. 예를 들어, 거동 수정은 앱 초기화 중의 인증; 예를 들어, 스마트/CAC 카드, 또는 비밀번호 시도를 포함할 수도 있다. 일부 앱들은, 원래 설계된대로, 보안을 위해 비밀번호를 요구하지 않을 수도 있으나, 수정된 앱의 보안 버전은 사용자가 비밀번호를 입력할 것을 요구할 수도 있다. 단계 504 에서, 보안 앱을 활성화시키는 (예를 들어, 디바이스가 터치 스크린인 경우 아이콘을 탭핑하는) 사용자에 의해 모바일 디바이스 상에서 보안 앱을 실행한다. 앱의 실행시, 일 실시형태에서, 제어는 4개의 옵션들 중 하나를 취할 수 있다. 당업계에 알려져 있는 바와 같이, 앱을 실행하는 경우, 디바이스 운영 시스템에 호출들 또는 요청들을 하여 디바이스 운영 시스템의 기능들을 이행한다. 많은 경우들에서, 이들 콜들은 전화 또는 디바이스에 무해하거나 상당한 보안 위협을 제기하지 않을 수도 있다. 이것이 그 경우이면, 단계 506 에서 도시된 바와 같이 콜이 운영 시스템에 전달되도록 허용될 수도 있다. 여기서, 콜이 디바이스 운영 시스템에 대해 이루어지며 앱이 정상 방법으로 실행된다.

앱이 디바이스에 보안 위협을 제기할 수도 있는 요청을 한다고 앱 주위의 보안 계층 또는 랩퍼가 검출하는 경우, 앱 보안 계층 전화 내의 운영 시스템 또는 다른 소프트웨어나 하드웨어 구성요소로 요청이 전달되기 전에 요청을 향상시키거나 수정할 수도 있다. 이것은 단계 508 에서 도시된다. 일 실시형태에서, 통제자는 하나 이상의 정책들을 조사함으로써 어느 콜들이 허락가능한지를 결정한다. 예를 들어, 통제자는 모든 데이터가 암호화된 형태로 저장되어야 한다고 결정할 수도 있다. 다른 예에서, 통제자는 신뢰 앱들 중 오직 선택된 그룹만이 군인들의 GPS 좌표에 대한 데이터를 가져야 한다고 결정할 수도 있다. 일 실시형태에서, 어떤 것이 안전하거나, 잠재적 위협이거나, 실제 위협인지를 결정하기 위한 런타임 로직이 없으며; 이는 기본적으로 위의 단계 404 에서 생성된 정책에서 통제자에 의해 미리 언명된다. 다른 실시형태에서, 일부 런타임 로직이 있을 수도 있다. 예를 들어, 앱은 비용이 많이 드는 SMS 문자 메시지들을 전송하려고 할 수도 있다. 앱 제어 프로그램이 이를 결정하여, 앱이 소정의 개수보다 많은 문자 메시지들을 전송하는 것을 차단할 수도 있는데, 예를 들어, 앱 제어 프로그램은 하나의 메시지의 송신으로 제한할 수도 있다. 향상은 패스워드 요구사항과 같은, 뭔가 새로운 것을 추가하는 것일 수도 있다. 다른 예에서, 콜이 모바일 디바이스 메모리 상에 데이터를 저장하는 것일 경우, 보안 앱이 클라우드에서 또는 인터넷 상에서 (즉, 디바이스 외에서) 저장 영역에 데이터를 실질적으로 백업할 수도 있다. 다른 예에서, 콜에 관련된 데이터는 암호화될 수도 있다.

단계 510 에서, 콜이 실제 위협이고 단계 508 에서보다 좀더 엄격한 방식으로 다뤄져야 한다고 보안 앱이 결정할 수도 있다. 예를 들어, 앱에 대한 정책에 기초하여, 보안 빌딩 (예를 들어, 펜타곤) 내에 있는 동안 디바이스 상의 카메라가 액세스되는 경우, 앱은 즉시 종료되어야 한다고 결정할 수도 있다. 단지 요청을 향상시키는 것만으로는 이 경우에 충분하지 않을 수도 있다. 단계 510 에서, 요청은 디바이스의 운영 시스템 또는 임의의 다른 구성요소로 진행하도록 허용되지 않을 수도 있다. 그러나, 일 실시형태에서, 응답이 앱으로 반환되나, 그 응답은 의도적으로 정확하거나 옳지 않다. 그것은 본질적으로 모호한 응답이다. 예를 들어, 그것은 디바이스의 실제 물리적 좌표가 아닌 GPS 좌표일 수도 있다 (예를 들어, 디바이스는 캘리포니아에 있으나, 앱에 반환되는 GPS 좌표는 네브래스카의 좌표이다). 이는 앱들이 어린이들에 의해 이용되는 경우에 바람직할 수도 있다. 다른 예들은 오직 제한적인 환경 (예를 들어, 보안 오피스 영역) 내에서만 구동해야 하는 앱이 환경 외부에서 (예를 들어, 가정에서) 구동될 것으로 결정되는 경우 나쁘거나 잘 알아들을 수 없는 데이터 결과들을 반환하는 것일 수도 있다. 이 예에서, 앱이 부분적으로 심각하게 손상될 수도 있어 앱이 오직 기밀로 분류되지 않은 데이터 (unclassified data) 에만 액세스할 수 있고, 여기서 기밀로 분류된 데이터 (classified information) 는 무효화된다. 다른 예에서, 사용자가 기밀로 분류된 앱으로부터 기밀로 분류되지 않은 앱으로 민감한 데이터를 붙이거나 복사하려고 시도하는 경우, 앱 제어 프로그램은 붙여지는 데이터의 복사본을 쓰레기로 변화시키거나 기본적으로 그것을 의미 없게 만들 수도 있다. 단계 506, 단계 508, 또는 단계 510 중 어느 일방이 완료된 후에, 보안 랩핑된 앱은 단계 514 에서 모바일 디바이스 상에서 실행을 계속한다.

단계 512 에서, 앱에 의해 이루어진 콜 또는 앱 실행 거동이 일반적으로 모바일 디바이스에게 너무 높은 보안 위협 수준을 제기한다고 앱 주위의 보안 계층이 결정하였다. 이 극단 경우에, 보안 계층은 앱의 실행을 종료하고/하거나 앱을 삭제하도록 결정한다. 예를 들어, 앱이 대역폭과 같은 전화 상의 리소스들을 너무 많이 이용할 수도 있거나 운영 시스템에 너무 많은 고위험 콜들을 행함으로써, 모바일 디바이스를 과다 노출시킨다. 이 경우, 앱은 간단히 전화로부터 삭제될 수도 있거나 앱이 종료될 수도 있다. 사용자는 그 앱을 재실행하거나 그 앱을 재설치할 수 없을 수도 있다. 예를 들어, 앱이 민감한 회사 데이터를 노출시켰기 때문에 종업원은 회사 전화 상에 다시 그 앱을 설치할 수 없을 수도 있다. 또는, 앱이 몰래 전화 상에서 데이터를 수집하거나 악성코드를 설치한다고 결정될 수도 있다.

도 6 은 일 실시형태에 따른 앱 보안 제어 시스템의 시스템 아키텍처 다이어그램이다. 트리거 관리기 구성요소 (602) 는 2 개의 이벤트들을 처리하는데, 하나는 새로운 정책을 생성하는 것 (604) 이고 다른 하나는 정책 파라미터들을 업데이트하는 것 (606) 이다. 이러한 이벤트들은 여러 시스템들에 의해 트리거링될 수 있다. 예를 들어, 콘솔 관리자 또는 통제자가 모든 디바이스들에 새로운 정책을 적용할지도 모른다 (수동 동작). 또는, 네트워크 모니터링 애플리케이션은, 디바이스 (또는 앱) 로부터 비롯되는 의심스러운 트래픽을 검출한 후에, 사용자/디바이스/앱이 네트워크 리소스들에 액세스하는 것을 방지할 새로운 정책을 푸시할 수도 있다 (자동 동작의 일 예). 정책들을 변화시킬/업데이트할 권한을 갖는 여러 시스템들 또는 엔티티들은 트리거 관리자 (602) 를 통해 그렇게 행한다.

런타임에 발생될 수도 있고, 예를 들어, 앱 제어 서비스 제공자 또는 정책이 적용되는 앱/사용자/디바이스에 특정한 다양한 유형의 코드 및 확장들을 포함할 수도 있는 정책 정의 파일 (608) 에 새로운 정책 출력 (604) 이 입력된다. 정책 정의 파일 (608) 은 2 개의 출력들을 갖는 정책 컴파일러 (610) 에 입력된다. 하나의 출력은 래퍼 정의 파일 (612) 이다. 이 파일은 앱 래퍼 구성요소 (614) 에 입력된다. 앱 래퍼 구성요소 (614) 는 예를 들어 앱 스토어로부터 직접적으로 다운로드된 앱 내에 맞춤 이진 코드 (자연어 또는 바이트코드) 를 삽입함으로써 보안 앱을 발생시키는 것을 담당한다. 또는, 앱은 사용자가 그의 디바이스 상으로 다운로드하고, 그 다음에 "앱제어 (AppControl)" 서버에 업로드하는 앱일 수도 있다.

앱 래퍼 구성요소 (614) 는 3개의 입력들, 즉 하나 이상의 앱 스토어들 (616) 로부터의 앱들, 아이덴티티 관리 구성요소 (618) 로부터의 인증서 키 관리 데이터, 및 강화된 (hardened) 구성요소들 (620) 을 가질 수도 있다. 키 관리 데이터는 사용자, 디바이스, 및 앱의 아이덴티티들을 연결하기 위해 사용되며, 정책 제어의 대상이 되는 임의의 동작이 특정 사용자/디바이스/앱과 연결될 수 있도록 보장한다. 이것은 또한 악의적인 앱이 정책들 및 강화된 구성요소들 (620) (예를 들어, "디바이스 보안 프레임워크") 을 우회하는 것을 래핑된 애플리케이션이 단지 방지하기 위해 특정의 디바이스 상에서 실행될 수 있도록 보장한다. 앱 래퍼 (614) 로부터의 출력은 디바이스의 제어기 (626) 를 통해서 모바일 디바이스 (624) 상으로 다운로드되거나 또는 설치되는 래핑된 앱 (622) 이다. 디바이스 제어기 (626) 의 책무들은, 앱 래퍼로부터 앱을 다운로드하는 것; 디바이스들 상에서 구동하는 앱이 적절히 랩핑된 앱 (예를 들어, 사용자2 에 대한 디바이스 상에 설치/구동되지 말아야할 사용자1 에 대해 랩핑된 앱) 임을 보장하는 것; 관리 콘솔이 각각의 디바이스/사용자/애플리케이션에 대한 정책들을 제어하는 것을 허용하도록 설치된 애플리케이션들의 리스트/버전을 보고하는 것; 및 적합한 경우 정책 파라미터들을 다운로드하는 것을 포함한다. 래핑된 앱 (622) 은 정책 파라미터들 (628) 과 커플링된 디바이스 (624) 상에 상주한다.

이제 정책 컴파일러 (610) 로 되돌아 가면, 다른 출력은 런타임 정책 정의 파일 (630) 이다. 이 파일은 런타임 정책 컴파일러 (632) 에 입력되며, 런타임 정책 컴파일러 (632) 는 또한 입력으로서 (관리 콘솔 또는 다른 서브시스템들에 의해 규정된) 정책 파라미터들 (606) 을 수락한다. 컴파일러 (632) 로부터의 출력은 디바이스 런타임 정책 파일 (634) 이다. 이 파일 (634) 은 정책 파라미터들 (628) 로 도시된 바와 같이 디바이스 (624) 상으로 다운로드되고, 랩핑된 앱 (622) 에 적용되는 정책들을 커스터마이즈하는데 이용된다.

아래에서 설명되는 것은 본 발명의 앱 제어 보안 프로그램의 여러 이용 사례들 (use cases) 및 능력들이다. 하나의 이용 사례는 모바일 전화 상에서 업무 생활 및 개인 생활의 분리를 수반한다. 사용자의 개인적 이용을 위한 앱들 및 사용자의 고용주 (또는 고용주의 사업 파트너) 가 제공했을 수도 있는 앱들이 있고, 앱들은 종종 사용자의 개인 전화인 동일한 전화 상에서 동작한다. 사용자의 전화 상에서 보안되어야 할 앱들의 보안을 결정하는 통제자는 (이메일 앱들과 같은) 앱들 사이의 복사/붙이기 동작들을 차단할 수도 있다. 통제자는 앱들 및 연관된 파일들의 선택적 소거들을 수행하는 업무 관련 앱들에 대한 정책들을 설정할 수도 있다. 사용자 로케이션-기반의 정책들은 또한 어디서 소정의 앱들을 실행할 수도 있을지를 제어할 수도 있다. 악성코드로 인한 보호 레벨들의 예들은, 접촉들에 대한 액세스를 거부하는 것, 허락 없는 SMS 의 송신을 거부하는 것, 등등이다.

이용 사례의 다른 예는 앱 제어이다. 본 발명을 이용하여, 통제자에 의해 설정된 정책들에 따른 앱들의 완전 삭제뿐만 아니라, 앱들의 화이트 및 블랙 리스트가 구현될 수도 있다. 앱은 디바이스의 다른 앱들, 소프트웨어, 및 하드웨어를 보호하기 위해 '샌드박스화될 (sandbox)' 수도 있다. 다른 능력들은 앱들 또는 서비스들의 아이덴티티 기반 제어, 및 앱 거동에 대한 매우 미세한 (granular) 제어를 포함할 수도 있다. 트로이 목마 바이러스 식별은 앱 보안 프로그램으로 구현될 수 있는 다른 이용 사례이다. 예를 들어, 각각의 앱 및 콘텐츠는 암호화되어 불량한 앱들이 전화 상의 비밀 정보에 대한 액세스를 얻고 이를 훔치는 것을 방지할 수도 있다. 보안 프로그램은 또한 앱의 변칙적인 시스템 호출 거동을 식별할 수 있어 공개된 의도 외로 활동하는 악의적인 트로이 목마 바이러스 앱들을 식별할 수도 있다.

다른 이용 사례는 IT 보안 관리자들 및 통제자들이 데이터 교정 제어를 갖고, 백업 및 재저장 동작들을 통해 앱 및 디바이스 콘텐츠 이동을 구현할 수 있는 앱 데이터의 백업 및 복구이다. 다른 이용 사례는 네트워크 트래픽 모니터링이다. 모바일 디바이스 상의 앱은 기존의 기업 ID들/IP들/웹 필터링 기반구조의 시계 하에서 앱 통신들에 대한 점검 및 제어를 가능하도록 초래할 수도 있다. 앱 보안 프로그램은 또한 악성코드를 식별하기 위해 Symantec 의 DNS 서비스와 같은 제 3 자 DNS 서비스들과 통합할 수 있다. 모바일 전화 서비스 제공자에서의 통신들을 포함하여 모든 앱 통신들은 암호화될 수도 있다. 다른 이용 사례들은 세션 연속성, 소비자 프라이버시 (예를 들어, GPS 불명료화, 안전한 DNS들 구현), 및 모바일 디바이스로부터의 지불/트랜잭션 메시지들 가로채기 (즉, 모바일 커머스 스트림들의 중간에서의 동작) 를 포함한다.

일 실시형태에서, 예를 들어, 최종 사용자들 또는 개인들 (즉, 고용주 또는 기업과 연관되지 않은 사용자들) 에 의해 앱들이 이용되도록 제 3 자 서비스 제공자에 의해 앱 보안 서비스가 제공된다. 예를 들어, 부모는 자녀가 어디에 있는지를 페이스북과 같은 소셜 네트워크 사이트가 알기를 원하지 않기 때문에, 부모는 자녀의 전화의 GPS 를 알기 어렵게 하기를 원할 수도 있어, 본질적으로 GPS 를 디스에이블시킨다. 다른 실시형태에서, 무선 전화 사업자 (예를 들어, Verizon, AT&T) 에 의해 운영되는 앱 스토어는 가외의 요금 또는 프리미엄에 대해 보안 앱을 제공할 수도 있다. 사업자의 고객은 가외의 금액을 지불함으로써 보안되지 않은 버전 대신에 마켓플레이스 또는 온라인 스토어로부터 보안 앱을 다운로드할 수 있다. 다른 실시형태에서, 기업은 기업의 종업원들, 파트너들 등을 위해 기업 자체의 앱 스토어를 가질 수도 있으며, 여기서 사용자들은 ("견고한 (hard)" 앱들로서 지칭될 수도 있는) 오직 앱들의 보안 버전들만을 다운로드할 수 있다. 이들 앱들은 이메일 또는 법인 데이터를 복사하기 및 붙이기를 차단하는 것, 사용자가 회사를 떠나는 경우 사용자의 전화로부터 앱을 죽이는 것 등과 같은, 기업에서의 통제자 (보안 관리자) 에 의해 정의된 바와 같은 상술된 보안 특징들 중 많은 보안 특징들을 가질 수도 있다. 모바일 전화 사업자의 DNS 는 통상적으로 어떤 사이트에도 액세스할 수 있으나, 오직 안전한 웹 사이트들만이 액세스될 수도 있는 안전한 DNS (예를 들어, Symantec 의 DNS) 에만 액세스할 수 있도록 앱 보안 프로그램이 모바일 디바이스 브라우저를 차단할 수 있다. 다른 실시형태에서, 앱 보안 프로그램 제공자는 모바일 디바이스 제조자와 협력하여 앱 보안 프로그램 또는 기능성을 디바이스의 하드웨어 및 소프트웨어 동작들 내에 포함시킬 수 있다. 아래에서 설명되는, 이 실시형태에서, 사용자는 비보안 앱을 다운로드하여 실행하기 전에 전화나 디바이스 그 자체 상에서 보안화되게 할 수도 있고, 보안 앱을 갖거나 보안 앱을 갖거나 디바이스 상으로 다운로드되기 전에 앱이 보안화되도록 보장하기 위해 제 3 자 서비스에 액세스할 필요가 없다.

위에서 설명된 여러 실시형태들로부터 알수 있는 바와 같이, 모바일 디바이스의 보안은 디바이스 그 자체를 넘어 확장하며, 디바이스 상으로 다운로드되는 앱들에 직접적으로 적용된다. 회사의 기업 IT 시스템의 데이터 누출 또는 악성 소프트웨어 감염과 같은 보안 위험들에 대해 걱정할 필요없이, 회사들 및 다른 엔티티들은 좀더 자유롭게 앱들의 이점을 취할 수 있다. 회사들은 회사의 법인 데이터의 통제를 유지할 수 있다.

본 발명의 다른 양태에서, VPN 은 디바이스 상에서의 개개의 앱들에 의해 생성되어 이용된다. 즉, 앱은 예를 들어, 법인 VPN 게이트웨이와 통신하기 위해 VPN 터널을 갖는다. 이 VPN 터널은 디바이스 상의 단일 앱과 VPN 게이트웨이 사이에서만 오직 사용된다. 일 실시형태에서, 각각의 보안 래핑된 앱은 그의 자신의 IP 스택 또는, 더 일반적으로는, VPN 스택을 갖는다. 디바이스 상의 특정의 래핑된 앱에 대해 VPN 터널을 생성하는 방법들 및 시스템들이 도 7 및 도 8 에 설명된다.

위에서 언급한 바와 같이, 종래, VPN 터널은 VPN 게이트웨이와 이후 통신하는 (클라이언트/ 디바이스 측 상에서) 시스템 UDP 또는 TCP 모듈들의 상부 상에 탑재된다. 설명된 실시형태에서, 디바이스는 스마트폰, 태블릿, 또는 다른 모바일 디바이스일 수도 있다. 다른 실시형태들에서, 디바이스는 PC 또는 랩탑일 수도 있다. 그것은 또한 watch, goggles, 또는 다른 유목 (nomadic) 인터넷-이용가능 컴퓨팅 디바이스와 같은, 착용가능한 디바이스일 수도 있다. 또한 다른 실시형태들에서, 디바이스는 임의의 인터넷-이용가능 기기 또는 시스템일 수도 있다. 예들은 인터넷 액세스를 행하는 차들, 가전 제품들 (냉장고들, 세탁기들, 등), 또는 HVAC, 홈 난방/AC 시스템들, 또는 보안 시스템들을 포함한다. 언급한 바와 같이, 설명된 실시형태는 사용자들이 앱들을 다운로드하는 모바일 디바이스들을 이용한다. 그러나, 본 발명은 또한 다른 실시형태들, 및 상황들에서 사용될 수도 있다.

일반적으로, 스마트폰, 태블릿, PC, 또는 게이트웨이 디바이스에의 VPN 접속을 행할 수 있도록 하는 다른 인터넷-이용가능 디바이스와 같은 디바이스 상의 소프트웨어가 존재한다. 그러나, 설명된 실시형태는 더 보안화된 디바이스 상의 VPN 터널을 생성하여 이용하는 더욱 구분된 (compartmentalized) 방법을 제공한다. 일 실시형태에서, 각각의 래핑된 앱은 그의 자신의 VPN 터널을 갖는다. 다른 실시형태에서, 디바이스 상의 앱들의 연합체에서의 일부 또는 모든 앱들은 하나의 VPN 터널을 공유하는 옵션을 갖는다. IPC 의 보안 유형이 "연합된" 애플리케이션의 경우에 프로세스들 사이에 통신하기 위해 이용될 수도 있다. 아래에서 좀더 자세하게 설명하는 바와 같이, IPSec 패킷들은 각각의 래핑된 앱에 대해 작성될 수도 있다 (각각의 래핑된 앱은 그의 자신의 샌드박스에서, 즉, 디바이스 운영 시스템 외부에서 동작한다). IP 패킷들은 프록시 또는 가상 데이터 링크 계층 (앱 VPN 스택의 일부) 을 통해서 운영 시스템에서의 네이티브 UDP 모듈로 송신된다. 그로부터 IP 패킷들은 VPN 게이트웨이로 송신된다. 위에서 언급한 바와 같이, 디바이스는 또한 PC 일 수도 있다. 예를 들어, 마이크로소프트 Outlook 의 PC 실행 래핑된 버전은 PC 로부터 게이트웨이로의 그의 자신의 VPN 터널을 가질 수도 있다.

VPN 터널을 확립하기 위해, 초기 단계는 전형적인 운영 시스템이 애플리케이션들에 이용가능하게 만드는 패킷 유형들만을 생성하는 것이다. 예를 들어, IP-기반의 VPN 에 접속하기 위해, 애플리케이션은 TCP 또는 UDP 패킷들을 이용할 수 있다. 설명된 실시형태에서, 앱 IP 스택은 UDP 패킷들을 이용한다. 일반적으로, 이러한 패킷들이 단지 특권을 가진 애플리케이션들만이 그들을 전송하거나 또는 수신할 수도 있도록 일반적으로 운영 시스템들에 의해 예약되기 때문에, 그것은 "미가공" IP 패킷들을 (특정의 계층 4 프로토콜 없이) 이용하지 않아야 한다. 본 발명의 여러 실시형태들에 설명된 바와 같은, 퍼-앱 VPN 은, 디바이스 상의 프로세스에 특권을 부여받도록 요구되지 않는다. IPsec 패킷들의 NAT 트래버셜 (NAT traversal) 은 미가공 IP 패킷들 대신, (RFC 3947 및 RFC 3984 에서 설명된 바와 같은) UDP 프로토콜을 이용하여 인에이블된다.

앱이 데이터를 VPN 터널을 통해서 게이트웨이로 전송하기 위해, 앱은 디바이스 상의 VPN 소프트웨어를 이용하여 그후 캡슐화되는 IP 패킷들을 형성가능해야 한다. IP 패킷들은 IP 스택을 이용하여 형성된다. 이 소프트웨어는 일반적으로 디바이스의 운영 시스템에 상주한다. 따라서, 퍼-앱 VPN 이 동작하도록 하기 위해, 일 실시형태에서, 앱은 단일 애플리케이션과 게이트웨이 사이에 오직 사용되는 터널을 형성하는데 사용되는 IP 또는 VPN 스택을 이용한다. 즉, 일 실시형태에서, 그것은 다른 앱들에 의해 사용되지 않는다. 이 스택은 또한 앱 샌드박스에서, 퍼-앱 IP 스택으로서 지칭될 수도 있다. 그 목표는 일반적으로 샌드박스에서 운영 시스템 기능을 복제하는 것이다.

임의의 IP 스택이 외부 네트워크에 액세스하기 위해, 그것은 데이터 링크 인터페이스로서 지칭되는 (또한, 계층 2, 퍼 TCP/IP 및 OSI 네트 (net) 작업 모델들로서 알려져 있는) 소프트웨어를 이용한다. 본 발명의 일 실시형태에서, 그리고 도 7 에 나타낸 바와 같이, 이 데이터 링크 인터페이스는 하부의 운영 시스템의 (네이티브) IP 스택에 대한 프록시 (또는, 가상) 데이터 링크 인터페이스로서 구현된다. 일 실시형태에서, 단지 UDP 패킷들만이 전송되고 수신된다고 가정하면, 이 프록시 데이터 링크 인터페이스는 네이티브 운영 시스템의 IP/VPN 스택 및 퍼-앱 IP/VPN 스택을 통해서 UDP 트래픽을 전송하고 수신하는 것을 지원한다. IPsec 모듈은 가상 데이터-링크 계층으로부터의 유입 트래픽을 해독하고, 퍼-앱 IP 스택으로부터의 유출 트래픽을 암호화한다.

IPsec 는 일반적으로 "[IP] 스택에서의 범프" 로서 구현되며, 운영 시스템의 IP 스택에 통합된다. 일 실시형태에서, IPsec 는 대신, 퍼-앱 IP 스택에 구현된다. 언급한 바와 같이, IPsec 에 대한 프록시 또는 가상 데이터 링크 인터페이스는 퍼-앱 IP 스택에 정의된다. IPsec 는 퍼-앱 IP 스택을 통해 형성된 트래픽 (IP 패킷들) 을 캡슐화하고 그 트래픽을 프록시 데이터 링크 인터페이스를 통해서, 일 실시형태에서는, 네이티브 운영 시스템 공간에서의 UDP 모듈로 라우팅한다.

도 7 은 일 실시형태에 따른 퍼-앱 VPN 을 구현하는데 요구되는 모바일 디바이스에서의 구성요소들 및 모듈들을 나타내는 블록도이다. 나타낸 것은 모바일 디바이스 (702) 상에 2개의 관련된 메모리 공간들, 즉, 래핑된 앱의 구성요소들, 시스템 구성요소들, 및 IP/VPN 스택을 포함하는 샌드박스 영역 (704), 및 디바이스 운영 시스템 공간 (706) 이다. 또한, 모바일 디바이스 (702) 외부에 나타낸 것은, VPN 게이트웨이 구성요소 (708) 이다. 위에서 언급한 바와 같이, 본 발명의 실시형태들은 샌드박스 영역 (704) 에서의 보안 래핑된 앱에 대해 IP 스택을 생성하고 구현하는 것을 수반한다.

IP 스택 (710) 은 네트워크 계층 및 전송 계층과 같은, TCP/IP 스택의 종래의 계층들의 일부를 갖는다. IP 스택 (710) 위에는 HTTP 프록시 또는 소켓들 계층 (712) 이 있다. 앱 IP 스택 (710) 에서의 2개의 구성요소들은 IPsec (714) 및 프록시 데이터 링크 계층 (716) 이다. 가상 데이터 링크 계층 (716) 은 가상 IPsec (714) 와 네이티브 UDP 모듈 (722) 사이의 IP 인터페이스로서 기능한다. 가상 IPsec (714), 가상 데이터 링크 계층 (716), 및 IP 스택 (710) 의 조합은 또한 "퍼-앱 VPN" 스택으로서 지칭될 수도 있다. 본 발명의 퍼-앱 VPN 스택의 1차 목표는 네이티브 운영 시스템 (706) 에서 일어나는 동작들 및 기능을 복제하는 것이다. 단일 앱에 대한 구성요소들 및 임의의 시스템 구성요소들은 샌드박스 영역 (704) 에 상주한다. 그러나, 예시를 위해, 오직 하나의 앱 구성요소 (718) 및 하나의 시스템 구성요소 (720) 가 도시된다.

네이티브 운영 시스템 (706) 은 시스템-레벨 또는 네이티브 IP 스택 (미도시) 을 포함한, 여러 구성요소들을 포함한다. 본 발명에서 요구되는 운영 시스템 공간 (706) 에서의 모듈들 중 하나는 UDP 모듈 (722) 이다. 언급한 바와 같이, IPsec 패킷들은 모바일 디바이스 (702) 로부터 VPN 게이트웨이 (708) 로 UDP 를 이용하여 송신된다. 다른 실시형태들에서, TCP 가 사용될 수도 있다. 보안 래핑된 앱에 대한 데이터 패킷들은 또한 UDP 모듈 (722) 에서의 VPN 게이트웨이 디바이스 (708) 로부터 수신되며 프록시 데이터 링크 계층 (716) 으로 릴레이된다.

도 8 은 본 발명의 일 실시형태에 따른 앱 VPN 을 구현하는 프로세스의 흐름도이다. 샌드박스 (704) 에서의 보안-래핑된 앱은 정상 방법으로 실행하며, 그 프로세스에서, 일부가 VPN 을 통한 통신을 필요로 하는 디바이스 운영 시스템으로 콜들을 행한다. 이것은 단계 802 에서 일어난다. 일 실시형태에서, 그들 콜들은 단계 804 에서 앱 IP 스택 (710) 으로 다시 전송된다. 일 실시형태에서, HTTP 프록시 계층 박스 (712) 를 통해서 애플리케이션 (및 앱 및 시스템 구성요소들, 박스들 (718 및 720) 에 노출된 인터페이스들은 운영 시스템 (706) 에 의해 제공되는 대응하는 인터페이스들을 미러링한다.

단계 806 에서, 앱 IP 스택은 IPsec 패킷들을 종래의 방법으로 형성한다. 이것은 샌드박스에서의 앱 또는 시스템 구성요소가 운영 시스템으로 콜을 행하는 것의 결과로서, 시스템/네이티브 IP 스택에 의해 일반적으로 이루어질 것이다. IP 패킷들은 그후 앱 VPN 스택에서의 IPsec 를 이용하여 캡슐화된다. 단계 808 에서, 프록시 데이터 링크 계층, 또한 앱 VPN 스택의 일부는, 패킷들을 시스템/네이티브 IP 스택에서의 UDP 모듈로 송신한다. 다른 실시형태들에서, SSL VPN 이 구현되는 경우, 패킷들이 TCP 모듈로 송신될 수도 있다. 언급한 바와 같이, 프록시 (가상) 데이터 링크 계층은 앱 IP 스택과 시스템 네이티브 스택, 구체적으로 말하면, UDP 모듈 사이의 인터페이스로서 기능한다. IPsec 모듈은 가상 IPsec 인터페이스로서 설명될 수 있다. 이것은 IP 패킷들을 앱 VPN 스택을 통해서 취하고 네이티브 UDP 모듈을 통해서 VPN 게이트웨이로 내보내기 위해 가상 데이터 링크 인터페이스 기능들과 함께 인터페이스한다.

그것은 이것이 네트워크 어드레스 변환 (NAT) 을 이용하는 것에 의해 가능하다는 점에 유의될 수도 있다. 당업계에 알려져 있는 바와 같이, 이 기법은 엔터티로 하여금 공공 IP 어드레스들에 맵핑되는 "사설" IP 어드레스들을 할당가능하게 한다. 사설 IP 어드레스들은 공중에게 전혀 보여지지 않는다. 전통적인 NAT 접근법들은 IP 패킷을 재기록하고 그후 그것을 상이한, 사설 어드레스로 전송할 수 있다.

위에서 언급한 바와 같이, 그의 자신의 VPN 터널로 특정의 애플리케이션을 구성함으로써, 사람들은 그것이 필요로 하는 특정의 리소스들에 앱이 단지 액세스할 수 있도록 네트워크 리소스들에의 액세스를 제한하도록 앱 보안 래핑 서버를 구성할 수 있다. HTTP 프록시 (712) 가 운영 시스템 (706) 에 의해 제공되는 TCP 포트 상에서 청취하고 있으면, 다른 애플리케이션들은 잠재적으로 그 TCP 포트에 접속할 수 있다. 일 실시형태에서, HTTP 프록시 계층 (712) 은 디바이스 상의 다른 애플리케이션들이 HTTP 프록시에 액세스하는 것을 방지하는 기법들을 구현한다. 일 실시형태에서, 시스템은 파일 디스크립터들 중 임의의 파일 디스크립터가 HTTP 프록시 계층 (712) 에의 접속을 이루었는지를 결정하기 위해, 예를 들어, 현재의 프로세스에서의 모든 파일 디스크립터들을 전체적으로 탐색하여 커널에 조회함으로써, HTTP 프록시 계층 (712) 에의 접속이 현재의 프로세스 (즉, 래핑된, 호스트 앱) 로부터 유래하였는지를 결정한다. 앱들의 그룹 또는 연합체의 진실성 (authenticity) 이 검증되고 그들 앱들 사이에 통신을 확립하면, 일 실시형태에서, 연합된 앱들은 단일 VPN 터널을 공유할 수 있다. 이것이 디바이스에 요구되는 병행 VPN 터널들의 개수보다 더 적더라도, 그것은 단지 그것이 필요로 하는 특정의 리소스들에 앱이 액세스할 수 있도록 네트워크 리소스들에의 액세스를 제한하도록 서버를 구성하는 것과 같은, 위에서 설명된 이점들 중 일부를 손상시킬 수도 있다.

이와 같이, 일 실시형태에서, 단지 특정의 보안 래핑된 앱만이 그 앱의 VPN 스택에 의해 생성된 VPN 터널에 접속할 수 있다. 이것은 다른 앱에 대한 HTTP 프록시가 또한 악의적인 앱에 대한 프록시라는 지정하는 것을 디바이스 상의 다른 악의적인 앱 또는 임의의 다른 악성 소프트웨어가 방지함으로써, 악의적인 앱이 래핑된 앱의 VPN 을 이용하는 것을 방지한다. 다른 실시형태에서, 보안 래핑된 앱에 의해 생성된 VPN 터널은 VPN 을 생성한 앱과 동일한 연합체 또는 그룹에서의 다른 래핑된 앱들에 의해 공유될 수도 있다.

다른 실시형태에서, 디바이스 사용자는 (예컨대, 사용자가 해외에서 제한적인 인터넷 액세스를 가진 국가에서 작업하고 있으면) 조금이라도 임의 종류의 액세스 또는 연결을 획득하기 위해서 VPN 을 필요로 할 수도 있으며, 사용자는 디바이스-레벨 VPN 에 액세스하여 초기 풀-인터넷 액세스를 획득하고, 그후 퍼-앱 VPN 을 이용하여 법인 액세스 (corporate access) 를 획득할 수 있다.

단일 애플리케이션을 VPN 터널에 연결하는 (tying) 다른 이점은 VPN 게이트웨이에서, 애플리케이션 당 상이한 "구성 프로파일" (즉, VPN 그룹) 을 이용함으로써, 애플리케이션이 액세스할 네트워크 리소스들을, 제한하는 능력이다.

이제, 본 발명의 다른 양태에서, 네트워크 보안이 게이트웨이 소유자의 관점에서 향상된다 (게이트웨이는 디바이스 상의 앱과 게이트웨이 (708) 사이의 VPN 을 도시하는 도 7 에서 먼저 설명되었다). 즉, 법인 또는 제도적 네트워크와 같은, 게이트웨이 이면의 구성요소들의 보안이 더 잘 보호된다. 아래에서 설명하는 바와 같이, 일 실시형태에서, 감옥 탈출한 또는 파헤쳐진 디바이스를 보고하는 능력 덕분에 보안이 향상된다. 보고 (reporting) 는 적합한 네트워크 구성요소들을 결국 보고할 수 있는 게이트웨이로의 사설 터널을 통해서 이루어질 수도 있다. 본 발명의 또 다른 양태에서, 게이트웨이는 모바일 디바이스들 상의 앱들과의, VPN 또는 IPSEC 접속들과 같은, 다수 (예컨대, 수만 또는 수 십만) 의 사설 터널들을 관리하기 위해, 스케일링할 수 있다.

설명하는 바와 같이, 캘리포니아, 샌프란시코, Mocana 사와 같은, 앱 보안 제공자는, 디바이스 상에서의 선택된 및 디폴트 정책들에 따라서 앱을 래핑하는데 요구되는 소프트웨어를 공급한다. 앱 보안 제공자는 또한 디바이스 상의 래핑된 앱으로 하여금, 사용자의 고용주와 같은, 회사의 제어 하에 있을 수도 있는 게이트웨이와 앱 사이에, VPN 또는 IPSEC 접속과 같은, 사설 터널을 생성가능하게 하는 소프트웨어를 제공할 수 있다. 앱 보안 제공자는 또한 게이트웨이를 포함한 소프트웨어 및 하드웨어를 그 회사에 제공할 수도 있다. 하나의 전형적인 시나리오에서, 디바이스의 사용자는 회사의 종업원이다. 디바이스는 많은 경우들에 사용자에 의해 소유된다 (그것은 또한 회사에 의해 소유되고 업무 용도로 사용자에게 제공될 수도 있다). 디바이스는 회사에 의해 종업원/사용자에게 제공되거나 또는 어떤 점에서는 고용주를 위한 종업원의 업무에 관련되는 하나 이상의 앱들, 예를 들어, e-메일 클라이언트를 실행한다. 앱들은 고용주에 의해 (예를 들어, IT 부서에 의해) 앱 보안 제공자로부터 구입된 보안 래핑 소프트웨어를 이용하여 래핑된다. 일단 래핑되면 그들은 앱들이 종업원 (본원에서 "사용자" 로서 지칭됨) 에 의해 사용되기 전에 사용자에게 제공된다.

일 실시형태에서, 각각의 사용자는 다수의 업무-관련된, 보안-래핑된 앱들을 가질 수도 있는 하나의 (또는, 더 이상의) 디바이스를 갖는다. 고용주는 하나 이상의 래핑된, 업무-관련된 앱들을 가지는 그들 자신의 디바이스를 각각 이용하는 수백 또는 수천의 사용자들을 가질 수도 있다. 그들 앱들의 각각은, 실행중일 때, 고용주의 게이트웨이 (위에서 게이트웨이 (708)) 와의 그의 자신의 전용 사설 터널을 가질 것이며, 이것은 종래의 설정에서는, 고용주가 잠재적으로 아주 많은 고유 IP 어드레스들을 관리할 필요가 있을 것임을 의미한다. 이들 고유 IP 어드레스들은 아마도 10 개의 네트 어드레스들일 것이다. IP 어드레싱 이슈들 및 트래픽을 게이트웨이로부터 앱들로 되라우팅하는 것은 거의 확실히, 고용주에게는, 극복할 수 없는 또는, 적어도, 상당한 기술적인 그리고 논리적 (logistical) 시도일 것이다.

래핑된 앱들 및 게이트웨이와의 그들의 사설 접속들의 개수를 스케일링가능함과 동시에, 기업과 같은, 엔터티가 할당하여 관리해야 할 고유 IP 어드레스들의 개수를 감소시키는 수단 및 방법들을 제공하는 것이 바람직할 것이다. 즉, 퍼-앱 VPN 실시형태의 이점들을 유지하지만, 이들 실시형태들을 구현하는 관리상 및 기술적인 단점들 및 장애들을 감소시킨다.

게이트웨이에 접속할 수 있는 사용자 디바이스들의 개수의 증가에 따라, 또한 기업 네트워크의 보안을 유지하기 위해 게이트웨이에게 감옥 탈출한 및 파헤쳐진 (rooted) 디바이스들을 통지할 수 있는 것이 바람직할 것이다.

언급한 바와 같이, 게이트웨이를 이용하는 기업들에 중요한 이슈들은 감옥 탈출한 또는 파헤쳐진 디바이스들로부터의 (게이트웨이 이면의) 기업 네트워크의 보안의 잠재적인 침범이다. 언급한 바와 같이, 모바일 디바이스들은 대부분의 경우, 종업원들에 속할 것이며 (점점 더 일반적인 "당신 자신의 디바이스를 가지고 온다 (bring your own device)" BYOD 환경을 반영한다), 고용주는 사용자들이 감옥 탈출한 또는 파헤쳐진 디바이스들을 이용하면 방지되거나 또는 경보받기를 원할 것이다. 또는, 그것은 적어도 이러한 디바이스가 게이트웨이에 접속하는데 사용되고 있을 때를 알기를 원할 것이다. 무수한 사용자들, 따라서, 그의 게이트웨이에 접속하는 무수한 상이한 디바이스들을 가진 많은 고용주에게는, 실제로 감옥 탈출한 또는 파헤쳐진 디바이스들의 적지 않은 개수가 존재할 가능성이 있을 것이다. 고용주는 이러한 디바이스들이 게이트웨이에 접속할 때에 알기를 원할 것이다.

이와 같이, 래핑된 앱으로 하여금, 그것이 감옥 탈출한 디바이스 상에서 실행하고 있는지 여부를 앱의 사설 터널을 통해서, 게이트웨이로, 보고할 수 있도록 하는 것이 바람직할 것이다. 디바이스가 탈옥되었는지 여부의 실제 검출을, 앱을 래핑하는 디바이스 상에서 실행하는 앱 보안 소프트웨어가 수행하는 점을 여기서 주의하는 것이 도움이 된다. 이 탈옥 검출은 본 발명에 관련된 기능, 즉, 디바이스가 탈옥되어 있는지 여부를 게이트웨이에 (즉, 고용주 또는 기업에) 보고하는 기능과는 별개의 동작이다.

모바일 디바이스 상의 앱과 게이트웨이 사이에 접속을 확립하는 2개의 페이즈들 (phases) 을 설명하기 전에, 게이트웨이의 관점에서, 신뢰 지점 (trust point) 으로서 특징화될 수도 있는 모바일 디바이스 상의 래핑된 앱으로 동작하는 게이트웨이의 능력들의 간략한 개관을 제공하는 것이 도움이 된다. 아래에서 설명하는 바와 같이, 본 발명의 기능 및 능력들은 앱 보안 소프트웨어를 이용하는, 게이트웨이 및 래핑된 앱 양쪽을 소유하는 기업으로부터 유래한다. 언급한 바와 같이, 보안 제공자는 그 게이트웨이에 대한 앱 및 소프트웨어를 래핑하는 소프트웨어를 제공한다 (그리고, 또한 게이트웨이 자체를 제공할 수도 있다.

게이트웨이의 능력들의 중심은 다수의 사설 접속들을 종료시키는 능력이다. 이들 접속들은 VPN/SSL, IKE/IPSEC 또는 다른 프로토콜들 또는 표준들을 이용할 수도 있다. 설명된 실시형태에서 그리고 예시적인 목적들을 위해, 게이트웨이는 래핑된 앱들로부터 유래하는 IKE/IPSEC 세션들을 종료시킨다. 게이트웨이의 다른 중심 능력은 래핑된 앱과 게이트웨이 사이에 더 높은 레벨의 인증 또는 보안을 강제하는 능력이다. 언급한 바와 같이, 이것의 하나의 특징은 감옥 탈출한 또는 파헤쳐진 디바이스를 보고하는 래핑된 앱의 능력이다. 게이트웨이의 다른 능력은 래핑된 앱들로부터 나오는 그리고 들어가는 데이터 패킷들에 관련된 상세한 트래픽 데이터를 획득하는 것이다. 게이트웨이는 다른 능력들을 가지며, 그 중 일부는 앱-특정의 데이터베이스를 일부가 이용한다.

모바일 디바이스 상의 앱들과 게이트웨이 사이에 엿듣거나 부당하게 변조하는 것을 방지하도록 보안 터널 또는 접속을 확립하는 프로세스는 2개의 페이즈들로 설명될 수 있다. 일 실시형태에서, 페이즈 1 은 2-인자 인증을 가진 XAUTH 프로토콜의 확장판으로서 특징화될 수도 있다. 각각의 래핑된 앱 (또한, 아래에서 "클라이언트" 로서 지칭됨) 은 게이트웨이 (또한, 아래에서 "헤드-엔드" 로서 지칭됨) 와의 IKE/페이즈 1 을 거친다. 앱이 래핑될 때, 그것은 게이트웨이에 대한 공공의, 고유 IP 어드레스 및/또는 전체 도메인 이름 (fully qualified domain name) 으로 제공되거나 또는 사전-구성된다. 즉, 앱은 "홈을 호출하는" 능력이 주어진다. 앱은 게이트웨이에 그의 아이덴티티를 증명하도록 먼저 요구한다. 이 프로세스는 앱이 사용자에 의해 디바이스 상에서 호출될 때 시작하며, 게이트웨이와 보안 사설 접속을 행하려고 시도한다. 사용자는 또한 사용자의 애플리케이션 및 디바이스에 고유한 재접속 토큰을 제공할 수 있다.

당업계에 알려져 있는 바와 같이, 이것은 2-인자 인증 프로세스 (two-factor authentication process) 중 제 1 인자이다. 클라이언트는 보안 터널을 이용하여 디바이스 인증서를 게이트웨이로 게이트웨이의 공공 IP 어드레스를 이용하여 송신한다. 게이트웨이는 종래의 수단을 이용하여 인증서를 검사하고 검증한다. 등록 인증서가 유효하고 헤드 엔드가 사용자의 아이덴티티에 관하여 만족되면, 제 2 인자에 대한 프로세스가 시작된다.

XAUTH 확장판의 2-인자 인증 프로세스 중 제 2 인자에 대해서, 클라이언트는 클라이언트와 헤드 엔드 (즉, VPN 게이트웨이) 사이에 송신되는 데이터에 대한 보안 연관성들 (security associations) 을 협상한다. 클라이언트는 그것이 그의 사용자 이름, 패스워드, MAC 어드레스, 및 프로토콜을 증명하는 XAUTH 시도로 진행한다. 앱은 또한 클라이언트가 실행중인 모바일 디바이스가 탈옥되어 있는지 여부 및 다른 정보, 예컨대 클라이언트 상에서 실행하는 앱의 이름을 보고한다. 이것은 보안 IKE 터널을 통해서 모두 이루어진다. 클라이언트는 PERP 로서 지칭되는, 정책 시행 및 보고 프로토콜로서 특징화될 수 있는 XAUTH 프로토콜에 대한 확장판을 이용하여 이것을 행한다. 게이트웨이는 데이터베이스를 체킹함으로써 이 데이터를 로컬로 검증할 수 있거나 또는 그것은 AAA 서버 또는 활성 디렉토리와 같은, 외부 구성요소를 이용할 수 있다.

일단 게이트웨이가 이 데이터를 검증하고 그 PERP 응답이 허용가능하면, XAUTH 페이즈의 제 2 인자가 완료된다. 이 PERP-확장된 XAUTH 페이즈 1 단계 덕분에, 래핑된 앱은 고용주의 네트워크에서의 구성요소들 (예컨대, 보안 관리자의 콘솔) 에 결국, 통지할 수 있는 게이트웨이로 감옥 탈출한 디바이스들을 보고할 수 있다. 다시 말해서, 게이트웨이는 PERP 를 이용하여 앱, 사용자, 디바이스, IP 어드레스, 및 MAC 어드레스에 관한 특정의 정보를 학습한다. 따라서, 게이트웨이에 의해 IKE/IPSEC 세션들 중 임의의 세션을 통해서 수신된 임의의 데이터에 대해, PERP 덕분에, 고용주는 어느 사용자가 데이터를 전송하였는지, 어느 래핑된 앱으로부터 그 데이터가 전송되었는지, 및 어느 디바이스로부터 그 데이터가 전송되었는지를 확실하게 학습할 수 있다. 여기서, PERP 가 임의의 보안 프로토콜을 통해서 2개의 지점들 사이에 사용될 수 있다, 즉, 그것이 설명된 실시형태에서와 같이 IKE 에 구속되지 않는다는 점에 주의해야 한다. PERP 는 VPN/SSL 을 포함한, 임의의 적합한 보안 프로토콜을 통해서 전송될 수 있다. 기업은 휴리스틱스, 패킷 분석, 또는 추정들 또는 특정값 미만의 결과들 (즉, 사람, 어떤 것, 및 장소에 관한 지능적 추측들) 을 일반적으로 초래하는 다른 수단에 의존할 필요없이, 이 아주 미세한 (highly granular) 데이터를 획득할 수 있다. 일 실시형태에서, 이것은 데이터가 시원하는 신뢰되는 클라이언트와의 관계를 헤드-엔드 (게이트웨이) 가 갖기 때문에 가능하다. PERP 및 기존 래핑된 앱에 대한 끊김없는 사용자 인증에 사용될 수 있는 방법에 관한 추가적인 세부 사항들이 아래에 제공된다.

일단 보안 연관성들이 협상되면, 클라이언트는 게이트웨이와의 구성을 개시한다. 일 실시형태에서, 이것은 IKE 모드-CONFIG 를 이용하여 이루어진다. 이 단계에서, 앱은 게이트웨이에 고유한 (내부) IP 어드레스를 요청한다. 앱은 또한 서브넷 및 DNS 이름을 요청할 수도 있다.

일 실시형태에서 XAUTH/PERP 에 대해, 게이트웨이는 클라이언트/앱에게 디바이스 상에 래핑된 앱들의 연합체가 존재하는지 여부를 쿼리할 수도 있다. 즉, 그 앱이 그 기업으로부터의, 앱들의 연합체로서 지칭되는, 앱들의 그룹에서의 하나인가? 클라이언트가 그렇다고 응답하면, 게이트웨이는 연합체 쿠키를 클라이언트로 송신함으로써 응답한다. 다른 실시형태에서, 게이트웨이는 래핑된 앱에 연합체에 관해 쿼리하지 않는다. 대신, 그것은 간단히 앱으로 연합체 쿠키를 전송한다. 앱이 연합체의 부분이 아니면, 즉, 그 앱이 단지 (즉, 앱들의 연합체인) 디바이스 상의 기업으로부터의 앱이면, 쿠키는 그 후에 사용될 수도 또는 사용되지 않을 수도 있다. 아래 단계들에서 설명되는 바와 같이, 연합체에서의 다른 앱들은 이 연합체 쿠키를 사용할 것이다.

일단 랩핑된 앱이 게이트웨이에 의해 자신을 구성하였으면, IKE 페이즈 1 이 완료되며 앱과 게이트웨이 사이의 보안 터널이 확립되었다. 이 정책 시행은 페이즈 1 동안 PERP 를 이용하여, 그리고 이후에는 IPSec 세션 내에서 트래픽을 모니터링함으로써, 구현될 가능성이 클 것이다. 게이트웨이는 이제 사용자들의 디바이스들 상에서 고용주/기업을 위해 정책 (예컨대, 지오-펜싱 (geo-fencing), 복사/붙이기, 등) 을 시행할 수 있다. 예를 들어, 게이트웨이는 특정의 래핑된 앱을 이용하고 있는 특정의 종업원에 대한 정책을 시행하고, 종업원이 하루중 어떤 시간대 동안 및 단지 어떤 지리적 영역에서만 (예컨대, 종업원의 부동산 (premises) 내에 있는 동안) 앱을 단지 사용하도록 강요할 수 있다. 게이트웨이는 사용자, 앱, 및 디바이스에 관련된 정확하고 구체적인 데이터를 갖고 있기 때문에 이를 행할 수 있으며, 따라서 하나 이상의 정책들을 적용할 수 있다. 아래에서 설명하는 바와 같이, 게이트웨이는 앱 및 정책 시행에 사용되는 다른 데이터를 포함하는 데이터베이스를 가질 수도 있다.

게이트웨이는 특정의 모드, 예를 들어, IKE 메인 모드 또는 적극적인 모드, XAUTH 인에이블 또는 비인에이블 등으로 사전 구성된다. 위에서 언급한 바와 같이, 래핑된 앱이 시동되며, 게이트웨이의 공공 및 고유 IP 어드레스 및 도메인 이름으로 사전 구성된다고 가정하면, 그것은 게이트웨이와 접속할 수 있다. 메인 모드 세션에서, 6-패킷 교환이 존재하며, 그의 끝에서 게이트웨이 및 래핑된 앱이 본질적으로 서로 신뢰한다. 이것은 1-인자 인증의 끝이며 그후 아래에서 설명되는 바와 같이 XAUTH/PERP 교환이 일어난다.

페이즈 2 동안, 새로운 보안 연관성들이 페이즈 1 터널을 통해서 협상되며 2개의 새로운 단방향의 페이즈 2 터널들, 즉 송신용 터널 및 수신용 터널이 앱과 게이트웨이 사이에 생성된다. IPSEC 의 분야에서 주지되어 있는 바와 같이, 게이트웨이 및 래핑된 앱은 새로운 터널을 통해서 데이터를 송신하는 각각에 의해 사용되는 대칭 키들을 생성한다. 여기서, 페이즈 2 는 앱과 게이트웨이 사이의 실제 앱 데이터의 송신을 위해 사용된다. 페이즈 2 의 끝까지, 설명된 실시형태는, 1) 본원에서 PERP 로서 지칭되는 정책 시행을 위한 프로토콜, 및 2) 아래에서 설명되는 이유로 연합체 쿠키를 앱으로 전송하는 것을 이용한다.

위에서 언급한 바와 같이, IPSEC 터널 모드에서, 게이트웨이는 고유 및 사설 IP 어드레스를 디바이스 상의 래핑된 앱에 부여한다. 종종, 디바이스는 하나 보다 많은 래핑된 앱을 가질 것이며, 각각의 앱이 구성 모드를 거치기 때문에, 각각은 고유 및 사설 IP 어드레스를 획득할 것이다. 본질적으로, 각각의 래핑된 앱은 게이트웨이에 등록한다 (하나의 앱은 다음 메시지를 전송함으로써 시작된다: "나는 디바이스 A 상의 앱 1 입니다. 나는 사설 IP 어드레스를 요청합니다; 디바이스 상의 다른 앱이 메시지를 전송한다: 나는 디바이스 A 상의 앱 2 입니다, 나는 사설 IP 어드레스... 를 요청합니다" 등). 3개, 4개 또는 그 이상의 이러한 래핑된 앱들이 존재할 수도 있으며, 각각의 앱은 설령 그들이 동일한 연합체에 있더라도 각각이 독립적으로 동작하는 앱이기 때문에 게이트웨이와 페이즈 1 을 거쳐야 한다. 그들이 동일한 연합체에 있을 수도 있지만, 효과적으로, 그들은 그들이 동일한 연합체에 있다는 것 이외에는, 서로에 대해 알지 못한다.

언급한 바와 같이, 기업 또는 임의의 엔터티가 대량의 외부, 고유 IP 어드레스들 (예컨대, "10-네트" 어드레스들) 을 관리하는 것은 도전적인 기술적 및 논리적 작업일 것이다. 일반적으로는, 각각의 디바이스 상의 각각의 래핑된 앱에 대해 고유 IP 어드레스를 발행하는 것이 실현불가능할 것이다. 동시에, 도 7 및 도 8 에 대해 설명된 바와 같이 각각의 래핑된 앱과 게이트웨이 사이에 사설 VPN 또는 터널을 구현하는 것이 보안 관점에서 바람직할 것이다. 게이트웨이 하드웨어 및 소프트웨어는 다수의 IKE/IPSEC 세션들을 종료하도록 스케일링할 수 있다. 다른 실시형태에서, 그것은 대량의 SSL/VPN 접속들을 종료할 수 있다. 따라서, IP 어드레스들을 통합할 필요가 있다.

일 실시형태에서, 이 통합은 하나의 디바이스 상의 하나의 연합체에서의 앱들에 대한 IP 어드레스들을 번들화하거나 통합하는 것을 수반한다. 예를 들어, 사용자의 모바일 디바이스 상에 하나의 연합체에 8개의 래핑된 앱들이 존재하면, 각각의 클라이언트 (앱) 가 게이트웨이로의 사설 VPN 을 갖도록 VPN 게이트웨이가 그 디바이스에 대해 8개의 고유 IP 어드레스들을 할당해야 하는 대신, 게이트웨이는 디바이스 상의 하나의 연합체에서의 모든 래핑된 앱들에 대해 하나의 고유 IP 어드레스를 할당할 수 있다. 일 실시형태에서, 래핑된 앱들은 하나의 연합체 내에 있다. 기업의 종업원은 종업원이 업무용으로 이용하는 모든 기업 앱들을 아마 보유할 것이며, 그 앱들 모두는 하나의 연합체에, 래핑될 것이다.

이 IP 어드레스의 통합의 결과로서, 설명된 실시형태에서, 게이트웨이는 디바이스 상의 어느 연합된 래핑된 앱이 반환 트래픽을 수신해야 하는지를 결정하는 방법들을 가지며, 여기서, 그 트래픽이 디바이스에 의해 수신될 때 그 트래픽은 래핑된 연합된 앱들 중 임의의 하나에 대한 것일 수 있다. 즉, 그 앱은 그 연합체에서의 임의의 앱에 대한 모든 인입하는 트래픽을 수신하여 트래픽을 적합한 연합된 앱으로 한번 연합체에서 라우팅하도록 지정되어야 한다. 단일 IP 어드레스는 연합체에서의 각각의 모바일 애플리케이션이 게이트웨이와의 그의 자신의 페이즈 2 보안 연관성들의 세트를 갖기 때문에 모바일 디바이스 및 앱 연합체를 결정하기에는 충분하지만 특정의 모바일 앱을 결정하기에는 충분하지 않다; 그것은 게이트웨이로 하여금 연합체에서의 특정의 모바일 앱에 대한 올바른 유출 보안 연관성을 선택가능하게 하는, IP 어드레스와 연계하여 사용되는, 포트 범위이다. IP 어드레스는 앱들의 특정의 연합체에 대한 것이며 따라서 트래픽이 적어도 올바른 연합체에 도달할 것이다. 래핑된 앱들과 게이트웨이 사이의 사설 접속 및 트래픽이 여전히 올바른 페이즈 2 보안 연관성들을 이용한다는 점에 유의하는 것이 중요하다; 이것은 포트 범위와 함께 IP 어드레스에 의해 달성된다. 따라서, 데이터 트래픽은 위에서 설명한 바와 같이 특정의 래핑된 앱과 게이트웨이 사이에 확립된 대칭적인 키들을 이용하여 여전히 암호화된다.

IP 어드레스들을 통합하고 이에 의해 게이트웨이에서 다수의 VPN 터널들의 종료를 가능하게 하는 방법들을 예시하려는 목적들을 위해, 앱 연합체가 고용주의 제어 하에서 게이트웨이에 구속되도록, 모두가 사용자의 고용주 (또는, 다른 관련된 엔터티/기업) 과 관련된 n 개의 래핑된 앱들의 연합체가 디바이스 상에 존재하고 있다고 가정된다. 단지 디바이스 상에 하나의 래핑된, 업무-관련된 앱만이 존재할 수도 있으며, 그 경우 여기서 설명되는 방법들은 불필요할 수도 있다. 이 경우, 필요되는 전부는 어쨌든 앱이 가질 고유 IP 어드레스이다. 그러나, 다른 실시형태에서, 단일 앱은 하나의 앱 연합체로서 취급될 수도 있으며, 그렇게 함에 있어 상당한 단점이 전혀 없다고 가정하면 일관성을 위해 아래에서 설명되는 프로세스들을 여전히 거칠 수도 있다. 사용자가 연합체에서의 앱을 호출할 때, 앱은 퍼-앱 VPN 실시형태들에 대해 위에서 설명된 방법들을 이용하여 게이트웨이와 접속한다. 앱은 게이트웨이에 대해 자신을 식별하고 페이즈 1 을 거친다. 게이트웨이는 고유 IP 어드레스를 앱에 할당하며, 일 실시형태에서는, 그 앱이 연합체의 일부인지 여부를 쿼리할 것이다. 앱은 (이 예시에서는) 일부라고 응답할 것이며, 게이트웨이는 그후 연합체 쿠키를 송신한다. 게이트웨이는 연합체 쿠키를 다른 앱들과 공유하도록 앱에게 지시한다.

일 실시형태에서, 앱이 래핑될 때, 그것이 게이트웨이로부터 연합체 쿠키를 수신하면 (앱이 쿠키를 발견할 때 앱은 쿠키를 인식할 방법을 알고 있을 것이다), 앱이 쿠키를 이용가능하게 만들어야 한다는 것을 앱이 그의 연합체에서의 다른 앱들에 알도록, 구성된다. 게이트웨이에 등록하려고 시도하는 연합체 내 다른 앱들은 이 연합체 쿠키에 대해 시도될 것이다. 다른, 그 후에 호출된, 앱이 쿠키를 가지면, 게이트웨이는 IP 어드레스들 및 다른 데이터를 아래에서 설명되는 특정의 방법으로 조작하는 것으로 진행할 수 있다는 것을 알고 있다.

앱이 래핑될 때, 연합체 쿠키가 부여될 수도 있다는 점, 또는 앱이 게이트웨이에 의해 그에 시도될 것이기 때문에 (동일한 연합체에서의 다른 앱으로부터) 연합체 쿠키를 획득해야 할 수도 있다는 점을 알도록 앱이 구성된다. 본질적으로, 연합된 앱은 그것이 게이트웨이와 통신할 때 연합체 쿠키를 이용해야 할 수도 있을 가능성을 알도록 래핑 (wrap) 시간 동안 구성될 수 있다.

일 실시형태에서, 게이트웨이가 모바일 디바이스 상에서 먼저 호출되는 연합된 앱에 연합체 쿠키를 부여할 때, 게이트웨이는 또한 앱에 고유 IP 어드레스, 즉, 그 모바일 디바이스에 고유 IP 어드레스를 부여한다. 이들 2개의 아이템들, 즉, 쿠키 및 IP 어드레스에 더해서, 일 실시형태에서, 그것은 또한 앱에 모바일 디바이스 상에서의 포트들의 범위를 부여한다. 이 포트 범위는 데이터 트래픽을 소스 IP (모바일 디바이스) 로부터 목적지 IP (게이트웨이) 로 통신하는데 사용되며, 반대의 경우도 마찬가지이다.

앱은 이 포트 범위를 이용하여, 디바이스 상의 특정의 연합된 앱으로부터 데이터를 전송할 때 어느 (모바일 디바이스 상의) 소스 포트를 이용할지를 제한한다. 예시하기 위하여, 게이트웨이는 앱에 100-199 의 포트 범위를 전송할 수도 있다. 이것은 앱이 트래픽을 생성하여 사설 VPN 접속을 통해서 전송할 때 앱이 100 내지 199 의 범위에서의 포트를 이용해야 한다는 것을 앱에 알린다. 이와 같이, 게이트웨이가 디바이스로부터 트래픽을 수신하고 트래픽이 유래하고 있는 장소로부터의 소스 포트 (모바일 디바이스 상의 포트) 가 100-199 범위 이내라고 발견할 때, 게이트웨이는 설령 IP 어드레스가 단지 그 디바이스에 대해서만 고유하더라도 트래픽이 특정의 연합된 앱으로부터 들어오고 있다는 것을 안다. 그 디바이스 상에서, 앱이 사용할 포트 번호가 디바이스의 운영 시스템에 의해 앱에 할당되며 그 포트 번호가 그 앱에 고유하다.

게이트웨이의 기업 측면에서, 게이트웨이가 기업 서버들 (예컨대, 고용주의 내부 네트워크) 로부터 트래픽을 수신하는 경우, 게이트웨이는 디바이스 상의 앱에 맵핑하는 (게이트웨이 상의) 목적지 포트 범위에 대한 테스트로서 이 포트 범위를 이용할 수 있다. 1차 제한 사항들은 (모바일 디바이스 상의) 소스 포트 번호가 게이트웨이에 의해 할당된 범위이어야 하는 점, 그리고 VPN 을 통해서 통신할 때 디바이스 상의 어떤 다른 앱도 그 포트 번호를 이용하지 않는다는 점이다. 위에서 언급한 바와 같이, 하나의 앱의 연합체는 설령 앱이 고유 IP 어드레스를 사용하기에 충분하더라도, 포트 범위를 여전히 할당받을 수도 있다.

이 단계에서는, 연합체에서의 제 1 앱이 실행중에 있으며 게이트웨이와의 보안 VPN 을 가지며, 고유 IP 어드레스를 가지며, 그리고 게이트웨이에 의해 지시받은 바에 따라서 포트 범위 내 포트로부터 데이터를 송신하고 있다. 이제 연합체에서의 제 2 앱이 열린다. 이 제 2 앱은 연합체 쿠키에 대해 게이트웨이에 의해 시도된다. 일단 쿠키가 제 2 앱에 의해 게이트웨이에 제시되면, 앱은 제 1 앱에 부여된 동일한 IP 어드레스를 부여받는다. 게이트웨이는 그 제 2 연합된 앱에 대해 단독으로 제 2 고유 IP 어드레스를 생성할 필요가 없다. 그러나, 게이트웨이는 제 2 앱에 상이한 포트 범위, 예컨대, 200-299 를 부여한다. 제 2 앱이 200-299 포트 범위에서의 포트로부터 그의 자신의 사설 VPN 터널을 통해서 데이터를 전송하기 시작할 때, 게이트웨이는 200-299 범위의 임의의 소스 포트로부터 수신하는 데이터가 특정의 연합체에서의 제 2 앱으로부터 유래함을 알 것이다. 언급한 바와 같이, 게이트웨이는, 또한 특정의 소스 포트로부터 유래하는 수신하는 트래픽이 그 특정의 앱 (즉, 제 2 앱) 으로부터 들어오고 있다고 게이트웨이가 확신할 수 있게 제 2 앱이 이용하는 포트가 그 앱에 고유하다는 것을 보장하도록, 제 2 앱에게 지시한다. 단지 그 앱만이 그 범위에서의 포트를 이용할 것이다. 앱이 닫혀지고 포트를 이용하여 행해질 때, 포트는 닫혀지고 운영 시스템은 그 포트 번호를 재사용할 수 있다. 게이트웨이는 단지 그 앱만이 200-299 포트 범위에서의 소스 포트를 이용할 것이라고 더 이상 예상하지 않을 것이다.

도 9 는 본 발명의 여러 컨셉들을 예시하는 네트워크의 구성요소들을 도시하는 블록도이다. 도시된 것은 모바일 디바이스 (902), 게이트웨이 (904), 및 기업 (사설) 서버 (906) 이다. 디바이스 (902) 와 게이트웨이 (904) 사이의, 2개의 앱들 (912 및 914) 사이에, 각각 2개의 보안 터널들 또는 VPNs (908 및 910) 이 존재한다.

모바일 디바이스 (902) 는 소스 IP ("SRC IP") 로서 지칭되는, (공공 사업자에 의해 그에 할당된) 공공 IP 어드레스를 갖는다. 앱들 (912 및 914) 의 각각은 내부 IP 어드레스 및 포트 범위를 가지며, 이의 양자는 게이트웨이 (904) 에 의해 할당된다. 게이트웨이 (904) 는 공공 사업자에 의해 할당된 공공 IP 어드레스 ("DEST IP"), 내부 IP 어드레스 풀, 및 포트 범위 데이터 스토어를 갖는다.

2개의 VPNs 또는 보안 터널들 (908 및 910) 이 존재한다. VPN (908) 은 앱 (912) 을 모바일 디바이스 (902) 상의 포트 x (916) (앱 (912) 에 대해 배타적으로 포트 x) 를 통해서 게이트웨이 (904) 에 접속한다. 보안 터널 (908) 은 SRC IP 어드레스 및 DEST IP 어드레스를 이용하여 확립되거나 또는 생성된다. 이와 유사하게, 보안 터널 (910) 은 SRC IP 및 DEST IP 어드레스들을 이용하여 생성되며 앱 (914) 을 포트 m (918) 을 통해서 게이트웨이 (904) 에 접속한다. 그러나, 보안 터널들에서 여행하는 데이터는, "터널 내부" IP 어드레스들로서 특징화될 수도 있는 기업 서버 IP 어드레스 및 내부 IP 어드레스들로 이루어지는 어드레스들을 갖는다. 아래에서 설명되는 바와 같이, 보안 터널들에서 여행하는 데이터는 일반적으로 사설 기업 서버, 예컨대 서버 (906) 와 특정의 앱 사이에 있다. 따라서, 보안 터널을 통해서 게이트웨이 (904) 를 경유해서 송신되는 데이터는 앱의 내부 IP 어드레스를 이용하며 디바이스 (902) 의 공공 IP 어드레스를 이용하지 않는다.

도 10 은 일 실시형태에 따른 데이터를 기업 서버로부터 특정의 앱으로 되라우팅하는 방법을 결정하기 위해 게이트웨이 디바이스에 의해 실행되는 프로세스의 흐름도이다. 단계 1002 에서, 디바이스 및 게이트웨이는 AT&T 또는 Comcast 와 같은, 기업의 인터넷 서비스 제공자로부터 공공 IP 어드레스들을 할당받는다 (또는, 이미 할당받았다). 모바일 디바이스에 대한 어드레스는 소스 IP 어드레스 (SRC IP) 이고 게이트웨이에 대한 어드레스는 목적지 IP 어드레스 (DEST IP) 이다.

단계 1004 에서, 사용자는 모바일 디바이스 상의 제 1 앱을 연다. 게이트웨이는 내부 IP 어드레스를 그의 자신의 IP 어드레스 풀로부터 제 1 앱에 할당한다. 게이트웨이는 또한 (본원에서 "제 1 포트 범위" 로서 지칭되는) 포트 범위를 앱에 할당한다. 게이트웨이는 이들 데이터를, 구체적으로 설명하면, 제 1 앱에 할당된, 내부 IP 어드레스 및 포트 범위를 데이터 스토어에 저장한다. 단계 1006 에서, 사용자는 모바일 디바이스 상에서 제 2 앱을 연다. 게이트웨이는 동일한 내부 IP 어드레스를 제 2 앱에 할당하고, 이에 의해 내부 어드레스들의 게이트웨이의 제한된 풀 (pool) 로부터의 다른 내부 IP 어드레스를 이용할 필요가 없다. 제 1 및 제 2 앱들은 동일한 게이트웨이 내부 IP 어드레스를 갖는다. 게이트웨이는 또한 제 2 앱에 제 1 앱에 할당된 포트 범위와는 상이한 제 2 포트 범위를 할당한다. 이들 데이터는 또한 게이트웨이에 저장된다. 아래에서 설명하는 바와 같이, 데이터는 본질적으로 역방향 룩-업을 수행하여 (게이트웨이에 의해 동일한 내부 IP 어드레스를 부여받은 모든 앱들 중에서) 어느 앱이 데이터를 수신해야 하는지를 발견하기 위해 게이트웨이에 의해 사용된다.

단계 1008 에서, 사용자는 제 1 앱을 실행하고, 앱은 데이터를 사설 기업 네트워크에서의 게이트웨이 이면에서 동작하는 (앱에 관련된) 기업 서버로 가는 도중에 게이트웨이로 송신하기 시작한다. 단계 1010 에서, 사용자는 데이터가 게이트웨이 이면의 기업 서버로 송신되는 제 2 앱 (그것은 제 1 앱 또는 다른 앱과 동일한 앱일 수도 있다) 에 대해 동일하게 수행한다. 이 예에서, 2개의 앱들은 데이터를 동일한 기업 서버로 전송한다.

단계 1012 에서, 기업 서버는 데이터를 게이트웨이로 되전송한다. 이 데이터는 제 1 앱으로부터 또는 제 2 앱으로부터의 요청에 응답할 수도 있다. 사설 기업 서버 자체는 그 디바이스 상의 어느 앱으로 데이터가 전송되어야 하는지를 알지 못한다. 사설 기업 서버는 어떤 룩-업들 또는 임의 종류의 어드레스 변환도 수행하지 않는다. 사설 기업 서버는 간단히 데이터를 게이트웨이로 되송신하고, 여기서 데이터는 내부 IP 어드레스가 동반된다. 기업 서버로부터 게이트웨이로의 데이터는 그에 내장된, 내부 DEST IP 어드레스 및 DEST 포트 (또는, 트래픽을 발신한 모바일 앱의 내부 DEST IP 어드레스 및 DEST 포트) 를 갖는다.

단계 1014 에서, 게이트웨이는 서버로부터 데이터를 수신하고 데이터가 전송될 내부 IP 어드레스 및 목적지 포트를 검사한다. 게이트웨이는 내부 또는 아니면 액세스가능한 데이터 스토어에서 탐색하여, 게이트웨이가 기업 서버로부터 데이터를 획득하는 내부 IP 어드레스가 디바이스 상의 앱들의 특정의 연합체에 대응하는지를 결정하고, 목적지 포트를 이용하여 디바이스 상의 연합체에서의 어느 특정의 앱이 데이터를 수신하기로 되어 있는지를 탐색한다. 일 실시형태에서, 게이트웨이는 구체적으로 말하면 어느 앱이 데이터를 수신해야 하며 데이터를 전송하는데 어느 보안 연관성을 이용할지를 결정하기 위해, 양쪽의 이들 아이템들, 즉 내부 IP 어드레스 및 포트 번호 양자를 필요로 한다. 단계 1016 에서, 게이트웨이는 모바일 디바이스 상의 앱의 할당된 포트를 이용하여 데이터를 특정의 앱으로 게이트웨이와 특정의 앱 사이의 전용 보안 터널을 통해서 전송한다.

도 11 은 일 실시형태에 따른, VPN 게이트웨이 활성 세션 모니터 스크린을 도시하는 디스플레이의 스크린 샷이다. 사용자 디스플레이 (1102) 는 게이트웨이에 접속된 사용자들, 디바이스들, 및 앱들에 관련된 여러 데이터 및 정보를 보인다. 도 11 에 나타낸 바와 같은 활성 세션 쿼리의 전형적인 사용자는, 그들의 기업들에서 모바일 앱 및 데이터 사용에 관한 특정의 및 정확한 정보를 학습하는데 흥미를 갖고 있는, 기업 모바일 보안 책임자 또는 네트워크 보안 관리자일 수도 있다.

스크린 (1102) 에는 데이터의 3개의 카테고리들, 즉, 선택된 사용자를 위한 세션 데이터 (1104); 디바이스 데이터 (1106); 및 앱 데이터 (1108) 가 있다. 이 정보는 박스 (1110) 에 나타낸 선택된 사용자에 대한 것이다. 세션 데이터 (1104) 는 사용자 이름, 그룹, 로그인 시간 및 일자, 현재의 세션의 길이, 및 인증 제공자와 같은 정보를 나타낸다. 이 경우, 사용자 인증은 재접속 토큰을 이용하여 제공된다.

활성 세션 데이터의 다른 카테고리는 박스 (1106) 에 도시된 "사용 디바이스들" 이다. 여기에 나타낸 것은, 적용가능한 경우, 디바이스 식별자 (예컨대, 일부 경우들에서는 MAC 어드레스), (스마트폰, 태블릿, 랩탑, 또는 다른 휴대형 컴퓨팅 디바이스일 수도 있는) 디바이스의 하드웨어 유형, 디바이스 상의 운영 시스템의 유형 및 버전, 및 그 접속을 제공하는 사업자의 이름이다. 사업자는 모바일 디바이스 및 게이트웨이의 공공 IP 어드레스들를 제공할 수도 있다.

제 3 카테고리는 선택된 사용자에 의해 사용될 애플리케이션들을 기술하는 데이터 (1108) 이다. 이 데이터는 (박스 (1106) 에 나타낸 디바이스 데이터와 동일한) 디바이스 정보, 애플리케이션 (이 경우, "NSLookup" 으로 불리는, 브라우저 앱 및 다른 앱) 의 이름 및 관련된 앱 정보를 포함한다. 이 데이터는 패키지 ID, UUID, 및 세션 ID 를 포함할 수도 있다. VPN 게이트웨이를 이용하여 모니터링되는 앱들이 위에서 도 1 내지 도 6 에서 설명된 프로세스들을 이용하여 보안 래핑된다는 것을 상기하자. 이와 같이, 또한 제공된 것은 박스 (1108) 에 리스트된 앱을 래핑하는데 사용되는 앱 보안 소프트웨어 버전 정보이다. 모든 이런 정보는 기업에서의 실제 앱 사용에 기초하는 심층적인 세부사항, 즉 누가 어느 디바이스들 상에서 (그리고 어떤 그들 디바이스들의 상태에서) 그리고 얼마나 오랫동안 기간 동안 어느 앱들 (및 어느 그들 앱들의 버전) 을 이용하고 있는 지를 제공한다.

도 12a 및 도 12b 는 본 발명의 실시형태들을 구현하는데 적합한 컴퓨팅 시스템 (1200) 을 예시한다. 도 12a 는 컴퓨팅 시스템의 하나의 가능한 물리적인 유형을 도시한다. 물론, 컴퓨팅 시스템은 집적 회로, 인쇄 회로 보드, (모바일 전화기, 핸드셋 또는 PDA 와 같은) 소형 핸드헬드 디바이스, 개인용 컴퓨터 또는 슈퍼 컴퓨터를 포함한, 많은 물리적인 형태들을 가질 수도 있다. 컴퓨팅 시스템 (1200) 은 모니터 (1202), 디스플레이 (1204), 하우징 (1206), 디스크 드라이브 (1208), 키보드 (1210) 및 마우스 (1212) 를 포함한다. 디스크 (1214) 는 컴퓨터 시스템 (1200) 으로 그리고 그로부터 데이터를 전송하는데 사용되는 컴퓨터-판독가능 매체이다.

도 12b 는 컴퓨팅 시스템 (1200) 에 대한 블록도의 일 예이다. 매우 다양한 서브시스템들이 시스템 버스 (1220) 에 부착된다. 프로세서(들) (1222) (또한, 중앙 처리 유닛들, 또는 CPU들로서 지칭됨) 은 메모리 (1224) 를 포함하는 저장 디바이스들에 커플링된다. 메모리 (1224) 는 랜덤 액세스 메모리 (RAM) 및 판독 전용 메모리 (ROM) 를 포함한다. 당업계에 널리 알려져 있는 바와 같이, ROM 은 데이터 및 명령들을 CPU 로 단방향으로 전송하도록 작용하며, RAM 은 일반적으로 데이터 및 명령들을 양방향으로 전송하기 위해 사용된다. 이들 유형들의 메모리들 양자는 아래에 설명되는 컴퓨터-판독가능 매체들 중 임의의 적합한 매체를 포함할 수도 있다. 고정 디스크 (1226) 는 또한 CPU (1222) 에 양방향으로 커플링되며; 고정 디스크는 추가적인 데이터 저장용량을 제공하며 또한 아래에 설명되는 컴퓨터-판독가능 매체들 중 임의의 매체를 포함할 수도 있다. 고정 디스크 (1226) 는 프로그램들, 데이터 및 기타 등등을 저장하는데 사용될 수도 있으며, 일반적으로 1차 스토리지보다 더 느린 (하드 디스크와 같은) 2차 저장 매체이다. 고정 디스크 (1226) 내에 보유하고 있는 정보는, 적합한 경우, 메모리 (1224) 에 가상 메모리로서 표준 방식으로 포함될 수도 있음을 알 수 있을 것이다. 착탈식 디스크 (1214) 는 아래에 설명되는 컴퓨터-판독가능 매체들 중 임의의 매체의 유형을 취할 수도 있다.

CPU (1222) 는 또한 디스플레이 (1204), 키보드 (1210), 마우스 (1212) 및 스피커들 (1230) 과 같은, 다양한 입출력 디바이스들에 커플링된다. 일반적으로, 입출력 디바이스는 비디오 디스플레이들, 트랙 볼들, 마우스들, 키보드들, 마이크로폰들, 터치-감지 디스플레이들, 트랜스듀서 카드 리더들, 자기 또는 종이 테이프 리더들, 태블릿들, 스타일러스들, 보이스 또는 필기 인식기들, 생체인식 리더들, 또는 다른 컴퓨터들 중 어느 것일 수도 있다. CPU (1222) 는 옵션적으로 다른 컴퓨터 또는 원격통신 네트워크에 네트워크 인터페이스 (1240) 를 이용하여 커플링될 수도 있다. 이러한 네트워크 인터페이스에 의하면, 위에서 설명한 방법 단계들을 수행하는 도중에 CPU 가 네트워크로부터 정보를 수신할지도 모르거나, 또는 정보를 네트워크로 출력할지도 모른는 것으로 예기된다. 더욱이, 본 발명의 방법 실시형태들은 CPU (1222) 상에서 단독으로 실행할 수도 있거나, 또는 프로세싱의 일부를 분담하는 원격 CPU 와 연계하여 인터넷과 같은 네트워크를 통해서 실행할 수도 있다.

본 발명의 예시적인 실시형태들 및 애플리케이션들이 도시되고 본원에서 설명되지만, 본 발명의 컨셉, 범위, 및 정신 내에서 유지하는 많은 변형예들 및 변경들이 가능하며, 이들 변형예들은 본 출원의 숙독 후 당업자들에게 명백해질 것이다. 따라서, 설명된 실시형태들은 예시적이고 비한정적인 것으로 간주되어야 하며, 본 발명은 본원에서 주어지는 세부 사항들에 한정되지 않고, 첨부된 청구항들의 범위 및 균등물들 내에서 변경될 수도 있다.

Claims

디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법으로서,
내부 고유 IP 어드레스를 상기 VPN 게이트웨이로부터 상기 제 1 앱으로 송신하는 단계;
앱 연합체 쿠키를 상기 VPN 게이트웨이로부터 상기 제 1 앱으로 송신하는 단계;
상기 앱 연합체 쿠키를 앱들의 연합체에서의 제 2 앱과 공유시키는 단계;
상기 제 2 앱에 동일한 내부 고유 IP 어드레스를 할당하는 단계;
포트들의 제 1 범위를 상기 제 1 앱으로 송신하는 단계로서, 상기 제 1 앱은 상기 제 1 포트 범위에서의 포트를 상기 제 1 앱으로부터 상기 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 사용하는, 상기 송신하는 단계;
상기 VPN 게이트웨이에서, 상기 제 1 앱으로부터의 데이터 송신을 수신하는 단계; 및
상기 VPN 게이트웨이에서, 상기 소스 포트에 기초하여 상기 데이터 송신이 상기 제 1 앱으로부터 유래하였다고 결정하는 단계를 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 1 항에 있어서,
상기 VPN 게이트웨이로부터 상기 제 2 앱으로, 제 2 포트 범위를 송신하는 단계로서, 상기 제 2 앱은 상기 제 2 포트 범위에서의 포트를 상기 제 2 앱으로부터 상기 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 이용하는, 상기 송신하는 단계;
상기 VPN 게이트웨이에서, 상기 제 2 앱으로부터의 데이터 송신을 수신하는 단계; 및
상기 VPN 게이트웨이에서, 상기 소스 포트에 기초하여 상기 데이터 송신이 상기 제 2 앱으로부터 유래하였다고 결정하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 1 항 또는 제 2 항에 있어서,
상기 고유 IP 어드레스는 상기 앱들의 연합체에 의해 사용되며, 상기 앱들의 연합체에서의 개개의 앱들에는 개개의 고유 IP 어드레스들이 할당되지 않는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
VPN 게이트웨이 IP 어드레스 및 VPN 게이트웨이 도메인 이름으로 상기 제 1 앱을 구성하고, 상기 제 1 앱이 실행할 때 상기 제 1 앱을 상기 VPN 게이트웨이에 접촉가능하도록 하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
상기 제 1 앱에게 상기 연합체 쿠키를 상기 제 2 앱과 공유하도록 지시하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 5 항에 있어서,
상기 제 2 앱이 실행할 때 상기 연합체 쿠키에 대해 상기 제 2 앱을 시도하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
상기 제 1 앱을 래핑할 때, 연합체 쿠키를 부여받을 수도 있음을 또는 상기 연합체에서의 다른 앱으로부터 연합체 쿠키를 취출해야 할 수도 있음을 알 수 있도록, 상기 제 1 앱을 구성하는 단계; 및
상기 제 2 앱을 래핑할 때, 연합체 쿠키를 부여받을 수도 있음을 또는 상기 연합체에서의 다른 앱으로부터 연합체 쿠키를 취출해야 할 수도 있음을 알 수 있도록, 상기 제 2 앱을 구성하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
상기 제 2 앱으로부터 상기 연합체 쿠키를 수신하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 VPN 터널을 통해서 통신하는 방법.
디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법으로서,
내부 고유 IP 어드레스 및 앱 연합체 쿠키를 VPN 게이트웨이로부터 상기 디바이스 상의 상기 제 1 앱으로 송신하는 단계로서, 상기 앱 연합체 쿠키는 앱들의 연합체에서의 제 2 앱과 공유되며 상기 제 2 앱에는 상기 동일한 내부 고유 IP 어드레스가 할당되는, 상기 송신하는 단계;
포트들의 제 1 범위를 상기 VPN 게이트웨이로부터 상기 제 1 앱으로 송신하는 단계로서, 상기 제 1 앱은 상기 제 1 포트 범위에서의 포트를 상기 제 1 앱으로부터 상기 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 사용하는, 상기 송신하는 단계;
상기 VPN 게이트웨이에서, 상기 제 1 앱으로부터의 데이터 송신을 수신하는 단계; 및
상기 VPN 게이트웨이에서, 상기 소스 포트에 기초하여 상기 데이터 송신이 상기 제 1 앱으로부터 유래하였다고 결정하는 단계를 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 9 항에 있어서,
상기 VPN 게이트웨이로부터 상기 제 2 앱으로, 제 2 포트 범위를 송신하는 단계로서, 상기 제 2 앱은 상기 제 2 포트 범위에서의 포트를 상기 제 2 앱으로부터 상기 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 이용하는, 상기 송신하는 단계;
상기 VPN 게이트웨이에서, 상기 제 2 앱으로부터의 데이터 송신을 수신하는 단계; 및
상기 VPN 게이트웨이에서, 상기 소스 포트에 기초하여 상기 데이터 송신이 상기 제 2 앱으로부터 유래하였다고 결정하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 9 항 또는 제 10 항에 있어서,
상기 고유 IP 어드레스는 상기 앱들의 연합체에 의해 사용되며, 상기 앱들의 연합체에서의 개개의 앱들에는 개개의 고유 IP 어드레스들이 할당되지 않는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 9 항 내지 제 11 항 중 어느 한 항에 있어서,
VPN 게이트웨이 IP 어드레스 및 VPN 게이트웨이 도메인 이름으로 상기 제 1 앱을 구성하고, 상기 제 1 앱이 실행할 때 상기 제 1 앱을 상기 VPN 게이트웨이에 접촉가능하도록 하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 9 항 내지 제 12 항 중 어느 한 항에 있어서,
상기 제 1 앱에게 상기 연합체 쿠키를 상기 제 2 앱과 공유하도록 지시하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 13 항에 있어서,
상기 제 2 앱이 실행할 때 상기 연합체 쿠키에 대해 상기 제 2 앱을 시도하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 9 항 내지 제 14 항 중 어느 한 항에 있어서,
상기 제 1 앱을 래핑할 때, 연합체 쿠키를 부여받을 수도 있음을 또는 상기 연합체에서의 다른 앱으로부터 연합체 쿠키를 취출해야 할 수도 있음을 알 수 있도록, 상기 제 1 앱을 구성하는 단계; 및
상기 제 2 앱을 래핑할 때, 연합체 쿠키를 부여받을 수도 있음을 또는 상기 연합체에서의 다른 앱으로부터 연합체 쿠키를 취출해야 할 수도 있음을 알 수 있도록, 상기 제 2 앱을 구성하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
제 9 항 내지 제 15 항 중 어느 한 항에 있어서,
상기 제 2 앱으로부터 상기 연합체 쿠키를 수신하는 단계를 더 포함하는, 디바이스 상의 제 1 앱과 VPN 게이트웨이 사이에 가상 사설 네트워크 (VPN) 터널을 통해서 통신하는 방법.
가상 사설 네트워크 (VPN) 게이트웨이로서,
내부 고유 IP 어드레스 및 앱 연합체 쿠키를 상기 가상 사설 네트워크 (VPN) 게이트웨이로부터 디바이스 상의 제 1 앱으로 송신하도록 구성된 출력 인터페이스로서, 상기 앱 연합체 쿠키는 앱들의 연합체에서의 제 2 앱과 공유되며 상기 제 2 앱에는 상기 동일한 내부 고유 IP 어드레스가 할당되며, 상기 출력 인터페이스는 포트들의 제 1 범위를 상기 VPN 게이트웨이로부터 상기 제 1 앱으로 송신하도록 더 구성되며, 상기 제 1 앱은 상기 제 1 포트 범위에서의 포트를 상기 제 1 앱으로부터 상기 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 사용하는, 상기 출력 인터페이스;
상기 VPN 게이트웨이에서, 상기 제 1 앱으로부터의 데이터 송신을 수신하도록 구성된 입력 인터페이스;
상기 제 1 포트 범위를 상기 제 1 앱과 연관시키도록 구성된 맵핑 메커니즘; 및
상기 소스 포트에 기초하여 상기 데이터 송신이 상기 제 1 앱으로부터 유래하였다고 결정하도록 구성된 VPN 게이트웨이 프로세서를 포함하는, 가상 사설 네트워크 (VPN) 게이트웨이.
제 17 항에 있어서,
상기 출력 인터페이스는 상기 VPN 게이트웨이로부터 상기 제 2 앱으로, 제 2 포트 범위를 송신하도록 더 구성되며, 상기 제 2 앱은 상기 제 2 포트 범위에서의 포트를 상기 제 2 앱으로부터 상기 VPN 게이트웨이로의 데이터 송신을 위한 소스 포트로서 이용하는, 가상 사설 네트워크 (VPN) 게이트웨이.
제 17 항 또는 제 18 항에 있어서,
상기 맵핑 메커니즘은 상기 제 2 포트 범위를 상기 제 2 앱과 연관시키도록 더 구성되는, 가상 사설 네트워크 (VPN) 게이트웨이.
제 17 항 내지 제 19 항 중 어느 한 항에 있어서,
상기 VPN 게이트웨이 프로세서는 상기 소스 포트에 기초하여 상기 데이터 송신이 상기 제 2 앱으로부터 유래하였다고 결정하도록 더 구성되는, 가상 사설 네트워크 (VPN) 게이트웨이.