Со временем на любом проекте накапливаются учётные записи с избыточными правами — уволенный сотрудник с активным доступом, разработчик, получивший временный административный доступ для конкретной задачи и так и не лишённый его после завершения. Разберём, как провести аудит прав доступа на сайте 1С-Битрикс.
Инвентаризация учётных записей с административными правами
<?php
use Bitrix\Main\UserTable;
$admins = UserTable::getList([
'select' => ['ID', 'LOGIN', 'EMAIL', 'LAST_LOGIN', 'ACTIVE'],
'filter' => ['GROUPS_ID' => 1], // группа администраторов
])->fetchAll();
foreach ($admins as $admin) {
echo $admin['LOGIN'] . ' — последний вход: ' . $admin['LAST_LOGIN'] . PHP_EOL;
}Первый шаг аудита — полный список учётных записей с правами администратора и датой последнего входа. Учётная запись с административным доступом, не заходившая на сайт много месяцев, — явный кандидат на деактивацию или, как минимум, на уточнение, почему она до сих пор активна и нужен ли ей такой уровень доступа.
Проверка прав доступа групп на модули и разделы
Раздел Настройки → Пользователи → Группы пользователей показывает права каждой группы на модули системы — стоит регулярно проверять, что права соответствуют реальным должностным обязанностям, а не остались расширенными с момента, когда конкретному сотруднику временно требовался более широкий доступ для разовой задачи.
Нужна помощь с Битрикс?
Принцип минимальных необходимых привилегий
Практика предоставления доступа "с запасом на будущее" — распространённая, но рискованная привычка: сотруднику, которому нужен доступ только к разделу заказов, не стоит давать полный административный доступ ко всем модулям просто потому, что "может пригодится позже". Права стоит расширять по факту реальной необходимости, а не выдавать заранее максимально широкий набор ради удобства избежать повторной настройки в будущем.
Аудит доступа к FTP и SSH сервера
Аудит прав не должен ограничиваться только уровнем административной панели Битрикса — доступ к серверу через FTP или SSH (для тех, у кого он есть) заслуживает такой же регулярной проверки, поскольку прямой доступ к файловой системе сервера — более мощный и потенциально опасный уровень привилегий, чем административная панель CMS с её ограничениями через права модулей.
Своевременная деактивация при увольнении
Отдельного процесса заслуживает деактивация всех связанных учётных записей (сайт, сервер, почта, сторонние сервисы) сразу при увольнении или завершении сотрудничества с внешним разработчиком — задержка между фактическим уходом человека из команды и отзывом его доступов создаёт окно уязвимости, особенно если увольнение было конфликтным.
Журнал прав как часть общего аудита безопасности
Регулярный аудит прав доступа стоит проводить не разово, а по расписанию — например, ежеквартально, — и документировать результат: кто имеет какой доступ и почему, чтобы при следующей проверке было легче отследить, что изменилось с прошлого раза, а не начинать анализ с нуля каждый раз без опоры на предыдущие результаты.
Двухфакторная аутентификация как обязательное требование
Для всех учётных записей с административными правами двухфакторная аутентификация должна быть обязательным, а не опциональным требованием — аудит прав доступа логично сочетать с проверкой, что 2FA реально включена для каждой такой учётной записи, а не оставлена на усмотрение конкретного пользователя, который мог не настроить её из соображений удобства.
Частые ошибки
- Аудит проводится разово и больше не повторяется. Проблема избыточных прав накапливается заново со временем.
- Проверяются только права в самой Битрикс, но не доступ к серверу. Часть реальных привилегий остаётся вне поля зрения аудита.
- Доступ уволенного сотрудника не отзывается сразу. Окно уязвимости между фактическим уходом и деактивацией учётных записей.
Итог
Регулярный аудит прав доступа — инвентаризация административных учётных записей, проверка соответствия прав реальным обязанностям, своевременная деактивация при увольнении и обязательная двухфакторная аутентификация для всех административных доступов. Аудит должен охватывать не только права внутри самой Битрикс, но и доступ к серверу через FTP/SSH, поскольку это более мощный уровень привилегий, часто упускаемый при проверке только административной панели CMS.