Sophos-apparaten tussen Central-tenants migreren

Bij een bedrijfsovername, tenantconsolidatie of onjuiste klanttoewijzing worden beheerde computers met Device Migration van een verzendend naar een ontvangend Sophos Fusion-account verplaatst. Het reguliere proces maakt gebruik van de Endpoint API: eerst wordt in het doel een Receiving Job aangemaakt, waarna in het bronaccount de bijbehorende Sending Job wordt gestart.

Toepassingsgebied: De huidige Sophos-documentatie beschrijft dit proces voor «computers». Welke besturingssystemen, apparaattypen, agentversies en geïnstalleerde producten in de specifieke tenant zijn toegestaan, moet vóór de uitrol worden bevestigd aan de hand van de actuele Endpoint API-documentatie, het antwoord van de live-tenant of Sophos Support. De algemene Endpoint API-typen vormen geen lijst van apparaten die voor migratie zijn goedgekeurd. Access Points en Switches hebben hun eigen processen en horen niet thuis in deze API-workflow.

Wat Device Migration doet – en wat afzonderlijk wordt voorbereid

Device Migration wijzigt de registratie en het account dat de computer beheert. Na een geslaagde migratie wordt de computer door het ontvangende account beheerd. Als de migratie mislukt, blijft de computer volgens Sophos door het verzendende account beheerd.

De openbare documentatie beschrijft niet dat policies, groepen, globale uitzonderingen, websitelijsten, licenties, producttoewijzingen, alerts, onderzoeken of auditgeschiedenis worden overgedragen. Hieruit kan niet worden afgeleid dat deze gegevens automatisch worden overgedragen, noch dat ze volledig in het bronaccount achterblijven. Daarom wordt de doelconfiguratie voorbereid en wordt de effectieve status na de migratie gecontroleerd.

Vereisten en pilot plannen

Vóór de eerste taak worden bron en doel geïnventariseerd en wordt een kleine, representatieve pilot vastgesteld. Kritieke servers, VDI-systemen, thuiswerkapparaten, geïsoleerde computers en zelden verbonden laptops worden in afzonderlijke golven opgenomen.

Aan de volgende vereisten moet zijn voldaan:

• De uitvoerende persoon heeft in beide accounts de Sophos-rol Admin.
• Voor beide accounts bestaan afzonderlijke API Credentials met de credentialrol Service Principal Super Admin. Een menselijke Super Admin moet deze credentials aanmaken en beheren; alleen de rol Admin is hiervoor niet voldoende.
• De Tenant-ID en regionale API-host zijn voor beide accounts bekend. Ze worden via de reguliere Sophos API-setup vastgesteld en niet geraden.
• De te migreren Endpoint-ID’s zijn afkomstig uit het verzendende account en de geschiktheid van elk pilotapparaat is in de live-tenant of met Sophos Support bevestigd.
• In het doel zijn passende licenties, policies, groepen, uitzonderingen en websitelijsten voorbereid.
• Update Caches, Message Relays en proxies van het doelaccount zijn vanaf de betreffende apparaatlocatie bereikbaar.
• Isolaties, openstaande alerts en lopende onderzoeken zijn gedocumenteerd; benodigde incident- en auditbewijzen zijn vóór de overstap veiliggesteld.

API Client Secret en de daarmee verkregen Bearer Token behoren elk tot één account. De Migration Job Access Token die later door de Receiving Job wordt uitgegeven, is een ander geheim. Client Secrets, Bearer Tokens en Migration Job Access Tokens horen niet thuis in screenshots, tickets, shellgeschiedenis of operationele logboeken.

Device Migration in beide accounts toestaan

Eerst meldt u zich aan bij het verzendende en vervolgens bij het ontvangende account en opent u in elk account Global Settings > Platform > Device Migration:

1. Activeer Allow device migration.
2. Stel een zo kort mogelijke tijdslimiet in die voldoende is voor de pilot of golf.
3. Controleer vlak vóór het starten van de taak opnieuw of het venster in beide accounts actief is.

Als de optie is vergrendeld, is de instelling afkomstig uit de globale instellingen van de partner- of Enterprise-administrator. De taak wordt dan niet met workarounds omzeild; de verantwoordelijke bovenliggende beheerder moet toestemming verlenen.

Migratie uitvoeren met Receiving Job en Sending Job

De actuele Sophos-documentatie over Device Migration beschrijft de volgorde van de taken. De Endpoint Migration API Guide leidt naar de actuele API-referentie. De exacte requeststructuur, veldinvulling en actuele hoeveelheidslimiet worden vlak vóór de uitvoering rechtstreeks in de actuele Endpoint API-definitie gecontroleerd. Historische payloads of limieten worden niet zonder controle overgenomen. De volgende volgorde is van toepassing:

1. Receiving Job in het doel aanmaken

Het bewerkingspatroon is POST /endpoint/v1/migrations. De aanroep gebruikt de regionale API-host en de credentials van het ontvangende account. De Bearer Token wordt meegestuurd in de header Authorization, de ID van het ontvangende account in de header X-Tenant-ID en bij een JSON-body de header Content-Type: application/json.

De body vermeldt het verzendende account en de bevestigde apparaten van de pilotfase of golf. In het historische schema heten deze velden fromTenant en endpoints; vóór de uitvoering moet worden bevestigd of ze in het live-schema nog steeds exact zo heten en beide in deze stap vereist zijn.

Uit het antwoord worden de volgende gegevens veiliggesteld:

• de ID van de Receiving Job;
• de Migration Job Access Token voor de bijbehorende Sending Job;
• een door de actuele API opgegeven vervaldatum, indien aanwezig.

De taak-ID mag in het wijzigingslogboek worden opgenomen. De Migration Job Access Token wordt uitsluitend via een beveiligd geheimenkanaal doorgegeven aan de persoon of automatisering die de Sending Job aanmaakt en wordt niet permanent vastgelegd.

2. Sending Job in de bron starten

Daarna vindt afzonderlijke authenticatie in het verzendende account plaats. Het bewerkingspatroon is PUT /endpoint/v1/migrations/{receivingMigrationJobId}. Het pad bevat de Receiving Job-ID. De aanroep stuurt de Bearer Token mee in de header Authorization en de ID van het verzendende account in de header X-Tenant-ID; bij een JSON-body wordt Content-Type: application/json toegevoegd.

De Sending Job gebruikt:

• de bevestigde lijst met Endpoint-ID’s uit het bronaccount;
• de ID van de eerder aangemaakte Receiving Job;
• de bijbehorende Migration Job Access Token.

Het historische schema noemt de bodyvelden token en endpoints. Ook deze namen en de actuele antwoordstructuur worden vóór de uitvoering in de live-definitie bevestigd.

De migratie begint met de Sending Job. Vóór verzending worden de tenantcontext, Endpoint-lijst en omvang van de golf opnieuw gecontroleerd. Een token of taak-ID uit een andere uitvoering mag niet opnieuw worden gebruikt. De door de actuele API geretourneerde Sending Job-ID wordt samen met de Receiving Job-ID vastgelegd; een vervaldatum wordt alleen geregistreerd als het live-antwoord er een opgeeft.

3. Status en wachtrij bewaken

De voortgang wordt opgevraagd met GET /endpoint/v1/migrations/{migrationJobId}/endpoints. De aanroep vindt plaats voor de relevante Sending Job en Receiving Job in de context van respectievelijk het verzendende en ontvangende account, telkens met de bijbehorende Bearer Token en X-Tenant-ID. Als er meerdere resultaatpagina’s zijn, worden alle pagina’s opgevraagd en vergeleken met elke aangevraagde Endpoint-ID. Optioneel toont GET /endpoint/v1/settings/migration of migratie in het betreffende account is toegestaan.

De actuele live-definitie bepaalt de statuswaarden en detailvelden. Het historische API-schema gebruikte pending, succeeded en failed; afhankelijk van het resultaat leverde het onder meer een nieuwe Endpoint-ID, tijdgegevens en een foutreden. Deze namen zijn bedoeld als richtlijn en vormen geen toezegging over het actuele schema. De daadwerkelijk geretourneerde waarden en velden worden vastgelegd.

Computers blijven maximaal 14 dagen in de migratiewachtrij. Een offline computer moet binnen deze periode online komen. Een korter ingesteld migratievenster kan de beschikbare periode verder beperken. Als het apparaat langer offline blijft en de migratie verloopt, mislukt deze en moet een administrator het apparaat handmatig opnieuw in de migratiewachtrij plaatsen.

Een offline apparaat met de status in behandeling wordt niet preventief verwijderd of met lokale wijzigingen aan de Tenant-ID bewerkt. Eerst wordt de verbinding binnen het geldige venster hersteld. Bij een mislukte poging blijft het apparaat door het bronaccount beheerd.

Succes in bron, doel en op het apparaat controleren

Een API-status alleen is geen volledig acceptatiebewijs. Vóór de volgende golf worden de resultaten in beide accounts en op de computer met elkaar vergeleken.

Officiële migratiebewijzen

1. In het Audit Log van het verzendende account staat de gebeurtenis Send endpoints to another tenant.
2. In de gebeurtenis van de succesvol gemigreerde computer staat Device registered with new account . It’s now managed by that account.
3. Bij een computer waarvan de migratie is mislukt, staat in plaats daarvan Device failed to register with new account . It continues to be managed by this account.
4. In het Audit Log van het ontvangende account staat Allow endpoints to migrate to this tenant.
5. Onder My Environment > Computers & Servers in het doel is de computer geregistreerd, aan een gebruiker toegewezen en actueel.
6. De aangevraagde Endpoint-ID’s zijn zonder hiaten aan de API-resultaten gekoppeld; indien geretourneerd, wordt ook de nieuwe Endpoint-ID gedocumenteerd.

Operationele acceptatie

Vervolgens wordt gecontroleerd of de computer in het doel daadwerkelijk zoals gepland wordt beschermd en beheerd:

• Apparaattype, licentie en geïnstalleerde producten komen overeen met de geplande doelconfiguratie.
• Doelgroep, effectieve policies, globale uitzonderingen en websitelijsten zijn correct.
• Agentupdates, een goedgekeurde beveiligingstest en de geplande responsfuncties werken.
• Het gedrag van Update Cache, Message Relay en proxy past bij het doelaccount.
• Het oude record in het bronaccount wordt niet verward met de actieve doelregistratie.

Pas wanneer het API-resultaat, de audit- en Endpoint-events en de operationele acceptatie overeenkomen, begint de volgende kleine golf.

Fouten veilig afbakenen

Taak blijft openstaan

Als de actuele API een nog niet voltooide status toont, controleert u eerst of de computer online is, Sophos kan bereiken en beide migratievensters nog geldig zijn. Zolang migratie is toegestaan, mag een offline apparaat in de wachtrij blijven staan. Na een mislukking of het verlopen van de migratie wordt de Endpoint met een nieuw, geldig migratievenster handmatig opnieuw in de wachtrij geplaatst.

Migratie mislukt

Eerst wordt een door de actuele API geretourneerde foutreden vergeleken met de gebeurtenis van de computer en de Audit Logs van beide accounts. Daarna worden de tenantcontext, Endpoint-ID, taakkoppeling, actuele migratietoestemming en de voor deze computer bevestigde geschiktheid gecontroleerd. Bij een onduidelijke fout worden beide taak-ID’s, de Endpoint-ID, tijdstempels, API-correlatiegegevens en een SDU-archief veiliggesteld en aan Sophos Support verstrekt – zonder geheimen of tokens.

Bij een mislukking is het beheer niet met succes overgedragen; het apparaat blijft bij het bronaccount. Voor een reeds geslaagde migratie is in de gedocumenteerde API geen automatisch Cancel-, Undo- of Rollback-proces aangetoond. Een terugkeer wordt als een nieuwe, afzonderlijk bevestigde migratie of herregistratie gepland.

API-aanroep wordt geweigerd

Controleer of de Bearer Token, X-Tenant-ID en regionale API-host bij hetzelfde account horen en of de API Credentials daar de rol Service Principal Super Admin hebben. De Bearer Token mag niet worden verward met de Migration Job Access Token van de Receiving Job. Bovendien moet Allow device migration nog steeds in beide accounts actief zijn.

Windows-alternatief: opnieuw registreren met --registeronly

--registeronly maakt geen deel uit van het proces met een Receiving Job en Sending Job en vervangt de API-migratie niet. De optie is bedoeld voor de afzonderlijke Windows-herregistratie van een reeds beschermd apparaat wanneer Device Migration voor het specifieke geval niet geschikt of niet beschikbaar is en deze methode aan de hand van de actuele documentatie voor het Windows-installatieprogramma of door Sophos Support is bevestigd.

Hiervoor gelden afzonderlijke vereisten:

• Op het Windows-apparaat is een werkende Sophos Protection-installatie aanwezig.
• Een actueel, ongewijzigd SophosSetup.exe-installatieprogramma is onder My Environment > Installers afkomstig uit het doelaccount.
• Volgens de gedocumenteerde vereiste voor --registeronly is Tamper Protection op het apparaat uitgeschakeld.
• De opdracht wordt lokaal of via softwaredistributie met administratorrechten uitgevoerd; het apparaat moet Sophos kunnen bereiken.

Open op het Windows-apparaat een opdrachtprompt of PowerShell als administrator en start het doelinstallatieprogramma:

.\SophosSetup.exe --registeronly

De bestandsnaam en het pad kunnen afwijken. Een pakket uit het bronaccount zou het doel missen. Na de opdracht gelden dezelfde operationele doelcontroles als hierboven; alleen het beëindigen van het installatieproces is geen bewijs van succes.

De Windows-optie mag niet op macOS of Linux worden toegepast. Voor herregistratie op andere platforms wordt het actuele, door Sophos gedocumenteerde platformproces of Sophos Support gebruikt. Als de bestaande Windows-agent beschadigd of al verwijderd is, kan --registeronly niet worden gebruikt. Volg dan het ondersteunde reparatie- of verwijderingsproces en installeer vervolgens opnieuw met het doelinstallatieprogramma. Voor Windows beschrijft Sophos Endpoint verwijderen met ingeschakelde Tamper Protection het ondersteunde herstelproces.

Registerwijzigingen, trucs met de veilige modus, manipulatie van MCS-bestanden en handmatig ingestelde Tenant-ID’s zijn geen ondersteunde procedures voor een migratie of terugkeer naar het bronaccount. Als --registeronly mislukt, worden de herkomst en actualiteit van het installatieprogramma, administratorrechten, internet-/proxybereikbaarheid en agentstatus gecontroleerd. Installatielogboeken en zo nodig een SDU-archief worden veiliggesteld voordat Sophos Support wordt ingeschakeld.

Golf afronden en bewijzen veiligstellen

Na elke golf worden de geplande lijst en de resultaten met elkaar vergeleken. De volgende gegevens worden gedocumenteerd:

• Receiving Job-ID en Sending Job-ID en de in het API-resultaat vermelde taakkoppeling;
• de oude en, indien geretourneerd, nieuwe Endpoint-ID;
• de door de actuele API geretourneerde status-, tijd- en foutgegevens;
• toegestaan migratievenster, omvang van de golf en verantwoordelijke persoon;
• technische en operationele acceptatie;
• eigenaar van de gebruikte API Credentials, maar geen Client Secrets, Bearer Tokens of Migration Job Access Tokens.

Na de laatste golf worden Allow device migration of de tijdgebonden toestemmingen gesloten, tijdelijke uitzonderingen opgeruimd en alle beveiligingscontroles in de beoogde status teruggebracht. Oude bronobjecten worden niet zonder meer verwijderd: eerst worden het API-resultaat, de eigendomsstatus en de bewaareisen gecontroleerd. Incident- en auditbewijzen blijven volgens de interne voorschriften afzonderlijk gearchiveerd.

Veelgestelde vragen