KR20160042110A

KR20160042110A - 운영 시스템 통합 도메인 관리

Info

Publication number: KR20160042110A
Application number: KR1020167006469A
Authority: KR
Inventors: 알렉산더 제임스 메인; 제임스 헨리 알란 푸더러
Original assignee: 그라파이트 소프트웨어 코포레이션
Priority date: 2013-08-12
Filing date: 2014-08-11
Publication date: 2016-04-18
Also published as: CA2921090A1; CN105830477A; EP3033894A1; WO2015021547A1; US11356431B2; WO2015021548A1; EP3033707A1; CN105981027A; EP3033707A4; KR102096550B1; US10469472B2; CA2921090C; US20160196432A1; US20200244637A1; KR20160043029A; EP3033894B1; US20160205082A1; EP3033894A4; CA2921092A1

Abstract

컴퓨팅 디바이스 운영 시스템이 복수의 보안 도메인들을 제공한다. 도메인 관리자는 복수의 보안 도메인들을 선택적으로 생성하며, 그리고 상기 보안 도메인들 중 하나의 보안 도메인이 현재 도메인으로 선택된다. 도메인 정책 서비스는 각 보안 도메인에 대해 정책을 저장하고 강제하며, 그 정책은 상기 도메인과 연관된 애플리케이션들 및 파일들에 대한 액세스를 제어하는 규칙 세트를 포함한다. 패키지 관리자는 각 보안 도메인에 대해 그 도메인과 연관된 애플리케이션의 설치를 강제한다. 도메인 메시지 서비스는 상기 보안 도메인들 중 상이한 것들과 연관된 동작 프로세스들을 제공한다. 활성화 관리자는 현재의 도메인을 선택적으로 스위치한다. 도메인 격리는 통합된 사용자 인터페이스가 다중의 도메인들의 자원들에게로 동시 액세스를 제공하는 것을 가능하게 하면서 달성된다.

Description

운영 시스템 통합 도메인 관리 {OPERATING SYSTEM INTEGRATED DOMAIN MANAGEMENT}

본 발명 개시는 모바일 디바이스 보안에 일반적으로 관련된다. 더욱 상세하게는, 본 발명 개시는 모바일 디바이스들을 위한 보안 도메인 관리에 관련된다.

안드로이드 (Android™), 리눅스 (Linux™), 또는 유닉스 (Unix™)-기반의 운영 시스템 (예를 들면, 아이폰 (iPhone™)과 같은)을 기반으로 하는 스마트폰들, 태블릿들 그리고 모바일 인터넷 디바이스들과 같은 모바일 디바이스들 상에 다중의 분리된 도메인들에 대한 필요성이 존재하며, 여기에서 도메인 내에 상주하는 애플리케이션들 및 데이터는 상기 도메인 외부에, 웹 사이트 상에, 또는 동일한 디바이스 상의 다른 도메인 내에 상주하는 애플리케이션들로부터의 결과일 수 있는 보안 위험들로부터 격리된다. 그런 다중의 보안 도메인들은 상이한 모바일 디바이스 사용 경우들과 연관된 가변의 쉬운 액세스, 프라이버시 및 보안 요구사항들을 중점을 두어 다루기 위해서 단일의 사용자, 디바이스 소유자에 의해 보통 사용될 것이다. 예를 들면, 디바이스 소유자는 모바일 뱅킹 애플리케이션 및 데이터를 위해서, 게임 애플리케이션들을 위해 가지는 것과는 상이한 액세스 용이성, 프라이버시 및 보안 요구사항들을 가질 수 있을 것이며, 또는 디바이스 소유자는 가족이나 친구와 일시적으로 자신의 디바이스 상에서 어떤 애플리케이션을 공유하지만 다른 애플리케이션들 그리고 개인적인 이메일들, 연락처들 및 텍스트 메시지들과 같은 데이터는 공유하지 않기를 원할 수 있을 것이다. 추가로, 상이한 도메인들이 디바이스 소유자 또는 기관이나 회사와 같은 외부 파티 (party)와 같이 상이한 엔티티들에 의해 관리될 것에 대한 요구가 존재하며, 이 경우 각 엔티티는 자신이 관리하는 도메인 내 애플리케이션들 및 데이터에 액세스하고 사용하기 위한 상이한 보안 요구사항들을 가질 수 있다. 예를 들면, 그 요구사항들은 각 도메인 내에서 허용된 애플리케이션들에 대한 도메인들, 그리고 애플리케이션들이 도메인 내에서 실행하는 상황들에 걸쳐서는 상이할 수 있으며, 그것들 각각은 각 도메인에 대해서 그 도메인을 관리하는 엔티티에 의해 유일하게 설정 가능할 필요가 있을 것이다. 도메인 내에 포함된 애플리케이션들 및 데이터의 유형에 종속하여 상이한 도메인들로 진입하기 위해 필요한 상이한 사용자 인증 메커니즘들, 상이한 재-인증 타임프레임들 (또는 옵션으로는 인증 없음)을 지원할 필요성이 또한 존재한다 (예를 들면, 디바이스 소유자는 게임을 하기 위해 또는 Google™ Maps에 액세스하기 위해 패스워드를 입력할 것을 원하지 않을 수 있을 것이지만 모바일 뱅킹 애플리케이션들에 액세스하기 위해서는 강력한 모습의 인증을 가질 것을 원할 수 있을 것이다).

모바일 디바이스 보안 및 도메인 격리를 위한 기술의 현재 상태는 전통적인 개인용 컴퓨터 (PC) 그리고 사용자 계정들, 하이퍼바이저들/가상화 (hypervisors/virtualization), 애플리케이션 래퍼들 (wrappers) 및 안티-바이러스 스캐닝과 같은 서버 컴퓨팅 보안 기술들을 사용한다. 그러나, 모바일 디바이스들의 전형적인 사용은 이런 전통적인 환경과는 아주 상이하다. 모바일 디바이스들은 원래 이동성이며 그리고 디바이스 소유자가 항상 가지고 있다. 그것들은 항상 온 (on) 상태로 연결되어 짧은 지속시간의 태스크들을 위한 빠른 액세스를 필요로 한다. 그것들은 전통적인 워크스테이션 및 메인프레임 공유와는 아주 상이한 방식으로 공유된다. 전력 소비는 또한 모바일 디바이스들에게 중대하며, 이는 전력을 잡아먹은 바이러스 스캐닝 및 가상화 기술들이 모바일 디바이스들에서 아직 널리 사용되지 않는 한 이유이다.

한 가지 전통적인 도메인 격리 접근 방식은 그 디바이스 상에 분리된 사용자 계정들을 생성하는 것이며, 그럼으로써 각 사용자는 그 사용자를 위해 구성된 계정으로 로그인해야만 한다. 운영 시스템 (operating system (OS))에 종속하여, 이것은 다른 사용자가 로그 아웃 하도록 강제할 수 있다. 이 접근 방식은 단일 디바이스 상의 여러 사용자들을 지원하며 그리고 각 사용자의 애플리케이션 데이터를 분리하거나 격리한다. 동일한 운영 시스템은 모든 사용자들에 걸쳐서 레버리지를 도입하며 그리고 모든 사용자들은 동일한 사용자 인터페이스 특징들을 가진다. 설치된 애플리케이션은 모든 사용자들에게 액세스 가능하며, 이는 메모리 및 중앙 처리 유닛 (CPU) 자원들의 효율적인 사용이다. 이것은 사용자가 자신이 원하는 룩 앤 필로 자신의 계정을 설정하는 것을 또한 허용한다.

사용자 계정들이 데이터 격리 그리고 상이한 사용자 계정들에 걸쳐 동일한 애플리케이션 및 OS를 사용하는 효율성을 제공하지만, 이 접근 방식은 다음의 한계들을 가진다. 그것은 디바이스로의 전부 아니면 아무것도 아닌 (all-or-nothing) 액세스를 제공하며, 일시적인 액세스를 위한 유연성도 없다. "게스트 (guest)" 사용자 계정들은 제한된 액세스를 구비하여 셋업될 수 있을 것이지만, 이것은 모바일 디바이스들과의 (예를 들면, 가족들이나 친구와의) 공통인 자발적인 공유를 쉽게 하지 않는다. 사용자 계정들은 개인용 디바이스들로 간주되는 모바일 디바이스들 상에서는 보통은 이용 가능하지 않다. 사용자는 각 사용자 계정 사이에서 여전히 스위치 해야만 하며, 이것은 사람들이 자신의 모바일 디바이스들을 사용하기 원하는 방식을 반영하지 않는다. 사용자는 사용자 계정들을 스위치할 때에는 로그인 해야만 하며, 이는 이런 접근 방식에 더 불편을 느끼게 하는데, 이는 다중-사용자 계정들에서의 제1 사용자와 제2 사용자 사이에는 어떤 암시적인 관계도 존재하지 않기 때문이다. 활동성이 없는 타이머나 유사한 메커니즘은 보통은 존재하지 않으며, 그래서 도메인들을 스위치할 때에는 로그인이 항상 요청되지는 않는다. 사용자들 (계정들) 사이의 격리는 사용자 공간, 또는 애플리케이션 레벨에서이며, 그리고 OS에 의해 집행된다. 관리자 또는 루트 액세스를 가진 사람이나 악성 소프트웨어 (malware)를 포함하는 소프트웨어는 모든 사용자들의 데이터에 액세스할 수 있다. 몇몇의 시스템들은 이 공격을 완화시키는 것을 돕기 위해 몇몇의 사용자 데이터를 암호화하는 것을 가능하게 하지만, 일반적으로는 상기 사용자 데이터는 여전히 매우 공격받기 쉬우며 그리고 어떤 커널 레벨 활용 또는 프로세스는 애플리케이션들, 프로세스들을 수정하고, 데이터를 가로채며 그리고 자신이 원하는 어떤 파일들/객체들에 액세스할 수 있다.

더욱이, 메인프레임 컴퓨터의 시절에 개발되었으며 유사하게 데스크탑들까지 연장된 전통적인 사용자 계정들은 스마트폰과 같은 진정한 개인용 디바이스 상에서는 제대로 동작하지 않는다. 모바일 디바이스들은 메인프레임들이나 데스크탑 컴퓨터들과는 상이하게 공유된다. 모바일 디바이스들 상에서 전통적인 스크린 잠금 또는 '전부 아니면 아무것도 아닌' 액세스 제어 메커니즘들에 대한 대안을 가지자는 디바이스 소유자들 및 사용자들로부터의 소망이 점점 증가한다. 예를 들면, 빈번하게 액세스되며 사용자 인증을 필요로 하지 않는 도메인에 민감한 정보를 포함하지 않는 애플리케이션들을 디바이스 소유자가 가지는 것이 바람직하다; 이것은 개인적인 보호된 도메인 또는 작업 보호된 도메인에 대한 요구사항들과는 상이하다. 그런 개방된, 공유된 또는 공통의 도메인의 주요 목표는 그런 애플리케이션들 및 데이터의 보안이 사용자에 의해 중요하지 않은 것으로 간주될 때에 (예를 들면, 날씨 또는 내비게이션) 사용의 용이함 및 빠른 액세스이다. 그처럼, 사용자는 그런 개방 도메인에 액세스하는 매번 패스워드나 PIN을 입력하는 것을 원하지 않는다. 추가로, 그런 개방 도메인은 사용자 또는 도메인 소유자가 자신의 보호된 도메인 내에서 허용할 수 있을 것보다 덜 믿을 수 있을 애플리케이션을 포함할 수 있다. 예를 들면, 안드로이드 상의 많은 애플리케이션들은 연락처 데이터베이스에 액세스하는 것으로 알려져 있다. 마지막으로, 애플리케이션의 설치를 가능하게 하기 위해 설치 시간 동안에 이 허가가 승인되어야만 하지만, 많은 사용자들은 이것을 면밀하게 체크하지 않으며 또는 그런 허가를 승인하는 것이 함축하는 것들을 이해하지 않는다.

추가의 전통적인 도메인 격리 접근 방식들이 도 1a 내지 도 1d를 참조하여 이제 설명된다.

당 기술 분야에서 알려진 것처럼, 그리고 도 1a에 도시되듯이, 운영 시스템을 구현한 모바일 디바이스와 같은 컴퓨팅 디바이스는 하드웨어, 커널 및 미들웨어를 포함한 운영 시스템, 그리고 애플리케이션 공간 (또는 사용자 공간)을 포함하는 것으로 이해될 수 있다. 상기 커널은 상기 하드웨어로의 액세스를 위해 소프트웨어 애플리케이션들로의 입력/출력 (I/O) 서비스들을 관리하고 제공하며, 그리고 상기 미들웨어는 커널에 의해 제공된 것들에 추가로 소프트웨어 애플리케이션들에게 서비스들을 제공한다.

도 1b 및 도 1c에 도시된 한 전통적인 도메인 격리 접근 방식은 하이퍼바이저-기반의 가상화 또는 가상 머신들을 채택한다. 가상 머신들을 이용하여 상기 운영 시스템은 상이한 격리 도메인들을 제공하기 위해 어느 정도 복제된다. 상기 하이퍼바이저에 종속하여 상이한 유형의 가상 머신들이 존재한다. 도 1b에 도시된 타입 1 (또는 베어-메탈 (bare-metal)) 하이퍼바이저는 디바이스 CPU ('베어메탈 (bare metal)') 상에서 직접 동작하며 그리고 각 도메인에 대해 운영 시스템의 완전하며 분리된, 권한을 뺏긴 (de-privileged) 인스턴스들을 지원함으로써 도메인의 격리를 제공한다. 격리는 상기 하이퍼바이저에만 종속한다. 도 1c에 도시된 타입 2 하이퍼바이저들은 다른 가상화 접근 방식이며, 여기에서 제2 게스트 OS는 호스트 OS의 제일 위에서 동작한다. 다른 혼성의 운영-시스템 레벨 가상화 접근 방식들이 마찬가지로 존재한다.

하이퍼바이저-기반 가상화는 도메인들 사이에서의 격리를 제공하지만, 다음의 한계들을 가진다. OS 및 애플리케이션들의 복제는 디바이스 메모리, CPU 및 전력 소비의 면에서 중대한 디바이스 오버헤드가 존재한다는 것을 의미한다. 하이퍼바이저 솔루션들을 위한 높은 자원 요구사항들은 다중 도메인들의 지원을 실행할 수 없게 만든다. 비록 몇몇의 크로스 도메인 데이터 공유가 상기 하비퍼바이저에 의해 지원된다면 특별한 메시징 서비스들을 통해 그런 공유가 제안되지만, 데이터, 애플리케이션 공유 및 인터-프로세스 통신들 (inter-process communications (IPC))은 보통은 가능하지 않다. 각 OS는 도메인들 사이에서의 격리를 손상시킬 수 있을 커널 레이어 악성 소프트웨어에게 노출된다. 사용자는 도메인들 사이에서 뒤로 그리고 앞으로 토글해야만 하며 (예를 들면, 개인 애플리케이션으로부터 작동 애플리케이션으로의 스위치), 이것은 사람들이 자신의 모바일 디바이스들을 사용하기를 원하는 방식에 영향을 미치지 않는다. 타입 1 또는 타입 2 하이퍼바이저를 모바일 디바이스로 통합하기 위한 시간 및 오버헤드는 낮은 가격의 모바일 디바이스들에 대해 이런 접근 방식을 매우 많이 실행 불가능하게 만든다. 도메인들 사이에서의 토글하는 것의 성능에 대한 영향은 매우 높다. 마지막으로, 그런 솔루션들은 각 OS에 의해 제공된 사용자 계정 및 사용자 인증은 무엇이든지 지원하며, 이는 전통적인 전부 아니면 아무것도 아닌 액세스이다.

도 1d에 도시된, 모바일 디바이스들 상 도메인 격리로의 세 번째 전통적인 접근 방식은 애플리케이션-레벨 컨테이너화 (containerization)를 포함한다. 이 경우에, 애플리케이션 컨테이너들 (또는 도메인들)은 동일한 하드웨어 및 OS를 공유하지만, 그 컨테이너 내의 애플리케이션과 OS 사이에서의 프록시로서 행동하기 위하여 컨테이너화 또는 래퍼 (wrapper) 기술을 사용한다. 이것은 우회적인 방법의 레이어를 제공함으로써 다중의 독립적인 도메인들을 생성하여, 더 낮은 레벨의 디바이스 자원들, 메모리 및 파일 시스템이 컨테이너 또는 도메인 내의 애플리케이션드레 의해서만 액세스 가능해야 하는 더 높은 레벨의 자원들로 투명하게 매핑될 수 있도록 한다. 비록 애플리케이션들이 컨테이너 내부에서 그리고 컨테이너 외부에서 보통은 복제되지만 (예를 들면, 컨테이너 내부에서의 작업을 위해 그리고 컨테이너 외부에서 개인적 사용을 위해 사용될 수 있을 이메일 애플리케이션), 컨테이너화는, 특히 단 하나의 OS 버전만이 존재하는 가상화와 비교하여 모바일 디바이스 자원들의 소비의 면에서 상대적으로 효율적이다. 애플리케이션 레벨 솔루션으로서, 컨테이너 솔루션들은 필드 내에서 디바이스들로 이미 다운로드될 수 있다는 점에서 (예를 들면, 역 호환성) 매우 실제적인 이점을 가진다.

컨테이너 화에서, 모든 보안 및 모든 집행들은 애플리케이션들을 포함하는 컨테이너 주변에 포장된다 (wrapped). 그처럼, 포함된 애플리케이션을 다운로드하는 어떤 사람은 그 애플리케이션만이 아니라, 그 애플리케이션과 연관된 모든 보안 정보도 수신하는 것이다. 컨테이너화를 이용하면, 악의를 가진 개인들이: (1) 보안 정책을 역 설계하고; 또는 (2) 정보가 추출될 수 있는 에뮬레이터 상에서와 같은 환경에서 애플리케이션을 실행하는 것 중 어느 것이 여전히 가능하다.

도메인 격리로의 접근 방식으로서의 애플리케이션-레벨 컨테이너화는 그러나 다음의 한계들을 가진다. 보안의 관점에서, 몇몇의 기본적인 기술들을 가진 해커 또는 디바이스 상에 상주하는 악성 소프트웨어가 상기 컨테이너와 상기 OS 사이의 호들을 가로채어 격리를 깨고 데이터 및 개인적인 정보를 포착하는 것은 상대적으로 쉽다. 컨테이너화는 운영 시스템 또는 커널 내에서 강제되지 않으며 그리고 상기 디바이스 상에 존재할 수 있을 악성 소프트웨어에 노출된다. 예를 들면, 운영 시스템이 리눅스 또는 안드로이드이며 그리고 해커가 루트 액세스 권한을 얻는다면, RAM으로부터 도메인 데이터 또는 다른 중대한 정보 (예를 들면, 도메인에 액세스하기 위해 사용되는 패스워드들, 또는 도메인 내 데이터를 암호화하기 위해 사용되는 암호화 키들)를 추출하는 것은, 또는 그런 커널 레이어 악성 소프트웨어가 마이크로폰이나 프레임 버퍼와 같은 I/O 드라이버들 상에서 도청하는 것은 상대적으로 쉽다. 컨테이너들은 그 컨테이너에 의해 "포장된 (wrapped)" 애플리케이션들 및 데이터를 격리하지만, 메모리, 파일들 또는 네트워크들 등에 액세스하는 것으로부터 그 컨테이너 내에 있지 않은 다른 애플리케이션들에 의한 액세스를 제한하지는 않는다. 도메인들에 걸쳐 단일의 애플리케이션 이미지를 공유하는 것은 가능하지 않으며 그리고 그런 기술은 컨테이너 내부 그리고 외부 둘 모두에 동일한 애플리케이션을 허용하지 않는다. 그 결과, 컨테이너는 메일, 메시징, 브라이징, 연락처들, 달력 등과 같이 그 컨테이너에게로 수정되었던 미리 정해진 애플리케이션만을 보통은 지원할 것이다. 이것은 사용자들 또는 회사 IT 부서가 원하는 애플리케이션 선택을 제공하지 않는다. 공통의 애플리케이션들은 상기 컨테이너를 지원하기 위해 수정되어야만 하며, 이것은 디바이스 상의 저장 및 메모리를 복제하며 그리고 애플리케이션 개발자의 노력 및 관련됨을 증가시킨다. 종종 비밀의 애플리케이션 저장이 컨테이너 솔루션에 특정하여 생성될 수 있으며, 이는 벤더 솔루션으로 속박되는 것을 증가시키며 그리고 애플리케이션 개발자에 의한 관련을 필요로 하여, 선택을 더 제한시킨다. 애플리케이션 래핑 접근 방식들을 구비함으로 인해서, 실행가능 코드는 데이터가 어떻게 저장되며, 공유되고 그리고 전송되는가를 제어하는 보안 라이브러리들로 패치되어야 할 필요가 있을 수 있다. 라이센스가 있어도 라이센스를 받은 사람이 애플리케이션을 수정하도록 보통은 허가하지 않으므로 이것은 라이센스 및 저작권 문제들을 이끌어 들인다 사용자는 도메인들 또는 컨테이너들 사이에서 뒤로 그리고 앞으로 여전히 토글해야만 하며, 이것은 사람들이 자신의 모바일 디바이스들을 사용하는 방식을 반영하지 않는다. 마지작으로, 도메인은 보통은 자신의 소유한 미리 정해진 사용자 인터페이스를 가지며, 이것은 사용자가 경험하는 원래의 OS와는 상이하며 그리고 디바이스 사용자에 의해 커스텀화될 수 없다.

도메인 격리로의 더 추가의 접근 방식은 보안 향상된 리눅스 (Security Enhanced Linux™ (SELinux™))와 같은 디바이스 운영 시스템 내 커널 레벨 플랫폼 보안 접근 방식이다. SELinux는 애플리케이션들 및 사용자들을 위한 파일들과 같은 객체들 및 자원들로의 강제적인 액세스 제어 (mandatory access control (MAC))를 제공한다. 각 사용자, 또는 애플리케이션은 보안 라벨을 할당받으며 그리고 모든 라벨들에 정책이 할당될 수 있다. 비록 안드로이드 (Android™)가 그런 방식으로 사용자 식별자들을 사용하지는 않지만, SELinux는 도메인 스위칭 메커니즘과 결합된 역할-기반 액세스 제어들을 위해 사용될 수 있다. SELinux는 보안 정책을 기반으로 하여 프로세스들 사이에서의 격리를 집행하기 위해 리눅스 내 리눅스 보안 모듈 (Linux Security Module (LSM))에 의존하는 특별한 커널 모듈을 사용한다. 애플리케이션들은 로딩 이전에 SELinux 정책에 반하여 검증될 수 있으며 그리고 모든 프로세스들은 미리 정해진 액세스로 제한될 수 있어서, 정책에 의해 허용되지 않는다면 한 애플리케이션은 다른 프로세스, 디렉토리들 또는 데이터에 액세스하거나 그것들을 시작시킬 수 없다. 권한 정책 매커니즘들을 이용하여, 애플리케이션들, 악성 소프트웨어들 그리고 심지어는 커널 루트 키트 (root kit)들은 애플리케이션들에 그리고 다른 사용자 또는 애플리케이션에 속한 데이터에 액세스하는 것이 방지될 수 있다.

원래의 OS 솔루션이 컨테이너들에 비해 그리고 가상화 접근 방식들에 비해 보안, 성능 및 애플리케이션 격리의 관점에서 많은 이점들을 가지지만, 그것은 미들웨어 레벨들에서 필요한 도메인 격리를 강제하는 것을 가능하게 하기에는 미들웨어 레벨로의 충분한 가시성 (visibility)을 가지지 않는다는 약점을 가진다.

더욱이, 도메인 격리로의 접근 방식으로서의 커널-레벨 플랫폼 보안은 다음의 한계들을 가진다. 그런 커널 모듈 접근 방식들은 어떤 사용자 인터페이스도 또는 도메인들의 개념도 가지지 않지만, 현존하는 전통적인 사용자 계정들을 보통은 사용하며, 이는 모든 도메인들에 걸친 권한들을 가지는 루트 또는 관리자 계정을 허용하는 것을 포함한다. 이 접근 방식에서 사용된 커널 모듈은 운영 시스템에서 매우 하위에 있으며 그리고 모바일 디바이스 상 격리된 도메인들을 조직이 사용하는 것 및 소비자의 요구사항들을 충족시키기 위해 필요한 유형의 정책 제어 (예를 들면, 도메인에 대한 사용자 인증 정책) 및 애플리케이션 제어 (예를 들면, 특정 도메인들에 대한 애플리케이션들 제한)를 제공하기 위한 미세한 (granular), 애플리케이션 특정 정보를 가지지 않는다. 확장된 SELinux 유형의 정책 언어 및 미들웨어로의 집행은 상기 솔루션의 복잡성을 크게 증가시킨다. 그런 정책들은 보통은 정적인 것이며 업데이트되지 않는다. SELinux를 위한 원격 정책 업데이트들을 제공하기 위한 프로젝트들이 존재하지만, 정책들은 전체 디바이스에 적용되며 각 도메인에 대해 유일한 것이 아니다. 예를 들면 안드로이드 상에서의 인터-프로세스 통신들 (Inter-Process Communications (IPC))은 모니터하기 힘들며, 이는 허가 체크들 그리고 호출자/피호출자 체크들이 안드로이드 미들웨어에서 수행되며 그리고 커널은 도메인들 사이의 IPC를 모니터하고 제어하기 위한 충분한 정보에 대한 액세스를 가지지 않기 때문이다. 마지막으로, 인터-도메인 데이터 공유를 한정하기 위한 사용자 및 애플리케이션 액세스에 대한 충분하게 미세한 제어가 존재하지 않으며, 이것은 데이터 누설의 문제들을 야기하며, 이것은 특정 유형의 데이터에 대해서는 수용될 수 없다. 이것이 몇몇의 공유 애플리케이션들 (예를 들면, 카메라 및 사진 갤러리)에 대해 수용 가능할 수 있을 것이지만, 커널 레벨 솔루션으로는 가능하지 않은 문서들 및 문서 리더기 솔루션들 (예를 들면, pdf 뷰어)을 위해 필요한 더 높은 정도의 미세함이 존재한다.

보안을 제공하기 위한 다른 전통적인 접근 방식은 암호 스택 파일시스템 (cryptographic stacked filesystem)과 같은 암호화된 파일시스템이다. 예를 들면, eCryptFS 파일시스템 (http://ecryptfs.org)은 리눅스용의 POSIX-호환 기업 암호 스택 파일 시스템이다. 암호화된 파일시스템들은 그러나 다중의 도메인들을 제공하기 위한 적합한 수단은 아니다.

그러므로 도메인 내 상주하는 애플리케이션들 및 데이터가 상기 도메인의 외부에 웹사이트 상에 또는 동일한 디바이스 상의 다른 도메인 내에 상주하는 애플리케이션들로부터 생길 수 있는 보안 위협으로부터 격리되는 곳인 모바일 디바이스들 상에 다중의 도메인들을 생성하며, 그리고 상기에서 설명된 전통적인 접근 방식들 각각의 하나 또는 그 이상의 불리함들을 완화시키며, 그런 전통적인 접근 방식들을 능가하는 유리함들을 제공하며, 또는 그런 전통적인 접근 방식들에 대한 대안을 제공하는 수단을 제공하는 것이 바람직하다.

본 발명의 효과는 본 명세서의 해당되는 부분들에 개별적으로 명시되어 있다.

본 발명 개시의 실시예들은 첨부된 도면들을 참조하여, 예시로서만 이제 설명될 것이다.
도 1a, 도 1b, 도 1c 및 도 1d는 운영 시스템 구조 및 도메인 격리를 위한 전통적인 방법들을 도시한 블록 도면들을 보여준다.
도 2는 격리된 도메인들을 제공하기 위한 특허적인 시스템을 도시한 블록 도면을 보여준다.
도 3은 다중의 사용자 계정들 및 다중의 도메인들의 구현을 도시한 개략적인 도면을 보여준다.
도 4는 제1 도메인으로부터 제2 도메인으로 스위칭하는 방법을 도시한 블록 도면을 보여준다.
도 5는 도메인 메시징 방법을 도시한 블록 도면을 보여준다.
도 6은 크로스 도메인 실행 방법을 도시한 블록 도면을 보여준다.
도 7은 도메인 애플리케이션 설치 방법을 도시한 블록 도면을 보여준다.
도 8은 업데이트 정책 방법을 도시한 블록 도면을 보여준다.
도 9는 현재의 도메인으로부터 다른 도메인으로 스위칭하는 방법을 도시한 블록 도면을 보여준다.
도 10은 현재의 도메인으로부터, 동작하지 않고 있으며, 암호화되어 있으며, 그리고 액세스를 위한 인증을 필요로 하는 타겟 도메인으로 스위칭하는 방법을 도시한 블록 도면을 보여준다.

여기에서 개시된 솔루션은 유연하며, 효율적이며, 그리고 안전한 격리된 도메인들 그리고 모바일 디바이스들을 위한 그런 도메인들의 관리를 제공하며 그리고 위에서 설명된 전통적인 접근 방식들 각각의 하나 또는 그 이상의 불리함들을 완화시키며, 그런 전통적인 접근 방식들을 능가하는 이점들을 제공하며, 또는 그런 전통적인 접근 방식들에 대한 대안을 제공한다.

다음의 팩터들은 전통적인 방법들의 상기 약점들을 극복하는 솔루션에 관련된다. 첫 번째로, 주로 모바일 전화 및 SMS (Short Message Service)를 위하여 주로 모바일 디바이스들을 사용하는 것으로부터 웹 브라우징, 소셜 네트워킹, 게임, 이메일, 인스턴트 메시징, 위치 기반 서비스들 및 모바일 커머스를 위해 모바일 디바이스들을 사용하는 것으로 근래에 이동이 있었다. 서비스 제공자들 및 WiFi를 경유하여 넓은 인터넷 접속성을 이용하여, 모바일 컴퓨팅은 항상 연결되어 있으며 그리고 진정하게 이동성이다. 추가로, 카메라, GPS, 가속도계, 기압계 등과 같은 센서들을 포함한 디바이스들의 능력들 및 애플리케이션들의 확산으로 인해, 모바일 디바이스의 더욱 다양한 사용들이 존재한다. 그것들은 엔터테인먼트, 소셜 네트워킹, 카메라/비디오 내비게이션, 개인적인 (예를 들면, 사진 공유) 또는 업무 (회사 CRM 시스템들) 또는 결합된 것 (예를 들면, 드롭 박스와 같은 파일 공유) 모두를 위해 클라우드 서비스들에 액세스에 IP 또는 전통적인 전화 네트워크들을 통한 텍스트, 채팅, 이메일 및 음성으로부터의 많은 모습의 메시징을 더한 것을 위해 사용된다. 또한, 그런 모바일 디바이스들 상에서의 늘어나는 전력, 접속성 및 애플리케이션들의 개수를 이용하여, 사용자들은 이 디바이스들에 더욱 민감한 정보를 점점 더 많이 저장하고 추적한다 (예를 들면, 개인적인 데이터, 크리덴셜들 (credentials), 암호 키들, 신용 카드 번호들, 패스워드, 연락처들, 과거 위치, 현재 위치, 웹 서핑 이력, 설치된 애플리케이션들 및 현재 디바이스 상태 (예를 들면, 이동하지 않음) 등). 이 민감한 정보는 종종 악의를 가진 사용자들 및 악성 소프트웨어 (malicious software (malware))의 타겟이다. 더욱이, 모바일 디바이스들이 사람에 의해 운반되므로, 그리고 그것들의 광대한 기능들로 인해서, 빠른 응답, 빠른 웹 검색 등을 위해 이 디바이스들에 빠르게 액세스하는 것이 가능하게 될 소망이 존재한다. 전통적인 디바이스 잠금 (lock)을 사용하는 것은 불편함을 만든다. 예를 들면, 사용자가 사전 내의 한 단어를 찾기 위해서 그 디바이스를 잠금 해제하기 위해 패스워드를 입력하는 것은 바람직하지 않을 것이다. 추가로, 모바일 디바이스들은, 예를 들면, 전화 호출을 하고, 식구들이 게임을 하도록 하고, 또는 디바이스 소유자가 운전하고 있을 때에 차량 내비게이션에서 일시적인 목적들을 위해 종종 공유된다 (또는 공유되기를 바란다). 이것은 하나의 디바이스 또는 서비스가 여러 사람들 사이에서 공유되지만, 사용자들이 미리 알려져 있으며 그리고 그런 공유된 사용이 진행하는 그리고 규칙적인 기반인 경향이 있는 전통적인 컴퓨팅 또는 서버 환경에서의 전통적인 사용자 계정들과는 매우 상이하다. 추가로, 모바일 디바이스들의 더 작은 폼 팩터 그리고 사용의 빈도 및 위치로 인해서, 모바일 디바이스들은 랩톱들이나 PC들보다 아주 더 자주 분실되거나 도난 당하며 그래서 공격자의 손에 떨어질 수 있을 것이다. 많은 사용자들 및 기업들은 분실되거나 도난 당한 모바일 디바이스를 원격으로 잠금하고, 위치를 확인하고 그리고/또는 "지우기 (wipe)" (그 디바이스로부터 모든 애플리케이션들 및 데이터를 삭제한다) 위한 수단을 필요로 하며, 이는 몇몇의 국가들에서 스마트폰 도난-방지 (anti-theft) 규정들을 포함한다 (http://www.ctia.org/policy-initiatives/voluntary-guidelines/smartphone-anti-theft-voluntary-commitment). 또한, 개인적인 사용 그리고 업무적인 사용 둘 모두를 위해 단일의 디바이스를 사용하는 것이 회사 환경에서의 종업원에게는 일반적이다. 이것은 공유의 다른 모습이며 - 그러나 하드웨어 및 네트워크 서비스들만의 공유임 - 이 경우 보안, 프라이버시 및 데이터 격리의 요구들은 더 높으며, 이는 회사는 작업 데이터의 살포를 소유하고 제어하기를 원하며 (예를 들면, 특히 종업원이 퇴사하는 경우에), 그리고 사용자는 자신이 고용주와 공유하기를 원하지 않는 비밀 데이터를 가질 수 있기 때문이다. 많은 경우들에, 동일한 애플리케이션들이 개인적인 사용 및 회사에서의 사용 둘 모두를 위해 사용될 수 있을 것이며 - 이것이 생산성을 향상시킬 수 있기 때문이다 -, 그러나 회사가 개인 데이터에 영향을 미치지 않으면서 데이터를 삭제 (지움)할 수 있도록, 또는 그 반대의 경우를 위해서 애플리케이션 데이터는 격리되어야만 한다. 더욱이, 디바이스 기능들, 민감한 정보, 고유 및 이중의 사용 때문에, 프라이버시 및 유연한 액세스 제어에 대한 필요성이 증가한다. 종종 통지들이 민감한 개인적인 정보 (채팅 메시지들, 소프트웨어 업그레이드들, 광고들)를 디스플레이하며, 이것은 디바이스 소유자들이 모든 사람들이 보거나 액세스하기를 항상 원하지 않는 것들이다. 사용자들은 자신의 디바이스를 빌려주기 위한 유연성을 원하지만, 읽기 전용, 수신 전화 통화 전용, 또는 특정 계정 (예를 들면, 페이스북 (Facebook))과 같은 특정 기능들 및/또는 서비스들로 액세스를 제한하기를 원한다. 많은 사용자들은 전부 아니면 아무것도 아닌 디바이스 잠금의 만족스럽지 않은 대안들 대 디바이스를 전혀 보호하지 않는 것 사이에서 선택하는 것에 마주친다. 마지막으로, 모바일 디바이스들은 원래 PC들보다 더 많은 네트워크들 (예를 들면, 레스토랑, 호텔 및 공항에서의 WiFi 네트워크들)에 접속하며, 이것은 이 디바이스들을 더욱 많은 네트워크 기반의 공격들, 침입들 및 패킷 포착에 노출시킨다. 추가로, 모바일 디바이스 사용자들은 악성 소프트웨어 (몰웨어)를 포함할 수 있을 애플리케이션들을 사용자들이 다운로드하는 것을 가능하게 하는 서드 파티 애플리케이션 상점들에 액세스한다. 예를 들면, 안드로이드 운영 시스템을 기반으로 하는 모바일 디바이스들은 이제 악성 소프트웨어 타겟 모바일 디바이스들 중 90%를 넘게 차지한다.

'도메인 (domain)'은 여기에서는 자원들의 세트 - 예를 들면, 데이터 파일들, 애플리케이션들, 그리고 서비스들 - 그리고 규칙 세트, 또는 '정책 (policy)' 사이의 관계를 나타내는 것으로 간주될 수 있으며, 그럼으로써 프로세스들에 의한 상기 자원들로의 액세스는 적어도 부분적으로 상기 정책에 의해서 제어된다. 예를 들면, 특별한 도메인은 그 도메인과 연관된 여러 데이터 파일들을 포함하거나 담고 있는 것으로 간주될 수 있으며, 그리고 그 데이터 파일들로의 액세스는 그 도메인과 연관되어 정의된 정책에 의해 적어도 부분적으로 제어된다. 유사하게, 애플리케이션은 설치될 수 있으며 또는 그렇지 않고 특별한 도메인과 연관될 수 있을 것이며, 그리고 그 애플리케이션을 실행시키는 능력을 포함하는 그 애플리케이션으로의 액세스는, 예를 들면, 그 도메인과 연관되어 정의된 정책에 의해 적어도 부분적으로 제어된다.

예를 들면, 선택된 애플리케이션들 및 다른 자원들에게로의 상이한 액세스를 제공하는 상이한 정책들을 구비한 다중의 도메인들을 단일-사용자 디바이스가 제공할 수 있는 것이 바람직하다. 한 경우에, 인증을 필요로 하며 아이들에게 액세스 가능하지 않도록 의도된 데이터 또는 애플리케이션들을 포함하는 제한된 도메인, 그리고 (예를 들면, 게임을 하기 위해서) 인증을 필요로 하지 않으며 아이들에게 액세스 가능한 것으로 의도된 아동 모드 도메인을 제공하는 것이 소망될 수 있다. 그러므로, 공개 도메인에서 동작할 때에, 상기 제한된 도메인의 데이터나 애플리케이션들이 그 공개 도메인과 연관된 프로세스들에게 액세스될 수 없도록 하는 것이 소망된다.

위에서 설명된, 도메인들의 바람직한 기능성 중 몇몇은 다중-사용자 운영 시스템들에서 일반적으로 구현된 전통적인 사용자 계정들에 의해 제공될 수 있다. 그런 사용자 계정들은 어떤 유형의 도메인을 구성하는 것으로 간주될 수 있으며, 이는 사용자 계정이 여러 가지 중에서도, 사용자의 자원들로의 액세스를 제어하는 그 사용자 계정과 연관된 자원들의 세트 (예를 들면, 사용자의 데이터 파일들, 애플리케이션들) 및 규칙 세트, 또는 정책을 나타내기 때문이다 (예를 들면, 허가들, 권한들).

그러나, 전통적인 사용자 계정들은 모바일 디바이스 상의 전통적인 그리고 통합되지 않은 단일-사용자 경험은 물론이며 상이한 도메인의 보안 격리의 이점 모두를 제공하기 위해서는 적당하지 않은 수단이다. 상기의 소망되는 기능성에 추가로, 소망된 경험을 제공하는 것은 두 도메인들 모두를 동시에 수반하는 행동들을, 예를 들면, 한 도메인으로부터 다른 도메인으로 복사하여 붙이기 (copy-and-paste)를 수행하기 위한 능력을 또한 필요로 하여, 다중의 도메인들의 자원들로의 동시 액세스를 제공하는 단일 사용자 인터페이스를 제공하며, 또는 제2 도메인과 연관된 이메일을 제1 도메인에서 동작하는 메일 클라이언트로부터 오픈하는 것을 제공한다. 전통적인 사용자 계정들은 운영 시스템 서비스들에 보통 통합된 사용자 격리 제어와 같은 그런 기능성을 가능하게 하도록 의도된 것이 아니며, 그리고 이는 상이한 사용자 계정들은 상이한 개인들에 의해 사용되도록 의도된 것이며, 상이한 도메인들의 자원들 및 프로세스들의 준비된 공유 및 협력을 허용하지 않으며, 또는 쉽게 가능하게 하지 않도록 한다는 가정으로부터 논리적으로 이어지며, 이는 상기 도메인들이 개인에 의해 동시에 사용되는 소망된 기능성을 가능하게 하기 위해서 필요하다.

위에서 설명된 것처럼, 가상화 및 컨테이너화와 같은 대안의 격리 메커니즘들이 사용자 계정들과 동일한 방식으로 제한될 수 있을 것이지만, 그것들은 위에서 설명된 상이한 불리함들을 경험한다. 그러므로, 격리된 도메인 관리를 운영 시스템의 통합된 모습으로서 제공하는 것이 소망된다. 그리고, 위에서 또한 설명되었지만, 몇몇의 소망된 기능성은 운영 시스템의 커널 내 상주하는 서비스들에 의해 제공될 수 있을 것이며, 현재의 운영 시스템 커널들은 다중 도메인들을 동시에 수반하는 행동들을 위해 필요한 공유 및 협력을 상기 프로세스에게 제공하기에 충분한 도메인 시그날링 및 도메인 관리를 가능하게 하지 않으며 또는 허용하지 않는다

그처럼, 상기 개시된 솔루션은 운영 시스템의 현존하는 서비스들이나 컴포넌트들에 대한 수정 또는 새로운 컴포넌트들이나 서비스들의 도입을 통해서 도메인 인식 (domain awareness)을 제공한다. 몇몇의 실시예들에서, 상기 컴포넌트들 및 서비스들 중 적어도 몇몇은 커널 외부의 운영 시스템 내에, 말하자면 (여기에서는 상기 커널 외부의 그리고 상기 커널과 사용자 애플리케이션들 사이의 운영 시스템을 의미하기 위해 사용된)미들웨어 내에 제공된다. 몇몇의 실시예들에서, 상기 컴포넌트들 및 서비스들 중 적어도 몇몇은 운영 시스템 커널 내에 제공된다. 몇몇의 실시예들에서, 도메인 생성 및 관리는 상기 운영 시스템 미들웨어의 수정된 또는 새로운 컴포넌트들 또는 서비스들에 의해 가능해지며, 그리고 도메인 집행은 운영 시스템 커널에 의해 수행되며, 그리고 수정된 또는 새로운 커널 모듈들, 또는 커널 수정들이 이 목적을 위해 제공된다.

그래서, 제1 실시예에서, 프로세서 그리고 안드로이드 운영 시스템을 구현하기 위해 상기 프로세서에 의해 실행 가능한 명령어들을 저장하는 메모리를 포함하는 모바일 디바이스에서, 개선점은: 상기 안드로이드 운영 시스템에서 구현된 사용자 계정들과는 상이한 복수의 도메인들을 선택적으로 생성하는 사용자 관리자; 상기 도메인들 중 하나의 도메인을 현재 도메인으로서 선택하는 도메인 관리자; 도메인과 연관된 파일들 및 애플리케이션들로의 액세스를 제어하는 규칙 세트를 포함하는 정책을 각 도메인에 대해 저장하고 집행하는 도메인 정책 서비스; 도메인의 정책 그리고 상기 현재 도메인의 정책을 기초로 하여, 도메인과 연관된 애플리케이션들의 설치 또는 실행을 각 도메인에 대해 선택적으로 허용하거나 차단하는 패키지 관리자; 상기 도메인들 중 상이한 것들과 연관된 동작 프로세스들 사이에, 상기 도메인들 중 상기 상이한 것들 각자의 정책을 기초로 하여, 통신을 제공하는 도메인 메시지 서비스; 그리고 상기 현재 도메인을 선택적으로 스위치하기 위한 활동성 (activity) 관리자를 포함하며, 여기에서 상기 사용자 관리자, 도메인 관리자, 도메인 정책 서비스, 패키지 관리자, 도메인 메시지 서비스, 및 활동성 관리자는 상기 안드로이드 운영 시스템의 커널 외부에서 상기 안드로이드 운영 시스템 내에 구현된다. 상기 개선점은 : 도메인과 연관된 정책을 각 도메인에 대해 집행하기 위한 도메인 커널 모듈을 더 포함하며, 상기 도메인 커널 모듈은 상기 안드로이드 운영 시스템의 커널에서 구현된다.

제2 실시예에서, 컴퓨팅 디바이스의 운영 시스템에서 복수의 보안 도메인들을 제공하기 위해 상기 컴퓨팅 디바이스의 프로세서에 의해 실행되는 방법은: (a) 각 보안 도메인에 대해: (a1) 상기 보안 도메인의 자원들을 유일 도메인 식별자와 연관시키는 단계로서, 상기 자원들은 적어도 하나의 데이터 파일 또는 적어도 하나의 애플리케이션을 포함하는, 연관 단계; 및 (a2) 상기 유일 도메인 식별자와 연관하여 정책을 저장하는 단계로, 상기 정책은 상기 자원들로의 액세스를 제어하기 위한 규칙 세트를 포함하는, 저장 단계; (b) 상기 복수의 보안 도메인들 중 하나의 보안 도메인을 선택한 것을 현재 도메인으로서 수신하는 단계로, 상기 복수의 보안 도메인들은 상기 현재 도메인과는 상이한 타겟 도메인을 포함하는, 수신 단계; 그리고 (c) 상기 현재 도메인과 연관된 정책 그리고/또는 상기 타겟 도메인과 연관된 정책을 기초로 하여 상기 타겟 도메인 자원들로의 액세스를 제어하는 단계를 포함한다.

제3 실시예에서, 컴퓨팅 디바이스의 운영 시스템에서 복수의 보안 도메인들을 제공하기 위한 방법은: (a) 각 보안 도메인에 대해: (a1) 상기 보안 도메인의 자원들을 상기 보안 도메인과 연관된 유일 도메인 식별자와 연관시키는 단계로서, 상기 자원들은 적어도 하나의 데이터 파일 또는 적어도 하나의 애플리케이션을 포함하는, 연관 단계; 및 (a2) 상기 유일 도메인 식별자와 연관하여 정책을 저장하는 단계로, 상기 정책은 상기 자원들로의 액세스를 제어하기 위한 규칙 세트를 포함하는, 저장 단계; (b) 상기 보안 도메인들 중 제1 보안 도메인과 연관된 시작 프로세스 (originating process)와 연관된 이벤트 메시지를 생성하는 단계; (c) 상기 보안 도메인들 중 제2 보안 도메인과 연관된 타겟 프로세스가 상기 이벤트 메시지에 응답하도록 구성된 것을 판별하는 단계; (d) 상기 이벤트 메시지를 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 프로세싱하여, 프로세싱된 이벤트 메시지를 생산하는 단계; 그리고 (e) 상기 프로세싱된 이벤트 메시지를 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 상기 타겟 프로세스로 통과시키거나 차단하는 단계를 포함한다.

제4 실시예에서, 컴퓨팅 디바이스의 운영 시스템에서 복수의 보안 도메인들을 제공하기 위한 방법은: (a) 각 보안 도메인에 대해: (a1) 상기 보안 도메인의 자원들을 상기 보안 도메인의 유일 도메인 식별자와 연관시키는 단계로서, 상기 자원들은 적어도 하나의 데이터 파일 또는 적어도 하나의 애플리케이션을 포함하는, 연관 단계; 및 (a2) 상기 유일 도메인 식별자와 연관하여 정책을 저장하는 단계로, 상기 정책은 상기 자원들로의 액세스를 제어하기 위한 규칙 세트를 포함하는, 저장 단계; (b) 상기 보안 도메인들 중 제1 보안 도메인과 연관된 시작 프로세스로부터, 상기 보안 도메인들 중 제2 보안 도메인과 연관된 타겟 프로세스를 시작시키라는 요청을 수신하는 단계; 그리고 (c) 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 상기 요청을 프로세싱하는 단계를 포함한다.

제5 실시예에서, 프로세서 그리고 커널 및 그 커널 외부의 미들웨어를 포함하는 운영 시스템을 저장하기 위한 저장 메커니즘을 포함하는 데이터 프로세싱 시스템에서의 방법은: 도메인들을 생성하기 위해 상기 미들웨어에 제1 설비 (facility)를 제공하고 그리고 상기 도메인들로의 액세스를 제어하기 위한 대응 정책들을 상기 도메인들과 연관시키는 단계; 상기 도메인들 사이에서 스위칭하기 위해 상기 미들웨어 내 제2 설비를 제공하는 단계; 그리고 상기 도메인들의 상기 대응 정책들을 집행하기 위해 상기 미들웨어 내 적어도 부분적으로 제3 설비를 제공하는 단계를 포함한다.

제6 실시예에서, 컴퓨터 디바이스는 프로세서 및 메모리를 포함하며, 상기 메모리는 복수의 보안 도메인들을 제공하는 운영 시스템을 구현하기 위해 상기 프로세서에 의해 실행 가능한 명령어들을 저장하며, 상기 운영 시스템은: 상기 복수의 보안 도메인들을 선택적으로 생성하며, 그리고 상기 보안 도메인들 중 하나의 보안 도메인을 현재 도메인으로서 선택하는 도메인 관리자; 도메인과 연관된 파일들 및 애플리케이션들로의 액세스를 제어하는 규칙 세트를 포함하는 정책을 각 보안 도메인에 대해 저장하고 집행하는 도메인 정책 서비스; 상기 도메인과 연관된 애플리케이션들의 설치를 각 보안 도메인에 대해 집행하는 패키지 관리자; 상기 보안 도메인들 중 상이한 것들과 연관된 동작 프로세스들 사이에 통신을 제공하는 도메인 메시지 서비스; 그리고 상기 현재 도메인을 선택적으로 스위치하기 위한 활동성 관리자를 포함한다.

격리된 도메인들을 제공하기 위한 예시적인 시스템 (100)이 도 2를 참조하여 이제 설명된다.

상기 시스템은 스마트폰, 태블릿, 랩톱, 또는 데스크탑이나 휘발성 메모리 및 프로세서를 구비한 어떤 다른 전자 디바이스로, 그 휘발성 메모리는 운영 시스템 및 소프트웨어 애플리케이션들 (또는 "애플리케이션들" 또는 "apps")를 제공하기 위해 상기 프로세서에 의해 실행 가능한 컴퓨터 코드를 포함하는 전자 디바이스와 같은 모바일 디바이스를 포함하는 컴퓨팅 디바이스에서 구현될 수 있다. 상기 컴퓨팅 디바이스는 인터페이스를 더 포함할 수 있으며, 이는 키보드, 포인팅 디바이스, 터치스크린과 같은 사용자 입력 디바이스를 포함할 수 있으며 그리고 라디오 및 유선 또는 무선의 통신 네트워크를 통해 통신하기 위한 연관된 제어 회로와 같은 통신 인터페이스를 더 포함할 수 있으며, 이 통신 네트워크는 인터넷 및/또는 셀룰러 또는 WiFi 링크 또는 블루투스, 또는 근거리 무선 통신 (near field communication (NFC))일 수 있다.

상기 운영 시스템은 커널 및 미들웨어를 포함하는 특징이 있으며, 이 커널은 상기 디바이스의 프로세서 및 다른 하드웨어 컴포넌트들로부터 소프트웨어 애플리케이션으로의 입력/출력 (I/O) 서비스들을 관리하고 제공하며, 상기 미들웨어는 상기 커널에 의해 제공되는 서비스들에 추가적인 서비스들을 제공한다.

일반적으로, 본 솔루션은 도메인 인식 (domain awareness)을 가능하게 하기 위해 운영-시스템-레벨 프로콜들을 수정하는 것을 포함한다. 복수의 도메인들이 모바일 디바이스 상에서 생성된다. 이하에서 설명되는 실시예들에서, 운영 시스템은 안드로이드 (Android™)이며, 그런 선택은 본 발명의 범위를 제한하는 것으로 해석되지 않아야 한다. 안드로이드는 단지 예로서 사용되며 그리고 다른 다중-사용자 운영 시스템들 (예를 들면, QNX, 윈도우즈)과 유사하다.

그래서, 도 2에서 보이는 것처럼, 상기 시스템 (100)은 커널을 포함하며, 상기 시스템 (100)이 안드로이드 (Android™) 운영 시스템을 동작시키는 모바일 디바이스에서 구현될 때에 이 커널은 리눅스 (Linux™) 커널 (110)이다. 상기 커널은 다음을 포함한다: 보안 데이터 저장 (112), 도메인 커널 모듈 (116), 그리고 리눅스 보안 모듈 (114). 일 실시예에서 이 리눅스 보안 모듈은 향상된 리눅스 보안 모듈 (Enhanced Linux Security Module)이며, 이들 각자의 기능들은 아래에서 더 설명될 것이다. 본 발명이 속한 기술 분야에서의 통상의 지식을 가진 자는 상기 커널 (110)은 추가의 전통적인 컴포넌트들 (예를 들면, 드라이버들) 또는 전술한 것과는 상이한 다른 컴포넌트들을 더 포함할 수 있을 것이라는 것을 이해할 것이다.

상기 시스템 (100)은 운영 시스템 미들웨어 (120)를 더 포함하며, 이 미들웨어는 도메인 메시지 서비스 (122), 도메인 관리자 (124), 도메인 정책 서비스 (126), 사용자 관리자 (128), 시스템 세팅 모듈 (130), 키 가드 중재자 (Key Guard Mediator) (132), 활동성 관리자 (134), 패키지 관리자 (136), 그리고 윈도우 관리자 (138)를 포함한다. 상기 사용자 관리자 (128), 시스템 세팅 모듈 (130), 키 가드 중재자 (Key Guard Mediator) (132), 활동성 관리자 (134), 패키지 관리자 (136), 그리고 윈도우 관리자 (138)는 안드로이드의 알려진 컴포넌트들이나 서비스들의 각자의 기능성들에 대응하며 그리고 그런 기능성들을 소유하지만, 아래에서 설명되는 것처럼 도메인-인식이도록 수정된다. 상기 도메인 메시지 서비스 (122), 도메인 관리자 (124), 그리고 도메인 정책 서비스 (126)는 추가적인 컴포넌트들이며, 그 기능성들은 아래에서 설명된다.

상기 시스템 (100)은 하나 또는 그 이상의 도메인들을 구현하기 위한 애플리케이션 공간 (140) (또는 사용자 공간)을 더 포함한다. 예시의 목적들을 위해서, 제1 도메인 (142-1) 및 제2 도메인 (142-2)이 도시되지만, 어떤 개수의 도메인들도 구현될 수 있을 것이라는 것이 이해될 것이다. 각 도메인은 도메인 세팅 모듈 (144-1, 144-2)의 제1 및 제2 예시화들과 같은 도메인 세팅 모듈의 예시화 (instantiation)를 포함할 수 있으며, 그리고 일반적으로 도메인 내비게이터 모듈 (146-1, 146-2) 및 도메인 관리 애플리케이션 (148-1, 148-2)의 제1 및 제2 예시화들을 포함할 것이다. 각 도메인은 제1 애플리케이션 (150-1, 150-2)의 분리된 예시화들을 또한 구비하며, 상기 제1 도메인 (142-1)은 제2 도메인 (142-2)에서 예시화된 제3 애플리케이션 (154)과는 상이한 제2 애플리케이션 (152)을 예시화할 수 있다.

도메인들

제1 도메인 (142-1) 및 제2 도메인 (142-2)과 같은 도메인은 애플리케이션들 및 그 애플리케이션들과 연관된 데이터를 분리하여 유지하는 격리된 영역이다. 도메인들은 그 특별한 도메인을 위한 애플리케이션들, 데이터, 설정, 접속성 및 보안 정책을 원격으로 (예를 들면, 회사 정보 기술 (IT) 관리자에 의해) 또는 로컬로 (예를 들면, 디바이스 소유자에 의해) 제어될 수 있다. 예를 들면, 특별한 도메인으로의 네트워크 액세스는 제어될 수 있다. 패스워드 재-인증 시간은 제어될 수 있다 (예를 들면, 그래서 사용자는 특정 기간 내에 도메인들을 스위칭할 때에 재-인증할 필요가 없다). 상기 도메인의 관리자는 보통은 그런 제어를 구비한다. 상기 관리자는 개인적인 사용자일 수 있으며, 또는 회사 IT 관리자 또는 다른 원격 엔티티일 수 있다.

그것들의 격리 및 분리된 속성으로 인해서, 여기에서 설명된 도메인들은 보호받는 도메인들인 것으로 간주될 수 있다. 예를 들면, 상기 디바이스가 다른 도메인에서 디바이스 소유자에 의해 다운로드된 악성 소프트웨어에 의해 위태롭게 된다면 또는 디바이스가 분실되거나 도난당하는 경우에 정보와 독점의 사업 애플리케이션들 위태롭게 될 것을 원하지 않는 회사에 의해 한 도메인이 외부에서 관리될 수 있을 것이다. 디바이스 소유자는 회사가 자신의 선호드들, 웹 서핑 습관들 또는 개인적인 통신들을 추적할 것을 원하지 않으며, 그래서 그 소유자는 자기 자신의 보호받는 도메인을 또한 원한다. 그러나, 상기 디바이스 소유자는 상기 디바이스 상의 모든 애플리케이션들 및 서비스들에 동일한 레벨의 인증이 적용될 것을 원하지 않지만, 보호 도메인들 내 데이터가 여전히 안전하다는 것을 확신할 수 있다.

다중 도메인들을 제공하는 것은 전통적인 "전부 아니면 아무것도 아닌 (all-or-nothing)" 디바이스 액세스 제어에 대한 대안을 디바이스 소유자에게 제공한다. 보안 도메인 및 개방 도메인 둘 모두를 지원하기 위한 능력을 이용하여, 변하는 로그아웃 시간들 및 액세스 제어 (예를 들면, PIN, 패스워드, 얼굴 인식, 또는 아무것도 아님)를 구비하여, 액세스는 사용자에 의해 필요한대로 설정될 수 있다. 디바이스 소유자에게 원격 관리자들과 관계없는 선택을 또한 부여하면서도, 이 유연성은 불편함으로 인해 상기 디바이스 상에서 어떤 패스워드도 사용하지 않을 가능성을 줄어들게 한다.

단지 예로서, 도 3은 개략적인 도면 (300)을 보여주며, 이 경우 상기 시스템 (100)을 구현한 디바이스 (305)는 사용자 A (310) 및 사용자 B (315)의 두 사용자들로 구성되며, 이 경우 세 개의 도메인들 A1 (320), A2 (325), A3 (330)이 사용자 A와 연관하여 생성되며, 그리고 두 개의 도메인들 B1 (335), B2 (340)이 사용자 B와 연관하여 생성된다. 보이는 것처럼, 도메인 A1의 정책은 선택된 이메일 계정 (345)으로의 액세스를 허용할 수 있으며, 반면에 도메인 A2의 정책은 G메일 (Gmail™) 계정으로의 그리고 페이스북 (Facebook™) (350)으로의 액세스를 허용할 수 있다.

간략함을 위해서, 상기 시스템 (100)을 구현한 디바이스는 단 하나의 사용자만으로 또한 구성될 수 있지만, 여기에서 설명된 다중의 도메인들이 생성될 수 있을 것이며 그리고 상기 방법들 및 프로토콜들은 그런 다중의 도메인들과 연결하여 여기에서 또한 구현된다.

도메인 인식 ( Domain Awareness)

도메인 인식은 유닉스 (Unix™) 및 리눅스 (Linux™) 운영 시스템들에서 구현된 사용자 식별자 (user identifier (UID)) 및 그룹 식별자 (group identifier (GID)) 개념들을 기초로 하여 제공될 수 있다. 상기 UID 및 GID는 유닉스 및 리눅스에서 프로세스들 및 파일들에 허가들을 할당하기 위해 사용된다. 수퍼유저, 또는 루트 (root)는 보통은 UID 0이 할당되며, 그리고 다른 범위들은 시스템 프로세스들을 위해 종종 보류된다.

그러나, 안드로이드에서, 상기 UID는 사용자들을 나타내기 위해 사용되지 않는다; 대신에, 각 애플리케이션에는 그 애플리케이션이 설치될 때에 유일한 UID 및 GID가 할당되며, 그리고 애플리케이션 식별자로 간주될 수 있을 이 (UID, GID) 쌍은 그 애플리케이션과 연관된 프로세스들 및 데이터 파일들에 할당된다. 안드로이드의 최근 버전 (안드로이드 4.2)에서, 다중-사용자 기능들이 도입되었으며, 이는 어느 사용자 계정이 액티브인가를 표시하기 위해 운영 시스템 전체에 걸쳐서 시그날링을 추가했다. UID 내 특정 비트들은 사용자 계정을 표현하기 위해서 예약되며, 그래서 사용자 식별자를 구성한다. 프로세스가 시작될 때에, 이 사용자 식별자는 설치 시에 그 애플리케이션에 할당된 애플리케이션 식별자와 결합되어 실행 콘텍스트 (execution context) 식별자를 생성하여, 동작하는 프로세스에 연관된 비밀 데이터 파일들 및 그 동작하는 프로세스의 콘텍스트를 표시한다. 이 시그날링을 이용하여, 사용자를 기초로 하여 애플리케이션 데이터가 생성되어 독립적으로 저장될 수 있다.

이전의 버전들과 비교하면, 안드로이드 4.2의 서비스들은 사용자 계정을 인식하도록 수정되었다. 예를 들면, 그리고 도 2를 참조하면, 안드로이드 패키지 관리자 (136)는 각 사용자를 위해 어느 애플리케이션이 이용 가능한가를 제어하기 위해 수정되었다. 유사하게, 상기 윈도우 관리자 (138)는 각 사용자를 위해 무엇이 디스플레이 되는가를 제어하기 위해 수정되었다; 그리고 상기 활동성 관리자 (134)는 애플리케이션들의 시작 및 각 사용자를 위한 허가들의 집행을 제어하기 위해 수정되었다. 추가로, 사용자 관리자 (128)로 불리는 새로운 서비스가 안드로이드 4.2에 추가되었으며 그리고 사용자들 사이에서의 생성, 인증, 삭제 및 스위칭을 처리한다.

본 솔루션의 일 실시예에서, 도메인-인식 시그날링 메커니즘이 상기 운영 시스템에 추가되며, 이는 안드로이드 4.2에 추가되었던 다중-사용자 기능들과 유사하며, 현존하는 서비스들은 도메인 인식이 되기 위해 수정되었다. 특히, 도메인 시그날링이 UID에 대한 확장에 의해, 또는 새로운 필드의 추가로서 추가되며, 이는 도메인 식별자 또는 "DID (domain identifier)"를 구성한다. 상기 UID 내 미리 정해진 비트들은 도메인을 표시하기 위해 예약되며, 그리고 설치 시에 애플리케이션에게 할당된 애플리케이션 식별자와 함께 결합되어 실행 콘텍스트 식별자를 생성하며, 이는 동작 프로세스 및 그 도메인에 관한 연관된 비밀 데이터 파일들의 콘텍스트를 표시한다. 일 실시예에서, 패키지 관리자 (136)는 각 설치된 애플리케이션의 애플리케이션 식별자와 각 도메인 사이의 연관들의 목록을 유지하기 위해 구성된다. 상기 실행 콘텍스트 식별자는 그러면 애플리케이션의 애플리케이션 식별자 그리고 그 애플리케이션이 실행되는 도메인의 도메인 식별자를 기초로 하는 프로세스에 대해 생성된다. 일 실시예에서, 상기 UID는 특별한 사용자 계정과 연관된 보류된 비트들을 또한 가진다. 또한 도메인을 표시하기 위해 상기 UID 필드를 보류하거나 확장하는 그런 접근 방식은 운영 시스템이 변하는 정도를 줄어들게 하며, 구현을 쉽게 하며, 그리고 배치하기 위한 시간을 줄어들게 한다.

일 실시예에서, 도메인 관리자 (124)로 불리는 새로운 서비스가 구현되어 도메인들의 생성, 인증, 및 삭제를 관리하며, 이는 아래에서 설명된다.

시스템 도메인-인식을 만들기 위한 대안의 방법은 SELinux가 상이한 자원들 및 객체들을 어떻게 식별하는가와 같은 보안 라벨들을 사용하는 것이다. 몇몇의 실시예들에서, 그런 목적들을 위해 SELinux 보안 라벨들이 사용된다. 다른 실시예들에서는 도메인들을 식별하는 다른 라벨 또는 파라미터가 추가된다.

도메인 생성 (Domain Creation)

일 실시예에서, 사용자 관리자 (128) 기능성은

새로운 사용자를 추가하고 그리고 도메인을 또한 추가하는 것 둘 모두를 가능하게 하기 위해 수정되며, 이것은 단일 사용자를 위한 서브-계정과 유사한 것으로 간주될 수 있을 것이다. 그렇게 하는 것은 다중의 도메인들이 각 사용자 계정과 연관되는 것을 가능하게 하다. 상기 사용자 관리자 (128) 기능성을 수정하는 것은 특정한 유리함들을 제공한다. 예를 들면, (예를 들면, 도 3에서 보이는 것처럼) 다중의 사용자들을 구비하는 것을 구현함에 있어서, 도메인 생성이 사용자 관리자 (128) 내 사용자 생성과 통합되는 것이 유리하다. (예를 들면, 다중 사용자 계정들을 지원하지 않는 스마트폰 상에) 단일 사용자만을 구비한 대안의 실시예에서, 그런 기능성은 도메인 관리자 (124)에서 구현될 수 있을 것이다.

그래서, 일 실시예에서, 상기 사용자 관리자 (128)는 다음의 것들 중 하나 또는 그 이상을 제공하기 위해 수정된다: (i) 전형적인 로그인 스크린으로 촉구하지 않으면서 단일 사용자 하에서 도메인들 상에서 쉬운 스위칭을 허용하기 위해; (ii) 도메인을 위한 정책에서 규정된 시간 기간 동안 다른 도메인으로 스위칭할 때에 그 도메인 또는 도메인들에 로그인 상태로 남아 있기 위해; 그리고 도메인들 사이에서의 빠른 스위칭을 용이하게 하기 위해 도메인들을 액티브로 유지하기 위해서. 추가적인 도메인 시그날링을 이용하여, 상기 사용자 관리자 (128)는 하나보다 많은 사용자 계정이 존재할 때에만 사용자 이름을 묻도록 구성될 수 있을 것이다.

새로운 도메인을 생성하는 경우에, 사용자 관리자 (128)는 상기 도메인 관리자 서비스 (124)를 호출할 수 있다. 새로운 도메인을 생성하는 것은 새로운 사용자를 생성하는 것과 유사할 수 있으며, 새로운 사용자 환영 스크린들이 스킵되는 것처럼 차이점들은 적용된 도메인들에 특정된 것이다. 도메인 생성 동안에, 상기 패키지 관리자 (136)는 미리-존재하는 애플리케이션들을 설치하거나 또는 새로운 도메인으로 새 애플리케이션들을 다운로드하기 위해 자동적으로 호출될 수 있을 것이다. 도메인 정책 서비스 (126)는 디폴트 정책을 세팅할 수 있을 것이며 그리고 사용자가 새로운 도메인을 위한 정책을 원하는 대로 가다듬는 것을 돕기 위해 마법사 프로그램들이 실행될 수 있을 것이다.

작업 (work) 도메인 (또는 도메인의 정책이 디바이스 소유자에 의해서 아니라 엔티티에 의해 적어도 부분적으로 외부에서-제어되는 그런 어떤 다른 도메인)을 생성하는 이벤트에서, 그 도메인은 그 특별한 작업 도메인을 위한 원격 도메인 관리 서버에 등록될 수 있다. 이것은 그 사용자의 작업 크리덴셜들을 이용한 등록을 필요로 할 수 있을 것이다. 상기 서버는 그런 작업 도메인의 생성을 승인할 것이며 그리고 그 후에 상기 사용자 그룹, 상기 디바이스 그리고 상기 작업 도메인을 위해 특정된 정책, 아이콘들, 크리덴셜들, 파일들, 월페이퍼 및 애플리케이션들을 다운로드할 것이다.

도메인 정책들

도메인을 생성하면, 정책 명세서 또는 정책 데이터를 포함하는 각자의 보안 정책이 그 도메인과 연관하여 저장된다. 몇몇의 실시예들에서, 적어도 몇몇의 도메인-특정 및 크로스-도메인 정책이 애플리케이션 레벨 및/또는 미들웨어 레벨에서 강제된다 (예를 들면, 인증 타임-아웃). 몇몇의 실시예들에서, 각 도메인과 연관된 엔티티들 및 프로세스들의 격리는 커널 레벨에서 그리고 복수의 도메인들을 위한 각자의 보안 정책들에 따라서 적어도 부분적으로 강제된다. 몇몇의 실시예들에서, 미들웨어 레벨에서 적어도 부분적으로 격리가 강제되며, 그것은 운영 시스템 서비스들에 의한 것이며 그리고 커널의 외부에서의 동작을 용이하게 한다. 각 도메인과 연관된 각자의 정책들은 그 도메인의 의도된 역할 또는 회사 기업 서비스와 같은 다른 엔티티들과의 상기 도메인의 관계 또는 연관에 종속하여 상이할 수 있을 것이다.

예를 들면, 상이한 실시예들에서, 하나 또는 그 이상의 정책들은 다음과 같을 수 있다: (i) 미리-정해지며 정적 (static)임; (ii) 미리-정해지지만, 몇몇의 런-타인 구성 및 선택을 구비한다; (iii) 관리 서버 상에서의 설정 이후에 다운로드된다; 또는 (iv) 디바이스 상에서 사용자 설정 가능하다. 각자의 정책들의 상기 특정 파라미터들은 연관된 도메인의 역할 그리고 다른 엔티티들과의 관계에 다시 관련한 어떤 적절한 상태들 또는 변수들을 고려할 수 있다. 예를 들면, 상이한 정책들은 다음과 같은 특징이 있을 수 있다: (i) 특정 OS 서비스들 사이의 격리는 정적이며 미리-정해진 것일 수 있다; (ii) 부울 값들을 기초로 하여 세팅될 수 있는 미리 정해진 낮은/중간/높은 보안 레벨들이 제공될 수 있다; (iii) GPS 가상 울타리 (geo-fencing) 파라미터들, 또는 애플리케이션 화이트리스트가 다운로드될 수 있다; 또는 (iv) 개인 도메인들에 대한 디버그 액세스를 위한 능력은 디바이스 상에서 로컬로 설정될 수 있다. 어떤 조합도 또한 구현될 수 있다.

몇몇의 경우들에, 정책은 (예를 들면, 도메인 세팅 앱 (144-1, 144-2)을 경유하여) 디바이스 상에서 수정될 수 있으며, 그리고 다른 경우들에서는 정책은 (예를 들면, 작업 도메인을 위해) 원격 서버로부터 다운로드될 수 있다. 일 실시예에서, 상기 도메인 메시지 서비스 (122)는 다운로드, 검증, 인증 그리고 정책들의 업데이트를 관리하며, 그리고 상기 도메인 정책 서비스 (126)는 각 도메인에 대한 정책들의 적용을 관리한다. 상기 정책은 그러면 그 정책을 적용하는 시스템 컴포넌트에게 분배될 수 있으며, 그 정책은 이것은 애플리케이션 레벨, 미들웨어 레벨 또는 커널 레벨일 수 있다.

애플리케이션 관리

위에서 설명된 도메인 시그날링을 제공하는 것은 도메인-특정 설치 그리고 상이한 도메인들에 걸친 애플리케이션들의 관리를 가능하게 한다. 일반적으로, 상기 패키지 관리자 (136)는 현재 도메인이나 선택된 도메인의 DID 또는 그런 도메인과 연관된 정책을 기초로 하여 프로그램들의 설치 또는 실행을 허가하거나 또는 금지하도록 구성될 수 있다.

상이한 도메인들에 걸친 애플리케이션들의 도메인-특정 설치 및 관리는 특정 유리함들을 가능하게 한다. 예를 들면, 도메인 시그날링은 도메인들에 걸쳐 상이한 애플리케이션 버전들의 설치 및 관리를 가능하게 한다. 애플리케이션이 한 사용자에 의해 업데이트될 때에, 그것은 모든 사용자들을 위해 또한 업데이트된다는 것이 안드로이드의 현재의 경우이다. 그런 결과는 항상 바람직한 것은 아니다. 예를 들면, 애플리케이션으로의 업데이트는 추가적인 허가들을 요청할 수 있으며 또는 기업에 의해서 테스트되거나 지원되지 않은 특징들을 포함할 수 있으며 그래서 작업 도메인에서는 소망되지 않을 것이다. 추가로, 회사는 화이트-리스트 애플리케이션들만을 허용하는 연관된 작업 도메인을 원할 수 있을 것이며, 또는 특정 애플리케이션에는 블랙-리스트를 원할 수 있다

심지어 도메인들이 특별한 개인에 의해서만 액세스될 때에도, 상이한 도메인들에서 상이한 애플리케이션 액세스 및 제어를 제공하는 것은 향상된 보안 옵션들을 또한 제공한다. 예를 들면, 안드로이드 디바이스 소유자는 일반적으로 제한되지 않은 개방 도메인에서 구글 플레이 (Google™ Play™) 스토어 계정을 셋업하는 것을 좋아하지 않을 수 있다; 디바이스가 도난 당했다면, 상기 계정은 개방 도메인에서는 이용 가능할 것이며, 그리고 그 도둑질은 그 디바이스의 소유자의 계정을 이용한 도둑에 의해 디바이스 소유자에게 비용이 발생하는 결과를 가져올 수 있다. 그래서, 디바이스 소유자는 상기 플레이 스토어 애플리케이션이 개방 도메인에서는 가능하지 않으며, 그러나 대신에, 예를 들면, 개방 도메인에서는 적용하기에 바람직하지 않게 불편한 것으로 간주될 수 있을 액세스 패스워드를 일반적으로 필요로 하는 더욱 제한된 보안 정책을 구비한 다른 도메인에서만 가능하기를 원할 수 있을 것이다.

따라서, 상기 솔루션은 상기 안드로이드 패키지 관리자 (136)에 대한 하나 또는 그 이상의 수정들을 포함할 수 있으며, 이는 그것이 도메인 인식하도록 만들며, 그래서 애플리케이션들이 도메인 정책에 따라서 설치되고 업데이트될 수 있도록 한다. 일 실시예에서, 상기 패키지 관리자 (136)는 각 설치된 애플리케이션의 애플리케이션 식별자 그리고 각 도메인의 도메인 식별자 사이에서 애플리케이션의 목록을 유지하게 하기 위해 설정된다. 프로세스가 시작될 때에, 상기 프로세스를 위해 생성된 실행 콘텍스트 식별자는 상기 애플리케이션의 애플리케이션 식별자 그리고 상기 애플리케이션이 실행되는 도메인의 도메인 식별자를 기초로 한다. 이 방식에서, 상기 패키지 관리자 (136)는 다음과 같이 설정될 수 있다: (i) 애플리케이션 화이트-리스트들 및/또는 블랙 리스트들의 구현을 선택된 도메인들에서 허용하며, 그래서 오직 승인된 애플리케이션들만이 그 도메인에 설치될 수 있도록 한다; (ii) 애플리케이션이 한 도메인으로부터 다른 도메인으로 복사되거나 이동되는 것을 가능하게 한다; (iii) 애플리케이션을 다운로드할 때에, 어느 도메인에 계정 크리덴셜들이 상주하는가에 관계없이 애플리케이션이 어느 도메인이나 도메인들에 설치되어야 하는가를 사용자에게 알려준다; (iv) 새 도메인을 셋업할 때에, 현존하는 애플리케이션, 그리고 그것의 설정 및 데이터가 새로운 도메인으로 복사되거나 이동되는 것을 가능하게 한다; (v) 애플리케이션 업데이트들이 다운로드될 때에, 상이한 도메인들 내에 애플리케이션의 다중의 상이한 버전들이 가능하게 하기 위해 애플리케이션 화이트-리스트들 또는 블랙-리스트들에 관한 소프트웨어 버전들을 고려한다 (그래서, 예를 들면, 테스트되고 승인된 애플리케이션 버전들의 설치 및 업데이트의 기업들에 의한 선택적인 제어를 가능하게 하며, 그럼으로써 하이퍼바이저 솔루션들과 유사한 정도의 애플리케이션 버전 제어를 제공한다); 그리고 (vi) 사용자 입력에 기초하여, 또는 그 정책에 관련된 도메인에 관한 다운로드된 정책을 기초로 하여, 한 도메인 또는 다중의 도메인들로부터 애플리케이션이 선택적으로 삭제되는 것을 가능하게 하며, 아마도 다른 것들은 그렇지 않다.

윈도우 관리

일 실시예에서, 상기 윈도우 관리자 (138)에 대한 디폴트 설정은 상이한 도메인들에 대한 상이한 스크린들을 제공하는 것이며, 종래 기술과 유사하다. 도메인들은 통지 셰이드 (notification shade), 내비게이터 애플리케이션 (예를 들면, 도메인 내비게이터 (146-1, 146-2)를 이용하여, 또는 버튼, 아이콘들, 제스처들 또는 이것들의 어떤 조합 등을 통해서 스위치될 수 있다.

상기 솔루션은 상기 윈도우 관리자 (138)가, 상이한 도메인들에 연관된 애플리케이션들이 단일의 스크린 상에 디스플레이되는 곳인 혼합된 UI를 구비한 더욱 혁신적인 사용자 인터페이스를 제공하는 것을 또한 가능하게 한다. 예를 들면, 일 실시예에서, 상기 윈도우 관리자 (138)는 하나 또는 그 이상의 애플리케이션 아이콘들에게 오버레이를 제공하며, 이는 상기 애플리케이션이 어느 도메인에 연관된 것인가를 표시한다. 하나보다 많은 도메인에 연관된 애플리케이션은 다중의 아이콘들을 제공할 수 있으며, 각 아이콘은 상이한 오버레이를 구비하여 (예를 들면, 상이한 색상, 상이한 심볼, 상이한 외곽선 등) 그 애플리케이션이 어느 도메인과 연관된 것인지를 표시한다. 그런 접근 방식은 도메인들 사이에서 스위치해야 할 필요성을 없앨 것이며, 이 경우 도메인 액세스는 그 아이콘에 의해 지시되며, 그리고 사용자는 현재 도메인과 상이한 도메인과 연관된 애플리케이션에 액세스할 때에는, 상기 액세스된 애플리케이션의 도메인 정책에 의해 요청된 대로 인증할 것을 요청받을 수 있을 것이다. 도메인마다의 정책들 및 데이터 격리는 디스플레이 메커니즘과는 독립적으로 유지되고 집행된다. 상기 솔루션의 성능은 다중의 아이콘들을 구비함에 의해 영향을 받지 않는다. 이 접근 방식의 유리함은 도메인들 사이에 어떤 눈에 보이는 스위칭도 존재하지 않는다는 것이다. 상기 디바이스 홈 스크린의 불리함은 아이콘들로 인해 혼란케 될 수 있으며 그리고 사용자가 내부에서 동작하고 있는 도메인의 시각적인 표시가 더 적게 있다는 것이다.

크로스-도메인 통신 (Cross-Domain Communication)

상기 시스템 (100)은 다른 기능들 중에서도 데이터 컷팅 및 붙이기 (cutting and pasting), 전화 호출 시작, 통지, 데이터 공유, 데이터 전달 및 애플리케이션 설치를 위한 것과 같은 크로스-도메인 통신들을 관리하기 위해 도메인 관리자 서비스 (124)를 포함할 수 있다. 상기 도메인 정책 서비스 (126)는 도메인들 사이에서 정책을 집행하기 위한 단일 포인트로서 행동할 수 있다.

예를 들면, 사용자는 도메인들 사이에서 애플리케이션을 이동시키거나 복사하기를 원할 수 있을 것이다. 작업 도메인 정책은 회사 정보 (예를 들며, 작업 연락처들 또는 작업 문서들)를 훔치기 위해 상기 작업 도메인에 악성 소프트웨어가 들어올 수 없다는 것을 확실하게 하기 위해 애플리케이션 화이트리스트 접근 방식을 구현할 수 있다. 추가의 예로서, 대응하는 보호받는 도메인 내부인 때를 제외하면, 한 도메인에서의 통지는 다른 도메인에서 디스플레이될 때에는 분명하지 않게, 또는 전혀 디스플레이되지 않게 만들어질 수 있다. 다른 예로서, 데이터 누설을 방지하기 위해 작업 도메인을 떠날 때에는 그 작업 도메인은 연락처들과 같은 데이터를 제한할 수 있다. 사용자가 자신의 개인적인 연락처들을 작업 도메인 내로 가져오는 것은 받아들일 수 있을 것이지만, 그 반대는 작업 도메인 정책에 의해 허용되지 않을 수 있다. 이것은 상기 도메인 정책 서비스 (126)에 의해 관리될 것인 정책에 의해 설정된 도메인들 사이의 단-방향 데이터 공유의 예이다.

외부 통신 (External Communication)

상기 시스템 (100)은 상기 디바이스 내에서 인-바운드 (in-bound) 그리고 아웃-바운드 (out-bound) 통신을 또한 관리할 수 있다. 이 목적들을 위해서, 일 실시예에서 상기 도메인 관리자 서비스 (124)는 네트워크 접속들 그리고 통지들을 필요로 할 수 있는 또는 다중의 도메인들로 의도할 수 있는 인-바운드 이벤트들을 관리한다. 간단한 예는 듀얼 번호 (예를 들면, 듀얼 SIM 카드) 스마트폰의 경우이며, 여기에서 한 번호로의 호들은 특정 도메인으로 라우팅되어야 하며 그리고 두 번째 번호로의 호들은 상이한 도메인에 등록되어야 한다고 정책이 규정할 수 있을 것이다. 그런 통신은 단일 전화 번호 디바이스가 인-바운드 전화 호출을 수신하는 경우에 아주 더 복잡하다. 정책은 어느 연락처들이 호출자-id 목적들을 위해서 액세스될 수 있는가 그리고 어느 곳에 상기 호출 로그 정보가 등록되어야 하는가를 지시할 수 있다. 몇몇의 실시예들에서, 상기 도메인 정책 서비스 (126)는 VPN, 블루투스 및 WiFi 네트워크 자원들과 같은 하드웨어 자원들로의 액세스를 포함하는 적어도 몇몇의 정책 집행을 위한 포인트일 수 있다. 예를 들면, 몇몇의 보호받는 도메인들의 정책은 특정된 네트워크들 상에 있을 때에만 통신들을 허용할 수 있을 것이다.

도메인 집행 (Domain Enforcement)

상기 시스템 (100)은 도메인들의 그리고 도메인 정책마다의 집행을 또한 제공하며, 이는 도메인들을 생성하고 관리하는 소프트웨어 기능성에 대한 추가의 요구사항이다. 도메인 정책 그리고 도메인들의 집행이 없었다면, 악성 소프트웨어 또는 루트키트들 (rootkits)은 시스템 또는 커널 코드를 정적으로 또는 동적으로 수정하여 정책이 집행될 것을 방해하거나 또는 정책을 업데이트하는 것을 방해할 수 있었을 것이다.

일 실시예에서, 상기 시스템 (100)은 강제적인 액세스 제어 (mandatory access control (MAC))를 구현하기 위해 SELinux™ 및 Linux™ 보안 모듈 (LSM)을 사용한다. MAC은 주체들 (예를 들면, 애플리케이션들)이 정책에 의해 허가된 객체들 (예를 들면, 애플리케이션, 파일들 및 자원들)에만 액세스하는 것을 보장한다. 이것은 각 애플리케이션이 설치될 때에 유일하게 생성되는 UID/GID 조합을 통해서 강제된다. 위에서 설명된 것처럼, 상기 시스템 (100)의 일 실시예에서, 상기 UID는 도메인들을 표시하기 위해 또한 확장되거나 또는 할당된다.

그러나, SELinux™는 동일한 유형 (그리고 정책)을 모든 사용자 다운로드 애플리케이션들에 적용하며, 이것은 그것이 집행 도메인들이 아니라는 것을 의미한다. 그래서, SELinux는 도메인 인식이 되기 위해 또한 수정될 수 있다. 일 실시예에서, 이것은 정책 내 역할-기반의 액세스 제어 필드들을 통해 수행되며, 또는 상이한 도메인들에 대해 상이한 정책들을 생성하고 그리고 런-타임 동안에 정책을 조절하기 위해 상기 도메인 관리자 (124)를 동적으로 사용함으로써 수행되며, 또는 Android™의 경우에 도메인 인식이 되기 위해 SEAndroid™의 미들웨어 강제적인 액세스 제어 특징들 및/또는 자고우트 (Zygote)를 수정함으로써 프로세스들이 생성될 때에 도메인 특정 SELinux™ 보안 라벨들을 그 프로세스들에 할당함으로써 수행된다.

시스템 레벨 자원들로의 밀하게 (tightly) 제한하는 애플리케이션 액세스는 커널 레벨에서 구현될 수 있는 여러 보안 향상들 중 하나일 뿐이다. 상기 도메인 커널 모듈 (114)은 다른 도메인 인식 보안을 수행할 수 있으며, 이는 다음과 같다: 제어 디버그 액세스, 정책들로의 체크 업데이트들 (인증 및 무결성 검증), 도메인 데이터 암호화, 체크 로드 타임 애플리케이션 서명들, 액세스 안전 하드웨어 및 안전 운영 시스템 컴포넌트들 (가능한 경우) 그리고 네트워크, 카메라 및 GPS와 같은 하드웨어 자원들로의 제어 액세스. 상기 도메인 커널 모듈 (114)은 디바이스 전체적인 보안 세팅들을 또한 제공하며, 다음과 같다: 부트 시 커널의 무결성 검증, 정책들의 안전한 저장, 자체적인 그리고 다른 시스템 레벨 자원들 (예를 들면, 도메인 정책 엔진)의 무결성 검증, SEAndroid™가 턴 온 (turn on)된 것을 보장함, 그리고 원격 증명 (remote attestation).

도메인들은 사용자 계정 및 관리자 계정과 동일하지 않다는 것에 유의해야 한다. 디바이스 소유자가 계정들을 생성하고 삭제하기 위한 특정 권한들을 허가했던 특별한 계정을 가질 수 있지만, 그런 권한들은 루트 액세스와 등가인 것은 아니며 그리고 서드 파티 관리자 (예를 들면, 작업 IT 관리자)에 의해 관리된 도메인들에 대해서는 제한될 수 있다는 것에 유의해야 한다. SELinux™ 및 SEAndroid™를 사용함으로써, 여기에서 설명된 것과 같은 정밀한 도메인 시그날링과 함께, 심지어는 도메인들 사이에 상이한 정책들 및 액세스 제어들이 존재하는 때에도 애플리케이션들 및 애플리케이션 데이터는 격리된 채로 남아 있게 된다. 한 도메인에서의 악성 소프트웨어는 다른 도메인 내의 데이터 또는 애플리케이션에 액세스할 수 없다.

도메인 스위칭

제1 도메인 (142-1)으로부터 제2 도메인 (142-2)으로의 도메인 스위칭 방법의 일 실시예를 도시한 블록 도면 (400)이 도 4에 보인다. 사용자는 제2 도메인으로의 스위치를 요청하는 입력을 도메인 내비게이터 (146-1)를 이용하여 넣는다. 도메인 내비게이터 (146-1)는 활동성 관리자 (134)에게 시그날링하여 (행동 405) 제2 도메인 (142-2)으로 스위치하도록 한다. 제2 도메인 (142-2)이 제1 도메인 (142-1)과 연관된 사용자와 상이한 사용자와 연관되었다면, (예를 들면, 도 3에서 도메인 A1으로부터 도메인 B1으로), 그러면 활동성 관리자 (134)는 사용자 관리자 서비스 (128)에게 시그날링하여 (행동 410) 그 사용자를 로그 아웃시키도록 하며, 그러나 만약 상이한 사용자와 연관되지 않았다면 그렇게 하지 않는다. 사용자 관리자 서비스 (128)로부터의 호 (행동 412)에 응답하여, 도메인 관리자 서비스 (124)는 시스템 세팅 모듈 (130)과 함께 상기 제2 도메인 (142-2)와 연관된 로그인 정책을 체크하며 (행동 415), 또한 도메인 정책 서비스 (126)와 함께 그런 스위칭이 발생하는 것을 가능하게 하기 위해 어떤 다른 정책들을 체크한다 (예를 들면, GPS 가상-울타리, 네트워크 액세스 요구사항들, 커널 무결성) (행동 420). 상기 활동성 관리자 (134)는 상기 키 가드 중재자 (132)에게 상기 제1 도메인 (142-1)의 타임-아웃을 통지한다 (이것은 즉시일 수 있으며 또는 미리 정해진 기간만큼 지연할 수 있다) (행동 425). 상기 키 가드 중재자 (132)는 상기 제2 도메인 (142-2)과 연관된 정책을 구현한다. 상기 정책 체크가 충족된다면, 그러면 상기 키 가드 중재자 (132)는 제2 도메인 (142-2)으로 스위치할 것을 통지 받으며 그리고 상기 정책을 기초로 하여 액세스를, 예를 들면, 액세스에 대한 필요한 인증 (행동 430)을 결정하며, 또는 (예를 들어, 어떤 인증도 요청되지 않는다면) 도메인에 직접적으로 액세스하며 (행동 435), 또는 대안으로 스위치를 거절할 수 있을 것이다. 그 스위치에 이어서, 상기 활동성 관리자 (134)는 제2 도메인 (142-2)에서 애플리케이션 런처 (424)를 실행한다.

다른 실시예에서, 위에서 언급된 것처럼, 도메인 스위치는 애플리케이션을 선택하고 그리고 상기 도메인 내비게이터가 필요하지 않을 때를 암시할 수 있다.

몇몇의 실시예들에서, 도메인 스위칭 방법은 암호화된 도메인으로의 안전한 스위칭을 가능하게 하도록 구성될 수 있다. 하나 또는 그 이상의 도메인들과 연관된 데이터 파일들은 암호 스택 파일시스템을 이용하는 것처럼 암호화될 수 있을 것이다. 예를 들면, eCryptFS 파일시스템 (http://ecryptfs.org)은 리눅스용의 POSIX-호환 기업 암호 스택 파일시스템이다. 도메인과 연관된 데이터 파일들이 그렇게 암호화되는 경우에, 도메인은 암호화된 도메인으로 간주될 수 있을 것이다. 암호화된 도메인의 데이터를 암호화하고 해독하기 위해 대칭적 키들이 사용될 수 있으며, 그리고 리눅스 커널 키링 (keyring) 내에 저장될 수 있을 것이며 (커널 메모리 내 안전한 저장), 그러나 어떤 안전한 저장소에 또한 저장될 수 있을 것이다. 비록 몇몇의 실시예들에서는 단일 키가 사용될 수 있다고 이해되지만 암호 스택 파일시스템에서, 다중의 대칭적인 키가 사용되는 것은 전형적이다.

위에서 설명된 것처럼, 다중의 도메인들을 구비한 디바이스는 액세스를 위해 인증을 필요로 하는 하나 또는 그 이상의 도메인들을 포함할 수 있을 것이다. 예를 들면, 디바이스 운영 시스템이 안드로이드인 경우에, 빌트-인 안드로이드 잠금 화면 (lock screen) 인증 (패턴, 핀, 패스워드 등)이 도메인으로의 액세스를 제어하기 위해 사용될 수 있다. 그 도메인이 또한 암호화되었다면, 이 잠금 화면 인증은 암호화된 도메인의 데이터에 액세스하기 위해 상기 암호 파일시스템에 의해 사용된 키들을 암호화하고 해독하기 위해 또한 사용될 수 있을 것이다.

디바이스가 다중의 도메인들을 가지고 있을 수 있기 때문에, 하나 또는 그 이상의 도메인들이 암호화될 수 있을 것이며, 그리고 하나 또는 그 이상의 도메인들이 인증을 필요로 할 수 있을 것이며, 현재의 도메인 (사용자 인터페이스 (UI) 초점을 현재 소유하는 도메인)으로부터 상이한 타겟 도메인으로 스위칭할 때에 네 가지의 가능한 시나리오들이 존재한다: 도메인은 동작하고 있지 않다; 도메인은 동작하고 있지 않으며, 암호화되지 않았다; 도메인은 동작하고 있지 않으며, 암호화되었지만, 인증을 필요로 하지 않는다; 그리고 도메인은 동작하고 있지 않으며, 암호화되었으며, 그리고 인증을 필요로 한다 (도메인과 연관된 프로세스들이 동작하고 있다면 그 도메인은 동작하고 있는 것으로 간주된다).

이런 가능성을 비추어 보면, 현재 도메인으로부터 타겟 도메인으로의 스위칭 방법 (900)이 도 9에 도시된다. 도시된 것처럼, 동작하고 있는 도메인은 즉시 스위치될 수 있다. 타겟 도메인으로 스위치하기 위한 입력을 수신하면 (시작 902) 그 도메인이 동작하고 있는가 (결정 904)의 여부가 판별되며 그리고, 동작하고 있다면 (분기 906) 상기 타겟 도메인이 UI 내에 보이며 (단계 908) 그리고 스위치는 종래된다 (종료 910). 그 도메인이 동작하고 있지 않다면 (분기 912), 그러면 그 도메인이 암호화되었는가의 여부가 판별된다 (결정 914); 암호화되어 있지 않다면 (분기 916) 그 도메인은 시작된다 (단계 918), UI 내에 보이며 (단계 908), 그리고 스위치는 완료한다 (종료 910). 상기 도메인이 암호화되었다면 (분기 920), 그러면 그 도메인이 인증을 필요로 하는가의 여부가 판별된다 (결정 922); 인증을 필요로 하지 않는다면 (분기 924), 그러면 해독 키들이 로드될 수 있으며 파일시스템이 마운트되며 (단계 926), 상기 도메인은 시작되며 (단계 918), UI 내에 보이며 (단계 908), 그리고 스위치가 완료한다 (종료 910). 인증이 요청된다면 (분기 928), 그러면 인증 정보가 수신되며 (단계 930), 상기 파일시스템 키들은 그 인증 정보를 기초로 하여 해독되며 (단계 932), 그 해독된 키들은 로드되고 파일 시스템은 마운트되며 (단계 926), 도메인은 시작되며 (단계 918), UI에서 보이며 (단계 908), 그리고 그 스위치는 완료한다 (종료 910).

그래서, 도 9에서 볼 수 있는 것처럼, 현재 동작하고 있지 않은 암호화되지 않은 도메인이 시작될 수 있으며 그리고 즉시 스위치된다. 그러나, 암호화된 도메인으로 스위치하기 위한 시도가 만들어진다면, 상기 암호 파일시스템 키들은 상기 도메인이 사용될 수 있기 이전에 리눅스 커널 키링으로 로드되어야만 한다. 암호화된 도메인이 인증을 필요로 하지 않는다면, 상기 암호 파일시스템 키들은 로드될 수 있으며, 그리고 상기 파일시스템은 사용자 개입 없이 마운트된다. 그러나, 상기 암호화된 도메인이 인증을 요청한다면, 상기 암호 파일 시스템 키들 그 자체는 로드될 수 있기 이전에 먼저 해독되어야만 하며, 그리고 그 파일시스템은 마운트된다. 그래서, 인증을 요청하는 암호화된 도메인을 시작시키는 마지막 경우에, 그 도메인의 데이터가 액세스될 수 있기 (마운트됨) 이전에 상기 타겟 도메인을 위한 인증 데이터를 수집하기 위한 메커니즘이 요청된다.

그러나, 많은 디바이스 운영 시스템들에서, 인증 프로세스는 현재 도메인 내에서 또는 현재 도메인과 연관하여 동작할 수 있다. 예를 들면, 안드로이드에 구축된 현존하는 잠금 화면 인증 메커니즘은 현재 사용자 또는 도메인을 인증한다. 타겟 도메인으로 스위칭할 때에, 락스크린 위젯들, 라이브 월페이퍼들, 및 입력 방법 에디터들 (Input Method Editors (IMEs))과 같은 안드로이드 잠금 화면은 그 잠금 화면으로부터의 타겟 도메인을 위한 프로세스들을 동작시킨다. 전통적인 안드로이드 사용자 경험을 보존하기 위해서, 상기 인증은 도메인 스위치 이후에 발생할 필요가 있다.

이런 기능성을 제공하는 여러 대안의 방법들이 존재하며, 다음과 같다.

첫 번째 대안에서, 커스텀 사용자 인터페이스 (UI)가 제공되어 타겟 도메인으로 스위칭하기 이전에 인증 정보를 획득한다. 이 방법이 몇몇의 환경들에서는 그것을 적절하게 만들 수 있을 여러 이점들을 소유하지만, 다음과 같은 특정 불리함들을 또한 경험한다. 예를 들면, 이 방법은 이미 안드로이드에 구축된 인증 메커니즘을 효과적으로 복제하기 위한 노력을 필요로 하며, 그리고 구축된 안드로이드 메커니즘들로의 업데이트들과의 공통 조작성을 유지하기 위해 업데이트하는 것을 필요로 할 것이다. 더욱이, 이 방법은 보안의 염려를 이끌어들이며, 이는 사용자가 스위칭하여 나온 도메인에서 커스텀 인증 UI 프로세스들이 동작하고 있을 것이기 때문이다, 정교한 공격자는 신뢰받는 암호화된 도메인을 위한 도메인 인증 정보를 포착하기 위해서, 잠재적으로 신뢰받지 않는 도메인 내 입력 방법 에디터들 (IMEs)과 같은 중요한 애플리케이션 패키지들을 바꿀 수 있다.

두 번째 대안에서, 한 방법이 타겟 도메인으로 우선 스위치하지만, 그 타겟 도메인의 데이터를 마운트하지 않는다. 상기 방법은 그러면 타겟 도메인의 데이터를 마운트하기 이전에, 잠금 화면이 기능하기에 필요한 그런 프로세스들만을 동작시키며, 그리고 그 후 스위치를 타겟 도메인으로 완료한다. 이 방법이 몇몇의 환경들에서는 그것을 적절하게 만들 수 있을 여러 이점들을 소유하지만, 다음과 같은 특정 불리함들을 또한 경험한다. 예를 들어, 잠금 화면 (락스크린 위젯들, 라이브 월페이퍼들, 및 입력 방법 에디터들 (MEs))으로부터 보통 동작하는 애플리케이션 컴포넌트들은 암호화된 파일시스템으로의 액세스를 요청할 수 있다. 어느 패키지가 동작하고 있을 것인가를 선험적으로 판별하는 것은 일반적으로 가능하지 않으며, 이는 사용자 및 원 장비 제조자 (original equipment manufacturer (OEM)) 둘 모두가 이 컴포넌트들을 변경하고, 업그레이드하고, 또는 제거하는 것이 가능하기 때문이며, 그래서 이 문제점들은 예상될 수 없으며 그리고 보상될 수 없다. 더욱이, 도메인 스위치 동작은 도메인 인증 정보가 제공될 때까지는 완료되지 않는다. 이것은 상기 디바이스를 안드로이드가 처리하도록 설계되지 않은 중간적인, 비-정의된 상태로 남겨둔다. 이것은 안드로이드의 배포들 사이에서 올바르게 처리되고, 테스트되고, 그리고 유지되어야만 하는 안드로이드 미들웨어 전체에 걸쳐서 많은 추가적인 에지 케이스들 (edge cases)을 생성한다.

세 번째 대안에서, 인증 정보의 안전한 수집을 용이하게 하고 그리고 도메인들 사이에서의 안전한 이동을 가능하게 하기 위해 상기 대안의 방법은 디바이스 상에서 의도적으로 생성된 중간 도메인으로 스위치한다. 동작하고 있지 않으며 인증을 요청하는 암호화된 도메인으로 스위칭할 때에 이 중간 도메인은 시작된다. 이 방법은 위에서 설명된 처음의 두 대안들에 의해 가지는 불리한 점들의 많은 부분을 극복한다.

그래서, 첫 번째의 동작하는 도메인으로부터 상이한 타겟 도메인으로 스위칭하는 방법 (1000)으로, 상기 타겟 도메인은 암호화된 도메인이며 (암호화된 파일시스템 내에 포함된 데이터 파일들을 구비하거나 또는 그 데이터 파일들과 연관된다) 그리고 동작하고 있지 않으며, 상기 방법은 도 10에서 보인다. 도메인 스위치는 타겟 도메인으로 개시된다 (시작 1002). 상기 타겟 도메인은 동작하고 있지 않으며, 암호화되어 있으며, 그리고 인증을 요청한다. (안드로이드 미들웨어로 보고된 것처럼) 상기 중간 도메인은 현재 도메인이 되었으며 (단계 1004), 그리고 잠금 화면 프로세스가 그 중간 노드에서 시작된다 (단계 1006). 잠금 화면 컴포넌트는 수정되거나 또는 그렇지 않다면 제공되어, 불러내질 때에 타겟 도메인을 위한 인증 챌린지 (authentication challenge)를 보여줄 것이며, 그리고 상기 타겟 도메인을 식별하는 몇몇의 표시를 보여줄 것이다.

상기 타겟 도메인과 연관된 몇몇의 UI 요소들이 상기 암호화된 파일시스템에 저장되지 않지만, 대신에 다른 위치 (예를 들면, 암호화되지 않은 파일이나 데이터베이스 내 메타데이터)에 저장된다면, 그런 UI 요소들은 상기 인증 챌린지와 함께 보일 수 있다. 예를 들면, 상기 타겟 도메인과 연관된 월페이퍼가 이 경우에 보일 수 있다. 대안으로, 몇몇의 다른 월페이퍼 또는 영상이, 타겟 도메인으로의 스위치가 발생하고 있다는 것을 표시하기 위해 보일 수 있다. 유사하게, 상기 타겟 도메인과 연관된 IME가 상기 암호화된 파일시스템 외에 저장된다면, 그러면 그것은 인증 정보를 수신하기 위해 사용될 수 있을 것이다. 대안으로, 인증 정보를 집어넣기 위해 IME에 대한 사용자 선택이 수신될 수 있다 (단계 1008) (이것은, 예를 들면, 상기 중간 도메인 내의 언어가 상기 타겟 도메인의 언어와는 상이한 경우를 포함할 수 있다).

상기 인증 정보는 그러면 상기 선택된 IME를 이용하여 수신된다 (단계 1010). 사용자가 타겟 도메인을 위한 올바른 인증 정보를 제공한다면, 그 타겟 도메인을 위한 암호 파일 시스템 키들은 해독되며 (단계 1012), 그 키들은 로드되며, 그리고 상기 파일시스템은 마운트된다 (단계 1014). 보통은 타겟 도메인에 디스플레이될 상기 잠금 화면이 무시된다 (단계 1016) (이것은 사용자가 상기 도메인에서 직접 인증했다면, 그리고 암호화되지 않은 도메인들을 위해 잠금 화면 인증이 어떻게 동작하는지에 대한 이음 없는 (seemless) 사용자 경험을 제공한다는 것과 전혀 다르지 않다). 상기 타겟 도메인은 시작되어 현재 도메인이 된다 (단계 1018). 그 새로운 도메인은 UI 내에서 보이며 (단계 1020), 그리고 상기 도메인 스위치가 완료된다 (종료 1022).

언급된 것처럼, 이 방법은 동작하고 있지 않은 암호화된 도메인으로의 스위칭하는 다른 방법들의 불리함들 중 적어도 일부를 극복하며, 그리고 다음과 같은 여러 이점들을 더 제공한다.

예를 들면, 인증 프로세스가 어떤 사용자 제어 가능한 도메인 외부에서 발생하여, 인증 정보를 수집하는 것을 더욱 안전하게 만드는 것이 유리한 점이다. 잠금 화면으로부터 동작하는 프로세스들은 다른 사용자 액세스 가능 도메인들 내 변화들로부터의 간섭에 덜 걸리는 제어된 환경에서 동작한다. 안드로이드 미들웨어에서 요청된 상기 변화들은 유지하기에 더 쉬우며, 그리고 안드로이드 내로 구축된 다중-사용자 상태 머신과 더욱 쉽게 호환된다. 이것은 더 작은 결함, 더 적은 유지보수, 그리고 더 양호한 상위 호환성 (forward compatibility)으로 안내한다. IME 상으로의 공격들 (예를 들면, 교체 또는 권한 상승), 또는 키 가드를 위한 사용자 인터페이스는 수행하기 더 어려우며 그리고 위에서 개설된 다른 옵션들에 비해 이득들 (예를 들면, 중간 노드로의 액세스)을 최소화할 것이다. 필요한 추가적인 성능 및 저장은 최소이다.

여러 구현 옵션들이 이용 가능하다. 상기 중간 도메인은 운영 시스템의 첫 번째 부트 시에 생성되며, 또는 대안으로 제1 암호화 도메인이 생성되기 이전의 어느 다른 때에 생성될 수 있을 것이다. 상기 중간 도메인은 잠겨져서 사용자가 인증 외에는 어느 것도 할 수 없도록 할 수 있다. '잠겨진다 (locked down)'의 표현은 필요하지 않은 어떤 애플리케이션, 서비스들, 또는 다른 모습들은 기능을 억지하고, 또는 필요한 특별한 애플리케이션들, 서비스들, 또는 다른 모습들만은 대신에 선택적으로 활성화시키는 것을 의미하는 것으로 이해될 수 있다. 예를 들면, 그것은 잠금 화면 위젯들 및 구글 검색을 무력화시키는 것을 포함할 수 있다. 상기 중간 도메인은 보안 위험을 더 최소화하기 위해 정책 메커니즘들 (SELinux 및 SEAndroid를 포함한다)을 사용하여 더 잠겨질 수 있을 것이다. 다른 도메인들과 다르게, 상기 중간 도메인은 도메인들 사이에서 스위칭할 때에 간략하게만 동작할 뿐이다. 동작할 때에, 그것은 안드로이드에 의해 유지되는 세 개의 액티브 동작 도메인들의 최대 한계에 대항하여 동작하는 도메인으로서 카운트되지 않는다. 그래서, 상기 중간 도메인으로 이동하는 것은 다른 도메인들이 중단되도록 하는 원인이 되지 않는다. 상기 중간 도메인을 시작시키고 중단시킬 때에, 안드로이드는 도메인을 시작시킬 때에 통상적으로 송신되는 많은 브로드캐스트들을 송신하지 않는다. 이것은 중대한 성능 향상을 가져오며, 이는 그것이 불필요한 프로세스들 및 애플리케이션들이 시작되는 것을 막기 때문이다. 이 애플리케이션들이 존재할 수 있는 보안 위험들을 줄이기 위해 상기 중간 도메인은 화이트-리스트, 불능-리스트들, 블랙리스트들 등을 사용하여 도메인에 설치된 최소의 애플리케이션들을 가질 수 있다.

상기 중간 도메인은 허가된 애플리케이션들, 서비스들 등의 특정 선택을 이용하여 미리 구성될 수 있으며, 또는 모든 도메인들에 의해 사용되는 것과 동일한 또는 유사한 집행 메커니즘들을 사용하며, 예를 들면, 그 중간 도메인에 특정된 정책을 이용함으로써 다른 도메인들과 유사한 방식으로 동적으로 공급받을 수 있다.

도메인 메시지 서비스 프로토콜

도메인 메시징 방법을 도시하는 블록 도면 (500)이 도 5에 보인다. 제1 도메인 (142-1)과 연관된 제1 프로세스 (505)는 이벤트 메시지 (예를 들면, 메시지 수신 통지 (이 경우 메시지는 이메일일 수 있다), 잘라 붙이기 (cut-and-paste) 행동, 파일 복사)를 생성할 수 있다. 상기 이벤트를 생성하는 이 제1 프로세스 (505)는 상기 이벤트에 관한 메시지를 송신하고 (이것은 브로드캐스트의 모습을 가진다) 그리고 상기 도메인 관리자 서비스 (124)에 의해 수신된다 (행동 510). 일 실시예에서, 제2 도메인 (142-2)에서 동작하는 제2 프로세스 (515)는 리스닝 (listening) 프로세스일 수 있지만, 대안으로 API가 사용될 수 있다는 것이 이해될 것이다. 상기 도메인 메시지 서비스 (122)는 제2 도메인 (142-2) 내 제2 프로세스 (515)처럼, 다른 도메인에서 리스닝 프로세스들이 상기 수신된 이벤트 메시지에 응답하도록 구성되는가를 체크한다.

제2 도메인 (142-2) 내 상기 제2 프로세스 (515)가 그렇게 구성되었다고 판별하면, 상기 도메인 관리자 서비스 (124)는 상기 도메인 정책 서비스 (126)에게 상기 이벤트 메시지 유형 (예를 들면, 통지, 클립보드 버퍼, 파일)에 관하여 시그날링한다 (행동 520). 상기 도메인 정책 서비스 (126)는 관련된 정책을 구현하며, 이것은 여러 상이한 행동들의 결과가 될 수 있을 것이다. 예를 들어, 상기 요청된 이벤트가 허용되거나 (예를 들면, 100개 캐릭터들보다 적은 버퍼는 통과될 수 있다), 또는 허용되지 않을 수 있다 (예를 들어, 정책은 파일이 도메인으로 전달되도록 허용할 수 있지만, 상기 도메인으로부터의 그런 파일 전달은 방해한다). 대안으로, 상기 정책은 메시지가 필터링되는 결과를 가져올 수 있다 (예를 들면, 특정 필드들은 분명하지 않게 만들어질 수 있으며, 또는 발송자, 주제 등과 같은 상세한 내용들 없이 이메일의 수신의 통지처럼 제공된 단지 표지만의 통지). 상기 정책에 따라서, 상기 이벤트 메시지는 상기 제2 도메인 (142-2) 내 제2 프로세스 (515)로 통과된다 (행동 525).

크로스 도메인 실행 프로토콜

크로스 도메인 실행 방법을 예시한 블록 도면 (600)이 도 6에 보인다.

상기 방법에서, 제1 도메인 (142-1) 내 제1 프로세스 (605)는 행동을 생성하며, 이 경우에 상기 행동은 몇몇의 행동이 제2 도메인 (142-2)과 관련하여 수행될 것을 요청한다. 예를 들면, 새로운 이메일의 통지는 제1 도메인에서 선택될 수 있을 것이며, 그리고 요청은 제2 도메인에서 그 메일을 보기 위해 입력된다. 대안으로, 제1 도메인 (142-1)에서 상기 도메인 세팅들 (144-1) 서비스를 이용하여, 제2 도메인 (142-2)을 삭제하라는 요청이 입력될 수 있을 것이다. 또는, 제1 도메인 (142-1)에서 동작하면서, 제2 도메인 (142-2)으로부터 특정 전화 번호로의 전화 호출을 수행하기 위한 요청이 입력될 수 있을 것이다.

제1 도메인 (142-1)에서 제1 프로세스 (505)에 의한 행동의 생성에 이어서, 상기 활동성 관리자 (134)는 상기 제1 프로세스 (505)로부터 도메인 스위치 요청을 수신한다 (행동 610). 그 스위치를 위해 인증이 필요하다면, 그러면 인증이 실패한 경우 상기 요청은 거절된다. 상기 활동성 관리자 (134)는 상기 제1 도메인 (142-1) 및 제2 도메인 (142-2)과 연관된 각자의 정책들을 체크하기 위해 상기 도메인 정책 서비스 (126)에게 시그날링하며 (행동 615), 이는 상기 요청하는 제1 도메인 (142-1)이 상기 요청된 행동을 상기 제2 도메인 (142-2)과 함께 개시할 것을 양 정책들이 허용한다고 판별하기 위한 것이다.

양 정책들이 그렇게 허용한다면, 상기 활동성 관리자 (134)는 상기 요청된 제2 프로세스 (620)를 상기 제2 도메인 (142-2)과 연관하여 시작한다 (행동 625). 위에서 도입된 예들에 추가로, 이메일 서비스가 시작될 수 있을 것이며, 또는 상기 도메인 세팅 (144-1) 서비스가 시작될 수 있을 것이며 그리고 사용자는 상기 제2 도메인 (144-2)의 삭제를 확인하도록 촉구받으며, 또는 전화 서비스는 호출하기 위한 원하는 번호가 디스플레이된 것과 함께 시작될 수 있을 것이다.

도메인 애플리케이션 설치 프로토콜

도메인 애플리케이션 설치를 도시한 블록 도면 (700)이 도 7에서 보이며, 이 경우 제1 도메인 내에 설치된 애플리케이션은 제2 도메인으로 이동되거나 복사된다.

위에서 설명된 것처럼, 애플리케이션은 선택된 안전한 도메인에 연관하여 설치될 수 있으며, 이 경우에 상기 도메인의 DID는 상기 설치된 애플리케이션의 애플리케이션 식별자와 연관하여 저장된다.

도메인 세팅 (144-1) 서비스를 이용하여, 사용자는 애플리케이션을 다른 도메인으로, 예를 들면, 제1 도메인 (142-1)으로부터 제2 도메인 (142-2)으로 이동 또는 복사를 선택할 수 있을 것이다. 상기 도메인 세팅 (144-1) 서비스는 상기 패키지 관리자 (136)에게 시그날링하여 제2 도메인 (142-2) 내에 상기 애플리케이션을 설치하도록 한다 (행동 705). 상기 패키지 관리자 (136)는 상기 도메인 관리자 (124)에게 시그날링하여 상기 제2 도메인 (142-2)을 위한 보안 라벨을 결정하도록 한다 (행동 710). 상기 패키지 관리자 (136)는 그러면 상기 도메인 관리자 (124)로부터 수신한 올바른 보안 라벨과 함께 상기 애플리케이션을 상기 제2 도메인 (142-2) 내에 설치한다. 선택된 행동이 이동이라면, 복사와는 반대로, 상기 도메인 세팅 (144-1) 서비스는 그러면 상기 패키지 관리자 (136)에게 시그날링하여 상기 제1 도메인 (142-1)으로부터 상기 애플리케이션을 설치 해제하고 (행동 715) 그리고 마찬가지로 상기 애플리케이션 사용자 데이터를 새로운 도메인으로 전달하도록 한다.

업데이트 정책 프로토콜

업데이트 정책 방법을 예시한 블록 도면 (800)이 도 8에 보인다.

도메인 메시지 서비스 (122)는 원격 관리 서버 (805)로부터 정책을 수신하며 (행동 810), 또는 대안으로 상기 디바이스 상의 세팅 스크린을 통해, 또는 API를 통해 수신하며, 이는 상기 정책을 그 후 상기 도메인 메시지 서비스 (122)로 (행동 815) 그리고 그 후에 도메인 커널 모듈 (114)로 적절하게 통과시키며 (행동 820), 이 도메인 커널 모듈은 상기 정책을 보안 저장 (112)에 저장한다 (행동 825). 상기 정책의 원본의 무결성 및 진정함은 상기 도메인 커널 모듈 (116)에 의해 검증된다. 안티-롤백 메커니즘들이 도메인 커널 모듈 (116) 또는 보안 저장 (112) 내에 적용되어, 더 오래된 정책들이 재-사용될 수 없으며 또는 다시 재생될 수 없다는 것을 확실하게 한다. 상기 도메인 정책 서비스 (126)는 그러면 상기 정책 그리고 이전에 정책들을 로드하며, 이는 업데이트된 정책에서 변했던 그런 정책들만을 스마트하게 적용하기 위한 것이다. 상기 도메인 정책 서비스 (126)는 상기 정책의 업데이트된 SELinux 부분을 로드하기 위해 (행동 830) 상기 향상된 리눅스 보안 모델 (116)에게 시그날링할 수 있다. 상기 도메인 정책 서비스 (126)는 상기 시스템 세팅 모듈 (130)에게 시그날링하여 패스워드 강도 (strength), 월페이퍼 및 런처처럼 상기 시스템 세팅 모듈 (130)에 의해 적용되며 강제된 정책들을 업데이트하도록 한다 (행동 835). 상기 도메인 정책 서비스 (126)는 그러면 도메인 암호화, 도메인 디버그 액세스, 크로스 도메인 정책들 및 도메인 이름과 같이 도메인들에 특정된 자기 자신의 정책들을 업데이트한다.

이점들

본 솔루션은 분리된 보호받는 도메인들을 안전하게 설립하고, 유지하며 관리하기 위한 그리고 그렇게 분리된 보호받는 도메인들 내에서 애플리케이션들 및 데이터를 정의하고 격리하기 위한 수단을 제공한다. 본 솔루션은 종래 기술에 비하면 메모리, 공간 및 컴퓨팅 파워의 면에서 효율적이다. 그것은 애플리케이션들에 대한 하위 호환성 (backward compatibility)을 포함하는 원래의 운영 시스템 특징들을 유지한다. 그것은 몇몇의 도메인들에서 원래의 그리고 직관적인 디바이스 사용자 인터페이스를 유지하며, 그러나 다른 도메인들에서는 전통적인 "전부 아니면 아무것도 아닌 (all-or-nothing)" 디바이스 잠금 및/또는 사용자 계정 액세스가 아닌 많은 상이한 사용자 인터페이스 옵션들 및 정책들을 가능하게 한다. 그것은 상이한 도메인 소유자들과 함께 두 사람, 여러-사람, 다중의 사람 사이에서의 다중-도메인 사용, 다중 작업 및 한 디바이스 상에서의 "공개 (open)" 도메인들을 가능하게 한다. 그것은 그런 다중의 도메인들에 대한 원격 관리 및 정책 업데이트들을 가능하게 한다. 그것은 각 도메인에 대해 상이한 액세스 제어 및 정책들을 허용한다. 그것은 데이터가 도메인들 사이에서 전달될 수 있는가 또는 아닌가의 여부를 정책이 판별하도록 허용한다. 그것은 일시적인 공유를 포함하여 모바일 디바이스들에 더욱 적합한 새로운 사용 모델들을 가능하게 한다. 그것은 다른 솔루션들이 비해 각 도메인에서 이용 가능한 애플리케이션들에 대한 더욱 정밀한 제어를 가능하게 한다. 상기 솔루션은, 각 대응하는 하이퍼바이저에 의해 복제될 수 있을 운영 시스템 프로세스들의 분리된 세트와 연관하여 각 도메인이 동작하는 하이퍼바이저-기반의 가상화와 연관된, 도메인들 사이에서의 운영-시스템 레벨의 "하드 스위칭"을 아주 간략하게 하거나, 또는 심지어 제거할 수 있다. 그것은 현재의 솔루션들의 약점들을 가지지 않으면서 도메인들 사이에서 애플리케이션들 및 애플리케이션 데이터를 격리시킨다. 그것은 도메인 내 애플리케이션들 및 데이터를 그 도메인 외부의 악의의 애플리케이션으로부터 격리시킨다. 마지막으로, 그것은 모바일 디바이스 사용자들의 선택의 자유 및 프라이버시 걱정을 중점을 두어 다룬다.

구현의 상세 내용들에 독립하여 도메인 시그날링, 도메인 관리 및 도메인 집행을 이용하여 도입된 중요한 이점들 및 특징들이 존재한다. 이것들은 다음과 같다. 상기 솔루션은 애플리케이션들에 대한 하위 호환성을 포함하여 원래의 고유의 운영 시스템 특징들을 유지한다. 모든 고유한 운영 시스템 허가 체크들 및 IPC 메커니즘들은 공존할 것이며 그리고 여전히 효과적일 것이다. 상기 운영 시스템은 변하지 않고 동작하며 그리고 상기 솔루션은 이전의 운영 시스템과의 하위 호환한다. 상기 솔루션은 종래 기술에 비교하여 메모리, 공간 및 컴퓨팅 파워의 면에서 효율적이다. 디바이스 성능 및 저장 그리고 메모리 사용은, 운영 시스템 스택을 복제하여 실질적인 CPU 및 RAM 오버헤드를 초래하는 가상화와 같은 대안의 접근 방식들에 비해 매우 효율적이다. 원래의 OS 구현 때문에, 종래의 기술에 비교하면 도메인들 사이에서의 스위칭은 매우 빠르고 효과적이다.

상기 솔루션은 상이한 도메인 소유자들과 함께 두 사람, 여러-사람, 다중의 사람 사이에서의 다중-도메인 사용, 다중 작업 및 한 디바이스 상에서의 "공개 (open)" 도메인들을 가능하게 한다. 다중의 보호받는 도메인들이 쉽게 추가될 수 있으며 무시할 수 있을 정도의 메모리 및 성능 영향을 가지면서 강제될 수 있다. 단일의 디바이스 상에 다중의 보호받는 작업 도메인들이 존재할 수 있다. 예를 들어, 사용자가 다중의 고객들을 가지고 있다면, 회사 X 도메인, 그리고 동일한 디바이스 상에 회사 Y 도메인이 존재할 수 있다. 대안으로 디바이스는 각각이 상이한 정책들을 가진 회사 기밀 도메인 그리고 회사 분류 도메인을 가지도록 구성될 수 있다 (예를 들면, 회사 분류 도메인 내 상주하는 애플리케이션들을 위한 보안 정책은, 그것들이 보통의 근무 시간들 동안에만 또는 디바이스가 회사 WiFi 네트워크에 연결될 때에 액세스될 수 있는 것처럼 더욱 제한적일 수 있다). 디바이스는 액세스의 편리함을 위해 그리고 식구나 동료들과 함께 개방 도메인에서 디바이스와 애플리케이션들을 애드혹 (ad-hoc) 공유를 가능하게 하기 위해, 개방된 공유 도메인을 가지도록 구성될 수 있다. 사용자는, 비밀의 관계에 속한 연락처 정보 및 메시징을 격리시키거나 모바일 뱅킹이나 상업적인 목적들을 위한 것처럼 비밀 목적들을 위해서 보호받는 도메인을 가질 수 있다. 은행처럼 디바이스 소유자의 고용주가 아닌 서비스 제공자는 계정 액세스, 신용 카드 또는 직불 카드 서비스들, 주식 거래, 보험, 대부 등과 같은 서비스들에 대한 시세 결정과 같은 자신들의 서비스들에 액세스하기 위해 다양한 애플리케이션을 포함하는 디바이스 상에 보호받는 도메인을 가지기를 바랄 수 있을 것이다. 상기 서비스 제공자는 자신의 애플리케이션들 그리고 그런 애플리케이션들과 연관된 사용자의 개인적인 정보가 안전하며 그리고 디바이스 분실의 경우에 지워지거나 잠금이 될 수 있다는 확신을 가질 것이다.

상기 솔루션은 도메인들 사이에서 상이한 도메인들에 대해 상이한 액세스 제어 및 정책들을 그리고 그리고 단일의 디바이스 상의 보호받는 도메인들로부터의 인-바운드 및 아웃-바운드 통신들을 허용한다. 도메인 정책은 (예를 들면, 디바이스 세팅들을 통해서) 로컬에서 관리되거나 또는 (예를 들면, 클라우드 서비스를 통해서) 원격으로 관리되는 것 중 어느 하나일 수 있다. 정책은 디바이스 소유자 또는 고용주나 서비스 제공자와 같은 서드 파티 중 어느 하나에 의해 또한 관리될 수 있다. 크로스 도메인 통신 및 데이터 공유는 한정된 그리고 강제된 정책일 수 있다. 데이터 암호화는 도메인 인식일 수 있다. 전화 기능성, 호출자 통지 및 비상 호출 등은 도메인 인식일 수 있으며 그리고 정책을 기반으로 할 수 있다. 예를 들면, 외부로 나가는 호출들은 특정 도메인들로부터 차단될 수 있을 것이다. 네트워크 접속성은 도메인 인식일 수 있으며 그리로 강제된 정책일 수 있다. 태스크 선택기 및 프로세스 디스플레이는 도메인 인식일 수 있다. 예를 들면, 프로세스들은 도메인에 로그인 되어야만 디스플레이될 수 있을 것이다. 통지들은 통지를 기초로 하여 도메인 인식일 수 있다. 예를 들면, 작업 도메인 통지는 공유 동안에 데이터 누설을 피하기 위해서 특정 페이지로부터만 볼 수 있을 것이다. 또는, 상기 통지는 상기 통지를 축소된 정보를 구비하여 (예를 들면, 수신된 이메일의 제목, 또는 수신된 SMS의 발송자를 공개하지 않는 등) 제공하는 애플리케이션을 표시할 수 있을 것이다. 클라우드 백업 및 동기화 메커니즘들은 또한 도메인 인식일 수 있다. 예를 들어, 개방 도메인과 연관된 특정 계정이 존재하지 않는다고 해도, 그 개방 도메인은 백업될 수 있을 것이다.

상기 솔루션은 원래의 타고난 그리고 직관적인 사용자 인터페이스를 유지하지만, 전통적인 "전부 아니면 아무것도 아닌" 디바이스 잠금 및/또는 전통적인 다중-사용자 계정 액세스가 아닌 상이한 도메인들 사이에서의 많은 상이한 인터페이스 옵션들 및 정책들을 가능하게 한다. 상기 사용자 인터페이스 및 도메인들 사이에서의 스위칭은 이제는 도메인 천이 (transition)의 유형에 맞추어질 수 있다. 전통적인 사용자 계정 스타일 인터페이스가 유지될 수 있으며 그리고 각 도메인은 여전히 개인화될 수 있으며 그리고 상이한 배경 및/또는 도메인 당 상이한 시작 스크린과 같이 각 도메인에 대한 모든 표준의 원래의 OS 능력들을 가지며 설정될 수 있다. 사용자 인증 메커니즘들은 (예를 들면, 패스워드, 생물 측정학, 패턴, 인증 없음)은 도메인마다 설정될 수 있다. 도메인 로그-인 정책들은 사용자가 도메인들 사이에서 스위칭할 때에 그 사용자를 반복하여 인증할 필요성을 줄이거나 또는 제거하기 위해 사용될 수 있다. 액세스 제어 및 인증 기술들은 도메인을 위한 정책 세트에 따라서 각 보호받는 도메인에 대해 강제될 수 있다 (예를 들면, 디바이스가 활동하지 않으면 15분 후에 자동적으로 로그-아웃, 또는 도메인이 활동하지 않으면 5분 후에 자동적인 도메인 로그-아웃, 또는 특정 도메인 내에 있을 때에는 매 10분마다 재-인증 등). 상기 솔루션은 모바일 디바이스들에 더욱 적합한 새로운 사용 모델들을 가능하게 하며, 이는 개방 도메인을 경유하는 것 같은 애플리케이션의 애드-혹 공유를 포함한다. 모바일 디바이스들에서 근래의 특징들은 확장이며, 여기에서 몇몇의 디바이스 능력들은 인증을 요청하지 않으면서 디바이스 잠금 화면으로부터 이용 가능하다. (예를 들면, 사용자가 여전히 사진을 찍을 수 있으며, 또는 들어오는 호출을 수신할 수 있다). 기능성을 제한하는 것이 아니라, 도메인 시그날링 및 도메인 격리 집행을 이용하여 개방 영역은, 비록 제한된 인터넷 액세스 (예를 들면, 불가, 또는 WiFi를 통한 것만) 그리고 제한된 전화 액세스 (에를 들면, 들어오는 호출만, 또는 로컬에서의 호출들만 등)와 같이 다른 특별한 정책을 가질 수 있을 것이지만, 애플리케이션들로의 전체 피처 (feature) 액세스를 제공할 수 있다. 도메인들 사이에서의 스위칭은 도메인들을 디스플레이하기 위한 다른 수단 (예를 들면, 아이콘들 상의 오버레이들)을 이용함으로써 제거될 수 있다. 상기 디바이스 소유자는 운영 시스템에 의해 지원되는 폴더들, 탭들 또는 어떤 다른 메커니즘 내에 분리하여 그룹으로 된 도메인들을 유지할 수 있다 (아마도 프라이버시 이유들 또는 개인적인 선호들을 위한 것임). 도메인마다의 인증 정책은 탭 또는 특정 애플리케이션으로 액세스할 때에도 여전히 적용될 것이지만, 스위칭하기 위한 필요성 그리고 상이한 도메인 "홈 스크린들" 및 월페이퍼들 등은 제거될 수 있을 것이다.

각 도메인에서 이용 가능한 애플리케이션들은, 디바이스 상이 하나의 사본만을 저장하면서도, 다른 솔루션들에 비교하여 더욱 미세한 레벨에서 제어되고 디스플레이될 수 있으며, 그래서 메모리 및 CPU의 매우 효과적인 사용을 제공한다. 상기 패키지 관리자는

각 도메인에서 애플리케이션들의 설치를 관리할 수 있으며, 이는 사용자 계정들 사이에 이미 있지만, 더욱 세련되고, 도메인-특정 메커니즘들을 구비한다. 이용 가능성, 디스플레이 및 애플리케이션들로의 액세스는 정책에 의해 도메인마다 제어될 수 있다. 애플리케이션 데이터는 (사용자 계정마다에 추가하여) 도메인마다 격리될 수 있으며 그리고 (예를 들어, 디바이스가 분실되거나, 또는 고용이 종결되는 등의 경우에) 도메인마다 쉽게 제거되고 관리될 수 있다. 안드로이드 4.2가 그런 것처럼 도메인마다 애플리케이션 설치를 수행하는 것이 아니라, 홈 페이지들 및 탭들 사이에서 애플리케이션들을 이동시키는 것과 유사하게 애플리케이션들은 더욱 직관적이고 창의적인 방식들로 도메인들 사이에서 이동되거나 지워질 수 있다.

상기 솔루션은 도메인 인식 버전의 SE 리눅스를 구비한 도메인들에 의해 규정된 것처럼 애플리케이션 및 애플리케이션 데이터 격리를 강제할 수 있다. 그것은 한 도메인 상에 애플리케이션들에 의한 액세스가 다른 도메인을 액세스할 수 없다는 것을 보증할 수 있다. 그것은 크로스 도메인 호들이 정책을 강제하는 도메인 관리 서비스를 경유해야만 가능하다는 것을 보증한다. 그것은 한 도메인 상의 악성 소프트웨어가 다른 도메인 내 애플리케이션들 및 데이터에 영향을 미칠 수 없다는 것을 보증한다. 그것은 인증 없이 도메인들을 사용하는 것이 다른 도메인들의 보안에 영향을 미치지 않는다는 것을 보증한다.

본 솔루션은 가상화 및 컨테이너들과 같은 다른 보안 기술의 사용에 영향을 미치치 않으며, 이는 상기 솔루션이 그런 기술들과 하위 호환성이기 때문이다. 특히, 수정을 한 유형 2 하이퍼바이저들은 도메인 정보를 상이한 운영 시스템들 사이에서의 스위칭의 일부로서 활용할 수 있을 것이다. 애플리케이션 솔루션들은 본 솔루션 내에 또한 배치될 수 있다.

상기의 실시예들이 안드로이드 및 리눅스 운영 시스템들에 관련하여 특히 설명되었지만, 여기에서 개시된 원칙들은 상기의 개시에 의해 중점을 두어 다루어진 관련된 특성들을 소유하는 어떤 운영 시스템에도 적용 가능하다는 것이 이해될 것이다.

상기의 운영 시스템을 동작시키는 상기 디바이스가 스마트폰, 태블릿, 개인용 디지털 보조기 (PDA), 스마트와치, 또는 어떤 유사한 디바이스를 포함할 수 있을 모바일 디바이스로서 참조되었지만, 여기에서 개시된 원칙들은 상기의 개시에 의해 중점을 두어 다루어진 관련된 특성들을 소유하며, 그리고 몇몇의 실시예들에서는 범용 컴퓨터를 포함하는 어떤 디바이스에도 적용 가능하다는 것이 이해될 것이다.

전술한 설명에서, 설명의 목적들을 위해, 여러 상세한 내용들이 본 발명의 실시예들에 대한 철저한 이해를 제공하기 위해서 제시되었다. 그러나, 본 발명이 속한 기술 분야에서의 통상의 지식을 가진 자에게는 이런 특정 상세 내용들이 본 발명을 수행하기 위해 필요하지 않다는 것이 명백할 것이다. 다른 예들에서, 본 발명을 불명료하게 하지 않도록 하기 위해서, 잘 알려진 전기적인 구조들 및 회로들이 블록 도면 모습으로 도시된다. 예를 들면, 특정 상세 내용들은 여기에서 설명된 본 발명의 실시예들이 소프트웨어 루틴, 하드웨어 회로, 펌페어, 또는 그것들의 조합으로서 구현되는지의 여부에 관하여는 제공되지 않는다.

본 발명의 실시예들은 기계-판독가능 매체 (컴퓨터-판독가능 매체, 프로세서-판독가능 매체, 또는 컴퓨터-판독가능 프로그램 코드가 내부에 내장된 컴퓨터 사용가능 매체로도 언급됨) 내에 저장된 소프트웨어 제품으로서 표현될 수 있다. 상기 기계-판독가능 매체는 어떤 적합한 유형적인 매체로, 디스켓, 컴팩트 디스크 읽기 전용 메모리 (CD-ROM), 메모리 디바이스 (휘발성 또는 비-휘발성), 또는 유사한 저장 메커니즘을 포함하는 자기적인, 광학적인, 또는 전기적 저장 매체를 포함한다. 상기 기계-판독가능 매체는 다양한 세트의 명령어들, 코드 시퀀스들, 설정 정보, 또는 다른 데이터를 포함할 수 있으며, 이것들은 실행될 때에 프로세서로 하여금 본 발명의 실시예에 따른 방법 내의 단계들을 수행하도록 한다. 본 발명이 속한 기술 분야에서의 통상의 지식을 가진 자들은 설명된 본 발명을 구현하기 위해 필요한 다른 명령어들 및 오퍼레이션들이 상기 기계-판독가능 매체 상에 또한 저장될 수 있다는 것을 인정할 것이다. 상기 기계-판독가능 매체로부터 실행되는 소프트웨어는 상기 설명된 태스크들을 수행하기 위해 회로와 정합할 수 있다.

본 발명의 상기 설명된 실시예들은 단지 예시적인 것으로 의도된 것이다. 변경, 수정 및 변이들은 본 발명의 범위로부터 벗어나지 않으면서 본 발명이 속한 기술 분야에서의 통상의 지식을 가진 자들에 의해 상기 특별한 실시예들로 실행될 수 있으며, 본 발명의 범위는 첨부된 청구항들에 의해서만 한정된다.

Claims

프로세서 그리고 안드로이드 운영 시스템을 구현하기 위해 상기 프로세서에 의해 실행 가능한 명령어들을 저장하는 메모리를 포함하는 모바일 디바이스에서, 상기 개선점은:
상기 안드로이드 운영 시스템에서 구현된 사용자 계정들과는 상이한 복수의 도메인들을 선택적으로 생성하는 사용자 관리자;
상기 도메인들 중 하나의 도메인을 현재 도메인으로서 선택하는 도메인 관리자;
도메인과 연관된 파일들 및 애플리케이션들로의 액세스를 제어하는 규칙 세트를 포함하는 정책을 각 도메인에 대해 저장하고 집행하는 도메인 정책 서비스;
도메인의 정책 그리고 상기 현재 도메인의 정책을 기초로 하여, 도메인과 연관된 애플리케이션들의 설치 또는 실행을 각 도메인에 대해 선택적으로 허용하거나 차단하는 패키지 관리자;
상기 도메인들 중 상이한 것들과 연관된 동작 프로세스들 사이에, 상기 도메인들 중 상기 상이한 것들 각자의 정책을 기초로 하여, 통신을 제공하는 도메인 메시지 서비스; 그리고
상기 현재 도메인을 선택적으로 스위치하기 위한 활동성 관리자를 포함하며,
상기 사용자 관리자, 도메인 관리자, 도메인 정책 서비스, 패키지 관리자, 도메인 메시지 서비스, 및 활동성 관리자는 상기 안드로이드 운영 시스템의 커널 외부에서 상기 안드로이드 운영 시스템 내에 구현되는, 모바일 디바이스.
제1항에 있어서,
상기 개선점은:
도메인과 연관된 정책을 각 도메인에 대해 집행하기 위한 도메인 커널 모듈을 더 포함하며,
상기 도메인 커널 모듈은 상기 안드로이드 운영 시스템의 커널에서 구현되는, 모바일 디바이스.
컴퓨팅 디바이스의 운영 시스템에서 복수의 보안 도메인들을 제공하기 위해 상기 컴퓨팅 디바이스의 프로세서에 의해 실행되는 방법으로, 상기 방법은:
(a) 각 보안 도메인에 대해:
(a1) 상기 보안 도메인의 자원들을 유일 도메인 식별자와 연관시키는 단계로서, 상기 자원들은 적어도 하나의 데이터 파일 또는 적어도 하나의 애플리케이션을 포함하는, 연관 단계; 그리고
(a2) 상기 유일 도메인 식별자와 연관하여 정책을 저장하는 단계로, 상기 정책은 상기 자원들로의 액세스를 제어하기 위한 규칙 세트를 포함하는, 저장 단계;
(b) 상기 복수의 보안 도메인들 중 하나의 보안 도메인을 선택한 것을 현재 도메인으로서 수신하는 단계로, 상기 복수의 보안 도메인들은 상기 현재 도메인과는 상이한 타겟 도메인을 포함하는, 수신 단계; 그리고
(c) 상기 현재 도메인과 연관된 정책 그리고/또는 상기 타겟 도메인과 연관된 정책을 기초로 하여 상기 타겟 도메인 자원들로의 액세스를 제어하는 단계를 포함하는, 방법.
제3항에 있어서,
(a), (b), 및 (c) 중 적어도 하나를 수행하기 위해 상기 운영 시스템의 커널 외부에서 적어도 부분적으로 상기 운영 시스템의 적어도 하나의 서비스를 실행하는 단계를 더 포함하는, 방법.
제3항에 있어서,
(c)는 상기 운영 시스템의 커널 내에서 동작하는 제1 서비스에 의해 적어도 부분적으로 수행되며 그리고 상기 커널의 외부의 상기 운영 시스템의 미들웨어에서 동작하는 제2 서비스에 의해 적어도 부분적으로 수행되는, 방법.
제5항에 있어서,
(a) 및 (b)는 상기 커널 외부의 상기 운영 시스템의 미들웨어에서 동작하는 추가의 서비스에 의해 수행되는, 방법.
제3항에 있어서,
상기 운영 시스템은 복수의 사용자 계정들을 구현하며, 그리고 상기 현재 도메인 및 상기 타겟 도메인은 상기 사용자 계정들 중 하나에 공통으로 연관된, 방법.
제3항에 있어서,
(c)는 상기 현재 도메인과 연관된 정책 그리고 상기 타겟 도메인과 연관된 정책을 기초로 하여 상기 타겟 도메인 자원들로의 프로세스에 의한 액세스를 제어하는 단계를 포함하며. 상기 프로세스는 상기 현재 도메인과 연관된, 방법.
제8항에 있어서,
상기 프로세스는 상기 현재 도메인의 유일 도메인 식별자를 기초로 하여 실행 콘텍스트 (execution context) 식별자와 연관되며, 그리고 (c)는 상기 실행 콘텍스트 식별자를 기초로 하여 상기 타겟 도메인 자원들로의 상기 프로세스에 의한 액세스를 제어하는 단계를 포함하는, 방법.
제9항에 있어서,
상기 현재 도메인의 자원들은 적어도 하나의 애플리케이션을 포함하며, 그리고
상기 실행 콘텍스트 식별자는 상기 현재 도메인의 유일 도메인 식별자 그리고 상기 프로세스를 생성하기 위해 실행된 적어도 하나의 애플리케이션과 연관된 유일 애플리케이션 식별자를 기초로 하는, 방법.
제10항에 있어서,
상기 운영 시스템은 안드로이드 운영 시스템이며, 상기 유일 애플리케이션 식별자는 설치 시 상기 애플리케이션에게 할당된 유닉스-유형 사용자 식별자 (Unix-type user identifier (UID))이며, 상기 실행 콘텍스트 식별자는 상기 애플리케이션의 상기 UID를 포함하며, 그리고 상기 유일 도메인 식별자는 상기 UID의 예비 비트들 내에 포함된, 방법.
제3항에 있어서,
상기 운영 시스템은 상기 현재 도메인의 자원들 및 상기 타겟 도메인의 자원들로의 동시 액세스를 제공하는 사용자 인터페이스를 제공하는, 방법.
제12항에 있어서,
상기 타겟 도메인의 자원들은 상기 타겟 도메인과 연관된 적어도 하나의 애플리케이션을 포함하며, 그리고 상기 사용자 인터페이스는 상기 적어도 하나의 애플리케이션을 실행하기 위한 수단을 제공하는, 방법.
제13항에 있어서,
상기 사용자 인터페이스는 상기 타겟 도메인의 적어도 하나의 애플리케이션과 연관된 아이콘을 구현하며,
상기 아이콘은 상기 타겟 도메인과의 상기 적어도 하나의 애플리케이션의 연관을 의미하는 오버레이를 포함하는, 방법.
제12항에 있어서,
상기 타겟 도메인의 상기 자원들은 상기 타겟 도메인과 연관된 수신된 메시지를 더 포함하며, 그리고 상기 사용자 인터페이스는 상기 메시지를 열기 위한 수단을 제공하는, 방법.
제3항에 있어서,
(a1)은 상기 자원들을 상기 보안 도메인의 유일 도메인 식별자와 연관시키는 메타데이터를 저장하는 단계를 포함하는, 방법.
제3항에 있어서,
상기 보안 도메인들 중 하나는 외부에서 제어되는 도메인이며, 그리고 상기 외부에서 제어되는 도메인과 연관된 정책은 네트워크를 경유하여 원격 도메인 관리 서버로부터 수신되는, 방법.
제17항에 있어서,
상기 현재 도메인은 상기 외부에서 제어되는 도메인이며, 그리고 상기 현재 도메인과 연관된 상기 정책의 적어도 일부에 대한 수정은 상기 원격 도메인 관리 서버에 의한 것을 제외하고는 차단되는, 방법.
제3항에 있어서,
상기 타겟 도메인 자원들은 공통 애플리케이션의 제1 버전을 구비한 적어도 하나의 애플리케이션을 포함하며,
상기 현재 도메인과 연관된 정책 및 상기 타겟 도메인과 연관된 정책은 상기 공통 애플리케이션의 상기 제1 버전에 대한 액세스를 차단하는, 방법.
제19항에 있어서,
상기 현재 도메인 자원들은 상기 공통 애플리케이션의 상기 제1 버전과는 상이한 상기 공통 애플리케이션의 제2 버전을 구비한 적어도 하나의 애플리케이션을 포함하는, 방법.
저장된 명령어들을 포함하는 컴퓨터-판독가능 매체로서,
상기 명령어들은 컴퓨터에 의해 실행될 때에 제3항의 방법을 수행하는, 컴퓨터-판독가능 매체.
컴퓨팅 디바이스의 운영 시스템에서 복수의 보안 도메인들을 제공하기 위한 방법으로, 상기 방법은:
(a) 각 보안 도메인에 대해:
(a1) 상기 보안 도메인의 자원들을 상기 보안 도메인과 연관된 유일 도메인 식별자와 연관시키는 단계로서, 상기 자원들은 적어도 하나의 데이터 파일 또는 적어도 하나의 애플리케이션을 포함하는, 연관 단계; 그리고
(a2) 상기 유일 도메인 식별자와 연관하여 정책을 저장하는 단계로, 상기 정책은 상기 자원들로의 액세스를 제어하기 위한 규칙 세트를 포함하는, 저장 단계;
(b) 상기 보안 도메인들 중 제1 보안 도메인과 연관된 시작 프로세스 (originating process)와 연관된 이벤트 메시지를 생성하는 단계;
(c) 상기 보안 도메인들 중 제2 보안 도메인과 연관된 타겟 프로세스가 상기 이벤트 메시지에 응답하도록 구성된 것을 판별하는 단계;
(d) 상기 이벤트 메시지를 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 프로세싱하여, 프로세싱된 이벤트 메시지를 생산하는 단계; 그리고
(e) 상기 프로세싱된 이벤트 메시지를 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 상기 타겟 프로세스로 통과시키거나 차단하는 단계를 포함하는, 복수의 보안 도메인들 제공 방법.
제22항에 있어서,
상기 이벤트 메시지는 상기 시작 프로세스에 의해 생성된 복사하여 붙이기 (copy-and-paste) 행동을 표시하며,
상기 제1 도메인과 연관된 정책은 클립보드 버퍼를 상기 제1 도메인 밖으로 통과시키는 것을 허용하는 제1 규칙을 구현하며, 그리고 상기 제2 도메인과 연관된 정책은 상기 클립보드 버퍼를 상기 제2 도메인으로 통과시키는 것을 허용하는 제2 규칙을 구현하며,
상기 클립보드 버퍼를 기초로 하는 상기 프로세싱된 이벤트 메시지는 상기 타겟 프로세스로 통과되는, 복수의 보안 도메인들 제공 방법.
제22항에 있어서,
상기 이벤트 메시지는 상기 시작 프로세스에 의해 생성된 복사하여 붙이기 행동을 표시하며,
상기 제1 도메인과 연관된 정책은 클립보드 버퍼가 상기 제1 도메인 밖으로 통과하는 것을 방해하는 제1 규칙을 구현하며, 또는 상기 제2 도메인과 연관된 정책은 상기 클립보드 버퍼를 상기 제2 도메인으로 통과시키는 것을 방해하는 제2 규칙을 구현하며,
상기 클립보드 버퍼를 기초로 하는 상기 프로세싱된 이벤트 메시지는 상기 타겟 프로세스로부터 차단되는, 복수의 보안 도메인들 제공 방법.
제22항에 있어서,
상기 이벤트 메시지는 상기 시작 프로세스에 의해 생성된 메시지 수신 통지를 포함하며, 상기 제1 도메인과 연관된 정책은 상기 메시지 수신 통지의 필터를 구현하는 제1 규칙을 구현하며, 또는 상기 제2 도메인과 연관된 정책은 상기 메시지 수신 통지의 필터를 구현하는 제2 규칙을 구현하며,
상기 프로세싱된 이벤트 메시지는 필터링된 메시지 수신 통지를 포함하며, 그리고 상기 필터링된 메시지 수신 통지는 상기 타겟 프로세스로 통과되는, 복수의 보안 도메인들 제공 방법.
제22항에 있어서,
(a1)은 상기 자원들을 상기 보안 도메인의 유일 도메인 식별자 필터와 연관시키는 메타데이터를 저장하는 단계를 포함하는, 복수의 보안 도메인들 제공 방법.
제25항에 있어서,
상기 필터는 적어도 상기 메시지 수신 통지의 송신자 식별자 또는 주체 식별자를 제거하거나 또는 가리는, 복수의 보안 도메인들 제공 방법.
저장된 명령어들을 포함하는 컴퓨터-판독가능 매체로서,
상기 명령어들은 컴퓨터에 의해 실행될 때에 제22항의 방법을 수행하는, 컴퓨터-판독가능 매체.
컴퓨팅 디바이스의 운영 시스템에서 복수의 보안 도메인들을 제공하기 위한 방법으로, 상기 방법은:
(a) 각 보안 도메인에 대해:
(a1) 상기 보안 도메인의 자원들을 상기 보안 도메인의 유일 도메인 식별자와 연관시키는 단계로서, 상기 자원들은 적어도 하나의 데이터 파일 또는 적어도 하나의 애플리케이션을 포함하는, 연관 단계; 그리고
(a2) 상기 유일 도메인 식별자와 연관하여 정책을 저장하는 단계로, 상기 정책은 상기 자원들로의 액세스를 제어하기 위한 규칙 세트를 포함하는, 저장 단계;
(b) 상기 보안 도메인들 중 제1 보안 도메인과 연관된 시작 프로세스로부터, 상기 보안 도메인들 중 제2 보안 도메인과 연관된 타겟 프로세스를 시작시키라는 요청을 수신하는 단계; 그리고
(c) 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 상기 요청을 프로세싱하는 단계를 포함하는, 복수의 보안 도메인들 제공 방법.
제29항에 있어서,
상기 시작 프로세스는 상기 제2 도메인과 연관하여 수신된 메시지와 연관된 메시지 수신 통지를 생성하며, 상기 요청은 상기 메시지를 디스플레이하라는 것이며, 상기 제2 도메인과 연관된 정책은 상기 메시지를 상기 제2 도메인에 디스플레이하는 것을 허용하는 제2 규칙을 구현하며, 그리고 상기 타겟 프로세스는 상기 메시지를 디스플레이하는, 복수의 보안 도메인들 제공 방법.
제30항에 있어서,
상기 제1 도메인과 연관된 정책은 상기 메시지를 상기 제2 도메인에 디스플레이하는 것을 허용하는 제1 규칙을 구현하는, 복수의 보안 도메인들 제공 방법.
저장된 명령어들을 포함하는 컴퓨터-판독가능 매체로서,
상기 명령어들은 컴퓨터에 의해 실행될 때에 제29항의 방법을 수행하는, 컴퓨터-판독가능 매체.
프로세서 그리고 커널 및 그 커널 외부의 미들웨어를 포함하는 운영 시스템을 저장하기 위한 저장 메커니즘을 포함하는 데이터 프로세싱 시스템에서,
도메인들을 생성하기 위해 상기 미들웨어에 제1 설비 (facility)를 제공하고 그리고 상기 도메인들로의 액세스를 제어하기 위한 대응 정책들을 상기 도메인들과 연관시키는 단계;
상기 도메인들 사이에서 스위칭하기 위해 상기 미들웨어 내 제2 설비를 제공하는 단계; 그리고
상기 도메인들의 상기 대응 정책들을 집행하기 위해 상기 미들웨어 내 적어도 부분적으로 제3 설비를 제공하는 단계를 포함하는, 방법.
제33항에 있어서,
상기 도메인들의 상기 대응 정책들을 기초로 하여 애플리케이션들의 설치를 관리하기 위해 상기 미들웨어 내 제4 설비를 제공하는 단계를 더 포함하는, 방법.
제34항에 있어서,
상기 도메인들 중 상이한 도메인들 내 동작 프로세스들 사이에 통신을 제공하기 위해 상기 미들웨어 내 제5 설비를 제공하는 단계를 더 포함하는, 방법.
제35항에 있어서,
상기 동작 프로세스는 상기 도메인들 중 제1 도메인으로부터 상기 도메인들 중 제2 도메인으로의 복사하여 붙이기 행동을 구현하며,
상기 제5 설비는 상기 제1 도메인 내 동작 프로세스들 중 제1 동작 프로세스와 상기 제2 도메인 내 동작 프로세스들 중 제2 동작 프로세스 사이에서의 시그날링을 제공하며, 그리고 상기 제5 설비는 상기 제1 도메인에 대응하는 정책 및 상기 제2 도메인에 대응하는 정책을 기초로 하여 상기 복사하여 붙이기 행동을 허용하거나 차단하는, 방법.
제35항에 있어서,
상기 동작 프로세스들은 상기 도메인들 중 제1 도메인에서 동작하는 메시지 클라이언트를 구현하며,
상기 제5 설비는 상기 제1 도메인 내 동작 프로세스들 중 제1 동작 프로세스와 상기 제2 도메인 내 동작 프로세스들 중 제2 동작 프로세스 사이에서의 시그날링을 제공하여, 상기 제1 도메인에 대응하는 정책 및 상기 제2 도메인에 대응하는 정책에 기초하여 상기 제2 도메인과 관련하여 생성된 메시지 수신 통지를 선택적으로 허용하고, 필터링하고, 또는 차단하는, 방법.
제35항에 있어서,
상기 도메인들 중 제1 도메인 및 제2 도메인의 대응하는 정책들에 기초하여 상기 제2 도메인과 연관된 적어도 하나의 애플리케이션의 상기 제1 도메인에서의 실행을 가능하게 하기 위해 상기 미들웨어 내 제6 설비를 제공하는 단계를 더 포함하는, 방법.
제38항에 있어서,
상기 제6 설비는 상기 적어도 하나의 애플리케이션을 실행하기 위해 상기 제1 도메인과 연관된 시작 프로세스로부터의 요청을 수신하며, 그리고 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책에 기초하여 상기 적어도 하나의 애플리케이션의 실행을 허용하거나 차단하는, 방법.
제39항에 있어서,
상기 요청은 상기 제2 도메인과 연관하여 수신된 메시지를 디스플레이하는 것은, 방법.
제38항에 있어서,
상기 도메인들의 대응하는 정책들을 기초로 하여 상기 도메인들 중 상이한 도메인들로의 동시 액세스를 제공하는 사용자 인터페이스로 상기 미들웨어 내에 제7 설비를 제공하는 단계를 더 포함하는, 방법.
제33항에 있어서,
상기 커널 내에 부분적으로 상기 제3 설비를 제공하는 단계를 더 포함하는, 방법.
제33항에 있어서,
상기 운영 시스템은 복수의 사용자 계정들을 구현하며, 그리고 상기 사용자 계정들 중 적어도 하나의 사용자 계정은 대응하는 복수의 도메인들과 유일하게 연관된, 방법.
제33항에 있어서,
상기 제3 설비는,
상기 도메인들 중 제1 도메인과 연관된 정책들 중 제1 정책 그리고 상기 도메인들 중 제2 도메인과 연관된 정책들 중 제2 정책을 기초로 하여 상기 제2 도메인과 연관된 자원들로의, 상기 제1 도메인과 연관된 프로세스에 의한 액세스를 제어하는, 방법.
제44항에 있어서,
상기 프로세스는 상기 제1 도메인의 유일 도메인 식별자를 기초로 하여 실행 콘텍스트 식별자와 연관되며, 그리고 상기 제3 설비는 상기 실행 콘텍스트 식별자를 기초로 하여 상기 프로세스에 의한 상기 자원들로의 액세스를 제어하는, 방법.
제45항에 있어서,
실행 콘텍스트 식별자는 상기 제1 도메인의 유일 도메인 식별자 그리고 상기 프로세스를 생성하기 위해 실행된 애플리케이션과 연관된 유일 애플리케이션 식별자를 기초로 하는, 방법.
제46항에 있어서,
상기 운영 시스템은 안드로이드 운영 시스템이며, 상기 유일 애플리케이션 식별자는 설치 시 상기 애플리케이션에게 할당된 유닉스-유형 사용자 식별자 (UID)이며, 상기 실행 콘텍스트 식별자는 상기 애플리케이션의 상기 UID를 포함하며, 그리고 상기 유일 도메인 식별자는 상기 UID의 예비 비트들 내에 포함된, 방법.
제41항에 있어서,
상기 사용자 인터페이스는 상기 도메인들 중 제1 도메인과 연관된 적어도 제1 애플리케이션 및 상기 도메인들 중 제2 도메인과 연관된 적어도 제2 애플리케이션으로의 동시 액세스를 상기 제1 도메인과 연관된 정책 및 상기 제2 도메인과 연관된 정책을 기초로 하여 제공하는, 방법.
제48항에 있어서,
상기 사용자 인터페이스는 상기 제1 애플리케이션과 연관된 제1 아이콘 그리고 제2 애플리케이션과 연관된 제2 아이콘을 구현하며, 그리고 상기 제1 아이콘은 상기 제1 애플리케이션의 상기 제1 도메인과의 연관을 의미하는 오버레이를 포함하는, 방법.
제33항에 있어서,
상기 도메인들 중 하나는 외부에서 제어되는 도메인이며, 그리고 상기 외부에서 제어되는 도메인과 연관된 정책은 네트워크를 경유하여 원격 도메인 관리 서버로부터 수신되는, 방법.
제50항에 있어서,
상기 외부에서 제어된 도메인과 연관된 정책의 적어도 일부에 대한 수정은 상기 원격 도메인 관리 서버에 의한 것을 제외하고는 차단되는, 방법.
저장된 명령어들을 포함하는 컴퓨터-판독가능 매체로서,
상기 명령어들은 컴퓨터에 의해 실행될 때에 제33항의 방법을 수행하는, 컴퓨터-판독가능 매체.
프로세서 및 메모리를 포함하는 컴퓨터 디바이스로서,
상기 메모리는 복수의 보안 도메인들을 제공하는 운영 시스템을 구현하기 위해 상기 프로세서에 의해 실행 가능한 명령어들을 저장하며, 상기 운영 시스템은:
상기 복수의 보안 도메인들을 선택적으로 생성하며, 그리고 상기 보안 도메인들 중 하나의 보안 도메인을 현재 도메인으로서 선택하는 도메인 관리자;
도메인과 연관된 파일들 및 애플리케이션들로의 액세스를 제어하는 규칙 세트를 포함하는 정책을 각 보안 도메인에 대해 저장하고 집행하는 도메인 정책 서비스;
상기 도메인과 연관된 애플리케이션들의 설치를 각 보안 도메인에 대해 집행하는 패키지 관리자;
상기 보안 도메인들 중 상이한 것들과 연관된 동작 프로세스들 사이에 통신을 제공하는 도메인 메시지 서비스; 그리고
상기 현재 도메인을 선택적으로 스위치하기 위한 활동성 관리자를 포함하는, 컴퓨팅 디바이스.