Beget, Reg.ru, Timeweb: для интернет-магазинов

Российские хостинг-провайдеры — Beget, Reg.ru и Timeweb — входят в реестр операторов ПДн РКН и располагают инфраструктурой в РФ, что закрывает требование локализации по ч. 5 ст. 18 ФЗ-152. Однако сам факт размещения на российском хостинге не освобождает интернет-магазин ни от определения уровня защищённости, ни от заключения договора поручения обработки, ни от применения мер по Приказу ФСТЭК №21. В этом материале — технико-правовой разбор: какие обязательства возникают у CTO при выборе хостинга, как выбрать нужный УЗ, что требовать от провайдера в договоре и где граница уголовной ответственности по ст. 272.1 УК.

Чем российский хостинг закрывает требования 152-ФЗ, а чем — нет?

Размещение баз данных с ПДн граждан РФ на серверах внутри страны соответствует требованию ч. 5 ст. 18 ФЗ-152 о локализации. Beget, Reg.ru и Timeweb физически размещают оборудование в российских дата-центрах, что подтверждается их статусом в реестре РКН. Это снимает риск штрафа по ч. 8 ст. 13.11 КоАП (1–6 млн ₽ за нарушение локализации).

Однако локализация — только один из блоков требований. ФЗ-152 отдельно обязывает оператора определить уровень защищённости ИСПДн (ПП РФ №1119), применить технические меры по Приказу ФСТЭК №21, заключить договор поручения обработки с провайдером по п. 3 ст. 6 ФЗ-152 и назначить ответственного по ст. 22.1. Ни Beget, ни Reg.ru, ни Timeweb эти обязательства за оператора не выполняют — их выполняет CTO совместно с юристом.

На практике это означает: если хостер допустит инцидент безопасности и из его инфраструктуры утекут данные клиентов интернет-магазина — протокол по ст. 13.11 КоАП получит оператор, а не хостер. Верховный суд последовательно поддерживает тезис об ответственности оператора за действия обработчика (case_generic_subpodryad).

Как выбрать уровень защищённости для интернет-магазина?

Уровень защищённости (УЗ) определяется по трём параметрам: категория ПДн, тип актуальных угроз и число субъектов. Для типового интернет-магазина, обрабатывающего ФИО, email, номер телефона, адрес доставки и историю заказов, применима следующая логика по ПП РФ №1119.

Если магазин хранит данные менее 100 000 субъектов и обрабатывает только общедоступные категории ПДн без биометрии и медицинских сведений — базовый уровень защищённости составит УЗ-4. При превышении порога 100 000 субъектов или при наличии специальных категорий ПДн (например, сведений о состоянии здоровья при доставке рецептурных препаратов) — УЗ-3. Угрозы 1-го типа (закладки в системном ПО) актуальны редко для коммерческих структур, поэтому большинство e-commerce работает в диапазоне УЗ-3–УЗ-4.

Выбор УЗ фиксируется во внутреннем документе — акте определения уровня защищённости. Без него проверяющий инспектор РКН квалифицирует ситуацию как отсутствие организационных мер по ст. 18.1 ФЗ-152, что даёт основание для штрафа по ч. 3 ст. 13.11 КоАП (30–60 тыс. ₽ для юрлица, но это не предел: одновременно могут быть возбуждены дела по ч. 1 и ч. 2).

Что должен содержать договор поручения обработки с Beget, Reg.ru или Timeweb?

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

Стандартные публичные оферты Beget, Reg.ru и Timeweb содержат общие положения об ИБ, но, как правило, не включают явный перечень ПДн и не фиксируют УЗ, применяемый провайдером к данным клиента. Это означает, что для полного соответствия ФЗ-152 потребуется либо отдельное DPA (Data Processing Agreement), либо дополнительное соглашение к основному договору.

Провайдеры корпоративного уровня — Beget Business, Reg.ru Enterprise, Timeweb Cloud Pro — предлагают такие соглашения в рамках корпоративных тарифов. На стандартных тарифах CTO либо подписывает универсальную оферту (с рисками неполноты), либо инициирует заключение дополнительного соглашения. Второй вариант юридически корректен; первый создаёт уязвимость при проверке.

Обезличивание для ML и логирование: где граница персональных данных?

Интернет-магазины всё чаще используют данные покупательского поведения для рекомендательных систем и ML-моделей. Здесь возникает вопрос: остаются ли данные о кликах, просмотрах и транзакциях персональными после агрегации?

По позиции РКН, данные считаются обезличенными, если применены методы по приказу регулятора: введение идентификаторов вместо прямых атрибутов, изменение состава и семантики, декомпозиция, перемешивание или обобщение (агрегация). Псевдонимизация через замену email на хэш без использования соли — не обезличивание: при наличии исходной таблицы данные восстанавливаются. Такой набор данных остаётся персональными по ст. 3 ФЗ-152.

Для ML-моделей, обучаемых на поведенческих данных, рекомендуется агрегация на уровне когорт (не менее k=5 субъектов в группе) до передачи в обучающий пайплайн. Это соответствует методу обобщения из приказа РКН о методах обезличивания. Хранение необезличенных логов на хостинге — это обработка ПДн, которая требует правового основания по ст. 6 ФЗ-152 и включения в политику конфиденциальности.

Отдельная тема — логи веб-сервера (IP-адреса, User-Agent, временные метки). РКН считает IP-адрес персональным данным при наличии возможности идентификации субъекта. Если хостер ведёт access-логи и передаёт их клиенту — они входят в периметр обработки ПДн оператора. Срок хранения логов должен быть зафиксирован в ОРД и не превышать необходимого по принципу ст. 5 ФЗ-152.

Мультиарендность SaaS и КИИ: что меняется для e-commerce на облачном хостинге?

Если интернет-магазин работает на SaaS-платформе (например, Shopify-аналог российского производства или облачный конструктор на Timeweb), возникает вопрос о разграничении ролей. Оператором ПДн покупателей является магазин — он определяет цели и состав обработки. SaaS-провайдер — обработчик по поручению. Это разграничение критично: при мультиарендной архитектуре данные разных магазинов могут храниться в одной БД с логической изоляцией, но без физического разделения.

Логическая изоляция приемлема при УЗ-4, но при УЗ-3 Приказ ФСТЭК №21 требует более строгого контроля доступа (группа мер УПД) и регистрации событий (группа РСБ). CTO должен запросить у провайдера подтверждение, что инфраструктура соответствует выбранному УЗ, — желательно в форме технического паспорта ИСПДн или письма с перечнем реализованных мер.

Если интернет-магазин относится к субъектам КИИ по ФЗ-187 (это редкость для e-commerce, но актуально для маркетплейсов с критической инфраструктурой или операторов связи) — к требованиям добавляются меры по безопасности значимых объектов. На практике большинство интернет-магазинов под КИИ не подпадают, но CTO стоит проверить критерии отнесения по Постановлению Правительства о категорировании.

Типовые сценарии: как это выглядит при проверке РКН

Сценарий 1. Интернет-магазин без договора поручения. Магазин размещён на Beget на стандартном тарифе. Оферта подписана, но отдельного DPA нет. РКН проводит внеплановую документарную проверку по жалобе субъекта. Инспектор запрашивает договор поручения обработки с хостером — его нет. Это нарушение п. 3 ст. 6 ФЗ-152, которое квалифицируется как обработка без надлежащего правового основания по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽). При наличии аналогичного нарушения ранее — ч. 1.1 (300–500 тыс. ₽). Стратегия: заключить DPA до проверки, зафиксировать дату подписания; при протоколе — подать возражения с приложением договора.

Сценарий 2. Утечка через панель управления хостера. Хакер получил доступ к панели управления Reg.ru через скомпрометированные учётные данные сотрудника CTO-службы. Выгружена база с 15 000 записей покупателей (ФИО, email, телефон, адрес доставки). По ч. 3.1 ст. 21 ФЗ-152 у оператора — 24 часа на первичное уведомление РКН и 72 часа на отчёт о расследовании по Приказу РКН №187. Несоблюдение — штраф 1–3 млн ₽ по ч. 11 ст. 13.11. Сама утечка 15 000 субъектов — ч. 13 ст. 13.11 (5–10 млн ₽). Если компания уже привлекалась по ч. 12–14 ранее — оборотный штраф по ч. 15 (1–3% выручки, не менее 20 млн ₽). Стратегия: отлажённый playbook реагирования, двухфакторная аутентификация к панели хостера, мониторинг аномальных сессий.

Сценарий 3. ML-модель на необезличенных данных. CTO развернул рекомендательную систему на Timeweb Cloud, обучая модель на полном профиле покупателя (ФИО, история заказов, поведение на сайте). Обезличивание не применялось. При проверке РКН выяснилось, что обработка данных в целях ML не указана в политике конфиденциальности и не охвачена согласием субъекта. Нарушение ст. 6 ФЗ-152 (обработка без основания) и ст. 5 (несовместимость целей). Ч. 1 ст. 13.11 — 150–300 тыс. ₽, возможно ч. 2 (300–700 тыс. ₽ при отсутствии согласия). При умысле и систематичности — риск ст. 272.1 УК (введена ФЗ-421, действует с 11.12.2024). Стратегия: обезличить данные до обучения, расширить согласие и политику, провести DPIA.

Кейс 1. IT-компания из Сибирского федерального округа (осень 2025), оператор SaaS-платформы для e-commerce, прошла аудит DATUM после получения предписания РКН. Выявлено: договор поручения с тремя хостерами не содержал перечня ПДн и не фиксировал УЗ; обезличивание ML-данных не применялось; логи хранились бессрочно. После устранения нарушений и подачи возражений протокол по ч. 1 ст. 13.11 был прекращён в связи с добровольным устранением. CTO получил задокументированный пакет ОРД и технический паспорт ИСПДн.

Кейс 2. Интернет-магазин из Центрального федерального округа (начало 2026) зафиксировал утечку 8 000 записей покупателей через скомпрометированный API-ключ хостера. DATUM подключился в течение первого часа: первичное уведомление РКН направлено за 20 часов, отчёт — в рамках 72-часового окна по Приказу РКН №187. Применена ст. 4.1.1 КоАП — первичность нарушения. Арбитражный суд региона снизил штраф по ч. 12 ст. 13.11 (базовый диапазон 3–5 млн ₽) до минимального значения с учётом оперативности реагирования. ⚠️ Точная сумма и номер дела — менеджер уточняет при публикации.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка ИСПДн, УЗ, договоров с хостерами, ОРД
• DPIA (оценка воздействия) — для ML-систем и облачных SaaS-архитектур
• Комплект ОРД под ключ — политика, акт УЗ, договор поручения, регламенты

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

1. Какой УЗ выбрать для SaaS-платформы интернет-магазина?

Уровень защищённости определяется по ПП РФ №1119: категория ПДн, число субъектов и тип актуальных угроз. Для большинства e-commerce-платформ, обрабатывающих контактные данные и историю заказов менее 100 000 субъектов без биометрии, применяется УЗ-4. При превышении порога 100 000 субъектов или наличии специальных категорий ПДн — УЗ-3. При мультиарендной SaaS важно учитывать, что УЗ определяется для каждой ИСПДн отдельно, а не для всей платформы в целом.

2. Можно ли использовать иностранные облака для данных российских покупателей?

Первичный сбор, систематизация и хранение ПДн граждан РФ обязаны осуществляться в базах данных на серверах в России — это требование ч. 5 ст. 18 ФЗ-152 в ужесточённой редакции с 01.07.2025 (ФЗ-233). Использование AWS, GCP или Azure в качестве основного хранилища для российских покупателей нарушает требование локализации и грозит штрафом по ч. 8 ст. 13.11 КоАП (1–6 млн ₽) или ч. 9 при повторности (6–18 млн ₽). Beget, Reg.ru и Timeweb закрывают это требование — но только при условии, что основная база ПДн физически размещена у них, а не реплицируется за рубеж.

3. Что такое обезличивание для ML и чем оно отличается от псевдонимизации?

Обезличивание по приказу РКН — это применение одного из пяти методов (введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение), при которых идентификация субъекта становится невозможной без дополнительной информации, хранящейся отдельно. Псевдонимизация (замена email на хэш при сохранении таблицы сопоставления) — не обезличивание: данные остаются персональными по ст. 3 ФЗ-152. Для ML-пайплайна рекомендуется агрегация на уровне когорт и удаление прямых идентификаторов до передачи в обучающую выборку.

4. Кто является оператором ПДн при использовании мультиарендной SaaS?

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

5. Какие СЗИ обязательны при размещении ИСПДн на хостинге?

Состав обязательных средств защиты информации определяется Приказом ФСТЭК №21 в зависимости от УЗ. Для УЗ-4 базовый набор включает: идентификацию и аутентификацию (группа ИАФ), управление доступом (УПД), антивирусную защиту (АВЗ), межсетевое экранирование (ЗИС) и регистрацию событий безопасности (РСБ). Для УЗ-3 добавляются обнаружение вторжений (СОВ) и контроль целостности (ОЦЛ). При размещении на облачном хостинге часть мер может быть реализована провайдером — это должно быть зафиксировано в договоре поручения с указанием конкретных мер и ответственной стороны.

Итог

Beget, Reg.ru и Timeweb закрывают требование локализации по ч. 5 ст. 18 ФЗ-152 и снимают риск штрафа по ч. 8 ст. 13.11 КоАП. Но остальной периметр обязательств — определение УЗ, договор поручения, применение мер ФСТЭК, обезличивание для ML и реагирование на инциденты за 24 часа — лежит на операторе и его CTO. С 30.05.2025 цена ошибки выросла кратно: повторная утечка влечёт оборотный штраф до 500 млн ₽ по ч. 15 ст. 13.11, а умышленный сбор данных без основания — уголовную ответственность по ст. 272.1 УК.

DATUM сопровождает IT-команды интернет-магазинов в части 152-ФЗ: от определения УЗ и составления договоров поручения до реагирования на утечки и защиты в арбитраже по ст. 13.11. Практика охватывает все три крупнейших российских хостинга и облачные SaaS-архитектуры.