Согласуйте окно передачи и владельцев
Подтвердите, кто уполномочен утверждать передачи и отзывать доступ. Назовите владельца клиентской учётной записи, уходящего подрядчика, заменяющего оператора и человека, который может помочь, если доступ сломается. Согласуйте момент отсечения, разрешённые изменения в период перекрытия и доказательства, необходимые до завершения.
Имейте актуальную инвентаризацию проекта, согласованную область работ и доступ к защищённой системе учётных данных клиента. Установите, как работает восстановление учётных записей, прежде чем удалять уходящего оператора. Если передача следует за подозрением на компрометацию, ответственный за реагирование на инцидент должен определить сроки локализации; обычная последовательность перекрытия может не подойти.
Инвентаризируйте владение отдельно от доступа для входа
Перечислите для каждой услуги владельца учётной записи, текущих операторов, идентификаторы автоматизации, владельца восстановления и требуемое действие по передаче. Вход администратора не решает, кто контролирует биллинг или восстановление. Фиксируйте только ссылки на учётные данные или отпечатки открытых ключей; никогда не помещайте пароли, токены, закрытые ключи или коды восстановления в этот реестр.
Прокрутите по горизонтали, чтобы увидеть все столбцы таблицы.
| Актив проекта | Вопрос владения | Доказательство завершения |
|---|---|---|
| Домен и DNS | Кто контролирует регистратора, продление и контакт для восстановления? | Владелец подтверждает доступ и актуальные записи. |
| Хостинг и сервер | Кто контролирует учётную запись, консоль и привилегированных пользователей? | Заменяющий независимо проверяет необходимый доступ. |
| Репозиторий и развёртывание | Кому принадлежат репозиторий, автоматизация и учётные данные для развёртывания? | Утверждённый релиз развёрнут на изолированной цели. |
| Приложение и интеграции | Кто администрирует CMS, почту, API и запланированные задания? | Записаны проверки ролей и интеграций. |
| Резервные копии и восстановление | Кто контролирует хранилище резервных копий и любые необходимые материалы для расшифровки? | Заменяющий выполняет изолированное Exercise по восстановлению. |
Передайте владение и операционные знания
Используйте поддерживаемый услугой механизм передачи или приглашения, затем попросите принимающего владельца проверить контроль из своей учётной записи. Избегайте использования личной идентичности подрядчика как общего входа. Перевыпустите учётные данные проекта через утверждённую защищённую систему там, где ранее их предоставляла личная учётная запись.
Для репозиториев GitHub передача сохраняет связанные секреты, ключи развёртывания и вебхуки, а существующие соавторы могут остаться. Проверьте это явно после передачи. Квитанция о передаче подтверждает смену владельца, а не завершение удаления доступа.
Предоставьте ссылку на релиз, версии среды выполнения, расположения конфигурации, запланированные задания, внешние зависимости, охват резервного копирования и процедуру восстановления. Добавьте известные сбои и следующую задачу обслуживания. Объясните, где учётные данные безопасно извлекаются, не копируя их значения в документацию.
Позвольте заменяющему выполнить работу
Попросите заменяющего следовать письменной процедуре, не используя сессию подрядчика. Он должен получить утверждённый источник, развернуть на изолированной тестовой цели, найти полезные журналы и продемонстрировать разрешённую задачу администрирования приложения. Запишите каждый пропущенный шаг, затем обновите инструкции и повторите затронутую проверку.
Попросите их восстановить согласованную резервную копию в отдельное тестовое назначение с отключёнными или перенаправленными исходящими интеграциями. Проверьте репрезентативные записи, загрузки и поведение приложения. Запишите идентификатор резервной копии, цель, затраченное время и нерешённые пробелы. Не перезаписывайте продакшен, чтобы продемонстрировать восстановление, и не интерпретируйте успешное задание резервного копирования как завершённый тест восстановления.
Удалите доступ уходящего по всем маршрутам
После подтверждения замены доступа и восстановления удалите подрядчика из соответствующих команд, репозиториев, хостинговых аккаунтов и ролей приложений. Проверьте активные сессии и отзовите проектные токены, интеграции и учётные данные, которые могли у него остаться. Если учётные данные являются общими, выпустите их замену, обновите зависимые сервисы и протестируйте их, прежде чем выводить из эксплуатации старое значение. Повторите задачу замены после отзыва, чтобы выявить скрытую зависимость от старых учётных данных.
Ключи развёртывания GitHub остаются активными, когда их создатель удаляется из репозитория. Проверяйте их отдельно, включая права на запись и машину, использующую каждый ключ. Для авторизованных OAuth-приложений владелец аккаунта должен просмотреть список приложений и отозвать устаревшие авторизации с помощью средств GitHub.
Для доступа SSH определите фактическую конфигурацию авторизации по открытому ключу. В документации OpenSSH указано, что AuthorizedKeysFile выбирает файлы, используемые для аутентификации по открытому ключу; не предполагайте, что каждый сервер использует один файл по умолчанию. Сохраните проверенный путь восстановления и протестируйте свежее подключение замены и требуемые привилегии, прежде чем закрывать сеанс обслуживания.
Пример: репозиторий перенесён, но развёртывание — нет
В этом вымышленном сценарии Cedar Workshop меняет подрядчика по сайту. Репозиторий попадает в организацию клиента, но задание развёртывания по-прежнему использует учётные данные, принадлежащие уходящему подрядчику. Замена может редактировать код, но не может опубликовать одобренную сборку. Передача остаётся незавершённой.
Владелец организует подконтрольные проекту учётные данные развёртывания с правами, необходимыми для этого задания. Замена проверяет развёртывание и восстановление на тестовой цели. Затем команда выводит из эксплуатации старые учётные данные, проверяет оставшиеся ключи развёртывания и повторно запускает разрешённые проверки. Запись о закрытии ссылается на эти результаты, не содержа значения учётных данных.
Закройте с доказательствами и запланированным владением
Зафиксируйте владельца, принявшего передачу, каждую ссылку на отозванный доступ, время завершения, результаты тестирования замены и нерешённые исключения. Подтвердите, кто будет действовать при следующем сбое запланированного задания, продлении домена и задаче обслуживания. Согласуйте, как обрабатываются временные тестовые данные и копии проекта у подрядчика в рамках существующего соглашения.
Удаление доступа не может доказать, что исторические копии никогда не сохранялись. Учебное восстановление доказывает проверенный сценарий, а не все режимы отказа. Сохраняйте эти границы видимыми и переносите нерешённую работу в запись об операционной ответственности с указанием ответственного и срока.
Источники и проверка
Технические ссылки были проверены 12 сентября 2026 года. Примеры являются планировочными упражнениями; документация упомянутого программного обеспечения не подтверждает возможности услуг PrivateHostLab.