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