Como Estruturar Políticas de Segurança para Dispositivos Android, iOS e Windows

Política de segurança igual para Android, iOS e Windows. Parece eficiente. Na prática: cobertura parcial em todos os três. Cada OS tem suas exigências específicas. Uma abordagem por camadas resolve — e este guia mostra como estruturar.

1. Por que políticas únicas falham em ambientes multi-OS

Empresas que gerenciam múltiplos sistemas operacionais frequentemente cometem o erro de criar uma política de segurança genérica e aplicar para todos os dispositivos. O resultado é uma política que não é rigorosa o suficiente para nenhum dos sistemas — porque o mínimo comum denominador entre Android, iOS e Windows é muito baixo.

As diferenças que importam para a segurança:

• Android tem modelo de permissão de apps muito mais granular que iOS — a política de controle de permissões precisa ser específica
• iOS tem criptografia de dados gerenciada diferente do Android — as verificações de conformidade são diferentes
• Windows tem superfície de ataque muito maior que mobile — BitLocker, privilégios locais e patch management precisam de políticas próprias
• Cada OS tem suas APIs de MDM específicas — uma política configurada para Android simplesmente não se aplica ao Windows

2. Framework de políticas por camada

A abordagem correta para ambientes multi-OS é definir políticas em camadas — uma camada base comum e camadas específicas por OS:

Camada	O que define
Camada 1 — Base	Princípios universais: criptografia obrigatória, senha mínima, wipe remoto habilitado, dispositivos devem estar registrados no MDM
Camada 2 — Por OS	Configurações específicas de cada sistema operacional: Work Profile (Android), User Enrollment (iOS), BitLocker + Defender (Windows)
Camada 3 — Por grupo	Configurações por função: operador de campo tem política diferente de executivo, que tem política diferente de desenvolvedor
Camada 4 — Por risco	Políticas baseadas em contexto de risco: acesso a dados sensíveis (financeiro, saúde, PII) exige controles adicionais

3. Políticas essenciais para Android corporativo

Senha e autenticação

• Comprimento mínimo: 8 caracteres (alfanumérico para gestores, PIN de 6 para operadores de campo)
• Bloqueio de tela automático: 2 minutos de inatividade (reduzir para 30 segundos em ambientes de alto risco)
• Máximo de tentativas: 5 tentativas antes de wipe automático (COBO) ou bloqueio com PIN de admin (COPE/BYOD)

Criptografia e proteção de dados

• Criptografia de disco: verificar que está ativa (padrão no Android 6+ com PIN configurado, mas confirmar no MDM)
• Work Profile obrigatório para BYOD: dados corporativos isolados dos pessoais
• Prevenção de cópia de dados corporativos: desabilitar cópia/cola entre Work Profile e perfil pessoal (configuração Android Enterprise)

Controle de apps

• Managed Google Play habilitado: apenas apps aprovados disponíveis
• Instalação de apps de fontes desconhecidas (APK) bloqueada
• Google Play Protect ativo e não pode ser desabilitado pelo usuário
• Verificação periódica de apps: MDM escaneia apps instalados contra lista de risco

Redes e conectividade

• VPN corporativa configurada (obrigatória ou sob demanda para acesso a sistemas internos)
• Redes Wi-Fi corporativas pré-configuradas via MDM
• Bluetooth restrito (opcional, dependendo da operação)

4. Políticas para iOS

Senha e autenticação

• Comprimento mínimo: 6 dígitos numéricos (ou alfanumérico — mais seguro mas maior resistência do usuário)
• Touch ID / Face ID: habilitado como segunda camada, mas não substitui PIN
• Histórico de senhas: últimas 5 senhas não podem ser reutilizadas

Restrições específicas de iOS

• AirDrop: desabilitado para dados gerenciados (documentes corporativos não podem ser enviados via AirDrop)
• iCloud Backup de dados gerenciados: desabilitado — backup corporativo não deve ir para iCloud pessoal
• Captura de tela: pode ser restrita para apps corporativos específicos (disponível via API de gerenciamento de conteúdo)
• Instalação de apps fora da App Store: desabilitada (sideloading)

Managed Open-In

Controle de para onde documentos corporativos podem ser ‘abertos’ — um PDF do app de email corporativo não pode ser aberto no app de notas pessoais. Configurado via política de Managed Open-In do iOS MDM.

5. Políticas para Windows

Criptografia

• BitLocker obrigatório em todos os endpoints Windows Pro/Enterprise
• Chave de recuperação do BitLocker em escrow no MDM (não no Azure AD apenas)
• Verificação de status do BitLocker no relatório de conformidade

Proteção de endpoint

• Windows Defender ativo, atualizado e com definições em no máximo 24 horas de atraso
• Firewall do Windows ativo em todos os perfis de rede (domínio, privado, público)
• SmartScreen ativo para proteger contra downloads de fontes não confiáveis

Controle de privilégios

• Usuários sem privilégio de administrador local como padrão
• Elevação de privilégio controlada: apenas para tarefas específicas aprovadas pela TI
• Controle de aplicativos (AppLocker ou Windows Defender Application Control): apenas apps aprovados podem executar em ambientes de alto risco

Patch management

• Windows Update for Business configurado via MDM
• Anéis de atualização por grupo: piloto (imediato), usuários gerais (7 dias), missão crítica (14 dias)
• Patches de segurança críticos: sem possibilidade de adiamento

6. Como sincronizar políticas sem criar inconsistência entre plataformas

A inconsistência mais comum em ambientes multi-OS: senha de 8 caracteres obrigatória no Windows, mas PIN de 4 dígitos aceito no Android do mesmo colaborador. Isso cria uma percepção de que a segurança não é levada a sério — e um atacante que obtém acesso ao celular pode usar essa brecha.

Princípio de equivalência funcional: a política de senha deve ter nível de segurança equivalente em todos os OS, mesmo que a forma de configuração seja diferente. 8 caracteres alfanuméricos no Windows = PIN de 6 dígitos no Android = senha de 6 dígitos no iOS. Equivalente em prática, não idêntica na configuração.

7. FAQ

É possível aplicar a mesma política MDM para Android e iOS simultaneamente?

Não diretamente — cada OS tem suas APIs específicas. O MDM permite criar perfis de política separados para Android e iOS com configurações equivalentes. O resultado operacional é o mesmo (dispositivos com nível de segurança equivalente), mas as configurações técnicas são necessariamente diferentes.

Como auditar se as políticas estão sendo aplicadas corretamente?

O MDM gera relatórios de conformidade por dispositivo: lista de políticas esperadas vs políticas aplicadas. Dispositivos fora de conformidade aparecem com indicador de ‘não conforme’ e detalhe do que está diferente. Esses relatórios podem ser exportados para auditorias de segurança e compliance.

O que fazer com dispositivos que não conseguem aplicar uma política específica (hardware incompatível)?

Definir política de exceção com justificativa documentada. Por exemplo: dispositivos Android 9 que não suportam algumas APIs de Work Profile recebem política alternativa equivalente mais básica. A exceção fica registrada no MDM com data de revisão — para garantir que o dispositivo seja atualizado ou substituído antes da próxima auditoria.

Preciso de MDM diferente para Android, iOS e Windows?

Não — MDMs modernos como a Urmobo gerenciam Android, iOS e Windows na mesma plataforma e console. Um único agente por OS, uma única console de administração, um único relatório de conformidade unificado. Isso é exatamente o que define UEM (Unified Endpoint Management).

→ Veja como a Urmobo gerencia Android, iOS e Windows em uma plataforma: urmobo.com.br/funcionalidades