Jak dojść do niemal pełnego pokrycia MFA

dlaczego niemal pełne pokrycie to prawdziwy cel

Częściowe MFA daje fałszywe wrażenie postępu. Firma, która włącza MFA dla głównej populacji pracowników i widzi na dashboardzie 90% pokrycia, często traktuje wdrożenie jako zakończone. Pozostałe 10% rzadko jest przypadkowe. Zwykle to konta, które trudno było zarejestrować: współdzielone loginy, konta serwisowe, kontraktorzy, dyrektor, który poprosił o wyjątek, stara skrzynka mailowa, której nikt nie chciał ruszać. To też są konta, które najbardziej lubi atakujący, bo jedyne, co stoi mu na drodze, to hasło.

Atakujący nie testuje każdego konta wobec Twojej najsilniejszej kontroli. Szuka konta, które wciąż akceptuje samo hasło, i celuje w nie. Kampanie credential stuffing i password spray są zbudowane właśnie po to, żeby znajdować takie konta na skalę. Dziewięćdziesiąt procent pokrycia oznacza, że jedno na dziesięć kont wciąż jest celem jednoskładnikowym, a atakującemu wystarczy jedno.

Dlatego celem jest liczba bliska 100%, konto po koncie, a nie wysoka średnia. Pokrycie ma sens tylko wtedy, kiedy obejmuje każdą ścieżkę uwierzytelniania i każdy typ konta.

metody, od najsilniejszej do najsłabszej

Nie każdy drugi czynnik daje tę samą ochronę. „MFA” obejmuje szereg metod, które bardzo różnią się tym, jak dobrze opierają się realnej próbie phishingu, a liczba pokrycia licząca je wszystkie tak samo to ukrywa.

• Passkeys, klucze bezpieczeństwa FIDO2 · Siła: Najsilniejsza (odporna na phishing) · Przed czym chroni: Phishing, proxy typu adversary-in-the-middle, powtórne użycie danych logowania. Czynnik jest związany z legalną domeną. · Przed czym nie chroni: Fizyczna kradzież urządzenia w połączeniu z PIN-em albo biometrią, która je odblokowuje, wąski przypadek.
• Push w aplikacji z number matching · Siła: Silna · Przed czym chroni: Push fatigue i ślepe zatwierdzanie, bo użytkownik musi wpisać numer pokazany na ekranie. · Przed czym nie chroni: Proxy typu adversary-in-the-middle w niektórych przepływach. Lepsza niż zwykły push, ale nie odporna na phishing.
• Kody TOTP z aplikacji authenticator · Siła: Dobra · Przed czym chroni: Ataki oparte tylko na haśle, SIM-swap, przechwycenie SMS. Kod nigdy nie przechodzi przez sieć telefoniczną. · Przed czym nie chroni: Phishing typu adversary-in-the-middle, który przechwytuje kod w czasie rzeczywistym w krótkim oknie jego ważności.
• Kody jednorazowe SMS i głosowe · Siła: Najsłabsza · Przed czym chroni: Ataki oparte tylko na haśle na najbardziej podstawowym poziomie. · Przed czym nie chroni: SIM-swap, przechwycenie SS7 i phishing w czasie rzeczywistym. CISA i NIST SP 800-63B traktują SMS jako najsłabszy dostępny czynnik.

Praktyczny wniosek: każde MFA jest lepsze niż jego brak, więc SMS wciąż jest realną poprawą względem samego hasła dla zwykłego użytkownika. Różnica między górą a dołem tabeli jest duża i ma największe znaczenie dla kont z największym dostępem.

Dla administratorów używaj czynników odpornych na phishing. Passkeys albo klucze bezpieczeństwa FIDO2 dla każdego konta admina to standard, do którego warto dążyć. Konta adminów to te, których najbardziej chcą zestawy phishingowe typu adversary-in-the-middle, a te zestawy pokonują SMS, TOTP i zwykły push. Ubezpieczyciele cybernetyczni zaczęli pytać konkretnie, czy uprzywilejowane konta używają MFA odpornego na phishing, a nie po prostu jakiegokolwiek MFA, co odzwierciedla, gdzie koncentruje się ryzyko.

pojedynczy ruch o największej wartości: najpierw admini

Jeśli masz zrobić jedną rzecz przed wszystkim innym, wymuś MFA na każdym koncie administratora.

Konto admina bez drugiego czynnika to najwyższy poziom uprawnień w Twoim środowisku chroniony samym hasłem. Przejęte konto globalnego administratora może tworzyć konta, zmieniać polityki, wyłączać logowanie zdarzeń i sięgać po dane w całym tenancie. Blast radius to cała organizacja.

Konta adminów to też mała, dobrze znana populacja. Możesz wypisać każdego globalnego administratora, każdego super admina Workspace, każdą uprzywilejowaną rolę w Entra i każdą konsolę administracyjną dla głównych narzędzi SaaS, a potem potwierdzić, że każde z nich ma wymuszony czynnik odporny na phishing. To krótki projekt o dużym efekcie. Nie zależy od wdrożenia obejmującego całą firmę ani żadnej kampanii komunikacyjnej dla użytkowników.

Powiązana kwestia higieny: praca administracyjna powinna odbywać się na osobnych, imiennych kontach admina, nie na koncie codziennego użytku, którego dana osoba używa też do maila i przeglądania sieci. Rozdzielenie tych dwóch i nadanie najsilniejszego czynnika kontu admina to punkt wyjścia, do którego warto dążyć.

legacy authentication: obejście, przez które liczba kłamie

Wdrożenie pokrycia, które ignoruje legacy authentication, daje liczbę, która nie jest prawdziwa.

Protokoły legacy, takie jak IMAP, POP3, SMTP basic authentication, oraz starsze klienty poczty i kalendarza powstały, zanim istniało nowoczesne uwierzytelnianie. Uwierzytelniają się nazwą użytkownika i hasłem wysyłanym prosto na serwer. W tym przepływie nie ma kroku, w który można wstawić wyzwanie MFA. Kiedy klient łączy się w ten sposób, polityka MFA w ogóle nie jest sprawdzana.

To nie jest marginalna ścieżka. Microsoft podaje, że zdecydowana większość ataków password spray i credential stuffing na Microsoft 365 jedzie właśnie na legacy authentication, dokładnie dlatego, że omija każdą kontrolę nałożoną na logowanie interaktywne. Atakujący, który znajdzie jedną skrzynkę wciąż dostępną przez SMTP basic auth, ma drzwi do Twojego tenanta chronione tylko hasłem.

Blokowanie legacy authentication to część wdrożenia. W Microsoft 365 i Entra oznacza to politykę dostępu warunkowego, która blokuje przepływy legacy authentication, najlepiej wdrożoną najpierw w trybie report-only, żebyś zobaczył, które konta i urządzenia wciąż go używają, zanim wymusisz blokadę. W Google Workspace oznacza to wyłączenie dostępu dla mniej bezpiecznych aplikacji i przeniesienie pozostałych integracji na OAuth. Częstymi winowajcami są skrzynki współdzielone, skanery i drukarki wielofunkcyjne, starsze konektory CRM oraz narzędzia deweloperskie podpięte bezpośrednio pod Exchange. Każde z nich potrzebuje ścieżki nowoczesnego uwierzytelniania albo zarządzanej alternatywy, zanim blokada wejdzie w życie.

dostęp warunkowy i ustawienia domyślne bezpieczeństwa

MFA działa, kiedy jest wymuszone polityką. Zawodzi, kiedy zależy od dobrowolnej decyzji użytkowników. Ludzie odkładają monit, pomijają maila rejestracyjnego i omijają prośbę, która jest opcjonalna. Wymuszenie zamienia zarejestrowaną metodę w chronione logowanie.

W Microsoft 365 i Entra ustawienia domyślne bezpieczeństwa dają Ci podstawę: wymagane MFA dla administratorów i nacisk na MFA dla wszystkich użytkowników, z zablokowanym legacy authentication. To rozsądny minimalny poziom dla mniejszej organizacji. Dostęp warunkowy daje kontrolę wykraczającą poza ten poziom: reguły wymagające MFA w zależności od kontekstu, takiego jak użytkownik, aplikacja, stan urządzenia, lokalizacja sieciowa i ryzyko logowania wyliczane przez platformę. W Google Workspace odpowiednikiem jest wymuszenie weryfikacji dwuetapowej przez politykę jednostki organizacyjnej i stosowanie reguł dostępu uwzględniających kontekst.

Reguły uwzględniające kontekst pozwalają zaostrzać zabezpieczenia bez dodawania tarcia wszędzie. Możesz wymagać czynnika odpornego na phishing dla konsol administracyjnych, wymagać MFA dla każdego dostępu do wrażliwych aplikacji i podnosić poziom wyzwania, kiedy logowanie wygląda ryzykownie, jednocześnie zachowując prostotę rutynowego logowania na znanym, zarządzanym urządzeniu.

Jedna przestroga: polityki dostępu warunkowego z czasem gromadzą wyjątki, z których każdy dodano z powodu, który miał sens w danym momencie, a ich suma potrafi po cichu wyciąć szeroką dziurę w tym, co polityka faktycznie obejmuje. Przeglądaj wyjątki na harmonogramie, zamiast ustawić je i zapomnieć.

problem kont serwisowych i współdzielonych, bez odpuszczania MFA

To jest ta część wdrożenia, w której pokrycie zwykle się zatrzymuje. Konta serwisowe i współdzielone loginy nie pasują do modelu MFA interaktywnego, a łatwą odpowiedzią jest odpuszczenie wymogu i pójście dalej. Ten odpustek to luka, przez którą przechodzi atakujący. Nie odpuszczaj MFA. Zamiast tego napraw przyczynę.

Konta serwisowe i tożsamości maszynowe (NHI). Konto serwisowe uwierzytelnia się programowo, sekretem, certyfikatem albo hasłem. Nie ma sesji interaktywnej, w której można pokazać wyzwanie. Odpowiedzią jest inny zestaw kontroli dopasowany do typu konta, nie wyjątek. Nadaj kontu tożsamość zarządzaną tam, gdzie platforma to wspiera, żeby nie było stałych danych logowania do wykradzenia. Tam, gdzie tożsamość zarządzana nie jest dostępna, użyj uwierzytelniania certyfikatem zamiast długożyjącego hasła, ogranicz konto do minimalnych uprawnień, zmieniaj jego dane logowania na krótkim harmonogramie, ogranicz sieci, z których może się uwierzytelniać, i ustaw alert na użycie poza spodziewanym wzorcem.

Konta współdzielone. Współdzielony login to jeden komplet danych logowania używany przez kilka osób. W praktyce łamie MFA, bo drugi czynnik musi gdzieś być i kończy na urządzeniu jednej osoby albo we współdzielonej skrzynce. Łamie też rozliczalność, bo żadna pojedyncza osoba nie odpowiada za działania wykonane przez to konto. Zastąp współdzielony login kontami imiennymi, po jednym na osobę, każdym z własnym MFA. Tam, gdzie kilka osób naprawdę potrzebuje tej samej uprzywilejowanej funkcji, nadaj ją ich imiennym kontom przez rolę albo grupę, nie przez współdzielone dane logowania.

Zasada w obu przypadkach jest ta sama. Konta, które nie pasują do MFA interaktywnego, nie są powodem, żeby obniżać poprzeczkę. Są powodem, żeby zastosować właściwą kontrolę.

konto break-glass

Jest jeden celowy, ściśle kontrolowany wyjątek i istnieje po to, żeby Cię chronić, nie żeby komuś było wygodniej.

Konto break-glass to konto dostępu awaryjnego z najwyższymi uprawnieniami administracyjnymi, trzymane na boku, żeby awaria usługi MFA albo źle skonfigurowana polityka nie zablokowały Ci dostępu do własnego tenanta. Jeśli usługa MFA Twojego dostawcy tożsamości ma incydent, albo zmiana w dostępie warunkowym pójdzie źle i zacznie blokować wszystkich, konto break-glass to sposób, żeby wrócić i to naprawić. Każde dobrze prowadzone środowisko Microsoft 365 trzyma przynajmniej jedno, zwykle dwa, i ta sama logika dotyczy Google Workspace.

To konto jest z założenia wyjątkiem od Twoich polityk dostępu warunkowego, i dokładnie dlatego potrzebuje mocnej kontroli kompensującej. Nazwij je tak, żeby nie reklamowało się jako cel o wysokich uprawnieniach. Nadaj mu długie, unikalne hasło przechowywane offline, w zapieczętowanym, zabezpieczonym fizycznym miejscu, nie w współdzielonym menedżerze haseł. Tam, gdzie ma drugi czynnik, wybierz klucz sprzętowy przechowywany osobno od hasła. Nigdy nie używaj go do rutynowej administracji. Ustaw alert, który uruchamia się przy każdym logowaniu. Testuj je na harmonogramie, żeby wiedzieć, że działa, zanim nadejdzie dzień, w którym będziesz go potrzebować.

kolejność wdrożenia

1. Zmierz aktualne pokrycie. Zacznij od prawdziwej liczby, nie nagłówka na dashboardzie. Policz konta z zarejestrowanym i faktycznie wymuszonym MFA. Rozdziel ludzi od kont serwisowych. Zanotuj, które konta używają czynników odpornych na phishing, a które podatnych. Sprawdź, czy legacy authentication jest gdziekolwiek wciąż włączone.

2. Wymuś na adminach. Każde konto administratora na czynniku odpornym na phishing, wymuszone polityką. Zrób to przed szerokim wdrożeniem, bo jest od niego niezależne i najpierw usuwa największe pojedyncze ryzyko.

3. Zablokuj legacy authentication. Wdróż blokadę w trybie report-only, żeby znaleźć, co wciąż używa protokołów legacy, przenieś albo zastąp te połączenia, a potem wymuś blokadę. Dopóki tego nie zrobisz, reszta liczby pokrycia jest niewiarygodna.

4. Wprowadzaj wymuszenie dla użytkowników etapami. Przenoś ogół użytkowników na wymuszone MFA falami, nie wszystkich naraz. Komunikuj przed każdą falą: co się zmienia, dlaczego, co osoba musi zrobić i gdzie szukać pomocy. Uruchom krótkie okno wsparcia z obsadą wokół każdej fali, żeby zablokowany użytkownik odzyskał dostęp w kilka minut.

5. Obsłuż wyjątki właściwie. Konta serwisowe dostają swój zestaw kontroli kompensujących. Współdzielone loginy zostają zastąpione kontami imiennymi. Prawdziwy przypadek awaryjny dostaje udokumentowane konto break-glass. Wyjątek, który jest zaprojektowany i monitorowany, jest w porządku. Wyjątek, który jest cichym odpustkiem, jest luką.

6. Trzymaj się polityki. Nowe konta dostają MFA od pierwszego dnia przez politykę domyślną. Przeglądaj wyjątki w dostępie warunkowym na harmonogramie i usuwaj te, które nie mają już powodu istnieć. Mierz pokrycie ponownie okresowo, bo środowiska dryfują.

częste powody, dla których pokrycie się zatrzymuje

Stos odpustków. Każde konto, które trudno było zarejestrować, dostało wyjątek, a wyjątki nigdy nie zostały ponownie sprawdzone. Traktuj każdy wyjątek jako tymczasowy, dopóki nie stoi za nim zaprojektowana kontrola.

Legacy auth wciąż włączone. Logowania interaktywne są pokryte i dashboard wygląda dobrze, podczas gdy protokół legacy wciąż akceptuje hasła na skrzynce albo integracji.

Konta serwisowe traktowane jako poza zakresem. Ponieważ MFA ich nie dotyczy, zostają całkowicie pominięte w programie, zamiast dostać zestaw kontroli, który faktycznie ich dotyczy. W ten sposób połowa populacji kont może zostać niezabezpieczona.

Czynniki podatne na phishing liczone jako gotowe. Pokrycie pokazuje 100%, duża część to SMS, a konta adminów, w które celuje zestaw phishingowy, nie są lepiej chronione niż zwykły użytkownik. Liczba jest osiągnięta, odporność nie.