Rotazione dei Segreti App Registration di Entra: Rilevamento e Remediation

Cos'è l'igiene delle credenziali di App Registration in Entra

I segreti di rotazione delle credenziali Entra App Registration sono i client secret, i certificati e le credenziali federate che le vostre applicazioni usano per autenticarsi, e sono uno degli angoli più trascurati della superficie di attacco identitaria di un tenant. Ogni App Registration che si autentica come sé stessa, che sia un daemon, una pipeline CI/CD o un'integrazione API, ha bisogno di una credenziale per dimostrare di essere ciò che dichiara di essere. Quella credenziale è un passwordCredential (un client secret), un keyCredential (una chiave pubblica di certificato caricata), oppure una credenziale federata (una relazione di trust con un identity provider esterno, senza alcun materiale segreto). Dimenticare di ruotare una di queste è il modo in cui una credenziale di routine diventa silenziosamente una backdoor permanente, senza alcuna richiesta MFA e spesso senza nessun proprietario che la sorvegli.

Questo è importante perché la credenziale di una App Registration concede tutto ciò che i permessi di quell'applicazione consentono: scope di Microsoft Graph, permessi delegati o applicativi, a volte accesso in lettura/scrittura sull'intera directory. Le indicazioni di Microsoft sono esplicite: i client secret sono meno sicuri delle credenziali a certificato o federate e non dovrebbero essere usati in produzione; con la federazione dell'identità workload si elimina l'onere di gestire manualmente le credenziali e il rischio di far trapelare segreti o di lasciare scadere i certificati. Un tenant che non inventaria mai le credenziali applicative non ha modo di distinguere un segreto di routine da uno che è silenziosamente sopravvissuto a tutti gli amministratori che sapevano a cosa servisse.

Questo è un angolo diverso rispetto alle App Registration sovrapprivilegiate (trattato in Azure App Registrations: Over-Privileged Tenant Apps) — quell'articolo riguarda cosa può fare un'applicazione; questo riguarda per quanto tempo restano valide le sue chiavi della porta, e se qualcuno sta sorvegliando la serratura. Un segreto a lunga durata trapelato viene sfruttato allo stesso modo di un token OAuth phishato in OAuth Consent Phishing: come le app malevole aggirano il furto di password: silenziosamente, con i permessi propri dell'applicazione, finché qualcuno non nota che l'attività non corrisponde al comportamento normale dell'app.

Come funziona: segreti, certificati e perché la rotazione viene saltata

Ogni oggetto application e servicePrincipal in Microsoft Graph espone due collezioni di credenziali:

• passwordCredentials — i client secret, ciascuno con un keyId, uno startDateTime e un endDateTime. Secondo il riferimento della risorsa passwordCredential, endDateTime è il timestamp ISO 8601 UTC dopo il quale il segreto smette di funzionare.
• keyCredentials — chiavi pubbliche di certificati caricate, usate per l'autenticazione basata su certificato (CBA), ciascuna con la propria scadenza.

I client secret creati dal portale hanno un limite massimo di durata di 24 mesi, e Microsoft raccomanda esplicitamente di impostare una scadenza inferiore ai 12 mesi invece di usare per default il massimo consentito. In pratica, i team spesso fanno l'opposto: scelgono la scadenza più lunga disponibile per non rompere nulla inaspettatamente, e poi lasciano l'app in pace. Due anni dopo, la persona che l'ha configurata se n'è andata, il segreto è ancora valido, e nessuno ricorda più quale pipeline o script ne dipenda.

Un problema correlato ma distinto è la proliferazione delle credenziali (credential sprawl): un'applicazione che accumula più segreti attivi nel tempo perché la rotazione è stata fatta aggiungendo un nuovo segreto invece di sostituire quello vecchio. Ogni segreto attivo aggiuntivo è un'ulteriore via d'accesso da tracciare, revocare e auditare — e i vecchi segreti di una rotazione che "ha funzionato" praticamente non vengono mai ripuliti. È comune trovare App Registration vecchie di diversi anni che portano tre o quattro segreti attivi, ciascuno creato da un amministratore diverso durante un incidente diverso, nessuno dei quali è mai stato revocato.

L'autenticazione basata su certificato è generalmente il tipo di credenziale più sicuro tra i due — la chiave privata di un certificato non deve mai essere trasmessa o incollata in un file di configurazione come invece accade con il valore di un segreto. Ma un certificato CBA attivo resta comunque una credenziale viva, con una scadenza e un raggio d'impatto se la chiave privata viene compromessa, e Microsoft raccomanda che i certificati siano emessi da una CA affidabile, con una policy che imponga emittenti fidati invece di certificati autofirmati con trust indefinito.

Rilevare i segreti di rotazione Entra App Registration obsoleti o proliferati

Iniziate con un inventario, non con un controllo a campione — non potete ruotare ciò che non avete contato.

Inventariare ogni credenziale via Microsoft Graph

Interrogate direttamente le credenziali di ogni applicazione:

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

La risposta include endDateTime per ogni segreto e certificato, permettendo di segnalare tutto ciò che è già scaduto o in scadenza a breve.

Automatizzarlo su tutto il tenant con PowerShell

L'SDK Microsoft Graph PowerShell rende più semplice eseguire questa operazione su tutto il tenant invece che app per app:

# Requires: 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

Leggere i segnali che contano

A partire da quell'inventario, collegate i risultati a un rischio concreto:

Confermare l'uso reale nei log di accesso

Verificate come le credenziali vengono effettivamente usate, non solo cosa esiste, tramite i log di accesso dei service principal. Ogni evento di accesso porta un campo ClientCredentialType: un valore client secret indica autenticazione basata su password, mentre l'autenticazione a certificato appare come client assertion, insieme a un ClientCredentialKeyID che potete far corrispondere al keyId specifico nell'elenco credenziali dell'app. Questa corrispondenza indica quale credenziale è realmente viva in produzione rispetto a quelle che sono peso morto che nessuno ha rimosso — una distinzione che l'inventario grezzo delle credenziali da solo non può darvi. Se una credenziale compare segnalata in una rilevazione di rischio piuttosto che in un accesso di routine, trattatela come raccomandato in Azure Identity Protection: Criteri di Rischio per qualsiasi altro segnale di credenziale trapelata.

Tracciare i cambi di credenziale nel log di audit

Per il tracciamento storico delle modifiche, filtrate il log di audit di Entra per Categoria = ApplicationManagement: le aggiunte e rimozioni di credenziali di applicazioni e service principal vengono registrate come modifiche di proprietà sulla risorsa target, consultabili per app — vedete il riferimento alle attività del log di audit di Microsoft Entra. Esportatele verso un SIEM o un workspace Log Analytics se avete bisogno di una retention più lunga della finestra predefinita dell'admin center, secondo la panoramica dei log di audit.

Remediation: ruotare, restringere e abbandonare i segreti

Prima inventariare, poi ruotare

Eseguite la query Graph sopra su tutte le applicazioni prima di toccare qualsiasi cosa — dovete sapere quali segreti sono effettivamente referenziati da un workload in esecuzione prima di revocarli. Ruotare o eliminare un segreto ancora in uso rompe il workload che ne dipende, quindi questo passaggio non è opzionale.

Sostituire, non aggiungere

Quando ruotate, create il nuovo segreto o certificato, aggiornate il workload che lo consuma, verificate che si autentichi correttamente, e solo allora eliminate la credenziale vecchia. Aggiungerne una nuova lasciando quella vecchia "per sicurezza" è esattamente il modo in cui nasce la proliferazione di segreti multipli.

Passare a certificati o credenziali federate

Microsoft raccomanda i certificati rispetto ai client secret prima che un'app raggiunga la produzione, e le credenziali federate dove la piattaforma del workload lo consente — eliminando il problema della rotazione alla radice invece di gestirlo meglio.

Applicare lo standard a livello di tenant

Invece di affidarsi all'autodisciplina di ogni proprietario di app, imponete standard sulle credenziali con una Application Management Policy. Le policy si configurano tramite Microsoft Graph o Graph PowerShell (nessuna interfaccia nel portale) e possono limitare la durata dei certificati e bloccare del tutto le nuove credenziali a password:

# Requires: 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

Consultate il tutorial su come applicare standard per segreti e certificati e la configurazione delle restrizioni della policy di gestione applicazioni per l'elenco completo dei tipi di restrizione disponibili, incluso come limitare una policy ad app specifiche invece che a tutto il tenant.

Assegnare un proprietario e rivedere con una cadenza fissa

Una credenziale che nessuno possiede è una credenziale che nessuno ruota né revoca quando dovrebbe. Abbinate la proprietà a una revisione ricorrente della query di inventario sopra riportata — almeno mensile per le app con permessi Graph privilegiati.

Verificare il trust del certificato, non solo la scadenza

Per il CBA in particolare, confermate che i certificati attivi provengano da una CA affidabile secondo le vostre best practice di sicurezza per le proprietà di App Registration, e non da un certificato autofirmato che nessuno ricorda di aver emesso.

Letture correlate: Certificato di firma SAML Entra scaduto: perché il login federato smette di funzionare illustra cosa succede quando un tipo diverso di certificato — la firma SAML — viene lasciato scadere senza monitoraggio, e Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica illustra la revisione dei permessi applicativi come parte di un audit di tenant più ampio.

Come EtcSec rileva tutto questo

L'audit Entra di EtcSec verifica le credenziali di applicazioni e service principal direttamente rispetto a Microsoft Graph a ogni scansione. APP_NO_CREDENTIAL_ROTATION segnala le app le cui credenziali sono diventate obsolete senza attività di sostituzione; APP_SECRET_LONG_EXPIRY e APP_SECRET_EXPIRED individuano segreti configurati con una durata eccessiva o già oltre il loro endDateTime; APP_MULTIPLE_SECRETS rivela la proliferazione di credenziali da rotazione additiva; SP_STALE_CREDENTIAL estende lo stesso controllo ai service principal; e CBA_CERTIFICATES_ACTIVE inventaria ogni applicazione che attualmente si affida all'autenticazione basata su certificato, così potete verificare trust e scadenza in modo deliberato invece di scoprirlo quando si rompe.