アプリのセキュリティ対策は、公開前に診断を一度受けて終わる作業ではありません。
守るデータ、利用者、権限、通信先、端末、運用者を洗い出し、悪用された場合の影響を設計、実装、テスト、監視へ反映します。
すべてを同じ強さで守ろうとせず、個人情報、決済、管理権限、データ削除から優先してください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 対象 | 主な脅威 | 基本対策 |
|---|---|---|
| アカウント | 乗っ取り、権限昇格 | 強い認証、再認証、最小権限 |
| 端末内データ | 抽出、紛失、バックアップ流出 | 保存最小化、適切な保護、削除 |
| 通信 | 盗聴、改ざん、偽装先 | TLS、証明書検証、応答検証 |
| API、DB | 入力悪用、他人データ閲覧 | 入力検証、サーバー側認可 |
| 依存関係 | 脆弱版、供給元の侵害 | 版管理、更新、構成記録 |
| 運用 | 鍵漏えい、誤設定、対応遅れ | 分離、監視、失効、対応手順 |
脅威をデータと操作の境界で分ける
ログインできることと、すべてのデータへアクセスしてよいことは別です。
認証は本人やシステムを確認し、認可はその主体が実行できる操作と対象データを決めてください。
| 境界 | 確認する問い | 失敗例 |
|---|---|---|
| 端末とAPI | 誰のトークンで何を送るか | 他人のIDへ差し替え |
| APIとDB | 行単位の権限はどこで判定するか | 認証済みなら全件取得 |
| 利用者と管理者 | 強い操作で再認証するか | 一般権限から削除 |
| 自社と外部API | 秘密値と同意をどう管理するか | キー埋込み、過剰権限 |
OWASP MASVSは、モバイルアプリの保存、暗号、認証、通信、プラットフォーム連携、コード品質などを検証領域として整理しています。
サーバー側やWeb APIにはOWASP ASVSを併用し、端末だけを診断対象にしないことが重要です。
脅威一覧には、攻撃者だけでなく利用者の誤操作、管理者の設定ミス、外部サービス停止も含めます。
誰が、どの入口から、何を変更できるかを具体的な操作で書いてください。
設計から運用までを七段階でつなぐ
安全性を一担当者へ任せず、各工程の完了条件に入れます。
- 個人情報、秘密値、管理操作など守る対象を分類する
- 利用者、管理者、外部サービス、攻撃者の入口を描く
- 認証、認可、保存、通信、ログの要求を決める
- 安全な実装規則とレビュー対象をチームで共有する
- 正常だけでなく権限違い、改ざん、期限切れをテストする
- ログ、アラート、鍵の更新、依存関係の監視を準備する
- 漏えい、乗っ取り、脆弱性報告への対応手順を訓練する
NIST Secure Software Development Frameworkは、安全な開発の準備、ソフトウェアの保護、安全な生成、公開後の脆弱性対応を一連の活動として扱っています。
診断結果を修正するだけでなく、同じ種類の欠陥を設計規則とテストへ戻します。
安全な実装規則を作る際は、IPAのセキュア・プログラミング講座のような公的資料を参照し、入力、メモリ、エラー処理など利用言語に該当する項目を選んでください。
発生可能性と影響を掛けるリスク計算例
次の数字は、対策の順番を決めるための仮定です。
発生可能性と影響をそれぞれ1から5で評価し、掛け算した値を比較します。
管理者権限の奪取が可能性3、影響5ならリスク値は15です。
プロフィール画像の表示崩れが可能性5、影響1ならリスク値は5なので、件数が少なくても管理権限の対策を先にします。
| 事象 | 可能性 | 影響 | 仮の値 |
|---|---|---|---|
| 管理者権限の奪取 | 3 | 5 | 15 |
| 他人データの閲覧 | 2 | 5 | 10 |
| 表示崩れ | 5 | 1 | 5 |
数字は議論をそろえる補助であり、絶対的な安全度ではありません。
法令、契約、生命や財産への影響がある事象は、単純な積だけで優先度を下げないでください。
秘密情報と端末データを最小限にする
APIキー、署名鍵、管理者トークンをソースコードへ直接書きません。
配布アプリへ含めた値は解析される可能性があるため、サーバー側で保持できる秘密は端末へ渡さないことが基本です。
配布アプリから利用する地図キーなどは、完全に隠すのではなく利用先を制限します。
Google Maps PlatformのAPIセキュリティ推奨事項に沿い、利用アプリ、Webサイト、IP、APIの制限と鍵の分離を行います。
端末にはオフライン利用に必要なデータだけを保存し、ログアウト、退会、端末紛失時の削除範囲を決めます。
「暗号化したから保存してよい」ではなく、そもそも保存しない選択を先に検討してください。
ログにも秘密値や個人情報をそのまま書きません。
調査に必要な利用者の匿名識別子、操作、結果、相関ID、時刻を残し、本文やトークンはマスキングします。
公開後の鍵更新と脆弱性対応を準備する
安全な版を公開しても、依存ライブラリ、OS、外部API、攻撃手法は変化します。
構成要素、利用版、供給元、更新担当者、サポート期限を台帳へ残してください。
脆弱性報告の窓口と一次回答の手順を用意します。
報告を受けたら、影響範囲、悪用の有無、一時対策、修正版、利用者への連絡を分けて判断します。
管理者トークンや鍵が漏れた場合に、失効して再発行できるかを演習します。
バックアップから戻すだけでは漏れた鍵も戻るため、データ復旧と資格情報の更新は別の手順です。
監視は攻撃数だけでなく、ログイン失敗の急増、権限エラー、通常と異なるデータ出力、鍵の利用先を見ます。
アラートには確認方法、一時停止手段、責任者、連絡先を付けてください。
アプリ開発のセキュリティ対策でよくある質問
生体認証を付ければログインは安全ですか？
生体認証は端末上の本人確認を強められますが、サーバー側のセッション、再認証、端末紛失、アカウント復旧、認可まで自動で解決しません。
モバイル認証を確認する際はOWASP MASVSの認証領域とアプリの実際の復旧手順を照合してください。
データを暗号化すれば保存してもよいですか？
暗号化は重要ですが、鍵の保管、復号権限、バックアップ、ログ、削除まで設計が必要です。
必要性のない個人情報や秘密値は保存せず、保持するデータだけを適切な仕組みで保護します。
セキュリティ診断は公開直前だけでよいですか？
診断は有効ですが、要件、設計、コードレビュー、依存関係、テスト、監視へ安全性を入れる必要があります。
NIST SSDFの工程全体の考え方を使い、診断で見つかった原因を開発手順へ戻してください。
守る対象と対応責任者が明確なアプリを公開する
セキュリティ対策の成果は、チェック項目の数ではなく重要なデータと操作を継続して守れる仕組みです。
最小権限、保存最小化、失効可能な秘密情報、検証可能な対応手順を設計から運用までつなげます。
- 認証と認可を分ける主体確認、操作権限、対象データの境界
- リスク評価で先に扱う個人情報、決済、管理権限、データ削除
- 端末へ残さない秘密値と配布キーへ加える利用先制限
- 公開後の台帳、更新担当、脆弱性窓口、鍵失効の演習
対策をコードへ維持する方法は、読みやすさと保守性を高めるコード設計で責任分離とレビュー単位へ落とし込めます。
