Как выявить все внешние домены на сайте, которые получают персональные данные: методика и примеры

Полное практическое руководство по аудиту веб-трафика в условиях ужесточения 152-ФЗ

Почему это стало критически важным

Современный корпоративный сайт — это не монолитное приложение, а экосистема из десятков внешних зависимостей. Форма обратной связи отправляет данные в CRM, кнопка «Войти через ВКонтакте» тянет скрипты с серверов социальной сети, чат-виджет обращается к серверам зарубежного SaaS-провайдера, пиксель ретаргетинга улетает на рекламные серверы. Для маркетолога это удобные инструменты. Для специалиста по защите данных — каждый такой запрос потенциально является передачей персональных данных третьей стороне.

До 2024 года многие компании закрывали на это глаза: штрафы были символическими (5 000–50 000 рублей), а проверки — редкими. Всё изменилось. Федеральный закон № 420-ФЗ от 30 ноября 2024 года ввёл оборотные штрафы и уголовную ответственность за утечки [3]. Поправки к 152-ФЗ, вступившие в силу с 1 июля 2025 года, прямо запрещают первичный сбор ПДн граждан РФ на иностранных серверах [4]. Роскомнадзор уже начал штрафовать компании за использование Google Tag Manager без уведомления о трансграничной передаче [5].

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

Материал ориентирован на специалистов по информационной безопасности, DPO (Data Protection Officer), разработчиков и технических директоров компаний, которым нужна не теория, а конкретная пошаговая методика.

Что считается передачей ПДн внешнему домену

Прежде чем переходить к инструментам, необходимо разобраться с понятийной базой. Согласно 152-ФЗ «О персональных данных», персональные данные — это любая информация, относящаяся к прямо или косвенно определённому физическому лицу [6]. Это определение шире, чем кажется на первый взгляд.

Когда пользователь открывает страницу сайта, браузер отправляет HTTP-запросы. Каждый такой запрос к внешнему домену автоматически включает IP-адрес пользователя в заголовке запроса. Исследования подтвердили, что в 61% случаев из 185 проверенных крупных сайтов имя пользователя или идентификатор передавались в домен с другим публичным суффиксом [7]. Это означает, что пассивный получатель внешнего запроса — например, рекламный пиксель или счётчик аналитики — получает как минимум IP-адрес, а нередко и гораздо больше.

Российская правоприменительная практика трактует это широко. Управления Роскомнадзора по Приволжскому федеральному округу и Курганской области прямо квалифицируют применение Google Analytics как нарушение ч. 5 ст. 18 152-ФЗ, поскольку сведения о пользователях попадают в базы данных вне территории РФ [8].

На практике передача ПДн внешнему домену происходит через следующие механизмы:

Первый — загрузка JavaScript-скрипта с внешнего сервера. Скрипт исполняется в контексте страницы и имеет доступ к DOM, cookie, данным форм. Именно так работают Google Analytics, Яндекс.Метрика, пиксели рекламных систем, виджеты чатов.

Второй — HTTP-запросы к API. Форма на сайте может отправлять данные напрямую на сервер CRM или email-сервиса, минуя ваш бэкенд.

Третий — tracking pixel (пиксель отслеживания). Изображение размером 1×1 пиксель, загружаемое с внешнего сервера, передаёт ему IP-адрес пользователя, заголовок Referer с URL текущей страницы, данные cookies.

Четвёртый — iFrame. Встроенный фрейм, загружающий контент с внешнего домена (формы, видео, виджеты), взаимодействует с пользователем напрямую и может получать вводимые им данные.

Пятый — WebSocket-соединения и SSE. Постоянные соединения с внешними серверами для чат-виджетов или real-time уведомлений.

Шестой — font и CDN запросы. Загрузка шрифтов с Google Fonts или ресурсов с CDN третьих сторон также передаёт IP-адрес пользователя внешнему оператору.

Уровень 1: Ручной аудит через браузерные DevTools

Это самый доступный метод — не требует установки дополнительного ПО и подходит для первичной проверки. Достаточно любого современного браузера на базе Chromium или Firefox.

Шаг 1. Открываем панель Network

Откройте целевую страницу сайта, нажмите F12 (или Ctrl+Shift+I), перейдите на вкладку Network. Перезагрузите страницу с открытой панелью. Вы увидите полный список всех сетевых запросов, которые сделал браузер при загрузке страницы.

Важный нюанс: панель Network показывает запросы только в момент открытия. Чтобы поймать запросы, которые происходят при взаимодействии пользователя (заполнение формы, клик, скролл), оставьте панель открытой и воспроизведите целевое действие — например, заполните форму обратного звонка тестовыми данными.

Шаг 2. Фильтрация по домену

В строке фильтра Network панели введите -domain:ваш-домен.ru (в Chrome) или используйте колонку Domain для сортировки. Это покажет только запросы к внешним доменам.

Обратите особое внимание на запросы типа XHR и Fetch — они часто содержат POST-запросы с данными форм. Нажмите на такой запрос, откройте вкладку Payload (Chrome) или Request (Firefox) — там вы увидите тело запроса, то есть именно те данные, которые ушли на внешний сервер.

Для каждого внешнего запроса зафиксируйте:

• Домен получателя
• Метод HTTP (GET или POST)
• Тип ресурса (Script, XHR, Image, Document)
• Заголовки — особенно Cookie и Referer в исходящем запросе
• Тело запроса (для POST)
• Ответ сервера

Шаг 3. Экспорт в HAR-файл

Для документирования и передачи коллегам: в панели Network нажмите правой кнопкой на список запросов, выберите «Save all as HAR with content». Файл .har — это JSON-архив всех запросов с заголовками и телами. Его можно открыть в онлайн-просмотрщиках (например, har.tech) или проанализировать скриптом.

# Пример анализа HAR-файла на Python для извлечения уникальных внешних доменов
import json
from urllib.parse import urlparse

with open("site_audit.har", "r", encoding="utf-8") as f:
    har = json.load(f)

own_domain = "example.ru"
external = set()

for entry in har["log"]["entries"]:
    url = entry["request"]["url"]
    domain = urlparse(url).netloc
    if own_domain not in domain:
        external.add(domain)

for d in sorted(external):
    print(d)

Шаг 4. Проверка вкладки Sources

Помимо Network, вкладка Sources показывает все скрипты, загруженные на странице. Скрипты, загруженные с внешних доменов, отображаются в отдельных папках (не в папке вашего домена). Это позволяет обнаружить скрипты, которые могут не генерировать видимых сетевых запросов при стандартной проверке, но читают данные страницы.

Ограничения метода

Ручной аудит через DevTools имеет существенный недостаток: он фиксирует только то, что происходит в конкретном сеансе. Если скрипт активируется через несколько дней или в зависимости от источника перехода (реферальный трафик, UTM-метки), вы его не увидите. Кроме того, некоторые запросы происходят после взаимодействий, которые сложно воспроизвести вручную.

Уровень 2: Статический анализ HTML и JavaScript-кода

Статический анализ позволяет найти потенциальные точки передачи данных, не запуская браузер. Это особенно полезно для регулярного мониторинга в CI/CD-пайплайне.

Анализ HTML-разметки

В исходном коде страницы ищите следующие паттерны, указывающие на внешние домены:

<!-- Внешние скрипты -->
<script src="https://www.googletagmanager.com/gtag/js?id=..."></script>
<script src="https://mc.yandex.ru/metrika/tag.js"></script>

<!-- Внешние формы и iFrame -->
<iframe src="https://external-service.com/widget/..."></iframe>
<form action="https://crm.example.com/submit">

<!-- Tracking pixels -->
<img src="https://pixel.facebook.com/..." width="1" height="1">

<!-- Внешние шрифты и CSS -->
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Для автоматического извлечения внешних URLs из HTML используйте инструменты типа grep или Python с BeautifulSoup:

from bs4 import BeautifulSoup
import requests
from urllib.parse import urlparse

def find_external_domains(url, own_domain):
    r = requests.get(url)
    soup = BeautifulSoup(r.text, 'html.parser')
    
    external = set()
    tags = {'script': 'src', 'img': 'src', 'link': 'href', 
            'iframe': 'src', 'form': 'action'}
    
    for tag, attr in tags.items():
        for el in soup.find_all(tag):
            val = el.get(attr, '')
            if val.startswith('http') and own_domain not in val:
                external.add(urlparse(val).netloc)
    
    return external

Анализ JavaScript-кода

Многие внешние домены появляются не в HTML, а в JavaScript. Наиболее опасный случай — Google Tag Manager: один тег GTM загружает десятки других тегов динамически, и из статического HTML вы увидите только googletagmanager.com, но не конечных получателей данных [9].

Для анализа содержимого GTM-контейнера откройте URL вида https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX и изучите JSON-конфигурацию контейнера. Она содержит список всех тегов, триггеров и переменных — фактически карту всех внешних сервисов, управляемых через этот GTM.

Другой подход — поиск паттернов прямой отправки данных в JS-коде:

// Паттерны, указывающие на передачу данных внешним доменам
fetch('https://external-api.com/...', { method: 'POST', body: data })
XMLHttpRequest.open('POST', 'https://...')
new Image().src = 'https://tracker.com/?email=' + userEmail
navigator.sendBeacon('https://...')

Инструмент grep помогает автоматизировать поиск по исходникам:

# Поиск всех URL в JS-файлах проекта
grep -roh 'https://[a-zA-Z0-9.-]*\.[a-zA-Z]{2,}' ./static/js/ | sort | uniq

Уровень 3: Автоматизированное сканирование

Для систематического аудита, особенно на крупных сайтах с сотнями страниц, ручная проверка неэффективна. Существует несколько классов инструментов.

Blacklight (The Markup)

Blacklight — бесплатный онлайн-инструмент, созданный некоммерческим изданием The Markup. Он автоматически проверяет сайт и выявляет семь типов отслеживания: сторонние cookies, сессионные рекордеры (запись действий мышью и клавиатуры), кейлоггеры, трекеры Facebook и Google, «canvas fingerprinting», поведенческие профили пользователей [10].

Достаточно ввести URL сайта — и через несколько секунд вы получите детальный отчёт. Например, по данным проверок Blacklight, на сайте Time Magazine обнаружены 14 трекеров и 25 cookie-файлов, а на WebMD — 26 трекеров и 31 cookie-файл [10].

Ограничение Blacklight: он проверяет только главную страницу (или указанный URL) и не охватывает внутренние страницы, формы авторизации, страницы оформления заказа — там, где реальная передача данных наиболее активна.

OpenWPM

OpenWPM — это академическая исследовательская платформа для автоматизированного измерения веб-конфиденциальности. Написана на Python и использует headless-браузер для имитации реального пользовательского поведения [11]. Позволяет автоматически посещать тысячи страниц и собирать полный лог сетевых запросов, включая JavaScript-вызовы к внешним API.

Для корпоративного аудита OpenWPM можно настроить на обход всех страниц сайта, выполнение сценариев (заполнение форм, авторизация) и сохранение результатов в базу данных SQLite для анализа.

Расширения браузера для аудита

Ghostery — расширение для Chrome/Firefox, которое обнаруживает трекеры в реальном времени при просмотре страниц и показывает список внешних компаний, получающих данные [12]. Ghostery идентифицирует более 500 рекламных сетей и поставщиков поведенческих данных.

Privacy Badger от Electronic Frontier Foundation автоматически обучается блокировать трекеры и позволяет увидеть, какие домены ведут кросс-сайтовое отслеживание [13].

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

BuiltWith и Wappalyzer

Эти инструменты анализируют технологический стек сайта и косвенно указывают на внешние домены — они определяют, какие системы аналитики, рекламы и CRM установлены на сайте. BuiltWith строит полную «технографию» сайта, включая исторические данные.

Уровень 4: Анализ HTTP-заголовков и CSP

Content Security Policy (CSP) — это HTTP-заголовок, который разрешает браузеру загружать ресурсы только с указанных доменов [14]. Он создан для защиты от XSS-атак, но в контексте аудита ПДн работает как инвентарная опись всех авторизованных внешних доменов.

Читаем существующий CSP

Если CSP на сайте уже настроен, его содержимое — это фактически декларация всех внешних доменов, которым разрешено получать данные пользователей. Проверить CSP можно через curl:

curl -I https://example.ru | grep -i content-security-policy

Или через онлайн-инструмент CSP Evaluator (csp-evaluator.withgoogle.com). Пример типичного CSP крупного сайта:

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://www.google-analytics.com https://mc.yandex.ru 
             https://www.googletagmanager.com https://vk.com;
  img-src 'self' data: https://www.google-analytics.com https://pixel.roistat.com;
  connect-src 'self' https://api.amplitude.com https://sentry.io;

Каждый домен в CSP — потенциальный получатель ПДн. Анализ CSP даёт не динамический список (что реально передаётся), а декларативный (что разрешено). Расхождение между ними — отдельная зона риска.

Настраиваем CSP в режиме report-only

Если CSP ещё не настроен, используйте режим Content-Security-Policy-Report-Only. В этом режиме политика не блокирует запросы, но отправляет отчёты о нарушениях на указанный endpoint [15]. Фактически это позволяет «подсветить» все домены, к которым обращается сайт, без риска что-то сломать:

Content-Security-Policy-Report-Only: 
  default-src 'self'; 
  report-uri https://your-csp-collector.internal/report

После нескольких дней работы в этом режиме вы соберёте полный список внешних доменов в логах endpoint.

Анализ остальных заголовков

Помимо CSP, для инвентаризации полезны:

Referrer-Policy — определяет, сколько информации о URL текущей страницы передаётся при переходах на внешние ресурсы. Значение no-referrer-when-downgrade (дефолт) означает, что внешние скрипты видят полный URL страницы, который может содержать ПДн (например, https://site.ru/profile?user=ivan.petrov@email.com).

Set-Cookie с флагами SameSite и Secure — отсутствие этих флагов означает, что cookies могут передаваться при кросс-доменных запросах, фактически идентифицируя пользователя на внешних серверах.

Классификация выявленных доменов: матрица риска

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

Категория A — Аналитика и метрики

К этой категории относятся: Google Analytics (analytics.google.com, www.googletagmanager.com), Яндекс.Метрика (mc.yandex.ru), Roistat, Amplitude, Mixpanel, Heap и аналоги.

Риск: высокий. Передают IP-адрес, cookie-идентификаторы, URL страниц, параметры форм (если настроено расширенное отслеживание). Для российских компаний использование Google Analytics и GTM без уведомления РКН о трансграничной передаче — прямое нарушение с 1 июля 2025 года [4].

Действие: уведомить РКН о трансграничной передаче (для иностранных сервисов), либо перейти на российские аналоги — Яндекс.Метрику или Яндекс Тег Менеджер [16].

Категория B — Рекламные трекеры и пиксели

К этой категории относятся: Facebook Pixel (connect.facebook.net), VK Pixel (vk.com/js/api/openapi.js), Google Ads remarketing, myTarget, DoubleClick.

Риск: очень высокий. Пиксели ретаргетинга отправляют данные о посетителях в рекламные системы, при этом возможна идентификация пользователей через email-хэши (если настроено «расширенное соответствие»). Исследования выявляют передачу данных о конкретном пользователе на внешние рекламные домены в большинстве случаев [7].

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

Категория C — CRM и email-сервисы

К этой категории относятся: HubSpot, Salesforce, Bitrix24, AmoCRM, SendPulse, UniSender.

Риск: высокий. Данные форм на сайте могут напрямую отправляться в эти системы. Для российских CRM требуется договор-поручение на обработку ПДн. Для иностранных — дополнительно уведомление о трансграничной передаче.

Действие: заключить договор-поручение (ч. 3 ст. 6 152-ФЗ), убедиться в наличии серверов на территории РФ или законного основания для трансграничной передачи [6].

Категория D — CDN и инфраструктурные домены

К этой категории относятся: Cloudflare, Google Fonts (fonts.googleapis.com), jsDelivr, cdnjs.

Риск: средний. IP-адрес передаётся, но обычно не связывается с идентификатором пользователя. Тем не менее с формальной точки зрения IP — это ПДн в трактовке регулятора.

Действие: оценить возможность self-hosting критичных ресурсов (шрифты, библиотеки). Для государственных компаний и госсервисов использование иностранных CDN ограничено.

Категория E — Чат-виджеты и поддержка

К этой категории относятся: Intercom, Zendesk, JivoSite, Binotel, Talk-me.

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

Действие: для чат-виджетов иностранных провайдеров — уведомление РКН. Предпочтительно использование российских решений с серверами в РФ.

Категория F — Сервисы верификации и CAPTCHA

К этой категории относятся: Google reCAPTCHA, hCaptcha, Cloudflare Turnstile.

Риск: средний-высокий. С 1 июля 2025 года использование reCAPTCHA может трактоваться как нарушение, поскольку при её работе данные передаются на серверы Google в момент первичного сбора [17].

Действие: рассмотреть переход на российские или самостоятельно размещённые решения.

Практический чек-лист: пошаговый аудит

Подготовительный этап

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

Технический этап

1. Откройте каждую ключевую страницу в браузере с открытыми DevTools, вкладка Network. Зафиксируйте все внешние домены при загрузке страницы.
2. Заполните каждую форму тестовыми данными при открытой вкладке Network. Зафиксируйте, куда ушли POST-запросы и что именно в них содержалось.
3. Экспортируйте HAR-файлы для каждой ключевой страницы/сценария.
4. Проверьте GTM-контейнер: откройте URL GTM-скрипта, найдите все теги в JSON-конфигурации.
5. Проверьте сайт через Blacklight (themarkup.org/blacklight) — для быстрого первичного сканирования.
6. Проверьте заголовок Content-Security-Policy через curl или онлайн-инструмент. Сопоставьте список доменов в CSP с реальными запросами.

Аналитический этап

1. Сведите все обнаруженные домены в единую таблицу с колонками: домен, тип (аналитика/реклама/CRM/CDN), страна регистрации, тип данных, которые передаются, наличие договора-поручения, наличие уведомления РКН.
2. Классифицируйте домены по матрице риска (категории A–F из предыдущего раздела).
3. Проверьте, упомянуты ли все выявленные домены в Политике конфиденциальности сайта и в форме согласия на обработку ПДн.

Юридический этап

1. Для каждого внешнего домена, получающего ПДн, убедитесь в наличии одного из правовых оснований: договор-поручение на обработку ПДн (для российских операторов), уведомление РКН о трансграничной передаче (для иностранных операторов).
2. Проверьте, что серверы иностранных сервисов, которым передаются ПДн, находятся либо в «белом списке» РКН (государства — участники Конвенции Совета Европы), либо получено специальное разрешение.
3. Подготовьте или обновите уведомление в РКН, включив в него все иностранные домены-получатели.

Мониторинг

1. Настройте CSP в режиме Report-Only для непрерывного мониторинга новых внешних доменов.
2. Установите процедуру: любая установка нового скрипта, виджета или интеграции требует согласования с DPO/ИБ-командой до выхода в прод.
3. Повторяйте технический аудит минимум раз в квартал и при каждом крупном изменении сайта.

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

Ошибка 1. Аудит только главной страницы

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

Как избежать: обязательно проверяйте все страницы с пользовательским вводом, страницы авторизации и checkout-воронки.

Ошибка 2. Игнорирование динамически подгружаемых скриптов

GTM и аналогичные Tag Management Systems динамически загружают скрипты в зависимости от условий (тип устройства, UTM-метки, поведение пользователя). При разовом аудите вы можете пропустить скрипты, которые загружаются только для определённых сегментов аудитории.

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

Ошибка 3. Путаница между CSP-конфигурацией и реальным трафиком

CSP показывает, что разрешено, а не что реально передаётся. Отсутствие домена в CSP не означает, что данные туда не уходят — CSP может быть настроен слишком широко (например, script-src: *) или вообще отсутствовать.

Как избежать: сопоставляйте данные из CSP с реальными запросами из HAR-файлов.

Ошибка 4. Забытые скрипты от предыдущих подрядчиков

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

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

Ошибка 5. Отсутствие проверки мобильной версии

Мобильная версия сайта и нативные приложения могут иметь свои интеграции, отличные от десктопной. Мобильные SDK рекламных сетей работают иначе, чем браузерные JavaScript-трекеры.

Как избежать: проводите отдельный аудит мобильной версии сайта (с помощью mobile emulation в DevTools) и нативных приложений (через анализ трафика с прокси-сервером Charles или mitmproxy).

Ошибка 6. Только технический аудит без юридического оформления

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

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

Реальные кейсы: что находят при аудите

Кейс 1. Интернет-магазин и «забытый» пиксель

В ходе аудита среднего российского интернет-магазина были обнаружены запросы к домену connect.facebook.net при заполнении формы оформления заказа. Конфигурация Facebook Pixel включала «расширенное соответствие» — это означало, что хэш введённого email-адреса уходил в рекламные системы Meta. Проблема: подрядное агентство настроило пиксель 2 года назад, с тех пор отношения закончились, но скрипт остался в GTM. Согласие пользователя на передачу email Facebook получено не было. Договор-поручение на обработку ПДн между магазином и Meta отсутствовал.

Кейс 2. B2B-компания и Intercom

У компании в сфере B2B-SaaS был установлен Intercom для поддержки пользователей. При заполнении формы регистрации данные (имя, email, название компании) через JavaScript SDK Intercom немедленно отправлялись на серверы Intercom в США. Политика конфиденциальности компании упоминала Intercom, но уведомление РКН о трансграничной передаче ПДн (США не является стороной Конвенции Совета Европы) подано не было. После 1 июля 2025 года это квалифицируется как нарушение, влекущее штраф до 6 млн рублей за первое нарушение [1].

Кейс 3. Государственный портал и Google reCAPTCHA

При аудите портала государственных услуг регионального уровня обнаружена интеграция Google reCAPTCHA на форме обратной связи. Запросы при прохождении капчи уходили на www.google.com и www.recaptcha.net. Для государственных сайтов и организаций с долей государственного участия более 50% использование иностранных информационных систем, собирающих ПДн, ограничено законодательством [17].

Тренды и что будет дальше

Регуляторное давление в области трансграничной передачи ПДн будет только усиливаться. В 2025 году Роскомнадзор перешёл от точечных проверок к систематическому автоматическому мониторингу: автоматические сканеры ведомства ищут домены googletagmanager.com, google-analytics.com и другие маркеры иностранных систем прямо в коде сайтов [5]. По сути, регулятор применяет тот же технический метод статического анализа HTML, что описан выше в уровне 2.

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

Одновременно технологический ландшафт продолжает меняться. Google в очередной раз пересмотрел планы по отказу от сторонних cookies, сохранив их поддержку в Chrome [19]. Это означает, что cookie-based tracking будет актуален ещё несколько лет. Параллельно набирают силу более трудно обнаруживаемые методы: server-side tracking (где данные уходят не через браузер, а через бэкенд), fingerprinting, а также трекинг через CNAME-cloaking (когда внешний домен маскируется под поддомен вашего собственного сайта).

Последний метод — CNAME-cloaking — особенно коварен с точки зрения аудита: запрос к analytics.yoursite.ru выглядит как обращение к собственному домену, но по факту является CNAME-записью, указывающей на серверы внешнего аналитического сервиса. Обнаружить такие домены через DevTools сложнее — они не выделяются как «внешние» в стандартных фильтрах. Для их выявления необходимо проверять DNS-записи каждого поддомена.

Параллельно с ужесточением контроля со стороны государства усиливается давление со стороны самих пользователей: исследования показывают, что конфиденциальность входит в топ-10 организационных угроз у 93% организаций, а 36% ставят её в топ-5 [20].

Как «Пятый фактор» помогает решить эту задачу

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

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

Платформа «Пятый фактор» (5factor.ru) решает эту проблему системно. Это on-premise решение для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах — включая веб-слой, БД, CRM, 1С, API и другие источники.

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

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

Что делать дальше

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

Первое — проведите экспресс-проверку прямо сейчас. Откройте ваш сайт, включите DevTools, вкладку Network, заполните форму обратного звонка. Посмотрите, куда ушли данные. Это займёт 15 минут и с высокой вероятностью покажет как минимум несколько неожиданных доменов.

Второе — проверьте сайт через Blacklight. Быстрый способ получить обзорную картину без технических знаний.

Третье — проверьте GTM-контейнер. Если на сайте установлен GTM, откройте его конфигурацию и пересчитайте все теги. С 30 декабря 2025 года РКН штрафует за GTM без уведомления о трансграничной передаче [5].

Четвёртое — сопоставьте найденное с документами. Есть ли все обнаруженные домены в Политике конфиденциальности? Есть ли договоры-поручения с российскими получателями? Есть ли уведомления РКН для иностранных?

Пятое — выстройте процесс. Назначьте ответственного за проверку новых интеграций, настройте CSP в режиме Report-Only, поставьте технический аудит в calendar на ежеквартальную повторяющуюся задачу.

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

Источники

[1] Штрафы за персональные данные в 2026 году — https://data-sec.ru/personal-data/fines/

[2] Запрет Google Tag Manager с 1 июля 2025 года — https://blog.click.ru/markirovka-reklamy/zapret-google-tag-manager/

[3] Новые наказания за незаконную обработку персональных данных — https://buh.ru/articles/novye-nakazaniya-za-nezakonnuyu-obrabotku-personalnykh-dannykh-shtrafy-do-500-mln-rubley-i-ugolovnye.html

[4] Изменения закона о персональных данных: как подготовить сайт — https://aspro.ru/news/izmeneniya-zakona-o-personalnykh-dannykh/

[5] Роскомнадзор начал штрафовать за использование Google Tag Manager — https://vc.ru/services/2663449-shtrafy-za-ispolzovanie-google-tag-manager

[6] Федеральный закон № 152-ФЗ «О персональных данных» — https://www.consultant.ru/document/cons_doc_LAW_61801/

[7] Third-Party Web Tracking: Policy and Technology (Mayer, Mitchell) — https://jonathanmayer.org/publications/trackingsurvey12.pdf

[8] Регулирование Google Analytics в России в 2025 году — https://mosdigitals.ru/blog/regulirovanie-raboty-google-analytics-v-rossii-v-2025-godu

[9] Собирает ли Google Tag Manager персональные данные — https://external.software/archives/20467

[10] Blacklight — инспектор конфиденциальности сайтов (обзор vc.ru) — https://vc.ru/services/161950-inspektor-konfidencialnosti-saytov-kak-rabotaet-i-zachem-nuzhen-amerikanskiy-servis-blacklight

[11] Combating Web Tracking: Analyzing Web Tracking Technologies (Future Internet, 2024) — https://www.mdpi.com/1999-5903/16/10/363

[12] Ghostery — описание на comss.ru — https://www.comss.ru/page.php?id=1210

[13] Инструменты для сохранения приватности в интернете (Касперский) — https://www.kaspersky.ru/blog/anti-tracking-tools/22651/

[14] Content Security Policy — MDN (ru) — https://developer.mozilla.org/ru/docs/Web/HTTP/Guides/CSP

[15] Content-Security-Policy-Report-Only header — MDN — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy-Report-Only

[16] Яндекс Тег Менеджер как альтернатива GTM — https://workspace.ru/blog/kogda-nelzya-google-tag-manager-no-ochen-hochetsya-yandeks-predstavil-svoy-teg-menedzher/

[17] С 1 июля 2025 Google Analytics, формы, капча, WhatsApp и Telegram на сайте — под запретом — https://www.klerk.ru/blogs/roskom24/652336/

[18] An Automated Approach to Auditing Disclosure of Third-Party Data Collection in Website Privacy Policies (ACM WWW 2018) — https://dl.acm.org/doi/10.1145/3178876.3186087

[19] Guide to Third-Party Cookie Trackers (TrustArc) — https://trustarc.com/resource/guide-third-party-cookie-trackers/

[20] Control Considerations for a Data Privacy Audit (ISACA, 2025) — https://www.isaca.org/resources/news-and-trends/industry-news/2025/control-considerations-for-a-data-privacy-audit

[21] Staying HIPAA-Compliant: How to Detect Web Tracking Risks (Freshpaint) — https://www.freshpaint.io/blog/how-to-detect-web-tracking-risks-on-your-website

[22] Data Privacy and Cybersecurity in 2025: Website Tracking (McDermott) — https://www.mcdermottlaw.com/insights/data-privacy-and-cybersecurity-in-2025-website-tracking/

[23] Персональные данные: требования закона и ответственность (DashaMail) — https://dashamail.ru/blog/personal_data/

[24] Получение разрешения у Роскомнадзора на использование Google Analytics (Осипенков) — https://osipenkov.ru/roskomnadzor-google-analytics/

[25] Chrome DevTools: Inspect network activity — https://developer.chrome.com/docs/devtools/network