Назад в блог
Практика

Роли, права и аудит: как держать admin-доступ под контролем

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

Роли, права и аудит: как держать admin-доступ под контролем

Флаг доступа — это только начало

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

Поэтому доступ в панели был собран в несколько ясных уровней: допуск в саму админку, роли и конкретные права на модули. Это не попытка построить универсальный IAM-сервис внутри портфолио, а минимальная модель, которую реально поддерживать.

Роль описывает набор возможностей

В Filament появилась отдельная сущность роли с понятным названием, описанием и набором разрешений. Пользователю можно назначить несколько ролей, а итоговый доступ вычисляется из их объединения. Системная роль администратора сохраняет полный набор прав и защищена от случайного удаления.

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

Гранулярность без списка из сотни флажков

Вместо отдельного разрешения на каждую кнопку права сгруппированы по реальным зонам ответственности: пользователи, роли, контент, задачи, отчёты, интеграции и системные функции. Такой список проще читать в форме роли и проще проверять в коде. Когда появляется новый модуль, ему явно назначается своё правило, а не достаётся случайное наследование от соседней страницы.

Изменения доступа оставляют след

Для ролей и назначения ролей пользователю добавлен журнал аудита. В нём видно, кто изменил доступ, какую роль затронуло действие и когда это произошло. События создания, изменения и удаления роли, а также смены ролей пользователя сохраняют состояние до и после изменения.

Журнал сделан read-only: его нельзя создать, поправить или удалить из интерфейса. Это не заменяет внешнее централизованное логирование для большой инфраструктуры, но для прикладной админки даёт важный ответ на практический вопрос: почему у человека изменился доступ.

Практический результат

Админ-панель перестала опираться на один глобальный флаг. Доступ теперь описывается ролями и проверяется на уровне конкретных разделов, а критичные изменения остаются в журнале. В итоге расширять панель безопаснее: новый модуль получает явное разрешение, а не неявный доступ всех, кто однажды оказался администратором.