Шрифты, Cdn и хостинг: как сайт передаёт данные за рубеж и нарушает 152-ФЗ

Шрифты, CDN и хостинг: как сайт незаметно передаёт данные за рубеж

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

Результат оказался неожиданным. На сайте обнаружились сразу несколько иностранных поставщиков, которых я не подключал осознанно как получателей пользовательских данных. Хостинг работал через Vercel, американскую платформу. Шрифты подгружались из Google Fonts на всех 33 страницах, а две библиотеки для просмотра PDF и Word загружались с cdnjs, принадлежащего Cloudflare. При таких обращениях внешние компании могли получать как минимум IP-адрес и технические сведения о браузере.

Договоры через эти сервисы не проходили. Однако отсутствие передаваемых файлов ещё не означает, что передачи персональных данных нет вовсе. Браузер сообщает серверу свой IP-адрес, а вместе с cookie и сведениями о посещённых страницах эта информация потенциально позволяет выделить конкретного пользователя. Поэтому подход "мы не отправляем за границу анкеты и договоры" не всегда снимает вопросы по 152-ФЗ персональные данные требования.

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

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

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

Есть и техническая сторона ответственности. Посетитель действительно обращается к Google за шрифтом напрямую, но этот запрос возникает потому, что владелец сайта добавил соответствующую ссылку в код страницы. В 2022 году суд в Германии обязал сайт выплатить компенсацию посетителю из-за передачи IP-адреса Google при использовании Google Fonts без согласия (Landgericht München I, дело 3 O 17493/20). Российскую практику нельзя автоматически приравнивать к немецкой, однако сам сценарий показывает, почему внешние компоненты заслуживают проверки.

В материале о таких рисках подробнее разбираются [трансграничная передача данных через шрифты, CDN и хостинг](https://habr.com/ru/articles/1090070/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1090070).

Какие требования важно учитывать

С 1 марта 2023 года до начала трансграничной передачи оператору необходимо направить в Роскомнадзор отдельное уведомление о намерении её осуществлять. Это не то же самое, что уведомление о начале обработки персональных данных. Для государств, не включённых в перечень стран с адекватной защитой прав субъектов, предусмотрен период ожидания: регулятор может ограничить или запретить передачу.

В описанном в статье случае отсутствие отдельного штрафа именно за передачу без уведомления не означает отсутствия ответственности: нарушение могут квалифицировать по части 1 статьи 13.11 КоАП РФ. В тексте приводится диапазон штрафа для юридических лиц - 150-300 тысяч рублей. Если же иностранный сервис принимает сведения из формы, например телефон или электронную почту, возникает дополнительный риск: при сборе данные граждан России должны записываться в базы данных, расположенные в России. За нарушение этого требования предусмотрены более значительные штрафы; для юридических лиц указывается диапазон от 1 до 6 миллионов рублей, а ИП по этой части отвечают как юридические лица.

Особенно часто внешние передачи скрываются в привычных элементах сайта. Помимо шрифтов и библиотек cdnjs, jsDelivr или unpkg, это могут быть Google Analytics, Hotjar, Microsoft Clarity, пиксели рекламных систем, reCAPTCHA, встроенные карты, видео, чаты, формы и сервисы рассылок. Облачные инструменты мониторинга ошибок тоже способны передавать за рубеж технические данные, а иногда - фрагменты запросов или пользовательский ввод.

Отдельно стоит проверять CDN и прокси-сервисы. Даже если ближайший узел расположен в Европе, это не обязательно означает, что компания и обработка данных находятся в России. Например, CDN для сайта в России следует оценивать не только по скорости доставки контента, но и по тому, кто управляет инфраструктурой, какие данные видит провайдер и где они обрабатываются. Аналогично хостинг в России для персональных данных должен соответствовать требованиям к локализации, но само расположение основного сервера не исключает передачи сведений через внешние скрипты и сторонние сервисы.

Что проверить владельцу сайта

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

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

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

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

Прокрутить вверх