Migrar dispositivos Sophos entre tenants do Central

Em caso de aquisição de uma empresa, consolidação de tenants ou atribuição incorreta de um cliente, os computadores geridos são transferidos de uma conta Sophos Fusion de origem para uma conta de destino através da Device Migration. O procedimento normal utiliza a Endpoint API: primeiro, cria-se um Receiving Job no destino e, em seguida, inicia-se o Sending Job correspondente na conta de origem.

Âmbito: A ajuda atual da Sophos descreve este procedimento para «computers». Antes da implementação, é necessário confirmar, através da documentação atual da Endpoint API, da resposta do tenant ativo ou do Sophos Support, quais os sistemas operativos, tipos de dispositivo, versões do agente e produtos instalados permitidos no tenant em questão. Os tipos gerais da Endpoint API não constituem uma lista de compatibilidade para a migração. Os Access Points e Switches têm procedimentos próprios e não fazem parte deste fluxo de trabalho da API.

O que faz a Device Migration — e o que deve ser preparado separadamente

A Device Migration altera o registo e a conta que gere o computador. Após uma migração bem-sucedida, este passa a ser gerido pela conta de destino. Se a migração falhar, segundo a Sophos, continua a ser gerido pela conta de origem.

A documentação pública não descreve a transferência de políticas, grupos, exceções globais, listas de sites, licenças, atribuições de produtos, alertas, investigações ou histórico de auditoria. Daqui não se pode concluir nem que estes dados sejam transferidos automaticamente, nem que permaneçam integralmente na conta de origem. Por este motivo, a configuração de destino é preparada e o estado efetivo é verificado após a migração.

Planear os pré-requisitos e o piloto

Antes do primeiro job, é feito o inventário da origem e do destino e definido um piloto pequeno e representativo. Os servidores críticos, sistemas VDI, dispositivos em teletrabalho, computadores isolados e portáteis que raramente estabelecem ligação são incluídos em vagas separadas.

Devem estar reunidos os seguintes pré-requisitos:

• A pessoa que executa o procedimento tem a função Sophos Admin em ambas as contas.
• Existem API Credentials distintas para ambas as contas, com a função de credencial Service Principal Super Admin. Um Super Admin humano tem de criar e gerir estas credenciais; a função Admin, por si só, não é suficiente para tal.
• O Tenant ID e o host regional da API de ambas as contas são conhecidos. Estes são obtidos através da configuração normal da API da Sophos e não determinados por suposição.
• Os Endpoint IDs a migrar provêm da conta de origem e a elegibilidade de cada dispositivo piloto foi confirmada no tenant ativo ou com o Sophos Support.
• Estão preparadas no destino as licenças, políticas, grupos, exceções e listas de sites adequados.
• Os Update Caches, Message Relays e proxies da conta de destino estão acessíveis a partir da localização de cada dispositivo.
• Os isolamentos, alertas em aberto e investigações em curso estão documentados; as provas necessárias de incidentes e auditoria foram guardadas antes da alteração.

O API Client Secret e o Bearer Token obtido a partir do mesmo pertencem, em cada caso, a uma conta. O Migration Job Access Token posteriormente devolvido pelo Receiving Job é um segredo diferente. Client Secrets, Bearer Tokens e Migration Job Access Tokens não devem constar de capturas de ecrã, tickets, histórico da shell ou registos operacionais.

Autorizar a Device Migration em ambas as contas

Primeiro, inicia-se sessão na conta de origem e depois na conta de destino, abrindo em cada uma Global Settings > Platform > Device Migration:

1. Ativar Allow device migration.
2. Definir um limite de tempo tão curto quanto possível, mas suficiente para o piloto ou a vaga.
3. Imediatamente antes de iniciar o job, confirmar novamente que a janela está ativa em ambas as contas.

Se a opção estiver bloqueada, a definição provém das definições globais do parceiro ou do Enterprise Administrator. Nesse caso, não se deve contornar o bloqueio do job com soluções alternativas; a administração superior responsável tem de conceder a autorização.

Efetuar a migração com Receiving Job e Sending Job

A ajuda atual da Sophos sobre Device Migration descreve a sequência dos jobs. O Endpoint Migration API Guide remete para a referência atual da API. A estrutura exata do pedido, o preenchimento dos campos e o limite quantitativo atual são verificados diretamente na definição atual da Endpoint API imediatamente antes da execução. Não se reutilizam payloads ou limites históricos sem os verificar. A sequência é a seguinte:

1. Criar o Receiving Job no destino

O padrão da operação é POST /endpoint/v1/migrations. A chamada utiliza o host regional da API e as credenciais da conta de destino. Envia o Bearer Token no cabeçalho Authorization, o ID da conta de destino no cabeçalho X-Tenant-ID e, quando existe um body JSON, o cabeçalho Content-Type: application/json.

O body identifica a conta de origem e os dispositivos confirmados da fase piloto ou da vaga. No esquema histórico, estes campos chamam-se fromTenant e endpoints; antes da execução, é necessário confirmar se continuam a ter exatamente estes nomes no esquema ativo e se ambos são necessários neste passo.

Da resposta, guardam-se:

• o ID do Receiving Job;
• o Migration Job Access Token para o Sending Job correspondente;
• uma data de expiração devolvida pela API atual, caso exista.

O Job ID pode ser incluído no registo de alterações. O Migration Job Access Token só é transmitido, através de um canal seguro para segredos, à pessoa ou automação que cria o Sending Job e não é registado de forma permanente.

2. Iniciar o Sending Job na origem

Em seguida, a autenticação é efetuada separadamente na conta de origem. O padrão da operação é PUT /endpoint/v1/migrations/{receivingMigrationJobId}. O caminho contém o ID do Receiving Job. A chamada envia o Bearer Token no cabeçalho Authorization e o ID da conta de origem no cabeçalho X-Tenant-ID; quando existe um body JSON, acrescenta-se Content-Type: application/json.

O Sending Job utiliza:

• a lista confirmada dos Endpoint IDs da conta de origem;
• o ID do Receiving Job anteriormente criado;
• o respetivo Migration Job Access Token.

O esquema histórico designa os campos do body por token e endpoints. Estes nomes e a estrutura atual da resposta também são confirmados na definição ativa antes da execução.

A migração começa com o Sending Job. Antes do envio, voltam a verificar-se o contexto do tenant, a lista de endpoints e a dimensão da vaga. Não se pode reutilizar um token ou Job ID de outra execução. O ID do Sending Job devolvido pela API atual é registado juntamente com o ID do Receiving Job; uma data de expiração só é registada caso a resposta ativa forneça uma.

3. Monitorizar o estado e a fila

O progresso é consultado com GET /endpoint/v1/migrations/{migrationJobId}/endpoints. A chamada é efetuada para o Sending Job e o Receiving Job relevantes, no contexto da conta de origem e de destino, respetivamente, sempre com o Bearer Token e o X-Tenant-ID dessa conta. Se os resultados ocuparem várias páginas, todas são consultadas e comparadas com cada Endpoint ID solicitado. Opcionalmente, GET /endpoint/v1/settings/migration confirma se a migração continua permitida para uma conta.

A definição ativa atual determina os valores de estado e os campos de detalhe. O esquema histórico da API utilizava pending, succeeded e failed; consoante o resultado, fornecia, entre outros elementos, um novo Endpoint ID, dados de tempo e um motivo de erro. Estes nomes são apenas referências e não uma garantia do esquema atual. São guardados os valores e campos efetivamente devolvidos.

Os computadores permanecem até 14 dias na fila de migração. Um computador offline tem de ficar online durante este período. Uma janela de migração configurada com uma duração inferior pode reduzir ainda mais o período disponível. Se o dispositivo permanecer offline durante mais tempo e a migração expirar, esta falha e um administrador tem de voltar a colocar manualmente o dispositivo na fila de migração.

Um dispositivo offline pendente não deve ser desinstalado preventivamente nem sujeito a alterações locais do Tenant ID. Primeiro, restabelece-se a ligação dentro da janela válida. Se uma tentativa falhar, o dispositivo continua a ser gerido pela conta de origem.

Verificar o sucesso na origem, no destino e no dispositivo

Um estado da API, por si só, não constitui uma prova completa de aceitação. Antes da vaga seguinte, comparam-se os resultados nas duas contas e no computador.

Provas oficiais da migração

1. O Audit Log da conta de origem contém o evento Send endpoints to another tenant.
2. O evento do computador migrado com êxito contém Device registered with new account . It’s now managed by that account.
3. No caso de um computador cuja migração tenha falhado, contém, em vez disso, Device failed to register with new account . It continues to be managed by this account.
4. O Audit Log da conta de destino contém Allow endpoints to migrate to this tenant.
5. Em My Environment > Computers & Servers, no destino, o computador está registado, atribuído a um utilizador e atualizado.
6. Todos os Endpoint IDs solicitados estão associados aos resultados da API; caso seja devolvido, o novo Endpoint ID também é documentado.

Aceitação operacional

Em seguida, verifica-se se, no destino, o computador está efetivamente protegido e é operado como planeado:

• O tipo de dispositivo, a licença e os produtos instalados correspondem à configuração de destino prevista.
• O grupo de destino, as políticas efetivas, as exceções globais e as listas de sites estão corretos.
• As atualizações do agente, um teste de proteção aprovado e as funções de resposta previstas funcionam.
• O comportamento do Update Cache, Message Relay e proxy é adequado à conta de destino.
• O registo antigo na conta de origem não é confundido com o registo de destino ativo.

A vaga pequena seguinte só começa quando o resultado da API, os eventos de auditoria e do endpoint, bem como a aceitação operacional, estiverem em conformidade.

Isolar os erros em segurança

O job permanece aberto

Se a API atual apresentar um estado ainda não concluído, verifica-se primeiro se o computador está online, se consegue comunicar com a Sophos e se ambas as janelas de migração continuam válidas. Enquanto a migração estiver autorizada, um dispositivo offline pode permanecer na fila. Após uma falha ou expiração, o endpoint é novamente colocado manualmente na fila com uma janela de migração nova e válida.

A migração falha

Primeiro, compara-se um eventual motivo de erro devolvido pela API atual com o evento do computador e os Audit Logs das duas contas. Em seguida, verificam-se o contexto do tenant, o Endpoint ID, a associação ao job, a autorização de migração atual e a elegibilidade confirmada para esse computador. Se o erro não for claro, guardam-se os dois Job IDs, o Endpoint ID, os carimbos de data/hora, os dados de correlação da API e um arquivo SDU, que são enviados ao Sophos Support — sem segredos nem tokens.

Em caso de falha, a gestão não foi transferida com êxito; o dispositivo permanece na conta de origem. Para uma migração já concluída com êxito, a API documentada não contém qualquer procedimento automático de cancelamento, anulação ou rollback. Uma transferência de regresso é planeada como uma migração nova e confirmada separadamente ou como um novo registo.

A chamada da API é rejeitada

Verifica-se se o Bearer Token, o X-Tenant-ID e o host regional da API pertencem à mesma conta e se as API Credentials dessa conta têm a função Service Principal Super Admin. O Bearer Token não deve ser confundido com o Migration Job Access Token do Receiving Job. Além disso, Allow device migration tem de continuar ativo nas duas contas.

Alternativa para Windows: efetuar um novo registo com --registeronly

--registeronly não faz parte do procedimento com Receiving Job e Sending Job e não substitui a migração através da API. Esta opção destina-se ao novo registo separado, no Windows, de um dispositivo já protegido quando a Device Migration não é adequada ou não está disponível para o caso concreto e este método foi confirmado através da documentação atual do instalador para Windows ou pelo Sophos Support.

Aplicam-se os seguintes pré-requisitos específicos:

• Existe uma instalação funcional do Sophos Protection no dispositivo Windows.
• Um instalador SophosSetup.exe atual e inalterado provém de My Environment > Installers na conta de destino.
• De acordo com o pré-requisito documentado para --registeronly, a Tamper Protection está desativada no dispositivo.
• O comando é executado localmente ou através de distribuição de software, com direitos de administrador; o dispositivo tem de conseguir comunicar com a Sophos.

No dispositivo Windows, abre-se uma Linha de Comandos ou o PowerShell como administrador e inicia-se o instalador de destino:

.\SophosSetup.exe --registeronly

O nome e o caminho do ficheiro podem ser diferentes. Um pacote da conta de origem não permitiria atingir o destino. Após o comando, aplicam-se as mesmas verificações operacionais no destino descritas acima; o simples facto de o processo do instalador terminar não constitui prova de êxito.

A opção do Windows não deve ser utilizada no macOS nem no Linux. Para efetuar um novo registo noutras plataformas, utiliza-se o procedimento atual documentado pela Sophos para a plataforma ou recorre-se ao Sophos Support. Se o agente Windows existente estiver danificado ou já tiver sido removido, não é possível utilizar --registeronly. Nesse caso, segue-se o procedimento suportado de reparação ou desinstalação e, posteriormente, efetua-se uma nova instalação com o instalador de destino. Para Windows, Desinstalar o Sophos Endpoint com a proteção contra adulteração ativada descreve o procedimento de recuperação suportado.

As alterações ao Registry, os truques em Safe Mode, a manipulação de ficheiros MCS e a definição manual de Tenant IDs não são métodos suportados para uma migração ou para o regresso à conta de origem. Se --registeronly falhar, verificam-se a origem e a atualidade do instalador, os direitos de administrador, a acessibilidade da Internet/do proxy e o estado do agente. Os registos de instalação e, se necessário, um arquivo SDU são guardados antes de contactar o Sophos Support.

Concluir a vaga e guardar as provas

Após cada vaga, a lista planeada é comparada com os resultados. Documentam-se:

• os IDs do Receiving Job e do Sending Job, bem como a associação ao job indicada no resultado da API;
• o Endpoint ID antigo e, caso seja devolvido, o novo;
• os dados de estado, tempo e erro devolvidos pela API atual;
• a janela de migração autorizada, a dimensão da vaga e a pessoa responsável;
• a aceitação técnica e operacional;
• o proprietário das API Credentials utilizadas, mas não segredos, Bearer Tokens nem Migration Job Access Tokens.

Após a última vaga, encerra-se Allow device migration ou as autorizações temporárias, removem-se as exceções temporárias e repõem-se todos os controlos de proteção no estado previsto. Os objetos antigos na origem não são eliminados indiscriminadamente: primeiro, verificam-se o resultado da API, o estado de propriedade e os requisitos de retenção. As provas de incidentes e auditoria permanecem arquivadas separadamente, de acordo com as regras internas.

Perguntas frequentes