Pronto para ler este conteúdo em voz alta.
Resumo executivo
Este estudo de caso documenta a extensão da estratégia de gerenciamento de endpoints da organização para celulares Android corporativos.
O objetivo não era apenas instalar aplicativos remotamente. O aparelho precisava entrar em um ciclo de vida administrado desde a configuração inicial: enrollment, associação ao colaborador, restrições, distribuição de software, proteção contra ameaças, ações remotas e, posteriormente, avaliação de conformidade para acesso a recursos corporativos.
Como os celulares pertencem à organização, são destinados a um único colaborador e não devem funcionar como dispositivos pessoais, o modelo escolhido foi Android Enterprise Corporate-owned, fully managed.
A implementação real permanece privada. Identificadores internos, URLs, chaves, QR Codes operacionais, nomes de grupos e parâmetros específicos dos sistemas corporativos foram omitidos ou generalizados.
Meu papel
Conduzi a validação do modelo Android Enterprise, o desenho do enrollment, as políticas de restrição, a distribuição de aplicativos, a configuração do Microsoft Launcher e a integração do Microsoft Defender ao fluxo de segurança móvel.
A parte mais relevante do trabalho foi transformar resultados de laboratório em um processo de onboarding suportável. Isso exigiu separar o que o Intune realmente consegue impor de forma centralizada daquilo que ainda depende do fabricante, do aplicativo ou de uma ação local da TI e do usuário.
Este case é uma extensão do estudo maior De Active Directory On-Premises ao Microsoft 365: Identidade, E-mail e Endpoints em 4 Meses, mas mantém o foco apenas no gerenciamento Android.
Por que Corporate-owned, fully managed
O requisito era administrar celulares pertencentes à empresa, utilizados individualmente por colaboradores e destinados ao trabalho.
Nesse cenário, permitir um perfil pessoal independente criaria uma fronteira desnecessária entre a TI e um ativo que continua pertencendo à organização. O modelo Fully Managed foi adotado justamente para que configurações administrativas, aplicativos corporativos, contas, requisitos de segurança e ações de manutenção permaneçam sob controle da empresa.
A integração com o Managed Google Play fornece o catálogo de aplicativos Android Enterprise, sem exigir que o colaborador utilize uma conta pessoal do Google para instalar os softwares necessários ao trabalho.
Do reset ao endpoint gerenciado
O enrollment começa com o aparelho restaurado e ainda na configuração inicial do Android.
Aparelho restaurado
↓
Enrollment por QR Code
↓
Autenticação corporativa
↓
Registro no Microsoft Intune
↓
Identificação automática do dispositivo
↓
Restrições + aplicativos obrigatórios
↓
Configurações manuais que ainda forem necessárias
↓
Ativação do Microsoft Defender
↓
Avaliação de conformidade
↓
Acesso corporativo conforme a política
O perfil de enrollment também foi ajustado para aplicar automaticamente uma nomenclatura baseada no usuário responsável. Isso reduz renomeações manuais e facilita relacionar cada aparelho à pessoa que o utiliza.
O resultado é um processo em que o dispositivo entra no gerenciamento antes de ser entregue, em vez de depender de uma configuração posterior feita pelo usuário.
Restrições e controle do ciclo de vida
A primeira baseline buscou comprovar que a TI realmente mantinha controle administrativo sobre o aparelho.
Entre os comportamentos validados estavam o bloqueio da redefinição de fábrica pelo usuário, bloqueio de contas pessoais do Google, bloqueio de alterações nas contas necessárias ao gerenciamento e exigência da verificação de ameaças do Google Play Protect.
A política também foi expandida durante o piloto para avaliar atualização automática do Android, comportamento de bloqueio de tela, restrições de usuários e atualização de aplicativos.
Nem toda configuração testada foi promovida automaticamente a padrão de produção. Opções de desenvolvedor permaneceram disponíveis durante a fase de diagnóstico, e uma política agressiva de limpeza após tentativas incorretas foi tratada como controle de alto impacto que exige avaliação antes de uma aplicação ampla.
Proteção do dispositivo e ações de ciclo de vida
Além das restrições de conta e sistema, o piloto avaliou restauração, criptografia, senha e resposta remota como partes do mesmo ciclo de proteção do aparelho.
O bloqueio de restauração foi validado tanto nas configurações normais do Android quanto no comportamento observado no menu de recuperação do aparelho piloto, onde a opção de limpeza não ficou disponível no cenário testado. A Factory Reset Protection permanece como uma camada complementar; o bloqueio preventivo foi comprovado, mas a validação completa do fluxo de recuperação por conta autorizada ainda exige um teste destrutivo separado.
A criptografia do armazenamento já estava ativa nativamente no dispositivo e pode ser utilizada como sinal verificável de conformidade. Já a exigência de PIN ou senha apresentou comportamento inconsistente no aparelho e no método de enrollment avaliados, por isso não foi promovida a requisito nesta fase.
Essa decisão afeta também a resposta remota: o bloqueio é mais efetivo quando já existe uma credencial de tela configurada. Em um aparelho perdido sem PIN ou senha, a limpeza remota pode se tornar a medida mais segura disponível, desde que o dispositivo continue conectado e consiga receber o comando.
Distribuição de aplicativos: três modelos diferentes
A padronização de software utilizou métodos diferentes conforme a origem da aplicação.
Aplicativos públicos, como Outlook, Teams e WhatsApp Business, foram distribuídos pelo Managed Google Play. Aplicações web corporativas puderam ser entregues como links gerenciados. Já aplicativos de negócio fornecidos diretamente em APK exigiram o modelo de Android Line-of-Business app no Intune.
Essa separação é importante porque “aplicativo Android” não representa um único modelo de gerenciamento.
Outlook com identidade corporativa pré-configurada
O Outlook recebeu uma política de configuração gerenciada para reduzir erros no primeiro uso e restringir o aplicativo à identidade corporativa associada ao dispositivo.
A política não elimina a autenticação do usuário, mas permite que o aplicativo já reconheça a conta correta e reduza a possibilidade de contas pessoais serem adicionadas ao cliente corporativo.
APKs e o problema do package name
Dois aplicativos necessários ao trabalho não puderam ser publicados como aplicativos privados no Managed Google Play porque seus identificadores Android já estavam registrados no ecossistema da loja.
A alternativa foi distribuí-los diretamente como APKs de linha de negócios pelo Intune.
Isso resolveu a instalação, mas transferiu para a TI a responsabilidade de manter o ciclo de atualização. Para um upgrade funcionar de forma previsível, o fornecedor precisa preservar o package name, o certificado de assinatura e utilizar um versionCode crescente. Alterar identidade ou assinatura pode transformar uma atualização simples em reinstalação e potencial perda de dados locais.
Onde a automação termina: Managed Configurations
Instalar um APK não significa conseguir configurá-lo remotamente.
Um dos aplicativos de negócio utilizados no piloto depende de um QR Code para receber parâmetros de conexão. Como o aplicativo não expõe Android Managed Configurations, o Intune não possui um canal suportado para enviar esses valores diretamente ao aplicativo. Essa etapa continua sendo executada manualmente pela TI durante o onboarding.
O mesmo limite apareceu no RustDesk para Android. O Intune consegue instalar o APK, mas a versão utilizada não expõe configurações gerenciadas para parâmetros de servidor e outras opções internas. O isolamento de aplicativos do Android também impede simplesmente editar os arquivos privados do aplicativo como seria possível fazer em um fluxo Windows com scripts.
A evolução ideal depende do próprio software: suporte a Android Managed Configurations ou uma versão do aplicativo preparada para receber os parâmetros corporativos de forma administrável.
Esse é um dos principais aprendizados do piloto: MDM não consegue automatizar uma interface que o aplicativo não oferece.
Padronização visual com Microsoft Launcher
O Microsoft Launcher foi utilizado para reduzir diferenças de experiência entre fabricantes e modelos.
No piloto, ele foi distribuído pelo Managed Google Play e definido como inicializador padrão. A TI passou a controlar elementos como organização da tela inicial, dock, pesquisa e capacidade do usuário de reorganizar alguns componentes.
A configuração de papel de parede corporativo apresentou comportamento inconsistente e foi mantida como pendência de baixo impacto. O restante da padronização permaneceu funcional mesmo após reinicializações e sincronizações.
O Launcher não substitui políticas de segurança. Sua função é fornecer uma experiência mais previsível e facilitar o onboarding, enquanto contas, restrições, proteção e ciclo de vida continuam sendo responsabilidade do Android Enterprise e do Intune.
Microsoft Defender como Mobile Threat Defense
O Microsoft Defender foi distribuído como aplicativo obrigatório e configurado para atuar como solução de Mobile Threat Defense.
O piloto validou recursos como proteção contra phishing, Network Protection, integração do dispositivo ao portal Defender e uma configuração de onboarding com menos interações manuais.
Porém, low-touch não significa no-touch. O usuário ainda precisa abrir o Microsoft Defender e concluir as etapas apresentadas pelo aplicativo para que a integração fique efetiva.
Após a ativação, o Android passa a exibir uma VPN local utilizada pelo Defender para analisar conexões e oferecer proteção web. Essa VPN não é uma conexão com a rede interna da empresa; a inspeção ocorre localmente no aparelho.
A limitação Xiaomi / HyperOS
O aparelho piloto também revelou um problema que não poderia ser resolvido apenas com políticas do Intune.
Em dispositivos Xiaomi, controles adicionais de bateria, inicialização automática e execução em segundo plano podem continuar interferindo no Microsoft Defender mesmo quando as permissões Android administráveis já foram concedidas.
Por isso, o procedimento de onboarding precisa incluir uma validação prática: o Defender deve continuar operacional após bloqueio da tela e reinicialização, além de permanecer visível no portal e com a proteção web ativa.
Esse comportamento é particularmente relevante porque o ambiente possui aparelhos desse fabricante. A exceção deixa de ser um detalhe do piloto e passa a fazer parte do procedimento operacional da TI.
Defender, conformidade e acesso ao Outlook
A arquitetura planejada utiliza o Outlook como um dos recursos móveis mais sensíveis, já que fornece acesso direto ao e-mail corporativo.
O fluxo desenhado é:
Intune enrollment
↓
Aplicativos corporativos
↓
Ativação do Defender
↓
Sinal de risco do dispositivo
↓
Compliance Policy
↓
Conditional Access
↓
Outlook / Exchange Online
A intenção é que instalar o Outlook e conhecer uma senha não seja suficiente. O aparelho também deve estar gerenciado, protegido e dentro do nível de risco aceito pela organização.
No momento documentado pelo piloto, esse fluxo representa a arquitetura planejada de enforcement. A integração do Defender e a avaliação dos sinais foram validadas, mas a exigência final de acesso deve ser ativada gradualmente, seguindo a mesma abordagem de piloto adotada no gerenciamento Windows.
WhatsApp Business e o limite entre sincronização e governança
Como contas pessoais do Google permanecem bloqueadas, o WhatsApp Business não utiliza backup em uma conta particular do colaborador. Em trocas planejadas, a estratégia é transferir diretamente as conversas antes da limpeza do aparelho anterior.
Esse procedimento não cobre perda, roubo ou falha total. Por isso, registros com valor corporativo não devem existir exclusivamente no WhatsApp: o MDM administra o dispositivo, mas não garante a recuperação dos dados internos de todos os aplicativos.
Resultados do piloto
O piloto demonstrou um ciclo de gerenciamento móvel funcional: enrollment Fully Managed, associação do dispositivo ao colaborador, instalação centralizada de aplicativos, bloqueio de contas pessoais, restrições de ciclo de vida, padronização com Microsoft Launcher, criptografia ativa, integração com Microsoft Defender e sinais disponíveis para uma política futura de conformidade e acesso.
Mais importante, o trabalho também tornou explícitas as exceções que precisam permanecer no processo operacional:
- aplicativos sem Managed Configurations ainda exigem configuração local;
- APKs distribuídos diretamente transferem parte do ciclo de atualização para a TI;
- a política de senha precisa de nova validação antes de enforcement;
- o bloqueio remoto perde efetividade sem PIN ou senha;
- a FRP ainda possui uma etapa destrutiva de validação pendente;
- aparelhos Xiaomi podem exigir ajustes e verificação manual da execução do Defender;
- o usuário ainda participa da ativação inicial do Microsoft Defender.
Essas limitações não anulam o gerenciamento. Elas definem com precisão onde termina o controle da plataforma e começam as dependências do dispositivo e das aplicações.
Próximos passos
A evolução natural é reduzir as exceções sem esconder seus riscos: reavaliar a baseline de senha, concluir a validação destrutiva de FRP, transformar sinais do Defender em requisitos efetivos de conformidade e Conditional Access e trabalhar com fornecedores para expor Android Managed Configurations nos aplicativos que ainda dependem de configuração manual.
Também é necessário manter um procedimento específico para fabricantes com controles agressivos de execução em segundo plano e validar novas versões de APK antes de ampliar sua distribuição.
O que este estudo de caso demonstra
Android Enterprise fornece à TI uma fronteira administrativa forte sobre aparelhos corporativos, mas gerenciamento moderno não é sinônimo de automação ilimitada.
A qualidade do resultado depende de três elementos trabalhando juntos: o que o MDM consegue impor, o que o sistema operacional e o fabricante permitem e o que cada aplicativo foi projetado para aceitar.
Documentar essas fronteiras foi tão importante quanto habilitar as políticas. Isso tornou o processo de onboarding mais previsível e evitou transformar limitações reais de Android em promessas de zero-touch que o ambiente ainda não consegue cumprir.