Użytkownik może mieć prawo do utworzenia nowego dostawcy w systemie finansowym. Ktoś inny może zatwierdzać płatności dla tego dostawcy. Problem zaczyna się, gdy obydwa uprawnienia trafiają do jednej osoby. Każde z osobna jest uzasadnione biznesowo, ale ich połączenie tworzy ryzyko, którego nie rozwiąże MFA, Conditional Access ani nawet poprawnie skonfigurowany RBAC.

Autor: 7 min czytania

Czy Entra ID umie w SoD?

To właśnie jeden z klasycznych przypadków Segregation of Duties – SoD, czyli rozdzielenia obowiązków. O SoD pisaliśmy już na Kapitanie Hacku przy okazji systemów IGA, wskazując, że ich zadaniem jest między innymi wykrywanie potencjalnie niebezpiecznych kombinacji dostępów. Czy system IGA jest niezbędny? – Kapitan Hack

Skoro jednak Microsoft rozwija Entra ID Governance jako platformę przejmującą coraz więcej funkcji klasycznych systemów IGA, pojawia się naturalnie pytanie, czy SoD można dziś zrobić bezpośrednio w Entra ID.

Odpowiedź brzmi – można. Trzeba jednak dobrze rozumieć, na jakim poziomie Entra widzi konflikt.

Access Package jako jednostka dostępu

Mechanizm SoD znajduje się w Entitlement Management. Jego podstawą nie jest pojedyncze uprawnienie, lecz Access Package, czyli pakiet dostępu.

Pakiet może zawierać między innymi członkostwo w grupach Entra ID, role aplikacyjne Enterprise Applications, dostęp do Teams czy SharePoint. Użytkownik nie musi więc wnioskować osobno o pięć uprawnień technicznych. Może otrzymać pakiet odpowiadający określonej funkcji biznesowej.

Microsoft opisuje Entitlement Management właśnie jako mechanizm zarządzania cyklem życia dostępu, obejmujący wnioskowanie, zatwierdzanie, przypisanie, przeglądy oraz wygasanie dostępu. Microsoft Learn – Entitlement Management

To ważne, ponieważ SoD w Entra działa właśnie na tak zbudowanym modelu.

Załóżmy, że mamy dwa pakiety:

  • Supplier Management – pozwalający tworzyć i modyfikować dostawców,

oraz

  • Payment Approval – pozwalający zatwierdzać płatności.

W konfiguracji pierwszego pakietu można wskazać drugi jako Incompatible access package. Jeśli użytkownik posiada już jeden z nich, Entra nie pozwoli mu uzyskać drugiego. Microsoft nazywa tę funkcję wprost – Separation of duties. Microsoft Learn – Configure separation of duties checks

Konfliktem może być również grupa

Nie każdy dostęp w organizacji jest jednak zarządzany przez Access Packages. Część może nadal wynikać ze zwykłego członkostwa w grupie.

Microsoft uwzględnił również taki scenariusz. Jako element niekompatybilny można wskazać security-enabled group. Jeżeli użytkownik należy do takiej grupy, nie będzie mógł uzyskać określonego pakietu.

Co ciekawe, grupa może pochodzić również z lokalnego Active Directory i być synchronizowana do Entra ID. Dzięki temu SoD w chmurze może uwzględnić dostęp, który faktycznie realizowany jest przez starszą aplikację, działającą jeszcze on-premises.

Może być to bardzo istotne podczas migracji z MIM lub innego klasycznego IDM. Nie trzeba od razu przenosić wszystkich aplikacji do modelu cloud-native, żeby zacząć kontrolować część konfliktów w Entra.

Blokada działa również na administratora

Sama blokada formularza w My Access nie byłaby jeszcze szczególnie mocnym zabezpieczeniem. Administrator mógłby przecież ominąć proces i przypisać dostęp ręcznie.

W przypadku SoD Microsoft poszedł krok dalej. Jeżeli Access Package jest skonfigurowany jako niekompatybilny z pakietem już posiadanym przez użytkownika, administrator nie może utworzyć konfliktującego bezpośredniego przypisania. Najpierw trzeba usunąć istniejący dostęp.

Istnieje jednak pewien szczegół, o którym łatwo zapomnieć: relacja niekompatybilności jest jednokierunkowa. Jeśli pakiet A ma blokować B i jednocześnie B ma blokować A, regułę trzeba skonfigurować po obu stronach.

A co z konfliktami, które już istnieją?

Wyobraźmy sobie, że SoD wdrażamy dopiero dzisiaj, a użytkownicy od kilku lat gromadzą uprawnienia. Samo utworzenie reguły nie odbierze automatycznie istniejącego dostępu.

Entra pozwala natomiast sprawdzić, którzy użytkownicy posiadają już przypisania do niekompatybilnych pakietów. Informację można uzyskać w Entra admin center, przez Microsoft Graph lub PowerShell. Microsoft udostępnia również raporty Entitlement Management umożliwiające analizę przypisań użytkownika. Microsoft Learn – Entitlement Management reports and logs

Mamy więc dwa elementy typowe dla SoD: prewencję, która ma zatrzymać powstanie nowego konfliktu, oraz detekcję, która pomaga odnaleźć konflikty już istniejące.

A co, jeśli konflikt trzeba zaakceptować?

W praktyce zdarzają się wyjątki. Administrator może chwilowo potrzebować dostępu zarówno do środowiska developerskiego, jak i produkcyjnego, albo jedna osoba może czasowo wykonywać obowiązki dwóch zespołów.

Microsoft proponuje wtedy ciekawe rozwiązanie: zamiast wyłączać regułę SoD, można utworzyć osobny Access Package reprezentujący wyjątek. Może on wymagać dodatkowej akceptacji, mieć krótszy czas ważności i częstszy Access Review. Dzięki temu odstępstwo nie znika w konfiguracji technicznej, ale staje się osobnym, widocznym elementem procesu governance.

Z punktu widzenia audytu jest to zdecydowanie lepsze niż dopisywanie kolejnego wyjątku do Excela.

Czy to już pełnoprawny silnik SoD?

I tutaj dochodzimy do najważniejszego ograniczenia.

Entra dobrze radzi sobie z SoD wtedy, gdy dostęp został odpowiednio zamodelowany jako Access Packages, role aplikacyjne i grupy. Nie oznacza to jednak automatycznej analizy każdego uprawnienia istniejącego w każdej z aplikacji organizacji.

Klasyczny system IGA może analizować rozbudowaną matrycę konfliktów obejmującą tysiące granularnych uprawnień, na przykład transakcje SAP, role biznesowe czy kombinacje uprawnień pochodzących z wielu niezależnych systemów. W Entra konflikt egzekwowany jest przede wszystkim pomiędzy obiektami, które zostały włączone do modelu Entitlement Management.

To rozróżnienie jest bardzo ważne. Sam fakt, że w aplikacji istnieją dwa konfliktujące uprawnienia, nie oznacza jeszcze, że Entra automatycznie odkryje ich biznesowe znaczenie. Najpierw ktoś musi zdecydować, że te dostępy się wykluczają i odwzorować tę zależność w modelu governance.

Czy Entra ID potrafi więc SoD?

Tak – i nie jest to wyłącznie raport ostrzegający administratora po fakcie. Entra może aktywnie uniemożliwić powstanie konfliktującego przypisania, uwzględnić istniejące grupy, wskazać już występujące konflikty i obsłużyć kontrolowane wyjątki.

Nie jest jednak magicznym silnikiem, który sam zrozumie procesy biznesowe organizacji.

I być może właśnie tutaj leży największa różnica między zarządzaniem dostępem a Identity Governance. Blokada techniczna jest stosunkowo prosta. Najtrudniejsze pozostaje określenie, które dwa dostępy nigdy nie powinny znaleźć się w rękach tej samej osoby.