Linuxにセキュリティパッチを適用する頻度は?

by Canonical on 1 October 2024

セキュアな環境を維持するには定期的なパッチの適用が不可欠ですが、Linux環境を安全に保つための方法は環境によって異なります。運用の安定性を考えて、どのぐらいの更新頻度が妥当でしょうか? 最も制限が多く、規制が厳しい環境でも、準拠が保証され安全な方法で、セキュリティパッチの適用を自動化できる方針が存在します。セキュリティパッチの適用方針を定義するときは、Canonicalでのソフトウェア更新のリリーススケジュールを理解し、セキュリティパッチの適用の時間枠を知っておくことが不可欠です。私は最近、ライブのウェビナーとセキュリティの質疑応答を主催し、パッチ適用の回数を最小化するとともに、パッチが適用されていない脆弱性が悪用される回数も最小化する方法について解説しました。この記事では、ウェビナーで話した重要な部分を要約し、更新のスケジュールにおいて最も重要な考慮事項について解説します。

Linuxカーネルへのセキュリティパッチの適用

Ubuntuで利用可能なカーネルには2種類あり、これらのカーネルをパッケージ化する方法も2つあります。カーネルの種類は、一般提供(GA)のカーネルとバリアントのカーネルの2つです。パッケージの種類は、debianパッケージとsnapパッケージです。GAカーネルは、Ubuntu LTSのリリース時点で含まれているバージョンのカーネルです。すべてのUbuntu LTSリリースには、毎年の2月と8月にポイントリリース更新があり、通常は5回のポイントリリースが行われます。Ubuntu Serverは、Ubuntu Proでそのリリースがカバーされている期間の終わりまで、GAカーネルをそのまま使うのがデフォルトです。Ubuntu Desktopは、2番目のポイントリリースから、アップストリームカーネルの最新バージョンにアップグレードするのがデフォルトです。このバージョンは、ハードウェアイネーブルメント(HWE)カーネルと呼ばれます。

GAカーネルは、Ubuntu Proでそのリリースがカバーされる期間の終わりまでセキュリティの保守が行われます。HWEカーネルは、HWEカーネルの使用期間の終わりまでの6か月と、追加の3か月にわたってセキュリティの保守が行われます。HWEカーネルの使用期間が終わってからも3か月間にわたりセキュリティが保守されるため、ユーザーは次のHWEカーネルにアップグレードするための猶予期間を得られます。

セキュリティパッチの適用には再起動が必要か

カーネルパッケージが更新されたときは、パッチの適用されたカーネルをメモリに読み込むために、Ubuntuインスタンスを再起動する必要があります。一般提供カーネルがsnapとしてインストールされるとき、そのsnapパッケージへの更新によりデバイスが再起動されます。一般提供カーネルがdebパッケージとしてインストールされるとき、再起動は自動的に行われませんが、セキュリティパッチを適用するには再起動する必要があります。

Ubuntuの他のパッケージにも、更新時に再起動が必要なものがあります。glibc、libc、CPUのマイクロコード、grubブートローダーへのセキュリティ更新を有効化するには再起動が必要です。サービスとして実行されるソフトウェアは、セキュリティパッチが適用されたときに、そのサービスを再起動する必要があります。例として、ssh、ウェブサーバーなどが挙げられます。サービスではなくオンデマンドで実行される他のソフトウェアは、システムやサービスの再起動を必要としません。

Livepatchサービスは、メモリ内で実行中のカーネルに、深刻度が高および致命的のセキュリティパッチを適用します。インストールされているカーネルパッケージは更新されないため、コンピュータを再起動してメモリをクリアすると、Livepatchで適用されたセキュリティパッチは消去されます。Livepatchは、GAカーネルには13か月、HWEカーネルには9か月にわたってセキュリティパッチを行います。この13か月または9か月の期間の経過後に、引き続きセキュリティにLivepatchを使用するには、カーネルパッケージをアップグレードし、Ubuntuインスタンスを再起動する必要があります。

セキュリティパッチを適用する3つの方法

CanonicalはLivepatch、Landscape、Snap、およびunattended-upgradeなどのコマンドラインユーティリティを含む多数のツールとサービスを提供しています。これらのツールとサービスを一緒に、または選択的に使用して、Ubuntuでのセキュリティパッチの適用を自動化できます。これらのツールを柔軟に使用して、デスクトップ、サーバー、IoTデバイスのすべてについて、さまざまなセキュリティパッチの適用の目標を達成できます。セキュアでない、または保守担当者によってサポートされていないソフトウェアを実行したい人はいないという想定に基づいて、次のいずれかのセキュリティパッチの適用方法を選択できます。

  1. セキュリティパッチの適用はできるだけ遅らせます。
  2. セキュリティパッチの適用は最低の頻度で、ただし事前に定めた間隔で定期的に行います。
  3. セキュリティパッチのリリースからインストールまでの時間を短縮し、システムの脆弱性が悪用される恐れがある期間を短くします。

どの方法を使用しても、glibc、libc、CPUのマイクロコードのセキュリティ脆弱性にパッチを適用するために、スケジュールにないセキュリティ保守の時間枠が必要な可能性があることに注意してください。

セキュリティパッチをできるだけ遅らせる

Livepatchが有効なとき、GAカーネル上にあるUbuntu LTSインスタンスは、13か月ごとにアップグレードと再起動が必要です。HWEカーネルで実行されるときは、13か月の経過後、5月に最初のアップグレードと再起動を行います。それ以後は、6か月後の11月に再度アップグレードと再起動を行う必要があります。以後の5月と11月にアップグレードと再起動を行った後で、HWEカーネルは次のGAカーネルに昇格されます。GAカーネルは、13か月ごとにアップグレードと再起動が必要です。

アップグレードと再起動の間に数か月が経過するため、この方法でパッチを遅らせると、深刻度が中程度およびそれ以下のカーネルの脆弱性はパッチが適用されず残ることになります。この方法では、深刻度が中および低のカーネルの脆弱性にパッチが適用されないまま残る期間が最も長くなります。

定期的なスケジュールでセキュリティパッチを適用する

GAカーネルが使用されるときは、毎年パッチを適用する方法がうまく機能することがあります。GAカーネルがLivepatchによって13か月セキュリティがサポートされることを考慮して、毎年5月にセキュリティパッチをインストールして再起動すると、コンピュータのカーネルと他のパッケージをセキュアな状態に維持できます。

HWEカーネルが使用されている場合、年ごとのパッチ適用周期を使用して、毎年同じ月にセキュリティパッチを適用することはできません。この方法では、カーネルのセキュリティパッチの適用が一定期間行われない結果になります。Ubuntu LTSリリースの3年目、4回目のポイントリリースが公開されるときを除けば、HWEカーネルを使用して年に1回セキュリティパッチを適用できます。

年に2回、5月と9月にセキュリティパッチを適用すると、カーネルの種類にかかわらずセキュアな状態を維持できます。このセキュリティパッチの適用スケジュールは、Canonicalのリリーススケジュールと、カーネルのセキュリティがカバーされる期間も考慮に入れたものです。セキュリティメンテナンスを毎年5月と9月の2回にスケジュールすると、セキュリティがカバーされない期間を無くすことができます。

セキュリティパッチの適用により悪用が可能な部分を最小限に抑える

セキュリティメンテナンスは頻度が多いほうがよいのは確かです。一般的なスケジュールは毎月です。カーネルを毎月アップグレードと再起動すれば、古いカーネルが実行されることはありません。セキュリティパッチの適用と再起動の推奨頻度は毎週です。毎日なら申し分ありません。Canonicalのセキュリティパッチは完成と同時に公開されるため、公開されたらすぐに利用することをおすすめします。ワークロードを高可用性で実行し、セキュリティパッチの適用を自動化して、コンピュータのグループに対して段階的なアップグレードと再起動を毎日行うことで、最も強固なセキュリティ態勢となります。

セキュリティパッチの適用を自動化するためのベストプラクティス

セキュリティパッチ適用の自動化をスケジュールするためのベストプラクティスのウェビナーでは、主な質問のすべてに回答します。

  • パッチ適用にはどんな自動化方法があるか
  • セキュリティパッチはどこから供給され、どこから配布されるのか
  • セキュリティパッチはどのように配布され、どのように適用するのか
  • Canonicalのローリングカーネル方式により、特定のカーネルについてセキュリティのカバー期間はどのように延長されるのか
  • セキュリティメンテナンスのイベントはどの時点にスケジュールすべきなのか
ニュースレターのサインアップ

Ubuntuニュースレターの配信登録

お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

Firefighting Supportを発表

新しいサービスでCanonicalの専門家が高度なクラウドサポートを提供 Canonicalのマネージドソリューションチームは、自社でインフラストラクチャの管理を行い、トラブルシューティングの必要があるときのみ専門家の対応を求める組織のために、新しいサービス「Firefighting Support」を発表しました。 Firefighting Supportでは、フルマネージドサービスを止めた、または厳しいセキュリティ規制によってサードパーティーに環境へのアクセスを許可できないお客様に対して、マネージドサービスレベルのサポートを提供します。このサービスはノードごとの年間料金で提供され、次のような内容です。 自己管理インフラストラクチャへの移行に理想的 現在の市場では、マネ […]

CanonicalのCISOがEUサイバーレジリエンス法を完全解説

強力で対象の広い規制は、関係者の安全を確保する一方、不確定性をもたらす可能性があります。EUサイバーレジリエンス法(CRA)も例外ではありません。オープンソース関係者と技術業界全般にわたり、心配、不安、希望などさまざまな反応が見られます。 しかし怖がる理由があるのでしょうか? EUサイバーレジリエンス法が本当にオープンソースの状況を変えるのでしょうか? 企業はこの法律にどう備えれば良いのでしょうか? この記事ではEUサイバーレジリエンス法とその目的、要件、オープンソース関係者に対する影響を説明し、施行に備えたサイバーセキュリティ上のアドバイスをご紹介します。 EUサイバーレジリエンス法とは? EUサイバーレジリエンス法(CRA)とは、欧州連合(EU)の法律で、EUのIT業 […]

機械学習のセキュリティリスクの概要

データはあらゆる機械学習(ML)プロジェクトの要であり、悪人もそれを知っています。技術者の間でAIが常に話題になるとともに、MLシステムは攻撃の標的としても注目を集めています。Identity Theft Resource Center(ID窃盗リソースセンター)の報告によれば、2023年にはデータ漏えいが72%も増加しており、MLプロジェクトが恰好の攻撃経路とならないよう適切な対策を施すことは極めて重要です。このブログ記事では、機械学習のセキュリティリスクについて説明し、主要な脅威と課題に言及します。しかし、悲観的な話だけでなくベストプラクティスにも目を向け、オープンソースの役割も含め、可能なソリューションを探求します。 機械学習の攻撃対象領域 あらゆるテクノロジーには […]