Portal klienta B2B udostępnia dane, które wcześniej pozostawały w ERP, skrzynkach działu obsługi i firmowym repozytorium dokumentów. Historia zakupów, ceny, faktury, adresy dostaw i status realizacji mają wartość biznesową. Bezpieczeństwo portalu nie może więc ograniczać się do formularza logowania.
Najważniejsza zasada brzmi: każda operacja musi być autoryzowana w kontekście użytkownika, organizacji, oddziału i roli. Dotyczy to zarówno ekranów, jak i API, plików oraz zadań wykonywanych w tle.
Tożsamość użytkownika a konto firmy
W B2C konto zwykle należy do jednej osoby. W B2B użytkownik działa w imieniu organizacji. Może mieć dostęp do kilku spółek, oddziałów lub magazynów, a jego zakres obowiązków zmienia się w czasie.
Model danych powinien rozdzielać:
- osobę i sposób logowania,
- organizację będącą kontrahentem,
- oddział lub jednostkę organizacyjną,
- członkostwo użytkownika w organizacji,
- rolę i konkretne uprawnienia,
- powiązanie organizacji z identyfikatorem w ERP.
Takie rozdzielenie pozwala odebrać dostęp bez usuwania historii operacji i nie zmusza do współdzielenia jednego hasła przez kilku pracowników klienta.
Role muszą opisywać operacje
Nazwy „administrator”, „kupujący” i „podgląd” są punktem wyjścia. Dla każdej roli zapisz, co może zrobić:
- zobaczyć historię wszystkich oddziałów czy tylko własnego,
- pobrać fakturę lub WZ,
- skopiować wcześniejsze zamówienie,
- wysłać zamówienie do ERP,
- zarządzać adresami,
- zaprosić użytkownika i nadać mu rolę,
- zobaczyć ceny, limity albo warunki płatności.
Interfejs może ukrywać niedostępne funkcje, ale serwer musi ponownie sprawdzać uprawnienie. Ręczna zmiana adresu lub żądania API nie może omijać kontroli.
Separacja danych między organizacjami
Najpoważniejszym scenariuszem jest dostęp klienta A do zamówienia, dokumentu lub ceny klienta B. Do takiego błędu może dojść przez brak filtra organizacji, przewidywalny identyfikator, pamięć podręczną albo zadanie synchronizujące dane.
Kontrolę separacji stosuj na kilku poziomach:
- użytkownik ma aktywne członkostwo w organizacji,
- żądany rekord należy do tej organizacji lub dozwolonego oddziału,
- rola dopuszcza operację na typie rekordu,
- plik jest wydawany dopiero po autoryzacji,
- zapytania i cache uwzględniają identyfikator najemcy,
- logi nie ujawniają pełnych danych innego klienta.
Test powinien objąć nie tylko przyciski w portalu, ale również bezpośrednie adresy, parametry zapytań, eksporty i ponowione żądania.
Kiedy stosować MFA
MFA, nazywane także 2FA, ogranicza ryzyko po przejęciu hasła. Szczególnie warto wymagać go od administratorów organizacji, pracowników dostawcy oraz ról pobierających dokumenty finansowe albo zarządzających dostępem.
Decyzję można uzależnić od ryzyka:
- obowiązkowe MFA dla administratorów,
- opcjonalne lub stopniowo wdrażane dla pozostałych użytkowników,
- dodatkowe potwierdzenie przy zmianie danych wrażliwych,
- integracja z firmowym dostawcą tożsamości dla dużych klientów.
Kody odzyskiwania i procedura utraty urządzenia wymagają równie starannego projektu jak samo logowanie. Obsługa nie powinna omijać zabezpieczeń wyłącznie na podstawie prośby e-mailowej.
Sesje, próby logowania i odzyskiwanie dostępu
Ustal czas bezczynności, maksymalny czas sesji i zasady unieważniania tokenów po zmianie hasła lub odebraniu roli. Ograniczaj automatyczne próby logowania, ale nie blokuj konta w sposób umożliwiający łatwe odcięcie klienta przez osobę trzecią.
Proces odzyskiwania dostępu powinien:
- używać jednorazowego, krótko ważnego odnośnika,
- nie ujawniać, czy adres istnieje w bazie,
- unieważniać wcześniejsze żądania,
- rejestrować zmianę,
- powiadamiać użytkownika o wykonanej operacji.
Dokumenty i eksporty
Pliki są częstym miejscem pominięcia autoryzacji. Nie wystarczy, że lista faktur jest chroniona, jeśli sam plik ma publiczny URL. Serwer powinien weryfikować dostęp przy każdej próbie pobrania albo generować krótkotrwały, podpisany odnośnik po wcześniejszej autoryzacji.
Eksport zbiorczy wymaga tych samych reguł co ekran. Jeżeli powstaje asynchronicznie, wynik należy przypisać do organizacji i użytkownika, ustalić czas dostępności oraz kontrolować pobranie.
Log audytowy bez nadmiarowego gromadzenia danych
Rejestrowania wymagają przede wszystkim operacje, które pomagają wyjaśnić incydent lub spór:
- logowania i istotne nieudane próby,
- zaproszenie oraz usunięcie użytkownika,
- zmiana roli i zakresu oddziałów,
- pobranie ważnego dokumentu,
- złożenie, ponowienie lub anulowanie zamówienia,
- działania administracyjne pracowników dostawcy.
Log powinien zawierać czas, aktora, organizację, rodzaj operacji, wynik i identyfikator zasobu. Nie powinien przechowywać haseł, pełnych tokenów ani treści dokumentu. Retencję trzeba uzasadnić wymaganiami procesu i zasadami ochrony danych.
Testy bezpieczeństwa w kryteriach odbioru
Przed pilotem przygotuj co najmniej następujące scenariusze:
- użytkownik próbuje otworzyć zamówienie innej organizacji,
- pracownik oddziału A odczytuje bezpośredni URL oddziału B,
- rola podglądu wysyła żądanie złożenia zamówienia,
- usunięty użytkownik korzysta z wcześniejszej sesji,
- wygasły link odzyskiwania jest używany ponownie,
- plik dokumentu jest pobierany bez aktywnej sesji,
- administrator odbiera sobie lub innym krytyczne uprawnienie,
- ERP zwraca rekord z nieznanym identyfikatorem kontrahenta.
Wynik testu musi być jednoznaczny: odmowa dostępu, bez ujawniania treści i z odpowiednim śladem diagnostycznym.
Bezpieczeństwo jako część architektury
Najtańszy moment na określenie organizacji, ról i zasad dostępu przypada przed budową ekranów. Późniejsze dopisywanie separacji danych wymaga zmian w API, bazie, integracji i testach.
Bezpieczny portal nie udostępnia klientowi „kawałka ERP”. Tworzy kontrolowaną warstwę procesu z własnym modelem tożsamości, jednoznacznym zakresem danych i zachowaniem w sytuacji błędu.
Zobacz zakres MVP portalu klienta z rolami i integracją ERP →
