이 섹션에는 핵심적인 Android 운영체제 및 기기의 보안 확인을 위한 권장사항이 포함되어 있습니다.
생체 인식 인증
사용자 인증을 위해 생체 인식 데이터를 신중하게 수집, 저장 및 처리합니다. 다음을 확인하세요.
- 생체 인식을 비롯한 다른 형식의 인증을 사용하기 전에 기본 인증 방식을 요구합니다.
- 인증 귀속 키가 개입되는 트랜잭션(예: 결제)에 얼굴 인식 등의 수동적 생체 인식 모달리티를 사용 중인 경우 의도를 나타내기 위한 명시적인 확인을 요구합니다.
- 72시간마다 기본 인증 방식을 요구합니다.
- 모든 생체 인식 데이터 및 취급과 관련하여 완벽한 보안이 적용된 파이프라인을 사용합니다.
- 생체 인식 데이터(원시 센서 측정값 및 파생 특성 포함)를 기기 외부로 전송하지 않습니다. 가능한 경우 이러한 데이터를 TEE(신뢰할 수 있는 실행 환경) 또는 보안 요소와 같은 격리된 보안 환경에 보관합니다.
생체 인식을 포함하는 기기는 BiometricPrompt API를 지원해야 합니다. 이 API는 생체 인식 기반 인증을 앱에서 활용할 수 있도록 공통적이고 일관적인 인터페이스를 앱 개발자에게 제공합니다. 강력한 생체 인식만 BiometricPrompt와 통합 가능하며 통합 시 Android 호환성 정의 문서(CDD) 가이드라인을 따라야 합니다.
생체 인식 가이드라인에 관한 자세한 내용은 생체 인식 HAL 구현 가이드라인을 참조하세요.
SELinux
SELinux는 다수의 Android 보안 모델을 정의하고 시행합니다. SELinux의 올바른 사용은 Android 기기의 보안에 매우 중요하며, 보안 취약성의 영향을 줄이는 데 도움이 될 수 있습니다. 따라서 모든 Android 기기는 강력한 SELinux 정책을 구현해야 합니다.
- 최소 권한 정책을 구현합니다.
CAP_DAC_OVERRIDE,CAP_SYS_ADMIN, 및CAP_NET_ADMIN권한을 부여하지 않도록 합니다.- 시스템 데이터를 SD 카드에 기록하지 않습니다.
gpu_device,audio_device등 제공된 드라이버 액세스 유형을 사용합니다.- 프로세스, 파일 및 SELinux 유형에 의미있는 이름을 사용합니다.
- 기본 라벨이 사용되지 않도록 하고 라벨에 액세스 권한이 부여되지 않도록 합니다.
- 기기별 정책은 기기에서 실행되는 모든 정책의 5~10%를 차지해야 합니다. 맞춤설정이 20% 이상이라면 과도한 권한을 부여받은 도메인과 유효하지 않은 정책이 포함되어 있다고 거의 확신할 수 있습니다. 불필요하게 큰 정책은 더 큰 부팅 이미지를 요구하고 런타임 정책 조회 시간에 부정적인 영향을 미침으로써 메모리와 디스크 공간을 낭비합니다.
SELinux 정책의 동적 로드
Android 기기에서는 SELinux 정책을 동적으로 로드하면 안 됩니다. 동적으로 로드할 경우 다음과 같은 문제가 발생할 수 있습니다.
- 중요 보안 패치가 수락되지 않습니다.
- 정책을 다시 로드하는 과정에서 기기의 루팅 기능이 노출됩니다.
- 정책 업데이터에 대한 중간자(man-in-the-middle) 공격의 벡터가 노출됩니다.
- 정책 업데이트 오류로 인해 기기가 제대로 작동하지 않습니다.
백도어
Android 앱에는 정상적인 보안 메커니즘을 우회하는 시스템이나 데이터에 액세스하기 위한 백도어 또는 수단이 없어야 합니다. 여기에는 진단, 디버깅, 개발 또는 개발자에게 알려진 보안 비밀에 의해 관리되는 보증 수리 특별 액세스가 포함됩니다. 백도어를 예방하는 방법은 다음과 같습니다.
- 업계에서 인정하는 앱 취약성 스캔 도구를 사용하여 모든 타사 앱을 스캔합니다.
- 타사 라이브러리를 비롯한 민감한 액세스 권한이 있는 모든 코드에 대한 코드 검토를 수행합니다.
- Google Play에 앱을 업로드하여 스캔하는 방식으로 Google Play 프로텍트를 활용합니다. Google Play에 게시하지 않고도 스캔할 앱을 업로드 할 수 있습니다.
- release 빌드에 진단 또는 수리에 초점을 맞춘 도구를 미리 로드하지 않습니다. 이러한 도구는 특정 문제의 해결을 위해 요구되는 경우에만 설치하세요. 또한 이러한 도구는 계정 관련 데이터를 처리하거나 업로드해서는 안 됩니다.
개발 도구
디버깅, 테스트 및 진단 도구와 같은 개발 도구는 작동 방식 및 수집되는 데이터를 드러내어 기기의 의도되지 않은 보안 결함을 야기하는 경우가 많습니다. 개발 도구가 이를 프로덕션 빌드로 전환하지 않도록 하려면 다음을 수행하세요.
- 시스템 이미지를 사용하기 전에 사내 디버그 및 테스트 도구 해시 차단 목록을 수립하고, 이러한 APK 관련 빌드를 스캔합니다.
- 업계에서 인정하는 앱 취약성 스캔 도구를 사용하여 모든 자사 앱을 스캔합니다.
- 주요 업데이터 전에(특히 앱이 타사에 의해 개발된 경우) 타사 앱 보안 테스트 업체를 고용하여 기기의 모든 중요한 진단 앱을 평가합니다.
- 지원 세션 도중 구두나 채팅을 통해 사용자만 도구를 사용 설정할 수 있도록 합니다. 필요한 진단 정보를 수집한 후에는 동의 관련 아티팩트를 저장하고 도구를 사용 중지합니다.
- 사용자가 이동통신사 계정에서 액세스 가능한 로그에 이 도구의 사용 기록을 저장합니다.
- 도구에 의해 수집된 모든 PII(개인 식별 정보) 또는 기기 원격계측 데이터가 국가와 관련된 익명처리, 유지 및 삭제 관행의 적용을 받는지 확인합니다. 지원 통화와 관련된 데이터만 수집해야 합니다. 이 데이터는 각 호출 후에 삭제되어야 합니다.
- 키 입력 로깅, 마이크 사용 또는 카메라 사용처럼 스파이웨어에 사용될 수 있는 기술이 명시적인 사용자의 동의없이 사용되지 않도록 해야 합니다. 이렇게 개인정보 침해 여지가 있는 방식을 활용하는 앱은 사용자가 동의해야 하는 개인정보처리방침과 더불어 매우 밀접한 방식으로 공개되어야 합니다. 이러한 앱은 사용자의 명시적인 동의없이 사용 설정하면 안 됩니다.
공개 및 동의 구현 시에 참조하면 좋은 몇 가지 추가적인 권장사항은 다음과 같습니다.
인앱 공개
- 인앱으로 직접 앱의 일반적인 사용법을 표시합니다. 사용자가 메뉴나 설정으로 이동할 필요가 없습니다.
- 수집되는 데이터 유형과 데이터가 어떻게 사용되는지 설명합니다.
- 이러한 정보는 개인정보처리방침이나 서비스 약관에 기재하지 않는 것이 좋습니다. 개인정보 또는 민감한 데이터 수집과 관련이 없는 다른 공개에는 포함하면 안 됩니다.
동의 요청
- 동의 의사가 확실해야 합니다. 공개 대화상자에서 나가는 행위 (탭해서 나가기, 뒤로 버튼이나 홈 버튼 누르기 포함)를 동의 의사로 간주하면 안 됩니다.
- 명확하고 분명한 방식으로 동의 요청 대화상자를 표시합니다.
- 사용자가 동의 의사를 확실하게 표현하도록 요구해야 합니다 (예: 탭 동작으로 동의, 음성 명령).
- 확실한 동의 의사 없이 개인정보 또는 민감한 데이터를 수집하면 안 됩니다.
- 메시지가 자동으로 닫히거나 만료되면 안 됩니다.
AOSP의 내장된 기능
AOSP에 추가 기능을 내장할 경우 예기치 못한 동작과 결과로 이어질 수 있으므로 조심해야 합니다.
- 다른 기본 앱(예: 검색 엔진, 웹브라우저, 런처)을 사용하고 데이터를 기기 외부로 전송하는 내용을 공개할 의향이 있는지 사용자에게 물어봐야 합니다.
- AOSP APK가 AOSP 인증서로 서명되었는지 확인합니다.
- 회귀 테스트를 실행하고 변경 로그를 유지하여 AOSP APK에 코드가 추가되었는지 확인합니다.
보안 업데이트
Android 기기는 출시 후 최소 2년간 지속적인 보안 지원을 받아야 합니다. 여기에는 알려진 보안 취약점 해결을 위한 정기적인 업데이트도 포함됩니다.
- SoC 공급업체와 같은 하드웨어 파트너와 협력하여 Android 기기의 모든 구성요소와 관련된 적절한 지원 계약을 수립합니다.
- 최소한의 사용자 상호작용으로 보안 업데이트를 설치할 수 있도록 하여 사용자가 Android 기기에 업데이트를 수락 및 설치할 가능성을 높입니다. 원활한 시스템 업데이트 또는 이와 동등한 보안 기능을 구현하는 것이 좋습니다.
- Android 보안 게시판에 선언된 Android SPL(보안 패치 수준)의 누적 요구사항을 이해해야 합니다. 예를 들어 2018-02-01 보안 패치 수준을 사용하는 기기는 이 보안 패치 수준과 관련된 모든 문제와 이전 보안 게시판에 보고된 모든 문제의 수정사항을 포함해야 합니다.
동적 커널 업데이트
중요한 시스템 구성 요소는 동적으로 수정하면 안 됩니다. 동적 커널 업데이트가 긴급한 위협을 예방하는 데 도움이 된다는 연구가 있기는 하지만 현재로서는 예상 비용이 이점보다 큽니다. 대신 강력한 OTA 업데이트 방식을 구축하여 취약성 보호를 빠르게 배포하는 것이 좋습니다.
키 관리
효과적인 키 관리 정책과 관행을 유지하여 서명 키의 보안을 보장하세요.
- 외부 단체와 서명 키를 공유하지 않습니다.
- 서명 키가 손상되면 새 키를 생성하고 향후의 모든 앱을 이중 서명합니다.
- 다중 인증 액세스를 요구하는 보안 수준이 높은 모듈 하드웨어나 서비스에 모든 키를 보관합니다.
시스템 이미지 서명
시스템 이미지 서명은 기기의 무결성을 파악하는 데 매우 중요합니다.
- 공개적으로 알려진 키로 기기에 서명하지 않습니다.
- 민감한 키 취급을 위한 업계 표준 관행(감사 가능한 제한적인 액세스를 제공하는 HSM(하드웨어 보안 모듈 포함)과 일치하는 방식으로 기기 서명 키를 관리합니다.
잠금 해제할 수 없는 부트로더
다수의 Android 기기는 잠금 해제를 지원합니다. 따라서 기기 소유자가 시스템
파티션을 수정하거나 맞춤 운영체제를 설치할 수 있습니다. 일반적인 사용 사례로는 타사 시스템 이미지를 설치하거나 기기에서 시스템 수준 개발을 실행하는 경우 등이 있습니다. 예를 들어 Google Nexus 또는 Pixel에서 시스템 이미지를 잠금 해제하려면 사용자는 다음 메시지에 표시되는 fastboot oem
unlock을 실행해야 합니다.
잠금 해제할 수 있는 Android 기기는 잠금 해제 전에 모든 사용자 데이터를 안전하게 삭제하는 것이 좋습니다. 잠금 해제 시 모든 데이터를 제대로 삭제하지 않으면 물리적으로 근접한 공격자가 Android 사용자의 기밀 데이터에 무단으로 액세스하도록 허용할 수 있습니다. 사용자 데이터가 공개되지 않도록 하려면 잠금 해제를 지원하는 기기에 관련 기능을 제대로 구현해야 합니다.
- 사용자가 잠금 해제 명령을 확인하면 기기에서 즉시 데이터 완전 삭제를 시작해야 합니다.
unlocked플래그는 보안 삭제가 완료될 때까지 설정하면 안 됩니다. - 보안 삭제를 완료할 수 없는 경우 기기는 잠금 상태를 유지해야 합니다.
- 기본 블록 기기에서 지원한다면
ioctl(BLKSECDISCARD)또는 이와 동등한 것을 사용해야 합니다. 삽입된 MultiMediaCard(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에서도 사용할 수 있습니다. 예를 들어 기기가 다시 잠금 해제되면 사용자 데이터가 완전 삭제됩니다.
기기 펜테스팅
기기는 배송 전에 자격을 갖춘 펜테스터에 의한 검토를 거쳐야 합니다. 펜테스팅으로 기기는 내부 OEM 보안 안내뿐만 아니라 여기에 명시된 보안 안내까지 준수했다고 입증받아야 합니다.