Script Guard i Backpressure: jak EximeeBPMS adresuje RCE i przeciążenia w bankach

Procesy krytyczne w bankach działają pod presją dwóch fundamentalnych ryzyk technicznych: pierwsze to Remote Code Execution (RCE) ukryte w definicjach procesów BPMN – ryzyko, że złośliwy kod zostanie wykonany przez silnik procesowy tylko dlatego, że znalazł się w modelu procesu; drugie to przeciążenia workerów External Tasks, które mogą zatrzymać przetwarzanie w momentach gwałtownego wzrostu ruchu lub spadku wydajności systemów zewnętrznych.

W wersji 1.3.0 EximeeBPMS wprowadził dwa mechanizmy zaprojektowane specjalnie pod kątem środowisk o wysokiej dostępności: Script Guard oraz Backpressure. Oba działają na nowoczesnym, wspieranym stosie Java i stanowią fundament bezpieczeństwa oraz odporności operacyjnej w bankowości.

Co warto wiedzieć:

• Script Guard blokuje RCE w definicjach procesów BPMN, zarówno podczas parsowania modeli, jak i w trakcie wykonania.
• Backpressure stabilizuje External Tasks, zapobiegając przeciążeniom workerów i utrzymując ciągłość działania procesów krytycznych.
• Mechanizmy działają na wspieranych wersjach Java 21/25.
• Całość wspiera zgodność z KNF, DORA i wewnętrznymi politykami bezpieczeństwa banków.

RCE z definicji procesów jako realny wektor ataku w BPMN

Silniki BPMN wykonują skrypty osadzone w modelach procesów. To oznacza, że definicja procesu może stać się nośnikiem złośliwego kodu.

RCE (Remote Code Execution) to sytuacja, w której złośliwy kod zostaje wykonany przez silnik procesowy – zdalnie, wyłącznie na podstawie treści modelu BPMN.

Najczęstsze miejsca, w których pojawia się ryzyko:

• Script Task – skrypty Groovy, JavaScript, JUEL,
• Execution Listener / Task Listener – kod wykonywany przy starcie lub zakończeniu aktywności,
• I/O Mapping – wyrażenia przetwarzające dane wejściowe i wyjściowe,
• JUEL – możliwość wywołania metod Javy z poziomu wyrażeń,
• XML procesu – wstrzyknięcie złośliwego kodu bezpośrednio do definicji.

W bankowości jest to szczególnie groźne: skrypt wykonuje się automatycznie, w środowisku produkcyjnym, często z dostępem do danych transakcyjnych lub systemów zewnętrznych. To klasyczny scenariusz RCE.

Jak Script Guard blokuje RCE?

Script Guard egzekwuje obecnie 38 reguł bezpieczeństwa, które wykrywają 26 odrębnych klas technik RCE (oznaczonych jako SCRIPT_SECURITY_*). Obejmują one m.in.:

• wywołania systemowe (ProcessBuilder, Runtime.exec),
• refleksję i dynamiczne ładowanie klas,
• dostęp do plików (java.io, java.nio),
• dostęp do sieci (sockety, HTTP, URL),
• konstrukcje Groovy (shell, metaclass),
• analogiczne techniki w JavaScript (GraalVM) i JUEL.

Reguły są egzekwowane na dwóch niezależnych punktach kontroli:

Polityka jest domyślnie włączona, konfigurowalna i audytowalna, co jest kluczowe dla zgodności regulacyjnej.

Dlaczego ta kwestia jest kluczowa dla banków?

• Zgodność z KNF i DORA – eliminacja RCE jest wymogiem bezpieczeństwa wykonania i odporności operacyjnej,
• Bezpieczeństwo procesów krytycznych – brak ryzyka wykonania nieautoryzowanego kodu,
• Przewidywalność audytowa – polityka jest jawna, udokumentowana i możliwa do przedstawienia audytorowi.

Przeciążenia External Tasks: jak Backpressure stabilizuje przetwarzanie

Dlaczego External Tasks są podatne na przeciążenia?

External Tasks są często wykorzystywane do integracji z systemami zewnętrznymi. To oznacza, że ich wydajność zależy od:

• gwałtownych wzrostów ruchu (np. kampanie, piki transakcyjne),
• wolnych lub zawieszonych workerów,
• opóźnień w systemach downstream.

W takich sytuacjach worker może pobrać więcej zadań, niż jest w stanie przetworzyć, co prowadzi do przeciążenia, blokowania procesów i incydentów operacyjnych.

Jak działa Backpressure w EximeeBPMS?

EximeeBPMS rozwija mechanizm Backpressure znany z Camundy, dopasowując go do wymagań środowisk o wysokiej dostępności – tak, aby worker nigdy nie pobierał więcej zadań, niż może faktycznie przetworzyć.

Mechanizm działa w trzech obszarach:

Dynamiczne ograniczanie fetch size

• Limit pobieranych zadań jest przeliczany na bieżąco względem liczby aktualnie zajętych wątków w puli workera.
• Jeśli worker jest obciążony, fetch size jest automatycznie ograniczany.
• Gdy w topicu chwilowo nie ma nowych zadań, Backpressure automatycznie wydłuża przerwy między kolejnymi próbami pobrania: zaczyna od 500 ms i podwaja odstęp przy kolejnych próbach (maksymalny odstęp może wynieść 60 sekund). Dzięki temu worker stabilizuje się sam – zarówno przy nagłym napływie zadań, jak i przy przestojach – bez ręcznego dostosowywania parametrów.
• Oznacza to, że Backpressure reguluje zarówno liczbę pobieranych zadań, jak i częstotliwość prób pobrania, utrzymując worker w stabilnym stanie niezależnie od charakteru obciążenia.

ThreadPoolExecutor per topic (opcjonalnie)

• EximeeBPMS nie wymusza osobnego executora per topic – to konfigurowalna opcja, którą można świadomie zastosować w środowiskach wymagających izolacji obciążeń.

Stabilizacja przepływu zadań przy dużym obciążeniu

• Mechanizm zapobiega „zalaniu” workera zadaniami, stabilizuje przetwarzanie i eliminuje błędy blokujące.

Dlaczego ta kwestia jest kluczowa dla banków?

• Ciągłość działania procesów krytycznych – brak ryzyka zatrzymania przetwarzania,
• Odporność na skoki ruchu – system zachowuje stabilność nawet przy gwałtownych zmianach obciążenia,
• Przewidywalność operacyjna – mniejsze ryzyko incydentów i błędów blokujących.

Aktualnie wspierane wersje Java jako fundament bezpieczeństwa i odporności

Wspierane wersje Javy (21/25)

Zgodność jest testowana na Eclipse Temurin JDK, co zapewnia przewidywalność i stabilność środowisk.

Dlaczego nowoczesne wersje Javy są kluczowe dla Script Guard i Backpressure?

• Ulepszenia bezpieczeństwa JVM → mniejsze ryzyko exploitów,
• Nowoczesne mechanizmy współbieżności → stabilniejsza praca Backpressure,
• Długoterminowe wsparcie LTS → zgodność z politykami banków i audytami.

Co to oznacza dla banków?

• Przewidywalność cyklu życia środowisk – łatwiejsze planowanie upgrade’ów,
• Mniejsze ryzyko wynikające z przestarzałych bibliotek,
• Zgodność z wymaganiami regulatorów – KNF, DORA, wewnętrzne polityki bezpieczeństwa.

Powiązanie z praktykami bankowymi

Script Guard i Backpressure wpisują się w kluczowe wymagania sektora finansowego:

• Procesy krytyczne – ochrona integralności i ciągłości działania,
• Audyty bezpieczeństwa – mechanizmy są jawnie dokumentowane i działają automatycznie,
• Zgodność regulacyjna – KNF, DORA, polityki bezpieczeństwa ICT,
• Odporność operacyjna – stabilność pod obciążeniem, przewidywalność, brak incydentów.

Podsumowanie

Script Guard i Backpressure stanowią dwa filary bezpieczeństwa i odporności EximeeBPMS: pierwszy blokuje RCE w definicjach procesów BPMN, drugi stabilizuje External Tasks pod obciążeniem. W połączeniu ze wspieranym, nowoczesnym stosem Java 21 i Java 25 tworzą fundament, który spełnia wymagania banków w zakresie bezpieczeństwa, ciągłości działania i zgodności regulacyjnej.

FAQ

Czy Script Guard działa zarówno podczas wdrożenia, jak i wykonania procesu?

Tak, polityka bezpieczeństwa jest egzekwowana na dwóch poziomach: podczas parsowania BPMN oraz w runtime. Dzięki temu blokowane są zarówno złośliwe skrypty w definicji procesu, jak i próby ich wykonania.

Czy Script Guard wymaga zmian w modelach BPMN?

Nie, mechanizm nie modyfikuje modeli BPMN. Chroni wyłącznie wykonanie skryptów, nie ingerując w semantykę procesów.

Czy Backpressure wymaga zmian po stronie workerów External Tasks?

Nie, mechanizm działa po stronie silnika. Worker nie musi implementować żadnych dodatkowych funkcji.

Czy Backpressure zapobiega przeciążeniom, gdy system downstream działa wolno?

Tak, ogranicza fetch size proporcjonalnie do obciążenia workerów, dzięki czemu nie są „zalewane” zadaniami, gdy system downstream spowalnia.

Jakie wersje Java wspiera EximeeBPMS?

Od wersji 1.4.0 EximeeBPMS wspiera Java 21 i Java 25, tym samym zapewniając najlepszą wydajność, bezpieczeństwo i stabilność mechanizmów Script Guard i Backpressure.

Czy Script Guard i Backpressure wspierają zgodność z DORA?

Tak, Script Guard wzmacnia bezpieczeństwo wykonania, a Backpressure odporność operacyjną. Oba mechanizmy wpisują się w wymagania DORA dotyczące stabilności i kontroli ryzyk ICT.

Źródła

1. EximeeBPMS – External Tasks: https://docs.eximeebpms.org/manual/latest/user-guide/ext-client/
2. EximeeBPMS – Supported Environments: https://docs.eximeebpms.org/manual/latest/introduction/supported-environments/
3. Polityki, procedury, protokoły i narzędzia w zakresie bezpieczeństwa ICT – Rozporządzenie delegowane 2024/1774 uzupełniające rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w odniesieniu do regulacyjnych standardów technicznych określających narzędzia, metody, procesy i polityki zarządzania ryzykiem związanym z ICT oraz uproszczone ramy zarządzania ryzykiem związanym z ICT: https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1774
4. EximeeBPMS 1.3.0 release notes: https://docs.eximeebpms.org/manual/latest/release-notes/release-notes-1.3.0/
5. EximeeBPMS – Security Instructions: https://docs.eximeebpms.org/manual/latest/user-guide/security/
6. EximeeBPMS – Script Guard: https://docs.eximeebpms.org/manual/latest/user-guide/process-engine/script-guard/
7. EximeeBPMS – Script Task: https://docs.eximeebpms.org/manual/latest/reference/bpmn20/tasks/script-task/
8. KNF – Rozporządzenie DORA: https://www.knf.gov.pl/dla_rynku/dora