Состояние инфраструктуры до и после: чёрная дыра без документации превращается в управляемое окружение

Аудит и приём дел 3 мая 2026 · 19 мин чтения · Семёнов Е.С., руководитель ITfresh

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

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

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

За 15 лет работы я насмотрелся на четыре типичных сценария, которые приводят к одному и тому же результату — заказчик остаётся без инженера и без доступов:

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

Самый частый случай. У клиента три года работал «один сильный сисадмин», который вёл всё единолично. Заболел, эмигрировал, нашёл работу в банке — выбрал любой из этих путей и просто перестал брать трубку. Документации нет, потому что она «вся в голове». В 2025 году я лично подобрал шесть таких проектов в Москве и области.

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

Подрядчик из 3-4 человек развалился по внутренним причинам — ругань между партнёрами, налоговая проверка, потеря крупного клиента. Заказчику никто не звонит, контракт не закрыт, доступы зависли в воздухе. Два таких случая в 2025 — обе компании были на 30-40 РМ.

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

Заказчик задолжал подрядчику 200-300 тысяч, тот перешёл в режим «тишины»: не реагирует на запросы, не закрывает заявки. Формально на договоре стоит подпись, но реальной поддержки нет. Здесь надо разруливать сначала юридически, потом технически.

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

Самый редкий и самый неприятный — около одного случая в 2-3 года. Уходящий подрядчик меняет пароли, удаляет аккаунты в облачных сервисах, переводит регистратор домена на свою учётку. Тут включается 274 УК и оперативная работа с полицией, но я не буду углубляться — это юридическая история.

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

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

Когда мне звонит руководитель торговой компании и говорит «Е.С., у нас исчез сисадмин, что делать», план первых 24 часов выглядит так:

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

Сменить пароль учётки Domain Admin и любых других учёток с правами «уровня бога»;
Отключить все VPN-сертификаты и L2TP/IKEv2-учётки, которыми мог пользоваться подрядчик;
Заблокировать на роутере все правила «remote access for IT» из доверенных IP подрядчика;
На MikroTik отключить порт SSH и Winbox с интернета, оставить только из локальной сети;
Сменить пароли админок всех публичных сервисов: SSL VPN на UTM, panel почтового сервера, личный кабинет хостера, регистратор домена.

Час 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

К концу первого дня у меня есть карта владения и список приоритетов — что закрываем в первую очередь, что во вторую.

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

Самый чувствительный момент — Active Directory. У торговой компании из Бутова был один контроллер DC01 на Windows Server 2019, в роли гипервизора — старый Hyper-V на Windows Server 2016. Пароль Domain Admin никто не помнит. Что делаю:

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

На физическом сервере встроенный Windows-логин обычно дефолтный или «admin/admin». Если нет — поднимаю с PE-носителя SystemRescue, монтирую системный диск, через chntpw сбрасываю пароль локального administrator на хосте. На это уходит 30-40 минут вместе с перезагрузками.

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

На контроллере домена есть отдельная offline-учётка 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 — Offline NTDS edit через esedbexport + chntpw, либо подъём нового DC из бэкапа. Это вторые 4-6 часов работы.

В нашем кейсе нам повезло — главный бухгалтер хранила в сейфе конверт с надписью «На случай Х», там был DSRM-пароль и пароль admin для гипервизора. Подрядчик передавал их год назад, в момент подписания договора, и про конверт никто не вспоминал.

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

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

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. Если бы он умер — паралич офиса на сутки минимум. С двумя 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

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

4 неактивные учётки бывших сотрудников, которые не отключали 1-2 года;
3 сервисных аккаунта с PasswordNeverExpires (нестандартно для нашей практики);
1 учётка ITSupport с правами Domain Admin и last logon вчера — это и был ушедший подрядчик;
2 учётки backup-svc и monitoring-svc с неизвестным паролем — пришлось пересоздавать.

Дальше — массовая смена паролей всех привилегированных учёток + отключение «мёртвых душ» сотрудников.

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

Самая уязвимая часть после AD — это публичные сервисы. У торговой компании из Бутова было:

Microsoft 365 tenant — числился на ИП ушедшего инженера. Это типичная ловушка: подрядчик регистрирует tenant на себя, потом «не отдаёт» при расторжении. Я отправил запрос в Microsoft Support, через 4 рабочих дня tenant перевели на юрлицо заказчика по уставным документам и доверенности директора;
Яндекс 360 Бизнес — здесь было проще, организация привязана к ИНН компании, я через директора восстановил пароль admin@yandex и сменил его на длинный из менеджера паролей;
Битрикс24 — admin-учётка с почтой ушедшего сотрудника. Через техподдержку Битрикс24 восстановили доступ через паспорт директора-основателя за 2 рабочих дня;
МойСклад — учётка владельца числилась на бухгалтера, она просто залогинилась и сменила пароли;
Эквайринг и онлайн-касса — здесь была минимальная драма: сертификат КриптоПро для отправки чеков в ОФД истекал через 8 дней. Перевыпустили срочно через УЦ за 12 000 рублей;
Telegram-боты для уведомлений склада — токен у подрядчика, мы его ротировали через @BotFather под учёткой генерального.

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

К этому моменту инфраструктура под контролем, доступы перевыпущены, мониторинг настроен. Но проект ещё не закрыт — без документации через год снова будет «всё в голове». Я разворачиваю BookStack или Notion (по выбору заказчика) и в течение двух дней пишу:

Сетевая карта. Схема всех VLAN, IP-плана, серверов, точек Wi-Fi, камер, принтеров. Делаю в Draw.io, экспортирую в PNG и SVG;
Реестр доступов. Все учётные записи с указанием, на кого зарегистрированы, где хранятся пароли, у кого 2FA;
Регламенты на типовые операции. Заведение нового сотрудника (пошагово), увольнение, выдача нового ноутбука, восстановление файла из бэкапа;
SLA. Время реакции по приоритетам инцидентов, контакты команды ITfresh, эскалация на руководителя;
Plan of action на типичные аварии. Что делать, если упал интернет; что делать, если упал 1С; что делать, если истёк сертификат кассы; что делать, если зашифровал шифровальщик.

Все пароли я сразу выгружаю в 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 и закрываем доступ к admin-панели по 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 рабочих дней передаёт заказчику актуальную документацию, актуальные пароли в защищённом виде, перечень используемых сторонних сервисов с указанием владельца аккаунта». Это юридически обязывает нас сделать передачу — и заказчик чувствует себя защищённым.

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

Скажу неприятное. В половине случаев причина «интегратор исчез» — на стороне заказчика. Платили нерегулярно, требовали работ за рамками договора, тянули с продлением подписки, не выделяли инженеру admin-доступ когда надо. Через год-два инженер выгорает и уходит. Меняешь подрядчика — повторяется через 18 месяцев.

Я честно говорю на первой встрече: половина успеха IT-аутсорсинга — это адекватный заказчик. Если в компании принято звонить инженеру в 23:00 в воскресенье «у меня не печатает дома принтер» — и при этом задерживать оплату на 3 месяца — никакой подрядчик не выживет. Перед тем как искать нового интегратора, заказчику стоит честно посмотреть на свою сторону отношений.

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

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

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

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

Технически — да. Если у него админ-доступ к домену, гипервизору, регистратору домена, BitLocker-ключам или почтовому серверу — он может оставить мину или перевести лицензии на свой аккаунт. Юридически — нет, такие действия попадают под 274 УК. На практике мы видим саботаж в одном случае из десяти — обычно подрядчик просто не отвечает на звонки, и саботажа нет, есть тишина.

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

Аудит и план восстановления — 30-40 тысяч рублей за 1-2 дня инженера. Полное восстановление контроля и переход на наш аутсорсинг — 80-150 тысяч в зависимости от состояния инфраструктуры. Для большинства торговых компаний 25-50 РМ это 9-12 рабочих дней растянутых на 2-3 недели календарного времени.

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

Перевыпустить всё. SSL — заново через Let's Encrypt или по заявке у того же CA, S/MIME-сертификаты сотрудников — отозвать через УЦ и выпустить новые. Все API-токены сторонних сервисов (CRM, телефония, эквайринг) — перевыпустить с нуля. На это уходит 2-3 дня дополнительной работы, но это единственный честный способ закрыть лазейки.

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

Договор с обязательством передавать заказчику все пароли в Bitwarden/KeePass-хранилище заказчика — раз в месяц контрольная сверка. SLA с описанием передачи дел в случае расторжения — 30 рабочих дней с обязательной документацией. Доступы к регистратору домена и облачным сервисам — на учётке заказчика, у подрядчика только делегированный доступ. И никогда не нанимайте подрядчика, у которого в команде один человек — это бомба замедленного действия.

Итог

Подбор проекта после ушедшего подрядчика — это не магия, а методика. 9 рабочих дней инженера, чек-лист из 40 пунктов, базовые правила безопасности. Главное — действовать в первые 24 часа: сменить пароли, отключить VPN, инвентаризовать активы. Дальше — это уже технический проект на 2-3 недели. Если у вас сейчас именно такая ситуация — напишите, я приеду на первичный аудит в течение рабочего дня.

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

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

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

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