運用要件から始める
構成を比較する前に、各プロジェクトのアプリケーションスタック、データベース、アップロード、スケジュールされたタスク、統合、予想される変更を収集します。コンテンツアクセス、デプロイアクセス、ホスト管理を必要とする人を特定します。これらは異なる職務です。ページを編集するクライアントはアプリケーションアカウントのみを必要とするかもしれませんが、オペレーティングシステムを保守する請負業者にはかなり広範な権限が必要です。
また、許容されるメンテナンス時間帯、ダウンタイムを承認する人、復旧コピーの保管場所、運用作業の支払い者も記録します。別のサーバーやアカウントに対するクライアント要件があれば、決定制約として記録します。リソースのスプレッドシートでは、所有権やアクセスの要件を解決できません。
- 各プロジェクトの主担当オペレーターと後任を指名します。
- 共有依存関係を一覧化します: DNSアクセス、デプロイ認証情報、データベースサービス、バックアップ先。
- 契約を結ぶ前に、クライアントの判断が必要な不明な要件を明確にする。
サーバーサイズより先にアクセス境界を選ぶ
OWASPは、個人の職務に必要な権限のみを付与し、意図した制限が維持されていることを検証することを推奨している。この原則をホスティングプランに適用する。個別のID、プロジェクト固有のアプリケーション認証情報、文書化されたデプロイパスを使用する。クライアント名のディレクトリは組織上の補助であり、アクセスポリシーではない。
Dockerを使用する場合、そのデーモンへのアクセスはホストレベルの責任として扱う。Dockerのセキュリティドキュメントは、信頼されたデーモンオペレーターがホストファイルをマウントおよび変更できると説明している。したがって、外部委託業者に無制限のDocker制御を付与することは、無関係なクライアントのデータを含むホストには不適切である。
VPSインスタンスを分離することで、オペレーティングシステムの管理とリリースの決定を別々に行える。ただし、各プロジェクト内での慎重な権限設定は依然として必要である。共通の代理店認証情報や共有デプロイアカウントは、分離しようとしたリスクを再び結びつける可能性がある。
2つの架空のクライアントブリーフを検討する
以下のクライアントは架空の例であり、顧客の履歴ではない。代理店は現在両方のプロジェクトを運営しているが、アクセスとタイミングの要件は異なる。
これら2つのプロジェクトを一緒に配置すると、Morrowの請負業者アクセスと立ち上げスケジュールがAsterの運用リスクの一部となる。サーバー分離の決定はこれらの制約に従うものであり、Morrowが特定の数のCPUを必要とすることや、Asterがリスクフリーであることを主張するものではない。
テーブルのすべての列を表示するには横にスクロールしてください。
| 決定要因 | Aster Furniture：ブローシュアサイト | Morrow Workshops：登録サイト |
|---|---|---|
| ワークロード | 公開ページと時折のコンテンツ更新 | フォーム、データベース、スケジュールされた登録エクスポート |
| アクセス | クライアントがコンテンツを編集、代理店がデプロイ | 外部開発者がホスト管理を必要とする |
| メンテナンス | 合意された夜間の時間帯 | 予約開始期間中の計画的な変更なし |
| インシデントの影響 | 一時的なページ停止は協議可能 | 送信の喪失または重複は調査が必要 |
| 終了要件 | コンテンツをエクスポートしてアプリケーションを移動 | 独立して運用されている環境を移転 |
| 暫定決定 | 互換性のある代理店運営サイトとの共有を検討 | 別のVPSと別のプロジェクト認証情報を使用 |
両方の arrangements の全コストを比較する
現在のコンフィギュレーターを使用して2つの予算バージョンを作成する。1つは共有構成、もう1つはプロジェクトごとの構成。それぞれについて、選択した期間のホスティング合計、定期的なオプション、外部サービス、代理店のメンテナンス時間を個別に記載する。古い価格をクライアントブリーフにコピーしないこと。構成が準備された日時と、割り当てを承認した者を記録する。
共有ホストの場合、クライアントが固定費をどのように分担するか、また1つが離脱したりアップグレードを必要としたりした場合にどうなるかを合意する。均等割は単純だが、1つのプロジェクトがストレージの増大や運用作業の大部分を引き起こす場合は不適切なことがある。別々のサーバーは帰属を明確にする一方で、個別のパッチ適用、監視、復旧タスクを追加する。
リリース、バックアップ、一時的な作業のためにリソースの余裕を残す。DockerコンテナはデフォルトでCPUやメモリの制約がない。適切な制限を設定し、合計ワークロードを評価する。コンテナのリストだけでは、実行可能なリソース予算を証明できない。
メンテナンスと復旧をプロジェクト固有にする
共有ホストでは、オペレーティングシステムの再起動がすべての常在プロジェクトに影響する。ホストメンテナンスを共通カレンダーに載せ、各クライアントへの連絡担当者を特定する。アプリケーションのリリースは実用的な範囲で分離し、あるプロジェクトのデータエクスポートを別のプロジェクトの重要な立ち上げ中にスケジュールしないこと。
復旧ノートには、プロジェクトのデータベース、ファイル、構成、必要な認証情報を特定するが、シークレットをノートにコピーしないこと。復元は別のテスト先に計画する。共有ホスト全体を最初の対応として復元すると、他のクライアントに属する健全な変更を置き換える可能性がある。
別々のVPSインスタンスの場合、残る共有サービスを記録する。共通のDNSアカウント、バックアップ先、またはオペレーターは依然として両方のプロジェクトに影響を与える可能性がある。サーバー分離は、独立した物理インフラや保証された可用性の証拠ではない。
arrangements を検証し、レビュートリガーを設定する
契約を受け入れる前に、別のオペレーターに、プロジェクトIDが割り当てられた作業を実行でき、他のプロジェクトのファイル、バックアップ、シークレットを読み取れないことを確認させる。アプリケーション画面だけでなく、データベース権限とデプロイされた認証情報もレビューする。合意された環境で無害なテストデータを使用する。他のクライアントの本番データを調査しないこと。
結果を承認、拒否、または指定された修正待ちとして記録する。分離を証明できない場合は、より広い権限を付与する前にアクセスを狭めるか、プロジェクトを移動する。ホームページの応答成功は、アクセスや復旧のチェックではない。
- 選択したレイアウト、承認されたコスト配分、担当者、未解決項目を含む決定記録を保持する。
- 外部管理者が参加したとき、立ち上げウィンドウが変更されたとき、ストレージが増大したとき、またはクライアントが離脱を準備したときに選択を見直す。
- 責任ガイドを使用して、技術的な選択を運用合意に変換する。
出典とレビュー
技術参照は12年2026月に確認しました。例は計画上の演習であり、参照されたソフトウェア文書はPrivateHostLabのサービス機能を立証するものではありません。