長期的なAndroidセキュリティのメーカーガイド

このガイドでは、Android互換性テストスイート（CTS）によって評価されるセキュリティパッチを適用するためのGoogleが推奨するベストプラクティスについて説明します。これは、車両、テレビ、セットトップボックス、家電製品など、3年以上サポートされるAndroid互換のOEM機器（メーカー）のメーカーを対象としています。このガイドは、エンドユーザー（たとえば、車両の所有者）。

謝辞と免責事項

このガイドは、Googleまたはその他のメーカーを法的にまたは契約上拘束するものではなく、一連の要件を意図したものではありません。むしろ、このガイドは、推奨される方法を説明する教材です。

フィードバック

このガイドは包括的なものではありません。追加の改訂が計画されています。フィードバックをmanufacturers-guide-android@googlegroups.comに送信してください。

用語集

学期意味
ACC Android互換性の取り組み。以前はAndroidAnti-FragmentationAgreement（AFA）として知られていました。
AOSP Android Open Source Project
ASB Androidセキュリティ速報
BSPボードサポートパッケージ
CDD互換性定義ドキュメント
CTS互換性テストスイート
FOTA無線によるファームウェア
GPS全地球測位システム
MISRAモーター産業ソフトウェア信頼性協会
NIST米国国立標準技術研究所
OBDオンボード診断（ OBD-IIは、機能と標準化の両方でOBD-Iを改善したものです）
OEM相手先ブランド供給（OEM）
OSオペレーティング·システム
SEIソフトウェア工学研究所
SOCシステムオンチップ
SOP生産開始
SPLセキュリティパッチレベル
TPMSタイヤ空気圧監視システム

AndroidOSについて

Androidは、さまざまなデバイスやフォームファクター向けに設計されたオープンソースのLinuxベースのフルソフトウェアスタックです。 2008年の最初のリリース以来、Androidは最も人気のあるオペレーティングシステム（「OS」）になり、世界中で14億台以上のデバイスに電力を供給しています（2016年）。 2017年3月の時点で、これらのデバイスの約67％がAndroid 5.0（Lollipop）以降を使用しています（最新の数値はAndroidダッシュボードで入手できます）。デバイスの大部分は携帯電話やタブレットですが、Androidはスマートウォッチ、テレビ、自動車の車載インフォテインメント（ "IVI"）デバイスで成長しています。

Google Playストアで利用できるAndroidアプリケーションの数は220万以上（2016年）に達しました。 Androidアプリケーションの開発は、互換性定義ドキュメント（CDD）を介して一連の要件を定義し、互換性テストスイート（CTS）を介してテストツールを提供するAndroid互換性プログラムによって支えられています。 Android互換プログラムにより、Androidアプリケーションは、アプリケーションに必要な機能をサポートするAndroid互換デバイスで実行できます。

Googleは、新しいOSバージョン、OSセキュリティアップデート、および発見された脆弱性に関する情報を定期的にリリースしています。 Android OSでサポートされている製品へのこれらの更新の適用性については、メーカーがAndroidセキュリティ情報を確認する必要があります。 Androidのセキュリティ、互換性、ビルドシステムのレビューについては、以下を参照してください。

コネクテッドカーについて（正規の長寿命製品）

1920年代にAMラジオの導入に伴い車両が接続され始めました。そこから、規制当局や自動車メーカーが診断とサービスを容易にし（OBD-IIポートなど）、安全性を向上させ（TPMSなど）、燃費目標を達成するために電子機器に目を向けるにつれて、外部の物理接続とワイヤレス接続の数が増え始めました。 。次の接続の波は、リモートキーレスエントリー、テレマティクスシステムなどのドライバーの便利な機能、およびBluetooth、Wi-Fi、スマートフォンの投影などの高度なインフォテインメント機能を導入しました。現在、統合されたセンサーと接続（GPSなど）は、安全性と半自動運転システムをサポートしています。

車両接続の数が増えると、潜在的な車両攻撃対象領域の領域も増えます。接続は、家庭用電化製品と同様のサイバーセキュリティの懸念事項をもたらします。ただし、再起動、毎日のパッチ更新、および説明のつかない動作は家電製品の標準ですが、車両などのセーフティクリティカルシステムを備えた製品では一貫性がありません。

製造業者は、現場での製品の継続的なセキュリティと安全姿勢を確保するために、積極的なアプローチをとる必要があります。つまり、製造元は製品の既知のセキュリティの脆弱性を認識し、リスクベースのアプローチでそれらに対処する必要があります。

長期的なセキュリティの確保

コネクテッドカーには、OS、ライブラリ、ユーティリティなどの複数のソフトウェアコンポーネントを含む1つ以上の電子制御ユニット（「ECU」）が搭載されていることがよくあります。

  • Common Vulnerabilities and Exposures（CVE）データベースに対して製品を定期的に評価します。
  • 製品関連のセキュリティ上の欠陥に関する情報収集。
  • セキュリティテスト。
  • Androidのセキュリティ情報を積極的に分析します。

OSとセキュリティパッチの更新の例（Androidを実行しているIVI）：

図1.車両の寿命全体にわたる主要なOSとセキュリティアップデートのロールアウトの例。

＃ステップ活動

①

開発ブランチメーカーはAndroidのバージョン（Android X）を選択します。この例では、「Android X」が、最初の生産開始（SOP）の2年前に車両に出荷されるものの基礎になります。
②最初の起動Android Xが製品に同梱される最初のOSバージョンになる数か月前に、セキュリティ更新プログラムはAndroid Security Bulletins（ASB）および製造元によって価値があると見なされるその他のソースから取得されます。 y2 =AndroidのバージョンXの2番目のセキュリティ情報。メーカーによってAndroidXに適用（バックポート）されています。このアップデートは製品に同梱されており、AndroidX.y2では生産クロックがゼロ年から始まります。

この例では、メーカーは最新のAndroid X+1年間リリースを出荷しないことを決定しました。最新リリースを出荷する理由には、新機能の追加、新しいセキュリティの脆弱性への対処、および/または新しいAndroidバージョンを必要とするGoogleまたはサードパーティのサービスの出荷が含まれます。最新のリリースで出荷されない理由は、すべての規制および認証要件への準拠を含め、変更を統合、テスト、および検証するために必要な車両開発および打ち上げプロセスに固有の時間がないことです。

③フルOSアップデートSOP後、メーカーはAndroid X + 2 OSアップデートをリリースします。これは、初期製品（Android X0）に使用されたバージョンの2つのAndroidリリースです。 ASBセキュリティアップデートはAPIレベル（出荷日現在）で利用可能であるため、アップデートはSOPから約1。25年後にX+2.y0として送信されます。このOSアップデートは、フィールド製品と互換性がある場合と互換性がない場合があります。もしそうなら、配備された車両を更新するための計画を作成することができます。

他のビジネス契約が締結されていない限り、OSの完全な更新を行うかどうかの決定は、完全に製造元の裁量に委ねられています。

④セキュリティアップデート車両の製造寿命の2年後、メーカーはAndroid X +2OSにパッチを適用します。この決定は、メーカーのリスク評価に基づいています。製造元は、リリースX+2の3番目のASBセキュリティ更新を更新の基礎として選択します。セキュリティアップデートを受信する製品は、（X + 2.y3）OS+Androidセキュリティパッチレベルになりました。

メーカーは個々のASBから個々のセキュリティパッチを選択できますが、セキュリティ情報に関連付けられたAndroidセキュリティパッチレベル（SPL）を使用するには、セキュリティ情報に必要なすべての問題を修正する必要があります（たとえば、2017-02-05）。サポートされている製品のバックポートとセキュリティリリースを実行するのはメーカーの責任です。

⑤フルOSアップデート手順3（フルOSアップデート）を繰り返すと、2回目のフルOSアップデートにより、製品がAndroid X + 4に移行し、車両の生産寿命が3年になります。メーカーは現在、最新のAndroidバージョンの新しいハードウェア要件と製品のハードウェアのバランスを取り、ユーザーは更新されたAndroidOSの恩恵を受けています。メーカーはセキュリティアップデートなしでアップデートをリリースしているため、製品は現在（X + 4.y0）OS+Androidセキュリティパッチレベルになっています。

この例では、ハードウェアの制限により、X + 4がこの製品に提供されるAndroidの最後のメジャーバージョンですが、車両の6年以上の予想寿命にはセキュリティサポートが必要です。

✧セキュリティアップデート手順4（セキュリティ更新）の繰り返し。製造元には、はるかに新しいバージョンのAndroid（X + 6）からASBセキュリティ更新を取得し、それらの更新の一部またはすべてをAndroid X+4に移植するタスクがあります。更新をマージ、統合、および実行する（またはサードパーティと契約する）のは、製造元の責任です。また、製造元は、サポートされなくなったバージョンのAndroidのセキュリティ問題はASBでカバーされないことに注意する必要があります。
✧セキュリティアップデート車両の生産ライフサイクルの8年後、ステップ5の最後のOSアップデート（フルOSアップデート）から4つのAndroidリリース、Android Xが指定されてから10年後、セキュリティパッチのキュレーションとバックポートの負担は完全にメーカーにあります。 APIレベルの公開リリースから3年以上経過したバージョン。

セキュリティのベストプラクティス

セキュリティの侵害をより困難にするために、Googleは、セキュリティの実装で説明されているように、セキュリティとソフトウェアエンジニアリングに関して一般的に受け入れられているベストプラクティスの使用を推奨および採用しています。

セキュリティガイドライン

セキュリティの推奨プラクティスは次のとおりです。

  • 最新バージョンの外部ライブラリとオープンソースコンポーネントを使用します。
  • OSのリリースバージョンに煩わしいデバッグ機能を含めないでください。
  • 未使用の機能を削除します（不要な攻撃対象領域を減らすため）。
  • 最小特権の原則とその他のAndroidアプリケーション開発のベストプラクティスを使用します。

ソフトウェア開発ガイドライン

システムのライフサイクルで安全なソフトウェア開発を行うための推奨プラクティスは次のとおりです。

  • 脅威モデリングを実行して、資産、脅威、および潜在的な緩和策をランク付けして特定します。
  • アーキテクチャ/設計レビューを実行して、安全で健全な設計を確保します。
  • 定期的なコードレビューを実行して、アンチパターンとバグをできるだけ早く特定します。
  • 以下を含むハイコードカバレッジ単体テストを設計、実装、および実行します。
    • 機能テスト（ネガティブテストケースを含む）
    • 定期的な回帰テスト（修正されたバグが再発しないことを確認するため）
    • ファジングテスト（ユニットテストスイートの一部として）
  • 静的ソースコード分析ツール（スキャンビルド、lintなど）を使用して、潜在的な問題を特定します。
  • AddressSanitizer、UndefinedBehaviorSanitizer、FORTIFY_SOURCE（ネイティブコンポーネント用）などの動的ソースコード分析ツールを使用して、システム開発中の潜在的な問題を特定して軽減します。
  • ソフトウェアのソースコードとリリースの構成/バージョンの管理戦略を立てます。
  • ソフトウェアパッチの生成と展開のためのパッチ管理戦略を立てます。

セキュリティバックポートポリシー

Googleは現在、 APIレベルの公開リリースから3年間、発見および報告されたセキュリティの脆弱性のセキュリティバックポートを積極的にサポートしています。アクティブなサポートは次のもので構成されます。

  1. 脆弱性レポートを受け取り、調査します。
  2. セキュリティ更新プログラムを作成、テスト、およびリリースします。
  3. セキュリティ更新プログラムの定期的なリリースとセキュリティ情報の詳細を提供します。
  4. 確立されたガイドラインに従って重大度評価を実行します。

APIレベルの公開リリース日から3年後、Googleは次のガイドラインを推奨します。

  • APIリリースから3年以上経過したOSセキュリティアップデートのバックポートサポートには、サードパーティ（SoCベンダーやカーネルプロバイダーなど）を使用してください。
  • サードパーティを使用して、公的に提供されたASBを使用してコードレビューを実行します。 ASBは現在サポートされているバージョンの脆弱性を特定しますが、製造元は提供された情報を使用して、新しくリリースされたアップデートを以前のバージョンと比較する場合があります。このデータを使用して、影響分析を実行し、APIリリースから3年以上経過したOSバージョンに対して同様のパッチを生成する可能性があります。
  • 必要に応じて、セキュリティアップデートをAndroid Open Source Project（AOSP）にアップロードします。
  • 製造元は、ベンダー固有のコード（たとえば、独自のデバイス固有のコード）のセキュリティ更新の処理を調整する必要があります。
  • メーカーは、NDA Android Security Bulletin Partner Preview通知グループに参加する必要があります（Developer NDAなどの法的契約に署名する必要があります）。速報には以下を含める必要があります。
    • お知らせ
    • CVEや重大度など、パッチレベルごとの問題の概要
    • 必要に応じて脆弱性の詳細

その他の参考資料

安全なコーディングとソフトウェア開発の実践に関する指示については、以下を参照してください。

Googleは、次の推奨プラクティスの使用を推奨しています。

通常、接続されている製品はすべて最新のOSバージョンで起動することをお勧めします。製造元は、製品を起動する前に最新のOSバージョンを使用するようにしてください。テストと検証の前に安定性を高めるにはバージョンをロックダウンする必要がありますが、製造元は、古いOSバージョンから得られる製品の安定性と既知のセキュリティ脆弱性が少なくセキュリティ保護が強化された新しいOSバージョンとのバランスをとる必要があります。

推奨されるガイドラインは次のとおりです。

  • 車両開発プロセスに固有の長い開発リードタイムの​​ため、メーカーはOSバージョンn-2以前で起動する必要がある場合があります。
  • 無線（OTA）キャンペーンを介して、リリースされた各AndroidOSバージョンのAndroid互換性への準拠を維持します。
  • 製品AndroidFirmware-over-the-Air（FOTA）を実装します。これにより、迅速で顧客フレンドリーな更新が可能になります。 FOTAは、コード署名や製品とITバックオフィス間のTLS接続などのセキュリティのベストプラクティスを使用して実行する必要があります。
  • 独自に特定されたAndroidセキュリティの脆弱性をAndroidセキュリティチームに送信します。

注： Googleは、Androidセキュリティ情報でデバイスタイプまたは業界固有の通知を検討しています。ただし、Googleは特定のデバイス（車両、テレビ、ウェアラブル、電話など）のカーネル、ドライバー、またはチップセットを認識していないため、特定のセキュリティ問題にデバイスタイプのラベルを付ける決定的な方法はありません。

製造元は、製品サイクルの機能強化中に使用されているバージョンの最新のOSバージョンまたはセキュリティアップデートを使用するようにあらゆる試みを行う必要があります。更新は、定期的な製品の更新中に、または品質やその他の問題に対処するための修正プログラムに対して実行できます。推奨される方法は次のとおりです。

  • ドライバー、カーネル、およびプロトコルの更新に対処するための計画を作成します。
  • 配備された車両にアップデートを提供するために、業界に適した方法を利用します。

互換性定義文書（CDD）

互換性定義ドキュメント（CDD）には、Android互換と見なされるデバイスの要件が記載されています。 CDDは公開されており、誰でも利用できます。 CDDバージョンはAndroid1.6から最新バージョンまでsource.android.comからダウンロードできます。

製品のこれらの要件を満たすには、次の基本的な手順が含まれます。

  1. パートナーは、GoogleとAndroid互換性コミットメント（ACC）に署名します。次に、テクニカルソリューションコンサルタント（TSC）がガイドとして割り当てられます。
  2. パートナーは、製品のAndroidOSバージョンのCDDレビューを完了します。
  3. パートナーは、結果がAndroid互換性に受け入れられるまで、CTS結果（以下で説明）を実行して送信します。

互換性テストスイート（CTS）

互換性テストスイート（CTS）テストツールは、製品の実装がAndroidと互換性があり、最新のセキュリティパッチが含まれていることを確認します。 CTSは公開されており、オープンソースであり、誰でも利用できます。 CTSバージョンはAndroid1.6からsource.android.comから最新バージョンにダウンロードできます。

一般にリリースされたAndroidソフトウェアの各ビルド（ファクトリインストールおよびフィールドアップデートイメージ）は、CTSの結果を通じてAndroidの互換性を証明する必要があります。たとえば、デバイスがAndroid 7.1を実行している場合、リリースインテントビルドイメージを作成してテストするときに、対応する最新バージョンのCDD7.1とCTS7.1を参照する必要があります。メーカーは、問題を特定して修正するために、CTSを早期に頻繁に使用することを強くお勧めします。

注： Googleモバイルサービス（GMS）などの他の契約に署名するパートナーは、他の要件を満たす必要がある場合があります。

CTSワークフロー

CTSワークフローには、テスト環境のセットアップ、テストの実行、結果の解釈、およびCTSソースコードの理解が含まれます。次のガイドラインは、CTSユーザー（開発者、メーカーなど）がCTSを効果的かつ効率的に使用できるようにすることを目的としています。

  • テストを頻繁に実行します。 CTSは、ビルドシステムに統合する自動化ツールとして設計されています。 CTSを頻繁に実行すると、ソフトウェアの劣化やリグレッションが発生したときに、欠陥をすばやく早期に見つけることができます。
  • CTSソースコードをダウンロードして調べます。完全なCTSソースコードは、誰でもダウンロードして使用できるオープンソースソフトウェアです（ダウンロードされたソースコードは完全にビルド可能で実行可能です）。デバイスでテストが失敗した場合、ソースコードの関連セクションを調べると、その理由を特定するのに役立ちます。
  • 最新のCTSを入手してください。新しいAndroidリリースでは、バグ修正、改善、新しいテストでCTSを更新できます。 CTSダウンロードを頻繁に確認し、必要に応じてCTSプログラムを更新してください。メーカーとGoogleは、CTSが更新され続けている間、ある時点で製品を凍結する必要があるため、製品の発売に合格するためにCTSバージョンに同意するものとします。

CTSの合格

Android互換製品の場合、GoogleはデバイスのCTSとCTSVerifierレポートのテスト結果が許容できるものであることを確認します。原則として、すべてのテストに合格する必要があります。ただし、デバイスが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：デバイスを直接提供するメーカーが責任を負います。このエンティティはGoogleではなく、特定のデバイス（車両など）ではなく、AOSPでセキュリティアップデートを公開しています。

Q：GoogleはAndroidのセキュリティ問題をどのように処理しますか？

A：Googleは継続的に問題を調査し、潜在的な修正を開発しています。これは、定期的なセキュリティ更新プロセスの一環として、サポートされているすべてのAPIレベルで利用できるようになっています。 2015年8月以降、Googleは、セキュリティ情報とsource.android.comの更新へのリンクを定期的に公開しています。 Googleは、主要なOSリリースの一部としてセキュリティアップデートも公開しています。セキュリティバックポートポリシーも参照してください。

Q：メーカーがASBのすべてのAOSPパッチを統合したが、同じセキュリティ情報に記載されているBSPベンダーのパッチを統合しなかった場合でも、セキュリティレベルを上げることができますか（たとえば、対応するパッチをプラットフォーム/ビルドに適用します） ？

A：Androidセキュリティパッチレベル（SPL）を宣言するには、メーカーはAndroidセキュリティ速報（以前の速報を含む）で公開され、特定のAndroidSPLにマッピングされたすべての必要な問題に対処する必要があります。たとえば、 2017年3月のセキュリティ情報（2017-03-01 SPL）を使用しているメーカーは、そのSPLの2017年3月の情報に記載されているすべての必要な問題と、以前のすべてのAndroidセキュリティ情報のデバイス固有の更新を含むすべての以前の更新に対処しています。 2017-02-05SPLに関連付けられたデバイス固有の更新。

Q：製造元がBSPベンダーによって提供されるセキュリティ更新に同意しない場合、またはASBによって義務付けられているセキュリティ更新がベンダーによって提供されない場合はどうなりますか？

A：ASBは、セキュリティの脆弱性（CVEのリストによって列挙される）を記述し、多くの場合、一致するセキュリティテストを提供します。目標は、リストされた脆弱性がデバイス上で再現できなくなり、デバイスが関連するセキュリティテストに合格できるようにすることです。そのため、問題はGoogleまたはサードパーティベンダーが提供するセキュリティアップデートを取得することではなく、デバイスがASBのCVEのリストに対して脆弱ではないことを証明するメーカーに関するものです。製造元は、提供されているセキュリティ更新プログラムを自由に使用できます。または、デバイスにより適した変更がある場合は、代わりにその変更を使用してください。

たとえば、Googleがコード変更を使用してAOSPセキュリティの脆弱性に対処し、コンポーネントが完全に機能し、CDDに準拠し続けることができる場合を考えてみます。製造元が、コンポーネントがデバイスに不要である、またはCDD（または関連する認証テスト）によって義務付けられていないと判断した場合、製造元はコンポーネントを削除して、将来のサービスの必要性を減らし、攻撃対象領域を減らすことができます。製造元は提供されたセキュリティアップデートを使用しませんでしたが、セキュリティ情報に記載されているCVEに対してデバイスが脆弱でないことを確認しました。ただし、推奨されるセキュリティ更新プログラムから逸脱する場合、製造元は問題に誤って対処したり、新しいセキュリティの脆弱性を導入したり、その他の方法で最終ビルドの機能を低下させたりするリスクを負っています。

すべてのSoCパートナーと協力して、ASBのすべての問題に修正が存在することを確認しますが、メーカーは、デバイスのライフサイクルについてSoCベンダーとのサービス契約を確保することをお勧めします。 SoCは、チップセットのサービスを希望よりも早く停止する可能性があるため、デバイスチップセットを選択する前に合意を確立することは、デバイスの起動プロセスの重要な部分です。

最後に、ASBに記載されている問題の修正を直接取得したり、独自に作成したりすることが不可能な場合、メーカーは以前のAndroid SPLを維持し、利用可能な新しい修正をビルドに追加できます。ただし、この方法では、最終的にビルド認定の問題が発生します（Androidは、認定されたデバイスで最新のセキュリティパッチレベルを利用できるようにするため）。この慣行を回避するために、Googleは事前にSoCを使用することをお勧めします。

Q：メーカーがASBアイテムが自社の製品に適用できないと判断した場合でも、他のGoogle要件を満たすため、またはCTSに合格するために、アイテムを適用またはパッチする必要がありますか？

A：Androidセキュリティパッチレベル（SPL）を宣言するために、パッチを適用する必要はありません。製造元が、ビルドが問題に対して脆弱ではないことを証明する必要があります。

1つの例は、パッチが適用されているコンポーネントが製造元のシステムに存在しない場合、または問題に対処するためにコンポーネントが製造元のシステムから削除されている場合です。その場合、システムは、製造元がパッチを取得しなくても準拠している可能性があります。

これは、たとえば、セキュリティテストが失敗する原因となる他の適用可能なパッチを取得せずに、重要なパッチのみを修正することを望んでいる製造元とは根本的に異なります。この場合、SPLは満たされていないと見なされます。