장기적인 Android 보안을 위한 제조업체 가이드

이 가이드에서는 Android CTS(Compatibility Test Suite)에서 평가하는 보안 패치를 적용하기 위한 Google 권장 모범 사례를 설명합니다. 차량, TV, 셋톱박스, 가전제품 등 3년 이상 지원되는 Android 호환 OEM 장비(제조업체) 제조업체 를 대상으로 합니다. 이 안내서는 최종 사용자( 예: 차량 소유자).

승인 및 면책 조항

이 가이드는 법적 또는 계약상 Google 또는 기타 제조업체를 구속하지 않으며 일련의 요구사항을 의도한 것이 아닙니다. 오히려 이 안내서는 권장되는 방법을 설명하는 교육 보조 자료입니다.

피드백

이 가이드는 포괄적이지 않습니다. 추가 개정이 예정되어 있습니다. Manufacturer-guide-android@googlegroups.com으로 피드백을 제출하세요.

용어 사전

안드로이드 OS 정보

Android는 다양한 기기 및 폼 팩터용으로 설계된 오픈 소스, Linux 기반 전체 소프트웨어 스택입니다. 2008년 첫 출시 이후 Android는 가장 널리 사용되는 운영 체제("OS")가 되어 전 세계적으로 14억 개 이상의 장치를 지원합니다(2016년). 2017년 3월 기준으로 이러한 기기의 약 67%가 Android 5.0(Lollipop) 이상을 사용합니다(최신 수치는 Android 대시보드 에서 확인 가능). 대다수의 기기가 휴대전화와 태블릿이지만, Android는 스마트워치, TV, 자동차 내 인포테인먼트("IVI") 기기에서 성장하고 있습니다.

Google Play 스토어에서 사용할 수 있는 Android 애플리케이션의 수는 220만 개 이상(2016년)에 도달했습니다. Android 애플리케이션 개발은 CDD(호환성 정의 문서) 를 통해 일련의 요구 사항을 정의하고 CTS(호환성 테스트 모음 )를 통해 테스트 도구를 제공하는 Android 호환성 프로그램의 지원을 받습니다. Android 호환성 프로그램은 모든 Android 애플리케이션이 애플리케이션에 필요한 기능을 지원하는 모든 Android 호환 장치에서 실행될 수 있도록 합니다.

Google은 새로운 OS 버전, OS 보안 업데이트 및 발견된 취약점에 대한 정보를 정기적으로 릴리스합니다. 제조업체는 Android OS 지원 제품에 대한 이러한 업데이트의 적용 가능성에 대해 Android 보안 게시판 을 검토해야 합니다. Android 보안, 호환성 및 빌드 시스템에 대한 검토는 다음을 참조하세요.

• Android 기기 보안
• 보안 업데이트 및 리소스
• 호환성 테스트 제품군
• 코드명, 태그 및 빌드 번호

커넥티드 차량 정보(표준 장수명 제품)

차량은 1920년대 AM 라디오의 도입과 함께 연결 되기 시작했습니다. 거기에서 규제 기관과 자동차 제조업체가 진단 및 서비스(예: OBD-II 포트)를 용이하게 하고 안전성을 개선하며(예: TPMS) 연비 목표를 달성하기 위해 전자 장치로 전환함에 따라 외부 물리적 및 무선 연결의 수가 증가하기 시작했습니다. . 다음 연결 물결은 원격 키리스 엔트리, 텔레매틱스 시스템과 같은 운전자 편의 기능과 블루투스, Wi-Fi 및 스마트폰 프로젝션과 같은 고급 인포테인먼트 기능을 도입했습니다. 오늘날 통합 센서 및 연결(예: GPS)은 안전 및 반자율 주행 시스템을 지원합니다.

차량 연결 수가 증가함에 따라 잠재적인 차량 공격 표면 영역도 증가합니다. 연결은 소비자 전자 제품의 경우와 유사한 사이버 보안 문제 모음을 가져옵니다. 그러나 재부팅, 일일 패치 업데이트 및 설명할 수 없는 동작은 소비자 전자 제품의 표준이지만 차량과 같이 안전이 중요한 시스템이 있는 제품에는 일치하지 않습니다.

제조업체는 현장에서 제품의 지속적인 보안 및 안전 태세를 보장하기 위해 사전 예방적인 접근 방식을 취해야 합니다. 요컨대, 제조업체는 제품의 알려진 보안 취약성을 인식하고 이를 해결하기 위해 위험 기반 접근 방식을 취해야 합니다.

장기 보안 보장

연결된 차량에는 OS, 라이브러리, 유틸리티 등과 같은 여러 소프트웨어 구성 요소를 포함하는 하나 이상의 전자 제어 장치("ECU")가 있는 경우가 많습니다. 제조업체는 다음을 포함하여 사전 분석을 통해 이러한 구성 요소를 추적하고 알려진 공개된 취약점을 식별해야 합니다.

• CVE(Common Vulnerabilities and Exposures) 데이터베이스에 대해 제품을 정기적으로 평가합니다.
• 제품 관련 보안 결함에 대한 인텔리전스 수집.
• 보안 테스트.
• Android 보안 게시판을 적극적으로 분석합니다.

OS 및 보안 패치 업데이트의 예(Android를 실행하는 IVI):

그림 1. 차량 수명 동안의 샘플 주요 OS 및 보안 업데이트 롤아웃.

보안 모범 사례

보안 타협을 더 어렵게 만들기 위해 Google은 보안 구현 에 설명된 대로 보안 및 소프트웨어 엔지니어링에 대해 일반적으로 인정되는 모범 사례를 사용할 것을 권장하고 채택합니다.

보안 지침

보안을 위한 권장 사례는 다음과 같습니다.

• 최신 버전의 외부 라이브러리 및 오픈 소스 구성 요소를 사용합니다.
• OS 릴리스 버전에 방해가 되는 디버그 기능을 포함하지 마십시오.
• 사용하지 않는 기능을 제거합니다(불필요한 공격 표면을 줄이기 위해).
• 최소 권한 원칙 및 기타 Android 애플리케이션 개발 모범 사례 를 사용합니다.

소프트웨어 개발 지침

시스템 수명 주기 동안 안전한 소프트웨어 개발을 위한 권장 사례는 다음과 같습니다.

• 위협 모델링을 수행하여 자산, 위협 및 잠재적 완화의 순위를 지정하고 식별합니다.
• 안전하고 건전한 설계를 위해 아키텍처/설계 검토를 수행합니다.
• 정기적인 코드 검토를 수행하여 가능한 한 빨리 안티 패턴과 버그를 식별하십시오.
• 다음을 포함하여 높은 코드 범위 단위 테스트를 설계, 구현 및 실행합니다.
  • 기능 테스트(음성 테스트 케이스 포함)
  • 정기 회귀 테스트(수정된 버그가 다시 나타나지 않도록 하기 위해)
  • 퍼지 테스트(단위 테스트 모음의 일부로)
• 정적 소스 코드 분석 도구(scan-build, lint 등)를 사용하여 잠재적 문제를 식별합니다.
• AddressSanitizer, UndefinedBehaviorSanitizer 및 FORTIFY_SOURCE(네이티브 구성 요소용)와 같은 동적 소스 코드 분석 도구를 사용하여 시스템 개발 중 잠재적인 문제를 식별하고 완화합니다.
• 소프트웨어 소스 코드 및 릴리스 구성/버전에 대한 관리 전략이 있습니다.
• 소프트웨어 패치 생성 및 배포를 위한 패치 관리 전략이 있습니다.

보안 백포트 정책

Google은 현재 API 수준 공개 릴리스로부터 3년 동안 발견 및 보고된 보안 취약점의 보안 백포트에 대한 적극적인 지원을 제공합니다. 적극적인 지원은 다음으로 구성됩니다.

1. 취약점 보고서를 받고 조사합니다.
2. 보안 업데이트를 생성, 테스트 및 출시합니다.
3. 보안 업데이트 및 보안 게시판 세부 정보의 반복 릴리스를 제공합니다.
4. 확립된 지침에 따라 심각도 평가를 수행합니다.

API 수준 공개 출시일로부터 3년 후 Google은 다음 가이드라인을 권장합니다.

• API 릴리스로부터 3년이 지난 OS 보안 업데이트에 대한 백포트 지원을 위해 타사(예: SoC 공급업체 또는 커널 공급자)를 사용합니다.
• 타사를 사용하여 공개적으로 제공되는 ASB를 사용하여 코드 검토를 수행합니다. ASB는 현재 지원되는 버전의 취약점을 식별하지만 제조업체는 제공된 정보를 사용하여 새로 출시된 업데이트를 이전 버전과 비교할 수 있습니다. 이 데이터는 영향 분석을 수행하고 API 릴리스로부터 3년보다 오래된 OS 버전에 대한 유사한 패치를 생성하는 데 사용할 수 있습니다.
• 적절한 경우 AOSP(Android 오픈 소스 프로젝트)에 보안 업데이트를 업로드합니다.
• 제조업체는 공급업체별 코드(예: 독점 장치별 코드)에 대한 보안 업데이트 처리를 조정해야 합니다.
• 제조업체는 NDA Android 보안 게시판 파트너 미리보기 알림 그룹에 가입해야 합니다(개발자 NDA와 같은 법적 계약서 서명 필요). 게시판에는 다음이 포함되어야 합니다.
  • 공지사항
  • CVE 및 심각도를 포함한 패치 수준별 문제 요약
  • 해당되는 경우 취약성 세부정보

추가 참조

보안 코딩 및 소프트웨어 개발 사례에 대한 지침은 다음을 참조하십시오.

• 자동차 산업 소프트웨어 신뢰성 협회(MISRA) .
• SEI(소프트웨어 공학 연구소) 도구 및 방법 .
• NIST(National Institute of Standards and Technology).

권장 제품 관행

Google은 다음 권장 사례를 사용할 것을 권장합니다.

일반 출시 지침

일반적으로 연결된 모든 제품은 최신 OS 버전으로 실행하는 것이 좋으며, 제조사는 제품을 실행하기 전에 최신 OS 버전을 사용하도록 시도해야 합니다. 테스트 및 검증 전에 안정성을 확보하기 위해 버전을 잠그는 것이 필요하지만 제조업체는 이전 OS 버전에서 얻은 제품 안정성과 알려진 보안 취약점이 적고 보안 보호 기능이 강화된 최신 OS 버전의 균형을 유지해야 합니다.

권장 지침은 다음과 같습니다.

• 차량 개발 프로세스에 내재된 긴 개발 리드 타임으로 인해 제조업체는 OS 버전 n-2 또는 이전 버전으로 출시해야 할 수 있습니다.
• OTA(무선) 캠페인을 통해 출시된 각 Android OS 버전에 대한 Android 호환성 준수를 유지합니다.
• 빠르고 고객 친화적인 업데이트를 위해 제품 Android FOTA(Firmware-over-the-Air)를 구현합니다. FOTA는 코드 서명 및 제품과 IT 백오피스 간의 TLS 연결과 같은 보안 모범 사례를 사용하여 수행해야 합니다.
• 독립적으로 식별된 Android 보안 취약점을 Android 보안 팀에 제출 합니다.

참고: Google은 Android 보안 게시판에서 기기 유형 또는 산업별 알림을 고려했습니다. 그러나 Google은 특정 장치(차량, TV, 웨어러블, 전화 등)의 커널, 드라이버 또는 칩셋을 알지 못하기 때문에 Google은 특정 보안 문제에 장치 유형에 레이블을 지정하는 결정적인 방법이 없습니다.

제품 주기 지침

제조업체는 제품 주기 향상 동안 사용 중인 버전에 대한 최신 OS 버전 또는 보안 업데이트를 사용하도록 모든 시도를 해야 합니다. 정기적인 제품 업데이트를 반복하거나 품질 및/또는 기타 문제를 해결하기 위한 핫픽스를 위해 업데이트를 수행할 수 있습니다. 권장 사례는 다음과 같습니다.

• 드라이버, 커널 및 프로토콜 업데이트를 처리할 계획을 세웁니다.
• 배포된 차량에 업데이트를 제공하기 위해 업계에 적절한 방법을 활용합니다.

호환성 정의 문서(CDD)

호환성 정의 문서(CDD)는 기기가 Android와 호환되는 것으로 간주되기 위한 요구 사항을 설명합니다. CDD는 공개되어 모든 사람이 사용할 수 있습니다. source.android.com 에서 Android 1.6부터 최신 버전까지 CDD 버전을 다운로드할 수 있습니다.

제품에 대한 이러한 요구 사항을 충족하려면 다음과 같은 기본 단계가 필요합니다.

1. 파트너는 Google과 ACC(Android 호환성 약정)에 서명합니다. 그런 다음 기술 솔루션 컨설턴트(TSC)가 가이드로 지정됩니다.
2. 파트너는 제품의 Android OS 버전에 대한 CDD 검토를 완료합니다.
3. 파트너는 결과가 Android 호환성에 적합할 때까지 CTS 결과(아래에 설명됨)를 실행하고 제출합니다.

CTS(호환성 테스트 모음)

CTS(Compatibility Test Suite) 테스트 도구는 제품 구현이 Android와 호환되며 최신 보안 패치가 포함되어 있는지 확인합니다. CTS는 공개 소스이며 모든 사람이 사용할 수 있습니다. source.android.com 에서 Android 1.6부터 최신 버전까지 CTS 버전을 다운로드할 수 있습니다.

공개된 Android 소프트웨어의 각 빌드(공장 설치 및 현장 업데이트 이미지)는 CTS 결과를 통해 Android 호환성을 증명해야 합니다. 예를 들어 기기에서 Android 7.1을 실행하는 경우 릴리스 인텐트 빌드 이미지를 만들고 테스트할 때 해당하는 최신 버전의 CDD 7.1 및 CTS 7.1을 참조해야 합니다. 제조업체는 CTS를 조기에 자주 사용하여 문제를 식별하고 해결할 것을 강력히 권장합니다.

CTS 워크플로

CTS 워크플로 에는 테스트 환경 설정, 테스트 실행, 결과 해석 및 CTS 소스 코드 이해가 포함됩니다. 다음 지침은 CTS 사용자(예: 개발자, 제조업체)가 CTS를 효과적이고 효율적으로 사용할 수 있도록 돕기 위한 것입니다.

• 테스트를 자주 실행하십시오 . CTS는 빌드 시스템에 통합되는 자동화된 도구로 설계되었습니다. CTS를 자주 실행하면 소프트웨어 성능 저하 또는 회귀가 발생할 때 신속하고 조기에 결함을 찾는 데 도움이 될 수 있습니다.
• CTS 소스 코드를 다운로드하여 검사합니다 . 전체 CTS 소스 코드는 누구나 다운로드하여 사용할 수 있는 오픈 소스 소프트웨어입니다(다운로드한 소스 코드는 완전히 빌드 및 실행 가능). 장치에서 테스트가 실패하면 소스 코드의 관련 섹션을 검사하면 이유를 식별하는 데 도움이 됩니다.
• 최신 CTS를 받으세요 . 새로운 Android 릴리스는 버그 수정, 개선 사항 및 새로운 테스트로 CTS를 업데이트할 수 있습니다. CTS 다운로드 를 자주 확인하고 필요에 따라 CTS 프로그램을 업데이트하십시오. 제조업체와 Google은 CTS가 계속 새로고침되는 동안 제품이 특정 시점에서 동결되어야 하므로 제품 출시를 위해 통과할 CTS 버전에 동의합니다.

CTS 통과

Android 호환 제품의 경우 Google은 기기의 CTS 및 CTS Verifier 보고서 테스트 결과가 허용 가능한지 확인합니다. 원칙적으로 모든 테스트를 통과해야 합니다. 그러나 Android 호환성 요구 사항을 준수하지 않는 기기 이외의 이유로 테스트에 실패한 경우 Google에서 검토해야 합니다. 이 과정에서:

1. 제조업체는 주장을 입증하기 위해 제안된 CTS 패치, 패치 검증 및 근거를 Google에 제공합니다.
2. Google은 제출된 자료를 검토하고 승인되면 기기가 CTS의 다음 개정판에서 통과할 수 있도록 관련 CTS 테스트를 업데이트합니다.

보안 패치를 적용한 후 CTS 테스트가 갑자기 실패하는 경우 제조업체는 패치를 수정하여 호환성을 손상시키지 않거나 테스트가 잘못되었음을 보여주고 테스트에 대한 수정 사항을 제공해야 합니다(위에 설명됨).

CTS는 테스트 수정 사항의 검토를 위해 열려 있습니다. 예를 들어 Android 4.4는 계속 수정 사항을 수용합니다( https://android-review.googlesource.com/#/c/273371/ 참조 ).

자주 묻는 질문(FAQ)

Q: Android의 특정 구현에 보안 업데이트를 적용하는 책임은 누구에게 있습니까?

A: 기기를 직접 제공하는 제조사가 책임을 집니다. 이 법인은 특정 기기(예: 차량)에 대한 보안 업데이트가 아닌 AOSP의 보안 업데이트를 게시하는 Google이 아닙니다 .

Q: Google은 Android의 보안 문제를 어떻게 처리합니까?

A: Google은 정기적인 보안 업데이트 프로세스의 일부로 지원되는 모든 API 수준에서 사용할 수 있도록 지속적으로 문제를 조사하고 잠재적인 수정 사항을 개발합니다. 2015년 8월부터 Google은 게시판과 source.android.com 에 대한 업데이트 링크를 정기적으로 게시하고 있습니다. Google은 또한 주요 OS 릴리스의 일부로 보안 업데이트를 게시합니다. 보안 백포트 정책 도 참조하십시오.

Q: 제조업체가 ASB의 모든 AOSP 패치를 통합했지만 동일한 게시판에 언급된 BSP 공급업체의 패치를 통합하지 않은 경우에도 보안 수준을 높일 수 있습니까(예: 플랫폼/빌드에 해당 패치 적용) ?

A: Android 보안 패치 수준(SPL)을 선언하려면 제조업체가 Android 보안 게시판( 이전 게시판 포함 )에 게시되고 특정 Android SPL에 매핑된 모든 필수 문제를 해결해야 합니다. 예를 들어, 2017년 3월 보안 게시판 (2017-03-01 SPL)을 사용하는 제조업체는 해당 SPL에 대한 2017년 3월 게시판에 문서화된 모든 필수 문제와 다음을 포함한 모든 이전 Android 보안 게시판에 대한 기기별 업데이트를 포함한 모든 이전 업데이트를 해결했습니다. 2017-02-05 SPL과 관련된 장치별 업데이트.

Q: 제조업체가 BSP 공급업체에서 제공한 보안 업데이트에 동의하지 않거나 ASB에서 요구하는 보안 업데이트가 공급업체에서 제공되지 않으면 어떻게 됩니까?

A: ASB는 보안 취약점(CVE 목록으로 열거)을 설명하고 종종 일치하는 보안 테스트를 제공합니다. 목표는 나열된 취약점이 더 이상 장치에서 재현되지 않도록 하고 장치가 관련 보안 테스트를 통과할 수 있도록 하는 것입니다. 따라서 문제는 Google이나 타사 공급업체에서 제공하는 보안 업데이트를 받는 것이 아니라 기기가 ASB의 CVE 목록에 취약하지 않음을 증명하는 제조업체에 관한 것입니다. 제조업체는 제공된 보안 업데이트를 자유롭게 사용할 수 있으며, 장치에 더 적합한 변경 사항이 있는 경우 해당 변경 사항을 대신 사용합니다.

예를 들어 Google에서 구성 요소가 완전히 기능하고 CDD를 준수하도록 허용하는 코드 변경을 사용하여 AOSP 보안 취약점을 해결하는 경우를 생각해 보십시오. 제조업체가 구성 요소가 장치에 필요하지 않거나 CDD(또는 관련 인증 테스트)에서 의무화하지 않는다고 판단하는 경우 제조업체는 구성 요소를 제거하여 향후 서비스 요구 사항을 줄이고 공격 표면을 줄일 수 있습니다. 제조업체는 제공된 보안 업데이트를 사용하지 않았지만 장치가 보안 게시판에 설명된 CVE에 취약하지 않은지 확인했습니다. 그러나 권장 보안 업데이트에서 벗어나 제조업체는 문제를 잘못 해결하거나 새로운 보안 취약성을 도입하거나 그렇지 않으면 최종 빌드의 기능을 축소할 위험을 감수하고 있습니다.

ASB의 모든 문제에 대한 수정 사항이 있는지 확인하기 위해 모든 SoC 파트너와 협력하는 동안 제조업체가 장치 수명 주기 동안 SoC 공급업체와 서비스 계약을 체결하는 것이 좋습니다. SoC는 원하는 것보다 일찍 칩셋 서비스를 중단할 수 있으므로 장치 칩셋을 선택하기 전에 계약을 설정하는 것은 장치 출시 프로세스의 중요한 부분입니다.

마지막으로 ASB에 문서화된 문제에 대한 수정 사항을 직접 획득하거나 독립적으로 생성할 수 없는 경우 제조업체는 이전 Android SPL을 유지하면서 사용 가능한 새 수정 사항을 빌드에 추가할 수 있습니다. 그러나 이 관행은 결국 빌드 인증 문제로 이어집니다(Android는 인증된 기기에서 최신 보안 패치 수준을 사용할 수 있도록 보장하기 때문입니다). Google은 이러한 관행을 피하기 위해 사전에 SoC와 협력할 것을 권장합니다.

Q: 제조업체에서 ASB 항목을 해당 제품에 적용할 수 없다고 결정한 경우 다른 Google 요구사항을 충족하거나 CTS를 통과하기 위해 해당 항목을 적용하거나 패치해야 합니까?

A: Android SPL(보안 패치 수준)을 선언하기 위해 패치를 요구하지 않습니다. 우리는 제조업체가 해당 빌드가 문제에 취약하지 않다는 것을 증명할 것을 요구합니다.

한 가지 예는 패치되는 구성 요소가 제조업체의 시스템에 존재하지 않거나 문제를 해결하기 위해 제조업체의 시스템에서 구성 요소가 제거되는 경우입니다. 이 경우 제조업체가 패치를 적용하지 않아도 시스템이 규정을 준수할 수 있습니다.

이것은 예를 들어 중요한 패치만 수정하고 보안 테스트에 실패할 수 있는 다른 적용 가능한 패치는 사용하지 않기를 원하는 제조업체와 근본적으로 다릅니다. 이 경우 SPL이 충족되지 않은 것으로 간주됩니다.