Проектування рольової моделі доступу 1С-Бітрікс

Проектування рольової моделі доступу 1С-Бітрікс

Типова ситуація: клієнт приходить із завданням «потрібно, щоб менеджер не міг видаляти товари, а редактор бачив лише свої розділи». У Бітрікс це вирішується через систему прав — модульну, багаторівневу і, якщо чесно, не найочевиднішу. Без проектування ролі ліплять вручну, потім з'являються суперечності: користувач одночасно входить до двох груп із конфліктуючими правами, і з'ясувати, чому кнопка не відображається, стає завданням на півдня.

Як влаштована система прав у 1С-Бітрікс

Платформа працює з трьома рівнями доступу:

Групи користувачів — базова одиниця. Права призначаються групі, а не конкретному користувачеві. Користувач може перебувати в кількох групах; фінальні права обчислюються за максимумом серед усіх груп.

Права на модулі — кожен модуль (iblock, catalog, sale, crm, im тощо) має власний реєстр прав. Наприклад, модуль iblock знає про права iblock_read, iblock_edit, iblock_admin. Це не глобальні константи — кожен модуль визначає свої.

Права на об'єкти — інфоблоки, розділи, елементи можуть мати точкові обмеження через CIBlock::SetPermission() або через інтерфейс «Налаштування доступу» на конкретному інфоблоці.

Крім цього, у D7-компонентах та REST API діє окремий механізм — Bitrix\Main\Access, що ґрунтується на правилах (AccessRule), провайдерах (AccessProvider) і суб'єктах (AccessSubject). Якщо проект активно використовує D7, права потрібно проектувати вже з урахуванням цього шару.

Процес проектування

Робота починається не з Бітрікс, а з аналізу бізнес-процесів замовника. Потрібно зрозуміти: хто створює контент, хто модерує, хто публікує, хто тільки переглядає, хто адмініструє технічно. Це п'ять типів акторів, які в реальних проектах змішуються в найнесподіваніших комбінаціях.

На практиці розробка рольової моделі проходить такі етапи:

1. Аудит наявних груп. На живих проектах нерідко виявляється 15–20 груп, половина з яких — застарілі експерименти. Починаємо з інвентаризації: b_group, b_user_group — дивимося, хто куди входить і чи є взагалі якась логіка.

2. Матриця доступу. Складаємо таблицю «роль × ресурс». Рядки — функціональні ролі (контент-менеджер каталогу, менеджер замовлень, SEO-спеціаліст, технічний адміністратор). Стовпці — модулі та об'єкти. Клітинки — рівень доступу (немає / читання / редагування / адміністрування).

3. Маппінг на групи Бітрікс. Визначаємо, чи потрібне відображення 1:1, чи одна бізнес-роль покривається кількома технічними групами. Іноді вигідніше зробити «базову» групу із загальними правами і «спеціалізовані» з додатковими.

4. Налаштування прав на інфоблоки. Для великих каталогів це критично: права задаються окремо на читання, запис, повний доступ — і можуть успадковуватися по розділах ієрархічно через CIBlockSection.

5. Тестування прав. Створюємо тестових користувачів для кожної ролі та вручну перевіряємо граничні сценарії: чи може менеджер експортувати прайс, чи бачить SEO-спеціаліст вкладку «SEO» в елементах, але не вкладку «Ціни».

Кейс: розмежування доступу в оптовому інтернет-магазині

Проект — B2B-каталог із ролями: оператор складу, менеджер з продажу, регіональний керівник, контент-менеджер, технічний адміністратор. Разом 5 ролей, 3 інфоблоки (товари, новини, банери), модулі catalog, sale, iblock.

Проблема при початковому налаштуванні: менеджери з продажу випадково отримали право редагувати ціни — через групу «Співробітники», якій видали catalog_admin «на час» і забули прибрати. Виявили через три тижні, коли один менеджер змінив ціну на позицію з високим оборотом.

Рішення: перезібрали групи з нуля. Ввели принцип «мінімально необхідних прав»: кожна група отримує рівно те, що потрібно для роботи, і не більше. Для каталогу розділили права: catalog_read — склад, iblock_edit лише на інфоблок товарів — контент-менеджер, повний catalog_admin — лише технічний адміністратор. Права на інфоблоки призначили явно через CIBlock::SetPermission(), прибравши успадкування від загальних налаштувань модуля.

Результат: 5 груп замість 17, задокументована матриця доступу, яку розуміє не тільки розробник, а й технічний директор замовника.

Особливості Enterprise-проектів

На проектах з редакцією «Ентерпрайз» (безліч сайтів під однією ліцензією) додається вимір сайтів: користувач може бути адміністратором одного сайту, але не мати доступу до іншого. Це управляється через b_user_site і потребує окремого проектування — матриця стає тривимірною: роль × ресурс × сайт.

Для REST API та інтеграцій проектується окремий шар: webhook-користувачі та застосунки отримують лише скоупи, необхідні для конкретної інтеграції. Надавати інтеграції права адміністратора — типова помилка, яка виявляється лише під час інциденту безпеки.

Терміни і що входить у роботу

Проектування рольової моделі для проекту зі стандартним набором ролей (5–8) і типовими модулями займає 3–7 робочих днів: аналіз, складання матриці, погодження, реалізація, тестування та документація. Складні Enterprise-проекти з безліччю сайтів і нестандартними модулями — 2–4 тижні.

До результату роботи входять: задокументована матриця доступу, налаштовані групи користувачів у системі, тест-протокол перевірки прав, рекомендації щодо підтримки моделі при зростанні команди.