Substituir o Sophos Mobile Container: transferir dados e dispositivos em segurança
Decisão em resumo: Não efetuar novas implementações do Sophos Container, que deixou de ter suporte, com Sophos Secure Email e Sophos Secure Workspace. Uma política do Samsung Knox Container corresponde a outra forma de gestão: o fim do Sophos Container não implica o fim generalizado do Samsung Knox Workspace. Para os dispositivos existentes, identificar primeiro o tipo de contentor, o modo de gestão e os dados profissionais. Nem uma nova inscrição nem a remoção do dispositivo antigo transferem automaticamente os dados do contentor.
Que contentor é afetado?
Sophos Container: O Sophos Container, com Secure Email e Secure Workspace, chegou ao fim do período de suporte. A Sophos indica o Android Enterprise com perfil de trabalho e o Apple User Enrollment como futuros modelos de gestão para os respetivos cenários Android e Apple. São modelos de gestão de destino, não uma garantia de transferência de ficheiros, mensagens, contas ou definições das aplicações.
Desde 6 de maio de 2024, as aplicações Secure Workspace para Android e iOS deixaram de poder transferir documentos de trabalho do Sophos Mobile. Em 7 de outubro de 2024, a Sophos anunciou que estava a retirar a possibilidade de criar novas políticas de contentor Android/iOS e de adicionar ou atualizar documentos de trabalho. Em 21 de outubro de 2024, a Sophos declarou que começava a eliminar os documentos de trabalho do Secure Workspace anteriormente carregados para o Sophos Mobile. Isto não comprova que todas as cópias tenham sido eliminadas nem estabelece um método de recuperação atualmente suportado; uma entrada de ficheiro ainda visível não prova que o conteúdo continue acessível no serviço.
Samsung Knox Container: As páginas da Sophos sobre Knox container policies que ainda se encontram disponíveis descrevem contentores Samsung Knox: requisitos de palavra-passe, restrições e uma conta de e-mail. Não comprovam a existência de suporte atual para uma nova implementação do Knox num dispositivo específico.
A Samsung distingue os antigos contentores CL/COM, o Knox Workspace enquanto contentor gerido e os perfis de trabalho do Android Enterprise. Mesmo que a Samsung continue a descrever o Knox Workspace como contentor gerido em dispositivos elegíveis, isso não garante o suporte pelo Sophos Mobile no tenant em causa nem a disponibilidade de novas funcionalidades Knox.
O modo Device administrator do Android está obsoleto no Sophos Mobile e só está disponível para o Android 9 ou anterior. Nenhuma destas informações estabelece uma data geral de desativação do Knox.
Fazer o inventário sem alterar nada
Criar uma lista de trabalho para cada dispositivo, com responsáveis e estado da aprovação:
- Registar o dispositivo, o tipo de propriedade (empresa ou particular), o modelo, a versão do Android/iOS, o utilizador e a área de negócio. Comparar o tipo real de contentor e o modo de gestão no dispositivo e no tenant. Na página Show device da Sophos, Status, Policies, Device properties, Installed apps e, no caso da Samsung, Knox apps e Knox system apps podem fornecer indícios; uma aplicação visível na lista ainda não constitui uma cópia de segurança dos dados.
- Verificar as políticas Knox atribuídas quanto a Password, Restrictions e Email account, sem as alterar. Registar as contas profissionais, os ficheiros, os anexos e as aplicações que se encontram no contentor, bem como os respetivos responsáveis pelos dados. A entrada documentada de uma conta Exchange não comprova que a autenticação ainda funcione nem que seja possível exportar localmente as mensagens de e-mail.
- Confirmar com o responsável pelos dados se os conteúdos se encontram no serviço de origem ou apenas localmente no contentor, se já existe uma cópia de segurança autorizada e se o acesso funciona atualmente. No caso do Knox, verificar a licença associada ao dispositivo e a respetiva data de validade: uma licença do Workspace expirada pode impedir o acesso, sobretudo em versões mais antigas do Android, sem necessariamente eliminar os dados. Isso não constitui um método universal de recuperação.
Parar se não houver acesso aos dados: Não tentar sucessivamente palavras-passe nem repor um contentor. Uma política de palavras-passe Knox pode eliminar o contentor após demasiadas tentativas falhadas. O antigo percurso de autosserviço ResetContainerPassword contém atualmente apenas o aviso sobre o fim do suporte do Sophos Container e a indicação para contactar a equipa de TI; não contém instruções de reposição ou recuperação.
Aprovar a transferência dos dados antes de cancelar a inscrição
Antes de qualquer alteração, a equipa de TI, o utilizador e os responsáveis pelos dados devem definir, para cada tipo de dados afetado e tendo em conta a propriedade do dispositivo e as regras de proteção de dados, um método autorizado de exportação específico da aplicação ou de novo acesso pelo serviço de origem, bem como o novo destino.
Uma lista de nomes de ficheiros ou de aplicações instaladas não basta: para um pequeno grupo-piloto, abrir no destino os documentos aprovados e as mensagens necessárias com a identidade prevista e verificar as permissões de acesso. Só considerar comprovada a recuperação a partir de uma cópia de segurança se existir efetivamente um método aprovado de cópia de segurança e recuperação. Voltar a abrir um documento no serviço de origem não equivale a recuperar dados locais eliminados do contentor.
Condição para cópias de segurança: Para cada dispositivo, tipo de dados necessário e identidade prevista, verificar o acesso autorizado e independente no novo destino aprovado ou restaurar efetivamente a cópia num destino distinto e aprovado durante o piloto. Verificar com o responsável pelos dados os conteúdos e permissões restaurados; documentar e obter a sua aprovação explícita para quaisquer dados exclusivamente locais excluídos. Uma recuperação apenas no dispositivo antigo não autoriza a sua reposição, desinscrição ou eliminação. Se faltar algum dado necessário, parar e deixar o dispositivo inalterado.
Se o acesso ou uma recuperação necessária falhar, não cancelar a inscrição, eliminar a entrada do dispositivo na consola nem executar ações que possam apagar dados, incluindo um wipe; escalar o caso, incluindo o tipo de dispositivo, o modo, o estado da licença e a descrição do erro, às equipas competentes da Sophos/Samsung e ao responsável pelos dados. A solução de contingência pode consistir em deixar o dispositivo antigo inalterado; não se pressupõe que a recuperação técnica seja possível. Para o Secure Workspace, não está comprovada a existência de um método geral de download atualmente nem a recuperação de documentos eliminados do serviço.
A opção Knox Allow data export permite que aplicações pessoais acedam aos dados do contentor; não é uma funcionalidade de cópia de segurança pronta a usar nem uma autorização geral para transferir dados profissionais para o espaço pessoal. Allow all certificates, no histórico perfil de e-mail Knox, também não é uma solução aceitável para contornar problemas de autenticação ou certificados. Não ativar preventivamente nenhuma destas opções.
Aprovação e piloto
Só planear a forma de gestão adequada a cada dispositivo depois de os dados do piloto estarem legíveis no novo destino e de estar definido o procedimento para o caso de a transferência falhar. Um piloto bem-sucedido não prova que os dados guardados exclusivamente de forma local estejam acessíveis em todos os outros dispositivos. Para cada dispositivo afetado e cada tipo de dados, antes de cancelar a inscrição, eliminar a entrada do dispositivo na consola, eliminar dados, remover uma política ou aplicação, ou executar um wipe, verificar o método de acesso autorizado para esse caso e a aprovação do responsável pelos dados.
Forma de gestão conforme a propriedade do dispositivo
Antes de qualquer uma das vias, confirmar por dispositivo o acesso aos dados e a aprovação do responsável pelos dados, conforme indicado acima. Numa inscrição antiga no modo Device administrator, Unenroll desativa o administrador de dispositivo Sophos Mobile Control, remove as credenciais de acesso ao servidor e outros dados recebidos deste e repõe o Sophos Intercept X for Mobile; Delete remove depois o registo do dispositivo e os dados associados armazenados pelo Sophos Mobile. Primeiro cancelar a inscrição e só depois eliminar o registo: eliminar um dispositivo ainda inscrito pode torná-lo inutilizável. Esta sequência não transfere conteúdos locais dos contentores Knox ou Sophos. Não se aplica a um perfil de trabalho Android Enterprise já existente: a remoção desse perfil apaga todas as aplicações e todos os dados dentro dele. O cancelamento da inscrição de um dispositivo Android Enterprise totalmente gerido exige uma reposição de fábrica. Verificar o modo real e obter aprovação dos possíveis riscos de perda de dados antes de agir.
Verificação antes de ações destrutivas (antes de Wipe ou Delete): Num dispositivo Android Enterprise totalmente gerido, o próprio Delete desencadeia uma reposição de fábrica; Unenroll antes de Delete não a evita. Para esse dispositivo específico, confirmar a identidade, o destino aprovado dos dados e o responsável pela reposição e nova inscrição, bem como a Factory Reset Protection (FRP): validar os identificadores das contas Google configuradas e confirmar que o responsável consegue utilizar ou recuperar as respetivas credenciais após a reposição. Contas FRP inválidas ou credenciais desconhecidas podem tornar o dispositivo inutilizável. Se a responsabilidade pelo dispositivo ou pelas contas não estiver comprovada, parar e escalar sem Wipe, Unenroll ou Delete. A remoção de um perfil de trabalho apaga as aplicações e os dados nele contidos; a sequência Device administrator abaixo só é aplicável depois de confirmar esse modo antigo.
Nos dispositivos Android da empresa já inscritos no Sophos Mobile no modo Device administrator, a mudança documentada para o Android Enterprise com gestão completa do dispositivo exige primeiro uma reposição de fábrica (Show device na consola de administração: Actions > Wipe) e só depois uma nova inscrição. Antes do wipe, é necessário configurar o Android Enterprise, confirmar a identidade do dispositivo e os possíveis riscos de perda de dados, e comprovar, para cada dispositivo, o acesso aos dados e a aprovação do responsável pelos dados; sem essas provas, não executar o wipe. Para dispositivos Android particulares, a outra sequência documentada só se aplica aos já inscritos no modo Device administrator: depois de configurar o Android Enterprise, na consola de administração, abrir Show device e executar primeiro Actions > Unenroll, depois Actions > Delete e, por fim, inscrever novamente o dispositivo com um perfil de trabalho do Android Enterprise. Não se trata de uma ação de autosserviço (SSP) para remover um perfil de trabalho já existente. Ambas são formas de gestão, não uma migração dos conteúdos locais dos contentores Knox ou Sophos.
Os efeitos de Unenroll, Delete, desinstalação de políticas, desinstalação de aplicações e Wipe são diferentes; em particular, um wipe pode eliminar dados de forma irrecuperável. Não considerar nenhuma destas ações, por si só, como prova da transferência completa dos dados apenas porque uma tarefa na consola foi concluída com êxito.
Verificação final e condição de paragem
Após a alteração controlada nos dispositivos-piloto, verificar separadamente a autenticação, o perfil de trabalho ou o User Enrollment, as aplicações geridas e o acesso aos dados profissionais aprovados.
Parar em cada dispositivo: Antes de qualquer alteração, são necessários a aprovação exigida e o acesso confirmado e autorizado aos dados profissionais aprovados no novo destino ou, quando aplicável, a recuperação comprovada a partir de uma cópia de segurança. Se não houver acesso e não estiver comprovada uma recuperação aplicável, deixar o dispositivo antigo inalterado e escalar o caso. Sem aprovação, também deve permanecer inalterado. Nem o piloto nem o cancelamento da inscrição comprovam a recuperação de dados locais eliminados.
Uma cópia recuperada apenas no dispositivo antigo nunca satisfaz esta condição. Para cada tipo de dados e identidade necessários, exigir um destino aprovado acessível de modo independente ou uma cópia restaurada e validada noutro destino aprovado durante o piloto, com aprovação do responsável para os dados exclusivamente locais excluídos. Sem acesso independente comprovado, responsabilidade pelas contas FRP, quando aplicável, ou aprovação, nenhuma ação destrutiva.