## Что я слышу, когда клиент говорит «нам нужен безопасный сайт» Когда клиент приходит и говорит «нам нужен безопасный сайт», я слышу за этими словами совсем не то, что он имеет в виду. У него в голове — образ: поставили сертификат, поставили антивирус, и всё, сайт защищён. У меня в голове — список из двенадцати пунктов, по которому этот сайт нужно проверить, прежде чем я вообще начну говорить о защите. Разница между этими двумя картинками — и есть тема этого поста. ## Ожидание первое: «поставим SSL — и всё зашифровано» Реальность: SSL решает только одну задачу — защищает трафик между браузером и сервером. Он не защищает от взлома админки, не защищает от атак через запросы к базе данных, не защищает от того, что кто-то подберёт пароль. Заказчик видит зелёный замочек в адресной строке и считает, что угрозы закрыты. Я вижу этот же замочек и сразу открываю список из двадцати других вещей, которые нужно проверить. На прошлой неделе клиент прислал мне ссылку на свой интернет-магазин: «У нас SSL, мы в безопасности». Я открыла страницу входа в админку, набрала admin/admin — и попала внутрь. Зелёный замочек горел, а пароль администратора стоял стандартный. Это не анекдот, это обычный вторник. ## Ожидание второе: «антивирус всё поймает» Реальность: антивирус на сервере ловит известные сигнатуры — конкретные куски вредоносного кода, которые уже кто-то видел и загрузил в базу. Если злоумышленник зальёт что-то новое или модифицированное, антивирус промолчит. На одном из сайтов клиента я обнаружила шелл, который висел там три месяца. Антивирус показывал зелёную галочку, всё «чисто». Я нашла его случайно, когда искала причину медленной загрузки страниц. В современной разработке антивирус на сервере — это примерно как замок на двери, который открывается любой пластиковой картой. Не бесполезно, но и не панацея. ## Ожидание третье: «мы делали бэкапы, мы в безопасности» Реальность: я видела проекты, где бэкапы делались каждый день, но проверялись последний раз восемь месяцев назад. Оказалось, что три месяца из этих восьми бэкапы падали с ошибкой, и никто не заметил. Клиент был уверен, что всё хранится, и узнал о проблеме, только когда понадобилось восстановиться. Бэкап — это не процесс, это результат. Если вы не можете руками взять бэкап, развернуть его на тестовом сервере и убедиться, что сайт работает — у вас нет бэкапа. У вас есть файлы, которые, возможно, пригодятся, а возможно, нет. ## Ожидание четвёртое: «обновим CMS, и всё будет ок» Реальность: обновление CMS до последней версии действительно закрывает часть известных уязвимостей. Но в типичном сайте на популярной CMS кроме самого движка стоит ещё пятнадцать-двадцать плагинов, у каждого своя версия, у каждого свои дыры. Я смотрю на такой сайт и вижу не «обновлённый движок», а пятнадцать отдельных точек входа, которые нужно проверить отдельно. Клиент обновил ядро и был спокоен. А я посмотрела на список плагинов, нашла в одном из них уязвимость трёхлетней давности, и оказалось, что через этот плагин можно получить доступ к базе данных. Без обновления этого конкретного плагина вся защита — дырка от бублика. ## Ожидание пятое: «нас маленький сайт, кому мы нужны» Реальность: боты не смотрят на размер сайта. Они перебирают уязвимости массово, им всё равно, интернет-магазин это или сайт-визитка стоматологической клиники. Я видела взломанные сайты парикмахерских, детских центров, автомоек — всего, что только можно придумать. Боту не важно, сколько у вас посетителей, ему важно, есть ли дыра, в которую можно зайти. Это, наверное, самое опасное ожидание, потому что оно приводит к тому, что защиту вообще не делают. «Кому мы нужны» — это как «мне нечего скрывать». Звучит логично, пока не окажется, что через ваш сайт рассылают спам, ваш домен попал в чёрные списки, и почта от вашего домена не доходит до клиентов. ## Что я делаю в начале работы с новым клиентом Я не пугаю, я показываю. Беру его сайт, провожу быстрый аудит по тому самому списку из двенадцати пунктов и присылаю отчёт: вот здесь пароль администратора, вот здесь уязвимый плагин, вот здесь бэкапы падают с марта, вот здесь сертификат установлен, но не настроен правильно. После такого отчёта разговор про безопасность перестаёт быть абстрактным и превращается в конкретный список работ с конкретной стоимостью. Когда заказчик видит не «ваш сайт небезопасный», а «вот в этих пяти местах у вас конкретные дыры, и вот сколько стоит их закрыть» — он начинает принимать решения. Не потому что я его напугала, а потому что напугал результат аудита, который он сам попросил. ## Главное, что я поняла за эти годы Безопасность — это не состояние, это процесс. Сайт, который был безопасным в январе, в июле может быть уже небезопасным, потому что вышла новая версия какого-нибудь плагина, или потому что боты нашли новый способ обхода защиты, или потому что кто-то из сотрудников установил на сервер программу, которую не следовало устанавливать. Заказчики, которые это понимают, делают безопасность частью бюджета на поддержку, а не разовой услугой. Они не платят один раз «за защиту», они платят за то, чтобы кто-то регулярно смотрел, обновлял, проверял, реагировал. Это дороже, но это единственное, что реально работает в 2026 году. Если вы узнали в этом списке свой сайт — это нормально. Главное, что вы это теперь знаете, а не продолжаете думать, что зелёный замочек в адресной строке означает безопасность.