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のプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

バックポートでパッケージのサポート終了を回避

2025年7月、Gitは危険度の高い脆弱性「CVE-2025-48384」の報告を受けました。攻撃者がこの脆弱性を悪用すれば、リポジトリのクローンを作成する際に任意のコードを実行できます。米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は、この脆弱性の実際の悪用事例を確認後、Known Exploited Vulnerabilities(KEV、悪用が確認されている脆弱性)のカタログに追加しました。 この脆弱性の公開時に標準サポート終了を過ぎていたユーザーにとって、選択肢は2つでした。Ubuntu Proのサブスクリプションでセキュリティパッチを入手するか、開発者の作業環境やCI/CDインフラに既知のリモートコード実行(RCE)脆弱性を抱えたまま […]

Canonical、Ubuntu Pro for WSLを発表

Windows環境におけるUbuntu 24.04 LTSのWSLインスタンスにセキュリティメンテナンスとエンタープライズサポートを一括して提供。包括的なシステム管理機能も利用できるサブスクリプションサービス。 Canonicalは本日、Ubuntu Pro for WSLの一般提供を発表しました。Microsoftストアからインストール、ソースコードとベータ版はGitHubからダウンロード可能です。 「CanonicalとMicrosoftは、緊密なパートナーシップを通じてWSLの各種機能を構築しています。この取り組みは、WSLを利用して実運用向けのLinuxソリューションを構築する企業の開発者に有益です。」 Microsoft、WSLプロダクトマネージャー、Craig […]

Canonical、FIPS対応のKubernetesを公開

FIPS 140-3暗号化とDISA-STIGハードニングを備えた、FedRAMP対応のKubernetesクラスターとアプリケーションスイートを導入しましょう。 本日、KubeConにおいて、Ubuntuを提供するCanonicalは同社のKubernetesディストリビューションでFIPSモードを有効化するためのサポートを公開しました。これにより、高いセキュリティの導入や連邦政府向けの導入に適したスケーラブルなクラスターの構築と管理に必要なすべての要素を提供します。バージョン1.34以降、Canonical Kubernetesは認証済みの暗号モジュールを使用した内蔵FIPS 140-3機能とともに使用できます。このFIPS機能を備えた導入により、snapパッケージと […]