Как принять IT-инфраструктуру от прежнего админа: чек-лист передачи и аудит за неделю

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

Чем приёмка инфраструктуры отличается от обычной передачи дел

Когда читают «передача дел системного администратора, чек-лист», обычно имеют в виду взгляд уходящей стороны: собрать пароли, написать инструкцию, подписать бумагу. Я же последние годы чаще сижу с другой стороны стола. Мы в АйТи-Фреш берём чужую инфраструктуру на IT-аутсорсинг, и первое, что я говорю директору: передача дел и приёмка — это разные работы. Передача — это то, что админ готов показать. Приёмка — это то, что реально есть в сети, и эти два списка почти никогда не совпадают полностью.

Поэтому моя задача на старте не получить пароли, а построить собственную карту: что запущено, кто с чем может войти, что и куда копируется, за что и когда нужно платить. Пароли — только вход в эту карту. Уходящий админ может быть добросовестным и всё равно забыть про старый сервер в серверной, про учётную запись для сканера, про домен, который он когда-то купил на свою почту. Недобросовестный случай встречается реже, чем принято думать, а вот усталый, спешащий или просто не ведущий записей — постоянно.

Отдельно скажу про границы. Здесь речь об офисе до 50 рабочих мест: один-два сервера, домен Active Directory, облачная почта или своя, сетевое хранилище, пара коммутаторов, пара внешних сервисов. Если у вас сотни серверов и отдельная команда безопасности, у вас другие процедуры. А если вы смотрите на ситуацию со стороны ухода сотрудника — как собрать доступы до его последнего дня, — это отдельный разбор, и я его уже писал: передача дел при увольнении сисадмина. Здесь я иду от обратного: админа уже нет или он в режиме отработки, а отвечать за всё предстоит вам.

• передача — это рассказ прежнего админа, приёмка — это проверка того, что он рассказал
• результат приёмки — не набор паролей, а карта систем, список рисков и подписанный акт
• приёмка укладывается в пять рабочих дней, если не пытаться чинить найденное по ходу

День 1: что запросить до первого входа на серверы

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

Дальше прошу у директора и бухгалтерии то, чего у админа может не быть: договоры с провайдером, с хостером, с поставщиками ПО, последние платёжные документы за подписки. По счетам видно живую картину, потому что платят за то, что работает. Нашёл регулярный платёж за сервис, о котором никто не рассказал, — значит, где-то есть система, о которой тоже никто не рассказал. Это быстрее и надёжнее любых опросов. Параллельно прошу у прежнего админа не пароли, а его собственный список систем в любом виде: хоть таблица, хоть заметки. Мне важно не качество списка, а сам факт расхождений с тем, что я увижу при проверке.

Про сам процесс передачи доступов у меня есть отдельный короткий документ, и он про порядок, а не про технику: чек-лист отзыва доступов пригодится, когда сотрудник уже ушёл, и вам нужно закрыть всё, что на него завязано. На приёмке я его держу открытым параллельно, потому что каждая найденная учётная запись прежнего админа должна получить судьбу: отключена, заменена или осознанно оставлена. Самое неприятное решение — «пока не трогаем», принятое без записи в акте. Через год никто не вспомнит, почему так.

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

День 2: как проверить Active Directory и Windows-серверы

Домен — это центр приёмки, потому что в нём лежит большая часть прав. Начинаю с вопроса «кто здесь главный»: состав группы администраторов домена вместе с вложенными группами. На русскоязычной системе группа называется «Администраторы домена», а в командах для английской локали используется Domain Admins. Параметр -Recursive у Get-ADGroupMember разворачивает вложенные группы, а без него вы увидите только верхний уровень и пропустите тех, кто попал в права через промежуточную группу. Эту команду я запускаю в первый же час, потому что результат определяет остальной план.

Import-Module ActiveDirectory
Get-ADGroupMember -Identity 'Domain Admins' -Recursive | Select-Object Name,SamAccountName,objectClass
netdom query fsmo

Команда netdom query fsmo показывает, на каких контроллерах домена сидят пять ролей FSMO. Ей нужен запуск из консоли с повышенными правами, а доступна она там, где установлены роль AD DS или средства RSAT. Для маленького домена с одним контроллером вывод скучный, и именно это скучное «все пять ролей на единственном сервере» я заношу в акт как риск: нет резервного контроллера, а значит, отказ этого сервера останавливает вход пользователей. Если контроллеров два, смотрю, что роли распределены осознанно, а не оказались на старом сервере, который собираются выводить из эксплуатации.

Следующий шаг — «мёртвые души» и вечные пароли. Search-ADAccount умеет искать неактивные учётные записи за заданный период и учётные записи с паролем, который никогда не истекает. Параметр -TimeSpan принимает формат дни.часы:минуты:секунды, и значение 90.00:00:00 означает девяносто дней. Документация отдельно оговаривает, что поиск неактивных работает на функциональном уровне домена Windows Server 2003 и выше, но в 2026 году мы такие домены практически не видим.

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Select-Object Name,SamAccountName,Enabled,LastLogonDate
Search-ADAccount -PasswordNeverExpires -UsersOnly | Select-Object Name,SamAccountName,Enabled

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

Get-CimInstance Win32_Service | Where-Object { $_.StartName -and $_.StartName -notlike 'NT *' -and $_.StartName -ne 'LocalSystem' } | Select-Object Name,StartName,StartMode,State
Get-ScheduledTask | Get-ScheduledTaskInfo | Select-Object TaskName,LastRunTime,LastTaskResult,NextRunTime
Get-ScheduledTask | Select-Object TaskName,@{n='User';e={$_.Principal.UserId}}

Две последние команды дают список заданий планировщика с временем последнего запуска и результатом, а потом — с пользователем, от имени которого каждое выполняется. Именно здесь находится ночной бэкап, скрипт очистки, выгрузка в бухгалтерию. Если в столбце пользователя стоит учётная запись прежнего админа, то в день его отключения задание молча перестанет работать, и вы узнаете об этом позже, чем хотелось бы. Результат последнего запуска, отличный от нуля, — повод открыть задание и разобраться, а не закрыть глаза.

Дни 3-4: Linux-серверы, сеть, резервные копии и почта

Для Linux-серверов моя задача на приёмке та же: понять, что слушает сеть и кто может войти. Команда ss с ключами -tlnp выводит слушающие TCP-сокеты без разрешения имён и с процессами, которым они принадлежат: -t означает TCP, -l только слушающие, -n числовой вывод, -p процессы. Сравниваю список с тем, что мне рассказали. Лишний открытый порт баз данных или панели управления — это находка уровня «красный». Запускаю от администратора, иначе имена процессов не отобразятся. Затем ищу ключи доступа: чьи публичные ключи лежат в файлах authorized_keys у пользователей, особенно у root. Ключ прежнего админа, оставшийся на сервере, — такая же действующая учётная запись, как и пароль.

sudo ss -tlnp
sudo find /root /home -name authorized_keys

Резервные копии я проверяю последними по очередности, но первыми по важности. Расписание и комментарий в crontab ничего не доказывают: нужен сам файл копии, его дата и размер, а главное — пробное восстановление в отдельное место. Я разбирал такой случай подробно: копия считалась рабочей, а общий диск, куда она писалась, давно отвалился, и скрипт молча падал каждую ночь. Похожую историю с почтой я описал в статье про Zimbra без документации после ухода админа, и вывод тот же: проверяйте файлы, а не расписание. Минимальный тест приёмки — найти последнюю копию каждой критичной системы, определить её возраст и восстановить одну тестовую единицу: файл, базу, ящик.

С сетью и почтой работаю по тому же принципу «кто владелец и кто может изменить». У маршрутизатора и коммутаторов проверяю, есть ли доступ по управлению у кого-то кроме прежнего админа, не остался ли заводской или общий пароль, сохранена ли актуальная конфигурация. Для почты выясняю, где она живёт: своя инсталляция или облачный сервис, и кто там администратор. Если это облачный сервис, в консоли администратора должна быть учётная запись организации, а не личный ящик сотрудника. Проверяю и записи DNS: куда указывают MX-записи, кто управляет зоной. Забытая запись, ведущая на старый сервер, — частая причина сюрпризов при любых переездах.

В эти же дни собираю сведения о сроках поддержки. Windows Server 2016, например, по данным Microsoft Lifecycle, вышел из основной поддержки 11 января 2022 года, а расширенная заканчивается 12 января 2027 года, то есть на момент, когда я это пишу, осталось около трёх месяцев. Если у клиента такой сервер единственный контроллер домена, это не повод для паники, но миграцию нужно ставить в план прямо сейчас, а не «на следующий год». Точные даты по своей версии я всегда сверяю на странице продукта на learn.microsoft.com, а не по памяти.

• для каждой критичной системы найдена последняя копия, определён её возраст и проверено восстановление
• список слушающих портов сверен с тем, что рассказал прежний админ
• ключи и учётные записи прежнего админа на серверах и сетевом оборудовании найдены и учтены
• у почты и DNS есть владелец-организация, а не личный аккаунт
• сроки поддержки ОС и программ записаны в акт с датами

День 5: акт приёмки, оценка рисков и смена секретов

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

Акт должен подписать директор, а лучше и прежний админ, если он ещё в компании: подпись фиксирует, на какую дату и в каком состоянии компания приняла инфраструктуру. Это защищает обе стороны. Если через полгода выяснится, что бэкап не работал, станет ясно, что вы унаследовали это состояние, а не создали его. Для самой карты систем нужен постоянный носитель, и тут я не стал бы городить сложное: подойдёт любая понятная таблица или система учёта, главное, чтобы её обновляли. Про выбор подхода у меня написан отдельный разбор: инвентаризация IT-активов без Excel.

Теперь про секреты. Смену паролей я не откладываю, но и не начинаю с неё: сначала карта, потом замена, иначе легко сломать то, о чём не знал. Порядок такой. Сначала административные учётные записи и учётные записи на сетевом оборудовании, затем служебные учётные записи интеграций, затем пароли доступа к внешним сервисам. Отдельная история — учётная запись krbtgt: если прежний админ или кто-то ещё мог получить доступ к контроллеру домена, пароль этой записи тоже стоит сменить. По документации Microsoft, пароль krbtgt сбрасывают дважды, выдерживая между сбросами не менее десяти часов, потому что столько по умолчанию живёт максимальный срок билета; если в вашем домене политика изменена, ждать нужно дольше настроенного значения. Эту операцию я всегда делаю в согласованное окно и с готовностью к тому, что кто-то перезайдёт в сессию.

Новые секреты складываю в корпоративный менеджер паролей с общим доступом у двух ответственных, чтобы повторить историю с «одним человеком, который знает всё», было невозможно. Как это организовать без больших затрат, я описывал в материале про корпоративный менеджер паролей Bitwarden. Физические носители — токены, ключи, флешки с сертификатами — переходят в сейф организации с записью в акте о том, кто их выдал и кому.

• красный: единственный контроллер домена, неработающий бэкап, домен на чужом аккаунте
• жёлтый: ОС приближается к концу поддержки, общие и вечные пароли, лишние права
• зелёный: зафиксированные и осознанно принятые особенности без срочных действий

Как это выглядело на практике: платформа «Идея на миллион», 35 рабочих мест

Покажу на условном клиенте, чтобы цифры были осязаемыми. Краудфандинг-платформа «Идея на миллион», 35 рабочих мест: офис с доменом на двух Windows-серверах, сетевое хранилище, веб-приложение платформы на арендованном Linux-сервере. Штатный администратор проработал шесть лет и уволился, директор нашёл нас за неделю до его последнего дня. Договорились, что приёмку делаем в пять рабочих дней: два инженера, ведущий — я. В первый день ушло три часа на разговор с директором и бухгалтерией и четыре на бумаги: договоры, счета за год, регистратор домена.

Первая же сверка платежей дала картину, которой не было в списке админа: помимо хостинга и домена, оплачивался сервис рассылки писем, о котором никто не говорил. За ним стояла интеграция платформы, отправлявшая уведомления вкладчикам, и работала она от учётной записи прежнего админа. На второй день проверка домена показала, что оба сервера работают на Windows Server 2016, а роли FSMO стоят на единственном контроллере. Дату окончания расширенной поддержки, 12 января 2027 года, мы сверили на странице Microsoft и внесли в акт как жёлтый риск с планом миграции до конца года. Там же, у регистратора, выяснилось, что домен компании оформлен на личный аккаунт уволившегося админа.

На третий день разбирали Linux-сервер платформы. Список слушающих портов расходился со словами админа: наружу смотрел служебный интерфейс, которым пользовались только изнутри. Закрыли его правилами файрвола в тот же день. На четвёртый день проверяли резервные копии: копия базы платформы формально настраивалась, но при пробном восстановлении выяснилось, что самый свежий файл старше сорока дней, потому что задание перестало выполняться после смены пароля на сетевом хранилище. Это единственный красный пункт, который мы начали исправлять до подписания акта. Схожий сценарий я разбирал в материале про историю сбоя резервного копирования.

Итог пятого дня: акт на девять страниц, три красных пункта (резервная копия, единственный контроллер, домен на личном аккаунте бывшего админа), пять жёлтых и несколько зелёных. Красные закрыли за две недели: новое задание копирования с отчётом на почту двух ответственных, второй контроллер домена, перенос домена на организацию. Аудит обошёлся клиенту в 90 тысяч рублей: пять рабочих дней, из которых второй инженер был занят примерно половину времени, плюс подготовка документов. Для сравнения: восстановление платформы без свежей копии стоило бы недель простоя и репутации перед вкладчиками, а не девяноста тысяч.

Ошибки, из-за которых приёмка превращается в потерю контроля

Первая ошибка — довериться устному «всё работает». Работает ровно то, что вы проверили сами. Я включаю в акт столбец «как проверено» и не принимаю ответов вроде «вроде да». Вторая — начать менять пароли и удалять учётные записи на первом же часу. Так ломаются интеграции: сервис, который ходил на сервер под чьей-то учёткой, внезапно получает отказ, и вы узнаёте об этом по звонку недовольных людей, а не по плану. Сначала карта, потом замена.

Третья ошибка — принимать всё и сразу ради порядка, пытаясь заодно починить найденное. Приёмка отвечает на вопрос «что у нас есть и в каком состоянии», а исправление — отдельная работа с отдельным планом и согласованием окон. Если смешать, не получится ни того, ни другого, а директор не поймёт, за что платит. Четвёртая — оставить карту систем только в голове нового админа. Тогда вы вернулись в исходную точку: при следующем уходе всё повторится, просто с другим человеком.

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

Частые вопросы