Dotyczy wersji 2023.1.3 i powyżej
Wprowadzenie
Na bezpieczeństwo systemu WEBCON BPS wpływa infrastruktura instalacji systemu oraz elementy konfiguracji samej platformy WEBCON BPS. W niniejszym artykule omówiono drugi ze wspomnianych wariantów, mianowicie opcje dostępne w Designer Studio, które pozwalają kontrolować dostęp do systemu.
Biuletyn bezpieczeństwa – podatności komponentów
Do rozwoju platformy WEBCON BPS wykorzystywane są zewnętrzne komponenty, biblioteki oraz frameworki, które podlegają audytom bezpieczeństwa. Znane podatności wykorzystywanych komponentów, a także samego systemu, katalogowane są na stronie Security bulletin witryny Community
Lista zawiera identyfikator CVE/CWE podatności lub krótki opis, jeżeli źródłem podatności jest platforma WEBCON BPS.
Parametry globalne – ustawienia w Konfiguracji systemu
Większość opcji powiązanych z bezpieczeństwem znajduje się w węźle Bezpieczeństwo (1) (Konfiguracja systemu → Parametry globalne). Dodatkowo niektóre opcje znajdują się w samym węźle Parametry globalne (2) (w starszych wersjach platformy pozbawionych wyodrębnionego węzła Bezpieczeństwo odpowiednie opcje znajdują się właśnie w węźle głównym). Opcje te pozwalają dostosować zachowanie systemu do standardów bezpieczeństwa obowiązujących w danym przedsiębiorstwie.
Zaufane domeny
Aby móc wyświetlać elementy Portalu w innych witrynach, należy dodać je 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ć.
UWAGA 2: dla istniejących instalacji domeny dla MS Outlook i MS Teams oraz domena skonfigurowanego Portalu zostaną dopisane do zaufanych domen przez skrypt migracyjny. Zapewni 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 w przedmiotowej sekcji dodawane są do każdej odpowiedzi z Portalu. Pozwala to na dostosowanie jego działania do specyficznych wymagań bezpieczeństwa, szczególnie jeżeli Portal dostępny jest 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 chroni przed podatnością Cross Site Request Forgery 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, tak 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 oraz plików cookies, a także długość trwania sesji udostępnionej przez link publiczny, można kontrolować zgodnie z wymaganiami bezpieczeństwa.
Ustawieniem domyślnym w tym przypadku jest Systemowe wartości domyślne. Opcję tę można zmienić, 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 odpowiada za automatyczne przedłużanie czasu życia pliku cookie. Jeżeli zaznaczono, przedłużenie następuje w momencie odwołania do WEBCON BPS Portalu po upływie połowy czasu życia pliku cookie. W takim przypadku wystawiany jest nowy plik cookie, który pozostaje ważny przez okres odpowiadający wartości parametru Czas życia cookie. Jeżeli opcji nie zaznaczono, czas życia pliku cookie nie jest w żaden sposób przedłużany.
Czas życia access tokenu w formacie dd.hh:mm:ss. Domyślną wartością tego pola jest 1 h.
Czas życia refresh tokenu w formacie dd.hh:mm:ss. Domyślną wartością tego pola jest 26 dni.
Sekcja Konfiguracja kodów autoryzacyjnych dla publicznego dostępu do elementów zawiera opcję Interwał wymuszenia autoryzacji określającą czas, po upływie którego konieczna jest ponowna autoryzacja dostępu do elementu uzyskanego poprzez otworzenie otrzymanego linku.
Z pełnym opisem tej funkcjonalności oraz przykładem jej zastosowania można zapoznać się w artykule Publiczny link.
Metody dodatkowej autoryzacji
Jeżeli w konfiguracji ścieżki aktywowany jest wymóg dodatkowej autoryzacji, użytkownik może 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.
Z pełnym opisem tej funkcjonalności można zapoznać się w artykule Autoryzacja 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 użytkownicy chętnie korzystają z aplikacji mobilnej, możliwe jest wprowadzenie obowiązku ustawienia kodu PIN. Jeżeli mimo wszystko ustawienie kodu nie będzie wymagane, aplikacja periodycznie sugerować będzie użytkownikowi ustawienie kodu PIN i dodanie urządzenia do zaufanych.
Dodatkowe informacje na temat aplikacji mobilnej zawarto w artykule Nowa aplikacja mobilna WEBCON BPS 2023.
Konfiguracja aplikacji w Designer Studio
Poza opcjami dostępnymi w węźle Parametry globalne w konfiguracji samych procesów, obiegów oraz źródeł danych znajduje się wiele opcji, które umożliwiają „uszczelnienie” konfiguracji systemu. Podczas projektowania procesów należy zdecydować, jakimi zasobami i danymi powinni dysponować użytkownicy nie tylko w ramach obiegu, ale także Raportów i Dashboardów. Ograniczenie dostępu do najistotniejszych danych jest korzystne z perspektywy użytkownika oraz pomaga chronić wrażliwe dane.
Kompartmentalizacja obiegów
Elementy, do których mają dostęp i które widzą użytkownicy, najczęściej określa się na podstawie konfiguracji uprawnień. Aby to ułatwić, procesy biznesowe należy rozbić na szereg obiegów, które mogą (ale nie muszą) być ze sobą połączone. Takie mniejsze obiegi ułatwiają przypisywanie uprawnień i kontrolowanie zadań.
Istnieje możliwość zaplanowania obiegu w oparciu o dane, jakie będą w nim dostępne. Jeżeli w proces zaangażowani są użytkownicy, którym ma zostać udostępniona część danych z określonego elementu, możliwe jest stworzenie podobiegu, do którego zostaną przekazane tylko te wymagane dane. Dzięki temu w procesie biznesowym może uczestniczyć więcej użytkowników, ale niekoniecznie będą oni mieli dostęp do wszystkich danych, jakie istnieją w procesie. Ich dostęp i możliwości edycji będą ograniczone do elementu podobiegu, co oznacza, że nie będą oni mogli przejść do historii elementu i podglądać danych z głównego obiegu.
Z wieloma przykładami praktycznego zastosowania podobiegów można zapoznać się w artykułach dostępnych na blogu technicznym KB.
Przydzielanie uprawnień i licencji
Mimo, że licencje i uprawnienia można przydzielać ręcznie z poziomu Designer Studio, aby wyeliminować ewentualność wystąpienia błędu ludzkiego, zaleca się projektowanie obiegów, które nadają odpowiednie uprawnienia za pomocą akcji. Procesy takie, jak proces onboardingu, mogą ułatwić zarządzanie użytkownikami w bezpieczny sposób.
DEV-TEST-PROD Import-Export
W odniesieniu do unikania wprowadzania ręcznych zmian w systemie dobrą praktyką jest modyfikowanie środowiska produkcyjnego wyłącznie za pomocą mechanizmu Import-eksport. W tym przypadku dostępna jest opcja, która uniemożliwia edycję procesu zaimportowanego za pomocą tego mechanizmu.
Obecnie możliwy jest ponadto import za pomocą API.
Dzięki paczkom użytkownik dysponuje też kopiami zapasowymi poprzednich wersji aplikacji umożliwiającymi przywrócenie jej oryginalnej wersji.
Zawartość wiadomości e-mail
Użytkownik może dokładnie kontrolować co wysyłane jest w wiadomościach e-mail (standardowych i konfigurowalnych). W tym względzie ciekawe rozwiązanie oferuje opcja dostępna w konfiguracji atrybutów Nigdy nie pokazuj w powiadomieniach e-mail. Warto tez wspomnieć, że atrybuty techniczne nie będą uwzględniane w wiadomościach e-mail.
W przypadku konfiguracji szablonu w procesie oraz akcji wysyłającej konfigurowalną wiadomość e-mail możliwe jest zdefiniowanie linków, jakie będą zawarte w wiadomości. W tym względzie warto rozważyć ukrycie niechcianych opcji, szczególnie jeżeli wiadomość e-mail wysyłana jest do kogoś spoza organizacji.
Ponadto możliwe jest zablokowanie wysyłki wiadomości e-mail z wybranych procesów lub globalnie, włączając tzw. Tryb wdrożeniowy.
Źródła danych
W konfiguracji połączeń oraz źródeł dostępnych jest szereg opcji umożliwiających kontrolowanie osób, które mają dostęp do danych. W tym przypadku globalny administrator widzi wszystkie źródła i połączenia, natomiast administrator aplikacji ma dostęp wyłącznie do takich źródeł i połączeń, które są powiązane z jego aplikacjami lub są publiczne.
RODO
W roku 2017 wprowadzono szereg funkcjonalności pozwalających oznaczać i usuwać dane osobowe znajdujące się w systemie oraz śledzić ich wykorzystanie. Odpowiednią konfigurację opisano w artykule RODO – oznaczanie atrybutów, procesów i źródeł danych.