Rotação de Credenciais em Registros de Aplicativo do Entra e Higiene de Secrets

O Que É Higiene De Credenciais Em Registros De Aplicativo Do Entra

A rotação de credenciais em registros de aplicativo do Entra envolve os client secrets, certificados e federated credentials que suas aplicações usam para se autenticar, e é um dos cantos mais negligenciados da superfície de ataque de identidade em um tenant. Todo registro de aplicativo que se autentica como si mesmo, seja um daemon, um pipeline de CI/CD ou uma integração de API, precisa de uma credencial para provar que é quem diz ser. Essa credencial é um passwordCredential (um client secret), um keyCredential (a chave pública de um certificado carregado) ou um federated credential (uma relação de confiança com um provedor de identidade externo, sem nenhum material de secret). Esquecer de rotacionar qualquer uma delas é como uma credencial rotineira silenciosamente se torna uma backdoor permanente, sem prompt de MFA e, muitas vezes, sem ninguém de olho nela.

Isso importa porque a credencial de um registro de aplicativo concede exatamente o que as permissões dessa aplicação permitem: escopos da API do Microsoft Graph, permissões delegadas ou de aplicativo, às vezes acesso de leitura/escrita em todo o diretório. A orientação da própria Microsoft é explícita: client secrets são menos seguros que certificados ou federated credentials e não devem ser usados em produção; com workload identity federation, você elimina o esforço de manutenção de gerenciar credenciais manualmente e o risco de vazar secrets ou deixar certificados expirarem. Um tenant que nunca inventaria as credenciais de aplicativos não tem como distinguir um secret rotineiro de um que sobreviveu silenciosamente a todo admin que sabia para que ele servia.

Este é um ângulo diferente do de registros de aplicativo com privilégios excessivos (abordado em Registros de Aplicativo Azure: Apps Com Privilégios Excessivos) — aquele artigo trata do que um aplicativo pode fazer; este trata de por quanto tempo as chaves da porta continuam válidas e se alguém está de olho na fechadura. Um secret de longa duração vazado é usado da mesma forma que um token OAuth obtido por phishing em OAuth Consent Phishing: silenciosamente, com as próprias permissões do aplicativo, até que alguém perceba que a atividade não corresponde ao comportamento normal do app.

Como Funciona: Secrets, Certificados E Por Que A Rotação É Pulada

Todo objeto application e servicePrincipal no Microsoft Graph expõe duas coleções de credenciais:

• passwordCredentials — client secrets, cada um com keyId, startDateTime e endDateTime. Segundo a referência do recurso passwordCredential, endDateTime é o timestamp ISO 8601 UTC após o qual o secret deixa de funcionar.
• keyCredentials — chaves públicas de certificados carregados, usadas para autenticação baseada em certificado (CBA), cada uma com seu próprio prazo de expiração.

Client secrets criados pelo portal têm um limite máximo de 24 meses de vida útil, e a Microsoft recomenda explicitamente definir uma expiração abaixo de 12 meses, em vez de usar o padrão máximo. Na prática, as equipes costumam fazer o oposto: escolhem a validade mais longa oferecida para que nada quebre inesperadamente, e depois deixam a aplicação em paz. Dois anos depois, a pessoa que configurou já saiu, o secret ainda é válido, e ninguém se lembra de qual pipeline ou script depende dele.

Um problema relacionado, mas distinto, é o sprawl de credenciais: uma aplicação acumula múltiplos secrets ativos ao longo do tempo porque a rotação foi feita adicionando um novo secret em vez de substituir o antigo. Cada secret ativo adicional é mais um caminho de entrada que precisa ser rastreado, revogado e auditado — e secrets antigos de uma rotação que "funcionou" rotineiramente nunca são removidos. É comum encontrar registros de aplicativo com vários anos carregando três ou quatro secrets ativos, cada um criado por um admin diferente durante um incidente diferente, nenhum deles jamais revogado.

A autenticação baseada em certificado é, em geral, o tipo de credencial mais seguro dos dois — a chave privada de um certificado nunca precisa ser transmitida ou colada em um arquivo de configuração como acontece com o valor de um secret. Mas um certificado CBA ativo ainda é uma credencial viva, com prazo de expiração e um raio de impacto caso a chave privada seja comprometida, e a Microsoft recomenda que certificados sejam emitidos por uma CA confiável, com uma política que exija emissores confiáveis, em vez de certificados autoassinados com confiança indefinida.

Detectando Rotação De Credenciais Obsoleta Ou Em Sprawl Em Registros De Aplicativo Do Entra

Comece com um inventário, não com uma amostragem — você não pode rotacionar o que não contou.

Inventarie Cada Credencial Via Microsoft Graph

Consulte as credenciais de cada aplicação diretamente:

GET https://graph.microsoft.com/v1.0/applications
    ?$select=id,displayName,passwordCredentials,keyCredentials

A resposta inclui endDateTime para cada secret e certificado, permitindo sinalizar qualquer coisa já expirada ou prestes a expirar.

Automatize Com PowerShell Em Todo O Tenant

O Microsoft Graph PowerShell SDK facilita rodar isso em todo o tenant, em vez de aplicativo por aplicativo:

# Requer: Connect-MgGraph -Scopes "Application.Read.All"
Get-MgApplication -All -Property Id, DisplayName, PasswordCredentials, KeyCredentials |
  ForEach-Object {
    $app = $_
    $app.PasswordCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Secret"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
    $app.KeyCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Certificate"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
  } | Sort-Object DaysLeft

Leia Os Sinais Que Importam

A partir desse inventário, mapeie os achados para riscos concretos:

Confirme O Uso Real Nos Logs De Sign-In

Verifique como as credenciais estão realmente sendo usadas, não apenas o que existe, através dos logs de sign-in de service principals. Cada evento de sign-in carrega um campo ClientCredentialType: um valor de client secret indica autenticação baseada em senha, enquanto a autenticação baseada em certificado aparece como client assertion, junto com um ClientCredentialKeyID que você pode relacionar ao keyId específico na lista de credenciais do app. Esse mapeamento mostra qual credencial está realmente ativa em produção versus quais são peso morto que ninguém removeu — uma distinção que o inventário bruto de credenciais sozinho não oferece. Se uma credencial aparecer sinalizada em uma detecção de risco em vez de em um sign-in de rotina, trate-a da forma como Azure Identity Protection: Risk Policies recomenda tratar qualquer outro sinal de credencial vazada.

Rastreie Alterações De Credenciais No Log De Auditoria

Para o rastreamento histórico de alterações, filtre o log de auditoria do Entra por Category = ApplicationManagement: adições e remoções de credenciais de aplicações e service principals são registradas como alterações de propriedade do recurso alvo, revisáveis por aplicativo — veja a referência de atividades do log de auditoria do Microsoft Entra. Exporte-os para um SIEM ou workspace do Log Analytics se precisar de retenção maior que a janela padrão do admin center, conforme a visão geral dos logs de auditoria.

Remediação: Rotacionar, Restringir E Sair Dos Secrets

Primeiro Inventarie, Depois Rotacione

Execute a consulta do Graph acima em todas as aplicações antes de mexer em qualquer coisa — você precisa saber quais secrets são realmente referenciados por um workload em produção antes de revogá-los. Rotacionar ou excluir um secret ainda em uso quebra o workload que depende dele, então esse passo não é opcional.

Substitua, Não Adicione

Ao rotacionar, crie o novo secret ou certificado, atualize o workload consumidor, verifique se ele autentica, então exclua a credencial antiga. Adicionar uma nova e deixar a antiga "só por garantia" é exatamente como o sprawl de múltiplos secrets começa.

Migre Para Certificados Ou Federated Credentials

A Microsoft recomenda certificados em vez de client secrets antes de um app chegar à produção, e federated credentials onde a plataforma do workload suportar — eliminando o problema da rotação por completo, em vez de apenas geri-lo melhor.

Imponha O Padrão Em Todo O Tenant

Em vez de depender que cada dono de aplicativo se autopolicie, imponha padrões de credencial com uma Application Management Policy. As políticas são configuradas via Microsoft Graph ou Graph PowerShell (sem UI no portal) e podem limitar a vida útil de certificados e bloquear totalmente novas password credentials:

# Requer: Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
$policy = @{
  displayName    = "Enforce credential standards"
  isEnabled      = $true
  applications   = @{
    keyCredentials = @(
      @{
        restrictionType = "asymmetricKeyLifetime"
        maxLifetime     = "P180D"
        state           = "enforced"
      }
    )
    passwordCredentials = @(
      @{
        restrictionType = "passwordAddition"
        state           = "enforced"
      }
    )
  }
}
New-MgPolicyAppManagementPolicy -BodyParameter $policy

Veja o tutorial sobre como impor padrões de secret e certificado e a configuração de restrições de application management policy para todos os tipos de restrição disponíveis, incluindo como restringir uma política a apps específicos ou aplicá-la a todo o tenant.

Atribua Um Owner E Revise Em Uma Cadência

Uma credencial que não tem dono é uma credencial que ninguém rotaciona ou revoga quando deveria. Combine ownership com uma revisão recorrente da consulta de inventário acima — mensalmente, no mínimo, para apps com permissões privilegiadas do Graph.

Verifique A Confiança Do Certificado, Não Apenas A Expiração

Para CBA especificamente, confirme que os certificados ativos vêm de uma CA confiável, conforme as suas boas práticas de segurança para propriedades de registro de aplicativo, e não de um certificado autoassinado que ninguém se lembra de ter emitido.

Leitura relacionada: Certificado De Assinatura SAML Do Entra Expirado aborda o que acontece quando um tipo diferente de certificado — assinatura SAML — é deixado para expirar sem monitoramento, e Como Auditar A Segurança Do Microsoft Entra ID: Guia Prático percorre a revisão de permissões de aplicativos como parte de uma auditoria mais ampla do tenant.

Como A EtcSec Detecta Isso

A auditoria de Entra da EtcSec verifica as credenciais de aplicações e service principals diretamente contra o Microsoft Graph em cada scan. APP_NO_CREDENTIAL_ROTATION sinaliza apps cujas credenciais ficaram obsoletas sem nenhuma atividade de substituição; APP_SECRET_LONG_EXPIRY e APP_SECRET_EXPIRED capturam secrets com vida útil excessiva ou já além do endDateTime; APP_MULTIPLE_SECRETS revela sprawl de credenciais por rotação aditiva; SP_STALE_CREDENTIAL estende a mesma verificação para service principals; e CBA_CERTIFICATES_ACTIVE inventaria toda aplicação que atualmente depende de autenticação baseada em certificado, para que você possa verificar confiança e expiração deliberadamente, em vez de descobrir quando algo quebra.