Planear e verificar políticas de conformidade do Sophos Mobile com segurança

Uma política de conformidade não é um certificado nem um perfil de dispositivo. Avalia regras selecionadas para dispositivos inscritos e pode desencadear ações em caso de infração. O que importa é a edição efetiva do produto (Sophos Mobile ou Sophos Mobile Threat Defense), a plataforma e versão do SO, se o dispositivo é da empresa ou pessoal, o modo de inscrição/gestão, quando aplicável a aplicação Intercept X for Mobile (IXM) gerida pelo Sophos Mobile, bem como o grupo de dispositivos ao qual a política foi atribuída. A presença de uma regra ou de um modelo PCI/HIPAA não demonstra que se aplica a todos os dispositivos nem constitui uma certificação.

Antes de qualquer intervenção em produção: Check now verifica todos os dispositivos inscritos e executa as ações configuradas. Criar ou alterar uma política e atribuí-la a um grupo também não são operações apenas de leitura. Primeiro, esclarecer o conjunto completo de dispositivos afetados e a forma de reverter as alterações; não usar a frota de produção para experimentar.

O que é efetivamente avaliado?

Escolher primeiro a edição do produto e depois verificar a plataforma, o SO e o modo de inscrição: em Android Enterprise fully managed, o MDM gere todo o dispositivo; em Apple User Enrollment, os dispositivos Apple pessoais são inscritos com um âmbito de gestão limitado; supervised designa iPhones/iPads supervisionados. Uma aplicação IXM gerida pelo Sophos Mobile não comprova, por si só, uma gestão integral de dispositivos móveis (MDM). Comparar, no próprio ambiente, as regras disponíveis para a edição e o modo efetivamente utilizados; não confundir o âmbito das regras e ações do Sophos Mobile com o do Sophos Mobile Threat Defense.

As regras definem quais as funções ou estados dos dispositivos que são permitidos, proibidos ou obrigatórios. A reação a uma infração é escolhida separadamente; um critério de conformidade, por si só, não comprova que uma definição do dispositivo seja ativamente alterada ou imposta.

Para criar uma política no Sophos Mobile ou na edição autónoma Sophos Mobile Threat Defense, abrir o menu Compliance policies, clicar em Create compliance policy e selecionar o modelo Default, PCI ou HIPAA. Introduzir um nome e, opcionalmente, uma descrição; a escolha do modelo não limita as configurações posteriores. Apenas o modelo Default não tem ações predefinidas; os modelos PCI/HIPAA já podem conter ações. A Sophos descreve as regras e ações dos modelos PCI/HIPAA como baseadas em HIPAA e PCI DSS. Contudo, a ordem dos modelos e das normas na documentação é ambígua; não se deduz aqui uma correspondência entre um modelo específico e uma norma. É necessário ativar o separador da plataforma com Enable platform: sem essa seleção, não há verificação de conformidade para dispositivos dessa plataforma. Os níveis de gravidade high, medium e low estão associados de forma fixa às regras; não equivalem a uma ação de resposta escolhida livremente. No planeamento da política, ajudam a avaliar a importância de cada regra e a escolher uma resposta adequada a uma infração. Isto não autoriza a execução de uma ação durante um incidente. Na edição completa, Highlight rules ajuda a destacar um tipo de gestão, mas não comprova que uma regra produza efeitos em todos os dispositivos desse tipo.

Só depois de configurar e verificar as regras e as respetivas reações para todas as plataformas necessárias, clicar em Save. A política é assim guardada com o nome introduzido; a atribuição posterior a grupos é feita separadamente, após as verificações descritas abaixo.

Sophos Mobile (edição completa/MDM): Além das regras de gestão e de SO específicas de cada plataforma, podem estar disponíveis sinais da IXM quando o Sophos Mobile gere a aplicação. As respostas disponíveis por regra são Deny email, Lock container, Set health, Create alert e Transfer task bundle; continuam a aplicar-se os requisitos de plataforma e os pré-requisitos de cada ação.
Sophos Mobile Threat Defense (edição autónoma do produto): O seu conjunto distinto de regras abrange, entre outros, permissões da IXM no Android e deteções de malware/aplicações, filtragem Web no iOS e regras de segurança dos Chromebooks. Para esta edição, a resposta descrita é Create alert, não as ações MDM relativas a e-mail, contentor, Health ou conjuntos de tarefas.

Na edição autónoma, Installed apps e Mandatory apps aplicam-se apenas a Chromebooks. Em Installed apps, selecionar primeiro Allowed apps ou Forbidden apps e depois o grupo de aplicações com as aplicações ou extensões permitidas ou proibidas, respetivamente. Em Mandatory apps, selecionar o grupo de aplicações com as aplicações ou extensões que têm de estar instaladas. As correspondências para Android, iOS e Mac descritas mais abaixo, bem como as indicações sobre aplicações do sistema e atualizações de aplicações Android, pertencem ao catálogo geral da edição completa Sophos Mobile, não a estas duas regras da edição autónoma Threat Defense.

O catálogo separado Mobile Threat Defense compliance rules, dentro da ajuda do Sophos Mobile, descreve um subconjunto de regras para dispositivos Android/iOS cuja aplicação IXM é gerida pelo Sophos Mobile: por exemplo, root/jailbreak, limites do SO, sincronização da IXM e análises de aplicações Android. Uma aplicação gerida, por si só, não comprova a gestão MDM integral do dispositivo; este subconjunto também não é o catálogo de regras da edição autónoma Sophos Mobile Threat Defense. No Android, a regra Intercept X for Mobile permissions can be denied define se a recusa de permissões da aplicação IXM torna o dispositivo não conforme. Pode assinalar como infração a falha do Web Filtering quando o Accessibility Service é recusado; a Sophos recomenda o valor No quando se utiliza Web Filtering. A regra iOS Web Filtering turned on consta do catálogo geral de regras do Sophos Mobile e do catálogo da edição autónoma Threat Defense, não do referido subconjunto IXM. Exige que a função Web Filtering do Intercept X for Mobile esteja ativada nos iPhones e iPads; trata-se de um critério próprio, não da regra de permissões do Android. As regras para Chromebooks não são automaticamente regras para Android/iOS.

O subconjunto IXM gerido está documentado nas duas ajudas, para Sophos Mobile e para Sophos Mobile Threat Defense. Para dispositivos cuja aplicação IXM é gerida pelo Sophos Mobile, indica as seguintes correspondências:

Managed required aplica-se a Android e iOS. A regra define a reação quando um dispositivo deixa de ser gerido. Não equivale a Device administrator management allowed nem comprova uma gestão MDM integral.
Minimum OS version e Maximum OS version aplicam-se, neste subconjunto, a Android e iOS. Definem a versão mínima exigida e a versão máxima permitida do SO, respetivamente. A ausência de uma lista de plataformas no catálogo geral mais abaixo não altera esta correspondência.
Malware apps allowed aplica-se aqui apenas a Android. Esta regra define se são permitidas aplicações maliciosas detetadas pela IXM.
PUAs allowed aplica-se aqui apenas a Android. Esta regra define se são permitidas aplicações potencialmente indesejadas detetadas pela IXM.

As duas regras de aplicações avaliam a conformidade. Não são definições de análise nem uma autorização para desbloquear aplicações detetadas ou excluí-las de análises futuras. As consequências das deteções e as exceções são verificadas separadamente no procedimento de resposta a um incidente de conformidade ligado abaixo.

Uma regra Maximum interval between … synchronizations é uma regra de conformidade configurável para a respetiva fonte de sincronização: o software MDM nativo do sistema operativo, Sophos Mobile Control, IXM ou Sophos Chrome Security. No catálogo geral, aplica-se a seguinte correspondência:

Native MDM: iPhones/iPads sem Sophos Mobile Control ou IXM, bem como Macs e computadores Windows.
SMC (Sophos Mobile Control): Dispositivos Android e iPhones/iPads.
Intercept X for Mobile: Dispositivos Android e iPhones/iPads.
Sophos Chrome Security: Chromebooks.

Cada uma destas regras limita o intervalo máximo permitido entre sincronizações do respetivo agente com o Sophos Fusion; não trocar os agentes nem os valores de tempo entre regras. Em contrapartida, Maximum interval between Intercept X for Mobile scans limita, no Android, o intervalo entre análises de malware da IXM, não entre sincronizações. Um limite ultrapassado só pode ser avaliado à luz da regra efetivamente ativada e infringida e da hora da respetiva sincronização ou análise. Separadamente, uma sincronização atrasada ou falhada pode tornar desatualizado o estado de conformidade apresentado; por si só, não comprova uma infração nem a conformidade. Um estado desconhecido para o EAS Proxy constitui outro caso, no fluxo de quarentena do Exchange configurado separadamente, e não é automaticamente uma infração da regra de intervalo máximo.

Selecionar regras conforme a tarefa de verificação

Os grupos seguintes organizam o catálogo geral de regras da edição completa Sophos Mobile para efeitos de planeamento. Não constituem uma lista de valores predefinidos recomendados. Primeiro, confirmar a edição e o modo de gestão, depois selecionar apenas os critérios adequados e verificar separadamente a reação de cada regra.

Estado de gestão, versões e atualizações

Managed required / Device administrator management allowed: A primeira regra diz respeito a dispositivos que deixaram de ser geridos; a segunda define as ações para dispositivos Android nos quais o próprio Sophos Mobile é utilizado como Device Administrator. Este modo de gestão do Sophos Mobile está obsoleto e só está disponível para Android 9 ou anterior; não pode ser utilizado com Android 10 ou posterior. A Sophos recomenda migrar os dispositivos neste modo para Android Enterprise. Trata-se de um limite do modo de gestão do Sophos Mobile aqui descrito, não de uma afirmação de que as APIs Android Device Administrator tenham sido removidas em geral, nem de instruções para inscrever novos dispositivos nesse modo.
Minimum SMC version: Versão mínima permitida da aplicação Sophos Mobile Control, para Android e iPhones/iPads. Não confundir com a versão da IXM ou do SO.
Minimum OS version / Maximum OS version: Versão mínima ou máxima permitida do sistema operativo, respetivamente. O catálogo não apresenta uma lista específica de plataformas para estas duas entradas; verificar a disponibilidade no separador da respetiva plataforma.
Mandatory OS updates: Aplica-se a iPhones/iPads supervisionados, não ao Apple User Enrollment. Latest available update exige a atualização mais recente disponível; Latest critical update, a atualização mais recente classificada como crítica pela Apple. A atualização mais recente disponível pode ser posterior à atualização crítica mais recente. Latest critical update não está disponível a partir do iOS/iPadOS 27. Para gerir as atualizações destes dispositivos, a Sophos indica uma política declarativa com Software update settings ou Enforced software update; não inferir daí que a seleção de conformidade anterior mantém o mesmo efeito. Software update settings requer iOS/iPadOS 26 ou posterior, o modo de gestão Apple Device Enrollment e um dispositivo supervisionado. Para Enforced software update, a Sophos indica como pré-requisitos iOS/iPadOS 26 ou posterior e Apple Device Enrollment, mas não um requisito adicional de supervisão. Esta versão mínima 26 é distinta do limite 27 da opção anterior Latest critical update.

As informações sobre atualizações Apple requerem um percurso de rede próprio: Para obter informações sobre atualizações disponíveis em iPhone, iPad e Mac, mesu.apple.com tem de estar acessível através de HTTPS 443. Se este destino não estiver acessível, o Sophos Mobile não dispõe de informações sobre atualizações; nesse caso, as regras de conformidade relativas a atualizações obrigatórias não produzem efeito. Verificar o percurso efetivo com a administração de rede antes de considerar fiável o estado de uma regra desse tipo. Isto não alarga os limites de plataforma, SO ou inscrição de Mandatory OS updates indicados acima, nem afirma que todas as instalações de atualizações Apple falham.

Proteção do dispositivo e separação dos dados de trabalho

Root access allowed (Android): Definir se são permitidos dispositivos com privilégios de root. A permissão documentada também abrange dispositivos Sony com Enterprise API Level 4 ou posterior e dispositivos Samsung com Knox Standard SDK 5.5 (API Level 17) ou anterior classificados como inseguros pelo sistema operativo. Trata-se de qualificações históricas da ajuda da regra, não de uma recomendação para utilizar esses dispositivos atualmente.
Android Debug Bridge (ADB) allowed (Android): Definir se a interface de depuração ADB é permitida ou proibida.
Allow jailbreak (iPhone/iPad): Definir separadamente se são permitidos dispositivos com jailbreak; não transpor a regra de root do Android.
Screen lock required (Android, iPhone/iPad, Windows): Definir se é obrigatória uma palavra-passe do dispositivo ou outro mecanismo de bloqueio. No Android, são válidos Pattern, PIN e Password, mas não Swipe. No Apple User Enrollment, a regra é cumprida se a política atribuída incluir uma configuração Password policies.
Encryption required (Android, Mac, Windows): Exigir encriptação; no macOS, a regra refere-se à encriptação integral com FileVault. Segundo a ajuda da regra, os iPhones e iPads estão sempre encriptados e não constam da lista de aplicabilidade desta regra.
Container configured (Android): Tem de existir um contentor configurado e ativado, por exemplo, um perfil de trabalho Android ou um contentor Samsung Knox. Trata-se de um critério de estado, não da reação Lock container.
Data roaming allowed: Permitir ou proibir o roaming de dados, para Android e iPhones/iPads sem Apple User Enrollment.

Não corrigir indiscriminadamente a encriptação do Android: A ajuda atual da regra Encryption required para Android ainda refere Require PIN to start device ou Require Password to start device ao configurar um bloqueio de ecrã. Isso não demonstra que a opção de PIN/palavra-passe no arranque esteja disponível nas versões atuais do Android ou em todos os modos Android Enterprise. A KBA-000004067, em separado, descreve uma falha com a chave de encriptação padrão apresentada e aponta o PIN de arranque e a sincronização manual como solução, sem especificar a versão do SO ou o modo de inscrição; não é uma solução universal para versões atuais do Android ou modos Android Enterprise. Antes de qualquer intervenção num dispositivo, esclarecer a falha efetivamente observada, a versão do SO suportada e o modo de inscrição; não recomendar indiscriminadamente alterar o PIN ou usar Synchronize now.

Aplicações, perfis e permissões

Installed apps: Selecionar primeiro Allowed apps ou Forbidden apps e depois o grupo de aplicações com as aplicações permitidas ou proibidas, respetivamente. Aplica-se a Android, iPhones/iPads sem Apple User Enrollment, Macs e Chromebooks. As aplicações do sistema Android são sempre permitidas; os grupos de aplicações Chrome OS podem conter aplicações e extensões.
Mandatory apps: Selecionar na lista o grupo de aplicações cujas aplicações têm de estar instaladas. Os grupos Chrome OS também podem conter extensões. Em Mandatory apps no iOS, não incluir aplicações do sistema entre as obrigatórias: o Sophos Mobile não consegue detetar a sua instalação e, segundo a ajuda da regra, marca todos os dispositivos afetados como não conformes. Para Android, a Sophos descreve em SMCAND-3159 que as atualizações de aplicações em paralelo durante uma sincronização da aplicação Control com o backend do Mobile podem fazer o estado passar brevemente a não conforme e depois voltar a conforme, sobretudo em dispositivos mais antigos. Para avaliar a situação apenas por leitura, comparar a regra efetivamente infringida, os momentos das atualizações e da sincronização e o estado observado posteriormente. Isto não justifica tornar menos exigente a regra de aplicações obrigatórias. Não inferir de um estado conforme posterior que o funcionamento não teve consequências nem que o acesso às aplicações, ao correio ou ao Wireless foi restabelecido; o regresso automático à conformidade documentado não é um resultado observado aqui nem implica um prazo garantido.
Suspicious apps allowed (Android): Definir se são permitidas aplicações suspeitas detetadas pela IXM. Trata-se de uma seleção de conformidade própria, não automaticamente equivalente às definições de análise de aplicações com baixa reputação.
Third-party profiles allowed (iPhone/iPad, sem Apple User Enrollment): Definir se são permitidos perfis de configuração não geridos pelo Sophos Mobile.
Unmanaged apps from unknown sources allowed (iPhone/iPad): Definir se são permitidas aplicações desenvolvidas internamente, instaladas manualmente através de um ficheiro IPA e assinadas com um perfil de aprovisionamento ad hoc. Não equiparar à regra dos Chromebooks para aplicações fora da Chrome Web Store.
SMC permissions can be denied (Android): A aplicação Control necessita de permissões para funcionar, que têm de ser concedidas durante a instalação. A regra define se a sua recusa desencadeia uma infração de conformidade. Trata-se de uma aplicação diferente da referida em Intercept X for Mobile permissions can be denied acima.
Locate permission required (Android): Para a função Locate, definir se a permissão da aplicação Control para obter dados de localização, concedida durante a instalação, é necessária para a conformidade.
App is able to locate (iPhone/iPad): Os serviços de localização têm de estar ativados e a aplicação Control tem de ter permissão para os utilizar. Esta combinação é distinta do critério de instalação do Android. Nenhuma das regras de localização concede autorização organizacional ou legal para recolher dados de localização.

Verificar especificamente Chromebook, Mac e Windows

Chromebooks: As regras seguintes dizem respeito ao Sophos Chrome Security, não à aplicação Control do Android:

Tamper protection turned off: Selecionar as reações para o caso de a Chrome Security policy ter sido adulterada.
Minimum Sophos Chrome Security version: Definir a versão mínima permitida da extensão Chrome Security.
Apps from unknown sources allowed: Definir se são permitidas aplicações e extensões fora da Chrome Web Store.

Macs: Os critérios dizem respeito à ativação da respetiva proteção, não comprovam que a própria regra de conformidade a ative:

Firewall required: A firewall do macOS tem de estar ativada.
System Integrity Protection required: SIP tem de estar ativada. Esta função de proteção do macOS limita as ações do utilizador root; é possível configurá-la ao arrancar a partir de macOS Recovery. Isto não concede autorização para alterar SIP durante o funcionamento normal.
Security updates required: A instalação automática de atualizações de segurança do macOS tem de estar ativada. A ajuda da regra limita este requisito ao macOS 26 (Tahoe) ou anterior; este limite não é o limite do iOS/iPadOS 27 da regra de atualizações para dispositivos móveis.

Computadores Windows: Selecionar três critérios distintos do Defender, sem os inferir a partir de um único estado:

Windows Defender must be turned on: A proteção em tempo real do Windows Defender tem de estar ativada. Este critério mantém-se como requisito pretendido. Contudo, para Windows 10, a Sophos descreve em SMCSRV-13801 uma limitação da verificação: a regra verifica apenas se o serviço Defender está em execução, não se a proteção em tempo real está ativada. Por isso, um dispositivo pode aparecer como conforme mesmo com a proteção desativada. Antes de confiar na proteção, verificar separadamente, e apenas por leitura, se a proteção em tempo real está efetivamente ativada no dispositivo Windows 10 em causa, sem alterar os controlos de ativação da proteção nem as políticas. Um serviço em execução e o estado de conformidade não substituem esta verificação no dispositivo.
Clean status from Windows Defender required: O dispositivo não está conforme se o Windows Defender apresentar avisos.
Up-to-date Windows Defender definitions required: O Windows Defender tem de utilizar as definições de spyware mais recentes.

Não confundir as reações com a regra

Create alert cria, na edição completa, um evento visível na página de detalhes do dispositivo e um alerta; o Threat Defense descreve alertas no Sophos Fusion. Um alerta não é um bloqueio configurado de e-mail ou de contentor. No entanto, selecionar apenas Create alert não garante que a Health do dispositivo ou o acesso Wireless se mantenham inalterados; também podem ocorrer outras consequências da não conformidade.
Deny email é uma reação configurada a uma regra da política infringida na edição completa; requer uma ligação configurada ao Sophos Mobile EAS Proxy e destina-se a Android, iPhone/iPad e Windows. A mera existência de um EAS Proxy não comprova a autenticação do serviço de correio em causa nem a interrupção ou reposição efetiva da entrega. Separadamente, a Sophos descreve uma quarentena do Exchange para dispositivos não inscritos apenas com o EAS Proxy em modo PowerShell e a regra de acesso predefinida do Exchange configurada em conformidade. Nesse caso, dispositivos inscritos também podem ficar em quarentena se o proxy desconhecer o seu estado de conformidade por causa de uma sincronização demasiado antiga ou da ausência de ligação ao Sophos Mobile. A notificação de inscrição enviada pelo Exchange no fluxo de quarentena não é Create alert nem comprova que Deny email tenha sido acionado. Não inferir uma quarentena generalizada ou a reposição automática do correio a partir de uma infração de regra ou de um alerta; a investigação pertence à resposta a incidentes, não a este planeamento de políticas.
Lock container está previsto na edição completa atual para Android Enterprise, não como um bloqueio comprovado do contentor iOS. A tabela geral de ações de conformidade da edição completa descreve esta ação configurada como o bloqueio de todas as aplicações exceto Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages e Phone. Esta descrição geral não especifica o efeito nas aplicações do perfil pessoal BYOD; nem as seis exceções nem o exemplo do perfil de trabalho abaixo comprovam que as aplicações pessoais continuem acessíveis. Para um perfil de trabalho Android suportado, a Sophos documenta, no controlo de acesso separado, Auto (predefinição sem permissão de acesso manual: o perfil de trabalho é bloqueado se uma regra de conformidade infringida incluir Lock container), Deny (perfil de trabalho bloqueado) e Allow (perfil de trabalho desbloqueado). Quando bloqueado, não é possível aceder às aplicações e aos dados do perfil de trabalho; a definição só é aplicada depois da sincronização do dispositivo. Este controlo de acesso ao perfil de trabalho é distinto do comando de bloqueio de todo o dispositivo; não comprova o efeito da ação de conformidade configurada nas aplicações pessoais, nem a sua disponibilidade em todos os cenários BYOD/de inscrição, nem um caminho de reversão testado. Verificar o âmbito e o efeito num dispositivo de teste autorizado antes da aprovação.
Distinguir Set health da Health calculada: Set health é uma ação expressamente selecionada por regra na edição completa: quando essa regra é infringida, atribui-se o valor escolhido Vermelho/Amarelo/Verde; se várias regras forem infringidas, prevalece o pior valor de Health atribuído. Para Android, iPhone e iPad, a ação requer Synchronized Security ativada; para produzir o efeito pretendido no Wireless, é ainda necessário configurar na política o valor de Health para não conformidade e as regras Wireless. Em separado, o Fusion apresenta uma Health do dispositivo baseada em infrações de regras de conformidade; com Synchronized Security ativada, esta pode ser substituída manualmente, enquanto Auto retoma o cálculo a partir do estado de conformidade. Não está esclarecido qual o valor resultante sem a ação Set health em cada edição e modo, nem como se estabelece a prioridade entre uma substituição manual e uma ação de regra simultânea; não inferir uma atribuição automática de Vermelho/Amarelo nem uma Health inalterada a partir de Create alert. Verificar separadamente a regra infringida/não conformidade, a ação Set health guardada, a Health apresentada e o estado manual/Auto, o valor comunicado ao Wireless e o acesso efetivo. O Sophos Wireless pode limitar o acesso à rede consoante a configuração; a indicação na consola, por si só, não comprova um efeito específico no Wireless.
Transfer task bundle pode provocar configurações incorretas nos dispositivos ou até apagá-los. Não definir tarefas de wipe/reset nem conjuntos automáticos de tarefas como reação padrão; aqui, None significa apenas que não é transferido nenhum conjunto de tarefas, não que a não conformidade deixe de ter consequências.

Caso especial: Na edição completa, todas as aplicações de um dispositivo Android Enterprise fully managed não conforme são automaticamente desativadas, independentemente da reação escolhida por regra. Isto não equivale à ação configurável Lock container nem é um efeito comprovado para dispositivos Android BYOD/com perfil de trabalho, apenas MTD ou outros modos Android. No Android BYOD, o efeito de Lock container depende do modo de gestão efetivamente suportado e da configuração; não inferir o bloqueio do dispositivo a partir de um eventual bloqueio do espaço de trabalho. Verificar num dispositivo de teste autorizado o acesso ao telefone, ao espaço de trabalho, aos mecanismos de recuperação e às aplicações críticas antes de qualquer aprovação.

Synchronized Security não está disponível para todos os dispositivos: A Sophos exclui Chromebooks, Apple User Enrollment e dispositivos com endereços MAC específicos da rede/privados ou aleatórios, porque não comunicam o seu endereço MAC ao Sophos Mobile. A possibilidade separada de transmitir o endereço MAC através da configuração da aplicação IXM com um EMM de terceiros não comprova uma exceção para endereços MAC privados/aleatórios. Planear um piloto Wireless apenas para um modo de dispositivo/inscrição efetivamente suportado, com a configuração MAC e Synchronized Security verificada; uma indicação de Health, por si só, não substitui um teste de acesso.

Atribuir por etapas em vez de testar globalmente

Inventariar dispositivos e pré-requisitos: Registar o ambiente, a licença/edição, o modo de gestão, a plataforma/SO, a titularidade, o estado de gestão da IXM, a última sincronização, as regras existentes e as dependências ativas do EAS Proxy e do Sophos Wireless. Documentar a elegibilidade para Synchronized Security e os limites MAC, a Health do dispositivo apresentada e o estado manual/Auto, as regras Wireless existentes, bem como as políticas e atribuições.
Avaliar cada regra e ação: Abrir o catálogo de regras atual da edição correta do produto; para cada plataforma ativada, inventariar todas as regras herdadas do modelo ou definidas manualmente, com a respetiva reação. Verificar o sinal, o modo e os pré-requisitos da ação antes de Save e da atribuição; não presumir que PCI/HIPAA são passivos. Para um piloto aprovado, planear uma nova política isolada sem ações de bloqueio ou destrutivas e voltar a verificar as ações efetivamente guardadas. A ausência de Set health não comprova que a Health calculada/manual ou o acesso Wireless permaneçam inalterados. Importante: Mesmo Create alert isoladamente ou None num conjunto de tarefas não impede a desativação automática documentada das aplicações num dispositivo Android Enterprise fully managed não conforme. Excluir esses dispositivos deste piloto até que um teste específico do acesso às aplicações e dos mecanismos de recuperação seja autorizado e preparado para a versão e o modo efetivos.
Selecionar um grupo-piloto limitado: Considerar separadamente os dispositivos da empresa e os pessoais previstos. Se o piloto aprovado exigir um novo grupo, primeiro preparar o grupo de dispositivos e confirmar o seu âmbito. Se forem geridos ambos os tipos de titularidade, a Sophos recomenda políticas de conformidade distintas para dispositivos da empresa e pessoais; a existência de dois campos de atribuição separados, por si só, não significa que sejam utilizadas políticas diferentes. Em Device groups > [Grupo] > Compliance policies, as políticas para corporate e personal são atribuídas separadamente. Antes de Save, verificar, para cada dispositivo visado, o seu único grupo de dispositivos atual (incluindo o grupo Default existente, se estiver atribuído), o tipo de titularidade (corporate/personal) e a atribuição de política desse grupo, para detetar um alcance não pretendido. Depois de selecionar as políticas para corporate e personal e verificar o alcance, clicar em Save para guardar a atribuição ao grupo. Em seguida, na página Device groups, comparar ambas as colunas Compliance policy (corporate) e Compliance policy (personal) do grupo escolhido com a atribuição planeada. Antes de alterar uma política existente e partilhada, verificar todos os grupos aos quais essa política está atribuída; a alteração pode afetar outros grupos, não por um dispositivo pertencer a vários grupos. Um novo piloto isolado não deve alterar silenciosamente uma política partilhada.
Verificar o efeito no piloto autorizado: Antes de provocar intencionalmente uma infração, voltar a confirmar que o piloto apenas com alertas/sem ações não inclui nenhum dispositivo Android Enterprise fully managed; Create alert ou None não protege as suas aplicações. Comparar primeiro a atribuição ao grupo e o dispositivo concreto, incluindo o novo valor de conformidade, a regra infringida, a hora da sincronização e, se aplicável, o alerta/evento. No dispositivo de teste suportado, observar separadamente, antes e depois da infração, a ação Set health efetivamente guardada, a Health apresentada e o modo manual/Auto, bem como, se Synchronized Security estiver ativada, a Health comunicada, a regra Wireless e o acesso Wireless efetivo; verificar também o fluxo de correio e o acesso às aplicações quando a configuração for relevante. Mesmo sem uma ação Set health, não presumir que o acesso à rede permanece inalterado; não interpretar uma sincronização atrasada ou ausente como conformidade. Testar uma infração intencional apenas com reversão confirmada e sem colocar dados de produção em risco. Antes de alargar o âmbito aos dispositivos Android Enterprise totalmente geridos, verificar primeiro num dispositivo autorizado se a consequência automática documentada ocorre na versão e modo efetivos e se a reversão funciona.
Alargar apenas após aprovação: Comparar os dispositivos afetados e as infrações inesperadas com a situação inicial. Em caso de desvios, parar o alargamento, repor após autorização a anterior atribuição ao grupo/configuração de regras e ações documentada e verificar novamente a recuperação no dispositivo e nos serviços externos. Remover uma regra não reverte automaticamente conjuntos de tarefas já executados, apagamentos ou bloqueios de acesso externos.

Não usar como teste: Compliance policies > Check now abrange todos os dispositivos inscritos e executa as ações aí configuradas, mesmo que só se pretendesse abranger um grupo pequeno. Antes de uma verificação global planeada, é necessário rever todos os grupos e reações e obter aprovação da alteração; este artigo não autoriza premir esse botão no ambiente de produção.

Apenas exemplo de planeamento, não testado: Um grupo expressamente aprovado com um iPhone da empresa (sem Apple User Enrollment e sem Android Enterprise fully managed), uma regra não destrutiva cuja aplicabilidade tenha sido previamente verificada e Create alert poderia servir como piloto limitado. Antes da atribuição, registar todos os pares regra/ação, as associações a grupos e, se o Wireless fizer parte do teste, a elegibilidade para Synchronized Security e a configuração MAC e Wireless. Perante uma infração de teste autorizada e reversível, verificar, na edição completa Sophos Mobile, a infração/não conformidade e o evento na página de detalhes do dispositivo na consola, bem como o alerta na consola; na edição autónoma Sophos Mobile Threat Defense, verificar o alerta na página Alerts do Sophos Fusion. Separadamente, antes e depois da sincronização, observar a Health apresentada (manual/Auto) e verificar no dispositivo visado o fluxo efetivo de correio, o acesso às aplicações e o acesso Wireless efetivo; não esperar que o alerta apareça no próprio dispositivo físico. Não presumir que a Health ou a rede permanecem inalteradas só por se usar Create alert. Parar se outros dispositivos forem afetados, se a sincronização não ocorrer ou se a Health/o acesso diferirem inesperadamente; não alargar o âmbito, repor a atribuição anterior após autorização e voltar a verificar o efeito. Trata-se de um plano de verificação, não de um resultado de teste observado.

Limites e pré-requisitos de utilização

A investigação de um dispositivo já sinalizado ou bloqueado, a triagem de alertas, o tratamento de falsos positivos e a reposição do acesso ao e-mail/Wireless não fazem parte destas instruções de planeamento de políticas. Estas não substituem instruções de resposta a incidentes ou de reposição. Uma medida relativa ao PIN de arranque do Android ou uma sincronização manual indicada na KBA-000004067 não constitui uma correção geral sem verificar o erro concreto e a combinação suportada de dispositivo/modo de inscrição. Para a triagem inicial só de leitura e a verificação do acesso Wi-Fi, consultar as instruções sobre a resposta a um incidente de conformidade; estas também não concedem autorização operacional.

Os procedimentos descritos não foram validados em dispositivos nem num tenant. Este artigo não concede autorização operacional. A relação entre a ação Set health selecionada, a Health calculada automaticamente/substituída manualmente e o efeito no Wireless não está aqui esclarecida para todos os modos. As combinações de regras/ações por edição do produto, SO e modo, bem como as formas de repor o acesso EAS/Wireless e às aplicações Android, têm de ser autorizadas e verificadas em cada dispositivo antes da adoção operacional.