애플리케이션의 요소
Android는 휴대기기에 오픈소스 플랫폼 및 애플리케이션 환경을 제공합니다. 핵심 운영체제는 Linux 커널에 기반을 두고 있습니다. Android 애플리케이션은 대부분 자바 프로그래밍 언어로 작성되며 Dalvik 가상 머신에서 실행됩니다. 하지만 애플리케이션을 네이티브 코드로 작성할 수도 있습니다. 애플리케이션은 파일 확장자가 .apk인 단일 파일에서 설치됩니다.
Android 애플리케이션의 주요 구성요소는 다음과 같습니다.
-
AndroidManifest.xml: AndroidManifest.xml 파일은 애플리케이션의 모든 최상위 구성요소(특히 아래에 설명된 활동, 서비스, broadcast receiver, 콘텐츠 제공업체)를 이용해 할 일을 시스템에 지시하는 제어 파일입니다. 또한 필요한 권한도 지정합니다.
-
활동: 일반적으로 활동은 사용자 중심의 단일 작업을 위한 코드입니다. 활동은 일반적으로 사용자에게 UI로 표시되지만 반드시 그런 것은 아닙니다. 일부 활동은 UI로 전혀 표시되지 않습니다. 보통 애플리케이션의 활동 중 하나는 애플리케이션 진입점입니다.
-
서비스: 서비스는 백그라운드에서 실행되는 코드의 본문입니다. 자체 프로세스에서 실행되거나 다른 애플리케이션 프로세스의 컨텍스트에서 실행될 수 있습니다. 다른 구성요소는 서비스에 '연결'되고 리모트 프로시져 콜을 통해 이 서비스의 메서드를 호출합니다. 서비스의 한 가지 예는 미디어 플레이어입니다. 즉 사용자는 선택한 미디어의 UI를 종료해도 음악이 계속 재생되기를 원할 수 있습니다. 서비스는 UI가 종료되더라도 음악을 계속 재생합니다.
-
Broadcast Receiver: BroadcastReceiver는 운영체제나 다른 애플리케이션에서 인텐트라고 하는 IPC 메커니즘을 발행할 때 인스턴스화되는 객체입니다. 예를 들어 애플리케이션은 배터리 부족 메시지의 수신자를 등록하고 이 정보에 따라 동작을 변경할 수 있습니다.
Android 권한 모델: 보호 대상 API에 액세스
Android의 모든 애플리케이션은 애플리케이션 샌드박스에서 실행됩니다. 기본적으로 Android 애플리케이션은 제한된 범위의 시스템 리소스에만 액세스할 수 있습니다. 시스템에서는 잘못 사용하거나 악의적으로 사용하면 사용자 환경, 네트워크 또는 기기의 데이터에 악영향을 미칠 수 있는, Android 애플리케이션의 리소스 액세스 권한을 관리합니다.
이러한 제한사항은 다양한 형태로 구현됩니다. 어떤 기능은 의도적인 API 부족으로 인해 민감한 기능에만 영향을 줍니다(예: SIM 카드를 직접 조작하는 Android API는 없음). 어떤 경우에는 애플리케이션별 저장공간 분리와 마찬가지로 역할 분리를 통해 보안 조치를 적용합니다. 다른 경우, 민감한 API는 신뢰할 수 있는 애플리케이션에서 사용하며 '권한'이라는 보안 메커니즘을 통해 보호됩니다.
이와 같은 보호 대상 API는 다음과 같습니다.
- 카메라 기능
- 위치 데이터(GPS)
- 블루투스 기능
- 전화 기능
- SMS/MMS 기능
- 네트워크/데이터 연결
이러한 리소스는 운영체제를 통해서만 액세스할 수 있습니다. 기기에서 보호 대상 API를 사용하려면 애플리케이션이 매니페스트에서 필요한 기능을 정의해야 합니다. Android 버전 6.0 이상에서는 모두 런타임 권한 모델을 사용합니다. 사용자가 보호 대상 API가 필요한 앱에서 기능을 요청하면 권한을 거부 또는 허용하라는 대화상자가 시스템에 표시됩니다.
권한이 부여되면 애플리케이션이 설치되어 있는 경우 권한이 애플리케이션에 적용됩니다. 사용자가 혼동하지 않도록 시스템에서는 애플리케이션에 부여된 권한을 사용자에게 다시 알리지 않습니다. 또한 핵심 운영체제에 포함되어 있거나 OEM에서 번들로 제공하는 애플리케이션에서는 사용자에게 권한을 요청하지 않습니다. 애플리케이션이 제거되면 권한도 삭제됩니다. 따라서 이후에 다시 설치하면 권한이 다시 표시됩니다.
기기 설정에서 사용자는 이전에 설치한 애플리케이션의 권한을 볼 수 있습니다. 사용자는 GPS, 무선 또는 Wi-Fi 사용 중지와 같은 몇 가지 기능을 자신의 선택에 따라 전역적으로 사용 중지할 수도 있습니다.
애플리케이션의 매니페스트에 선언되지 않은 보호 대상 기능을 애플리케이션에서 사용하려 할 경우 일반적으로 권한 오류로 인해 보안 예외가 애플리케이션에 다시 발생합니다. 보호 대상 API 권한 검사는 우회를 방지하기 위해 최대한 낮은 수준에서 시행됩니다. 애플리케이션이 설치되면서 보호 대상 API 액세스 권한을 요청하는 경우 표시되는 사용자 메시지의 예는 그림 2에 나와 있습니다.
시스템 기본 권한은 https://developer.android.com/reference/android/Manifest.permission.html에 설명되어 있습니다. 애플리케이션은 자체 권한을 선언하여 다른 애플리케이션에서 사용하게 할 수 있습니다. 이 권한은 위의 위치 목록에는 없습니다.
권한을 정의할 때 protectionLevel 속성은 권한이 필요한 애플리케이션을 사용자에게 알리는 방식 또는 권한을 보유하도록 허용되는 사용자를 시스템에 알려줍니다. 애플리케이션별 권한 생성 및 사용에 관한 세부정보는 https://developer.android.com/guide/topics/security/security.html에 설명되어 있습니다.
타사 애플리케이션에서 사용할 수 없지만 OEM에서 사전 설치한 애플리케이션에서는 사용할 수 있는 SMS 브로드캐스트 인텐트 전송 기능과 같은 기기 기능이 있습니다. 이러한 권한에서는 signatureOrSystem 권한을 사용합니다.
사용자가 서드 파티 애플리케이션을 이해하는 방법
Android는 서드 파티 애플리케이션과 상호작용할 때 사용자에게 명확한 정보를 제공하고 서드 파티 애플리케이션의 기능을 사용자에게 알리기 위해 노력합니다. 애플리케이션 설치 전에 사용자에게 애플리케이션이 요청하는 여러 권한에 관한 명확한 메시지가 표시됩니다. 설치 후 사용자에게 권한을 확인하라는 메시지가 다시 표시되지 않습니다.
설치 직전에 권한을 표시해야 하는 이유는 여러 가지가 있습니다. 설치 전에는 사용자가 애플리케이션, 개발자 및 기능에 관한 정보를 적극적으로 검토하여 본인의 요구사항과 기대치에 부합하는지 확인하게 마련입니다. 또한 앱과 관련해 정신적 또는 금전적 의무가 아직 성립하지 않았으며 애플리케이션을 다른 애플리케이션과 쉽게 비교할 수 있다는 점도 중요합니다.
다른 플랫폼에서는 사용자 알림에 다른 방식으로 접근하여 각 세션 시작 시 또는 애플리케이션 사용 중에 권한을 요청합니다. Android의 비전은 사용자가 원하는 대로 애플리케이션 사이를 원활하게 전환하도록 하는 것입니다. 매번 확인하게 하면 사용자의 전환 속도가 느려지고 Android에서 탁월한 사용자 환경을 제공하는 데 방해가 됩니다. 사용자가 설치 시간에 검토 권한을 갖게 되면 마음이 내키지 않을 경우 애플리케이션을 설치하지 않을 수 있습니다.
또한 다수의 사용자 인터페이스 연구에 따르면 사용자에게 메시지를 너무 많이 표시하면 사용자가 표시되는 모든 대화상자에 '확인'을 클릭하게 된다고 합니다. Android의 보안 목표 중 하나는 중요한 보안 정보를 사용자에게 효과적으로 전달하는 것입니다. 사용자가 습관적으로 무시하는 대화상자를 사용해서는 이러한 목표를 달성할 수 없습니다. 중요한 정보를 중요할 때, 한 번만 표시하면 사용자는 자신이 동의하려는 정보가 어떤 것인지 생각해볼 가능성이 더 높아집니다.
어떤 플랫폼에서는 애플리케이션 기능에 관한 정보를 전혀 표시하지 않는 방식을 취합니다. 이러한 접근 방식으로는 사용자가 애플리케이션 기능을 쉽게 이해하고 논의할 수 없습니다. 모든 사용자가 항상 충분한 정보를 바탕으로 결정할 수는 없지만 Android 권한 모델을 사용하면 다양한 사용자가 애플리케이션 관련 정보에 쉽게 액세스할 수 있습니다. 예를 들어 예기치 않은 권한 요청을 하면 더 세심하게 판단하는 사용자는 애플리케이션 기능에 관한 중요한 질문을 하고 모든 사용자에게 표시되는 Google Play 등에서 문제를 공유할 수 있습니다.
애플리케이션 설치 시 권한 - Google 지도 | 설치된 애플리케이션의 권한 - Gmail |
프로세스 간 통신
기존 UNIX 유형 메커니즘을 사용하면 프로세스 간 통신이 가능합니다. 파일 시스템, 로컬 소켓, 신호 등을 예로 들 수 있습니다. 하지만 Linux 권한은 계속 적용됩니다.
또한 Android에서는 새로운 IPC 메커니즘을 제공합니다.
-
바인더: 프로세스 내 및 프로세스 간 호출을 실행할 때 고성능을 발휘하도록 설계된 경량 기능 리모트 프로시져 콜 메커니즘입니다. 바인더는 맞춤 Linux 드라이버를 사용해 구현합니다. https://developer.android.com/reference/android/os/Binder.html을 참조하세요.
-
서비스: 바인더를 사용하여 직접 액세스할 수 있는 인터페이스를 서비스(위에서 설명함)에서 제공할 수 있습니다.
-
인텐트: 인텐트는 무언가를 할 '의도'를 나타내는 단순한 메시지 객체입니다. 예를 들어 애플리케이션에서 웹페이지를 표시하려면 인텐트 인스턴스를 만들어 이를 시스템에 전달함으로써 URL을 보려는 '의도'를 표현합니다. 시스템에서는 이 인텐트를 처리하는 방법을 알고 있는 다른 코드 조각(이 경우에는 브라우저)을 찾아서 실행합니다. 인텐트는 시스템 전체에서 흥미로운 이벤트(예: 알림)를 브로드캐스트하는 데 사용될 수도 있습니다. https://developer.android.com/reference/android/content/Intent.html을 참조하세요.
-
ContentProviders: ContentProvider는 기기의 데이터에 액세스할 수 있는 권한을 제공하는 데이터 저장소입니다. 기본적인 예는 사용자의 연락처 목록에 액세스하는 데 사용되는 ContentProvider입니다. 애플리케이션은 다른 애플리케이션이 ContentProvider를 통해 노출한 데이터에 액세스할 수 있으며 자체 ContentProvider를 정의하여 자체 데이터를 노출할 수도 있습니다. https://developer.android.com/reference/android/content/ContentProvider.html을 참조하세요.
네트워크 소켓이나 누구나 쓸 수 있는 파일과 같은 다른 메커니즘을 사용하여 IPC를 구현할 수 있지만 위에 설명한 것들은 권장되는 Android IPC 프레임워크입니다. Android 개발자는 사용자 데이터 보호 및 보안 취약점 방지에 관한 권장사항을 따르는 것이 좋습니다.
비용에 민감한 API
비용에 민감한 API는 사용자나 네트워크에 비용을 발생시킬 수 있는 모든 기능입니다. Android 플랫폼은 비용에 민감한 API를 OS에서 제어하는 보호 대상 API 목록에 배치했습니다. 사용자는 비용에 민감한 API 사용을 요청하는 서드 파티 애플리케이션에 명시적 권한을 부여해야 합니다. 이러한 API의 예는 다음과 같습니다.
- 텔레포니
- SMS/MMS
- 네트워크/데이터
- 인앱 결제
- NFC 액세스
Android 4.2에는 SMS 사용을 제어하는 기능이 추가되었습니다. 애플리케이션에서 추가 요금이 발생할 수 있는 프리미엄 서비스를 사용하는 짧은 코드로 SMS를 보내려고 하면 Android에서 알림을 제공합니다. 사용자는 애플리케이션이 메시지를 보내도록 허용할지 또는 차단할지를 선택할 수 있습니다.
SIM 카드 액세스
SIM 카드에 액세스할 수 있는 낮은 수준의 권한은 서드 파티 앱에서 사용할 수 없습니다. OS에서는 SIM 카드 메모리에 있는 개인 정보(연락처)에 액세스할 수 있는 권한을 비롯한 SIM 카드와의 모든 통신을 처리합니다. 또한 RIL(무선 인터페이스 레이어)에서만 AT 명령어를 관리하므로 애플리케이션에서는 이 명령어에 액세스할 수 없습니다. RIL에서는 이러한 명령어에 높은 수준의 API를 제공하지 않습니다.
개인 정보
Android에서는 사용자 데이터에 액세스할 수 있는 권한을 제공하는 API를 보호 대상 API 집합에 배치하였습니다. 또한 통상적인 사용 중에 Android 기기는 사용자가 설치한 서드 파티 애플리케이션에 사용자 데이터를 축적합니다. 이 정보를 공유하기로 선택하는 애플리케이션에서는 Android OS 권한 검사를 사용하여 타사 애플리케이션의 데이터를 보호할 수 있습니다.
연락처 및 캘린더와 같이 개인 정보 또는 개인 식별 정보를 포함할 가능성이 있는 시스템 콘텐츠 제공업체는 명확하게 식별된 권한으로 만들어졌습니다. 이 세부사항에서는 애플리케이션에 제공될 수 있는 정보 유형을 명확하게 사용자에게 표시합니다. 설치하는 동안 타사 애플리케이션에서 이러한 리소스에 액세스할 수 있는 권한을 요청할 수 있습니다. 권한이 부여되면 애플리케이션은 설치될 수 있으며 설치 시 언제든지 요청된 데이터에 액세스할 수 있습니다.
개인 정보를 수집하는 애플리케이션은 기본적으로 이 데이터가 특정 애플리케이션으로 제한됩니다. 애플리케이션이 IPC를 통해 다른 애플리케이션에 데이터를 제공하기로 선택하면 액세스 권한을 부여하는 애플리케이션은 운영체제에서 시행하는 IPC 메커니즘에 권한을 적용할 수 있습니다.
민감한 정보 입력 기기
Android 기기에서는 애플리케이션이 주변 환경과 상호작용하도록 허용하는 카메라, 마이크 또는 GPS 등의 민감한 정보 입력 기기를 대개 제공합니다. 타사 애플리케이션에서 이러한 기기에 액세스하려면 먼저 Android OS 권한을 통해 사용자가 명시적으로 액세스 권한을 제공해야 합니다. 설치가 완료되면 설치 프로그램에서 사용자에게 이름별로 센서 권한을 요청하는 메시지를 표시합니다.
애플리케이션에서 사용자 위치를 알려면 이 위치에 액세스할 수 있는 권한이 필요합니다. 설치가 완료되면 애플리케이션에서 사용자의 위치에 액세스할 수 있는지 묻는 메시지를 설치 프로그램이 사용자에게 표시합니다. 사용자는 애플리케이션이 자신의 위치에 액세스하는 것을 원하지 않는다면 언제든지 '설정' 애플리케이션을 실행하고 '위치 및 보안'으로 이동하여 '무선 네트워크 사용' 및 'GPS 위성 사용'을 선택 해제할 수 있습니다. 이렇게 하면 사용자 기기에 있는 모든 애플리케이션의 위치 기반 서비스가 중지됩니다.
기기 메타데이터
또한 Android에서는 본질적으로 민감하지 않은 데이터에 액세스할 수 있는 권한을 제한하려고 노력하지만 사용자, 사용자 환경설정 및 사용자의 기기 사용 방식에 관한 특성을 간접적으로 드러낼 수 있습니다.
기본적으로 애플리케이션은 운영체제 로그, 브라우저 기록, 전화번호 또는 하드웨어/네트워크 식별 정보에 액세스할 수 있는 권한이 없습니다. 애플리케이션 설치 시 이 정보에 액세스할 수 있는 권한을 애플리케이션이 요청하면 설치 프로그램에서는 애플리케이션이 이 정보에 액세스할 수 있는지 묻는 메시지를 사용자에게 표시합니다. 사용자가 액세스 권한을 부여하지 않으면 애플리케이션이 설치되지 않습니다.
인증 기관
Android에는 시스템 전체적으로 신뢰할 수 있는 설치된 시스템 인증 기관의 집합이 포함되어 있습니다. Android 7.0 이전에는 기기 제조업체가 기기에 배송되는 CA 집합을 수정할 수 있었습니다. 그러나 7.0 이상을 실행하는 기기에는 기기 제조업체의 수정이 더 이상 허용되지 않으므로 동일한 시스템 CA 집합이 사용됩니다.
Android 스톡 집합에 새로운 공개 CA로 추가되려면 CA는 Mozilla CA 포함 프로세스를 완료한 후 Android에 기능 요청을 제출(https://code.google.com/p/android/issues/entry)하여 CA가 Android 오픈소스 프로젝트(AOSP)의 스톡 Android CA 집합에 추가되게 해야 합니다.
기기별로 되어 있고 핵심 AOSP CA 집합(예: SMS/MMS 게이트웨이와 같이 이동통신사의 인프라 구성요소에 안전하게 액세스하는 데 필요한 이동통신사의 비공개 CA)에 포함되어서는 안 되는 CA가 아직 있습니다. 기기 제조업체는 이러한 CA를 신뢰하는 데 필요한 구성요소/앱에만 비공개 CA를 포함하는 것이 좋습니다. 자세한 내용은 네트워크 보안 구성을 참조하세요.
애플리케이션 서명
개발자는 코드 서명을 사용하여 복잡한 인터페이스와 권한을 만들지 않고도 애플리케이션 작성자를 식별하고 애플리케이션을 업데이트할 수 있습니다. Android 플랫폼에서 실행되는 모든 애플리케이션은 개발자가 서명해야 합니다. 서명 없이 설치하려는 애플리케이션은 Google Play 또는 Android 기기의 패키지 설치 프로그램에서 거부됩니다.
Google Play에서는 애플리케이션 서명으로 Google의 개발자 신뢰와 개발자의 애플리케이션 신뢰가 연계됩니다. 개발자는 애플리케이션이 수정되지 않고 Android 기기에 제공된다는 점을 인지합니다. 따라서 애플리케이션의 동작에 개발자의 책임이 있다고 간주할 수 있습니다.
Android에서는 애플리케이션 서명이 애플리케이션을 애플리케이션 샌드박스에 배치하기 위한 첫 단계입니다. 서명된 애플리케이션 인증서는 어떤 사용자 ID가 어떤 애플리케이션에 연결되는지 정의합니다. 다른 애플리케이션은 다른 사용자 ID로 실행됩니다. 애플리케이션 서명으로 인해 애플리케이션은 제대로 정의된 IPC를 통하지 않고서는 다른 어떤 애플리케이션에도 액세스할 수 없게 됩니다.
애플리케이션(APK 파일)이 Android 기기에 설치되면 패키지 관리자는 APK가 APK에 포함된 인증서로 제대로 서명되었음을 확인합니다. 인증서(구체적으로는 인증서의 공개 키)가 기기의 다른 APK에 서명하는 데 사용된 키와 일치하면 새 APK에는 UID를 유사한 방식으로 서명된 다른 APK와 공유하겠다는 내용을 매니페스트에 명시할 수 있는 옵션이 있습니다.
애플리케이션은 타사(OEM, 운영자, 대체 시장)에서 서명하거나 자체 서명할 수 있습니다. Android에서는 개발자가 외부 지원 또는 권한 없이 생성할 수 있는 자체 서명된 인증서를 사용하는 코드 서명을 제공합니다. 중앙 기관에서 애플리케이션에 서명하지 않아도 됩니다. Android는 현재 애플리케이션 인증서에 CA 인증을 실행하지 않습니다.
또한 애플리케이션은 서명 보호 수준에서 보안 권한을 선언하여 액세스를 동일한 키로 서명된 애플리케이션으로 제한하는 동시에 고유한 UID 및 애플리케이션 샌드박스를 유지할 수 있습니다. 공유된 애플리케이션 샌드박스와의 긴밀한 관계는 공유된 UID 기능을 통해 가능합니다. 여기서는 동일한 개발자 키로 서명된 2개 이상의 애플리케이션이 공유 UID를 매니페스트에서 선언할 수 있습니다.
애플리케이션 인증
Android 4.2 이상에서는 애플리케이션 인증을 지원합니다. 사용자는 '앱 인증'을 사용하기로 선택하고 설치 전에 애플리케이션 인증 기관이 애플리케이션을 평가하게 할 수 있습니다. 사용자가 유해할 수 있는 앱을 설치하려 하면 앱 인증을 통해 사용자에게 이를 알릴 수 있습니다. 매우 불량한 애플리케이션이라면 설치를 차단할 수 있습니다.
디지털 권한 관리
Android 플랫폼에서는 콘텐츠와 관련된 라이선스 제약 조건에 따라 권한이 보호되는 콘텐츠를 애플리케이션에서 관리할 수 있도록 확장 가능한 DRM 프레임워크를 제공합니다. DRM 프레임워크에서는 여러 가지 DRM 체계를 지원합니다. 기기에서 지원하는 DRM 체계는 기기 제조업체에 따라 다릅니다.
Android DRM 프레임워크는 두 가지 아키텍처 레이어로 구현됩니다. 아래 그림을 참조하세요.
-
Android 애플리케이션 프레임워크를 통해 애플리케이션에 노출되고 표준 애플리케이션용 Dalvik VM을 통해 실행되는 DRM 프레임워크 API
-
DRM 프레임워크를 구현하고 다양한 DRM 체계의 권한 관리 및 복호화를 처리하기 위한 DRM 플러그인(에이전트)용 인터페이스를 노출하는 네이티브 코드 DRM 관리자