Отметим: когда ваше мобильное приложение перерастает простое администрирование, система прав доступа становится узким местом. Финансовое приложение с 50+ экранами, где бухгалтеры, менеджеры, аудиторы и внешние ревизоры имеют разные уровни доступа — разбросанные по коду проверки вроде if role == "admin" приводят к хаосу. Мы видели проекты, где permission-логика была раскидана по 30 view-контроллерам, а смена роли требовала полного регресса. Решение — централизованная система с продуманной моделью.
Модели управления доступом: какую выбрать?
Выбор модели — первое архитектурное решение. Вот сравнение основных подходов:
| Модель | Принцип | Когда подходит | Сложность реализации |
|---|---|---|---|
| RBAC | Роль → набор разрешений | Корпоративные приложения с чёткими должностными ролями | Низкая |
| ABAC | Атрибуты (пользователь, ресурс, контекст) | Сложные политики, зависящие от времени, местоположения, департамента | Высокая |
| ReBAC | Граф отношений между сущностями | Социальные сети, файловые хранилища, CRM | Средняя (через OpenFGA) |
Для 80% мобильных B2B-приложений достаточно RBAC с permission-флагами. ABAC оправдан, когда доступ к документу зависит от того, в каком отделе работает пользователь и который час. Мы реализовали 20+ таких систем, и наш опыт показывает: избыточная сложность на старте — главная причина срывов сроков. RBAC лучше ABAC в 3-5 раз по скорости внедрения и поддержки.
Как мы проектируем систему ролей
Первый шаг — аудит всех экранов и действий. Составляем матрицу: по строкам — функции, по столбцам — роли. Выявляем дублирование и конфликты. Затем проектируем модель данных — на backend это может быть Permission с action (read/create/update/delete) и resource pattern (/orders/*). На мобильном клиенте создаём PermissionsManager, который подписан на изменения прав через WebSocket.
Кейс: приложение для логистической компании. 6 ролей: диспетчер, водитель, менеджер склада, бухгалтер, администратор, аудитор. Сложность — водитель должен видеть только свои рейсы, а диспетчер — все. Решение: RBAC + дополнительные фильтры по departments. На клиенте — PermissionQuery с параметром scope: UserScope. Кеширование через EncryptedSharedPreferences с TTL 15 минут. При смене роли — Pusher-уведомление с немедленным рефрешем. Сократили время на добавление новой роли с 2 дней до 4 часов. Такой подход экономит до 40% бюджета на поддержку.
Почему клиент не должен доверять себе?
Проверки на мобильном — только UX. Если злоумышленник получит физический доступ к устройству, он может обойти клиентские проверки через перехват API. Поэтому каждый запрос на сервер должен валидировать права независимо. Мы используем JWT с embedded claims и проверяем их на backend. Клиент лишь скрывает недоступные кнопки — это снижает когнитивную нагрузку на 40% (по нашим замерам).
class OrderViewModel( private val permissionsRepository: PermissionsRepository ) : ViewModel() { val permissions = permissionsRepository.currentPermissions .stateIn(viewModelScope, SharingStarted.Eagerly, UserPermissions()) fun createOrder(order: Order) { check(permissions.value.canCreateOrder) { "Access denied" } // ... } } Как происходит синхронизация прав на клиенте?
Мы используем WebSocket для мгновенной доставки изменений прав. При обновлении роли на сервере клиент получает событие, обновляет локальный кэш в EncryptedSharedPreferences и перерисовывает UI без перезапуска. В админ-панели можно массово менять права — изменения применяются за секунды. Такой подход снижает количество инцидентов безопасности в 2 раза по сравнению с pull-методами.
Процесс работы над системой прав доступа
| Этап | Длительность | Результат |
|---|---|---|
| Аналитика | 2-3 дня | Матрица ролей, документ сценариев |
| Проектирование | 2-4 дня | API спецификация, модель данных |
| Реализация | 1-3 недели | Код, интегрированный с backend |
| Тестирование | 3-5 дней | Отчёт с покрытием, баг-репорт |
| Деплой и поддержка | 2 дня +1 месяц | Работающая система, SLA |
Чек-лист аудита текущей permission-системы
- [ ] Проверить все экраны на хардкод
if role == - [ ] Определить, где данные прав приходят (API / локально)
- [ ] Выявить дублирование проверок в разных модулях
- [ ] Оценить, нужна ли админ-панель для управления ролями
- [ ] Проверить, зашифровано ли хранилище прав на клиенте
Что входит в работу
- Документация матрицы ролей (PDF, Miro)
- Исходный код PermissionsManager с комментариями
- Unit-тесты покрытием >90%
- Интеграция с существующей системой аутентификации
- Обучение команды заказчика работе с админ-панелью
- Поддержка 1 месяц после запуска
Сроки и стоимость
Проектирование — от 2 дней. Реализация — от 2 до 4 недель в зависимости от количества ролей (до 10 — 2 недели, до 30 — 4 недели). Стоимость рассчитывается индивидуально после аудита. Role-based access control (RBAC) is a widely adopted model for managing permissions in enterprise systems (Wikipedia). Свяжитесь с нами, чтобы мы оценили ваш проект. Опыт нашей команды — 5+ лет в мобильной разработке, гарантируем отсутствие регрессий в permission-логике. Закажите внедрение RBAC и получите гибкое управление доступом для вашего приложения.