Przejdź do treści

Dostęp warunkowy w Azure Active Directory

5
(1)

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ć 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:

Users and groups

Tym razem uwzględniamy wyłącznie grupę Home Office:

Choć w przypadku tej zasady nie ma raczej zagrożenia przypadkowego zablokowania dostępu administratorowi, to i tak pamiętamy o jego wykluczeniu:

Cloud apps or actions

W sekcji cloud apps or actions, tak samo jak w przypadku poprzedniej zasady, uwzględniam wszystkie aplikacje w chmurze:

Conditions

W przypadku tej zasady również niezbędne będzie wykluczenie lokacji „Biuro”. Brak takiego wykluczenie spowodowałby konieczność korzystania przez osoby należące do grupy „Home Office” z urządzeń zarządzanych przez organizację także wtedy, gdy łączyliby się oni z biura, co nie jest określone w warunkach tworzonych przez nas zasad:

Access Control: Grant

Pamiętając, że celem tej zasady jest zawężenie dostępu jedynie do urządzeń „należących” do organizacji, musimy określić odpowiednie warunki także w tej sekcji. W tym przypadku będzie to nadanie dostępu wraz z zaznaczeniem:

  • Require device to be marked as compilant
  • Require Hybrid Azure AD joined device

Dla poprawności działania niezbędne będzie również zaznaczenie opcje Require one of the selected controls. Ograniczamy w ten sposób konieczność wystąpienia tylko jednego warunku, aby dostęp został nadany:

Podsumowanie

Utworzona w ten sposób zasada jest uzupełnieniem dla tego tworzonej wcześniej. Taka konfiguracja pozwala nam na perfekcyjne spełnienie naszego założenia, co nie byłoby możliwe w przypadku tylko jednej zasady.

Weryfikacja poprawności konfiguracji – What If

W przypadku środowiska testowego, które z reguły nie zawiera wielu innych elementów, weryfikacja poprawności jest dość prosta. Wystarczy po prostu zalogować się na konto danego użytkownika i sprawdzić, czy dana zasada działa. W przypadku realnego środowiska nie jesteśmy przecież w stanie zalogować się na konto każdego użytkownika w naszym AD. Teoretycznie możemy utworzyć testowe konto z uprawnieniami użytkownika i przetestować działanie, ale nie da nam to 100% gwarancji. Jak więc poradzić sobie z weryfikacją, czy utworzone przez nas zasady działają zgodnie z założeniami? Z pomocą przychodzi nam tutaj wspomniana wcześniej funkcja What If:

What If pozwala nam na wprowadzenie dowolnych wartości, w polach odpowiadających tym z kreatora konfiguracji zasad. W ten sposób jesteśmy w stanie bardzo dokładnie przetestować wybrane przez siebie przypadki na konkretnym, istniejącym w naszym AAD użytkowniku. Za pomocą tego narzędzia możemy w szybki sposób przetestować zachowanie wszystkich istniejących zasad dla wybranych sytuacji. Przedstawię teraz kilka przykładów potwierdzających poprawność konfiguracji wcześniej utworzonych zasad. Nie będę tutaj omawiał poszczególnych pól – zostały one omówione przy okazji konfigurowania zasad:

Użytkownik spoza grupy „Home Office” loguje się spoza biura na komputerze należącym do organizacji

Wybieram więc użytkownika spoza grupy Home Office. Definiuję jego adres IP tak, aby wskazywał na połączenie spoza biura. Dodatkowo zaznaczam, że urządzenie jest oznaczone jako należące do organizacji. Jak widać w takim przypadku konfiguracja działa prawidłowo, zasada jest aplikowana – blokuje dostęp takiemu użytkownikowi:

Użytkownik należący do grupy „Home Office” loguje się spoza biura na komputerze należącym do organizacji

Modyfikuję konfigurację względem poprzedniego punktu, zamieniając użytkownika na takiego, który należy do grupy „Home Office”. Pozostałe parametry zostają bez zmian. Jak widać w takim przypadku zasada również działa poprawnie. Aplikowana jest jedynie druga zasada weryfikująca z jakiego urządzenia korzysta użytkownik. W przypadku urządzenia należącego do organizacji dostęp zostaje nadany:

Użytkownik należący do grupy „Home Office” loguje się z biura na komputerze obcym

W tym przypadku dostęp oczywiście nie powinien być w żaden sposób ograniczany. Utworzone przez nas zasady w żaden sposób nie poruszają dostępu z Biura. Dlatego też, niezależnie od użytkownika czy urządzenia nie powinna działać tutaj żadna z zasad. Jak widać wszystko działa poprawnie, w takim przypadku żadna z zasad nie jest aplikowana:

W ten sposób można weryfikować poprawność aplikowania zasad dla bardzo wielu scenariuszy. Sam mechanizm jest niezwykle prosty w obsłudze, a za jego pomocą można bardzo szybko zweryfikować zachowania zasad dla bardzo wielu sytuacji, wyjątków itp. Dlatego też, szczególnie na środowisku produkcyjnym, zawsze warto uruchomić zasady w trybie Report-only i dobrze zweryfikować poprawność ich konfiguracji.

Słowo końcowe

Jak widać dostęp warunkowy jest niezwykle skutecznym mechanizmem, pozwalającym na dokładne pokrycie nawet bardzo nietypowych sytuacji. Wystarczy tylko logiczne ułożenie sobie w głowie tego co i jak chcemy osiągnąć. Istotną cechą tego mechanizmu jest również łatwość jego konfiguracji. Choć sama logika niektórych zasad może przysparzać problemy, to realizacja poprzez „wyklikanie” nie wymaga wysokich umiejętności technicznych. Właśnie dlatego, ze względu na skuteczność i względną prostotę dostępu warunkowego, powinno ono znaleźć zastosowania dla niemalże wszystkich środowisk.

Coś jest dla Ciebie niezrozumiałe? Chciałbyś wyrazić opinię na temat artykułu? Znalazłeś jakiś błąd? Koniecznie daj mi o tym znać wysyłając maila lub wypełniając formularz!

Czy ten wpis był dla Ciebie przydatny?

Zostaw ocenę!

Średnia ocena 5 / 5. 1

Nikt nie ocenił jeszcze tego wpisu. Bądź pierwszym, który to zrobi!

Przykro mi, że post nie był dla Ciebie przydatny ...

Podziel się proszę swoją opinią

Twoja opinia jest dla mnie niezwykle ważna

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.