Application Sandbox는 안드로이드 (운영체제)가 앱을 기본적으로 서로 분리해 다루는 보안 경계다. 각 앱은 별도의 Linux 사용자 ID와 프로세스 공간을 받으며, 기본 상태에서는 다른 앱의 데이터나 시스템 자원에 임의로 접근할 수 없다.[1][2] 이 모델은 AOSP의 아키텍처와 Android framework의 권한 시스템 위에서 동작하지만, 그 자체가 앱의 기본 격리 단위다.[1][2]

1. 개요

Application Sandbox는 Android 보안 모델의 출발점이다. 앱은 설치될 때 고유한 시스템 정체성을 받고, 그 정체성 안에서 파일, 프로세스, IPC, 권한 요청이 해석된다.[1][2] 이 때문에 같은 제조사 기기라도 앱 하나가 다른 앱의 내부 저장소를 마음대로 읽거나 시스템 권한을 넘겨받을 수는 없다.[1]

2. 앱 격리 구조

Android는 앱마다 별도 UID와 보통 별도 프로세스를 할당해, 앱 데이터 디렉터리와 실행 컨텍스트를 분리한다.[1][2] 앱이 서로 통신할 수 있는 길은 기본적으로 제한적이며, 명시적 IPC, content provider, exported component, 서명 기반 권한처럼 시스템이 허용한 통로를 통해서만 열린다.[2][4] 이 구조 덕분에 한 앱의 침해가 곧바로 전체 기기 침해로 이어지지 않도록 경계가 생긴다.[1][4]

3. 권한 모델

Application Sandbox가 "접근 금지"를 기본값으로 둔다면, 권한 모델은 그 금지를 필요한 범위에서만 풀어 주는 장치다. 앱은 카메라, 위치, 연락처 같은 민감한 리소스에 접근하려면 선언과 사용자 승인을 거쳐야 하며, Android 6.0 이상에서는 위험 권한을 런타임에 요청한다.[3] 커스텀 권한과 서명 기반 권한도 같은 원리로, 동일한 샌드박스 안에서 특정 앱끼리만 신뢰 관계를 열어 주는 데 쓰인다.[2][3]

4. Android 보안 체계에서의 위치

Application Sandbox는 Verified Boot처럼 부팅 무결성을 보장하는 계층과도 다르고, Android framework가 제공하는 API 계층과도 다르다. 샌드박스는 앱 실행의 기본 경계이고, framework는 그 경계 안에서 앱이 어떤 API를 사용할 수 있는지 조율하며, Verified Boot는 기기 신뢰 체인을 부팅 시점부터 점검한다.[1][4] Android Enterprise Security White Paper는 이런 샌드박스, SELinux, Verified Boot 같은 계층이 함께 Android의 방어면을 이룬다고 설명한다.[1]

5. 사용자와 개발자 관점

사용자에게 Application Sandbox의 가치는 악성 앱이 다른 앱의 데이터를 쉽게 훔치지 못하게 하고, 권한 요청이 왜 필요한지 보여 주는 데 있다.[3][4] 개발자에게는 이 모델이 기본 전제다. 앱은 자기 데이터와 민감 기능을 최소 권한으로 설계해야 하고, 다른 앱과의 통합은 명시적 권한, 서명 키, 안전한 IPC를 통해 구성해야 한다.[2][4]

6. 관련 문서

7. 인용 및 각주

[1] Android Enterprise Security White Paper, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[2] Define a custom app permission, Android Developers, Ddeveloper.android.com(새 탭에서 열림)

[3] Request runtime permissions, Android Developers, Ddeveloper.android.com(새 탭에서 열림)

[4] Improve your app's security, Android Developers, Ddeveloper.android.com(새 탭에서 열림)