Короткая версия этой истории уже разошлась: оптовая компания, стройматериалы, штат около 40 человек, два крупных клиента внезапно ушли к конкуренту на почти идентичных условиях. Владелец заказал аудит «на всякий случай» — и дыра оказалась не в файрволе и не в паролях, а в привычке одного менеджера копировать прайсы и переписку в бесплатную зарубежную нейросеть, чтобы та красиво оформляла коммерческие предложения.
В коротком посте я рассказал сюжет и цену вопроса. Здесь — техническая часть: как такие утечки на самом деле работают с точки зрения инфраструктуры, почему их почти невозможно заметить без специального инструментария, и что конкретно нужно настроить, чтобы это не повторилось.
Где технически была дыра
Формально в компании не было взлома в привычном смысле — никто не подбирал пароль и не эксплуатировал уязвимость в CRM. Дыра была архитектурной:
- исходящий трафик из офиса никак не фильтровался — сотрудник мог обратиться к любому внешнему API;
- не было DLP-системы (Data Loss Prevention), которая ловит исходящие файлы с маркерами «коммерческая тайна» или паттернами номеров телефонов/цен;
- учётные записи в сторонних сервисах регистрировались на личную почту сотрудника — компания физически не видела, что там происходит;
- прокси-сервер логировал только факт соединения, но не содержимое запроса (TLS без инспекции).
Именно поэтому история четыре месяца оставалась незамеченной: с точки зрения ИТ-отдела это был обычный HTTPS-трафик на домен зарубежного сервиса, ничем не отличающийся от чтения новостей.
Как это эксплуатируется
Разберём по шагам, как аудитор (а по факту — точно так же и злоумышленник или конкурентная разведка) обнаруживает и подтверждает подобный канал утечки.
Шаг 1. Поиск shadow IT в исходящем трафике
Первое, что смотрится при аудите — куда вообще ходит трафик из офисной сети. На прокси или на зеркалированном порту коммутатора это делается так:
tcpdump -i eth0 -n 'tcp port 443' -w office_traffic.pcap
# затем разбор SNI из TLS ClientHello без расшифровки
tshark -r office_traffic.pcap -Y "tls.handshake.extensions_server_name" \
-T fields -e tls.handshake.extensions_server_name | sort | uniq -c | sort -rn
Типичный результат такого разбора для компании без политики ИИ выглядит примерно так:
1420 chat.openai.com
980 api.deepseek.com
340 bard.google.com
12 vpn.company.local
Уже на этом этапе видно: сотрудники массово ходят на внешние LLM-сервисы, а компания об этом не знает и, соответственно, ничего не контролирует.
Шаг 2. Перехват содержимого запроса
Дальше нужно понять, что именно уходит наружу. Для этого поднимается прозрачный TLS-прокси с собственным корневым сертификатом, установленным на тестовую машину (в реальном аудите — с письменного согласия владельца бизнеса):
mitmproxy --mode transparent -p 8080 --set confdir=~/.mitmproxy
# на клиенте — маршрутизация трафика через прокси
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080
В перехваченных запросах к API нейросети видна структура POST-запроса — фактически это и есть канал утечки:
POST /v1/chat/completions HTTP/1.1
Host: api.deepseek.com
Content-Type: application/json
Authorization: Bearer sk-****************
{
"model": "deepseek-chat",
"messages": [
{"role": "user", "content": "Составь письмо клиенту ООО «...», прайс: цемент М500 — 4800 руб/т со скидкой 12%, условия отсрочки 30 дней, контакт снабженца +7 9**-***-**-**"}
]
}
Это ровно тот момент, в котором коммерческая тайна и персональные данные физлица покидают периметр компании и уходят на сервера стороннего оператора, юрисдикция которого никак не регулируется 152-ФЗ.
Шаг 3. Проверка, куда физически уходят данные
whois $(dig +short api.deepseek.com | head -1)
nslookup api.deepseek.com
В большинстве случаев ответ показывает хостинг за пределами РФ, без договора обработки персональных данных с компанией и без каких-либо гарантий по 152-ФЗ. Пользовательское соглашение бесплатных нейросетей почти всегда содержит пункт об использовании загруженного контента для дообучения модели — то есть прайс и переписка юридически «покидают» компанию навсегда.
Шаг 4. Почему это не гипотетический риск
В январе 2025 года исследователи Wiz Research публично сообщили, что сама компания-разработчик одной из популярных нейросетей оставила в открытом доступе базу ClickHouse на портах 8123 и 9000 — без аутентификации, с логами чатов, историей запросов и внутренними API-ключами. Проверить открытость такого сервиса — вопрос одной команды:
nmap -p 8123,9000 -sV target_ip
PORT STATE SERVICE VERSION
8123/tcp open http ClickHouse HTTP API
9000/tcp open tcp ClickHouse native protocol
Мораль простая: даже если бы менеджер использовал платную «корпоративную» версию нейросети, это не гарантирует, что данные не окажутся в открытом доступе из-за ошибки конфигурации на стороне провайдера. Компания в такой схеме полностью зависит от чужой инфраструктуры и чужой культуры безопасности.
Что и почему сработало бы дальше
Дальнейшее развитие такой утечки не требует хакерских навыков — достаточно любопытства или недобросовестной конкуренции:
- Прямое совпадение условий. Если у конкурента оказался доступ к тем же данным (через утечку у провайдера, через инсайдера, через компрометацию аккаунта менеджера) — предложить клиенту чуть более выгодные условия не составляет труда: точные цифры скидок и отсрочек уже известны.
- Компрометация самого аккаунта в нейросети. Личные почтовые аккаунты сотрудников регулярно всплывают в утечках баз (Collection #1 и подобные дампы). Проверка на скомпрометированность — рутинная операция:
Если пароль от почты совпадает с паролcurl -s "https://haveibeenpwned.com/api/v3/breachedaccount/manager@gmail.com" \ -H "hibp-api-key: $KEY"