После смены подрядчика на сайте могут остаться его учетная запись, доступ к хостингу и ключи внешних сервисов. Пока все работает, о них легко забыть. Плановый аудит Joomla помогает собрать такие точки доступа вместе с версиями расширений и резервными копиями в понятный список действий.
Плановая проверка безопасности Joomla до инцидента
Здесь исходная ситуация — действующий сайт без признаков взлома. Задача проверки: найти известные уязвимости Joomla, лишние полномочия и пробелы обслуживания до того, как ими воспользуются.
До начала работ согласуют состав проверки и допустимые действия. Обновление, удаление расширения и смена ключей — отдельные исправления: аудит сам по себе не означает разрешение немедленно менять рабочий сайт. Если обнаружены неизвестные администраторы, посторонние файлы или перенаправления, это основание отдельно исследовать возможный инцидент.
Версии ядра, расширений и окружения
Инвентаризация должна охватывать ядро, компоненты, модули, плагины и шаблоны. Для каждого стороннего продукта записывают точную версию, разработчика, источник обновлений, назначение и наличие действующей поддержки. Для PHP, СУБД и веб-сервера — версии и ответственного за обновления.
Версию ядра сопоставляют с затронутыми и исправленными выпусками в официальных уведомлениях Joomla. Вывод «есть дыра» должен опираться на конкретное уведомление и установленную версию, а не на возраст сайта.
Для расширений проверяют Vulnerable Extensions List и сообщения разработчиков. Сам VEL предупреждает о возможной неполноте: отсутствие продукта в списке не доказывает его безопасность. Скрытый модуль тоже нельзя автоматически исключать из проверки: руководство Joomla поясняет, что снятие с публикации не удаляет доступные на сервере файлы расширения.
Кто может войти и от чьего имени
По каждой учетной записи с административным доступом выясняют владельца и текущую задачу. Неизвестные или общие логины заносят в отчет, для бывших исполнителей планируют отзыв доступа. До блокировки проверяют, что у владельца сайта остается рабочий способ управления и восстановления входа.
Внешние доступы собирают отдельно: панель хостинга, SFTP/SSH, база данных, регистратор домена, DNS, почта для восстановления, хранилище копий и ключи интеграций. Удаление пользователя Joomla не является проверкой этого перечня. При смене общего пароля или ключа сначала выясняют, какие процессы им пользуются, чтобы не остановить обмен или отправку писем.
Для актуальных версий Joomla проверяют настройку многофакторной аутентификации у администраторов и сохранность резервного способа входа. Справка Joomla описывает дополнительные методы и одноразовые резервные коды. Для старой ветки доступность средств уточняют отдельно.
Права и изоляция: границы возможного ущерба
Редактору материалов не обязательно иметь полномочия управления всем сайтом. Проверяют фактические разрешения групп и отдельных компонентов: в Joomla они могут наследоваться и переопределяться на разных уровнях, что описано в документации ACL.
На сервере исследуют владельцев файлов, разрешения на запись, доступность архивов и дампов из интернета. Отдельный вопрос хостеру — может ли соседний сайт в той же учетной записи читать или менять файлы Joomla. Для тестовой копии тоже проверяют доступ и подключения к сервисам.
Не стоит применять ко всему сайту универсальный набор числовых прав. Памятка Joomla по серверу связывает права с режимом работы PHP; это архивная документация, поэтому конкретные значения нужно сверять с устройством текущего хостинга. Итог проверки — перечень лишних возможностей и способ их убрать без нарушения работы.
Копии и уведомления, которым можно доверять
Свежая дата архива не подтверждает возможность восстановления. Проверяют, входят ли в копию файлы и база данных, доступны ли они владельцу и сколько изменений потеряется при откате. Эти две части сайта и необходимость проверки восстановленного экземпляра разобраны в руководстве Joomla по резервированию.
Пригодность копии подтверждают пробным восстановлением в изолированной среде. Там проверяют вход, основные страницы и функции, не допуская отправки реальных заказов, писем или данных во внешние системы. Дополнительно выясняют, сохранится ли доступ к копии при потере основной учетной записи хостинга.
В отчете фиксируют, кому приходят уведомления об ошибке резервирования и доступных обновлениях, кто их просматривает и за какой срок реагирует. Полезна контрольная проверка доставки предусмотренного системой уведомления: адрес бывшего подрядчика в настройках не обеспечивает обслуживание.
От находок к очереди исправлений
Полезный отчет связывает наблюдение с действием. Например: «У бывшего исполнителя есть административный доступ; текущих задач нет; проверить резервный вход владельца и отозвать доступ; ответственный — администратор; приемка — вход этой учетной записью недоступен». Пароли и ключи в отчет не включают.
Для каждой находки нужны подтверждение, приоритет, ответственный, срок и способ проверки. Отдельно отмечают неизвестное: если нет доступа к настройкам изоляции, это непроверенная область, а не отметка «безопасно». Исправления с влиянием на сайт планируют с копией, проверкой совместимости и возможностью отката.
Аудит не дает гарантии абсолютной защиты. Результат — очередь работ и ответственный за контроль. Такие задачи можно включить в поддержку и сопровождение сайта.
Пришлите версию Joomla и сведения о текущем обслуживании — определим состав аудита безопасности.