Come vedere quali app hanno accesso al vostro Microsoft 365

Potete vedere tutte le app con accesso al vostro tenant Microsoft 365 dal Microsoft Entra admin center, in Identity → Applications → Enterprise applications → All applications. Selezionando un'app e aprendo la relativa scheda Permissions si vede esattamente quali dati di Microsoft Graph può raggiungere, suddivisi tra permessi approvati dagli amministratori dell'organizzazione e permessi approvati singolarmente dai singoli utenti per se stessi.

Questa guida illustra questo percorso in modo completo, la distinzione tra admin consent e user consent che spesso trae in inganno, e cosa non può dirvi una revisione app per app.

Dove trovo l'elenco delle app con accesso in Entra?

1. Accedete a entra.microsoft.com con un account che detenga almeno il ruolo di Cloud Application Administrator o Application Administrator.
2. Andate su Identity → Applications → Enterprise applications → All applications.
3. Selezionate l'app che volete esaminare, quindi aprite Permissions.

Qui sono elencate tutte le applicazioni aggiunte al vostro tenant tramite consenso utente o consenso amministratore — inclusi assistenti AI, bot per riunioni ed estensioni di produttività che si collegano tramite la piattaforma di identità Microsoft, insieme alle applicazioni line-of-business. L'elenco copre sia le app Microsoft di prima parte sia le registrazioni di terze parti, quindi vale la pena scorrere oltre i nomi familiari per vedere quali altri permessi si sono accumulati silenziosamente nel tempo.

Qual è la differenza tra admin consent e user consent?

La scheda Permissions si suddivide in due parti:

• Admin consent — permessi concessi per l'intera organizzazione da un amministratore. Si applicano a tutti gli utenti coperti dalla concessione, non solo alla persona che ha effettuato il click.
• User consent — permessi che un singolo utente ha approvato per se stesso, una persona alla volta, senza il coinvolgimento di un amministratore (quando le impostazioni di consenso del tenant lo consentono).

Selezionando qualsiasi permesso elencato si apre un riquadro Permission Details che descrive esattamente cosa consente.

Come revoco l'accesso di un'app?

Per una concessione di admin consent: aprite il permesso nell'elenco, selezionate il controllo … accanto ad esso e scegliete Revoke permission — questa operazione funziona direttamente nel portale.

Per una concessione di user consent, il portale non dispone di un pulsante di revoca. Per revocarla è necessaria una chiamata API Microsoft Graph (DELETE /oAuth2PermissionGrants/{id} per i permessi delegati, o la chiamata equivalente appRoleAssignments per i permessi applicativi) oppure il relativo cmdlet PowerShell, eseguito da chi possiede il ruolo di Cloud Application Administrator. Revocare una concessione non impedisce inoltre allo stesso utente di dare nuovamente il consenso la volta successiva in cui l'app lo richiede: per impedirlo occorre modificare separatamente la policy di consenso del tenant, in Enterprise apps → Consent and permissions → User consent settings.

Cosa succede quando un utente incontra un permesso che non può concedere da solo?

Se un tenant limita lo user consent, una persona che tenta di accedere a un'app che richiede un permesso superiore a tale limite si trova di fronte a un blocco anziché a una concessione. Un Global Administrator può attivare il flusso di lavoro di admin consent in Enterprise apps → Consent and permissions → Admin consent settings, che consente a quella persona di inviare una richiesta: questa viene recapitata via email agli utenti, gruppi o ruoli impostati come revisori, i quali possono approvarla, bloccarla o negarla dalla propria scheda My Pending. Solo un Global Administrator può approvare una richiesta relativa a permessi applicativi di Microsoft Graph — essere nominato revisore non conferisce di per sé questo privilegio. Ogni richiesta scade inoltre dopo un numero configurabile di giorni, così una richiesta non esaminata non resta aperta a tempo indeterminato.

E se la mia organizzazione si estende su più tenant Microsoft 365 o su una directory partner?

Una revisione all'interno di un singolo tenant mostra solo quel tenant. Se la vostra organizzazione opera su più directory Microsoft 365 — una società madre e una controllata acquisita, per esempio, oppure il tenant proprio di un partner — ciascuna richiede lo stesso percorso separatamente, con accesso effettuato con il ruolo corretto in ognuna. Gli strumenti pensati per un singolo tenant fisso smettono di funzionare non appena entra in gioco una seconda directory, quindi qualsiasi strumento destinato a coprire più tenant deve poter ottenere il consenso dalla directory propria di qualsiasi organizzazione, non solo da quella per cui è stato originariamente configurato.

Cosa non può dirvi una revisione app per app, e come risponde 8200.dev?

Esaminare le Enterprise applications un'app alla volta vi dice cosa ciascuna app è *autorizzata* a raggiungere. Non classifica le app in base al rischio effettivo che rappresentano, non segnala quali concessioni sono ormai obsolete e non resta ferma mentre esaminate l'elenco — un nuovo consenso può arrivare mentre state ancora esaminando l'ultimo. Il connettore Microsoft 365 di 8200.dev legge Sites, Files, Directory, Application registrations, Users, le policy di sicurezza del tenant, i report di registrazione MFA, i log di audit, le assegnazioni di ruolo e le concessioni di permessi delegati — tutto tramite scope Graph in sola lettura — e li trasforma in un inventario unico, con punteggio di rischio, aggiornato continuamente anziché in un elenco da riaprire manualmente. Lo stesso accesso in sola lettura esegue anche un audit di configurazione a livello di tenant insieme all'inventario delle app: stato dei Security Defaults e delle policy di Conditional Access, policy di consenso app e impostazioni di collaborazione esterna, cosicché un'app con permessi eccessivi e una policy di tenant allentata che le ha permesso di entrare compaiano insieme invece che in due revisioni separate e scollegate. Si collega allo stesso modo alla directory Microsoft work o school propria di qualsiasi organizzazione, quindi un gruppo che si estende su più tenant non richiede una configurazione separata per ciascuno. Ogni scope qui elencato è in sola lettura: nulla modifica un permesso o una policy a meno che l'organizzazione non scelga separatamente di automatizzare un'azione specifica.

Consultate l'elenco completo dei connettori per vedere come questo si integra con Google Workspace, Slack e GitHub.