AWS・VPSでWordPressを運用する担当者のためのサーバーのパッチ管理

AWSでは「責任共有モデル」という考え方がとられており、クラウドの基盤はAWSが、その上で動かすOSやミドルウェア、アプリケーションは利用者が責任を持ちます。VPSも同じように、OSから上は利用者の管理範囲です。

つまり、EC2やVPSでWordPressを構築している場合、OSやPHPに脆弱性が見つかったときに修正を当てるのは、利用者自身です。サーバーの種類ごとの責任範囲の違いは「PHPの更新は誰がやる？」で比較しています。

WordPressを動かすサーバーでは、主に次のソフトウェアがパッチ管理の対象になります。

WordPress本体やプラグインの更新に加えて、これらのサーバー側の更新も必要です。サイト側とサーバー側の脆弱性の違いは「WordPressを更新していても防げない『サーバー側』の脆弱性とは」で解説しています。

OSの提供元のセキュリティ情報、PHPなど各ソフトウェアの公式発表、国内のセキュリティ機関（JPCERT/CCやIPAなど）の注意喚起などを、定期的に確認します。確認する情報源と頻度を決めておくと、担当者が変わっても続けやすくなります。

すべての更新を同じ急ぎ方で適用する必要はありません。外部から攻撃できる脆弱性かどうか、すでに悪用されているかどうかで、優先度を判断します。

いきなり本番に適用すると、更新によってサイトが動かなくなることがあります。本番と同じ構成の検証環境で先に適用し、動作を確認しましょう。

アクセスの少ない時間帯に、事前にバックアップやスナップショットを取ってから適用します。AWSでは、AWS Systems Manager（Patch Manager）のように、パッチの適用を自動化・一元管理する仕組みも用意されています。

PHPやWebサーバーは、更新しても再起動するまで古いプログラムが動き続けることがあります。PHP-FPMやWebサーバー、カーネルの更新ではサーバー自体の再起動が必要です。再起動後に、バージョンや更新履歴で反映を確認し、サイトの表示や機能を確認します。

更新の日時、対象、内容、結果を記録しておくと、問題が起きたときの原因の切り分けや、担当者の引き継ぎに役立ちます。

サーバーの管理を1人か2人で兼任していることが多く、その人がいないと更新が止まります。担当者が異動や退職をすると、サーバーの構成や手順が分からなくなることもあります。

重大な脆弱性は、時間を選ばずに公表されます。公表から攻撃までの時間が短いこともあり、すぐに対応できる体制がないと、無防備な時間が長くなります。

脆弱性が公表されたときの具体的な対応の流れは「PHPの重大な脆弱性が公表されたとき、WordPressサイトの担当者がやるべきこと」で解説しています。

「更新してサイトが止まったら困る」という心配から、更新が後回しになりがちです。とくにOSやPHPのバージョンを上げる大きな更新は、検証の手間もかかるため、先送りされやすくなります。

情報収集、検証、適用、再起動、記録を繰り返すうちに、インフラ担当者の時間がパッチ管理に取られ、本来取り組みたい業務に手が回らなくなります。

次の項目に当てはまるものが多いほど、自前での運用を見直す時期に来ていると考えられます。

• サーバーを管理できる担当者が1人か2人しかいない
• 緊急の脆弱性に、夜間や休日でもすぐ対応できる体制がない
• パッチの適用が、数週間から数か月遅れることがある
• OSやPHPのバージョンが古く、サポート期限が近いか過ぎている
• サーバーの構成や手順が文書になっていない
• インフラ担当者がパッチ管理に時間を取られ、本来の業務が進まない
  
  

一方で、サーバーの構成を細かく調整する必要がある場合や、社内に十分な体制がある場合は、自前での運用にも利点があります。大切なのは、「なんとなく続けている」状態をやめ、体制と負担を見たうえで判断することです。

自前での運用を見直すとき、「レンタルサーバーに戻すと性能が足りない」と考える担当者は少なくありません。その場合は、クラウドの基盤はそのままに、サーバーの管理をサービスとして提供するマネージドホスティングを選ぶ方法があります。

「WP-Chorus」は、NHNテコラスが提供する企業向けのWordPressクラウドホスティングです。AWSの基盤の上で、サーバーの管理を任せられます。

• OSやミドルウェアのパッチ適用を含むインフラ運用管理を全プランで標準提供（ミドルウェアのパッチ管理はNHNテコラスが対応）
• 24時間365日のサーバー運用監視
• マネージドデータベース（SMALL1以上）で、データベースのメンテナンスの負担を軽減
• フェイルオーバー機能（SINGLE以外）で、サーバー障害時に自動で復旧
• 電話・メールでのサポート（SMALL1以上。SINGLEはメールのみ）

技術的に後退するのではなく、専門の事業者に運用を任せることで、インフラ担当者は本来の業務に時間を使えるようになります。

• AWSやVPSで自前で運用している場合、OS、Webサーバー、PHP、データベースのパッチ管理は利用者の責任
• 情報収集、影響の判断、検証、適用、再起動と確認、記録の流れで進める
• 自前のパッチ管理では、担当者への依存、夜間・休日の対応、更新の先送りが問題になりやすい
• 体制と負担を見て、自前での運用を続けるか、管理を任せるかを判断する
  
  

自社のパッチ管理の状況を、一度チェックリストで振り返ってみてください。