自動アップデートのセキュリティ設計

はじめに

自動アップデートは、アプリに「外部からファイルを取得し、既存の実行物を置き換える」経路を組み込むことです。これは信頼境界そのものです。

よくある誤解は「HTTPSだから安全」ですが、TLSは通信経路しか守れません。サーバー侵害や誤配信には対応できないため、別の防御層が必要です。

1. まず結論

• 要件が合うなら、MSIX App InstallerやClickOnceなどの既存基盤を優先する
• 自前updaterを作るなら、UIより先に署名検証と失敗時復旧を入れる
• latest.json は未署名ではなく署名付きmetadataとして扱う
• 更新の判断は「サーバーがそう言っているから」ではなく「クライアントが検証できたから」にする
• 署名鍵は開発用と本番用を分離する
• 更新失敗時はfail-open（検証失敗でも続行）ではなくfail-closed（停止）にする
• ロールバック対策がないと、脆弱な古いバージョンに戻されるリスクがある

2. ダメなパターン一覧

3. ベストプラクティス

3.1 まずは既存の更新基盤を使う

Windowsなら以下を最初に検討してください。

• MSIX + App Installer
• ClickOnce（.NETデスクトップアプリ）
• Store / MDM / 社内配布基盤

自前updaterは更新責任をすべて自分で持つことを意味します。

3.2 信頼の起点をクライアントに置く

更新が安全であるためには、クライアントが次の2つを持つ必要があります。

1. 信頼する公開鍵（または証明書チェーン）
2. その鍵で署名されたmetadataを検証する仕組み

3.3 署名付きmetadataの設計

更新metadataには最低限以下を含め、すべて署名対象にします。

3.4 成果物自体も検証する

metadata検証後、ダウンロードした成果物でも確認:

• ファイルサイズ
• ハッシュ値
• コード署名（Authenticode）
• 発行元の識別子

3.5 鍵管理のルール

• 開発用、ステージング用、本番用で署名鍵を分離する
• 本番鍵は HSM またはクラウド署名サービスに置く
• 署名操作に承認フローと監査ログを導入する
• キーローテーションの手順を用意する

3.6 更新フロー（fail-closed）

1. metadataを取得
2. 署名・有効期限・バージョン・チャネルを検証 → 失敗なら停止
3. 成果物をstaging領域へダウンロード
4. hash/size/署名を検証 → 失敗なら停止
5. 旧版を残したままactivation準備
6. 再起動時または専用helperで切り替え
7. 初回起動の健全性確認
8. 問題があれば旧版へrollback

3.7 権限の分離

| 処理 | 必要な権限 | |——|———–| | ダウンロードと検証 | 低権限（通常ユーザー） | | ファイル置換 | 最小権限のhelper（必要な場合のみ昇格） |

3.8 攻撃対策

• ロールバック対策: クライアントが見た最高のバージョンを保持し、より古い版を拒否する
• フリーズ対策: metadataに有効期限（expiry）を持たせる
• ミックスアンドマッチ対策: metadataに対象成果物のhash/size/versionを固定する

4. 最小安全構成

自前updaterを作る場合の最小構成:

クライアント側が持つもの:

• 信頼するroot公開鍵（または固定した証明書チェーン）
• 現在実行中のversion
• 過去に見た最高のmetadata version
• 許可するchannel
• rollback用の直前バージョン

サーバー側が返すもの:

• 署名されたupdate metadata
• 署名済みの成果物
• 必要ならblocklist / minimum allowed version

5. Windows案件での考え方

まず配布方式に合わせて選びます。

1. MSIX App Installer（要件が合う場合）
2. ClickOnce（.NET社内アプリ、per-user配布）
3. MSI + 独自updater（高度な制御が必要な場合）

独自updaterを選んでも、責任は減らずむしろ増えます。Authenticode署名検証、signed manifest、rollback対策、権限分離をすべて自前で用意する必要があります。

6. 最低限のチェックリスト

自前updaterをリリースする前に:

• 更新metadataは署名されている
• metadataにversion/hash/size/channel/expiryが含まれている
• クライアント側で署名とversionを検証している
• 成果物のhashとコード署名を検証している
• 本番署名鍵は開発環境から分離されている
• staging更新で旧版を残したまま切り替えている
• 検証失敗時はfail-closedで停止する
• rollbackの条件と手順がある
• blocklist / minimum allowed versionを配れる
• 失敗率や署名検証失敗を監視できる

7. まとめ

自動アップデートのセキュリティは一言で言うと:

「更新の便利さ」ではなく、「誰を信頼し、クライアントがどう検証するか」を設計する。

• 既存基盤で足りるなら、まずはそれに乗る
• 自前updaterを作るなら、UIより先に署名付きmetadataと鍵管理を入れる
• 失敗時の復旧とrollbackを設計しないupdaterは本番で致命的な事故を起こす
• updaterは「配布機能」ではなく「製品のセキュリティ境界」である

8. 参考資料

• CISA Secure by Design Pledge
• NIST: Security Considerations for Code Signing
• NIST Secure Software Development Framework (SSDF)
• The Update Framework Specification
• TUF: Roles and metadata
• TUF: Security
• Microsoft Learn: Authenticode Digital Signatures
• Microsoft Learn: Auto-update and repair apps - MSIX
• Microsoft Learn: ClickOnce Deployment and Security
• Apple Developer: Developer ID
• CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

Windows技術トピック

Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。

このテーマがつながるサービス

Windowsアプリ開発

自動更新は UI だけの話ではなく、配布方式、権限、復旧、運用まで含む設計です。Windows アプリの新規開発や既存ソフトの見直しで、更新方式の整理から対応できます。

技術相談・設計レビュー

「独自 updater が必要なのか」「MSIX / ClickOnce で十分なのか」「いまの更新設計のどこが危ないのか」といった整理段階から相談できます。

著者プロフィール

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

• プロフィールを見る
• お問い合わせ