Dostęp warunkowy w Azure Active Directory

Dostęp warunkowy w Azure Active Directory jest jedną z metod zabezpieczania procesu uwierzytelniania w środowisku chmurowym Microsoft. Pozwala on zdefiniowanie zasad szczegółowo określających dostęp dla danej grupy użytkowników, a także określenie warunków, dla jakich mają być one aplikowane. Dzięki temu poprawnie skonfigurowany dostęp warunkowy jest niezwykle skutecznym mechanizmem, sprawdzającym się również w bardzo nietypowych sytuacjach.

W tym wpisie skoncentruję się przede wszystkim na omówieniu dostępnych opcji podczas konfiguracji oraz pokazaniu kilku scenariuszy, dla których ten mechanizm znajdzie swojej zastosowanie. Warto w tym miejscu wspomnieć o tym, że aby wykorzystać dostęp warunkowy będziemy potrzebowali licencji AAD Premium P1 lub wyższej.

Gdzie znaleźć dostęp warunkowy w AAD?

Aby znaleźć dostęp warunkowy w portalu Azure przechodzimy do Azure Active Directory (AAD):

Następnie w panelu po lewej stronie odnajdujemy sekcję Security:

W sekcji Security spośród szeregu dostępnych opcji wybieramy pierwszą – Conditional Access:

Znajdziemy tutaj dwie główne opcje:

New policy – pozwalającą na zdefiniowanie nowej zasady
What If – pozwalającą na zweryfikowanie poprawności aplikowania stworzonych zasad

Tworzenie nowych zasad

Zacznijmy od stworzenia nowej zasady za pomocą New policy. Po wybraniu tej opcji ukaże się nam kreator tworzenia nowej zasady:

Users and groups

Omówmy dostępne opcje od początku, zaczynając od „Users and groups”. W tej zakładce możemy określić zakres użytkowników, jaki będzie obejmowała tworzona zasada. Mamy tutaj do wyboru szereg dostępnych opcji, pozwalających na wskazanie konkretnych użytkowników. Dzielą się one na dwie główne kategorie, pozwalające na uwzględnienie wybranych użytkowników/grup – Include, oraz wykluczenie wybranych użytkowników/grup – Exclude.

Opcja Include pozwala na wybranie:

None – czyli żadne z użytkowników nie będzie objęty tworzoną zasadą
All users – zasada będzie aplikowana na wszystkich użytkowników w AAD, także tych dodanych jako użytkownicy zewnętrzni/goście.
Select users or groups – opcja pozwalająca na wybranie jasno sprecyzowanej grupy użytkowników, na podstawie ich przynależności do grup, przypisanych im ról czy statusu gościa/użytkownika zewnętrznego. Możemy tutaj również przypisać użytkowników w formie statycznej, tzn. wybrać konkretnych użytkowników, na których będzie aplikowana dana zasada

Opcja Exclude pozwala na wskazanie konkretnych użytkowników lub grupy, podobnie jak ma to miejsce w ostatniej z wyżej opisanych opcji. Dobrą praktyką przy tworzeniu zasad jest wykluczanie w sposób statyczny (wybierając konkretnego użytkownika) konta z uprawnieniami administratora, tak aby mieć możliwość wprowadzenia ewentualnych zmian. W ten sposób unikniemy sytuacji, gdy na skutek błędnej konfiguracji niektórych zasad odetniemy sobie dostęp np. do całego portalu Azure, a tym samym możliwości poprawienia konfiguracji zasad:

Cloud apps or actions

W kolejnym kroku, w sekcji Cloud apps or actions, określamy zakres działania zasady w kontekście konkretnej aplikacji w chmurze. Inaczej mówiąc, możemy tutaj określić, dla których aplikacji lub działań tworzona zasada będzie aktywna:

Conditions

W kolejnym kroku określamy warunki, dla których aplikowana będzie dana zasada. Warunki zostały tutaj podzielona na kilka kategorii:

User risk and Sign-in risk – obie te opcje bazują na mechanizmie Identity Protection. Mechanizm ten określa poziom ryzyka dla danego użytkownika czy logowania. Warunki te można wykorzystać np. do blokowania możliwości logowania do usług w chmurze dla ryzyka określonego jako minimum średnie. Takie ryzyko występuje, gdy np. użytkownik loguje się z nowego IP, czy w ciągu kilku minut ma logowanie z dwóch różnych części świata itp.

Device platforms – pozwala na uwzględnienie lub wykluczenie urządzeń na podstawie ich systemu operacyjnego. Możemy tutaj wybierać spośród pięciu zdefiniowanych systemów operacyjnych – Android, iOS, Windows Phone, Windows oraz macOS.

Locations – pozwala na uwzględnienie lub wykluczenie dostępu dla wskazanych w tworzonej zasadzie użytkowników na podstawie ich lokalizacji:

Lokacje możemy określać w sekcji Named locations. Możemy ją znaleźć poprzez znajdujące się na stronie Conditional Access menu po lewej stronie:

Lokacje możemy określać na podstawie adresu zakresu adresów IP lub Państwa. Mamy również opcje oznaczenia tworzonej lokacji jako zaufanej. Pozwala to np. na późniejsze wybranie „wszystkich zaufanych lokacji” tworząc zasadę w dostępie warunkowym:

Client apps – warunek pozwalający na określenie „za pomocą czego” użytkownik próbuje uzyskać dostęp do określonych w tworzonej zasadzie aplikacji. „Za pomocą czego” odnosi się tutaj min. do przeglądarki, aplikacji, aplikacji mobilnej

Device state – warunek pozwalający na uwzględnienie lub wykluczenie urządzeń, które są/nie są zarządzane przez organizacje (dołączone do AAD, Intune itp.):

Access Control: Grant

W tej sekcji możemy określić zachowanie (sposób działania) tworzonej zasady. Spośród dostępnych opcji możemy przede wszystkim wybrać, czy dostęp ma być blokowany lub nadawany. W przypadku nadawania dostępu mamy dodatkowo możliwość wyboru dodatkowych warunków – np. wymagania MFA przy logowaniu. Na dole mamy również możliwość określenia czy wymagane jest spełnienie jednego spośród wybranych warunków, czy wszystkich na raz.

Access Control: Session

Ostatnia spośród dostępnych sekcji – session, pozwala na określenie dodatkowych kontroli w kontekście sesji użytkownika. Można tutaj określić czas, po jakim dany użytkownik zostanie poproszony o ponowne uwierzytelnienie, czy określić, czy wymagane będzie ponowne uwierzytelnienie po zamknięciu i ponownym otwarciu okna przeglądarki:

Enable policy

Po odpowiednim skonfigurowaniu zakresu oraz warunków tworzonej zasady trzeba jeszcze określić „tryb jej działania”. W tym zakresie dostępne mamy 3 różne opcje:

Report-only – pozwala na weryfikację poprawności aplikowania utworzonej zasady, bez realnego wpływu na środowisko. Inaczej mówiąc, zasada utworzona w tym trybie pozwala nam sprawdzić (np. za pomocą funkcji What If, o czym za chwilę), czy działa ona dokładnie tak jak chcieliśmy. Nie ma ona jednak żadnego praktycznego wpływu na dostęp użytkowników, dopóki nie zostanie przełączona w tryb On
On – jak łatwo się domyślić, oznacza to, że tworzona zasada będzie od razu włączona i aplikowana
Off – jak również łatwo się domyślić, taka zasada zostanie utworzona, ale będzie wyłączona

Dostęp warunkowy w praktyce

Aby pokazać tworzenie oraz działanie utworzonej zasady wykorzystamy dowolny przykładowy scenariusz. Załóżmy na przykład, że interesuje nas utworzenie następującej zasady – tylko uprawnieni do pracy w trybie „Home Office” mogą logować się spoza biura, ale muszą do tego wykorzystywać urządzenia zarządzane przez organizację.

Przygotowanie środowiska

Z uwagi na to, że w moim przypadku będę realizował to zadanie w środowisku testowym, przed przystąpieniem do konfiguracji zasady muszę spełnić kilka podstawowych warunków:

posiadać kilka kont w Azure Active Directory.
Określić osoby uprawnione do pracy w trybie Home Office – np. w formie dedykowanej do tego grupy w Azure Active Directory

Posiadać zdefiniowaną lokację zawierającą pule adresów IP, które przypisane są do biura – w tym celu dodaję nową lokację. Tworzenie nowej lokacji zostało pokrótce omówione w sekcji Conditions -> Locations powyżej.

Tworzę przykładową lokalizację „Biuro” na podstawie puli adresów IP. Jako zakres adresów IP przyjmuje wszystkie adresy z zakresu 10.20.30.[0-256] oraz 1.2.[0-256].[0-256]. W taki sposób można np. skonfigurować zaufane adresy dla dwóch biur naszej organizacji. Dodatkowo oznaczam jeszcze lokację jako zaufaną

Konfiguracja zasady: Users and groups

Spełniając wyżej wymienione warunki możemy przystąpić do konfiguracji zasady. Przechodzę więc do kreatora i wybieram dowolną nazwę dla nowo tworzonej zasady. Następnie w sekcji Users and groups, w zakładce Include wybieram All Users, a w zakładce Exclude – grupę zawierającą użytkowników uprawnionych do pracy w trybie Home Office (oraz oczywiście konto administratora ze względów bezpieczeństwa):

Uwzględniam więc wszystkich użytkowników, aby podczas konfiguracji zablokować im dostęp do logowania z „Home Office”. Wykluczam całą grupę, czyli tym samym wszystkich użytkowników należących do grupy „Home Office”. W ten sposób wszyscy użytkownicy mają domyślnie zablokowany dostęp spoza biura, natomiast wystarczy dodać ich do odpowiedniej grupy, aby taki dostęp został im nadany przez system.

Ale dlaczego robię to w taki sposób, a nie odwrotnie – tj. uwzględniam osoby w grupie Home Office i nadaję im uprawnienia do logowania spoza biura? W takim przypadku faktycznie wszystkie osoby logujące się spoza biura posiadałyby odpowiedni dostęp. Natomiast pozostałe osoby, w przypadku mojego środowiska, nie zostałyby ujęte żadną inną zasadą. Oznacza to, że nic nie blokowałoby im dostępu spoza biura, więc osoby nieuprawnione nadal mogłyby się logować, co nie jest w tym przypadku zgodne z naszym celem.

Być może ktoś zastanawia się co w przypadku, gdy jedna zasada zabraniałaby wszystkim dostępu, a druga zezwalałaby na dostęp określonej grupie? Niestety taka konfiguracja również nie zadziała w naszym przypadki. Załóżmy, że blokujemy dostęp wszystkim użytkownikom za pomocą jednej zasady, a za pomocą drugiej nadajemy dostęp grupie „Home Office”. W takim przypadku, jak to zwykle bywa, block jest ważniejszy niż grant. Taka konfiguracja spowodowałaby więc zablokowanie dostępu wszystkim użytkownikom, nawet tym z grupy Home Office.

Konfiguracja zasady: Cloud apps or actions

W sekcji Coulud apps or actions wybieram opcję All cloud apps. W naszej zasadnie chodzi o generalny dostęp spoza biura, a nie dostęp wyłącznie do wybranej usługi. Z tego względu uwzględniam tutaj wszystkie aplikacje w chmurze:

Konfiguracja zasady: Conditions

W sekcji Conditions będziemy musieli skonfigurować dwa warunki. Pierwszym z nich będzie wykluczenie logowań w Biura (lokacji, którą utworzyliśmy wcześniej). Wynika to z tego, że na potrzeby tworzonej zasady interesują nas logowania wyłącznie spoza biura. Domyślnie zasada blokuje dostęp użytkownikom. Wykluczenie biura pozwoli zawęzić zakres działania zasady wyłącznie do logowań spoza tej lokalizacji (do logowania z biura uprawnieni są wszyscy):

Drugim z warunków, który musimy określić jest konieczność wykorzystania urządzenia dołączonego do AD/zarządzanego przez naszą organizację. Tutaj sprawa nieco się komplikuje. Wykluczenie takich urządzeń spowoduje, że dostęp nie będzie blokowany również nieuprawnionym osobom korzystającym z takich urządzeń. W takim przypadku nie ma możliwości (a przynajmniej ja jej nie znam) na skonfigurowanie takiego warunku w jednej zasadzie. Na szczęście zawsze można osiągnąć zamierzony cel za pomocą więcej niż jedne zasady.

Z tego względu aktualnie konfigurowana zasada ograniczy się w swoim działaniu jedynie do blokowania dostępu spoza biura nieuprawnionym użytkownikom. Dlatego też nie konfigurujemy żadnych dodatkowych warunków w tym miejscu.

Konfiguracja zasady: Access Control (Grant)

W sekcji Access Control -> Grant pozostaje nam jedynie zablokować dostęp dla aktualnej konfiguracji. Oprócz blokowania dostępu nie musimy tutaj (a nawet nie możemy) wybrać żadnych innych opcji):

Podsumowanie konfiguracji

Na koniec wybieramy odpowiednią opcję i tworzymy zasadę. W moim przypadku wybieram od razu opcję On, aby zasada była aktywna od razu po utworzeniu. Jeżeli nie jesteśmy pewni co do poprawności konfiguracji, sugeruję wybrać najpierw opcję Report-Only i porządnie ją przetestować:

Podsumujmy teraz, co udało się nam osiągnąć za pomocą tej zasady. Aktualnie zablokowaliśmy dostęp spoza biura wszystkim użytkownikom, którzy nie są przypisani do grupy „Home Office„. Tak jak wspominałem wcześniej, nasz cel nie jest jeszcze do końca spełniony. Aktualnie osoby należące do grupy „Home Office” będą mogły uzyskać dostęp niezależnie od używanego przez nie urządzenia. Pozostaje nam więc skonfigurować drugą zasadę, która ograniczy ten dostęp wyłącznie dla urządzeń zarządzanych przez organizację.

Tworzenie drugiej zasady

Konfiguracja drugiej zasady będzie oczywiście nieco inna niż pierwszej. Przede wszystkim interesują nas teraz wyłącznie osoby z grupy Home Office, więc zakres jest już nieco zawężony. Ale po kolei: