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 warstwie polityk żądanie zawiera tożsamość, jednostkę organizacyjną, klasę danych, rodzaj działania, możliwość jego cofnięcia i wymaganą liczbę zatwierdzeń. Przed wykonaniem operacji zewnętrzny punkt decyzyjny OPA zwraca zgodę, odmowę albo wymóg drugiego zatwierdzenia przez człowieka. Każda odpowiedź zawiera przyczynę i wersję reguły.

Wersja demonstracyjna używa fikcyjnych systemów i danych. Środowisko klienta wymaga osobnego pomiaru polityk, integracji i opóźnień.

Reguły są zapisane i wersjonowane poza aplikacją wykonującą proces. Można je testować niezależnie, a zmiana polityki 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 polityki. Wpis pozwala wyjaśnić, dlaczego działanie zostało dopuszczone. Test integralności wykrywa zmianę historii.

Zacznij od katalogu działań

Warstwa polityk wymaga precyzyjnych danych wejściowych. 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 właściciela szansy 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. Polityka powinna mieć bezpieczną odpowiedź domyślną dla nowych działań oraz jasno określone zachowanie podczas niedostępności punktu 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 polityki 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.

Takie wdrożenie pozwala znaleźć zbyt szerokie reguły i braki w opisie kontekstu, zanim automatyzacja otrzyma możliwość zmiany danych.

Co może pójść źle

Polityka nie pomoże, jeśli agent ma stałe poświadczenie omijające punkt egzekwowania. 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.

Pomiar

Macierz polityk przeszła wszystkie 640 kontroli obejmujących tożsamości, działania i klasy danych. W 647 ocenionych żądaniach nie wykonano żadnej nieautoryzowanej operacji, a kontrolowana zmiana dziennika została wykryta. W osobnej próbie mechanizm OPA zażądał drugiej zgody i nie dopuścił do wywołania systemu docelowego. Próba zużyła 696 tokenów, trwała 11,57 s i kosztowała szacunkowo 0,0032 zł.

Te liczby sprawdzają zamkniętą macierz fikcyjnych systemów. Nie potwierdzają kompletności polityk klienta ani opóźnień jego integracji. W pilotażu należy mierzyć odsetek zgód, odmów i eskalacji, błędne odmowy, czas drugiego zatwierdzenia, wygasłe zgody oraz operacje, dla których zabrakło reguły.

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 polityki 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ę polityki.
• 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.