アプリのセキュリティに関するおすすめの方法

このセクションでは、Android デバイス上のアプリのセキュリティを確保するためのおすすめの方法について説明します。

ソースコード レビュー

ソースコード レビューでは、このドキュメントに掲載されているような広範なセキュリティ問題を検出できます。手動と自動の両方でのソースコードのレビューを強くおすすめします。

• 対象範囲をカバーするため、包括的なセキュリティ ガイダンスに沿ってレビューを実施します。社内外の関連する基準を活用して、一貫性のある完全なレビューとなるようにします。
• Android SDK を使用してすべてのアプリコードに Android Studio Linter などの linter を実行し、識別した問題を修正します。
• バッファ オーバーフローや off-by-one エラーなど、メモリ管理の問題を検出できる自動ツールを使用してネイティブ コードを分析します。
• Android ビルドシステムは、AddressSanitizer や UndefinedBehaviorSanitizer など多くの LLVM サニタイザをサポートしており、メモリ関連の問題に対するランタイム分析に使用できます。libFuzzer を利用して Android でサポートされているファジングと組み合わせると、追加の調査が必要な不審なエッジケースをサニタイザで検出できます。
• 暗号化、支払い処理、PII 処理などのよりリスクの高いコードは、知識のあるセキュリティ評価者がレビューする必要があります。

自動テスト

自動テストは、広範なセキュリティ問題を検出するのに役立ち、定期的に実施する必要があります。

• 最新バージョンの CTS を開発プロセス全体を通じて定期的に実行することで、問題を早期発見し修正までの時間を短縮します。Android では 1 日に何度も行われる自動ビルドプロセスで CTS を継続的インテグレーションの一環として使用しています。
• インターフェースのセキュリティ テストを自動化します。ファズテストなどの不正入力のテストも可能です。Android のビルドシステムは、ファズテストの記述用に libFuzzer をサポートしています。

脆弱性スキャン

脆弱性スキャンは、プリインストールされたアプリに既知のセキュリティ上の脆弱性がないか確認します。高度な検出により、これらの脆弱性に対処するために必要な時間とコストを削減し、ユーザーやデバイスのリスクを回避します。

• 業界に広く認められているアプリの脆弱性スキャンツールを使用してインストール済みのアプリをスキャンし、検出された脆弱性に対応します。

有害な可能性があるアプリ

デバイスにプリインストールされているアプリが、有害な可能性があるアプリ（PHA）ではないことを必ず確認してください。デバイスに含まれるすべてのアプリの動作はデバイス メーカーの責任となります。デバイスを起動する前に、プリロードされているすべてのアプリに脆弱性が存在していないかスキャンしてください。

PHA の詳細や、PHA に対して Google が Play ストア内で実施している対処方法については、Google Play プロテクト デベロッパー ドキュメントをご覧ください。

アプリのインストールと権限

プリインストール アプリに対して過剰な権限が付与されると、セキュリティ上のリスクが発生します。プリインストール アプリには必要最小限の権限を付与して、不要な権限や特権を利用できないようにする必要があります。アプリの権限は AndroidManifest.xml に記述されます。

• プリインストールされたアプリに不要な権限や特権を付与しないでください。システム特権を持つアプリは、高度な機密情報に関わる権限を有する場合があるため、慎重にレビューする必要があります。
• リクエストされている権限がすべて、その特定アプリの機能に関連しており、かつ必要なものであることを確認してください。
• プリインストール アプリが INSTALL_PACKAGES 権限を使用する場合は、必ずその旨をユーザーに開示するようにしてください。
• UID 0 としてアプリをインストールしないように、デベロッパーに契約で義務付けてください。
• デベロッパーのネットワーク経由でインストールされるすべてのアプリについて、マニフェスト内で宣言されている権限を評価してください。
• デバイスにアプリを配信する前に自動更新ツールやインストーラ アプリのダウンロード URL をすべて Google Safe Browsing API でスキャンするように、デベロッパーに契約で義務付けてください。

アプリ署名

アプリ署名はデバイスのセキュリティで重要な役割を果たし、権限の確認やソフトウェアの更新に使用されます。アプリ署名に使用する鍵を選択する際は、アプリが 1 つのデバイスでのみ利用されるのか、複数のデバイスにまたがって使用されるのかを考慮することが重要です。

• アプリが、AOSP デベロッパー鍵など、一般に知られている鍵で署名されていないことを確認します。
• アプリの署名に使用される鍵が、制限付きで監査可能なアクセスを提供するハードウェア セキュリティ モジュール（HSM）など、業界基準の機密鍵の取り扱い方法に沿って管理されていることを確認します。
• アプリがプラットフォーム キーで署名されていないことを確認します。署名した場合、非常に強力でオペレーティング システムのコンポーネントのみが使用することを想定したプラットフォームの署名権限にアプリがアクセスできるようになります。システムアプリは特権的な権限を使用する必要があります。
• 同じパッケージ名のアプリが異なる鍵で署名されていないことを確認します。これは、プラットフォーム キーを使用する場合など、さまざまなデバイス用にアプリを作成する場合によく発生します。アプリがデバイスに依存しない場合は、デバイス間で同じ鍵を使用します。アプリがデバイス固有の場合は、デバイスと鍵ごとに固有のパッケージ名を作成します。

アプリとプロセスを分離

Android サンドボックス モデルは正しく使用するとアプリやプロセスのセキュリティを強化できます。

ルートプロセスを分離

ルートプロセスは、権限昇格攻撃で最も狙われるターゲットです。ルートプロセスの数を減らすと、権限昇格のリスクが減少します。

• デバイスがルートとして必要最小限のコードを実行していることを確認します。できるだけルートプロセスではなく通常の Android プロセスを使用します。プロセスをデバイスでルートとして実行する必要がある場合は、公開でレビューができるようにプロセスを AOSP 機能リクエストで文書化します。
• 可能であれば、ルートコードは信頼できないデータから分離し、プロセス間通信（IPC）を介してアクセスするようにします。たとえば、ルート機能を Binder 経由でアクセスできる小規模なサービスに縮小し、署名権限付きのサービスをネットワーク トラフィックを処理する特権が小さいかまったくないアプリに公開します。
• ルートプロセスはネットワーク ソケットでリッスンしないでください。
• ルートプロセスには、Java VM などの汎用ランタイムを含めないでください。

システムアプリを分離

一般的に、プリインストールされたアプリを共有システムの固有識別子（UID）で実行してはいけません。アプリがシステムや他の特権サービス（電話など）の共有 UID を使用する必要がある場合、ユーザーがインストールしたサードパーティ製アプリからアクセスできるサービス、ブロードキャスト レシーバ、コンテンツ プロバイダはエクスポートしないでください。

• デバイスがシステムとして最低限必要なコードを実行していることを確認します。可能であれば、システム UID を再使用するのではなく、独自の UID を保有する Android プロセスを使用します。
• 可能であれば、システムコードは信頼できないデータから分離し、IPC は他の信頼できるプロセスにのみ公開します。
• システム プロセスは、ネットワーク ソケットでリッスンしないでください。これは CTS の要件です。

プロセスを分離

Android アプリ サンドボックスでは、アプリがルートプロセスやデバッガを含むシステム上の他のプロセスと分離していることを想定しています。デバッグがアプリとユーザーによって特に有効にされていない限り、アプリはその想定に反しないようにする必要があります。

• ドキュメント化された Android のデバッグ方法を使用しない場合は、ルートプロセスが個々のアプリデータ フォルダ内にあるデータにアクセスしないようにします。
• ドキュメント化された Android のデバッグ方法を使用しない場合は、ルートプロセスがアプリのメモリにアクセスしないようにします。
• 他のアプリやプロセスのデータやメモリにアクセスするアプリがデバイスに含まれていないことを確認します。