앱 보안 권장사항(APP)
Andorid 사이트 참고
앱 보안 권장사항
이 섹션에는 Android 기기의 앱 보안을 보장하기 위한 권장사항이 포함되어 있습니다.
소스 코드 검토
소스 코드 검토를 통해 이 문서에 설명된 문제를 비롯한 광범위한 보안 문제를 알아낼 수 있습니다. Android에서는 수동 및 자동 소스 코드 검토를 모두 실행할 것을 적극 권장합니다.
적용 범위 확인을 위한 검토를 실시할 경우 다음과 같은 포괄적인 보안 지침을 따릅니다. 관련 있는 내부 또는 외부 표준을 활용하여 일관되고 완전한 검토가 이루어지도록 합니다.
Android SDK를 사용 중인 모든 앱 코드에 Android 스튜디오 린터와 같은 린터를 실행하고 모든 식별된 문제를 수정합니다.
버퍼 오버플로 및 하나 차이 오류와 같은 메모리 관리 문제를 감지할 수 있는 자동화된 도구를 사용하여 네이티브 코드를 분석합니다.
Android 빌드 시스템은 AddressSanitizer 및 UndefinedBehaviorSanitizer 등의 여러 LLVM 새니타이저를 지원합니다. 이러한 새니타이저는 메모리 관련 문제의 런타임 분석 용도로 사용할 수 있습니다. libFuzzer를 통해 Android에서 지원되는 퍼징과 결합할 경우 새니타이저는 추가적인 조사가 필요한 독특한 극단적 사례를 드러낼 수 있습니다.
지식이 풍부한 보안 평가자가 암호법, 결제 처리 및 개인 식별 정보 처리처럼 위험이 높은 코드를 검토해야 합니다.
자동화된 테스트
자동화된 테스트는 광범위한 보안 문제를 감지하는 데 도움이 될 수 있으며 정기적으로 실행해야 합니다.
개발 프로세스 전반에 걸쳐 최신 버전의 CTS를 정기적으로 실행하여 조기에 문제를 감지하고 수정 시간을 단축합니다. Android에서는 하루에 여러 번 빌드되는 자동 빌드 프로세스에서 CTS를 지속적 통합의 일부로 사용합니다.
잘못된 형식의 입력을 사용한 테스트(퍼징 테스트)를 비롯한 인터페이스 보안 테스트를 자동화합니다. Android의 빌드 시스템은 퍼징 테스트 작성을 위한 libFuzzer를 지원합니다.
취약점 스캔취약점 스캔은 사전 설치된 앱에 알려진 보안 취약점이 없는지 확인하는 데 도움을 줄 수 있습니다. 고급 감지 기능은 이러한 취약점을 해결하고 사용자와 기기에 미칠 위험을 예방하는 데 필요한 시간과 비용을 줄여줍니다.
업계에서 인정하는 앱 취약성 스캔 도구를 사용하여 사전 설치된 모든 앱을 스캔하고 감지된 취약점을 해결합니다.
잠재적으로 위험한 애플리케이션
기기에 사전 설치된 앱이 잠재적으로 위험한 애플리케이션(PHA)이 아니어야 합니다. 기기에 포함된 모든 앱의 동작에 관한 책임은 본인에게 있습니다. 기기 실행 전에 사전 로드된 모든 앱의 취약점을 스캔해야 합니다.
PHA 및 Play 스토어에서 Google이 이러한 앱을 차단하는 방법에 관한 자세한 내용은 Google Play 프로텍트 개발자 문서를 참조하세요.
앱 설치 및 권한
사전 설치된 앱에 과도한 권한이 부여되면 보안 위험이 생길 수 있습니다. 사전 설치된 앱의 권한을 필요한 최소 수준으로 제한하고 불필요한 권한에 액세스하지 않는지 확인하세요. 앱 권한은 AndroidManifest.xml에 설명되어 있습니다.
불필요한 권한을 사전 설치된 앱에 부여하지 않습니다. 아주 민감한 권한이 포함될 수 있으므로 시스템 권한이 있는 앱을 꼼꼼히 검토합니다.
요청된 모든 권한이 특정 앱의 기능에 관련되고 필요한 것인지 확인합니다.
INSTALL_PACKAGES권한을 사용하는 모든 사전 설치된 앱의 사용자 공개 정보가 있는지 확인합니다.개발자에게 앱을 UID 0으로 설치하지 않아야 하는 계약적 의무가 있는지 확인합니다.
개발자의 네트워크를 통해 설치될 모든 앱의 매니페스트에서 선언된 권한을 평가합니다.
앱을 기기에 게재하기 전에 개발자에게 Google Safe Browsing API를 사용하여 자동 업데이터 및 설치 프로그램 앱의 모든 다운로드된 URL을 스캔해야 할 계약적 의무가 있는지 확인합니다.
앱 서명
앱 서명은 기기 보안에서 중요한 역할을 하며 권한을 확인하고 소프트웨어를 업데이트하기 위한 용도로 사용됩니다. 앱 서명에 사용할 키를 선택할 때는 앱이 단일 기기에만 사용할 수 있는지, 아니면 여러 기기에 걸쳐 공용으로 사용할 수 있는지를 고려하는 것이 중요합니다.
앱이 AOSP 개발자 키와 같은 공개적으로 알려진 키로 서명되지 않았는지 확인합니다.
앱 서명에 사용된 키가 민감한 키 취급을 위한 업계 표준 관행(감사 가능한 제한적인 액세스를 제공하는 HSM(하드웨어 보안 모듈) 포함)과 일치하는 방식으로 관리되는지 확인합니다.
앱이 플랫폼 키로 서명되지 않았는지 확인합니다. 플랫폼 키로 서명할 경우 매우 강력하고 운영체제 구성요소만 사용하도록 되어있는 플랫폼 서명 권한에 앱이 액세스할 수 있습니다. 시스템 앱은 독점 권한을 사용해야 합니다.
패키지 이름이 같은 앱이 다른 키로 서명되지 않았는지 확인합니다. 이는 다른 기기의 앱을 구축하는 경우, 특히 플랫폼 키를 사용할 때 자주 발생합니다. 앱이 기기 독립형인 경우 여러 기기에 동일한 키를 사용하세요. 앱이 기기 전용인 경우 기기 및 키별로 고유한 패키지 이름을 생성하세요.
앱 및 프로세스 분리
Android 샌드박스 모델은 제대로 사용할 경우 앱 및 프로세스와 관련된 추가적인 보안 기능을 제공합니다.
루트 프로세스 분리
루트 프로세스는 권한 에스컬레이션 공격의 가장 빈번한 표적이며 루트 프로세스 수를 줄이면 권한 에스컬레이션의 위험도 감소합니다.
기기에서 최소로 필요한 코드를 루트로 실행하는지 확인합니다. 가능하다면 루트 프로세스가 아닌 일반 Android 프로세스를 사용하세요. 프로세스를 기기에서 루트로 실행해야 한다면 프로세스를 AOSP 기능 요청에 문서화하여 공개적으로 검토할 수 있습니다.
가능한 경우 루트 코드는 신뢰할 수 없는 데이터로부터 분리해야 하며 IPC(프로세스 간 통신)를 통해 액세스해야 합니다. 예를 들어 루트 기능을 바인더를 통해 액세스 가능한 소규모 서비스로 축소하고 서명 권한이 있는 서비스를 권한이 낮거나 없는 앱에 노출시켜 네트워크 트래픽을 처리합니다.
루트 프로세스는 네트워크 소켓에서 수신 대기하면 안 됩니다.
루트 프로세스에는 자바 VM과 같은 범용 런타임을 포함하면 안 됩니다.
시스템 앱 분리
일반적으로 사전 설치된 앱은 공유된 시스템의 고유 식별자(UID)로 실행되면 안 됩니다. 앱에서 시스템의 공유된 UID나 다른 권한이 있는 서비스(예: 휴대전화)를 사용해야 하는 경우 앱은 사용자가 설치한 타사 앱에 의해 액세스 가능한 어떠한 서비스, broadcast receiver 또는 콘텐츠 제공업체도 내보내면 안 됩니다.
기기에서 최소로 필요한 코드를 시스템으로 실행하도록 합니다. 가능하다면 시스템 UID를 재사용하기보다는 자체 UID가 있는 Android 프로세스를 사용하세요.
가능하다면 신뢰할 수 없는 데이터에서 시스템 코드를 분리하고 다른 신뢰할 수 있는 프로세스에만 IPC를 노출해야 합니다.
시스템 프로세스는 네트워크 소켓에서 수신 대기하면 안 됩니다. 이는 CTS 요구사항입니다.
프로세스 분리
Android 애플리케이션 샌드박스는 루트 프로세스 및 디버거를 비롯한 시스템의 다른 프로세스로부터 분리가 예상되는 앱을 제공합니다. 앱과 사용자가 디버깅을 특별히 사용 설정하지 않는 한 이러한 예상을 위반하는 앱이 없어야 합니다.
문서화된 Android 디버깅 메서드를 사용하지 않는 한 루트 프로세스가 개별 앱 데이터 폴더 내의 데이터에 액세스하지 않도록 합니다.
문서화된 Android 디버깅 메서드를 사용하지 않는 한 루트 프로세스가 앱의 메모리에 액세스하지 않도록 합니다.
다른 앱이나 프로세스의 데이터나 메모리에 액세스하는 어떠한 앱도 기기에 포함되지 않도록 합니다.
Last updated