Роль BAS

Роль BAS — це набір прав доступу в системі BAS, який визначає, що саме користувач може бачити, створювати, змінювати, проводити, видаляти, друкувати, експортувати або адмініструвати в інформаційній базі. Ролі використовуються для розмежування доступу між бухгалтерами, менеджерами, комірниками, касирами, керівниками, адміністраторами, інтеграційними користувачами та іншими учасниками облікової системи.

У BAS роль пов’язана з користувачем, конфігурацією, об’єктами метаданих, довідниками, документами, звітами, обробками, регістрами, підсистемами, журналом реєстрації та бізнес-процесами. Саме через ролі визначається, чи може користувач відкрити довідник, створити документ, провести операцію, побачити собівартість, змінити закритий період, запустити обробку або отримати доступ до інтеграції.

У контексті переходу з BAS на K2 ERP ролі мають особливе значення. Їх не можна просто копіювати зі старої системи. Потрібно проаналізувати реальні обов’язки користувачів, знайти зайві права, спільні логіни, сервісні акаунти, адміністраторські доступи, небезпечні обробки, права на зарплату, фінанси, собівартість, експорт і побудувати нову контрольовану модель доступу в K2 ERP.

Головне. Роль BAS — це не просто назва посади. Це технічний набір дозволів, який визначає, які дії користувач може виконувати в системі й до яких даних він має доступ.

Важливо про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій. Тому ролі BAS потрібно розглядати як об’єкт інвентаризації, аудиту доступів і контрольованої міграції на українську ERP-платформу.

Підхід K2 ERP. Під час переходу з BAS потрібно не переносити старі ролі “як є”, а побудувати нову рольову модель у K2 ERP: персональні користувачі, групи, мінімально необхідні права, сервісні акаунти, журналювання, контроль експорту, BI-доступу, API та адміністративних дій.

Вступ

Ролі в BAS потрібні для того, щоб кожен користувач мав доступ тільки до тих функцій, які потрібні йому для роботи.

Наприклад:

менеджер продажів створює замовлення покупців;
комірник працює зі складськими документами;
бухгалтер проводить банк і касу;
головний бухгалтер закриває період;
кадровик працює з працівниками;
керівник переглядає звіти;
адміністратор налаштовує систему;
сервісний користувач виконує інтеграційний обмін.

Якщо ролі налаштовані правильно, система підтримує порядок і безпеку. Якщо неправильно — користувачі бачать зайві дані, можуть змінювати критичні документи, запускати небезпечні обробки, відкривати зарплату, собівартість, фінанси або адміністрування без реальної потреби.

Що таке роль BAS

Роль BAS — це об’єкт конфігурації або налаштування доступу, який визначає набір дозволів для користувача.

Роль може дозволяти або забороняти:

перегляд довідників;
створення довідників;
зміну довідників;
створення документів;
проведення документів;
скасування проведення;
видалення або помітку на видалення;
запуск звітів;
запуск обробок;
друк документів;
експорт даних;
доступ до регістрів;
зміну налаштувань;
адміністрування;
роботу з інтеграціями;
роботу із закритими періодами;
доступ до зарплати;
доступ до собівартості;
доступ до фінансів.

Простий приклад:

Роль	Що дозволяє	Що обмежує
Менеджер продажів	Клієнти, замовлення, рахунки	Зарплата, адміністрування, собівартість
Комірник	Складські документи, залишки, інвентаризація	Банк, каса, зарплата
Бухгалтер	Каса, банк, проводки, податкові документи	Адміністрування без потреби
Керівник	Звіти, аналітика, контроль	Зміна первинних документів без потреби

Роль і користувач BAS

Роль сама по собі не працює без користувача.

Зв’язок такий:

Користувач BAS → Роль BAS → Права доступу → Доступні об’єкти і дії

Наприклад:

Користувач	Роль	Результат
ivanenko	Менеджер продажів	Може створювати замовлення покупців
petrenko_buh	Бухгалтер	Може працювати з банком і касою
sklad_kyiv	Комірник	Може працювати зі складом Київ
admin	Адміністратор	Має розширені права

Один користувач може мати кілька ролей. Це зручно, але може створювати ризики, якщо ролі накладаються і дають зайвий доступ.

Роль і група користувачів

У деяких конфігураціях або моделях адміністрування ролі можуть призначатися не тільки окремим користувачам, а й групам.

Приклад:

Група	Ролі	Користувачі
Продажі	Менеджер продажів, Перегляд залишків	ivanenko, shevchenko
Склад	Комірник, Перегляд номенклатури	sklad_kyiv, sklad_lviv
Бухгалтерія	Бухгалтер, Каса, Банк	buh1, buh2
Керівництво	Перегляд звітів, BI	director, fin_dir

Групи спрощують адміністрування, але потрібно контролювати, щоб група не давала користувачу зайвих прав.

Роль і профіль доступу

У практиці адміністрування може використовуватися поняття профілю доступу.

Профіль доступу — це логічний набір прав, який відповідає типовій посаді або функції.

Наприклад:

профіль “Менеджер продажів”;
профіль “Комірник”;
профіль “Бухгалтер по банку”;
профіль “Касир”;
профіль “Керівник”;
профіль “Адміністратор”;
профіль “API сайту”;
профіль “BI-експорт”.

У K2 ERP під час міграції краще будувати саме профільну модель: від реальних ролей бізнесу до конкретних технічних прав.

Роль і конфігурація BAS

Ролі є частиною конфігурації BAS або механізмів доступу конкретного рішення.

Конфігурація визначає:

які ролі існують;
які об’єкти доступні;
які довідники можна відкривати;
які документи можна проводити;
які звіти доступні;
які обробки дозволені;
які регістри відкриті;
які підсистеми показані;
які форми доступні;
які команди можна виконувати.

Якщо конфігурація нетипова, ролі також можуть бути дороблені.

Типові ролі BAS

У різних конфігураціях назви ролей можуть відрізнятися, але в бізнесі часто зустрічаються такі ролі:

адміністратор;
повні права;
бухгалтер;
головний бухгалтер;
менеджер продажів;
менеджер закупівель;
комірник;
касир;
керівник;
кадровик;
розраховувач зарплати;
логіст;
технолог;
виробничий користувач;
аудитор;
користувач інтеграції;
тільки перегляд;
зовнішній користувач.

Адміністратор BAS

Адміністратор — це роль із розширеними правами.

Адміністратор може:

створювати користувачів;
змінювати ролі;
блокувати користувачів;
налаштовувати базу;
запускати службові обробки;
змінювати параметри системи;
працювати з журналом реєстрації;
налаштовувати інтеграції;
виконувати оновлення;
працювати з конфігурацією.

Адміністраторські права не повинні використовуватися для щоденної роботи менеджера, бухгалтера або інтеграцій.

Роль “Повні права”

Роль із повними правами дає максимальний доступ до системи.

Це небезпечно, якщо її мають зайві користувачі.

Ризики:

зміна критичних довідників;
доступ до зарплати;
доступ до собівартості;
доступ до банку й каси;
зміна закритих періодів;
запуск службових обробок;
видалення даних;
зміна прав інших користувачів;
доступ до інтеграцій;
експорт конфіденційних даних.

Ризик. Роль “Повні права” має бути тільки в обмеженого кола відповідальних адміністраторів. Якщо її мають усі користувачі, система фактично не має контролю доступу.

Роль бухгалтера

Бухгалтерська роль може давати доступ до:

банківських документів;
касових документів;
авансових звітів;
податкових документів;
бухгалтерських проводок;
взаєморозрахунків;
основних засобів;
закриття місяця;
регламентованої звітності;
оборотно-сальдових відомостей.

Але бухгалтеру не завжди потрібні:

повні адміністративні права;
права на зміну користувачів;
доступ до технічних обробок;
доступ до API;
доступ до всіх інтеграцій.

Роль головного бухгалтера

Головний бухгалтер може мати ширші права, ніж звичайний бухгалтер.

Наприклад:

контроль закриття періоду;
скасування проведення окремих документів;
доступ до регламентованої звітності;
контроль податкових документів;
доступ до критичних бухгалтерських звітів;
погодження змін у закритому періоді;
контроль каси й банку.

Але навіть головному бухгалтеру не завжди потрібні права технічного адміністратора.

Роль менеджера продажів

Менеджер продажів зазвичай працює з:

контрагентами;
контактами;
договорами;
замовленнями покупців;
рахунками;
реалізаціями;
резервами;
цінами продажу;
статусами замовлень;
комерційними пропозиціями;
CRM-даними, якщо вони є.

Обмежувати бажано:

собівартість;
зарплату;
банк;
касу;
адміністрування;
закриті періоди;
технічні обробки.

Роль комірника

Комірник зазвичай має доступ до:

складів;
номенклатури;
надходжень;
переміщень;
відвантажень;
інвентаризацій;
списань;
серій;
характеристик;
штрихкодів;
складських звітів.

Обмежувати бажано:

фінанси;
зарплату;
собівартість;
адміністративні налаштування;
зміну цін;
зміну прав користувачів.

Роль касира

Касир може працювати з:

прибутковими касовими ордерами;
видатковими касовими ордерами;
оплатами;
поверненнями;
касовими змінами;
касовою книгою;
фіскальними операціями, якщо вони є;
звітами касира.

Касир не повинен мати зайвий доступ до:

зарплати;
собівартості;
налаштувань прав;
усіх банківських рахунків;
технічних обробок.

Роль керівника

Керівник часто потребує доступу до звітів і аналітики.

Наприклад:

продажі;
прибуток;
дебіторська заборгованість;
кредиторська заборгованість;
залишки;
фінансові звіти;
KPI;
план-факт;
BI.

Керівнику не завжди потрібні права на зміну первинних документів. Часто достатньо доступу на перегляд і затвердження.

Роль аудитора

Аудиторська роль зазвичай має бути роллю перегляду.

Аудитор може бачити:

документи;
довідники;
проводки;
звіти;
журнал реєстрації;
історичні дані.

Але аудитор не повинен:

змінювати документи;
проводити документи;
видаляти дані;
змінювати користувачів;
запускати критичні обробки.

Роль сервісного користувача

Сервісна роль потрібна для інтеграцій.

Наприклад:

Сервісна роль	Призначення	Доступ
API сайту	Обмін із сайтом	Товари, залишки, ціни, замовлення, статуси
API CRM	Обмін із CRM	Клієнти, угоди, замовлення
API WMS	Обмін зі складом	Складські документи, залишки, відвантаження
BI-експорт	Передача даних в аналітику	Читання потрібних аналітичних даних
Імпорт банку	Завантаження банківських операцій	Банківські документи

Сервісна роль має бути максимально обмеженою.

Роль “Тільки перегляд”

Роль тільки для перегляду потрібна для:

керівників;
аудиторів;
консультантів;
тимчасових користувачів;
контролерів;
служби безпеки;
зовнішніх перевірок;
архівного доступу.

Вона дозволяє бачити дані, але не змінювати їх.

Права на довідники

Роль може давати права на довідники.

Наприклад:

контрагенти;
номенклатура;
склади;
договори;
фізичні особи;
організації;
валюти;
каси;
банківські рахунки;
статті витрат;
підрозділи.

Приклад:

Довідник	Менеджер	Комірник	Бухгалтер
Контрагенти	Створення і зміна	Перегляд	Перегляд і зміна
Номенклатура	Перегляд	Перегляд і уточнення	Перегляд
Банківські рахунки	Немає доступу	Немає доступу	Зміна
Фізичні особи	Немає доступу	Немає доступу	Обмежений доступ

Права на документи

Права на документи можуть бути різними.

Наприклад:

створення;
зміна;
проведення;
скасування проведення;
помітка на видалення;
друк;
перегляд;
затвердження;
заборона зміни після проведення.

Приклад:

Документ	Менеджер	Комірник	Бухгалтер
Замовлення покупця	Створення і зміна	Перегляд	Перегляд
Реалізація товарів	Створення	Перегляд	Проведення
Переміщення товарів	Перегляд	Створення і проведення	Перегляд
Касовий ордер	Немає доступу	Немає доступу	Створення і проведення

Права на звіти

Звіти часто містять чутливу інформацію.

Роль може дозволяти або забороняти доступ до:

продажів;
залишків;
собівартості;
прибутку;
зарплати;
податкової звітності;
банківських залишків;
дебіторської заборгованості;
кредиторської заборгованості;
управлінської аналітики;
BI.

Наприклад, менеджер може бачити продажі, але не собівартість і зарплату.

Права на обробки

Обробки можуть бути небезпечнішими за звіти, бо вони змінюють дані.

Приклади обробок:

масова зміна цін;
перепроведення документів;
завантаження Excel;
імпорт банку;
обмін із сайтом;
видалення помічених об’єктів;
закриття місяця;
оновлення залишків;
сервісні обробки;
міграційні обробки.

Права на обробки потрібно обмежувати особливо уважно.

Права на експорт

Експорт даних — окрема зона ризику.

Користувач із правом експорту може вивантажити:

клієнтів;
постачальників;
ціни;
залишки;
зарплату;
фінансові звіти;
собівартість;
персональні дані;
договори;
банківські реквізити.

Права на експорт мають бути частиною матриці доступу.

Права на закриті періоди

Закриті періоди потрібно захищати.

Роль може дозволяти:

зміну документів минулих періодів;
перепроведення;
скасування проведення;
коригування;
зміну дати заборони редагування;
службове виправлення.

Такі права мають бути тільки у відповідальних користувачів.

Роль і обмеження по організаціях

Якщо в базі кілька юридичних осіб, роль може обмежувати доступ по організаціях.

Наприклад:

Користувач	Організація	Доступ
buh_kyiv	ТОВ Київ	Бухгалтерські документи ТОВ Київ
buh_lviv	ТОВ Львів	Бухгалтерські документи ТОВ Львів
fin_dir	Усі організації	Консолідована звітність

Роль і обмеження по складах

Для складського обліку важливо обмежувати доступ по складах.

Наприклад:

комірник Києва бачить тільки склад Київ;
комірник Львова бачить тільки склад Львів;
керівник складу бачить усі склади;
менеджер бачить доступний залишок, але не інвентаризацію;
бухгалтер бачить вартісний облік.

Роль і обмеження по підрозділах

Обмеження по підрозділах потрібні для:

продажів;
закупівель;
виробництва;
складу;
філій;
проєктів;
центрів витрат;
регіонів;
команд.

Наприклад, керівник відділу продажів бачить своїх менеджерів, але не бачить інший регіон.

Роль і зарплата

Зарплатні дані мають бути захищені.

Доступ до зарплати можуть мати:

бухгалтер із зарплати;
кадровик;
головний бухгалтер;
керівник за окремим дозволом;
сервісний користувач тільки за крайньої потреби й з обмеженнями.

Не повинні мати доступ:

менеджери;
комірники;
касири без потреби;
сайт;
CRM;
WMS;
BI-експорт без обмеження;
тестові користувачі.

Роль і собівартість

Собівартість є комерційно чутливою інформацією.

Її потрібно обмежувати для:

менеджерів продажів;
комірників;
зовнішніх користувачів;
сервісних акаунтів;
філій без відповідного рівня доступу.

Інакше користувачі можуть бачити маржу, закупівельні ціни, прибутковість і комерційні умови.

Роль і банк

Банківські права можуть включати:

перегляд виписок;
імпорт виписок;
створення платіжних документів;
проведення платежів;
експорт платежів;
перегляд залишків на рахунках;
зміну банківських реквізитів.

Такі права потрібно видавати обмежено.

Роль і каса

Касові права можуть включати:

створення касових ордерів;
проведення касових ордерів;
перегляд касової книги;
оформлення оплат;
повернення;
закриття касової зміни;
друк касових документів.

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

Роль і інтеграції

Ролі важливі для інтеграцій.

Погано:

Інтеграція із сайтом працює під admin

Краще:

Інтеграція із сайтом працює під api_site
Роль api_site має доступ тільки до товарів, цін, залишків, замовлень і статусів

Для кожної інтеграції має бути окрема роль або окремий профіль доступу.

Роль і веб-клієнт BAS

Якщо використовується Веб-клієнт BAS, роль визначає, що користувач може робити через браузер.

Потрібно перевірити:

хто має web-доступ;
чи є спільні логіни;
чи немає ролі “Повні права” у web-користувачів без потреби;
чи працює HTTPS;
чи ведеться журнал входів;
які web-сервіси доступні;
які ролі мають сервісні користувачі.

Роль і клієнт-серверний режим BAS

У клієнт-серверному режимі BAS ролі важливі для:

користувачів;
сервісних акаунтів;
регламентних завдань;
web-сервісів;
фонових обробок;
інтеграцій;
адміністрування.

Потрібно перевіряти не тільки людей, а й технічні підключення.

Роль і файловий режим BAS

У файловому режимі BAS ролі в системі можуть бути налаштовані правильно, але ризик залишається на рівні папки бази.

Якщо користувач має доступ до файлової папки, він може:

скопіювати базу;
перенести базу;
створити несанкціоновану копію;
передати файл стороннім;
працювати з локальною копією.

Тому ролі BAS потрібно доповнювати контролем файлових прав.

Роль і журнал реєстрації

Журнал реєстрації допомагає перевірити, як реально використовуються ролі.

Він може показати:

хто входить у систему;
хто створює документи;
хто змінює дані;
хто запускає обробки;
хто має помилки доступу;
хто працює під admin;
які сервісні акаунти активні;
які ролі фактично використовуються;
чи є підозрілі дії.

Приклад журналу дій

Дата	Користувач	Роль	Дія	Об’єкт
15.05.2026 10:15	ivanenko	Менеджер продажів	Створення	Замовлення покупця №123
15.05.2026 10:20	buh1	Бухгалтер	Проведення	Банківська виписка №45
15.05.2026 11:05	admin	Адміністратор	Зміна ролі	Користувач sklad_kyiv
15.05.2026 12:30	api_site	API сайту	Обмін	Замовлення WEB-100245

Аудит ролей BAS

Аудит ролей потрібен для виявлення ризиків.

Потрібно перевірити:

список ролей;
опис ролей;
користувачів із кожною роллю;
користувачів із повними правами;
адміністраторів;
сервісних користувачів;
спільні логіни;
ролі з доступом до зарплати;
ролі з доступом до собівартості;
ролі з доступом до банку;
ролі з доступом до обробок;
ролі з доступом до експорту;
неактуальні ролі;
ролі тестових користувачів.

Таблиця аудиту ролей

Роль	Користувачі	Ризик	Рішення
Повні права	admin, buh1, manager	Забагато користувачів	Залишити тільки адміністраторам
Менеджер продажів	ivanenko, shevchenko	Немає	Перенести в K2 ERP після перевірки
Комірник	sklad, sklad2	Спільні логіни	Створити персональні акаунти
API сайту	api_site	Має зайві права	Обмежити до API-сценаріїв
Старий консультант	consultant	Активний доступ	Заблокувати

Роль при міграції з BAS у K2 ERP

Під час переходу в K2 ERP ролі потрібно аналізувати окремо від даних.

Потрібно зібрати:

список ролей;
список користувачів;
відповідність ролей посадам;
фактичні права;
групи користувачів;
адміністраторів;
сервісні акаунти;
доступи до зарплати;
доступи до фінансів;
доступи до собівартості;
права на обробки;
права на експорт;
web-доступ;
API-доступ;
журнал активності.

Чому ролі BAS не можна переносити як є

У старих системах ролі часто накопичують хаос.

Типові проблеми:

роль має зайві права;
користувач має кілька несумісних ролей;
менеджер має повні права;
комірник бачить собівартість;
сервісний користувач має доступ до зарплати;
інтеграція працює під admin;
звільнений користувач має активну роль;
тестова роль використовується в роботі;
немає опису ролей;
права давно не переглядалися.

У K2 ERP потрібно створити чисту модель доступу.

Таблиця міграції ролей

Роль BAS	Проблема	Роль K2 ERP	Рішення
Повні права	Видана багатьом користувачам	Адміністратор K2 ERP	Залишити тільки відповідальним
Менеджер	Має доступ до собівартості	Менеджер продажів	Прибрати собівартість
Склад	Спільний логін	Комірник	Створити персональні доступи
Бухгалтер	Має зайві обробки	Бухгалтер	Обмежити службові обробки
api_site	Працює під admin	API сайту	Створити окремий сервісний профіль

Побудова ролей у K2 ERP

У K2 ERP ролі варто будувати від бізнес-процесів.

Порядок:

Описати посади.
Описати бізнес-функції.
Описати документи.
Описати довідники.
Описати звіти.
Описати обробки.
Описати BI-доступ.
Описати API-доступ.
Визначити чутливі дані.
Побудувати матрицю доступу.
Створити ролі.
Призначити користувачів.
Протестувати сценарії.
Переглянути зайві права.
Увімкнути журналювання.

Матриця доступу для K2 ERP

Приклад:

Об’єкт / Роль	Менеджер	Комірник	Бухгалтер	Керівник	Адміністратор
Контрагенти	Створення	Перегляд	Зміна	Перегляд	Повний доступ
Замовлення	Створення і зміна	Перегляд	Перегляд	Перегляд	Повний доступ
Складські документи	Перегляд	Створення	Перегляд	Перегляд	Повний доступ
Каса	Немає	Немає	Повний доступ	Перегляд	Повний доступ
Зарплата	Немає	Немає	Обмежений доступ	За окремим дозволом	Повний доступ
BI	Власні продажі	Складські KPI	Фінанси	Консолідована аналітика	Адміністрування

Контроль ролей після запуску K2 ERP

Після запуску потрібно перевірити:

чи всі користувачі мають правильні ролі;
чи немає зайвих адміністраторів;
чи немає спільних логінів;
чи сервісні акаунти обмежені;
чи менеджери не бачать зарплату;
чи комірники не бачать собівартість;
чи доступ до банку обмежений;
чи працює журналювання;
чи BI не відкриває зайві дані;
чи старі BAS-ролі більше не використовуються;
чи стара BAS не лишилася активною.

Типові помилки з ролями BAS

Найчастіші проблеми:

усі мають повні права;
ролі не відповідають посадам;
користувачі мають забагато ролей;
немає матриці доступу;
спільні логіни мають широкі права;
сервісні користувачі мають права адміністратора;
звільнені користувачі мають активні ролі;
немає обмеження по складах;
немає обмеження по організаціях;
менеджери бачать собівартість;
комірники бачать фінанси;
BI відкриває зайві дані;
права на експорт не контролюються;
права на обробки не обмежені.

Помилка: роль “Повні права” для всіх

Це одна з найнебезпечніших помилок.

Наслідки:

немає реального контролю;
кожен може змінити критичні дані;
важко розслідувати помилки;
користувачі бачать зайву інформацію;
інтеграції можуть змінити будь-що;
зростає ризик витоку даних;
журнал реєстрації не допомагає, якщо всі мають однаковий повний доступ.

Помилка: не розділяти ролі людей і сервісів

Люди й інтеграції мають різні ролі.

Погано:

admin використовується бухгалтером, сайтом, CRM і програмістом

Добре:

buh1       → бухгалтер
api_site   → сайт
api_crm    → CRM
admin      → тільки адміністрування
bi_export  → BI

Помилка: роль не відповідає посаді

Наприклад:

комірник має роль бухгалтера;
менеджер має роль адміністратора;
касир має доступ до зарплати;
консультант має повні права;
сервісний користувач має доступ до всіх довідників.

Такі невідповідності потрібно прибирати до міграції.

Помилка: не перевіряти права на обробки

Обробки можуть змінювати багато даних одразу.

Якщо звичайний користувач має доступ до службових обробок, він може:

перепровести документи;
змінити ціни;
завантажити неправильні дані;
видалити помічені об’єкти;
змінити реквізити;
зламати інтеграційний обмін.

Помилка: не перевіряти права на експорт

Навіть роль “тільки перегляд” може бути небезпечною, якщо дозволяє експорт.

Користувач може вивантажити:

клієнтську базу;
зарплату;
собівартість;
фінансові звіти;
залишки;
договори;
банківські реквізити.

Як не треба робити

Погані підходи:

переносити ролі BAS у K2 ERP без аналізу;
залишати всім повні права;
не створювати матрицю доступу;
не відокремлювати сервісні акаунти;
не обмежувати BI;
не обмежувати експорт;
не обмежувати зарплату;
не обмежувати собівартість;
не перевіряти журнал реєстрації;
не блокувати старі ролі;
залишати BAS активною після запуску K2 ERP;
ігнорувати санкційні й кібербезпекові ризики.

Найгірший сценарій. Компанія переходить у K2 ERP, але копіює старі ролі BAS без аудиту: усі мають повні права, інтеграції працюють під admin, менеджери бачать собівартість, звільнені користувачі активні, а права на експорт не контролюються.

Як правильно працювати з ролями BAS перед міграцією

Правильний порядок:

Зробити резервну копію BAS.
Вивантажити список користувачів.
Вивантажити список ролей.
Визначити користувачів із повними правами.
Знайти адміністраторів.
Знайти сервісні акаунти.
Знайти спільні логіни.
Перевірити доступ до зарплати.
Перевірити доступ до собівартості.
Перевірити доступ до банку й каси.
Перевірити права на обробки.
Перевірити права на експорт.
Перевірити web-доступ.
Перевірити API-доступ.
Перевірити журнал реєстрації.
Побудувати нову матрицю доступу.
Створити ролі в K2 ERP.
Призначити персональних користувачів.
Налаштувати сервісні ролі.
Протестувати сценарії.
Заблокувати старі BAS-доступи після запуску.

Роль BAS і цифрова незалежність

Аналіз ролей BAS — це частина виходу зі старої ризикової системи.

Компанія повинна:

знайти всі ролі;
знайти зайві права;
прибрати спільні логіни;
обмежити адміністраторів;
заблокувати звільнених користувачів;
замінити сервісні акаунти;
перенести інтеграції на контрольований API;
створити нову модель доступу в K2 ERP;
не залишити BAS активною робочою системою;
зменшити залежність від BAS і 1С.

Цифрова незалежність. Перехід із BAS у K2 ERP — це можливість не тільки перенести дані, а й навести порядок у ролях, правах, користувачах, інтеграціях, журналах і відповідальності.

Коротко

Питання	Відповідь
Що таке роль BAS?	Це набір прав доступу, який визначає, що користувач може робити в системі.
Чим роль відрізняється від користувача?	Користувач входить у систему, а роль визначає його дозволи.
Чи може користувач мати кілька ролей?	Так, але це потрібно контролювати, щоб не видати зайві права.
Що найнебезпечніше в ролях?	Неконтрольовані повні права, спільні логіни, інтеграції під адміністратором і доступ до чутливих даних без потреби.
Що таке сервісна роль?	Це роль для технічного користувача інтеграції, API, web-сервісу або автоматичного обміну.
Чи можна переносити ролі BAS у K2 ERP як є?	Ні. Потрібно провести аудит і створити нову контрольовану матрицю доступу.
Що перевірити перед міграцією?	Повні права, адміністраторів, сервісні акаунти, доступ до зарплати, собівартості, банку, каси, обробок, експорту, web і API.
Чи є санкційні ризики у BAS і 1С?	Так. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

Висновок

Роль BAS — це ключовий елемент системи доступу. Вона визначає, що користувач може бачити й робити: працювати з довідниками, документами, звітами, обробками, інтеграціями, фінансами, зарплатою, собівартістю, закритими періодами й адміністративними налаштуваннями.

Правильно налаштовані ролі дозволяють:

розділяти відповідальність;
захищати дані;
обмежувати доступ;
контролювати інтеграції;
захищати зарплату й фінанси;
не відкривати собівартість зайвим користувачам;
вести аудит;
готувати якісну міграцію в K2 ERP.

Під час переходу з BAS у K2 ERP ролі не потрібно переносити механічно. Потрібно провести аудит, знайти зайві права, прибрати спільні логіни, обмежити адміністраторів, створити сервісні ролі для API, побудувати матрицю доступу й перевірити її на реальних сценаріях.

Правильний підхід. Ролі BAS потрібно розглядати як джерело інформації про стару модель доступу, але не як готову схему для перенесення. У K2 ERP потрібно будувати нову, чисту й контрольовану модель ролей, прав, груп, сервісних акаунтів і журналювання.

З урахуванням санкційних, юридичних і кібербезпекових ризиків BAS та 1С, аудит ролей має бути частиною ширшої стратегії переходу на українське програмне забезпечення, цифрову незалежність і сучасну ERP-архітектуру.

K2 ERP у цьому процесі може стати платформою для контрольованих ролей, користувачів, груп доступу, сервісних акаунтів, API, BI-аналітики, журналювання, прав доступу, резервного копіювання, web-доступу й подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми BAS / 1С.

Див. також

Зовнішні посилання