Migracja haseł nie jest kopiowaniem bazy danych. Gdy użytkownicy są przenoszeni między identity providers, źródło często nie może udostępnić hasła, które system docelowy będzie mógł ponownie wykorzystać. Nawet jeśli eksport zawiera hashe haseł, hash utworzony dla jednej platformy nie jest automatycznie prawidłowy na innej.
Użytkownicy mogą czasem zachować dotychczasowe hasło bez wymuszonego resetu. Bezpieczna metoda zależy od tego, co źródło może wyeksportować, czy potrafi walidować hasła online, jak długo może pozostać dostępne oraz czy migracja może powiązać każde konto ze stabilnym identyfikatorem źródłowym.
Ten artykuł przedstawia model decyzyjny pozwalający wybrać między zgodnym importem, stopniową walidacją haseł, dalszą walidacją zewnętrzną i kontrolowanym resetem hasła. Koncentruje się na ścieżce haseł. Protokoły aplikacji, claims, rejestracja multi-factor authentication (MFA) i pełny plan cut-over nadal muszą być prowadzone jako powiązane strumienie migracji.
Zacznij od źródła, a nie od oczekiwanego doświadczenia użytkownika
„Bez resetu hasła” jest pożądanym wynikiem, ale nie jest jeszcze metodą migracji. Przed wyborem podejścia ustal, co źródło faktycznie obsługuje:
- Czy może wyeksportować hasła w postaci jawnej lub reprezentację hasła wyraźnie obsługiwaną przez system docelowy?
- Czy może zweryfikować bieżące hasło użytkownika przez zabezpieczone API walidacyjne?
- Czy to API może pozostać dostępne, monitorowane i wspierane przez cały okres stopniowej migracji i okno rollback?
- Czy istnieje stabilny, niezmienny identyfikator źródłowy użytkownika, który powiąże to samo konto mimo zmian identyfikatorów logowania?
- Czy zmiany i resety haseł mogą pozostać spójne, gdy zaangażowane są dwa systemy?
- Czy polityka bezpieczeństwa, umowy i ocena ryzyka pozwalają importować lub przechowywać materiał haseł?
Nie używaj adresu e-mail, numeru telefonu ani nazwy użytkownika jako jedynego klucza migracji. Te identyfikatory mogą się zmienić. Błędne powiązanie konta jest poważniejsze niż reset, ponieważ może przypisać dane uwierzytelniające i dostęp do niewłaściwej tożsamości.
Wybierz jedną z czterech ścieżek haseł
Różne grupy użytkowników mogą wymagać różnych ścieżek. Na przykład aktywni pracownicy mogą migrować stopniowo przez walidację online, a nieaktywne konta zewnętrzne otrzymają reset po powrocie użytkownika.
| Możliwość i ograniczenie źródła | Uzasadniona ścieżka | Główna korzyść | Główny koszt lub ryzyko |
|---|---|---|---|
| Hasła lub reprezentacja hasła zgodna z systemem docelowym są dostępne i mogą być bezpiecznie obsłużone | Kontrolowany import wsadowy | Użytkownicy mogą natychmiast uwierzytelniać się w systemie docelowym | Eksport, transport i przetwarzanie materiału haseł poszerzają granicę bezpieczeństwa |
| Źródło może walidować istniejące hasła online i pozostać autorytatywne w okresie przejściowym | Stopniowa migracja z Directory Connector | Aktywni użytkownicy przechodzą po udanym logowaniu bez zbiorczego resetu | Źródło i connector pozostają w produkcyjnej ścieżce authentication aż do cut-over |
| Użytkownicy są już utworzeni w FoxIDs, a tylko walidacja haseł, sprawdzanie polityki lub powiadamianie o zmianach pozostają zewnętrzne | External Password API | Zachowuje węższą integrację z magazynem haseł lub polityką | Nie zapewnia takiego samego procesu tworzenia użytkowników i synchronizacji profili jak Directory Connector |
| Nie ma bezpiecznego zgodnego importu ani niezawodnej walidacji online | Zweryfikowany reset hasła | Ustanawia nowe hasło docelowe z wyraźną granicą trust | Komunikacja z użytkownikami, kanały odzyskiwania i zdolność supportu stają się kluczowe |
Odpowiedź nie brzmi więc zawsze „zachowaj” ani zawsze „zresetuj”. Dla każdej grupy wybierz najmniej uciążliwą ścieżkę, którą nadal można uzasadnić technicznie i operacyjnie.
Stopniowa migracja z Directory Connector
Directory Connector jest głównym wzorcem FoxIDs, gdy istniejący katalog lub niestandardowe repository musi pozostać autorytatywne w okresie przejściowym.
Gdy użytkownik loguje się hasłem, FoxIDs wywołuje API connectora. Po udanej walidacji FoxIDs tworzy lub aktualizuje użytkownika wewnętrznego na podstawie zwróconych identyfikatorów, właściwości i claims. Odpowiedź zawiera stabilny directoryUserId, który wiąże użytkownika w FoxIDs z kontem źródłowym, nawet jeśli później zmieni się jego adres e-mail, numer telefonu lub nazwa użytkownika.
Tworzy to praktyczny proces just-in-time:
- Użytkownik loguje się do aplikacji przez FoxIDs przy użyciu dotychczasowego identyfikatora i hasła.
- FoxIDs prosi katalog źródłowy o walidację hasła.
- Connector zwraca stabilny identyfikator źródłowy i zatwierdzone dane użytkownika.
- FoxIDs tworzy lub aktualizuje użytkownika wewnętrznego i kończy authentication.
- Użytkownik może nadal korzystać z dotychczasowego hasła, dopóki źródło pozostaje autorytatywne.
Domyślnie FoxIDs zapisuje także lokalną kopię hasła po udanej walidacji connectora lub operacji cyklu życia hasła wykonanej przez connector. Kopia umożliwia późniejsze, planowane przejście na walidację haseł w FoxIDs bez resetowania haseł wszystkich użytkowników, którzy przeszli stopniowy proces.
Granica ma znaczenie: gdy Directory Connector jest włączony, zewnętrzny katalog pozostaje autorytatywny. FoxIDs nie używa zapisanego lokalnego hasha jako automatycznego fallbacku, jeśli connector jest niedostępny. Awaria connectora jest zatem błędem ścieżki authentication, a nie poleceniem ominięcia źródła.
Widoczny poniżej przełącznik polityki haseł jest trzecią, niezależną decyzją. Określa, czy FoxIDs sprawdza proponowane hasło względem polityki środowiska FoxIDs przed wywołaniem connectora. Zewnętrzny katalog nadal odpowiada za hasło i może je odrzucić zgodnie z własną polityką. Jeśli używane są obie kontrole, ich wymagania i komunikaty dla użytkownika muszą być spójne.
Zdefiniuj kryteria zakończenia przed włączeniem connectora
Stopniowa migracja wymaga warunku zakończenia. Przed wdrożeniem ustal:
- Które grupy użytkowników muszą pomyślnie się zalogować przed cut-over?
- Jak będą obsługiwane konta nieaktywne lub konta użytkowników, którzy nigdy nie wrócą?
- Jak długo źródło i connector muszą pozostać dostępne na potrzeby rollback?
- Jakie czasy odpowiedzi i wskaźniki błędów connectora zatrzymają lub cofną wdrożenie?
- Jak będą badane konflikty identyfikatorów, brakujące claims oraz wyłączone lub usunięte konta źródłowe?
- Kiedy connector można wyłączyć, a FoxIDs może stać się systemem autorytatywnym dla haseł?
Zapisywanie lokalnej kopii jest opcjonalne. Wyłącz je, gdy polityka wymaga, aby źródło pozostało jedynym magazynem haseł, ale pamiętaj, że usuwa to drogę do późniejszego przejścia bez resetu.
Kiedy External Password API jest węższym dopasowaniem
FoxIDs może skonfigurować External Password API jako kontrolę hasła dla użytkowników wewnętrznych. API może walidować bieżące hasło, sprawdzać nowe hasło względem zewnętrznej polityki, powiadamiać inny system o zmianach haseł lub łączyć te obowiązki.
Użyj tej opcji, gdy użytkownicy już istnieją w FoxIDs, a pozostała potrzeba dotyczy konkretnie magazynu haseł lub polityki haseł. Nie traktuj jej jako zamiennika Directory Connector, jeśli migracja wymaga również tworzenia użytkowników just-in-time, stabilnego powiązania z zewnętrznym katalogiem, aktualizacji profilu lub obsługi cyklu życia kont zewnętrznych.
To rozróżnienie utrzymuje wyraźną granicę integracji: Directory Connector reprezentuje autorytatywny katalog zewnętrzny. External Password API reprezentuje zewnętrzną zależność do walidacji haseł, polityki lub powiadomień dla użytkowników wewnętrznych.
Kiedy import wsadowy jest uzasadniony
Import wsadowy może usunąć zależność runtime od źródła, ale tylko wtedy, gdy dane wejściowe pasują do systemu docelowego i mogą być chronione przez cały transfer.
FoxIDs obsługuje przesyłanie użytkowników wewnętrznych ze znanymi hasłami, z wcześniej obliczonymi hashami haseł zgodnymi z FoxIDs lub bez haseł. Hash z dowolnej platformy źródłowej nie może zostać po prostu nazwany hashem FoxIDs. Przed uznaniem eksportowanego hasha za zdatny do ponownego użycia potwierdź dokładny algorytm, salt i format docelowy.
Eksport haseł w postaci jawnej traktuj jako decyzję bezpieczeństwa, a nie udogodnienie. Ogranicz dostęp, użyj kontrolowanej ścieżki transferu, nie pozwól, aby hasła trafiły do logów lub zwykłych plików projektu, potwierdź usunięcie materiału tymczasowego i udokumentuj osobę zatwierdzającą operację. Jeśli takiej obsługi nie można uzasadnić, wybierz walidację online lub reset.
Kiedy reset hasła jest bezpieczniejszy
Reset nie musi oznaczać nieudanej migracji. Jest uczciwą ścieżką, gdy zachowanie istniejącego hasła osłabiłoby system docelowy lub opierało się na założeniach, których zespół nie potrafi zweryfikować.
Wybierz kontrolowany reset, gdy:
- źródło nie może wyeksportować zgodnej reprezentacji ani zweryfikować bieżącego hasła online;
- przeniesienie materiału haseł spowodowałoby niedopuszczalne ujawnienie lub problem umowny;
- hasło w źródle jest znane jako skompromitowane lub istnieje takie podejrzenie;
- kont nie można z wystarczającą pewnością powiązać ze stabilnymi tożsamościami źródłowymi;
- źródło nie może pozostać niezawodne przez wymagany okres stopniowej migracji i rollback; lub
- zachowanie starego hasła wymagałoby słabszych kontroli w systemie docelowym.
Użytkowników FoxIDs można przesłać bez haseł i poprosić o ustawienie hasła przy użyciu kodu weryfikacyjnego wysłanego e-mailem lub SMS-em. Jest to bezpieczne tylko wtedy, gdy identyfikator odzyskiwania konta należy do właściwego użytkownika, a kanał dostawy spełnia wymagania organizacji dotyczące ryzyka. Przed szerokim wdrożeniem przetestuj wygasłe kody, niedostępne skrzynki odbiorcze lub numery telefonów, zduplikowane identyfikatory, zablokowane konta i eskalację do supportu.
Poinformuj o przyczynie i terminie, zanim użytkownicy zetkną się z resetem. Oddziel decyzję bezpieczeństwa od planu wsparcia: poprawny projekt resetu może nadal zawieść operacyjnie, jeśli kanały odzyskiwania są nieaktualne lub service desk nie poradzi sobie z początkowym obciążeniem.
Wymagaj dowodów przed cut-over haseł
Przetestuj wybraną ścieżkę w oddzielnym środowisku FoxIDs i najpierw przenieś kontrolowaną grupę użytkowników. Udane logowanie jest konieczne, ale niewystarczające.
| Obszar decyzji | Dowody wymagane przed szerszym wdrożeniem |
|---|---|
| Powiązanie tożsamości | Stabilne identyfikatory źródłowe, przetestowane zmiany identyfikatorów i zdefiniowana obsługa duplikatów lub brakujących użytkowników |
| Zachowanie haseł | Zaakceptowane i odrzucone hasła, proces wygasłego hasła, zmiana/reset hasła oraz błędy polityki |
| Dostępność | Monitorowanie connectora lub API walidacyjnego, timeouty, obsługa błędów i wskazany właściciel operacyjny |
| Migracja użytkowników | Wyniki pilota dla reprezentatywnych kont aktywnych, nieaktywnych, wyłączonych i ograniczonych |
| Bezpieczeństwo | Zatwierdzona obsługa materiału haseł, chronione secrets, logowanie diagnostyczne bez haseł i sprawdzona retencja danych |
| Cut-over | Kryteria zakończenia dla grup użytkowników, obsługa użytkowników bez zapisanego hasła docelowego, warunek rollback i właściciel wycofania źródła |
Utrzymuj źródło do czasu migracji wymaganej grupy użytkowników i zamknięcia okna rollback. Nie wyłączaj connectora tylko dlatego, że pilot się powiódł. Zweryfikuj docelową ścieżkę haseł dla grupy, która musi działać po cut-over, i zachowaj kontrolowaną ścieżkę resetu dla pozostałych.
Jak FoxIDs wspiera tę decyzję
Skorzystaj z dokumentacji migracji, aby wspólnie zaplanować aplikacje, użytkowników, hasła, cut-over i rollback. Dokumentacja Directory Connector, External Password API i przesyłania użytkowników zawiera dokładne szczegóły implementacyjne.
Jeśli możliwości źródła, grupy użytkowników lub kryteria cut-over nie są jeszcze jasne, FoxIDs Identity Migration opisuje, jak zespół stojący za platformą może pomóc zaprojektować i przeprowadzić migrację.
Podsumowanie
Użytkownicy mogą zachować istniejące hasło tylko wtedy, gdy migracja zachowuje wiarygodną ścieżkę walidacji lub bezpiecznie ustanawia zgodne hasło docelowe. Directory Connector często zapewnia najmniej uciążliwą stopniową ścieżkę, ale utrzymuje źródło w produkcyjnym przepływie authentication aż do świadomego cut-over.
Wybierz reset, gdy nie można wykazać zgodności, prawidłowego powiązania tożsamości lub bezpiecznej obsługi. Właściwa strategia haseł jasno określa autorytatywne źródło, zachowanie przy błędach, wpływ na użytkownika i kryteria zakończenia przed przeniesieniem ruchu produkcyjnego.