HTTPS/SSL и 152‑ФЗ: когда обязателен защищённый канал

Table of contents

• Кратко: зачем HTTPS при обработке ПДн
• Когда HTTPS обязателен по 152‑ФЗ
• Как закон формулирует требования
• Какие данные на сайте считаются ПДн
• HTTPS как мера защиты и его пределы
• Технические настройки TLS/SSL: минимум к соответствию
• Серверы и хостинг под 152‑ФЗ
• Проверка соответствия: быстрый чек‑лист
• Частые ошибки и риски
• Связанные требования (cookie, аналитика, формы)
• Ответственность и штрафы
• FAQ: когда HTTPS можно не применять?
• Итоги и что делать дальше

Кратко: зачем HTTPS при обработке ПДн

Если вы собираете на сайте имя, телефон, e‑mail, резюме, адрес, данные детей, записи на приём или оформляете заказ — вы оператор ПДн. В таком случае защищённый канал связи (HTTPS/SSL) — базовая мера, которая снижает риски перехвата и подмены данных при передаче. Требование использования HTTPS 152‑ФЗ прямо следует из общего принципа «защита информации 152 ФЗ» и конкретизируется подзаконными актами о безопасности ИСПДн.

Ключевая мысль: как только на сайте есть формы, личный кабинет или API, где идут персональные данные, канал должен быть защищён.

Когда HTTPS обязателен по 152‑ФЗ

Ниже — практическая таблица «сценарий ↔ требование». Это поможет понять, когда «https 152 фз» обязателен, а когда — рекомендателен.

Сценарий	Есть ПДн?	HTTPS обязателен?	Пояснение
Форма обратной связи (имя, e‑mail, телефон)	Да	Да	Передача идентификаторов субъекта — ПДн.
Подписка на рассылку (почта)	Да	Да	E‑mail — ПДн; нужен защищённый канал.
Онлайн‑оплата	Да (в т.ч. чувствительные данные)	Да	Плюс требования платёжных систем; строгий TLS.
Запись к врачу/сервис с медданными	Да (спецкатегории)	Да	Усиленные меры защиты и разделение контуров.
Загрузка резюме (ФИО, опыт, контакты)	Да	Да	Требуется TLS и организационные меры.
Личный кабинет пользователя	Да	Да	Аутентификация/сессии требуют шифрования.
Статический сайт без форм	Нет	Не обязательно	Но HTTPS рекомендуется (HSTS, SEO, доверие).
Анонимный опрос без идентификаторов	Скорее нет	Опционально	Если исключены деанонимизирующие поля и IP не привязывается.

Важно: даже если ПДн «только видны» (история заказов в личном кабинете) без ввода, соединение всё равно должно быть защищено.

Как закон формулирует требования

• Базовые нормы об обязанностях оператора содержатся в статье 19 152‑ФЗ — «Меры по обеспечению безопасности ПДн». Подробнее см. ст. 19 152‑ФЗ и раздел Меры безопасности ПДн.
• HTTPS относится к мерам защиты при передаче данных по сетям связи. В ряде ИСПДн может потребоваться применение сертифицированных средств криптозащиты, см. требования ФСТЭК и ФСБ и криптография и шифрование.
• Объект регулирования — ИСПДн (информационная система персональных данных). Определение и уровни защищенности смотрите в ИСПДн: определение и требования и уровни защищенности ИСПДн.

Если кратко: использование https 152 фз — не единственное требование, а элемент комплекса мер защиты.

Какие данные на сайте считаются ПДн

К персональным данным относятся любые сведения, прямо или косвенно относящиеся к физическому лицу: ФИО, контактные данные, идентификаторы, профили, адреса доставки. См. термины и определения, ст. 3, принципы и цели обработки.

Особые случаи:

• Специальные категории (здоровье, убеждения) — специальные категории ПДн;
• Биометрия — биометрические ПДн;
• Данные детей — дети и несовершеннолетние.

Для всех перечисленных HTTPS обязателен и дополняется усиленными мерами.

HTTPS как мера защиты и его пределы

Защищённый канал решает задачу «шифрование персональных данных согласно 152 фз» на этапе передачи между браузером и сервером. Но этого недостаточно:

• На серверной стороне должны действовать организационные и технические меры: разграничение доступа, журналирование, резервное копирование, антивирус/EDR, контроль уязвимостей — см. модель угроз ИСПДн и меры безопасности ПДн.
• Внутрицепочечные интеграции (CRM, платёжные шлюзы, почтовые сервисы) тоже должны использовать защищённые каналы и договорные отношения — см. поручение обработки ПДн и передача третьим лицам.
• Для контуров с высокими рисками могут потребоваться сертифицированные СКЗИ (ГОСТ), особенно при межсетевом взаимодействии с ИСПДн высокого уровня — смотрите требования ФСТЭК и ФСБ.

Вывод: HTTPS необходим, но должен сочетаться с другими мерами «защита информации 152 фз».

Технические настройки TLS/SSL: минимум к соответствию

Рекомендации для публичных сайтов и API, обрабатывающих ПДн:

• Протоколы: TLS 1.2 и 1.3 включены; TLS 1.0/1.1 выключены.
• Шифросuites: только современные, с ECDHE (PFS). Отключить устаревшие (RC4, 3DES, MD5, SHA‑1).
• Сертификат: действующий DV/OV/EV от доверенного УЦ; для поддоменов — wildcard. Самоподписанные сертификаты нельзя.
• HSTS: включить (с осторожностью при mixed content). Можно добавить preload, когда сайт готов.
• OCSP stapling: включить для ускорения проверки отзыва.
• SNI: корректная настройка на балансировщике/веб‑сервере.
• Политики безопасности: Content‑Security‑Policy (upgrade‑insecure‑requests), Referrer‑Policy, X‑Content‑Type‑Options.
• Сжатие TLS (CRIME/BREACH): отключить, использовать безопасные заголовки для CSRF/XSS.

Таблица мини‑чеклистов для DevOps:

Параметр	Рекомендация
Протоколы	TLS 1.2/1.3
Ключ	RSA 2048+ или EC P‑256/384
PFS	ECDHE обязательна
HSTS	max‑age ≥ 15552000, includeSubDomains при готовности
Кросс‑домены	Настроить CORS только на доверенные origin
Мониторинг	Автопроверка срока действия, алерты

Дополнительно: для популярных CMS см. практики в разделах WordPress и 152‑ФЗ, Tilda и 152‑ФЗ, 1C‑Битрикс и 152‑ФЗ. Требования к вебу в целом — в требования к сайту 152‑ФЗ.

Серверы и хостинг под 152‑ФЗ

Тема «серверы 152 фз» включает как технические, так и юридические аспекты:

• Размещение и инфраструктура: при первичном сборе ПДн граждан РФ действуют требования локализации (см. связанные законы 149‑ФЗ, 187‑ФЗ, 63‑ФЗ, 98‑ФЗ). Выбирайте дата‑центры и облака, соответствующие российскому праву — см. Серверы, хостинг, ЦОД и Облака: Yandex Cloud и 152‑ФЗ.
• Сегментация: публичный веб‑контур (DMZ) отделён от ИСПДн; взаимодействие через защищённые шлюзы/межсетевые экраны.
• Журналы и резервные копии: хранение и защита логов (включая веб‑сервер, WAF, VPN), контроль доступа, сроки хранения данных — см. сроки хранения ПДн.

Проверка соответствия: быстрый чек‑лист

• Все формы и кабинеты доступны только по HTTPS? Нет mixed content? Проверьте через онлайн‑проверку сайта.
• Сертификат валиден, не истекает в ближайшие 30 дней, есть автообновление? Настройте мониторинг.
• TLS 1.0/1.1 отключены, PFS включена? Проверьте SSL Labs.
• Уведомление субъекта и согласие реализованы? См. формы на сайте и согласие, политика конфиденциальности (шаблон), документы для сайта.
• Заключены договоры с обработчиками? См. поручение обработки ПДн.
• Роскомнадзор уведомлён (если требуется)? См. уведомление Роскомнадзора и реестр операторов ПДн.
• Проведён внутренний контроль? См. внутренний контроль и обучение и модель угроз ИСПДн.

Дополнительно можно заказать аудит сайта на соответствие 152‑ФЗ или пройти чек‑лист.

Частые ошибки и риски

• Самоподписанный сертификат: браузер показывает предупреждение — формально канал не считается доверенно защищённым.
• Mixed content: загрузка скриптов/изображений по HTTP ломает целостность и HSTS, даёт вектор атак.
• Включённый TLS 1.0/1.1 или слабые шифры: риск компрометации.
• Отсутствие HSTS и редиректов: возможна атака SSL‑strip.
• Отсутствует «secure»/«HttpOnly» у cookie сессий: риск кражи сессий.
• Шифрование «только наружу»: внутри между балансировщиком и приложением — открытый HTTP. Для контуров с ПДн желательно сквозной TLS или зашифрованные сегменты.
• Нет организационных мер: HTTPS есть, но нет инструкций, журналов, политики — это нарушение комплекса требований. См. пакет документов 152‑ФЗ.

Связанные требования (cookie, аналитика, формы)

• Cookie и баннеры: настройте явное уведомление и предпочтения — см. cookie и баннеры 152‑ФЗ.
• Веб‑аналитика и виджеты: передача идентификаторов должна быть легитимна и по защищённому каналу. См. Яндекс.Метрика и 152‑ФЗ, Яндекс.Формы, мессенджеры.
• Согласия и юридические тексты: политика обработки ПДн, согласие на обработку, шаблоны и формы.

Ответственность и штрафы

Нарушение требований безопасности (включая отсутствие защищённого канала при передаче ПДн) ведёт к административной ответственности. Ознакомьтесь с разделом ответственность и штрафы и нормой КоАП 13.11. При инциденте действуют процедуры инциденты и утечки ПДн и уведомление Роскомнадзора. Практические кейсы — в разделе судебная практика.

FAQ: когда HTTPS можно не применять?

• Статические лендинги без форм и без личных кабинетов. Юридически можно не использовать, но рекомендуется из‑за SEO, доверия и HSTS.
• Внутренние страницы в закрытой корпоративной сети без ПДн и без выхода в интернет. Однако при наличии аутентификации или журналов с ПДн лучше включить TLS.
• Анонимные опросы, где гарантировано не собираются идентификаторы, а IP адреса не сохраняются и не коррелируются. На практике такие сценарии редки; безопаснее использовать HTTPS.

Имейте в виду: как только появляется даже минимальный контакт с ПДн (телефон, e‑mail, логин), «https 152 фз» становится обязательным элементом.

Итоги и что делать дальше

• HTTPS — обязательный стандарт для всех сайтов, где обрабатываются ПДн. Это база для «защита информации 152 фз», но не единственная мера.
• Настройте современный TLS, HSTS, устраните mixed content, оформите документы и процессы.
• Проверьте подрядчиков и инфраструктуру, включая хостинг и облака, на соответствие российскому праву.

Нужна помощь? Закажите аудит сайта на соответствие 152‑ФЗ, воспользуйтесь онлайн‑проверкой сайта или обратитесь за консалтингом и документами под ключ. Мы поможем выстроить «шифрование персональных данных согласно 152 фз» и защиту канала без избыточных затрат.