引き継ぎ期間と担当者を合意する
誰が移転を承認し、アクセスを取り消す権限を持つかを確認してください。クライアントアカウントの所有者、退任する請負業者、後任オペレーター、アクセスが壊れた際に支援できる人物を指名します。カットオフ、重複期間中の許可された変更、完了前に必要な証拠を合意してください。
現在のプロジェクト棚卸し、合意された作業範囲、クライアントの安全な資格情報システムへのアクセスを用意してください。退任するオペレーターを削除する前に、アカウント復旧の仕組みを確立します。引き継ぎが侵害の疑いに続く場合、インシデント対応責任者が封じ込めのタイミングを決定すべきです。通常の重複シーケンスは不適切かもしれません。
所有権をログインアクセスとは別に棚卸しする
各サービスのアカウント所有者、現在のオペレーター、自動化ID、復旧担当者、必要な移転アクションを列挙してください。管理者ログインは、誰が請求や復旧を管理するかを決めるものではありません。資格情報の参照や公開鍵のフィンガープリントのみを記録し、パスワード、トークン、秘密鍵、復旧コードはこの台帳に記載しないでください。
テーブルのすべての列を表示するには横にスクロールしてください。
| プロジェクト資産 | 所有権の確認事項 | 完了の証拠 |
|---|---|---|
| ドメインとDNS | 誰がレジストラ、更新、復旧連絡先を管理していますか？ | 所有者がアクセスと現在の記録を確認します。 |
| ホスティングとサーバー | 誰がアカウント、コンソール、特権ユーザーを管理していますか？ | 後任が必要なアクセスを独立して検証します。 |
| リポジトリとデプロイ | 誰がリポジトリ、自動化、デプロイ資格情報を所有していますか？ | 承認されたリリースが分離されたターゲットにデプロイされます。 |
| アプリケーションと連携 | 誰がCMS、メール、API、スケジュールジョブを管理していますか？ | ロールと連携のチェックが記録されます。 |
| バックアップと復旧 | 誰がバックアップストレージと必要な復号マテリアルを管理していますか？ | 後任が分離された復旧演習を完了します。 |
所有権と運用知識を移転する
サービスのサポートされている移転または招待の仕組みを使用し、受領する所有者が自分のアカウントから管理を検証してください。請負業者の個人IDを共有ログインとして採用することは避けてください。個人アカウントが以前に提供していた場合は、承認された安全なシステムを通じてプロジェクト資格情報を再発行してください。
GitHubリポジトリの場合、移転により関連するシークレット、デプロイキー、Webhookが保持され、既存のコラボレーターも残ることがあります。移転後これらを明示的に確認してください。移転の受領は所有権の変更を確立するものであり、アクセス削除の完了ではありません。
リリース参照、ランタイムバージョン、構成の場所、スケジュールジョブ、外部依存関係、バックアップ範囲、復旧手順を提供してください。既知の障害と次のメンテナンスタスクを追加します。資格情報の値をドキュメントにコピーせずに、安全に取得する場所を説明してください。
後任に実際の作業を行わせる
後任に、請負業者のセッションを借用せずに、書面による手順に従ってもらいます。承認されたソースを取得し、分離されたテストターゲットにデプロイし、有用なログを見つけ、許可されたアプリケーション管理タスクを実演してもらいます。欠けている手順をすべて記録し、指示を更新して、影響を受けるチェックを繰り返してください。
合意されたバックアップを、アウトバウンド連携を無効化またはリダイレクトした別のテスト先に復元してもらいます。代表的なレコード、アップロード、アプリケーションの動作を確認してください。バックアップ識別子、ターゲット、経過時間、未解決のギャップを記録します。復旧を実演するために本番を上書きしないでください。また、バックアップジョブの成功を復元テスト完了と解釈しないでください。
すべての経路で退任者のアクセスを削除する
代替者のアクセスと復旧が検証された後、請負業者を関連チーム、リポジトリ、ホスティングアカウント、アプリケーションロールから削除します。アクティブセッションを確認し、彼らが保持しうるプロジェクトトークン、統合、資格情報を無効化します。資格情報が共有されている場合は、その代替を発行し、依存サービスを更新してテストしてから古い値を廃止します。無効化後に代替者のタスクを繰り返し、古い資格情報への隠れた依存を検出します。
GitHubデプロイキーは、作成者がリポジトリから削除されても有効なままです。書き込み権限と各キーを使用するマシンを含め、個別に検査します。承認されたOAuthアプリについては、アカウント所有者がアプリ一覧を確認し、GitHubのコントロールを使用して不要な認可を取り消すべきです。
SSHアクセスについては、実際の公開鍵認証設定を特定します。OpenSSHは、AuthorizedKeysFileが公開鍵認証に使用されるファイルを選択することを文書化しています。すべてのサーバーが単一のデフォルトファイルを使用すると仮定しないでください。検証済みの復旧経路を維持し、メンテナンスセッションを閉じる前に代替者の新規接続と必要な権限をテストします。
例: リポジトリは移動したが、デプロイはされなかった
この架空のシナリオでは、Cedar Workshopがウェブサイトの請負業者を変更します。リポジトリはクライアントの組織に到達しますが、デプロイジョブはまだ離任する請負業者が所有する資格情報を使用しています。代替者はコードを編集できますが、承認されたビルドを公開できません。引き継ぎは不完全なままです。
所有者は、そのジョブに必要な権限を持つプロジェクト管理のデプロイ資格情報を手配します。代替者はテストターゲットでデプロイと復旧を検証します。その後、チームは古い資格情報を廃止し、残りのデプロイキーを確認し、許可されたチェックを再実行します。クローズ記録は資格情報の値を含めずにこれらの結果にリンクします。
証拠とスケジュールされた所有権で締めくくる
引き継ぎを受け入れた所有者、各取り消されたアクセス参照、完了時刻、代替テスト結果、未解決の例外を記録します。次に予定されているジョブ障害、ドメイン更新、メンテナンスタスクに誰が対応するかを確認します。一時的なテストデータと請負業者が保持するプロジェクトコピーの扱いについて、既存の契約の下で合意します。
アクセス削除は、履歴コピーが保持されなかったことを証明できません。復旧演習はテストされたシナリオを証明するものであり、すべての障害モードを証明するものではありません。これらの境界を可視化し、未解決の作業を名前付きの所有者と期限とともに運用責任記録に引き継ぎます。
出典とレビュー
技術参照は12年2026月に確認しました。例は計画上の演習であり、参照されたソフトウェア文書はPrivateHostLabのサービス機能を立証するものではありません。