Современные компании всё чаще сталкиваются с тем, что даже самые дорогостоящие DLP-системы, призванные пресекать утечку чувствительных данных, не справляются со своей задачей, когда дело доходит до привычных рабочих инструментов. В условиях, когда организации вынуждены обеспечивать продуктивную удалённую и гибридную работу сотрудников, многие каналы коммуникации целенаправленно разрешаются, чтобы не мешать бизнес-процессам. Однако именно в этой технологической повседневности и кроется множество высокорисковых лазеек для легких и практически невидимых утечек данных, которые полностью обходят вложенные в DLP-мониторинг миллионы.
Акцент на формальное соответствие требованиям законодательства, таким как 152-ФЗ, часто сводит усилия ИБ к техническому минимуму: закупку лицензий, внедрению базовых ограничений на внешние накопители и пресечению очевидных попыток рассылки документов на внешние почты. Риски, возникающие из новых моделей работы – через облачные сервисы – при этом не получают должного внимания, хотя именно они позволяют без следа обходить привычные инструменты контроля.
Зачем защищаться от Google Docs, если он для работы?
Каждая организация, подчёркивающая своё внимание к обработке персональных и коммерческих данных, строго исполняет классический набор защитных мер: корреспонденцию отслеживают через mail-gateway, запрещают вставлять флешки, актуализируют антивирус, закупают «большую» DLP. В каком-то виде присутствует и web-фильтрация, блокируются сторонние обменники и подозрительные сайты, а все подозрительные активности, казалось бы, должны быть замечены и зафиксированы.
Тем не менее, чтобы сотрудники не тратили время на пересылку документов себе же, но между подразделениями, обычно разрешают key business tools — такие как Google Docs, Яндекс.Диск, облако Microsoft 365, «корпоративные» Google Drive, Confluence, Bitrix24, lessoften DropBox и другие. Сквозь прокси и DLP такие сервисы часто пускают на уровне домена без минимальной инспекции содержимого: технически невозможно постоянно расшифровывать внутренний трафик к ресурсам, которыми пользуются все отделы. Кроме того, многие компании идут дальше, организуя федерацию рабочих аккаунтов Google Workspace, интеграцию облака с почтой и собственными сервисами, и тем самым ещё сильнее вписывая Google Docs в производственные процессы.
Проблема здесь состоит в ложном чувстве защищенности: администратор считает, что через Google Docs «ничего такого» нельзя утянуть, ведь это внутренний ресурс компании, а его использование прозрачно. Но тот же Google Docs по умолчанию предоставляет достаточно широкий функционал совместного доступа, публикации и рассылки приглашений, который превращает его в настоящий «черный ход» для утечки информации.
В повседневной суматохе редко кто мониторит внутренние операции с доступом к документам — их количество велико, а события отличаются разнообразием, затрудняя выделение подозрительного поведения стандартными средствами.
Три способа превратить документ в канал утечки
Google Docs — это не только удобное облачное пространство для коллективной работы, но и технологически сложный сервис, заточенный на быструю совместную работу без бюрократии. Из-за этого опасность возникает не на техническом, а на процессном уровне: сотрудники получают возможность передать доступ к информации далеко за пределы компании, обосновывая свои действия необходимостью исполнения служебных обязанностей.
1. Ссылка с доступом «для всех»
В интерфейсе Google Docs стандартно доступна опция «Доступ по ссылке», при которой любой человек, получивший URI, может читать, комментировать или даже редактировать документ, независимо от наличия корпоративного аккаунта. Это значительно ускоряет обмен с подрядчиками и партнёрами, но также открывает уязвимость: ссылка может быть передана в личный мессенджер или другую нелегируемую зону, а обнаружить такую передачу на уровне корпоративной DLP практически невозможно.
Для системы контроля трафика это выглядит как обычное взаимодействие с разрешенным внутренним ресурсом — никаких явных признаков передачи секретных данных не возникает, а сам документ остаётся храниться на инфраструктуре, обслуживаемой Google. Поскольку большинство DLP настроены на блокировку отправки файлов наружу, а не на отслеживание изменений прав доступа в SaaS-сервисах, событие остаётся незамеченным.
[ИЗОБРАЖЕНИЕ: Скриншот интерфейса Google Docs с открытым меню «Настройки доступа», где выбрана опция «Всем, у кого есть ссылка»]
2. Добавление внешнего соавтора
Ещё одна стандартная опция — возможность пригласить к редактированию пользователей вне вашей доменной зоны. Например: сотрудник добавляет в документ адрес консультанта, партнёра или даже свой личный email. Вся активность проходит по каналам Google: внешнему соавтору отправляется приглашение на email, а дальше он пользуется всеми правами — копирует, экспортирует, дублирует данные или даже делает новую ссылку для кого угодно.
Для DLP-системы это формально «легальный» трафик — обычная серверная активность, разрешённый внешний участник, не подозрительная загрузка. Только специализированные средства аудита или SIEM в Google Workspace позволяют заметить смену состава участников, однако стандартный внешний DLP этого «не увидит» без интеграции с облаком.
Настоящая сложность такого сценария — отсутствие интуитивной связи между «фактом утечки» и привычными каналами передачи данных. Информация формально не покидает сервис Google Docs, но её получатель уже не является сотрудником компании, а «просачивание» происходит исключительно за счёт осознанного управления правами внутри интерфейса SaaS-платформы.
3. Публикация документа в виде веб-страницы
Самая незаметная и трудно отслеживаемая возможность — создание публично доступной web-страницы на основе документа или таблицы Google. Адрес страницы может быть отправлен кому угодно и открыть мгновенный анонимный доступ без паролей и регистрации. Результирующая ссылка выглядит штатно, сервис работает со стандартными API-командами. Обнаружить, какие конкретно документы были опубликованы, DLP не сможет — тем более что зафиксированные соединения НЕ соответствуют схеме пересылки файла за пределы сети. В технических логах отображаются только адреса запросов и базовые параметры, без контента и указания реального получателя.
[ИЗОБРАЖЕНИЕ: Визуализация календаря активности вокруг публикации документа из Google Docs с фиксацией передачи уникальной ссылки вне корпоративной инфраструктуры]
Почему DLP стоимостью 2 млн рублей это пропускает?
Рынок DLP развивается по классической модели противодействия известным угрозам: системы анализируют почтовый трафик, вложения, сетевые соединения по цепочке «отправил — зафиксировал — заблокировал». Большинство средств формируют три ядра контроля:
- Почтовый канал: мониторинг и блокировка вложений и подозрительных текстовых формулировок, алертинг по попытке отправки защищаемых данных по email, в том числе через веб-почты.
- Физические носители: контроль вставки, шифрование или тотальное блокирование USB, DVD, SD, а также логирование всех действий с файлами на этих носителях, отслеживание всех перетаскиваний/копирований интересующих объектов.
- Web-трафик & облака: DMZ, прокси с DPI-анализом, блокировка подозрительных web-форм, FTP, обменников, категоризация доменов и подпись подозрительной активности на популярных файлообменниках.
Однако распространение облачных платформ, особенно тех, что глубоко интегрированы в корпоративные процессы, привело к появлению целых групп доверенных сервисов, к которым системные администраторы вынуждены открывать «сквозные» соединения без деградации скорости. В отношении этих сервисов (Google Docs, 365, Confluence и пр.) DLP работает в «режиме доверия» — не проводит инспекцию сессий, шифровка и внутренние запросы не декодируются, а значит анализируется только metadata активности.
В реальности поведение с точки зрения системы выглядит следующим образом:
| Действие сотрудника | Что видит DLP или сеть | Почему не возникает тревоги |
|---|---|---|
| Создание публичной ссылки на документ Google Docs | Запрос внутреннего API Google или смена метаданных уровня доступа | Технически не происходит отправки файла за пределы организации, файл формально остаётся «на месте» |
| Передача ссылки через Telegram Web | Зашифрованный трафик между workstation и web.telegram.org | Если дешифровка трафика невозможна, поток выглядит как обыденная переписка. DLP не имеет критериев для триггера инцидента. |
| Открытие ссылки внешним получателем | Запрос к Google Docs с внешнего IP, download или просмотр документа | Событие происходит полностью вне периметра компании; возможности отследить, что по этой ссылке скачали документ, у DLP нет. |
| Добавление внешнего соавтора | Изменение состава группы доступа в SaaS, смена ACL в облаке | В большинстве решений не считается тревожной активностью; рассылка происходит в инфраструктуре поставщика (Google), а не через корпоративные сети. |
| Публикация web-версии документа | Системные логи только фиксируют очередной API-вызов Google | Как и в первом случае, формально никаких «утечек» не происходит — только меняется доступность документа для новых или анонимных пользователей. |
Записи, которые фиксирует DLP, не дифференцируют действия, связанные с изменением уровня доступа в облаках. Если у организации отсутствуют интеграции с SIEM или Cloud Access Security Broker (CASB), аумтация реагирования на массовое расширение доступа или публикации невозможна. Поэтому даже дорогая DLP становится «слепой зоной» — она отлично анализирует то, что прописано в политиках, и пропускает невидимое в сценариях работы через доверенные сервисы.
[ИЗОБРАЖЕНИЕ: Архитектурная схема: DLP фиксирует традиционные каналы утечки, но «облако» остаётся серой зоной между сотрудником и интернетом]
Особенности следов и расследования инцидентов
Подобные сценарии утечки уникальны тем, что минимизируют цифровые, технические и поведенческие следы. Внутренняя сеть действительно видит только трафик к разрешённым адресам Google или к внешним мессенджерам (если они разрешены). В логах прокси и DLP появляется стандартная активность — никаких признаков загрузки, отправки файлов или генерации большого трафика.
Типовой лог-поток выглядит так:
- Просмотр и периодическое обновление документов на docs.google.com.
- API-запросы к облаку с передачей идентификаторов, не раскрывающих содержимое.
- Переходы по ссылкам приглашений не отличимы от рабочих запросов — такие же адреса, те же user-agent, схожая продолжительность сессий.
Расследование таких инцидентов может быть построено только на:
- Полном анализе логов доступа к облачным сервисам (добавления участников, публикации, смены ACL), интеграции с SIEM и выработке специальных корреляционных правил.
- Отслеживании передачи ссылок через корпоративные мессенджеры (Telegram, WhatsApp Web), если они логируются или поддаются SSL-инспекции на периметре.
- Восполнении пробелов за счёт организации программ лояльности и внутреннего контроля за массовой аномальной сменой прав доступа или резким ростом числа публикаций, доступных по ссылке.
На практике, лишь малая доля компаний из сегмента среднего и крупного бизнеса централизует облачные логи Google Workspace и анализирует их на предмет «расшаривания» вовне, да и то редко реагируя проактивно. Более того, облачные политики Google по умолчанию настроены на удобство, а не на безопасность, поэтому навигацию и обнаружение подозрительного изменения прав доступа лучше всего решать через интеграцию Cloud Audit Log и автоматические алерты SIEM.
Что делать, чтобы закрыть эту лазейку?
Попытки полностью запретить Google Docs, Microsoft 365 и схожие инструменты в современном офисе имеют высокую цену для бизнеса — теряется производительность, усложняется обмен даже неперсональными некритичными данными, возникают обходные пути, которые ещё хуже управляются. Решать проблему нужно комплексно, комбинируя технические, организационные и даже поведенческие меры.
- Разграничение доступа по устройствам и сетям: Настроить доступ к разрешённым облачным сервисам (Google Docs, 365, Confluence) исключительно через корпоративные устройства и защищённые VPN. Блокировать попытки входа под корпоративными учётными данными с непроверенных сетей или домашних ПК.
- Внедрение внутреннего DLP или CASB в облаках: Активировать Google Workspace DLP или интегрировать CASB-решения, которые способны следить за изменением состава участников, массовыми публикациями, экспортом данных и рассылают алерты/блокируют операции по политике. У Google Workspace есть собственные DLP-правила для Google Drive и Docs — не пренебрегайте ими.
- Тотальный аудит действий внутри SaaS: Все административные события должны стекаться в центральную SIEM, отслеживаться на предмет скачка в количестве публикуемых наружу файлов, добавить контроль массового приглашения внешних участников или появления web-публикаций. Для этого автоматизируйте забор облачных логов и корреляцию с активностью сотрудников.
- Ограничение смешивания аккаунтов: Запретите входы в личные Google-аккаунты на корпоративных устройствах. Google Chrome позволяет управлять политиками профилей через управление устройствами и запрещать одновременно использовать личный и рабочий логин.
- Регулярное обучение и тесты персонала: Разъясняйте разницу между «расшарить ссылку» и «дать доступ только по корпоративному email». Делайте реальный упор на последствия случайного раскрытия документов через ссылки — потому что значительная доля подобных инцидентов возникает не из злого умысла, а по незнанию.
- Сегментация хранения: Самые критичные документы (персональные данные, КИ, ОКТ) переводите в отдельные зоны или хранилища, где политики лицензирования Google не позволяют публиковать файлы в открытый доступ даже технически.
- Проверка и регулярный аудит политик: Периодически инициируйте ревизию прав публикации, приглашения и доступа новых участников для ключевых рабочих папок. Организуйте контроль через процессы согласования публикаций наиболее важных документов.
[ИЗОБРАЖЕНИЕ: Схема потока данных при обычной работе с Docs (внутри периметра) и при утечке через публичную ссылку (данные уходят за периметр при запросе извне)]
Эта система не устраняет риск полностью, но делает его управляемым: сложнее случайно расшарить что-то вне рабочей группы, ИБ-сотрудники видят подозрительные публикации, а логи позволяют установить источник инцидента. Решения, интегрированные с Google Workspace, дают автоматические алерты на массовые изменения прав или публикацию большого числа документов за короткое время.
Итог: безопасность — это про процессы, а не про стены
Реалии работы в соответствии с 152-ФЗ требуют обеспечить не только формальный периметр, но и глубокое понимание жизненного цикла критичных данных. Как показывает практика, инвестиции в самые дорогие DLP-системы бессмысленны без выстроенных процессов аудита, сегментации доступа и интеграции логирования облачных сервисов с общими средствами расследования инцидентов. Старое заблуждение, что «если вход разрешен — то злоумышленник не сможет воспользоваться этим», сегодня приводит к массовым незаметным утечкам именно через штатные сервисы.
Ваша защита становится действительно надёжной только если вы:
- Применяете обучение не как формальность, а как инструмент изменения поведения.
- Следите и анализируете всю цепочку движения данных — от создания документа до любого изменения его прав или состава участников.
- Используете корректный баланс гибкости и жестких ограничений, особенно для СПДн, КИ, коммерческой тайны — всё, что критично сами регулирующие требования или ваши бизнес-риски.
- Регулярно пересматриваете политику и реагируете на изменения бизнес-моделей работы (например, массовый переход в облако, внедрение новых платформ обмена).
Пока классические средства контроля цепляются за привычные, но уже устаревшие каналы, перехитрить их не составляет труда даже у рядового пользователя. Только интеграция облачных DLP, автоматизация анализа событий и человеческий фактор — вот реальное ядро защищённой среды в XXI веке. Важно помнить: безопасность в условиях цифровой трансформации — это не «стена», а система живых, реагирующих на изменения процессов.