Sign-in risk policy for MFA

Úvod

Doporučuji si prohlédnou následující video, které mi poslal Bazi: https://www.youtube.com/watch?si=HYGz6jGHqtnyX2yJ&v=qItXM_oPmbA&feature=youtu.be .
Mě osobně docela překvapilo, jak moc jednoduše se dá dostat do 365ky, přestože je povolený MFA. Samozřejmě, je tu zapotřebí taky uživatelova nedbalosti, nicméně vzhledem k tomu jací jsou si troufnu předpokládat, že je úspěch takřka zaručen.
Říkám to každému, ale věřím tomu že spousta uživatelů „jinou“ doménu jednoduše přehlédne…

Hledal jsem, jestli je možné se nějak jednoduše bránit, a ano, jde to. Stačí využít nástroj, který už využíváme – podmíněný přístup. Nová politika dokáže něčemu podobnému účinně bránit.
Vyžaduje ovšem licenci Microsoft Entra ID P2.

 

Podmíněný přístup

Přihlaste se do portálu Azure a pokračujte na  .
V levém menu > > .

Novou zásadu pojmenujeme třeba ,
a postupně doplníme: Uživatelé – zahrnout – všechny uživatele, vyloučit – Uživatelé a skupiny: SA- [předpokládám, že nikdo z SA nebude v tomto případě hrozbou, a zajistím si tak „zadní vrátka“]:

Prostředky a cíle – Všechny cloudové aplikace:

Podmínky – Riziko přihlášení – Konfigurovat: Ano – Úroveň: Vysoká, Střední:

Udělení – Udělit přístup – Vyžadovat vícefaktorové ověření:

Relace – Frekvence přihlašování: pokaždé:

Tedy:

A doplníme tak původní MFA zásadu:

Diagnostika

Podobnou situaci jsem simuloval pomocí hotspotu tak, abych věděl, jak postupovat při chybném vyhodnocení.
Uživatele jsem téměř obratem zařadil na seznam „blokovaných“.
Vše je možné dohledat následovně:

> > Filtr: > .

V následném zobrazení je možné diagnostikovat příčinu a uživatele případně i odblokovat.

Závěr

Zásada funguje tak, že detekuje změnu, odkud dochází k připojení – IP. Pokud bylo přihlášení schváleno pro IP:A, nebude platné pro IP:B.
Ano, znamená to, že pokud uživatel přejde z LTE na WiFi nebo obráceně, bude po něm vyžadováno MFA ověření – dobrá cena za zvýšení zabezpečení…
Vyzkoušeno i změnou IP pomocí VPN.

Tímto způsobem je možné se podobným praktikám nějakým způsobem bránit. Uživatel by musel znovu zadat MFA, nikdy se ale nedozví kód, který má opsat :).
Jasně, sociální inženýr by mohl hledat způsob, zabezpečení je ale rozhodně o krok dál.

Zásada navíc nijak negativně neafektuje uživatele, kteří přistupují z důvěryhodných umístění, pro která získali přihlašovací token.
V podstatě nepoznají rozdíl.

Protože dedikovaná funkce „Tok kódu zařízení“ a „Přenos ověřování“ je zatím v betě/preview, zkouším pouze logovat.
Pokud se osvědčí jako funkční nástroj a nesloží celou infrastrukturu, doplním v blízké budoucnosti KB o další prvek zabezpečení.

Byl tento článek užitečný?