Migracja urządzeń Sophos między tenantami Central

W przypadku przejęcia firmy, konsolidacji tenantów lub nieprawidłowego przypisania klienta zarządzane komputery przenosi się za pomocą funkcji Device Migration z wysyłającego do odbierającego konta Sophos Fusion. Standardowy proces korzysta z Endpoint API: najpierw w miejscu docelowym tworzone jest zadanie Receiving Job, a następnie na koncie źródłowym uruchamiane jest powiązane zadanie Sending Job.

Zakres zastosowania: Aktualna pomoc Sophos opisuje ten proces dla „computers”. Przed wdrożeniem należy potwierdzić w aktualnej dokumentacji Endpoint API, odpowiedzi aktywnego tenanta lub u pomocy technicznej Sophos, jakie systemy operacyjne, typy urządzeń, wersje agentów i zainstalowane produkty są dozwolone w konkretnym tenancie. Ogólne typy Endpoint API nie stanowią listy typów urządzeń zatwierdzonych do migracji. Punkty dostępowe i przełączniki mają własne procesy i nie należą do tego przepływu pracy API.

Co zapewnia Device Migration, a co trzeba przygotować osobno

Device Migration zmienia rejestrację komputera i zarządzające nim konto. Po udanej migracji komputer jest zarządzany przez konto odbierające. Jeśli migracja się nie powiedzie, zgodnie z informacjami Sophos pozostaje on zarządzany przez konto wysyłające.

Publiczna dokumentacja nie opisuje przenoszenia polityk, grup, globalnych wykluczeń, list witryn, licencji, przypisań produktów, alertów, dochodzeń ani historii audytu. Nie można z tego wywnioskować ani że dane te są przenoszone automatycznie, ani że w całości pozostają na koncie źródłowym. Dlatego należy przygotować konfigurację docelową i po migracji sprawdzić faktycznie obowiązujące ustawienia.

Wymagania wstępne i planowanie pilotażu

Przed utworzeniem pierwszego zadania należy zinwentaryzować źródło i miejsce docelowe oraz wyznaczyć małą, reprezentatywną grupę pilotażową. Serwery krytyczne, systemy VDI, urządzenia w biurach domowych, odizolowane komputery i rzadko podłączane laptopy należy umieścić w osobnych falach.

Muszą być spełnione następujące wymagania:

• Osoba wykonująca migrację ma rolę Sophos Admin na obu kontach.
• Dla obu kont istnieją osobne API Credentials z rolą poświadczeń Service Principal Super Admin. Te poświadczenia musi utworzyć i nimi zarządzać osoba z rolą Super Admin; sama rola Admin nie wystarczy.
• Znane są identyfikator tenanta i regionalny host API obu kont. Należy je ustalić za pomocą standardowej konfiguracji Sophos API, a nie zgadywać.
• Identyfikatory Endpoint-ID migrowanych urządzeń pochodzą z konta wysyłającego, a przydatność każdego urządzenia pilotażowego została potwierdzona w aktywnym tenancie lub przez pomoc techniczną Sophos.
• W miejscu docelowym przygotowano odpowiednie licencje, polityki, grupy, wykluczenia i listy witryn.
• Update Caches, Message Relays i serwery proxy konta docelowego są dostępne z lokalizacji poszczególnych urządzeń.
• Odizolowania, otwarte alerty i trwające dochodzenia są udokumentowane, a niezbędne dowody incydentów i audytu zostały zabezpieczone przed zmianą.

API Client Secret oraz uzyskany za jego pomocą Bearer Token należą zawsze do konkretnego konta. Wydany później przez Receiving Job Migration Job Access Token jest innym sekretem. Client Secrets, Bearer Tokens i Migration Job Access Tokens nie mogą znaleźć się na zrzutach ekranu, w zgłoszeniach, historii powłoki ani dziennikach operacyjnych.

Zezwolenie na Device Migration na obu kontach

Najpierw należy zalogować się na konto wysyłające, a następnie na konto odbierające, i na każdym z nich otworzyć Global Settings > Platform > Device Migration:

1. Włączyć Allow device migration.
2. Ustawić możliwie krótki limit czasu, wystarczający dla pilotażu lub danej fali.
3. Bezpośrednio przed uruchomieniem zadania ponownie sprawdzić, czy okno jest aktywne na obu kontach.

Jeśli opcja jest zablokowana, ustawienie pochodzi z globalnych ustawień partnera lub administratora Enterprise. Nie należy obchodzić go metodami zastępczymi; zgodę musi wydać właściwa administracja nadrzędna.

Przeprowadzanie migracji za pomocą Receiving Job i Sending Job

Aktualna pomoc Sophos dotycząca Device Migration opisuje kolejność zadań. Endpoint Migration API Guide prowadzi do aktualnej dokumentacji API. Dokładną strukturę żądania, przypisanie pól i aktualny limit liczby elementów należy sprawdzić bezpośrednio przed wykonaniem w aktualnej definicji Endpoint API. Nie wolno bez weryfikacji przejmować historycznych payloadów ani limitów. Obowiązuje następująca kolejność:

1. Utworzenie Receiving Job w miejscu docelowym

Wzorzec operacji to POST /endpoint/v1/migrations. Wywołanie korzysta z regionalnego hosta API i poświadczeń konta odbierającego. Wysyła Bearer Token w nagłówku Authorization, identyfikator konta odbierającego w nagłówku X-Tenant-ID, a w przypadku treści JSON także nagłówek Content-Type: application/json.

Treść wskazuje konto wysyłające oraz zatwierdzone urządzenia z pilotażu lub fali. W historycznym schemacie pola te nazywały się fromTenant i endpoints; przed wykonaniem należy potwierdzić, czy w aktywnym schemacie nadal mają dokładnie takie nazwy i czy oba są wymagane na tym etapie.

Z odpowiedzi należy bezpiecznie zachować:

• identyfikator Receiving Job;
• Migration Job Access Token dla powiązanego Sending Job;
• datę wygaśnięcia zwróconą przez aktualne API, jeśli występuje.

Identyfikator zadania można zapisać w dzienniku zmian. Migration Job Access Token należy przekazać osobie lub automatyzacji tworzącej Sending Job wyłącznie bezpiecznym kanałem do przesyłania sekretów i nie wolno go trwale rejestrować.

2. Uruchomienie Sending Job w źródle

Następnie trzeba osobno uwierzytelnić się na koncie wysyłającym. Wzorzec operacji to PUT /endpoint/v1/migrations/{receivingMigrationJobId}. Ścieżka zawiera identyfikator Receiving Job. Wywołanie wysyła Bearer Token w nagłówku Authorization oraz identyfikator konta wysyłającego w nagłówku X-Tenant-ID; w przypadku treści JSON dochodzi nagłówek Content-Type: application/json.

Sending Job wykorzystuje:

• zatwierdzoną listę identyfikatorów Endpoint-ID z konta źródłowego;
• identyfikator utworzonego wcześniej Receiving Job;
• należący do niego Migration Job Access Token.

Historyczny schemat określa pola treści jako token i endpoints. Również te nazwy oraz aktualną strukturę odpowiedzi należy przed wykonaniem potwierdzić w aktywnej definicji.

Migracja rozpoczyna się wraz z Sending Job. Przed wysłaniem należy jeszcze raz sprawdzić kontekst tenanta, listę endpointów i zakres fali. Nie wolno ponownie używać tokena ani identyfikatora zadania z innego wykonania. Identyfikator Sending Job zwrócony przez aktualne API należy zapisać razem z identyfikatorem Receiving Job; datę wygaśnięcia zapisuje się tylko wtedy, gdy zwróci ją aktywna odpowiedź.

3. Monitorowanie statusu i kolejki

Postęp sprawdza się za pomocą GET /endpoint/v1/migrations/{migrationJobId}/endpoints. Wywołanie wykonuje się dla odpowiedniego Sending Job i Receiving Job w kontekście odpowiednio konta wysyłającego i odbierającego, każdorazowo z należącym do niego Bearer Token oraz X-Tenant-ID. Jeśli wyniki obejmują wiele stron, należy pobrać wszystkie strony i uzgodnić je dla każdego żądanego identyfikatora Endpoint-ID. Opcjonalnie GET /endpoint/v1/settings/migration pokazuje, czy na danym koncie zezwolono na migrację.

Aktualna aktywna definicja określa wartości statusów i pola szczegółowe. Historyczny schemat API używał wartości pending, succeeded i failed; zależnie od wyniku zwracał między innymi nowy identyfikator Endpoint-ID, dane czasowe i przyczynę błędu. Nazwy te są jedynie wskazówkami, a nie gwarancją dotyczącą aktualnego schematu. Należy zapisać faktycznie zwrócone wartości i pola.

Komputery pozostają w kolejce migracji do 14 dni. Komputer offline musi w tym czasie połączyć się z siecią. Krócej ustawione okno migracji może dodatkowo ograniczyć dostępny czas. Jeśli urządzenie pozostaje offline dłużej i migracja wygaśnie, zakończy się niepowodzeniem, a administrator będzie musiał ręcznie dodać je ponownie do kolejki migracji.

Oczekującego urządzenia offline nie należy profilaktycznie odinstalowywać ani modyfikować lokalnie jego identyfikatora tenanta. Najpierw trzeba przywrócić połączenie w czasie obowiązywania okna. Po nieudanej próbie urządzenie pozostaje zarządzane przez konto źródłowe.

Weryfikacja powodzenia w źródle, miejscu docelowym i na urządzeniu

Sam status API nie stanowi pełnego potwierdzenia odbioru. Przed kolejną falą należy uzgodnić wyniki z obu kont i komputera.

Oficjalne dowody migracji

1. Audit Log konta wysyłającego zawiera zdarzenie Send endpoints to another tenant.
2. Zdarzenie pomyślnie zmigrowanego komputera zawiera tekst Device registered with new account . It’s now managed by that account.
3. W przypadku komputera, którego migracja się nie powiodła, widnieje zamiast tego Device failed to register with new account . It continues to be managed by this account.
4. Audit Log konta odbierającego zawiera Allow endpoints to migrate to this tenant.
5. W miejscu docelowym, w sekcji My Environment > Computers & Servers, komputer jest zarejestrowany, przypisany do użytkownika i aktualny.
6. Wszystkie żądane identyfikatory Endpoint-ID są przypisane do wyników API; jeśli zwrócono nowy identyfikator Endpoint-ID, również należy go udokumentować.

Odbiór operacyjny

Następnie należy sprawdzić, czy komputer w miejscu docelowym jest rzeczywiście chroniony i obsługiwany zgodnie z planem:

• Typ urządzenia, licencja i zainstalowane produkty odpowiadają planowanej konfiguracji docelowej.
• Grupa docelowa, obowiązujące polityki, globalne wykluczenia i listy witryn są prawidłowe.
• Działają aktualizacje agenta, zatwierdzony test ochrony i planowane funkcje reagowania.
• Działanie Update Cache, Message Relay i serwera proxy jest zgodne z kontem docelowym.
• Stary rekord na koncie źródłowym nie jest mylony z aktywną rejestracją docelową.

Kolejna mała fala może się rozpocząć dopiero wtedy, gdy wynik API, zdarzenia audytu i endpointu oraz odbiór operacyjny są ze sobą zgodne.

Bezpieczne zawężanie przyczyn błędów

Zadanie pozostaje otwarte

Jeśli aktualne API pokazuje stan niezakończony, należy najpierw sprawdzić, czy komputer jest online, może połączyć się z Sophos i czy oba okna migracji nadal obowiązują. Dopóki migracja jest dozwolona, urządzenie offline może pozostać w kolejce. Po niepowodzeniu lub wygaśnięciu endpoint należy ręcznie dodać ponownie do kolejki z nowym, ważnym oknem migracji.

Migracja kończy się niepowodzeniem

Najpierw należy porównać przyczynę błędu zwróconą przez aktualne API ze zdarzeniem komputera i Audit Logs obu kont. Następnie sprawdza się kontekst tenanta, identyfikator Endpoint-ID, przypisanie zadania, aktualne zezwolenie na migrację i potwierdzoną przydatność danego komputera. Jeśli przyczyna błędu jest niejasna, należy zabezpieczyć identyfikatory obu zadań, identyfikator Endpoint-ID, znaczniki czasu, dane korelacyjne API i archiwum SDU, a następnie przekazać je pomocy technicznej Sophos — bez sekretów i tokenów.

W razie niepowodzenia zarządzanie nie zostało pomyślnie przeniesione; urządzenie pozostaje na koncie źródłowym. Udokumentowane API nie zawiera automatycznego procesu Cancel, Undo ani Rollback dla migracji, która już się powiodła. Powrót należy zaplanować jako nową, osobno potwierdzoną migrację albo ponowną rejestrację.

Wywołanie API zostaje odrzucone

Należy sprawdzić, czy Bearer Token, X-Tenant-ID i regionalny host API należą do tego samego konta oraz czy API Credentials mają na tym koncie rolę Service Principal Super Admin. Nie wolno mylić Bearer Token z Migration Job Access Token należącym do Receiving Job. Ponadto Allow device migration musi nadal być aktywne na obu kontach.

Alternatywa dla systemu Windows: ponowna rejestracja za pomocą --registeronly

--registeronly nie należy do procesu z Receiving Job i Sending Job ani nie zastępuje migracji API. Parametr służy do osobnej ponownej rejestracji chronionego już urządzenia z systemem Windows, gdy Device Migration nie jest odpowiednia lub dostępna w konkretnym przypadku, a zastosowanie tej metody zostało potwierdzone w aktualnej dokumentacji instalatora Windows albo przez pomoc techniczną Sophos.

Obowiązują przy tym osobne wymagania:

• Na urządzeniu z systemem Windows działa sprawna instalacja Sophos Protection.
• Aktualny, niezmodyfikowany instalator SophosSetup.exe pochodzi z konta docelowego, z sekcji My Environment > Installers.
• Zgodnie z udokumentowanym wymaganiem dla --registeronly na urządzeniu wyłączono Tamper Protection.
• Polecenie jest wykonywane lokalnie lub przez system dystrybucji oprogramowania z uprawnieniami administratora; urządzenie musi mieć łączność z Sophos.

Na urządzeniu z systemem Windows należy otworzyć Wiersz polecenia lub PowerShell jako administrator i uruchomić instalator docelowy:

.\SophosSetup.exe --registeronly

Nazwa pliku i ścieżka mogą się różnić. Pakiet z konta źródłowego nie doprowadziłby do oczekiwanego celu. Po wykonaniu polecenia obowiązują te same operacyjne kontrole miejsca docelowego co powyżej; samo zakończenie procesu instalatora nie jest dowodem powodzenia.

Parametru dla systemu Windows nie wolno stosować w systemach macOS ani Linux. Do ponownej rejestracji na innych platformach należy użyć aktualnego procesu platformowego udokumentowanego przez Sophos lub skorzystać z pomocy technicznej Sophos. Jeśli istniejący agent Windows jest uszkodzony lub został już usunięty, nie można użyć --registeronly. W takim przypadku należy zastosować obsługiwany proces naprawy lub dezinstalacji, a następnie przeprowadzić ponowną instalację za pomocą instalatora docelowego. Dla systemu Windows obsługiwaną procedurę odzyskiwania opisuje artykuł Odinstalowywanie Sophos Endpoint z włączoną ochroną antysabotażową.

Zmiany rejestru, sztuczki z trybem awaryjnym, modyfikacje plików MCS i ręcznie ustawiane identyfikatory tenantów nie są obsługiwanymi metodami migracji ani powrotu do konta źródłowego. Jeśli --registeronly się nie powiedzie, należy sprawdzić pochodzenie i aktualność instalatora, uprawnienia administratora, dostęp do Internetu lub serwera proxy oraz stan agenta. Przed skontaktowaniem się z pomocą techniczną Sophos należy zabezpieczyć dzienniki instalacji i, w razie potrzeby, archiwum SDU.

Zakończenie fali i zabezpieczenie dokumentacji

Po każdej fali należy uzgodnić listę planowaną z wynikami. Dokumentuje się:

• identyfikatory Receiving Job i Sending Job oraz przypisanie zadań wskazane w wyniku API;
• stary oraz, jeśli został zwrócony, nowy identyfikator Endpoint-ID;
• zwrócone przez aktualne API dane dotyczące statusu, czasu i błędów;
• zatwierdzone okno migracji, zakres fali i osobę odpowiedzialną;
• odbiór techniczny i operacyjny;
• właściciela użytych API Credentials, ale bez Secrets, Bearer Tokens i Migration Job Access Tokens.

Po ostatniej fali należy wyłączyć Allow device migration lub zamknąć ograniczone czasowo zezwolenia, usunąć tymczasowe wyjątki i przywrócić wszystkie mechanizmy ochrony do planowanego stanu. Nie należy zbiorczo usuwać starych obiektów źródłowych: najpierw trzeba sprawdzić wynik API, status własności i wymagania dotyczące przechowywania. Dowody incydentów i audytu należy nadal archiwizować osobno, zgodnie z wewnętrznymi zasadami.

Często zadawane pytania