Как информация утекает из компании: каналы и способы контроля

Что считать утечкой и почему обычный доступ не равен разрешению на передачу

У сотрудника может быть законный рабочий доступ к ценам или клиентам и при этом отсутствовать право передать всю базу другой компании. Поэтому важно определить не только «кто может открыть», но и «что можно выгружать, кому и с каким согласованием».

Утечка — это раскрытие сведений тем, кто не должен их получать. Удаление или шифрование данных затрагивает доступность, а подмена реквизитов — целостность; последствия могут сочетаться. Наличие резервной копии не возвращает секретность уже переданного документа.

Стоимость защиты и возможный ущерб разобраны в статье о бюджете ИБ. Здесь внимание на том, каким путём сведения покидают рабочую среду и где должен сработать контроль.

Девять каналов, которые стоит проверить в компании

Почта

Вложения, адресаты и пересылка наружу.

Мессенджеры

Личные чаты, группы и отправка файлов.

Облака и ссылки

Внешние получатели и общедоступные папки.

USB и носители

Копии документов и потерянные устройства.

Печать

Бумага в общем лотке и забытые документы.

Фото и экран

Личный телефон, снимки и демонстрация экрана.

Выгрузки из систем

Отчёты, API и копии баз данных.

Подрядчики и удалённый доступ

Рабочие права за пределами своей команды.

ИИ-сервисы и интеграции

Загрузка документов, запросы и журналы.

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

Как взлом превращается в утечку: цепочка одного инцидента

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

SMTP spoofing и SMTP smuggling: разные способы обмануть почтовую цепочку

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

Для администратора нужны корректная аутентификация доменов SPF/DKIM/DMARC, проверка политики входящей почты, маршрутов через шлюз и исключений. Один SPF pass не подтверждает добросовестность письма и не означает, что видимое имя принадлежит нужному человеку. Похожие домены и захваченные ящики требуют дополнительных проверок. См. официальное описание защиты от spoofing Microsoft.

SMTP smuggling — отдельный серверный вектор. Он связан с разным толкованием границ почтового сообщения участниками цепочки. Для защиты проверяют актуальные исправления и настройки конкретных MTA и шлюзов. Это не синоним любой подмены имени. Пример подтверждённой проблемы Postfix — уведомление безопасности Ubuntu. Оно описывает историческую уязвимость, а не доказывает, что ваш обновлённый сервер уязвим сейчас.

• Проверять подозрительное требование через известный канал: официальный кабинет или заранее известный контакт, а не номер и ссылку из письма.
• Не разрешать всю почту «от налоговой» или поставщика одним широким исключением из фильтрации.
• Разобрать тестовое письмо на разрешённом стенде: результаты проверок, применённое правило и фактическая доставка.

«Пришёл PDF из налоговой, но не открылся»: что могло произойти

ФНС предупреждала о вредоносных письмах от её имени. Значок PDF и знакомое имя отправителя не подтверждают происхождение файла. Возможны несколько разных ситуаций:

• Файл только выглядит как документ. Расширение скрыто, а открывается исполняемый файл, сценарий или ярлык. Имя «Требование.pdf.exe» не делает его PDF.
• Это настоящий PDF со ссылкой. Документ показывает «ошибку» или предлагает вход для просмотра; пользователь попадает на поддельную страницу и отдаёт доступ к почте.
• Документ эксплуатирует уязвимость просмотрщика. Риск зависит от программы, версии и исправлений; нельзя утверждать, что любой PDF запускает код.
• Вложение просит помочь ему выполниться. «Включите содержимое», «установите обновление», «снимите защиту» — действие пользователя может стать частью атаки.

Варианты фишинга через вложения и захвата доступа описаны в документации Microsoft. Неоткрывшееся окно не доказывает отсутствие запуска; открывшийся настоящий документ тоже не доказывает безопасность всей цепочки.

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

Меры: показывать расширения файлов; проверять вложения средствами почты; обновлять ОС и просмотрщики; применять защиту устройств и согласованные политики запуска; разделять рабочую и административную учётные записи. При подозрении на запуск — прекратить работу с вложением, связаться с ИТ/ИБ известным способом и изолировать узел по регламенту. Самостоятельная очистка и повторное открытие письма мешают разбору.

Расширения и внешние обработки 1С: это исполняемый код

«Новый отчёт», «исправление обмена» или «печатная форма» из письма могут требовать запуска кода в рабочей среде. Внешняя обработка .epf, отчёт .erf и расширение .cfe — разные механизмы; их нельзя считать обычными безопасными вложениями только из-за знакомой темы. 1С описывает внешние обработки как отдельные файлы с выполняемой функциональностью.

1. Ограничить установку и подключение. Определить, кто может добавлять расширения, открывать внешние обработки и менять защитные параметры.
2. Получать файл по доверенному каналу. Проверять источник и целостность; подпись, если она предусмотрена поставкой, дополняет проверку, но сама по себе не доказывает безвредность.
3. Испытать на отдельной базе с подходящими тестовыми данными. Согласовать доступ к файлам, сети, внешним компонентам и другим ресурсам. Рабочие секреты не переносить в тест автоматически.
4. Пересмотреть разрешения по принципу необходимости. Каждое отключение безопасного режима или защиты от опасных действий должно иметь конкретное основание. Просьба подрядчика «снять все галочки, чтобы заработало» не является достаточным обоснованием.
5. Разделить уровни прав. Роль в базе, безопасный режим выполнения и полномочия процесса 1С в ОС решают разные задачи. Не запускать службу под избыточно привилегированной учётной записью без необходимости.
6. Вести реестр изменений. Версия, дата, автор, доступы, результат проверки и возможность отключения. Периодически сверять реестр с реально установленным.

Доступные средства зависят от платформы, конфигурации и лицензий. Профили безопасности кластера могут ограничивать потенциально опасные действия; официальные материалы 1С относят их к функциональности КОРП. Их нельзя обещать как универсальную настройку любого сервера ПРОФ.

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

Почта: ошибочный адресат, личный ящик и автоматическая пересылка

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

• Определить, какие данные допускаются во внешней переписке и с какими получателями.
• Проверять вложения и контекст отправки доступными средствами почты или DLP; внешние предупреждения должны быть понятны сотруднику.
• Ограничить и учитывать внешнюю автоматическую пересылку, проверять изменения правил и входы.
• Предоставить разрешённый способ удалённой работы, чтобы личный ящик не стал единственным удобным вариантом.

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

Шифрованное соединение с почтовым сервером защищает передачу по сети, но само по себе не делает получателя допустимым. Письмо может быть защищено транспортом и всё равно уйти не тому человеку.

Мессенджеры, облачные ссылки и ИИ-сервисы

Личный чат или группа

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

Папка «доступна всем по ссылке»

Инженер передаёт заказчику один проект, но открывает всю папку. Предпочтительны конкретные получатели, ограниченный срок доступа и минимальный набор файлов. Проверяют вложенные права, старые ссылки и доступ подрядчиков. Закрытие ссылки останавливает дальнейшее обращение через неё, но не удаляет уже скачанные копии у получателя.

Документ в публичной нейросети

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

Управление ограниченными доменами, браузерами и приложениями показано в документации Microsoft Purview Endpoint DLP. Это пример реализации, а не обещание тех же функций во всех продуктах и редакциях.

Флешка, принтер, фотография: когда информация выходит физически

Съёмный накопитель

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

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

Печать и бумага

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

Снимок экрана и личный телефон

Запрет штатного скриншота не запрещает фотографирование внешним устройством. Маркировка, персонализированные водяные знаки, расположение рабочих мест и правила посещения могут уменьшить риск или помочь разбору, но не дают универсальной гарантии. Устную передачу сведений также нельзя перекрыть одним программным агентом.

Механизмы Endpoint DLP и ограничения поддерживаемых действий приведены в официальном описании Microsoft. Для пилота проверяют именно ваш путь работы с документом, а не только самый удобный демонстрационный пример.

Выгрузки из 1С, CRM, файловых серверов и интеграций

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

• Разделять просмотр, экспорт, администрирование и доступ к резервным копиям.
• Сопоставлять массовую выгрузку с задачей пользователя: большой объём может быть законной сверкой, а не нарушением.
• Учитывать временные папки, общие каталоги обмена и копии на рабочих станциях.
• Проверять сервисные учётные записи, API-токены и состав журналов интеграции.
• Ограничивать доступ к резервным копиям: полная копия может раскрывать больше, чем рабочая роль в приложении.

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

Контроль передачи дополняет ограничение исходного доступа: широкая роль не должна позволять получать сведения без рабочей необходимости.

Подрядчики и удалённый доступ: допуск по заявке, сроку и полномочиям

Типичная проблема: подрядчику однажды выдали общий пароль администратора и постоянный удалённый доступ. Работы давно закончились; подключиться по-прежнему можно. Компрометация компьютера или учётной записи подрядчика становится входом в инфраструктуру заказчика.

Более строгий порядок должен быть проверяемым:

1. Заявка до подключения. Кто выполняет работу, в какой системе, что меняет, когда начинает и заканчивает; владелец системы подтверждает объём.
2. Именная учётная запись и MFA. Без общего входа для всей команды. Не отправлять подрядчику основной пароль доменного администратора как универсальный пропуск.
3. Управляемая точка входа. Утверждённый VPN/шлюз или промежуточный узел с доступом только к нужным адресам. Не оставлять произвольные RMM-программы и прямые административные входы «на всякий случай».
4. Временные минимальные права. Просмотр там, где его достаточно; повышение под конкретное действие и ограниченное окно, если платформа это поддерживает.
5. Контроль передачи. Файлы, буфер обмена, локальные диски и печать разрешаются по задаче. Копия производственной базы для разработки требует отдельного решения и защиты данных.
6. Наблюдаемая работа. Сеанс и изменения связаны с исполнителем и заявкой; журналирование, а при необходимости запись сессии организованы с ограниченным доступом и согласованным порядком.
7. Закрытие работ. Проверить результат, остановить активные подключения, отозвать временные роли, токены и доступы. Общие секреты, ставшие известными исполнителю, менять по согласованному плану.
8. Периодическая сверка. Список разрешённых средств доступа и исполнителей сопоставляется с фактическими учётными записями и установленными программами.

Разделение привилегированного доступа и путей входа рассматривает модель доступа Microsoft. Конкретный механизм выбирают под инфраструктуру; один VPN без ограничения прав не решает задачу.

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

Три прикладные ситуации и что считать результатом

Ситуации модельные, не истории клиентов. Событие само по себе не доказывает намерение: для вывода нужны контекст, исходные записи и проверка фактов.

Какие средства что контролируют

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

Логику политик можно посмотреть в описании Microsoft Purview DLP. Для конкретного проекта ограничения и исключения выясняют до покупки.

Примеры систем: отечественные и зарубежные

• InfoWatch Traffic Monitor — контроль потоков и обработка событий; перечень каналов и условия развёртывания сверяют по поставке.
• СёрчИнформ КИБ — DLP и инструменты разбора внутренних инцидентов; при пилоте проверяют выбранные модули и нужные рабочие среды.
• Zecurion DLP — анализ событий, предотвращение и расследование; конкретные каналы и действия проверяют в используемой версии.
• Microsoft Purview Endpoint DLP — пример зарубежной платформы с контролем на поддерживаемых устройствах и в экосистеме Microsoft. Права использования, состав лицензий и доступность сервиса проверяют отдельно.

Первые три — примеры российских производителей. Это не рейтинг и не утверждение, что один пакет закрывает все каналы. Нужна матрица «ОС → приложение → действие → реакция → ограничение», а также оценка поддержки и хранения событий. Подробное назначение класса DLP разобрано в отдельной статье.

Как внедрить контроль потоков без блокировки обычной работы

1. Выбрать важные категории. Клиентские выгрузки, условия закупок, чертежи, кадровые документы — с владельцем и понятным критерием.
2. Описать реальные пути. Какая почта, ОС, приложения, удалённый доступ, принтеры и мобильные устройства используются.
3. Согласовать рабочие исключения. Разрешённый подрядчик, допустимый формат отчёта, временная передача по конкретной задаче.
4. Провести тесты на обезличенных данных. Разрешённая отправка проходит; запрещённая получает заданную реакцию. Проверяется результат у получателя.
5. Назначить обработку событий. Кто читает уведомление, уточняет основание и принимает решение; куда обращаться при ошибочной блокировке.
6. Пересмотреть охват после изменений. Новая версия браузера, ОС или мессенджера может изменить наблюдаемость канала.

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

Если передача уже произошла: как организовать разбор

1. Зафиксировать факты. Что передано, когда, каким способом и кому; различить подозрение и подтверждённую доставку.
2. Остановить дальнейший доступ. По согласованному порядку закрыть ссылку или лишние права, ограничить скомпрометированную учётную запись. Не считать это удалением уже полученных копий.
3. Сохранить исходные записи. Журналы, идентификаторы сообщений и объектов, временные отметки и настройки. Не уничтожать следы поспешной очисткой.
4. Определить затронутые данные и последствия. Проверить связанные каналы, внешних получателей и обязательства компании.
5. Передать решение уполномоченным лицам. Владелец данных, ИБ, руководство и другие ответственные определяют дальнейшие действия и необходимость уведомлений.
6. Исправить причину и повторить тест. Не ограничиваться удалением одной ссылки, если такая же ошибка возможна в других папках.

Подход к ответственным, реагированию и регулярным проверкам приведён в NIST SP 1300. Это методический ориентир; конкретные сроки и обязанности зависят от применимых требований и ситуации.

Что учитывать в эксплуатации и бюджете

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

Измеряют охват нужных узлов и каналов, состояние агентов, число подтверждённых и ложных срабатываний, время обработки и результат контрольных проверок. Большой объём собранных сообщений сам по себе не доказывает качество защиты.

Архив DLP может содержать чувствительные сведения. Его доступ, резервирование, аудит действий администраторов и срок хранения требуют защиты. При облачном размещении отдельно согласуют, где находятся события и содержимое, кто имеет доступ и как организованы соединения с рабочими системами.

Две памятки для обследования и проверки

Организовать доступы, контроль и сопровождение

Частые вопросы о контроле утечек