Вопрос «а где мы храним карты покупателей» звучит на старте почти каждого проекта интернет-магазина — и правильный ответ почти всегда обескураживает: нигде. Соблазн «сохранить карту, чтобы клиенту было удобнее» оборачивается огромной ответственностью, дорогой сертификацией и риском утечки, после которой бизнесу проще закрыться. Хорошая новость в том, что безопасно принимать оплату можно, вообще не касаясь данных карты.
Эта статья — о том, как правильно обрабатывать платежи в магазине на 1С-Битрикс: почему данные карт не должны попадать на ваш сервер, как работает платёжный шлюз, что такое PCI DSS и токенизация, и как защитить тот периметр, что остаётся под вашей ответственностью. Практическую настройку безопасности и разбор рисков мы закрываем услугой поддержки и аудита.
Коротко
- Данные карт не хранят на своём сервере — их вводят на стороне платёжного шлюза, а магазин получает только статус оплаты.
- Такая модель переводит вас в самый лёгкий уровень PCI DSS (SAQ A) и снимает основную ответственность.
- Для подписок и повторных платежей используют токенизацию у провайдера, а не хранение номеров.
- Периметр всё равно защищают: HTTPS, проактивная защита и WAF Битрикс, разграничение прав, обновления и бэкапы.
Главное правило: не хранить данные карт
Начнём с принципа, который экономит бизнесу деньги, нервы и репутацию: номер карты, срок действия и особенно CVV не должны попадать в базу данных магазина, в логи, в письма или в файлы на сервере. Как только эти данные оказываются на вашей стороне, вы принимаете на себя полную ответственность за их защиту по строгим требованиям индустрии платёжных карт.
Практически для всех задач интернет-магазина хранить карту не нужно. Разовая оплата проходит на стороне банка, а для повторных списаний есть безопасная токенизация. Модель «сайт не видит карту» не ограничивает бизнес — она убирает самый чувствительный актив с вашего сервера, а значит, и главный источник риска. Всё дальнейшее в статье строится вокруг этого принципа.
Что такое PCI DSS и уровни соответствия
PCI DSS (Payment Card Industry Data Security Standard) — международный стандарт безопасности данных платёжных карт. Он обязателен для всех, кто эти данные обрабатывает, передаёт или хранит. Объём требований к конкретному магазину зависит от того, как именно он работает с картой.
| Модель приёма оплаты | Форма самооценки | Нагрузка на магазин |
|---|---|---|
| Ввод карты на стороне провайдера (редирект/iframe банка) | SAQ A | Минимальная |
| Встроенная форма провайдера на странице сайта | SAQ A-EP | Средняя |
| Сайт сам принимает и передаёт данные карты | SAQ D | Максимальная, дорого |
| Хранение данных карт в своей базе | SAQ D + аудит | Крайне высокая, не рекомендуется |
Вывод прямой: чем дальше данные карты от вашего сервера, тем проще соответствие. Модель с вводом карты на стороне банка (SAQ A) — самая безопасная и дешёвая. Именно к ней стоит стремиться при проектировании платёжного узла магазина.
Как устроен безопасный платёж через шлюз
В 1С-Битрикс приём оплаты картой реализуется через платёжные системы модуля «Интернет-магазин» и обработчики платёжных провайдеров. Логика безопасного платежа выглядит так:
- Формирование заказа. Покупатель оформляет заказ, магазин фиксирует сумму, состав и создаёт запись о платеже.
- Передача шлюзу. Сайт передаёт провайдеру сумму и идентификатор заказа — но не данные карты, которых у него и нет.
- Ввод карты у провайдера. Покупатель попадает на защищённую страницу банка (редирект) или во встроенную форму провайдера и вводит карту там.
- Возврат статуса. Провайдер сообщает магазину результат — оплачено или нет — и идентификатор транзакции.
- Обновление заказа. Магазин переводит заказ в статус «оплачен» и запускает дальнейшую логику: уведомления, обмен с 1С, отгрузку.
Ключевая идея: карта физически проходит мимо вашего сервера. Магазин оперирует статусами и идентификаторами, а не PAN и CVV. Именно поэтому корректная настройка обработчика платежей — это не только про удобство, но и про безопасность и юридическую защиту бизнеса.
Токенизация для повторных платежей
Частый аргумент в пользу хранения карт — «нам нужны повторные списания» или «подписка». Это решается без хранения номеров через токенизацию. Схема такая: при первой оплате провайдер сохраняет карту у себя и выдаёт магазину токен — безопасный идентификатор, который сам по себе бесполезен для мошенника.
- Повторный платёж. Для следующего списания магазин отправляет провайдеру токен и сумму, а не номер карты.
- Подписки. Регулярные платежи инициируются по токену по расписанию, обычно через агенты Битрикс или внешний планировщик.
- Безопасность. Реальный номер карты остаётся у провайдера; утечка токена не даёт доступа к деньгам напрямую.
Так удобство повторной оплаты сохраняется, но чувствительные данные по-прежнему не лежат у вас. Логику регулярных списаний и обмен статусами с внешними системами удобно оформлять аккуратно на серверной стороне — близко к тому, что мы разбирали в материале про REST, вебхуки и их безопасность.
Что магазин всё-таки хранит и как это защищать
Отказавшись от данных карт, вы всё равно храните персональные данные покупателей, и они тоже требуют защиты — уже по 152-ФЗ, а не по PCI DSS. К ним относятся имя, телефон, email, адрес доставки и история заказов.
- Минимизация. Собирайте только те данные, что реально нужны для заказа и доставки, не больше.
- Разграничение доступа. В админке 1С-Битрикс права по ролям: менеджер видит заказы, но не имеет доступа к настройкам сервера.
- Шифрование канала. Весь сайт работает по HTTPS, персональные данные не передаются в открытом виде.
- Резервные копии. Регулярные бэкапы с контролем доступа к ним самим.
Персональные данные — тоже актив, за который вы отвечаете. Разница в том, что риск от их утечки несопоставимо ниже, чем от утечки платёжных карт, а защита строится штатными средствами платформы и грамотной инфраструктурой.
Проактивная защита и WAF в 1С-Битрикс
Даже без хранения карт периметр магазина нужно защищать: он обрабатывает деньги, персональные данные и является привлекательной целью. В 1С-Битрикс для этого есть встроенные механизмы.
- Проактивная защита. Комплекс настроек, повышающих уровень безопасности: уровень защищённости сессий, контроль активности, одноразовые пароли для админов.
- Веб-экран приложения (WAF). Проактивный фильтр отсекает типовые атаки — SQL-инъекции, XSS, попытки внедрения кода — на входе, до того как запрос дойдёт до логики.
- Журнал вторжений. Фиксация подозрительной активности для расследования инцидентов.
- Контроль целостности. Отслеживание изменений критичных файлов, чтобы вовремя заметить компрометацию.
Эти инструменты идут «из коробки», но требуют осознанной настройки под проект. Их включение и калибровка — обязательная часть подготовки магазина к боевой эксплуатации, а не опция «когда-нибудь потом».
HTTPS, доступы и разграничение прав
Базовая гигиена безопасности закрывает большую часть простых атак и часто игнорируется до первого инцидента. Минимальный набор:
- Только HTTPS. Весь трафик по защищённому соединению, с корректными редиректами и без «смешанного» контента.
- Сильные пароли и двухфакторность. Для администраторов — одноразовые пароли и ограничение по IP там, где это возможно.
- Принцип минимальных прав. Каждый сотрудник имеет ровно тот доступ, что нужен для работы, и не больше.
- Отдельные учётки. Никаких общих логинов «на всех» — каждое действие в админке персонифицировано.
Разграничение прав в 1С-Битрикс гибко настраивается через группы пользователей и права на модули. Продуманная ролевая модель снижает и внешние риски, и внутренние — от случайных или намеренных ошибок сотрудников.
Обновления, журналирование и мониторинг
Безопасность — это процесс, а не однократная настройка. Три вещи, которые нужно поддерживать постоянно:
- Обновления. Ядро 1С-Битрикс, модули и окружение (PHP, веб-сервер) обновляются регулярно — большинство взломов используют известные и давно закрытые уязвимости.
- Журналирование. Логи авторизаций, платежей и изменений хранятся и анализируются, чтобы восстановить картину при инциденте.
- Мониторинг. Оповещения о подозрительной активности, всплесках нагрузки и ошибках позволяют реагировать до того, как проблема станет утечкой.
Крепкое, регулярно обновляемое окружение — фундамент всей защиты. Как его выстроить, мы разбирали в статье про хостинг и инфраструктуру BitrixVM, а безопасную выкладку обновлений без простоя — в материале про CI/CD и деплой Битрикс.
Юридическая сторона и ответственность
Вынос платёжной формы за периметр сайта — это не только техника, но и распределение ответственности. Если данные карты вводятся на стороне сертифицированного провайдера, ответственность за их безопасность несёт он и банк, а не ваш магазин. Это принципиально снижает юридические и репутационные риски бизнеса.
Со своей стороны магазин отвечает за корректную обработку персональных данных: наличие политики конфиденциальности, получение согласий, уведомление регулятора при необходимости и защиту тех данных, что вы храните. Разделение «карты — у провайдера, персональные данные — у нас, но защищённые» даёт понятную и обороноспособную юридическую позицию.
Частые ошибки
- Хранение карт «для удобства». Номера, сроки или CVV в базе или логах — прямой путь к катастрофической утечке и нарушению PCI DSS.
- Самописное шифрование карт. Иллюзия безопасности: требования стандарта этим не закрываются, хранить PAN всё равно нельзя.
- Карта проходит через сервер магазина. Даже транзитом — это переводит вас в тяжёлый SAQ D и повышает риск.
- Выключенная проактивная защита и WAF. Штатные средства есть, но не настроены — периметр открыт.
- Отсутствие HTTPS на части страниц. Смешанный контент и незащищённые формы утекают в открытый канал.
- Общие админские доступы. Один логин на всех — невозможно расследовать инцидент и легко скомпрометировать.
- Забытые обновления. Устаревшее ядро и модули с известными дырами — самая частая причина взлома.
Чек-лист безопасности платежей
- Карта не касается сервера. Ввод данных карты — только на стороне платёжного провайдера, магазин получает статус и идентификатор.
- Уровень PCI DSS определён. Целитесь в SAQ A, форма оплаты вынесена за периметр сайта.
- Повторные платежи — по токену. Подписки и рекуррентные списания через токенизацию, без хранения номеров.
- Персональные данные защищены. Минимизация, HTTPS, разграничение прав, резервные копии.
- Проактивная защита включена. WAF, журнал вторжений, контроль целостности настроены под проект.
- Доступы под контролем. Персональные учётки, сильные пароли, двухфакторность для админов.
- Обновления и мониторинг. Ядро, модули и окружение обновляются, логи и оповещения работают.
- Юридическая база готова. Политика конфиденциальности, согласия, корректная обработка ПДн.
Вывод
Самый безопасный способ хранить данные карт — не хранить их вовсе. Вынос ввода карты на сторону платёжного провайдера переводит магазин в лёгкий уровень PCI DSS, снимает главный источник риска и распределяет ответственность в вашу пользу. Повторные платежи закрывает токенизация, а не собственная база номеров.
Всё, что остаётся под вашей ответственностью, — персональные данные покупателей и периметр сайта — защищается штатными средствами 1С-Битрикс: проактивной защитой и WAF, HTTPS, разграничением прав, обновлениями и мониторингом. Выстройте эти уровни один раз правильно — и приём оплаты станет не зоной риска, а надёжной частью вашего бизнеса.
