인수인계 기간과 담당자 합의
누가 이전을 승인하고 접근을 취소할 권한이 있는지 확인하세요. 고객 계정 소유자, 퇴사 계약자, 대체 운영자 및 접근이 중단될 경우 도움을 줄 수 있는 사람을 지정하세요. 마감 시점, 중복 기간 동안 허용되는 변경 사항 및 완료 전 필요한 증거를 합의하세요.
현재 프로젝트 인벤토리, 합의된 작업 범위 및 고객의 보안 자격 증명 시스템에 대한 접근 권한을 확보하세요. 퇴사 운영자를 제거하기 전에 계정 복구 방법을 확립하세요. 침해가 의심되어 인수인계가 이루어지는 경우 사고 대응 담당자가 봉쇄 시점을 결정해야 하며, 일반적인 중복 순서는 적절하지 않을 수 있습니다.
로그인 접근과 소유권을 별도로 목록화
각 서비스의 계정 소유자, 현재 운영자, 자동화 ID, 복구 담당자 및 필요한 이전 조치를 나열하세요. 관리자 로그인이 청구 또는 복구를 누가 통제하는지 결정하지는 않습니다. 자격 증명 참조 또는 공개 키 지문만 기록하고, 비밀번호, 토큰, 개인 키 또는 복구 코드는 이 등록부에 절대 넣지 마세요.
모든 테이블 열을 보려면 가로로 스크롤하세요.
| 프로젝트 자산 | 소유권 질문 | 완료 증거 |
|---|---|---|
| 도메인 및 DNS | 등록기관, 갱신 및 복구 연락처를 누가 통제하나요? | 소유자가 접근 및 현재 기록을 확인합니다. |
| 호스팅 및 서버 | 계정, 콘솔 및 권한 있는 사용자를 누가 통제하나요? | 대체자가 필요한 접근을 독립적으로 확인합니다. |
| 저장소 및 배포 | 저장소, 자동화 및 배포 자격 증명을 누가 소유하나요? | 승인된 릴리스를 격리된 대상에 배포했습니다. |
| 애플리케이션 및 통합 | CMS, 메일, API 및 예약 작업을 누가 관리하나요? | 역할 및 통합 검사 기록됨. |
| 백업 및 복구 | 백업 저장소와 필요한 복호화 자료를 누가 통제하나요? | 대체자가 격리된 복구 훈련을 완료합니다. |
소유권과 운영 지식 이전
서비스에서 지원하는 이전 또는 초대 메커니즘을 사용한 다음 수신 소유자가 자신의 계정에서 통제권을 확인하도록 하세요. 계약자의 개인 신원을 공유 로그인으로 채택하지 마세요. 개인 계정이 이전에 제공한 경우 승인된 보안 시스템을 통해 프로젝트 자격 증명을 재발급하세요.
GitHub 저장소의 경우 이전하면 관련 시크릿, 배포 키 및 웹훅이 유지되며 기존 협력자가 남을 수 있습니다. 이전 후 이를 명시적으로 검토하세요. 이전 영수증은 소유권 변경을 증명할 뿐 접근 제거 완료를 증명하지 않습니다.
릴리스 참조, 런타임 버전, 구성 위치, 예약 작업, 외부 종속성, 백업 범위 및 복구 절차를 제공하세요. 알려진 실패와 다음 유지 관리 작업을 추가하세요. 자격 증명 값을 문서에 복사하지 않고 안전하게 검색하는 위치를 설명하세요.
대체자가 직접 작업 수행
대체자가 계약자의 세션을 빌리지 않고 작성된 절차를 따르도록 요청하세요. 승인된 소스를 확보하고, 격리된 테스트 대상에 배포하고, 유용한 로그를 찾고, 허용된 애플리케이션 관리 작업을 시연해야 합니다. 누락된 단계를 모두 기록한 다음 지침을 업데이트하고 영향을 받은 검사를 반복하세요.
아웃바운드 통합을 비활성화하거나 리디렉션한 상태에서 합의된 백업을 별도의 테스트 대상으로 복원하도록 하세요. 대표 레코드, 업로드 및 애플리케이션 동작을 확인하세요. 백업 식별자, 대상, 경과 시간 및 해결되지 않은 격차를 기록하세요. 복구를 시연하기 위해 프로덕션을 덮어쓰지 말고, 성공적인 백업 작업을 완료된 복원 테스트로 해석하지 마세요.
모든 경로에서 퇴사자의 접근 제거
대체 접근과 복구가 검증된 후, 관련 팀, 저장소, 호스팅 계정, 애플리케이션 역할에서 계약자를 제거하세요. 활성 세션을 검토하고 계약자가 보유할 수 있는 프로젝트 토큰, 통합, 자격 증명을 취소하세요. 자격 증명이 공유된 경우 교체본을 발급하고, 종속 서비스를 업데이트한 뒤 테스트한 후 이전 값을 폐기하세요. 이전 자격 증명에 대한 숨은 의존성을 잡기 위해 취소 후 대체자의 작업을 반복하세요.
GitHub 배포 키는 생성자가 저장소에서 제거되어도 활성 상태로 남습니다. 쓰기 권한과 각 키를 사용하는 머신을 포함해 별도로 점검하세요. 승인된 OAuth 앱의 경우 계정 소유자는 GitHub의 제어를 사용해 앱 목록을 검토하고 불필요한 승인을 취소해야 합니다.
SSH 접근의 경우 실제 공개 키 인증 구성을 식별하세요. OpenSSH 문서에 따르면 AuthorizedKeysFile은 공개 키 인증에 사용되는 파일을 선택하므로 모든 서버가 하나의 기본 파일을 사용한다고 가정하지 마세요. 검증된 복구 경로를 유지하고 유지보수 세션을 닫기 전에 대체자의 새 연결과 필요한 권한을 테스트하세요.
예: 저장소는 이전되었지만 배포는 되지 않음
이 가상 시나리오에서 Cedar Workshop은 웹사이트 계약자를 변경합니다. 저장소는 클라이언트 조직에 도달하지만 배포 작업은 여전히 떠나는 계약자가 소유한 자격 증명을 사용합니다. 대체자는 코드를 편집할 수 있지만 승인된 빌드를 게시할 수 없습니다. 인계는 불완전하게 남습니다.
소유자는 해당 작업에 필요한 권한을 가진 프로젝트 제어 배포 자격 증명을 마련한다. 대체자는 테스트 대상에서 배포와 복구를 검증한다. 그런 다음 팀은 기존 자격 증명을 폐기하고, 남은 배포 키를 검토하며, 허용된 점검을 다시 실행한다. 종료 기록은 자격 증명 값을 포함하지 않은 채 이러한 결과에 연결된다.
증거와 예정된 소유권으로 마무리
인수인계를 수락한 소유자, 각 취소된 접근 참조, 완료 시간, 대체 테스트 결과 및 미해결 예외 사항을 기록한다. 다음 예정된 작업 실패, 도메인 갱신 및 유지보수 작업에 누가 대응할지 확인한다. 기존 계약에 따라 임시 테스트 데이터와 계약자가 보유한 프로젝트 사본을 어떻게 처리할지 합의한다.
접근 제거는 과거 사본이 보관되지 않았음을 입증할 수 없다. 복구 훈련은 테스트된 시나리오를 입증할 뿐, 모든 실패 모드를 입증하지는 않는다. 이러한 경계를 가시적으로 유지하고, 미해결 작업을 책임자와 기한이 지정된 운영 책임 기록으로 이관한다.
출처 및 검토
기술 참고 자료는 12년 2026월에 확인되었습니다. 예시는 계획 연습입니다. 참조된 소프트웨어 문서가 PrivateHostLab 서비스 기능을 입증하지는 않습니다.