セキュリティ

CloudLinuxのサイト分離機能：共有ホスティングにおいてCageFSよりも高いセキュリティを実現

サイトの分離 CloudLinuxは、1つのアカウント内の個々のウェブサイトを、以下よりも厳格に分離します CageFS これにより、共有ホスティングにおけるマルチサイトインストールで頻繁に発生する課題を解決します。ここでは、その違いや、日常的な運用におけるセキュリティ上のメリット、そしてこの機能を効果的に活用するための具体的な手順について解説します。.

中心点

微細粒子の断熱: ドメイン単位での分離により、1つのアカウント内での「浮気」が防止されます。.
分離されたプロセス: サイトごとに独自のPHPコンテキストを設定すると、ラテラル・ムーブメントが難しくなる。.
クリーンなCronバインディング: ジョブは、それぞれのドメインのドキュメントルートに紐付けられています。.
多層保護: CageFSはアカウントを分離し、Site Isolationはアカウント内のウェブサイトを分離します。.
計画可能なリソース: LVEリミットは負荷のピークを抑制し、応答時間を確保します。.

CageFS 対サイト分離：アーキテクチャの比較

と一緒に CageFS あるアカウントからは、自身のファイルと整理されたシステムパスしか表示されず、他者のプロセスは表示されないため、意図的な情報収集が大幅に制限される。その サイトの分離 より詳細なレベルで制御を行い、ドメインまたはサブドメインごとに、同一アカウント内のファイルやプロセスに対する独自のビューを作成します。これにより、侵害されたインストール環境は、たとえ同じログイン情報下にあっても、隣接するプロジェクトへの直接アクセスを失うため、横方向の移動が著しく困難になります。技術的な詳細を知りたい方は、以下の CageFSファイルシステム適切な比較基準を素早く見つけられる。セキュリティと運用の観点から見ると、ドメインレベルでの分離は 決定的な 役割。.

なぜこの追加のレイヤーが重要なのか

多くの代理店は複数のものをまとめています ワードプレス管理や請求処理が簡素化されるため、1つの大規模なアカウントに複数のサイトをまとめています。しかし、ドメインレベルで分離していない場合、古いインスタンスが隣接するプロジェクトの設定ファイルやパスを閲覧できてしまうため、リスクが大幅に高まります。まさにこの点で、 サイトの分離 …し、攻撃対象範囲を各ドキュメントルート内に厳密に限定します。これにより、個々のプロジェクトに脆弱性が生じたり、プラグインにセキュリティ上の穴が発見されたりした場合でも、波及被害を最小限に抑えることができます。このきめ細かな範囲設定により、隣接するプロジェクトに被害が及ぶことなく、影響を受けたサイトを強化するための時間を確保できます。.

管理者の日常業務：ドメインごとの分離、独自のPHPコンテキスト

起動させる断熱ドメインまたはサブドメインごとに個別に設定し、特にリスクの高いCMSインスタンスをより厳密に隔離します。 PHPハンドラー、FPMプール、およびini設定は個別に実行されるため、侵害されたコードが他のサイトのプロセスを読み取ることを防ぎます。Cronジョブは自動的にそれぞれのドキュメントルートに紐付けられるため、スクリプトが意図せず他のディレクトリにアクセスすることを防ぎます。切り替えの際、CloudLinuxは影響を受けたドメインの古いプロセスを順序立てて終了させ、隔離されたコンテキストで再起動します。これにより、リクエストは直ちに新しい保護層を通過することになります。このプロセスにより、サービスの中断を最小限に抑え、アカウント内の他のプロジェクトに影響を与えないため、運用が著しく より安全 はしません。

相互作用：CageFS、シンボリックリンク保護、およびLVE

CageFS アカウント同士を分離する「シェル」が残り、サイト分離は同一アカウント内のプロジェクト同士を互いに切り離します。シンボリックリンク保護とカーネルメカニズムにより、シンボリックリンクやパスに基づく手法を用いた典型的な迂回攻撃を排除します。これらの層は相互に連携しており、攻撃者が脆弱なサイトから次の脆弱なサイトへと移動することを困難にしています。これにより、私には二重のメリットがあります。一方で攻撃対象領域が縮小され、他方で保守作業の範囲が明確に限定されるのです。このように、このセキュリティモデルは、調和のとれた 多重システム 単一の措置の代わりに。.

攻撃シナリオ：実運用における隔離措置の効果

「会う」は時代遅れ プラグイン 書き込み可能なパスにアクセスできる場合、何らかの隔壁がなければ、ウェブシェルはすぐにファイルシステムに侵入し、設定情報を盗み出してしまう。サイト分離機能により、アクセスはドメインルートに制限されるため、隣接サイトへの移動が阻止され、盗まれた認証情報の悪用も抑制される。また、多数のクライアントプロジェクトを抱える代理店アカウントでは、この分離により、さもなくば足掛かりとなってしまうバックドアも阻止されます。さらに、許可されるパス範囲が狭くなるため、過度に寛容なバックアップスクリプトのような設定ミスの発生も抑制されます。 クリア と定義されています。これにより、被害の範囲が「アカウント全体」から「サイト内」へと限定され、対応時間とフォレンジック調査が簡素化されます。.

性能と信頼性：リソースを明確に分離

多くの人は、CloudLinuxを主に保護, 、しかしこの分離は、応答時間や計画性において具体的な効果をもたらします。CPU、RAM、I/O、およびプロセスに対するLVEリミットを設定することで、個々のサイトがリソースをすべて使い果たして近隣のサイトの動作を遅らせることを防ぎます。これにより、セキュリティを緩めたり、サーバーの他の部分を危険にさらしたりすることなく、プロジェクトごとの負荷のピークを吸収することができます。これと組み合わせて cgroup v2 リソースを明確な基準に基づいて配分し、ボトルネックをより透明性を持って把握しています。この仕組みにより、特に高頻度な処理において、予測可能なパフォーマンス値が得られます。 ＣＭＳ‑設備。.

実装の詳細：手順と検証チェック

実際には、切り替えをスムーズに行い、予期せぬ影響が生じないように、明確な手順を定めておくことが有効です。私は次のように進めています：

プロジェクトの確認：各ドメイン／サブドメインには、書き込みパスが重複しない一意のドキュメントルートが割り当てられます。.
バックアップとステージング：有効化する前に、ファイルとデータベースをバックアップし、ステージングコピーで隔離環境の動作を確認します。.
ドメインごとの分離を有効にする：コントロールパネルに応じて、サイトを専用のPHP-FPMプールに移行し、ini設定値を分離します。.
Cronジョブの再設定：Cronジョブはそれぞれのドキュメントルートから実行し、プロジェクト固有のパスだけを使用するようにしています。.
シンボリックリンクの管理：プロジェクト間のシンボリックリンクを削除するか、どうしても必要な場合に限り、読み取り専用リンクに置き換えます。.
グレースフル・リスタートの確認：切り替え後、古いプロセスが終了し、新しいプロセスが正常に起動したことを確認します。.
スモークテスト：各隔離されたコンテキストにおいて、ログイン、キャッシュ、ファイルのアップロード、Webhook、およびCLIタスク（例：wp-cli）を確認します。.

重要なのは、書き込み用のパス（アップロード、キャッシュ、セッション、tmp）をサイトごとに厳格に分離することです。共有の「assets」フォルダは便利ですが、分離性を損ない、フォレンジック調査を困難にします。.

権限とパス構成：サイトを明確に分離する方法

よりきめ細かな分類には、明確なファイル権限と一貫性のあるパスが不可欠です。私は以下の原則を重視しています：

Document-Root を境界とする：アプリケーションは、そのルートパス内でのみ書き込みを行うことができる。.
最小限の権限：ディレクトリ 750/755、ファイル 640/644 – 技術的に必要な場合のみ特別な権限を付与する。.
設定ファイルのセキュリティ強化：wp-config.php などのファイルに厳格なアクセス権限を設定し、可能であれば Web ルートから（サイトコンテキスト内へ）移動させる。.
サイトごとの一時パス：ドメインごとに独自の tmp および session ディレクトリを設け、それぞれのコンテキスト内に配置する。.
共有ベンダーは使用しない：複数のプロジェクトにまたがるComposerの「vendor」ツリーの共有は、一貫して避けている。.

さらに、サイトごとのini設定は厳格に管理しています。open_basedir、upload_tmp_dir、disable_functionsについては、グローバルな妥協案を採用するのではなく、プロジェクトごとに個別に設定しています。.

WordPress、TYPO3 など：プロジェクトごとの注意事項

CMSスタックの場合、いくつかの点に注意すれば、そのメリットがすぐに明らかになります：

WordPress：ジョブがサイトコンテキストで実行されるように、Cronを本家のシステムCronに切り替える。また、ドメインごとに個別にwp-cliを使用する。.
マルチサイト／ネットワーク：サブサイト間のファイルベースの相互参照は避けています。メディアのオフロードや専用のバケットの方が信頼性が高いです。.
TYPO3/Drupal：書き込みパス（var、public/fileadmin、sites/default/files）を厳格に分離し、プロジェクトごとに設定インクルードファイルを管理する。.
キャッシュ/OPcache：各サイトごとに、独自のOPcacheメモリを持つ個別のFPMプールを使用し、ウォームキャッシュが互いに影響し合わないようにする。.
デプロイ：プロジェクトごとにビルドアーティファクト（Composer、Node）を生成する。共通のビルドディレクトリの使用は避ける。.

特にモジュール化が進んだプロジェクト（「ヘッドレス」、複数のフロントエンド）では、境界を意図的に設定するようにしています。各フロントエンドを、明確なインターフェースを備えた、独立したコンテキストに配置するのです。.

監視とフォレンジック：サイトごとの可視性

ドメインごとにログや指標を管理しておくと、トラブルシューティングがしやすくなります：

サイトごとのエラーログおよびアクセスログ：4xx/5xxエラーの急増を特定のプロジェクトと明確に結びつける方法。.
PHP-FPMのスローログ：他のインスタンスからのノイズを排除し、サイトごとに処理速度の遅いスクリプトを特定する。.
LVEメトリクス：サイトごとのCPU、IO、EP（エントリープロセス）、NPROC、メモリを監視し、リミット超過を早期に検知する。.
アラート設定：プロジェクトごとに閾値を設定し（例：短時間に多数の503/508エラーが発生した場合など）、的確に対応できるようにする。.
アーティファクトの収集：インシデント発生時には、影響を受けたサイトルートのみを確保するようにしています。これにより、分析が迅速化され、データの影が軽減されます。.

境界線が明確であるため、証拠や侵害の兆候（Indicators of Compromise）をより迅速に特定し、より的確に対策を講じることができます。.

サイトごとのパフォーマンスチューニング：プールと制限の微調整

分離されたプールは、セキュリティ面だけでなく、チューニングの手段でもあります。私はプロジェクトごとに次のように調整しています：

pmモード：トラフィックプロファイルに応じて「ダイナミック」または「オンデマンド」を選択。バースト負荷に対しては、適度な余裕を持たせて吸収する。.
max_children：グローバルな一律値ではなく、サイトの同時リクエスト数とメモリ使用量の上限に紐づける。.
OPcacheのサイズ：サイトのウォームセットを考慮する。キャッシュが小さすぎると、断片化やコールドスタートが発生する。.
タイムアウト：各サイトごとに、アップストリームサービス（API、DB）の接続／読み取りタイムアウトを調整し、応答停止を防ぐ。.
スタティック・オフローディング：静的アセットを確実に配信（例：Webサーバーのキャッシュ）することで、PHPプールの負荷を軽減する。.

その結果、各サイトごとのトラフィックのピークを吸収しつつ、近隣サイトへの影響を最小限に抑える構成が実現されます。これにより、応答時間が安定し、予測可能になります。.

制限事項、副作用、トラブルシューティング

隔離は責任の所在を変化させる――これは意図されたことだが、注意を要する：

共有リソース：特別な設定を行わない限り、複数のサイトにまたがる中央のアップロードまたはバックアップディレクトリは、意図的に機能しなくなりました。.
レガシースクリプト：絶対アカウントパスを前提としている古いデプロイまたはメンテナンススクリプトについては、サイトルートに合わせて修正します。.
インポーター／エクスポーター：サイト境界を越えてアクセス可能なツールは、置き換えるか、ドメインごとに厳格に運用する必要があります。.
エラーメッセージ：503/504 は、多くの場合、プールの枯渇やアップストリームのハングアップを示しています。508 は、サイトの LVE 制限に達したことを示しています。.
ロールバック：サイトごとに独立したバックアップを用意し、副作用のない復元テストを行っています。.

プロジェクトで意図的にデータを共有する必要がある場合は、パス経由での直接的なファイルアクセスではなく、明確に定義された読み取り専用インターフェースを設計するようにしています。.

有効化前のチェックリスト

各ドメイン／サブドメインには、外部からの書き込みアクセスができない一意のドキュメントルートが設定されていますか？
Cronジョブ、CLIツール、およびデプロイスクリプトは、サイトパスに変更されていますか？
書き込みパス（アップロード、キャッシュ、tmp、セッション）はサイトごとに分離されていますか？
サイトごとにFPMプール、ini値、OPcacheのサイズが定義されていますか？
プロジェクトごとに、データベースを含む、機能テスト済みのバックアップは存在しますか？
サイト間のシンボリックリンクやインクルードは削除されたか、あるいは読み取り専用に制限されていますか？
サイトごとのエラー率やリソースに関するメトリクスやアラームはありますか？

このリストを活用することで、切り替え時の予期せぬ事態を減らし、初日から隔離措置が効果を発揮するようにします。.

代理店およびプロジェクトオーナー向けの実践的な推奨事項

プロバイダーに明確に確認します サイトの分離 そしてCageFSも、これらの機能が共有環境において真の分離を実現してくれるからです。私は各ウェブサイトを、コードパス、認証情報、デプロイメントがそれぞれ独立した個別のインスタンスとして扱い、複数のプロジェクトが混在する状態を維持することは避けています。コア、テーマ、プラグインのアップデートは、既知の脆弱性が放置されないよう、頻繁に実施しています。アクセス権限は役割に応じて厳格に付与し、異なるプロジェクトに複数のユーザーがアクセスする場合は、ログインを分離しています。より深く理解するためには、以下を参照することがよく役立ちます。サイトごとの分離, 、自社のスタックを適切に計画し、実装するために。.

ホスティングプランの選び方：品質の特徴を見極める

じっと見つめてはいない 収納スペース トラフィックだけでなく、セキュリティ機能や分離コンセプトについても、最初からしっかりと確認しましょう。CloudLinux、CageFS、Site Isolationを採用しているプロバイダーは、マルチサイトアカウントに顕著な付加価値を提供します。単純なchrootメカニズムのみに依存している場合、バックドアが残され、複数のプロジェクトが混在する環境ではリスクとなります。また、予測可能なパフォーマンスと応答時間を維持するためには、明確なリソース予算設定も重要です。eコマース、企業サイト、プロフェッショナルなブログは特に恩恵を受けます。なぜなら、ダウンタイムや予期せぬ影響は多大なコストにつながる可能性があるからです。評判費用。.

実装：有効化とグレースフル・リスタート

実際の作業では、私は以下を有効にしています断熱プロジェクトが独立している場合や、多くの拡張機能があるなど、リスクが高まる場合などです。切り替え後、CloudLinuxはドメインの古いPHPプロセスを順序立てて終了させ、新しいコンテキストで再起動するため、リクエストはスムーズに処理され続けます。サイトごとに独自のFPMプールを設定することで、メモリ制限、opcache、max_childrenのチューニングを副作用なく容易に行うことができます。 Cronエントリは各ドメインに割り当て、スケジュールされたスクリプトが他のパスのリソースにアクセスしないようにしています。これらの手順を組み合わせることで、メンテナンスが容易で、ダウンタイムを大幅に削減できるセットアップが実現します。下.

表による比較：CageFSとサイト分離の概要

以下の比較では、 相違点 CageFSとSite Isolationの比較を、管理者がよく抱く疑問に沿って行います。ここでは、可視性、プロセスのカプセル化、cronの処理、リソース、そして典型的なユースケースに焦点を当てます。この比較は、新しいアカウントに関する意思決定や優先順位付けを体系化するのに役立ちます。 1つのアカウント内で多数の独立したサイトを運用している場合は、よりきめ細かな分離によるメリットが大きくなります。インストールが1つだけの個別アカウントであれば、どちらのメカニズムでも問題なく動作しますが、Site Isolationにはさらに セキュリティ 成長のために。.

アスペクト	CageFS（アカウントレベル）	サイトの分離（ドメインレベル）
視認性	自分のアカウントのファイルのみを表示	ドメイン／サブドメインごとの表示
プロセス	アカウントごとの共通プロセス	サイトごとの独自のPHPコンテキストとFPMプール
Cronジョブ	アカウント全体に適用可能	サイトのドキュメントルートに紐付けられている
横方向の動き	サイト間の移動が可能	不倫が大幅に制限される
運営シナリオ	明確なアカウントの分離	明確な区分が設けられたマルチサイトアカウント

要約：セキュリティのレバレッジとしてのドメインレベル

クラウドリナックス サイト分離は、CageFSによる従来のアカウントカプセル化をさらに拡張し、ドメインごとの分離を実現することで、マルチサイトアカウントのセキュリティを著しく強化します。これにより、攻撃や設定ミスを各サイト内に封じ込め、脆弱なプロジェクトが近隣のプロジェクトに悪影響を及ぼすのを防ぎます。分離されたPHPコンテキスト、バインドされたcronジョブ、シンボリックリンク保護が、連携したセキュリティ体制を形成し、同時に運用計画の策定を容易にします。LVEおよびcgroup v2と組み合わせることで、明確なリソース配分が可能となり、プロジェクトごとの負荷のピークを適切に管理できます。共有ホスティングを本格的に利用するなら、サイト分離を積極的に導入すべきです。この追加のセキュリティ層はリスクを低減し、ダウンタイムを短縮し、 信頼性 環境全体。.