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 no Active Directory, Microsoft Entra ID e Microsoft Intune. Com o tempo, objetos obsoletos reduzem a precisão do inventário, complicam investigações e aumentam a quantidade de identidades e endpoints que precisam ser revisados.

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 avalia atividade, correlaciona identidades nas plataformas Microsoft quando esses registros existem 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;
• outros registros de enrollment ou provisionamento;
• 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 depois que o computador local deixa de se comunicar. E um computador pode existir somente no Active Directory porque nunca foi gerenciado pelo Intune ou porque o registro cloud já foi removido.

Isso significa que um processo seguro não pode depender de um único timestamp, apenas do nome do computador ou da premissa de que toda fonte sempre precisa possuir um registro.

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

Quais evidências realmente existem para este dispositivo e as evidências disponíveis são confiáveis o suficiente para justificar uma alteração na identidade?

Essa pergunta orientou todo o projeto.

Princípio de design: falhar de forma segura sem confundir ausência com inconsistência

A regra central do DeviceLifecycle é automatizar os casos rotineiros e interromper o fluxo quando a evidência existente é ambígua, inconsistente ou inutilizável.

A distinção importante é que um registro cloud ausente não é automaticamente uma inconsistência.

Se a consulta ao Entra ID ou Intune é concluída com sucesso e retorna zero registros correspondentes, essa fonte é tratada como evidência indisponível. O ciclo de vida continua utilizando as fontes que realmente existem. Se uma fonte existir, porém, sua identidade e seus dados de atividade precisam passar pelas validações antes de qualquer ação administrativa.

Isso é diferente de uma falha de consulta ao Microsoft Graph, uma correspondência duplicada, um conflito de identificadores ou um timestamp ausente em uma fonte existente. Essas condições continuam fail-closed.

Essa distinção se tornou importante em produção: exigir uma correspondência em todas as plataformas fazia objetos antigos do Active Directory permanecerem indefinidamente em revisão manual, mesmo quando a ausência dos registros cloud era legítima e as evidências disponíveis sustentavam a quarentena.

Arquitetura

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

DeviceLifecycle

O projeto principal controla o fluxo privilegiado. Ele:

• inventaria dispositivos do Active Directory e registros disponíveis no Entra ID/Intune;
• correlaciona identidades quando os registros cloud existem;
• avalia limites de inatividade usando sinais disponíveis e validados;
• gera relatórios CSV e logs de execução;
• armazena estado do lifecycle 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 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 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 lifecycle 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 utiliza identificadores estáveis quando um registro cloud está disponível:

1. o SID do computador no Active Directory é comparado ao onPremisesSecurityIdentifier do Entra ID;
2. quando existe exatamente uma correspondência válida no Entra, seu deviceId é comparado ao azureADDeviceId do Intune;
3. os timestamps de atividade de todas as fontes existentes e validadas são comparados aos limites configurados.

A política atual de atividade é propositalmente assimétrica:

• o Active Directory é sempre obrigatório porque é a fonte local autoritativa deste fluxo;
• um registro ausente no Entra ID é tratado como evidência indisponível;
• um registro ausente no Intune é tratado como evidência indisponível;
• um registro existente no Entra ou Intune precisa ser único, consistente e possuir o timestamp de atividade exigido;
• atividade recente em qualquer fonte existente impede que um timestamp antigo do AD produza uma quarentena incorreta.

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

• vários registros correspondem ao mesmo identificador;
• um timestamp obrigatório está ausente em uma fonte que existe;
• os identificadores são inconsistentes;
• o objeto já está em um estado administrativo inesperado;
• uma proteção ou regra de exclusão bloqueia a ação automática.

Uma consulta concluída com sucesso e zero resultados não é tratada da mesma forma que uma consulta que falha. A primeira significa “não há evidência nessa fonte”; a segunda significa que o sistema não conseguiu determinar se essa evidência existe e, portanto, mantém o comportamento fail-closed.

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

O fluxo utiliza múltiplos estágios.

1. Atenção

Após o limite de atenção configurado — 75 dias de inatividade por padrão — o dispositivo pode ser classificado como próximo do limite de quarentena.

Nenhuma alteração é realizada. Essa etapa fornece tempo para investigar dispositivos antes que eles se tornem elegíveis para contenção.

2. Candidato à quarentena

Após 90 dias de inatividade em todos os sinais validados que realmente existem, o dispositivo pode se tornar candidato à quarentena.

Quando Quarantine ou Enforce está habilitado, a automação pode:

• enviar um comando Retire ao Intune quando existe um registro managedDevice;
• desabilitar a conta do computador no Active Directory;
• mover o objeto para uma unidade organizacional dedicada à quarentena;
• registrar identificadores e timestamps do lifecycle no estado persistente.

O arquivo JSON de estado é essencial porque o Intune pode remover o registro managedDevice depois de processar o Retire. 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, quando aplicável;
• iniciar uma sincronização delta do Microsoft Entra Connect;
• verificar se ainda existe um objeto residual no Entra ID;
• remover esse objeto residual depois de 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 previsto e mudaria o comportamento do lifecycle.

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

É o modo padrão e mais seguro para implantação.

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

• dispositivos ativos;
• dispositivos próximos do limite de quarentena;
• candidatos à quarentena;
• correlações ambíguas;
• timestamps ausentes em fontes existentes;
• objetos protegidos ou excluídos;
• registros que realmente exigem revisão manual.

Uma fonte cloud sem registro correspondente é representada pela ausência dos identificadores e do timestamp daquela fonte, não por um motivo artificial MissingEntraMatch ou MissingIntuneMatch.

Quarantine

Esse modo habilita ações reversíveis de contenção. Ele pode executar Retire quando existe um registro no Intune, desabilitar a conta no Active Directory e mover o objeto para quarentena, mas não realiza exclusão definitiva.

Enforce

Esse modo habilita o ciclo de vida completo, incluindo remoção permanente depois dos períodos configurados de retenção e carência.

A promoção para Enforce é feita somente depois de revisar o ReportOnly, simular o caminho exato com Enforce -WhatIf e validar uma primeira execução real controlada.

Tarefas separadas para lifecycle e snapshot

O modelo instalado utiliza duas tarefas agendadas com responsabilidades diferentes.

Tarefa principal

{OrganizationName} - Device Lifecycle executa diariamente no TaskTime configurado e usa o modo operacional definido. Depois da validação de produção, essa tarefa pode permanecer em Enforce.

Tarefa de snapshot

{OrganizationName} - Device Lifecycle Snapshot executa periodicamente — a cada 30 minutos por padrão — e sempre força -ModeOverride ReportOnly.

A tarefa existe para manter DeviceLifecycle-Latest.csv atualizado para inventário, dashboards, monitoramento e a API somente leitura sem causar alterações administrativas toda vez que o snapshot é renovado.

As duas tarefas usam um wrapper de locking para evitar execuções concorrentes do lifecycle.

Controles de segurança

Os mecanismos de proteção fazem parte do design central.

O projeto inclui:

• ReportOnly como modo padrão de implantação;
• correlação por SID/GUID quando registros cloud existem;
• revisão manual para identidades ambíguas ou inconsistentes;
• revisão manual para timestamps ausentes em fontes existentes;
• proteções e exclusões para casos administrativos especiais;
• 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 do Entra ID;
• suporte ao -WhatIf do PowerShell;
• procedimentos explícitos de validação, recuperação e desinstalação.

A tarefa principal é 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 somente nas unidades organizacionais necessárias. 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 somente indicar que o dispositivo recebeu uma ação de gerenciamento anterior. 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 e estado de quarentena;
• iniciar a sincronização de diretório quando configurado;
• apoiar a revalidação do estado de join e enrollment.

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 administrativa.

Relatórios e estado operacional

Cada execução produz evidências estruturadas:

• um relatório atual DeviceLifecycle-Latest.csv;
• 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 dados operacionais a dashboards e serviços internos sem conceder acesso ao sistema de arquivos ou privilégios de lifecycle.

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 a 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 aleatórias;
• comparação da chave em tempo constante;
• segredos de runtime armazenados fora do repositório;
• allowlist de rede;
• documentação interativa da API desabilitada no runtime de produção;
• 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;
• logging de requisições sem exposição dos segredos de autenticação.

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

Validação em produção

Em 28 de agosto de 2026, validei a política atualizada de correlação em um ambiente real.

A sequência foi propositalmente conservadora:

1. gerar um novo snapshot em ReportOnly e comparar as classificações com o comportamento anterior;
2. confirmar que objetos antigos do AD sem registros no Entra ID ou Intune se tornaram candidatos normais ao lifecycle em vez de itens permanentes de revisão manual;
3. confirmar que atividade cloud recente continuava impedindo quarentena incorreta;
4. executar Enforce -WhatIf e revisar todas as ações propostas;
5. executar uma primeira rodada real controlada em Enforce, respeitando MaximumActionsPerRun;
6. revisar o novo relatório e o estado de quarentena antes de permitir que a tarefa diária permanecesse em Enforce.

O lote controlado foi concluído conforme esperado. Com isso, a tarefa principal pôde ser promovida para Enforce persistente, enquanto a tarefa frequente de snapshot continuou executando somente em ReportOnly.

Os nomes, identificadores e contagens reais do ambiente não são publicados no repositório público.

O que aprendi com o projeto

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

Um ciclo de vida de dispositivos Windows precisa lidar com:

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

Uma das lições mais úteis da implantação foi perceber que um sistema conservador não deve simplesmente classificar toda ausência como erro. Um modelo melhor pergunta se a consulta foi concluída com sucesso, se existe um registro, se esse registro é único e confiável e o que as demais evidências indicam.

O projeto também reforçou o valor de separar capacidades. O DeviceLifecycle controla o fluxo privilegiado. O DeviceLifecycle-API fornece visibilidade operacional. A tarefa de snapshot mantém o inventário recente sem receber autoridade de lifecycle própria.

O princípio que pretendo levar para futuras automações de segurança é:

Uma automação confiável deve distinguir evidência indisponível de evidência contraditória, preservar o contexto operacional e interromper o fluxo quando as evidências que existem não podem ser confiadas.

Código-fonte

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

• DeviceLifecycle
• DeviceLifecycle-API