안드로이드 보안 모델

안드로이드 보안 모델의 기초는 리눅스 커널에 구축되어 있다. 안드로이드는 리눅스 커널을 하드웨어 추상화 계층으로 사용하며, 이 커널은 프로세스 격리, 메모리 보호, 사용자 및 그룹 기반의 파일 시스템 접근 제어와 같은 핵심 운영 체제 보안 기능을 제공한다. 각 애플리케이션은 별도의 사용자 ID를 부여받아 실행되며, 이는 리눅스 커널 수준에서 강제되는 프로세스 격리의 근간이 된다.

이러한 사용자 ID 기반의 격리는 애플리케이션 샌드박싱의 핵심 메커니즘이다. 커널은 각 애플리케이션을 서로 다른 사용자로 취급하여, 한 애플리케이션이 다른 애플리케이션의 데이터나 시스템 리소스에 무단으로 접근하는 것을 방지한다. 또한, 리눅스 커널의 표준 파일 권한 모델을 통해 애플리케이션의 사용자 데이터와 코드가 저장되는 내부 저장소 영역을 보호한다.

안드로이드는 시간이 지남에 따라 리눅스 커널의 보안 기능을 강화해 왔다. 특히 SELinux를 도입하여 기존의 임의적 접근 제어를 보완하는 강제적 접근 제어 정책을 적용했다. SELinux는 모든 프로세스와 파일에 대해 엄격한 정책을 정의하고 시행함으로써, 잠재적인 취약점이 악용되어도 시스템 피해를 제한하는 데 기여한다. 이는 모바일 보안을 위한 중요한 방어층을 추가한다.

따라서 리눅스 커널은 안드로이드의 다층적 보안 접근법의 첫 번째이자 가장 근본적인 층을 형성한다. 이 커널 기반 보안은 애플리케이션 간 격리를 보장하고, 시스템의 무결성을 유지하며, 상위 계층의 권한 시스템과 같은 다른 보안 구성 요소가 작동할 수 있는 안전한 토대를 마련한다.

응용 프로그램 샌드박싱은 안드로이드 운영 체제의 핵심 보안 원칙 중 하나로, 각 애플리케이션이 고립된 환경에서 실행되도록 설계된 보호 메커니즘이다. 이는 기본 거부 원칙에 기반하여, 애플리케이션이 명시적으로 권한을 부여받지 않은 시스템 리소스나 다른 애플리케이션의 데이터에 접근하는 것을 차단한다. 각 애플리케이션은 설치 시 고유한 리눅스 사용자 ID를 부여받아 프로세스 수준에서 격리되며, 이는 리눅스 커널이 제공하는 파일 시스템 권한과 프로세스 관리 기능을 통해 강제된다.

구체적으로, 샌드박싱은 애플리케이션의 코드와 데이터를 다른 앱과 분리하여, 한 앱이 손상되더라도 시스템 전체나 다른 앱으로의 피해 확산을 방지한다. 애플리케이션은 자체적인 데이터 저장소를 가지며, 권한 시스템을 통해 허가된 경우에만 카메라, 마이크, 연락처와 같은 특정 리소스에 접근할 수 있다. 이 격리 구조는 모바일 보안의 기본 토대를 형성하며, 사용자 개인정보 보호를 보장하는 데 필수적이다.

응용 프로그램 샌드박싱의 구현은 리눅스 커널 보안과 긴밀하게 연동된다. 커널은 각 애플리케이션 프로세스에 할당된 사용자 ID를 기반으로 파일과 시스템 호출에 대한 접근을 제어한다. 또한, SELinux와 같은 고급 보안 모듈이 도입되면서, 이 기본적인 격리 메커니즘은 더욱 세분화된 정책 기반의 강제 접근 제어로 강화되었다. 이를 통해 애플리케이션의 비정상적인 행동이나 권한 남용 시도를 추가적으로 차단할 수 있다.

이러한 샌드박스 모델은 애플리케이션 보안의 첫 번째 방어선 역할을 하지만, 완벽하지는 않다. 애플리케이션이 부여받은 권한을 악용하거나, 운영 체제나 펌웨어의 취약점을 통해 샌드박스를 우회하는 공격 가능성은 항상 존재한다. 따라서 안드로이드는 샌드박싱에 더해 Google Play Protect, 검증된 부팅 등 다층적 보안 체계를 구축하여 위협에 대응하고 있다.

안드로이드의 권한 시스템은 애플리케이션이 민감한 사용자 데이터나 특정 시스템 기능에 접근하기 위해 반드시 사용자의 명시적 허가를 받도록 설계된 핵심 보안 메커니즘이다. 이 시스템은 최소 권한의 원칙을 구현하여, 각 애플리케이션이 정상적으로 작동하는 데 필요한 최소한의 권한만을 부여받도록 한다. 기본적으로 모든 애플리케이션은 샌드박스 내에서 제한된 권한으로 실행되며, 카메라, 마이크, 연락처, 위치 정보 등 보호된 리소스에 접근하려면 반드시 해당 권한을 선언하고 사용자로부터 승인을 받아야 한다.

권한은 크게 일반 권한과 위험 권한으로 구분된다. 일반 권한은 사용자의 프라이버시나 기기 운영에 직접적인 위험을 초래하지 않는 접근(예: 인터넷 접근, 블루투스 사용)을 포함하며, 설치 시 자동으로 부여된다. 반면, 위험 권한은 사용자의 개인정보나 기기 기능에 민감한 영향을 미칠 수 있어, 안드로이드 6.0부터 도입된 런타임 권한 시스템을 통해 실행 중에 사용자에게 직접 허가를 요청해야 한다. 또한, 서명 권한이나 시스템 권한과 같이 특수한 권한도 존재한다.

애플리케이션이 권한을 획득하는 절차는 설치 시와 런타임 시 두 단계로 나뉜다. 개발자는 애플리케이션의 매니페스트 파일에 필요한 모든 권한을 미리 선언한다. 사용자가 구글 플레이 스토어나 다른 경로를 통해 앱을 설치할 때, 시스템은 선언된 권한 목록을 사용자에게 보여준다. 이후 앱 실행 중 위험 권한이 필요한 기능을 처음 사용하려 할 때, 시스템은 사용자에게 상황에 맞는 팝업 대화상자를 통해 다시 한번 허용 여부를 묻는다. 사용자는 설정 메뉴를 통해 언제든지 부여된 권한을 개별적으로 취소할 수 있다.

이러한 권한 시스템은 사용자에게 애플리케이션의 행동을 투명하게 알리고 통제권을 부여함으로써 사용자 데이터 보호를 강화한다. 그러나 사용자의 권한 허용 결정에 의존하기 때문에, 사회 공학적 기법을 통한 권한 오남용이나 지나치게 많은 권한을 요구하는 애플리케이션의 문제는 지속적인 관리 과제로 남아있다.

안드로이드의 권한 시스템은 애플리케이션이 민감한 사용자 데이터나 특정 시스템 기능에 접근하기 위해 반드시 명시적으로 요청하고 사용자로부터 허가를 받아야 하는 보안 메커니즘이다. 이 시스템은 최소 권한의 원칙을 구현하여, 각 애플리케이션이 정상적으로 작동하는 데 필요한 최소한의 권한만을 부여받도록 설계되었다. 권한은 보호 수준과 부여 시기에 따라 크게 일반 권한, 서명 권한, 런타임 권한 등으로 분류된다.

일반 권한은 애플리케이션의 핵심 기능에 직접적인 영향을 미치지 않는 낮은 위험 수준의 권한이다. 예를 들어, 인터넷 접근이나 블루투스 사용과 같은 권한이 이에 해당하며, 안드로이드 6.0 마시멜로 이전 버전에서는 설치 시 묵시적으로 부여되었다. 서명 권한은 높은 수준의 보호가 필요한 권한으로, 권한을 정의한 애플리케이션과 동일한 디지털 인증서로 서명된 애플리케이션에게만 자동으로 부여된다. 이는 시스템 애플리케이션이나 동일 개발자 그룹의 애플리케이션 간에 제한된 리소스를 안전하게 공유할 수 있게 한다.

안드로이드 6.0 마시멜로부터 도입된 런타임 권한은 가장 중요한 변화 중 하나로, 카메라, 연락처, 위치 정보, 마이크, 저장 공간 접근 등과 같은 위험 권한을 관리한다. 이 권한들은 애플리케이션 설치 시가 아니라, 해당 기능이 실제로 필요한 시점에 사용자에게 요청하고 부여받는다. 사용자는 애플리케이션 설정을 통해 런타임 권한을 개별적으로 허용하거나 거부할 수 있으며, 필요 시 언제든지 취소할 수도 있다. 이는 사용자에게 더 큰 통제권을 부여하고, 애플리케이션이 불필요한 데이터 수집을 하지 못하도록 제한하는 데 핵심적이다.

권한 시스템의 핵심은 사용자가 애플리케이션이 요청하는 권한을 명시적으로 인지하고 허용하는 절차에 있다. 이 절차는 안드로이드 버전에 따라 진화해왔으며, 특히 안드로이드 6.0 (API 레벨 23)에서 도입된 런타임 권한 시스템이 중요한 전환점이 되었다.

안드로이드 6.0 이전에는 애플리케이션 설치 시점에 모든 권한을 한 번에 요청하고 사용자가 이를 일괄 승인해야 했다. 이 방식은 사용자가 특정 권한의 필요성을 제대로 이해하지 못한 채 설치를 진행할 수 있다는 문제가 있었다. 반면, 런타임 권한 시스템에서는 애플리케이션이 실제로 해당 기능(예: 카메라 접근, 위치 정보 조회)을 사용하려는 순간에만 권한을 요청한다. 이로 인해 사용자는 권한이 필요한 맥락을 더 명확히 이해하고, 필요에 따라 개별 권한을 허용하거나 거부할 수 있게 되었다.

권한 요청 및 부여 절차는 일반적으로 다음과 같은 흐름으로 진행된다. 먼저, 개발자는 애플리케이션의 매니페스트 파일에 필요한 권한을 선언한다. 애플리케이션이 실행되어 보호된 리소스에 접근해야 할 때, 시스템은 사용자에게 권한 허용을 요청하는 대화상자를 표시한다. 사용자는 '허용' 또는 '거부'를 선택할 수 있으며, 일부 권한의 경우 '다시 묻지 않음' 옵션을 선택하여 영구적으로 거부할 수도 있다. 사용자가 권한을 거부하면 애플리케이션은 해당 기능을 사용할 수 없으며, 이에 대비한 대체 동작을 제공해야 한다.

이러한 런타임 권한 모델은 최소 권한의 원칙을 더 효과적으로 구현하며, 사용자에게 더 세밀한 제어권을 부여한다. 사용자는 설정 메뉴를 통해 애플리케이션별로 부여된 권한을 언제든지 확인하고 취소할 수 있다. 또한, Google Play Protect와 같은 서비스는 권한을 남용하거나 위험한 패턴을 보이는 애플리케이션을 식별하는 데 도움을 준다.

사용자는 설치된 애플리케이션의 권한을 언제든지 관리하고 취소할 수 있다. 안드로이드 6.0 (API 레벨 23)부터 도입된 런타임 권한 시스템은 사용자에게 설치 시가 아닌, 해당 기능이 실제로 필요한 시점에 권한을 요청하고 부여받도록 하여 최소 권한의 원칙을 강화한다. 사용자는 시스템 설정의 '앱' 메뉴를 통해 각 애플리케이션에 부여된 권한 목록을 확인하고, 카메라나 위치 정보 접근과 같은 개별 권한을 선택적으로 해제할 수 있다.

권한이 취소되면 해당 애플리케이션은 그 기능에 더 이상 접근할 수 없으며, 이는 샌드박스 격리 메커니즘에 의해 강제된다. 애플리케이션이 취소된 권한이 필요한 API를 호출하려고 하면 시스템은 권한 부여를 거부하거나 빈 데이터를 반환하여 사용자 개인정보 보호를 보장한다. 일부 시스템 권한이나 서명 권한과 같이 높은 수준의 권한은 일반 사용자가 취소할 수 없도록 설계되어 있다.

사용자 중심의 권한 관리 외에도, 구글 플레이 스토어와 같은 앱 배포 플랫폼은 정기적인 스캔을 통해 위험한 권한 패턴을 가진 애플리케이션을 식별하고 사용자에게 경고한다. 또한, 개발자는 안드로이드 가이드라인에 따라 애플리케이션이 권한이 거부된 상황에서도 정상적으로 작동하거나 적절히 대체할 수 있도록 예외 처리를 구현해야 한다. 이는 사용자 경험을 유지하면서 보안과 프라이버시를 존중하는 데 중요하다.

응용 프로그램 서명은 안드로이드 운영 체제에서 앱의 출처와 무결성을 검증하는 핵심 메커니즘이다. 모든 APK 파일은 개발자가 소유한 디지털 인증서로 서명되어야만 기기에 설치 및 업데이트될 수 있다. 이 서명의 주요 목적은 앱의 저자를 식별하고, 앱이 배포 후 변조되지 않았음을 보장하는 것이다. 이를 통해 시스템은 동일한 개발자로부터 온 앱임을 확인하고, 신뢰할 수 없는 출처의 앱이 시스템을 위협하는 것을 방지할 수 있다.

서명의 가장 중요한 역할 중 하나는 앱 간의 신뢰 관계와 데이터 공유를 관리하는 것이다. 안드로이드는 동일한 서명 키로 서명된 앱들에 한해 리눅스 수준의 사용자 ID를 공유하도록 허용한다. 이는 샌드박스로 격리된 앱들이 서로의 데이터와 코드 리소스에 접근할 수 있게 해주며, 하나의 기능을 여러 앱으로 분리하거나 앱을 모듈화하는 데 필수적이다. 또한, 앱의 업데이트는 반드시 원본 앱과 동일한 서명 키로 서명되어야 하며, 그렇지 않으면 설치가 거부된다. 이는 앱이 악의적인 제3자에 의해 가로채어 변조된 버전으로 대체되는 것을 방지한다.

서명 키의 관리와 보안은 개발자의 책임이다. 구글이나 안드로이드 시스템은 개발자의 개인 키를 보관하지 않는다. 따라서 서명 키를 분실하면 해당 키로 서명된 앱을 공식적으로 업데이트할 수 없게 되며, 키가 유출되면 악의적 행위자가 정품 앱을 사칭할 수 있는 위험이 생긴다. 이는 서명이 단순한 기술적 절차를 넘어, 앱의 생명주기와 신뢰성을 유지하는 데 있어 근본적인 중요성을 갖게 한다.

안드로이드에서 모든 애플리케이션은 개발자가 생성한 디지털 인증서로 서명되어야 한다. 이 서명 과정에는 애플리케이션의 모든 구성 요소를 해시 알고리즘으로 요약한 후, 개발자의 개인 키로 암호화하여 서명 파일을 생성하는 작업이 포함된다. 이 서명은 애플리케이션의 출처와 무결성을 보장하는 근간이 된다. 시스템은 애플리케이션을 설치하거나 업데이트할 때마다 공개 키를 포함한 디지털 인증서를 사용해 서명을 검증한다.

서명에 사용되는 키와 인증서는 공식적인 공개 키 기반 구조를 통해 발급받는 것이 아니라, 개발자가 자체적으로 생성한다. 안드로이드 스튜디오와 같은 개발 도구는 개발 과정에서 디버그용 서명 키를 자동으로 생성해 준다. 그러나 앱 스토어에 출시할 앱은 반드시 개발자가 안전하게 보관한 고유한 릴리스 키로 서명해야 한다. 이 릴리스 키는 애플리케이션의 신원을 대표하며, 키를 분실하면 동일한 패키지명으로 앱을 업데이트할 수 없게 된다.

애플리케이션 서명은 몇 가지 중요한 보안 및 기능적 목적을 수행한다. 첫째, 서명은 앱의 저자를 식별하고 앱이 설치 후 변조되지 않았음을 보장한다. 둘째, 동일한 키로 서명된 애플리케이션 간에는 신뢰 관계가 형성되어, 공유 사용자 ID를 설정하거나 앱 간 통신에서 특정 권한을 공유할 수 있다. 또한 서명 권한을 정의하여 다른 앱이 자신의 구성 요소에 접근하는 것을 제어하는 데에도 활용된다.

안드로이드의 파일 시스템 보안은 그 기반이 되는 리눅스 커널의 파일 권한 모델을 상속한다. 각 파일과 디렉터리는 소유자(사용자), 그룹, 그리고 기타 사용자에 대한 읽기, 쓰기, 실행 권한을 정의하는 고전적인 유닉스 스타일 권한 비트를 가진다. 안드로이드에서는 이 모델이 애플리케이션 샌드박스와 결합되어 강력한 격리를 구현한다.

안드로이드 시스템은 설치된 각 애플리케이션에 고유한 리눅스 사용자 ID (UID)를 할당한다. 애플리케이션이 생성하는 파일의 소유자는 기본적으로 이 UID로 설정되며, 다른 애플리케이션은 기본적으로 해당 파일에 접근할 수 없다. 이는 애플리케이션 데이터가 시스템 수준에서 자동으로 다른 앱으로부터 보호되도록 한다. 애플리케이션 간 데이터 공유는 명시적으로 파일 권한을 수정하거나 콘텐츠 프로바이더와 같은 안드로이드 고유의 메커니즘을 통해 이루어진다.

파일 시스템의 보안은 내부 저장소와 외부 저장소에서 다르게 적용된다. 내부 저장소에 저장된 애플리케이션의 전용 데이터는 해당 앱의 UID로 보호되어 다른 앱이나 사용자가 직접 접근하는 것이 제한된다. 반면, SD 카드와 같은 외부 저장소는 전통적인 포터블 저장 매체로 설계되어, 기본적으로 모든 애플리케이션이 읽고 쓸 수 있는 공유 공간이다. 따라서 외부 저장소에 민감한 데이터를 저장할 때는 애플리케이션 수준에서 추가적인 암호화를 적용하는 것이 권장된다.

안드로이드는 애플리케이션 데이터의 보안과 무결성을 유지하기 위해 저장 공간을 내부 저장소와 외부 저장소로 구분한다. 이 구분은 파일 시스템 수준의 접근 제어를 통해 구현되며, 각 저장 공간마다 다른 보안 정책이 적용된다.

내부 저장소는 각 애플리케이션의 전용 샌드박스 디렉터리로, 기본적으로 해당 애플리케이션만 접근할 수 있다. 리눅스 커널의 파일 권한 시스템을 기반으로 하여, 애플리케이션이 설치될 때 할당된 고유한 사용자 식별자와 그룹 식별자로 디렉터리가 보호된다. 따라서 다른 애플리케이션이나 사용자가 직접 내부 저장소의 파일에 접근하는 것은 기본적으로 차단된다. 이 공간은 애플리케이션의 민감한 데이터나 코드를 저장하는 데 적합하다.

반면, 외부 저장소는 일반적으로 SD 카드와 같은 이동식 미디어나 장치 내 에뮬레이트된 공간을 지칭한다. 이 공간은 상대적으로 개방되어 있어, 사용자가 파일 관리자를 통해 직접 접근하거나 여러 애플리케이션이 데이터를 공유할 수 있다. 안드로이드 4.4(KitKat)부터는 애플리케이션이 외부 저장소의 특정 하위 디렉터리에만 쓰기 접근이 가능하도록 제한되었으며, 안드로이드 11부터 도입된 범위 지정 저장소는 외부 저장소 접근에 대한 제어를 더욱 강화했다. 이제 애플리케이션은 미디어 스토어 API를 통해 공용 미디어 파일에 접근하거나, 시스템 파일 선택기를 통해 사용자 승인 하에 특정 파일에만 접근할 수 있다.

이러한 이분법은 보안과 유연성 사이의 균형을 목표로 한다. 내부 저장소는 강력한 격리를 통해 애플리케이션과 사용자 데이터를 보호하는 데 중점을 두는 반면, 외부 저장소는 사용자 중심의 데이터 이동과 공유를 가능하게 한다. 개발자는 데이터의 민감도에 따라 적절한 저장 위치를 선택해야 하며, 외부 저장소에 저장된 데이터는 기본적으로 다른 애플리케이션이나 사용자에게 노출될 수 있음을 인지해야 한다.

안드로이드는 네트워크 통신의 기밀성과 무결성을 보장하기 위해 SSL과 TLS 프로토콜을 광범위하게 지원한다. 애플리케이션은 HTTPS를 통해 서버와 안전하게 통신할 수 있으며, 시스템은 신뢰할 수 있는 인증 기관의 루트 인증서 목록을 기본적으로 제공한다. 이를 통해 중간자 공격을 방지하고 데이터 전송 과정의 안전성을 확보한다.

안드로이드 7.0부터는 기본 네트워크 보안 구성이 도입되어, 명시적으로 구성하지 않은 애플리케이션도 안전한 통신 설정을 기본값으로 사용하게 된다. 이 구성은 신뢰할 수 없는 인증서를 기본적으로 거부하고, TLS 1.2 이상의 강력한 프로토콜을 선호하도록 설정되어 있다. 개발자는 필요에 따라 자체 네트워크 보안 구성 파일을 정의하여 특정 도메인에 대한 인증서 핀닝을 설정하거나 신뢰할 수 있는 인증서를 추가할 수 있다.

앱 번들러나 프록시 서버를 사용하는 기업 환경과 같은 특수한 경우를 위해, 사용자는 기기 설정에서 사용자 인증서를 설치할 수 있다. 또한, 개발자는 앱의 매니페스트 파일에서 특정 보안 구성을 선언하거나, 코드 내에서 SSLSocket 및 SSLContext와 같은 API를 직접 사용하여 세밀한 네트워크 보안 정책을 구현할 수 있다. 이러한 다층적인 접근 방식은 다양한 사용 시나리오에서 안전한 통신을 가능하게 한다.

안드로이드는 사용자 데이터의 기밀성을 보호하기 위해 강력한 암호화 기술을 제공한다. 주요 암호화 방식으로는 전체 디스크 암호화(Full-Disk Encryption, FDE)와 파일 기반 암호화(File-Based Encryption, FBE)가 있다. 전체 디스크 암호화는 안드로이드 5.0(롤리팝)에서 처음 도입되어 장치의 모든 사용자 데이터 파티션을 잠금 화면 자격 증명(비밀번호, PIN, 패턴 등)에서 파생된 단일 키로 암호화한다. 이 방식은 장치가 부팅될 때 사용자 인증 정보를 입력해야만 데이터에 접근할 수 있게 하여, 장치 분실이나 도난 시 물리적 접근으로부터 데이터를 보호한다.

안드로이드 7.0(누가)부터는 더욱 유연하고 사용자 친화적인 파일 기반 암호화가 도입되었다. 파일 기반 암호화는 각 파일을 독립적인 키로 암호화할 수 있게 하여, 장치가 재부팅된 후에도 특정 파일(예: 알림 소리, 접근성 설정 등)에 접근할 수 있는 직접 부팅(Direct Boot) 기능을 지원한다. 이는 사용자가 잠금 화면을 해제하기 전에도 알람 시계나 전화 수신과 같은 핵심 기능이 작동할 수 있도록 한다. 파일 기반 암호화는 각 애플리케이션의 데이터를 해당 애플리케이션과 사용자 프로필에 고유한 키로 보호함으로써 샌드박스 보안 모델을 강화한다.

이러한 암호화 체계의 핵심은 안전한 키 저장이다. 안드로이드는 하드웨어 보안 모듈(HSM)이나 신뢰 실행 환경(TEE)과 같은 전용 하드웨어 보안 칩을 활용하여 암호화 키를 보호한다. 이 하드웨어 기반 키 저장소는 암호화 키가 장치의 메인 운영 체제 밖에서 생성, 저장, 처리되도록 하여, 소프트웨어 공격으로부터 키를 격리시킨다. 사용자의 잠금 화면 자격 증명은 이 하드웨어 보안 영역에서 키를 해제하는 데 직접 사용되지 않으며, 대신 자격 증명을 검증한 후에만 키가 해제되는 방식으로 설계되어 보안을 한층 강화한다.

안드로이드에서 안전한 키 저장은 민감한 암호화 키를 하드웨어 기반 보안 영역에 보관하여 애플리케이션 프로세스 자체로부터도 보호하는 메커니즘이다. 이는 키가 운영 체제 수준에서 유출되거나 악성 애플리케이션에 의해 탈취되는 것을 방지하는 데 핵심적이다. 주요 구현 방식으로는 키 저장소 시스템과 하드웨어 백업 키 저장소가 있다. 키 저장소 시스템은 안드로이드 프레임워크가 제공하는 API로, 애플리케이션이 비대칭 키 쌍이나 대칭 키를 생성하고 안전하게 저장할 수 있게 한다. 이 시스템은 키 자료에 대한 접근을 엄격히 통제하며, 키 사용은 가능하지만 직접적인 키 추출은 허용하지 않는다.

보다 강력한 보안을 위해서는 하드웨어 백업 키 저장소를 활용한다. 이 기능은 신뢰 실행 환경 또는 전용 보안 하드웨어(예: 타이젠 보안 요소) 내에 키를 저장한다. 키의 생성, 저장, 사용이 모두 이 보안 칩 내에서 이루어지므로, 심지어 루트 권한을 획득한 공격이나 메인 운영 체제가 손상된 경우에도 키를 보호할 수 있다. 하드웨어 백업 키 저장소는 기기 인증, 강력한 사용자 인증이 필요한 키 저장, 금융 거래 보안 등 높은 보안이 요구되는 시나리오에 필수적이다.

개발자는 KeyStore 클래스와 KeyGenParameterSpec 빌더를 사용하여 키를 생성하고 보호 수준을 지정할 수 있다. 여기서 키의 보호 수준을 KeyProperties.PURPOSE_ENCRYPT 또는 KeyProperties.PURPOSE_SIGN 같은 용도와 함께 KeyProtection 플래그로 정의하며, 하드웨어 백업 저장소 사용 여부를 setIsStrongBoxBacked(true)와 같은 메서드로 명시할 수 있다. 이렇게 저장된 키는 암호화 작업 수행 시 애플리케이션에 노출되지 않은 채 보안 하드웨어 내에서 직접 연산된다.

안전한 키 저장은 애플리케이션의 자체 비밀번호나 토큰을 보호하는 데에도 적용된다. 안드로이드 키체인 공급자를 사용하면 애플리케이션 간에 공유될 수 있는 민감한 자격 증명을 안전하게 저장하고 관리할 수 있다. 전반적으로, 안드로이드의 안전한 키 저장 체계는 모바일 보안의 핵심 기둥으로, 엔드투엔드 암호화와 데이터 무결성을 구현하는 데 필요한 기반을 제공한다.

Google Play Protect는 안드로이드 기기의 기본적인 보안을 강화하기 위해 구글에서 제공하는 통합 보안 서비스이다. 이 서비스는 기기에 설치된 모든 애플리케이션을 지속적으로 스캔하고, 악성 소프트웨어나 잠재적으로 유해한 애플리케이션을 탐지하여 사용자를 보호하는 것을 목표로 한다. Google Play 스토어를 통해 앱을 설치할 때뿐만 아니라, 기기 내부에 이미 존재하는 앱들도 정기적으로 검사한다.

Google Play Protect의 주요 기능은 크게 두 가지로 나눌 수 있다. 첫째는 Google Play 스토어에서 다운로드되기 전 앱을 사전에 검사하는 것이다. 둘째는 기기에 이미 설치된 앱을 지속적으로 모니터링하고, 의심스러운 행동이 감지되면 사용자에게 경고를 제공하거나 해당 앱을 자동으로 제거하는 것이다. 이 서비스는 백그라운드에서 자동으로 작동하며, 사용자의 별도 조작 없이도 보호 기능을 제공한다.

이 서비스는 클라우드 컴퓨팅 기반의 위협 인텔리전스를 활용한다. 구글은 전 세계 수십억 대의 안드로이드 기기에서 수집된 데이터를 분석하여 새로운 위협을 빠르게 식별하고, 이 정보를 바탕으로 모든 사용자의 기기를 보호한다. 이를 통해 악성코드나 피싱 앱과 같은 신종 위협에도 대응할 수 있다.

Google Play Protect는 대부분의 안드로이드 기기에 기본적으로 탑재되어 있으며, 사용자는 Google Play 스토어 앱의 설정 메뉴에서 이 서비스의 상태를 확인할 수 있다. 이는 안드로이드의 다층적 보안 모델, 특히 애플리케이션 샌드박싱 및 권한 시스템과 함께 작동하여 사용자 데이터 보호를 위한 추가적인 안전망 역할을 한다.

안전한 부팅은 안드로이드 기기의 부팅 과정이 신뢰할 수 있는 소프트웨어로만 이루어지도록 보장하는 체계이다. 이 과정은 ROM에 하드코딩된 루트 키로 검증된 부트로더부터 시작하여, 부트로더가 다음 단계인 커널과 시스템 파티션을 검증하는 방식으로 이어진다. 각 단계의 소프트웨어는 암호학적으로 서명되어 있으며, 서명 검증에 실패하면 부팅이 중단되거나 제한된 모드로 진입하여 시스템 무결성을 보호한다.

검증된 부팅은 안전한 부팅의 연장선상에 있으며, 시스템이 실행 중일 때도 지속적으로 무결성을 확인하는 프로세스이다. 커널은 dm-verity와 같은 기술을 통해 시스템 파티션의 모든 데이터 블록을 검증한다. 사용자나 애플리케이션이 시스템 파일을 읽으려고 할 때, 해당 데이터 블록의 암호화 해시 값이 신뢰할 수 있는 값과 일치하는지 실시간으로 확인한다. 이를 통해 악성 코드에 의해 시스템 파일이 변조되는 것을 방지한다.

이러한 부팅 시 및 런타임 검증 메커니즘은 루팅이나 알려지지 않은 펌웨어 설치와 같은 무단 시스템 변경을 효과적으로 차단한다. 결과적으로 악성 소프트웨어가 저수준 시스템에 침투하거나 지속성을 확보하는 것을 어렵게 만든다. 안전한 부팅과 검증된 부팅은 안드로이드의 보안 모델을 구성하는 중요한 기반 기술로, 리눅스 커널 보안 및 SELinux와 같은 다른 보안 계층과 함께 다층 방어 체계를 완성한다.

SELinux(Security-Enhanced Linux)는 리눅스 커널에 강제 접근 제어(Mandatory Access Control, MAC)를 구현하는 보안 모듈이다. 안드로이드는 4.3 버전부터 SELinux를 채택하여 기존의 리눅스 커널 보안과 응용 프로그램 샌드박싱을 보완하는 강력한 보안 계층을 추가했다. SELinux는 시스템의 모든 프로세스와 파일에 보안 정책을 적용하여, 권한이 탈취되거나 악의적인 애플리케이션이 시스템을 손상시키는 것을 방지한다.

안드로이드에서 SELinux는 두 가지 주요 모드로 운영된다. 첫 번째는 '허용 모드'로, 정책 위반 사항을 로그로만 기록하고 차단하지 않아 초기 배포와 정책 개발에 사용된다. 두 번째는 '강제 모드'로, 정의된 보안 정책을 엄격하게 적용하여 모든 위반 시도를 차단한다. 안드로이드 5.0 이상의 최신 기기들은 대부분 이 강제 모드로 운영되어, 시스템 데몬과 샌드박스 간의 상호작용을 세밀하게 통제한다.

SELinux의 정책은 각 프로세스(주체)와 파일(객체)에 '보안 컨텍스트'라는 레이블을 부여하여 관리한다. 이 컨텍스트는 사용자, 역할, 타입, 수준(MLS) 정보를 포함한다. 안드로이드는 주로 '타입 강제' 정책을 사용하는데, 이는 특정 타입의 프로세스가 특정 타입의 객체(예: 파일, 소켓)에만 접근할 수 있도록 규정한다. 예를 들어, 카메라 서비스 프로세스는 카메라 장치 파일에만 접근할 수 있고, 다른 애플리케이션의 데이터에는 접근할 수 없도록 제한된다.

이러한 SELinux의 도입은 안드로이드의 기본 보안 구조를 한층 견고하게 만들었다. 특히 루팅이나 커널 취약점을 악용한 공격으로부터 시스템을 보호하는 데 핵심적인 역할을 한다. SELinux 정책은 기기 제조사와 구글이 협력하여 정의하며, 안전한 부팅 및 검증된 부팅 체인과 결합되어 시스템 무결성을 종단간으로 유지한다.