セキュリティ

サイトごとのCageFS：共有ホスティング向けの新しいセキュリティアーキテクチャ

サイトごとのCageFS 共有ホスティングアカウント内の個々のウェブサイトを厳格に分離し、侵入発生後の横方向への拡散リスクを低減します。本記事では、この新しいセキュリティアーキテクチャについて解説し、実際の活用例を紹介するとともに、1つのアカウント内で複数のプロジェクトを安全に運用する方法について説明します。.

中心点

ウェブサイトの分離: 1つのアカウント内でさらに区分を設けることで、間接的なリスクを低減できる。.
クラウドリナックス: CageFSのコンセプトをドメインレベルに拡張すること。.
ワードプレス: 複数のインスタンスを安全に並行して運用する。.
リソース: CPU/RAM/I/O の制限は、ファイルビューの分離を補完するものです。.
練習: ドメインごとの有効化と、明確な権限・パス戦略。.

「Per-Site CageFS」が具体的にどのような機能を提供するのか

この拡張機能は個々の ドメイン 既存のユーザー用CageFS内で、各ウェブサイトが自身のファイルとプロセスのみを認識できるようにします。これにより、侵害されたプロジェクトが、同じアカウント内の他のサイトの設定ファイル、アップロードされたファイル、または鍵にアクセスすることを防ぎます。によると クラウドリナックス ブログ（ベータ版発表）によると、Per-Site CageFSは同一ユーザーアカウント内のウェブサイト間の隔離を強化し、サイドウェイ移動のリスクを低減します。私にとってその利点は明らかです。ホスティング構造を崩すことなく、代理店アカウント、マルチサイト構成、テスト環境を明確に区分できるからです。CageFSの仕組みについて、こちらの背景解説記事で概要を素早く把握できます。 CageFSファイルシステム, 、サイトごとの分離がこれに基づいている。.

なぜアカウントの分離だけでは不十分なのか

1つのアカウントには、多くの場合、複数のものがまとめられています プロジェクト – たとえば、2つのショップ、3つのブログ、そして1つのステージング環境など。エクスプロイトが脆弱なプラグインを攻撃した場合、攻撃者は追加のセグメンテーションなしに隣接するディレクトリを覗き見し、そこにさらなるペイロードを配置することが可能になります。まさにこの点において、Per-Site CageFSはファイルシステムとプロセスへのアクセスを制限し、各ウェブサイトがあたかも独自の 刑務所 動作します。特に、PHPユーザーを共有する別々のWordPressインスタンスの場合、そうでなければ問題が悪化する余地が生じてしまいますが、ドメインの隔離によってそのリスクを排除しています。これにより、二次被害を軽減し、原因究明を容易にし、復旧作業の計画を迅速に立てられるようになります。.

ウェブサイト隔離の技術的な仕組み

CloudLinuxは、CageFSを介して、ユーザーごとの仮想環境を ファイルシステム; サイトごとのレイヤーは、これをドメインの境界にまで拡張します。有効化された各ドメインには、ユーザー用CageFS内に独立したビュー領域が割り当てられ、そこには制限付きのパス、独自の一時ディレクトリ、および隔離されたスクリプト実行環境が含まれます。これにより、攻撃を受けたウェブサイトの視点からは、外部の wp-config.php、アップロードフォルダ、または鍵ファイルが視界から消え去ります。Cronジョブ、PHP、および場合によってはSSHコマンドは、同じシステムライブラリにアクセスしますが、割り当てられた 部分集合 ファイルシステムについて。ドキュメントによると、この分離はドメインごとに有効・無効を切り替えられるため、本番環境、ステージング環境、テスト環境の各インスタンスに対してきめ細かな制御が可能になります。.

比較：アカウント分離、サイトごとのCageFS、およびコンテナ

体系的に選択を行うために、3つの一般的なものを比較しています モデル 分離の深度、手間、互換性の観点から。アカウント分離は顧客間の分離を実現しますが、内部のサイト境界は開放されたままとなります。サイト単位のCageFSは、ファイルシステムおよびプロセスの観点からこのギャップを埋めます。コンテナは厳格な境界を確立しますが、多くの場合、より多くのメンテナンスや調整が必要となります。プロセス分離に関する詳細な分類については、こちらをご覧ください。 Chroot、CageFS、Jailsの比較.

アプローチ	アカウント間の分離	アカウント内のウェブサイト間の区別	互換性（PHP/CGI/SSH/Cron）	営業費用
アカウントの分離（従来型）	高い	低い	非常に良い	低い
サイトごとのCageFS	高い	中～高	非常に良い	低～中
サイトごとのコンテナ数	非常に高い	非常に高い	良い～非常に良い	中～高

共有ホスティング環境において、Per-Site CageFSは、きめ細かな制御と強力な機能性を兼ね備えたソリューションを提供します。分離また、スクリプトは通常そのまま実行できるため、変更も最小限で済みます。これにより、最も一般的な脆弱性である「1つのユーザーアカウントで複数の独立したウェブサイトを運用している」という状況を防ぐことができます。.

実践：複数のWordPressインスタンスを安全に運用する

私は、有効化されている各WordPressインスタンスを分離しています ドメインの分離 また、各サイトごとに独自のPHP-FPMプールを設定し、ログ、opcache、および制限が明確に割り当てられるようにしています。さらに、各サイトごとにwp-config.php内で独自のSALT/KEYを定義し、ファイル権限やopen_basedirに相当する設定を通じて、サイト間のデータ漏洩を防止しています。アップロードファイルは、各ドキュメントルート内に厳格に保存し、グローバルな共有アップロードディレクトリの使用を禁止しています。デプロイ時には、一時パスをサイト内部に限定し、ビルドアーティファクトを直ちに削除することで、不必要な攻撃対象を残さないようにしています。 ComposerやNPMのキャッシュについては、サイトローカルの ディレクトリ, 、相互影響が生じないようにするためです。.

パフォーマンスとリソース管理の連携

Per-Site CageFS はファイルビューを対象としています。その パフォーマンス アカウントまたはプールレベルで、CPU、RAM、I/O、およびプロセスの制限を設定することで安全を確保しています。これにより、不具合のあるプラグインによって特定のサイトに過度な負荷がかかり、アカウント全体のパフォーマンスが低下するのを防いでいます。多くの環境では、これをLVEや類似のクォータに組み込み、プールごとまたはアカウントごとに細かく調整しています。さらに、WebサーバーやWAFでのリクエスト制限と連動させることで、トラフィックのピーク時でも処理が円滑に行われるようにしています。この「隔離」と「クォータ」の組み合わせにより、サービスの安定性と予測可能性が向上します。 負荷分散.

保護チェーン：Per-Site CageFSでは置き換えられないもの

遮蔽により横からの視界は遮られますが、アップデートについては、, 硬化 PHPの適切な運用と厳格なパスワード設定を引き続き徹底します。また、管理者ログインへの多要素認証（MFA）、最小限のファイル権限、アップロードフィルタも必須です。WAF、レート制限、継続的なログ記録により、単なるファイルアクセス分離では制御できない追加の攻撃経路をカバーします。また、攻撃者が見落としがちなCronジョブや統合トークンについても定期的に確認を行っています。テナント分離とハードニングの連携に関する詳細は、以下のガイドをご覧ください。共有ホスティングのセキュリティ, 、その思想的傾向を強調するものである。.

導入と典型的な課題

ドメインの隔離を、以下ごとに個別に有効にします ウェブサイト その後、実際の環境下でSSH、Cron、PHPへのアクセスをテストします。デプロイスクリプトやプラグイン内の絶対パスは問題を引き起こす可能性があるため、私は相対パスや変数を使用するようにしています。プロジェクト間のシンボリックリンクは、分離の原則を損なうため避けています。必要なライブラリは、サイトごとにリポジトリに追加するようにしています。バックアップについては、復元やフォレンジック調査を明確に行うため、ドメインごとに個別のアーカイブを定義し、ログもドメインごとに保存しています。権限については、ファイルに640、フォルダに750という設定が有効であることが実証されており、さらに 所有者 それぞれのPHPプールに合わせて。.

代理店とフリーランサーのための費用対効果の検討

セキュリティ上のメリットと、管理にかかる時間、および横断的なインシデントが発生した場合に生じうるダウンタイムコストを比較検討し、 ユーロ-を基本とします。インシデント対応に数時間費やすだけでも、隔離機能を強化するためのわずかな月額追加費用をはるかに上回るコストがかかることがよくあります。複数のクライアントプロジェクトを抱える代理店アカウントの場合、セグメンテーションにより、法的責任や評判に関するリスクが著しく軽減されます。また、個々のサイトを的確に復元できるため、バックアップや復元プロセスもより円滑に進みます。全体として、サイトごとのCageFSは、より信頼性の高い 運営管理 計画可能なプロセスで。.

チェックリスト：サイトごとのCageFSが必須となる場合

複数のものが存在するとすぐに、ドメイン分離を有効にします。 インストール 1つのアカウント内で稼働しているものの、更新サイクルが異なる場合。また、プロジェクトチームが分かれていたり、外部の管理者アクセス権が存在したりすることも重要であり、これらは意図しない操作が行われるリスクを高めます。大量のアップロード、ファイルコンバーター、画像処理などが行われる場合も、これらがしばしばセキュリティ上の侵入経路となるため、分離がさらに正当化されます。また、コンプライアンス要件（例：クライアント、市場、データ保護）が異なる場合も、よりきめ細かなセグメント分けが推奨されます。ステージング、テスト、本番環境を並行して運用している場合は、エラー領域が明確に分離され、明確な 科学捜査.

実際の運用における要件と互換性

Per-Site CageFSを本番環境で導入する前に、実行環境を確認します。具体的には、使用されているPHPハンドラー（PHP-FPMやlsapiなど）、稼働中のWebサーバー、利用可能なパネル統合機能、およびCronジョブやSSHセッションの管理方法などです。一般的な共有環境では、コードを変更することなくアプリケーションを継続して実行できます。ドメインごとに独自のドキュメントルートが存在すること、パスが一意であること（例：/home/user/sites/projekt-a/public）、そしてサイトごとに専用のPHP-FPMプールが割り当てられていることを確認します。 Cronジョブについては、ドメインごとに個別のcrontabを使用するか、コントロールパネルで一括管理されている場合は、明確なプレフィックスとログパスを設定し、各ジョブが自身の 刑務所 仕事だ。

データベース、キャッシュ、セッションを明確に分離する

ファイルの表示はあくまで一部に過ぎません。私はこの分離をデータベースやキャッシュにまで徹底しています。ウェブサイトごとに、専用のデータベースと、最小限の権限を持つ専用のDBユーザーを作成しています。オブジェクトキャッシュやページキャッシュ（Redis、Memcachedなど）については、サイトごとに独立したインスタンスを使用するか、少なくともキープレフィックスと専用のデータベース／ネームスペースを割り当てています。PHPセッションはサイト固有のパスに保存され、 FPMプールごとにsession.save_pathを個別に設定しています。中央キューや検索バックエンドを使用する場合は、サイトごとにインデックスとトピックを分離します。この「ラストマイルまで分離する」という原則により、インシデントが関連システムに波及するのを防ぎます。.

隔離環境下でのCI/CDとデプロイ

ビルドパイプラインでは、分離を標準的な手法としています。サイトごとに独自のデプロイジョブを用意し、そのジョブは当該サイトのディレクトリにのみアクセスするようにしています。アーティファクトはドメインルート内で展開し、その後、所有者・グループの修正を行い、影響を受けるキャッシュのみを無効化します。 WP-CLIコマンドはそれぞれのCageFSコンテキスト内で実行されるため、他のプロジェクトに影響を与えることはありません。環境変数はサイトごとに分離し、シークレットは各サイト固有の設定ファイルまたはパネルのシークレットストアに保管しています。ダウンタイムゼロを実現するため、ドメインの境界内（例：current/releases）でアトミックなシンボリックリンクの切り替えを行いますが、シンボリックリンクが隣接するプロジェクトを指さないよう注意しています。デプロイ後のチェック（ヘルスチェック、404/500スキャン、権限チェック）は、サイトごとに必須のプロセスです。.

モニタリング、ロギング、およびフォレンジック

私はログを徹底的に分類しています。ドメインごとにアクセスログとエラーログを分け、PHPログやcronログも個別に管理し、ローテーションや保存期間の設定を行っています。これにより、インシデントが発生した際、アカウント全体をくまなく調べる必要なく、個々のサイトのタイムラインを再現することができます。さらに、ファイル整合性チェック（コアディレクトリのチェックサム）、管理操作の分散型監査ログ、および改ざんを早期に検知するシンプルなカナリアファイルも活用しています。アラートについては、多くの場合、閾値を設定するだけで十分です。例えば、500エラーの急激な増加、異常なアップロードサイズ、iノード使用量の急激な増加、あるいはPHPワーカーの過剰な起動などが挙げられます。これらのシグナルに対して、明確なランブックを関連付けています。具体的には、サイトのロック、バックアップの確認、アーティファクトの保存、隔離されたスコープ内での再起動などです。.

WordPressの特殊なケース：マルチサイト、MUプラグイン、およびアップロードフロー

WordPressマルチサイトについては、次のように検討しています。マルチサイト環境では、複数のサイトが意図的にコードベースや構造を共有しているため、サイトごとのCageFSの恩恵はあまり受けられません。より厳格な分離が必要な場合（独立したチーム、キャッシュの分離、明確なフォレンジックなど）は、個別のインスタンスを立ち上げて隔離することを優先します。MUプラグイン、ドロップイン、またはグローバルなMust-Useライブラリは、サイト内部でのみ配布し、共有フォルダの使用は避けています。メディアワークフロー（CDN、画像最適化、コンバーター）はドメイン・ジェイル内で実行し、あるサイトから別のサイトのディレクトリへのアップロードは許可しません。チームがアセットパイプラインを共有したい場合は、サイトごとにレプリケートするか、パッケージとしてカプセル化し、それぞれのリポジトリに組み込みます。.

移行パス：モノリシック型からセグメント化されたアカウントへ

多くのアカウントは、当初から大きなpublic_htmlディレクトリを持っており、時間の経過とともに肥大化していきます。私は以下の5つのステップで対応しています：1) 現状把握：どのサイト、ドメイン、cronジョブ、データベース、シークレットがあるか？ 2) パス構成の決定：サイトごとに独自のルート、一時ファイル、ログ、バックアップディレクトリを設定する。 3) ドメインごとにPHP-FPMプールを定義し、制限を設定する。4) ファイルを移動し、権限を調整し、絶対パスやインクルードを整理する。5) サイトごとにCageFSを有効化し、負荷テストを実施し、モニタリングを稼働させる。その間、ロールバック戦略（スナップショット、分離されたバックアップ）を準備しておく。カットオーバー後は、WP-CLI、Composer、画像処理、Cronジョブなどのツールが正しいスコープで実行されているかを確認し、必要に応じてパス変数を調整する。.

エラーパターンとトラブルシューティング

有効化後の403/404エラー：多くの場合、リライトルールやインクルードがドメインのルートディレクトリ外のパスを参照しています。私はパスを相対パスに修正するか、変数を使用するようにしています。.
Composer/NPM が動作しなくなる：グローバルキャッシュが認識されない。サイトローカルのキャッシュディレクトリを設定し、デプロイ時に HOME/TMP 変数を調整している。.
WP-CLI が wp-config.php を見つけられません：ドメインのルートディレクトリ外で実行されています。作業ディレクトリを正しく設定するか、パスを明示的に指定します。.
cronジョブに関する問題：cronユーザーやパスがドメインごとに設定されていない。サイト・ジェイル内で環境変数、バイナリパス、ログの保存先を確認している。.
アップロードに失敗する：session.save_path または tmp_dir が誤ったディレクトリを指している。FPM プールごとにサイト固有の一時ファイルパスを割り当てている。.
共有ライブラリが見つかりません：隣接プロジェクトへのシンボリックリンクがブロックされています。各サイトにライブラリを複製するか、パッケージとしてデプロイメントに組み込みます。.

ガバナンスとアクセスモデル

技術的にはすべてが分離されていても、アクセス権の問題は残ります。私はサイトごとに専用のSSH／SFTPアクセス権を付与するか、コントロールパネルへのアクセスをそれぞれのドメインに限定しています。開発チームや代理店チームには、本当に必要なキーと権限のみを付与しています。緊急事態に備えて、「ブレイクグラス」プロセス（一時的な権限の拡大、完全なログ記録、事後の権限剥奪）を用意しています。監査では、サイトごとにパス、プール、制限、責任者、RBACの割り当て、バックアップを文書化しています。これにより、セグメンテーションは技術的な面だけでなく、組織的な面でも堅牢なものとなります。.

簡単にまとめると

サイトごとのCageFSは、既存のユーザー分離機能に以下の機能を追加します。 ウェブサイト-レベルで管理することで、横方向の動きによるリスクを効果的に低減します。多くのアカウントが複数の独立したプロジェクトを統合しているため、これは実務に即した措置だと考えています。ファイルビューの分離とリソース制限を組み合わせることで、パフォーマンス、セキュリティ、運用に秩序がもたらされます。複数のWordPressやECサイトのインスタンスをホストしている場合、トラブルシューティング、バックアップ、インシデント発生後の復旧にかかる時間を短縮できます。明確な権限設定、アップデート、多要素認証（MFA）、ログ記録により、堅牢な 安全チェーン, 、これにより共有ホスティングの耐負荷性が大幅に向上します。.