SSL и шифрование: технические требования ФСТЭК и ФСБ к сайтам с ПДн

Правовое основание: статья 19 ФЗ-152 и Приказ ФСТЭК N 21

Статья 19 Федерального закона N 152-ФЗ "О персональных данных" обязывает оператора принимать правовые, организационные и технические меры для защиты персональных данных от несанкционированного доступа, изменения, распространения и уничтожения. Конкретный перечень технических мер установлен Приказом ФСТЭК России N 21 от 18.02.2013 "Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных".

Приказ N 21 дифференцирует требования по уровням защищённости информационных систем персональных данных (ИСПДн). Уровень определяется по Постановлению Правительства РФ N 1119 от 01.11.2012. Правильное определение уровня защищённости - первый шаг к пониманию того, какие именно технические меры обязательны для вашего сайта.

Как определить уровень защищённости вашей ИСПДн

Постановление Правительства N 1119 устанавливает 4 уровня защищённости (УЗ-1 - УЗ-4), где УЗ-1 - наивысший. Уровень определяется по трём параметрам: тип обрабатываемых персональных данных, категория субъектов, актуальный тип угроз безопасности.

Уровень защищённости	Тип данных	Кол-во субъектов	Типичный пример
УЗ-4	Общедоступные или иные ПДн сотрудников	Менее 100 000	Корпоративный сайт с формой обратной связи (только сотрудники)
УЗ-3	Иные категории ПДн (не специальные, не биометрические) субъектов, не являющихся сотрудниками	Менее 100 000	Интернет-магазин, сервисный сайт, агрегатор, b2c-сервис
УЗ-2	Специальные или биометрические ПДн; иные ПДн при угрозах 2 типа	Любое	Медицинские сервисы, системы верификации личности, страховые порталы
УЗ-1	Специальные или биометрические ПДн при угрозах 1 типа	Более 100 000 или угрозы 1 типа	Крупные медицинские платформы, биометрические системы доступа

Большинство коммерческих сайтов малого и среднего бизнеса обрабатывают иные категории персональных данных (имена, контакты, история заказов) менее чем 100 000 субъектов, что соответствует уровню УЗ-3.

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

Требования к SSL/TLS по уровням защищённости

TLS 1.2 или выше - обязательно для всех уровней

Для сайтов с уровнями защищённости УЗ-3 и УЗ-4 применение протоколов TLS 1.0 и TLS 1.1 недопустимо: оба протокола имеют задокументированные уязвимости (атака POODLE для SSL 3.0 / TLS 1.0, атака BEAST для TLS 1.0). Должны быть включены только TLS 1.2 и TLS 1.3. Проверить текущую конфигурацию сервера можно с помощью сервиса SSL Labs (ssllabs.com/ssltest) или через онлайн-инструмент проверки SSL от Qualys - бесплатный тест покажет поддерживаемые протоколы, версию сертификата и cipher suites.

Настройка TLS в Nginx

Для веб-сервера Nginx корректная конфигурация TLS выглядит следующим образом. В блоке server необходимо указать: ssl_protocols TLSv1.2 TLSv1.3 (без TLSv1 и TLSv1.1), ssl_ciphers с современными cipher suites (ECDHE-RSA-AES256-GCM-SHA384 и аналоги), ssl_prefer_server_ciphers on. Конфигурацию следует проверить через SSL Labs и убедиться в оценке не ниже A.

Действительный SSL-сертификат

SSL-сертификат должен быть выдан удостоверяющим центром (УЦ), включённым в доверенные списки браузеров. Для коммерческих сайтов подходит бесплатный сертификат Let’s Encrypt - он признаётся всеми современными браузерами и полностью удовлетворяет требованиям для УЗ-3 и УЗ-4. Самоподписанные сертификаты (self-signed) недопустимы, поскольку не обеспечивают независимую верификацию подлинности сервера. Срок действия сертификата необходимо контролировать: просроченный сертификат означает полное отсутствие защиты и нарушение требований ФЗ-152.

Надёжные наборы шифров (cipher suites)

Конфигурация TLS должна использовать только надёжные cipher suites. Подлежат отключению: RC4 (сломан), DES и 3DES (слабые ключи), MD5 для подписей сертификатов (коллизии), SHA-1 для подписей (устарел), EXPORT-шифры (намеренно ослабленные). Рекомендуемые алгоритмы: AES-256-GCM, AES-128-GCM для симметричного шифрования, ECDHE для обмена ключами (Forward Secrecy), RSA 2048+ или ECDSA для сертификатов.

HSTS (HTTP Strict Transport Security)

Заголовок HSTS принудительно переключает браузер на HTTPS-соединение при всех будущих обращениях к сайту и предотвращает атаки с понижением протокола (SSL stripping). Добавьте в конфигурацию веб-сервера заголовок: Strict-Transport-Security: max-age=31536000; includeSubDomains. Значение max-age=31536000 означает 1 год. Параметр includeSubDomains распространяет HSTS на все поддомены - убедитесь, что они все работают по HTTPS, иначе пользователи не смогут открыть поддомены.

ГОСТ-криптография: кому реально нужна

ГОСТ-криптография (алгоритмы ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015) - это отдельное требование, которое часто ошибочно связывают с обычными сайтами с формой обратной связи. На практике ГОСТ-криптография обязательна в строго ограниченных случаях.

Когда ГОСТ обязателен

• Государственные информационные системы (ГИС) в соответствии с Приказом ФСТЭК N 17
• Объекты критической информационной инфраструктуры (КИИ) согласно ФЗ-187
• Системы, работающие с государственной тайной
• Системы взаимодействия со СМЭВ (система межведомственного электронного взаимодействия)
• Банковские системы и финансовая инфраструктура (по требованиям ЦБ РФ)

Когда ГОСТ не нужен

• Интернет-магазин, обрабатывающий данные покупателей
• Корпоративный сайт с формой обратной связи
• SaaS-сервис для частных клиентов (не ГИС)
• Сайт медицинской клиники (если не является государственной ГИС)
• Любой коммерческий сайт, не имеющий отношения к государственным системам

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

Лицензия ФСБ на криптографию: нужна ли вашему сайту

Лицензия ФСБ на деятельность по разработке, производству, распространению криптографических средств и услуг в области шифрования требуется исключительно для организаций, которые занимаются коммерческой разработкой или производством криптосредств, оказывают услуги по шифрованию данных третьих лиц, устанавливают или обслуживают криптосредства у третьих лиц. При использовании стандартных SSL-сертификатов и протоколов TLS на вашем сайте никакая лицензия ФСБ не требуется. Вы используете готовое лицензированное ПО (веб-сервер Nginx или Apache), а не разрабатываете криптосредства самостоятельно.

Дополнительные технические меры по Приказу ФСТЭК N 21 для УЗ-3

Помимо SSL, Приказ N 21 для уровня УЗ-3 требует реализации ряда организационных и технических мер. Для веб-сайтов наиболее актуальны следующие меры:

• УПД (Управление доступом) - идентификация и аутентификация пользователей с доступом к ИСПДн (администраторов, операторов), управление правами доступа к данным, принцип минимально необходимых привилегий
• АУД (Аудит безопасности) - регистрация событий безопасности в журналах, мониторинг событий, хранение журналов в течение установленного срока
• ЗИС (Защита информационной системы) - антивирусная защита сервера, межсетевой экран, защита от сетевых атак
• ОДТ (Обеспечение доступности) - резервное копирование, процедуры восстановления после сбоев
• ЗНИ (Защита носителей информации) - контроль использования съёмных носителей, содержащих ПДн

Практический чек-лист SSL и технической защиты для УЗ-3

1. Установлен SSL-сертификат от доверенного УЦ (Let’s Encrypt, Sectigo, DigiCert и аналоги)
2. Сертификат действителен, до истечения срока более 30 дней
3. Протоколы TLS 1.0 и TLS 1.1 отключены в конфигурации веб-сервера
4. Включены TLS 1.2 и/или TLS 1.3
5. Отключены устаревшие cipher suites (RC4, DES, 3DES, EXPORT)
6. Настроен заголовок HSTS с max-age не менее 1 года
7. Настроено автоматическое перенаправление с HTTP на HTTPS
8. Оценка SSL Labs не ниже A (проверяется на ssllabs.com/ssltest)
9. Все поддомены также работают по HTTPS
10. Настроено автоматическое обновление сертификата (для Let’s Encrypt - certbot или acme.sh)
11. На сервере установлен межсетевой экран (firewall) и антивирус
12. Доступ к административным интерфейсам (панель хостинга, SSH) ограничен по IP
13. Включена двухфакторная аутентификация для всех административных аккаунтов
14. Регулярные резервные копии настроены и хранятся на российских серверах

Настройка TLS в Apache

Для веб-сервера Apache корректная конфигурация TLS в файле ssl.conf или конфигурации виртуального хоста должна включать: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 (отключение устаревших протоколов), SSLCipherSuite с современными cipher suites, SSLHonorCipherOrder on для приоритета серверных настроек. После изменения конфигурации обязательно проверьте корректность через ssl-labs.com или аналогичный инструмент.

Let’s Encrypt: автоматизация обновления сертификата

SSL-сертификат Let’s Encrypt действует 90 дней и требует регулярного обновления. Для автоматизации используется утилита certbot или acme.sh. Настройка certbot: установите certbot через пакетный менеджер вашего дистрибутива (apt или yum), выполните первоначальную выдачу сертификата командой certbot -nginx или certbot -apache (в зависимости от веб-сервера), настройте cron-задание для автоматического обновления: certbot renew запускается дважды в сутки. Certbot автоматически обновит сертификат за 30 дней до истечения. Просроченный сертификат является нарушением требований ФЗ-152 о технической защите канала передачи данных.

Защита административных интерфейсов

Помимо защиты канала передачи данных пользователей, необходимо защитить административные интерфейсы, через которые осуществляется доступ к персональным данным. Это требование меры УПД (управление доступом) из Приказа ФСТЭК N 21:

• Панель управления CMS (WordPress /wp-admin, MODX Manager) - ограничьте доступ по IP-адресу через .htaccess или конфигурацию Nginx, включите двухфакторную аутентификацию
• phpMyAdmin и pgAdmin - никогда не оставляйте открытый доступ к phpMyAdmin на продакшн-сервере; используйте доступ только через VPN или SSH-туннель
• Панель хостинга (ISPmanager, cPanel, Plesk) - включите 2FA, ограничьте доступ по IP
• SSH-доступ к серверу - используйте аутентификацию по ключу (не по паролю), нестандартный порт, ограничение по IP через fail2ban

Мониторинг и реагирование на инциденты

Статья 19 ФЗ-152 требует не только предотвращать нарушения безопасности, но и реагировать на них. С 1 марта 2023 года операторы обязаны уведомлять Роскомнадзор об инцидентах с персональными данными в течение 24 часов (первичное уведомление) и 72 часов (детальный отчёт). Инцидентом считается: утечка персональных данных, несанкционированный доступ к ПДн, уничтожение или изменение данных без санкции оператора.

Минимальный набор мер мониторинга

• Настройте логирование ошибок и событий безопасности на веб-сервере
• Настройте уведомления об аномальной активности (массовые запросы к БД, неудачные попытки входа)
• Регулярно проверяйте логи на предмет признаков взлома (необычные IP, сканирование директорий)
• Используйте WAF (Web Application Firewall) для защиты от SQL-инъекций и XSS-атак, которые могут привести к утечке ПДн

Аттестация и документация ИСПДн

Для уровней УЗ-3 и УЗ-4 Приказ ФСТЭК N 21 не требует обязательной аттестации информационной системы. Аттестация обязательна для ГИС (государственных информационных систем) по Приказу ФСТЭК N 17. Коммерческие сайты обязаны: разработать документ "Модель угроз безопасности персональных данных", определить уровень защищённости ИСПДн и зафиксировать его в акте, составить перечень применяемых технических мер защиты, назначить ответственного за обработку и защиту персональных данных. Эти документы запрашиваются при проверке Роскомнадзора и являются доказательством системного подхода к защите данных.

Типичные вопросы о SSL и ФЗ-152

Нужен ли платный SSL или хватит бесплатного Let’s Encrypt

Для уровней защищённости УЗ-3 и УЗ-4 бесплатный сертификат Let’s Encrypt полностью удовлетворяет требованиям. Let’s Encrypt выдаёт DV-сертификаты (Domain Validation) - они подтверждают, что сертификат выдан для данного домена, и обеспечивают шифрование трафика. OV (Organization Validation) и EV (Extended Validation) сертификаты дополнительно подтверждают юридическое лицо - это может быть полезно для доверия пользователей, но не является требованием ФЗ-152.

Как часто нужно обновлять SSL-сертификат

Let’s Encrypt: сертификат действует 90 дней, обновление настраивается автоматически через certbot. Коммерческие сертификаты: как правило, выдаются на 1-2 года. В любом случае рекомендуется обновлять за 30 дней до истечения и получить уведомления на email об истечении срока сертификата.

Практические инструменты проверки SSL-конфигурации

Помимо SSL Labs, для проверки конфигурации TLS можно использовать следующие инструменты:

• Hardenize (hardenize.com) - комплексная проверка HTTPS, HSTS, HPKP, DNS и других параметров безопасности сайта
• Mozilla Observatory (observatory.mozilla.org) - проверка HTTP-заголовков безопасности: HSTS, CSP, X-Frame-Options и других
• testssl.sh - командный инструмент для проверки TLS-конфигурации сервера, работает локально без передачи данных в облако
• OpenSSL - проверка сертификата и поддерживаемых протоколов: openssl s_client -connect domain.ru:443 -tls1 (должно выдавать ошибку для TLS 1.0)

Заголовки безопасности HTTP и ФЗ-152

Приказ ФСТЭК N 21 для уровней УЗ-3 и УЗ-4 требует защиты от несанкционированного воздействия на информационную систему. На уровне HTTP-заголовков это реализуется через:

• Content-Security-Policy (CSP) - ограничивает источники, с которых могут загружаться ресурсы страницы; снижает риск XSS-атак, которые могут привести к перехвату персональных данных
• X-Content-Type-Options: nosniff - предотвращает MIME-sniffing, снижая риск выполнения вредоносного кода
• X-Frame-Options: SAMEORIGIN - защищает от clickjacking-атак
• Referrer-Policy: no-referrer-when-downgrade - ограничивает передачу URL страницы во внешние запросы (защита URL с персональными данными)
• Permissions-Policy - ограничивает доступ браузера к микрофону, камере, геолокации (снижает риск сбора биометрических данных)

Двухфакторная аутентификация для доступа к данным

Мера УПД.2 из Приказа ФСТЭК N 21 требует управления идентификаторами, а мера УПД.3 - управления аутентификационной информацией. Применительно к сайту это означает: доступ к административной панели сайта, базе данных, панели хостинга и другим системам, содержащим персональные данные, должен быть защищён не только паролем, но и вторым фактором аутентификации. Для WordPress это плагины типа WP 2FA или Google Authenticator. Для доступа к серверу по SSH - ключи без пароля или TOTP через PAM. Пароли для доступа к хранилищам персональных данных должны иметь минимальную длину 12 символов и содержать буквы, цифры и специальные символы.

Антивирусная защита и WAF

Мера ЗИС (защита информационной системы) из Приказа ФСТЭК N 21 предусматривает применение средств защиты от вредоносного кода. Для веб-сервера это означает:

• Антивирусное программное обеспечение на сервере (ClamAV для Linux, периодическое сканирование файлов сайта)
• Web Application Firewall (WAF) - защита от SQL-инъекций, XSS, CSRF и других веб-атак (ModSecurity для Nginx/Apache или облачный WAF провайдера хостинга)
• Регулярное обновление CMS, плагинов, библиотек (уязвимости в устаревших версиях WordPress или OpenCart могут привести к компрометации базы данных с ПДн)
• Мониторинг целостности файлов сайта (изменение PHP-файлов без ведома - признак взлома)

Итоговые рекомендации по SSL и технической защите

Техническая защита персональных данных на уровне SSL и сетевой безопасности является базовым, но обязательным уровнем соответствия ФЗ-152. Инвестиции в правильную конфигурацию TLS, настройку HTTP-заголовков безопасности, двухфакторную аутентификацию и WAF не только обеспечивают правовое соответствие, но и реально защищают данные пользователей от взлома и утечек. Соответствие требованиям ФСТЭК N 21 для уровня УЗ-3 достижимо без значительных финансовых вложений - большинство мер реализуются через правильную конфигурацию существующих компонентов веб-инфраструктуры.