著者: Gene Moody、Action1フィールドCTO
パッチ管理はスピードの問題を抱えています。
ソフトウェアが変化するペースは加速し続けている一方で、ITチームがその変化を評価するための時間は増えていません。
アップデートの件数と頻度はいずれも増加を続けており、近いうちに鈍化する兆しは見えません。新たな脆弱性は毎日公表され、ベンダーは独自のスケジュールで修正プログラムをリリースします。ブラウザ、OS、アプリケーション、インフラのすべてが、対応を要するアップデートを生み出し続けています。
一方で、それらを分析・展開する責任を負うチームは、多くの場合、限られた人員、競合する優先事項、複雑化する一方の環境、そして単純だった時代のポリシーを抱えたまま対応しています。
結果は予測可能です。バックログは膨らみ続けます。そうなると、組織は必要に迫られてトレードオフを行うようになります。テストの時間は圧縮され、レビューはざっと目を通す程度か、あるいは省略されます。本来なら管理されたテスト環境で時間をかけて検証すべきアップデートが、そのまま本番環境へ直接投入されます。なぜなら、あと1週間待てば既知の脆弱性がさらに1週間放置されることになり、そのリスクがあまりにも大きいからです。
この判断の背景には、正当な理由がある場合もあります。攻撃者によって引き起こされる障害よりも、自分たちでコントロールできる障害の方が一般的には望ましいものです。しかし、だからといって展開を無謀にしてよいという結論にはなりません。切迫した状況では、時に拙速な判断が求められることもあります。
しかし、コントロールできる部分もあります。それは、そうしたプレッシャーがプロセスのうち自分たちの管理下にある部分にどう影響するか、という点です。
では、どうすればよいのでしょうか。プロセスをよりスマートにすることです。
自動化は加速と同義ではない
自動化は、成功と同じくらいの速さで失敗も生み出しかねません。
パッチ自動化に対する一般的な考え方はシンプルです。アップデートを見つけ、承認し、展開する――それをより速く行う、というものです。これは問題の一部を解決しますが、その過程でより複雑な別の問題を生み出します。自動化によってアップデートが10,000台のエンドポイントに速く到達できるようになるなら、不具合のあるアップデートも同じように10,000台のエンドポイントに速く到達してしまうのです。
したがって、問題は自動化そのものではありません。問題が生じるのは、スピードを自動化の主要な評価基準として扱い始めたときです。優れたパッチ自動化にはアクセルが必要ですが、同時にブレーキも必要です。
そのブレーキが、アップデートがどこへ向かうか、いつそこに到達するか、次の段階に進む前に何が行われるべきか、そしていつ展開を止めるべきかを決定します。自動化が有用であり続けるのは、それが効果的である間だけです。効果が失われれば、自動化は効率を生み出すどころか、効率を奪っていきます。
小さく始め、そこから範囲を広げる権利を得る
パッチテストに対する従来の答えは、概してテストラボでした。これは今でも有用ですが、どんなラボであっても、本番環境に存在するハードウェア、ソフトウェア、設定、ユーザー行動のあらゆる組み合わせを再現することはできません。また、誰もがテスト環境を持ってはいるものの、本番システムから完全に独立したテスト環境を持てるほど恵まれた組織ばかりではありません。
誰もがある程度この制約と向き合っている以上、より良いアプローチは、管理された本番環境への展開を検証プロセスの一部として組み込むことです。ここで重要になるのが、ビジネスの文脈とインフラに対する深い知識です。
自動化しようとしているプロセスについて考えてみてください。それは単にファイルを送信して実行する以上の内容を含んでいます。エンドツーエンドで見れば、このプロセスには数多くの判断が絡み、それぞれが自社の環境に固有の知識と経験を必要とします。そこも自動化しなければ、単に実行を加速させているだけで、プロセス自体を加速させたことにはなりません。
小さく始めましょう。例えば、IT部門のスタッフや、代表的なエンドポイントの集まり、あるいは環境内で特に複雑な設定を反映したシステムなどが対象になります。
成功は計画から始まり、望ましい結果で終わります。ですから、成功とは何かを事前に定義しておく必要があります。その自動化は何に対して、何を行い、いつ実行するのか。望ましい結果とは何か。そして、成功への道筋から外れた場合、どこにブレーキがあるのか。
アップデートは正常に適用されたか。エンドポイントは健全な状態を保ったか。アプリケーションは引き続き機能したか。失敗率は許容範囲内に収まったか。これらの条件が満たされて初めて、アップデートはより大きなグループへと展開されるべきです。
これが、段階的展開、いわゆる「アップデートリング」の根本的な考え方です。全展開するかしないかという単一の二者択一の判断を下す代わりに、組織は段階的に大きくなっていくグループを作っていきます。
重要なのは、この進行が毎回誰かの判断に依存する必要はないという点です。事前に定義した基準に基づいて、進むべきタイミングと、条件が想定される基準から外れたために止めるべきタイミングを管理できます。
ここでこそ、自動化はより大きな価値を発揮します。定義できる判断はすべて自動化しましょう。人間の判断が必要なものは残せばよいのです。しかし、同じやり方を2回以上繰り返しているものは、すべて時間の無駄です。
目標は人間の関与をゼロにすることではない
完全自律型のパッチ適用こそが究極の解決策だと語りたくなる誘惑があります。しかし、私個人としてはそうは思いません。
自動化が完全に理にかなう場面もあれば、人間がループの中に留まるべきシステムもあります。自動化は解決策の一部であり、しかも重要な部分ではありますが、解決策のすべてであることはめったにありません。
ドメインコントローラ、本番データベース、ERPシステム、その他ビジネスクリティカルなワークロードは、標準的な従業員のワークステーションとは異なる扱いに値する場合があります。
幸いなことに、大規模な環境ほど集約が進む傾向があるため、規模が拡大するにつれて、一部のシステムをミッションクリティカル度の低いものとして指定する余地が通常は広がっていきます。ちょうど、炭鉱のカナリアのように機能するわけです。
目標は人間の判断を排除することではなく、それが本当に重要な場面で活用することです。つまり、安全に自動化できる判断にはもはや人間の判断力を費やさず、その結果が重要な注意を正当化する判断のためにこそ、人間の判断力を温存するということです。
システムが展開結果を評価し、失敗しつつあるアップデートを停止させ、実績のあるアップデートを自動的に継続できるのであれば、管理者は個々の展開を手作業で操縦するのではなく、ポリシーとプロセスを管理する立場になります。
効率という配当
このアプローチによる最大の利点は時間です。同じ手順を手作業で繰り返す代わりに、管理者はグループと成功基準を一度設定すれば、あとは展開プロセスが日常的な進行を処理してくれます。
目標は監視をなくすことではなく、不要な介入を減らすことです。そしてそれこそが、自動化の意味を変えるのです。
現代のパッチ管理プラットフォームは、段階的展開と、アップデートが進むタイミング・止まるタイミングに対する明確な制御を組み合わせることで、このモデルをサポートできます。
例えばAction1は、アップデートを先に進めるか止めるかを判断する基準とともに、エンドポイントへの段階的展開のためのアップデートリングを提供しています。
また、手動承認ワークフローや、さまざまな特性や展開要件に応じて整理できるエンドポイントグループにも対応しています。
こうした機能の価値は、単にパッチ適用を速くすることではありません。より速いパッチ適用を、より安全にすることにあります。
目標は、何かを展開する前にすべてを完璧にテストすることではありません。ほとんどの組織にとって、そのモデルは持続可能ではないからです。かといって、すべてを即座に展開し、何も壊れないことを願うというやり方でもありません。現実的な答えは、制御された自動化です。まず一貫して機能するようにし、そのうえでより速くすることを目指すのです。
テストが価値を発揮する場所でテストを行いましょう。小さく始めましょう。成功を定義しましょう。実績のあるアップデートは先に進ませ、問題のあるものは止めましょう。必要に応じてビジネスクリティカルなシステムは別扱いとし、結果が重要な意味を持つ場面では人間を関与させ続けましょう。そして、それ以外のすべてを自動化するのです。
アップデートリング、事前定義された展開基準、そして必要に応じた手動承認を組み合わせることで、Action1を使ってパッチ自動化をより安全にしましょう。
200エンドポイントまで永久無料で始め、準備ができたら規模を拡大しましょう。
その見返りとして得られるのは、ITチームが毎月無理にスピードを上げなくても、環境の変化についていけるパッチ適用プロセスです。
