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

Один клик «Поделиться» — и данные тысяч клиентов уходят в открытый доступ. Почему это происходит, чем грозит и как остановить

Когда «поделиться» означает «слить»

Утром 5 июля 2018 года пользователи «Яндекса» обнаружили в поисковой выдаче конфиденциальные документы из Google Docs — пароли, корпоративные контракты, персональные данные, а также внутренние материалы московских чиновников. Специалисты Group-IB назвали произошедшее «халатностью» пользователей, которые не выставили нужные ограничения доступа [7][8]. Причина была тривиальной: документы были созданы с настройкой «Все, у кого есть ссылка», и поисковой робот «Яндекса» их проиндексировал.

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

Файловый обмен стал кровеносной системой современного бизнеса. Менеджер отправляет прайс-лист клиенту по ссылке, HR прикрепляет к письму базу кандидатов в облаке, бухгалтер выгружает выписку во временную папку с открытым доступом «чтобы подрядчик мог скачать». Каждое из этих действий — потенциальная точка утечки персональных данных.

Эта статья — для тех, кто отвечает за информационную безопасность, compliance и ИТ в российских компаниях: руководителей ИБ-подразделений, DPO, системных администраторов и всех, кто хочет понять, как закрыть этот вектор утечек до того, как он станет инцидентом.

Часть 1. Анатомия утечки через публичную ссылку

Как работает «ссылка с доступом для всех»

Почти каждый облачный сервис — Google Drive, Microsoft OneDrive/SharePoint, Яндекс.Диск, Dropbox, S3-совместимые объектные хранилища — предлагает несколько уровней доступа к файлу или папке:

1. Закрытый доступ (только конкретные пользователи по приглашению).
2. Доступ по ссылке без аутентификации («любой, у кого есть ссылка»).
3. Публичный индексируемый доступ (поисковые роботы могут найти файл).
4. Полностью открытое хранилище (бакет без ограничений, как в случае с S3).

Уровни 2–4 и являются источником большинства непреднамеренных утечек. Ключевое слово здесь — «непреднамеренных»: подавляющее большинство инцидентов происходит не из-за атаки, а из-за удобства [9].

Когда пользователь нажимает «Поделиться» и выбирает режим «Все, у кого есть ссылка», он думает: «Ссылка длинная и случайная — никто не найдёт». Это ложное ощущение безопасности. На практике ссылка попадает в историю браузера, логи прокси-серверов, тело письма, мессенджер, кэш CDN — и оттуда уходит туда, куда не планировалось.

В случае Google Drive существовал ещё один нюанс: в 2018 году настройка «Все, у кого есть ссылка» в ряде случаев трактовалась платформой как публичный доступ — файлы оказывались доступны без прямой ссылки через поисковик [10]. Сейчас поведение изменилось, но риск некорректной интерпретации разных уровней доступа сохраняется.

Ошибки конфигурации как системная проблема

Согласно отчёту CSA Top Threats to Cloud Computing 2024, неверные настройки (misconfiguration and inadequate change control) вышли на первое место среди угроз безопасности облачных сред — по мнению более 500 опрошенных экспертов [3][11]. Среди конкретных вариантов неверной конфигурации упоминается «несанкционированный общий доступ к ресурсам» (unauthenticated resource sharing) как отдельная угроза в том же рейтинге.

Исследование Datadog Cloud Security Report 2024 показало, что 1,48% всех бакетов AWS S3 были «фактически публичными» на момент анализа — незначительный процент в абсолютном выражении означает тысячи открытых хранилищ по всему миру [12]. По данным исследователей, в июле 2025 года около половины бакетов S3 имели потенциально некорректные настройки [13].

Характерный пример: в мае 2022 года авиакомпания Pegasus Airlines допустила утечку через неправильно настроенный S3-бакет — в открытый доступ попало 6,5 терабайта данных, включая персональные данные членов экипажа и оперативную документацию [14]. Причина — публичный доступ без какого-либо контроля со стороны технической команды.

SentinelOne зафиксировала, что около 23% инцидентов с облачной безопасностью в 2024 году были связаны именно с неверной конфигурацией [15].

Три пути, которыми ПДн оказываются в публичном доступе

Первый путь — прямая ошибка настройки. Сотрудник создаёт ссылку «для всех», подрядчик случайно делает бакет публичным, DevOps-инженер копирует prod-данные в тестовую среду без ограничений доступа. Это наиболее распространённый сценарий.

Второй путь — «теневое ИТ» (Shadow IT). По данным российских ИБ-специалистов, сотрудники используют личные аккаунты в Google Drive, Яндекс.Диске, Dropbox и Telegram для передачи рабочих файлов, потому что корпоративные инструменты кажутся им неудобными [6]. Отделы кадров и продаж особенно склонны к этому поведению [16]. С точки зрения информационной безопасности эти файлы находятся в полной «слепой зоне»: компания о них не знает, управлять ими не может.

Третий путь — намеренное злоупотребление привилегиями. Недобросовестные сотрудники используют легитимные права доступа для создания публичных ссылок на конфиденциальные документы с целью последующей передачи данных [17]. Это внутренняя угроза, которая использует абсолютно легальный инструмент обмена файлами как вектор утечки.

Часть 2. Масштаб проблемы в России и правовой контекст

Что говорит статистика

Роскомнадзор в 2024 году выявил 135 фактов утечек персональных данных, содержавших более 710 млн записей — наибольшее количество в сфере торговли и оказания услуг [1]. Только за февраль 2024 года в открытый доступ попало более 510 млн строк — почти столько же, сколько за 2022 и 2023 годы вместе взятые [18].

По данным Yandex Cloud, около 76% разобранных инцидентов в первом полугодии 2025 года конечной целью имели облачные базы данных и объектные хранилища S3 [17]. Более 20% российских организаций пострадали от атак на облачные сервисы только за первый квартал 2025 года, а общее число кибератак на российские компании в 2024 году выросло в 2,5 раза [17].

Опрос CSA 2024 года показал: 95% из 600 опрошенных организаций столкнулись с облачными инцидентами безопасности за 18 месяцев, причём 92% из них отметили утечку конфиденциальных данных [19].

Как 152-ФЗ регулирует файлообмен с ПДн

Федеральный закон № 152-ФЗ «О персональных данных» не содержит отдельной нормы о публичных ссылках, однако создаёт правовую рамку, под которую подпадает любой способ передачи данных третьим лицам.

Статья 6 закона устанавливает: если оператор поручает обработку персональных данных другому лицу (в том числе облачному провайдеру), ответственность перед субъектом персональных данных за действия этого лица несёт оператор [20]. Иными словами, если данные попали в открытый доступ через облачный сервис, штраф получит компания, а не провайдер.

С 1 июля 2025 года вступила в силу обновлённая часть 5 статьи 18, требующая хранить все базы данных с ПДн российских граждан исключительно на серверах, физически расположенных в России [21][22]. Это прямо означает, что использование иностранных облачных хранилищ (Google Drive, Dropbox, OneDrive без российской локализации) для хранения ПДн без предварительного размещения данных в России является нарушением.

Штрафы: от символических к оборотным

До 30 мая 2025 года штрафы за утечки были относительно небольшими. С вступлением в силу Федерального закона № 420-ФЗ от 30.11.2024 картина изменилась кардинально [4]:

1. Утечка данных от 10 000 до 100 000 субъектов или от 100 000 до 1 млн идентификаторов: для юрлиц — от 5 до 10 млн рублей.
2. Утечка данных более 100 000 субъектов или более 1 млн идентификаторов: для юрлиц — от 10 до 15 млн рублей.
3. За неуведомление Роскомнадзора об утечке в течение 24 часов: для юрлиц — от 1 до 3 млн рублей.
4. За повторные нарушения — оборотный штраф, максимальный размер которого достигает 500 млн рублей [5][9].

При этом важно понимать: уведомление об инциденте Роскомнадзора является обязательным в течение 24 часов с момента обнаружения утечки, а не с момента её возникновения [23]. Это означает, что компания, которая обнаружила открытый публичный бакет с данными через месяц после его создания, уже нарушила требования об уведомлении.

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

Часть 3. Типология угроз: где прячутся открытые ссылки

Облачные хранилища корпоративного класса

Microsoft SharePoint и OneDrive — одни из самых распространённых платформ для корпоративного обмена файлами в России. В настройках SharePoint Online присутствует режим «Любой пользователь» (Anyone links) — ссылки, не требующие аутентификации. Официальная документация Microsoft прямо предупреждает: при использовании такого режима невозможно отслеживать, кто имеет доступ к общим файлам и кто ими воспользовался [25].

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

Отдельную проблему представляет функция DLP (Data Loss Prevention) в SharePoint: новые файлы некоторое время проходят проверку политик DLP, и если внешний общий доступ включён, гости могут получить доступ к конфиденциальному файлу ещё до завершения DLP-проверки [26].

Google Drive в корпоративном варианте (Google Workspace) предоставляет администраторам инструменты для ограничения внешнего доступа. Однако при стандартных настройках пользователи могут создавать ссылки «для всех в интернете», и такие файлы индексируются поисковыми системами, если владелец не установил запрет [10].

Объектные хранилища: S3, Yandex Object Storage, VK Cloud

S3-совместимые объектные хранилища — AWS S3, Yandex Object Storage, VK Cloud — широко используются для хранения дамп-файлов, резервных копий, медиаконтента и документов. Именно они стали источником наибольшего числа громких утечек за последние годы.

Типичная схема инцидента: DevOps-инженер создаёт бакет для временного хранения данных миграции, случайно или по незнанию выставляет публичный доступ, забывает о нём после завершения задачи. Через несколько недель или месяцев автоматизированные сканеры злоумышленников находят открытый бакет. Инструменты вроде S3Scanner и GrayHatWarfare позволяют перебирать открытые бакеты с минимальными техническими знаниями [13].

Показательный пример с Capital One в 2019 году: злоумышленник через уязвимость WAF получил временные credentials IAM-роли и получил доступ к S3-бакетам с более чем 100 млн записей клиентов [14]. Неверная конфигурация IAM-роли, а не прямой публичный доступ, стала точкой входа — но механика та же: избыточные права доступа к хранилищу.

AWS с апреля 2023 года по умолчанию блокирует публичный доступ для новых бакетов и отключает ACL. Однако существующие конфигурации не были изменены автоматически, а в российских облаках (Yandex Cloud, VK Cloud) настройки по умолчанию могут отличаться [12].

Файлообменники и мессенджеры

Отдельный и часто недооцениваемый вектор — использование файлообменников (WeTransfer, Dropbox Transfer) и мессенджеров (Telegram) для передачи документов с ПДн. Типичный сценарий, описанный ИБ-специалистами: менеджер по продажам прикрепляет таблицу с клиентской базой к сообщению в Telegram-канале или отправляет её через WeTransfer подрядчику, не задумываясь о том, что файл будет доступен по прямой ссылке ещё 7 дней [6][16].

С точки зрения 152-ФЗ передача данных через иностранный сервис без соответствующего правового основания и уведомления Роскомнадзора является нарушением требований о трансграничной передаче ПДн [20].

Тестовые среды и базы данных разработчиков

Отдельную категорию риска представляют копии продакшн-данных в тестовых средах. По наблюдениям специалистов по DSPM (Data Security Posture Management), компании часто не имеют актуальной картины того, где именно хранятся копии чувствительных данных [17]. Разработчики реплицируют данные клиентов в тестовые среды без обезличивания, а контроль доступа к этим средам значительно слабее, чем к продакшну.

По данным международных исследований, в тестовых базах данных нередко остаются реальные email-адреса, имена и другие ПДн пользователей — и именно эти среды имеют расширенный круг лиц с доступом [17].

Часть 4. Практическая часть: как закрыть утечки через файлообмен

Уровень 1. Технические настройки хранилищ

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

1. В Microsoft SharePoint/OneDrive: перейдите в центр администрирования SharePoint, раздел «Общий доступ». Установите для параметра «Внешний общий доступ» значение «Только существующие гости» или «Только люди в организации». Если внешний обмен необходим — ограничьте создание ссылок «Любой» конкретными группами безопасности. Включите параметр MarkNewFilesSensitiveByDefault для блокировки внешнего доступа к новым файлам до завершения DLP-проверки [25][26].
2. В Google Workspace: в консоли администратора (admin.google.com) откройте Приложения → Google Workspace → Drive и Docs → Настройки общего доступа. Отключите возможность делиться файлами с людьми вне домена или ограничьте её. Убедитесь, что опция индексирования документов поисковыми системами выключена.
3. В S3-совместимых хранилищах: включите Block Public Access на уровне аккаунта и отдельных бакетов. Регулярно запускайте AWS Config или аналогичные инструменты для обнаружения дрейфа конфигурации. Применяйте принцип минимальных привилегий в IAM-политиках [12][13].
4. Установите срок действия для временных ссылок: большинство платформ позволяют задать время жизни ссылки — например, 7 дней вместо «бессрочно».
5. Включите аудит-логирование на уровне объектов (object-level logging): стандартные журналы событий управления не фиксируют, кто и когда скачал конкретный файл [22].

Уровень 2. Политики и процессы

Технические ограничения работают только в связке с организационными мерами:

1. Разработайте корпоративную политику работы с облачными хранилищами. Она должна содержать список разрешённых сервисов, типы данных, которые запрещено хранить в облаке вне корпоративной инфраструктуры, требования к уровню доступа для разных категорий данных.
2. Запретите использование личных облачных аккаунтов для рабочих данных — и предложите корпоративную альтернативу с удобным интерфейсом. Запрет без альтернативы стимулирует «теневое ИТ» [6].
3. Внедрите политику «доступа по умолчанию — закрытый». Любое отклонение от этого правила должно проходить согласование.
4. Заключите договоры об обработке ПДн со всеми облачными провайдерами, которые имеют доступ к данным компании. Это требование прямо следует из части 3 статьи 6 152-ФЗ [20].
5. Проводите регулярное обучение сотрудников: конкретные примеры, объясняющие, что именно произойдёт при создании публичной ссылки на документ с данными клиентов [6][9].
6. Определите ответственных за «владение» каждым облачным хранилищем или бакетом. Отсутствие владельца — одна из главных причин, по которым открытые ресурсы остаются незамеченными [22].

Уровень 3. Мониторинг и обнаружение

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

1. Внедрите CSPM (Cloud Security Posture Management) для непрерывного мониторинга настроек облачной инфраструктуры и автоматического обнаружения отклонений.
2. Рассмотрите DSPM (Data Security Posture Management) — класс решений, ориентированных не на инфраструктуру, а на сами данные: где они находятся, кто имеет доступ, не являются ли они публично доступными. DSPM стал самой быстрорастущей категорией продуктов кибербезопасности: 75% организаций планировали внедрить его в течение года, по данным Cybersecurity Insiders за конец 2024 года [27].
3. Настройте оповещения для критичных событий: создание публичной ссылки на файл, содержащий паттерны ПДн (ИНН, паспортные данные, email, телефон), изменение политики доступа бакета на публичный.
4. Регулярно запускайте сканирование хранилищ на наличие ПДн в публичных или слабо защищённых местах.

Часть 5. Типичные ошибки и как их избежать

Ошибка 1: «Ссылка длинная — никто не найдёт»

Так называемая «безопасность через неизвестность» — классическая ловушка. Ссылка попадает в логи прокси-сервера, корпоративного почтового шлюза, браузерной истории, тела письма, поисковых индексов. Автоматизированные инструменты сканирования способны обнаружить открытый бакет в течение часов после его создания [13].

Правило: уровень доступа определяется настройками, а не «секретностью» URL.

Ошибка 2: «Мы пользуемся надёжным облачным провайдером, значит, данные защищены»

Модель разделённой ответственности (shared responsibility model) означает, что провайдер (AWS, Yandex Cloud, VK Cloud) отвечает за безопасность инфраструктуры, но не за конфигурацию ресурсов клиента [28]. Облачный провайдер не решает, кому и на каких условиях открывается доступ к данным компании [29]. В случае утечки через некорректно настроенный бакет или ссылку Роскомнадзор придёт к оператору, а не к провайдеру [30].

Ошибка 3: «Мы использовали данные только для теста»

Тестовые среды с реальными ПДн — распространённая причина инцидентов. Факт того, что данные «использовались временно», не снимает обязательств по их защите. Для тестирования следует использовать обезличенные или синтетические данные.

Ошибка 4: «Подрядчик сам несёт ответственность»

Это не так. Статья 6 152-ФЗ однозначно устанавливает: ответственность за действия подрядчика, которому переданы ПДн, несёт оператор [20]. Договор об обработке персональных данных с подрядчиком — обязательное условие, но он не освобождает от ответственности.

Ошибка 5: «Мы узнаем об утечке, когда она произойдёт»

К моменту, когда данные об утечке появятся в СМИ или на хакерских форумах, может пройти несколько месяцев с момента реального открытия доступа. IBM Cost of a Data Breach Report 2024 зафиксировал средний цикл инцидента в 242 дня для публичных облачных сред (204 дня до обнаружения и 38 дней на локализацию) [15]. Всё это время данные были доступны посторонним лицам.

Ошибка 6: «Мы провели аудит полгода назад»

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

Часть 6. Кейсы и реальные инциденты

Кейс 1. Google Docs в поисковой выдаче «Яндекса» (2018, Россия)

Вечером 4 июля 2018 года пользователи обнаружили, что в выдаче «Яндекса» по обычным запросам появляются документы из Google Docs: пароли, корпоративные контракты, персональные данные граждан. За несколько часов через поисковик успели найти внутренние документы о явке на выборы мэра Москвы. «Яндекс» и Google возложили ответственность на пользователей, которые сами сделали документы публичными [7][8]. Инцидент наглядно продемонстрировал: даже «ссылочный» доступ не гарантирует конфиденциальности.

Кейс 2. Pegasus Airlines и 6,5 ТБ открытых данных (2022)

Турецкая авиакомпания Pegasus Airlines допустила утечку через неправильно настроенный S3-бакет: в открытый доступ попали личные данные членов экипажа, навигационные файлы, исходный код бортовых систем и другие оперативные документы общим объёмом 6,5 терабайта [14]. Бакет был доступен без какой-либо аутентификации. Причина — отсутствие политики блокировки публичного доступа и контроля конфигурации.

Кейс 3. Сотрудники отдела кадров и Dropbox (обобщённый кейс из практики российских ИБ-компаний)

Эксперты компании iTPROTECT описывают типичный сценарий: сотрудники HR и продаж использовали личные Dropbox-аккаунты для передачи документов — в том числе с личными данными сотрудников и клиентов — при работе из дома. Это приводило к утечке информации через уязвимости сервиса и попаданию документов к несанкционированным пользователям [16]. Решением стал перевод на корпоративную систему безопасного обмена файлами с политиками доступа.

Кейс 4. Тестовые базы данных в публичных хранилищах

ИБ-специалисты из SearchInform описывают схему, когда компании, переходящие на новое ПО, временно выгружают «тестовые» копии клиентских баз в доступные облачные директории — и забывают их удалить [31]. Спустя месяцы эти данные обнаруживаются либо автоматическими сканерами, либо случайными пользователями, нашедшими открытую ссылку в кэше браузера коллеги.

Часть 7. Тренды: что изменится в 2025–2026 годах

Ужесточение регуляторной среды в России

2025–2026 годы в России пройдут под знаком двух параллельных трендов: ужесточения требований и расширения правоприменения. По данным экспертов, к 2026 году ожидается волна проверок Роскомнадзора с применением всех нормативных изменений второй половины 2025 года [21]. Распоряжение Правительства от 14.08.2025 № 2207-р обязало регуляторов разработать предложения об увеличении срока давности по делам о нарушениях 152-ФЗ и усилении ответственности [32].

Автоматизированный поиск открытых хранилищ

Злоумышленники всё активнее используют автоматизацию для поиска открытых облачных ресурсов. Инструменты S3Scanner, GrayHatWarfare, BucketLoot позволяют сканировать провайдерские IP-диапазоны и находить открытые бакеты в режиме реального времени [13]. Исследование 2024 года зафиксировало: как только бакет или endpoint оказывается в открытом доступе, в течение нескольких минут к нему начинают обращаться автоматизированные сканеры [13]. Это означает, что «случайно открытый» бакет уже не является случайно закрытым — он с высокой вероятностью был обнаружен и просканирован.

Рост DSPM и переход от периметральной защиты к защите данных

Традиционный подход «защити периметр» всё хуже работает в мире, где данные распределены между десятками облаков, SaaS-приложений и API. Gartner ввёл термин DSPM (Data Security Posture Management) в своём Hype Cycle for Data Security ещё в 2022 году [27]. К 2025 году это уже зрелая категория продуктов с десятками поставщиков. Суть подхода: безопасность фокусируется не на инфраструктуре, а на самих данных — где они находятся, кто имеет доступ, насколько хорошо они защищены.

Требования к локализации данных усиливаются

С 1 июля 2025 года в России действует требование о том, что не только операторы, но и обработчики (подрядчики, облачные сервисы) должны хранить ПДн российских граждан исключительно на серверах, расположенных в России [21]. Это означает, что компании должны будут либо мигрировать данные из иностранных облаков, либо работать только с российскими провайдерами для соответствующих категорий данных.

Часть 8. Как «Пятый фактор» помогает закрыть слепые зоны

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

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

Ключевые возможности, релевантные для описанного в статье контекста:

1. Непрерывная инвентаризация ПДн: платформа автоматически сканирует базы данных, хранилища, почту, Active Directory/LDAP, CRM, 1С и API — и строит актуальную карту того, где и какие персональные данные хранятся.
2. Раннее обнаружение новых рисков: когда в хранилище появляется новое поле с ПДн, новый источник данных или новая интеграция — платформа замечает это немедленно, а не спустя месяцы на очередном плановом аудите.
3. Privacy-by-design без рисков для самих данных: принципиальная особенность — платформа работает только с метаданными, структурой и агрегатами, не передавая и не сохраняя «сырые» значения ПДн. Это означает, что сама система не становится источником риска.
4. Контроль доступа и владельцев: понятные нарушения, статусы, владельцы данных и согласования — вместо разрозненных ручных проверок.
5. Готовность к аудиту и комплаенсу: актуальная документация о составе ПДн и мерах их защиты формируется автоматически, а не накануне проверки Роскомнадзора.

В контексте этой статьи Пятый фактор закрывает именно ту «слепую зону», которая делает утечки через публичные ссылки системной проблемой: компании не знают, где именно у них хранятся ПДн, — и потому не могут контролировать, не оказались ли они случайно в открытом доступе.

Заключение: чек-лист «минимальная защита»

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

1. Аудит настроек всех корпоративных облачных хранилищ: отключить режим «доступ для всех» везде, где он не нужен явно.
2. Запрет на использование личных облачных аккаунтов для рабочих данных + предоставление удобной корпоративной альтернативы.
3. Установка сроков жизни для всех временных ссылок на файлы с ПДн.
4. Обязательные договоры об обработке ПДн с облачными провайдерами.
5. Включение аудит-логов на уровне объектов в используемых хранилищах.
6. Обучение сотрудников: объяснить, что означает кнопка «поделиться для всех» на конкретных примерах.
7. Процедура реагирования на инцидент: зафиксировать, кто обязан уведомить Роскомнадзора в течение 24 часов и кто отвечает за ликвидацию публичного доступа.
8. Непрерывный мониторинг: разовый аудит не заменяет постоянного контроля.

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

Источники

[1] Роскомнадзор зафиксировал 135 фактов утечек ПДн в 2024 году — Хабр, 3 июля 2025 — https://habr.com/ru/news/924602/

[2] Роскомнадзор зарегистрировал утечки 50 млн записей ПДн — Фонтанка, 31 октября 2025 — https://www.fontanka.ru/2025/10/31/76100209/

[3] Cloud Security Alliance, Top Threats to Cloud Computing 2024 — https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-2024

[4] Закон о персональных данных 2025: изменения и штрафы — Битрикс24, декабрь 2025 — https://www.bitrix24.ru/journal/zakon-o-personalnyh-dannyh/

[5] Работа с ПДн в облаке: требования закона для МСБ — VC.ru, август 2025 — https://vc.ru/services/2182547-personalnye-dannye-v-oblake-trebovaniya-zakona-dlya-msb-v-rossii

[6] Борьба с Shadow IT и несанкционированными облачными хранилищами — CISOCLUB, январь 2026 — https://cisoclub.ru/vyjavlenie-i-blokirovanie-nesankcionirovannyh-oblachnyh-hranilishh-v-rabochih-processah/

[7] Утечка Google Docs через «Яндекс» — TJournal — https://tjournal.ru/news/73229-utechka-google-docs-cherez-yandeks-kak-lichnye-dannye-popali-v-otkrytyy-dostup-i-kakie-mogut-byt-posledstviya

[8] Google прокомментировал утечку документов Docs — Газета.Ру, 5 июля 2018 — https://www.gazeta.ru/tech/2018/07/05_a_11827645.shtml

[9] Персональные данные в 2025 году — Nubes — https://nubes.ru/blog/articles/personal-data-2025

[10] Новая утечка информации о проблемах Google с конфиденциальностью — AdGuard, июнь 2024 — https://adguard.com/ru/blog/google-privacy-failure-leak-report.html

[11] Cloud Security Alliance issues Top Threats 2025 — CSA, апрель 2025 — https://cloudsecurityalliance.org/press-releases/2025/04/29/cloud-security-alliance-issues-top-threats-to-cloud-computing-deep-dive-2025

[12] Misconfigured, exposed, forgotten: why S3 is still a problem in 2025 — ClearPoint Digital, август 2025 — https://clearpoint.digital/insights/misconfigured-exposed-forgotten-why-s3-is-still-a-problem-in-2025

[13] Misconfigured Cloud Assets: From Exposure to Data Breach — CybelAngel, октябрь 2025 — https://cybelangel.com/blog/misconfigured-cloud-assets/

[14] AWS Data Breach: Lessons From 4 High Profile Breaches — BlackFog, июль 2025 — https://www.blackfog.com/aws-data-breach/

[15] Top 5 Cloud Security Threats in 2025 — SecPod, июль 2025 — https://www.secpod.com/blog/top-5-cloud-security-threats/

[16] За пределами контроля: Shadow IT в организации — SecurityMedia — https://securitymedia.org/info/za-predelami-kontrolya-shadow-it-v-organizatsii.html

[17] DSPM-подход: как превратить хаос в систему защиты данных в облаке — SecurityLab, декабрь 2025 — https://www.securitylab.ru/analytics/567140.php

[18] Штрафы за утечку персональных данных 2024 — Rusonyx — https://www.rusonyx.ru/blog/post/shtrafy-za-utechku-personalnyh-dannyh-2024/

[19] Cloud Security in 2024: Insecure Identities — Cloud Security Alliance, июль 2024 — https://cloudsecurityalliance.org/blog/2024/07/02/cloud-security-study-most-surveyed-organizations-suffered-a-cloud-related-breach-over-an-18-month-period

[20] Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 6 — КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/

[21] 152-ФЗ 2025: разбор поправок — Riverstart, 2025 — https://riverstart.ru/blog/novyie-trebovaniya-kpersonalnyim-dannyim-v2025-pravila-rabotyi-dlya-biznesa-s152-fz

[22] Public S3 Bucket Exposure: Misconfiguration Risks in 2025 — Cloud Storage Security — https://cloudstoragesecurity.com/news/anatomy-of-an-s3-exposure-273k-bank-transfer-pdfs-left-open-online

[23] Как работать с персональными данными в 2025 году — РБК Компании, сентябрь 2025 — https://companies.rbc.ru/news/BSZ231iAod/kak-rabotat-s-personalnyimi-dannyimi-v-2025-godu-izmeneniya-s-1-sentyabrya/

[24] Риски для бизнеса: чем опасны утечки ПДн — SEOnews, июль 2025 — https://m.seonews.ru/analytics/utechka-dannykh-kak-odna-oshibka-mozhet-stoit-kompanii-milliony-rubley/

[25] Управление параметрами общего доступа для SharePoint и OneDrive — Microsoft Learn — https://learn.microsoft.com/ru-ru/sharepoint/turn-external-sharing-on-or-off

[26] Запрет гостевого доступа к файлам при применении DLP-правил — Microsoft Learn — https://learn.microsoft.com/ru-ru/sharepoint/sensitive-by-default

[27] What is DSPM? 2026 Guide to Data Security Posture Management — Concentric AI — https://concentric.ai/what-is-dspm/

[28] Overcoming Sensitive Data Protection Challenges in AWS S3 — Zscaler, апрель 2025 — https://www.zscaler.com/blogs/product-insights/overcoming-sensitive-data-protection-challenges-aws-s3-storage

[29] 152-ФЗ в облаке: хранение персональных данных в облаке — Cloud.ru — https://cloud.ru/blog/152-fz-v-oblake

[30] Персональные данные в 2025 году: новые правила — Nubes — https://nubes.ru/blog/articles/personal-data-2025

[31] Утечка информации в облачные хранилища — SearchInform — https://searchinform.ru/analitika-v-oblasti-ib/utechki-informatsii/prichiny-utechki-informatsii/istochniki-utechki-informacii/utechka-informacii-v-oblachnye-hranilishcha-vyyavlenie/

[32] Закон о персональных данных: что нас ждёт в 2026 году — Клерк, февраль 2026 — https://www.klerk.ru/blogs/fedresurs/680031/