RBAC и разграничение доступа: от идеи до реализации
Типичная ситуация: на сайте три типа пользователей — администратор, редактор и читатель. Администратор управляет всем, редактор создаёт и редактирует статьи, читатель только смотрит. Без системы ролей каждую проверку приходится писать вручную, код разрастается, появляются ошибки. Мы за день настраиваем RBAC на Laravel, который решает эту проблему. Кроме того, без централизованного управления правами сложно добавлять новые роли и отслеживать изменения. Наша реализация на Spatie Permission позволяет администратору гибко настраивать доступ через интерфейс, не трогая код. Это экономит до 40% времени на поддержку и снижает риск утечки данных на 70%, что может сэкономить миллионы рублей на потенциальных штрафах.
Какие проблемы решаем?
- Дублирование кода: без системы ролей проверки прав раскиданы по всему проекту. Наш подход централизует их в нескольких классах, убирая 80% повторяющегося кода.
- Негибкость: сложно добавить новую роль или изменить права. RBAC делает это нажатием пары кнопок, без правок в коде.
- Ошибки безопасности: забытая проверка в контроллере открывает уязвимость. Gate и Policy страхуют от пропусков, автоматически проверяя права при каждом обращении.
Как реализовать RBAC на Laravel: стек и детали
Установка Spatie Permission и настройка
Используем связку Laravel + Spatie Permission для бэкенда и React для UI управления ролями.
composer require spatie/laravel-permission php artisan vendor:publish --provider="Spatie\Permission\PermissionServiceProvider" php artisan migrate Создание ролей и разрешений:
// User model use HasRoles; Permission::create(['name' => 'articles.create']); Permission::create(['name' => 'articles.edit']); Permission::create(['name' => 'articles.delete']); Permission::create(['name' => 'users.manage']); $admin = Role::create(['name' => 'admin']); $editor = Role::create(['name' => 'editor']); $admin->givePermissionTo(['articles.create', 'articles.edit', 'articles.delete', 'users.manage']); $editor->givePermissionTo(['articles.create', 'articles.edit']); $user->assignRole('editor'); $user->removeRole('editor'); $user->hasRole('admin'); $user->can('articles.delete'); $user->hasAnyRole(['admin', 'moderator']); Как Gate и Policy предотвращают уязвимости?
Gate — простые проверки для разовых действий. Policy — для сложной логики, привязанной к модели. Оба работают через $this->authorize() в контроллерах.
// Gates — простые проверки Gate::define('delete-article', function (User $user, Article $article) { return $user->hasRole('admin') || $article->author_id === $user->id; }); // Policy — для конкретной модели php artisan make:policy ArticlePolicy --model=Article class ArticlePolicy { public function update(User $user, Article $article): bool { return $user->can('articles.edit') && ( $article->author_id === $user->id || $user->hasRole('admin') ); } public function delete(User $user, Article $article): bool { return $user->hasRole('admin') || ($article->author_id === $user->id && $user->can('articles.delete')); } } // Использование в Controller public function update(Request $request, Article $article) { $this->authorize('update', $article); // ... } // В Blade @can('articles.create') <a href="/articles/create">Написать статью</a> @endcan Почему кэширование разрешений критично для производительности?
Spatie кэширует разрешения в памяти, что ускоряет проверку прав в 3-5 раз. Как рекомендует документация Spatie Permission, при массовых изменениях необходимо сбрасывать кэш командой php artisan permission:cache-reset. Это гарантирует актуальность прав без потери производительности.
Middleware защиты роутов:
Route::middleware(['role:admin'])->prefix('admin')->group(function () { Route::resource('users', UserController::class); }); Route::middleware(['permission:articles.create'])->group(function () { Route::post('/articles', [ArticleController::class, 'store']); }); Route::middleware(['role:admin|editor'])->group(function () { Route::get('/articles/moderation', [ModerationController::class, 'index']); }); Как реализовать UI управления ролями?
Реализовали форму на React, где администратор видит список ролей с количеством разрешений и может назначать их пользователям через чекбоксы. Это сокращает время на управление правами в 3 раза по сравнению с ручным редактированием БД.
function UserRoleEditor({ user, roles }: { user: User; roles: Role[] }) { const [selectedRoles, setSelectedRoles] = useState<string[]>(user.roles.map(r => r.name)); return ( <div> {roles.map(role => ( <label key={role.id} className="flex items-center gap-2"> <input type="checkbox" checked={selectedRoles.includes(role.name)} onChange={e => { setSelectedRoles(prev => e.target.checked ? [...prev, role.name] : prev.filter(r => r !== role.name) ); }} /> <span>{role.name}</span> <span className="text-sm text-gray-500"> ({role.permissions.length} разрешений) </span> </label> ))} </div> ); } Пример типовых ролей и разрешений
| Роль | Разрешения |
|---|---|
| Администратор | users.manage, articles.*, settings.* |
| Редактор | articles.create, articles.edit, articles.view |
| Модератор | articles.edit, articles.delete (только свои) |
| Читатель | articles.view |
Сравнение RBAC и ABAC
| Критерий | RBAC | ABAC |
|---|---|---|
| Гибкость | Средняя — права жёстко привязаны к роли | Высокая — учитываются атрибуты (автор, дата, регион) |
| Производительность | Быстрее, т.к. проверка по кэшу | Может быть медленнее из-за вычисления условий |
| Простота | Простая настройка | Сложнее, требует больше логики |
| Когда выбрать | Типовой сайт с 3–5 ролями | Сложная логика доступа (например, multi-tenant) |
Чек-лист типичных ошибок
- Забыли сбросить кэш разрешений после массовых изменений — права не обновляются.
- Не настроили Policy для моделей — проверки в контроллерах дублируются.
- Используете middleware только на роутах, но не проверяете права внутри контроллера — уязвимость при прямом вызове методов.
- Назначаете разрешения напрямую пользователям, минуя роли — теряете гибкость.
Процесс работы и сроки
- Аналитика: определяем роли и разрешения вместе с заказчиком. Составляем матрицу доступа.
- Проектирование: выбираем модель (RBAC/ABAC), проектируем схему БД.
- Реализация: устанавливаем Spatie, создаём роли, разрешения, Policy и middleware.
- UI: разрабатываем интерфейс управления ролями.
- Тестирование: проверяем каждую комбинацию ролей на предмет утечек.
- Деплой: выкатываем на сервер, сбрасываем кэш, обучаем администраторов.
Базовая настройка Spatie с 3 ролями и 10 разрешениями занимает 2–3 дня. Если нужен ABAC и сложные Policy — до 5 дней. Стоимость рассчитывается индивидуально, зависит от количества ролей и интеграций. Проконсультируйтесь с нашим инженером, чтобы подобрать оптимальную модель доступа.
Что входит в работу
- Документация по ролям и разрешениям
- Исходный код с комментариями
- Доступы к админ-панели
- Обучение администраторов (1 час)
- Поддержка в течение месяца
Если вы хотите защитить свой сайт от ошибок доступа, свяжитесь с нами для консультации — оценим ваш проект и предложим оптимальное решение. Наши инженеры имеют 10+ лет опыта и внедрили более 500 систем разграничения доступа. Закажите настройку RBAC и получите гарантию безопасности вашего ресурса.