はじめに

こんにちは、ENKです。

 

今回のテーマは「システムを容易且つ安全に運用する」方法につきまして、特にAWSクラウドのパッチ適用運用に焦点を当てて、詳しく説明させていただきます。


パッチ(一般に修正プログラムや更新プログラム、アップデートファイルとも言います)には製品の不具合修正やセキュリティ脆弱性の解消が含まれます。そのため、パッチの提供状況を定期的に確認し、自システムに適用可能な項目を選び、これを検証し積極的に反映させる体制を作り上げることが一層重要となります。このような取り組みの積み重ねは、システムの安定稼働につながります。


本テーマでは特に、パッチ適用運用というクラウドでの観点から見て、クラウド上で管理されていないEC2(仮想サーバー)で、従来のオンプレミスサーバーと同じ対応が求められます。マネージドサービスであっても、そのサービスのパッチを含むバージョンアップ運用は必要になりますので、これも併せて考慮する必要があります。
このようなパッチ適用を容易にするための手段について、特にEC2について深くお話しできればと思います。

目次

  1. 本記事の対象範囲
  2. AWSでのパッチ適用運用の流れ
  3. Patch Manager利用環境のポイント
  4. まとめ

1. 本記事の対象範囲

本書では、AWSのサービスの中でも、特にEC2(WindowsおよびLinux)を対象にしたSystems Manager Patch Manager(以下、Patch Manager)の対応範囲に限定し、詳しく説明を行います。

 

EC2以外のサービスは、マネージドサービスに分類されるため、ユーザー自身が積極的にパッチを適用する必要はありません。例えば、RDS(Relational Database Service)のような一部のサービスでは、メンテナンス期間を設定し、パッチを含むマイナーバージョンアップが自動的に適用されるという方法も存在します。

しかし、本書ではこれらを扱う範囲からは外させていただきます。

2. AWSでのパッチ適用運用の流れ

パッチ適用運用を始めるにあたり、最初に必要なのは、お客様の自社で管理している情報システムを構築している各サーバーのソフトウェアおよびそのバージョン情報の正確な収集です。
近年では、インベントリやパッチ管理サービスを利用することで、このインベントリ情報の収集が大いに簡易化されています。AWSを使用する場合、インベントリ収集にはSystems Manager Inventoryを活用できます。これにより資産情報の詳細を効率的に収集することが可能となります。
さらに、パッチ管理プロセスにおいてはPatch Managerが活用可能です。特にPatch Managerを使用することで、本記事のテーマとしているパッチ適用運用のサイクルを実現し、運用にかかる労力を大幅に軽減することができます。

 

  1. 脆弱性情報の確認
    1. Patch Managerなどのパッチ管理サービスを使用している場合、パッチ適用候補は自動的に選択されます。これを用いて確認をすることができます。ただし、この選択された候補については、WindowsとLinuxでは特性が異なるため、以下の点を確認し、各OSの特性を理解しておくことが重要です。

      Linux と Windows のパッチ適用の重要な相違点
      https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-windows-and-linux-differences.html
    2. サードパーティーのミドルウェア等についても、一部はPatch Managerを用いて取得できますが、完全にはカバーできません。そのため、各サードパーティーのウェブサイトから直接、脆弱性情報を確認する必要があります。
    3. 尚、また、脆弱性情報の確認は、定期的に行うというルールを必ず設けましょう。ルールを設定しないと、確認対象として見落とされがちとなります。例えば、四半期に一度でも構いませんので、定期的に情報を確認することが推奨されます。
       
  2.  保有している情報システムに対する影響確認
    1. 対応の優先順位を決めるためには、まず影響度を見ることが重要です。パッチが提供された際には、CVE(Common Vulnerabilities and Exposures: 共通脆弱性識別子)と紐付けられたCVSSスコア(Common Vulnerability Scoring System: セキュリティ脆弱性の重大性を数値化したスコア)により判断します。CVSSの危険度は最高が10.0となっており、この数値を基に影響度を見ることができます。
      ①    深刻度がレベルⅢ(危険):CVSS基本値 7.0~10.0
      ②    深刻度がレベルⅡ(警告):CVSS基本値 4.0~6.9
      ③    深刻度がレベルⅠ(注意):CVSS基本値 0.0~3.9

      CVSSの詳細については、以下の資料を参考にすると、より深い理解を得ることができます。
      共通脆弱性評価システム CVSS v3について
      https://www.ipa.go.jp/security/guide/vuln/ug65p90000019bum-att/000081020.pdf
    2. システムを常に最新の状態に保つために、何の影響もなくすべてのパッチを適用するというポリシーも存在するかもしれません。しかし、パッチを適用するとシステムの構成に直接変更を加えることになるため、慎重な方針を策定することが推奨されます。
       
  3. 最新パッチの入手
    1. Patch Managerを利用している場合、パッチの個別ダウンロードは不要です。ここはサービス任せにすることが最適です。
    2. サードパーティーのミドルウェア等については、適切なサポート契約を元に適切な方法で入手してください。
       
  4.  パッチ適用スケジュール作成
    1. Patch Managerでは、まずメンテナンスウィンドウを設定します。次に、Patch Baselineというルール(カスタマイズ可能)を設定することで、パッチ適用のスケジュールを作成できます。メンテナンスウィンドウ内では、検出したパッチをすぐに適用するか、抽出してから承認後に適用するかの選択が可能で、さらに深刻度に応じたパッチ対象を選ぶこともできます。
    2. 一度スケジュールを設定してしまえば、後はどの環境で検証を行い、どのタイミングで本番環境に適用するかという準備に移行することができます。
       
  5.  検証から本番環境への適用
    1. 環境の分け方は多種多様で、一例としてAWSアカウント単位での分割やパッチグループによる区分けなどがあります。これらの方法を活用し、確実に環境を分離し、適切な検証が行えるようにご準備ください。
    2. このような方法により、パッチが本番環境に適用されない安全策を講じ、パッチ適用後の検証環境でアプリケーションへの影響がないことを確認しましょう。必ずこの工程を経てから本番環境へ移行することが重要です。
       
  6.  適用状況の確認
    1. パッチ適用の確認は、Patch Managerのダッシュボードから行うことができます。パッチが無事に適用され、情報システムの運用に問題がなければ、次に本番環境への適用に進みます。
    2. もちろん、サードパーティーの製品についてはPatch Managerのダッシュボードに表示されないため、パッチ適用後にログやバージョン確認コマンド等を用いて適用状況を確認する必要があります。
       
  7.  パッチ適用作業の完了
    1. このように一連の手順を踏むことで、パッチ適用運用の一サイクルが完成します。仮にシステムのライフサイクルを5年で考慮し、四半期ごとにパッチを行うと仮定すると、最低でも20回はこのサイクルを実行することになります。そのため、しっかりとしたパッチ適用運用を設計し、手順を作成することが重要となります。

3. Patch Manager利用環境のポイント

この機能は、パッチを適用するための直感的でシンプルなサービスです。マニュアルをご確認いただければ、それほど扱いが難しいサービスであるとは思われないでしょう。しかしながら、一部の点については、多くの方が誤解しているという事例が存在します。
ここではその一例を紹介します。
 

  • 一般的に見落とされがちな誤りとして、パッチリソースへの経路確保の漏れがあります。Linux系では、インターネット接続がなくてもAWSのリポジトリからパッチ情報を取得することが可能です。しかし、Windowsの場合は、パッチ情報を取得するためにはMicrosoftのサイトへの接続が必要となり、そのためにはインターネット接続が必要となります。このような違いが存在するので、気を付けていただきたいと思います。

    Patch Manager の前提条件
    https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-prerequisites.html

4. まとめ

パッチ適用運用自体は難易度の高い作業ではありませんが、パッチの確認から検証、そして本番への適用という一連の流れは、クラウドを利用していてもなお、地道かつ時間のかかる作業となります。そのため、作業を簡素化するためには、運用設計の段階でどの深刻度レベルのパッチを適用するのか、対象となるパッチを全て適用するのか、また検証作業をどの程度まで効率化できるか等、手動で行う作業の範囲をきちんと限定していく必要があると考えられます。さらに、新規にシステムを構築する際には、マネージドサービスの積極的な利用を設計の前提とすることが重要となります。


これらは結構大変だと思いますので、将来的には、パッチ適用運用という活動が全て自動化され、我々が「パッチ適用運用」という言葉自体を使わなくなることを期待されます。