보안 구현

Android 보안팀은 Android 기기에서 발생할 수 있는 보안 문제의 방지에 관한 정보를 정기적으로 요청받습니다. 또한 때때로 기기를 무작위로 추출하여 검사하고 기기 제조업체와 영향을 받는 파트너에게 발생할 가능성이 있는 문제를 알립니다.

Android 보안팀이 개발자에게 제공한 보안을 위한 디자인 문서의 연장선상에서 이 페이지에는 팀의 경험을 바탕으로 한 보안 권장사항이 정리되어 있습니다. 아울러 기기의 시스템 수준 소프트웨어 빌드 또는 설치에 관한 세부정보도 포함되어 있습니다.

이 권장사항을 쉽게 채택할 수 있도록 Android 보안팀은 가능한 경우 테스트를 Android 호환성 테스트 도구 모음(CTS) 및 Android 린트에 통합합니다. 기기 구현자는 다른 Android 사용자에게 도움이 되는 테스트를 제공하는 것이 좋습니다(root/cts/tests/tests/security/src/android/security/cts에서 보안 관련 테스트 확인).

개발 프로세스

개발 프로세스 및 환경에서 다음 권장사항을 참조하세요.

소스 코드 검토

소스 코드 검토를 통해 이 문서에 설명된 문제를 비롯한 광범위한 보안 문제를 알아낼 수 있습니다. Android에서는 수동 및 자동 소스 코드 검토를 모두 실행할 것을 적극 권장합니다. 권장사항

• Android SDK를 사용하여 모든 애플리케이션 코드에서 Android 린트를 실행하여 식별된 문제를 모두 교정하세요.
• 네이티브 코드는 버퍼 오버플로우, OBO(Off-By-One) 오류 등 메모리 관리 문제를 감지할 수 있는 자동화 도구를 사용하여 분석해야 합니다.
• Android 빌드 시스템은 이러한 목적으로 사용할 수 있는 AddressSanitizer, UndefinedBehaviorSanitizer와 같은 여러 LLVM 새니타이저를 지원합니다.

자동 테스트 사용

자동 테스트를 통해 아래에 설명된 몇 가지 문제를 비롯하여 광범위한 보안 문제를 감지할 수 있습니다. 권장사항

• CTS는 보안 테스트를 통해 정기적으로 업데이트됩니다. 최신 버전의 CTS를 실행하여 호환성을 확인하세요.
• CTS를 개발 프로세스 전반에 걸쳐 정기적으로 실행하여 문제를 조기에 발견하고 교정 시간을 줄이세요. Android에서는 하루에 여러 번 빌드되는 자동 빌드 프로세스에서 CTS를 지속적인 통합의 일부로 사용합니다.
• 기기 제조업체는 잘못된 형식의 입력으로 테스트(퍼징 테스트)하는 등 인터페이스 보안 테스트를 자동화해야 합니다.

시스템 이미지 서명

시스템 이미지 서명은 기기의 무결성을 확인하는 데 매우 중요합니다. 권장사항

• 공개적으로 알려진 키로 기기에 서명해서는 안 됩니다.
• 감사 가능한 제한적인 액세스를 제공하는 HSM(하드웨어 보안 모듈) 등 민감한 키 취급을 위한 업계 표준 관행과 일치하는 방식으로 기기 서명에 사용되는 키를 관리해야 합니다.

애플리케이션(APK) 서명

애플리케이션 서명은 기기 보안에 중요한 역할을 하며 권한 확인뿐 아니라 소프트웨어 업데이트에도 사용됩니다. 애플리케이션 서명에 사용할 키를 선택할 때 애플리케이션이 단일 기기에서만 사용되는지, 아니면 여러 기기에서 공통으로 사용되는지 여부를 고려하는 것이 중요합니다. 권장사항

• 공개적으로 알려진 키로 애플리케이션에 서명해서는 안 됩니다.
• 감사 가능한 제한적인 액세스를 제공하는 HSM(하드웨어 보안 모듈) 등 민감한 키 취급을 위한 업계 표준 관행과 일치하는 방식으로 애플리케이션 서명에 사용되는 키를 관리해야 합니다.
• 플랫폼 키로 애플리케이션에 서명해서는 안 됩니다.
• 패키지 이름이 같은 애플리케이션에 여러 키로 서명해서는 안됩니다. 이러한 오류는 특히 플랫폼 키를 사용하는 경우 다양한 기기에 사용할 애플리케이션을 만들 때 발생합니다. 애플리케이션이 기기 독립적이라면 기기 전체에 동일한 키를 사용하세요. 애플리케이션이 기기마다 다르다면 기기 및 키에 따라 고유한 패키지 이름을 만드세요.

애플리케이션 게시

Google Play는 전체 시스템 업데이트를 실행하지 않고도 애플리케이션을 업데이트할 수 있는 기능을 기기 제조업체에 제공합니다. 이를 통해 보안 문제 대응 및 새 기능 제공 속도가 빨라질 뿐 아니라 애플리케이션에 고유한 패키지 이름이 지정되게 하는 방법을 제공할 수 있습니다. 권장사항

• Google Play에 애플리케이션을 업로드하여 전체 무선 업데이트(OTA)가 필요 없는 자동 업데이트를 받으세요. 업로드되었으나 게시되지 않은 애플리케이션은 사용자가 직접 다운로드할 수 없지만 계속 업데이트됩니다. 이전에 앱을 설치한 사용자는 앱을 다시 설치하거나 다른 기기에 설치할 수 있습니다.
• 회사와 명확하게 연관된 애플리케이션 패키지 이름을 만드세요(예: 회사 상표 사용).
• 타사 사용자의 패키지 이름 도용을 방지하기 위해 기기 제조업체가 게시한 애플리케이션을 Google Play 스토어에 업로드해야 합니다. 기기 제조업체가 Play 스토어에 앱을 게시하지 않고 기기에 앱을 설치하면 다른 개발자가 동일한 앱을 업로드하고 동일한 패키지 이름을 사용하며 앱의 메타데이터를 변경할 수 있습니다. 앱이 사용자에게 표시될 때 이처럼 관련 없는 메타데이터는 혼동을 일으킬 수 있습니다.

사고 대응

외부 당사자는 기기별 보안 문제에 관해 기기 제조업체에 문의할 수 있어야 합니다. 보안 사고 관리를 위해 공개적으로 액세스할 수 있는 이메일 주소를 만드는 것이 좋습니다. 권장사항

• security@your-company.com 또는 이와 유사한 주소를 만들어 공개하세요.
• 여러 기기 제조업체의 Android OS 또는 Android 기기에 영향을 주는 보안 문제를 발견하면 보안 버그 신고를 제출하여 Android 보안팀에 문의해야 합니다.

제품 구현

제품을 구현할 때 다음 권장사항을 따르세요.

루트 프로세스 분리

루트 프로세스는 가장 빈번하게 권한 에스컬레이션 공격의 대상이 되므로 루트 프로세스의 수를 줄이면 권한 에스컬레이션의 위험이 줄어듭니다. CTS에는 루트 프로세스를 나열하는 정보 테스트가 포함됩니다. 권장사항

• 기기에서는 필요한 최소한의 코드를 루트로 실행해야 합니다. 가능하다면 루트 프로세스가 아닌 일반 Android 프로세스를 사용하세요. ICS Galaxy Nexus에는 vold, inetd, zygote, tf_daemon, ueventd, init의 6가지 루트 프로세스만 있습니다. 프로세스를 기기에서 루트로 실행해야 한다면 프로세스를 AOSP 기능 요청에 문서화하여 공개적으로 검토할 수 있습니다.
• 가능하다면 루트 코드를 신뢰할 수 없는 데이터와 분리하고 IPC를 통해 액세스해야 합니다. 예를 들어 루트 기능을 바인더를 통해 액세스할 수 있는 작은 서비스로 축소하고, 서명 권한이 있는 서비스를 네트워크 트래픽을 처리할 권한이 없거나 수준이 낮은 애플리케이션에 노출합니다.
• 루트 프로세스는 네트워크 소켓에서 수신 대기하면 안 됩니다.
• 루트 프로세스는 애플리케이션에 범용 런타임을 제공해서는 안 됩니다(예: 자바 VM).

시스템 앱 분리

일반적으로 사전 설치된 앱은 공유 시스템 UID로 실행하면 안 됩니다. 하지만 앱이 시스템의 공유 UID 또는 다른 권한 있는 서비스(예: 전화)를 사용해야 한다면 사용자가 설치한 타사 앱에서 액세스할 수 있는 서비스, broadcast receiver 또는 콘텐츠 제공업체를 앱에서 내보내면 안 됩니다. 권장사항

• 기기에서는 필요한 최소한의 코드를 시스템으로 실행해야 합니다. 가능하다면 시스템 UID를 재사용하기보다는 자체 UID가 있는 Android 프로세스를 사용하세요.
• 가능하다면 신뢰할 수 없는 데이터에서 시스템 코드를 분리하고 다른 신뢰할 수 있는 프로세스에만 IPC를 노출해야 합니다.
• 시스템 프로세스는 네트워크 소켓을 수신하면 안 됩니다.

프로세스 분리

Android 애플리케이션 샌드박스는 루트 프로세스 및 디버거를 비롯한 시스템의 다른 프로세스와 격리될 것이라는 예상을 애플리케이션에 제공합니다. 애플리케이션과 사용자가 디버깅을 특별히 활성화하지 않는 한 애플리케이션이 이러한 예상을 위반해서는 안 됩니다. 권장사항

• 루트 프로세스는 문서화된 Android 디버깅 메서드를 사용하지 않는 한 개별 애플리케이션 데이터 폴더에 있는 데이터에 액세스해서는 안 됩니다.
• 루트 프로세스는 문서화된 Android 디버깅 메서드를 사용하지 않는 한 애플리케이션의 메모리에 액세스해서는 안 됩니다.
• 다른 애플리케이션 또는 프로세스의 데이터나 메모리에 액세스하는 애플리케이션이 기기에 포함되어서는 안 됩니다.

SUID 파일 보안 설정

신뢰할 수 없는 프로그램이 새 setuid 프로그램에 액세스할 수 있게 해서는 안 됩니다. setuid 프로그램은 루트에 액세스하는 데 사용할 수 있는 취약점 위치가 된 경우가 많기 때문에 신뢰할 수 없는 애플리케이션의 setuid 프로그램 가용성을 최소화하기 위해 노력합니다. 권장사항

• SUID 프로세스는 Android 보안 모델을 우회하는 데 사용할 수 있는 셸 또는 백도어를 제공해서는 안 됩니다.
• SUID 프로그램은 어떤 사용자도 쓸 수 없게 해야 합니다.
• 누구나 SUID 프로그램을 읽거나 실행할 수 있게 해서는 안 됩니다. 그룹을 만들고, 이 그룹의 구성원이 SUID 바이너리에 액세스할 수 있는 권한을 제한하고, 이 그룹에 SUID 프로그램을 실행할 수 있는 모든 애플리케이션을 배치하세요.
• SUID 프로그램은 사용자가 기기를 루팅할 때 사용하는 일반적인 소스입니다. 이러한 위험을 줄이기 위해 SUID 프로그램을 셸 사용자가 실행할 수 있게 해서는 안 됩니다.

CTS 인증기는 SUID 파일을 나열하는 정보 테스트를 포함합니다. 어떤 setuid 파일은 CTS 테스트와 관련해 허용되지 않습니다.

수신 소켓 보안 설정

CTS 테스트는 기기가 어느 인터페이스, 어느 포트에서든 수신할 때 실패합니다. 실패할 경우 Android에서는 다음 권장사항이 실행되고 있는지 확인합니다.

• 기기에는 수신 포트가 없어야 합니다.
• 수신 포트는 OTA 없이 중지할 수 있어야 합니다. 이것은 서버 또는 사용자 기기 설정 변경일 수 있습니다.
• 루트 프로세스는 어떤 포트에서도 수신 대기해서는 안 됩니다.
• 시스템 UID가 소유한 프로세스는 포트에서 수신 대기하면 안 됩니다.
• 소켓을 사용하는 로컬 IPC의 경우 애플리케이션은 그룹에 액세스할 수 있는 권한이 제한된 UNIX 도메인 소켓을 사용해야 합니다. IPC의 파일 설명자를 생성하고 이를 특정 UNIX 그룹의 +RW로 지정합니다. 모든 클라이언트 애플리케이션은 이 UNIX 그룹 내에 있어야 합니다.
• 프로세서가 여러 개인 기기(예: 앱 프로세서와 분리된 라디오/모뎀)에서는 프로세서 간 통신에 네트워크 소켓을 사용합니다. 이러한 경우 프로세서 간 통신에 사용되는 네트워크 소켓은 분리된 네트워크 인터페이스를 사용하여 미승인 앱이 기기에 액세스하지 못하게 해야 합니다(즉 iptables를 사용하여 다른 앱이 기기에 액세스하지 못하도록 방지).
• 수신 포트를 처리하는 데몬은 잘못된 형식의 데이터에 강해야 합니다. Google은 승인되지 않은 클라이언트를 사용하여 포트에 퍼즈 테스트를 실시할 수 있으며, 가능한 경우 승인된 클라이언트를 사용할 수도 있습니다. 비정상 종료는 적절한 심각도를 지정하여 버그로 접수됩니다.

데이터 로깅

데이터를 로깅하면 데이터의 노출 위험이 증가하고 시스템 성능은 저하됩니다. Android 기기에 기본적으로 설치된 애플리케이션에서 민감한 사용자 데이터를 로깅한 것이 원인이 되어 공개 보안 사고가 여러 차례 발생하였습니다. 권장사항

• 민감한 정보가 포함되어 있을 수 있는 타사 애플리케이션에서 제공하는 데이터를 애플리케이션 또는 시스템 서비스에서 로깅해서는 안 됩니다.
• 애플리케이션에서는 일반적인 작업의 일부로 개인 식별 정보(PII)를 로깅해서는 안 됩니다.

CTS에는 시스템 로그에 민감한 정보가 있을 가능성이 있는지 확인하는 테스트가 포함됩니다.

디렉터리 액세스 제한

누구나 쓸 수 있는 디렉터리로 보안 취약점을 야기하여 애플리케이션이 신뢰할 수 있는 파일의 이름을 바꾸거나 파일을 대체하거나 심볼릭 링크 기반 공격을 하게 할 수 있습니다(공격자는 파일의 심볼릭 링크를 사용해 신뢰할 수 있는 프로그램이 작업을 하게 유도할 수 있음). 또한 쓰기 가능한 디렉터리로 인해 애플리케이션을 제거해도 애플리케이션과 연결된 모든 파일을 깨끗이 삭제할 수 없게 됩니다.

시스템 또는 루트 사용자가 만든 디렉터리에 누구나 쓸 수 있게 하지 않는 것이 좋습니다. CTS 테스트는 알려진 디렉터리를 테스트함으로써 이 권장사항을 시행하는 데 도움이 됩니다.

구성 파일 보안 설정

다수의 드라이버와 서비스는 /system/etc, /data 같은 디렉터리에 저장된 구성 및 데이터 파일에 의존합니다. 이 파일이 권한이 있는 프로세스로 처리되고 누구나 쓸 수 있다면 앱이 누구나 쓸 수 있는 파일에 악성 콘텐츠를 정교하게 만들어 프로세스의 취약성을 악용할 수 있습니다. 권장사항

• 권한이 있는 프로세스에서 사용하는 구성 파일은 누구나 읽을 수 있어서는 안 됩니다.
• 권한이 있는 프로세스에서 사용하는 구성 파일은 누구나 쓸 수 있어서는 안 됩니다.

네이티브 코드 라이브러리 저장

권한이 있는 기기 제조업체 프로세스에서 사용하는 모든 코드는 /vendor 또는 /system에 있어야 합니다. 이 파일 시스템은 부팅 시 읽기 전용으로 마운트됩니다. 전화에 설치된 시스템이나 높은 수준의 권한을 지닌 다른 앱에서 사용하는 라이브러리도 이 파일 시스템에 있는 것이 좋습니다. 이렇게 하면 공격자가 권한이 있는 프로세스에서 실행하는 코드를 제어할 수 있게 허용하는 보안 취약점을 방지할 수 있습니다.

기기 드라이버 액세스 제한

신뢰할 수 있는 코드만 드라이버에 직접 액세스할 수 있어야 합니다. 가능한 경우 기본적인 아키텍처는 드라이버에 호출을 프록시하고 드라이버가 데몬에 액세스할 수 있는 권한을 제한하는 단일 용도 데몬을 제공하는 것입니다. 드라이버 기기 노드는 누구나 읽거나 쓸 수 있게 하지 않는 것이 좋습니다. CTS 테스트는 노출된 드라이버의 알려진 사례를 확인함으로써 이 권장사항을 시행하는 데 도움이 됩니다.

ADB 사용 중지

Android 디버그 브리지(adb)는 중요한 개발 및 디버깅 도구이지만 통제된 보안 환경에서 사용하도록 설계되었기 때문에 일반적인 용도로 사용 설정하면 안 됩니다. 권장사항

• ADB는 기본적으로 사용 중지되어 있어야 합니다.
• ADB에서는 연결을 수락하기 전에 사용자가 ADB를 사용 설정해야 합니다.

부트로더 잠금 해제

다수의 Android 기기에서 잠금 해제를 지원하므로 기기 소유자가 시스템 파티션을 수정하거나 맞춤 운영체제를 설치할 수 있습니다. 일반적인 사용 사례로는 기기에 타사 ROM을 설치하고 시스템 수준 개발을 수행하는 것을 들 수 있습니다. 예를 들어 Google Nexus 기기 소유자는 fastboot oem unlock을 실행하여 잠금 해제 프로세스를 시작할 수 있으며 이를 통해 사용자에게 다음 메시지를 표시합니다.

잠금 해제할 수 있는 Android 기기는 잠금 해제 전에 모든 사용자 데이터를 안전하게 삭제하는 것이 좋습니다. 잠금 해제 시 모든 데이터를 제대로 삭제하지 않으면 물리적으로 근접한 공격자가 Android 사용자의 기밀 데이터에 무단으로 액세스하도록 허용할 수 있습니다. 사용자 데이터가 공개되지 않게 하려면 잠금 해제를 지원하는 기기에서 관련 기능을 제대로 구현해야 합니다(기기 제조업체에서 잠금 해제를 제대로 구현하지 않은 경우가 많이 있었음). 제대로 구현된 잠금 해제 프로세스의 속성은 다음과 같습니다.

• 잠금 해제 명령을 사용자가 확인하면 기기에서는 즉시 데이터 완전 삭제를 시작해야 합니다. unlocked 플래그는 보안 삭제가 완료될 때까지 설정하면 안 됩니다.
• 보안 삭제를 완료할 수 없다면 기기가 잠금 상태를 유지해야 합니다.
• 기본 블록 기기에서 지원한다면 ioctl(BLKSECDISCARD) 또는 이와 동등한 것을 사용해야 합니다. 이는 eMMC 기기에서 Secure Erase 또는 Secure Trim 명령어를 사용함을 뜻합니다. eMMC 4.5 이상에서는 Sanitize 작업에 이어 일반적인 Erase 또는 Trim을 사용함을 뜻합니다.
• BLKSECDISCARD를 기본 블록 기기에서 지원하지 않는다면 그 대신에 ioctl(BLKDISCARD)를 사용해야 합니다. eMMC 기기에서는 이것이 일반적인 Trim 작업입니다.
• BLKDISCARD가 지원되지 않는다면 전부 0으로 블록 기기를 덮어쓰는 것도 허용됩니다.
• 최종 사용자는 파티션을 플래시하기 전에 사용자 데이터를 완전 삭제할 수 있어야 합니다. 예를 들어 Nexus 기기에서는 fastboot oem lock 명령어를 사용하여 완전 삭제합니다.
• 기기에서는 efuse 또는 유사 메커니즘을 통해 기기의 잠금 해제 또는 다시 잠금 여부를 기록할 수 있습니다.

이러한 요구사항을 통해 잠금 해제 작업 완료 시 모든 데이터가 제거됩니다. 이러한 보호 기능을 구현하지 못하면 보통 수준의 보안 취약점으로 간주됩니다.

잠금 해제된 장치는 fastboot oem lock 명령어를 사용하여 다시 잠금 처리할 수 있습니다. 부트로더를 잠금 처리하면 원래 기기 제조업체 OS에서 제공한 것과 동일한 사용자 데이터 보호 기능을 새로운 맞춤 OS에서도 사용할 수 있습니다. 예를 들어 기기가 다시 잠금 해제되면 사용자 데이터가 완전 삭제됩니다.