Migracja backendu uwierzytelniania VPN bez ponownego użycia starych skrótów
Przeniesienie tożsamości VPN to cutover, a nie kopia: zmapuj łańcuch uwierzytelniania, przenieś grupę pilotażową, przetestuj zmiany poświadczeń i zaplanuj odtwarzanie, którego reset nie cofnie.
Nazwy użytkowników pojawiają się w nowym katalogu, migrację uznaje się za zakończoną, a logowania nadal zawodzą. Bramka wciąż potrzebuje obsługiwanej ścieżki uwierzytelniania i poprawnego wyniku autoryzacji, a żadne z nich nie wynika z katalogu, który zawiera teraz konta. Przeniesienie backendu to cutover z cyklem życia, a nie kopiowanie. Objaw poniżej to ten, który zwykle ujawnia różnicę.
Objaw: konta istnieją, sesje nie
Nowy katalog zawiera każdą nazwę użytkownika, testowy bind się udaje, a klient VPN nadal zwraca błąd uwierzytelniania. Taka kombinacja oznacza, że tożsamość istnieje, ale ścieżka weryfikacji używana przez bramkę do niej nie dociera albo dociera metodą, której nie może spełnić. Oba przypadki to konfiguracja i to różne problemy.
Pierwszy to okablowanie: bramka wskazuje backend, który nie odpowiada, używa wspólnego sekretu, którego druga strona nie oczekuje, albo prosi o atrybut, którego nowa usługa nie zwraca. Drugi jest kryptograficzny: metoda wymaga oryginalnego sekretu, a nowy magazyn przechowuje tylko jego skrót. Tekst błędu wygląda w obu przypadkach podobnie, dlatego oba są traktowane jako jeden problem.
Rozdzielenie ich przed dotknięciem kont oszczędza tydzień. Jeden to kwestia routingu i zaufania, drugi to decyzja o resecie poświadczeń, a mieszanie ich daje zmiany, których nikt nie potrafi przypisać.
Zmapuj łańcuch, zanim ktokolwiek zostanie przeniesiony
Dla każdego profilu klienta zapisz sześć rzeczy: zewnętrzną metodę uwierzytelniania, ewentualną metodę wewnętrzną, tożsamość serwera, której oczekuje klient, interfejs między bramką a backendem, atrybut mapowany przez bramkę na przynależność do grupy oraz wynikową politykę zasobów. Czytanie ich w kolejności pokazuje, którego ogniwa nikt nie posiada. Każda pozycja ma właściciela, a cutover zawodzi na tej, której nikt nie sprawdził.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
Zwykłe logowanie do katalogu nie przechodzi prawie żadnego z tych ogniw. Dowodzi, że konto istnieje i hasło działa, czyli właśnie tej części, która nigdy nie budziła wątpliwości.
Skróty nie podróżują między metodami
Zgodność poświadczeń trzeba sprawdzić raz, zanim przeniesie się jakąkolwiek grupę. FreeRADIUS jasno opisuje podział: kontrola CHAP wykonywana przez sam serwer wymaga rzeczywistego hasła, a MS-CHAP akceptuje to hasło lub odpowiedni materiał NT. Skrót wytworzony w innym celu nie pasuje do żadnego z przypadków, choćby był bardzo silny.
Różnica dotyczy tego, kto oblicza dowód. Metoda, która weryfikuje przez powiązanie z katalogiem, pozwala katalogowi sprawdzić to, co może sprawdzić. Metoda, która weryfikuje przez ponowne obliczenie odpowiedzi na wyzwanie, potrzebuje samego sekretu, bo serwer musi wykonać to samo obliczenie.
Tam, gdzie brakuje materiału, uczciwe opcje to obsługiwany reset, ponowna rejestracja, zewnętrzna usługa weryfikacji albo zmiana metody. Tymczasowy eksport odtwarzalnych haseł nie znajduje się na tej liście. Tworzy magazyn poświadczeń w czystym tekście w najbardziej chaotycznym tygodniu projektu i zwykle przeżywa migrację.
Grupa pilotażowa, potem zmiany cyklu życia
Przenieś małą grupę zatwierdzonych tożsamości z prawdziwym klientem i przetestuj cztery rzeczy: świeże logowanie, celowo błędne poświadczenie, zasoby, do których sesja może dotrzeć, oraz zasoby, do których nie może. Sprawdź też tożsamość serwera zaakceptowaną przez klienta, bo niezgodność nazwy certyfikatu jest niewidoczna, dopóki ktoś nie przeczyta logu klienta.
Potem przećwicz zmiany, od których faktycznie zależy wdrożenie. Zmień hasło, odnow lub ponownie zarejestruj certyfikat i odbierz dostęp jednemu kontu pilotażowemu. Po każdej z nich potwierdź, który weryfikator obsłużył próbę, bo sesja utworzona przed cutoverem może dalej działać i nic nie dowodzi o następnym logowaniu.
Oddziel dostarczanie profilu od przełączenia tożsamości. Każda grupa potrzebuje zamierzonego profilu, swojego stanu poświadczeń lub rejestracji, usługi uwierzytelniania, której ma używać, oraz kontaktu wsparcia, a żaden z tych zapisów nie może zawierać sekretu.
Jeśli stara i nowa ścieżka współistnieją, ogranicz je datą końcową. Automatyczny fallback może wpuścić konto starym poświadczeniem po tym, jak nowy właściciel odebrał dostęp, a to regresja bezpieczeństwa przebrana za dostępność.
Rollback nie przywróci poświadczenia
Odwrócenie cutoveru pozostawia katalog dokładnie w stanie, w jakim jest teraz. Zresetowane hasło pozostaje zresetowane, unieważniony certyfikat pozostaje unieważniony, a zmieniony format poświadczeń pozostaje zmieniony. To zdarzenia w katalogu, a bramka nigdy nie była ich źródłem. Odtwarzanie trzeba zdefiniować dla każdego zdarzenia i nic z tego nie może zależeć od rekonstrukcji sekretu z niekompatybilnego skrótu.
Utrzymuj ścieżkę administracyjną, która nie korzysta z migrowanego połączenia. Gdy nowe uwierzytelnianie zawodzi, wstrzymaj grupę i użyj jej udokumentowanej ścieżki odtwarzania, zamiast osłabiać uwierzytelnianie dla wszystkich, żeby dotrzymać terminu.
Po objęciu grup wycofaj stare poświadczenia backendu, profile i relacje zaufania przez ich właścicieli. Potwierdź, że stara ścieżka nie wpuszcza już użytkowników, i zachowaj pozbawione sekretów mapowanie tożsamości na politykę, którego wsparcie nadal potrzebuje. Migracja jest skończona, gdy nowy cykl życia działa i nikt nie wchodzi już starą ścieżką, a nie gdy lista kont wygląda na kompletną.