Прием ИТ-инфраструктуры после увольнения системного администратора: что проверить в первую очередь

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

Речь идет не только о пароле администратора Windows или Linux. В список должны попасть учетные записи облачных платформ и хостинга, сетевого оборудования, корпоративной почты, VPN, систем резервного копирования, баз данных, доменных регистраторов, DNS, антивирусов и других сервисов.

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

Поэтому все критичные аккаунты необходимо перевести на корпоративные адреса и номера телефонов, а пароли хранить в корпоративном менеджере паролей с ограниченным доступом.

Сам факт передачи списка логинов и паролей еще не означает, что передача доступов в компании завершена.

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

У него могут существовать отдельная учетная запись администратора, VPN-доступ, SSH-ключи, токены API, доступ к облаку или резервному хранилищу. Некоторые из них невозможно обнаружить простой сменой одного пароля.

Поэтому контроль ИТ-доступов после увольнения должен включать отключение персональной учетной записи сотрудника, смену общих административных паролей, отзыв активных сессий, токенов и ключей, проверку VPN и удаленного доступа.

Особое внимание стоит уделить общим учетным записям вроде admin, которыми пользовались несколько сотрудников. Если ушедший специалист знал пароль, его необходимо изменить.

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

Фраза «бэкапы настроены» ничего не гарантирует.

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

Поэтому при приеме ИТ-инфраструктуры нужно проверить не только наличие резервного копирования, но и возможность восстановления.

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

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

Если никто, кроме увольняющегося администратора, никогда не восстанавливал данные из резервной копии, для компании это отдельный риск.

Следующий этап – понять, что вообще находится под управлением ИТ.

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

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

Например, бухгалтерская система может работать на виртуальном сервере, база данных – на другом, резервные копии – сохраняться в отдельное хранилище, а удаленный доступ сотрудников – зависеть от VPN-шлюза. Простого пункта «1С – сервер №3» для передачи такой системы недостаточно.

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

Часть инфраструктуры может находиться за пределами компании.

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

Отдельно стоит проверить регулярные платежи.

Типичный риск: облачный сервис или домен годами оплачивается с банковской карты сотрудника. После его увольнения автоматическое продление прекращается, и проблема обнаруживается только после отключения услуги.

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

То же касается лицензий: компания должна понимать, какие лицензии используются, на кого они оформлены и когда требуют продления.

Смена системного администратора – удобный момент для небольшого аудита инфраструктуры.

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

Необязательно устранять все проблемы до последнего рабочего дня предыдущего администратора.

Важно другое: составить перечень рисков и определить приоритеты.

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

Так компания получает не просто переданную инфраструктуру, а понимание ее реального состояния.

Прием ИТ-инфраструктуры можно считать завершенным, когда у компании есть:

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

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