Відзначимо: коли ваш мобільний додаток переростає просте адміністрування, система прав доступу стає вузьким місцем. Фінансовий додаток з 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 тижні). Вартість розраховується індивідуально після аудиту, орієнтовно від $2000 за просту RBAC-систему до $10000 за ReBAC з OpenFGA. Role-based access control (RBAC) є широко прийнятою моделлю керування доступом у корпоративних системах (Wikipedia). Оцініть ваш проєкт безкоштовно — напишіть нам. Досвід нашої команди — 5+ років у мобільній розробці, понад 20 реалізованих проєктів. Гарантуємо відсутність регресій у permission-логіці. Замовте впровадження RBAC під ключ та отримайте гнучке управління доступом для вашого додатку за 2-4 тижні.