iOS应用开发的安全对策：防止网络攻击与信息泄露的注意事项

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

目次

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

1. はじめに

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

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

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

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

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

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

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

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

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

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

iOSアプリのデータは、基本的にアプリごとのサンドボックス内に保存されます。ただし、保存場所によって用途やバックアップの扱いが異なります。

3-1. 主な保存場所

ユーザーが管理する文書には Documents、アプリ内部のデータには Application Support を使用します。

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

Documents 内のファイルは、アプリの設定によって「ファイル」アプリなどから操作できます。

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

機密性の高い内部データは、不用意に外部公開しないようにします。

また、ファイルにはData Protectionによるアクセス制御を設定できます。

try data.write(
    to: fileURL,
    options: [.atomic, .completeFileProtection]
)

.completeFileProtection を指定すると、端末がロックされている間は、原則としてファイルにアクセスできなくなります。

ただし、バックグラウンド処理が必要な場合は、適切な保護レベルを選択する必要があります。

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

iCloudでは、アプリのデータをバックアップしたり、複数端末間で同期・共有したりできます。

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

4-1. iCloudの主な仕組み

たとえば、Documents に保存したファイルがiCloudバックアップに含まれていても、それだけでiCloud Drive上の共有ファイルになるわけではありません。

バックアップが不要なデータは、保存場所の選択やバックアップ除外設定で制御します。

4-2. CloudKitのアクセス制御

CloudKitには、3種類のデータベースがあります。

特にPublic Databaseでは、設定されたアクセス権限に従って他のユーザーがデータを読み取れるため、個人情報を不用意に保存しないようにします。

共有機能を実装する場合も、閲覧・編集権限や共有解除時の動作を確認します。

4-3. iCloudの暗号化

iCloudではデータが暗号化されますが、すべてのデータが常にエンドツーエンド暗号化されるわけではありません。

CloudKitでは、encryptedValues を使用して特定のフィールドを端末上で暗号化できます。ただし、Public Databaseでは利用できません。

また、iCloudの「高度なデータ保護」を有効にすると、CloudKitのPrivate DatabaseやShared Databaseの暗号化フィールドについても、暗号鍵へのアクセスがデータの所有者と共有相手に限定されます。

機密性の高いデータでは、iCloudの暗号化だけに依存せず、アクセス制御や必要に応じたアプリ独自の暗号化も検討することが重要です。

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

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

5-1. Keychainによる保存

パスワード、アクセストークン、秘密鍵などの保存には、Keychainを利用します。

Keychainの項目には、バックアップや端末移行で引き継げるものと、特定の端末に限定されるものがあります。

用途に応じた設定が必要です。

5-2. CryptoKitとSecure Enclave

iOSには、暗号処理のための「CryptoKit」と、暗号鍵を保護する「Secure Enclave」があります。

Secure Enclaveは、任意のファイルを直接保存する汎用ストレージではありません。

データの暗号化にはCryptoKit、鍵の管理にはKeychainやSecure Enclaveを組み合わせて利用します。

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

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

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

6-1. HTTPSとATS

iOSには、安全なネットワーク通信を要求する「App Transport Security（ATS）」が用意されています。

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

6-2. APIキーの管理

アプリに埋め込んだAPIキーや秘密情報は、解析によって取得される可能性があります。

アプリに含めた秘密情報は、攻撃者に取得される可能性があるという前提で設計します。

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

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

App Attestは正規アプリからのリクエストかどうかの検証を支援しますが、認証やアクセス制御の代わりにはなりません。

7. 認証とアクセス制御

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

7-1. 安全な認証方式

Face IDは端末内での本人確認に利用できますが、それだけでサーバー側のアクセス権限が保証されるわけではありません。

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

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

GET /api/users/123/profile

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

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

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

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

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

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

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

機密情報を外部に渡す場合は、共有先や公開範囲を確認します。

特にカスタムURLスキームでは、他のアプリによる処理の横取りや不正な入力を想定し、認証トークンなどを不用意に含めないようにします。

8-2. WebViewの安全性

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

特にJavaScriptとSwiftを連携させる場合は、信頼できないWebページから機密操作を実行できない設計が必要です。

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

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

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

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

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

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

print("Token: \(accessToken)")

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

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

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

iOSではバックグラウンド移行時に画面のスナップショットが生成されるため、必要に応じて機密情報を隠す処理を実装します。

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

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

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

また、利用するAPIやSDKに応じて必要となるPrivacy Manifest（PrivacyInfo.xcprivacy）を設定し、App Storeのプライバシー情報も正しく申告します。

10-2. GitとCI/CD

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

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

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

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

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

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

11-1. データの削除

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

特に、アプリをアンインストールしてもKeychainの情報が残る場合があるため、再インストール時の動作も確認します。

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

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

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

監視ログ自体にも、個人情報を過剰に記録しないよう注意します。

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

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

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

12-1. MASVSの8つの領域

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

具体的な検証方法は「MASTG」（Mobile Application Security Testing Guide）にまとめられています。

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

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

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

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

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

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

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

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

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

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

13. まとめ

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

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

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

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