Sophos Mobile: planejar com segurança as regras de senha e as políticas de segurança do Windows

Nas políticas do Windows no Sophos Mobile, a decisão mais importante não é escolher a configuração mais rigorosa, mas fazer um piloto recuperável: confirmar a edição e o estado de gerenciamento, verificar a recuperação do BitLocker antes de uma possível reinicialização, inventariar as contas locais e só então atribuir uma única alteração a um dispositivo de teste. Uma política do Windows não é a política de Device Encryption do Sophos Fusion e não substitui um processo de recuperação do BitLocker. Para o gerenciamento e a recuperação das respectivas chaves, consulte Gerenciar o BitLocker com o Sophos Fusion.

Antes da primeira atribuição

Plataforma e escopo: O dispositivo de destino deve estar efetivamente gerenciado como computador Windows pelo Sophos Mobile; o Sophos Endpoint Protection, por si só, não constitui uma inscrição no MDM. A lista de requisitos do Sophos Mobile inclui Windows 10/11 Enterprise, Education e Pro, mas não Home; isso não garante que todas as configurações de política funcionem em todas as edições ou builds listadas. Segundo a Sophos, Restrictions não se aplica ao Pro, e Device Guard não se aplica ao Pro nem ao Windows no modo S. Verifique no dispositivo a edição, a versão do Windows, os requisitos de hardware e as diretivas GPO/MDM efetivas; uma página antiga de ajuda não equivale a uma aprovação atual.
Ciclo de vida: O suporte da Microsoft às edições regulares do Windows 10 terminou em 14 de outubro de 2025; as edições LTSC/LTSB e os dispositivos com Extended Security Updates (ESU) elegíveis e ativadas devem ser avaliados separadamente conforme a edição e a versão. O ESU não prolonga o ciclo de vida do produto da Microsoft nem o suporte regular: fornece atualizações de segurança por tempo limitado a dispositivos elegíveis e devidamente registrados. Mesmo assim, a lista de requisitos do Sophos Mobile (versão 2026.38 de 21 de setembro de 2026) inclui Windows 10 Enterprise/Education/Pro a partir da 20H2 e Windows 11 Enterprise/Education/Pro. Trata-se de uma lista de plataformas da Sophos, não de uma garantia de suporte da Microsoft para builds antigos do Windows 10 nem de uma comprovação de funcionamento de todas as políticas do Windows. O Windows 11 também depende da versão e da edição: por exemplo, o 23H2 Pro já está fora do suporte a atualizações da Microsoft, enquanto o 23H2 Enterprise/Education tem prazos próprios. Antes do piloto, consulte o ciclo de vida da versão específica no Release Health da Microsoft e teste a configuração desejada exatamente nesse dispositivo.
Acesso e possibilidade de reversão: Organize um acesso local autorizado para recuperação, assistência disponível junto ao dispositivo e uma janela de mudança. Para o BitLocker, mantenha acessível, pelo procedimento aprovado, a Recovery Key correspondente ao dispositivo afetado e ao protetor atual, e confirme sua disponibilidade antes da alteração; não trate um registro simplesmente existente ou desatualizado como recuperação testada. Identifique primeiro quem efetivamente gerencia e onde está armazenada a BitLocker Recovery Key atual desse dispositivo (por exemplo, Fusion Device Encryption ou outro gerenciamento de chaves autorizado). O MDM do Sophos Mobile, por si só, não comprova que uma chave esteja armazenada no Fusion. Não revele uma chave de produção do Fusion por meio de Show Key apenas para verificar a prontidão. Documente as regras de senha e GPOs existentes. Para Device Guard, verifique também o estado atual de VBS/Credential Guard, além de Secure Boot e da capacidade de proteção DMA.
Grupo piloto pequeno: Não atribua a política primeiro a um grupo amplo de dispositivos. Documente o estado inicial, os usuários afetados e a alteração visível esperada. Segundo a Sophos, não há uma opção geral de reversão Uninstall policy para políticas do Windows; as configurações são corrigidas atualizando a política ou atribuindo outra. Um computador desconectado ou que não esteja sincronizando não receberá necessariamente essa correção de imediato.

Regras de senha: evitar reinicializações e contas bloqueadas

A configuração Password policies controla Maximum number of failed attempts, Time in minutes until the device is locked, Password history e Maximum password age in days.

Time in minutes until the device is locked define após quantos minutos sem uso o dispositivo é bloqueado. O usuário pode desbloqueá-lo por conta própria. Esse bloqueio por inatividade não é o limite de tentativas malsucedidas que pode provocar uma reinicialização com solicitação de recuperação do BitLocker. Maximum password age in days define após quantos dias os usuários devem alterar a senha.

Password history é a quantidade de senhas usadas anteriormente que o Sophos Mobile armazena para impedir a reutilização; uma senha nova não pode coincidir com nenhuma delas. A Sophos permite o valor 0 para tentativas malsucedidas, tempo de bloqueio e idade máxima da senha, indicando a ausência da respectiva restrição. Isso não é uma recomendação para desativar todas as proteções: escolha valores adequados ao modelo de contas e à capacidade de recuperação e teste cada um separadamente. A complexidade da senha (por exemplo, comprimento ou classes de caracteres) não pode ser configurada por essa política do Mobile; ela é determinada pelo Windows e depende, entre outros fatores, do tipo de conta. Não adote números específicos de complexidade documentados no passado como padrões universais atuais do Windows.

Se uma política de complexidade do Windows correspondente estiver ativada e em vigor para a conta afetada, a criação ou alteração da senha também poderá estar sujeita a verificações em relação ao nome da conta e a componentes do nome completo ou do nome de exibição. A aplicação e o funcionamento dessas verificações de nomes dependem da política efetiva e do tipo de conta; esclareça isso para as contas afetadas antes do piloto. Isso não estabelece uma regra universal para quaisquer caracteres consecutivos do nome nem comprova os requisitos atuais das contas Microsoft.

Antes de ativar “Maximum number of failed attempts”: Para computadores Windows, a Sophos descreve uma reinicialização com solicitação de recuperação do BitLocker quando o limite é atingido. A Microsoft esclarece que, para a regra MDM correspondente no Windows, em um computador desktop os dados não são apagados: ocorre uma solicitação de recuperação do BitLocker; sem o BitLocker ativado, a regra não pode ser aplicada. Portanto, não interprete um limite de tentativas malsucedidas nem como apagamento de dados nem como proteção efetiva em um dispositivo não criptografado. Verifique no dispositivo o estado do BitLocker e o acesso à chave de recuperação efetivamente armazenada antes da atribuição; não provoque intencionalmente falhas de autenticação em dispositivos de produção. Se houver outros usuários locais além do usuário inscrito no Sophos Mobile e pelo menos um deles não tiver permissão para alterar a própria senha, essa política de senha não poderá ser atribuída, segundo a Sophos. Avalie e corrija as permissões das contas somente em uma etapa separada e aprovada; não amplie permissões nem exclua contas às cegas para forçar a aplicação da política.

Para o piloto, primeiro identifique as contas e diretivas existentes, defina o tempo de inatividade e a idade máxima da senha de acordo com o fluxo de trabalho e confirme a prontidão da recuperação antes de configurar um limite de tentativas malsucedidas. Após a atribuição, verifique em modo somente leitura qual política está associada ao dispositivo e se o tempo de inatividade escolhido e a idade máxima da senha entram em vigor. Um teste do limite de tentativas malsucedidas deve ocorrer exclusivamente em um ambiente de teste isolado e aprovado, com a Recovery Key acessível. Diante de uma solicitação inesperada de recuperação do BitLocker, não tente novamente nem adivinhe outras chaves: identifique o dispositivo e a Key ID e siga o processo autorizado de recuperação do gerenciador de chaves efetivamente responsável; somente se o Sophos Device Encryption armazenar a chave atual será aplicável o procedimento de recuperação do Fusion.

Restrictions: avaliar previamente as consequências de cada opção

Restrictions não é uma solução geral de reforço de segurança para o Pro: a Sophos exclui expressamente o Windows Pro. A configuração inclui, entre outras opções, Forbid resetting the computer (impede a redefinição pelas Configurações e pelo Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level e Forbid manual MDM unenrollment. Impedir a redefinição ou o cancelamento manual da inscrição MDM pode bloquear um procedimento planejado de suporte ou retirada do gerenciamento. Escolha apenas uma configuração justificada por alteração no piloto e verifique seu funcionamento no dispositivo antes e depois da atribuição.

Forbid manual configuration, na seção Wi-Fi, representa um risco especial: perfis já configurados pelo usuário e perfis do Wi-Fi Sense são excluídos quando a opção é aplicada. Desmarcar a opção não recria automaticamente os perfis excluídos. Antes dessa intervenção, garanta outro acesso de gerenciamento e de rede já testado e um procedimento documentado para restaurar os perfis Wi-Fi necessários. Perfis Wi-Fi, certificados e SCEP pertencem a um processo separado de rede/certificados do Windows; sem essa garantia, não ative aqui o bloqueio da configuração de Wi-Fi.

Telemetry level designa, na lista da Sophos, os níveis Full, Enhanced, Basic e Security. O efeito real no Windows e a disponibilidade de cada nível dependem da edição atual e das políticas da Microsoft; a lista da Sophos não comprova que todos os níveis funcionem em todos os dispositivos piloto. Da mesma forma, termos históricos da interface, como Cortana ou Wi-Fi Sense, não comprovam efeito nas versões atuais do Windows.

Device Guard: escolher primeiro uma forma reversível

A configuração Device Guard da Sophos pode ativar a segurança baseada em virtualização (VBS) e o Credential Guard. Turn on virtualization-based security (VBS) é o campo específico para ativar a VBS; a seleção em Credential Guard configuration é separada. Segundo a Sophos, as configurações são aplicadas na primeira inicialização do computador Windows após a atribuição da política. Antes da atribuição, verifique o hardware e as diretivas GPO/MDM existentes e planeje uma reinicialização controlada.

Em Platform security level, a Sophos distingue duas opções:

Secure Boot utiliza os recursos de proteção compatíveis com o dispositivo. Sem Input/Output Memory Management Units (IOMMUs), a VBS utiliza o recurso Secure Boot do UEFI; com IOMMUs, utiliza Secure Boot com proteção contra acesso direto à memória (DMA).
Secure Boot and DMA protection exige Secure Boot com proteção DMA. Se o dispositivo não oferecer suporte à proteção DMA, a VBS não será ativada com essa seleção.

Verificação prévia do Credential Guard antes da atribuição: Somente se o Credential Guard for ativado no dispositivo piloto, identifique os caminhos de autenticação e acesso efetivamente usados no tenant específico: Wi-Fi ou 802.1X por cabo, VPN (especialmente PEAP/EAP-MSCHAPv2), SSO com NTLMv1, RDP/suporte remoto com credenciais do Windows armazenadas ou CredSSP e aplicativos que usam delegação irrestrita do Kerberos. A Microsoft documenta os efeitos na autenticação: Com MS-CHAP e NTLMv1, o SSO pode deixar de funcionar e uma nova autenticação manual pode ser necessária; isso não significa que esses protocolos sejam totalmente bloqueados em todos os casos. A autenticação de Wi-Fi/VPN baseada em certificados não é bloqueada por esse recurso. O cliente de Área de Trabalho Remota não consegue encaminhar credenciais do Windows armazenadas ao host de destino; o CredSSP deixa de poder utilizar credenciais armazenadas ou de SSO, mas credenciais digitadas explicitamente continuam possíveis. Já a delegação irrestrita do Kerberos é bloqueada. Verifique dependências adicionais somente se elas ocorrerem de fato no piloto: Esclareça com os responsáveis por identidade e pelos aplicativos se são necessários Kerberos PKINIT com RSA em vez de Diffie-Hellman ou Kerberos DES: o PKINIT com RSA e o DES são bloqueados pelo Credential Guard; digitar a senha novamente não resolve esses casos. Identifique também Security Support Providers/Authentication Packages (SSP/AP) personalizados ou de terceiros e aplicativos que leem credenciais do Windows armazenadas: essas integrações podem falhar, sobretudo se precisarem de hashes de senha da LSA ou de interfaces sem suporte. Para os caminhos realmente afetados, combine antes da atribuição uma alternativa compatível e um teste funcional representativo; se um caminho crítico permanecer sem esclarecimento, não atribua o Credential Guard. Avalie apenas os caminhos realmente relevantes para o dispositivo escolhido com os responsáveis por identidade e rede; antes da reinicialização, tenha à disposição um acesso de gerenciamento ou ao console local testado de forma independente e um procedimento aprovado de reversão sem bloqueio UEFI. Se a conexão normal de rede ou de suporte remoto for a única forma de acesso, não atribua ainda o Credential Guard.

Para um piloto que exija reversão remota, Credential Guard configuration: Turn on without lock é a escolha pertinente: a Sophos indica Turn off ou uma Diretiva de Grupo do Windows como forma de reversão. Turn on with UEFI lock não deve ser considerado uma opção reversível remotamente. A Sophos indica que a desativação exige presença física junto ao computador; a Microsoft documenta para isso um procedimento próprio de EFI/inicialização, com confirmação antes do boot. Não ative esse modo sem uma forma local de reversão expressamente preparada. Turn off não remove um bloqueio UEFI já estabelecido. Mesmo sem esse bloqueio, outras diretivas de gerenciamento podem sobrepor a alteração, ou o Windows já pode ativar o Credential Guard por padrão.

Compare o estado inicial e o desejado no dispositivo de teste em System Information (msinfo32.exe), em Virtualization-based Security Services Running: Credential Guard deve aparecer como em execução se sua ativação era o objetivo do piloto. O sucesso de uma tarefa de política, por si só, não comprova que o recurso esteja em execução. Após a reinicialização, use uma conta de teste autorizada no dispositivo piloto representativo para verificar as autenticações e conexões efetivamente usadas e identificadas antes (especialmente 802.1X/Wi-Fi, VPN, RDP/suporte remoto e aplicativos afetados por SSO/delegação; se existirem, também integrações PKINIT-RSA/DES e SSP/AP, além de aplicativos que leem credenciais do Windows armazenadas), bem como a forma independente de reversão; não presuma que redes e canais de suporte funcionem apenas porque o Credential Guard está em execução. Em caso de divergência, verifique primeiro a edição, Secure Boot/DMA, outras diretivas e o estado de reinicialização; não experimente alternar o bloqueio UEFI. Para reverter without lock, utilize a política do Windows preparada ou a GPO responsável, sincronize o dispositivo e confira novamente o estado após reiniciá-lo. Com with UEFI lock, interrompa a operação e utilize o processo local de recuperação da Microsoft aprovado, com acesso físico.

Não distribuir configurações de e-mail sem verificar

A ajuda do Mobile lista Email account para Exchange Online/Server e IMAP/POP como configurações do Windows. Para os marcadores %_EMAILADDRESS_% e %_USERNAME_%, os campos Exchange Login e Email Address do usuário atribuído devem estar preenchidos no Sophos Fusion. Com várias contas Exchange cujas políticas de caixa de correio sejam diferentes, o Windows só consegue aplicar uma política, segundo a Sophos; além disso, o usuário pode recusar alterações na configuração do Exchange. Campos de senha em um rascunho de política não substituem um procedimento aprovado para identidade e segredos.

Conflito importante quanto à atualidade: A Sophos descreve a configuração de e-mail do Exchange expressamente para o aplicativo Mail da Microsoft; a Microsoft encerrou o suporte ao Windows Mail/Calendar/People em 31 de dezembro de 2024 e informa que esses aplicativos não podem mais enviar nem receber e-mails ou eventos. A página da Sophos sobre IMAP/POP não indica um cliente de destino atualmente suportado; também não há comprovação de que essa configuração seja transferida para o novo Outlook. Portanto, não apresentamos aqui um procedimento de implantação em produção desse aplicativo Mail nem presumimos uma migração automática para o novo Outlook. Primeiro esclareça qual é o cliente de destino, a autenticação, a política da caixa de correio e o suporte atual no tenant específico, e faça um teste separado.

Distribuição, verificação e reversão

Depois das verificações prévias, crie em Policies > Windows, no Sophos Mobile, uma nova política destinada exclusivamente ao piloto. Antes de editar uma política existente, confira primeiro todos os dispositivos e grupos a ela atribuídos: alterações em uma política do Windows já atribuída são sincronizadas automaticamente na próxima conexão dos dispositivos e não constituem um teste em um único aparelho. Em Add configuration, acrescente somente a configuração verificada, salve e, com Assign, selecione exclusivamente o dispositivo piloto escolhido. Nas políticas do Windows, a página Schedule task descrita na interface da Sophos está disponível para políticas Android, Knox e iOS, não para Windows; não prometa aqui uma atribuição agendada para Windows. Portanto, só inicie o teste quando o responsável designado estiver pronto.

Após a atribuição, compare a visualização Policies do dispositivo afetado, o estado da tarefa e o comportamento real no dispositivo. As políticas do Windows são sincronizadas automaticamente quando o dispositivo se conecta; uma indicação na interface, por si só, não comprova o efeito local. Em caso de alteração inesperada, não ative uma segunda opção relevante à segurança: mantenha o dispositivo acessível, corrija de modo controlado apenas a política reservada ao dispositivo piloto ou atribua uma política substituta verificada, aguarde a sincronização e a reinicialização necessária e verifique novamente no próprio dispositivo. Antes de alterar uma política compartilhada também atribuída, confira as atribuições de dispositivos e grupos. Perfis Wi-Fi já removidos, um bloqueio UEFI ou uma solicitação de recuperação do BitLocker já disparada não são revertidos automaticamente por essas medidas.

Delimitação: Certificados raiz/de cliente, SCEP e perfis Wi-Fi fazem parte de um processo próprio de rede/certificados do Windows. Protetores BitLocker e o gerenciamento de Recovery Keys pertencem a Device Encryption. O modo quiosque e a inscrição do Windows têm, cada um, requisitos e procedimentos de reversão próprios; nenhuma dessas tarefas é concluída automaticamente pela política de segurança avaliada aqui.