Tenant może zablokować się sam, bez udziału atakującego. Jeśli każde przypisanie Global Administrator i Privileged Role Administrator jest typu eligible, aktywacja wymaga zatwierdzenia i nie wskazano żadnych osób zatwierdzających, nikt niczego nie zatwierdzi. Domyślnymi osobami zatwierdzającymi są aktywni administratorzy, a tych nie ma. Wyjściem są dwa konta break-glass tylko w chmurze, przygotowane i przećwiczone z wyprzedzeniem.
Kiedy będą potrzebne
Wytyczne Microsoft dotyczące dostępu awaryjnego wymieniają konkretne przypadki. Federacja przestaje działać, bo awarii uległ host dostawcy tożsamości. Każdy administrator zarejestrował dla MFA wyłącznie połączenia telefoniczne i SMS-y, a sieć komórkowa nie działa. Ostatnia osoba z dostępem Global Administrator odchodzi z firmy, a jej konto zostaje wyłączone lub usunięte w środowisku lokalnym, czego Entra ID nie blokuje.
Zbuduj konta
Utwórz co najmniej dwa konta. Niech będą tylko w chmurze, w domenie *.onmicrosoft.com, bez federacji i bez synchronizacji z środowiska lokalnego. Każdemu przypisz rolę Global Administrator.
W Privileged Identity Management (PIM) ustaw to przypisanie jako active permanent, a nie eligible. Codzienni administratorzy powinni korzystać z dostępu just-in-time, ale te konta nie mogą zależeć od kroku aktywacji, bo to właśnie on może być niedostępny. PIM wymaga licencji Microsoft Entra ID P2 lub Entra ID Governance.
Źródła nie obejmują tenantów bez PIM, więc ta część to nasze własne wnioskowanie. Ustawienie active kontra eligible istnieje w PIM i tam nie ma zastosowania. Konta nadal potrzebują bezpośredniego, stałego przypisania Global Administrator, z tego samego powodu: nic nie powinno wymagać aktywacji.
Do uwierzytelniania wybierz metodę bezhasłową, która spełnia wymóg MFA:
- Passkey (FIDO2), który zaleca Microsoft.
- Uwierzytelnianie oparte na certyfikatach, jeśli masz już własną PKI.
Użyj innej metody niż ta, której używają codzienni administratorzy. Jeśli oni korzystają z aplikacji Microsoft Authenticator, daj kontom awaryjnym klucz bezpieczeństwa FIDO2. Nie wiąż współdzielonych kont z konkretną osobą ani z urządzeniem dostarczonym przez pracownika, takim jak telefon. Microsoft dopuszcza też indywidualne konta awaryjne dla każdego administratora, co zapewnia rozliczalność i pozwala korzystać z nich z odległych lokalizacji. Wybierz jeden model świadomie.
Przechowuj klucze w ognioodpornych sejfach, w bezpiecznych, oddzielnych lokalizacjach, dostępnych dla osób upoważnionych do ich użycia. Za każdym razem, gdy ktoś loguje się tymi kontami, korzystaj z wyznaczonej, bezpiecznej stacji roboczej, na przykład Privileged Access Workstation.
Wyłącz je z Conditional Access
Wymuszana polityka, która wymaga MFA, zgodnego urządzenia lub innej kontroli, może uniemożliwić użycie konta w trakcie awarii. Konto chroni poświadczenie odporne na phishing, dlatego wyłącz je z każdej polityki, która blokuje lub ogranicza logowanie. Conditional Access wymaga Entra ID P1.
Utwórz dedykowaną grupę zabezpieczeń, na przykład EmergencyAccess, dodaj do niej oba konta i wyklucz tę grupę z takich polityk. Polityki w trybie report-only nie blokują dostępu i nie wymagają wykluczenia.
Sama grupa nie wystarczy, bo nowe polityki piszą ludzie, którzy mogą nie pamiętać o istnieniu tych kont. Otwórz każdą włączoną politykę i sprawdź w sekcji Exclude, czy jest tam ta grupa. Polityki report-only sprawdź ponownie, zanim ktokolwiek je włączy. Dodaj pytanie „czy EmergencyAccess jest wykluczona?" do listy kontrolnej przeglądu każdej nowej polityki i przetestuj logowanie po każdej istotnej zmianie.
Ustaw alert na każde logowanie
Te konta powinny logować się wyłącznie podczas ćwiczeń i prawdziwych awarii, więc każde logowanie zasługuje na alert. Przykład Microsoft wykorzystuje Azure Monitor i wymaga, by dzienniki logowania Entra były najpierw wysyłane do przestrzeni roboczej Log Analytics.
- W Entra admin center, jako co najmniej User Administrator, przejdź do Entra ID > Users, otwórz każde konto awaryjne i skopiuj jego Object ID.
- W portalu Azure, jako co najmniej Monitoring Contributor, otwórz Monitor > Alerts i wybierz + Create > Alert rule.
- Na karcie Scope wybierz swoją przestrzeń roboczą Log Analytics.
- Na karcie Condition wybierz Custom log search jako nazwę sygnału i Aggregated logs jako typ zapytania.
- Wpisz zapytanie z obydwoma Object ID:
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription- W sekcji Measurement wybierz miarę, typ agregacji i ziarnistość agregacji. W sekcji Split by dimensions wybierz kolumnę Resource ID.
- W sekcji Alert logic ustaw typ progu na Static, operator na Greater than, a wartość progową na 0. Częstotliwość oceny ustaw zgodnie z tym, jak szybko chcesz dowiedzieć się o zdarzeniu.
- Skieruj alert na e-mail i SMS do kilku administratorów, nie tylko do jednego.
Microsoft pokazuje też zapytanie po UserPrincipalName. My z przyzwyczajenia używamy Object ID, bo zapytanie oparte na nazwie zależy od tego, że ta nazwa się nie zmieni. Dla każdego dodatkowego konta dopisz kolejną klauzulę or UserId == "ObjectGuid".
Jeśli nikt w Twoim zespole nie obserwuje alertów poza godzinami pracy, tę część może przejąć usługa zarządzanego monitoringu.
Testuj konta i przeglądaj każde użycie
Sprawdzaj konta co najmniej raz na 90 dni. Ćwiczenie powinno obejmować listę osób upoważnionych, prawdziwe logowanie kluczem bezpieczeństwa oraz wykonanie zadania administracyjnego. Powinno potwierdzić, że konta nadal logują się przy obecnej konfiguracji Conditional Access oraz że każdy klucz lub certyfikat jest na miejscu, nie wygasł i nie został usunięty przez automatyczne czyszczenie.
Każde ćwiczenie powinno uruchomić Twój alert. Powtórz test po każdej zmianie w przestrzeni roboczej lub w ustawieniach diagnostycznych, które ją zasilają. Prowadź krótki dziennik:
| Data | Przeprowadził | Konto i klucz | Klucz lub certyfikat ważny | Alert otrzymany po | Wykryte usterki |
|---|---|---|---|---|---|
| Konto 1, klucz A | |||||
| Konto 2, klucz B |
Po każdym rzeczywistym użyciu przeprowadź analizę poincydentalną. Ustal, czy użycie było autoryzowane i czy podjęte działania były właściwe. Organizacje regulowane mogą pokazać ten zapis wraz z logami i dziennikiem ćwiczeń jako dowód, że dostęp awaryjny jest objęty nadzorem. Jeśli chcesz niezależnej weryfikacji, nasz zespół doradczy może przejrzeć konfigurację.
Od czego zacząć
- Wypisz swoich Global Administratorów w Entra admin center i porównaj ich liczbę z wytyczną Microsoft, by było ich mniej niż pięciu. Sprawdź, czy któreś konto jest już przeznaczone do użycia awaryjnego.
- Utwórz dwa konta
.onmicrosoft.comtylko w chmurze, z trwałym aktywnym przypisaniem Global Administrator, i zarejestruj dla każdego inny klucz FIDO2. - Utwórz grupę
EmergencyAccessi wyklucz ją z każdej polityki Conditional Access, która blokuje lub ogranicza logowanie. - Wyślij dzienniki logowania do Log Analytics i zbuduj regułę alertu z progiem większym niż 0 dla obu Object ID.
- Umieść klucze w oddzielnych, ognioodpornych miejscach, wskaż osoby upoważnione i sprawdź, czy żadne poświadczenie nie wygasa ani nie podlega automatycznemu czyszczeniu.
- Zaloguj się każdym kontem, potwierdź, że alert się uruchamia, wypełnij pierwszy wiersz dziennika ćwiczeń i wpisz do kalendarza kolejne ćwiczenie w ciągu 90 dni.
