Usługa MFA nie działa: zdecyduj o dostępie VPN wcześniej

Dostęp VPN zatrzymuje się, a alert informuje, że usługa drugiego czynnika jest nieosiągalna. To, czy ktoś jeszcze może się połączyć, jest pytaniem o politykę, na które należało odpowiedzieć przed awarią, a nie w jej trakcie. Niedostępny weryfikator nie jest dowodem, że czynnik przeszedł, a odrzucone wyzwanie nie jest tym samym zdarzeniem co nieosiągalne. Poniższa instrukcja zamienia tę różnicę w pisemną regułę, którą można przetestować.

Krok 1: nazwij trzy wyniki osobno

Zapisz trzy stany i odmów ich łączenia: uwierzytelnianie pierwotne nie powiodło się, wyzwanie drugiego czynnika zostało odrzucone albo wygasło, a usługa MFA nigdy nie odpowiedziała. Każdy ma innego właściciela, inną linię logu i inną prawidłową reakcję. Jeden ogólny komunikat o przekroczeniu czasu ukrywa, w którym stanie jesteś, i to właśnie ta niejednoznaczność zamienia awarię w spór. Nazwij stany w instrukcji, zanim będą potrzebne.

Odmowa oznacza, że weryfikator odpowiedział i powiedział nie, co jest wynikiem polityki, a nie problemem dostępności. Wygasła próba oznacza, że wyzwanie istniało i nikt go na czas nie ukończył. Nieosiągalna usługa oznacza, że pytanie w ogóle nie zostało rozstrzygnięte. Tylko trzeci przypadek jest awarią.

Krok 2: odczytaj tryb awaryjny, którego proxy naprawdę używa

Znajdź ustawienie sterujące zachowaniem, gdy nie można skontaktować się z usługą, i odczytaj je z działającej konfiguracji, a nie z szablonu. W proxy RADIUS firmy Duo udokumentowane wartości failmode to safe i secure, gdzie safe zezwala na próbę tylko wtedy, gdy uwierzytelnianie pierwotne się powiedzie, a secure odrzuca próbę w tym warunku.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Nazwa safe opisuje wybór dostępności, a nie gwarancję, że każda dopuszczona sesja miała świeży drugi czynnik. To zdanie należy do rejestru ryzyka, bo jest dokładnie tą wymianą, której dokonuje ustawienie. Nie uogólniaj wartości na innego dostawcę, inną integrację ani inny tryb proxy; przeczytaj dokumentację tego produktu dla jego własnego odpowiednika. Konfiguracja skopiowana z przykładu dostawcy bez tego zrozumienia jest niespodzianką czekającą na następną awarię.

Zatrzymaj się, jeśli nikt nie potrafi powiedzieć, który tryb jest aktywny. Reszta instrukcji zależy od tej odpowiedzi.

Krok 3: dopasuj ponowienia do przepływu

Dopasuj limit czasu i zachowanie przy ponowieniach bramy do przepływu uwierzytelniania, którym steruje. Nieskoordynowane ponowienia tworzą wiele monitów, mylą dopasowanie prób i sprawiają, że log nie potrafi powiedzieć, który wynik należy do którego logowania. Bardzo długi limit czasu nie jest projektem dostępności; to dłuższe oczekiwanie na tę samą odpowiedź.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Własny limit czasu żądania po stronie proxy to osobna granica: żądanie uwierzytelnienia, które zostanie wysłane i nigdy nie ukończone, jest odrzucane, a ta odmowa nie jest awarią, z której się wycofuje. Traktuj odmowę, niedokończone wyzwanie i nieosiągalną usługę jako trzy różne wejścia do swojej tabeli decyzyjnej. Następnie uczyń tabelę jawną: który stan wpuszcza, który stan wstrzymuje i który stan eskaluje do człowieka.

Jeśli oba komponenty ponawiają próby, najpierw napraw własność ponowień. Zduplikowane monity są objawem dwóch właścicieli, a nie wolnej usługi.

Krok 4: zarządzaj dostępem awaryjnym osobno

Jeśli dostęp awaryjny jest wymagany, daj mu własny zakres, tożsamość, autoryzację i ścieżkę audytu. Ciche wyłączanie MFA dla wszystkich użytkowników nie jest procedurą awaryjną; to trwałe osłabienie z przypisanym incydentem. Właściciel bezpieczeństwa zatwierdza z góry regułę dostępu, widoczność i ścieżkę eskalacji.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Przetestuj całą macierz w środowisku nieprodukcyjnym: awarię pierwotną, celową odmowę, wygaśnięcie wyzwania i niedostępność usługi. Dla każdego przypadku zapisz wynik dostępu i powód zapisany w logu. Nie wywołuj awarii produkcyjnej, aby odkryć skonfigurowane zachowanie, i nie testuj ścieżki awaryjnej po raz pierwszy podczas incydentu, dla którego ją napisano. Procedura odzyskiwania, która nigdy nie została uruchomiona, jest dokumentem, a nie kontrolą.

Instrukcja kończy się, gdy trzy stany są nazwane, tryb awaryjny odczytany z działającego systemu, ponowienia mają jednego właściciela, a dostęp awaryjny ma własne zatwierdzenie i przegląd. Przewidywalne egzekwowanie oraz znana ścieżka odzyskiwania to wynik wart udokumentowania.