Права доступу BAS

Права доступу BAS — це механізм керування тим, що користувачі можуть бачити і робити в BAS / BAF: відкривати розділи, створювати документи, редагувати довідники, проводити операції, переглядати звіти, працювати з банком, зарплатою, складом, виробництвом, ПДВ, собівартістю, запускати обробки, адмініструвати базу або працювати з інтеграціями.

Права доступу в BAS визначаються через користувачів, ролі, профілі, групи доступу, обмеження за організаціями, складами, підрозділами, видами документів, функціональними розділами, а також через механізми обмеження доступу на рівні записів. У практиці 1С/BAS такі обмеження часто називають RLS — Record Level Security.

Головне. Права доступу BAS — це не просто “поставити галочку користувачу”. Це модель безпеки, яка визначає, хто бачить дані, хто може їх змінювати, хто відповідає за документи, хто має доступ до зарплати, банку, ПДВ, собівартості, інтеграцій, конфігуратора і зовнішніх обробок.

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

Важливо про 1С, BAS і BAF. В Україні продукти екосистеми 1С і частина продуктів BAS пов’язані з санкційними, юридичними, кібербезпековими та репутаційними ризиками. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до санкцій. Перед використанням, підтримкою або міграцією таких систем потрібно перевіряти актуальні офіційні обмеження. ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009))

Що таке права доступу BAS

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

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

переглядати розділи;
відкривати довідники;
створювати документи;
змінювати документи;
проводити документи;
скасовувати проведення;
помічати на видалення;
видаляти помічені об’єкти;
формувати звіти;
переглядати зарплату;
переглядати банк;
переглядати ПДВ;
переглядати собівартість;
запускати зовнішні обробки;
змінювати налаштування;
адмініструвати користувачів;
працювати в конфігураторі;
виконувати інтеграційні операції.

Для чого потрібні права доступу

Права доступу потрібні для:

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

Без прав доступу BAS перетворюється на систему, де будь-хто може побачити або змінити критичні дані.

Основні елементи моделі доступу

Елемент	Що означає	Приклад
Користувач	Обліковий запис людини або сервісу	ivanenko.i
Роль	Набір технічних прав у конфігурації	Бухгалтер, Комірник, Адміністратор
Профіль доступу	Прикладний набір ролей і обмежень	Менеджер продажів
Група доступу	Об’єднання користувачів із однаковими правилами	Відділ продажів Київ
Обмеження	Фільтри по організації, складу, підрозділу	Доступ тільки до складу Київ
RLS	Обмеження доступу на рівні записів	Бачити тільки свої документи

Користувач BAS

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

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

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

Приклад:

Поле	Значення
Користувач	Іваненко Іван
Логін	ivanenko.i
Профіль	Менеджер продажів
Організація	ТОВ “Компанія”
Підрозділ	Відділ продажів
Статус	Активний

Роль BAS

Роль — це технічний набір прав у конфігурації BAS.

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

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

Приклади ролей:

Бухгалтер;
Головний бухгалтер;
Менеджер продажів;
Комірник;
Кадровик;
Зарплатний бухгалтер;
Фінансист;
Керівник;
Адміністратор;
Повні права;
Користувач інтеграції.

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

Профіль доступу BAS

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

Наприклад, профіль “Менеджер продажів” може включати:

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

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

Групи доступу

Групи доступу дозволяють керувати правами груп користувачів.

Приклади груп:

Бухгалтерія;
Відділ продажів;
Відділ закупівель;
Склад Київ;
Склад Львів;
HR;
Фінанси;
Керівники;
Адміністратори;
Зовнішні аудитори;
Інтеграційні користувачі.

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

RLS у BAS

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

Приклади RLS:

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

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

Приклад RLS по складах

Користувач	Склад Київ	Склад Львів	Склад Одеса
Комірник Київ	Так	Ні	Ні
Комірник Львів	Ні	Так	Ні
Керівник логістики	Так	Так	Так

Якщо RLS не налаштований, комірник одного складу може випадково створити документ на інший склад.

Приклад RLS по організаціях

Користувач	ТОВ “Компанія 1”	ТОВ “Компанія 2”	ФОП
Бухгалтер 1	Так	Ні	Ні
Бухгалтер 2	Ні	Так	Ні
Головний бухгалтер	Так	Так	Так

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

Приклад RLS по менеджерах

Менеджер продажів може бачити тільки своїх клієнтів і документи.

Приклад:

Користувач	Свої клієнти	Клієнти відділу	Усі клієнти
Менеджер	Так	Ні	Ні
Керівник відділу	Так	Так	Ні
Комерційний директор	Так	Так	Так

Таке обмеження захищає клієнтську базу і зменшує хаос у продажах.

Повні права BAS

Повні права — це максимальний доступ у системі.

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

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

Небезпека. Повні права не можна видавати “щоб не було питань”. Це найчастіше джерело витоків, помилок, випадкових змін, неконтрольованих обробок і проблем при аудиті.

Кому можна давати повні права

Повні права можуть бути потрібні:

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

Краще правило:

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

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

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

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

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

Доступ до конфігуратора

Конфігуратор — це режим, у якому можна змінювати структуру системи.

Доступ до конфігуратора дозволяє:

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

Цей доступ має бути суворо обмежений.

Погано:

У кожного бухгалтера є доступ до конфігуратора.

Краще:

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

Доступ до зовнішніх обробок

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

Вони можуть:

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

Перед запуском зовнішньої обробки потрібні:

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

Доступ до зарплати

Зарплатні дані є чутливими.

Потрібно обмежувати:

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

Зарплату мають бачити тільки ті користувачі, яким це потрібно за посадовими обов’язками.

Доступ до банку і платежів

Банківський блок потребує суворих прав.

Потрібно розділяти:

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

Приклад:

Роль	Створення заявки	Погодження	Експорт у банк
Менеджер	Так	Ні	Ні
Керівник	Ні	Так	Ні
Фінансист	Так	Так	Так
Бухгалтер	Ні	Ні	Так

Доступ до ПДВ

ПДВ є важливим податковим контуром.

Потрібно обмежувати:

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

Помилки в ПДВ можуть мати фінансові наслідки, тому доступ має бути контрольований.

Доступ до собівартості

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

Її не завжди мають бачити:

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

Можливі правила:

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

Доступ до складу

Складські права мають контролювати:

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

Погано, коли комірник одного складу може списати товар з іншого складу.

Доступ до продажів

У продажах потрібно контролювати:

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

Приклад:

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

Доступ до закупівель

У закупівлях контролюють:

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

Закупівельник не завжди має бачити всі фінансові звіти компанії.

Доступ до виробництва

У виробництві права можуть бути розділені між:

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

Потрібно обмежувати:

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

Доступ до звітів

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

Потрібно обмежувати:

фінансові звіти;
зарплатні звіти;
управлінський P&L;
ДДС;
собівартість;
маржу;
дебіторку;
кредиторку;
залишки з сумами;
Power BI-вивантаження;
Excel-експорт.

Звіт “Продажі” може бути безпечним для менеджера, а звіт “Продажі з маржею і собівартістю” — ні.

Доступ до Excel-експорту

BAS часто дозволяє вивантажувати звіти в Excel.

Це створює ризики:

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

Для критичних звітів потрібно обмежувати експорт або контролювати, хто і що вивантажує.

Доступ до інтеграцій

Інтеграційні користувачі мають мати мінімальні права.

Приклади:

Користувач	Призначення	Права
site_exchange	Обмін із сайтом	Замовлення, залишки, статуси
bank_exchange	Банк	Виписки, платежі
wms_exchange	WMS	Складські документи
powerbi_export	BI	Читання погоджених даних

Погано, коли інтеграція працює під користувачем із повними правами.

Спільні логіни

Спільні логіни — одна з найгірших практик.

Приклад:

Логін: Бухгалтерія
Пароль знають усі бухгалтери.

Проблеми:

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

Правильний принцип:

Одна людина = один користувач = персональна відповідальність.

Блокування користувачів

Користувача потрібно блокувати, якщо:

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

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

Журнал реєстрації BAS

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

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

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

Журнал потрібен для аудиту, розслідування інцидентів і міграційної перевірки.

Аудит прав доступу

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

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

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

Звіт по користувачах BAS

Корисний звіт:

Користувач	Статус	Профіль	Останній вхід	Ризик
ivanenko.i	Активний	Менеджер продажів	15.05.2026	Немає
petrenko.p	Активний	Бухгалтер	14.05.2026	Доступ до банку
admin	Активний	Повні права	15.05.2026	Критичний доступ
old.user	Активний	Менеджер	01.10.2024	Неактивний користувач

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

Помилка	Причина	Наслідок
Усім дають повні права	Щоб не було скарг	Витік, помилки, відсутність контролю
Один логін на відділ	Так простіше	Немає персонального аудиту
Не блокують звільнених	Немає процесу offboarding	Колишні працівники мають доступ
Не обмежують зарплату	Ролі налаштовані грубо	Витік персональних даних
Не обмежують склад	Немає RLS	Документи створюються не на той склад
Інтеграції під адміністратором	Швидко налаштували обмін	Надмірні ризики
Доступ до конфігуратора у зайвих людей	Немає контролю адміністрування	Ризик зміни системи

Помилка: усім дали повні права

Це типова помилка старих баз.

Причини:

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

Наслідки:

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

Помилка: користувач звільнився, але доступ залишився

Після звільнення потрібно:

заблокувати користувача BAS;
змінити паролі спільних логінів, якщо вони були;
відкликати доступ до RDP/VPN;
перевірити доступ до архівних баз;
перевірити доступ до Excel-вивантажень;
перевірити API-токени, якщо були;
передати відповідальність за документи іншій людині.

Не потрібно видаляти користувача, якщо його дії вже пов’язані з документами.

Помилка: RLS не налаштований

Якщо RLS не налаштований, користувачі бачать зайві дані.

Приклади:

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

Це створює ризики і помилки в роботі.

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

Тестові бази часто копіюються з робочих.

Проблема:

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

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

змінити назву;
обмежити доступ;
вимкнути інтеграції;
вимкнути регламентні завдання;
перевірити користувачів;
додати позначку “ТЕСТ”.

Права BAS і міграція в K2 ERP

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

Потрібно:

інвентаризувати користувачів;
знайти активних користувачів;
знайти неактивних користувачів;
знайти спільні логіни;
знайти користувачів із повними правами;
перевірити доступ до зарплати;
перевірити доступ до банку;
перевірити доступ до собівартості;
перевірити доступ до конфігуратора;
знайти інтеграційних користувачів;
описати нову рольову модель;
створити ролі K2 ERP;
налаштувати audit log;
заблокувати старі небезпечні доступи.

Чому не можна копіювати права 1:1

Права BAS часто накопичувалися роками.

Проблеми старої моделі:

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

Перехід у K2 ERP — це можливість побудувати чисту модель доступу.

Карта міграції прав BAS у K2 ERP

Об’єкт BAS	Що означає	Аналог у K2 ERP	Що перевірити
Користувач	Обліковий запис	User	Активність, email, працівник
Роль	Технічні права	Role	Не копіювати без аналізу
Профіль доступу	Прикладний набір прав	Access profile	Переглянути бізнес-логіку
Група доступу	Об’єднання користувачів	User group	Очистити старі групи
Організація	Обмеження по юрособі	Company access	Звірити з актуальною структурою
Склад	Обмеження по складу	Warehouse access	Звірити з логістикою
RLS	Обмеження записів	Row-level access	Перевірити правила
Інтеграційний користувач	Обмін із системами	API user	Мінімальні права, токени

Приклад нової рольової моделі K2 ERP

Роль K2 ERP	Доступ	Обмеження
Менеджер продажів	Клієнти, угоди, замовлення	Тільки свої клієнти або свій відділ
Комірник	Складські операції	Тільки свій склад, без собівартості
Фінансист	Платежі, ДДС, бюджети	Без зарплатних деталей, якщо не потрібно
Бухгалтер	Первинні документи, ПДВ, облік	По своїх організаціях
HR	Кадрові документи	Персональні дані тільки у межах ролі
Зарплатний бухгалтер	Нарахування, утримання, виплати	Обмежений доступ до зарплати
Директор	Управлінські звіти	Повний перегляд без технічного адміністрування
API-користувач	Інтеграція	Тільки потрібні API-методи

Реплікатор K2 і права BAS

Реплікатор K2 може допомогти при підготовці міграції прав із BAS у K2 ERP.

Він може використовуватися для:

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

Архів BAS після міграції

Після переходу в K2 ERP стару BAS-базу можна залишити як архів.

Права в архіві мають бути обмежені:

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

Архів BAS не повинен залишатися другою робочою системою.

Санкції та ризики BAS у контексті прав доступу

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

1С історично є російською програмною екосистемою, а BAS і BAF пов’язані з цією технологічною спадщиною. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де станом на опублікований перелік згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до персональних спеціальних економічних та інших санкцій. ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009))

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

Типові питання

Що таке права доступу BAS?

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

Чим роль відрізняється від профілю доступу?

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

Що таке RLS у BAS?

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

Чому небезпечно давати повні права?

Повні права дозволяють бачити й змінювати майже все. Це створює ризик витоку зарплати, фінансів, собівартості, випадкових змін, запуску небезпечних обробок і проблем з аудитом.

Чи можна переносити права BAS у K2 ERP один в один?

Ні. Права BAS часто накопичувалися хаотично. При переході в K2 ERP потрібно побудувати нову рольову модель, а не копіювати старі помилки.

Що робити зі старими правами BAS після міграції?

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

Коротко

Питання	Відповідь
Що це?	Механізм керування діями і видимістю даних у BAS.
Основні елементи	Користувачі, ролі, профілі, групи, RLS, обмеження.
Головний ризик	Повні права, спільні логіни, звільнені користувачі, небезпечні обробки.
Що захищати?	Зарплату, банк, ПДВ, собівартість, клієнтів, склади, інтеграції, конфігуратор.
При міграції	Права не копіювати 1:1, а будувати нову модель у K2 ERP.
Архів BAS	Тільки для читання, без інтеграцій і без зайвих користувачів.

Висновок

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

Найбільші проблеми старих BAS-баз зазвичай пов’язані не з відсутністю прав, а з їх хаотичністю: повні права у багатьох користувачів, спільні логіни, доступ звільнених працівників, інтеграції під адміністратором, відсутність RLS, зайвий доступ до зарплати й собівартості, тестові бази з реальними правами.

Правильна модель доступу — це не максимальний доступ “щоб працювало”, а мінімально необхідний доступ “щоб було безпечно і контрольовано”.

При переході з BAS або 1С у K2 ERP права доступу потрібно не переносити механічно, а переглядати: очистити користувачів, прибрати спільні логіни, заблокувати старі облікові записи, обмежити зарплату, банк, собівартість, API, Power BI, побудувати нові ролі, налаштувати audit log і залишити стару BAS-базу тільки як захищений архів для читання.

Див. також

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