大規模なホスティングインフラ向け「KernelCare ePortal」

KernelCare ePortalをフリート運用に組み込む

KernelCare ePortal これは、大規模なLinux環境におけるKernelCareエージェント向けの、自社運用型の管理・配布コンポーネントです。パッチセット、フィード、登録キーを、管理された一元的な場所に集約します。 これにより、運用担当者は、ホストがパッチを取得するかどうかを決定するだけでなく、どのローカルソースから、どのような承認ロジックに基づいて取得を行うかも決定できます。.

ePortal を使用しない場合、エージェントは TuxCare のインフラストラクチャに直接接続します。これは、小規模で、ほぼ均一かつインターネット接続可能なサーバー環境においては、たいていより簡単な方法です。追加の中央プラットフォームを更新、セキュリティ対策、監視する必要がないからです。 しかし、システム数が増加するにつれ、追跡可能なアクセス許可やネットワークへの出力制限が必要となる場合、この簡便さはむしろデメリットとなります。.

ホスティング環境では、異なるディストリビューションやカーネルシリーズを搭載したWebサーバー、データベースサーバー、仮想化ホスト、管理システムが混在することがよくあります。重要な パッチの入手 これにより、これらの技術グループに適切なフィードやキーを的確に提供することが可能になります。したがって、ePortalはKernelCareエージェントの代替となるものではなく、パッチセットの取得機能にローカルでの制御および配布機能を追加するものです。.

したがって、メリットは単にサーバーの数だけで決まるわけではない。 決定的な要素となるのは、パッチ適用サイクル、検査および証明義務、ネットワーク仕様、そして中央集約型サービス自体が確実に運用できるかどうかという点である。これらの要件によって、ローカルミラーリング、キャッシュ、あるいは直接取得のいずれが適切なアーキテクチャであるかも決まる。.

ライブパッチング、KernelCare、LibCareの区別

時点では ライブパッチ KernelCareエージェントは、適切なパッチセットが利用可能かどうかを定期的に確認します。エージェントはそれらをダウンロードし、検証した後、実行中のカーネルにインストールします。 これにより、カーネルの再起動を必要とせずにセキュリティ修正を有効にすることができます。適用可能なパッチセットは、インストールされているカーネルおよびサポートされているディストリビューションによって異なります。.

KernelCareとは、ライブカーネルパッチを提供するサービスを指します。LibCareはこれとは区別されるものであり、特定のユーザースペースコンポーネント向けのオプションの追加製品であり、カーネルパッチングの別名ではありません。 一方、ePortal自体はカーネルに直接パッチを適用するものではなく、ローカルのエンタープライズ環境において、パッチセットやフィードの管理、およびKernelCareエージェントの登録を管理するものです。.

旧名称「KernelCare Plus」は、古いドキュメントを分類する際のみ使用されるべきものです。 メーカーは2023年3月をもって本製品の販売を終了し、「KernelCare」に置き換えました。したがって、現状把握を行う際には、インストール済みのエージェント、契約、およびドキュメントについて、過去の製品名に基づいて現在のコンポーネントや機能範囲と同一視しないよう注意が必要です。.

ライブパッチングは、完全なメンテナンスプロセスの代わりにはなりません。計画的な リブート 定期的なカーネルの切り替え、ハードウェアやファームウェアのアップデート、ドライバの変更、設定作業、あるいはライブ環境では修正できないエラーの調査などには、依然として再起動が必要となります。したがって、運用コンセプトにおいては、再起動を無条件に廃止するのではなく、パッチセットによるリスク露出期間の短縮と、引き続き計画された再起動枠を組み合わせるべきです。.

集中型パッチ管理が経済的に適しているのはいつなのか

ePortalは、企業がパッチを単に迅速に配布するだけでなく、その展開を厳格に管理する必要がある場合に適しています。これには、例えば、Canaryホスト、ステージング、本番環境ごとに別々のリリースグループを設定すること、厳格なアウトバウンドファイアウォールルール、あるいはどのホストがどのフィードに割り当てられていたかを証明することなどが含まれます。 また、さまざまなプラットフォームを併用する多くのシステムにおいても、一元的に管理される配布インスタンスの恩恵を受けることができます。.

追加の利点は、そのコストに見合うものでなければなりません。ePortalインスタンスには、容量、アップデート、バックアップ、アクセス保護、監視が必要です。高可用性を確保する場合は、レプリケーションとネットワークアーキテクチャも追加されます。 インターネットへのアクセスが許可された少数の同種サーバーについては、TuxCareのインフラストラクチャを介して直接利用した方が、多くの場合、より簡便です。コンポーネント数が少なければ、自社で管理すべき運用範囲も小さくなります。.

経済的な観点から、集中管理が特に有効となるのは、予期せぬ同時アクセスが発生するとコストが高くなってしまう場合です。例えば、多数の顧客向けWebサーバー、データベースクラスター、あるいは仮想化ホストなどが挙げられます。 リリースプロセス そうすることで、技術的な類似性とビジネスリスクを同時に把握できるようになります。グループ分けは、拠点だけでなく、ディストリビューション、カーネルシリーズ、ハイパーバイザー、コントロールパネル、ハードウェア、顧客プロファイルも考慮して行うべきです。.

その際、セキュリティ対策の効果を過大評価してはなりません。KernelCareは、原則として、当該カーネルシリーズのディストリビューション提供者がセキュリティアップデートを公開している期間に限り、そのカーネル向けのライブパッチを提供します。また、ライブパッチ適用は、すべての脆弱性が修正されたことを一律に証明するものではありません。 パッチの適用状況、ディストリビューションのサポート状況、および定期的なメンテナンスについては、それぞれ個別に確認する必要があります。.

したがって、運用上の判断は「中央集権型の方が良い」という一概なものではありません。ePortalは、ローカルでの管理、段階的な分散、および信頼性の高い追跡可能性といった具体的な要件を満たす場合に有効です。これらの要件がない場合、意図的にシンプルに設計された直接アクセスの方が堅牢である可能性があります。 次のステップでは、希望する提供モデルによって、ストレージ要件や外部への依存関係が決まります。.

ミラーリングとキャッシュを適切に選択する

配布モデルの選択によって、ホスティング・フリートがパッチの取得においてどの程度独立しているか、またそのためにどの程度のインフラを運用する必要があるかが決まります。 ダイレクト取得の場合、KernelCareエージェントはTuxCareのインフラを介してパッチセットをダウンロードします。一方、ePortalは、リリース、ローカルでの保持、および配布を独自のインスタンスに移行します。ePortalは、パッチセットを完全なアーカイブまたはフィルタリングされたアーカイブとしてミラーリングしたり、必要に応じて一時保存したりすることができます。.

フルミラーリングは、すでに取り込まれたパッチセットを、外部接続が切断された場合でもローカルで利用可能にしておく必要がある場合や、内部の必須承認要件でそれが求められている場合に有効です。 フィルタリングされたミラーリングは、アーカイブのサイズとデータ転送量を、実際に使用されているディストリビューションに限定します。そのためには、インベントリが、その環境で使用されているカーネルシリーズやアーキテクチャを確実に把握している必要があります。そうしないと、ホストがアーカイブを必要とするまさにその瞬間に、そのアーカイブが欠落してしまうことになります。.

仝 キャッシュモード メモリを節約できますが、完全に隔離された運用を意味するものではありません。ePortalはメタデータを読み込み、必要に応じてソースからパッチのバイナリデータを取得します。ドキュメントによると、ダウンロードされたバイナリデータはローカルキャッシュに2週間保持されます。 ePortalが許可されたアップストリームパスを使用できる限り、隔離されたエージェントネットワークにとってはこれで十分である。.

完全にエアギャップ環境で稼働するePortalサーバーについては、これとは別に評価する必要があります。その場合、新しいパッチアーカイブは、別途計画された手動転送によって導入する必要があります。 そのために、ソース検証、整合性および署名のチェック、メディアまたはネットワークへのアクセス許可、インポート順序、および責任の所在を定義する必要があります。フィルタリングされたミラーリングも完全なミラーリングも、このプロセスを自動的に生成するものではなく、ePortalがローカルに保持するアーカイブを決定するに過ぎません。.

ストレージの計画は、現在のアーカイブのサイズだけで終わらせてはなりません。TuxCareは、ePortalについて、少なくとも100 IOPSのSSDストレージと、月あたり約4～5 GiBの成長率を目安として挙げています。 ただし、これらのメーカー仕様は容量計画の代わりにはなりません。リカバリ目標、並行展開、ネットワーク遅延、カーネルバリエーションの数、および監視要件は、空きディスク容量よりもアーキテクチャに大きな影響を与える可能性があります。.

ホスティング・フリート用のパッチリングを構築する

パッチリングは、中央で管理されるパッチセットを用いて、制御されたロールアウトを実現します。まず小規模なカナリーグループに承認が下り、次にステージング、限定された本番環境グループ、そして最後に本番環境全体へと順次展開されます。 各リングには、事前に定義された監視項目と責任部署が必要です。これらの基準がなければ、遅延はリスクを評価するのではなく、単に先送りするだけになってしまいます。.

生産リングについては、 Stable 予定されているチャネルです。「Testing」は、利用可能なすべてのパッチセットを含んでおり、まだ「Stable」としてマークされていない追加のパッチセットが含まれている可能性があるため、個別の、意図的に管理された評価プロセスに適しています。ドキュメントによると、「Unstable」は早期アクセス用のチャネルであり、推奨されていません。 したがって、TestingおよびUnstableは、一般的な本番環境での運用実績として扱うべきではありません。.

リングは、データセンターの立地だけでなく、技術的な類似性に基づいて構成されるべきです。 重要な要素としては、ディストリビューションとカーネルシリーズ、ハードウェアプラットフォーム、仮想化技術、コントロールパネル、Webサーバースタック、および顧客プロファイルが挙げられます。異なるカーネルシリーズや仮想化技術を採用したカナリアホストでは、本番環境のターゲットシステムの挙動を十分に再現することはできません。共有ホスティングの場合、リソースプロファイルや設定の CloudLinux LVE マネージャー この評価に含めるのは、これらが負荷状態や故障モードに影響を与える可能性があるためである。.

特に新しいePortalインスタンスには注意が必要です。メーカーの仕様によると、ePortalは10分ごとに新しいパッチセットの有無を確認してダウンロードしますが、それらを自動的にすべてのフィードに提供することはありません。アーカイブが初めて読み込まれる際、そこに含まれるパッチセットにはすべて同じ公開日時が割り当てられます。 そのため、あらかじめ設定された遅延時間が経過すると、初期データ全体が自動的に更新されるフィードに反映されてしまう可能性があります。.

したがって、初期同期中は、本番フィードおよびその本番キー割り当ての自動更新を保留してください。初期データを完全に読み込み、そのデータとフィード設定を確認した上で、キーを所定のリングに慎重に割り当てるか、自動更新を有効にしてください。 この遅延ロジックは、その後新たに到着するパッチセットに対して機能するものであり、新しいインスタンスの過去の初期データセットを確実に分離するものではありません。.

フィード、キー、およびクライアントを分離する

フィードは、ロールアウト・リングの技術的な側面を構成しています。フィードは、パッチチャネルと遅延ロジックを、一連のシステムに接続する役割を果たします。 登録キーをフィードに紐付け、サーバー制限を設定することができます。これにより、運用担当者は、各ホストのエージェント設定を個別に変更することなく、社内プラットフォーム、マネージドサーバーサービス、および分離された顧客環境などに、それぞれ異なるリリースパスを割り当てることが可能になります。.

ただし、この割り当ては完全な安全限界ではありません。オプション機能である 事業部門 ePortalではマルチテナント機能をサポートしていますが、ネットワークのセグメンテーションや権限モデル、あるいは管理責任の分離に代わるものではありません。また、ログ記録、シークレット管理、および鍵の作成やフィードの変更を許可されるユーザーの確認についても、製品の機能とは独立して計画し、定期的に監視する必要があります。.

クライアント環境においては、パッチ管理とその他のホスティング分離を明確に分けることが特に重要です。 キーを使用することで、意図したフィードの割り当てや登録可能なサーバーの数を制限することはできますが、他のインフラストラクチャコンポーネントへの横方向のアクセスを防ぐことはできません。プロセスおよびファイルシステムの分離は依然として別個の課題であり、これについては以下の記事で補足されています。 CloudLinux SecureLVE アカウントおよびウェブサイトのレベル。.

ePortal 2.14-1 以降では、パブリック API に対して、ベーシック認証の代わりに API キーを使用できるようになりました。 ePortalの管理機能では、APIキーについて、個別に無効化可能なキーやオプションの有効期限の設定などが可能です。これにより、関連するユーザーアカウントの権限を意図的に制限する場合、CMDB接続や構成の自動化に対して個別の権限設定を容易に行うことができます。.

トークンは、プレイブック、イメージ、シェル履歴、チケットではなく、シークレット管理システムにシークレットとして保存してください。これは運用上のセキュリティ対策であり、ePortalによって自動的に強制される機能ではありません。 実用的なプロセスでは、各キーに対して、所有者、目的、許可される製品、サーバー制限、およびローテーション日を割り当てます。.

システム変更、役割の変更、または自動化アクセスが不要になった場合は、APIキーを適切に無効化する必要があります。登録キーについては別の扱いとなります。ドキュメントによると、この種のキーを削除すると、そのキーに登録されているすべてのサーバーがePortalから削除されます。 そのため、削除を行う前に、新しいキーへの移行または対象ホストの再登録を計画し、その後、それらのフィードの割り当ておよびチェックインステータスを確認してください。.

レプリケーションとTLSを堅牢に運用する

の場合 高可用性を備えたパッチ配布 複数のePortalノードを組み合わせ、KernelCareエージェントが共通のクラスターDNS名またはHTTPロードバランサーにアクセスできるようにします。 一方、管理作業を行う際は、制御されたノード固有の管理用エンドポイントを使用します。メーカーの指示によると、ePortal管理インターフェースでの操作には、この共通のクラスターエンドポイントを使用してはなりません。.

本番運用開始前には、アーキテクチャにおいてePortalサーバーの障害のみを考慮すべきではありません。DNS解決、ロードバランサー、証明書、パッチアーカイブの保存場所、パッチソースへの接続、およびあらゆるネットワークセグメントからの到達可能性も重要な要素となります。 ネットワークおよび運用監視が適切に調整されていないセカンドノードは、可用性の向上に限りがあるだけでなく、障害発生時には異常な状態を隠蔽してしまう可能性さえあります。.

ノードはレプリケーションによって変更を同期させます。この同期は、必ずしも即座に反映されるとは限りません。特にラウンドロビン方式の場合、登録されたばかりのエージェントが、登録のために最初のノードにアクセスした後、直後にまだ同期されていないノードにアクセスして更新を行う可能性があります。 したがって、自動化処理では、直後に続くパッチの取得を確実な最終状態として扱うのではなく、短い待機時間または再試行回数に制限を設けたロジックを組み込むべきです。.

長期間の切断も障害シナリオに含まれます。ドキュメントによると、レプリケーションログは7日間保持されます。ノードの切断状態がそれより長く続くと、そのノードは変更内容を反映し損ねる可能性があります。その レプリケーションの遅延 これは単なる診断値ではなく、運用上のステータスである。したがって、ネットワーク障害が発生した後は、復旧したノードが通常通りエージェントの要求に応答し始める前に、そのノード上のフィードの割り当て、キーの在庫、およびパッチアーカイブを確認する必要がある。.

レプリケーションはHTTPを介して行われます。したがって、適切なTLSによる保護が施されていない場合、レプリケーションデータは暗号化されずに送信されます。このデータ通信を、少なくとも信頼できるネットワーク内に区画化するか、アーキテクチャに合わせてTLSを適切に適用してください。 外部またはネットワークを跨いでアクセス可能なエージェントエンドポイントについては、検証可能な証明書チェーンが重要な構成要素となります。 TLSの終了; 証明書の検証を無効にすることは、正当な恒久的な解決策とは言えません。.

ePortal の前にリバースプロキシが配置されている場合、ePortal がホストヘッダーの要求を制限できるよう、許可されるホスト名を設定する必要があります。また、プロキシは元のホストヘッダーおよび X-Forwarded-Proto を正しく転送する必要があります。 そうしないと、誤った外部URL、リダイレクトの問題、または使用されているプロトコルの誤った判定が発生する可能性があります。したがって、このヘッダー設定は、プロキシの変更およびその検収のたびに必ず実施する必要があります。.

ログの記録、バックアップ、および監視体制を確立する

管理可能なライブパッチ適用には、初回インストールが成功しただけでは不十分で、定期的な確認が必要です。少なくとも、各ホストのフィード割り当て、最新のエージェントチェックイン、報告されたパッチ適用状況、および登録キーのステータスを記録してください。 さらに、これらのデータに担当チームおよび追跡可能な承認決定を追加してください。そうすることで、セキュリティアラートが発生した際に、どのグループがどの展開経路を使用しているかを的確に特定できるようになります。.

その他の定期的なチェックとしては、ストレージの増加状況、アーカイブ用の空き容量、レプリケーションの状態、および不要になったキーのローテーションや無効化などが挙げられます。 APIキーは、個別に管理・失効させることができ、必要に応じて有効期限を設定することもできるため、共有された管理者パスワードよりも自動クエリに適しています。運用上のセキュリティ対策として、イメージ、プレイブック、チケットではなく、シークレット管理システムに保存してください。.

既存のクラスターに対しては、以下の非破壊的な検査呼び出しが、モニタリングや計画的なヘルスチェックに適した構成要素となります。これにより、レプリケーションの遅延を含む、機械可読な簡易ステータスが得られます。 問題が発生した場合、呼び出しは終了コード 1 で終了します。モニタリングシステムはこの状態をアラートとして通知すべきですが、ノードおよびネットワークデータに基づいて原因をさらに絞り込む必要があります。.

kc.eportal replication --short-status

ePortalでは、データバックアップのアーカイブ処理と、純粋なデータベースバックアップを区別しています。完全なコマンド構文は次のとおりです。 kc.eportal backup <path_to_archive>; パッチセットファイルを含むバックアップアーカイブを作成します。 kc.eportal backup-db <path_to_backup> これに対し、パッチセットファイルなしでデータベースのみをバックアップすることになります。この2つ目の方法は、構成データやサーバーデータには適していますが、ローカルでのパッチのアーカイブには適していません。.

これらのePortalバックアップには、環境全体が自動的に含まれるわけではありません。 OSの設定、リバースプロキシおよびロードバランサーの設定、TLS証明書と秘密鍵、DNS設定、ならびに外部ファイアウォールやシークレット管理の設定については、それぞれ個別のバックアップおよび復元ルールが必要です。 バックアップの種類ごとに、目的、保存期間、保存場所、および復元手順を定義してください。.

復旧作業を行う際は、ePortalサービスを停止する必要があります。このサービス停止を事前に計画し、必要に応じて影響を受ける運用チームに通知した上で、復旧後にデータの整合性およびエージェントからのアクセス状況を重点的に確認してください。バックアップは、計画的に管理された手順を経て初めて有効となります。 リストア 耐障害性がある。その際、テストによって、本番のフィードやキーの割り当てが誤って変更されてはならない。.

故障パターンと運用判断の評価

予定されていたパッチが配信されない場合、まずは「利用不可」「取得不可」「リリース未完了」の3つのケースを区別する必要があります。インストールされているエージェントおよびePortalのバージョン、割り当てられたキーとフィード、該当するディストリビューション（カーネルシリーズを含む）、およびパッチソースへの接続を確認してください。 また、当該カーネルシリーズがディストリビューションプロバイダーからセキュリティ更新プログラムの提供を終了している場合、パッチが存在しないことがあります。ライブパッチ適用を行っても、この制限は解消されません。.

旧式のコンポーネントに関する過去のメーカーからの通知は、恒久的なバージョン指定として解釈してはなりません。2025年12月の通知では、新しい署名付きパッチ形式に関連して、KernelCare-Agent 3.x や ePortal 2.20 などが対象となっていました。そのため、更新を行う前には、最新の 互換性マトリックス, 、実際にインストールされているバージョン、および社内で承認されたアップデートの順序。.

キャッシュモードでは、外部へのアクセスが制限されている場合、キャッシュミスにより、必要なバイナリファイルがまだローカルに存在しないため、パッチの取得が遅れる可能性があります。これは、完全に隔離された運用が行われていることを示すものではありません。 制限のあるゾーンについては、どの接続が許可されるか、欠落しているアーカイブがどのように転送されるか、そしてその転送の承認、完全性、およびタイミングについて誰が責任を負うかを明確に定義してください。.

もう1つの不具合として、新しいインスタンスでパッチアーカイブを初めてダウンロードした後、予想以上に広範囲に展開されてしまうケースがあります。初めて読み込まれたアーカイブは、遅延ロジックにおいて同時に新規として認識されるため、事前に設定された遅延時間では、一括展開を確実に防ぐことができません。 初期同期中は、フィードの自動更新や本番環境向けのキー割り当てを保留し、初期状態を確認した上で、その後、管理された状態で本番環境のリングを有効にしてください。.

ノードの長期停止によるレプリケーションの遅れと、リバースプロキシの不具合には、それぞれ異なる対応策が必要です。前者はノードの状態の同期が必要であり、後者はTLS、許可されたホスト名、および転送されたヘッダーの確認が必要です。いずれの場合も、明確なエスカレーション手順を定めたランブックに盛り込む必要があります。 一律に再起動を行っても、データの欠落や不適切な信頼境界は解決されません。.

ePortalは、パッチリング、ローカル配布、管理されたネットワーク出力、あるいは検証可能な承認が実際に求められる場合に特に有用です。小規模で均質、かつインターネット接続可能なサーバー環境の場合、TuxCareのインフラを介した直接的な取得の方が、多くの場合、より簡単です。 したがって、決定にあたっては、サーバーの数だけにとどまらず、追加の運用負担と、具体的な管理・証明義務とのバランスを慎重に検討する必要があります。.