Утечка данных через ИИ стала угрозой для бизнеса

Сценарий тривиальный: сотрудник копирует тело письма, фрагмент CRM-выгрузки или черновик договора в публичный LLM — и текст уходит за периметр инфраструктуры, минуя MX, DLP и журналы почтового шлюза. Для инженера почтовой инфраструктуры это новый канал эксфильтрации, на котором стандартные проверки MTA бессильны.

Канал эксфильтрации вне MTA

Источники фиксируют типовые сценарии: вставка тела письма в чат-бот, загрузка вложений в облачные LLM, обработка скриншотов переписки. Ключевая проблема — данные уходят через HTTPS к сторонним сервисам, а не через корпоративный SMTP. MX, MTA-STS и DKIM-проверки здесь не отрабатывают: трафик идёт с рабочей станции напрямую в браузере.

Проверьте на почтовом шлюзе наличие и корректность правил DLP для исходящих вложений с грифом. Если правил нет — начните с регулярных выражений под ИНН, паспортные данные, клиентские email-базы и привяжите их к postfix-фильтру или milter. Это не остановит LLM-канал, но даст точку отсчёта и инвентаризацию чувствительных потоков.

Что закрыть на периметре

Запретите исходящий SMTP/SMTPS с рабочих станций наружу. Оставьте только relay через корпоративный MTA. Один outbound-канал — одна точка логирования. Прикройте также web-mail клиенты: прямой SSL на smtp.gmail.com, smtp.office365.com, smtp.mail.ru с рабочих хостов — резать ACL на edge.

Настройте HTTP-egress filtering на прокси: блокируйте SNI публичных LLM по FQDN-спискам. Разрешайте только одобренные корпоративные AI-эндпоинты. Проверьте SPF домена: записей вида v=spf1 include:_spf.google.com ~all недостаточно — добавьте -all и уберите wildcard, иначе подделка уведомлений от «AI-сервиса» откроет вектор фишинга поверх домена.

Что отслеживать и как проверить

Поведенческие аномалии на MAPI/RPC: массовое копирование в буфер обмена в рамках одного mailbox, особенно перед увольнениями — типовой предиктор утечки через LLM. Реализуется через Outlook COM-надстройку или хук на клиенте с инкрементальной отправкой телеметрии в SIEM.

SNI-потоки к доменам вида *.openai.com, *.anthropic.com, *.google.com/aichat — собирайте в SIEM, привязывайте к подразделениям через ACL. Аномальный всплеск по конкретному OU — повод для блокировки egress на уровне VLAN.

DMARC-политика получателей: если домен рассылает «AI-уведомления», подписывайте их DKIM и держите DMARC=p=reject у крупных провайдеров. Иначе подделка под корпоративный AI-сервис станет готовым вектором для credential phishing.

Команды первичной проверки:

dig TXT example.com | grep "v=spf1" | grep "*"
nslookup -type=txt _dmarc.example.com
nslookup -type=mx example.com
tcpdump -i eth0 -nn 'src net 10.0.0.0/8 and (dst port 25 or dst port 465 or dst port 587)'
grep -E "CONNECT.*443" /var/log/squid/access.log | awk '{print $7}' \
| sort | uniq -c | sort -rn | head -50

Первый запрос покажет wildcard в SPF. Второй и третий — корректность DMARC и MX. Четвёртый — попытки прямого SMTP с рабочих станций. Пятый — топ исходящих HTTPS-эндпоинтов: если среди лидеров внезапно появились LLM-домены — это уже факт, а не гипотеза.

Отдельный разбор конкретных кейсов и регуляторики — впереди. Задача инженера сейчас: закрыть egress, вернуть потоки в зону контроля и зафиксировать baseline до того, как утечка проявится в отчёте DLP.