Что входит в безопасность сайта и как ее обеспечить

Проактивный фильтр закрывает 1 слой защиты из 6, и обычно не самый дырявый. Безопасность сайта по контурам: версия PHP и права на файлы, обновления платформы, доступы, код и формы, сертификат с сокращающимся сроком жизни, резервные копии и штрафы по 152-ФЗ.

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

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

Разложим сразу, без предисловий. Безопасность сайта складывается из 6 контуров: окружение (сервер, версии ПО, права на файлы), платформа и ее обновления, доступы и учетные записи, код и обработка пользовательских данных, защищенное соединение с сертификатом, резервные копии с проверенным восстановлением. Поверх этого лежит седьмой, юридический контур — персональные данные посетителей и обязанности оператора по 152-ФЗ. Он не технический, но штрафы по нему сегодня больнее любого простоя.

Разница между «у нас есть защита» и «сайт защищен» проходит ровно здесь. Проактивный фильтр не поможет, если пароль администратора совпадает с паролем от почты, а почта утекла год назад в чужой базе. Свежая платформа не спасет, если PHP на хостинге не обновлялся с 2022 года. Резервная копия бесполезна, если ее ни разу не пробовали развернуть.

Таблица нужна ради одной мысли: у каждого контура свой ответственный, и дыры чаще всего появляются на стыках. Хостинг считает, что обновление PHP — забота разработчика. Разработчик считает, что это хостинг. PHP остается старым.

Окружение: то, что под сайтом, ломают чаще, чем сам сайт

Начну с неприятного факта, который легко проверить прямо сейчас. Откройте у себя в панели хостинга версию PHP. Если там 8.1 или ниже — сайт работает на ветке, которую разработчики языка больше не поддерживают вообще: она вышла из четырехлетнего цикла и не получает даже исправлений критических уязвимостей.

По официальному графику php.net каждая ветка живет 4 года: 2 года активной поддержки и еще 2 года только с исправлениями критических дыр. На август 2026 расклад такой: 8.2 доживает последние месяцы (security-обновления заканчиваются 31 декабря 2026), 8.3 закрыта по безопасности до конца 2027 года, 8.4 еще в активной поддержке до конца 2026 года, 8.5 — текущая ветка.

Отсюда практическое правило: держите PHP не ниже той ветки, у которой до конца security-поддержки остается больше года. Сегодня это 8.3 и выше. Переезд на новую ветку — это работа, иногда с правкой кода, и ее надо планировать заранее, а не в тот день, когда хостинг присылает письмо о принудительном обновлении.

Что еще живет в этом контуре и что стоит проверить:

• Права на файлы и папки. Права 777 на каталоге загрузок — приглашение залить туда исполняемый файл. Рабочий вариант: 644 на файлах, 755 на папках, запись только там, где она нужна движку.
• Выполнение скриптов в каталогах загрузки. Если в папку с картинками можно положить PHP-файл и он выполнится, все остальное уже неважно. Выполнение там должно быть запрещено на уровне конфигурации веб-сервера.
• Изоляция сайтов. На дешевом шаред-хостинге десятки сайтов нередко работают под одним системным пользователем. Взломали соседа — получили доступ к вашим файлам. Отдельный пользователь на сайт закрывает этот сценарий.
• Доступ по SSH и FTP. FTP передает пароль открытым текстом. Если хостинг еще предлагает его, используйте SFTP. Доступ по SSH — по ключу, а не по паролю.
• Служебные файлы в корне. Забытые .git, .env, дампы базы backup.sql, архивы site.zip в публичном каталоге. Их находят автоматическими сканерами за минуты.

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

Платформа: обновления и чужие модули

Второй контур — сама CMS и все, что к ней докручено. Здесь важно различать 2 источника уязвимостей: ядро платформы и сторонние решения.

С ядром все относительно понятно. Вендор находит и закрывает уязвимости, выпускает обновления, публикует информацию. У 1С-Битрикс для этого есть центр информирования о необходимых обновлениях — туда стоит заглядывать или подписаться на уведомления. Обновления работают только при активной лицензии: когда она закончилась, сайт продолжает работать, но новые исправления безопасности вы уже не получаете.

Со сторонними модулями сложнее. Решение из маркетплейса — это чужой код, который выполняется с теми же правами, что и ядро. Если разработчик модуля перестал его поддерживать, дыра в нем останется навсегда. У 1С-Битрикс под это заведен отдельный реестр решений сторонних разработчиков с выявленными уязвимостями. Проверьте по нему то, что стоит у вас.

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

Отдельно про то, что дает сама платформа. В 1С-Битрикс за этот контур отвечает модуль «Проактивная защита»: проактивный фильтр (это WAF, он анализирует входящие данные и режет типовые атаки вроде SQL-инъекций и XSS), веб-антивирус, контроль целостности файлов, журнал вторжений, контроль активности против перебора паролей, стоп-лист по IP и ограничение доступа в административный раздел по адресам. Плюс «Сканер безопасности», который проверяет настройки окружения и подсвечивает слабые места. Уровней защиты 3: стандартный, высокий и повышенный — система сама подсказывает, что включить.

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

Доступы: самый дешевый и самый игнорируемый контур

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

В свежем OWASP Top 10 версии 2025 года — это отраслевой список самых критичных рисков веб-приложений, который поддерживает международное сообщество OWASP, — на первом месте стоит Broken Access Control, нарушение контроля доступа. То есть ситуация, когда пользователь может сделать то, что ему делать не положено. Речь идет про обычные незакрытые двери: доступную посторонним страницу, лишнюю учетную запись, права, которые никто не пересматривал.

Что проверить в первую очередь:

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

Есть еще одна дверь, про которую забывают: доступ подрядчика. Когда сотрудничество заканчивается, доступы надо отзывать в тот же день — и к сайту, и к хостингу, и к домену, и к репозиторию. Мы в Design Lab при передаче проекта другому подрядчику всегда просим клиента сменить пароли после нас. Это нормальная практика, а не недоверие.

Код и данные: что приходит от посетителей

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

В версии OWASP Top 10 2025 года список заметно перетасовали. На втором месте — Security Misconfiguration, ошибки конфигурации. Третье место занял новый пункт Software Supply Chain Failures, то есть проблемы в цепочке поставки: уязвимости приходят не из вашего кода, а из библиотек, пакетов и сборочных инструментов, которые вы подключили. Инъекции опустились на пятое место, а SSRF растворили внутри первого пункта. Появилась и десятая категория Mishandling of Exceptional Conditions — неправильная обработка нештатных ситуаций, когда приложение при ошибке вываливает наружу лишнее или ведет себя непредсказуемо.

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

Практический минимум для этого контура:

• Параметризованные запросы к базе. Никакой склейки SQL из пользовательских строк. Это правило старше многих разработчиков и до сих пор нарушается.
• Проверка загружаемых файлов. По содержимому, а не по расширению. Файл photo.jpg.php проходит проверку по имени и не проходит по типу.
• Экранирование вывода. Все, что пришло от пользователя и попадает в HTML, должно быть обработано. Иначе комментарий с тегом script станет чужим кодом на вашей странице.
• Заголовки безопасности. Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security. Настраиваются один раз и снимают целый класс атак на посетителей.
• Учет внешних скриптов. Каждый подключенный на сайт чужой скрипт — виджет, чат, пиксель — выполняется с полными правами на вашей странице и видит все, что вводит посетитель. Список таких скриптов стоит держать коротким и осознанным.
• Аккуратные сообщения об ошибках. Стандартный текст для посетителя, подробности — в лог. Вывод стека вызовов на боевом сайте показывает атакующему структуру проекта.

Проверить эти пункты на существующем сайте без разработчика тяжело. Часть из них видна снаружи, часть — только в коде. Это одна из причин, по которой технический аудит имеет смысл: чек-лист из 30 проверок мы описали отдельно, безопасности там посвящен свой блок.

Сертификат: срок жизни сокращают, и ручное продление скоро станет проблемой

HTTPS сегодня есть почти у всех, поэтому контур кажется закрытым. Но в нем происходит изменение, которое застанет врасплох тех, кто продлевает сертификат руками раз в год.

В апреле 2025 года CA/Browser Forum утвердил бюллетень SC-081v3 — это отраслевой орган, в котором браузеры и удостоверяющие центры договариваются о правилах. Он ввел график сокращения максимального срока жизни публичных TLS-сертификатов: с 15 марта 2026 года — 200 дней, с 15 марта 2027 года — 100 дней, с 15 марта 2029 года — 47 дней.

Что это значит на практике. Пока срок был год, ручное продление еще как-то жило: 1 раз в 12 мес. кто-нибудь вспоминал. При 100 днях продлевать придется 3–4 раза в год, при 47 — примерно раз в 6 недель. Ручной процесс на такой частоте ломается гарантированно, и однажды посетители увидят предупреждение браузера вместо сайта.

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

Резервные копии: копия, которую не разворачивали, копией не считается

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

Рабочая схема выглядит так:

1. Регулярность по частоте изменений. Интернет-магазину с заказами нужна ежедневная копия базы, корпоративному сайту с новостями раз в неделю хватит. Ориентир простой: сколько данных вы готовы потерять.
2. Копия вне сервера. Бэкап на том же диске, что и сайт, не спасает ни от шифровальщика, ни от отказа хостинга. Нужна вторая площадка.
3. Глубина хранения. Одной последней копии мало: заражение часто замечают через неделю, и к этому моменту вредоносный код уже во всех свежих копиях. Держите цепочку хотя бы за 30 дней.
4. Проверка восстановления. Раз в квартал копия разворачивается на тестовой площадке целиком и проверяется, что сайт работает. Без этого шага вы храните архивы, а не резервные копии.
5. Записанный порядок действий. Кто восстанавливает, откуда берет доступы, сколько времени это займет. В момент аварии искать эти ответы поздно.

Четвертый пункт пропускают почти все. У нас в Design Lab тестовое восстановление стоит в графике плановых работ с конкретной датой, потому что «когда-нибудь проверим» на практике означает «не проверим».

Юридический контур: персональные данные и суммы штрафов

Если на сайте есть форма обратной связи, регистрация или оформление заказа, вы собираете персональные данные и являетесь оператором со всеми обязанностями по 152-ФЗ. Технической защиты это касается напрямую: утечка базы клиентов — это не только репутация, но и административная ответственность.

Размеры штрафов задает статья 13.11 КоАП РФ, в которую Федеральным законом от 30.11.2024 № 420-ФЗ добавили части 10–18, действующие с 30 мая 2025 года. Цифры по действующей редакции статьи для юридических лиц:

Оборотный штраф из части 15 стоит перечитать дважды: он считается от выручки за календарный год и не может быть меньше 20 млн руб. Для среднего бизнеса это уже не «неприятность», а угроза существованию компании. Индивидуальные предприниматели по этим частям отвечают как юридические лица — примечание 1 к статье.

Есть и вторая часть обязанностей, о которой узнают поздно. По статье 21 152-ФЗ оператор при установлении факта неправомерной передачи персональных данных обязан уведомить Роскомнадзор в течение 24 часов о самом инциденте и в течение 72 часов — о результатах внутреннего расследования. Сутки на реакцию означают, что порядок действий должен быть написан заранее: кто фиксирует инцидент, кто подает уведомление, где лежат контакты.

Минимальный набор по этому контуру: уведомление в Роскомнадзор подано, политика обработки персональных данных опубликована на сайте и доступна с каждой формы, согласие берется отдельной галочкой без предзаполнения, базы с данными россиян размещены на территории России, доступ к персональным данным ограничен ролями, порядок действий при утечке описан.

Как это выглядит по календарю

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

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

По часам это обычно 4–8 ч. в месяц для типового корпоративного сайта и заметно больше для магазина с интеграциями. Если своего технического специалиста нет, эти работы обычно входят в абонемент по поддержке сайта; из чего складывается его стоимость, мы разбирали в материале про цену обслуживания сайта.

С чего начать, если сейчас нет ничего

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

1. Ревизия доступов. Откройте список пользователей админки, удалите лишних, включите двухфакторный вход оставшимся, смените пароли, которые совпадают с другими сервисами. Это делается за 1 час и закрывает самый частый сценарий взлома.
2. Проверка копий. Выясните, где лежат бэкапы, за какой период и попросите развернуть свежий на тестовой площадке. Если ответа нет — это первая задача подрядчику.
3. Версия PHP и лицензия. Посмотрите в панели хостинга версию PHP, в админке — дату окончания лицензии на платформу. Обе цифры должны быть в будущем.
4. Сертификат. Проверьте дату истечения, включите автопродление, убедитесь, что уведомления приходят на действующий адрес.
5. Технический осмотр. Все, что связано с кодом, правами на файлы, заголовками и настройками сервера, оценивает специалист. По итогам получается список работ с приоритетами, а не общая рекомендация «усилить безопасность».
6. Регламент. Зафиксируйте, кто и с какой периодичностью делает работы из предыдущего раздела. Устная договоренность перестает выполняться на втором месяце.

4 убеждения, из-за которых сайты остаются незащищенными

«Наш сайт никому не интересен». Массовые атаки не выбирают жертву по интересности. Сканеры обходят диапазоны адресов и пробуют известные уязвимости на всем подряд. Небольшой сайт ломают не ради него самого, а чтобы разместить чужие страницы, рассылать спам или встроить редирект. Почему таких атак стало больше, мы разбирали в материале о росте числа уязвимостей.

«Мы платим за хостинг, значит защита включена». Хостинг отвечает за свою инфраструктуру: сеть, железо, изоляцию, иногда за версии системного ПО. За код сайта, обновления CMS, пароли администраторов и настройки прав он не отвечает и по договору обычно прямо это оговаривает.

«У нас стоит WAF, все закрыто». Проактивный фильтр режет типовые атаки на входе. Он не защищает от украденного пароля администратора, от уязвимого модуля, установленного вами же, от старого PHP и от утечки через доступ подрядчика. Это 1 слой, а не замена остальным.

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

Частые вопросы

Сколько стоит привести безопасность сайта в порядок?

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

Достаточно ли поставить плагин безопасности и забыть?

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

Как понять, что сайт уже взломан?

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

Что делать первым делом, если взлом уже произошел?

Снять свежую копию текущего состояния (она понадобится для разбора), сменить все пароли и ключи доступа, включая доступ к базе и хостингу, найти точку входа по логам, восстановиться из заведомо чистой копии и только потом закрыть уязвимость. Если утекли персональные данные, параллельно включается срок в 24 часа на уведомление Роскомнадзора.

Нужно ли все это сайту-визитке на 5 страниц без форм?

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

Что стоит сделать на этой неделе

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

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

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