Безопасность сайта для малого бизнеса: минимальный набор мер

От кого вы на самом деле защищаетесь

Забудьте про образ хакера, который выбрал вашу компанию целью. В 95% случаев происходит другое: бот обходит интернет подряд, дёргает известные адреса вроде /wp-login.php или /administrator, проверяет старые версии плагинов и подбирает пароли по словарю. Если что-то сработало — сайт попадает в чужую сеть: с него рассылают спам, льют трафик на казино, вставляют скрытые ссылки.

Из этого следует практический вывод. Вам не нужна защита от целенаправленной атаки — вам нужно перестать быть лёгкой мишенью. Это разные по стоимости задачи.

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

Пять вещей, без которых сайт не должен выходить в продакшн

Это минимум. Если чего-то из списка нет — это не «повышенный риск», это незакрытая дверь.

По каждому пункту можно требовать от подрядчика ответ «сделано, вот где посмотреть». Ответ «ну там всё стандартно» не считается.

• HTTPS на всём сайте, с автоматическим продлением сертификата. Проверка: откройте сайт, кликните замок в адресной строке, посмотрите дату окончания. Если сертификат надо продлевать руками — однажды его не продлят.
• Обновления. Для CMS — актуальные версии ядра и плагинов, для самописного проекта — обновлённые зависимости. Спросите, когда обновлялись в последний раз и есть ли тестовая копия, где обновления сначала прогоняют.
• Пароли и двухфакторка. Отдельный пароль на админку, отдельный на хостинг, отдельный на домен, ничего не повторяется. Двухфакторная аутентификация включена на аккаунтах хостинга, регистратора домена и почты — это три точки, потеря которых означает потерю сайта целиком.
• Бэкапы, которые лежат не на том же сервере. Если резервная копия хранится рядом с сайтом, она умрёт вместе с ним при шифровании или сносе аккаунта.
• Разграничение доступов. Контент-менеджеру — роль редактора, не администратора. Подрядчику по рекламе — доступ к аналитике, не к серверу. Один общий админ-логин на всех — это гарантия, что вы никогда не узнаете, кто что сломал.

Бэкап — единственная мера, которая спасает всегда

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

Ключевая проверка, которую почти никто не проводит: попросите развернуть бэкап на тестовом домене и покажите результат. Очень часто выясняется, что копии есть, но в них только файлы без базы данных, или архив бьётся, или последняя рабочая копия — двухмесячной давности. Бэкап, который ни разу не восстанавливали, нельзя считать бэкапом.

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

Формы, заявки и персональные данные

Формы — самое уязвимое место типового сайта, но не в смысле взлома сервера. Через них приходит спам, а вместе с данными клиентов приезжает ответственность перед законом.

Про уведомление Роскомнадзора и тонкости 152-ФЗ говорите с юристом — это не задача разработчика. Задача разработчика — чтобы политика была опубликована, согласие технически фиксировалось, а данные не хранились в открытом виде там, где им не место.

• Защита от ботов на формах: капча или невидимая проверка плюс ограничение частоты отправок с одного адреса. Без этого менеджер начнёт пропускать реальные заявки среди мусора.
• Дублирование заявок минимум в два места — например, в почту и в базу или CRM. Форма, которая отправляет только письмо, однажды съест заявку молча, и вы об этом не узнаете.
• Страница политики обработки персональных данных и чекбокс согласия рядом с кнопкой отправки, а не мелким текстом в подвале.
• Не собирайте лишнего. Каждое поле «дата рождения» и «паспортные данные», которое вам не нужно для работы, — это данные, которые вы обязаны защищать без всякой выгоды для себя.
• Проверьте, кто получает письма с заявками. Если это личная почта уволившегося сотрудника — у вас утечка, а не безопасность.

На что малому бизнесу тратиться не надо

Честно: большинству компаний с сайтом на несколько десятков страниц не нужны платный WAF, корпоративная антиDDoS-защита, пентест и сертификации. Это инструменты для тех, у кого сайт — источник основной выручки или хранилище чувствительных данных.

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

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

Что спросить у подрядчика на старте

Эти вопросы можно задать до подписания договора, ответы не требуют технических знаний для оценки. Вас интересует не терминология, а конкретика: где, как часто, кто отвечает.

Отдельный пункт, о котором забывают все: домен должен быть зарегистрирован на вас или вашу компанию, а не на студию. Хостинг — тоже на ваш аккаунт, с выдачей доступа разработчику. Это ваше имущество, и при расставании с подрядчиком вы не должны ничего у него выпрашивать.

• На кого оформлены домен и хостинг и передаёте ли вы мне все доступы после сдачи проекта?
• Куда и с какой периодичностью делаются бэкапы, можно ли увидеть восстановление?
• Что происходит, если через полгода выйдет уязвимость в используемой CMS или библиотеке: это ваша зона ответственности или моя?
• Есть ли тестовая копия сайта, где обновления проверяются до заливки на живой?
• Как передаются пароли — в мессенджере текстом или через менеджер паролей?

Если сайт уже взломали

Порядок действий важнее скорости. Первое — не удаляйте ничего сразу: сохраните текущее состояние сайта и логи, иначе потом невозможно понять, как зашли. Второе — смените пароли: хостинг, админка, база, FTP/SSH, почта, регистратор домена.

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

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