LASSIC Media らしくメディア

サーバーやミドルウェアには、日々あたらしい脆弱性が見つかり、ベンダーから修正のためのパッチ（セキュリティ更新）が公表されます。これを当て続けなければ、公表済みの弱点を突かれる危険が積み上がっていきます。とはいえ、パッチ適用は「当てれば動かなくなるかもしれない」という不安や、再起動の段取り、対象の把握しにくさから、つい後回しになりがちです。気づけば何か月分もの更新が溜まっていた、という状況は珍しくありません。

だからこそ、パッチ適用は一度やって終わりではなく、周期を決めて回し続ける運用として捉える必要があります。ただ、この運用は「脆弱性診断」や「アプリの依存パッケージ管理」としばしば混同されがちで、担う中身は別物です。本記事では、自社のシステムを守る立場の情報システム部門やインフラ担当者に向けて、定期パッチ適用運用とは何か、近い取り組みとどう違うのか、そして進め方と外注の勘所を整理します。

定期パッチ適用運用とは——脆弱性診断・依存パッケージ管理との違い

定期パッチ適用運用とは、自社が使うOSやミドルウェアに対して、ベンダーが公表するパッチを、決めた周期で当て続ける運用を指します。公表された脆弱性の情報を集め、自社に影響するかを見極め、検証してから本番へ適用する——この流れを回し続ける取り組みです。似た文脈で語られる2つの取り組みと並べると、役割の違いがはっきりします。

脆弱性診断は、自社のシステムに弱点がないかを検査して洗い出す取り組みで、いわば「弱点を見つける」側です。またアプリの依存パッケージ管理は、自社で開発するアプリが取り込むライブラリの脆弱性に対応するもので、扱う層がアプリのコードに近いところにあります。これらに対して定期パッチ適用運用は、見つかった弱点をふさぐために、OSやミドルウェアという土台へ、公表されたパッチを当て続ける部分を受け持ちます。

弱点を見つける診断でも、アプリのライブラリ管理でもなく、土台に公表済みのパッチを当て続ける——ここに違いがあります。なお、こうした手入れを含めてインフラの運用ごと任せたい場合に向くのが、クラウド運用代行（マネージドサービス）という選択肢です。自社が何をしたいのか、弱点探しなのか、アプリのライブラリなのか、土台へのパッチ適用なのかを見極めておくと、取り組みの範囲を絞りやすくなります。

なぜパッチは溜まりやすいのか

パッチを当てる必要は分かっていても、実際には後回しになりがちです。理由はいくつか重なっています。一つは、当てることへの不安です。パッチによってアプリの動きが変わったり、思わぬ不具合が出たりする心配から、「動いているものは触りたくない」という判断が働きます。もう一つは、再起動の段取りです。適用には再起動が伴うことが多く、業務を止められる時間帯が限られると、実施の機会をなかなか作れません。

さらに、対象の把握しにくさもあります。どのサーバーに何が入っていて、どのパッチが未適用なのかを台帳で押さえていないと、当て漏れが生じがちです。こうして先送りが重なると、更新が何か月分も溜まり、いざ当てようとしたときの検証範囲が膨らんで、ますます手を出しにくくなります。放置された弱点は、すでに攻撃の手口が出回っているものも多く、時間がたつほど危険が増す一方です。だからこそ、溜めてから一気に当てるより、周期を決めてこまめに回すほうが、結果として負担も危険も抑えられます。

定期パッチ適用でやること

パッチ適用は、通知が来たそばから当てるだけでは、かえって事故のもとになります。おおまかには次のような工程を、決めた周期で繰り返します。自社でどこまで回せているかと照らし合わせてみてください。

まず、脆弱性やパッチの情報を集めます。ベンダーの公表や、公的機関が出す脆弱性情報を追い、自社に関係するものを拾う工程です。次に、集めた情報が自社の資産に該当するかを見極め、深刻度をもとに優先度を付けます。そのうえで、本番と同じ構成の検証環境で先に当ててみて、不具合が出ないかを確かめる工程です。問題がなければ、業務への影響が小さい時間帯を選んで本番へ適用し、必要な再起動を行って業務が動くことを確認します。最後に、どのサーバーに何を当てたかを台帳へ記録し、当て漏れがないかを見える化する段階です。緊急性の高いパッチは、この周期を待たずに随時対応します。この一連の流れを図にすると次のとおりです。

つまずきやすい難所

定期パッチ適用を回すうえで、あらかじめ想定しておきたい難所がいくつかあります。着手前に押さえておくと、思わぬ停止や当て漏れを避けやすくなります。

一つ目は、定例と緊急の切り分けです。多くのパッチは決めた周期でまとめて当てられますが、攻撃が広がっている深刻な脆弱性は、周期を待たずに急いで当てる判断が要ります。どこからを緊急とするかの基準を、あらかじめ決めておく必要があります。二つ目は、再起動の計画です。止められない仕組みでは、冗長化して順番に再起動するなど、業務を止めずに当てる工夫が欠かせません。三つ目は、依存と互換です。あるパッチが別のソフトの動作に影響することもあり、検証を抜きにした適用は避けます。四つ目は、当てない判断とその管理です。事情があってすぐ当てられない場合は、暫定の回避策を取ったうえで、いつ当てるかを台帳で管理する必要があります。これらは、溜めるほど絡み合って難しくなります。だからこそ、周期を決めてこまめに回す運用が現実的なのです。

どれくらいの頻度・優先度でやるか

パッチ適用は、すべてを同じ扱いにするのではなく、緊急度と対象の重要度でめりはりを付けるのが現実的です。目安を整理しました。

優先度は、その資産が攻撃にさらされやすいか、止まったときの影響が大きいかで決めます。インターネットに面したサーバーや、重要なデータを扱う仕組みほど、緊急度を一段高く見ておくとよいでしょう。判断の軸をあらかじめ決めておくと、次々に出るパッチに追われず、落ち着いて回せます。

外注時に確認しておきたい点

定期パッチ適用運用を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、対象とするサーバーやミドルウェアの範囲と、いまの適用状況です。対象がどれだけあり、どれくらい溜まっているかによって、最初にやるべきことが変わります。次に、どこまでを任せるか。情報収集と影響評価だけなのか、検証や本番への適用まで含めるのか、緊急対応も担ってもらうのかで、契約の形が変わります。

さらに、定例の頻度と作業を行う時間帯、緊急パッチをどう扱うか、そして適用状況をどう報告し見える化するかも、あらかじめ決めておきたいところです。加えて、当てられない事情がある場合の扱いや、切り戻しの考え方も整理しておきたい点です。パッチ適用運用は続いていく取り組みなので、いずれ自社で回せるように台帳や手順を残してもらえるかどうかは、後々の助けになります。適用の実施だけを頼むのか、監視や報告まで含めて依頼するのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：パッチ適用運用で押さえる3つの視点

定期パッチ適用運用は、弱点を見つける脆弱性診断や、アプリのライブラリを扱う依存パッケージ管理とは役割の異なる、「OS・ミドルウェアへ公表済みのパッチを当て続ける」運用です。検討するうえで押さえたい視点は3つに整理できます。第一に、脆弱性診断・依存パッケージ管理・定期パッチ適用運用を切り分け、自社がやりたいのがどれなのかを見極めること。第二に、パッチが溜まりやすい理由を踏まえ、溜めてから一気にではなく、周期を決めてこまめに当てること。第三に、定例と緊急を切り分け、検証を挟み、適用状況を台帳で見える化することです。この3点を踏まえておけば、「公表済みの弱点を放置したまま狙われる」という事態を避けやすくなります。自社だけで回しきるのが難しいと感じたら、適用状況の棚卸しや検証の仕組みづくりから外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：情報処理推進機構（IPA）「脆弱性対策」（https://www.ipa.go.jp/security/vuln/index.html）

Tweet