Construindo um Ciclo de Vida Seguro para Dispositivos Windows Híbridos

O gerenciamento de dispositivos híbridos tem um problema de ciclo de vida.

Um computador pode ser substituído, reinstalado, abandonado ou desconectado do ambiente corporativo, enquanto seus registros permanecem ativos no Active Directory, Microsoft Entra ID e Microsoft Intune. Com o tempo, esses objetos obsoletos reduzem a precisão do inventário, complicam investigações e aumentam o número de identidades e endpoints que os administradores precisam revisar.

Criei o DeviceLifecycle para resolver esse problema sem tratar a exclusão como uma simples tarefa de limpeza.

O projeto é uma automação em PowerShell que correlaciona identidades de dispositivos entre as plataformas Microsoft, avalia a inatividade por meio de múltiplos sinais e conduz os dispositivos elegíveis por um ciclo de vida controlado. Também criei o DeviceLifecycle-API, uma extensão separada e somente leitura que disponibiliza relatórios e logs para sistemas internos autorizados.

Código-fonte:

• DeviceLifecycle
• DeviceLifecycle-API

O problema de engenharia

Em um ambiente Microsoft híbrido, um único computador físico pode ser representado por vários registros:

• um objeto de computador no Active Directory;
• um objeto de dispositivo no Microsoft Entra ID;
• um registro de dispositivo gerenciado no Microsoft Intune;
• um registro no Windows Autopilot;
• estado local do ciclo de vida, relatórios e logs.

Esses registros não surgem, não são atualizados e não desaparecem necessariamente ao mesmo tempo.

Um registro do Intune pode ser removido depois de uma ação Retire, enquanto o objeto do Active Directory permanece em quarentena. Um objeto no Entra ID pode continuar existindo mesmo depois que o computador local deixa de se comunicar. Além disso, o nome de um dispositivo pode ser reutilizado após uma reinstalação ou substituição de hardware.

Isso significa que um processo seguro não pode depender de um único timestamp nem apenas do nome do computador.

A automação precisa responder a uma pergunta mais difícil:

Existem evidências consistentes o suficiente para justificar uma alteração nessa identidade de dispositivo?

Essa pergunta orientou todo o projeto.

Princípio de design: falhar de forma segura

A regra central do DeviceLifecycle é simples:

Automatizar os casos rotineiros, mas interromper o processo quando as evidências forem incompletas ou ambíguas.

Um dispositivo não é alterado apenas porque uma fonte indica inatividade. Antes de permitir qualquer ação, a automação valida a correlação de identidade, os sinais de atividade, as exclusões, as proteções e o estado do ciclo de vida.

Informações ausentes ou conflitantes produzem um resultado de revisão manual, e não uma ação automática.

Esse modelo fail-closed é especialmente importante porque o projeto pode desabilitar e, posteriormente, excluir identidades em vários sistemas administrativos.

Arquitetura

Separei a solução em dois repositórios com limites de confiança distintos.

DeviceLifecycle

O projeto principal controla o fluxo privilegiado. Ele:

• inventaria dispositivos no Active Directory, Entra ID e Intune;
• correlaciona as identidades entre as plataformas;
• avalia os limites de inatividade;
• gera relatórios CSV e logs de execução;
• armazena o estado do ciclo de vida em JSON;
• coloca em quarentena ou remove dispositivos elegíveis, conforme o modo configurado;
• oferece recuperação para dispositivos em quarentena.

DeviceLifecycle-API

A API é uma extensão opcional. Ela:

• lê o relatório CSV e o log de execução mais recentes;
• autentica consumidores por meio de uma chave de API;
• expõe endpoints em CSV, JSON, metadados e texto;
• não executa ações de ciclo de vida;
• não acessa Active Directory, Entra ID, Intune ou Microsoft Graph.

Essa separação mantém os consumidores de relatórios fora do plano de controle.

Active Directory ----\
Microsoft Entra ID ----> DeviceLifecycle ---> Relatórios CSV
Microsoft Intune -----/                     Logs de execução
                                             Estado persistente
                                                    |
                                                    v
                                          DeviceLifecycle-API
                                                    |
                              Dashboards, monitoramento, auditorias,
                                  inventário e ferramentas internas

Se a API ficar indisponível, o DeviceLifecycle continua funcionando normalmente. O motor do ciclo de vida permanece como produtor autoritativo do estado e dos relatórios.

Correlacionando identidades com segurança

Os nomes dos computadores são rótulos úteis, mas não são chaves de identidade confiáveis.

Um dispositivo pode ser renomeado, reinstalado ou substituído por outro computador que recebe o mesmo nome padronizado. Por isso, o DeviceLifecycle correlaciona os registros usando identificadores compartilhados entre as plataformas:

1. O SID do computador no Active Directory é comparado ao onPremisesSecurityIdentifier no Entra ID.
2. O deviceId do Entra ID é comparado ao azureADDeviceId do Intune.
3. Os timestamps de atividade dos sistemas disponíveis são avaliados em relação aos limites configurados.

Uma ação só é permitida quando a correlação é inequívoca e os sinais de atividade obrigatórios sustentam a mesma conclusão.

Os registros são enviados para revisão manual quando, por exemplo:

• não existe correspondência no Entra ID ou no Intune;
• vários registros correspondem ao mesmo identificador;
• um timestamp obrigatório está ausente;
• os identificadores são inconsistentes;
• o dispositivo está protegido ou excluído;
• não é possível determinar com segurança sua participação no Autopilot.

A incerteza é tratada como motivo para interromper o processo, e não como permissão para continuar.

Um ciclo de vida em etapas, não uma exclusão imediata

O fluxo padrão utiliza múltiplos estágios.

1. Atenção

Após o limite configurado de atenção — 75 dias de inatividade por padrão — o dispositivo aparece no relatório.

Nenhuma alteração é realizada. Essa etapa fornece tempo para investigar dispositivos que estão se aproximando da elegibilidade para quarentena.

2. Candidato à quarentena

Após 90 dias de inatividade nos sinais obrigatórios, o dispositivo pode se tornar um candidato à quarentena.

Quando os modos Quarantine ou Enforce estão habilitados, a automação pode:

• enviar um comando Retire ao Intune;
• desabilitar a conta do computador no Active Directory;
• mover o objeto para uma unidade organizacional dedicada à quarentena;
• registrar identificadores e timestamps do ciclo de vida em estado persistente.

O arquivo JSON de estado é essencial porque o Intune pode remover o registro managedDevice depois de processar a operação de desativação. O ciclo de vida precisa continuar rastreável mesmo depois que uma fonte deixa de conter o registro.

3. Remoção permanente

Após o período de retenção em quarentena — 30 dias adicionais por padrão — o dispositivo pode se tornar elegível para remoção final.

No modo Enforce, o fluxo pode:

• excluir o objeto de computador do Active Directory;
• remover qualquer registro restante no Intune;
• iniciar uma sincronização delta do Microsoft Entra Connect;
• verificar se ainda existe um objeto residual no Entra ID;
• remover o objeto residual após um período adicional de carência.

Essa sequência cria várias oportunidades para detectar erros antes de uma ação irreversível.

Um detalhe crítico do Entra Connect

A unidade organizacional de quarentena deve permanecer dentro do escopo de sincronização do Microsoft Entra Connect.

Se a OU for excluída, mover um computador para a quarentena pode fazer o objeto correspondente desaparecer imediatamente do Entra ID. Isso contornaria o período de retenção e mudaria o comportamento esperado do ciclo de vida.

Essa foi uma lição importante do projeto: uma operação aparentemente segura dentro do Active Directory pode produzir um efeito não intencional na nuvem por causa da sincronização de diretórios.

A automação precisa considerar o sistema completo, não apenas o comando executado.

Modos de operação progressivos

O DeviceLifecycle oferece três modos de operação.

ReportOnly

Esse é o modo padrão e mais seguro.

A automação inventaria e avalia os dispositivos, mas não realiza nenhuma alteração administrativa. Os relatórios incluem resultados como:

• dispositivos em período de atenção;
• candidatos à quarentena;
• correspondências ausentes no Entra ID;
• correspondências ausentes no Intune;
• correlações ambíguas;
• timestamps de atividade ausentes;
• registros que exigem revisão manual.

Esse modo deve permanecer ativo pelo tempo necessário para validar as premissas no ambiente real.

Quarantine

Esse modo habilita ações reversíveis de contenção. Ele pode desativar o registro do Intune, desabilitar a conta no Active Directory e mover o objeto para quarentena, mas não realiza a exclusão final.

Enforce

Esse modo habilita o ciclo de vida completo, incluindo a remoção permanente após os períodos configurados de retenção e carência.

A imposição só deve ser habilitada depois que relatórios, quarentena, recuperação, permissões, comportamento da sincronização e limites operacionais forem testados.

Controles de segurança

Os mecanismos de proteção fazem parte do design central, não são recursos adicionais.

O projeto inclui:

• ReportOnly como modo padrão;
• correlação por SID e GUID, em vez de apenas pelo nome;
• revisão manual para registros incompletos ou ambíguos;
• exclusão de servidores Windows e controladores de domínio;
• exclusão de dispositivos registrados no Autopilot;
• exclusão do próprio host da automação;
• um grupo de exceção dedicado no Active Directory;
• detecção de proteção contra exclusão acidental;
• limite configurável de ações por execução;
• estado persistente em JSON;
• relatórios CSV e logs de execução;
• limpeza atrasada de objetos residuais no Entra ID;
• suporte ao -WhatIf do PowerShell;
• procedimentos explícitos de validação, recuperação e desinstalação.

A tarefa agendada é executada como NT AUTHORITY\SYSTEM. No Active Directory, portanto, ela atua por meio da conta de computador do servidor que hospeda a automação.

Em vez de conceder privilégios administrativos amplos, as permissões podem ser delegadas apenas nas unidades organizacionais gerenciada e de quarentena. Isso segue o princípio do menor privilégio e reduz o impacto de um host de automação comprometido.

A recuperação é deliberadamente manual

Um dispositivo em quarentena não é restaurado automaticamente apenas porque voltou a se comunicar.

Uma sincronização posterior do Intune pode indicar somente que o dispositivo recebeu o comando de desativação. Isso não comprova que o computador deve retornar à produção.

Por esse motivo, a recuperação exige uma decisão administrativa explícita.

O script de recuperação pode:

• reabilitar a conta do computador no Active Directory;
• movê-la de volta para a OU de produção;
• remover marcadores do ciclo de vida e o estado de quarentena;
• iniciar a sincronização de diretório;
• permitir a validação do hybrid join e do enrollment no Intune.

Ele também oferece suporte ao -WhatIf, permitindo revisar o procedimento antes da execução.

Quarentena automatizada e recuperação deliberada oferecem um equilíbrio mais seguro do que reverter silenciosamente uma decisão de segurança.

Relatórios e estado operacional

Cada execução produz evidências estruturadas:

• um relatório CSV atual;
• relatórios individuais por execução;
• logs de execução;
• um arquivo JSON de estado persistente.

O arquivo de estado preserva identificadores e timestamps entre as execuções. Isso é necessário porque o próprio fluxo pode remover registros dos sistemas de origem.

Os relatórios podem ser revisados diretamente no servidor ou consumidos pela API opcional.

A extensão de API somente leitura

Criei o DeviceLifecycle-API com FastAPI e Uvicorn para disponibilizar os dados operacionais a dashboards e serviços internos, sem conceder acesso ao sistema de arquivos ou privilégios de ciclo de vida.

Os principais endpoints são:

A API não possui endpoints de quarentena, exclusão, restauração ou modificação de dispositivos.

Isso impede que uma integração de relatórios se transforme em uma interface administrativa privilegiada.

Modelo de segurança da API

A API é destinada ao uso interno, mas a rede interna não é tratada como inerentemente confiável.

Os controles incluem:

• autenticação por chave no cabeçalho X-API-Key;
• chaves hexadecimais aleatórias de 64 caracteres;
• comparação da chave em tempo constante;
• segredos de runtime armazenados fora do repositório;
• allowlist de endereços de origem no Windows Firewall;
• Swagger, ReDoc e OpenAPI desabilitados em runtime;
• rejeição de caminhos de arquivos controlados pelo cliente;
• leitura estável dos arquivos para evitar respostas parcialmente atualizadas;
• respostas com Cache-Control: no-store;
• limites configuráveis para leitura parcial do log;
• rotação de logs sem exposição da chave de API.

O transporte padrão é HTTP interno. Em redes roteadas ou não confiáveis, o serviço deve ser colocado atrás de um proxy reverso HTTPS.

O que aprendi com o projeto

A parte mais difícil da automação não é substituir comandos por código. É definir quando o software possui evidências suficientes para tomar uma decisão com segurança.

Um ciclo de vida de dispositivos híbridos precisa lidar com:

• consistência eventual;
• registros ausentes ou duplicados;
• atrasos de sincronização;
• reutilização de nomes de computadores;
• operações assíncronas de desativação;
• dependências entre sistemas locais e em nuvem.

Uma decisão correta em um sistema isolado ainda pode ser insegura quando o ambiente completo é considerado.

O projeto também reforçou a importância de separar capacidades. O DeviceLifecycle controla o fluxo privilegiado. O DeviceLifecycle-API fornece visibilidade operacional. Ferramentas de monitoramento e relatórios podem consumir os dados sem receber autoridade para alterar o ambiente.

O principal princípio que pretendo levar para futuros projetos de automação de segurança é:

Uma automação confiável deve tomar decisões conservadoras, preservar evidências e parar quando as informações disponíveis forem insuficientes.

Código-fonte

Os projetos completos e suas documentações de instalação estão disponíveis no GitHub:

• DeviceLifecycle
• DeviceLifecycle-API