In een standaard Microsoft Entra ID-tenant kan elke gebruiker een app van een derde partij goedkeuren die zijn mailbox leest, zonder dat iemand bij IT daarnaar wordt gevraagd. Als u deze instelling nooit hebt beoordeeld, ga er dan van uit dat er al grants bestaan en controleer ze voordat u het beleid wijzigt.
Wat de standaardinstelling toestaat
Een gebruiker kan toestemming geven aan een app die zijn eigen mailbox leest. Hij kan een app geen onbeperkte lees- en schrijftoegang geven tot alle bestanden in de organisatie, want daarvoor is een beheerder nodig. Microsoft raadt aan gebruikerstoestemming alleen toe te staan voor apps van een verified publisher, om het risico te verkleinen dat kwaadaardige apps gebruikers verleiden toegang te verlenen.
Een grant is ook geen wachtwoord. Onder OAuth 2.0 (RFC 6749) ontvangt de app een access token met een vastgelegde scope en levensduur, uitgegeven in plaats van de inloggegevens van de gebruiker. De grant is een eigen object, dat u zelf moet opsporen en verwijderen.
Overzicht van verleende toestemmingen
U hebt minimaal de rol Cloud Application Administrator of Application Administrator nodig. Ga in het Microsoft Entra admin center naar Entra ID > Enterprise apps > All applications, selecteer de app en open Permissions. Het tabblad Admin consent toont de rechten die voor de hele organisatie zijn verleend. Het tabblad User consent toont wat specifieke gebruikers of groepen hebben verleend.
Het portaal werkt per app, dus voor een overzicht van de hele tenant hebt u een lus nodig. De Graph-endpoints in de Microsoft-richtlijnen voor het intrekken van rechten gelden elk voor één service principal: oauth2PermissionGrants geeft delegated permissions terug en appRoleAssignments geeft application permissions terug. Het onderstaande script gebruikt de equivalente cmdlets en zet ID's om naar namen, inclusief application roles zoals Mail.Read:
Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All","AppRoleAssignment.ReadWrite.All"
$sps = Get-MgServicePrincipal -All
$name = @{}
$role = @{}
foreach ($s in $sps) {
$name[$s.Id] = $s.DisplayName
foreach ($r in $s.AppRoles) { $role["$($s.Id)|$($r.Id)"] = $r.Value }
}
$rows = @()
foreach ($g in Get-MgOauth2PermissionGrant -All) {
$rows += [pscustomobject]@{ App=$name[$g.ClientId]; Type="Delegated"
Resource=$name[$g.ResourceId]; Detail=$g.Scope }
}
foreach ($sp in $sps) {
$assigned = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All |
Where-Object { $_.PrincipalType -eq "ServicePrincipal" }
foreach ($a in $assigned) {
$rows += [pscustomobject]@{ App=$sp.DisplayName; Type="Application"
Resource=$name[$a.ResourceId]; Detail=$role["$($a.ResourceId)|$($a.AppRoleId)"] }
}
}
$rows | Export-Csv consent-audit.csv -NoTypeInformation
Deze scopes komen uit de voorbeelden van Microsoft voor het intrekken van rechten en omvatten schrijftoegang, die een audit met alleen leesrechten niet nodig heeft. Vraag smallere scopes aan als uw tenant dat toestaat en test het script eerst op een kleine set.
Volgorde van triage
Deze volgorde is van onszelf en geen richtlijn van Microsoft. Begin met delegated grants waarvan de scopes e-mail lezen of versturen of bestanden lezen. Filter de kolom Detail op Mail en Files. Neem daarna elke application permission door.
Een kwaadaardige grant ziet er in het portaal gewoon uit, met een plausibele naam en een paar scopes. Let op het patroon waarbij meerdere gebruikers toestemming geven aan dezelfde onbekende app van een uitgever die u niet kunt verifiëren. Als u zo'n grant vindt, behandel het dan als een incident en schakel ons incident response-team of uw eigen team in.
Risicovolle grants verwijderen
Open voor rechten die door beheerders zijn verleend het tabblad Admin consent, selecteer het ...-menu naast het recht en kies Revoke permission. Op het tabblad User consent kunt u in het portaal niets intrekken. Daarvoor hebt u Graph of PowerShell nodig.
Verwijder in Graph een delegated grant via zijn ID, of verwijder een application permission via het ID van de assignment:
DELETE https://graph.microsoft.com/v1.0/oAuth2PermissionGrants/{id}
DELETE https://graph.microsoft.com/v1.0/servicePrincipals/{resource-servicePrincipal-id}/appRoleAssignedTo/{appRoleAssignment-id}
De pagina over het intrekken van rechten bevat ook PowerShell-scripts die alle delegated en application permissions van één app verwijderen. Lees ze door voordat u ze uitvoert, want ze halen alles weg voor die service principal.
Intrekken weerhoudt een gebruiker er niet van dezelfde app opnieuw goed te keuren. Microsoft noemt twee oplossingen: voorkomen dat de app de rechten via dynamic consent aanvraagt, of gebruikerstoestemming volledig blokkeren. Bij apps van derden kunt u niet bepalen wat ze aanvragen, dus is blokkeren naar onze mening de maatregel die u zelf in handen hebt.
Gebruikerstoestemming beperken
U hebt de rol Privileged Role Administrator nodig. De rol Global Administrator is alleen vereist als u het admin center gebruikt, waar de instelling staat onder Identity > Applications > Enterprise apps > Consent and permissions > User consent settings.
Entra levert hiervoor twee ingebouwde beleidsregels mee:
| ID | Effect |
|---|---|
microsoft-user-default-low | Gebruikers geven alleen toestemming aan apps van verified publishers of apps die in uw tenant zijn geregistreerd, en alleen voor rechten die u als laag risico classificeert |
microsoft-user-default-legacy | Gebruikers geven toestemming voor elk recht waarvoor geen admin consent nodig is, voor elke applicatie |
Het low-beleid hangt af van uw classificatie van rechten, waarmee u bepaalt wat gebruikers mogen goedkeuren. Doe dat eerst en test daarna met een gewoon gebruikersaccount.
Haal voordat u iets wijzigt in PowerShell of Graph de huidige authorizationPolicy op. In uw tenant kunnen ManagePermissionGrantsForOwnedResource.*-beleidsregels zijn toegewezen, zoals die waarmee ontwikkelaars toestemming kunnen beheren voor apps die ze zelf bezitten. Houd ze in de collectie, anders verwijdert u ze. Gebruikerstoestemming uitschakelen met Graph PowerShell ziet er zo uit:
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"
$body = @{
"permissionGrantPolicyIdsAssignedToDefaultUserRole" = @(
"managePermissionGrantsForOwnedResource.{other-current-policies}"
)
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $body
Wilt u toestemming toestaan onder het low-impactbeleid, voeg dan managePermissionGrantsForSelf.microsoft-user-default-low toe aan de Graph PATCH van defaultUserRolePermissions.permissionGrantPoliciesAssigned. Een beleidswijziging geldt alleen voor toekomstige toestemming, dus bestaande grants blijven bestaan totdat u ze verwijdert.
Geef gebruikers een manier om te vragen
Als u toestemming blokkeert zonder alternatief, gaan gebruikers op zoek naar omwegen. Met de admin consent workflow kunnen ze in plaats daarvan om goedkeuring vragen. Een Global Administrator schakelt dit in onder Entra ID > Enterprise apps > Consent and permissions > Admin consent settings. Zet "Users can request admin consent to apps they are unable to consent to" op Yes en kies vervolgens:
- Reviewers: gebruikers, groepen of rollen. Reviewer zijn verhoogt iemands rechten niet, dus elke reviewer moet zelf al de rechten hebben om toestemming te verlenen voor de aangevraagde app. Alleen Global Administrators kunnen apps goedkeuren die Microsoft Graph app roles (application permissions) aanvragen.
- E-mailmeldingen: als u ze voor reviewers uitschakelt, worden ook de meldingen aan aanvragers uitgeschakeld.
- Geldigheid van aanvragen en herinneringen voor het verlopen: de geldigheid is het aantal dagen dat een aanvraag geldig blijft. De eerste herinnering komt ongeveer halverwege, dus op dag twee bij een aanvraag van drie dagen.
Sla op en wacht daarna maximaal een uur tot de workflow actief is. Een verwijderde reviewer houdt toegang tot aanvragen die zijn gedaan toen hij de rol had. Nieuwe reviewers kunnen niet handelen op aanvragen die zijn aangemaakt voordat zij werden toegevoegd.
Ingebouwde Entra-rollen, Exchange RBAC en Teams resource-specific consent kunnen ook toegang verlenen, dus betrek ze bij een bredere review.
Waar te beginnen
- Voer het inventarisatiescript uit en beoordeel delegated grants en application permissions als aparte lijsten. Markeer de apps die niemand kan verantwoorden.
- Trek de risicovolle grants in: de grants met admin consent in het portaal, de grants met gebruikerstoestemming via Graph of PowerShell.
- Lees de huidige
authorizationPolicyuit en zet gebruikerstoestemming daarna opmicrosoft-user-default-lowmet geclassificeerde rechten, of schakel het uit en behoud deManagePermissionGrantsForOwnedResource.*-items. - Schakel de admin consent workflow in. Wijs reviewers aan met rollen die toestemming kunnen verlenen voor wat gebruikers zullen aanvragen, en houd een Global Administrator in de groep, omdat alleen die rol Microsoft Graph application permissions goedkeurt.
- Herhaal de review volgens een vast schema. Ontbreekt de tijd, dan kan ons consultingteam het uitvoeren als assessment en kan onze managed security-dienst de monitoring afdekken.
