«У нас всё работает, зачем нам аудит безопасности?» — пока однажды не приходит письмо о том, что данные клиентов утекли, а на сайте появился чужой код. Проблема безопасности в том, что она невидима до инцидента: сайт может годами работать с открытыми дырами, и никто не замечает, пока их не найдёт злоумышленник, а не аудитор.
Разберём на обобщённом примере, что типично находит аудит безопасности сайта на 1С-Битрикс: какие критические уязвимости встречаются чаще всего, чем они грозят и как их закрывают штатными средствами платформы. Это не разбор конкретного клиента, а собирательная картина типовых находок. Системную проверку и приведение сайта в порядок закрывает аудит и оптимизация 1С.
Коротко
- Аудит проверяет слои сразу: версию платформы, доступы, защиту, кастомный код, служебные файлы и сервер.
- Самые частые критические дыры — устаревший Битрикс, слабые пароли, отключённая защита и уязвимый код.
- Дыры закрывают по приоритету риска: сначала прямой доступ и утечки, потом средние и низкие угрозы.
- Безопасность — процесс: разовая заплатка без регулярных обновлений и контроля быстро устаревает.
Зачем нужен аудит безопасности
Аудит безопасности — это системная проверка сайта на то, через что его можно скомпрометировать. Не поиск одного бага, а обзор всех слоёв обороны: от версии платформы до прав доступа и собственного кода. Его смысл — найти дыры раньше, чем это сделает злоумышленник.
Для интернет-магазина цена взлома высока: утечка данных клиентов, потеря доверия, простой продаж, внедрение вредоносного кода, который крадёт платёжные данные или перенаправляет клиентов. Причём атаки чаще автоматизированы: боты массово сканируют сайты на известные уязвимости, и жертвой становится не «избранный», а любой уязвимый. Поэтому аудит нужен не только крупным, но и обычным магазинам.
Что проверяет аудит по слоям
Хороший аудит идёт по слоям, потому что безопасность цепочки определяется её слабейшим звеном. Проверяют несколько уровней сразу.
- Платформа и модули. Актуальность версии, установлены ли обновления безопасности.
- Доступы. Учётные записи, пароли, права пользователей и администраторов.
- Защитные механизмы. Проактивная защита, веб-фильтр (WAF), настройки безопасности платформы.
- Кастомный код. Собственные доработки на предмет уязвимостей и небезопасных практик.
- Файлы и сервер. Открытые служебные файлы, резервные копии, настройки веб-сервера и окружения.
Дыра в любом из слоёв может свести на нет все остальные. Поэтому аудит не ограничивается одним уровнем, а смотрит на картину целиком.
Устаревшая версия и отсутствие обновлений
Самая частая и самая опасная находка — устаревшая версия платформы и модулей без установленных обновлений безопасности. Причина проста: обновления часто закрывают известные уязвимости, и как только они выходят, детали становятся публичными.
Это переворачивает ситуацию: необновлённый сайт превращается в лёгкую мишень, потому что злоумышленнику не нужно ничего изобретать — готовый способ атаки уже известен и автоматизирован. Устаревшая версия — не абстрактный риск «на будущее», а открытая дверь прямо сейчас. Регулярная установка обновлений безопасности — базовая гигиена, но именно её нарушают чаще всего, откладывая обновления «чтобы не сломать работающее».
Пароли, доступы и лишние права
Второй пласт частых находок — слабости в доступах. Даже идеально обновлённая платформа беззащитна, если в неё легко войти.
- Слабые пароли. Простые или переиспользованные пароли администраторов подбираются или всплывают в утечках.
- Избыточные права. Пользователи имеют доступ шире необходимого, и компрометация одного бьёт по всему.
- Забытые учётные записи. Аккаунты бывших сотрудников и подрядчиков остаются активными.
- Отсутствие двухфакторной защиты. Вход в админку защищён только паролем.
Принцип наименьших привилегий — каждый имеет ровно те права, что нужны для работы, — простой, но его регулярно нарушают ради удобства. Аудит почти всегда находит лишние доступы и забытые аккаунты, через которые можно войти незаметно.
Отключённая проактивная защита и WAF
Платформа даёт мощные встроенные механизмы обороны — проактивную защиту и веб-фильтр (WAF), которые отсекают типовые атаки: инъекции, подозрительные запросы, попытки обойти авторизацию. Но аудит регулярно обнаруживает, что защита есть только на бумаге.
Типичные варианты: механизмы вообще выключены, либо стоят в мягком режиме и лишь наблюдают, ничего не блокируя, либо настроены так, что мешают работе и их отключили «временно», а потом забыли включить. В результате магазин полагается на защиту, которой фактически нет. Включение и правильная настройка этих механизмов — одна из самых дешёвых и эффективных мер, которую часто просто не довели до конца.
Уязвимости в кастомном коде
Ядро платформы проходит проверки вендора, а вот собственные доработки под конкретный проект пишут разные руки и разного качества — именно в них чаще всего живут уязвимости. Это слой, который автоматический сканер видит хуже всего, а эксплуатируют охотно.
Типичные проблемы кастомного кода: необработанный пользовательский ввод, прямые запросы к базе без экранирования, небезопасная загрузка файлов, доверие к данным из форм и параметров. Платформа даёт безопасные инструменты работы с данными, и когда разработчик их использует, риск минимален. Про современный и безопасный доступ к данным мы писали в статье про D7 и ORM в Битрикс. Если же сайт общается с внешними системами, отдельного внимания требует защита интеграционного слоя — этому посвящён материал про REST, вебхуки и безопасность.
Открытые служебные и резервные файлы
Отдельная категория находок — то, что вообще не должно быть доступно снаружи, но доступно. Часто это следы разработки и обслуживания, о которых забыли.
- Резервные копии. Архивы базы и файлов, лежащие в открытом доступе, — прямая утечка всего сайта.
- Служебные и отладочные файлы. Скрипты диагностики, оставленные после работ, дают лишнюю информацию или доступ.
- Открытые конфигурации. Файлы с настройками и доступами, читаемые снаружи.
- Логи и временные файлы. Раскрывают внутреннее устройство и иногда чувствительные данные.
Ни одна из этих дыр не требует «взлома» — достаточно знать адрес файла. Поэтому наведение порядка в файлах и закрытие лишнего доступа — обязательная часть закрытия уязвимостей.
Как расставляют приоритеты рисков
Аудит обычно находит не одну, а десятки проблем разной опасности. Хвататься за всё сразу неэффективно — риски ранжируют.
| Уровень | Пример | Действие |
|---|---|---|
| Критический | Прямой доступ, утечка данных | Закрыть немедленно |
| Высокий | Устаревшая версия, слабые пароли | В ближайший релиз |
| Средний | Лишние права, мягкий режим WAF | По плану |
| Низкий | Мелкие настройки, гигиена | В рабочем порядке |
Приоритет определяется не сложностью исправления, а величиной ущерба и лёгкостью эксплуатации. Сначала закрывают то, что даёт прямой доступ или утечку и легко эксплуатируется, — даже если чинить это дольше, чем десяток мелочей.
План закрытия дыр по шагам
После аудита важно не просто получить список проблем, а закрыть их по продуманному плану.
- Проверить факт взлома. Убедиться, что сайт ещё не скомпрометирован; если да — сначала лечить последствия.
- Закрыть критическое. Обновить платформу, сменить скомпрометированные пароли, убрать открытые файлы.
- Включить защиту. Активировать и настроить проактивную защиту и WAF в блокирующем режиме.
- Починить код. Устранить уязвимости в доработках через тестовый контур, а не на боевом сайте.
- Навести порядок в доступах. Убрать лишние права, забытые аккаунты, усилить вход.
- Выстроить процесс. Настроить регулярные обновления, мониторинг и ревизию нового кода.
Изменения в защите и коде лучше проводить через нормальный процесс с тестовым контуром — про это статья про CI/CD и деплой в Битрикс. Хаотичные правки на боевом сайте сами по себе источник риска.
Безопасность как процесс, а не разовая заплатка
Главный вывод любого аудита: закрыть найденные дыры — необходимо, но недостаточно. Безопасность — это не состояние, а процесс. Сайт, безопасный сегодня, без поддержки становится уязвимым завтра, потому что новые уязвимости появляются постоянно.
Поэтому после разовой чистки выстраивают регулярные практики: своевременные обновления, мониторинг подозрительной активности, контроль прав доступа, ревизия нового кода перед выкладкой, периодические повторные аудиты. Это дешевле и надёжнее, чем героически спасать взломанный сайт. Разовая заплатка без процесса — временная мера, после которой дыры возвращаются.
Частые ошибки владельцев
- «Работает — значит безопасно». Дыры невидимы до инцидента, работоспособность ничего не говорит о защите.
- Откладывание обновлений. Страх сломать работающее оставляет известные уязвимости открытыми.
- Защита «для галочки». Проактивная защита и WAF включены в мягком режиме и ничего не блокируют.
- Слепая зона кастомного кода. Проверяют настройки, но не собственные доработки, где и живут дыры.
- Забытые доступы и файлы. Аккаунты подрядчиков и резервные копии остаются открытыми.
- Разовый аудит. Проверились один раз и успокоились, без регулярного процесса.
Чек-лист базовой защиты
- Платформа обновлена. Установлены актуальные обновления безопасности платформы и модулей.
- Доступы под контролем. Сильные пароли, наименьшие привилегии, нет забытых аккаунтов, усилен вход.
- Защита включена. Проактивная защита и WAF работают в блокирующем, а не наблюдательном режиме.
- Код проверен. Кастомные доработки прошли ревизию на уязвимости и используют безопасные инструменты.
- Файлы закрыты. Нет открытых резервных копий, служебных и отладочных файлов, конфигураций.
- Процесс налажен. Регулярные обновления, мониторинг, ревизия кода, повторные аудиты.
- Есть план на инцидент. Понятно, что делать при взломе: бэкапы, восстановление, оповещение.
Вывод
Аудит безопасности почти всегда находит критические дыры, и они удивительно однообразны: устаревшая платформа без обновлений, слабые пароли и лишние права, отключённая защита, уязвимый кастомный код, открытые служебные файлы. Ни одна из этих проблем не экзотична — именно поэтому их так часто и эксплуатируют автоматизированные атаки.
Хорошая новость в том, что закрываются они штатными средствами платформы и разумной дисциплиной. Закройте критическое по приоритету риска, включите встроенную защиту, наведите порядок в доступах и коде — и, главное, превратите безопасность в регулярный процесс. Дыры невидимы до инцидента, поэтому дешевле искать их аудитом, чем узнавать о них от злоумышленника.
