BYOD bem feito: um guia de campo para proteger celulares pessoais com o Intune

Se você toca uma empresa pequena no Microsoft 365 e quer o e-mail de trabalho no celular de todo mundo, você esbarra numa pergunta que parece simples e não é: como proteger os dados da empresa num aparelho que não é seu?

A resposta é uma pilha de ferramentas bem definidas, com trade-offs claros. Usadas do jeito certo, elas dão proteção forte para os dados da empresa e privacidade total para os dados pessoais no mesmo celular. Este é um guia dos conceitos, dos trade-offs, da configuração exata que usamos — e dos problemas que encontramos no caminho, porque foram vários.

Por que se dar ao trabalho — os fatos

Algumas razões diretas pelas quais vale a pena fazer isso direito:

• Os celulares já são pessoais. Uma empresa pequena não distribui hardware corporativo. As pessoas checam e-mail e Teams no aparelho que está no bolso, então esse aparelho já está no escopo, quer você o gerencie ou não.
• Acesso não gerenciado é um caminho real de dados. Deixados por conta própria, o e-mail e os arquivos da empresa ficam em apps sem exigência de criptografia, sem PIN, sem controle sobre para onde os dados são copiados e sem como removê-los se um celular for perdido ou uma pessoa sair.
• Guardamos dados que importam. Operamos uma plataforma com fundos de jogadores e informações pessoais, então mantemos nosso próprio acesso interno num padrão definido (controles no estilo CIS/SOC 2), não num "melhor esforço".
• Privacidade é requisito, não um luxo. O que quer que a gente faça não pode estender o alcance da TI aos apps, fotos, mensagens ou localização pessoais de ninguém.

O objetivo era específico: todo caminho até os dados da empresa num celular precisa atender a um padrão de segurança definido, sem gerenciar o aparelho pessoal em volta.

O problema, enunciado com precisão

Dois requisitos valem ao mesmo tempo:

• Os dados da empresa precisam de proteção — criptografados, com acesso controlado e removíveis se o celular for perdido ou a pessoa sair.
• Um celular pessoal pertence à pessoa — fotos, conversas, apps e localização ficam privados e fora do alcance da TI.

O gerenciamento de dispositivos móveis é o ferramental construído para satisfazer os dois ao mesmo tempo. O resto deste guia é a caixa de ferramentas e como as peças se encaixam.

A caixa de ferramentas: três jeitos de gerenciar um celular

O Microsoft Intune oferece um espectro, não um interruptor:

1. MAM — Mobile Application Management gerencia o app. Você protege os apps de trabalho e deixa o resto do celular em paz. Sem registro.

2. MDM — Mobile Device Management gerencia o dispositivo, em dois sabores distintos:

• Perfil de trabalho / User Enrollment — um contêiner de trabalho separado e criptografado num celular pessoal. A TI gerencia só o contêiner.
• Totalmente gerenciado — a TI gerencia o dispositivo inteiro. Apropriado para hardware da empresa, não para celulares pessoais.

A maioria dos times considera só a opção 1 e a ponta "totalmente gerenciada" da opção 2, rejeita as duas e se contenta com algo frouxo. A opção útil é a do meio.

Conceito 1: MAM / proteção de aplicativo

As políticas de proteção de aplicativo do Intune são a camada MAM. Uma política aplicada a um app como o Outlook:

• Criptografa os dados da empresa dentro do app.
• Exige PIN ou biometria para abri-lo.
• Bloqueia copy, Save As e Open in dos dados da empresa para apps pessoais.
• Permite um apagamento seletivo só dos dados da empresa, deixando os dados pessoais intactos.

Nada disso exige registrar o dispositivo. O celular continua inteiramente pessoal; só os apps de trabalho são gerenciados. Para muitos casos de BYOD, isso é suficiente — e foi o nosso ponto de partida.

Conceito 2: conformidade implica registro

O conceito que amarra tudo é a conformidade do dispositivo.

Um dispositivo está "em conformidade" quando está registrado no gerenciamento e atende às regras de integridade que você define — criptografia de disco ativada, bloqueio de tela configurado, sistema atualizado, sem root, e assim por diante. Conformidade é um estado que o dispositivo reporta e o gerenciamento verifica.

O ponto-chave: não dá para avaliar a conformidade de um dispositivo que nunca foi registrado. A premissa do MAM é não haver registro, então um celular só com MAM está protegido no nível do app, mas nunca pode estar "em conformidade" — não há nada registrado para verificar. Require compliant device e "sem registro" são mutuamente exclusivos por design.

Se você quer uma garantia no nível do dispositivo, o dispositivo precisa estar registrado em alguma coisa. Isso aponta para a opção do meio.

Conceito 3: o perfil de trabalho

No Android, a opção do meio é o perfil de trabalho (via Android Enterprise). No iOS, o equivalente é o User Enrollment. O modelo:

Um perfil de trabalho é um contêiner separado e criptografado num celular pessoal. A TI gerencia apenas o que está dentro desse contêiner. Tudo fora dele — apps pessoais, fotos, mensagens, contas — fica num espaço que a TI não pode ver, tocar nem apagar.

Os apps de trabalho aparecem como um conjunto com selo ao lado da tela inicial pessoal, isolados no contêiner. O dispositivo passa a estar registrado e em conformidade, com escopo limitado ao contêiner de trabalho. Os dados pessoais continuam privados. "Registro", aqui, significa que a empresa gerencia um contêiner, não o dispositivo.

Conceito 4: acesso condicional

O acesso condicional (CA) no Microsoft Entra é o portão de acesso. Antes de conceder um login, ele checa condições que você define. Duas concessões importam aqui:

• Require app protection — o acesso é permitido se o app tem a sua política MAM aplicada. Combina com MAM.
• Require compliant device — o acesso é permitido se o dispositivo está registrado e íntegro. Combina com MDM / perfil de trabalho.

O CA é onde você impõe qual modelo está usando. Mude a concessão, mude a régua do acesso.

O caminho que seguimos

Com o modelo em mãos, a construção é direta:

1. Comece com MAM. Proteção de aplicativo nos apps de trabalho, mais uma regra de CA exigindo proteção de app. O toque mais leve.
2. Decida a garantia de que você precisa. Se "o app está protegido" basta, pare aqui — é válido. Nós queríamos a garantia no nível do dispositivo.
3. Habilite o Android Enterprise vinculando o Managed Google Play ao tenant. Uma conexão única que destrava o registro por perfil de trabalho.
4. Registre o celular como perfil de trabalho de propriedade pessoal. Um espaço de trabalho criptografado e com selo é criado, o lado pessoal fica intocado, e o dispositivo reporta compliant em uns dois minutos.
5. Entregue os apps de trabalho pelo Managed Google Play — aprove Outlook, Teams, Edge e os apps do Office, atribua-os, e eles se instalam no contêiner.
6. Mova a concessão do CA de Require app protection para Require compliant device — a mesma régua usada para os laptops.

Essa é a versão limpa. Eis o que aconteceu de verdade.

Problemas que encontramos, e como resolvemos

1. Todo app gerenciado bloqueado com "device is not compliant". Nossa política MAM de proteção de aplicativo carregava uma regra de inicialização condicional, appActionIfDeviceComplianceRequired, definida como block. Quando tentamos afrouxá-la, o Intune só aceitou block ou wipe — a API rejeita null e warn. Combinado com o Conceito 2, isso é um loop fechado: a política exige um dispositivo em conformidade, um celular só com MAM nunca é registrado, então nunca está em conformidade, então todo app é bloqueado e o Company Portal fica tentando registrar. É imposto no lado do cliente, então nunca aparece como falha de login no Entra — um detalhe que dificulta o diagnóstico. Correção: pare de brigar com o portão. Registre o dispositivo (perfil de trabalho) para que ele possa de fato estar em conformidade, e depois abandone o MAM nessa plataforma (problema 5).

2. Company Portal: "does not meet requirements to enroll". Antes de o Android Enterprise ser conectado, não existia caminho de registro por perfil de trabalho, então a tentativa de registro não tinha onde aterrissar. Correção: conecte o Managed Google Play para vincular o Android Enterprise. É essa única conexão que torna o registro por perfil de trabalho disponível.

3. O conflito de conta Google — o passo que mais custou tempo. O Managed Google Play se vincula usando uma conta Google que se torna a dona do enterprise. Nosso e-mail comercial já estava atrelado a uma conta Google pessoal, e o Google trata isso como uma conta conflitante — ele não deixa usar o mesmo endereço para criar o administrador organizacional/do Workspace. É fácil deixar passar, e isso trava tudo. Correção: resolva o conflito primeiro. Ou libere o e-mail pelo processo de contas conflitantes do Google (renomeie ou encerre a conta Google pessoal existente naquele endereço), ou use uma conta dedicada, sem registro prévio no Google. Reserve tempo de verdade para isso — é a coisa mais provável de travar um time pequeno no primeiro dia, e não tem nada a ver com o Intune.

4. O perfil de trabalho estava vazio depois do registro. Os apps do perfil de trabalho não migram do lado pessoal. Um contêiner recém-criado não tem nada dentro. Correção: aprove os apps no Managed Google Play e atribua-os ao seu grupo como Required (instalação automática) ou Available (instalação pelo próprio usuário na loja do perfil de trabalho). Eles então aparecem como apps com selo no contêiner.

5. Ainda "not compliant" — mesmo depois de o dispositivo estar em conformidade. O dispositivo agora reportava compliant, mas o Outlook continuava recusando. A causa: a política MAM de proteção de aplicativo continuava aplicada ao mesmo app que agora era gerenciado por MDM no perfil de trabalho, e o seu portão de conformidade de dispositivo conflitava com o registro. MAM e MDM não querem cogerenciar o mesmo app. Correção: comprometa-se com um modelo por plataforma. Desatribuímos a política de proteção de aplicativo do Android e trocamos a concessão do acesso condicional do Android de Require app protection para Require compliant device. O dispositivo com perfil de trabalho a satisfaz diretamente; não sobra portão MAM para conflitar.

6. Nossa própria política bloqueou nosso ferramental de admin — AADSTS530033. Ao automatizar as mudanças no Intune, um login de admin foi recusado: o acesso condicional negando um login por device code porque esse token não está vinculado a um dispositivo em conformidade. Correção: execute o trabalho privilegiado a partir de um dispositivo já em conformidade, para que o token fique vinculado ao dispositivo — por exemplo, Connect-MgGraph interativamente numa máquina gerenciada. A lição é positiva: se o seu acesso condicional consegue barrar um login por device code, ele está configurado corretamente.

Sobre construir com IA

Construímos em público, e construímos com IA, inclusive na operação. A IA é eficaz para trabalhar uma configuração por muitos caminhos rapidamente. Nós a combinamos com uma regra: a IA propõe, um humano decide — especialmente em qualquer coisa que toque segurança. Essa divisão de trabalho permite que um time pequeno opere no ritmo de um time maior.

Os modelos mentais para levar

1. MAM gerencia o app; MDM gerencia o dispositivo. Escolha com base na garantia de que você precisa.
2. Conformidade implica registro. Não dá para verificar um dispositivo que nunca foi registrado, então Require compliant device e "sem registro" não podem coexistir.
3. O perfil de trabalho é a opção do meio. Ele gerencia um contêiner, não o dispositivo — conformidade do dispositivo e privacidade pessoal ao mesmo tempo.
4. Um modelo por app. Não deixe uma política MAM num app que você moveu para MDM; escolha uma pista e siga nela.
5. O acesso condicional define a régua. Escolha a concessão que combina com o seu modelo e deixe que ela imponha.

Colocamos esse nível de cuidado em algumas caixas de e-mail de trabalho porque a mesma disciplina que protege o nosso acesso móvel é a que protege a sua conta, os seus fundos e os seus dados na plataforma. Segurança é um hábito que atravessa o trabalho interno, não só as partes que os clientes veem.

Nos vemos nas mesas.