Kontrola uprawnień przed każdym działaniem w systemie

Gdy automatyzacja działa w kilku systemach, dział bezpieczeństwa słusznie pyta, dlaczego miałaby otrzymać wspólny klucz do wszystkiego. Instrukcja „nie modyfikuj danych kadrowych” nie zastępuje kontroli technicznej. Może zostać błędnie zinterpretowana albo ominięta podczas ataku.

Uprawnienia powinny być sprawdzane poza automatyzacją, przez osobny mechanizm podejmujący decyzję przed każdym działaniem. To wzorzec stosowany w autoryzacji między usługami. Automatyzacja jest traktowana tak samo jak każdy inny niezaufany klient systemu.

Jak to wygląda w praktyce

W systemie kontroli uprawnień żądanie zawiera tożsamość, jednostkę organizacyjną, klasę danych, rodzaj działania, możliwość jego cofnięcia i wymaganą liczbę zatwierdzeń. Przed wykonaniem operacji OPA sprawdza reguły dostępu i zwraca zgodę, odmowę albo wymóg drugiego zatwierdzenia przez człowieka. Każda odpowiedź zawiera przyczynę i wersję reguły.

W środowisku firmy trzeba osobno zmierzyć kompletność reguł, działanie integracji i opóźnienie decyzji. Sama obecność punktu decyzyjnego nie przesądza o jakości wdrożenia.

Reguły są zapisane i wersjonowane poza aplikacją wykonującą proces. Można je testować niezależnie, a zmiana uprawnień nie wymaga zmiany logiki automatyzacji.

Odmowa blokuje wydanie danych dostępowych

Po odmowie system docelowy nie wydaje danych dostępowych. Zakazane działanie nie może zostać wykonane, niezależnie od treści żądania.

Każdy z trzech systemów docelowych ma odrębną tożsamość techniczną i własny sposób uwierzytelnienia. Nie ma wspólnego klucza. Jednorazowe dane dostępowe są wydawane tylko na czas jednej dozwolonej operacji. Działania nieodwracalne i wrażliwe klasy danych wymagają drugiego zatwierdzenia przez człowieka.

Historia wyjaśnia każdą decyzję

Każda decyzja trafia do dziennika: kto wykonał żądanie, jakiego narzędzia i systemu dotyczyło, jaka była odpowiedź, przyczyna oraz wersja reguły. Wpis pozwala wyjaśnić, dlaczego działanie zostało dopuszczone. Test integralności wykrywa zmianę historii.

Katalog działań przed integracją

Kontrola działa tylko wtedy, gdy dostaje precyzyjne dane. Dla każdego narzędzia trzeba zdefiniować system docelowy, akcję, klasę danych, jednostkę organizacyjną, odwracalność i skutek biznesowy. Ogólne uprawnienie „dostęp do CRM” jest zbyt szerokie. Odczyt danych kontaktowych, zmiana osoby odpowiedzialnej za szansę i usunięcie rekordu powinny być trzema osobnymi działaniami.

Następnie powstaje macierz: kto może wykonać działanie, na jakich danych, w jakim kontekście i z iloma zatwierdzeniami. Nowe działanie bez pasującej reguły powinno zostać odrzucone. Trzeba też ustalić, co stanie się podczas awarii mechanizmu decyzyjnego.

Wdrożenie etapami

1. Zinwentaryzuj narzędzia, poświadczenia i działania wykonywane dziś przez ludzi.
2. Podziel działania według ryzyka, odwracalności i klasy danych.
3. Zbuduj macierz decyzji wraz z przypadkami odmowy i drugiego zatwierdzenia.
4. Umieść punkt egzekwowania przed usługą wydającą poświadczenia oraz systemem docelowym.
5. Testuj reguły automatycznie przy każdej zmianie, korzystając z kompletnej macierzy i przypadków regresyjnych.
6. Uruchom tryb obserwacji, porównując proponowane decyzje z decyzjami operatorów.
7. Włącz egzekwowanie najpierw dla działań tylko do odczytu, potem dla zmian odwracalnych.

Tryb obserwacji ujawnia zbyt szerokie reguły i brakujące dane, zanim automatyzacja otrzyma możliwość zmiany danych.

Co może pójść źle

Reguły nie pomogą, jeśli agent ma stałe poświadczenie omijające kontrolę. Ryzykiem jest też niepełny kontekst: błędna klasa danych lub jednostka organizacyjna prowadzi do poprawnej decyzji na złych danych wejściowych. Dlatego atrybuty muszą pochodzić z zaufanych systemów, a ich pochodzenie powinno znaleźć się w dzienniku.

Trzeba zaplanować awarię OPA, usługi wydającej poświadczenia i systemu docelowego. Dla operacji wrażliwych bezpieczne zachowanie oznacza odmowę oraz kolejkę do człowieka. Warto również ograniczyć czas ważności zatwierdzenia, aby stara zgoda nie mogła autoryzować późniejszego działania w zmienionym kontekście.

Test przed włączeniem egzekwowania

Przygotuj macierz obejmującą tożsamości, działania, klasy danych, sytuacje odmowy i wymagane zatwierdzenia. Dla każdego przypadku sprawdź decyzję OPA, powód, wersję reguły oraz zachowanie usługi wydającej dane dostępowe. Osobno przetestuj zmianę historii i przerwanie połączenia z systemem docelowym.

W pilotażu mierz odsetek zgód i odmów, liczbę błędnych odmów, czas drugiego zatwierdzenia, wygasłe zgody oraz każde żądanie, dla którego zabrakło reguły w aktualnym katalogu. Wyniki zależą od kompletności danych firmy i sposobu integracji.

Lista kontrolna architektury

• Agent nie przechowuje stałych poświadczeń systemów docelowych.
• Każda akcja ma nazwany typ, klasę danych i informację o odwracalności.
• Nowe lub nieznane działanie trafia do odmowy albo przeglądu.
• Decyzja o dostępie zapada przed wydaniem krótkotrwałego poświadczenia.
• Zatwierdzenie jest związane z konkretną akcją i wygasa.
• Dziennik zawiera kontekst, źródła atrybutów i wersję reguły.
• Testy obejmują zgody, odmowy, eskalacje i awarie zależności.
• Operator ma kolejkę odrzuconych spraw i czytelne uzasadnienie.

Jeżeli automatyzacja ma działać w ERP, CRM albo DMS, szczegóły kontroli znajdziesz na karcie systemu. Podczas bezpłatnego przeglądu procesu możemy pokazać odmowę wraz z regułą, która ją spowodowała.