Как сменить ИТ-подрядчика и не потерять доступы, данные и управление

Коротко. Смена ИТ-подрядчика опасна не самим переходом, а потерей управления: доступами, доменом, лицензиями и знаниями об инфраструктуре. Порядок действий: назначить внутреннего владельца перехода, собрать перечень активов, проверить, на кого оформлены домен и ключевые сервисы, создать собственные административные доступы, убедиться в работоспособности резервных копий — и только потом сообщать прежней команде. Доступы меняются по приоритету, окончание работы прежнего подрядчика фиксируется письменно.

Смена ИТ-подрядчика часто откладывается не из-за удовлетворённости сервисом, а из-за страха: «вдруг у текущей компании останутся пароли», «мы не знаем, на кого оформлен домен», «новые специалисты ничего не поймут». Эти риски реальны, но управляемы, если провести переход как отдельный проект.

Главная задача — вернуть компании контроль над собственной инфраструктурой. Новый подрядчик вторичен: сначала нужно убедиться, что критичные активы и права принадлежат заказчику.

1. Назначьте владельца перехода

Со стороны компании должен быть человек, который утверждает приоритеты и имеет право запрашивать информацию. Это может быть директор, операционный руководитель или ответственный за ИТ. Он не обязан разбираться в технических деталях, но должен контролировать полноту передачи.

2. Соберите перечень активов

Минимальный список включает:

• доменные имена и DNS;
• корпоративную почту;
• сайты и хостинг;
• серверы и виртуальные машины;
• облачные кабинеты;
• сетевое оборудование;
• лицензии и подписки;
• телефонию;
• 1С, CRM и базы данных;
• резервные копии;
• системы удалённого доступа;
• сертификаты и ключи;
• репозитории исходного кода;
• договоры с провайдерами.

Важно установить не только местонахождение, но и владельца учётной записи, способ оплаты и контакт для восстановления доступа.

3. Проверьте, на кого оформлены ключевые сервисы

Домен, облачный аккаунт или лицензия не должны быть зарегистрированы на личную почту сотрудника подрядчика. Лучше использовать корпоративный адрес компании и отдельный административный профиль.

Если сервис оформлен на подрядчика, необходимо заранее согласовать перенос. Иногда он требует подтверждения владельца, документов или времени на обработку заявки.

4. Создайте резервные административные доступы

Не меняйте все пароли в первый день без плана: можно случайно остановить интеграции или потерять связь с оборудованием. Сначала создайте независимые учётные записи компании с достаточными правами и проверьте вход.

Для каждого критичного сервиса желательно иметь:

• основную административную учётную запись;
• резервный способ восстановления;
• двухфакторную аутентификацию, привязанную к контролируемому устройству;
• запись в корпоративном менеджере паролей.

5. Проверьте резервные копии до конфликта

До завершения отношений с прежним подрядчиком убедитесь, что у компании есть доступ к резервным копиям и понятен порядок восстановления. Желательно выполнить тестовое восстановление хотя бы одной критичной системы.

Если резервная копия хранится только в инфраструктуре подрядчика, согласуйте экспорт или перенос.

6. Запросите документацию

Полезный комплект передачи содержит:

• схему сети;
• адресный план;
• список серверов и сервисов;
• описание резервного копирования;
• перечень внешних интеграций;
• инструкции по аварийному запуску;
• контакты провайдеров;
• список открытых проблем и незавершённых работ;
• историю существенных изменений.

Документация может быть краткой. Важнее актуальность, чем объём.

7. Организуйте совместный период

Лучший вариант — несколько дней или недель, когда прежняя и новая команды могут обмениваться вопросами через представителя заказчика. Это сокращает риск догадок и повторного исследования инфраструктуры.

Совместный период не означает передачу новых паролей старому подрядчику. Доступы меняются по согласованному плану, а вопросы фиксируются письменно.

8. Составьте карту зависимостей

Изменение одного пароля может остановить резервное копирование, интеграцию CRM, отправку уведомлений или автоматический обмен с 1С. Поэтому перед ротацией секретов важно понять, где они используются.

Для каждого административного доступа зафиксируйте:

• сервис;
• владельца;
• зависимые системы;
• дату смены;
• результат проверки после смены.

9. Меняйте доступы по приоритету

Обычно начинают с наиболее критичных внешних точек:

1. Домены и DNS.
2. Облачные кабинеты и хостинг.
3. Почта и административные панели.
4. VPN и удалённый доступ.
5. Серверы и гипервизоры.
6. Сетевое оборудование.
7. Прикладные системы.
8. Сервисные учётные записи и API-ключи.

После каждого этапа нужно проверить работоспособность связанных сервисов.

10. Зафиксируйте окончание доступа прежней команды

В конце перехода составьте перечень закрытых учётных записей, отозванных ключей и удалённых доверенных устройств. Попросите прежнего подрядчика письменно подтвердить, что рабочие копии данных и секретов удалены в соответствии с договором.

Каких ошибок избегать при смене подрядчика

• Не начинать с конфронтации и мгновенной блокировки всех доступов, если нет признаков злоупотребления.
• Не передавать новому подрядчику старую общую учётную запись «admin» как единственный доступ.
• Не считать скриншот паролей полноценной передачей инфраструктуры.
• Не удалять старые резервные копии до проверки новых.
• Не менять DNS, почту и серверы одновременно без плана отката.

Что проверить в первые недели после перехода

В течение первых недель полезно внимательно следить за:

• ошибками резервного копирования;
• недоставленными письмами;
• сбоями интеграций;
• неожиданными запросами двухфакторной аутентификации;
• попытками входа старых учётных записей;
• истечением сертификатов и лицензий;
• обращениями пользователей по ранее скрытым проблемам.

Смена подрядчика — удобный момент для наведения порядка. Но цель перехода не в том, чтобы заменить одно имя в договоре. Компания должна получить прозрачную инфраструктуру, собственные административные права и понятные правила работы новой команды.