SSL-сертификат больше не является конкурентным преимуществом — это базовое требование. Браузеры помечают сайты без HTTPS как «небезопасные», а поисковые системы понижают их в выдаче. Но одного SSL недостаточно: он шифрует соединение, но не защищает от взлома сервера, кражи паролей или заражения malware.

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

Для кого этот чек-лист

Для владельцев сайтов на WordPress, Tilda, 1С-Битрикс или кастомных решениях. Для тех, у кого нет штатного безопасника, но есть ответственность за данные клиентов.

1. Доступы и пароли

Слабые и украденные учётные данные — самый простой путь для атакующего. По данным Verizon DBIR 2025, украденные логины фигурируют в 22% взломов. Один скомпрометированный пароль может открыть доступ к серверу, админке сайта и CRM.

  • Длинные уникальные пароли. Минимум 12 символов, разные для каждого сервиса. Используйте менеджер паролей (Bitwarden, 1Password).
  • Двухфакторная аутентификация (2FA). Включите её для хостинга, админки CMS, CRM и почты. Приоритет — аппаратные токены или приложения (не SMS).
  • Ролевой доступ. У каждого сотрудника — свой аккаунт с минимально необходимыми правами. Не используйте общий логин «admin» на нескольких сайтах.
  • Ревизия аккаунтов раз в месяц. Удаляйте учётки уволенных сотрудников и подрядчиков, чьи проекты завершены.

2. SSL, HTTPS и заголовки безопасности

HTTPS — обязательный минимум. Убедитесь, что HTTP-запросы редиректятся на HTTPS, а сертификат автоматически продлевается. Но это только начало.

  • HSTS (HTTP Strict Transport Security). Заставляет браузер всегда подключаться по HTTPS, даже если пользователь ввёл http://. Включайте только после того, как убедитесь, что все поддомены работают по HTTPS.
  • Content-Security-Policy (CSP). Ограничивает источники, с которых можно загружать скрипты. Это главная защита от XSS-атак.
  • X-Frame-Options / frame-ancestors. Защита от кликджекинга — когда сайт встраивают в iframe и обманом заставляют пользователя кликать.
  • Referrer-Policy. Ограничивает передачу данных о том, откуда пришёл пользователь. Убирает утечку чувствительных URL.
Как проверить: откройте securityheaders.com и введите адрес сайта. Сервис покажет оценку и список отсутствующих заголовков.

3. Обновления CMS, плагинов и зависимостей

Устаревший плагин — классическая точка входа. Google прямо рекомендует «оставаться в курсе последних обновлений и патчей»: каждый инструмент, который упрощает создание сайта, добавляет риск эксплуатации.

  • Автообновления для CMS. WordPress, Tilda, 1С-Битрикс — включите автообновление ядра и критических плагинов.
  • Инвентаризация плагинов. Раз в квартал проверяйте список установленных плагинов. Удаляйте те, которыми не пользуетесь — они всё равно остаются точкой уязвимости.
  • Мониторинг уязвимостей. Подпишитесь на уведомления о безопасности для вашей CMS и плагинов. Сервисы вроде WPScan или Patchstack присылают алерты.

4. Резервные копии

Бэкапы — ваша страховка. Если сайт взломают или сервер упадёт, вы восстановите всё за 15 минут вместо недель переговоров с хостингом. Главное правило — 3-2-1: три копии, на двух разных носителях, одна — вне офиса.

  • Автоматические бэкапы. Ежедневно — база данных, еженедельно — полная копия сайта (файлы + БД).
  • Хранение вне сервера. Не храните бэкапы на том же хостинге. Используйте внешнее хранилище (S3, Яндекс.Облако, Dropbox).
  • Тестирование восстановления. Раз в квартал разверните бэкап на тестовом домене и убедитесь, что сайт работает. Бэкап, который никогда не восстанавливали, — это не бэкап.

5. Мониторинг и логи

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

  • Мониторинг доступности. Сервисы вроде UptimeRobot или Better Stack проверяют сайт каждую минуту и присылают алерт при падении.
  • Алерты на подозрительные входы. Настройте уведомления при повторных неудачных попытках входа в админку и по SSH.
  • Google Search Console. Раздел «Проблемы безопасности» покажет, если Google обнаружил malware или фишинговые страницы на вашем сайте.

6. WAF и защита от атак

Web Application Firewall (WAF) фильтрует трафик до того, как он дойдёт до сервера. Блокирует SQL-инъекции, XSS, попытки подбора паролей и DDoS-атаки.

  • Cloudflare (бесплатный тариф). Проксирует трафик через свою сеть, блокирует ботов и известные атаки. Подходит для любого сайта.
  • WAF на уровне хостинга. Многие хостинги (Cloudways, Timeweb, Reg.ru) предлагают встроенный WAF. Проверьте, включён ли он.
  • Ограничение доступа к админке. Если возможно — ограничьте доступ к /wp-admin и SSH по IP-адресам офиса.

7. Регулярный аудит и план на случай инцидента

Безопасность — это процесс, а не разовая акция. Даже если всё настроено правильно сегодня, через месяц выйдет новый плагин с уязвимостью или изменится конфигурация сервера.

  • Сканирование уязвимостей раз в квартал. Автоматический скан + ручная проверка критичных мест.
  • План реагирования. Заранее решите: кто отключает сайт, кто меняет пароли, кого уведомлять. Запишите это в документе и храните вне сайта.
  • Проверка после изменений. После крупного обновления CMS, смены хостинга или добавления нового плагина — прогоните чек-лист заново.

Безопасность — это не разовая настройка

Мы в «Русу по Вкусу» закрываем все эти пункты при запуске сайта и продолжаем следить за ними в рамках технической поддержки. Если у вас уже есть сайт — проведём начальную проверку и покажем, что можно улучшить.