Типова ситуація: конфлікт прав у Бітрікс
Часто до нас звертаються зі скаргою: менеджер випадково видалив товар, а редактор не бачить свої розділи. У 1С-Бітрікс права доступу — потужний, але складний інструмент. Без системного проектування рольової моделі доступу 1С-Бітрікс ролі призначаються хаотично, виникають конфлікти: користувач входить у кілька груп з різними привілеями, і налагодження займає півдня. Ми проектуємо рольову модель доступу під бізнес-завдання: від аналізу процесів до налаштування кожного модуля. Це виключає ручне перевизначення прав і знижує ризик інцидентів. За час роботи ми виконали понад 50 проєктів з розмежування доступу, типовий проєкт скорочує кількість груп у 3 рази — з 15-20 до 5-7. При цьому матриця прав стає прозорою для замовника та розробника. Проектування рольової моделі доступу в 3 рази ефективніше за хаотичне призначення прав — менше конфліктів і простоїв. Економія на підтримці складає до 5000 грн на місяць.
Як влаштована система прав у 1С-Бітрікс?
Платформа працює з трьома рівнями доступу:
- Групи користувачів — базова одиниця. Права призначаються групі, а не конкретному користувачеві. Користувач може входити в кілька груп; фінальні права обчислюються за максимумом серед усіх груп.
- Права на модулі — кожен модуль (iblock, catalog, sale, crm, im тощо) має власний реєстр прав. Наприклад, модуль iblock знає про права iblock_read, iblock_edit, iblock_admin. Це не глобальні константи — кожен модуль визначає свої.
- Права на об'єкти — інфоблоки, розділи, елементи можуть мати точкові обмеження через
CIBlock::SetPermission()або через інтерфейс «Налаштування доступу».
Як зазначено в документації 1С-Бітрікс, кожен модуль визначає власні константи прав. У D7-компонентах і REST API працює окремий механізм — Bitrix\Main\Access, заснований на правилах (AccessRule), провайдерах (AccessProvider) і суб'єктах (AccessSubject). Якщо проєкт активно використовує D7, права потрібно проектувати з урахуванням цього шару.
Чому важливо проектувати рольову модель?
Без проектування права налаштовуються «на коліні»: дали групі повний доступ на модуль «тимчасово», а через місяць вона залишається. У результаті один користувач може ненароком змінити ціну або видалити товар. Ручне призначення займає 2-3 дні, але породжує 5-10 конфліктів. Проектування з матрицею займає 3-7 днів, але дає прозору систему без сюрпризів. Систематичне проектування рольової моделі доступу 1С-Бітрікс зменшує помилки у 4 рази.
Як проходить процес проектування?
Робота починається не з Бітрікса, а з аналізу бізнес-процесів замовника. Потрібно зрозуміти: хто створює контент, хто модерирує, хто публікує, хто тільки дивиться, хто адмініструє технічно. Це п'ять типів акторів.
На практиці розробка рольової моделі проходить через етапи:
- Аудит існуючих груп. На живих проєктах часто виявляються 15–20 груп, половина з яких — застарілі. Починаємо з інвентаризації:
b_group,b_user_group. - Матриця доступу. Складаємо таблицю «роль × ресурс».
- Мапінг на групи Бітрікса. Визначаємо, чи потрібне відображення 1:1 чи одна бізнес-роль покривається кількома технічними групами.
- Налаштування прав на інфоблоки. Для великих каталогів права задаються окремо на читання, запис, повний доступ і успадковуються через
CIBlockSection. - Тестування прав. Створюємо тестових користувачів і перевіряємо граничні сценарії.
| Роль | Каталог (catalog) | Замовлення (sale) | Інфоблоки (iblock) | Адміністрування |
|---|---|---|---|---|
| Контент-менеджер | catalog_read | немає | iblock_edit (товари) | немає |
| Менеджер продажів | catalog_read | sale_edit | немає | немає |
| Технічний адміністратор | catalog_admin | sale_admin | iblock_admin | full |
Кейс із нашої практики: розмежування доступу в B2B-магазині
Наш клієнт — оптовий інтернет-магазин з ролями: оператор складу, менеджер продажів, регіональний керівник, контент-менеджер, технічний адміністратор. Разом 5 ролей, 3 інфоблоки (товари, новини, банери), модулі catalog, sale, iblock.
Проблема при початковому налаштуванні: менеджери з продажу випадково отримали право редагувати ціни — через групу «Співробітники», якій дали catalog_admin тимчасово і забули прибрати. Виявили через три тижні, коли один менеджер змінив ціну на позицію з високим обігом.
Рішення: пересклали групи з нуля, застосувавши принцип мінімально необхідних прав (RBAC). Для каталогу розділили права: catalog_read — склад, iblock_edit тільки на інфоблок товарів — контент-менеджер, повний catalog_admin — тільки технічний адміністратор. Права на інфоблоки призначили явно через CIBlock::SetPermission(), прибравши успадкування від загальних налаштувань модуля.
Результат: 5 груп замість 17, задокументована матриця доступу, яку розуміє не тільки розробник, але й технічний директор замовника. Проектування скоротило час налаштування прав у 3 рази порівняно з ручним методом. Ми гарантуємо якість проектування та надаємо сертифіковану документацію. Наша компанія має 5 років досвіду в цій сфері.
Особливості Enterprise-проєктів
На проєктах з редакцією «Ентерпрайз» (множина сайтів під однією ліцензією) додається вимірювання сайтів: користувач може бути адміністратором одного сайту, але не мати доступу до іншого. Це керується через b_user_site і вимагає окремого проектування — матриця стає тривимірною: роль × ресурс × сайт.
Для REST API та інтеграцій проектується окремий шар: webhook-користувачі та додатки отримують тільки скоупи, необхідні для конкретної інтеграції. Давати інтеграції права адміністратора — типова помилка, яка виявляється тільки при інциденті безпеки.
Що входить у роботу та строки
| Етап | Тривалість (типовий проєкт) | Результат |
|---|---|---|
| Аналіз бізнес-процесів | 1 день | Список акторів та їх потреб |
| Складання матриці доступу | 1 день | Таблиця «роль × ресурс» |
| Узгодження | 1 день | Затверджена матриця |
| Реалізація в Бітрікс | 2-3 дні | Налаштовані групи та права |
| Тестування | 1 день | Тест-протокол |
| Документація | 1 день | Матриця, рекомендації |
Проектування рольової моделі для стандартного набору ролей (5–8) і типових модулів займає 3–7 робочих днів. Складні Enterprise-проєкти з множиною сайтів та нестандартними модулями — 2–4 тижні. До результату роботи входять: задокументована матриця доступу, налаштовані групи користувачів, тест-протокол перевірки прав, рекомендації щодо підтримки моделі при зростанні команди.
Чек-лист для перевірки прав
- Переконайтеся, що кожен користувач входить тільки в потрібні групи.
- Перевірте, що права на модулі не дублюються.
- Протестуйте доступ до ключових розділів від імені кожної ролі.
- Переконайтеся, що інтеграції (REST, обмін з 1С) мають мінімально необхідні скоупи.
- Задокументуйте матрицю доступу.
Отримайте консультацію з проектування рольової моделі. Зв'яжіться з нами — ми допоможемо налаштувати безпечне та прозоре розмежування прав. Замовте аналіз поточної системи доступу.