合同会社小村ソフト
メニュー

自動アップデート機能のセキュリティ基本 - ダメなパターンとベストプラクティス

· · Windows開発, セキュリティ, updater, 自動更新, 署名, MSIX, ClickOnce

目次

  1. まず結論
  2. なぜ自動アップデートは危険領域なのか
  3. ダメなパターン
  4. ベストプラクティス
  5. 最小安全構成
  6. Windows 案件ではどう考えるか
  7. 最低限のチェックリスト
  8. まとめ
  9. 参考資料

1. まず結論

かなり雑に、でも実務で使いやすく言うとこうです。

  • 要件が合うなら、まず MSIX App Installer や ClickOnce など既存の更新基盤を優先する
  • 自前 updater が必要なら、最初に入れるべきは UI ではなく署名検証と失敗時復旧
  • latest.json のような更新情報は、未署名の設定ファイルではなく署名された metadata として扱う
  • TLS は必要だが十分条件ではない
  • 更新判定は「サーバーがそう言っているから」ではなく、「クライアントが検証して正しいと判断できたから」にする
  • 署名鍵は開発用と本番用を分離し、HSM や署名サービスで保護する
  • 更新失敗時は fail-open ではなく fail-closed にする
  • ロールバック対策がない updater は、脆弱版へ戻される前提で考えたほうが安全
  • 署名検証をまだ入れられない段階なら、自動更新より手動の署名済み installer 配布のほうが安全

要するに、自動アップデートの核心は「どうダウンロードするか」ではなく、「何を信頼し、どこで検証し、壊れたときにどう戻すか」です。

2. なぜ自動アップデートは危険領域なのか

通常の機能は、アプリの中に閉じています。 一方、updater は次の 3 つを一気に持ちます。

  1. 外部からファイルを取りに行く
  2. そのファイルを信頼する
  3. 既存の実行物を置き換える

つまり、任意コード実行の経路が製品の中に最初から組み込まれている、ということです。

ここでよくある誤解が、「HTTPS だから安全」というものです。 もちろん TLS は必要です。ただ、それで守れるのは主に通信経路と接続先の正当性です。更新サーバーそのものが侵害された、誤った成果物が正規 CDN へ置かれた、未署名の manifest が差し替えられた、という話には、それだけでは足りません。

実際、TUF が整理している脅威だけでも、更新系には次のようなものがあります。

  • 任意の不正ソフトを入れさせる
  • 脆弱な古い版へ戻させる rollback
  • 新版を見せない freeze
  • 互いに整合しない metadata と成果物を混ぜる mix-and-match

つまり、自動アップデートは「ファイル転送」ではなく「信頼の配布」です。 ここを設計して初めて、自動更新が安全に回り始めます。

3. ダメなパターン

先に、実務でよく見る危ない形をまとめます。

ダメなパターン 何が危ないか 最低限の直し方
version.json を HTTPS で取り、URL の zip / exe をそのまま実行 origin 侵害、設定差し替え、誤配信に弱い 署名付き metadata と成果物のクライアント検証に変える
バイナリだけ署名し、manifest は未署名 URL、version、channel、必須更新フラグを改ざんできる version / hash / size / channel / expiry を含む signed manifest にする
署名鍵を開発 PC や CI のファイルに置く 侵害されると正規署名付きマルウェアを配られる HSM / 署名サービス + 承認フロー + 監査ログ
更新失敗時に「検証エラーを無視して続行」 事故時に一番弱い経路が開く fail-closed にする
旧版を残さず上書き更新 電源断、ディスク不足、途中失敗で起動不能 staging + atomic activate + rollback
バージョン比較だけで古い版を許す 脆弱版への rollback が通る 単調増加する release version と最高既知版の保存
updater 全体を管理者権限で動かす 侵害時の被害範囲が広い ダウンロード/検証は低権限、置換だけ最小 helper へ分離
差分更新から始める 実装が複雑で検証漏れが増える まずはフルパッケージ更新から始める

以下、少し詳しく見ます。

3.1 HTTPS だから大丈夫、で止まる

これは一番多いです。

  • 起動時に latest.json を読む
  • downloadUrl を取り出す
  • zip / exe を落とす
  • 展開して差し替える
  • 終了

見た目はそれっぽいですが、信頼の根がサーバー返答に寄りすぎています。 更新サーバーや配信設定が侵害されたら、正しい HTTPS の上で不正な更新を配れてしまいます。

TLS は必要です。 ただし、TLS だけでは updater の設計は終わりません。

3.2 署名はしているが、クライアント側で検証していない

リリース時にファイルへ署名していても、クライアントがそれを見ていなければ意味がありません。

よくあるのは、

  • CI では署名している
  • でも updater は hash しか見ていない
  • しかもその hash 自体が未署名 manifest から来る

という形です。

これだと、manifest を差し替えられた時点で、hash も一緒にすり替えられます。 「hash を見ているから安全」は、hash の出どころまで守れて初めて成立します。

3.3 manifest が未署名

更新系で本当に守るべきなのは、実行ファイルそのものだけではありません。 少なくとも次の情報は、改ざんされると危険です。

  • version / release id
  • ダウンロード対象の URL やファイル名
  • hash / size
  • channel（stable / beta など）
  • 必須更新かどうか
  • 適用可能な OS / アーキテクチャ
  • metadata の有効期限
  • 最低必要 updater version

つまり、更新判断に使う情報は全部 signed metadata に入れる くらいの感覚がちょうどいいです。

3.4 署名鍵の扱いが雑

更新機能の安全性は、かなりの割合で鍵管理の安全性です。

本番署名鍵が次のように置かれているなら、かなり危険です。

  • 開発 PC の証明書ストアに入れっぱなし
  • CI の secret として .pfx をアップロード
  • 複数人が同じ秘密鍵をローカルへ配布
  • 開発用署名と本番用署名が同じ信頼鎖

これだと、updater 自体が正しくても「正規署名された不正更新」を止められません。

3.5 旧版を残さない上書き更新

更新は、成功時より失敗時の設計が大事です。

  • ダウンロード途中で切れた
  • 展開に失敗した
  • 置換途中で電源断した
  • 新版は起動したが初回 migration で落ちた

このとき、旧版が消えていると復旧が重くなります。 実務では「更新に失敗した」という事実より、「現場でアプリが起動しなくなった」のほうが問題になります。

3.6 rollback を考えていない

署名された正規版でも、古い脆弱版なら攻撃者にとって都合がいいことがあります。

たとえば、

  • version 1.8 に既知脆弱性がある
  • 現場は 2.3 へ上がっている
  • 攻撃者が 1.8 を再配信する

これが通ると、署名自体は正しいのに危険です。

「署名されているか」だけではなく、「その版を今入れてよいか」まで見ないと足りません。

3.7 fail-open

本番で一番やってはいけないのがこれです。

  • 署名検証に失敗したら警告だけ出して続行
  • 証明書の期限エラーを無視できる hidden flag がある
  • デバッグ用の skipVerify=true が本番でも残る

障害時や攻撃時ほど、こういう抜け道が本命になります。

4. ベストプラクティス

4.1 まずは既存の更新基盤に乗る

自前 updater が本当に必要かは、最初に疑ったほうが安全です。

Windows なら、要件が合う限りは次を優先検討しやすいです。

  • MSIX + App Installer
  • ClickOnce
  • Store / MDM / 社内配布基盤
  • MSI + 企業側の配布管理

理由は単純で、更新そのものの責任範囲をある程度プラットフォームへ寄せられるからです。 もちろん自由度は下がりますが、更新 UI、配布 manifest、パッケージ署名、運用との整合が取りやすくなります。

自前 updater が必要になるのは、たとえば次のような時です。

  • stable / beta / preview の複数チャネルを厳密に制御したい
  • 段階配信や rollout 率を持ちたい
  • 独自の業務都合で更新タイミングを細かく制御したい
  • MSIX / ClickOnce に乗らない構成がある

この場合でも、「自由度が欲しい」ではなく「更新責任を自分たちで持つ」と理解したほうがぶれません。

4.2 信頼の起点をクライアント側へ持つ

安全な updater は、サーバー返答をそのまま信用しません。 クライアント側に、少なくとも次の 2 つが必要です。

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

要するに、「サーバーが最新版と言っている」ではなく、 「この metadata は、信頼している署名者が出した最新版だ」とクライアントが確認できる状態を作る必要があります。

4.3 signed metadata を中心に設計する

最低限、更新 metadata には次を入れて署名対象にします。

項目 入れる理由
release version / release id rollback 防止、監査
artifact 名、URL、package type どのファイルを取るかを固定する
hash、size 改ざん検知、壊れた配信の検知
channel stable に beta を混ぜない
対象 OS / architecture 誤配布防止
minimum updater version protocol 変更時に古い updater を止める
expires_at freeze 対策
published_at 監査、切り分け
mandatory / optional 更新 UX の分岐も改ざん不可にする

ここで大事なのは、更新の判断材料を全部 signed metadata に集約する ことです。 ロジックはクライアントにあり、情報の真正性は署名で守る、という形に寄せると事故が減ります。

4.4 成果物そのものも検証する

metadata を検証したあと、ダウンロードした成果物でも次を確認します。

  • size
  • hash
  • パッケージ署名 / コード署名
  • 発行元や期待する識別子

Windows の PE / MSI / MSIX を扱うなら、AuthentiCode やパッケージ署名の検証をクライアント側で行う前提にしたほうが安全です。 macOS なら Developer ID と notarization を更新経路でも前提にしたほうがぶれません。

4.5 鍵は機能ではなく運用で守る

鍵管理は、実装より運用で差が出ます。

最低でも次は分けたほうが安全です。

  • 開発用署名鍵
  • ステージング用署名鍵
  • 本番用署名鍵

さらに本番用は、

  • HSM
  • クラウド署名サービス
  • 承認フロー付きの signing system
  • 監査ログ
  • key rotation 手順
  • timestamp 付き署名

まで含めて設計したいです。

「本番ビルドが通れば CI が自動署名する」は便利ですが、侵害時の被害半径も大きくなります。 少なくとも、誰が何をいつ署名したかは追えるようにしておくべきです。

運用が乗ってきたら、滅多に変えない root trust と、頻繁に再署名する更新 metadata の鍵を分けるとさらに安全です。 root を offline 寄りに保ち、更新 metadata には別鍵を使う設計は、鍵侵害時の被害半径を下げやすくなります。

4.6 fail-closed と staged update

更新フローは、次の順が基本です。

  1. metadata を取得
  2. 署名と有効期限と version を検証
  3. 成果物を staging 領域へダウンロード
  4. hash / size / 署名を検証
  5. 旧版を残したまま activation 準備
  6. 再起動時か専用 helper で切り替え
  7. 初回起動の健全性確認
  8. 問題があれば rollback

ここで重要なのは、 検証が終わる前に置き換えない 失敗したら進めない の 2 つです。

4.7 updater の権限を絞る

updater 全体を管理者権限で動かすのは避けたいです。

理想は次の分離です。

  • ダウンロードと検証: 低権限
  • 実ファイル置換だけ: 最小の権限を持つ helper
  • helper は「検証済み package を所定場所へ置く」以上のことをしない

権限昇格が必要な設計ほど、昇格前に何を検証済みかをはっきり分けないと危なくなります。

4.8 rollback / freeze / mix-and-match を最初から潰す

ここは後から足すとつらいので、最初に入れたほうがいいです。

  • rollback 対策
    クライアントは「今まで見た最高の metadata version / release version」を保持し、それより古いものを拒否する

  • freeze 対策
    metadata に expiry を持たせ、古すぎる metadata を拒否する

  • mix-and-match 対策
    metadata 同士の整合性を持たせる。少なくとも manifest 自体に対象 artifact の hash / size / version を固定する

加えて、特定 build を拒否する blocklist や minimum allowed version を signed metadata で配れると、事故時の封じ込めが速くなります。

TUF をそのまま採用しなくても、この 3 つの性質はかなり重要です。

4.9 最初はフル更新から始める

差分更新は帯域には効きますが、最初の実装としては複雑です。

  • どの旧版からどの新版へ当てる差分か
  • 差分適用前の前提 hash
  • 差分適用後の最終 hash
  • 途中失敗時の復旧
  • 部分適用や古い差分の掃除

このへんが一気に増えます。 初期版では、署名済みフルパッケージを安全に入れ替える ところまでで十分です。

5. 最小安全構成

フル TUF ほど大げさにしないとしても、自前 updater の最小安全構成はだいたい次になります。

5.1 クライアントが持つもの

  • 信頼する root 公開鍵、または固定した証明書チェーン
  • 現在動作中の version
  • 過去に見た最高の metadata version / release version
  • 許可する channel
  • rollback 用の直前版

5.2 サーバーが返すもの

  • 署名された update metadata
  • 署名済みまたは platform 署名された成果物
  • 必要なら blocklist / minimum allowed version 情報

5.3 典型フロー

metadata を取る
  ↓
署名・expiry・version・channel を検証
  ↓
成果物を staging へ落とす
  ↓
size / hash / package signature を検証
  ↓
旧版を残したまま activation
  ↓
初回起動に失敗したら rollback

ここで大事なのは、更新サーバーの応答だけでは何も成立しない ことです。 成立させるのは、クライアントが持つ trust anchor と、検証ロジックです。

6. Windows 案件ではどう考えるか

Windows アプリでは、まず配布方式から逆算したほうが整理しやすいです。

  • 要件が合うなら MSIX App Installer
  • .NET の社内アプリで per-user が合うなら ClickOnce
  • サービス、driver、shell extension、独自チャネル制御まで必要なら MSI + 独自 updater も比較対象

ただし、独自 updater を選んでも、やるべきことは減りません。 むしろ増えます。

  • Authenticode / パッケージ署名の検証
  • signed manifest
  • rollback 対策
  • 更新 helper の権限分離
  • updater 自身の更新戦略

Windows でありがちな危ない形は、DownloadFile -> unzip -> kill process -> overwrite -> restart の一直線です。 これは動くことはありますが、セキュリティと復旧性の両方が弱いです。

SmartScreen や UAC の警告を「詳細情報 → 実行」で乗り切らせる運用は、更新設計ではなく警告馴化です。 正しい更新経路を作るなら、警告を慣れさせるのではなく、警告が出にくい配布と検証の構成に寄せるべきです。

配布方式の比較そのものは、次の記事でも整理しています。
Windows アプリの配布方式をどう選ぶか - MSI / MSIX / ClickOnce / xcopy / 独自 updater の判断表

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

自前 updater を出す前に、最低でも次は確認したいです。

  • 更新 metadata は署名されている
  • metadata には version / hash / size / channel / expiry が入っている
  • クライアント側で署名と version を検証している
  • 成果物の hash と platform 署名を検証している
  • 本番署名鍵は開発環境から分離されている
  • 鍵の利用ログと承認記録が残る
  • timestamp 付き署名を使っている
  • staging 更新で、旧版を残したまま切り替える
  • rollback の条件と手順がある
  • 検証失敗時は fail-closed で止まる
  • updater 自体の更新方針がある
  • blocklist / minimum allowed version を配れる
  • 段階配信を止める kill switch がある
  • 失敗率、rollback 率、署名検証失敗を観測できる

このチェックリストに空きが多いなら、先に updater の UI を作るより、配布信頼モデルを詰めるほうが効果があります。

8. まとめ

自動アップデート機能のセキュリティは、次の一文にかなり集約できます。

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

そのうえで、実務向けの判断をざっくり言うとこうです。

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

もし今の構成が latest.json + zip 差し替え に近いなら、最初に直すべきはダウンロード処理より信頼の置き方です。 ここを直すだけで、危険度はかなり変わります。

9. 参考資料

関連トピック

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

Windows技術トピック

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

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

Windowsアプリ開発

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

技術相談・設計レビュー

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

著者プロフィール

小村 豪

合同会社小村ソフト 代表

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

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

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

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

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

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

お問い合わせ

公開リンク

ブログ一覧に戻る