この記事の要点
- 仮想サーバー（IaaS）では OS とその上のソフトの更新は利用者が担い、マネージドのデータベースなどでは事業者が保守の時間帯に更新を当てます。どこまでが自社の分かを先に分けます。
- AWS・Azure・Google Cloud には、足りない更新を調べ、決めた時間帯に当てる仕組みがあります。ただし、事業者は更新の中身を利用者の環境で試してはくれません。
- 毎月の定期の更新と、急ぎの更新の進め方を分けて決め、当てる前に戻せる状態をつくっておきます。
OS・ミドルウェアの更新を回すとは、更新する対象を洗い出し、どの周期で、どの環境から順に当て、当てた後に何を確かめ、うまくいかないときにどう戻すかを決めて、毎月同じ手順でくり返すことです。クラウドに移っても、更新の作業がすべてなくなるわけではありません。どこまでが自社の仕事として残るのかを分けるところから始めます。
誰が、何を更新するのか
更新の分担は、使っているサービスの形で変わります。仮想サーバーを借りる IaaS では、OS とその上のミドルウェア（Web サーバー・PHP・データベースのソフトなど）の更新は利用者が担います。データベースなどを事業者が運用する PaaS では、OS やエンジンの更新の多くを事業者が行います。
たとえば、Amazon RDS（AWS のマネージドのデータベース）では、事業者が定期的に保守を行い、その対象には、基盤のハードウェア、OS、データベースのエンジンの版が含まれます。OS の更新の多くはセキュリティのためで、AWS はできるだけ早く当てることを勧めています。必須の更新には適用の期日があり、期日の後は、利用者が決めた週1回の保守の時間帯に当てられます。一部の更新では、データベースが短い時間止まることがあります。
出典：Maintaining a DB instance（AWS）
つまり、マネージドのサービスでも「いつ止まってよいか」を決めるのは利用者です。分担の全体は、IaaS・PaaS・SaaS の違いと、運用の責任の分かれ目と責任共有モデルで説明しています。
クラウドに用意されている更新の仕組み
3つのクラウドには、仮想サーバーの足りない更新を調べ、決めた時間帯に当てる仕組みが用意されています。手作業でサーバーに1台ずつ入って更新するより、漏れを見つけやすくなります。
| クラウド | 仕組み | できること（公式の説明から） |
|---|---|---|
| AWS | Systems Manager の Patch Manager | 足りない更新の報告だけを出す「調べる」と、「調べて当てる」を選べる。当てる更新の決まり（パッチベースライン）を定め、保守の時間帯に実行し、準拠の状況を一覧で見られる |
| Microsoft Azure | Azure Update Manager | 24時間ごとの定期の確認、決めた保守の時間帯での更新。Azure Arc でつないだ社内や他社のクラウドのサーバーも、同じ画面で扱える |
| Google Cloud | VM Manager の Patch | 更新の状況を重要度ごとに示す報告と、更新の実行。その場で、日時を決めて、くり返しの予定で実行でき、更新の前と後に動かす処理も設定できる |
出典：AWS Systems Manager Patch Manager（AWS）、About Azure Update Manager（Microsoft Learn）、About Patch（Google Cloud）
ただし、仕組みがあれば任せきりにできるわけではありません。AWS の説明では、Patch Manager で配る更新を AWS が事前に試すことはしないとされています。また、Windows Server 2016 から 2019 へのような、OS の大きな版の上げ方には対応していません。用意されている決まり（パッチベースライン）も見本で、推奨の設定ではないとされています。自社のシステムで動くかどうかを確かめる工程は、利用者の側に残ります。
出典：AWS Systems Manager Patch Manager（AWS）
毎月の更新の回し方
定期の更新は、同じ順番で毎月くり返せる形にします。順番を決めておくと、担当が替わっても同じ品質で回せます。
- 情報を集める：OS・ミドルウェアの更新（セキュリティパッチ）の情報と、脆弱性の深刻さを確かめる
- 検証の環境で当てる：本番と同じ構成の検証の環境に先に当て、業務の画面や連携が動くかを確かめる
- 本番に当てる：決めた保守の時間帯に当てる。台数が多い場合は、一部から順に広げる
- 確かめる：サービスが起動しているか、エラーが増えていないかを監視の画面で見る
- 記録する：当てた更新、当てなかった更新とその理由、気づいた点を残す
当てなかった更新を記録に残すことが大切です。アプリが古い版にしか対応していないなどの理由で見送った更新は、いつまでに解消するのかを決めておかないと、そのまま残り続けます。サポートの期限が近い OS やデータベースは、サポートの終わるOS・データベースを放置しないで説明しています。
急ぎの更新は、別の道を用意する
すでに攻撃に使われている脆弱性のように、毎月の周期を待てない更新もあります。急ぎの更新は、定期の更新とは別の進め方を、あらかじめ決めておきます。
AWS の Patch Manager には、予定を組まずにすぐ更新を当てる「Patch now」という操作があります。こうした操作を使う場合でも、誰が急ぎと判断するのか、検証をどこまで省くのか、業務の担当にいつ知らせるのかは、人が決めておく必要があります。判断の基準を事前に文書にしておくと、夜間に慌てて決めずに済みます。脆弱性の情報の集め方は脆弱性の情報を、どう集めて優先順位をつけるか。JVN・KEV・CVSSの使い方で説明しています。
出典：AWS Systems Manager Patch Manager（AWS）
毎月の周期を待てる更新か、待てない更新か
- 待てる更新定期の更新の進め方で回す
- 待てない更新すでに攻撃に使われている脆弱性など。急ぎの更新の道で進める
- 急ぎの道で決めておくこと誰が急ぎと判断するか、検証をどこまで省くか、業務の担当にいつ知らせるか
判断の基準は、事前に文書にしておきます
当てる前に、戻せる状態をつくる
更新は、当てた後に不具合が見つかることがあります。当てる前に、元に戻せる状態をつくっておきます。
- 仮想サーバー：更新の前にディスクのスナップショットやマシンのイメージを取り、戻す手順を手順書に書いておく
- マネージドのデータベース：Amazon RDS のマルチ AZ 構成では、OS の更新を待機側から当て、切り替えてから元の主側に当てる流れになるため、止まる時間を短くできます。一方で、エンジンの版を上げるときは主と待機を同時に変更するため、その間は使えなくなります
出典：Maintaining a DB instance（AWS）
戻す手順は、使う機会が少ないほど、いざというときに動かないことがあります。検証の環境で、実際に戻してみることをおすすめします。
当社のご支援
アメリア・テクノロジーのクラウドの構築と運用管理では、更新の対象の洗い出し、更新の仕組みの設定、検証から本番までの手順書づくり、毎月の更新の実施と報告をご支援しています。運用管理の月額の時間の中で、更新の作業と記録をお受けすることもできます。いまの更新の状況をおおまかに確かめたい場合は、無料のクラウドの自己診断をご利用ください。
- クラウド
- パッチ管理
- 運用管理
- 脆弱性
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。