Безопасность в IT — как страховка. Пока ничего не происходит, кажется, что можно жить спокойно и не тратить время. Но как только случается атака, всё внимание переключается туда, и гайки начинают закручивать даже там, где это мешает бизнесу.

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

Я знаю, о чём говорю: по диплому у меня «комплексная защита объектов информатизации», и за годы в веб-разработке мы видели всё — от ежедневных DDoS по 2 терабайта трафика до заражённых модулей и майнеров, внедрённых через пакеты.

Что реально ломают

Чаще всего достаётся CMS: в Битриксе это модули и готовые решения, которые не обновляются вовремя; в WordPress ситуация ещё хуже. Laravel-проекты тоже не застрахованы: последние пару лет участились случаи заражения через сторонние пакеты, особенно бесплатные.

Что работает против уязвимостей

• Регулярные обновления ядра и модулей, плюс актуальная версия PHP (сейчас минимум 8.2).\
• Использование штатных инструментов: проактивный фильтр, защита админки по IP, одноразовый вход, настройка безопасных паролей.
• Ограничение доступа к серверу: FTP, SSH, база — только по IP.
• Периодическое сканирование на уязвимости: встроенный модуль безопасности в Битрикс + AI-Bolit.
• Мониторинг серверов и кода: чем раньше обнаружен вирус, тем проще вычистить.

Бэкапы — наше всё

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

ТруСтори

К нам однажды вернулся клиент, с которым мы уже не работали год. Новый подрядчик не смог вычистить вирусы. Спас только бэкап: откатились на момент до атаки, обновили систему — и всё заработало. Если бы не копия, проект мог бы умереть.

Где перегибают

Иногда в погоне за безопасностью «закручивают гайки» так, что разработчики не могут работать, а бизнес теряет скорость. Баланс важен: защита должна быть системной, но не мешать развитию.

40 рекомендаций для условно безопасной веб-системы

1. Обновите ядро и все модули/пакеты до последних версий.

2. Используйте актуальную версию PHP (8.2+).

3. Удалите неиспользуемые модули и пакеты.

4. Проверяйте зависимости на уязвимости (composer audit, встроенные сканеры).

5. Включите WAF/проактивный фильтр.

6. Ограничьте доступ к админке и API по IP.

7. Включите двухфакторную авторизацию для админов.

8. Используйте только сложные пароли, настройте их регулярную смену.

9. Запретите доступ к FTP/SSH/БД извне, кроме доверенных IP.

10. Закройте публичный доступ к .env, конфигам, логам.

11. Отключите показ ошибок на продакшене.

12. Настройте права на файлы и каталоги (минимально необходимые).

13. Используйте HTTPS везде.

14. Настройте корректные заголовки безопасности (CSP, HSTS, X-Frame-Options).

15. Защитите формы CSRF-токенами.

16. Ограничьте CORS только доверенными доменами.

17. Сканируйте проект встроенными и внешними сканерами (AI-Bolit, OWASP ZAP).

18. Подключите мониторинг логов авторизаций, ошибок и изменений файлов.

19. Настройте уведомления о подозрительных активностях.

20. Проверяйте целостность файлов ядра/фреймворка.

21. Раз в полгода проводите внешний аудит безопасности.

22. Храните секреты и ключи только в переменных окружения, не в коде.

23. Проверьте APP_KEY (Laravel) или аналоги — он должен быть надёжным.

24. Используйте очереди/джобы для тяжёлых процессов.

25. Минимизируйте количество администраторов с полными правами.

26. Разграничьте права доступа для редакторов, маркетологов и разработчиков.

27. Отключите или ограничьте системные консольные команды на продакшене.

28. Настройте регулярные бэкапы БД и файлов.

29. Храните бэкапы на отдельном сервере/в облаке.

30. Проверяйте возможность восстановления из бэкапов.

31. Храните несколько версий бэкапов за последние 1–2 месяца.

32. Используйте Fail2Ban или аналог для защиты от брутфорса.

33. Настройте Firewall (сетевой и на уровне веб-сервера).

34. Ограничьте доступ к /storage, /bootstrap, /bitrix/admin и другим критичным директориям.

35. Удалите или закройте от доступа тестовые и dev-сервера.

36. Включите автоматическое обновление ОС и критичных пакетов.

37. Используйте CDN/DDoS-защиту (Cloudflare, DDoS-Guard).

38. Подключите систему централизованного логирования (ELK, Sentry, Zabbix).

39. Регулярно проверяйте базу CVE на уязвимости используемых решений.

40. Делайте пентест/нагрузочное тестирование хотя бы раз в год.

 

Вывод

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

Поэтому если у вас до сих пор живёт старый «БУС», проекты на ранних версиях Laravel или давно не обновлявшийся Битрикс24 — сейчас тот самый момент, когда стоит обновить. Если вы ждали сигнала, то вот он.