Audyt zgód aplikacji OAuth w Microsoft Entra ID

W domyślnie skonfigurowanym tenancie Microsoft Entra ID każdy użytkownik może zatwierdzić zewnętrzną aplikację, która czyta jego skrzynkę pocztową, a nikt z IT nie zostaje o to zapytany. Jeśli nigdy nie przeglądałeś tego ustawienia, załóż, że część zgód już istnieje, i przeprowadź ich audyt, zanim zmienisz politykę.

Co dopuszcza konfiguracja domyślna

Użytkownik może zgodzić się, by aplikacja czytała jego własną skrzynkę. Nie może natomiast przyznać aplikacji nieograniczonego dostępu do odczytu i zapisu wszystkich plików w organizacji, bo wymaga to administratora. Microsoft zaleca, by zgodę użytkownika dopuszczać tylko dla aplikacji od zweryfikowanego wydawcy (verified publisher), co zmniejsza ryzyko, że złośliwe aplikacje podstępem wyłudzą dostęp.

Zgoda to także nie hasło. Zgodnie z OAuth 2.0 (RFC 6749) aplikacja otrzymuje token dostępu o określonym zakresie i czasie ważności, wydany zamiast danych uwierzytelniających użytkownika. Zgoda jest odrębnym obiektem i musisz sam ją znaleźć i usunąć.

Wylistuj przyznane zgody

Potrzebujesz co najmniej roli Cloud Application Administrator lub Application Administrator. W Microsoft Entra admin center przejdź do Entra ID > Enterprise apps > All applications, wybierz aplikację i otwórz Permissions. Zakładka Admin consent pokazuje uprawnienia przyznane dla całej organizacji. Zakładka User consent pokazuje, co przyznali konkretni użytkownicy lub grupy.

Portal działa aplikacja po aplikacji, więc widok całego tenanta wymaga pętli. Endpointy Graph opisane w wytycznych Microsoft dotyczących cofania zgód dotyczą każdy jednego service principal: oauth2PermissionGrants zwraca uprawnienia delegowane, a appRoleAssignments zwraca uprawnienia aplikacji. Poniższy skrypt używa równoważnych cmdletów i zamienia identyfikatory na nazwy, w tym role aplikacji, takie jak 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

Te zakresy pochodzą z przykładów Microsoft dotyczących cofania zgód i obejmują dostęp do zapisu, którego audyt tylko do odczytu nie potrzebuje. Jeśli tenant na to pozwala, zażądaj węższych zakresów, a skrypt najpierw przetestuj na niewielkim zbiorze.

Kolejność triage

Ta kolejność jest naszą propozycją, a nie wytyczną Microsoft. Zacznij od zgód delegowanych, których zakresy pozwalają czytać lub wysyłać pocztę albo czytać pliki. Przefiltruj kolumnę Detail pod kątem Mail i Files. Następnie weź na warsztat wszystkie uprawnienia aplikacji.

Złośliwa zgoda w portalu wygląda zwyczajnie: wiarygodna nazwa i kilka zakresów. Wzorzec, na który warto zwrócić uwagę, to wielu użytkowników zgadzających się na tę samą nieznaną aplikację od wydawcy, którego nie możesz zweryfikować. Jeśli ją znajdziesz, potraktuj to jak incydent i zaangażuj nasz zespół reagowania na incydenty lub własny.

Usuń ryzykowne zgody

Aby usunąć uprawnienia przyznane przez administratorów, otwórz zakładkę Admin consent, wybierz kontrolkę ... obok uprawnienia i kliknij Revoke permission. Na zakładce User consent w portalu niczego nie cofniesz. W takim przypadku potrzebujesz Graph lub PowerShell.

W Graph usuniesz zgodę delegowaną po jej identyfikatorze albo uprawnienie aplikacji po identyfikatorze przypisania:

DELETE https://graph.microsoft.com/v1.0/oAuth2PermissionGrants/{id}
DELETE https://graph.microsoft.com/v1.0/servicePrincipals/{resource-servicePrincipal-id}/appRoleAssignedTo/{appRoleAssignment-id}

Na stronie o cofaniu zgód są też skrypty PowerShell, które usuwają wszystkie uprawnienia delegowane i uprawnienia aplikacji jednej aplikacji. Przeczytaj je przed uruchomieniem, bo odbierają wszystko temu service principal.

Cofnięcie zgody nie powstrzymuje użytkownika przed ponownym zatwierdzeniem tej samej aplikacji. Microsoft wskazuje dwa środki zaradcze: sprawić, by aplikacja nie żądała uprawnień przez dynamic consent, albo całkowicie zablokować zgodę użytkownika. W przypadku aplikacji zewnętrznych nie zmienisz tego, o co proszą, więc naszym zdaniem to blokada jest kontrolą, którą masz w swoich rękach.

Ogranicz zgodę użytkowników

Potrzebujesz roli Privileged Role Administrator. Rola Global Administrator jest wymagana tylko wtedy, gdy korzystasz z admin center, gdzie ustawienie znajdziesz w Identity > Applications > Enterprise apps > Consent and permissions > User consent settings.

Entra zawiera dwie wbudowane polityki dla tego obszaru:

Polityka low zależy od tego, że sklasyfikujesz uprawnienia, a w ten sposób wybierasz, co użytkownicy mogą zatwierdzać. Zrób to najpierw, a potem przetestuj na zwykłym koncie użytkownika.

Zanim cokolwiek zmienisz w PowerShell lub Graph, pobierz aktualny authorizationPolicy. W Twoim tenancie mogą być przypisane polityki ManagePermissionGrantsForOwnedResource.*, na przykład ta, która pozwala deweloperom zarządzać zgodami dla aplikacji, których są właścicielami. Zostaw je w kolekcji, bo inaczej je usuniesz. Wyłączenie zgody użytkowników w Graph PowerShell wygląda tak:

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$body = @{
  "permissionGrantPolicyIdsAssignedToDefaultUserRole" = @(
    "managePermissionGrantsForOwnedResource.{other-current-policies}"
  )
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $body

Jeśli zamiast tego chcesz dopuścić zgodę w ramach polityki low-impact, dodaj managePermissionGrantsForSelf.microsoft-user-default-low do żądania PATCH w Graph dla defaultUserRolePermissions.permissionGrantPoliciesAssigned. Zmiana polityki dotyczy tylko przyszłych zgód, więc istniejące zostają na miejscu, dopóki ich nie usuniesz.

Daj użytkownikom sposób, by mogli poprosić o zgodę

Jeśli zablokujesz zgodę bez żadnej alternatywy, użytkownicy zaczną szukać obejść. Workflow zgody administratora (admin consent workflow) pozwala im zamiast tego poprosić o zatwierdzenie. Global Administrator włącza go w Entra ID > Enterprise apps > Consent and permissions > Admin consent settings. Ustaw "Users can request admin consent to apps they are unable to consent to" na Yes, a następnie wybierz:

• Reviewers: użytkownicy, grupy lub role. Bycie recenzentem nie podnosi uprawnień, więc każdy z nich musi już mieć uprawnienia do udzielenia zgody dla żądanej aplikacji. Tylko Global Administrators mogą zatwierdzać aplikacje żądające ról aplikacji Microsoft Graph (uprawnień aplikacji).
• Email notifications: jeśli wyłączysz je dla recenzentów, powiadomienia dla osób zgłaszających także zostaną wyłączone.
• Request lifetime i expiration reminders: czas życia to liczba dni, przez które wniosek pozostaje ważny. Pierwsze przypomnienie przychodzi mniej więcej w połowie tego okresu, czyli drugiego dnia przy wniosku trzydniowym.

Zapisz, a potem odczekaj do godziny, aż workflow zacznie działać. Usunięty recenzent zachowuje dostęp do wniosków złożonych, gdy miał tę rolę. Nowi recenzenci nie mogą działać na wnioskach utworzonych przed ich dodaniem.

Dostęp mogą też przyznawać wbudowane role Entra, Exchange RBAC oraz Teams resource-specific consent, więc uwzględnij je w szerszym przeglądzie.

Od czego zacząć

1. Uruchom skrypt inwentaryzacyjny i przejrzyj zgody delegowane oraz uprawnienia aplikacji jako osobne listy. Oznacz aplikacje, których nikt nie potrafi uzasadnić.
2. Cofnij ryzykowne zgody: te udzielone przez administratorów w portalu, a te udzielone przez użytkowników przez Graph lub PowerShell.
3. Odczytaj aktualny authorizationPolicy, a potem ustaw zgodę użytkowników na microsoft-user-default-low z sklasyfikowanymi uprawnieniami albo ją wyłącz, zachowując wpisy ManagePermissionGrantsForOwnedResource.*.
4. Włącz workflow zgody administratora. Wskaż recenzentów, których role pozwalają udzielać zgody na to, o co poproszą użytkownicy, i zachowaj wśród nich Global Administratora, bo tylko ta rola zatwierdza uprawnienia aplikacji Microsoft Graph.
5. Powtarzaj przegląd według harmonogramu. Jeśli brakuje Ci czasu, nasz zespół konsultingowy może przeprowadzić go jako assessment, a nasza usługa zarządzanego bezpieczeństwa może objąć monitoring.