Узгодьте вікно передачі та власників
Підтвердьте, хто уповноважений затверджувати передачі та відкликати доступ. Назвіть власника клієнтського акаунта, підрядника, який виходить, оператора-замінника та особу, яка може допомогти, якщо доступ зламається. Узгодьте граничний термін, дозволені зміни під час перекриття та докази, потрібні до завершення.
Майте актуальний інвентар проєкту, узгоджений обсяг робіт і доступ до безпечної системи облікових даних клієнта. Встановіть, як працює відновлення акаунта, перш ніж видаляти оператора, який виходить. Якщо передача відбувається після підозри на компрометацію, власник реагування на інцидент має визначити час локалізації; звичайна послідовність перекриття може бути недоречною.
Інвентаризуйте володіння окремо від доступу для входу
Перелічіть для кожної послуги власника акаунта, поточних операторів, ідентичності автоматизації, власника відновлення та потрібну дію передачі. Вхід адміністратора не вирішує, хто контролює виставлення рахунків або відновлення. Записуйте лише посилання на облікові дані або відбитки відкритих ключів; ніколи не вносьте паролі, токени, приватні ключі чи коди відновлення до цього реєстру.
Прокрутіть горизонтально, щоб побачити всі стовпці таблиці.
| Актив проєкту | Питання володіння | Доказ завершення |
|---|---|---|
| Домен і DNS | Хто контролює реєстратора, поновлення та контакт для відновлення? | Власник підтверджує доступ і поточні записи. |
| Хостинг і сервер | Хто контролює акаунт, консоль і привілейованих користувачів? | Замінник самостійно перевіряє необхідний доступ. |
| Репозиторій і розгортання | Хто володіє репозиторієм, автоматизацією та обліковими даними для розгортання? | Затверджений випуск розгорнуто на ізольованій цілі. |
| Застосунок та інтеграції | Хто адмініструє CMS, пошту, API та заплановані завдання? | Перевірки ролей та інтеграцій записано. |
| Резервні копії та відновлення | Хто контролює сховище резервних копій і будь-який потрібний матеріал для розшифрування? | Замінник виконує ізольовану вправу з відновлення. |
Передайте володіння та операційні знання
Використайте підтримуваний механізм передачі або запрошення цієї послуги, а потім нехай власник-отримувач перевірить контроль зі свого власного акаунта. Уникайте прийняття особистої ідентичності підрядника як спільного входу. Перевипустіть облікові дані проєкту через затверджену безпечну систему там, де раніше їх надавав особистий акаунт.
Для репозиторіїв GitHub передача зберігає пов’язані секрети, ключі розгортання та вебхуки, а наявні співробітники можуть залишитися. Перегляньте їх явно після передачі. Квитанція про передачу засвідчує зміну власника, а не завершення видалення доступу.
Надайте посилання на випуск, версії середовища виконання, розташування конфігурації, заплановані завдання, зовнішні залежності, обсяг резервного копіювання та процедуру відновлення. Додайте відомі збої та наступне завдання з обслуговування. Поясніть, де облікові дані отримуються безпечно, не копіюючи їхні значення до документації.
Дозвольте заміннику виконати роботу
Попросіть замінника виконати письмову процедуру, не позичаючи сеанс підрядника. Він має отримати затверджене джерело, розгорнути на ізольованій тестовій цілі, знайти корисні журнали та продемонструвати дозволене завдання адміністрування застосунку. Записуйте кожен пропущений крок, потім оновіть інструкції та повторіть відповідну перевірку.
Нехай вони відновлять узгоджену резервну копію в окреме тестове призначення з вимкненими або перенаправленими вихідними інтеграціями. Перевірте репрезентативні записи, завантаження та поведінку застосунку. Запишіть ідентифікатор резервної копії, ціль, витрачений час і невирішені прогалини. Не перезаписуйте продакшн, щоб продемонструвати відновлення, і не тлумачте успішне завдання резервного копіювання як завершений тест відновлення.
Видаліть доступ того, хто виходить, на всіх маршрутах
Після підтвердження заміни доступу та відновлення видаліть підрядника з відповідних команд, репозиторіїв, хостингових акаунтів і ролей у застосунку. Перегляньте активні сесії та відкличте проєктні токени, інтеграції та облікові дані, які вони могли зберегти. Якщо облікові дані є спільними, випустіть їхню заміну, оновіть залежні сервіси та протестуйте їх, перш ніж виводити з експлуатації старе значення. Повторіть завдання заміни після відкликання, щоб виявити приховану залежність від старих облікових даних.
Ключі розгортання GitHub залишаються активними, коли їхнього творця вилучено з репозиторію. Перевіряйте їх окремо, зокрема права на запис і машину, яка використовує кожен ключ. Для авторизованих застосунків OAuth власник акаунта має переглянути список застосунків і відкликати застарілі авторизації за допомогою засобів керування GitHub.
Для доступу SSH визначте фактичну конфігурацію авторизації за відкритим ключем. OpenSSH документує, що AuthorizedKeysFile вибирає файли, які використовуються для автентифікації за відкритим ключем; не припускайте, що кожен сервер використовує один типовий файл. Збережіть перевірений шлях відновлення та перевірте нове з'єднання заміни й необхідні привілеї, перш ніж закрити сеанс обслуговування.
Приклад: репозиторій переміщено, але розгортання — ні
У цьому вигаданому сценарії Cedar Workshop змінює підрядника свого вебсайту. Репозиторій потрапляє до організації клієнта, але завдання розгортання все ще використовує облікові дані, що належать підряднику, який вибуває. Заміна може редагувати код, але не може опублікувати затверджену збірку. Передача залишається незавершеною.
Власник організовує контрольовані проєктом облікові дані для розгортання з дозволами, потрібними для цього завдання. Заміна перевіряє розгортання та відновлення на тестовій цілі. Потім команда виводить з експлуатації старі облікові дані, переглядає решту ключів розгортання та повторно запускає дозволені перевірки. Запис про закриття посилається на ці результати, не містячи значень облікових даних.
Закрийте з доказами та запланованим володінням
Запишіть власника, який прийняв передачу, кожне посилання на відкликаний доступ, час завершення, результати тестування заміни та невирішені винятки. Підтвердьте, хто діятиме в разі наступного запланованого збою завдання, поновлення домену та завдання обслуговування. Домовтеся, як поводитися з тимчасовими тестовими даними та копіями проєкту, що їх тримає підрядник, згідно з чинною угодою.
Видалення доступу не може довести, що історичні копії ніколи не зберігалися. Навчання з відновлення доводить перевірений сценарій, а не кожен режим відмови. Тримайте ці межі видимими та переносьте невирішену роботу до запису про операційну відповідальність із призначеним власником і терміном.
Джерела та перевірка
Технічні посилання було перевірено 12 вересня 2026. Приклади є навчальними вправами; документація згаданого програмного забезпечення не встановлює можливості послуг PrivateHostLab.