このセクションでは、Android の中核となるオペレーティング システムとデバイスのセキュリティを確保するためのおすすめの方法を説明します。
生体認証
ユーザー認証用の生体認証データは注意して取得、保存、処理します。設定時の注意事項:
- ほかの認証方法（生体認証など）を使用する前に、必ずメインの認証方法を使用する必要があります。
- 認証に基づく鍵を含んだトランザクション（支払いなど）に、顔認証などの受動的生体認証モダリティを使用する場合は、明確な意思表示が必要です。
- メインの認証方式は 72 時間ごとに必要です。
- すべての生体認証データと処理には完全に安全なパイプラインを使用します。
- 未加工のセンサー測定値やそこから生成した特性などの生体認証データをデバイス外に送信しないでください。可能であれば、このデータを安全な隔離環境、たとえば高信頼実行環境（TEE）やセキュア エレメントに保管します。
生体認証を使用するデバイスは、BiometricPrompt API に対応している必要があります。この API によりアプリのデベロッパーはアプリで生体認証ベースの認証を利用した共通で一貫したインターフェースを使用できます。強力な生体認証の場合のみ BiometricPrompt と統合できます。統合を行うには Android の互換性について定めるドキュメント（CDD）ガイドラインに従ってください。
生体認証システムのガイドラインについて詳しくは、Biometric 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 ポリシーを動的に読み込まないでください。次のような問題が発生する可能性があります。
- 重要なセキュリティ パッチの承認を妨げる。
- ポリシーの再読み込みによりデバイスのルート権限が公開される。
- ポリシー更新プロセスへの中間者攻撃の経路が公開される。
- ポリシー更新時のエラー発生が原因でデバイスが操作不能になる。
バックドア
Android アプリには、バックドアや、通常のセキュリティ メカニズムを通さないシステムやデータへのアクセス方法がないようにします。これには、診断、デバッグ、開発、保証修理のためにデベロッパーが把握している秘密の特別アクセス経路が含まれます。次の対応によりバックドアを防ぎます。
- 業界に広く認められているアプリの脆弱性スキャンツールを使用して、すべてのサードパーティ アプリをスキャンします。
- サードパーティのライブラリも含め、機密性の高いアクセスを伴うすべてのコードに対してコードレビューを行います。
- スキャンのために Google Play にアプリをアップロードして、Google Play プロテクトを利用します。Google Play に公開することなく、スキャン用にアプリをアップロードできます。
- 診断ツールや修復専用ツールをリリースビルドにプリロードしないでください。特定の問題の解決に必要な場合のみこれらのツールをインストールしてください。 また、これらのツールはアカウント固有のデータを操作またはアップロードすることはできません。
開発ツール
デバッグ、テスト、診断ツールなどの開発ツールは、ツールの動作状況や収集したデータを明らかにすることで、意図しないセキュリティ ギャップを生むことがあります。次のようにして開発ツールが本番環境のビルドに影響しないようにします。
- システム イメージを使用する前に、社内デバッグとテストツール ハッシュのブラックリストを作成し、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 以降の場合は、通常の Erase または Trim に続いて Sanitize 操作を使用します。 BLKSECDISCARDが下位のブロック デバイスでサポートされていない場合、ioctl(BLKDISCARD)を代わりに使用する必要があります。eMMC デバイスでは、通常の Trim 操作を行います。BLKDISCARDがサポートされていない場合、ブロック デバイスをすべてゼロで上書きすることは許容されます。- ユーザーデータをワイプしてからパーティションをフラッシュする方法もあります。たとえば、Nexus デバイスでは
fastboot oem lockコマンドを使用してユーザーデータを消去します。 - デバイスは、eFuse または同様のメカニズムを使用して、デバイスのロック解除や再ロックが行われたかどうかを記録できます。ただし、ブートローダーを工場出荷時の設定にリセットして再ロックするとデバイスすべての機能が復元されるようにすることを強くおすすめします。
上記の要件により、ロック解除操作が完了すると、すべてのデータが破棄されます。これらの保護を実装していない場合は、中レベルのセキュリティ脆弱性があると見なされます。
ロック解除されたデバイスを再度ロックするには fastboot oem lock コマンドを使用します。ブートローダーをロックすると、元のデバイス メーカーの OS と同じように、新しいカスタム OS によりユーザーデータが保護されます。たとえば、デバイスのロックが再度解除された場合はユーザーデータが消去されます。
デバイスのペネトレーション テスト
デバイスは、出荷前に専門知識を有するペネトレーション テスト実施者がレビューしてください。 デバイスがこのページで説明したセキュリティ ガイダンスや内部 OEM のセキュリティ ガイダンスに従っていることをペネトレーション テストで確認します。