Część 1
Gdzie szukać panelu konfiguracyjnego
Konfiguracja sieci
Część 2
Konfiguracja polityki dostępu warunkowego
Omówienie opcji
Część 3
Przykłady wymagań biznesowych
Jak je skonfigurować
Dostęp warunkowy Azure i jkonfiguracja polityk bedzie tematem drugiej cześci naszego przewodnika. Dowiesz się w niej jak skonfigurować politykę, które opcje są wymagane a które opcjonalne i za co odpowiadają.
Pisaliśmy już o tym
- Jak działa dostęp warunkowy
- Hierarchia polityk dostępu warunkowego
Dostęp warunkowy – Tworzenie nowej polityki
Po zalogowaniu do panelu konfiguracyjnego dostepu warunkowego, przejdź do widoku polityk wybierając opcję Policies (rys. 1) a nastepnie New Policy (rys. 2)
Okno dodawania nowej polityki składa się z 4 podstawowych sekcji.
1. Name – obowiązkowy
Nazwa polityki. Powinna być zrozumiała i jednoznacznie określać przeznaczenie polityki. Przykładem takiej nazwy może być np.: CA_POLICY_BLOCK_ALL_FROM_UNTRUST, albo: MFA_ALL_FROM_PUB
2. Assigments
Users and groups – parametr obowiązkowy. Lista użytkowników i/lub grup dla których polityka ma działać. Polityka zadziała TYLKO dla użytkowników skonfigurowanych w tym miejscu.
Cloud apps or actions – parametr obowiązkowy. Lista aplikacji do których łączy się użytkownik i/lub czynności które wykonuje. Polityka będzie działać TYLKO przy połączeniach do aplikacji tu skonfigurowanych.
Conditions – parametr opcjonalny. Dodatkowe warunki zawężające działanie polityki. Szczegóły w dalszej części.
3. Access controls
Grant – parametr obowiązkowy. Warunki pod którymi dostęp zostanie udzielony.
Session – parametr opcjonalny. Dodatkowe zaawansowane ustawienia. Dla podstawowych zastosowań nie są wymagane.
Ważne
Dostęp warunkowy działa PO WERYFIKACJI loginu i hasła, posiada więc dane na temat tego do jakich grup należy użytkownik i jakie ma przydzielone role administracyjne.
Zasada Działania Polityki Dostepu Warunkowego
Do systemu dociera połączenie. Rozpoczyna się proces sprawdzania polityk. Wykonywane są kolejne kroki:
Krok 1: Sprawdzenie warunku – Users and groups
Test: KTO WYKONUJE POŁĄCZENIE
Na przykład:
- użytkownik ma byc równy j.doe@ourdomain.com
- lub (OR) użytkownik ma należeć do grupy SALES
- i (AND) użytkownik NIE MA należeć do grupy PRIVILEDGED
Poza przynależnością do grup możesz wykorzystać także takie warunki jak: All guest and external users czy Directory roles
Wynik:
PRAWDA: przechodzimy do kolejnego warunku
FAŁSZ: koniec, ta polityka nie zostanie uruchomiona dla tego połączenia
Realne przykłady konfiguracji znajdziesz w ostatniej części naszego przewodnika.
Krok 2: Sprawdzenie warunku – Cloud apps or actions
Test: DO JAKIEJ APLIKACJI NASTĘPUJE POŁĄCZENIE
Na przykład:
- ma miejsce próba połączenia z Microsoft PowerApps
- lub (OR) ma miejsce próba połączenia z Office 365 SharePoint Online
- i (AND) NIE MA MIEJSCA próba połączenia do Project Online
W zakładce User actions dostępna jest opcja Register security information – opcja ta dotyczy rejestracji dodatkowego mechanizmu autentykacji dla MFA. Sprawdź akapit: Podstawowe Zasady O Których Musisz Pamietać
Wynik:
PRAWDA: przechodzimy do kolejnego warunku
FAŁSZ: koniec, ta polityka nie zostanie uruchomiona dla tego połączenia
Realne przykłady konfiguracji znajdziesz w ostatniej części naszego przewodnika.
Ważne
Krok 1 i Krok 2 – MUSZĄ MIEĆ ZDEFINIOWANE WARUNKI
Mogą to być warunki All users lub All cloud apps ale muszą zostać ustawione.
Krok 3 jest OPCJONALNY, nie musimy go konfigurować.
Daje on nam możliwość budowy różnych polityk dla tych samych grup uzytkowników i aplikacji w oparciu o dodatkowe parametry
Krok 3: Sprawdzenie Warunku – Conditions
Test następujących 5 warunków
Ważne:
- Sprawdzane są tylko warunki skonfigurowane
- Ogólny wynik jest iloczynem wyników warunków (skonfigurowanych) – jeżeli chociaż jeden warunek zwróci FAŁSZ, cały test zwraca FAŁSZ
Jeżeli chcemy aby polityka działała dla użytkownika DLA WSZYSTKICH SIECI – nie należy włączać warunku Locations i ustawiać Any location
PO PROSTU NIE WŁĄCZAMY tego warunku.
Tak samo z pozostałymi warunkami z sekcji Conditions.
Warunki w sekcji Conditions służą do ograniczenia działania polityki, jeśli nie są potrzebne – nie włączamy ich!
Sign-in-risk
Dla jakich poziomów ryzyka logowania polityka ma zadziałać.
Np. polityka ma zadziałać dla połączeń ocenionych jako:
sign-in-risk level = High lub Medium
Device platforms
Dla jakich systemów operacyjnych polityka ma zadziałać? Chodzi tu o system operacyjny na urządzeniu z którego użytkownik dokonuje aktualnego połączenia.
Locations
Możliwość określenia warunków dla adresacji IP z której nastepuje połączenie.
W tym momencie możesz wykorzystać zdefiniowane wcześniej definicje sieci. Omawialiśmy to w części 1,
w akapicie: nazwane lokalizacje
Client apps
Możliwość oreślenia warunku na aplikację kliencką z której korzysta użytkownik. Na przykład polityka ma działać tylko dla połączeń z przeglądarki internetowej.
Device state
Określenie warunku na podstawie stanu urządzenia w AAD i jego zgodności z politykami Intune. Na przykład: polityka ma zadziałać dla wszystkich połączeń wykonywanych z urządzeń które nie mają w AAD statusu: Device Hybrid Azure AD joined
Wynik (wszystkich 5 warunków, jeśli są skonfigurowane):
PRAWDA: przechodzimy do kolejnego warunku
FAŁSZ: koniec, ta polityka nie zostanie uruchomiona dla tego połączenia
Realne przykłady konfiguracji znajdziesz w ostatniej części naszego przewodnika.
Ok, warunki mamy Gotowe
W tej chwili, na podstawie przeprowadzonych testów: dotyczących:
- użytkownika i grup do których należy (to w sekcji konfiguracyjnej: Users and groups)
- docelowej aplikacji do której próbuje się połączyć (to w sekcji: Cloud apps and actions)
- opcjonalnych, dodatkowych ograniczeń (w sekcji Conditions)
System może zdecydować czy polityka ma zostać uruchomiona.
JEŻELI NIE: na tym skończy sie proces.
JEŻELI TAK: idziemy do Kroku 4
Krok 5: Nałożenie ograniczeń – Grant
Po serii weryfikacji przyszła kolej na decyzję. W tym kroku decydujemy wybierając jedną z dwóch możliwości:
Block access – nie zgadzamy się na takie połączenie i je blokujemy.
lub
Grant access – zezwalamy na połączenie ale pod pewnymi warunkami
Mogą to być warunki dowolnie wybrane spośród:
- Require multi-factor authentication
- Require device to be marked as compliant
- Require Hybrid Azure AD joined device
- Require approved client app
- Require app protection policy
Realne przykłady konfiguracji znajdziesz w ostatniej części naszego przewodnika.
I na koniec decydujemy czy wystarczy, że użytkownik spełni jeden z wybranych przez nas warunków, czy musi spełnić wszystkie.
Podstawowe Zasady O Których Musisz Pamietać
Jak skonfigurować politykę – procedura w kilku prostych krokach
- Ustal dla jakich warunków w postaci (użytkownik A łączy się do aplikacji B) ma działać polityka i skonfiguruj je w sekcjach Users and groups oraz Cloud apps or actions
- Pomyśl czy oczekujesz różnego poziomu zabezpieczenia w zależności od
- ryzyka logowania
- systemu operacyjnego użytkownika
- sieci z której się łączy
- aplikacji z jakiej korzysta
- stanu urządzenia
- Skonfiguruj je w sekcji Conditions
- Określ wymagania jakie stawiasz przed użytkownikiem i skonfiguruj je w sekcji Grant
- Na razie nie dotykaj sekcji Session
- Włącz politykę
All users and groups – Korzyści i niebezpieczeństwa
Polityka zadziała dla tych użytkowników, którzy spełnią warunki postawione w sekcji Users and groups.
Jeżeli konfigurujesz politykę i skonfigurujesz ją wybierając z listy wszystkie grupy (na przykład IT i Sales) – to jeśli pojawi się nowa grupa, np. HR, polityka nie zadziała dla jej członków .
Musisz pamiętać o aktualizowaniu polityk albo o pilnowaniu aby użytkownik zawsze był przypisany do określonej grupy. Nie jest to rozwiązanie bezpieczne.
Wybranie opcji All users wydaje się ciekawym rozwiązaniem tego problemu.
Jakie istnieje niebezpieczeństwo związane z włączaniem polityki dla wszystkich?
Przede wszystkim, możliwość zablokowania samego siebie i utraty dostępu nawet do panelu administracyjnego. pozostanie nam wtedy kontakt z supportem Microsoft.
W połączeniu z All cloud apps tworzy już bardzo śmiertelną mieszankę.
Jakieś sugestie?
Pamietaj
- Najpierw sprawdź działanie polityki na małej grupie osób a dopiero później włączaj ją dla wiekszej.
- Stwórz konto albo grupę Emergency_Access, która bedzie wyłączona z działania Dostepu Warunkowego. Niech będą to konta nie uzywane na codzień, przeznaczone do uzycia tylko w wyjątkowych sytuacjach.
Po dwóch częściach teoretycznych kolej na przykłady czysto praktyczne. W kolejnej, trzeciej już części naszego przewodnika przedstawię zagadnienia biznesowe z jakimi spotykam sie we wdrożeniach i pokażę jak moim zdaniem nalezy je skonfigurować.
Przydatne Linki
Co to jest dostęp warunkowy? – Dokumentacja Microsoft
https://docs.microsoft.com/pl-pl/azure/active-directory/conditional-access/overview
