Konta awaryjne to nie tylko konto administratora z MFA

Każdy MSP w końcu słyszy pytanie, dlaczego klient potrzebuje dedykowanych kont dostępu awaryjnego, skoro od każdego administratora wymaga się już uwierzytelniania wieloskładnikowego. Odpowiedź brzmi: konta dostępu awaryjnego rozwiązują inny problem — pozostają użyteczne, gdy sam dostawca tożsamości lub system MFA jest niedostępny, a nie dodają kolejnej warstwy do systemu, który już działa.

Co zaleca Microsoft

Wytyczne Microsoft dotyczące Entra ID wymagają co najmniej dwóch kont dostępu awaryjnego działających wyłącznie w chmurze, niesynchronizowanych z katalogiem lokalnym ani sfederowanych za pośrednictwem zewnętrznego dostawcy tożsamości — ponieważ konto zależne od tej samej infrastruktury, którą ma ratować, nie jest tak naprawdę kontem awaryjnym. Microsoft zaleca uwierzytelnianie odporne na phishing, takie jak klucze FIDO2 lub uwierzytelnianie oparte na certyfikatach, celowo niezależne od metod używanych przez zwykłych administratorów, oraz trwałe — a nie tymczasowe lub ograniczone czasowo — przypisanie roli administratora globalnego w Privileged Identity Management, ponieważ przepływ aktywacji może właśnie nie zadziałać podczas awarii. Konta te nadal powinny być objęte zasadami Conditional Access wymagającymi uwierzytelniania MFA odpornego na phishing; zalecane wykluczenie dotyczy konkretnie blokowania opartego na geolokalizacji, a nie kontroli dostępu w ogóle, biorąc pod uwagę wcześniejsze przypadki błędnego klasyfikowania geograficznego legalnych logowań przez wiele godzin.

Co dodają NIST i OWASP

Kontrola AC-2(2) z NIST SP 800-53 traktuje konta awaryjne jako coś, co aktywuje się na czas zdefiniowanego kryzysu, a następnie automatycznie wyłącza lub usuwa, zamiast istnieć bezterminowo. Wytyczne OWASP dotyczące MFA wskazują, że procesy odzyskiwania i obejścia same w sobie są celem ataków: każdy mechanizm przywracający dostęp w sytuacji awaryjnej nie może po cichu stać się sposobem na pominięcie MFA w normalnych warunkach.

Jak wygląda „udowodnij, że działa”

• Monitoruj logowania do tych kont, z alertem przy każdej próbie — udanej lub nieudanej.
• Przeprowadzaj testy dostępu według stałego harmonogramu, zwykle co 90 dni, zamiast zakładać, że konfiguracja nadal działa.
• Po każdym rzeczywistym użyciu lub teście napisz krótką analizę post-mortem i dostosuj konfigurację na podstawie ustaleń.
• Udokumentuj, kto i w jaki sposób może pobrać poświadczenia, ponieważ nadmiarowość bez procesu pobierania nie jest tak naprawdę nadmiarowością.

Projekt dostępu awaryjnego, który nigdy nie został przetestowany w warunkach symulowanej awarii, nie jest zabezpieczeniem — jest założeniem.

Źródła: Microsoft Learn — konta dostępu awaryjnego, NIST SP 800-53 Rev. 5.