Android应用开发安全指南：防网络攻击与信息泄露要点

Androidアプリ開発のセキュリティ対策をまとめました。

目次

1. 1. はじめに
2. 2. Androidのセキュリティの基本
3. 3. ファイルの保存場所とアクセス権限
4. 3-1. 主な保存場所
5. 3-2. ファイルの公開範囲
6. 4. Googleのバックアップ・同期・共有
7. 4-1. 主な仕組み
8. 4-2. バックアップ対象の制御
9. 4-3. クラウドのアクセス制御と暗号化
10. 5. 機密情報の保存と暗号化

1. はじめに

Androidは、アプリのサンドボックス、アプリ署名、データの暗号化など、OSレベルで強力なセキュリティ機能を備えています。

しかし、アプリの実装に問題があれば、個人情報や認証情報が漏洩したり、サーバーが不正アクセスを受けたりする可能性があります。また、Googleのバックアップ機能、アプリ間のデータ共有、外部ライブラリ、開発環境の管理にも注意が必要です。

今回は、Androidアプリを安全に開発・運用するためのセキュリティ対策を、データ保存、通信、認証、情報共有、開発環境などの観点から紹介します。

2. Androidのセキュリティの基本

Androidには、アプリやユーザーデータを保護するための複数の仕組みが用意されています。

主なセキュリティ機能は次のとおりです。

これらによって、他のアプリのデータへの不正アクセスなどが制限されています。

ただし、次のような問題まで自動的に防げるわけではありません。

Androidが保護する範囲と、開発者自身が対策すべき範囲を区別することが重要です。

3. ファイルの保存場所とアクセス権限

Androidアプリのデータは、保存場所によって他のアプリからのアクセス範囲やバックアップの扱いが異なります。

3-1. 主な保存場所

機密性の高いデータは、基本的にアプリ専用の内部ストレージを利用します。

外部ストレージは用途に応じて他のアプリやユーザーからアクセスされる可能性があるため、公開範囲に注意します。

3-2. ファイルの公開範囲

Androidでは、内部ストレージのファイルは原則として他のアプリから直接アクセスできません。

ただし、ContentProvider や FileProvider などを使用すると、他のアプリにデータを共有できます。

特に次の点に注意します。

たとえば、内部ファイルへのアクセスは次のように行います。

context.openFileOutput(
    "data.txt",
    Context.MODE_PRIVATE
).use {
    it.write(data)
}

MODE_PRIVATE はアプリ専用のファイルを作成します。ただし、この指定だけでファイル内容がアプリ独自に暗号化されるわけではありません。

4. Googleのバックアップ・同期・共有

Androidでは、アプリのデータをGoogleのバックアップ機能で保存したり、クラウドサービスを通じて同期・共有したりできます。

ただし、バックアップ、同期、共有は異なる機能です。

4-1. 主な仕組み

たとえば、filesDir に保存したデータがAuto Backupに含まれていても、それだけでGoogle Drive上の共有ファイルになるわけではありません。

4-2. バックアップ対象の制御

Androidでは、バックアップ対象を設定ファイルで制御できます。

特に次の設定に注意します。

機密情報や端末固有の情報は、必要に応じてバックアップ対象から除外します。

なお、allowBackup="false" だけですべての端末間転送を制御できるとは限らないため、OSバージョンや端末メーカーごとの動作確認も必要です。

4-3. クラウドのアクセス制御と暗号化

Googleのバックアップには暗号化機能がありますが、すべてのデータが同じ条件でエンドツーエンド暗号化されるわけではありません。

また、Firebaseなどを利用してデータを共有する場合は、アプリ側でアクセス制御を設定する必要があります。

特にAndroid Keystoreで生成した鍵は、通常、バックアップ先の別端末へ復元できません。

暗号化したファイルだけが復元され、復号できなくなる問題にも注意が必要です。

5. 機密情報の保存と暗号化

アプリ内で扱う情報は、機密性に応じて保存方法を選択します。

5-1. Android Keystoreによる鍵管理

Androidには、暗号鍵を管理する「Android Keystore」があります。

Android Keystoreは、暗号鍵を管理する仕組みであり、任意のパスワードやファイルを直接保存する汎用ストレージではありません。

たとえば、アプリ独自の認証トークンはKeystoreで保護した鍵で暗号化し、暗号文をDataStoreなどに保存します。

なお、従来の EncryptedSharedPreferences や MasterKey は非推奨となっています。新規開発では、Android Keystoreと標準の暗号化APIなどを利用し、必要に応じてGoogle Tinkの採用も検討します。

5-2. 暗号化とハードウェア保護

Androidでは、AES-GCMなどの標準的な暗号方式を利用できます。

また、対応端末では暗号鍵をTEE（Trusted Execution Environment）やStrongBoxなどで保護できます。

ハードウェア保護の対応状況は端末によって異なります。

独自の暗号アルゴリズムを作成せず、標準の安全な方式を利用することが基本です。

6. ネットワーク通信とAPIの保護

アプリとサーバー間の通信では、盗聴、改ざん、認証情報の漏洩を防ぐ必要があります。

6-1. HTTPSとNetwork Security Configuration

Androidでは「Network Security Configuration」を利用して、ネットワーク通信のセキュリティ設定を管理できます。

たとえば、平文HTTP通信を禁止する設定は次のようになります。

<network-security-config>
    <base-config
        cleartextTrafficPermitted="false" />
</network-security-config>

Android 9（APIレベル28）以降をターゲットとするアプリでは、標準的なネットワークAPIの平文HTTP通信はデフォルトで制限されています。ただし、独自の通信実装などでは別途確認が必要です。

また、HTTPSは通信経路を保護する仕組みであり、APIへの不正アクセスそのものを防ぐものではありません。

6-2. APIキーの管理

APKやAABに含まれるコードやリソースは、解析によって読み取られる可能性があります。

難読化しても、アプリに含めた秘密情報を完全に隠すことはできません。

6-3. サーバー側の対策

サーバーでは、次の対策も必要です。

Play Integrity APIは、アプリや端末の整合性について判断するための情報を提供します。

ただし、不正利用を完全に検出できるものではなく、ユーザー認証やサーバー側のアクセス制御の代わりにはなりません。

7. 認証とアクセス制御

ログイン機能があっても、認証やアクセス権限の検証に問題があれば、他人の情報を取得される可能性があります。

7-1. 安全な認証方式

Androidの Credential Manager は、パスワード、パスキーなどの認証方法を統合して扱う仕組みです。

また、BiometricPrompt は指紋や顔などによる端末内の本人確認に利用できますが、それだけでサーバー側のアクセス権限が保証されるわけではありません。

7-2. サーバー側での認可

たとえば、次のAPIがあるとします。

GET /api/users/123/profile

ユーザーIDを 124 に変更するだけで他人の情報が取得できてしまう場合、アクセス制御に問題があります。

APIでは認証状態だけでなく、操作対象のデータにアクセスする権限があるかどうかをサーバー側で検証する必要があります。

画面上でボタンを非表示にするだけでは、不正操作を防げません。

8. アプリ間の情報共有とWebView

Androidではサンドボックスによってアプリ間のアクセスが制限されていますが、Intentなどを通じてデータを受け渡せます。

8-1. アプリ間の情報共有

主な共有機能には、次のものがあります。

特に AndroidManifest.xml の設定に注意が必要です。

Activity、Service、BroadcastReceiver、ContentProvider の公開範囲に問題があると、他のアプリから意図しない処理を実行される可能性があります。

8-2. WebViewの安全性

WebView でWebコンテンツを表示する場合にも注意が必要です。

特に addJavascriptInterface では、JavaScriptからAndroid側のメソッドを呼び出せます。

信頼できないWebページから重要な端末機能を実行できないように設計する必要があります。

9. 個人情報・ログ・通知の取り扱い

機密情報は、ログや画面からも漏洩する可能性があります。

9-1. 個人情報へのアクセス権限

カメラ、マイク、写真、連絡先、位置情報などには、必要な範囲でアクセスします。

AndroidではOSバージョンによって権限の種類や動作が変化するため、対応するバージョンごとに確認が必要です。

9-2. ログへの情報漏洩

次のようなコードは避けます。

Log.d("Auth", "Token: $accessToken")

パスワード、認証トークン、個人情報などをLogcatに出力しないことが重要です。

また、クラッシュ解析やアクセス解析のSDKにも、意図しない情報が送信されていないか確認します。

9-3. 画面や通知からの漏洩

Androidでは、機密性の高い画面に FLAG_SECURE を設定することで、通常のスクリーンショットや一部の画面共有を制限できます。

window.addFlags(
    WindowManager.LayoutParams.FLAG_SECURE
)

ただし、別の端末での撮影など、あらゆる情報流出を防げるわけではありません。

10. 外部ライブラリと開発環境の保護

Androidアプリ開発では、外部ライブラリやGitHub、CI/CD、AI開発ツールなども攻撃対象になる可能性があります。

10-1. 外部ライブラリとSDK

特に広告SDKやアクセス解析SDKは、アプリが収集する情報の範囲に影響します。

10-2. GitとCI/CD

特に keystore.jks などの署名鍵やパスワードが漏洩しないようにします。

Google Play App Signingを利用する場合も、アップロード鍵やPlay Consoleへのアクセスを適切に管理する必要があります。

秘密情報を誤ってコミットした場合は、Gitの履歴から削除するだけでなく、該当するキーやトークンを失効・再発行します。

10-3. AI開発ツールの安全性

CodexやClaude CodeなどのAIエージェントを利用する場合も注意が必要です。

AIが生成したコードが安全とは限りません。特に認証、暗号化、アクセス制御などの重要な処理では、人間によるレビューが必要です。

11. データの削除とアプリの運用

個人情報の保護では、保存だけでなく削除方法も重要です。

11-1. データの削除

ログアウト、退会、アンインストール時には、次のデータの扱いを確認します。

通常、アンインストール時にはアプリ専用データやKeystoreの鍵が削除されます。

ただし、バックアップされたデータが再インストール時に復元される場合があります。

また、退会時にはサーバーやクラウド上のデータに加え、バックアップに残るデータの保存期間や削除方針も確認します。

11-2. アプリの継続的な運用

アプリ公開後も、脆弱性への対応が必要です。

Androidは端末メーカーやOSバージョンによって更新状況が異なるため、サポート対象の決定も重要です。

12. セキュリティテストと公開前チェック

モバイルアプリのセキュリティ評価には、OWASPが公開する「MASVS」（Mobile Application Security Verification Standard）を利用できます。

MASVSは、モバイルアプリが満たすべきセキュリティ要件を定義した標準であり、チェックツールではありません。

12-1. MASVSの8つの領域

MASVSは、次の8領域で構成されています。

具体的な検証方法は「MASTG」（Mobile Application Security Testing Guide）にまとめられています。また、「MASWE」（Mobile Application Security Weakness Enumeration）では、モバイルアプリのセキュリティ上の弱点が体系化されています。

MASVSで「何を確認するか」を定義し、MASTGで「どう確認するか」を調べ、解析ツールや手動テストで検証するという関係です。

12-2. AIエージェントによるセキュリティレビュー

CodexやClaude CodeなどのAIエージェントに、MASVSのセキュリティ要件に沿ったレビューを依頼する方法も有効です。

AIエージェントなら、Kotlinコード、AndroidManifest.xml、Gradle設定、依存ライブラリなどを横断的に調査し、潜在的な問題を洗い出せます。

たとえば、次のように依頼します。

ただし、AIによるコードレビューだけではMASVSへの適合を保証できません。

実機での動作、通信内容、サーバー側のアクセス制御、Googleバックアップの設定などは、別途検証が必要です。

なお、AIへのソースコード送信やツール実行の安全性についても、事前に設定を確認します。

12-3. 公開前のチェックリスト

AIエージェントによる初期レビュー → 指摘事項の修正 → 実機・APIのセキュリティテストという流れで確認するとよいでしょう。

13. まとめ

Androidは強力なセキュリティ機能を備えていますが、アプリやサーバーの実装に問題があれば、サイバー攻撃や情報漏洩は発生します。

特に重要なのは、機密情報の安全な保存、Googleバックアップや外部アプリとの共有範囲、通信の保護、サーバー側でのアクセス制御です。

また、外部ライブラリやAI開発ツール、開発環境の管理も含め、設計から公開後の運用まで継続的に安全性を確認する必要があります。

MASVSのような標準やAIエージェントを活用しながら、セキュリティ対策を開発プロセスに組み込むことが、安全なAndroidアプリの提供につながります。

関連