Dostęp Warunkowy – Instrukcja Konfiguracji Krok Po Kroku – Część 2

Dostęp Warunkowy krok po kroku. Chcesz skonfigurować dostęp warunkowy i nie jesteś pewien jak dobrze to zrobić? Ten poradnik jest dla Ciebie.

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ą.

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)

Lista polityk dostępu warunkowego Azure
Rys. 1
Dostęp warunkowy Azure - dodaj nową politykę
Rys. 2

Okno dodawania nowej polityki składa się z 4 podstawowych sekcji.

1. Nameobowią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 actionsparametr 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.

Conditionsparametr opcjonalny. Dodatkowe warunki zawężające działanie polityki. Szczegóły w dalszej części.

3. Access controls

Grantparametr obowiązkowy. Warunki pod którymi dostęp zostanie udzielony.

Session parametr opcjonalny. Dodatkowe zaawansowane ustawienia. Dla podstawowych zastosowań nie są wymagane.

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.

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.

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
  1. 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
  2. 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
  3. Skonfiguruj je w sekcji Conditions
  4. Określ wymagania jakie stawiasz przed użytkownikiem i skonfiguruj je w sekcji Grant
  5. Na razie nie dotykaj sekcji Session
  6. 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?

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

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *