Registros de Aplicativo Azure: Apps com Privilegios Excessivos

Os registros de aplicativo Azure estão entre os pontos do tenant onde o privilégio se torna mais facilmente invisível. Um registro de aplicativo pode parecer um detalhe de integração, mas seu service principal pode deter permissões de aplicativo do Microsoft Graph, credenciais ativas e caminhos de acesso em nível de tenant que não dependem de um usuário com sessão iniciada.

Quais são os riscos dos registros de aplicativo Azure?

Os registros de aplicativo Azure são os objetos de identidade por trás de aplicativos personalizados, automações, integrações e muitas conexões SaaS de terceiros no Microsoft Entra ID. Eles podem se autenticar no Microsoft Graph, em recursos do Azure e em outras APIs protegidas.

O risco aparece quando esses aplicativos mantêm mais permissões do que precisam, guardam credenciais por mais tempo do que deveriam, ou permanecem no tenant muito depois de o proprietário original ter parado de prestar atenção. Nesse estado, o aplicativo se comporta como uma identidade privilegiada permanente, com muito menos visibilidade humana no dia a dia do que uma conta de usuário administrador.

Uma boa revisão não consiste apenas em encontrar uma permissão perigosa. Consiste em comprovar quais aplicativos estão ativos, quais têm acesso de aplicativo de alto privilégio, quem é o proprietário e como suas credenciais são governadas.

Como funciona

Os registros de aplicativo normalmente se autenticam com um de dois tipos de credencial:

• client secrets
• certificados

O aplicativo então age de acordo com as permissões concedidas ao seu service principal correspondente.

Dois modelos amplos de permissão importam:

• permissões delegadas, em que o aplicativo age no contexto de um usuário com sessão iniciada
• permissões de aplicativo, em que o aplicativo age como si mesmo, sem nenhum usuário presente

A documentação do Microsoft Graph é explícita sobre a diferença: permissões de aplicativo são permissões exclusivas do app, usadas sem um usuário com sessão iniciada. Um app daemon ou um serviço de backend pode usá-las para chamar APIs em seu próprio nome. Se o aplicativo tem uma permissão de aplicativo ampla, o raio de impacto é determinado por essa permissão e pelo recurso, não pela sessão atual de um usuário interativo.

Os casos de maior risco costumam ser permissões de aplicativo que concedem amplo acesso a dados de todo o tenant ou capacidade de modificação do diretório. Se um atacante obtém a credencial do aplicativo, herda todo o poder de API que o aplicativo já possui.

Registros de aplicativo Azure: o que os torna de alto risco

O padrão perigoso costuma ser uma combinação, não uma única marcação:

• permissões de aplicativo amplas, como acesso a caixas de correio, arquivos ou diretório em todo o tenant
• credenciais de longa duração, com rotação fraca, ou copiadas em vários lugares
• nenhum proprietário claro para o aplicativo ou seu service principal
• nenhuma atividade de login recente, o que sugere que o aplicativo pode estar abandonado mas ainda é confiável
• consentimento de administrador concedido há muito tempo, sem revisão recorrente

Por isso, uma revisão de permissões sem revisão de ownership fica incompleta. Um aplicativo com permissões moderadas e sem proprietário ainda pode se tornar um incidente sério quando o secret vaza e ninguém percebe os logins.

Uma segunda distinção prática também importa: alguns aplicativos são arriscados porque podem escrever ou administrar, enquanto outros são arriscados porque podem ler silenciosamente grandes volumes de dados do tenant. Ambos os casos merecem revisão, mesmo quando o portal os rotula como conjuntos de permissões diferentes.

Fatos sobre permissões que mudam o risco

Não trate cada permissão do Graph como intercambiável. A Microsoft documenta que permissões de aplicativo podem operar sem um usuário com sessão iniciada, e que algumas permissões permitem acesso em nível de toda a organização aos dados associados. Por exemplo, uma permissão ampla de arquivos, e-mail, diretório ou gerenciamento de aplicativos pode ser mais danosa do que uma permissão delegada que só funciona dentro de uma sessão de usuário restrita.

Permissões de gerenciamento de aplicativos merecem atenção especial. A referência de permissões do Microsoft Graph alerta que permissões capazes de gerenciar credenciais podem permitir que um aplicativo aja como outras entidades e use os privilégios concedidos a elas. Essa é uma classe de risco diferente da de um aplicativo que apenas lê seu próprio perfil.

O consentimento de administrador também faz parte da fronteira de controle. Permissões de aplicativo só podem ser consentidas por um administrador, nunca por um usuário final. Especificamente para permissões de aplicativo do Microsoft Graph, a Microsoft documenta que somente Privileged Role Administrator e Global Administrator podem consentir; Application Administrator e Cloud Application Administrator podem consentir permissões de aplicativo excluindo o Microsoft Graph. Se o tenant não tiver uma revisão recorrente das aplicações com consentimento de administrador, o modelo de acesso efetivo pode ir se desviando por anos depois que o projeto original terminou.

A cadeia de ataque

Passo 1 - Enumerar os registros de aplicativo e suas permissões

Connect-MgGraph -Scopes 'Application.Read.All'

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
  $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

  [PSCustomObject]@{
    AppName      = $app.DisplayName
    AppId        = $app.AppId
    Created      = $app.CreatedDateTime
    SecretExpiry = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
    Permissions  = ($appRoles | ForEach-Object { "$($_.ResourceDisplayName):$($_.AppRoleId)" }) -join ', '
  }
} | Where-Object { $_.Permissions -ne '' }

Passo 2 - Priorizar as combinações mais sensíveis

Concentre-se primeiro nos aplicativos que combinam permissões amplas de tenant com credenciais obsoletas ou ownership pouco clara. Service principals que detêm diretamente papéis de admin do Entra são um caso à parte e muitas vezes pior, tratado em Entra Service Principal com Privilégios de Admin Excessivos: Detecção e Correção.

Uma ordem de triagem útil:

1. aplicativos com permissões de aplicativo para o Microsoft Graph ou workloads do Exchange
2. aplicativos com permissões de gerenciamento de app ou de gerenciamento de diretório
3. service principals com credenciais ativas mas sem evidência de login recente
4. aplicativos com vários secrets ou certificados ativos que nenhum proprietário sabe explicar
5. aplicativos com consentimento de administrador mas sem proprietário de negócio atual

Passo 3 - Obter a credencial

Client secrets costumam ser expostos por repositórios de código, pipelines de deployment, arquivos de configuração locais, ou notas operacionais copiadas. O problema não é que secrets possam vazar teoricamente. O problema é que muitos tenants ainda dependem de secrets de longa duração para aplicativos de alto valor.

Passo 4 - Autenticar-se como o aplicativo e usar o scope concedido

import msal

app = msal.ConfidentialClientApplication(
    client_id='APP_CLIENT_ID',
    client_credential='STOLEN_SECRET',
    authority='https://login.microsoftonline.com/TENANT_ID'
)
result = app.acquire_token_for_client(scopes=['https://graph.microsoft.com/.default'])
token = result['access_token']

A partir desse ponto, o caminho de ataque é determinado pelas permissões já concedidas ao aplicativo, não por nenhum novo exploit administrativo.

Detecção

Sinais de auditoria e login do Entra

A Microsoft documenta os logs de login de service principal separadamente dos logins interativos e não interativos de usuário. Esses logs são importantes porque a autenticação exclusivamente de aplicativo não envolve um usuário humano. A Microsoft também documenta que esses eventos são agregados: os logins são agrupados em uma única linha quando o nome ou ID do service principal, o status, o endereço IP e o nome ou ID do recurso coincidem, então expanda uma linha antes de concluir que um aplicativo fez login apenas uma vez. Logins de managed identity não aparecem neste log; eles têm o seu próprio. Para os padrões de detecção específicos deste log, veja Entra Service Principal: Detecção de Anomalias de Login e Pontos Cegos de Workload Identity.

Perguntas práticas de revisão

• quais aplicativos detêm permissões de aplicativo com alcance em todo o tenant
• quais aplicativos têm vários secrets ativos ou secrets antigos que nunca foram removidos
• quais aplicativos não têm login recente mas ainda mantêm acesso privilegiado
• quais aplicativos não têm proprietário ativo nem patrocinador de negócio
• quais aplicativos podem gerenciar aplicativos, service principals, credenciais, grants ou atribuições de papéis

Consulta de detecção SIEM (Elastic KQL)

data_stream.dataset: "azure.auditlogs"
    and azure.auditlogs.operation_name: "Add service principal credentials"
    and event.outcome: "success"

Use o nome da atividade exatamente como a Microsoft publica na referência de atividades de auditoria. Uma credencial adicionada no objeto application é registrada sob uma atividade diferente, Update application - Certificates and secrets management, então uma regra que monitora apenas a atividade do service principal perde metade dos casos. Esse evento se torna muito mais útil quando enriquecido com o proprietário do app, o inventário anterior de credenciais e o nível de permissão do service principal afetado.

Lógica de detecção que reduz falsos positivos

Um secret novo em um app de teste de baixo privilégio não é a mesma coisa que um secret novo em um app com permissões de aplicativo do Graph e sem proprietário. Priorize cruzando a atividade de auditoria com o inventário de aplicativos:

• permissões atuais do app e status de consentimento
• se o app usa permissões de aplicativo ou permissões delegadas
• quantidade de credenciais e datas de expiração
• horário do último login do service principal
• número de proprietários e se ainda são funcionários ativos
• se o IP de origem ou o workload mudou em relação à baseline histórica

Remediação

Ganho rápido: faça um inventário de cada aplicativo com permissões de aplicativo amplas e peça que o proprietário ateste que a permissão e a credencial ainda são necessárias.

1. Remover ou desabilitar aplicativos não utilizados

Comece pela idade, mas não confunda idade com desuso. A consulta abaixo lista aplicativos registrados há mais de 90 dias, o que em um tenant maduro é a maioria deles. Ela produz uma lista de candidatos à revisão, não uma lista de aplicativos sem uso.

$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication -All | Where-Object { $_.CreatedDateTime -lt $cutoff } |
  Select-Object DisplayName, AppId, CreatedDateTime

O sinal de desuso é a autenticação, não a data de criação: verifique os logs de login do service principal do app, ou o relatório Service principal sign-in activity usage and insights, que ainda está em preview no momento da escrita. Combine revisão de atividade, ownership e dependências. Se ninguém consegue explicar por que o aplicativo ainda existe, ele não deveria manter acesso permanente.

2. Rotacionar e reduzir credenciais

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $app.PasswordCredentials |
    Where-Object { $_.EndDateTime -lt (Get-Date).AddDays(30) } |
    Select-Object @{n='AppName';e={$app.DisplayName}}, DisplayName, EndDateTime
}

Rotacione secrets antigos, remova secrets substituídos e evite deixar várias credenciais válidas ativas sem motivo. Se uma credencial foi copiada em código, pipelines ou documentação, trate a rotação como apenas uma etapa. O local de armazenamento antigo também precisa de limpeza.

3. Preferir um gerenciamento de credenciais mais robusto

A Microsoft publica uma ordem de preferência explícita, e ela não começa com certificados. Use uma managed identity sempre que o workload rodar no Azure: a Microsoft a classifica como a opção mais segura e a recomenda fortemente. Se o workload rodar em outro lugar, em uma plataforma que ofereça gerenciamento automatizado de credenciais, use workload identity federation em vez disso. Somente quando nenhuma das duas for possível você deve recorrer a credenciais de certificado, armazenadas em um key vault e emitidas por uma CA confiável em vez de autoassinadas.

A orientação da Microsoft sobre secrets é direta: «Don't use password credentials, also known as secrets». Secrets são convenientes, e é exatamente por isso que acabam copiados em ferramentas de desenvolvimento e operação. Políticas de gerenciamento de aplicativos também podem limitar o tempo de vida dos secrets ou bloquear totalmente seu uso.

4. Reduzir o escopo de permissões

Verifique se o aplicativo realmente precisa de permissões de aplicativo. Onde possível:

• substitua permissões de escrita amplas por permissões de leitura ou com escopo mais restrito
• prefira permissões delegadas quando existir um contexto de usuário real
• remova o consentimento de administrador que não é mais justificado pelo workload
• evite conceder permissões de gerenciamento de app a menos que o workload realmente gerencie aplicativos
• documente por que cada permissão de aplicativo restante é necessária

5. Restringir quem pode criar aplicativos e conceder consentimento

A Microsoft fornece configurações de tenant e papéis delegados para controlar quem pode registrar aplicativos e quem pode consentir aplicativos. Desabilite o registro amplo de apps por usuários e o consentimento de usuário onde o negócio não precisar disso, e então atribua papéis explícitos às equipes que precisam.

Isso não é apenas governança. Isso impede que o tenant reintroduza o mesmo problema depois da limpeza. Se qualquer pessoa pode criar apps e solicitar permissões amplas sem um caminho de revisão, a proliferação de apps privilegiados vai voltar.

Validar antes de encerrar o achado

Uma revisão de registros de aplicativo não está completa só porque o portal parece mais limpo. Valide o resultado em relação ao comportamento real do tenant.

• exporte os apps de alto risco restantes, seus proprietários, suas credenciais ativas e suas permissões efetivas
• confirme que secrets antigos foram removidos, e não apenas substituídos enquanto a credencial anterior continuava ativa
• verifique se o app ainda funciona após a redução de permissões ou a rotação de credenciais
• confirme que aplicativos abandonados foram de fato desabilitados ou excluídos, em vez de deixados como exceções não documentadas
• revise os logs de login do service principal após a mudança para confirmar que não restam IPs de origem ou recursos inesperados
• reverifique as permissões com consentimento de administrador e confirme que a lista corresponde ao inventário de aplicativos

Revise também o caminho de governança ao redor: quem pode criar apps, quem pode conceder consentimento de administrador, e quem deve aprovar acesso de aplicativo privilegiado. Sem esse controle, o mesmo padrão vai voltar no próximo ciclo de projeto.

Como a EtcSec detecta isso

A EtcSec torna os achados de registros de aplicativo úteis combinando privilégio, idade das credenciais, lacunas de ownership e sinais de atividade. Um tenant geralmente não falha porque tem muitos aplicativos. Ele falha porque um pequeno número de aplicativos tem permissões amplas, higiene de credenciais fraca e nenhum caminho de revisão claro.

O modelo de detecção é baseado em exposição: permissões de aplicativo amplas, credenciais que permanecem válidas, ownership pouco clara e atividade de service principal que não corresponde ao caso de uso documentado. Cada um desses elementos mapeia para uma verificação dedicada: permissões perigosas de e-mail, arquivos, diretório e papéis concedidas a um app; aplicativos com vários secrets ativos ou sem rotação de credenciais; aplicativos e service principals sem proprietário; concessões de consentimento em todo o tenant; e service principals que ainda mantêm credenciais obsoletas. O valor está no cruzamento, não em um único sinal isolado.

Leituras relacionadas

• Fortalecimento do Tenant Azure: Security Defaults
• Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM
• Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real
• Contas de Convidado Azure: Riscos do Tenant
• Azure Identity Protection: Bloqueando Credenciais Vazadas

Referências principais

• Microsoft Graph permissions overview
• Microsoft Graph permissions reference
• Permissions and consent in the Microsoft identity platform
• Service principal sign-in logs in Microsoft Entra ID
• Security best practices for application properties
• Delegate application management administrator permissions
• Microsoft Entra audit log activity reference