自動化のスコープ

第一話ではパッチマネジメントの重要性について説明してきましたが、今回はパッチ適用を円滑に実施するための自動化についてお話させていただきます。
今回お話させていただくスコープ（範囲）は以下のとおりです。

基盤環境構築・単体試験の自動化

パッチマネジメントを正しく運用するためには試験環境でのパッチ適用試験が必須となります。パッチ適用試験環境をタイムリーに短時間で構築するためには、基盤環境の構築および単体試験の自動化が欠かせません。
ここではCI/CD（Continuous Integration／Continuous Delivery）ツールを組み合わせた基盤環境の自動化ソリューションを検討していきたいと思います。

基本になるのは構成管理ツールAnsible

Ansible（アンシブル）は、レッドハット社が開発するオープンソースの構成管理ツールで、あらかじめ用意した設定ファイルに従ってOSやミドルウェアのインストールや設定を行い、サーバーを自動的に構築・設定変更ができるので、作業時間の短縮や作業ミスの削減に有用です。
Ansibleのシステム構成は管理サーバーとターゲットとなる操作対象マシンからなり、管理サーバーから操作対象マシンに対して、ネットワークを介してPush型で操作指示がなされます。
Ansibleには以下のような特長があります。

・エージェントレス	Ansibleに先行してリリースされた構成管理ツールであるChefやPuppetとAnsibleの大きな違いはエージェントレスであることです。エージェント型の構成管理ツールでは事前にOSにエージェントを配布する必要がありますが、エージェントレス型であれば、そのような前段の作業が不要になります。 また、ネットワークを介して行う管理サーバーから操作対象マシンへの操作指示は、特別なプロトコルを使わず、操作対象マシンがLinuxであればSSH、WindowsであればWinRMで接続します。
・簡易性	Ansibleは設定情報を定義したPlaybookと呼ぶ指示書を操作対象マシンに送ることで構成管理を行います。PlaybookはYAML 形式で表現され最小限の構文を持っていますが、プログラミング言語やスクリプトではありませんのでプログラム作成技術は特に必要ありません。
・技術ノウハウ	AnsibleはOSSコミュニティの活動が活発でさまざまな機器を操作するためのPlaybookのひな形が豊富にあり、誰でもコミュニティで培われたベストプラクティスを利用することができます。また、日本語化された技術文書も多くありますので初心者の勉強を大いに助けます。

単体試験を行うServerspec

Serverspec(サーバスペック)は構築したサーバー環境が意図した通りに構成されているかについて自動的に確認作業を行うツールです。
ServerspecによってAnsibleで構築したり設定変更（パッチ適用含む）したりしたサーバーが意図通りに構成されているかを確認することで単体試験を行います。テストスクリプトは、Rubyのテストフレームワーク「RSpec」に準拠しています。
Serverspecで確認できることには下記のようなものがあります。

Serverspecのシステム構成はAnsible同様、管理サーバーとターゲットとなる操作対象マシンからなり、双方をつなぐネットワークも特別なプロトコルを使わずLinuxであればSSH、WindowsであればWinRMで接続します。

Jenkinsのスケジューラ機能、Gitのバージョン管理を使用

Jenkins（ジェンキンス）はもともと複数の組織にまたがる大規模システム開発において、継続的インテグレーション(CI）の自動化、継続的デリバリー（CD）の自動化を支援するためのCI/CDツールです。
本稿ではAnsibleを定期的に自動実行するために、Jenkinsのビルドトリガ（スケジューラ機能）を使います。
また、AnsibleのPlaybookのバージョン管理のために、バージョン管理システムGit（ギット）を使います。

Ansible、Serverspec、Jenkins、Gitの４つのオープンソースツールを組み合わせて、基盤環境構築・単体テストのフレームワークを構築します。構築、単体試験の流れはおおむね下記のとおりになります。

以上のように基盤環境の構築・単体試験の自動化ソリューションを使って、パッチの事前動作確認を行う試験環境を素早く、正確に作ることができることがおわかりいただけたでしょうか。

パッチ適用の自動化（Linux編）

前章ではパッチマネジメントのために必要となる試験環境を整備するための、基盤環境構築・単体試験の自動化についてご説明してきました。次にマッチマネジメントのコアの部分と言うべきパッチ適用の自動化についてみていきましょう。
パッチ適用についてはLinux系とWindows系でそのやり方が大きく違いますので、最初にLinux系、その次にWindows系の順で話を進めていきます。

Red Hat Linuxのセキュリティ情報の入手とパッチ適用方法

ご承知のとおりLinuxにはいくつものディストリビューションが存在し、セキュリティパッチの適用方法もさまざまですが、ここでは企業向けLinuxの代表的な製品であるRed Hat Enterprise Linux(RHEL)を例題として取り上げていきます。
レッドハットではRHELを含むすべてのソフトウェア製品の修正情報ををerrata（エラータ）というデータベースで公開しています。
errataではアドバイザリーという単位で修正情報が公開されており、アドバイザリーには、1つまたは複数の修正情報が含まれています。修正情報にはセキュリティ修正に加え、バグフィックスおよびエンハンスの情報もあります。
アドバイザリーに含まれる情報には、概要、技術的な解説、該当する製品名／バージョン、解決方法などがあり、セキュリティ修正の場合には、特別に重要度、関連する脆弱性情報（CVE番号）が付加されます。

Red Hat errataの画面
さまざまな条件でアドバイザリーの検索ができる

RHELのセキュリティパッチの適用を検討する情報システム部門の担当者は、errataを使って適用するセキュリティ修正を検討し、セキュリティパッチを入手することができます。
また、Red Hatカスタマーポータルに登録するとメール等によりPush型で情報を入手することが可能です。
このようにして得られたパッチファイルはrpmコマンドによりインストールできるパッケージとして配布されます。

Ansibleを使ったパッチ適用とその問題点

基盤環境の自動化で取り上げたAnsibleを使うと、パッチファイル（パッケージ）の入手およびパッチ適用を自動化することができますが、以下の点が課題となります。

それではRed Hat社の製品である「Red Hat Satellite」を導入することで、このような課題にどのような対応ができるのか詳しく見ていきましょう。

Red Hat Satellite

Red Hat SatelliteはRHELサーバーのライフサイクルを一括管理するシステム管理製品で、豊富な機能を有しておりますが、ここではセキュリティパッチ適用に関する機能に焦点を当てると、下記のようにまとめることができます。
管理画面はグラフィカルユーザーインタフェースですので、LinuxのCUIに不慣れな運用オペレータでも管理することができます。

Red Hat Satelliteの構成
Red Hat SatelliteサーバーからRHELサーバーを一元管理
プロキシー（Capslute）サーバーにより柔軟な多段構成可能

・RHELサーバーの情報収集	管理しているRHELサーバーごとに適用できるerrata情報を一元的に表示することができます。errata情報のうち種類（セキュリティ修正／バグフィックス／エンハンス）と個数を一覧化して表示できるので、各サーバーで対応すべきセキュリティ修正がどの程度あるのかを一括して確認することができます。 また、観点を変えてerrata情報ごとに対応一覧、未対応のサーバーを一覧表示することも可能です。これにより、緊急性が高い脆弱性が発生した場合には、その脆弱性に対応する修正パッチの未対応サーバーをすぐに抽出することができます。
・パッケージの配布・適用	管理するRHELサーバーに対してRed Hat Satelliteの管理サーバーよりセキュリティ修正パッケージ（パッチファイル）を配布し適用することができます。スケジュールを決めてパッチの配布、適用をコントロールするも可能です。 また、Red Hat Satelliteのプロキシーを配置することで、セキュリティパッケージをプロキシーにダウンロードしておき、そこから管理するRHELサーバーへセキュリティパッケージを配布、適用することもできるので、インターネットに接続していない閉域ネットワークにあるRHELサーバーにもタイムリーにセキュリティパッケージの配布・適用を実現します。

以上にようにRHEL環境へのセキュリティパッチ適用の自動化を実現する方法として、Red Hat純正製品であるRed Hat Satelliteをご紹介しました。先にご紹介しましたAnsible等のCI/CDツールは無償版がございますが、Red Hat Satelliteのラインセンスは有償であることにご留意ください。

パッチ適用の自動化（Windows編）

この章ではWindows Serverのパッチ適用自動化についてみていくことにします。

Microsoft Update カタログ

Windowsサーバーをはじめマイクロソフトのソフトウェア製品のセキュリティパッチはMicrosoft Updateカタログから入手することができます。(https://www.catalog.update.microsoft.com/Home.aspx)
Microsoft Updateカタログではセキュリティパッチの他、デバイスドライバ、セキュリティ問題以外の修正プログラム、Windowsの新機能についても入手可能です。
Microsoft Updateカタログは、パッチの名前、説明、適用される製品、種類、サポート技術情報の記事等で検索することができるデータベースになっており、入手したい修正プログラムをダウンロードすることが可能です。

Microsoft Updateカタログの画面
Windows Server 2019のセキュリティパッチを検索しているところ

しかしながら、システム管理者が直接Microsoft Updateカタログから手動で修正プログラムを入手することはレアケースで、通常はパソコンのWindowsOSでおなじみのWindowsUpdateを使って修正プログラムを入手し適用します。

Windows Server Update Services(WSUS)によるWindows Updateの自動化

WindowsサーバーにはLinuxと違い、修正プログラムを適用するためのWindows Updateという専用のプグラムが備わっていますので、Windowsサーバーのパッチ適用の自動化とは、各々のWindowsサーバーのWindows Updateをどのように管理し自動化を実現するか。というポイントに絞り込まれますが、そのためには無償のWindowsサーバーのアプリケーションであるWSUSを利用するのがよいでしょう。
通常WindowsサーバーがWindows Updateを実行すると、インターネット上にあるマイクロソフトのアップデートサーバーにアクセスして、更新プログラムを検索、ダウンロードすることになります。
一方、WSUSを導入するとWSUSサーバーが一元的にインターネットから更新プログラムをダウンロードし、配下のWindowサーバーへ配布する仕組みを構築することができます。つまりインターネットにあるマイクロソフトのアップデートサーバーを企業内ネットワーク内に持ってくるイメージで、前章でご説明したRHELでのRed Hat Satelliteと同じような位置づけになります。

Windows Server Update Services(WSUS)の構成

WSUSの主な機能は下記のとおりです。

・修正プログラムの配布および適用の制御	管理するサーバーに対して強制的に修正プログラムを配布し適用することができます。 また、修正プログラムの削除も同様に制御できます。
・グループによる管理	WSUSを運用するためにはActive Directory(AD)によるディレクトリ管理が前提になります。 WSUSはグループごとにポリシーを決め効率的にパッチ適用の運用することができます。 たとえば、グループごとにパッチ適用に時間差を設け、WSUSサーバーやネットワークの負荷を軽減させるなどの対応をとることができます。
・適用状況の可視化	管理するサーバーのパッチ適用状況を一覧化するなどして可視化することができます。
・閉域ネットワークでの修正プログラムの自動化対応	管理するサーバーがインターネットに接続していない閉域ネットワークにある場合でもタイムリーに修正プログラムの配布が可能となります。

第二話のまとめ

第一話でご説明したパッチマネジメントサイクルのうち、今回は

について具体的なツールを組み合わせたソリューションについてお話してきましたがいかがでしたでしょうか。
次回はパッチマネジメントサイクルのうち、残りの工程である

を自動化するための、脆弱性管理ソリューションについてお話させていただく予定です。