База знаний · 1С-Битрикс

Шифрование персональных данных

Настройка модуля шифрования, выбор полей ПДн и безопасное хранение ключа

Модуль «Шифрование» в 1С-Битрикс позволяет хранить персональные данные пользователей в базе в зашифрованном виде, снижая ущерб при утечке дампа БД. В статье разберём включение модуля, выбор полей, хранение ключа и практику эксплуатации.

Настройки находятся в Настройки → Настройки продукта → Настройки модулей → Шифрование. Модуль доступен в старших редакциях; при его отсутствии установите «Шифрование» через Marketplace → Установленные решения.

Что и зачем шифрует модуль

Шифрование персональных данных защищает от одной конкретной угрозы — чтения данных из украденного дампа или файлов базы. Даже получив SQL-дамп, злоумышленник без ключа не прочитает зашифрованные значения.

Важно понимать границы применимости:

Защищает: данные «в покое» (at rest) — содержимое таблиц БД и её резервных копий.
Не защищает: данные в момент отображения в админке или на витрине — приложение всё равно расшифровывает их для показа авторизованному пользователю.
Не заменяет: проактивную защиту, права доступа и разграничение ролей — это дополняющие меры.

Типовой набор полей для шифрования: ФИО, телефон, e-mail, адрес, паспортные данные, а также пользовательские свойства с ПДн. Поля, по которым нужен полнотекстовый поиск или фильтрация в SQL, шифровать нельзя — по ним поиск станет невозможен.

Включение модуля и создание ключа

Перед включением шифрования сделайте полную резервную копию сайта и базы данных — операция изменит формат хранения выбранных полей.

Откройте Настройки → Настройки продукта → Настройки модулей → Шифрование.
Убедитесь, что модуль установлен. Если его нет в списке — установите решение «Шифрование» из Marketplace.
Сгенерируйте или задайте ключ шифрования. Ключ должен быть длинным и случайным; не используйте словарные значения.
Укажите место хранения ключа. Рекомендуется хранить ключ вне корня сайта (например, в файле выше DOCUMENT_ROOT), чтобы он не попадал в дамп БД и не был доступен по HTTP.
Сохраните настройки и запишите резервную копию ключа в защищённое хранилище (менеджер секретов, оффлайн-носитель).

Критически важно: при потере ключа расшифровать данные будет невозможно. Ключ — это единственный способ доступа к зашифрованным ПДн.

Выбор полей для шифрования

После включения модуля отметьте, какие поля хранить в зашифрованном виде. Подходите избирательно: шифруйте только реальные ПДн, а не все подряд, чтобы не сломать поиск и фильтрацию.

Поле	Шифровать	Комментарий
Фамилия, имя, отчество	Да	Потеря поиска по ФИО в SQL допустима
Телефон, адрес, паспорт	Да	Классические ПДн
E-mail (логин)	Осторожно	Используется для авторизации и поиска — шифрование ломает быстрый поиск
Логин, права, группы	Нет	Служебные поля, нужны для работы системы

Отметьте нужные свойства и запустите перешифровку существующих записей. Для больших таблиц процесс идёт пошагово (пакетно) через агент или мастер, чтобы не превысить лимит времени выполнения скрипта.

Правильное хранение ключа

Безопасность всей схемы держится на ключе. Если ключ лежит рядом с базой и доступен вместе с ней — смысл шифрования теряется.

Храните ключ в файле вне DOCUMENT_ROOT, недоступном по HTTP.
Ограничьте права на файл ключа на уровне ОС (чтение только пользователем веб-сервера).
Исключите файл ключа из резервных копий базы данных — держите его резерв отдельно.
Не коммитьте ключ в систему контроля версий.
Ведите учёт: кто имеет доступ к ключу и где хранится его резервная копия.

Оптимальная модель угроз: дамп БД и файл ключа никогда не должны оказаться в одних руках одновременно.

Ротация ключа шифрования

Периодическая смена ключа снижает риск при возможной компрометации. Ротация — это перешифровка всех данных со старого ключа на новый.

Сделайте полную резервную копию базы и текущего ключа.
Переведите сайт в технологический режим или выберите время низкой нагрузки.
Задайте новый ключ и запустите перешифровку: система читает данные старым ключом и сохраняет новым.
Дождитесь завершения пакетной обработки всех записей.
Проверьте корректность отображения ПДн в нескольких карточках пользователей.
Только после успешной проверки уничтожьте старый ключ.

Не удаляйте старый ключ до полного завершения перешифровки — иначе часть данных останется нечитаемой.

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

Ошибки при работе с шифрованием обычно приводят к потере данных, поэтому разберём их отдельно.

Потеря ключа. Нет резервной копии ключа — зашифрованные ПДн восстановить невозможно. Всегда храните резерв отдельно.
Ключ рядом с базой. Файл ключа внутри DOCUMENT_ROOT или в том же бэкапе, что и БД — защита фактически отсутствует.
Шифрование поисковых полей. Зашифровали e-mail или логин — сломался поиск и фильтрация по этим полям в SQL.
Нет бэкапа перед включением. Сбой во время массовой перешифровки без резервной копии оставляет базу в смешанном состоянии.
Удаление старого ключа при ротации преждевременно. Часть записей ещё не перешифрована — данные становятся нечитаемыми.
Иллюзия полной защиты. Расчёт, что шифрование заменяет права доступа и проактивную защиту. Оно закрывает только чтение дампа, но не доступ через само приложение.

Проверка и эксплуатация

После настройки убедитесь, что шифрование работает и не нарушает бизнес-логику.

Откройте карточку пользователя в админке — зашифрованные поля должны отображаться корректно (расшифровка «на лету»).
Посмотрите значение поля напрямую в базе (через phpMyAdmin или консоль MySQL) — там должно лежать нечитаемое зашифрованное значение.
Проверьте формы регистрации, оформления заказа и профиля — сохранение и чтение ПДн должно работать штатно.
Убедитесь, что резервное копирование не выгружает файл ключа вместе с базой.

В штатной эксплуатации фиксируйте изменения ключа и состав зашифрованных полей в регламенте, а доступ к ключу — в журнале. Совмещайте шифрование с контролем целостности файлов и журналом событий безопасности.

Итог

Шифрование персональных данных в 1С-Битрикс — целевая мера против чтения ПДн из украденного дампа БД. Она не заменяет права доступа и проактивную защиту, а дополняет их.

Перед включением — полный бэкап сайта и базы.
Шифруйте только реальные ПДн, не трогайте поисковые и служебные поля.
Храните ключ вне корня сайта и отдельно от резервных копий базы.
Держите резервную копию ключа — его потеря необратима.
Периодически проводите ротацию ключа и проверяйте корректность отображения данных.

Соблюдая эти правила, вы получите работающую защиту ПДн «в покое» без риска потерять доступ к собственным данным.

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

Что произойдёт, если потерять ключ шифрования?

Зашифрованные персональные данные станут нечитаемыми навсегда. Ключ — единственный способ расшифровки, поэтому его резервную копию нужно хранить отдельно и в защищённом месте.

Замедляет ли шифрование работу сайта?

Небольшие накладные расходы есть: данные расшифровываются при каждом чтении и шифруются при записи. На типовых объёмах это незаметно, но по зашифрованным полям пропадает быстрый поиск и фильтрация средствами SQL.

Можно ли шифровать e-mail и логин пользователя?

Технически можно, но не рекомендуется. Эти поля используются для авторизации, поиска и фильтрации. После шифрования поиск по ним через SQL перестанет работать, что нарушит штатную логику.

Защищает ли шифрование от взлома админки?

Нет. Шифрование закрывает только чтение данных из дампа базы. Авторизованному пользователю или взломщику с доступом к приложению данные показываются в расшифрованном виде. Нужны права доступа и проактивная защита.

Где безопаснее всего хранить ключ?

В файле вне DOCUMENT_ROOT, недоступном по HTTP, с ограниченными правами на уровне ОС. Ключ нельзя включать в резервные копии базы и коммитить в систему контроля версий.

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

Поможем с настройкой и поддержкой 1С-Битрикс

Поможем с настройкой, доработкой и поддержкой 1С-Битрикс.