Шифрование и криптография для персональных данных по 152‑ФЗ
Table of contents
- Что требует 152‑ФЗ и подзаконные акты
- Когда шифрование обязательно
- HTTPS/TLS для сайтов: как выполнить 152‑ФЗ
- Шифрование в ИСПДн: каналы, хранение, резервные копии
- Российская криптография (СКЗИ) и международные алгоритмы
- Управление ключами: KMS, HSM, ротация
- Выбор решения: типовые сценарии и рекомендации
- Облака и ЦОД: как не потерять соответствие
- Биометрия, спецкатегории и обезличивание
- Документы, проверки, инциденты
- Чек‑лист внедрения
- Частые ошибки
- Заключение и следующий шаг
Что требует 152‑ФЗ и подзаконные акты
Шифрование персональных данных согласно 152‑ФЗ — это часть комплекса мер защиты, а не самоцель. Базовые обязанности оператора заложены в статье 19 Закона «О персональных данных»; подробнее см. о законе, текст 152‑ФЗ и структуру и статьи.
Практические требования к ИСПДн (информационным системам ПДн) раскрывают подзаконные акты:
- Постановление Правительства № 1119 — уровни защищенности ИСПДн и общие меры.
- Приказ ФСТЭК № 21 — требования к защите ПДн, в т.ч. к межсетевым и криптографическим мерам в зависимости от уровня защищенности.
- Нормативы ФСБ — когда используются средства криптографической защиты информации (СКЗИ) и каким требованиям они должны соответствовать.
Ключевые ориентиры и взаимосвязь органов — в нашем материале Требования ФСТЭК и ФСБ. Для определения класса и объемов защиты начните с ИСПДн: определение и требования, уровней защищенности и модели угроз.
Когда шифрование обязательно
Решение «нужно ли шифровать» принимается по модели угроз и уровню защищенности ИСПДн. Типовые случаи, когда шифрование требуется или настоятельно рекомендуется:
- Передача ПД по публичным и/или ненадежным сетям (интернет, Wi‑Fi, межфилиальные каналы, мобильные клиенты).
- Доступ удаленных сотрудников/подрядчиков к ИСПДн — каналы VPN с сильными шифрами.
- Хранение ПД на мобильных устройствах, ноутбуках, внешних носителях — полнодисковое шифрование.
- Бэкапы с ПД, особенно уносимые за периметр или в облака.
- Специальные категории ПД, биометрия, медицинские данные, ПД детей — усиленные меры, как правило, с обязательным шифрованием.
- Уровни защищенности 1–3 по ПП 1119 обычно предполагают применение криптографических мер; уровень 4 — по результатам оценки угроз.
Подробнее о подходе к мерам читайте в разделе меры безопасности ПДн. Отдельная практика — при трансграничной передаче ПД: шифрование каналов часто обязательное условие.
HTTPS/TLS для сайтов: как выполнить 152‑ФЗ
Формулировка «использование HTTPS 152‑ФЗ» встречается в чек‑листах проверок. Сам закон не называет HTTPS по имени, но для сайтов и веб‑форм защищенный протокол — практически необходимая мера.
Что нужно для соответствия и хорошей криптографической гигиены:
- Включите HTTPS на всех страницах сайта, особенно на формах (регистрация, заявки, корзина). См. требования к сайту и раздел SSL/HTTPS по 152‑ФЗ.
- Поддерживайте TLS 1.2/1.3; отключите SSLv3, TLS 1.0/1.1.
- Включите шифросuites с PFS (ECDHE) и AEAD (AES‑GCM, ChaCha20‑Poly1305); запретите слабые MD5/RC4/3DES.
- Включите HSTS, настройте редирект HTTP→HTTPS, используйте современную цепочку сертификатов (RSA 2048+/ECC)
- Применяйте mTLS внутри инфраструктуры (админ‑панели, API) при повышенных рисках.
- Если регулятор или модель угроз требует российских СКЗИ — используйте TLS с ГОСТ (например, CryptoPro TLS) на критических сегментах/сервисах.
Сертификаты DV/OV/EV допустимы; EV не обязателен для соответствия, но упрощает доверие. Проводите регулярный аудит сайта и экспресс‑проверки настроек TLS — см. инструмент онлайн‑проверка сайта. Не забудьте про согласия во формах на сайте и корректные cookie‑баннеры: шифрование защищает канал, но не заменяет правовые основания обработки.
Шифрование в ИСПДн: каналы, хранение, резервные копии
В реальных системах нужна комбинация мер.
- Данные «в полете» (in transit): TLS 1.2/1.3 для веб и сервисов, IPsec/SSL‑VPN для филиалов и удаленных пользователей, mTLS для сервис‑к‑сервису, SSH с ключами для админ‑доступа.
- Данные «в покое» (at rest): TDE в СУБД (PostgreSQL, MySQL, MS SQL), шифрование на уровне файлов/томов (BitLocker, LUKS), объектное шифрование хранилищ, обязательное шифрование бэкапов.
- Данные «на уровне приложения»: селективное шифрование чувствительных полей (номер паспорта, СНИЛС) с разделением ключей и ролей доступа.
- Сегментация и минимизация: выделяйте контуры с ПД, применяйте принцип наименьших привилегий.
Таблица ориентиров по защите слоев:
| Слой |
Минимум |
Усиление |
| Каналы |
TLS 1.2+ с PFS |
mTLS, IPsec, VPN с MFA |
| Хранение |
Шифрование тома/файла |
TDE + шифрование бэкапов + KMS |
| Приложение |
Хеширование паролей (bcrypt/Argon2) |
Полевая криптография + токенизация |
| Администрирование |
SSH‑ключи |
PAM/MFA, jump‑host, запись сессий |
Российская криптография (СКЗИ) и международные алгоритмы
Вопрос «какую криптографию выбрать» упирается в статус системы и требования регуляторов:
- Международные алгоритмы (AES‑GCM, ChaCha20, ECDHE, SHA‑256) широко применяются и достаточны во многих коммерческих ИСПДн при надлежащих настройках.
- Российские СКЗИ (CryptoPro, VipNet и др.) и ГОСТ‑алгоритмы (Кузнечик, Магма, Стрибог, ГОСТ Р 34.10‑2012) обязательны там, где это прямо требует регулятор, договор или модель угроз, а также в государственных ИС и ряде критических контуров.
Важно: если вы используете СКЗИ — средства должны иметь действующие сертификаты ФСБ, а защитные средства — подтверждение соответствия ФСТЭК. Детали — в разделе требования ФСТЭК и ФСБ.
Управление ключами: KMS, HSM, ротация
Надежность криптографии зависит от практик управления ключами:
- Центральный KMS (вендорный или облачный) с аудитом операций.
- Аппаратные модули HSM для генерации/хранения корневых ключей, операций подписания и TLS‑терминации на критичных узлах.
- Ротация ключей и сертификатов по графику (обычно 90–365 дней), автоматическое продление.
- Разделение обязанностей (SoD), хранение секретов в защищенных секрет‑менеджерах, а не в коде или .env.
- Шифрование бэкапов ключей, контроль экспорта, процесс экстренной замены при компрометации.
Выбор решения: типовые сценарии и рекомендации
Ниже — ориентир для быстрого выбора.
| Сценарий |
Что делать |
Примечание |
| Публичный сайт с формами |
Полный HTTPS, TLS 1.2/1.3, HSTS |
См. HTTPS по 152‑ФЗ |
| Личный кабинет/мобильное приложение |
HTTPS + mTLS/API‑ключи, защита токенов |
PFS, защита сессий |
| Межфилиальные каналы |
IPsec/SSL‑VPN с MFA, шифры уровня enterprise |
Логику доступа — по Zero Trust |
| Бэкапы ПД |
Шифрование на стороне клиента + хранение в зашифр. хранилище |
Отдельные ключи и KMS |
| Гос. заказчик/крит. контур |
СКЗИ с ГОСТ TLS/КЗИ |
Требования ФСБ/ФСТЭК |
| Обработка биометрии |
Шифрование в канале и при хранении + токенизация |
См. биометрические ПД |
Облака и ЦОД: как не потерять соответствие
При переносе ИСПДн в облако или ЦОД обратите внимание на:
- Сертификацию площадки и договорные гарантии (сегментация, доступ, логи). См. Серверы, хостинг, ЦОД.
- Шифрование на уровне сервисов: объектные хранилища с server‑side encryption и/или client‑side крипто, KMS/CMK, BYOK.
- Сетевую изоляцию, VPN‑доступы, mTLS между сервисами, private‑link.
- Особенности конкретных провайдеров — например, облака Yandex Cloud.
При аутсорсинге обработки — фиксируйте меры в договоре и в политике: см. поручение обработки ПД.
Биометрия, спецкатегории и обезличивание
Шифрование критично для повышенно чувствительных данных:
Следите за обновлениями регуляторики: изменения 2025.
Документы, проверки, инциденты
Одной техники мало — нужны документы и процессы:
Чек‑лист внедрения
- Инвентаризация: какие ПД, где хранятся, кто имеет доступ.
- Определение уровня защищенности ИСПДн и угроз.
- Проект сети: сегментация, границы, точки шифрования.
- Настройка HTTPS/TLS, VPN, mTLS; отключение устаревших протоколов.
- Шифрование хранения: БД, тома, файлы, бэкапы.
- Внедрение KMS/HSM, процессы ротации ключей.
- Тестирование, сканирование конфигураций, журналирование и мониторинг.
- Обновление политики и договоров, обучение персонала.
- План реагирования на инциденты и регулярные учения.
Частые ошибки
- Ограничиваются «галочкой HTTPS», но оставляют открытые админ‑панели, API без mTLS или слабые шифры.
- Не шифруют бэкапы и временные выгрузки, которые потом утрачиваются.
- Хранят секреты в коде/репозиториях, без ротации и аудита.
- Используют СКЗИ без актуальных сертификатов или вне контура, описанного в документах.
- Не фиксируют криптомеры в модели угроз и политике — трудно доказать соответствие.
Заключение и следующий шаг
Шифрование — обязательный элемент зрелой защиты ПД по 152‑ФЗ: оно закрывает риски в каналах, хранении и резервировании, но работает только в сочетании с корректной архитектурой, управлением ключами и документами. Начните с инвентаризации и модели угроз, внедрите HTTPS/TLS, VPN и шифрование хранения, затем закрепите это в политике и договорах.
Нужна помощь? Проведем аудит и подготовим решения «под ключ»: консалтинг и документы, аудит сайта и генератор политики и согласий. Материал носит информационный характер; за деталями обращайтесь к тексту 152‑ФЗ, смежным требованиям (149‑ФЗ, 187‑ФЗ, 63‑ФЗ, 98‑ФЗ) и сопоставлению с GDPR.