Dotyczy wersji 2023.1.3 i powyżej

Na bezpieczeństwo systemu WEBCON BPS wpływa infrastruktura instalacji systemu, oraz elementy konfiguracji samego WEBCON BPS. W tym artykule skupimy się na tych drugich – opcjach dostępnych w Designer Studio pozwalających kontrolować dostęp do systemu.

1. Biuletyn bezpieczeństwa – podatności komponentów.

Do rozwoju WEBCON BPS wykorzystywane są zewnętrzne komponenty, biblioteki, frameworki, które podlegają audytom bezpieczeństwa. Znane podatności wykorzystywanych komponentów, oraz samego systemu katalogowane są na stronie Security bulletin na Community.

Lista zawiera identyfikator CVE/CWE podatności, lub krótki opis jeżeli podatność wynikła w WEBCON BPS.

2. Parametry Globalne – ustawienia w Konfiguracji Systemu

Większość opcji powiązanych z bezpieczeństwem znajduje się w węźle Bezpieczeństwo (1) Parametrów Globalnych w Konfiguracji systemu. Dodatkowo, kilka opcji znajduje się w samym węźle Parametry globalne (2) (W starszych wersjach, w których nie powstał jeszcze odrębny węzeł Bezpieczeństwo, dostępne opcje znajdują się właśnie w głównym węźle).

Opcje te pozwalają dostosować zachowanie systemu do standardów bezpieczeństwa obowiązujących w danej korporacji.

Zaufane domeny

Aby móc wyświetlać elementy Portalu na innych witrynach, należy je dodać do listy domen zaufanych. Elementy Portalu osadzone w witrynach z domeną spoza listy domen zaufanych nie zostaną wyświetlone w przeglądarce.

Funkcjonalność nie jest dostępna dla przeglądarki Internet Explorer. W tym przypadku wyświetlane są wszystkie elementy Portalu, nawet jeśli domena witryny, w której osadzono elementy, nie znajduje się na liście domen zaufanych.

Aby osadzić Portal w aplikacjach Microsoft Teams oraz Microsoft Outlook, należy dodać do zaufanych domen następujące wpisy:

https://*.office365.com
https://*.office.com
https://*.microsoft.com

UWAGA W przypadku skonfigurowania nagłówków Content-Security-Policy oraz dodania do sekcji frame-ancestors lista zaufanych domen zostanie dodana do domen zdefiniowanych w tym nagłówku. Wyjątkiem jest wpis „*”, który w takim przypadku przestaje obowiązywać.

AKTUALIZACJA Dla istniejących instalacji, domeny dla MS Outlook i MS Teams oraz domena skonfigurowanego Portalu zostaną dopisane do zaufanych domen przez skrypt migracyjny. Zapewnienia to ciągłości działania systemu. Usunięcie dodatkowych wpisów możliwe będzie poprzez ręczną edycję listy zaufanych domen.

Dodatkowe nagłówki response

Dodatkowe nagłówki zdefiniowane tutaj dodawane są do każdej odpowiedzi z Portalu. Pozwala to na dostosowanie jego działania do specyficznych wymagań bezpieczeństwa, szczególnie jeżeli nasz Portal dostępny jest w publicznie w sieci.

Nagłówek Content-Security-Policy zostanie scalony z wartościami domen zaufanych.

Przykład konfiguracji znajduje się w artykule Nagłówki HTTP w WEBCON BPS

Zabezpieczenie CSRF

Zabezpieczenie CSRF (Cross Site Request Forgery, CSRF) chroni przed tą podatnością poprzez sprawdzanie nagłówków Origin oraz Referer w wywołaniach POST z przeglądarki użytkownika.

Prawidłowo skonfigurowane zabezpieczenie powinno chronić wszystkie endpointy, w których uwierzytelnianie użytkownika odbywa się na podstawie plików cookies dostarczonych przez przeglądarkę.

Adresy pomijane przy sprawdzaniu zabezpieczenia CSRF – Sprawdzanie wskazanych nagłówków jest natychmiast pomijane w endpointach, w przypadku których uwierzytelnianie działa w oparciu o tokeny (lista wyjątków powinna zawierać wyłącznie takie endpointy).

Zachowanie wylogowania z WEBCON BPS Portal

Możemy udostępnić użytkownikom dodatkowy przycisk pozwalający na globalne wylogowanie ze wszystkich sesji. Możemy też zmienić działanie domyślnego przycisku wylogowania, aby powodował wylogowanie ze wszystkich sesji.

Wylogowanie z pojedynczej sesji (domyślne) – w menu użytkownika Portalu dostępny jest przycisk Wyloguj pozwalający na wylogowanie z pojedynczej sesji użytkownika,
Możliwość wylogowania ze wszystkich sesji – w menu użytkownika dostępny jest przycisk Wyloguj pozwalający na wylogowanie z pojedynczej sesji użytkownika oraz przycisk Wyloguj wszędzie pozwalający na wylogowanie z wszystkich sesji użytkownika na wszystkich urządzeniach,
Wymuszenie wylogowania ze wszystkich sesji – w menu użytkownika dostępny jest tylko przycisk Wyloguj wszędzie pozwalający na wylogowanie z wszystkich sesji na wszystkich urządzeniach.

Token, Cookie, i Publiczny link

Długość życia access i refresh tokenów, ciasteczek, oraz długość trwania sesji udostępnionej przez link publiczny możemy kontrolować według wymagań bezpieczeństwa.

Domyślne stosowane są Systemowe wartości domyślne – możemy zmienić tą opcję aby dowolnie definiować wybrane wartości.

Po wybraniu opcji Definiowane przez użytkownika, aktywowane zostają pola w znajdujących się poniżej sekcjach Konfiguracja cookie WEBCON BPS Portal, Konfiguracja tokenów dla aplikacji systemowych (Designer Studio, Aplikacje mobilne, Dodatki) oraz Konfiguracja kodów autoryzacyjnych dla publicznego dostępu do elementów.

Czas życia plików cookie w formacie dd.hh:mm:ss. Domyślną wartością tego pola jest 14 dni.

Sliding expiration Umożliwia wyzerowanie na żądanie czasu wygaśnięcia ważnego uwierzytelniającego pliku cookie, jeżeli upłynęła ponad połowa limitu czasu.

Czas życia access tokenu dostępu w formacie dd.hh:mm:ss. Domyślną wartością tego pola jest 1 godzina.

Czas życia refresh tokenu dostępu w formacie dd.hh:mm:ss. Domyślną wartością tego pola jest 26 dni.

Konfiguracja kodów autoryzacyjnych dla publicznego dostępu do elementów zawiera Interwał wymuszenia autoryzacji

Jest to czas, po upływie którego konieczna jest ponowna autoryzacja dostępu do elementu uzyskanego poprzez otworzenie otrzymanego linku.

Pełny opis oraz przykład znajduje się w artykule Publiczny link

Metody dodatkowej autoryzacji

Jeżeli w konfiguracji ścieżki aktywowany będzie wymóg dodatkowej autoryzacji, użytkownik będzie mógł skorzystać z jednej z dostępnych metod. Wymagane jest, by aktywna była co najmniej jedna metoda dodatkowej autoryzacji – domyślnie jest to e-mail, ponieważ każdy użytkownik WEBCON BPS powiązany jest z adresem mailowym.

Pełny artykuł dotyczący Autoryzacji przejścia ścieżką

SMS – jednorazowy kod autoryzacyjny zostanie wysłany na numer telefonu użytkownika wykonującego czynność, dla której wymagana jest dodatkowa autoryzacja. Numer telefonu, na który zostanie wysłany SMS z kodem definiowany jest w profilu użytkownika. Kod autoryzacyjny użytkownik musi wprowadzić w okienku formularza, by potwierdzić swoją tożsamość i kontynuować pracę. Jeśli dla użytkownika nie wprowadzono numeru telefonu, autoryzacja tym kanałem nie będzie możliwa.
E-mail – jednorazowy kod autoryzacyjny zostanie wysłany na adres e-mail użytkownika wykonującego czynność, dla której wymagana jest dodatkowa autoryzacja. Kod autoryzacyjny użytkownik musi wprowadzić w okienku formularza, by potwierdzić swoją tożsamość i kontynuować pracę.
Aplikacja mobilna – na urządzenie z zainstalowaną aplikacją mobilną zostanie wysłane powiadomienie PUSH z prośbą o potwierdzenie tożsamości użytkownika wykonującego czynność, dla której wymagana jest dodatkowa autoryzacja. Aby móc skorzystać z tej metody dodatkowej autoryzacji, na urządzeniu użytkownika musi być zainstalowana najnowsza wersja aplikacji mobilnej, a urządzenie musi być dodane do urządzeń zaufanych (konfiguracja urządzeń zaufanych dostępna jest w profilu użytkownika).

Wymagany poziom zabezpieczenia aplikacji mobilnej

Jeżeli nasi użytkownicy chętnie korzystają z aplikacji mobilnej, możemy narzucić na nich obowiązek ustawienia kodu PIN. Nawet jeżeli nie wymusimy ustawienia kodu, aplikacja będzie periodycznie sugerować użytkownikowi ustawienie PIN i dodanie urządzenia do zaufanych.

Aby zobaczyć inne możliwości aplikacji mobilnej, zobacz artykuł o nowej aplikacji mobilnej.

3. Konfiguracja Aplikacji w Designer Studio

Poza opcjami znajdującymi się w Parametrach Globalnych, w konfiguracji samych procesów, obiegów, oraz źródeł danych znajduje się multum opcji które pozwolą nam „uszczelnić” konfigurację naszego systemu. Podczas projektowania procesów, należy zdecydować jakimi zasobami i danymi powinni dysponować użytkownicy – nie tylko w trakcie trwania obiegu, ale też na Raportach i Dashboardach. Ograniczenie dostępu do najistotnieszych danych wygląda dobrze z perspektywy użytkownika, oraz pomaga chronić wrażliwe dane.

Kompartmentalizacja obiegów

Do czego mają dostęp, oraz co widzą nasi użytkownicy, najczęściej ustalamy na podstawie konfiguracji uprawnień. Aby to ułatwić, procesy biznesowe rozbijamy na szereg obiegów które mogą (ale nie muszą) być ze sobą połączone. Do takich mniejszych obiegów wygodniej przypisuje się uprawnienia i kontroluje zadania.

Możemy zaplanować obieg wokół danych jakie będą w nim dostępne – jeżeli w proces zaangażowani są użytkownicy którym chcemy udostępnić część danych z jakiegoś elementu, możemy stworzyć podobieg do którego przekażemy tylko te wymagane dane. Dzięki temu, w procesie biznesowym może uczestniczyć więcej użytkowników, ale nie koniecznie będą mieli dostęp do wszystkich danych jakie uczestniczą w procesie. Ich dostęp i kontrybucja będzie ograniczona do elementu podobiegu – nie będą mogli zaglądnąć do historii elementu i podglądać danych z głównego obiegu.

Na blogu technicznym znajduje się wiele przykładów praktycznego zastosowania podobiegów.

Przydzielanie uprawnień i licencji

Mimo że licencje i uprawnienia można przydzielać ręcznie, z poziomu Designer Studio, aby wyeliminować możliwość błędu ludzkiego, zaleca się zaprojektowanie obiegów które nadadzą odpowiednie uprawnienia za pomocą Akcji. Takie procesy „Onboarding” mogą ułatwić zarządzanie użytkownikami w bezpieczny sposób.

DEV-TEST-PROD Import-Export

À propos unikania ręcznych zmian w systemie, dobrą praktyką jest modyfikacja środowiska Produkcyjnego wyłącznie za pomocą mechanizmu Eksport-Import. Istnieje opcja, która blokuję edycję procesu zaimportowaną za pomocą tego mechanizmu.

Na chwilę obecną możliwy jest też import za pomocą API.

Dzięki paczkom importu dysponujemy też „backupami” poprzednich wersji aplikacji, jeżeli wyniknie potrzeba do nich wrócić.

Zawartość E-mail

Możemy dokładnie kontrolować co wysyłane jest w wiadomościach e-mail (standardowych i konfigurowalnych). Ciekawa jest opcja dostępna w konfiguracji atrybutu: Nigdy nie pokazuj w powiadomieniach e-mail. Warto tez wspomnieć, że atrybuty techniczne nie będą zawierane w wiadomościach e-mail.

W konfiguracji szablonu w procesie, oraz akcji wysyłającej e-mail konfigurowalny, sterować można linkami jakie zawarte będą w wiadomości. Warto rozważyć ukrycie niechcianych opcji, szczególnie jeżeli e-mail wysyłany jest do kogoś spoza organizacji.

Możemy też zablokować wysyłkę maili z wybranych procesów (lub globalnie) włączając tzw. Tryb wdrożeniowy.

Źródła danych

W konfiguracji połączeń i źródeł dysponujemy kilkoma opcjami do kontrolowania kto ma dostęp do danych. Globalny administrator będzie widział wszystkie źródła i połączenia, natomiast administrator aplikacji będzie widział tylko takie źródła i połączenia, które są Powiązane z jego aplikacjami (lub takie które są Publiczne)

GDPR/RODO

W roku 2017 wprowadzono szereg funkcjonalności pozwalających oznaczać, śledzić wykorzystanie, i usuwać dane osobowe rozpowszechnione w systemie. Konfiguracja została opisana w artykule oznaczanie atrybutów, procesów i źródeł danych.