Российский хостинг: когда он обязателен, реестр провайдеров и локализация персональных данных

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

Дисклеймер. Материал не является юридической консультацией. Требования к обработке персональных данных и к хостинг-провайдерам регулярно меняются, а правоприменение уточняется разъяснениями регулятора. Перед любыми решениями сверяйтесь с действующими редакциями законов на pravo.gov.ru и с материалами Роскомнадзора на rkn.gov.ru, а по спорным местам — с юристом.

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

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

Ключевая ошибка — считать, что «персональные данные» это только паспорт и СНИЛС. На практике оператором делает сайт почти любой из этих элементов:

• форма заявки или обратного звонка с именем и телефоном;
• регистрация, личный кабинет, авторизация через сторонние сервисы;
• оформление заказа с адресом доставки;
• подписка на рассылку по e-mail;
• чат поддержки, где пользователь называет себя и оставляет контакт;
• загрузка пользователем документов, фото, резюме;
• отзывы и комментарии с привязкой к учётной записи;
• аналитика и рекламные пиксели, которые собирают идентификаторы устройства и поведение.

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

Три обязанности, которые часто путают

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

1. Локализация первичной базы — данные россиян записываются и хранятся в базах на территории РФ.
2. Уведомление Роскомнадзора об обработке персональных данных — самостоятельная обязанность оператора, не заменяемая переездом на российский хостинг.
3. Организационные и технические меры защиты — политика обработки, согласия, разграничение доступа, сроки хранения, ответственный за организацию обработки, журналы доступа.

Типичная картина у среднего бизнеса: сервер уже в России, а уведомление не подано и политика написана десять лет назад «по образцу из интернета». С точки зрения проверки это три отдельных пункта, а не один.

Что реально означает локализация персональных данных

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

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

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

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

Реестр хостинг-провайдеров: что это значит для владельца сайта

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

Что из этого следует практически:

• Проверяйте статус провайдера сами. Перечень публикуется регулятором — это открытая информация, а не «по словам менеджера».
• Смотрите на юрлицо в договоре, а не на бренд сайта. Часто продаёт услугу одно юрлицо, а мощности арендуются у другого; в реестре фигурирует конкретная организация.
• Отличайте реселлера от владельца инфраструктуры. Реселлер может честно перепродавать хорошие мощности, но цепочка ответственности при инциденте удлиняется, а рычагов у вас меньше.
• Не путайте реестр с аттестацией. Присутствие в перечне хостинг-провайдеров и наличие у площадки аттестованного сегмента под определённый уровень защищённости — разные вещи, и второе нужно спрашивать отдельно, если ваша система того требует.

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

Типичные разрывы: сервер в РФ, а данные уходят наружу

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

Форма постится напрямую во внешний сервис

Конструкторы форм, чат-виджеты и CRM-виджеты обычно подключаются одной строкой скрипта, и данные из полей уходят на их домен, минуя ваш бэкенд. Лечится переносом приёмника: форма отправляется на собственный эндпоинт, тот пишет запись в базу в России, и только потом фоновая задача синхронизирует нужные поля наружу. Дополнительный бонус — вы перестаёте зависеть от доступности виджета: если внешний сервис лежит, заявка всё равно сохранена.

Рассыльщик как первичное хранилище

Подписка «оставьте e-mail» часто устроена так, что единственное место, где живёт база подписчиков, — это зарубежный сервис рассылок. Первичная база в этом случае за границей. Правильная схема: своя таблица подписчиков в РФ как источник истины, внешний сервис — как канал доставки, синхронизируемый по расписанию и очищаемый от лишних полей.

Аналитика и рекламные пиксели

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

Логи и мониторинг

Внешние сервисы сбора логов и ошибок фронтенда охотно принимают всё подряд: URL с токеном в query-параметре, тело запроса, e-mail пользователя в контексте ошибки. Формально это тоже передача данных. Минимум — маскирование чувствительных полей на стороне отправителя и понимание, где физически лежит хранилище логов.

Резервные копии

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

CDN и зарубежные прокси перед сайтом — отдельный риск

Схема, когда перед сайтом стоит зарубежный CDN или reverse-proxy, создаёт сразу три проблемы. Первая: трафик с персональными данными терминируется на чужом узле за пределами РФ — там расшифровывается TLS, и оператор прокси технически видит содержимое запросов. Вторая: реальный IP-адрес сервера скрыт, и «где стоит сервер» перестаёт быть очевидным даже для вас — а восстанавливать это в момент проверки поздно. Третья: доступность становится зависимой от чужой сети, на маршрутизацию которой вы не влияете.

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

Проверяйте не только фронт. Если перед сайтом стоит прокси, «сервер в России» надо доказывать по origin-адресу, а не по адресу, который видит браузер. Держите у себя актуальную схему: домен → CDN/прокси → origin → база → бэкапы, с указанием страны на каждом шаге.

Логи, IP-адреса и cookie: что считать персональными данными

Вопрос «является ли IP персональными данными» на практике решается не абстрактно, а по контексту: если IP лежит рядом с идентификатором пользователя, номером заказа или сессией, он позволяет соотнести действия с конкретным человеком — и относиться к нему нужно как к персональным данным. Аналогично с cookie-идентификаторами и отпечатками устройства.

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

# nginx: усечение IP-адреса в журнале доступа
# IPv4 -> последний октет обнуляется, IPv6 -> остаётся первый префикс
map $remote_addr $ip_anon {
    ~^(?P<pfx4>\d+\.\d+\.\d+)\.\d+$   $pfx4.0;
    ~^(?P<pfx6>[^:]+:[^:]+):          $pfx6::;
    default                            0.0.0.0;
}

log_format privacy '$ip_anon - [$time_local] "$request" '
                   '$status $body_bytes_sent "$http_referer"';

access_log /var/log/nginx/access.log privacy;

# срок хранения журналов: 14 суток вместо «вечно»
# /etc/logrotate.d/nginx-privacy
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

Если полный IP нужен для антифрода или расследования инцидентов — это законная цель, но она должна быть заявлена, а срок хранения ограничен. «Храним всё и навсегда, вдруг пригодится» — не цель.

Когда российский хостинг не обязателен

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

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

Таблица: типовые сценарии и минимум действий

Сценарий сайта	Собираются ли ПДн россиян	Возникает ли обязанность локализации	Что сделать как минимум
Визитка без форм, без счётчиков, без комментариев	Нет	Нет	Зафиксировать это письменно и перепроверять при каждом добавлении блока на сайт
Лендинг с формой заявки или обратного звонка	Да (имя, телефон, e-mail)	Да	Приём формы на своём сервере в РФ, база в РФ, политика и согласие, уведомление регулятора
Интернет-магазин с оформлением заказа	Да (контакты, адрес доставки, история заказов)	Да	Всё из предыдущей строки плюс контроль передач в службы доставки и платёжные сервисы, сроки хранения заказов
SaaS с личным кабинетом	Да (учётные записи, пользовательский контент, логи действий)	Да	Первичная база и бэкапы в РФ, разграничение доступа сотрудников, журналирование доступа, договорная фиксация с подрядчиками
Зарубежный сайт, ориентированный на аудиторию из РФ (русский язык, цены в рублях, доставка по РФ)	Да	Да — ориентация на российскую аудиторию является ключевым признаком	Выделить российский сегмент обработки: база для пользователей из РФ в РФ, остальное — как трансграничная передача
Витрина без форм, но с внешней аналитикой и пикселями	Да, косвенно (идентификаторы, поведение)	Спорная зона — оцените состав собираемого	Инвентаризовать все внешние скрипты, убрать лишние, добавить cookie-баннер и политику

Что проверить у провайдера перед переездом

Это разговор не с отделом продаж, а с техподдержкой и юристом провайдера. Хороший провайдер отвечает на такие вопросы письменно и быстро; уклончивые ответы — сами по себе результат проверки.

• Юрлицо и договор. Кто именно сторона договора, российское ли это юридическое лицо, есть ли поручение на обработку персональных данных с перечнем действий и мерами защиты.
• Наличие в реестре хостинг-провайдеров. Проверяется по данным регулятора, а не по логотипу на сайте.
• Размещение ЦОД. Конкретные площадки и города, а не «дата-центры уровня Tier III». Важно, стоят ли мощности в собственном ЦОД или арендуются, и у кого.
• Аттестации и уровни защищённости. Нужны ли они вам — зависит от типа данных; спрашивайте предметно, под какой класс систем есть аттестованный сегмент.
• Где лежат резервные копии. Страна, срок хранения, шифрование, кто имеет доступ, как проверяется восстановление.
• Порядок реакции на запросы. Как провайдер уведомляет клиента о запросах в его адрес, есть ли сроки, кто подписывает ответы.
• SLA и компенсации. Не только процент доступности, но и что считается простоем, как он фиксируется и кем.
• Миграция и выход. Возможность забрать данные и образы, сроки удаления после расторжения, есть ли vendor lock-in на панели управления.
• Инженерная реальность. Каналы, защита от DDoS на входе, доступ к IPMI/консоли, скорость реакции по тикетам ночью.

Крупные российские площадки — например, Selectel — публично раскрывают перечень своих ЦОД и реквизиты юрлица, и это первое, что стоит открыть до сравнения тарифов. Сравнение форм размещения — shared, VPS, выделенный сервер — разобрано отдельно в статье про shared, VPS и выделенные серверы, а обзорный разбор площадок — в подборке хостинг-провайдеров.

Как проверить

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

Инструментами enterno.io

• Проверка IP — где физически расположен сервер, какой автономной системе принадлежит адрес, чей это провайдер. Проверяйте и домен, и origin-адрес, если перед сайтом стоит прокси.
• WHOIS — регистратор и владелец домена, даты продления, серверы имён. Домен у зарубежного регистратора при российском хостинге — не нарушение, но это точка отказа, о которой стоит знать.
• Проверка блокировок — не находится ли домен или IP в реестрах ограничения доступа. Особенно актуально для shared-хостинга, где вы делите IP с соседями.
• Проверка по требованиям 152-ФЗ — есть ли на страницах политика обработки, согласие у форм, cookie-баннер, корректны ли ссылки в подвале.
• Флаги cookie и баннер — выставлены ли Secure, HttpOnly и SameSite, не ставятся ли трекинговые cookie до получения согласия.

Из командной строки

# 1. Куда резолвится домен и какие адреса отдаёт DNS
dig +short example.ru A
dig +short www.example.ru A

# 2. Чей это адрес: сеть, страна, организация
whois 203.0.113.10 | grep -Ei 'netname|country|org-name|descr|origin'

# 3. Маршрут до сервера — видно, через какие сети идёт трафик
traceroute -n -w 2 -q 1 example.ru

# 4. Не стоит ли перед сайтом внешний прокси или CDN
curl -sSI https://example.ru | grep -Ei 'server:|via:|x-cache|x-served-by|cf-ray'

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

# все внешние хосты, к которым обращается фронтенд
grep -rEoh 'https?://[A-Za-z0-9._-]+' . \
  --include='*.html' --include='*.js' --include='*.php' --include='*.tpl' \
  | sed -E 's#https?://##' | sort -u

# куда постятся формы и какие есть внешние вызовы
grep -rEn 'action="https?://|fetch\(|XMLHttpRequest|axios\.(get|post)' . \
  --include='*.html' --include='*.js' --include='*.php'

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

Чек-лист приведения сайта в соответствие

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

1. Инвентаризация данных. Какие поля собираются, на каких страницах, куда попадают, сколько хранятся, кто имеет доступ.
2. Инвентаризация получателей. Полный список внешних сервисов из кода, а не из памяти.
3. Первичная база в РФ. Все формы приземляются на свой бэкенд; внешние интеграции переводятся в режим синхронизации «после записи».
4. Бэкапы в РФ. Проверить фактическое расположение хранилища копий и шифрование.
5. Уведомление Роскомнадзора. Отдельная обязанность, её не закрывает переезд сервера.
6. Политика обработки персональных данных. Опубликована, доступна с каждой страницы, описывает реальные цели, состав данных, получателей и сроки.
7. Согласия. Отдельный чекбокс, не предустановленный, с понятной формулировкой цели; факт согласия логируется вместе с датой и версией текста.
8. Cookie-баннер. Трекинговые скрипты не грузятся до согласия; выбор пользователя сохраняется и уважается.
9. Разграничение доступа. Кто из сотрудников и подрядчиков видит персональные данные, есть ли журналирование доступа, отзываются ли учётки при увольнении.
10. Сроки хранения. Определены для каждой категории; есть механизм удаления, а не только намерение.
11. Ответственный за организацию обработки. Назначен приказом, знает о своей роли.
12. Мониторинг. Доступность и корректность отслеживаются постоянно, чтобы обнаруживать регрессии — например, когда разработчик вернул на сайт удалённый внешний виджет.

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

Риски «серых» решений

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

• Проверяемость. Куда браузер отправляет данные, видно в инструментах разработчика за минуту. Это не скрытая информация.
• Расхождение с документами. Политика, описывающая несуществующую архитектуру, ухудшает положение, а не улучшает: она фиксирует, что оператор знал о требовании.
• Ответственность. За нарушения в области обработки персональных данных предусмотрена административная ответственность; размеры санкций пересматривались и имеют тенденцию к росту, поэтому ориентироваться нужно на действующую редакцию КоАП, а не на цифры из старых статей.
• Операционная хрупкость. Схемы с прокси и «серой» маршрутизацией ломаются при первом же изменении на стороне посредника, и чинить их приходится в момент, когда сайт уже недоступен.
• Блокировка по IP. Если ресурс попадает под ограничение доступа, страдает вся площадка, а восстановление занимает время. Что делать в этой ситуации — разобрано в руководстве для владельца заблокированного сайта.

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

Мониторинг после переезда

Переезд — это не конец, а точка, после которой начинается контроль. Что стоит держать под наблюдением постоянно:

• доступность сайта и времена отклика с российских точек — деградация после переезда встречается часто;
• срок действия TLS-сертификата и корректность цепочки на новом сервере;
• резолвинг DNS: не остались ли старые A-записи у части резолверов после смены IP;
• появление новых внешних запросов на страницах — сигнал, что кто-то вернул сторонний виджет;
• наличие домена и IP в реестрах ограничения доступа.

Как это выстроить в постоянный процесс с уведомлениями — в материале про мониторинг сайта и требования 152-ФЗ. Точечные проверки удобно делать вручную через мониторинг, проверку DNS и анализ HTTP-заголовков.

Частые вопросы

Обязателен ли российский хостинг, если у меня только форма обратной связи?

Да, если форма собирает имя, телефон, e-mail или иные данные, позволяющие идентифицировать человека. Объём не имеет значения: одна форма делает вас оператором так же, как и личный кабинет на сто тысяч пользователей. Разница только в масштабе мер защиты, а не в наличии обязанности.

Можно ли пользоваться зарубежной аналитикой и внешним рассыльщиком?

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

Считается ли IP-адрес персональными данными?

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

Нужно ли подавать уведомление в Роскомнадзор маленькому сайту?

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

Помогает ли VPS в России, если база данных в зарубежном облаке?

Нет. Требование касается базы, а не веб-сервера. Если приложение работает на российском VPS, а СУБД или управляемый сервис хранения находится за рубежом, первичная запись происходит за пределами РФ. Переносить нужно именно хранилище, включая реплики и резервные копии.

Что делать зарубежной компании с русскоязычным сайтом?

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

Чек-лист

• Определено, обрабатывает ли сайт персональные данные граждан РФ, и зафиксирован состав полей.
• Первичная база размещена в России; проверено фактическое расположение сервера и origin за прокси.
• Формы отправляются на собственный эндпоинт, а не напрямую во внешние сервисы.
• Составлен полный список внешних получателей данных по исходникам, а не по памяти.
• Резервные копии хранятся в РФ, зашифрованы, восстановление проверялось.
• Провайдер: российское юрлицо, наличие в реестре хостинг-провайдеров проверено, ЦОД и площадки известны.
• Получены письменные ответы по SLA, порядку реакции на запросы и условиям выхода.
• Подано уведомление об обработке персональных данных.
• Политика обработки опубликована и описывает реальную архитектуру и реальных получателей.
• Согласия оформлены отдельным непредустановленным чекбоксом и логируются с датой и версией текста.
• Cookie-баннер блокирует трекинг до согласия; флаги Secure, HttpOnly, SameSite выставлены.
• Сроки хранения определены, механизм удаления работает, логи ротируются.
• Назначен ответственный за организацию обработки персональных данных.
• Настроен мониторинг доступности, TLS, DNS и появления новых внешних запросов на страницах.