Старое и новое состояние инфраструктуры после смены интегратора БЫЛО СТАЛО Один DC пароль ? VPN старые юзеры Бэкап ? не проверен Доступы у подрядчика SSL ? не у нас Документация — нет всё в голове ушедшего инженера Сертификат на кассу истекает через 8 дней DC01 + DC02 пароль наш VPN clean только активные Backup OK test-restore Bitwarden у заказчика SSL новый Wiki + сетевая схема + регламенты всё в Confluence/BookStack Сертификат перевыпущен + мониторинг expiry в Telegram 9 рабочих дней инженера 2-3 недели календарных
Состояние инфраструктуры до и после: чёрная дыра без документации превращается в управляемое окружение
· 19 мин чтения · Семёнов Е.С., руководитель ITfresh

Интегратор исчез — что делать: план восстановления проекта

Интегратор исчез — что делать: план восстановления проекта

Представьте ситуацию. Звонит нам торговая компания из Бутово, у них 28 рабочих мест, и это просто катастрофа: три недели назад их подрядчик-интегратор пропал, совсем не отвечает. Единственный инженер уехал, телефон заблокирован, и — вишенка на торте — никто не помнит пароль от контроллера домена. А через восемь дней ещё и сертификат на онлайн-кассе истекает! Звучит как анекдот, правда? Но, к сожалению, это реальность, с которой мы в ITfresh сталкиваемся постоянно, где-то 4-5 раз в год. Ниже я расскажу вам, как мы справляемся с такими проектами, шаг за шагом: что делаем в первые 24 часа, как возвращаем контроль над доступом, чем замещаем утерянную документацию, и во сколько это всё обойдётся.

Откуда берутся истории «интегратор исчез»

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

Сценарий 1. Подрядчик-одиночка ушёл

Пожалуй, это самый частый сценарий. Только представьте: три года в компании работал «один сильный сисадмин». Он, как говорится, держал всю IT-инфраструктуру на себе. А потом — бах! Человек просто исчезает. Заболел? Уехал за границу? Или, может, получил крутое предложение в банке? Неважно. Главное, что на связь он больше не выходит. И что самое неприятное? Документации, конечно, никакой нет! Ведь «всё было у него в голове», как любят говорить. Только в этом, 2025 году, я лично брался за шесть подобных проектов в Москве и Подмосковье.

Сценарий 2. Маленькая компания закрылась

А иногда бывает и такая история. Небольшая команда подрядчика, всего 3-4 человека, просто разваливается. Причины? Да какие угодно: бурные ссоры между партнёрами, внезапные налоговые проверки, или потеря крупного клиента. Конец один: заказчику никто не звонит, договор формально всё ещё действует, но доступы буквально «зависают в воздухе». Просто некому их передать. В 2025 году, между прочим, мы уже сталкивались с двумя такими случаями. И обе компании были не маленькие – по 30-40 рабочих мест.

Сценарий 3. Конфликт по деньгам

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

Сценарий 4. Целевой саботаж

Этот сценарий, пожалуй, самый редкий, но, поверьте, и самый мерзкий. Слава богу, случается такое не чаще, чем раз в 2-3 года. Что происходит? Уходящий подрядчик, словно назло, специально меняет все пароли. Стирает аккаунты из облачных сервисов. А бывает, ещё и переписывает регистратор домена на себя! Это уже не шутки. Тут, конечно, сразу в дело вступает статья 274 Уголовного кодекса. Начинается оперативная работа с полицией. Но в эти чисто юридические дебри я сейчас углубляться не стану, это отдельный разговор.

Что интересно, несмотря на все эти ужасные истории, алгоритм восстановления контроля всегда один и тот же. Разница лишь во времени реакции. Если мы сталкиваемся с очевидным саботажем, то действуем моментально, буквально за считанные часы. А когда это просто «режим тишины» от подрядчика, у нас есть запас в несколько дней.

Первые 24 часа: что я делаю в день звонка

Когда мне на телефон звонит руководитель какой-нибудь торговой компании и, едва сдерживая панику, почти кричит: «Е.С., наш сисадмин пропал! Что нам теперь делать?!», мой план на первые 24 часа всегда чёткий и отработанный. Выглядит он так:

Час 1-2. Заморозка периметра

Час 2-4. Инвентаризация по горячим следам

Первым делом я мчусь в офис клиента, а оттуда — прямиком в серверную. Моя главная задача? Описать абсолютно всё, что там вижу. Причём именно своими руками. Вот минимальный список того, что я скрупулёзно заношу в свой блокнот:

# Серверы
- HPE ProLiant DL360 Gen10, серийник CZ12345ABC, ILO 192.168.1.5
  - hostname VHOST01, гипервизор VMware ESXi 7.0u3
  - на нём: DC01, FS01, 1C-APP01, 1C-DB01
- Synology RS1221+, MAC 00:11:32:XX:XX:XX, IP 192.168.1.10
  - бэкапы, файловые шары, время восстановления неизвестно

# Сеть
- MikroTik CCR2004-1G-12S+2XS, IP 192.168.1.1
- Коммутатор HPE Aruba 2530-24G, IP 192.168.1.2
- Wi-Fi: UniFi U6-LR (3 шт.), контроллер CloudKey 192.168.1.3

# Внешний контур
- Домен company.ru — у регистратора REG.RU, доступ ?
- SSL-сертификаты: на сайте Let's Encrypt, на сервере 1С от КриптоПро
- Почта: Яндекс 360 Бизнес, админ-учётка ?

Мой блокнот — это фундамент для всей последующей работы, без него никуда. Пока один инженер обходит всю инфраструктуру, я не теряю времени. Сразу же связываюсь с бухгалтерией. Зачем? Чтобы найти любые старые письма от хостеров и регистраторов доменов. Там, поверьте, зачастую скрываются самые актуальные контакты!

Час 4-8. Поиск точек владения

А вот что меня волнует больше всего: где у клиента остался реальный административный контроль, а где он по факту всё ещё у того самого исчезнувшего подрядчика? Чтобы это быстро прояснить, я всегда составляю простую табличку. В ней три колонки: 'что' (это может быть сервер, сервис, домен), 'у кого' (кто этим управляет) и 'что делать' (какие шаги предпринять).

Ресурс              | Владелец            | Действие
--------------------|---------------------|------------------
DNS-зона company.ru | reg.ru, аккаунт ?   | Восстановить через паспорт директора
SSL-сертификат сайт | Let's Encrypt       | OK, перевыпустим автоматически
Сертификат на кассу | КриптоПро, носитель | Найти токен в сейфе, перевыпустить
Microsoft 365       | tenant ушедшего ИП  | Перенос tenant на ООО заказчика
Яндекс 360          | OK, на ООО          | Сменить пароль admin
Битрикс24           | OK, на ООО          | Сменить пароль и 2FA admin
1C 8.3              | KEY-USB у клиента   | OK
Камеры Hikvision    | Hik-Connect ?       | Сбросить регистратор, привязать заново
ИБП APC             | прошивка дефолт     | Сменить пароль APC NMC

К концу первого дня у меня на руках уже есть полная карта владения IT-активами. И, конечно, чёткий список приоритетов: что нужно закрыть первым делом, а что подождёт до второго.

День 2-3: возврат контроля над доменом и AD

Ну вот мы и подошли к самому щекотливому вопросу: Active Directory. Помните ту торговую компанию из Бутово, о которой я говорил в самом начале? У них был всего один контроллер домена — DC01 на Windows Server 2019. А в качестве гипервизора — старенький Hyper-V на Windows Server 2016. И пароль Domain Admin, вы ведь догадываетесь, никто, естественно, не помнит! Так что же мы делаем в таких ситуациях?

Сброс пароля локального админа гипервизора

Часто бывает, что на физическом сервере есть встроенный Windows-логин или какой-нибудь дефолтный типа «admin/admin». Но если это не наш случай, то я не пасую. Запускаюсь с PE-носителя (например, SystemRescue), монтирую системный диск, а потом с помощью утилиты chntpw сбрасываю пароль локального администратора прямо на хосте. Вся процедура, учитывая все необходимые перезагрузки, занимает обычно минут 30-40. Не больше.

Сброс пароля Domain Admin через DSRM

На контроллере домена есть специальная офлайн-учётка DSRM (Directory Services Restore Mode). И вот её пароль, как правило, подрядчики почему-то не записывают нигде. Но если вдруг, совершенно случайно, нам повезёт и пароль всё-таки найдётся — тогда я просто вхожу в DSRM-режим.

# На DC, перезагружаемся в Safe Mode With Networking
bcdedit /set safeboot dsrepair
shutdown /r /t 0

# В DSRM логин — .\Administrator с DSRM-паролем
# Дальше сбрасываем пароль доменного admin через ntdsutil
ntdsutil
   set instance to NTDS
   ifm
   create full c:\dump
   quit
quit

А что, если DSRM-пароль тоже пропал? Такое, кстати, случается в 60% случаев! Тогда мы переходим к плану B: либо правим NTDS офлайн через esedbexport и chntpw, либо поднимаем новый контроллер домена прямо из бэкапа. Это добавит ещё 4-6 часов к общему времени восстановления.

В том кейсе нам просто фантастически повезло! Главный бухгалтер, как оказалось, бережно хранила в сейфе тот самый "заветный конверт" с пометкой «На случай Х». И что там было? Угадайте! Там лежал и DSRM-пароль, и, что уж совсем удача, админский пароль от гипервизора. Выяснилось, что наш предыдущий подрядчик отдал их год назад, ещё при подписании договора, но, разумеется, про конверт этот никто и не вспоминал, пока не прижало.

Подъём второго DC немедленно

В тот же день я, не теряя ни минуты, сразу разворачиваю второй контроллер домена. Важно, что уже на отдельной виртуалке. Команда для этого, кстати, совсем стандартная:

Install-WindowsFeature -Name AD-Domain-Services,DNS -IncludeManagementTools

$DSRM = ConvertTo-SecureString "ITfresh!DSRM2026" -AsPlainText -Force
$Cred = Get-Credential -Message "Domain Admin"

Install-ADDSDomainController `
  -DomainName "corp.company.ru" `
  -InstallDns:$true `
  -Credential $Cred `
  -SafeModeAdministratorPassword $DSRM `
  -SiteName "Default-First-Site-Name" `
  -Force:$true

# Проверка репликации
repadmin /replsummary
repadmin /showrepl

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

День 4-5: смена паролей и инвентарь учёток

Моя задача номер один после этого? Вытащить вообще всё: полный-преполный список доменных учёток, локальных админов на каждом сервере, все сервисные аккаунты. Ну и, конечно же, общие почтовые ящики!

# Все доменные учётки
Get-ADUser -Filter * -Properties LastLogonDate, PasswordLastSet, Enabled |
  Select-Object SamAccountName, Enabled, LastLogonDate, PasswordLastSet |
  Export-Csv -Path "C:\audit\users.csv" -Encoding UTF8 -Delimiter ";"

# Сервисные аккаунты
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' -Properties PasswordNeverExpires |
  Select-Object SamAccountName, Description |
  Export-Csv -Path "C:\audit\service.csv" -Encoding UTF8 -Delimiter ";"

# Учётки в группе Domain Admins
Get-ADGroupMember "Domain Admins" |
  Get-ADUser -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate |
  Export-Csv -Path "C:\audit\admins.csv" -Encoding UTF8 -Delimiter ";"

# Локальные админы серверов через PSRemoting
Invoke-Command -ComputerName (Get-ADComputer -Filter 'OperatingSystem -like "*Server*"').Name `
  -ScriptBlock { Get-LocalGroupMember "Administrators" } |
  Select-Object PSComputerName, Name, ObjectClass

В кейсе торговой компании нашлось:

А что потом? Мы массово меняем пароли для каждой привилегированной учётки. И, конечно, безжалостно отключаем все "мёртвые души" — аккаунты сотрудников, которые давно уже не работают.

День 6-7: почта, облачные сервисы, сторонние API

После того, как разобрались с Active Directory, что дальше? Самое уязвимое место — это, как правило, публичные сервисы. Вот что мы увидели у одной торговой компании из Бутова:

День 8-9: документация и регламенты

Обычно к этому моменту я уже полностью контролирую всю инфраструктуру: доступы перевыпущены, мониторинг настроен. Кажется, финиш? Но это ещё рано радоваться! Проект совсем не закрыт, потому что без чёткой документации через год мы опять столкнёмся с тем, что «всё в голове». Поэтому я разворачиваю либо BookStack, либо Notion — здесь уже заказчик сам выбирает, что ему удобнее — и за два дня предельно подробно описываю всё-всё-всё:

Все-все пароли я моментально выгружаю в Bitwarden Vaultwarden. Важный нюанс: он ОБЯЗАТЕЛЬНО разворачивается на собственном сервере клиента, а не где-то у нас. Мы принципиально не пользуемся общим хранилищем подрядчика. Знаете, почему? Потому что именно это, по нашему опыту, и становится главной головной болью и первопричиной большинства проблем.

Что мы внедряем сразу, чтобы история не повторилась

Мы? Мы не просто приходим, всё чиним и испаряемся! Ни в коем случае. После нас у клиента остаются целых три полезных "подарка", которых, скорее всего, раньше и в помине не было:

1. Vaultwarden у заказчика

Во-первых, это, конечно, наш self-hosted менеджер паролей. Мы поднимаем его в Docker, обычно прямо рядом с уже существующими сервисами. Хотите знать самое главное? Все-все пароли остаются только у ВАС, у клиента. Да, у ITfresh есть своя рабочая учётка, но она с очень ограниченным доступом и только к нужным нам секциям. Истинный владелец и полный хозяин этого хранилища — только сам заказчик. Если вдруг наши пути разойдутся, никаких проблем: вы останетесь со всеми своими ключами в руках.

# docker-compose.yml для Vaultwarden
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: always
    environment:
      DOMAIN: "https://passwords.company.ru"
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: "ОченьДлинныйТокенДляAdminPanel2026"
      WEBSOCKET_ENABLED: "true"
      DATA_FOLDER: /data
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8088:80"

Перед самим Vaultwarden мы ставим nginx с Let's Encrypt — так безопаснее. А доступ к админ-панели? Его полностью закрываем, разрешая вход только с IP-адресов вашего офиса.

2. Уведомления в Telegram

Второй пункт — это наш мини-бот. Он круглосуточно шлёт алерты прямо в группу директора и сисадмина. Какие именно? Вот несколько примеров: упал контроллер домена (DC), истекает срок действия важного сертификата, диск на Synology забит уже на 85%, ночной бэкап не завершился, или fail2ban забанил какой-то подозрительный IP-адрес.

#!/bin/bash
# /opt/itfresh/check_certs.sh
DOMAINS="company.ru ofd.company.ru passwords.company.ru"
TOKEN="$(cat /opt/itfresh/.tg_token)"
CHAT="$(cat /opt/itfresh/.tg_chat)"

for D in $DOMAINS; do
  EXP=$(echo | openssl s_client -servername $D -connect $D:443 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  EPOCH=$(date -d "$EXP" +%s)
  NOW=$(date +%s)
  DAYS=$(( (EPOCH - NOW) / 86400 ))
  if [ $DAYS -lt 14 ]; then
    curl -s "https://api.telegram.org/bot${TOKEN}/sendMessage" \
      -d "chat_id=${CHAT}" \
      -d "text=SSL ${D} истекает через ${DAYS} дн."
  fi
done

Мы ставим этого бота в cron — он срабатывает каждый день ровно в 9:00 утра. Казалось бы, мелочь, да? Но только в 2026 году эта система спасла трёх наших клиентов от внезапно истёкших сертификатов!

3. Договор с пунктом «передача дел»

И последнее, но не менее важное. Загляните в любой наш договор с ITfresh. Вы там всегда найдёте очень чёткий пункт, где черным по белому прописано: «При расторжении договора подрядчик в течение 30 рабочих дней передаёт заказчику актуальную документацию, актуальные пароли в защищённом виде, а также полный перечень используемых сторонних сервисов с указанием владельца аккаунта». Что это значит для вас? Это юридически обязывает нас провести полноценную и прозрачную передачу всех дел. Клиент, благодаря этому, всегда чувствует себя на 100% защищённым.

Контр-нарратив: почему смена интегратора часто не решает проблему

Давайте будем честны: когда говорят, что «интегратор куда-то исчез», в половине случаев причина, увы, кроется на стороне самого заказчика. Это неприятная правда. Зачастую картина выглядит так: нерегулярные платежи, внедоговорные требования, затяжка с продлением подписки, а иногда и вовсе — инженеру просто не дают админ-доступ, когда он реально нужен для работы! Что происходит потом? Через год-два специалист выгорает и уходит. Вы меняете подрядчика, а через 18 месяцев история повторяется. Неужели это тупик?

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

FAQ: что чаще всего спрашивают клиенты

Что делать в первые 24 часа после ухода интегратора?

С чего начинать? Сразу же меняйте пароль администратора домена — это самое главное! Обязательно отключите весь VPN-доступ для всех учёток бывшего подрядчика. И не забудьте забрать ключи: от офиса, от серверной — вообще всё. А дальше что? Проверьте наличие резервного контроллера домена. Самое важное: убедитесь, что бэкапы хотя бы за прошлые сутки доступны и их можно прочитать. Только когда весь этот список выполнен, можно спокойно выдохнуть и уже начинать искать нового подрядчика.

Может ли уходящий подрядчик заблокировать вашу инфраструктуру?

Может ли бывший подрядчик нанести вред? Технически — да, вполне. Если у человека есть админ-доступ к таким критическим точкам, как домен, гипервизор, регистратор домена, BitLocker-ключи или почтовый сервер, он запросто может оставить после себя «мину» или перевести все лицензии на свой личный аккаунт. Это очень неприятно! Но вот юридически — нет, такие действия попадают напрямую под статью 274 УК РФ. На нашей практике, кстати, с реальным саботажем мы сталкиваемся редко, лишь в одном случае из десяти. Чаще всего подрядчик просто перестаёт брать трубку. Это не саботаж, это скорее… просто тишина.

Сколько стоит у ITfresh подбор после ушедшего интегратора?

Сколько стоит привести всё в порядок? За аудит и разработку чёткого плана восстановления вы заплатите 30-40 тысяч рублей. Это примерно один-два дня работы нашего инженера. Полное же восстановление контроля над вашей системой, а затем и переход на наш аутсорсинг, обойдётся от 80 до 150 тысяч рублей. Тут всё зависит от текущего состояния вашей инфраструктуры. Для примера: торговым компаниям с 25-50 рабочими местами (РМ) на это требуется, как правило, 9-12 полных рабочих дней. Но в реальности, с учётом всех нюансов, процесс может растянуться и на две-три календарные недели.

Что делать, если у подрядчика были все мейл-сертификаты и SSL-ключи?

Мой личный совет: перевыпускайте абсолютно всё! Не жалейте времени. SSL-сертификаты — их можно выпустить заново через Let's Encrypt или запросить у того же CA. S/MIME-сертификаты ваших сотрудников? Отозвать через УЦ и выдать новенькие. А как быть с API-токенами сторонних сервисов? CRM, телефония, эквайринг — неважно что, но их нужно перевыпускать только с нуля. Да, такая работа добавит ещё 2-3 дня к общему сроку. Но поверьте, это единственный по-настоящему честный, надёжный способ закрыть вообще все возможные лазейки в безопасности.

Как выбрать нового подрядчика, чтобы история не повторилась?

Какие пункты обязательно должны быть в вашем договоре? Первое: чёткое обязательство передавать клиенту абсолютно все пароли в его собственном Bitwarden/KeePass-хранилище. И не просто передавать, а проводить контрольную сверку раз в месяц! Второе: полноценное SLA, где детально прописана процедура передачи дел в случае расторжения. На это должно быть отведено 30 рабочих дней, и, конечно, с обязательной документацией. Третье: доступы к регистратору домена и вообще ко всем облачным сервисам всегда должны быть оформлены на учётке заказчика. Подрядчику же предоставляйте только делегированный доступ. И, ради бога, наш самый горячий совет: никогда не нанимайте подрядчика, если у него в команде всего один человек! Это не просто риск, это настоящая бомба замедленного действия под вашу инфраструктуру.

Итог

Что делать, если бывший подрядчик просто исчез? Перехват проекта — это не магия и не колдовство. Это чёткая, отработанная нами методика. Обычно она занимает 9 рабочих дней инженера, включает большой чек-лист из 40 пунктов и требует строгого соблюдения базовых правил безопасности. Но самое-самое главное — действовать нужно максимально быстро, буквально в первые 24 часа! Что именно? Срочно сменить все пароли, отключить VPN, провести полную инвентаризацию активов. А всё, что последует за этим, — это уже полноценный технический проект на две-три недели. Если вы сейчас столкнулись именно с такой бедой, просто напишите мне. Я приеду на первичный аудит прямо в течение этого же рабочего дня.

Похожая задача в вашей компании?

Расскажите мне, что у вас происходит прямо сейчас — я пришлю вам план работ и оценку стоимости в течение этого же рабочего дня.

Написать в Telegram  или  +7 903 729-62-41

Семёнов Е.С., руководитель ITfresh

Подпишитесь на рассылку ITfresh

Каждую неделю мы выпускаем свежие, практические гайды специально для IT-руководителей и сисадминов. Мы делимся нашими знаниями: говорим о безопасности, нюансах 1С, успешных миграциях, надёжных резервных копиях и, конечно, лайфхаках, которые проверены на реальных проектах.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.