Практика
Безопасность интернет-магазина: платежи и данные
Безопасность интернет-магазина: как не хранить данные карт по PCI DSS, защитить аккаунты покупателей и админку, выполнить закон 99-З. Чек-лист из 15 пунктов.
Коротко. Безопасность интернет-магазина держится на трёх зонах. Первая — платежи: данные банковских карт не должны проходить через ваш сервер, оплата идёт на странице банка или платёжного провайдера, а скрипты на странице оформления заказа под контролем; требования задают стандарт PCI DSS и договор с эквайером. Вторая — аккаунты: обязательная двухфакторная аутентификация для администраторов и менеджеров, защита входа покупателей от подбора паролей, безопасное хранение паролей и сброс по одноразовой ссылке. Третья — данные покупателей: минимум собираемых полей, разграничение доступа, резервные копии и выполнение закона № 99-З. Основу для всех трёх зон дают обновлённая CMS и настроенные заголовки безопасности сайта.
Статья для владельца, директора по e-commerce или разработчика интернет-магазина, который принимает оплату картами и хранит данные покупателей.
Что атакуют в интернет-магазине
Интернет-магазин интересен атакующему сразу по нескольким причинам: через него проходят платежи, в нём хранятся контакты и адреса покупателей, а бонусные баллы и подарочные сертификаты можно превратить в деньги. OWASP Top 10 2021 ставит на первое место нарушения контроля доступа (Broken Access Control) — это ровно та ошибка, при которой покупатель видит чужой заказ, поменяв номер в адресной строке.
| Что атакуют | Как | Чем закрыть |
|---|---|---|
| Страница оплаты | внедрение чужого скрипта, который копирует данные карты (веб-скимминг) | оплата на стороне банка, контроль скриптов, Content-Security-Policy |
| Вход покупателей | подбор паролей из чужих утечек (credential stuffing) | лимиты попыток, проверка паролей, уведомления о входе |
| Админка и CMS | уязвимые модули, слабые пароли, забытые учётные записи | обновления, двухфакторная аутентификация, ограничение доступа |
| Заказы и личные кабинеты | доступ к чужому заказу по номеру, SQL-инъекции | проверка владельца на сервере, параметризованные запросы |
| Бонусы и промокоды | повторное применение, отрицательное количество, подмена цены | все расчёты только на сервере, лимиты |
| База покупателей | выгрузки в открытых папках, резервные копии в публичном каталоге | права доступа, шифрование копий, минимизация данных |
| Сотрудники | фишинг, поддельные просьбы о выгрузке базы | роли, журнал действий, обучение |
Платежи: как не стать хранилищем данных карт
Главное решение принимается на этапе выбора способа оплаты. Чем меньше карточных данных касается вашей инфраструктуры, тем меньше требований PCI DSS к магазину и тем меньше ущерб при взломе.
- Используйте платёжную страницу банка или провайдера. Перенаправление на страницу оплаты или встроенная форма провайдера означает, что номер карты вводится не на вашем сервере. Для такого сценария небольшие магазины обычно подтверждают соответствие анкетой самооценки SAQ A, но выбор анкеты согласуется с эквайером.
- Не храните данные карт сами. Код безопасности карты (CVC/CVV) хранить после авторизации платежа стандарт PCI DSS запрещает. Для повторных покупок используйте токены, которые выдаёт платёжный провайдер.
- Контролируйте скрипты на странице оформления заказа. Даже если форма карты у провайдера, чужой скрипт на вашей странице может подменить кнопку оплаты или перенаправление. В PCI DSS v4.0.1 есть отдельные требования к скриптам платёжной страницы и контролю её изменений.
- Проверяйте уведомления об оплате на сервере. Сверяйте подпись уведомления от платёжного шлюза, сумму и номер заказа. Цене и статусу, пришедшим из браузера, доверять нельзя.
- Храните ключи платёжного шлюза на сервере, не в коде сайта и не в репозитории, и перевыпускайте их при смене подрядчика.
Подробно о требованиях, уровнях и анкетах — в статье о PCI DSS для интернет-магазина.
Аккаунты покупателей и сотрудников
Покупатели
- Пароли хранятся только в виде хеша медленной функцией, например Argon2id или bcrypt, как рекомендует OWASP Password Storage Cheat Sheet.
- Вход защищён от подбора: ограничение числа попыток, задержка после неудач, проверка по спискам скомпрометированных паролей, уведомление покупателя о входе с нового устройства.
- Сброс пароля — по одноразовой ссылке с ограниченным сроком действия. Ответ формы одинаков для существующей и несуществующей почты, чтобы по нему нельзя было проверить, есть ли покупатель в базе.
- Вход по коду из SMS ограничен по частоте: иначе форму используют для рассылки дорогих сообщений за ваш счёт.
- Каждый запрос к заказу, адресу или бонусам проверяет на сервере, что объект принадлежит этому покупателю.
- Сессии завершаются по кнопке «Выйти на всех устройствах» и после смены пароля.
Администраторы и менеджеры
- Двухфакторная аутентификация обязательна для всех, у кого есть доступ к админке.
- Личные учётные записи вместо общей учётной записи «admin».
- Роли: менеджер обрабатывает заказы, но не выгружает всю базу; контент-менеджер не видит платежи.
- Журнал действий: кто выгружал данные, менял цены и способы оплаты.
- Админка доступна только из офиса или через VPN, если CMS это позволяет.
- Учётные записи уволенных сотрудников и бывших подрядчиков отключаются в день ухода.
Данные покупателей и закон № 99-З
Интернет-магазин — оператор персональных данных: имена, телефоны, адреса доставки, история заказов. Закон Республики Беларусь № 99-З «О защите персональных данных» требует:
- политику обработки персональных данных, доступную на сайте;
- основания обработки — например, согласие покупателя на рассылки. Какие основания применимы к исполнению заказа без отдельного согласия, нужно уточнить.
- назначенное ответственное лицо в компании;
- меры защиты по статье 17 закона и документы, которые их подтверждают;
- уведомление НЦЗПД о нарушениях систем защиты персональных данных.
Для cookie действуют рекомендации НЦЗПД: необходимые cookie работают без согласия, аналитические и рекламные — только после явного согласия, кнопки «Принять» и «Отклонить» равнозначны, есть «Настройки cookie» и отдельная политика cookie.
Практические правила сверх документов: не собирайте поля «на всякий случай», передавайте службе доставки только нужное для доставки, не держите выгрузки покупателей в почте и мессенджерах менеджеров. За непринятие мер защиты персональных данных ст. 23.7 КоАП предусматривает штраф до 50 базовых величин, за умышленную утечку — до 200 базовых величин. Подробнее — в статье о требованиях закона № 99-З к сайту.
Сайт, CMS и хостинг
Большинство платформ магазинов — WordPress с WooCommerce, 1С-Битрикс, OpenCart и собственные разработки — уязвимы в первую очередь через модули и отсутствие обновлений. Базовые меры:
- обновлять ядро CMS, тему и модули, удалять неиспользуемые расширения — порядок описан в материале об уязвимостях WordPress, Bitrix и других CMS;
- включить HTTPS, HSTS и Content-Security-Policy, флаги Secure, HttpOnly и SameSite для cookie сессии — за один день по инструкции о заголовках безопасности сайта;
- не публиковать тестовую копию магазина с реальной базой;
- хранить пароли баз данных и ключи API вне репозитория;
- делать зашифрованные резервные копии базы и файлов вне основного сервера и проверять восстановление;
- отслеживать изменения файлов на страницах оформления заказа и оплаты.
Чек-лист безопасности интернет-магазина
- Номер карты вводится на странице банка или провайдера, а не на вашем сервере.
- Данные карт и CVC нигде не хранятся, для повторных покупок — токены провайдера.
- Анкета PCI DSS выбрана и согласована с эквайером.
- Скрипты на странице оформления заказа перечислены и контролируются.
- Уведомления об оплате проверяются по подписи, сумма сверяется на сервере.
- Двухфакторная аутентификация обязательна для админки.
- У сотрудников личные учётные записи и роли, действия журналируются.
- Пароли покупателей хранятся медленным хешем, вход защищён от подбора.
- Доступ к заказам и личным кабинетам проверяется на сервере.
- Промокоды, бонусы и цены рассчитываются только на сервере.
- CMS, тема и модули обновлены, лишние расширения удалены.
- Настроены HTTPS, HSTS, Content-Security-Policy и флаги cookie.
- Есть политика обработки персональных данных, согласия и настройки cookie.
- Резервные копии зашифрованы, хранятся отдельно, восстановление проверено.
- Записан порядок действий при взломе и контакты эквайера.
Если магазин всё-таки взломали
- Не удаляйте следы и не переустанавливайте сайт до снятия копий журналов и файлов.
- Смените пароли администраторов, базы данных и ключи платёжного шлюза.
- Сообщите эквайеру в сроки и порядке, установленные договором.
- Оцените, затронуты ли персональные данные, и при нарушении систем защиты уведомите НЦЗПД.
- Найдите и закройте причину, иначе повторный взлом — вопрос дней.
Пошаговый порядок — в статье о том, что делать при утечке данных. Проверить магазин до инцидента помогут пакеты Viviar: «Цифровой Минимум» с проверкой по закону 99-З и сканированием уязвимостей — от 1 700 BYN, аудит защищённости одного продукта с разбором кода в пакете «Запуск безопасной разработки» — от 20 300 BYN. Все направления — на странице кибербезопасности Viviar.
Частые вопросы
Нужно ли интернет-магазину соответствовать PCI DSS?
Да, если магазин принимает оплату банковскими картами: требования PCI DSS распространяются на всех, кто хранит, обрабатывает или передаёт данные карт, и приходят через договор с эквайером. Объём зависит от способа оплаты. Если номер карты вводится на странице банка или провайдера, требований к магазину значительно меньше, но формат подтверждения согласуют с эквайером.
Можно ли хранить данные карт для повторных покупок?
Самостоятельно хранить номера карт магазину не стоит: это резко увеличивает объём требований PCI DSS и ущерб при взломе, а код безопасности карты после авторизации хранить запрещено. Для повторных покупок используют токены, которые выдаёт платёжный провайдер. Магазин хранит только токен, который бесполезен вне связки с конкретным провайдером.
Какие данные покупателей можно собирать?
Собирайте только то, что нужно для заказа, доставки и связи с покупателем, и то, на что есть основание по закону № 99-З. Дату рождения, отчество или второй телефон просить без необходимости не стоит. Для рассылок нужно отдельное согласие. На сайте должна быть политика обработки персональных данных и настройки cookie.
Как защитить личные кабинеты покупателей от взлома?
Храните пароли медленным хешем, ограничьте число попыток входа, проверяйте пароли по спискам утечек и уведомляйте покупателя о входе с нового устройства. Сброс пароля делайте по одноразовой ссылке с коротким сроком. Каждый запрос к заказам и адресам должен проверять на сервере, что данные принадлежат этому покупателю.
Как часто проверять безопасность интернет-магазина?
Обновления CMS и модулей устанавливайте по мере выхода, сканирование уязвимостей проводите регулярно, а полноценную проверку защищённости — минимум раз в год и после крупных изменений: смены платформы, платёжного шлюза, подключения новой интеграции или редизайна. Отдельно проверяйте страницу оформления заказа после любого добавления сторонних скриптов.
Вывод
Безопасность интернет-магазина начинается с архитектуры оплаты: данные карт остаются у банка или провайдера, а скрипты на странице оформления заказа под контролем. Дальше — защищённые аккаунты покупателей и сотрудников, минимум персональных данных по закону № 99-З, обновлённая CMS и заголовки безопасности. Пройдите чек-лист выше и закройте пункты, которые не отмечены. Покажите нам ваш магазин — проверим платежи, аккаунты и данные покупателей и назовём стоимость после получасового разговора.
Источники: PCI DSS v4.0.1 и анкеты самооценки SAQ (pcisecuritystandards.org); OWASP Top 10 2021 и OWASP Password Storage Cheat Sheet (owasp.org); OWASP Automated Threats to Web Applications (owasp.org); Закон Республики Беларусь от 07.05.2021 № 99-З «О защите персональных данных» (pravo.by); Национальный центр защиты персональных данных — рекомендации по cookie (cpd.by); КоАП Республики Беларусь, ст. 23.7 (pravo.by); цены — публичные пакеты Viviar, /pricing, действуют с 01.09.2026.