Безопасность данных сайта нужна не ради «галочки»: сайт влияет на репутацию, заявки и часто на данные клиентов. Уязвимость ведёт к взлому, подмене, простою и прямым потерям. Базовая гигиена — ssl сертификат для сайта и корректный HTTPS, резервное копирование сайта, дисциплина доступов и защита сайта от взлома через обновления и контроль админки.
Ниже — практичный чек-лист и вопросы подрядчику. Материал не заменяет аудит ИБ и не является юридической консультацией по 152-ФЗ.
HTTPS и SSL-сертификат: что проверить без админской магии
SSL-сертификат для сайта сам по себе не гарантирует корректную настройку: смешанный контент, редиректы HTTP→HTTPS, просрочка цепочки. HTTPS шифрует транспорт и поддерживает доверие; не отменяет остальных рисков.
Что проверить
- Сайт по умолчанию открывается по HTTPS, HTTP редиректится.
- Нет смешанного контента (ресурсы по HTTP на HTTPS-странице).
- Сертификат действующий, цепочка intermediate настроена.
Самоподписанный сертификат
На публичной витрине, магазине и ЛК — неприемлем (предупреждения браузера). Для внутренних стендов — допустим при контролируемом доступе.
DV, OV, EV
DV — база для большинства сайтов; OV — доп. проверка организации; EV — расширенная проверка, визуальные бонусы в браузерах сегодня минимальны. Важнее корректная настройка и сроки, чем «тип букв».
Резервное копирование: что именно спасать
Резервное копирование сайта — страховка данных и репутации. В бэкап: файлы (шаблоны, медиа, плагины), БД CMS, конфиги, в обобщённом виде критичные секреты и интеграции, служебные файлы восстановления.
Храните копии off-site, желательно в нескольких уровнях. Раз в квартал — тест восстановления на отдельной среде (страницы, формы, авторизация, интеграции). Уточняйте у хостера расписание, ретеншн и ручной бэкап перед обновлениями.
Сертификаты и ключи в бэкапах: не потерять и не светить
Публичный сертификат — не секрет; приватный ключ — секрет уровня продакшена. Не класть ключи в общие папки и чаты; при шифровании бэкапа ключ расшифровки хранить отдельно. Варианты: зашифрованный бэкап с изолированным ключом; редкий PFX с сильным паролем (пароль отдельно); или не бэкапить ключ, а иметь регламент перевыпуска (часто безопаснее при отлаженном процессе). Для крупных контуров — разговор про HSM.
| Платформа | Что учитывать |
|---|---|
| IIS | Экспорт в PFX при переносе; ограничить доступ |
| Apache | Cert + key с правами файловой системы |
| Tomcat | Keystore целиком + отдельное хранение пароля |
Доступы и пароли: кто владелец ключей от сайта
Реестр зон: хостинг, DNS/регистратор, CMS, почта домена, Git/CI/CD. Пароли уникальные; хранение — менеджер паролей, не переписка. MFA на почту, регистратор, хостинг, CMS, Git.
При уходе подрядчика: смена паролей, отзыв API/SSH-ключей, завершение сессий, проверка почты восстановления, ревизия ролей в CMS.
Обновления CMS и плагинов: главный рычаг против массовых взломов
Массовые компрометации часто идут через известные дыры в плагинах и ядре. Схема: бэкап → тест на копии (staging) → прод. Тревожные признаки: лишние админы, неизвестные файлы, редиректы, чужие плагины, лишние скрипты — срочная проверка, не только «очередное обновление».
Данные клиентов и минимальная защита периметра
Безопасность данных сайта начинается с дисциплины: формы только по HTTPS, собирать минимум полей, ограничить куда уходят копии заявок (не размножать по личным чатам). Внутренний регламент по ПДн — с юристом.
У хостера/админа запросите: лимит попыток входа, WAF или эквивалент, закрытие служебных путей. Просите письменное описание, что включено, а не общие обещания.
Как проверить сайт на безопасность без паранойи
Базовая самопроверка: HTTPS без предупреждений, редиректы, ошибки на ключевых страницах, версия CMS, обновления плагинов/тем, тестовые поддомены, права на файлы, админка с сильным паролем и 2FA, подозрительные пользователи, свежий бэкап, чужие виджеты.
Онлайн-сканеры полезны, но «красные» флаги без контекста бывают ложными — уточняйте у разработчика, не покупайте панику.
Чек-лист безопасности сайта для бизнеса
- Только HTTPS по умолчанию.
- 301 с HTTP на HTTPS.
- Регулярные бэкапы.
- Хранение off-site.
- Тест восстановления.
- Ключи сертификатов — как секреты.
- Ограничение доступов к хостингу и CMS.
- MFA на критичных аккаунтах.
- Процедура при смене подрядчика.
- Обновления CMS/плагинов/тем по схеме с тестом.
- Мониторинг признаков взлома.
- Минимизация ПДн в формах и маршрутизация заявок.
- Разовый скан после крупных изменений или инцидента.
- Назначенный ответственный и простой регламент при инциденте.