■はじめに

本記事では、Tanium Patchによる環境内の端末へのパッチの適用手順を解説しております。
本記事の参照元：Tanium Patch User Guide for Cloud

興味のある方はぜひご一読ください。

=================================================
目次
■Tanium Patchモジュールとは？
■特徴と他製品との差別化部分
 ■実際に適用してみた
 ■最後に
=================================================

■Tanium Patchモジュールとは？

TaniumのPatchモジュールは、環境内で適用が必要(または可能)なパッチの可視化・適用を実施できるモジュールで、脆弱性対策には必須の機能です。

可視化と言ってもただパッチをリスト化するだけではなく、Taniumテナント内の端末やTaniumユーザーのデータを分析して様々な指標で可視化いたします。
今回は、入門編としてPatchモジュールのダッシュボードから確認してみましょう。

例として、Patchモジュールのダッシュボードではエンドポイントの重要なパッチの適用状況からコンプライアンスに準拠している端末と非準拠の端末がどれくらいあるのかを示してくれます。
ガバナンスを意識した際にこういった数値は目標達成の指標にもなります。

他にも重大なKBごとに対応するパッチが適用されているかという分析結果も見せてくれます。
「KB～に対する対応状況は？」と思ったときにすぐに答えにたどり着けるのはありがたいですね。

この例ですと、致命的な脆弱性の数々に対してノーガードの筐体がおそらく一台あることがわかります。

ダッシュボードで確認できる情報は他にもありますが、ページの長さの都合上次の項目へ移らせていただきます。

次項ではもう少し掘り下げてPatchモジュールの特徴や差別化要因をより詳しく見ていきましょう。

■特徴と他製品との差別化部分

ここでは私の独断と偏見で、Patchの画面を基点にPatch機能の嬉しいところをあげさせていただきます。
メーカー様の推しとは違う部分もあるかとは存じますが、ご容赦ください。

その①：Confidence Scoreでパッチ適用前に適用後の影響が確認できる

「パッチを適用したせいで深刻な不具合が起きた！」なんていうお話を最近よく耳にするのではないでしょうか。
良かれと思って適用したパッチのせいで、逆に非難されてしまうのは非常に不条理だと思います。
しかしながら、こういった問題は大体[パッチを適用したユーザーがたくさんいる→メーカーに問い合わせが来て問題を把握するorニュースになる]といった形で
ある程度時間がたたないと情報がもたらされないこともしばしば。
情報を得る前にパッチを適用して巻き込まれてしまった。というご経験がある方もいらっしゃるのでは？

「適用前に何か問題が起きてないかリアルタイムな情報で判断できればいいのに」
が形になったのがこのConfidence Scoreです。

Taniumユーザーの端末でのパッチ適用状況をTaniumのクラウド上で収集し、"適用の結果とユーザーの行動"を数値化してくれます。
具体的には以下のような形です。
●Installation Status
・Success...該当のパッチを適用し、正常に成功した割合
・Failed...該当のパッチを適用し、失敗した割合
・Aborted...該当のパッチを適用し、中止した割合
・Rolled Back...該当のパッチを適用し、その際エラーなどが起因し端末がロールバックした割合
・Uninstall Rate...該当のパッチを適用し、その後パッチをアンインストールした割合

指標として見たときに、適用判断の基準として重みを置きたいのはFailedとRolled Backでしょうか。
Failedは単純に適用失敗という事になりますが、この値が大きいとパッチ自体に明らかに問題がある可能性が高いように思われます。
また、Rolled Backについては業務影響が高く、少しでも発生していたら警戒して事前に情報を探ってみるのも一つの手段かと。

そもそもパッチというものは今日において相当数リリースされています。
Windowsだけ見てもこれくらい...。

ではその中でWindows端末向けのものはと言うと...

大分減りましたがまだ現実的な数ではないですね。
次にその中で重要なパッチは？というと...

今年いっぱいは頑張ろうと思えるくらいの数に絞られてきました。
では更に環境内の端末で適用が可能かつ独自指標であるConfidence ScoreでHigh(適用しても問題ない)以上のものは？

存外無駄な作業というものは多いものです。
その無駄を洗い出すために工数がかかってしまう場合も少なくありません。
今回は検証環境という事もあり配置された端末は多くないので、もしかしたら極端な数字なのかもしれません。
しかし、先々を考えた場合この効率の違いはかなり大きいものなのではないでしょうか。

その②：未適用の端末がすぐに確認できる。

Taniumのリアルタイム性を活かすことで端末の今の状態をモニターし必要な操作を実行することができます。
MDMなど資産の管理をテーマとした製品であってもパッチの適用状況などをリアルタイムにモニターすることは難しいです。
Taniumプロトコルやリニアチェーンの仕組みが無い他の製品だと「細かくデータをクラウドに集めるとNWリソースが逼迫する」という課題があるため数時間前のデータを利用する形になります。
その点TaniumであればNWに負荷をかけずに"今のデータ"を利用することで後述しますがパッチ適用の状況の把握や、適用作業の進捗のモニターがリアルタイムに可能になります。

画像16.png

また、適用の際に雑に対象端末の範囲を指定しても、必要な端末にのみ絞って適用されます。

その③：再起動のタイミングをコントロールできる

意外と「パッチ適用は出来るけど適用後の再起動などの操作は設定できない」という製品も少なくありません。
これを実現するにはリアルタイムな機器の状態の把握と強力な権限が必要になります。Taniumはシステム権限を持っている為、権限が必要な操作も行う事が可能になります。

再起動に限定した話ではないですが、Taniumは端末に対しての操作を行う事にも長けています。
リモートでパッチを適用できる製品というのは昨今多くありますが、パッチ適用に併せて"特定の範囲に一括でフレキシブルに指定のアクションを実行できる"という製品は実際少ないです。

その④：複数端末への複数パッチの一括適用が可能

これも「できて当たり前」と思われるかもしれませんが、実は意外と製品選定の盲点だったりします。
「リモートでパッチ適用もできますよ」とうたっていても「複数端末への一括適用は不可」や「複数のパッチの適用は不可」といった但し書きがついてしまう製品もあります。
些細なことのように思えますが、この要件を満たしているかどうかで運用の負荷が段違いです。これから製品選定される際はひじょ～～～に注意してみてください。

その⑤：マルチOS対応

OSごとにパッチ適用に必要な技術は異なります。「Windowsのみ」適用可能という事も少なくありません。
その点TaniumはマルチOSに対応していますが、パッチに関してももちろんLinuxやMacに対応しているというのもひとつの特徴と言えます。

例えばLinuxの画面

その⑥：パッチ配信の負荷が小さい

前述している通り、特許技術のリニアチェーンを採用している為パッチなどの容量が大きいデータのやりとりでも端末台数分の負荷をかけることはありません。
各端末がそれぞれ内外のパッチサーバーからパッチファイルをやり取りするのと比較するとNWリソースへの影響は段違いに少なくなります。
この機構はTaniumが特許を持っている為、他の製品では真似できません。唯一無二の仕様です。

その⑦：パッチの詳細はもちろん見れます。

Taniumが保持しているパッチのデータは、しっかりとKBやCVEに紐づいています。
それぞれのパッチに関連する情報も簡潔にまとめられており、パッチ名をクリックするだけで情報へアクセスできます。
機能ごとのシームが少ないに越したことはないので、こういった部分も地味に嬉しいポイントです。
パッチの公式配布リンクもついているので、「あれ、Confidence Scoreが低い。なんかあるのかな？ポチッとな」とパッチの既知のバグなどを確認しに行くことも簡単です。

さきほどのパッチ一覧画面のパッチ名をクリックすると...

■実際に適用してみた

では実際にパッチを適用してみます。
様々な適用のシチュエーションに対応すべくオプションとして様々な機能がございますが、今回はとりあえず適用の流れの一例を簡単にお見せできれば良い。
という形で実施します。

まず、今回は検証環境の筐体への適用という事で特にこだわりも無いため
とりあえず以下のように重要そうかつ直近にリリースされ環境内の端末に適用可能なセキュリティアップデートをフィルターして適用してみましょう。

2件出てきました。
今回は上のパッチだけ単体で適用してみます。
特に意味はありません。

適用に移る前に、念のため端末がオンラインかどうか確認しましょう。
右端の適用できるエンドポイントの数字をクリックして、オンラインデータから今の状態を確認します。

この画面のままだとパッチの適用状態などをQuestionで確認した画面になっているので、ここから更に端末に「オンラインかどうか」を聞いてみます。

オンラインですね。すぐに結果がわかりそうなので検証にぴったりです。
では次にいよいよパッチの適用です。
適用対象のパッチにチェックマークを入れて、インストールボタンをクリックします。

パッチ適用画面が表示されます。
※一部ロード中の画面になってしまいました。

次に今回の適用の対象となる端末を中段からグループで指定していくのですが、
適用が必要(可能)な端末が自動的に指定されるという部分もお見せしたいので、ここはあえて雑に設定します。

更に適用に際しての設定部分をいじっていきましょう。

各項目の鉛筆マークをクリックすることで設定を展開できます。
まず時間についてはすぐに結果を見たいので直近の時間で設定します。
デプロイメントの種類は、もしオフラインなどの端末がある場合などに繰り返し適用を試みることでオンライン時に適用が開始されるように仕込むことも可能です。
今回はオンラインだったので1回のままです。
また、配布期間ですがこれも対象が1台なので今回はデフォルトのままです。
もし分散して実行したい場合などは利用しましょう。、

次は展開の設定です。
ここではパッチをローカルにダウンロードするタイミングや、メンテナンスウィンドウ(あらかじめ作業を行わない時間などを指定可能)やブロックリスト(このパッチは配布しないなどの事前定義)に上書き/優先するかを設定できます。
また、以前記事にしたエンドユーザーセルフサービスで、ユーザー側から能動的に適用を行うといった設定も可能です。
最後に重要な項目として再起動についての設定です。

次にユーザー通知の有無の設定です。
通知アリの場合、通知の内容はアイコンや文言など細かく設定可能です。
また、再起動ついてユーザーによる延長の可否(仕事中だと困るので)などを設定可能です。

ここまで設定したら、最後はプレビューで適用対象のパッチを確認し実行します。

こちらは実行後に表示される適用の進捗を示した画面です。
設定した適用時間後に確認したのですが、既に再起動待ちになっています。
あとは端末が再起動(もしくはシャットダウン)されるときに、おなじみのWindowsの再起動画面が表示される流れです。