Чек-лист безопасности интернет-магазина

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

Ниже — практический чек-лист. Он не заменяет полноценный аудит безопасности, но помогает убрать очевидные риски.

Почему магазин — цель

Магазин интересен не только деньгами. Через него можно получить доступ к почте, CRM, платёжным данным и базе клиентов. Часто атакуют не сайт целиком, а слабое место: старый модуль, простой пароль или открытую админку.

Доступы

Большинство проблем начинается с доступов. Проверьте, кто и как входит в админку, сервер, базу и панель хостинга.

• У каждого сотрудника свой аккаунт.
• Двухфакторная аутентификация для админов.
• Минимальные права и регулярный пересмотр.
• Нет общих паролей в чатах и документах.
• Уволенные сотрудники лишены доступа.
• Пароли хранятся в менеджере, а не в блокноте.

Обновления и зависимости

Устаревшие CMS, модули и библиотеки — частая точка входа. Но обновления без тестирования тоже опасны: можно сломать checkout.

• CMS и фреймворк обновляются по регламенту.
• Плагины и зависимости проверяются.
• Обновления тестируются на копии.
• Есть план отката.
• Нет заброшенных модулей.

Сервер и сеть

• SSL и корректные редиректы.
• Файрвол и ограничение портов.
• Защита от подбора паролей.
• Резервные копии вне сервера.
• Ограничение доступа к админке по IP, где возможно.
• Логи и мониторинг входов.

Код и формы

Формы и загрузка файлов — частый канал атак. Проверьте валидацию, ограничения и защиту от автоматических отправок.

• Валидация на сервере, а не только в браузере.
• Ограничение типов и размеров файлов.
• Защита от SQL-инъекций и XSS.
• CSRF-токены.
• Ограничение частоты запросов.
• Логи ошибок без паролей и токенов.

Платежи и персональные данные

Платёжные данные должны обрабатываться на стороне платёжного провайдера. Магазину не нужно хранить номер карты.

• Оплата через проверенный провайдер.
• Нет хранения CVV и полных карт.
• Согласия на обработку данных.
• Минимум персональных данных.
• Журнал доступа к чувствительным разделам.

Бэкапы и восстановление

Бэкап, который никогда не восстанавливали, — это не бэкап, а надежда. Проверяйте восстановление на копии.

• База и файлы сайта.
• Регулярность и хранение вне сервера.
• Проверка восстановления.
• Доступ к бэкапам ограничен.
• Есть план действий при потере данных.

Чек-лист

Что делать при инциденте

Типичные ошибки

• Один пароль на всех сотрудников.
• Обновления «когда-нибудь».
• Бэкапы на том же сервере.
• Хранение карт на сайте.
• Игнорирование логов и алертов.

Безопасность — это процесс, а не разовая настройка. Начните с доступов, обновлений и бэкапов: они закрывают большинство практических рисков.

Проверка сервера

Сервер — фундамент. Если на нём устаревшие пакеты или открытые порты, защита сайта не поможет.

• Обновления ОС и PHP.
• Файрвол и ограничение портов.
• Отдельный пользователь для сайта.
• Ограничение доступа к админке.
• Логи входов и ошибок.

Платёжные сценарии

Платёжный сценарий должен быть устойчив к подмене суммы и повторным уведомлениям. Проверяйте подпись и статус на сервере, а не только в браузере.

• Серверное подтверждение оплаты.
• Проверка суммы и заказа.
• Идемпотентность уведомлений.
• Логи платежей.
• Алерты на зависшие оплаты.

Регламент доступов

Доступы должны жить по правилам, а не по памяти администратора. Иначе через год никто не вспомнит, у кого остались ключи.

• Список всех доступов и владельцев.
• Выдача по минимальным правам.
• Регулярный пересмотр.
• Закрытие при увольнении.
• Ротация паролей и ключей.

План на 30 дней

Этого плана недостаточно для полного аудита, но он закрывает самые частые и дешёвые риски.

Резервное копирование

Бэкапы должны быть регулярными, полными и проверенными. Копия, которую невозможно восстановить, создаёт ложное чувство защиты.

• База и файлы сайта.
• Хранение вне основного сервера.
• Разные сроки хранения.
• Ограничение доступа к копиям.
• Проверка восстановления.

Мониторинг и реакция

О взломе или сбое нужно узнавать от системы, а не от клиентов. Минимальный мониторинг доступен даже небольшому магазину.

• Недоступность сайта.
• Ошибки 5xx.
• Подозрительные входы.
• Зависшие платежи.

Платёжные данные

Не храните на сайте то, что должен хранить платёжный провайдер. Чем меньше чувствительных данных, тем ниже риск.

• Нет полных номеров карт.
• Нет CVV.
• Проверка подписи платежа.
• Логи без чувствительных данных.

Безопасность — это набор привычек и проверок, а не один установленный модуль.

Доступы подрядчиков

Подрядчики тоже создают риски. У каждого должен быть свой доступ, ограниченный задачей и сроком.

• Отдельные аккаунты.
• Минимальные права.
• Срок действия доступа.
• Отзыв после проекта.

Формы и загрузки

Формы — частая точка входа. Проверяйте не только капчу, но и серверную валидацию.

• Ограничение размера файлов.
• Проверка типов.
• Защита от автоматических отправок.
• Логирование ошибок.

Если форма принимает файлы, храните их вне публичной директории и проверяйте содержимое.

Что делать при утечке

Утечка — это не только техническая проблема. Нужен план, кто что делает и как сообщает клиентам.

• Закрыть доступы.
• Сохранить логи.
• Оценить данные.
• Уведомить ответственных.

Паника и удаление логов мешают разобраться. Сначала факты, потом решения.

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

И зафиксируйте, что изменилось. Через месяц никто не вспомнит, почему был закрыт порт или удалён модуль.

Безопасность не заканчивается списком проверок. Она живёт в привычках команды и регулярных действиях. Чем раньше они станут рутиной, тем ниже цена ошибки. Регулярность важнее разовой настройки: именно она снижает число инцидентов и упрощает разбор. Проверки стоит поставить в календарь и назначить ответственного. Это часть эксплуатации, а не разовый проект. Без регулярности даже хорошие настройки быстро устаревают и перестают защищать. Это очень важно.