Многие владельцы магазинов уверены, что если на сайте висит замочек HTTPS, то с безопасностью данных всё в порядке. Но HTTPS защищает данные только в пути — между браузером и сервером. А дальше телефоны, адреса, история заказов и платёжные реквизиты покупателей лежат в базе, в бэкапах и логах, где один слитый дамп превращает их в открытую книгу. Утечка персональных данных — это и удар по репутации, и штрафы, и потеря доверия клиентов.
В этой статье разберём, как правильно защищать чувствительные данные в базе интернет-магазина: чем шифрование отличается от хеширования, почему карты нельзя хранить у себя, где держать ключи и как всё это ложится на 1С-Битрикс и требования 152-ФЗ. Практическую защиту проекта помогает выстроить аудит и оптимизация 1С-решения.
Коротко
- HTTPS защищает данные в передаче; хранимые данные нужно шифровать отдельно — это разные уровни.
- Пароли не шифруют, а хешируют стойким алгоритмом с солью; карты не хранят вовсе — только токены провайдера.
- Ключи шифрования держат отдельно от данных, вне репозитория, с ротацией и ограниченным доступом.
- Бэкапы и логи — та же зона риска: шифруйте копии и маскируйте чувствительные поля в логах.
Почему одного HTTPS недостаточно
HTTPS решает одну конкретную задачу: он шифрует канал между браузером покупателя и вашим сервером, чтобы данные нельзя было перехватить по пути. Это обязательная база, но она не покрывает то, что происходит с данными после того, как они доехали до сервера.
А происходит вот что: данные записываются в базу, попадают в резервные копии, иногда — в журналы приложения. Если злоумышленник получит дамп базы (через уязвимость, украденный доступ или слитый бэкап), HTTPS ему не помешает — данные будут в открытом виде. Поэтому защита строится в два слоя: шифрование в передаче (HTTPS) и шифрование в покое (в хранилище). Нужны оба.
Какие данные надо защищать
Прежде чем шифровать, нужно понять, что именно чувствительно. Шифровать всё подряд неэффективно — важно выделить категории риска.
| Категория | Примеры | Как защищать |
|---|---|---|
| Персональные данные | ФИО, телефон, email, адрес | Шифрование в покое, ограничение доступа |
| Документы | Паспорт, ИНН (если собираете) | Шифрование, минимизация сбора |
| Пароли | Пароли аккаунтов | Стойкое хеширование с солью |
| Платёжные данные | Номер карты, CVV | Не хранить; токенизация у провайдера |
| Служебные секреты | API-ключи, токены интеграций | Защищённое хранилище, вне кода |
Ключевой принцип — минимизация: не собирайте и не храните то, что вам не нужно. Данных, которых нет в базе, невозможно украсть. Всё остальное защищайте по категории риска.
Шифрование в передаче и в покое
Два уровня шифрования решают разные задачи, и путать их нельзя.
- В передаче (in transit). HTTPS/TLS для сайта, а также шифрованные соединения к базе и внешним сервисам. Защищает от перехвата в сети.
- В покое (at rest). Шифрование хранимых данных: отдельных полей на уровне приложения, таблиц/дисков на уровне СУБД или файловой системы. Защищает от чтения украденного дампа или диска.
На практике сочетают оба: TLS закрывает каналы, а шифрование полей и бэкапов закрывает хранилище. Соединения с внешними сервисами (платёжные шлюзы, CRM, 1С) тоже должны идти по защищённым каналам — принципы безопасного обмена мы разбираем в статье про REST, вебхуки и безопасность в Битрикс.
Хеширование паролей
Пароли — особый случай: их нельзя шифровать, их нужно хешировать. Разница принципиальна. Шифрование обратимо — при наличии ключа данные расшифровываются. Хеширование односторонне — из пароля получают необратимый отпечаток, и восстановить исходный пароль невозможно.
Правильная схема: при регистрации пароль прогоняют через стойкий алгоритм (bcrypt, Argon2) с уникальной солью и хранят только хеш. При входе сравнивают хеши, а не расшифровывают пароль. Тогда даже полная утечка базы не раскрывает пароли пользователей. 1С-Битрикс хеширует пароли штатно, но при кастомной аутентификации или миграции важно не «изобрести» слабую схему вместо стойкой.
Токенизация банковских карт
Самое строгое правило — данные банковских карт. Полные номера (PAN), CVV и срок действия хранить у себя нельзя: этого требуют стандарты безопасности индустрии платёжных карт. Нарушение — это не только риск, но и прямая ответственность.
Правильная схема — токенизация. Карту покупатель вводит на стороне платёжного провайдера (или в его защищённой форме), а вам возвращается токен — безопасный идентификатор для повторных списаний. Токен бесполезен вне вашей связки с провайдером, поэтому его хранение безопасно. Так реализуются сохранённые карты и рекуррентные платежи для подписок — без хранения самих карт у вас. Это ложится на общую архитектуру приёма оплаты и надёжность транзакций.
Шифрование полей в базе
Персональные данные, которые вы обязаны хранить (адреса, телефоны, документы), защищают шифрованием в покое. Есть несколько подходов, и выбор зависит от сценариев работы с данными.
- На уровне приложения. Поле шифруется перед записью и расшифровывается при чтении в коде. Гибко, но требует аккуратной работы с ключами.
- На уровне СУБД. Прозрачное шифрование таблиц или дисков средствами базы. Проще в поддержке, но защищает в основном от кражи файлов, а не от доступа через приложение.
- Гибрид. Особо чувствительные поля — на уровне приложения, остальное — прозрачным шифрованием СУБД.
Важный нюанс: по обычному зашифрованному полю нельзя искать и сортировать — это частая причина «тормозов». Если по полю нужен точный поиск, применяют детерминированное шифрование или отдельный хеш-индекс. Как строить быстрые выборки к данным в Битрикс, мы разбираем в материале про D7 ORM.
Управление ключами
Шифрование ровно настолько надёжно, насколько защищён ключ. Главная ошибка — держать ключ рядом с данными или прямо в коде.
- Отделите ключ от данных. Ключ не должен попадать в тот же дамп, что и зашифрованная база.
- Не храните ключи в репозитории. Секреты — в переменных окружения или защищённом хранилище, а не в git.
- Ограничьте доступ. К ключам имеет доступ минимум людей и сервисов, строго по необходимости.
- Ротация. Ключи периодически меняют, предусматривая перешифрование данных.
Секреты интеграций (API-ключи платёжек, CRM, обмена с 1С) относятся к тому же классу и хранятся так же — вне кода, с ограниченным доступом. Как правильно вести секреты при деплое, показано в статье про CI/CD и деплой в Битрикс.
Разграничение доступа и аудит
Шифрование не заменяет контроль доступа — они работают вместе. Даже зашифрованные данные должны быть доступны только тем, кому они нужны по работе.
- Роли и права. Группы пользователей Битрикс с минимально необходимыми правами; менеджер видит только то, что нужно для его задач.
- Двухфакторная аутентификация. Для доступа в админку и к чувствительным разделам.
- Журнал действий. Логирование операций в админке, чтобы можно было расследовать инцидент.
- Принцип наименьших привилегий. Сервисные учётки и интеграции получают только те права, что реально используют.
Бэкапы, логи и утечки данных
О резервных копиях и логах вспоминают в последнюю очередь, а зря — это частый источник утечек. Бэкап базы содержит те же чувствительные данные, что и боевая база, поэтому его нужно шифровать и хранить в защищённом месте с ограниченным доступом.
Логи не должны содержать полные персональные и платёжные данные в открытом виде. Настройте маскирование: телефоны, email, номера документов и токены в журналах — скрыты или обрезаны. Отдельно проработайте регламент реагирования на утечку: кто и что делает, кого уведомлять, как локализовать инцидент. Наличие такого плана превращает потенциальную катастрофу в управляемую ситуацию.
152-ФЗ и юридический контур
Техническая защита данных — часть требований закона о персональных данных. 152-ФЗ обязывает принимать организационные и технические меры, и шифрование — одна из ключевых технических мер. Но само по себе оно не делает вас соответствующим закону.
Полный контур включает: корректные согласия на обработку, политику конфиденциальности, хранение данных россиян на серверах в РФ, разграничение доступа и, при необходимости, уведомление регулятора. Шифрование закрывает пункт «безопасность хранения», но должно идти в связке с юридической частью. Комплексно навести порядок и в технике, и в процессах помогает аудит и оптимизация решения.
Частые ошибки
- «Есть HTTPS — значит защищено». Хранимые данные остаются в открытом виде в базе и бэкапах.
- Пароли шифруют или хранят открыто. Нужен стойкий хеш с солью, а не обратимое шифрование.
- Хранят полные номера карт. Прямое нарушение стандартов; нужна токенизация у провайдера.
- Ключ лежит рядом с данными или в коде. Утечка базы вместе с ключом обнуляет шифрование.
- Незашифрованные бэкапы. Копия базы утекает так же легко, как и сама база.
- Персональные данные в логах. Журналы становятся вторым каналом утечки.
- Нет разграничения доступа. К чувствительным данным имеют доступ все подряд сотрудники.
Чек-лист внедрения
- Инвентаризация данных. Определено, какие поля чувствительны и какие вообще нужно хранить.
- Два уровня шифрования. HTTPS/TLS для каналов и шифрование в покое для хранилища.
- Пароли хешируются. Стойкий алгоритм с солью, восстановление пароля невозможно — только сброс.
- Карты не хранятся. Реализована токенизация через платёжного провайдера.
- Ключи под контролем. Отделены от данных, вне репозитория, с ограниченным доступом и ротацией.
- Доступ разграничен. Роли, минимальные права, двухфакторная аутентификация, журнал действий.
- Бэкапы и логи защищены. Копии зашифрованы, чувствительные поля в логах маскируются.
- Юридический контур. Согласия, политика, хранение данных в РФ, регламент реагирования на утечку.
Вывод
Защита чувствительных данных — это не одна галочка, а система из нескольких уровней. HTTPS закрывает передачу, шифрование в покое — хранилище, хеширование — пароли, токенизация — карты, а управление ключами и разграничение доступа связывают всё воедино. Забыть про бэкапы и логи — значит оставить открытой заднюю дверь.
Для магазина на 1С-Битрикс всё это реализуемо штатными средствами и аккуратной кастомизацией, а поверх ложится юридический контур 152-ФЗ. Начните с инвентаризации данных и аудита текущего хранения — это точка, с которой безопасность перестаёт быть иллюзией «замочка в адресной строке» и становится реальной защитой ваших клиентов и бизнеса.
