ホスティング業務におけるCageFS：顧客アカウント間のファイルシステムの分離

ホスティングアカウントに隔離が必要な理由

共有ホスティングでは、複数の顧客が同じサーバー上でウェブサイトを運営しています。アカウントAのスクリプトが侵害された場合、そのスクリプトは環境に関する情報を収集したり、他のアカウントのファイルにアクセスしようとしたりする可能性があります。これには、アクセス情報や個人データを含む設定ファイルなどが含まれる場合があります。 アカウントを分離することで、インフラが共有されているにもかかわらず、このようなアクセスを困難にすることを目的としています。

その際、以下の点が挙げられます 表示とアクセス権限 さまざまな問題があります。ディレクトリ名は表示されていても、ファイル権限によってその内容の読み取りが拒否される場合があります。逆に、閲覧制限だけでは、慎重に設定された権限の代わりにはなりません。環境内でアクセス可能なものは、引き続き適切に保護されなければなりません。

CageFS 権限に、ユーザー固有のファイルシステム環境を追加します。指定されたコンテキスト内のプロセスは、管理者と同じホストのビューを単純に取得することはできません。これにより、アカウントAのスクリプトが、他のアカウントのディレクトリを容易に探索できないようにします。実際にどの領域が表示されるかは、設定によって異なります。

事業者にとっては、これはさらなる 分離層、他の顧客への影響を一切排除する保証はありません。共有サービスにおける不具合、権限の範囲が広すぎる場合、またはサービスの統合が不完全な場合は、保護効果に影響を及ぼす可能性があります。そのため、隔離の状態は、管理画面の設定だけでなく、顧客プログラムが実際に実行されている場所で確認する必要があります。

ホスティングサービスをご利用のお客様にとっても、この区別は重要です。独自のアプリケーションが外部のディレクトリを認識しないということは、あくまでそのアプリケーションの具体的な実行環境に関する事実に過ぎません。これは、すべてのサービスの設定や、他のすべてのアカウントの保護が確保されていることを示すものではありません。全体的な設定や管理については、引き続きプロバイダーが責任を負います。

CageFSがファイルシステムのビューをどのように構成しているか

CageFSは、ユーザーに独自のファイルシステムビューを提供します。その基盤となっているのは、 スケルトン: それぞれの環境向けに用意されたファイルやディレクトリを含むテンプレート。必要な部分が組み込まれ、ユーザーのホームディレクトリもその環境に統合される。したがって、表示されるディレクトリツリーは、単にホスト側の表示をそのままコピーしたものではない。

この統合の仕組みは、あるツールを例に挙げて説明できます。管理者がホストにプログラムをインストールしても、クライアントプロセスがその環境内でそのプログラムを見つけられない場合があります。これは必ずしもインストールエラーとは限りません。プログラムはホスト上に存在していても、スケルトン内や、クライアント向けに用意された統合機能を通じて利用可能になっていない可能性があるのです。

逆に、追加で提供されるファイルは、そのプロセスが認識できる環境を拡大することになります。マウントされたディレクトリについても同様です。 したがって、運用担当者は、機能上の必要性と、それによる可視性の拡大とのバランスを考慮する必要があります。アプリケーションは特定のツールとその依存関係を必要とするかもしれませんが、必ずしもホストのディレクトリ全体を必要とするわけではありません。

仝 マウント設定 ファイルシステムのどの部分が環境内に表示されるかを決定します。しかし、プロセスが可視ファイルを読み取ったり、変更したり、実行したりできるかどうかは、これだけで決まるわけではありません。その判断には、所有権や権限なども関係してきます。したがって、可視パスがあるからといって、書き込みアクセスが許可されているとは限りません。

ホームディレクトリは、ホスティングの日常運用において特に重要です。通常、各アカウントのファイルはこのディレクトリに格納されています。 この統合により、所定のコンテキスト内でのアクセスが可能になる一方で、それ以外の表示は制限されます。ただし、特定のアプリケーションがすべての必要なファイルにアクセスできるかどうかは、その設定や実際に利用可能なパスによって異なります。

CageFS、LVE、および共通のリスク

CageFSとLVEは、それぞれ異なる問題を解決します。CageFSは、ユーザーのファイルシステムビューと実行コンテキストを構成します； LVE CPU、メモリ、入出力などのリソースを監視・制限するために使用されます。ファイルシステムへのアクセスが制限されているプロセスであっても、引き続きリソースを消費する可能性があります。逆に、リソース制限そのものは、誤って共有されたファイルへのアクセスを阻止するものではありません。

ホスティングコントロールパネルには、もう1つの役割があります。それは、アカウントの管理やCloudLinuxコンポーネントの統合などを行うことです。しかし、単にパネルをインストールしただけでは、すべてのWebプロセス、シェル、およびスケジュールされたタスクが、所定のCageFSコンテキスト内で実行されるとは限りません。 運用者は、自社の具体的なプラットフォームに適した統合方法を確認する必要があります。

CageFSは、アカウントごとに個別の仮想マシンを用意するものではありません。各アカウントは引き続き 共通カーネル また、共同で運用されるサービスに依存している場合もあります。したがって、これらの共有コンポーネントにおける脆弱性や設定ミスは、依然として脅威モデルの一部となります。ファイルシステムの分離は、可視環境の一部を縮小しますが、ホストのセキュリティ対策やメンテナンスに代わるものではありません。

適切に隔離されたアカウント内であっても、リスクは残ります。 例えば、脆弱性のあるアプリケーションが自身のデータを漏洩させたり、盗まれた認証情報によって攻撃者が当該アカウントの権限内でアクセスを行えるようになる可能性があります。CageFSは、安全でないアプリケーションコードや、そのアカウント内でアクセス可能なファイルに対する過度な権限については修正しません。

したがって、堅牢なセキュリティ戦略を構築するには、各層が適切に連携している必要があります。具体的には、アカウントとサービスを正しく統合し、ファイル権限を管理し、リソース制限を適切に設定し、アプリケーションを最新の状態に保つことです。これらによって得られる保護効果は、実際の構成や運用されているサービスによって異なります。個々のコンポーネントの名前だけでは、こうした検証の代わりにはなりません。

アカウントとウェブサイトを別々に考える

同じサーバー上に2つの顧客アカウントが存在する場合と、1つのアカウント内に2つのウェブサイトが存在する場合とは、状況が異なります。CageFSはユーザー固有の環境を提供し、それによって1つのアカウントがファイルシステムに対して持つアクセス範囲を制限します。しかし、それによって、そのアカウント内のすべてのウェブサイトが個別のファイルシステム境界を持つようになるわけではありません。

ある代理店が同一のホスティングアカウントで複数のプロジェクトを運用している場合、そのアプリケーションは実行コンテキストや権限によっては、他のプロジェクトのファイルにアクセスできる可能性があります。 したがって、攻撃者が脆弱性のあるプラグインを介してウェブサイトに侵入した場合、そのアカウント下でどの設定ファイルやアクセスデータにアクセス可能かを確認する必要があります。別の顧客アカウントとの分離だけでは、この疑問は解消されません。

よりきめ細かな ウェブサイトの分離 CloudLinuxは、CloudLinux Isolatesにより、ドメイン単位のファイルシステム分離機能を追加で提供しています。この機能が利用可能かどうかは、具体的な製品の提供状況、バージョン、およびパネルとの統合状況によって異なります。 CageFSの有効化のみに基づいてドメインの分離を推測するのではなく、ご自身のホスティング・スタックにおけるこれらの前提条件を確認してください。

ドメインごとのLVE制限も、独自の要件を持つ独立した機能です。したがって、ファイルシステムの制限が追加されたからといって、必ずしも各ドメインのCPUやメモリが個別に制限されるわけではありません。この記事について CloudLinux サイト分離 アカウントレベルとウェブサイトレベルの違いを明確にします。設定にあたっては、導入している製品バリエーションの要件が依然として決定的となります。

計画を立てるにあたっては、まず現状把握を行うことが重要です。どのサイトが1つのアカウントを共有しているか、どのファイルを共有する必要があるか、そしてどのアクセス情報を分離しておくべきか。これらを把握することで、個別のアカウントと、利用可能なドメイン単位の分離のどちらが運用モデルに適しているかを判断できます。 どちらの選択肢も、実際のアプリケーションパスを確認する必要があります。

PilotおよびCageFSのステータスを確認する

パイロット運用に先立ち、運用担当者として、導入するOSのバージョンがサポートされているか、必要なパッケージとライセンスが揃っているか、そしてコントロールパネルが適切に統合されているかを確認してください。パネルに対するサポートが文書化されているからといって、すべての機能があらゆる組み合わせで同じように動作するとは限りません。 また、選択したテストアカウントで必要なアプリケーションやツールについても記録しておいてください。

まずは、明示的に承認されたテスト用アカウントと、典型的なアプリケーションを厳選したセットから始めましょう。他のアカウントを追加する前に、それらのホームディレクトリ、必要なプログラム、および関連する実行パスを確認してください。 導入時には、CageFSを原則として無効にし、個々のアカウントごとに有効にするモードを利用できます。あるいは、原則として有効にし、例外を設定するモードもあります。

以下の読み取りコマンドは、CageFSがインストールされたシステム上で、権限を持つ管理者向けに用意されています。 TESTBENUTZER を、テスト用に承認済みの既存のアカウントに置き換えてください。必要な権限や具体的な出力内容はシステムによって異なります。これらのコマンドは設定を変更しません。

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

1つ目のコマンドはCageFSの全体的なステータスを表示し、2つ目のコマンドは 動作モード。3つ目は、選択したアカウントのステータスを照会します。モードとアカウントのステータスは併せて考慮する必要があります。原則として有効になっているモードには例外がある一方で、別のモードでは個々のアカウントが明示的に含まれる場合があります。

ステータスが「正常」と表示されたからといって、すべてのサービスが実際に想定されたコンテキストで動作しているという証拠にはなりません。そのため、管理システムが報告する内容と、テストアカウントで検証された実行パスを別々に記録してください。 その上で初めて、パイロット運用を他のアカウントに拡大できるかどうか、また運用上どのような例外措置が必要かを判断することができます。

保護アプローチの比較

これらのアプローチの違いは、主にどの境界線を引くか、そして誰がそれを管理するかという点にあります。表では、それぞれの保護目標を分類しています。運用コストに関する情報は、定性的な計画上の指針であり、測定値ではありません。具体的な要件は、各プラットフォームとその構成によって異なります。

ファイルのアクセス権と閲覧制限は、互いに置き換え可能な概念ではありません。表示されているパスであっても読み取り可能とは限らず、公開されているパスには適切なセキュリティ対策が施されている必要があります。 CageFSは、設計された環境を通じてこれらの権限を補完します。一方、LVEはリソース消費に対処するものです。両者を併用するには、両方のレイヤーを適切に設定する必要があります。

A 独自のVM ユーザー固有の環境に対して管理の境界をずらします。ゲストシステムは自身でメンテナンスする必要があり、仮想化プラットフォームへの依存状態が続きます。 別のサーバーを導入すると、共有インフラストラクチャがさらに変化します。どの方式が適切かは、脅威モデル、必要な権限、および利用可能な運用リソースによって異なります。

したがって、一律のセキュリティランキングを作成することは誤解を招く恐れがあります。その他のメカニズムやそれぞれの適用分野を比較するには、以下の概要が参考になります。 ホスティングにおけるプロセス分離。その後、具体的な検証が重要となる。どの境界線がどのアクセスを阻止すべきか、どのサービスがその境界線を越えるのか、そして誰がその設定を監視するのか。

実行パスを制御してテストする

アカウントが有効化されていても、それに関連するすべてのプロセスが実際にCageFS内で起動するとは限りません。重要なのは、それぞれの 実行パス: SSHログイン、Webサーバー、およびスケジュールされたタスクは、それぞれ異なる統合機能を利用する場合があります。そのため、運用担当者は、関連する各サービスについて、そのサービスがアカウントおよびその環境に対してプロセスをどのように割り当てているかを確認する必要があります。

管理されたテストを行うため、運用者は承認済みのテストアカウントを設定し、自社で明示的に承認されたテストファイルのみを使用します。 所定の環境内にあるファイルを使用することで、想定されるアクセスが機能するかどうかを確認できます。一方、所定のビューの外で別途用意されたファイルは、境界の検証に使用されます。他社の顧客ディレクトリは、この目的には適したテスト素材ではありません。

まず、SSH を使用して、テストアカウントが実際にどのような環境下にあるか、また、用意されたテストファイルが想定通りにアクセス可能かどうかを確認してください。次に、そのために設定された Web アプリケーションと、予定されているタスクを使用して、この確認を繰り返してください。サービスの統合方法が異なっていたり、異なるユーザーコンテキストで実行されていたりする場合、結果が異なる可能性があります。

各試行について、サービス、アカウント、パス、および結果を記録してください。 アクセス拒否は、その特定のコンテキストにおける観測された境界のみを証明するものであり、すべてのサービスの適切な分離やホスト全体のセキュリティを証明するものではありません。逆に、予期せずアクセスが成功した場合は、他のアカウントを運用に導入する前に調査を行う必要があります。

ホスティングサービスをご利用のお客様は、ご自身の実行コンテキストや共有ファイルを確認することができます。CageFSのグローバル設定、他のアカウント、およびすべてのサービスの統合については、通常、お客様ご自身で確認することはできません。 これらの事項については運営者が責任を負っています。異常が見つかった場合は、影響を受けているサービスと具体的なパスを運営者に報告してください。

不足しているツールとスケルトンのメンテナンス

ホストにツールがインストールされているにもかかわらず、顧客アカウントで見つからない場合は、まず実行コンテキストを確認してください。 SSH経由での呼び出しは、Webアプリケーションやスケジュールされたタスクと同じ環境を使用しているとは限りません。パッケージが欠落していると判断する前に、検索パスと具体的なエラーメッセージを確認してください。

その後、運営者は以下の点を調査する。 スケルトン およびマウント設定。スケルトンは、CageFS内でどのファイルやディレクトリが提供されるかを決定する要因の一つとなります。そのため、ホスト上には存在するプログラムであっても、ユーザー固有の環境には存在しない場合があります。また、必要なライブラリやその他の依存関係についても、提供時に考慮する必要があります。

実用的な解決策は、念のため大規模なホストディレクトリをマウントすることではありません。そうすると、そのタスクに必要な数よりも多くのファイルが可視化されてしまう可能性があります。その代わりに、管理者はメーカーのドキュメントを参照して必要なプログラムファイルや依存関係を選択し、その後、所定のサービスコンテキスト内でツールが正常に動作するかを確認すべきです。

宛先 スケルトンのメンテナンス また、システムパッケージやコントロールパネルの変更も考慮に入れる必要があります。CloudLinuxでは定期的な更新が記載されていますが、特定の変更を行った後には、強制的な更新が必要になる場合があります。Apacheの再構築後も、更新が必要になることがあります。ただし、これは更新のたびに同じ手動コマンドを実行しなければならないという意味ではありません。

使用しているプラットフォームに合わせて更新を計画し、その後、影響を受けるアプリケーションやツールを確認してください。以前は正常に動作していたアプリケーションが変更後に動作しなくなった場合、パッケージが変更された時期、影響を受けたサービス、および正確なエラーメッセージが、原因の特定に役立ちます。 これにより、デプロイの問題とアプリケーションのエラーを区別することができます。

安全に運用し、意識的に判断する

運用上の判断においては、CageFSが原則として利用可能かどうかだけが重要なのではありません。運用担当者は、どのアカウントやサービスを保護すべきか、それらにどのようなプログラムが必要か、そして統合や保守の責任を誰が負うかを把握しておく必要があります。この制限されたファイルシステムの可視性は、他のセキュリティ対策を補完するものであり、安全なアプリケーションやアクセス情報の保護に代わるものではありません。

特に注目すべき点は 共用エリア および追加のマウント。CloudLinuxでは、 /dev/shm ユーザーごとに、共有マウントと分離の選択肢があります。実際にどちらの方式が適用されるかは、具体的な構成に基づいて確認する必要があります。追加のマウントは、アプリケーションが必要とするもののみを提供するようにすべきです。なぜなら、それらは可視環境を拡大する可能性があるからです。

CageFSへの進入時のエラーも、セキュリティ上重要な問題となります。CloudLinuxでは、CageFS 7.2.0-1以降、このようなエラーが発生した際にプロセスの実行を阻止できるオプションがドキュメントに記載されています。 このオプションの存在だけで、特定のホスティングサービスにおける動作を推測するのではなく、インストールされているバージョンと実際の設定を確認してください。

スケルトン、マウント、またはアカウントの割り当てに関する変更は、調整済みの 保守手順。その際、再マウントの可能性、影響を受けるアプリケーション、およびメンテナンスウィンドウを考慮に入れ、問題が発生した場合に変更を元に戻す方法も文書化してください。その後、関連する実行パスと必要なツールを、用意されたテストアカウントを使用して再度確認する必要があります。

顧客にとって重要なのは、プロバイダーが実際にどのような分離を実施しており、それをどのように検証しているかという点です。 一方、事業者は、保護の必要性と継続的な運用コストを総合的に考慮しなければなりません。環境の提供範囲が広すぎれば分離が弱まり、狭すぎれば必要なアプリケーションの運用に支障をきたす可能性があります。いずれの場合も、慎重な設定と定期的な検証が求められます。