TuxCare ELS：古いLinuxバージョンの運用を管理しながら継続する

TuxCare ELSを補完するもの

Linuxディストリビューションの正規サポートが終了すると、サーバーは必ずしも従来のパッケージリポジトリからセキュリティアップデートを受け続けられるとは限りません。これは、特定の業務用アプリケーションが依然として旧環境に依存している場合に特に問題となります。 延長サポートを利用すれば、正規のメンテナンス終了という事実を覆すことなく、計画的な移行を行うための時間を確保することができます。

TuxCare 無期限のライフサイクルサポート for OSは、サポート対象の旧版ディストリビューション向けに、セキュリティアップデートおよび厳選されたバグ修正を提供します。メーカーによると、このサービスにはカーネルと、ディストリビューションに応じた重要なパッケージのセレクションが含まれます。新しいLinuxのメジャーバージョンはインストールされません。サーバーは従来のディストリビューションバージョンのまま維持され、対象となるコンポーネントに対して追加のメンテナンスが提供されます。

運用上、これは重要な暫定的な解決策となり得ます。互換性のないアプリケーションを直ちに切り替える必要はなく、対象となるパッケージに対して利用可能なセキュリティ修正プログラムを適用しながら、移行の準備を進めることができるからです。ただし、その前提として、実際に必要なパッケージ、アーキテクチャ、および選択したサービスが互いに適合している必要があります。

仝 パッケージカバー これは、サーバー全体のセキュリティと同一視することはできません。自分でインストールしたアプリケーション、拡張機能、あるいは別のパッケージソースからのサービスは、OSが提供する範囲外にある可能性があります。また、設定ミスや不必要に公開されているサービスは、サブスクリプションを契約したからといって解消されるわけではなく、引き続き確認とセキュリティ対策を行う必要があります。

対象となるパッケージにおいても、深刻度は重要な要素となります。TuxCareでは、CVSS 7以上の「高」および「重大」なリスクに対するセキュリティ修正を提供しています。CVSS 4.0から6.9の「中」リスクについては、同社によれば、緩和策が利用できず、かつ顧客からの需要が十分にある場合に、パッチの提供が検討されます。 また、TuxCareは、直接的なコード修正の代わりに緩和策を提供する権利を留保しています。したがって、対象パッケージに含まれているからといって、その中のすべての既知の脆弱性が修正されるわけではありません。

したがって、重要なのは、そのディストリビューションがサポートリストに掲載されているかどうかだけではありません。 Linuxのセキュリティ 具体的なサーバー上でどのコンポーネントが使用されているか、適切な修正プログラムが用意されているか、そしてそれらが実際にインストールされているかを確認します。ELSはパッチ適用プロセスを補完するものではありますが、現状把握や移行計画に代わるものではありません。

カバーとサーバーの在庫を確認する

TuxCare ELS を選択する前に、 サーバーの資産一覧. ディストリビューション名、正確なバージョン、アーキテクチャ、および稼働中のカーネルを記録してください。また、設定済みのパッケージリポジトリや、公開されているサービス、あるいは他のネットワークからアクセス可能なサービスについても記録してください。そうすることで、単にディストリビューション名をチェックするだけでなく、ベンダーリストと実際のシステムを照合することが可能になります。

例えば、古いWebサーバーの場合、Webサーバーパッケージ、暗号ライブラリ、PHPランタイム、および必要なPHP拡張機能などを棚卸しの対象に含める必要があります。 各パッケージの入手元とインストールされているバージョンを必ず記録しておいてください。サードパーティのリポジトリからの拡張機能は、元のディストリビューションに含まれるパッケージとはメンテナンス条件が異なる場合があります。

これらのコンポーネントを、該当するディストリビューションの最新のパッケージリストと一つずつ照合してください。また、対象となる提供内容のアーキテクチャや条件についても確認してください。 サポート対象のディストリビューションであっても、そこにインストールされているすべてのパッケージやランタイムのすべてのバージョンが、自動的にELS for OSの対象となるわけではありません。対象となっているパッケージであっても、個々の脆弱性への対応は、その深刻度などによって異なります。

特に見落としがちなのが、自分でコンパイルしたプログラムや、別途インストールした実行環境です。 コンテナイメージにも独自のコンポーネントが含まれています。ホストOSのメンテナンスを行っても、イメージ内のパッケージが更新されているとは限りません。こうしたコンポーネントについては、別途確認を行い、独自の更新プロセスが必要です。

ELS for OS および アプリケーション向けELS これらは別々のサービスです。古いPHPバージョンを追加サービスを通じてメンテナンスできるかどうかは、バージョン、パッケージ形式、アーキテクチャ、入手方法などによって異なります。古いPHPアプリケーション向けのもう1つの可能な環境については、以下の記事で説明されています。 CloudLinuxのAlt-PHPとそのセキュリティ面; したがって、TuxCare OSサブスクリプションによる補償の対象にはなりません。

サポート期間を正しく把握する

サポートの終了時期は、それぞれの保守期間と併せて考慮して初めて意味を持ちます。通常の保守期間が終了しても、有料サービスや追加サービスがすべて同時に終了するとは限りません。そのため、判断を下す際には、期間だけでなく、対象となるパッケージ、アーキテクチャ、契約条件も確認しておく必要があります。

現在公開されているTuxCareのドキュメントによると、サポート対象のオペレーティングシステムにおけるELSの保証実行時間は 25年 それぞれ記載されている当初のサポート終了日から。例として、CentOS 7については2049年6月30日、Ubuntu 18.04については2048年5月31日が挙げられています。これらはプロバイダーが提示するサポート期間に関する情報であり、インストールされたすべてのアプリケーションに対する保証ではありません。

Ubuntu 18.04 について、Canonical はいくつかのフェーズを区別しています。標準サポートは 2023 年 5 月に終了し、Ubuntu Pro は 2028 年 5 月まで提供される予定です。 現在の概要では、追加のレガシーサポートは2033年5月までと記載されています。これらのサービスは、終了日だけで比較することはできません。具体的なサーバーのパッケージ構成、アーキテクチャ、契約条件などが考慮される必要があるためです。

例えばUbuntuのWebサーバーの場合、必要なパッケージが実際に選択したメンテナンスプランに含まれているか、またアップデートが既存の運用プロセスにどのように組み込まれるかを確認してください。合意された範囲外の重要な稼働期間や拡張機能がある場合、期間が長くてもあまり意味がありません。

記載された期限は、2026年11月4日時点の調査対象となった情報源に基づく、メーカーの動的ウェブページに基づいています。この基準日時点で、すべての最新情報がすでに適用されていたかどうかを、遡及的に一通り確認することはできません。 そのため、公開または契約締結の前に、期限や梱包リストを再度確認し、それぞれの アクセス状況 確かに。サポート期間が長くても、サーバー全体の安全性が保証されるわけではありません。

CentOS 7 サーバーの実践的な導入

たとえば、CentOS 7 の Web サーバーで、古い業務用アプリケーションを一時的に引き続き実行する必要があると仮定します。その前に、 TuxCare ELS を選択することで、システムの実際の状態やアプリケーションの依存関係を把握できます。重要なのは、CentOS 7 がサポートされているかどうかだけでなく、既存のアーキテクチャに必要なコンポーネントが網羅されているかどうかです。

以下のコマンドは、サーバーのシェルで実行できます。これらは、ディストリビューション識別子、マシンアーキテクチャ、および実行中のカーネルのバージョンを読み取りますが、パッケージやパッケージソースを変更することはありません。出力結果をサーバーのインベントリに記録し、最新の CentOS 7 ガイドと照合してください。

cat /etc/os-release
uname -m
uname -r

これを補完してください サーバーの資産一覧 設定済みのパッケージソース、インストール済みのパッケージバージョン、および外部からアクセス可能なサービス。Webサーバーの場合、これには特にWebサーバーパッケージ、暗号ライブラリ、PHPランタイム、および拡張機能が含まれます。 また、サードパーティのソースに由来するコンポーネントや、独自にコンパイルされたコンポーネントについても記録しておいてください。これらは、検証なしにOSのカバレッジの一部として扱ってはなりません。

CentOS 7 については、TuxCare は有効なライセンスキー、root 権限、および HTTPS 接続を前提条件として挙げています。 また、このガイドではアーキテクチャごとに区別されています。aarch64およびi686についてはユーザースペースの対応範囲が説明されていますが、カーネルのライブパッチ適用についてはx86_64のみが対象となっています。この制限はCentOS 7のガイドに固有のものであり、他のディストリビューションに一律に適用できるものではありません。

その後、具体的な業務用途について、必要な各パッケージを最新のリストと照らし合わせて確認し、残っている不足分については各プロバイダーと調整してください。また、サポート対象の稼働中のカーネルであっても、それだけではアプリケーションがカバーされていること、あるいは利用可能なすべての更新プログラムがインストールされ有効になっていることを証明するものではありません。

リポジトリの設定とアップデートの展開

管理された環境として設備を計画する 検証チェーン: まず、ライセンス、アーキテクチャ、および必要なパッケージが適合している必要があります。その後、サーバーがそのディストリビューションに必要なHTTPS経由のターゲットにアクセスできるかどうかを確認してください。登録およびリポジトリの設定については、前提条件やターゲットアドレスが変更される可能性があるため、各ディストリビューション専用の最新の公式マニュアルに従ってください。

CentOS 7 については、TuxCare がシステムの登録、パッケージリポジトリの追加、および PGP 鍵の追加の手順を説明しています。 このリポジトリにより、適切なパッケージを入手できるようになりますが、利用可能なすべての更新プログラムが自動的にインストールされるわけではありません。設定後、リポジトリが想定通りにマウントされているか、またパッケージマネージャーが適切な更新プログラムを提示しているかを確認してください。

プロキシや、制限的な送信側ファイアウォールルールを計画に組み込む必要があります。複数のシステムがある場合は、TuxCareと調整した上で、ローカルミラーの導入を検討することも可能です。 一般的なFAQから宛先アドレスを安易に流用しないでください。公開前に、選択したディストリビューションの最新マニュアルおよび想定される運用手順と照らし合わせて確認してください。

利用可能なアップデートについては、まず、業務アプリケーションと可能な限り類似したテスト環境で検証を行ってください。 その際、アプリケーションの起動、重要な業務プロセス、およびインターフェースを検証してください。その後、運用上の承認を経て本番システムへのインストールを行います。リポジトリの有効化が成功しただけで完了とみなすのではなく、パッケージのバージョン、実施日時、および結果を文書化してください。

期待しているアップデートがまだ提供されていない場合は、以下の点も確認してください。 展開状況. TuxCareは、複数のプラットフォーム向けに更新プログラムを段階的に配布しています。安定版リポジトリでの公開後、配布まで最大14日間かかる場合があります。 必要に応じて、プロバイダーは回避策を説明しています。これを使用する場合は、各ディストリビューションおよび具体的なリリースに関する最新の指示に従い、かつ運用上の承認を得た上で行ってください。ロールアウト期間から、パッチの提供までの総所要期間が保証されるわけではありません。

また、復旧手順と適切なメンテナンス期間を確保しておいてください。ライセンスキーは、公開されたサンプルコマンド、チケット、または保護されていないログに記載してはいけません。実際の登録については、メーカーの最新の手順に従い、アクセス情報は所定の手順を通じてのみ提供してください。

メンテナンス方法の比較

TuxCare ELS とメーカーによる拡張メンテナンスのどちらを選択するかは、実際のパッケージ構成および契約条件によって異なります。 この表は事前選定の例を示すものであり、すべてのアーキテクチャやパッケージに対する一般的な保証ではありません。調査時点は2026年11月4日です。動的に変化するベンダー情報およびパッケージリストについては、公開前に再確認する必要があります。

Ubuntu 18.04の標準サポートは2023年5月に終了しました。Canonicalは、Ubuntu Proのサポート期間を2028年5月まで、また最新の「追加レガシーサポート」の概要では2033年5月までと明記しています。 TuxCareは現在、Ubuntu 18.04のELS終了日を2048年5月31日としている。これらの日付は異なるサービス内容を表しており、終了日が遅いからといって、必ずしも適切なパッケージサポートが提供されるとは限らない。

したがって、以下のものを比較してください。 保守範囲 必要な各パッケージおよび実際に採用されているアーキテクチャについて。Ubuntuの場合、特にMainおよびUniverseコンポーネント、ならびにProの条件やレガシー追加機能の有無が重要となる。また、利用可能なCVE修正プログラムをどのように確認できるか、および既存のリリース・更新プロセスが提供内容に適しているかについても確認しておくこと。

どちらの例においても、移行先は計画上の決定事項であり、保守契約の条件ではありません。 サポート対象のプラットフォーム上で業務アプリケーションがまだ実行できない場合、適切な保守の代替案を用意することで、テストを行う時間を確保することができます。いずれの提案も重要な依存関係をカバーしていない場合は、運用を継続することが正当化される前に、このギャップを別途対処する必要があります。

CVEの報告とバックポートを確認する

アップデート後もスキャナーが脆弱性を報告し続ける場合は、まず、該当するパッケージの正確なディストリビューションとバージョン、および名前、アーキテクチャ、インストールされているバージョンを確認してください。また、そのパッケージがどのパッケージリポジトリから取得されたものかも特定してください。 ディストリビューションのパッケージに関する検出結果は、自己コンパイルしたアプリケーションやサードパーティのリポジトリからのパッケージには、そのまま適用できるとは限りません。

一見矛盾しているように見える理由の一つは、 バックポート ：この場合、セキュリティ修正が古い開発段階に組み込まれるが、そのアップストリームのバージョン番号は最新のリリースと一致しない。したがって、バージョン番号が古いという事実だけでは、そのパッケージに脆弱性があること、あるいはスキャナーの警告が誤りであることは証明されない。

具体的なCVEとインストール済みのパッケージのバージョンを、TuxCare CVEトラッカーに記載されているお使いのディストリビューションの情報と照らし合わせてください。「In Testing」は修正プログラムがまだテスト中であることを意味し、「In Rollout」の場合は、ロールアウトリポジトリを通じて配布されています。 一方、「Released」は、すべてのユーザー向けに正式にリリースされたことを示します。その場合でも、適切なバージョンが実際にインストールされているかどうかを確認する必要があります。「Not Vulnerable」は、TuxCare版が影響を受けていないことを意味します。

パッケージマネージャーに期待していた更新がない場合は、パッケージのソースやバージョンに加え、 展開状況. 複数のプラットフォームが存在する場合、安定版リポジトリへの公開後の段階的な配布には、最大でさらに14日間を要する場合があります。 バイパスの実施は、最新のディストリビューションおよびリリースに関する公式の指示に従い、かつ運用上の承認を得た場合にのみプロセスに組み込まれます。これにより、パッチ適用までの総所要期間が保証されるわけではありません。

その後、スキャナーのデータベースと分析結果を確認してください。TuxCareは一連のELS製品についてOVALデータを提供していますが、お使いのツールが当該システムに適したデータを使用し、正しく解釈しているかどうかは、ご自身で確認する必要があります。パッケージのバージョン、CVEステータス、およびスキャン日時を記録してください。 照合結果が不明確な場合は、その所見を未解決として扱い、担当の専門部署またはベンダーに確認してください。

パッチ適用と再起動の計画

リポジトリの設定は、パッチ適用作業の始まりに過ぎず、その完了を意味するものではありません。誰が定期的に利用可能な更新を確認するか、誰が承認を行うか、そして更新の失敗をどのように検知するかを明確に定めてください。その際、実際にインストールされているパッケージのバージョンと利用可能な更新を照合し、各システムごとに差異を記録してください。

アップデートは、可能な限りまず、同じアプリケーションと関連するパッケージソースを備えた同等のテストシステムで試してください。特に、起動、ログイン、および業務アプリケーションの重要なインターフェースをそこで確認してください。運用上の承認を得てから初めて、パッケージを管理された形で展開してください。その結果や発生したエラーは、インストール記録に記載する必要があります。

また、変更に備えて余裕を持たせておく メンテナンス・ウィンドウ. パッケージの更新が正常に完了した後でも、実行中のプロセスは再起動されるまで古いライブラリを使い続ける可能性があります。必要に応じてアプリケーションも再起動する必要があります。カーネルの変更があった場合は、システムの再起動が必要になる場合があります。再起動後は、サービスの動作状況と、パッケージおよびシステムの動作状態が期待どおりであるかを確認してください。

KernelCare Live Patching は補完的な製品であり、通常の ELS パッケージ更新とは区別されます。これは、サポート対象のカーネル修正を稼働中に適用できますが、すべての更新や、すべてのサービスおよびシステムの再起動に取って代わるものではありません。 製品、ディストリビューション、アーキテクチャを確認してください。CentOS 7 については、TuxCare は x86_64 向けのカーネル・ライブパッチングのみを文書化しています。その他の基本事項については、以下の記事で解説しています。 KernelCare パッチフィード.

の出力は uname -r 現在実行中のカーネルは表示されますが、サーバーの更新状況の全容は表示されません。たとえば、インストールされたカーネルパッケージは再起動後に初めて有効になる場合があります。逆に、この出力からは、ライブラリやアプリケーションが更新され、再起動されたかどうかについては何も分かりません。

暫定的な解決策か、移行かを選ぶ

TuxCare ELSが特定のサーバーにとって十分かどうかは、そのサーバーの実際の構成要素とリスクによって決まります。 必要なパッケージと利用可能なサポート範囲を照らし合わせ、アプリケーション、実行環境、サードパーティ製ソフトウェアにおける未対応の脆弱性を特定してください。ELS for OSはディストリビューションに応じた範囲をカバーしており、オペレーティングシステムのサポートが、その上で動作するすべてのアプリケーションのメンテナンスを保証するものではありません。

また、対応済みのパッケージ内に残っているCVE脆弱性についても確認してください。 TuxCareによると、中程度のリスクは、パッチ適用に追加の条件が満たされた場合にのみ考慮されます。また、ベンダーは直接的なコード修正の代わりに緩和策を講じる場合もあります。したがって、具体的な脆弱性について、修正プログラムまたは緩和策が利用可能かどうか、また残存するリスクが自社の運用にとって許容範囲内であるかどうかを評価してください。

専門アプリケーションが当面は旧プラットフォームに依存しており、残存するリスクが管理可能な範囲内である場合は、暫定的な解決策が有効となる場合があります。 ただし、利用可能なベンダーによるメンテナンスも比較検討してください。Ubuntu 18.04の場合、必要なサポート範囲に応じて、Ubuntu Proや、必要に応じて「Legacy」アドオンが代替案として検討できます。単にサポート終了日だけでなく、パッケージ、アーキテクチャ、契約条件も確認してください。

管理が不十分なアプリケーションや、サポート対象外の稼働期間を持つ、一般に公開されているサービスについては、ELSだけでは不十分である可能性があります。そのため、実際に必要なネットワークやサービスへのアクセスを制限し、不要なアクセス権限を削除し、管理者アクセスを管理してください。これら ネットワークの制限 攻撃対象領域を縮小しますが、欠落しているセキュリティ更新プログラムの代わりにはなりません。

継続運用は期間限定とし、責任者と確認可能な期限を定めた移行目標を設定してください。 移行先プラットフォームでのアプリケーションテスト、データ移行、および関連するすべてのインターフェースの検証を計画してください。また、移行を中止する条件や、従来の運用に戻す方法を定めた「ロールバック計画」を策定しておく必要があります。

新しいパッケージの脆弱性、変更されたベンダー依存関係、および運用コストを踏まえて、計画を定期的に見直してください。必要なコンポーネントのメンテナンスが不可能になった場合や、必要なアクセス権限を十分に制限できない場合、単にオペレーティングシステムのサポート期間を延長するだけでは不十分な可能性があります。 その場合は、移行、アプリケーションの置き換え、または管理された廃止について、改めて検討する必要があります。