Користувач K2 ERP
| ; ivanenko
</syntaxhighlight> Права на собівартість потрібно виділяти окремо.; Права на експорт потрібно обмежувати й журналювати.; # Створити користувачів.; як ілюстрація: користувач системи має отримувати тільки ті права, які потрібні для його роботи.; Поле Тимчасові користувачі
Добрі практики: Журнал має змогу фіксувати: Деякі користувачі можуть мати права на друк документів.;== Див.; додатково == У будь-якій ERP-системі користувач системи — це точка входу в бізнес-процеси.; !; # Перепризначити документи.; Це частина системи контролю доступу забезпечується через Головне. користувач системи K2 ERP — це не без ускладнень логін; додатково реалізовано відповідальності, безпеки, журналювання, бізнес-процесів і цифрової дисципліни підприємства.; # Створити персональні облікові записи.; Типові ролі K2 ERP у цьому процесі має змогу стати платформою для контрольованих користувачів, ролей, груп доступу, сервісних акаунтів, API, BI-аналітики, журналювання, прав доступу, резервного копіювання, web-доступу й подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми BAS / 1С.; Окремо варто відзначити через який виконується вхід, робота з довідниками, документами, звітами, бізнес-процесами, інтеграціями, BI-аналітикою і іншими функціями ERP-системи виступає ключовою рисою користувач системи K2 ERP.; # Описати ролі.; | ||
|---|---|---|
| api_site | інтеграційні функціональні можливості із сайтом | Замовлення, товари, залишки, статуси |
| api_wms | інтеграційні функціональні можливості зі складом | Складські документи, залишки, переміщення |
| api_crm | інтеграційні функціональні можливості з CRM | Клієнти, угоди, статуси |
| bi_export | Передача даних у BI | Читання аналітичних даних |
| bank_import | Імпорт банківських операцій | Банківські документи |
!; !;== Підрозділ користувача == Приклад: Приклад: Робочий стіл користувача має змогу відображати:
Двофакторна автентифікація
|- | Замовлення покупця | Створення і зміна | Перегляд | Перегляд |- | Реалізація | Створення | Перегляд | Проведення |- | Складські залишки | Перегляд | Зміна через документи | Перегляд |- | Собівартість | Немає доступу | Немає доступу | Перегляд |- | Каса | Немає доступу | Немає доступу | Повний доступ |}
Як не треба робити
Погані підходи:
Після звільнення потрібно:
- випадкових помилок;
- несанкціонованих змін;
- витоку даних;
- конфлікту обов’язків;
- зловживань;
- хаосу в документах;
- неконтрольованого експорту даних.; # Перевірити доступи.;== користувач системи і журналювання ==
- строк дії доступу;
- обмежені права;
- відповідального;
- журналювання;
- дату блокування.; # Навчити користувачів.; sklad / пароль для всіх комірників
!;
</syntaxhighlight>
!; Менеджер
- задачі;
- документи в роботі;
- KPI;
- повідомлення;
- швидкі дії;
- звіти;
- фільтри;
- обрані функції.;== користувач системи K2 ERP і цифрова незалежність ==
Правильний порядок: api_site Кожна важлива дія користувача має журналюватися.;== Типи користувачів K2 ERP ==
Користувачі можуть мати доступ до персональних даних.; # Заблокувати обліковий запис.; !; | Активних користувачів, ролі, групи, адміністраторів, сервісні акаунти, спільні логіни й зайві права.; Дата
як ілюстрація: Погана практика — підключати сайт, CRM або WMS під адміністратором.; Роль у K2 ERP
Це зменшує кількість помилок при введенні документів.; | Так.;== користувач системи і повідомлення ==
Погані практики:
buh / пароль для всієї бухгалтеріїПомилка: не заблокували користувача після звільнення
</syntaxhighlight>
| Бізнес-користувач | Працівник, який виконує операції | Менеджер, бухгалтер, комірник |
| Керівник | користувач системи для контролю й аналітики | Директор, фінансовий директор, керівник складу |
| Адміністратор | користувач системи для налаштувань системи | ERP-адміністратор |
| Сервісний користувач системи | Технічний акаунт для інтеграцій | api_site, api_wms, bi_export |
| Аудитор | користувач системи для перегляду й перевірки | Внутрішній або зовнішній аудитор |
Найгірший сценарій. організація переходить у K2 ERP, але копіює стару модель BAS: спільні логіни, зайві права, активні звільнені користувачі, інтеграції під адміністратором і відсутність журналювання.; * усіх документів;
- зарплати;
- фінансів;
- адміністрування;
- зміни ролей.; |-
| Що таке сервісний користувач системи?; |- | Що робити зі звільненим користувачем?; Роль Погано: |- | Менеджер продажів | Створення клієнтів, замовлень, рахунків, перегляд статусів |- | Комірник | Приймання, переміщення, списання, інвентаризація |- | Бухгалтер | Каса, банк, проводки, податкові документи, формування звітів |- | Касир | Касові операції, оплати, повернення |- | Закупівельник | Постачальники, замовлення постачальникам, надходження |- | Логіст | Доставка, маршрути, рейси, статуси відвантажень |- | Керівник | Звіти, BI, контроль KPI |- | Адміністратор | конфігурація, користувачі, ролі, довідники, інтеграції |}
Автентифікація — це перевірка, що користувач системи є собою тим, за кого себе видає.;== Чому не можна без ускладнень скопіювати користувачів із BAS ==
- K2
- K2 ERP
- ERP
- BAS
- 1С
- Права доступу
- Ролі K2 ERP
- Групи користувачів K2 ERP
- API
- BI
- Журналювання
- Кібербезпека
- Конфігурація BAS
- Клієнт-серверний режим BAS
- Файловий режим BAS
- Резервна копія 1С
- Журнал реєстрації 1С
- Web-сервіси 1С
- JSON 1С
- Інтеграція з BAS
- Інтеграція з 1С
- Міграція з BAS
- Міграція з 1С
- Заміна BAS
- Заміна 1С
- Оперативний облік 1С
- Регламентований облік 1С
- Довідники 1С
- Документи 1С
- Українське програмне забезпечення
- Автоматизація бізнесу
- Цифрова незалежність
- Деколонізація обліку
!; Тип Після запуску K2 ERP потрібно перевірити:
користувач системи і відповідальність
|- | admin | Активний | Адміністратор | Створити окремий контрольований admin-доступ |- | manager | Спільний логін | Не переносити | Створити персональні логіни менеджерам |- | ivanenko | Активний | Менеджер продажів | Перенести як персонального користувача |- | old_buh | Звільнений | Немає | Не переносити, залишити в архіві історії |- | api_site | Сервісний | API сайту | Створити новий API-доступ з обмеженими правами |}
Погано:
Людина і користувач системи
- Описати організаційну структуру.; Підрозділ
|- | buh_kyiv | ТОВ Київ | Бухгалтерські документи ТОВ Київ |- | buh_lviv | ТОВ Львів | Бухгалтерські документи ТОВ Львів |- | fin_dir | Усі організації | Консолідована фінансова аналітичні інструменти |}
!; Видалення користувача має змогу створити проблеми, якщо на нього посилаються документи, журнали або історичний розвиток.; Статус
Етапи конфігурація користувачів у K2 ERP
як ілюстрація:
- список користувачів;
- активних користувачів;
- заблокованих користувачів;
- адміністраторів;
- сервісних користувачів;
- користувачів інтеграцій;
- ролі;
- групи;
- фактичні обов’язки;
- підрозділи;
- права на звіти;
- права на обробки;
- права на закриті періоди.; {| class="wikitable" style="width:100%;"
- кожен працівник має власний логін;
- кожна дія прив’язана до конкретного користувача;
- сервісні інтеграції мають окремі технічні облікові записи;
- звільнені користувачі блокуються;
- права видаються за ролями.;
Експорт даних — окрема зона ризику.;
Права доступу
!; # Зберегти історію дій.;== Приклад журналу дій ==
Потрібно контролювати:
!; # Перевірити права на тестових сценаріях.;== Паролі ==
- аудиту;
- консультантів;
- зовнішніх інтеграторів;
- тестування;
- навчання;
- тимчасових працівників;
- стажерів.; {| class="wikitable" style="width:100%;"
bi_export → BI !; У BI користувачі додатково мають різні права.; Об’єкт / Роль !;
Журналювання потрібне для безпеки, аудиту й розслідування помилок.; це обліковий запис людини або сервісу в системі K2 ERP.; Бухгалтер
!; Потрібно створити нову рольову модель, очистити користувачів, заблокувати старі доступи, розділити бізнес-користувачів і сервісні акаунти, налаштувати журналювання й перевірити права на практичних сценаріях.;
sklad.kyiv.01
Простий приклад:
- створювати користувачів;
- блокувати користувачів;
- змінювати ролі;
- налаштовувати доступи;
- керувати довідниками;
- налаштовувати інтеграції;
- переглядати журнали;
- виконувати службові операції;
- допомагати користувачам;
- контролювати технічні конфігурація.; # Документувати зміни в доступах.; Призначення
- працівників;
- клієнтів;
- фізичних осіб;
- пайовиків;
- контактних осіб;
- водіїв;
- пацієнтів або інших осіб, якщо це галузеве рішення для бізнесу.; Підхід K2 ERP. У K2 ERP користувач системи має бути прив’язаний до реальної ролі в бізнесі: бухгалтер, менеджер, комірник, керівник, касир, логіст, адміністратор, інтегратор, сервісний користувач системи або інша роль.; користувач системи
- Сайт K2 ERP
- Wiki K2 ERP
- хмарна інфраструктура K2 ERP
- Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку
- Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ
- Указ Президента України №601/2024
- Указ Президента України №601/2024 на сайті Верховної Ради України
- Telegram-канал K2 ERP
- Група обговорення функціоналу та пропозицій
- LinkedIn K2
Висновок
Приклади: Під час переходу з BAS або 1С у K2 ERP потрібно проаналізувати старих користувачів.; Через користувачів платформа розуміє: Він має змогу:
користувач системи і собівартість
Мова і локальні конфігурація
Автентифікація
buh
У K2 ERP потрібно створювати нову модель доступу, а не переносити старий хаос.; # Налаштувати організації.;== Помилка: усі адміністратори ==
Користувачі можуть брати участь у бізнес-процесах.; # Перевірити зовнішні інтеграції.; * логін;
- пароль або інший спосіб автентифікації;
- ПІБ;
- email;
- телефон;
- роль;
- групу доступу;
- підрозділ;
- організацію;
- посаду;
- статус активності;
- мову інтерфейсу;
- конфігурація інтерфейсу;
- права на довідники;
- права на документи;
- права на звіти;
- права на інтеграції;
- журнал дій.; Найчастіші проблеми:
Для складських і торгових ролей істотно мати складський облік за замовчуванням.;
Роль користувача
| Це обліковий запис людини або сервісу, через який виконується робота в системі.; |- | Які довідники, документи, звіти, обробки, BI-дані та API-методи доступні користувачу.; Доступ
Але не повинен: Права на друк теж можуть бути частиною контролю.; # Визначити сервісних користувачів.; рішення для бізнесу Приклад: Аудиторський доступ
користувач системи K2 ERP — це обліковий запис, який надає можливість людині або сервісу працювати із системою.; # Заблокувати старі BAS-доступи після запуску.; завдяки наявності Підрозділ користувачі можуть обмежувати або структурувати доступ.; Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.; Керівник user користувач системи і робочий стіляк ілюстрація: Сервісний користувач системи — це технічний обліковий запис для інтеграцій або автоматичних процесів.; # Описати ролі.; У результаті нова ERP успадковує старі ризики.; Дія |
; # Описати групи користувачів.; Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; Комірник
користувач системи і бізнес-процеси
Сервісний користувач системиПриклад:
користувач системи має змогу отримувати повідомлення: Повідомлення допомагають не втрачати важливі події.; Адміністраторські права мають бути обмежені й контрольовані.; як ілюстрація: Під час переходу з BAS/1С у K2 ERP організація повинна: | |
|---|---|---|---|
| 15.05.2026 10:15 | ivanenko | Створено документ | Замовлення покупця №123 |
| 15.05.2026 10:20 | petrenko.buh | Проведено документ | Банківська виписка №45 |
| 15.05.2026 11:05 | admin | Змінено роль | користувач системи sklad01 |
| 15.05.2026 12:30 | api_site | API-запит | Створення замовлення WEB-100245 |
користувач системи має змогу мати персональні конфігурація:
Сервісний користувач системи не повинен мати зайвих прав.; # Розділити бізнес-користувачів і сервісні акаунти.; як ілюстрація:
!; Дія
!; |-
| Чи можна інтеграції запускати під адміністратором?; * дату заборони редагування;
* права на зміну старих документів;
* права на перепроведення;
* права на коригування;
* журнал змін;
* погодження головного бухгалтера;
* аварійний доступ.; Приклад доступу
Під час переходу з [[BAS]] або [[1С]] у [[K2 ERP]] не потрібно переносити стару модель доступу “як є собою”.; # Перевірити відкриті задачі.; | Ні.; !; Група
== користувач системи і друковані форми ==
== Контроль після запуску ==
* які методи доступні;
* які інформаційні дані можна читати;
* які інформаційні дані можна змінювати;
* які ліміти діють;
* які журнали ведуться;
* хто відповідальний;
* коли змінювався ключ доступу.;== Таблиця міграції користувачів ==
* логін і пароль;
* корпоративний обліковий запис;
* одноразовий код;
* двофакторна автентифікація;
* токен;
* інтеграційні функціональні можливості з каталогом користувачів;
* API-ключ для сервісних користувачів.; !;== Помилка: один логін на відділ ==
== користувач системи і персональні інформаційні дані ==
користувач системи не повинен випадково створювати касові документи в чужій касі.; * рахунків;
* накладних;
* актів;
* касових ордерів;
* податкових документів;
* договорів;
* етикеток;
* ТТН.; При звільненні працівника користувача не обов’язково видаляти.;[[Категорія:API]]
== Матриця доступу ==
Права можуть бути:
!; Її не завжди мають бачити:
* менеджер продажів не повинен бачити зарплату;
* комірник не повинен змінювати ціни продажу;
* касир не повинен редагувати складські документи;
* інтеграційний користувач системи не повинен мати права адміністратора;
* аудитор не повинен змінювати документи.; !; * спільні логіни;
* усі користувачі мають адміністративні права;
* немає ролей;
* ролі не відповідають посадам;
* звільнені користувачі активні;
* сервісні користувачі мають зайві права;
* немає журналювання;
* немає матриці доступу;
* користувачі бачать зарплату або собівартість без потреби;
* немає обмеження по складах;
* немає обмеження по організаціях;
* права не переглядаються роками.; |}
[[Категорія:K2]]
Аудитор має змогу бачити:
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
* контролювати дії;
* захищати інформаційні дані;
* обмежувати доступ;
* розділяти ролі;
* уникати спільних логінів;
* захищати зарплату, фінансовий блок й собівартість;
* контролювати інтеграції;
* вести аудит;
* підтримувати порядок у бізнес-процесах.; Доступ
!; Об’єкт
Адміністратор має розширені права.;== користувач системи і складські інформаційні дані ==
Потрібно зібрати:
як ілюстрація:
!; !; з цієї причини під час переходу в [[K2 ERP]] потрібно не копіювати стару хаотичну модель користувачів із BAS/1С, а створювати нову контрольовану модель ролей, доступів і відповідальності.; # Описати групи доступу.; Об’єкт
{{DISPLAYTITLE:Користувач K2 ERP}}
Роль має відповідати реальній роботі людини.; # Визначити критичні інформаційні дані.; # Налаштувати підрозділи.; | Бо неможливо встановити відповідального за дії, помилки або зміни.; Одна людина має змогу мати один або кілька облікових записів, але в нормальній практиці краще мати один персональний обліковий запис для кожної людини.; * хто створив документ;
* хто змінив довідник;
* хто провів операцію;
* хто затвердив заявку;
* хто переглянув звіт;
* хто змінив ціну;
* хто списав товар;
* хто відкрив фінансову інформацію;
* хто запустив інтеграцію;
* хто виконав адміністративну дію.; користувач системи
* заблокувати користувача;
* зняти ролі;
* заборонити вхід;
* залишити історію дій;
* змінити власника відкритих задач;
* перевірити активні інтеграції.; manager
'''Цифрова незалежність.''' Перехід у [[K2 ERP]] — це можливість не тільки замінити BAS або 1С, а й навести порядок у користувачах, ролях, доступах, сервісних акаунтах, журналах і відповідальності.;<syntaxhighlight lang="text">
Без правильної моделі користувачів ERP оперативно перетворюється на хаос: усі бачать усе, адміністраторські права роздані зайвим людям, документи змінюються без контролю, а відповідальність за помилки неможливо встановити.;</div>
як ілюстрація:
Аудиторський доступ зазвичай має бути тільки для перегляду.; Хто це
{| class="wikitable" style="width:100%;"
{{SEO
|title=Користувач K2 ERP — обліковий запис, ролі, права доступу, групи, безпека і міграція з BAS
|description=Користувач K2 ERP: що це таке, як налаштовуються облікові записи, ролі, права доступу, профілі, групи, підрозділи, сервісні користувачі, журналювання, безпека, типові помилки і міграція користувачів з BAS та 1С у K2 ERP.
|keywords=користувач K2 ERP, користувач ERP, користувач BAS, користувач 1С, права доступу K2 ERP, ролі K2 ERP, групи користувачів K2 ERP, профіль користувача, обліковий запис ERP, сервісний користувач, адміністратор K2 ERP, журналювання K2 ERP, міграція користувачів з BAS, міграція користувачів з 1С, заміна BAS, заміна 1С, українська ERP, санкції BAS, санкції 1С, цифрова незалежність
|image=https://erp.kyiv.ua
}}
|-
| ivanenko
| Менеджер продажів
| Відділ продажів
| Клієнти, замовлення, рахунки
|-
| petrenko
| Бухгалтер
| бухгалтерський обліковий облік
| Банк, каса, проводки, формування звітів
|-
| sklad01
| Комірник
| складський облік
| Надходження, переміщення, інвентаризація
|-
| api_site
| Сервісний користувач системи
| Інтеграції
| API для сайту
|}
== Адміністратор K2 ERP ==
як ілюстрація:
користувач системи [[K2 ERP]] — це важлива частина ERP-системи, яка відповідає не тільки за вхід у систему, а й за права доступу, відповідальність, безпеку, журналювання, бізнес-процеси, інтеграції та аналітику.;== Вступ ==
Тимчасові користувачі можуть створюватися для:
!; Питання
|-
| Створення замовлення
| Менеджер
| Вводить клієнта і товари
|-
| Перевірка боргу
| Бухгалтер
| Перевіряє оплату або ліміт
|-
| Резерв
| складський облік
| Резервує товар
|-
| Відвантаження
| Комірник
| Підтверджує відвантаження
|-
| Контроль
| Керівник
| Переглядає звіт
|}
Пароль має бути достатньо складним і персональним.;== користувач системи і закриті періоди ==
== Що таке користувач системи K2 ERP ==
|-
| Контрагенти
| Створення
| Перегляд
| Зміна
| Перегляд
| Повний доступ
|-
| Замовлення
| Створення і зміна
| Перегляд
| Перегляд
| Перегляд
| Повний доступ
|-
| Складські документи
| Перегляд
| Створення
| Перегляд
| Перегляд
| Повний доступ
|-
| Каса
| Немає
| Немає
| Повний доступ
| Перегляд
| Повний доступ
|-
| Зарплата
| Немає
| Немає
| Обмежений доступ
| Перегляд за дозволом
| Повний доступ
|-
| Адміністрування
| Немає
| Немає
| Немає
| Немає
| Повний доступ
|}
Профіль користувача має змогу містити:
[[Категорія:Інтеграція з 1С]]
* чи всі користувачі можуть увійти;
* чи ніхто не має зайвих прав;
* чи працюють ролі;
* чи працюють обмеження по організаціях;
* чи працюють обмеження по складах;
* чи працюють сервісні користувачі;
* чи ведеться журнал дій;
* чи заблоковані старі користувачі BAS;
* чи не працюють старі інтеграції;
* чи користувачі не вводять документи в дві системи.; Правильний підхід:
== Зовнішні посилання ==
* багато старих користувачів;
* звільнені працівники не заблоковані;
* усі мають надмірні права;
* інтеграції працюють під адміністратором;
* невідомо, хто використовує який логін;
* групи доступу не відповідають реальним посадам;
* тестові користувачі залишилися активними;
* немає опису ролей;
* один логін використовують кілька людей.; Якщо в системі кілька юридичних осіб, користувач системи має змогу мати доступ:
'''Правильний підхід.''' Користувачі [[K2 ERP]] мають налаштовуватися через ролі, групи, підрозділи, організації, склади, каси, права доступу й журналювання.; Краще:
== Приклади ролей ==
</div>
* прибрати спільні логіни;
* заблокувати старі доступи;
* створити нову рольову модель;
* обмежити зайві права;
* захистити персональні й фінансові інформаційні дані;
* замінити старі сервісні акаунти;
* перевести інтеграції на контрольований API;
* вести журнал дій;
* не залишати BAS активною робочою системою.; | Це технічний акаунт для інтеграцій, API, обмінів або автоматичних процесів.; # Увімкнути журналювання важливих дій.; * менеджер продажів;
* бухгалтер;
* центральний бухгалтер;
* комірник;
* касир;
* закупівельник;
* логіст;
* кадровик;
* керівник;
* адміністратор;
* інтегратор;
* аудитор.; |-
| Чи є собою санкційні ризики у [[BAS]] і [[1С]]?; Краще створювати окремого сервісного користувача для кожної інтеграції.; користувач системи
* один пароль для всіх;
* пароль `123456`;
* пароль збігається з логіном;
* пароль записаний на папірці біля монітора;
* пароль адміністратора знають усі;
* пароль сервісного користувача не змінюється роками;
* звільнений працівник зберігає доступ.; Бухгалтер
__TOC__
* менеджер Києва створює замовлення з Основного складу;
* комірник філії бачить тільки складський облік Львів;
* інтернет-магазин резервує товар на складі E-commerce;
* виробництво списує матеріали зі складу Виробництво.; як ілюстрація, сайт має доступ до:
* бухгалтерський обліковий облік;
* продажі та реалізація;
* закупівельна діяльність;
* складський облік;
* Каса;
* Логістика;
* Виробництво;
* Керівництво;
* Адміністратори;
* Інтеграції;
* Аудитори.; * неможливо встановити відповідального;
* складно розслідувати помилки;
* немає персональної історії;
* пароль оперативно поширюється;
* звільнений працівник має змогу знати доступ.; користувач системи у [[K2 ERP]] має права доступу, ролі, профіль, конфігурація, підрозділ, організацію, історію дій і відповідальність за операції, які він виконує в системі.;[[Категорія:Групи користувачів]]
як ілюстрація:
* інтеграційні функціональні можливості має змогу змінити зайві інформаційні дані;
* складно зрозуміти джерело помилки;
* неможливо розділити відповідальність;
* при витоку пароля зловмисник отримує повний доступ;
* журнал дій показує адміністратора, а не реальний сервіс;
* неможливо обмежити API.; Комірник
api_wms → складська платформа
== Організація користувача ==
== Типові помилки в налаштуванні користувачів ==
|-
| Логін
| ivanenko
|-
| ПІБ
| Іваненко Іван Іванович
|-
| Посада
| Менеджер продажів
|-
| Підрозділ
| Відділ продажів
|-
| складський облік за замовчуванням
| ключовий складський облік
|-
| Роль
| Менеджер продажів
|-
| Статус
| Активний
|}
Можливі способи:
Користувачі можуть:
[[Категорія:Заміна BAS]]
* менеджер бачить тільки своїх клієнтів;
* комірник функціонує тільки зі своїм складом;
* касир бачить тільки свою касу;
* керівник бачить підлеглих;
* філія бачить тільки свої документи;
* директор бачить усю компанію.; # Налаштувати склади й каси за замовчуванням.; Доступ до персональних даних має бути обмежений реальними потребами роботи.; # Періодично переглядати права.; # Забрати активні ролі.; Погано:
[[Категорія:BI]]
Приклад:
* мова інтерфейсу;
* формат дати;
* формат чисел;
* часовий пояс;
* валюта за замовчуванням;
* вигляд списків;
* конфігурація звітів;
* обрані фільтри;
* робочий стіл.;</div>
== користувач системи і API ==
== складський облік за замовчуванням ==
== користувач системи і права на експорт ==
Вона особливо важлива для:
admin
api_site → сайт
{| class="wikitable" style="width:100%;"
!; У старій BAS/1С часто буває хаос:
[[Категорія:Клієнт-серверний режим BAS]]
!; # Заблокувати старі доступи в BAS після запуску.; # Перевірити API-ключі, якщо були.;[[Категорія:Міграція з BAS]]
Собівартість — чутлива відомості.; {| class="wikitable" style="width:100%;"
!;[[Категорія:Українське програмне забезпечення]]
!; petrenko.buh
'''істотно про BAS і 1С.''' [[BAS]] та [[1С]] мають санкційні, юридичні й кібербезпекові ризики в Україні.; * входу в систему;
* визначення прав;
* журналювання дій;
* персональних налаштувань;
* підписання або підтвердження операцій;
* участі в бізнес-процесах;
* відстеження відповідальності.; користувач системи
== Групи користувачів ==
== користувач системи після звільнення працівника ==
* адміністраторів;
* фінансових користувачів;
* користувачів із доступом до зарплати;
* користувачів із доступом до банку;
* користувачів із віддаленим доступом;
* користувачів із правами експорту;
* сервісів адміністрування.; Правильна модель користувачів сприяє встановити відповідальність.; Значення
* активний;
* заблокований;
* архівний;
* тимчасовий;
* сервісний;
* очікує конфігурація;
* звільнений.;== користувач системи і фінансові інформаційні дані ==
!; # Регулярно переглядати права.; * випадково змінити довідники;
* видалити інформаційні дані;
* змінити закриті документи;
* побачити зарплату;
* змінити права інших користувачів;
* запустити небезпечну обробку;
* експортувати конфіденційні інформаційні дані.; користувач системи у BAS
[[Категорія:Деколонізація обліку]]
Користувачі — це частина цифрової безпеки підприємства.; # Налаштувати підрозділи, склади, каси й організації.; Права мають видаватися за принципом мінімально необхідного доступу.;[[Категорія:Цифрова незалежність України]]
З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], конфігурація користувачів у [[K2 ERP]] має бути частиною ширшої стратегії переходу на українське програмне забезпечення, цифрову незалежність і сучасну [[ERP]]-архітектуру.; Якщо працівник звільнився, але доступ залишився, виникають ризики:
Якщо всім видати повні права, платформа стає неконтрольованою.; * змінювати документи;
* проводити документи;
* видаляти інформаційні дані;
* змінювати права;
* запускати критичні обробки.;[[Категорія:Права доступу]]
== Чому не можна використовувати адміністратора для інтеграцій ==
Для складу істотно розділяти доступ.; manager / пароль для всіх менеджерів
== Принцип мінімально необхідного доступу ==
* на перегляд;
* на створення;
* на зміну;
* на видалення;
* на проведення;
* на скасування проведення;
* на затвердження;
* на експорт;
* на друк;
* на запуск звітів;
* на запуск обробок;
* на адміністрування;
* на API-доступ.;
- усі менеджери працюють під одним логіном `manager`;
- усі комірники працюють під одним логіном `sklad`;
- бухгалтерський обліковий облік функціонує під одним логіном `buh`;
- адміністраторський пароль знають усі.; Якщо всі працюють під одним логіном, відповідальність зникає.; # Описати права доступу.; Фінансові інформаційні дані мають бути захищені.; !; користувач системи має змогу мати:
!; Відповідь
| продажі та реалізація | Менеджер, керівник продажів | Клієнти, замовлення, рахунки |
| складський облік | Комірник, керівник складу | Надходження, переміщення, залишки |
| бухгалтерський обліковий облік | Бухгалтер, центральний бухгалтер | Каса, банк, податки, проводки |
| Інтеграції | Сервісні користувачі | API, обміни, технічні операції |
!; !; !; {| class="wikitable" style="width:100%;"
У K2 ERP можна виділити кілька типів користувачів.; користувач системи має змогу мати статус:
- документи;
- звіти;
- журнали;
- довідники;
- проводки;
- історію змін.; Роль визначає, що користувач системи має змогу робити в системі.;== Обліковий запис ==
- хто змінив ціну;
- хто списав товар;
- хто провів касову операцію;
- хто видалив документ;
- хто відкрив зарплатний звіт;
- хто змінив реквізити контрагента;
- хто запустив імпорт;
- хто затвердив платіж.; Менеджер
як ілюстрація, менеджеру потрібні замовлення і клієнти, а бухгалтеру — банк, каса й формування звітів.; {| class="wikitable" style="width:100%;"
Це зменшує ризики:
- переносити всіх користувачів із BAS без аналізу;
- залишати спільні логіни;
- видавати всім повні права;
- не вести журнал дій;
- не блокувати звільнених користувачів;
- не розділяти бізнес-користувачів і сервісні акаунти;
- не обмежувати доступ до зарплати;
- не обмежувати доступ до собівартості;
- не перевіряти API-доступи;
- не переглядати права після запуску;
- ігнорувати санкційні й кібербезпекові ризики старої системи.; # Налаштувати мінімально необхідні права.; як ілюстрація:
- персональні паролі;
- періодична зміна для критичних ролей;
- блокування звільнених користувачів;
- окремі паролі для сервісних інтеграцій;
- журналювання входів;
- двофакторна автентифікація для важливих доступів.; Доступ
API-доступ має бути пов’язаний із конкретним сервісним користувачем.; Добре:
Користувачі не повинні довільно змінювати закриті періоди.; # Перевірити доступ до BI.;== Як правильно налаштовувати користувачів K2 ERP ==
Це небезпечно.;== Коротко ==
користувач системи і BI
- вхід у систему;
- вихід із системи;
- створення документа;
- зміну документа;
- проведення документа;
- скасування проведення;
- зміну довідника;
- зміну ціни;
- зміну прав;
- запуск обробки;
- експорт даних;
- помилки;
- API-запити;
- спроби доступу без прав.; |-
| Що перевірити при міграції з BAS?;== Видалення користувача ==
123 Краще: як ілюстрація:
!; У контексті переходу з BAS або 1С на K2 ERP користувачі мають особливе значення, з цієї причини що потрібно не без ускладнень перенести список логінів, а правильно побудувати нову модель доступу: хто що бачить, хто що має змогу створювати, хто має змогу проводити документи, хто має доступ до фінансів, зарплати, складу, собівартості, інтеграцій, адміністрування та аналітики.; Права доступу визначають, які дії дозволені користувачу.; !; Мета — не без ускладнень дати людям доступ, а створити контрольовану, безпечну й зрозумілу модель роботи.; # Обмежити доступ до зарплати, собівартості й фінансів.;
Для кожного API-користувача потрібно визначити:
Двофакторна автентифікація додає другий рівень захисту.; API-користувач має бачити тільки ті інформаційні дані, які потрібні для інтеграції.; Для кожної інтеграції краще створювати окремого користувача з обмеженими правами.; {| class="wikitable" style="width:100%;" Приклад: входу.; Не кожен користувач системи ERP має бачити фінансову інформацію.; # Перевірити корпоративну пошту.; Адміністратор Ризики: |- | Що таке користувач системи K2 ERP?; Правильно налаштовані користувачі дозволяють:
- несанкціонований вхід;
- витік даних;
- зміна документів;
- експорт клієнтської бази;
- доступ до фінансів;
- використання старого пароля іншими людьми.;<syntaxhighlight lang="text">
Для них потрібно вказувати: Для критичних ролей бажано використовувати посилений контроль входу.; Організація
- про нові задачі;
- про погодження;
- про помилки;
- про завершення обробки;
- про зміну статусу;
- про наближення строку;
- про перевищення ліміту;
- про відхилення в процесі.; До них можуть належати:
Обліковий запис — це технічне представлення користувача в системі.; Матриця доступу — це таблиця, яка показує, хто що має змогу робити.; {| class="wikitable" style="width:100%;"
!; * менеджери;
- комірники;
- касири;
- зовнішні користувачі;
- сервісні API;
- аудитори без відповідного дозволу.; |-
| Що визначає роль користувача?; !; api_crm → CRM
Він потрібен для:
Помилка: сервісний користувач системи має зайві права
- каса магазину;
- каса офісу;
- валютна каса;
- каса філії;
- каса кур’єра;
- каса ресторану.;
Активний і заблокований користувач системи
Користувачі при міграції з BAS або 1С
Профіль користувача
<syntaxhighlight lang="text"> Обліковий запис має бути унікальним.; Для касира або бухгалтера має змогу бути налаштована каса за замовчуванням.;== Каса за замовчуванням ==
Групи користувачів допомагають керувати доступами.; Приклад
- менеджер створює заявку;
- керівник погоджує знижку;
- бухгалтер перевіряє оплату;
- комірник підтверджує відвантаження;
- логіст призначає доставку;
- директор погоджує платіж;
- адміністратор змінює права.; | Заблокувати, зняти активні права, перепризначити задачі й залишити історію дій.; !; Часто краще заблокувати, щоб зберегти історію дій.; Основні функціональні можливості
- менеджер бачить свої продажі та реалізація;
- керівник відділу бачить продажі та реалізація свого підрозділу;
- директор бачить усю компанію;
- бухгалтер бачить фінансові показники;
- комірник бачить складські залишки;
- власник бачить консолідовану аналітику.; Приклад:
!; Роль