Редагування groovy скриптів бізнес-процесів в адмін-порталі

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

1. Загальний опис проблеми та рішення

Розробка бізнес-процесів регламенту реєстру передбачає розробку Groovy-скриптів, що відображають логіку роботи кроків бізнес-процесу. Адмін-портал дозволяє проводити розробку бізнес-процесів регламенту реєстру. Набагато ефективніше вести розробку Groovy-скриптів у спеціалізованих засобах розробки, таких як IDE (Desktop або Web версії).

Розширення адмін-порталу використанням rich вебредакторів редагування Groovy-скриптів покращить користувацький досвід до рівня використання настільних IDE-інструментів, а також зменшить час на постійне переміщення скриптів до Desktop IDE для редагування та назад — до BPMN.IO-візуального конструктора бізнес-процесів.

Результати POC для ознайомлення з LSP протоколом та вебредактором коду MonacoEditor.

2. Глосарій

LSP - Language Server Protocol
LS - Language Server
WS - WebSocket
WSS - WebSocket Secure

3. Актори

Розробник регламенту реєстру

4. Функціональні можливості редактору

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

Автодоповнення у вигляді випадного списку варіантів виклику
Відображення результату аналізу коду на наявність помилок за допомогою language server
Показ Hoover-підказки (hoover tooltip) з javadoc-інформацією
Використання різних кольорів при перегляді коду
Автодоповнення для DDM JUEL-функцій:
- initiator
- completer
- system_user
- submission
- sign_submission
- get_variable
- set_variable
- set_transient_variable
- process_caller
- message_payload

5. Основні принципи

Monaco editor як вебінструмент розробки groovy-скриптів
Використання сторонніх Language Server’s (LS’s) для отримання підказок, переліку для автодоповнення та результату помилок семантичного аналізу Groovy-скриптів
Використання Language Server Protocol для комунікації між Language Server та Monaco editor
Використання lsp4j для менеджменту (orchestration) LS’s
Транспортний протокол комунікації між Monaco editor та LS — WebSocket over HTTP (HTTPS).
Логічний протокол комунікації (структура payload у повідомленнях транспортного протоколу) між Monaco editor та LS — Json-RPC.

6. Високорівневий дизайн

6.1. Опис та призначення компонентів

Назва	Мова програмування	Опис
Monaco editor	JavaScript	Візуальний вебредактор коду
Remote LS’s	Java, LSP4J	Екземпляри LS сервісів, що реалізує LSP протокол та виконують перевірку клієнтського коду з поверненням результатів перевірки в форматі Json-RPC(LSP).
LS Manager, Websocket Manager	Java, Spring	Spring boot web controller. Створює необхідні екземпляри LS. Створює WebSocket та використовує відповідний LS-екземпляр для аналізу та перевірки коду з візуального редактора клієнту.

Назва

Мова програмування

Опис

Monaco editor

JavaScript

Візуальний вебредактор коду

Remote LS’s

Java, LSP4J

Екземпляри LS сервісів, що реалізує LSP протокол та виконують перевірку клієнтського коду з поверненням результатів перевірки в форматі Json-RPC(LSP).

LS Manager, Websocket Manager

Java, Spring

Spring boot web controller. Створює необхідні екземпляри LS. Створює WebSocket та використовує відповідний LS-екземпляр для аналізу та перевірки коду з візуального редактора клієнту.

6.2. LSP комунікація

Як транспортний протокол використовується WSS-протокол
Як RPC-взаємодія використовується LSP-протокол версії 3.17.

6.2.1. WebSocket-комунікація

Як транспортний протокол використовується WSS
Для налаштування Web-socket зв’язку зі сторони візуального рівня (UI layer) використовується monaco-languageclient.
Для організації частини websocket backend використовується spring-websocket.

6.2.2. Кількість екземплярів LS

Кожне вікно з monaco editor використовує свій окремий web-socket instance для з’єднання з LS.
Кожний web-socket використовує окремий екземпляр LS.
Усі LS-екземпляри знаходяться в одному JVM-екземплярі. Технічно кожний екземпляр LS — це новий екземпляр з інтерфейсом org.eclipse.lsp4j.services.LanguageServer.

bp-script-editing ls-communication-sequence

7. Розгортання компонента

8. Масштабування

В поточній версії розгортання сервісу пропонується використовувати лише вертикальне масштабування (RAM, CPU). Оскільки використовується підхід розміщення всіх LS в рамках однієї JVM, тому не очікується значного збільшення використання обчислювальних ресурсів під час збільшення кількості одночасно запущених клієнтів LS.

Горизонтальне масштабування можливе шляхом додавання Load Balancer для LSP (WebSocket JSON-RPC) трафіку. Out of scope.

9. Моделювання загроз

Area Назва Опис Значення ліміту

Area	Назва	Опис	Значення ліміту
Kong	WSS трафік через Kong	Налаштування пропускання трафіку через admin kong шляхом використання Upgrade headers. WebSocket kong manual
Авторизація під час handshake процесу	Поточна авторизація на admin kong. `GET /groovy` повинен бути доступним тільки авторизованим користувачам через admin realm
Максимальний розмір запита	Ліміт для payload всередині LSP (JSON-RPC). Використати Request Size Limiting	65kb (30kb after SC)
Socket timeout	Idle time для сокету, через який він автоматично закривається. Необхідна конфігурація як на BE так і на FE side. Kong config property `proxy_read_timeout`	60s (should be by default)
Socket open Rate limit	Ліміт на кількість запитів на створення web-socket `/groovy`. Використати існуючий плагін в Kong Rate limit plugin	10 per minute per user
Java application	Конфігурація CORS	Налаштувати CORS для `/groovy` методу відкриття web-socket
Chart configuration	RAM limit	Встановити RAM ліміт шляхом налаштування resources.requests.memory в Chart deployment	1GB

Kong

WSS трафік через Kong

Налаштування пропускання трафіку через admin kong шляхом використання Upgrade headers. WebSocket kong manual

Авторизація під час handshake процесу

Поточна авторизація на admin kong. GET /groovy повинен бути доступним тільки авторизованим користувачам через admin realm

Максимальний розмір запита

Ліміт для payload всередині LSP (JSON-RPC). Використати Request Size Limiting

65kb (30kb after SC)

Socket timeout

Idle time для сокету, через який він автоматично закривається. Необхідна конфігурація як на BE так і на FE side. Kong config property proxy_read_timeout

60s (should be by default)

Socket open Rate limit

Ліміт на кількість запитів на створення web-socket /groovy. Використати існуючий плагін в Kong Rate limit plugin

10 per minute per user

Java application

Конфігурація CORS

Налаштувати CORS для /groovy методу відкриття web-socket

Chart configuration

RAM limit

Встановити RAM ліміт шляхом налаштування resources.requests.memory в Chart deployment

1GB

10. Технологічний стек

Назва	Версія	Ліцензія	Опис
Monaco editor	0.34.1	MIT	Візуальний вебредактор коду
monaco-languageclient	4.0.3	MIT	Language server клієнт, що підключається до Monaco editor та використовується для з’єднання з віддаленими language серверами використовуючи LSP протокол)
vscode-languageclient	8.0.2	MIT	Транзитивна залежність з monaco-languageclient
LSP4J	0.19	Eclipse Public License - v 2.0	Бібліотека для менеджменту екземплярів LS. Використовується для запуску LS коду.
Groovy language server	-	APACHE LICENSE, v2.0	Реалізує LSP протокол та виконую перевірку Groovy коду з поверненням результатів перевірки в форматі Json-RPC
Spring Boot	2.6.1	APACHE LICENSE, v2.0	Розширення до Spring Framework для спрощення побудови аплікацій на базі Spring завдяки автоматичній конфігурації та наявності spring boot стартерів
spring-boot-starter-websocket	2.6.1	APACHE LICENSE, v2.0	Розширення для Spring для менеджменту вебсокетів в серверних додатках (використовує spring-websocket:5.3.13)

Назва

Версія

Ліцензія

Опис

Monaco editor

0.34.1

MIT

Візуальний вебредактор коду

monaco-languageclient

4.0.3

MIT

Language server клієнт, що підключається до Monaco editor та використовується для з’єднання з віддаленими language серверами використовуючи LSP протокол)

vscode-languageclient

8.0.2

MIT

Транзитивна залежність з monaco-languageclient

LSP4J

0.19

Eclipse Public License - v 2.0

Бібліотека для менеджменту екземплярів LS. Використовується для запуску LS коду.

Groovy language server

APACHE LICENSE, v2.0

Реалізує LSP протокол та виконую перевірку Groovy коду з поверненням результатів перевірки в форматі Json-RPC

Spring Boot

2.6.1

APACHE LICENSE, v2.0

Розширення до Spring Framework для спрощення побудови аплікацій на базі Spring завдяки автоматичній конфігурації та наявності spring boot стартерів

spring-boot-starter-websocket

2.6.1

APACHE LICENSE, v2.0

Розширення для Spring для менеджменту вебсокетів в серверних додатках (використовує spring-websocket:5.3.13)

11. Інтерфейс управління

BPMN.io буде розширено додатковою кнопкою виклику модального вікна редагування groovy скриптів.

Зображення 1. Вікно виклику редактору скриптів бізнес-процесів

Зображення 2. Вікно редагування скрипта в Monaco Editor

12. Високорівневий план розробки

12.1. Необхідні експертизи

Java
Javascript
DevOps
QA, AQA

12.1.1. Backend Java activities

Створити Spring Boot-based backend service ddm-language-server
Розробити WebSocket proxy component
Підвищити версію LSP4J до 0.19 для GroovyLanguageServer

12.1.2. Javascript activities

Інтеграція Monaco editor в BPMN.IO редактор бізнес-процесів
Інтеграція Monaco-editor з ddm-language-server використовуючи monaco-languageclient

12.1.3. DevOps activities

Впровадити https://github.com/GroovyLanguageServer/groovy-language-server: підготувати кодову базу (codebase) в gerrit та створити пов’язаний Jenkins-пайплайн.
Створити deploy-templates та Dockerfile для service ddm-language-server (openjdk based image).
Конфігурація AdminKong для пропускання трафіку до ddm-language-server. Додати websocket проксі заголовки до конфігурації Kong.
Конфігурація плагінів Kong для перевірки лімітів безпеки (security limits).
Додати в environment-js змінну languageServerUrl з відносною адресою ddm-laguage-server.

13. Безпека

13.1. Бізнес Дані

Категорія Даних

Опис

Конфіденційність

Цілісність

Доступність

Проміжні дані бізнес-процесів, що містять відкриту інформацію

Дані бізнес форм та процесів що не містять інформацію з обмеженим доступом

Низька

Висока

Середня

Операційні журнали

Списки зафіксованих (logged) звернень до сервісу та журнали його роботи

Середня

Висока

13.2. Спрощена модель загроз

13.3. Механізми протидії ризикам безпеки та відповідність вимогам безпеки

Ризик

Засоби контролю безпеки

Реалізація

Пріорітет

Порушення цілісності та конфіденційності даних при передачі

Використання HTTPS та WSS

Враховано в початковому дизайні

Високий

Небезпечне завершення сеансу на стороні сервера

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

Не враховано в початковому дизайні

Високий

Відмова в обслуговуванні через вичерпання обчислювальних ресурсів (DOS), спричинена відсутністю обмежень для вебсокетів

Впровадження ліміту на максимальний розмір запиту на рівні 30 kb
Час очікування сокета: 60s
Обмеження кількості відкритих сокетів на рівні 10 сокетів для одного користувача протягом хвилини

Враховано в початковому дизайні

Високий

Відмова в обслуговуванні через вичерпання обчислювальних ресурсів (DOS), спричинена відсутністю обмежень для сервісу на рівні OpenShift.

Обмеження споживання оперативної пам’яті. Сам ліміт повинен бути прорахований після проведення тестування.
Обмеження споживання часу процесора. Сам ліміт повинен бути прорахований після проведення тестування.
Налаштувати механізм перезапуску сервісу при надмірному використанні ресурсів.

Враховано в початковому дизайні

Високий

Відмова в обслуговуванні через вичерпання обчислювальних ресурсів (DOS), спричинена відсутністю обмежень для HTTP запитів на рівні вхідного (ingress) контролера Kong.

Обмеження сокета та кількості запитів має бути налаштований окремо на /groovy ендпоінт. Тобто плагін рейт лімітів для Kong має бути налаштований на /groovy

Не враховано в початковому дизайні

Високий

Ризик бекдору (backdoor) у компоненті language-server

Вбудувати усі необхідні ресурси та мовні словники для розбору AST в образі ddm-language-server для запобігання будь-яких звернень цього сервісу до зовнішніх джерел
Заборонити на рівні мережевих політик openshift будь-яке спілкування сервісу ddm-language-server з зовнішніми ресурсами й дозволити комунікацію з сервісом логування та сервісами залученими відповідно до бізнес-логіки.

Частково враховано в початковому дизайні. Необхідно повністю ізолювати сервіс ddm-language-server від зовнішньої мережі

Високий

Ризик виконання вразливості інтерактивних інформаційних систем (XSS)

Налатування CORS

Враховано в початковому дизайні

Високий

Ризик розкриття технічної інформації про систему

Сервіс має віддавати загальну помилку при появі проблем.
Сервіс повинен мати механізм "last resort" який опрацює будь-які помилки які не були опрацьовані до цього.
Переконатись що режим DEBUG вимкнений на усіх рівнях у пре-продакшн та промислових середовищах.
language-server не віддає свою версію та будь-яку технічну та/або системну інформацію у HTTP-відповіді.

Не враховано в початковому дизайні

Середній

Десеріалізація ненадійних даних

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

Не враховано в початковому дизайні

Середній

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

Переконатись, що запити, які містять неочікувані або відсутні Content Types, відхиляються відповідними заголовками (статус відповіді HTTP 406 Неприйнятний або 415 Непідтримуваний тип медіа).
Вебсервер приймає тільки затверджені HTTP методи.
Переконатись що HTTP-відповідь має заголовок Content-Type, а також безпечний набір символів. Наприклад, UTF-8, ISO-8859-1.
Веб сторінка з Монако редактором має містити налаштовані заголовки Content Security Policy (CSP).
Вебсторінка з Монако редактором має містити заголовок X-Content-Type-Options: nosniff

Не враховано в початковому дизайні

Середній

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

Системний сервіс не повинен отримувати ключ сервісного облікового запису від openshift (якщо це не є вимогою) та повинен бути запущений від не привілейованого системного користувача.

Не враховано в початковому дизайні

Середній

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

Цільовий сервіс має логувати усі запити та надсилати їх до централізованої системи логування та моніторингу.
Переконатись що усі неуспішні запити та помилки при виконанні операцій будуть залоговані.
Система логування має використовувати уніфікований час та часову зону.
Логи мають бути в уніфікованому форматі та містити усю необхідну інформацію для розслідування інцидентів безпеки.
Логи не мають містити чутливої інформації або вона повинна бути заплутана (obfuscated) відповідним чином

Не враховано в початковому дизайні

Низький

Неправильна конфігурація сервісу та/або фреймфорку

Переконатися, що конфігурація сервера захищена відповідно до рекомендацій сервера додатків і фреймворків, які використовуються (web server/app server/framework hardening).

Не враховано в початковому дизайні

Низький

13.4. Система тестування комплексу засобів захисту (КЗЗ)

Репозиторій з вихідним кодом повинен бути впроваджений до системи керування вразливостями та проходити регулярне тестування.
Базовий образ (image) сервісу повинен бути просканований та не повинен містити не розв’язаних критичних вразливостей.
Базовий образ (image) повинен бути розміщений у довіреному сховищі, підконтрольному організації.
Технологія language-server повинна бути додана до переліку сторонніх продуктів, які використовуються (inventory).