Jedna aplikacja, wiele firm. Gdzie przebiega granica danych?

Wspólna aplikacja może obsługiwać wiele firm i nadal pokazywać każdej wyłącznie jej własne sprawy. Warunek brzmi prosto. Trudniej sprawdzić go w miejscu, w którym pracownik pobiera eksport, integracja ponawia zadanie, a administrator pomaga użytkownikowi odzyskać dostęp. Każda z tych czynności przechodzi przez inny fragment systemu. Granica między firmami musi obowiązywać na każdym z nich.

Wyobraźmy sobie platformę obsługującą zlecenia serwisowe kilku przedsiębiorstw. Pracownik firmy A widzi listę urządzeń, zmienia termin przeglądu i pobiera historię naprawy. Firma B korzysta z tego samego ekranu, ale jej dane nie powinny pojawić się w wyszukiwaniu, eksporcie ani odpowiedzi API firmy A. To przykład projektowy, nie opis zrealizowanego wdrożenia. Już na nim widać, że samo ukrycie przycisku nie rozwiązuje problemu.

Zanim powstanie architektura, warto nazwać jednostkę, którą system oddziela. Czy jest nią klient, jego oddział, spółka należąca do grupy, a może konkretny kontrakt? To ustalenie wpływa na sposób nadawania dostępu, obsługę wyjątków i późniejsze raporty. Jeśli przygotowujesz podobną usługę, wyślij nam brief z opisem użytkowników, danych oraz sytuacji, w których granice organizacji mogą się przecinać. Nie dołączaj haseł ani danych uwierzytelniających.

Najpierw ustal, co należy do organizacji

Punktem wyjścia jest lista zasobów: użytkowników, dokumentów, zleceń, plików, raportów, integracji i zadań wykonywanych w tle. Dla każdego z nich trzeba odpowiedzieć, kto jest właścicielem, kto może go odczytać, kto może go zmienić oraz co dzieje się po usunięciu lub odebraniu dostępu. W praktyce nawet załącznik do jednego zgłoszenia ma własny cykl życia i może zostać pobrany poza ekranem szczegółów.

Nie wszystkie elementy należą do jednej firmy w ten sam sposób. Katalog typów urządzeń może być wspólny, ale cena naprawy i historia konkretnego urządzenia są przypisane do klienta. Czasem jedna osoba pracuje dla kilku organizacji. Wtedy logowanie identyfikuje osobę, a wybór aktywnej firmy wskazuje kontekst, w którym wykonuje ona operację. Ten kontekst musi zostać zweryfikowany po stronie serwera, a nie tylko wyświetlony obok nazwiska w nagłówku.

Osobne pytanie dotyczy danych wspólnych celowo. Partner serwisowy może potrzebować dostępu do wybranych zleceń kilku firm, ale nie do całej ich dokumentacji. Zamiast nadawać mu ogólną rolę administratora, opisz zakres współpracy: organizację, rodzaj sprawy, dozwolone działania i moment wygaśnięcia. W tekście o dostępie do dokumentów wykorzystywanych przez asystenta AI pokazujemy podobny problem z innej strony: osoba i narzędzie nie powinny dostawać szerszego dostępu tylko dlatego, że potrafią z niego skorzystać.

Logowanie, rola i granica klienta odpowiadają na różne pytania

Logowanie potwierdza tożsamość. Rola opisuje przyznane uprawnienia, na przykład możliwość edycji zleceń. Izolacja organizacji ogranicza zasoby, na których wolno wykonać dane działanie. Trzeba sprawdzić wszystkie trzy warunki. Użytkownik może mieć prawo edytować zlecenia, ale wyłącznie w firmie, do której został przypisany. Poprawna rola nie powinna otwierać rekordu innej organizacji, nawet gdy ktoś zna jego adres lub identyfikator.

AWS w materiałach o architekturze usług dla wielu klientów rozdziela uwierzytelnienie, autoryzację i izolację organizacji. To przydatne rozróżnienie podczas odbioru: test samego logowania nie dowodzi jeszcze, że wszystkie ścieżki danych respektują granicę klienta. Z kolei wskazówki OWASP dotyczące autoryzacji zwracają uwagę na sprawdzanie dostępu przy każdym żądaniu. Szczegóły zależą od architektury i nie sprowadzają się do jednej biblioteki ani jednego ustawienia.

Weźmy zapis zmian w formularzu. Przeglądarka może przekazać identyfikator zlecenia, lecz serwer musi ustalić, czy dana osoba działa w odpowiedniej organizacji i czy wolno jej wykonać żądaną zmianę. Ta sama zasada dotyczy usuwania, eksportu oraz pobrania pliku. Artykuł o API i webhookach opisuje dodatkowo, dlaczego potwierdzenie przyjęcia wiadomości nie jest tym samym co bezpieczne wykonanie całej operacji.

Sprawdź granice poza głównym ekranem

Lista zleceń bywa dobrze zabezpieczona, a mniej oczywista ścieżka pozostaje poza testem. Eksport do arkusza korzysta z osobnego zapytania. Wyszukiwarka indeksuje pola z kilku źródeł. Raport jest tworzony w tle, a jego gotowy plik trafia pod adres używany przez przeglądarkę. Jeżeli którąkolwiek z tych ścieżek zbudowano bez kontekstu organizacji, poprawny widok listy nie wystarczy. Dostęp trzeba sprawdzić również przy przejściu z dashboardu operacyjnego do szczegółów konkretnej sprawy.

Dla każdego procesu warto narysować drogę danych od wejścia do wyniku. Przy eksporcie będzie to osoba, wybrana organizacja, zakres raportu, zadanie w tle, plik wynikowy i uprawnienie do jego pobrania. Pytanie kontrolne brzmi: czy system nadal wie, dla kogo i przez kogo powstał plik, kiedy użytkownik otwiera go kilka minut później? Jeżeli dostęp pracownika został w międzyczasie odebrany, projekt musi określić, czy pobranie pozostaje możliwe i na jakiej podstawie.

Podobnej analizy wymagają pamięci podręczne. Wspólny klucz, w którym pominięto organizację albo zakres uprawnień, może zwrócić wynik przygotowany dla innego użytkownika. Nie oznacza to, że każdy system powinien zrezygnować z cache. Oznacza, że identyfikator i czas życia zapisanej odpowiedzi trzeba uzgodnić z modelem dostępu. Wątek jest bliski definiowaniu wskaźników w dashboardzie: ta sama nazwa liczby nie oznacza, że każdy ma prawo zobaczyć jej wszystkie składniki.

Integracje i zadania w tle też potrzebują kontekstu

Automatyzacja nie ma ekranu, na którym wybiera się firmę, ale nadal działa w czyimś imieniu. Zdarzenie z systemu zewnętrznego powinno zostać powiązane z właściwą organizacją w sposób, który można zweryfikować. Nie wystarczy przyjąć nazwę firmy z dowolnego pola wiadomości. Trzeba ustalić, jak identyfikujemy źródło, jak mapujemy konto dostawcy do organizacji i co robimy, gdy mapowanie jest niejednoznaczne.

W kolejce zadań zapisuj tylko informacje potrzebne do bezpiecznego wykonania i diagnozy. Operator powinien móc znaleźć nieudaną próbę, nie otrzymując przy okazji dostępu do kompletu danych wszystkich klientów. Jeśli zadanie zostanie wznowione, ponownie sprawdź warunki, które mogły się zmienić: aktywność organizacji, uprawnienia konta technicznego i dostępność połączenia. Monitoring automatyzacji i obsługa błędów pomagają ustalić, co powinno trafić do operatora, a co do bezpiecznego dziennika technicznego.

Gdy z tych samych narzędzi korzysta model AI, jego propozycja wywołania nie jest dowodem uprawnienia. Serwer nadal sprawdza tożsamość, organizację, rodzaj operacji i parametry. Przy działaniu wymagającym zgody trzeba pokazać uprawnionej osobie konkretną wersję propozycji. O tym, jak oddzielić przygotowanie od wykonania, piszemy w artykule o zatwierdzaniu działań agenta.

Pomoc administratora nie powinna oznaczać klucza do wszystkiego

Zespół obsługi czasem musi odtworzyć problem, którego klient nie potrafi dokładnie opisać. Warto wcześniej uzgodnić, jak uzyskuje dostęp, kto go zatwierdza, jak długo obowiązuje i jakie czynności są zapisywane. Dane produkcyjne nie muszą być domyślnym materiałem do każdego zgłoszenia. Część problemów można odtworzyć na przygotowanym koncie testowym lub na danych zastępczych.

Jeżeli dostęp do rzeczywistej sprawy jest potrzebny, jego zakres powinien odpowiadać zadaniu. Ważna jest też czytelna odpowiedź na pytanie, co widzi klient: czy zostanie poinformowany o sesji pomocy, czy może ją zakończyć i kto wyjaśni skutki zmian. To decyzje organizacyjne i projektowe, które trzeba ustalić przed wdrożeniem. Sam przycisk „wejdź jako użytkownik” nie jest jeszcze procedurą wsparcia.

Podczas przekazywania rozwiązania zapytaj o konta techniczne, właścicieli usług, sposób odebrania uprawnień i dostęp do kodu. Są to elementy przekazania i utrzymania aplikacji, a nie szczegóły, które warto zostawić na ostatni dzień. Firma powinna wiedzieć, jak zareagować, gdy osoba administrująca systemem zmieni obowiązki albo przestanie współpracować z projektem.

Jak odebrać izolację danych

Przygotuj co najmniej dwie organizacje testowe z podobnymi rekordami, różnymi użytkownikami i łatwymi do rozpoznania danymi. Następnie sprawdź odczyt, zapis, wyszukiwanie, pobranie, eksport i zadania w tle. Zmień identyfikator rekordu w żądaniu, spróbuj otworzyć wcześniej zapisany adres pliku po odebraniu dostępu i sprawdź, czy raport jednej firmy nie zawiera wierszy drugiej. Wynik testu ma opisywać obserwowane zachowanie, nie obietnicę, że system jest odporny na każdy możliwy atak.

Dodaj przypadki wynikające z życia usługi: osoba należy do dwóch firm i zmienia kontekst, partner ma dostęp tylko do części zleceń, a użytkownik traci uprawnienie, kiedy eksport jest w kolejce. Weryfikuj również odpowiedzi błędów. Czasem sam komunikat może zdradzić, że cudzy rekord istnieje, choć nie pokazuje jego szczegółów. Uzgodnij, jakie informacje są potrzebne uprawnionej osobie, a jakie powinny pozostać niedostępne.

Testy powinny wracać przy zmianie funkcji, integracji i zasad dostępu. Raport wygenerowany dzisiaj może działać poprawnie, a jego następna wersja może pobrać dane z nowego źródła z pominięciem organizacji. Zapisz więc przypadki odbiorowe razem z warunkami, które muszą spełnić. Testowanie asystenta AI wymaga podobnego podejścia do powtarzalności: potrzebne są przykłady, wynik oczekiwany i decyzja, co zrobić po wykryciu odchylenia.

Warto przeprowadzić także próbę zmiany granic organizacji. Firma może połączyć oddziały, wydzielić spółkę albo przekazać wybrany obszar innemu podmiotowi. Zanim rozpocznie się przenoszenie danych, trzeba ustalić, które rekordy rzeczywiście zmieniają właściciela, kto potwierdza listę i czy wcześniejszy dostęp ma wygasnąć jednocześnie dla wszystkich użytkowników. Historia działania, powiązane dokumenty i zależne raporty mogą wymagać osobnej decyzji. Przeniesienie kilku wierszy w bazie bez sprawdzenia tych powiązań pozostawia problem w miejscach, których nie widać na ekranie administracyjnym.

Przygotuj plan próbnego przeniesienia na danych testowych oraz sposób uzgodnienia wyników. Osoba odpowiedzialna po stronie firmy powinna móc porównać liczbę spraw i przykładowe powiązania przed operacją i po niej. Jeśli pojawi się rozbieżność, proces potrzebuje czytelnego punktu zatrzymania oraz osoby uprawnionej do decyzji. Dopiero potem warto rozstrzygać, czy daną zmianę da się cofnąć w całości, czy potrzebne będą działania naprawcze dla dokumentów lub wiadomości, które zdążyły już opuścić aplikację.

Przy wspólnych katalogach i słownikach określ, kto może proponować zmianę nazwy oraz jak zmiana wpływa na dotychczasowe dane klientów. Globalna korekta opisu kategorii może być potrzebna wszystkim, ale nie powinna automatycznie zmieniać uzgodnionych oznaczeń w dokumentach konkretnej firmy. Dobrym materiałem do rozmowy są dwa przykładowe rekordy: jeden świadomie wspólny, drugi należący do wybranej organizacji. Na ich podstawie łatwiej ustalić odpowiedzialność, niż rozstrzygać ją przy pierwszej prośbie o eksport.

Jeżeli planujesz platformę dla wielu firm, opisz nam najważniejszy proces i granice odpowiedzialności przez formularz kontaktowy. W ramach projektowania oprogramowania na zamówienie możemy przełożyć te informacje na role, ścieżki danych oraz sprawdzalne scenariusze odbioru. W briefie wystarczą przykładowe nazwy i opis sytuacji; prawdziwe dane klientów nie są potrzebne do pierwszej rozmowy.