Funkcjonalność

Polityki adaptacyjne (Adaptive policy)

Jak działa: Podnosi wymagania, gdy logowanie lub sesja wygląda nietypowo.

WICCIC

W skrócie

Polityki adaptacyjne zmieniają to, czego wymaga od użytkownika operacja logowania - zależnie od ryzyka. Znany użytkownik na znanym urządzeniu przechodzi z mniejszymi utrudnieniami, a nietypowe żądanie rozpoczyna proces dodatkowej weryfikacji lub zostaje całkowicie odrzucone.124

Umów rozmowęJak to robią Okta i Auth0 ↓
5
rodzajów ataków, przed którymi pomaga chronić

Co to jest i jakie ataki zatrzymuje

Jedna stała reguła jest albo zbyt surowa dla codziennych logowań, albo zbyt łagodna dla nietypowych - albo użytkownicy się irytują, albo atakujący ma ułatwione zadanie.

Polityki adaptacyjne oceniają kontekst każdego logowania, na przykład sieć, urządzenie lub zachowanie, i stosują wymaganie, które do niego pasuje.234 Art. 21 ust. 2 lit. j dyrektywy NIS2 wymienia stosowanie uwierzytelniania wieloskładnikowego lub ciągłego uwierzytelniania wśród środków zarządzania ryzykiem cyberbezpieczeństwa.6

Adaptacyjne polityki logowania pomagają w sytuacjach, takich jak:

1

Logowania z nietypowych lokalizacji

Poprawne hasło zostaje użyte z kraju lub sieci, z której użytkownik zazwyczaj nie korzysta.

2

Wyciekłe hasła wypróbowywane z nowego urządzenia

Atakujący próbuje hasła z innego wycieku.

3

Niemożliwa podróż

To samo konto loguje się z dwóch odległych miejsc w krótkim czasie.

4

Logowania o nietypowej porze lub według nietypowego wzorca

Konto, które zwykle działa w godzinach pracy, nagle loguje się w nocy i otwiera wiele aplikacji.

5

Push fatigue (zasypywanie prośbami o zatwierdzenie)

Atakujący ze skradzionym hasłem wysyła prośby tak długo, aż ktoś kliknie „zatwierdź”. Przy nietypowym logowaniu polityka adaptacyjna może wymagać silniejszego faktora niż push.

Przed i po wdrożeniu funkcjonalności

Przed
Po
PrzedKażde logowanie ma to samo wymaganie.
PoWymaganie zależy od ryzyka logowania.12
PrzedLogowanie z nowego kraju wygląda tak samo, jak logowanie z biura.
PoW regułach polityki można używać warunków, takich jak strefa sieciowa lub zachowanie użytkownika.37
PrzedUżytkownicy dostają prośby bez przerwy, więc przestają zwracać na nie uwagę.
PoLogowania o niższym ryzyku mogą przechodzić z mniejszą liczbą próśb o potwierdzenie, a silniejsze faktory zostają dla bardziej ryzykownych logowań.1
PrzedLogowania klientów są obsługiwane zawsze tak samo.
PoAuth0 Adaptive MFA może ocenić sygnały ryzyka i poprosić o drugi faktor, gdy jest to potrzebne. Jest dostępne w planach Auth0 Enterprise jako dodatek.45

Jak to robią Okta i Auth0

Okta i Auth0 działają podobnie - oceniają sygnały przy logowaniu i stosują pasującą regułę.24

1

Użytkownik zaczyna logowanie

Użytkownik lub klient loguje się do aplikacji chronionej przez Okta lub Auth0.

2

Okta ocenia kontekst

Okta ocenia warunki polityki, takie jak strefa sieciowa i zachowanie, oraz sygnały ryzyka.347

3

Okta wybiera regułę

Okta sprawdza reguły polityki logowania do aplikacji po kolei i stosuje pierwszą, której warunki pasują do danego logowania. To ona określa, czego wymagać od użytkownika.2

4

Reguła określa wynik

Wynikiem może być uzyskanie dostępu, wymaganie silniejszego faktora MFA albo odmowa - zależnie od tego, jak admin skonfigurował regułę.24

WIC
Kogo chroniPracownicy, kontraktorzy, admini
App sign-in policiesReguły dla każdej aplikacji, które ustalają warunki i wymagane faktory MFA.2
Network zonesWskazują sieci zaufane i niezaufane, których reguły polityki mogą używać jako warunku.7
Behavior detectionPorównuje logowanie z typowym zachowaniem użytkownika, a wynik można wykorzystać w regule.3
Adaptive MFAOkta Adaptive MFA wymaga silniejszych faktorów, gdy ryzyko operacji jest wyższe.1
CIC
Kogo chroniUżytkownicy Twojej aplikacji
Adaptive MFAAuth0 Adaptive MFA może ocenić ryzyko logowania i poprosić o MFA, gdy pojawiają się sygnały ryzyka. Jest dostępne w planach Auth0 Enterprise jako dodatek.4
Sygnały ryzykaAuth0 ocenia sygnały, takie jak nowe urządzenie, niemożliwa podróż lub niezaufany adres IP.4
Faktory MFAAuth0 obsługuje wiele faktorów MFA dla logujących się użytkowników.5

Jak wdrażamy to w Zelto

Okta i Auth0 dostarczają warunki i reguły - Zelto ustala z Tobą, jakie sygnały generują Twoi użytkownicy w codziennej pracy i jaka reakcja pasuje do każdego z nich. Zaczynamy od tego, jak użytkownicy logują się dziś i zaostrzamy reguły etapami, aby zminimalizować ryzyko.

Typowy przebieg wdrożenia

  1. Sprawdzamy typowe wzorce logowania

    Spisujemy lokalizacje, sieci i urządzenia które są typowe dla każdej grupy.

  2. Definiujemy poziomy ryzyka i reakcje

    Z Twoim zespołem bezpieczeństwa ustalamy, które sygnały oznaczają wyższe ryzyko i czego wymaga każdy z nich: silniejszego faktora MFA albo odmowy.

  3. Pilotaż z adminami i działem IT

    Zaczynamy od adminów i działu IT - przeglądamy, które logowania uruchamiają regułę i czy uruchomienie było uzasadnione.

  4. Wdrażamy grupa po grupie

    Każda aplikacja i grupa dostaje w Okcie własną regułę polityki, a klienci dostają reguły w Auth0. Helpdesk dostaje instrukcję dla użytkowników, od których wymagamy dodatkowego sprawdzenia.

  5. Dostrajamy i przeglądamy

    Dostosowujemy reguły na podstawie fałszywych alarmów, a wyjątki przeglądamy regularnie.

Pułapki, które uwzględniamy w planie

Pracownicy podróżują lub pracują zdalnie.

−Blokujemy każde logowanie spoza sieci biurowej, więc uprawnieni użytkownicy tracą dostęp.

+W nieznanych lokalizacjach wymagamy silniejszego faktora MFA, a odmowę zostawiamy dla warunków o najwyższym ryzyku.

Reguły są dodawane z czasem przez różnych adminów.

−Dodajemy nową regułę po każdej skardze, aż nikt nie wie, która reguła obowiązuje.

+Utrzymujemy niewiele reguł w jasnej kolejności, z wyznaczonym właścicielem, i regularnie przeglądamy całą politykę.

Słabszy faktor jest dozwolony, gdy silny jest niedostępny.

−Akceptujemy słabszy faktor, jeżeli weryfikacja silniejszym faktorem się nie powiodła.

+Dla opcji zapasowej utrzymujemy ten sam poziom wymagań, a użytkownika kierujemy do procesu odzyskiwania dostępu, który weryfikuje jego tożsamość.

Klienci są sprawdzani zbyt często.

−Prosimy każdego klienta o drugi faktor przy każdym logowaniu, więc część z nich przestaje korzystać z aplikacji.

+Dodatkowe sprawdzenie włączamy na podstawie sygnałów ryzyka i dostrajamy reguły z zespołem produktowym na podstawie danych z logowań.

Chcesz reguł logowania, które podążają za ryzykiem, zamiast jednej stałej polityki logowania?

Sprawdzimy, jak dziś logują się Twoi pracownicy i klienci oraz jakich warunków możesz użyć. Potem powiemy, co należy zmienić w pierwszej kolejności.

Umów rozmowę30 minut, bez prezentacji. Sprawdzamy Twoje dzisiejsze polityki logowania.

Powiązane wpisy na blogu

Notatki z wdrożeń

Z Is For Zero Trust: Revalidate Access ContinuouslyCzytaj na blogu →

Źródła

Oficjalna dokumentacja Okta i Auth0 oraz źródła prawne

  1. 1Okta Adaptive MFAokta.com product page
  2. 2About app sign-in policiesOkta Help Center
  3. 3About behavior detectionOkta Help Center
  4. 4Adaptive MFAAuth0 Docs
  5. 5Multi-factor authenticationAuth0 Docs
  6. 6Directive (EU) 2022/2555 (NIS2)EUR-Lex
  7. 7Network zonesOkta Help Center