Pergunte ao time de TI como o parque de estações está configurado hoje e a resposta honesta costuma ser “abre o portal e olha”. Política de BitLocker, regra de firewall, exceção criada numa madrugada de incidente: tudo mora dentro de um console web, sem histórico legível, sem revisão e sem caminho de volta. É o problema que a infraestrutura resolveu com código versionado — só que quase ninguém aplicou a ideia ao gerenciamento de endpoints.

Foi o que fizemos num projeto com uma seguradora brasileira: um framework em PowerShell sobre a API do Microsoft Graph que exporta o estado do tenant do Intune para arquivos versionados e os aplica de volta de forma controlada. As políticas do parque viraram código em git — revisável em pull request e reproduzível. Com assistentes de IA escrevendo o framework, o que seria mês de trabalho virou dias.

O clique não deixa rastro

Gestão de estações feita a cliques falha em três pontos previsíveis. O primeiro é rastreabilidade: o portal registra que algo mudou, mas não conta o porquê, nem mostra o antes e o depois de uma política com dezenas de configurações. O segundo é reversibilidade — desfazer uma mudança ruim depende de alguém lembrar do valor anterior.

O terceiro é o mais caro: reprodutibilidade. Um parque bem configurado é um ativo que existe num único lugar. Se o tenant precisar ser recriado, ou se for preciso montar um ambiente de teste fiel, o caminho é refazer clique a clique — e o resultado nunca é idêntico. Por isso o assunto é disciplina de infraestrutura.

O que “as code” resolve no Intune

A ideia é simples. Em vez de o tenant ser a única fonte da verdade, ele passa a ser o destino de uma configuração que vive em um repositório. Quatro efeitos práticos:

• Exportar o estado. Políticas de configuração, regras de conformidade, perfis de Autopilot, scripts e atribuições saem como JSON legível. Isso já é o inventário que ninguém tinha.
• Versionar. “O que mudou na política de BitLocker no último trimestre” vira um comando, não uma investigação — e o histórico serve de evidência em auditoria.
• Revisar em PR. Mudança de baseline deixa de ser decisão solitária: duas pessoas leem o diff antes de qualquer coisa chegar às máquinas.
• Aplicar de novo. O mesmo conjunto de arquivos sobe em outro tenant, num ambiente de teste ou de volta ao original depois de um problema.

O que a IA acelerou de verdade

Vale separar promessa de resultado. A IA não desenhou a política de segurança do cliente nem decidiu o que era aceitável para aquele parque. Ela encurtou três trabalhos concretos.

Escrever o framework. A parte chata de falar com o Graph é sempre a mesma: autenticação por aplicação com permissões mínimas, paginação de @odata.nextLink, tratamento de throttling — o HTTP 429 com Retry-After, que aparece justamente ao exportar o tenant inteiro — e normalização dos JSON, para que o diff não acuse mudança por ordem de campos ou carimbo de data. Descrever isso em prosa e receber as funções estruturadas, com tratamento de erro e log, economizou quase todo o esforço mecânico.

Traduzir políticas de baseline. Recomendação de segurança vem como texto: exigir criptografia de disco, bloquear macro externa, habilitar as regras de redução de superfície de ataque. Transformar cada linha dessas no identificador correto do catálogo de configurações do Intune é garimpo em documentação. A IA fez o primeiro corte; o engenheiro conferiu e corrigiu — e havia o que corrigir.

Destravar troubleshooting de enrolment. É aqui que o ganho surpreende. Falha na inscrição devolve códigos hexadecimais pouco amigáveis, com indícios espalhados entre o visualizador de eventos e o relatório de diagnóstico MDM. Jogar esse material bruto para análise encurta o caminho entre “a máquina não entra” e “o escopo de inscrição automática não inclui esse grupo”.

O método: exportar, comparar, versionar, aplicar

A ordem importa, e começa pelo passo mais seguro: nada de escrever a configuração ideal antes de conhecer a real.

1. Exportar o tenant inteiro com credencial somente leitura. É a fotografia do que existe — inclusive das políticas duplicadas e das atribuições órfãs que ninguém sabia que ainda estavam ativas.
2. Comparar o export com o baseline pretendido. A lista de diferenças é a pauta real do projeto: o que falta, o que sobra e o que está em conflito.
3. Versionar a configuração aprovada, com as atribuições referenciando grupos por nome, não por identificador. Identificador não sobrevive à troca de tenant; nome, sim — e é isso que torna o repositório portável.
4. Aplicar por anel: piloto de dez máquinas do próprio TI, depois o TI inteiro, depois uma área de negócio e só então o parque. Cada anel fica em observação por dias.

Guarda-rails: o tenant é produção

Automatizar mudança em parque de estações é poderoso e perigoso na mesma medida. Quatro regras não são negociáveis. Separar credenciais: o que exporta usa permissão de leitura; o que aplica usa escrita e vive no pipeline. Backup antes de cada apply — um export do estado atual, marcado no repositório: é a diferença entre reverter e reconstruir.

Nada aplica sem revisão — o diff aprovado é o que roda, e a aprovação fica registrada. E anéis com critério de parada definidos antes: se o piloto gerar chamados acima do combinado, o anel seguinte não avança. Some a isso uma prática barata — rodar o apply em modo simulado e ler o que ele pretende alterar. Isso é continuidade operacional tanto quanto é cibersegurança.

Antes e depois: a migração das estações

O caso foi a migração de estações Windows do modelo híbrido — ingressadas no domínio local e apenas registradas na nuvem — para Entra Join com provisionamento por Autopilot: o equipamento sai da caixa, entra no tenant e chega configurado ao usuário, sem passar pela bancada da TI.

Antes, montar o baseline de segurança e as políticas equivalentes no novo modelo era trabalho de semanas de configuração manual, com o risco de esquecer silenciosamente uma regra do mundo antigo. Com o framework, virou questão de dias. Mais importante que a velocidade: o parque ficou reproduzível — o estado inteiro cabe num repositório que qualquer engenheiro do time lê e revisa.

Duas armadilhas valem o registro. A primeira é o acesso a recursos locais: sair do modelo híbrido sem resolver como a máquina autentica em compartilhamentos e impressoras do datacenter quebra a rotina de quem trabalha. A segunda são as políticas legadas do domínio, que precisam ser traduzidas uma a uma — e é aí que a comparação paga o próprio custo.

A ponte com Zero Trust

Nada disso é exercício de organização. Zero Trust parte de um princípio simples: nenhum acesso é concedido por estar dentro da rede. Ele depende de identidade verificada e de dispositivo conhecido, gerenciado e em conformidade. A estação é metade da equação, não um detalhe do inventário.

Só que “em conformidade” precisa ter significado técnico. Ele vem da política que o Intune avalia — disco criptografado, proteção contra ameaças ativa, versão mínima do sistema — e que o acesso condicional consulta antes de liberar e-mail, arquivos e aplicações. Se essa política não é versionada nem revisada, o pilar de dispositivo do Zero Trust se apoia em cliques que ninguém audita.

Para ir mais fundo, a Inove Academy disponibiliza o e-book de cibersegurança e LGPD, que trata da parte normalmente ausente dessa conversa: quais controles técnicos sustentam as obrigações legais e como demonstrar isso quando alguém pede evidência.

Uma ressalva final. Colocar o parque em código não elimina decisão técnica; muda o lugar onde ela acontece. O que bloquear, o que liberar e quanto atrito o usuário aguenta continuam sendo escolhas humanas. O que o framework garante é que a escolha fique escrita, revisada e reversível — em vez de virar mais uma alteração de portal que ninguém consegue explicar seis meses depois.