セキュリティパッチ

読み：せきゅりてぃぱっち　／　英語表記：Security Patch

• セキュリティ
• 性能・監視・運用

ソフトウェアの脆弱性を修正するために提供される更新プログラムである。OSやアプリケーション、機器のファームウェアなどが対象となり、適用後に再起動などの反映処理が必要な場合がある。

イマシルちゃんの解説

いつもどおり動いている機器でも、攻撃に悪用される弱点である脆弱性が隠れていることがあるよ。
その弱点を直すために提供される修正用のプログラムが、セキュリティパッチなんだ。
例えば外から届くデータの調べ方に不備があれば、危険なデータを受け付けない処理へ直すことがあるよ。
利用者に見える機能が変わらなくても、安全に使い続けるための大事な変更なんだね。
ただし修正を入れたことで、業務のソフトが動かなくなる場合もあるの。
だから動作を確かめながら適用して、修正が実際に働いているところまで確認するんだよ。

より深い解説

修正プログラムと、それを届ける管理活動

セキュリティパッチは、脆弱性の原因となるプログラムの処理などを変更するものである。入力の長さを正しく検査する、利用者の権限を確認する、誤った暗号処理を直す、といった変更が考えられる。配布形態は差分ファイルに限らず、修正済みのパッケージや機器のファームウェアイメージへの置換になる場合もある。

これに対し、どの機器へ何をいつ適用するかを決め、配布と結果確認を行う活動がパッチ管理である。NIST SP 800-40 Rev. 4は、対象の特定から優先付け、取得、インストール、検証までを管理の範囲としている。ファイルを配るだけでは、使われているソフトウェアが修正済みになったとは判断できない。

この区別から、パッチを適用できない場合にも対策の選択肢は残る。一方、通信を制限しただけで修正済みとして記録すると、その制限を解除したときに危険が戻る。

まず、適用すべき実物を特定する

提供元のセキュリティアドバイザリには、影響を受ける製品や版、成立条件、修正方法などが示される。自組織にある製品名だけで照合せず、詳細な版、追加モジュール、使用している機能まで確認する。OSの更新だけで、その上で動くすべてのアプリケーションが直るわけではない。

機器、導入ソフトウェア、管理担当者などを対応付けた資産台帳は、この調査の出発点になる。組込み機器の内部部品やコンテナの基盤イメージも対象に含める。利用中の構成を把握していなければ、修正が必要な機器を配布対象から落としてしまう。

適用順序や必要な空き容量、対応する機種、再起動の要否も提供元の手順から確認する。例えば、事前に別の修正を入れる必要がある製品で、その前提を満たさず配布すると、管理画面では配布済みでもインストールが失敗することがある。調査結果は対象、実施する処置、期限、担当者と結び付けて管理する。

通常の更新と緊急対応を使い分ける

すべての修正を同じ日程で扱うと、実際に悪用されている弱点への対応が遅れたり、不必要に大きな変更を急いだりする。攻撃の実績、外部から到達できるか、悪用時の業務影響などを踏まえて、通常の保守日程と緊急対応を分ける。深刻度の数値が高いという情報だけでなく、自組織で攻撃が成立する条件を確認する必要がある。

緊急であっても、対象の特定と最低限の動作確認は必要である。時間が不足する場合は、影響する機能の停止などで先に攻撃の機会を減らし、確認範囲を明確にしたうえで修正を適用する。NISTの実装ガイドも、通常の更新、緊急の修正、修正前の緩和、更新困難な機器の隔離を異なる場面として扱っている。

正しいファイルを取得し、影響を試す

修正ファイルを実行する前に、正規の提供元から取得したものかを確認する。署名の検証は作成元の真正性と、配布後に内容が変わっていないという完全性の確認に使える。信頼できる経路で得たハッシュ値との照合も改変の検出に役立つが、ファイルと照合値を同じ偽サイトから取得していては、そのサイトを信頼する根拠にはならない。

検証環境ではインストールの成否だけでなく、認証、通信、業務処理、監視などの主要な動作を確認する。変更前に動いていた機能が引き続き動くかを確かめる試験が回帰テストである。例えばVPN装置の修正なら、管理画面へログインできることだけでは利用者の接続や通信が正常とは判断できない。

検証環境と本番環境に差がある場合は、その差も結果に添える。設定、連携先、負荷が大きく違えば、検証に成功しても本番の障害をすべて予測できない。少数の対象で確認してから範囲を広げる段階的展開は、こうした不確実性がある場合に影響範囲を抑える方法である。

戻す手順と停止時間を先に決める

適用後に重大な不具合が出たとき、変更前の状態へ戻す処置をロールバックという。実施前に設定や必要なデータを保全し、旧版へ戻せる条件と所要時間を確認する。データ形式が変わる更新などでは、ソフトウェアだけを旧版へ戻しても動かない場合がある。

冗長構成では片側ずつ更新する方法が考えられるが、異なる版の混在を製品が許すか、切替え時に通信状態を引き継げるかを確認する。障害時に待機系へ処理を引き継ぐフェイルオーバーが使える構成でも、同時に両系を止めたり、両系へ同じ不具合を持ち込んだりすれば停止を避けられない。

作業計画には、成功と判断する条件、打ち切る条件、切戻しを開始する時刻を含める。旧版へ戻すと元の脆弱性も戻る可能性があるため、その場合のアクセス制限や代替経路も用意する。更新による停止と、未修正のまま稼働させる危険の両方を判断材料にする。

インストール済みと、修正が有効な状態を分ける

配布ツールの成功通知は、必要な確認の一部である。再起動を待っているOSや、古いライブラリを読み込んだままのプロセスでは、ファイルを置き換えても稼働中の処理に修正が反映されていないことがある。提供元が指定する反映手順を完了させ、実際に動作している版と設定を確認する必要がある。

確認は次のように分けると、どの段階で止まっているかを切り分けやすい。

確認結果には日時と対象を残し、未完了の機器を再実行の対象にする。修正の適用前に侵害されていた場合、修正だけで不正なアカウントや持ち込まれたプログラムまで消えるとは限らない。侵害の兆候があるときは、インシデント対応として調査と復旧を進める。

版番号だけでは修正の有無を決められない

提供元が、保守中の古い系列へ必要な修正だけを移植する方法をバックポートという。上流の最新版へ全面的に更新せずに、既存機能との互換性を保ちながら修正を届けるために使われる。Red Hatの説明は、この方法では上流の版番号だけによる判定が実際の修正状況と一致しない場合があるとしている。

したがって、スキャナが古い版を検出した場合も、提供元のアドバイザリとパッケージの詳細なリリース番号を照合する。逆に「最新版と表示されるから安全」とも限らない。対象となる製品系列に修正が提供されているか、必要な機能や追加部品にも反映されているかを確かめる。

適用できない場合の対策を期限付きで管理する

修正が未提供、業務との互換性に問題がある、といった理由で直ちに適用できない場合は、攻撃の成立条件を減らす。例えば不要なサービスを止める、管理用通信の送信元を限定する、対象を別のネットワークへ隔離する、といった方法がある。

WAFやIPSなどで特定の脆弱性を狙う通信を遮断し、修正までの間を補う手法は仮想パッチと呼ばれる。OWASPの解説も、対象のソースコードを変更せず、途中で攻撃を遮るという性質を説明している。通信が対策装置を通らない経路や、検知できない攻撃が残らないかを確認する必要がある。

製品のライフサイクル終了を表すEOLや、セキュリティ保守の終了も確認する。販売終了と修正提供の終了が別日である製品もあるため、名称だけでなく提供元の保守条件を調べる。今後の修正が得られない場合は、代替機器への移行や廃止も含めて計画し、例外として使い続ける期間と責任者を決める。

こうした代替措置の後にも残る危険が残存リスクである。例えば公開中の装置を接続元限定にしたとしても、許可済みの端末が侵害されれば攻撃される可能性は残る。午後問題などで「パッチを入れられないため何をするか」を考えるときは、遮断する経路、維持すべき業務、恒久的な修正や移行までの期限を対応付けて説明すると、対策の根拠が明確になる。

この用語が出てくる記事

• IaaS
• 脆弱性管理
• TLSアクセラレーター