Безопасность корпоративного сайта: чек-лист для IT-директора компании

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор компании АйТи Фреш. Практически у каждого из наших клиентов – а это, как правило, фирмы с офисами от 10 до 50 рабочих мест в Москве – обязательно есть свой сайт. И что интересно, именно сайты, а вовсе не серверы 1С, становятся главной причиной для тревожных звонков с криками «у нас всё сломалось!». Поэтому я подготовил этот практический чек-лист по безопасности корпоративного сайта. Он адресован IT-директору, чтобы вы точно знали, что ваш подрядчик или штатный сисадмин делает правильно, а где, возможно, что-то упускает.

Почему корпоративный сайт — самая частая точка взлома

За свои 15 лет работы я не раз с удивлением анализировал статистику инцидентов у наших клиентов. Вы только представьте: серверы 1С взламывают редко, с NAS такое почти никогда не случается, а вот сайты – постоянно! И на это есть три причины:

• Сайт всегда смотрит в интернет. Его круглосуточно сканируют автоматические боты на наличие известных уязвимостей. Сервер 1С обычно за NAT, его не достать без VPN.
• Сайт сделан подрядчиками год-два-пять назад, на CMS, которая с тех пор не обновлялась. Каждый месяц в WordPress, Битрикс и Joomla находят новые уязвимости, и каждый месяц на необновлённых сайтах их эксплуатируют.
• Сайт никто не считает критичным сервисом. «Ну работает и работает» — пока не упадёт перед тендером, или пока на главной не появится баннер казино.

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

Случай из практики: сайт «забыли», и он попал в чёрные списки

Вспомните случай с одной транспортной компанией в Хамовниках. Мы обслуживаем их инфраструктуру уже два года. В декабре 2025-го раздаётся звонок от директора: «Нам не дают отправлять коммерческие предложения с корпоративной почты, говорят, наш домен попал в чёрные списки!». Мы сразу стали разбираться. Оказалось, почта info@trans-pro.ru вроде бы уходит, но 80% получателей либо помечают её как спам, либо их почтовый сервер вообще отбивает её на входе.

И вот мы полезли выяснять, в чём же дело. У этой компании мы отвечаем только за офисную инфраструктуру. А сайт trans-pro.ru им делала какая-то веб-студия ещё в 2019 году, разместила на хостинге, и с тех пор туда никто даже не заглядывал. Я открыл сайт, а на главной странице выскакивает окошко «Установите расширение для просмотра» — ну чисто вредоносное ПО! Зашёл по FTP в админку (пароль, к счастью, директор дал сразу), а в корневой папке – больше 30 PHP-файлов с подозрительными именами вроде wp-stat.php, backup.php, ssp.php. Все они оказались веб-шеллами, причём от разных авторов.

Что же я увидел дальше, когда полез в логи доступа хостинга? С июля 2025 года сайт ежедневно отправлял десятки тысяч HTTP-запросов на mail-серверы Mail.ru, Яндекс, Google. Это были автоматические рассылки фишинга, замаскированные «от имени» нашего клиента. К декабрю репутация домена была полностью уничтожена, и, конечно, письма с офисной почты автоматически летели в спам.

Мы зачистили сайт буквально за день, перенесли его на защищённый хостинг с регулярными обновлениями, восстановили все важные настройки – DKIM/SPF/DMARC. Затем подали в Mail.ru и Яндекс заявки на пересмотр репутации. И вот, через 3 недели почта снова заработала как надо. Компании эта история стоила 2 месяцев просадки в продажах и 65 000 руб. на восстановительные работы. А база клиентов, что самое удивительное, не пострадала только чудом.

Чек-лист №1: HTTPS и сертификат

Казалось бы, это самое элементарное, но, к моему удивлению, до сих пор не у всех настроено. Проверить это можно за каких-то 30 секунд: просто вбейте адрес сайта в ssllabs.com/ssltest и посмотрите на оценку.

Я регулярно сталкиваюсь с просроченными сертификатами на корпоративных сайтах. Это всегда случается внезапно, всегда в самый неудачный момент и, конечно, всегда под гневные крики директора. А ведь решается это раз и навсегда простой настройкой автообновления через certbot:

# На сервере с nginx
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d trans-pro.ru -d www.trans-pro.ru

# Автообновление уже встроено в systemd-таймер,
# проверим что работает:
sudo systemctl status certbot.timer

Чек-лист №2: заголовки безопасности

Это вторая линия защиты, которая работает на стороне браузера посетителя. Даже если ваш сайт уже взломан и в код внедрён вредоносный JavaScript, правильные заголовки не дадут ему сработать. Проверить можно на securityheaders.com.

# Минимально необходимые заголовки в nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; \
    script-src 'self' 'unsafe-inline' https://mc.yandex.ru; \
    style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; \
    font-src 'self' https://fonts.gstatic.com" always;

Что именно делает каждый заголовок:

• HSTS — браузер запоминает, что на этот сайт можно ходить только по HTTPS, и не даст случайно открыть HTTP-версию.
• X-Frame-Options — запрещает встраивать сайт в iframe на чужих ресурсах. Защита от clickjacking, когда мошенники накладывают невидимый сайт поверх своего и ваши клики уходят им.
• X-Content-Type-Options — браузер не будет «угадывать» тип файла, что мешает атакам через подмену типа.
• Content Security Policy (CSP) — самый мощный заголовок, перечисляет источники, с которых разрешено грузить скрипты и стили. Чужой скрипт, внедрённый через уязвимость, браузер просто проигнорирует.

Чек-лист №3: обновления CMS и плагинов

Знаете, что является самым больным местом, если ваш сайт сделан на WordPress, Битриксе или Joomla? По данным Sucuri за 2025 год, 96% взломов сайтов на WordPress происходят из-за устаревших плагинов с уже известными уязвимостями. То есть это не какие-то хитрые целевые атаки, а просто злоумышленник просканировал интернет на наличие конкретной дыры и прошёлся по списку найденных сайтов.

Что должно быть настроено:

• WordPress: автообновление core (по умолчанию включено), автообновление плагинов и тем (включается в админке или через wp-cli);
• Битрикс: подписка на обновления, регулярное применение патчей (раз в 2-4 недели), запуск проактивной защиты в максимальном режиме;
• Удаление неиспользуемых плагинов: каждый отключённый, но установленный плагин — потенциальная дыра. Не отключайте — удаляйте.
• Регулярный аудит уязвимостей: для WordPress есть бесплатный WPScan (wpscan --url ваш-сайт), он показывает список устаревших компонентов с известными CVE.

У нас в АйТи Фреш для каждого клиентского сайта действует чёткий еженедельный регламент: в понедельник утром инженер заходит в админку, проверяет все обновления, устанавливает их и обязательно тестирует ключевые сценарии – это главная страница, форма обратной связи, корзина, если есть e-commerce. На каждый сайт уходит всего 15-20 минут, но это экономит десятки тысяч рублей на возможном восстановлении.

Чек-лист №4: разделение сайта и внутренней инфраструктуры

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

Если ваш сайт сейчас делит сервер с 1С, паниковать не стоит, но разносить их нужно срочно. У наших клиентов мы делаем это так: арендуем отдельный VPS, переносим туда сайт, обновляем DNS, всё тестируем, а через неделю уже удаляем сайт со старого места. Это занимает 6-12 часов работы инженера плюс примерно 3000 руб. в месяц за VPS – сущие копейки на фоне колоссальных рисков совмещённого размещения.

Чек-лист №5: бэкапы сайта (и тестирование восстановления)

Ох уж эти бэкапы! Они, конечно, должны быть, и что самое важное, они должны проверяться. В моей практике несколько раз повторялась одна и та же ситуация: сайт взломан, а клиент спокоен – «у нас же бэкап делается каждый день!». Лезем в бэкап – а там либо нулевые файлы, либо последний рабочий бэкап аж от 2022 года, либо бэкапы вроде бы и делаются, но их никто ни разу не пробовал развернуть, и при восстановлении вдруг выясняется, что не хватает базы.

Минимальный регламент бэкапов корпоративного сайта:

• Файлы сайта: ежедневный полный бэкап, хранение 14 дней. Можно через rsync на отдельный сервер, можно встроенным инструментом хостинга.
• База данных: ежедневный дамп mysqldump или pg_dump, тоже 14 дней хранения.
• Хранение в двух местах: один бэкап на сервере или хостинге, второй — копией в облако (Yandex Object Storage, Cloud.ru) или в офис на NAS.
• Тестовое восстановление раз в квартал: разворачиваем сайт из бэкапа в тестовом окружении, проверяем работу. Это единственный способ убедиться, что бэкап реально рабочий.

# Простой bash-скрипт ежедневного бэкапа сайта на WordPress
#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/var/backups/site"
SITE_DIR="/var/www/trans-pro.ru"
DB_NAME="wp_transpro"

# Архив файлов
tar -czf "$BACKUP_DIR/files_$DATE.tar.gz" -C "$SITE_DIR" .

# Дамп базы
mysqldump --single-transaction "$DB_NAME" | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Копия в облако
rclone copy "$BACKUP_DIR/files_$DATE.tar.gz" yandex:itfresh-backups/transpro/
rclone copy "$BACKUP_DIR/db_$DATE.sql.gz" yandex:itfresh-backups/transpro/

# Удаление бэкапов старше 14 дней
find "$BACKUP_DIR" -name "*.gz" -mtime +14 -delete

Чек-лист №6: защита от ботов и DDoS

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

Базовая защита, которая срабатывает в 95% случаев:

• Cloudflare в режиме «under attack» при инциденте — снимает 99% ботов. Бесплатный тариф полностью покрывает потребности корпоративного сайта.
• fail2ban на сервере с правилами для nginx и WordPress: после 5 неудачных входов в админку — блокировка на час;
• Rate limiting в nginx: ограничение количества запросов с одного IP в секунду;
• Закрытие админки по IP: вход в /wp-admin/ или /bitrix/admin/ только с IP офиса и VPN, всем остальным — 403.

# Закрытие админки по IP в nginx
location ~ ^/wp-admin/ {
    allow 213.227.x.x;     # IP офиса
    allow 188.130.x.x;     # IP VPN АйТи Фреш
    deny all;

    try_files $uri $uri/ /index.php?$args;
}

Что мы в АйТи Фреш делаем для безопасности сайтов клиентов

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

• Еженедельная проверка обновлений CMS, плагинов, тем — применение в течение 24 часов после выхода;
• Ежедневный бэкап файлов и БД с дублированием в облако;
• Тестовое восстановление раз в квартал в изолированной среде;
• Мониторинг доступности сайта (Uptime Robot или аналог) с алертом инженеру в Telegram при падении более 1 минуты;
• Ежемесячный аудит безопасности через WPScan, ручная проверка логов на аномалии;
• SSL-сертификаты с автообновлением, контроль сроков;
• Реакция на инциденты (взлом, дефейс, попадание в чёрные списки) — в первый рабочий день, как правило, в течение 2-4 часов.

Кстати, про стоимость: в составе абонентки на офисную инфраструктуру всё это идёт без дополнительной платы для одного-двух сайтов клиента. А если у компании 5+ сайтов или сложный e-commerce-проект, то у нас предусмотрен отдельный тариф от 8 000 руб./мес за сайт.

FAQ — частые вопросы по безопасности корпоративных сайтов

Нужен ли HTTPS на корпоративном сайте, если он не принимает оплату?

Да, обязательно. Во-первых, Google и Яндекс с 2019 года понижают сайты без HTTPS в выдаче. Во-вторых, без HTTPS любой провайдер или Wi-Fi точка может вставлять рекламу в ваш контент. В-третьих, форма обратной связи без HTTPS — это утечка персональных данных, штраф по 152-ФЗ от 60 000 руб.

Можно ли разместить корпоративный сайт на том же сервере, что и 1С?

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

Что такое CSP-заголовок и зачем он нужен?

Content Security Policy — заголовок, в котором сайт говорит браузеру, с каких доменов разрешено грузить скрипты, стили, картинки. Если злоумышленник внедрит на ваш сайт чужой скрипт-перехватчик форм, браузер просто откажется его выполнять. Это вторая линия защиты, которая работает даже если сайт уже взломали.

Как часто надо обновлять CMS и плагины?

WordPress, его плагины и темы — минимум раз в месяц, желательно раз в неделю. Битрикс — по мере выхода обновлений безопасности (раз в 2-4 недели). 90% взломов через CMS происходят из-за необновлённых плагинов с известными уязвимостями. Это самая частая причина дефейса корпоративных сайтов.

Сколько стоит обслуживание корпоративного сайта в АйТи Фреш?

Базовое сопровождение сайта на WordPress или Битрикс — от 8 000 руб./мес: обновления, мониторинг доступности, бэкапы, реакция на инциденты. В рамках абонентки на офисную инфраструктуру — без доплат. Восстановление взломанного сайта — от 18 000 руб.