所有権を日々のアクセスから分離する
各ホスティング、ドメイン、DNS、サードパーティアカウントを誰が保有し、誰がその請求を支払い、誰が復旧を管理するかを決定してください。これらの役割は異なる人が担う場合があります。リリースをアップロードする保守担当者が、クライアントプロジェクトを復旧できる唯一の人物になってはなりません。
アカウント識別子、ビジネスオーナー、復旧連絡先の担当者、認可された管理者を一覧にしてください。復旧資料そのものをこのシートに記載せず、どこに保管されているかを記録してください。事業継続が退任する請負業者の個人メールやデバイスに依存しないことを確認してください。
責任マトリクスを一緒に完成させる
以下の例は話し合いのための提案であり、PrivateHostLab の契約上の義務を示すものではありません。クライアントはビジネス上の決定を所有し、代理店は受け入れた技術作業を担当し、プロバイダーの義務は実際のサービス契約に基づきます。役割は、指名された人物または文書化されたプロバイダー連絡先に置き換えてください。
各行に承認の境界と合意された連絡方法を追加してください。代替担当者は役割を受け入れ、必要なアクセスを持っている必要があります。空欄の代替担当者や不明なプロバイダーのエスカレーション経路は、想定されたカバレッジではなく未対応のアクションです。
テーブルのすべての列を表示するには横にスクロールしてください。
| 責任 | 提案された主担当 | 指名する代替担当 | エスカレーション条件 |
|---|---|---|---|
| ホスティング予算と更新 | クライアント予算オーナー | クライアント認可の代理人 | 支払いの決定または更新が未割り当て |
| ドメインと DNS の管理 | クライアントオーナー。代理店は合意によってのみ変更 | 認可されたドメイン運用者 | アクセスが失敗するか、レコードがユーザーを誤って誘導 |
| OS とアプリケーションの保守 | 合意された範囲内の代理店保守担当者 | 有資格の代理店代替担当者 | 更新が失敗するか、サポートされていないコンポーネントの決定が必要 |
| バックアップと復旧の確認 | 指名された代理店またはクライアントのデータ運用者 | 訓練された復旧運用者 | コピーが欠落しているか、復元チェックが失敗 |
| インフラストラクチャの問題 | 検証されたサービス境界内のプロバイダー | 実際の契約に記載された経路 | 証拠がアプリケーションの制御範囲外を示す |
| クライアントへのインシデント更新 | 合意されたプロジェクト連絡先 | クライアント承認の代替担当者 | 重要なワークフローが中断されるか、次の更新が予定されている |
運用者にタスクに必要なアクセスを与える
関連システムが対応している場合は個別の ID を使用してください。公開、デプロイ、請求、アカウント復旧の権限は、実用的な範囲で区別してください。OWASP は必要最小限の権限を付与し、累積されたアクセス権限をレビューすることを推奨しています。この原則を、各プロジェクトアカウントの指名されたタスクとレビュー日に落とし込んでください。 OWASP 認可チートシート.
誰が SSH キーを追加または削除でき、誰が結果を検証するかを合意してください。SSH の構成を変更する前に、既知の動作するセッションと確認された復旧経路を保持し、適用前に構成を検証し、古いセッションを閉じる前に新しい認可された接続を証明してください。Ubuntu は、アクセスを失わないように OpenSSH を再起動する前に構成を確認することを明確に推奨しています。 Ubuntu OpenSSH サーバードキュメント.
引き継ぎ文書にはキーのフィンガープリントまたはアクセス記録の参照を含め、秘密鍵、パスワード、ウォレットの復旧フレーズは決して含めないでください。
ビジネスへの影響でエスカレーションを定義する
日常的なコンテンツ要求、計画されたメンテナンス変更、重要なクライアントワークフローに影響するインシデントを区別してください。対応時間、タイムゾーン、最初の連絡先、代替担当者、次のコミュニケーションチェックポイントを記載してください。便利なメッセージングチャネルを、暗黙の応答時間保証に変えないでください。
アラートは誰かが実行できるアクションにつながるべきです。Google の監視ガイドラインは、目に見える症状と考えられる原因を区別し、ページが緊急かつ実行可能かどうかを問いかけます。このプロジェクトでは、「問い合わせを送信できない」の方が「サーバーが異常に見える」よりも明確なインシデント説明です。 Google SRE 監視ガイドライン.
有用なエスカレーションメモには、影響を受けたワークフロー、最初に観測された時刻、最後に確認された成功、最近の変更、既に取られたアクションを記録します。サポートログから個人データとシークレットを削除してください。
バックアップ作業だけでなく復旧の決定も割り当てる
データをどの時点まで復旧させる必要があるか、またビジネスに重大な影響が出るまでに復旧にどれだけ時間をかけられるかを合意します。これらはNISTの 目標復旧時点 と 目標復旧時間 目標が示す、異なる計画上の問いです。
コピーを維持する担当者、それらをテストする担当者、本番復元の承認者を指名します。別の宛先でリハーサルを行います。復元されたデータポイント、機能チェック、経過時間、ギャップを記録します。成功したリハーサルはその演習の証拠であり、将来のすべてのインシデントに対する保証ではありません。
使用可能なプロジェクト記録を引き継ぐ
キャンペーン後にクライアントが日々の保守担当者を変更する場面を想像してください。引き継ぎ元の代理店は、現在のリリース、依存関係インベントリ、デプロイ手順、データベースおよびアップロードの復旧手順、スケジューラの詳細、DNSマップ、第三者アカウント台帳を提供します。クライアントは、どのアカウントと進行中の作業が後任に移るかを確認します。
受領側の運用担当者は、文書を使って管理された演習を実施すべきです。承認されたリリースを特定し、サンプルデータを分離環境で復元し、次のスケジュールされたジョブを見つけ、更新の責任者を特定します。完了できなかった事項を記録し、その運用担当者をインシデント対応に頼る前に解決します。
- 退任者のアクセス権を削除する前に、後任者の承認されたアクセス権を確認します。
- 共有されていた認証情報をローテーションするか、それが適切な管理手段である場合は個々のIDを取り消します。
- プロジェクトインベントリ全体にわたり、不要になったキー、デプロイトークン、アクセス許可を削除します。
- 合意された引き継ぎ条件の下で、残存コピーと進行中の作業の処分を確認します。
シートを受け入れ、その後維持する
各引き継ぎチェックを承認済み、ブロック中、または要フォローアップとして、レビュアーと証拠の保管場所とともに記録します。未解決の復旧連絡先は、一般的な「引き継ぎ完了」メッセージに紛れて消えるのではなく、可視化されたままにすべきです。
クライアント、代理店、プロバイダーの範囲、またはアプリケーションが変更されるたびに、このシートを見直します。これを 承認済みホスティング予算 と 移行記録にリンクします。このワークシートは運用合意を準備するものであり、実際の販売者条件に代わるものでも、プロバイダーのサポートコミットメントを生み出すものでもありません。公表されている サービス範囲 と比較し、不足している詳細を明示的に解決します。
出典とレビュー
技術参照は12年2026月に確認しました。例は計画上の演習であり、参照されたソフトウェア文書はPrivateHostLabのサービス機能を立証するものではありません。