Безопасность является процессом, а не плагином
Сайт зависит от кода, сервера, компьютеров редакторов, внешних сервисов и людей. Защитный модуль не исправит общий пароль в чате, устаревший плагин или публичную резервную копию. Нужны слои, ответственные и регулярные операции.
Меры выбираются по данным и последствиям. Презентационный сайт и кабинет с документами требуют разной строгости, но базовая гигиена обязательна обоим.
Сначала составьте карту данных
| Вопрос | Пример для формы | Зачем |
|---|---|---|
| Что собираем? | Имя, телефон, комментарий, UTM | Убрать лишние поля |
| Зачем? | Ответить на запрос проекта | Определить цель обработки |
| Куда передаём? | Сервер, CRM, служебная почта | Очертить контур |
| Кто видит? | Менеджеры конкретной группы | Настроить минимальные права |
| Сколько храним? | По утверждённому регламенту | Организовать удаление |
| Что при сбое? | Журнал и безопасный повтор | Не потерять заявку молча |
Карта охватывает не только WordPress. Если заявка дублируется в почту и резервную копию CRM, все три места входят в процесс.
Минимальные технические меры
- HTTPS на публичной и административной части.
- Обновляемые ядро, тема, плагины и серверные компоненты.
- Отдельные аккаунты, сильная аутентификация и минимальные роли.
- Серверная валидация и экранирование данных.
- Защита от спама, перебора и чрезмерной частоты запросов.
- Секреты вне публичного кода и журналов.
- Резервные копии с проверкой восстановления.
- Мониторинг доступности и значимых событий.
Безопасная форма заявки
Браузерная проверка улучшает опыт, но сервер заново валидирует каждое поле. Запрос защищается от подделки, внедрения кода и автоматического злоупотребления. Ограничение частоты не должно блокировать обычного пользователя без понятного сообщения.
После отправки пользователь не видит служебную ошибку, токен или персональные данные другого человека. Сайт показывает нейтральный идентификатор обращения, а детали попадают в защищённый журнал.
Доступы и административная часть
- Каждый человек использует собственную учётную запись.
- Роль соответствует задачам: редактору не нужен полный администратор.
- MFA применяется к критическим аккаунтам.
- Неиспользуемые и временные доступы отзываются.
- Вход и значимые изменения журналируются в разумном объёме.
- Секреты передаются защищённым каналом и меняются после передачи.
Смена адреса входа может уменьшить шум, но не заменяет защиту от перебора и сильную аутентификацию.
Плагины и цепочка поставки WordPress
Устанавливайте минимальный набор из официальных или проверенных источников. До добавления оцениваются обновления, совместимость, поддержка, лицензия и дублирование функций. Неиспользуемый отключённый код тоже требует удаления, если он не нужен.
Обновление сначала проверяется на staging с резервной копией и регрессом ключевых сценариев. Автоматическое обновление без наблюдения и вечное откладывание являются двумя крайностями.
Резервная копия считается рабочей после восстановления
Определите RPO: сколько данных допустимо потерять, и RTO: сколько времени допустимо восстанавливать работу. Для сайта с редкими обновлениями и магазина значения различаются. Копии хранятся отдельно от основного сервера и защищаются сопоставимо с данными.
Модельный тест: раз в квартал команда разворачивает копию в изолированном окружении, проверяет базу, файлы, вход и критическую операцию, фиксирует длительность и проблему.
Внешние сервисы и сценарий отказа
| Сервис | Риск | Контроль |
|---|---|---|
| CRM | Лид потерян или создан дважды | Очередь, идемпотентность, журнал, уведомление |
| Почта | Письмо не доставлено | Провайдер, SPF/DKIM, контроль ошибок |
| Платёж | Статус не синхронизирован | Повторная сверка и подпись уведомления |
| Карта/виджет | Замедление и передача данных | Согласие, отложенная загрузка, замена |
| Антиспам | Ложная блокировка | Резервный путь и мониторинг |
Что требуется от заказчика по персональным данным
Заказчик как владелец бизнес-процесса определяет цель, основание, состав, срок хранения, получателей и порядок работы с обращениями субъектов. Разработчик реализует утверждённые правила. Юридическая проверка зависит от юрисдикции, категории данных и организации.
Не копируйте политику другого сайта: она может описывать сервисы и цели, которых у вас нет, и не отражать реальный путь заявки.
План реакции на инцидент
- Обнаружить и зарегистрировать событие.
- Ограничить распространение и сохранить доказательства.
- Оценить затронутые системы и данные.
- Исправить причину и безопасно восстановить работу.
- Выполнить необходимые уведомления по утверждённому регламенту.
- Разобрать причину и изменить контроль.
Контакты и полномочия назначаются до инцидента. В критический момент не должно быть спора, кто имеет право отключить форму или восстановить копию.
Приёмочные доказательства безопасности
- Реестр компонентов, интеграций и владельцев.
- Результат проверки прав и административных аккаунтов.
- Протокол серверной валидации и негативных тестов форм.
- Подтверждение HTTPS и безопасной конфигурации.
- Проверенное восстановление копии.
- Инструкция обновления, мониторинга и инцидента.
Материал не заменяет юридическую консультацию или профессиональное моделирование угроз. Он задаёт минимальный каркас, без которого обещание «сайт защищён» невозможно проверить.