Linux／Windowsのパッチ適用自動化のポイント――基盤環境構築、単体試験の自動化で使える4つのOSSとは：こっそり始めるパッチマネジメント自動化入門（2）

パッチ適用の時間を短縮する「自動化」について解説する連載。今回は、Linux／Windowsのパッチ適用の自動化と、OSSを使う基盤環境構築、単体試験の自動化について解説します。

[大久保次郎，NTTデータ先端技術株式会社]

　パッチ適用の時間を短縮する「自動化」について解説する本連載「こっそり始めるパッチマネジメント自動化入門」。前回はパッチマネジメントの重要性について説明しました。今回はパッチ適用を円滑にするための自動化についてお話しします。

自動化のスコープ

　本稿のスコープ（範囲）は次の通りです。

• 【前提】
  • 物理サーバにあるハイパーバイザーの上に
  • 仮想OSをインストールし、仮想OS上で
  • ミドルウェアおよびアプリケーションが動作する
• 【スコープとするシステム構成】
  • 仮想OS（LinuxまたはWindows）
  • ミドルウェア
• 【スコープとする作業工程】
  • 上記スコープとするシステム構成の
    • 構築
    • パッチ適用
    • 単体試験

（赤枠内が本稿のスコープ）

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

　パッチマネジメントを正しく運用するには試験環境でのパッチ適用試験が必須です。パッチ適用試験環境をタイムリーに短時間で構築するには、基盤環境の構築および単体試験の自動化が欠かせません。

　ここではCI/CD（Continuous Integration／Continuous Delivery）ツールを組み合わせた基盤環境の自動化ソリューションを検討します。

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

　「Ansible」（アンシブル）は、Red Hatが開発するオープンソースソフトウェア（OSS）の構成管理ツールです。あらかじめ用意した設定ファイルに従ってOSやミドルウェアをインストール、設定し、サーバを自動的に構築したり、設定を変更したりできるので、作業時間の短縮や作業ミスの削減に有用です。

　Ansibleのシステム構成は管理サーバとターゲットとなる操作対象マシンからなり、管理サーバから操作対象マシンに対して、ネットワークを介してPush型で操作を指示します。

　Ansibleには次のような特長があります。

・エージェントレス

　Ansibleに先行していた構成管理ツールに「Chef」「Puppet」がありましたが、これらとAnsibleの大きな違いはエージェントレスです。エージェント型の構成管理ツールでは事前にOSにエージェントを配布する必要がありますが、エージェントレス型ならば、そのような前段の作業が不要になります。

　管理サーバから操作対象マシンへの操作指示はネットワークを介し、特別なプロトコルを使いません。操作対象マシンがLinuxならSSH（Secure Shell）、WindowsならWinRM（Windowsリモート管理）で接続します。

・簡易性

　Ansibleは設定情報を定義した「Playbook」という指示書を操作対象マシンに送ることで構成を管理します。PlaybookはYAML形式で表現され、最小限の構文を持っていますが、プログラミング言語やスクリプトではないので、プログラム作成技術は特に必要ありません。

・技術ノウハウ

　AnsibleはOSSコミュニティーの活動が活発です。さまざまな機器を操作するPlaybookのひな型が豊富にあり、誰でもコミュニティーで培われたベストプラクティスを利用できます。日本語化された技術文書も多くあるので、初心者の勉強を大いに助けます。

単体試験を行う「Serverspec」

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

　Serverspecで確認できることには次のようなものがあります。

• インストールされているOSやミドルウェアのバージョンが正しいかどうか
• OSやミドルウェアのパラメーター値が設計通りかどうか
• TCPの何番ポートがListenしているか

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

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

　「Jenkins」（ジェンキンス）はもともと複数の組織にまたがる大規模システム開発において、CI/CDの自動化を支援するツールです。

　本稿ではAnsibleを定期的に自動実行するために、Jenkinsのビルドトリガー（スケジューラー機能）を使います。

　また、AnsibleのPlaybookをバージョン管理するために、バージョン管理システム「Git」（ギット）を使います。

　Ansible、Serverspec、Jenkins、Gitの4つのOSSツールを組み合わせて、基盤環境や単体テストのフレームワークを構築します。構築、単体試験の流れはおおむね次の通りです。

1. Playbookの作成
   構築内容を、Ansibleが実行するPlaybookに記述する
2. Playbookのバージョン管理
   作成したPlaybookを、Jenkinsが自動的にGitにプッシュして管理する
3. Playbookの実行スケジューリング
   JenkinsでAnsibleの構築をスケジューリングする
4. Playbookの実行、環境構築
   スケジュール通りAnsibleで構築を自動実行する
5. 単体試験
   構築された環境をServerSpecで自動検証する

　以上のように、基盤環境の構築、単体試験を自動化することで、事前にパッチの動作を確認する試験環境を素早く、正確に作ることができます。

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

　前章ではパッチマネジメントのために必要となる試験環境を整備する、基盤環境構築と単体試験の自動化について説明しました。次に、「マッチマネジメントのコアの部分」といえるパッチ適用の自動化について見ていきましょう。

　パッチ適用についてはLinux系とWindows系でそのやり方が大きく異なるので、最初にLinux系、その次にWindows系の順で話を進めていきます。

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

　ご承知の通り、Linuxには幾つものディストリビューションが存在し、セキュリティパッチの適用方法もさまざまですが、ここでは企業向けLinuxの代表的な製品「Red Hat Enterprise Linux」（RHEL）を例として取り上げます。

　Red HatではRHELを含む全てのソフトウェア製品の修正情報を「errata」（エラータ）というデータベースで公開しています。errataでは「アドバイザリー」という単位で修正情報が公開されており、アドバイザリーには、1つまたは複数の修正情報が含まれています。修正情報にはセキュリティ修正に加え、バグフィックスおよびエンハンスの情報もあります。

　アドバイザリーに含まれる情報には、概要、技術的な解説、該当する製品名／バージョン、解決方法などがあり、セキュリティ修正の場合には、特別に重要度、関連する脆弱（ぜいじゃく）性情報（CVE番号）が付加されます。

　RHELのセキュリティパッチの適用を検討する情報システム部門の担当者は、errataを使って適用するセキュリティ修正を検討し、セキュリティパッチを入手できます。「Red Hatカスタマーポータル」に登録すると、メールなどによって、プッシュ型で情報を入手することもできます。

　このようにして得られたパッチファイルは「rpm」コマンドによってインストールできるパッケージとして配布されます。

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

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

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

• アドバイザリー情報とAnsibleのPlaybookの対応を手動で管理する必要がある（どのサーバにどのパッチ適用したのか、未実施なのかどうかを手動で別管理する必要がある）
• 閉域ネットワークにあるLinuxサーバの場合、インターネットからパッチをダウンロードできない

　Red Hatでは、このような課題に対応するために、「Red Hat Satellite」という製品を提供しています。先に紹介したAnsibleなどのCI/CDツールは無料版がありますが、Red Hat Satelliteのラインセンスは有料であることにご留意ください。

システム管理製品「Red Hat Satellite」

　Red Hat SatelliteはRHELサーバのライフサイクルを一括管理するシステム管理製品です。いろいろな機能を持っていますが、セキュリティパッチ適用に関する機能に焦点を当てると、下記のようにまとめることができます。なお管理はGUI（グラフィカルユーザーインタフェース）で行えるので、LinuxのCUIに不慣れな運用管理者でも管理しやすくなっています。

Red Hat Satelliteの構成（Red Hat SatelliteサーバからRHELサーバを一元管理できる。プロキシ（Capslute）サーバによって柔軟な構成も可能）

・RHELサーバの情報収集

　管理しているRHELサーバごとに適用できるerrata情報を一元的に表示できます。errata情報のうち、種類（セキュリティ修正／バグフィックス／エンハンス）と個数を一覧化して表示できるので、「各サーバで対応すべきセキュリティ修正がどの程度あるのか」を一括して確認できます。

　観点を変えてerrata情報ごとに対応一覧、未対応のサーバを一覧表示することも可能です。緊急性が高い脆弱性が発生した場合、その脆弱性に対応する修正パッチの未対応サーバをすぐに抽出することもできます。

・パッケージの配布、適用

　管理するRHELサーバに対して、Red Hat Satelliteの管理サーバからセキュリティ修正パッケージ（パッチファイル）を配布し、適用できます。スケジュールを決めてパッチの配布、適用をコントロールすることも可能です。

　Red Hat Satelliteのプロキシを配置することで、セキュリティパッケージをプロキシにダウンロードしておき、そこから管理するRHELサーバにセキュリティパッケージを配布、適用することもできるので、インターネットに接続していない閉域ネットワークにあるRHELサーバにもタイムリーにセキュリティパッケージの配布、適用できます。

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

　ここではWindows Serverのパッチ適用自動化について見ていきます。

Microsoft Updateカタログ

　Windows Serverをはじめ、Microsoftのソフトウェア製品のセキュリティパッチは「Microsoft Updateカタログ」から入手できます。

　Microsoft Updateカタログでは、セキュリティパッチの他、デバイスドライバ、セキュリティ問題以外の修正プログラム、Windowsの新機能も入手可能です。Microsoft Updateカタログは、パッチの名前、説明、適用される製品、種類、サポート技術情報の記事などで検索できるデータベースになっており、入手したい修正プログラムをダウンロードできます。

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

　システム管理者が直接Microsoft Updateカタログから手動で修正プログラムを入手するのはレアケースです。通常はPCのWindows OSでおなじみの「Windows Update」を使って修正プログラムを入手し、適用します。

「Windows Server Update Services」によるWindows Updateの自動化

　Windows ServerにはLinuxと異なり、修正プログラムを適用するWindows Updateという専用のプログラムが備わっているので、Windows Serverのパッチ適用の自動化については、「各Windows ServerのWindows Updateをどのように管理して自動化するか」というポイントに絞り込まれます。そのためには無料のWindows Serverアプリケーション「Windows Server Update Services」（WSUS）を利用するとよいでしょう。

　通常Windows ServerがWindows Updateを実行すると、インターネット上にあるMicrosoftのアップデートサーバにアクセスして、更新プログラムを検索、ダウンロードすることになります。一方、WSUSを導入するとWSUSサーバが一元的にインターネットから更新プログラムをダウンロードし、配下のWindows Serverに配布する仕組みを構築できます。つまりインターネットにあるMicrosoftのアップデートサーバを企業内ネットワーク内に持ってくるイメージです。前章で説明したRHELでのRed Hat Satelliteと同じような位置付けになります。

WSUSの構成

　WSUSの主な機能は次の通りです。

・修正プログラムの配布、適用の制御

　管理するサーバに対して強制的に修正プログラムを配布し、適用できます。修正プログラムの削除も同様に制御できます。

・グループによる管理

　WSUSを運用するには「Active Directory」（AD）によるディレクトリ管理が前提になります。WSUSはグループごとにポリシーを決め、パッチ適用を効率化できます。例えば、グループごとにパッチ適用に時間差を設け、WSUSサーバやネットワークの負荷を軽減させるといった対応ができます。

・適用状況の可視化

　管理するサーバのパッチ適用状況を一覧化するなどして可視化できます。

・閉域ネットワークでの修正プログラムの自動化対応

　管理するサーバがインターネットに接続していない閉域ネットワークにある場合でも、タイムリーに修正プログラムを配布できます。

次回は脆弱性管理の自動化について

　以上のように、今回は基盤環境の自動化、パッチ適用の自動化についてお話ししました。次回は脆弱性管理の自動化についてお話しします。

筆者紹介

大久保 次郎

NTTデータ先端技術株式会社

経営企画部テクノロジーパートナーアライアンス推進室

情報処理安全確保支援士　CISSP　CISA