Веб-клієнт BAS

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

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

У практиці переходу з BAS на K2 ERP веб-клієнт має особливе значення, тому що web-доступ часто пов’язаний із зовнішніми ризиками: відкритими URL, HTTPS, паролями, сервісними користувачами, web-сервісами, API, інтеграціями, правами доступу, журналюванням і кібербезпекою.

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

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

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

Вступ

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

Типові сценарії:

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

Але web-доступ до облікової системи — це не просто зручність. Це ще й зона підвищеного ризику.

Потрібно контролювати:

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

Що таке веб-клієнт BAS

Веб-клієнт BAS — це режим роботи, у якому користувач відкриває інформаційну базу через браузер.

Спрощена схема:

Користувач → Браузер → Web-сервер → Сервер BAS/1С → Інформаційна база → Дані

Користувач бачить інтерфейс BAS у браузері й може виконувати дозволені дії:

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

Простими словами. Веб-клієнт BAS — це BAS у браузері. Користувач не відкриває файлову базу напряму і не обов’язково встановлює тонкий клієнт, а працює через web-адресу.

Чим веб-клієнт відрізняється від тонкого клієнта

Ознака	Веб-клієнт BAS	Тонкий клієнт BAS
Спосіб запуску	Через браузер	Через встановлений клієнтський застосунок
Встановлення на ПК	Зазвичай не потрібне повноцінне встановлення клієнта	Потрібне встановлення клієнта
Доступ	Через web-публікацію	Через підключення до бази
Зручність віддаленої роботи	Вища	Залежить від налаштувань
Безпекові ризики	Вищі при відкритому web-доступі	Менші, якщо доступ тільки всередині мережі
Інтерфейс	Може мати обмеження залежно від конфігурації	Часто повніший і стабільніший

Чим веб-клієнт відрізняється від файлового режиму

Файловий режим і веб-клієнт — це різні речі.

Ознака	Файловий режим BAS	Веб-клієнт BAS
Доступ до бази	Через файл або каталог бази	Через браузер і web-сервер
Типова архітектура	Локальна або мережева файлова база	Серверна публікація
Web-сервер	Не потрібен	Потрібен
Віддалений доступ	Небажаний напряму через файлову папку	Можливий через web-публікацію
Безпека	Залежить від файлових прав	Залежить від HTTPS, авторизації, ролей, мережі

Основні елементи веб-клієнта BAS

Для роботи web-клієнта зазвичай потрібні:

інформаційна база BAS;
сервер BAS / 1С;
web-сервер;
публікація інформаційної бази;
URL-адреса;
браузер;
користувачі;
ролі й права;
HTTPS-сертифікат;
мережеві правила;
журналювання;
резервне копіювання;
адміністрування.

Web-публікація інформаційної бази

Web-публікація — це налаштування, завдяки якому інформаційна база стає доступною через web-адресу.

Приклад адреси:

https://erp.company.ua/bas

Публікація визначає:

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

Web-сервер

Web-сервер приймає запити від браузера і передає їх до серверної частини BAS.

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

обробку HTTP/HTTPS-запитів;
маршрутизацію до інформаційної бази;
сертифікат HTTPS;
журнали доступу;
обмеження доступу;
роботу web-клієнта;
роботу HTTP-сервісів;
роботу web-сервісів;
публікацію кількох баз.

Сервер BAS / 1С

Сервер BAS/1С виконує бізнес-логіку.

У web-сценарії він обробляє:

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

Браузер користувача

Користувач працює через браузер.

Через браузер він може:

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

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

HTTPS

HTTPS потрібен для захищеного обміну між браузером і web-сервером.

Без HTTPS дані можуть передаватися незахищено.

Через web-клієнт можуть проходити:

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

Критично. Відкривати web-клієнт BAS у зовнішній мережі без HTTPS, сильних паролів, обмеження доступу й журналювання — небезпечно.

VPN і обмеження доступу

Для віддаленої роботи часто використовують VPN.

VPN допомагає:

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

Але VPN не замінює:

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

Користувачі веб-клієнта

Користувач web-клієнта має бути персональним.

Погано:

manager / один пароль для всіх
buh / спільний логін бухгалтерії
admin / використовується для роботи й інтеграцій

Добре:

ivanenko
petrenko.buh
sklad.kyiv.01
api_site

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

Ролі й права доступу

Web-клієнт не повинен відкривати користувачу більше прав, ніж потрібно.

Приклад:

Роль	Доступ через web-клієнт	Обмеження
Менеджер продажів	Клієнти, замовлення, рахунки	Немає доступу до зарплати й собівартості
Керівник	Звіти, BI, контрольні дані	Без зміни первинних документів
Комірник	Складські документи	Тільки свій склад
Бухгалтер	Каса, банк, податкові документи	За організаціями й періодами
Сервісний користувач	API або обмін	Тільки потрібні методи й дані

Сервісні користувачі у web-доступі

Web-публікація може використовуватися не тільки людьми, а й інтеграціями.

Наприклад:

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

Для цього не можна використовувати адміністратора.

Потрібні окремі сервісні користувачі:

api_site
api_crm
api_wms
bi_export
bank_import

Web-сервіси BAS

Через web-інфраструктуру можуть працювати web-сервіси.

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

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

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

HTTP-сервіси BAS

HTTP-сервіси можуть приймати або віддавати дані у форматах:

JSON;
XML;
текст;
CSV;
двійкові файли;
архіви;
спеціальні формати.

Приклад сценарію:

Сайт → HTTP-сервіс BAS → Створення замовлення покупця

Або:

WMS → HTTP-сервіс BAS → Отримання залишків по складах

Веб-клієнт і API

Веб-клієнт і API — не одне й те саме, але вони часто використовують спільну web-інфраструктуру.

Веб-клієнт — для роботи людини через браузер.

API — для обміну між системами.

Під час міграції потрібно розділити:

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

Веб-клієнт і віддалена робота

Веб-клієнт часто використовують для віддаленої роботи.

Приклади:

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

Для цього потрібні:

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

Веб-клієнт і мобільні пристрої

Теоретично web-доступ може відкриватися з мобільного браузера, але це не завжди зручно.

Проблеми:

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

Для мобільної роботи краще проєктувати окремі адаптовані сценарії в K2 ERP.

Веб-клієнт і продуктивність

На швидкість web-клієнта впливають:

сервер BAS/1С;
web-сервер;
СУБД;
мережа;
інтернет-канал;
браузер;
кількість користувачів;
складність форм;
важкі звіти;
регламентні завдання;
інтеграції;
нетипова конфігурація;
великі табличні частини;
обсяг даних.

Типові причини повільної роботи

Симптом	Можлива причина
Повільно відкриваються форми	Складна форма, слабкий сервер, повільна мережа
Довго формуються звіти	Великий обсяг даних, неоптимальні запити
Користувача викидає із сеансу	Проблеми мережі, таймаути, web-сервер
Не працює друк	Обмеження браузера або web-клієнта
Інтеграція зависає	API або HTTP-сервіс працює через перевантажений сервер

Веб-клієнт і друковані форми

У web-клієнті друковані форми можуть працювати інакше, ніж у тонкому клієнті.

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

рахунки;
накладні;
акти;
касові ордери;
податкові документи;
етикетки;
ТТН;
договори;
звіти;
PDF-формування;
завантаження файлів.

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

Веб-клієнт і завантаження файлів

Через web-клієнт користувачі можуть завантажувати або вивантажувати файли.

Наприклад:

Excel;
XML;
JSON;
PDF;
CSV;
скани документів;
архіви;
прайси;
банківські виписки;
зображення.

Це потрібно контролювати, бо файли можуть містити персональні або комерційні дані.

Веб-клієнт і журналювання

Журналювання допомагає зрозуміти, що відбувалося через web-доступ.

Потрібно фіксувати:

входи користувачів;
IP-адреси;
час входу;
помилки входу;
відкриття документів;
зміну документів;
запуск обробок;
експорт даних;
API-запити;
помилки web-сервісів;
спроби доступу без прав;
дії адміністраторів.

Веб-клієнт і резервне копіювання

Web-клієнт сам по собі не є базою даних, але web-інфраструктуру також потрібно враховувати в резервному копіюванні.

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

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

Веб-клієнт і безпека

Основні ризики:

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

Чек-лист безпеки web-клієнта

Перевірка	Навіщо
HTTPS увімкнено	Захист логінів, паролів і даних
Спільні логіни відсутні	Персональна відповідальність
Старі користувачі заблоковані	Захист від несанкціонованого доступу
Права обмежені	Мінімізація ризиків
API не працює під адміністратором	Контроль інтеграцій
Журналювання увімкнено	Аудит і розслідування
Доступ з інтернету обмежений	Зменшення поверхні атаки
Web-сервіси описані	Контроль інтеграцій

Веб-клієнт і міграція в K2 ERP

Під час переходу з BAS у K2 ERP web-клієнт потрібно аналізувати як частину старої архітектури.

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

список web-публікацій;
URL-адреси;
користувачів web-доступу;
ролі й права;
web-сервіси;
HTTP-сервіси;
інтеграції;
сервісні акаунти;
журнали доступу;
зовнішні IP або VPN;
сертифікати;
регламентні завдання;
друковані форми;
сценарії віддаленої роботи.

Приклад інвентаризації web-доступу

Об’єкт	Приклад	Рішення при міграції
Web-публікація	https://erp.company.ua/bas	Перевірити, хто користується
Web-сервіс	/ws/orders	Замінити API K2 ERP
Користувач	api_site	Створити новий сервісний акаунт у K2 ERP
Роль	Менеджер web	Перенести як роль K2 ERP після перегляду прав
Друкована форма	Рахунок PDF	Перенести або замінити в K2 ERP

Що переносити в K2 ERP

З web-клієнта BAS не переносять сам web-клієнт як такий.

Потрібно перенести або переосмислити:

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

Що не варто переносити механічно

Не потрібно переносити:

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

Архівний режим web-доступу

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

Але web-доступ до архіву потрібно обмежити.

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

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

Типові помилки з веб-клієнтом BAS

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

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

Помилка: web-клієнт відкритий для всіх

Якщо web-клієнт доступний з інтернету без обмежень, ризики зростають.

Наслідки:

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

Помилка: інтеграції працюють під адміністратором

Погано:

Сайт → BAS web-сервіс → користувач admin

Краще:

Сайт → API → api_site з обмеженими правами

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

Помилка: не знайти всі web-сервіси перед міграцією

Якщо не знайти всі web-сервіси, після запуску K2 ERP може зупинитися:

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

Помилка: залишити BAS активною після запуску K2 ERP

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

Ризики:

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

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

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

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

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

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

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

Зробити резервну копію.
Знайти всі web-публікації.
Знайти всі URL-адреси.
Перевірити HTTPS.
Перевірити VPN або мережеві обмеження.
Зібрати список користувачів.
Зібрати список сервісних акаунтів.
Перевірити ролі й права.
Знайти всі web-сервіси.
Знайти всі HTTP-сервіси.
Перевірити інтеграції.
Перевірити журнали доступу.
Перевірити друковані форми.
Перевірити регламентні завдання.
Описати сценарії віддаленої роботи.
Визначити, що переносити в K2 ERP.
Замінити старі API на API K2 ERP.
Заблокувати зайвих користувачів.
Вимкнути старі web-інтеграції після запуску.
Перевести BAS в архівний режим.

Веб-клієнт BAS і цифрова незалежність

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

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

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

Цифрова незалежність. Веб-клієнт BAS часто відкриває стару систему назовні. Завдання міграції — не просто перенести дані, а забрати контроль над доступами, web-сервісами, інтеграціями, користувачами й API у K2 ERP.

Коротко

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

Висновок

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

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

Потрібно:

знайти всі web-публікації;
перевірити HTTPS;
перевірити користувачів;
знайти всі web-сервіси;
знайти всі HTTP-сервіси;
перевірити API-інтеграції;
перевірити сервісні акаунти;
перевірити ролі;
перевірити журнали;
перенести потрібні сценарії в K2 ERP;
вимкнути старі web-інтеграції;
залишити BAS тільки як архів, якщо це потрібно.

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

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

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

Див. також

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