Badanie złamanych zabezpieczeń i złośliwych aplikacji

Ten artykuł zawiera wskazówki dotyczące identyfikowania i badania złośliwych ataków na co najmniej jedną aplikację w dzierżawie klienta. Instrukcje krok po kroku pomogą Ci wykonać wymagane działania naprawcze w celu ochrony informacji i zminimalizowania dalszych zagrożeń.

  • Wymagania wstępne: Obejmuje określone wymagania, które należy wykonać przed rozpoczęciem badania. Na przykład rejestrowanie, które powinno być włączone, wymagane są między innymi role i uprawnienia.
  • Przepływu pracy: Przedstawia przepływ logiczny, który należy wykonać, aby wykonać to badanie.
  • Kroki badania: Zawiera szczegółowe wskazówki krok po kroku dotyczące tego konkretnego badania.
  • Kroki zawierania: Zawiera kroki wyłączania naruszonych aplikacji.
  • Kroki odzyskiwania: Zawiera ogólne kroki dotyczące odzyskiwania/eliminowania złośliwego ataku na naruszone aplikacje.
  • Odwołania: Zawiera dodatkowe materiały do czytania i materiałów referencyjnych.

Wymagania wstępne

Przed rozpoczęciem badania upewnij się, że masz odpowiednie narzędzia i uprawnienia, aby zebrać szczegółowe informacje o aplikacjach, których bezpieczeństwo ma zostać naruszone przez złośliwy atak.

Wymagane narzędzia

Aby przeprowadzić skuteczne badanie, zainstaluj następujący moduł programu PowerShell i zestaw narzędzi na maszynie badania:

Przepływ pracy

Detailed flow of the investigation steps

Kroki badania

W ramach tego badania przyjęto założenie, że istnieje wskazanie potencjalnego naruszenia zabezpieczeń aplikacji w postaci raportu użytkownika, przykładu dzienników logowania usługi Azure AD lub wykrywania ochrony tożsamości. Pamiętaj, aby ukończyć i włączyć wszystkie wymagane kroki wymagań wstępnych.

Ten podręcznik jest tworzony z zamiarem, że nie wszyscy klienci firmy Microsoft i ich zespoły badania będą mieć pełny pakiet licencji Microsoft 365 E5 lub Azure AD Premium P2 dostępny lub skonfigurowany w badanej dzierżawie. Jednak w razie potrzeby wyróżnimy dodatkowe możliwości automatyzacji.

Określanie typu aplikacji

Ważne jest, aby określić typ aplikacji (wielodostępnej lub pojedynczej) na wczesnym etapie badania, aby uzyskać poprawne informacje potrzebne do skontaktowania się z właścicielem aplikacji. Aby uzyskać więcej informacji, zobacz Dzierżawa w usłudze Azure Active Directory.

Aplikacje wielodostępne

W przypadku aplikacji z wieloma dzierżawami aplikacja jest hostowana i zarządzana przez inną firmę. Zidentyfikuj proces wymagany do skontaktowania się z właścicielem aplikacji i zgłaszania problemów.

Aplikacje z jedną dzierżawą

Znajdź szczegóły kontaktowe właściciela aplikacji w organizacji. Można go znaleźć na karcie Właściciele w sekcji Aplikacje dla przedsiębiorstw . Alternatywnie organizacja może mieć bazę danych zawierającą te informacje.

Możesz również wykonać to zapytanie programu Microsoft Graph:

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

Sprawdzanie tożsamości usługi Identity Protection — ryzykowne tożsamości obciążeń

Ta funkcja jest dostępna w wersji zapoznawczej podczas pisania tego podręcznika i wymagania licencyjne będą miały zastosowanie do jego użycia. Ryzykowne tożsamości obciążeń mogą być wyzwalaczem do zbadania jednostki usługi, ale może również służyć do dalszego zbadania innych wyzwalaczy, które mogły zostać zidentyfikowane. Stan ryzyka jednostki usługi można sprawdzić przy użyciu karty Identity Protection — ryzykownych tożsamości obciążeń lub interfejsu API programu Microsoft Graph.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Sprawdzanie nietypowego zachowania logowania

Pierwszym krokiem badania jest wyszukanie dowodów na nietypowe wzorce uwierzytelniania w użyciu jednostki usługi. W witrynie Azure Portal, usłudze Azure Monitor, usłudze Azure Sentinel lub systemie zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) wybranej organizacji poszukaj następujących informacji w sekcji Logowania główne usługi :

  • Lokalizacja — czy jednostka usługi uwierzytelnia się z lokalizacji\adresów IP, których nie można oczekiwać?
  • Błędy — czy istnieje duża liczba błędów uwierzytelniania dla jednostki usługi?
  • Znaczniki czasu — czy istnieją pomyślne uwierzytelnienia, które występują czasami, których nie można oczekiwać?
  • Częstotliwość — czy istnieje zwiększona częstotliwość uwierzytelniania dla jednostki usługi?
  • Przeciek poświadczeń — czy wszystkie poświadczenia aplikacji są zakodowane i publikowane w publicznym źródle, na przykład GitHub?

Jeśli wdrożono usługę Identity Protection — ryzykowne tożsamości obciążeń, sprawdź wykryte podejrzane logowania i wyciek poświadczeń. Aby uzyskać więcej informacji, zobacz zatrzymania ryzyka związane z tożsamościami obciążeń.

Sprawdzanie zasobu docelowego

W obszarze Logowania jednostki usługi sprawdź również zasób , do którego uzyskuje dostęp jednostka usługi podczas uwierzytelniania. Ważne jest, aby dane wejściowe od właściciela aplikacji były znane, do których zasobów powinna uzyskiwać dostęp jednostka usługi.

Check the Resource for Service Principal

Sprawdzanie nietypowych zmian poświadczeń

Użyj dzienników inspekcji, aby uzyskać informacje o zmianach poświadczeń w aplikacjach i jednostkach usługi. Filtruj według kategorii według zarządzania aplikacjami i działania według aktualizacji aplikacji — certyfikaty i zarządzanie wpisami tajnymi.

  • Sprawdź, czy nowo utworzone lub nieoczekiwane poświadczenia są przypisane do jednostki usługi.
  • Sprawdź poświadczenia w jednostce usługi przy użyciu interfejsu API programu Microsoft Graph.
  • Sprawdź zarówno aplikację, jak i skojarzone obiekty jednostki usługi.
  • Sprawdź dowolną rolę niestandardową , która mogła zostać utworzona lub zmodyfikowana. Zwróć uwagę na uprawnienia oznaczone poniżej:

Check custom roles that may be created or modified

Jeśli wdrożono dodatek dotyczący ładu aplikacji, sprawdź w witrynie Azure Portal alerty dotyczące aplikacji. Aby uzyskać więcej informacji, zobacz Wprowadzenie do wykrywania i korygowania zagrożeń aplikacji.

Jeśli wdrożono usługę Identity Protection, sprawdź raport "Wykrycia ryzyka" i w tożsamości użytkownika lub obciążenia "historia ryzyka".

Risk Detection portal

Jeśli wdrożono usługę Microsoft Defender for Cloud Apps, upewnij się, że włączono zasady "Nietypowe dodawanie poświadczeń do aplikacji OAuth" i sprawdź otwarte alerty. Aby uzyskać więcej informacji, zobacz Nietypowe dodawanie poświadczeń do aplikacji OAuth.

Ponadto możesz wykonywać zapytania dotyczące interfejsów API servicePrincipalRiskDetections i user riskDetections , aby pobrać te wykrycia ryzyka.

Wyszukiwanie nietypowych zmian konfiguracji aplikacji

  • Sprawdź uprawnienia interfejsu API przypisane do aplikacji, aby upewnić się, że uprawnienia są zgodne z oczekiwaniami aplikacji.
  • Sprawdź dzienniki inspekcji ( filtruj aktywność według aktualizacji aplikacji lub jednostki usługi aktualizacji).
  • Upewnij się, że parametry połączenia są spójne i czy adres URL wylogowywania został zmodyfikowany.
  • Sprawdź, czy domeny w adresie URL są zgodne z domenami zarejestrowanymi.
  • Ustal, czy ktoś dodał nieautoryzowany adres URL przekierowania.
  • Potwierdź własność identyfikatora URI przekierowania, którego jesteś właścicielem, aby upewnić się, że nie wygaśnie i został odrzucony przez przeciwnika.

Ponadto jeśli wdrożono usługę Microsoft Defender for Cloud Apps, sprawdź w witrynie Azure Portal alerty dotyczące aktualnie badanej aplikacji. Nie wszystkie zasady alertów są domyślnie włączone dla aplikacji OAuth, dlatego upewnij się, że wszystkie te zasady są włączone. Aby uzyskać więcej informacji, zobacz zasady aplikacji OAuth. Możesz również wyświetlić informacje na temat prewalansu aplikacji i ostatnich działań na karcie Badanie>aplikacji OAuth .

Sprawdzanie podejrzanych ról aplikacji

  • Można to również zbadać przy użyciu dzienników inspekcji. Filtruj działanie według dodaj przypisanie roli aplikacji do jednostki usługi.
  • Sprawdź, czy przypisane role mają wysokie uprawnienia.
  • Upewnij się, że te uprawnienia są niezbędne.

Sprawdzanie niezweryfikowanych aplikacji komercyjnych

  • Sprawdź, czy są używane aplikacje z galerii komercyjnej (opublikowane i zweryfikowane wersje).

Sprawdź, czy nie ma oznak ujawnienia informacji o właściwości keyCredential

Przejrzyj dzierżawę pod kątem potencjalnego ujawnienia informacji o właściwości keyCredential zgodnie z opisem w artykule CVE-2021-42306.

Aby zidentyfikować i skorygować aplikacje usługi Azure AD skojarzone z kontami usługi Automation Run-As, przejdź do wskazówek dotyczących korygowania w repozytorium GitHub.

Ważne

Dowody naruszenia: Jeśli odkryjesz dowody naruszenia zabezpieczeń, ważne jest, aby wykonać kroki wyróżnione w sekcjach zawierania i odzyskiwania. Pomoże to wyeliminować ryzyko, ale będzie potrzebować dalszych badań w celu zrozumienia źródła kompromisu, aby uniknąć dalszego wpływu i zapewnić usunięcie złych podmiotów.

Istnieją dwie podstawowe metody uzyskiwania dostępu do systemów za pośrednictwem aplikacji. Pierwszy polega na tym, że aplikacja jest wyrażana przez administratora lub użytkownika, zwykle za pośrednictwem ataku wyłudzania informacji. Jest to część początkowego dostępu do systemu i jest często nazywana "wyłudzaniem zgody".

Druga metoda obejmuje już naruszone konto administratora tworzące nową aplikację na potrzeby trwałości, zbierania danych i pozostania pod radarem. Na przykład aplikacja OAuth może zostać utworzona przez naruszonego administratora z pozornie nieszkodliwą nazwą, unikając wykrywania i zezwalania na długoterminowy dostęp do danych bez konieczności posiadania konta. Jest to często spotykane w atakach państwa narodowego.

Poniżej przedstawiono niektóre kroki, które można podjąć w celu dalszej analizy.

Sprawdź ujednolicony dziennik inspekcji usługi M365 (UAL) pod kątem wskazania wyłudzania informacji z ostatnich 7 dni

Czasami, gdy osoby atakujące używają złośliwych lub naruszonych aplikacji jako środka trwałości lub eksfiltracji danych, jest zaangażowana kampania wyłudzania informacji. Na podstawie wyników z poprzednich kroków należy przejrzeć tożsamości:

  • Właściciele aplikacji
  • Administratorzy zgody

Przejrzyj tożsamości pod kątem oznak ataków wyłudzających informacje w ciągu ostatnich 24 godzin. Zwiększ ten przedział czasu w razie potrzeby do 7, 14 i 30 dni, jeśli nie ma natychmiastowych wskazówek. Aby zapoznać się ze szczegółowym podręcznikiem badania wyłudzania informacji, zobacz podręcznik badania wyłudzania informacji.

Wyszukiwanie zgody złośliwych aplikacji przez ostatnie 7 dni

Aby dodać aplikację do dzierżawy, osoby atakujące fałszować użytkowników lub administratorów, aby wyrazić zgodę na aplikacje. Aby dowiedzieć się więcej na temat oznak ataku, zobacz podręcznik Application Consent Grant Investigation (Podręcznik udzielania zgody aplikacji).

Sprawdzanie dzienników inspekcji

Aby wyświetlić wszystkie udzielenie zgody dla tej aplikacji, odfiltruj działanie według zgody na aplikację.

  • Korzystanie z dzienników inspekcji portalu usługi Azure AD

  • Wykonywanie zapytań dotyczących dzienników inspekcji przy użyciu programu Microsoft Graph

    a) Filtruj dla określonego przedziału czasu:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) Filtruj dzienniki inspekcji pod kątem wpisów dziennika inspekcji "Zgoda na aplikacje":

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) Korzystanie z usługi Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Aby uzyskać więcej informacji, zobacz podręcznik Zgody aplikacji na badanie.

Użytkownik może autoryzować aplikację do uzyskiwania dostępu do niektórych danych w chronionym zasobie, działając jako ten użytkownik. Uprawnienia zezwalające na dostęp tego typu są nazywane "uprawnieniami delegowanymi" lub zgodą użytkownika.

Aby znaleźć aplikacje, na które wyrazili zgodę użytkownicy, użyj usługi LogAnalytics, aby wyszukać dzienniki inspekcji:

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

Sprawdź dzienniki inspekcji, aby dowiedzieć się, czy przyznane uprawnienia są zbyt szerokie (w całej dzierżawie lub zgody administratora)

Przeglądanie uprawnień przyznanych aplikacji lub jednostki usługi może być czasochłonnym zadaniem. Zacznij od zrozumienia potencjalnie ryzykownych uprawnień w usłudze Azure AD.

Teraz postępuj zgodnie ze wskazówkami dotyczącymi sposobu wyliczania i przeglądania uprawnień w ramach badania udzielania zgody aplikacji.

Sprawdź, czy uprawnienia zostały przyznane przez tożsamości użytkowników, które nie powinny mieć takiej możliwości, czy akcje zostały wykonane w dziwnych datach i godzinach

Przejrzyj przy użyciu dzienników inspekcji:

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

Możesz również użyć dzienników inspekcji usługi Azure AD, filtrując według wyrażenia zgody na aplikację. W sekcji Szczegóły dziennika inspekcji kliknij pozycję Zmodyfikowane właściwości, a następnie przejrzyj sekcję ConsentAction.Permissions:

Use the Azure AD Audit Logs

Kroki zawierania

Po zidentyfikowaniu co najmniej jednej aplikacji lub tożsamości obciążenia jako złośliwej lub naruszonej zabezpieczeń możesz nie od razu chcieć wdrożyć poświadczeń dla tej aplikacji ani natychmiast usunąć aplikację. Zdecydowanie zaleca się przestrzeganie wskazówek dotyczących najlepszych rozwiązań dotyczących reagowania na zdarzenia.

Ważne

Przed wykonaniem poniższego kroku organizacja musi rozważyć wpływ zabezpieczeń i wpływ na działalność biznesową wyłączania aplikacji. Jeśli wpływ na firmę wyłączenia aplikacji jest zbyt duży, rozważ przygotowanie i przejście do etapu odzyskiwania tego procesu.

Wyłączanie aplikacji z naruszonym zabezpieczeniami

Typowa strategia zawierania obejmuje wyłączenie logowania się do zidentyfikowanej aplikacji w celu nadania zespołowi reagowania na zdarzenia lub czasowi jednostki biznesowej, którego dotyczy problem, w celu oceny wpływu usunięcia lub rolowania klucza. Jeśli badanie prowadzi do przekonania, że poświadczenia konta administratora również zostały naruszone, tego typu działania powinny być koordynowane ze zdarzeniem eksmisji, aby upewnić się, że wszystkie trasy dostępu do dzierżawy są odcięte jednocześnie.

Toggle to disable users to sign-in

Możesz również użyć następującego kodu programu PowerShell, aby wyłączyć logowanie do aplikacji:

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
   # Service principal exists already, disable it
   Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   $servicePrincipal = New-AzureADServicePrincipal -AppId $appId -AccountEnabled $false
}

Kroki odzyskiwania

Korygowanie jednostek usługi

  1. Wyświetl listę wszystkich poświadczeń przypisanych do ryzykownych jednostek usługi. Najlepszym sposobem na to jest wykonanie wywołania programu Microsoft Graph przy użyciu polecenia GET ~/application/{id}, gdzie przekazany identyfikator to identyfikator obiektu aplikacji.

    • Przeanalizuj dane wyjściowe dla poświadczeń. Dane wyjściowe mogą zawierać wartości passwordCredentials lub keyCredentials. Zarejestruj identyfikatory keyId dla wszystkich.

      "keyCredentials": [],
           "parentalControlSettings": {
               "countriesBlockedForMinors": [],
               "legalAgeGroupRule": "Allow"
           },
           "passwordCredentials": [
               {
                   "customKeyIdentifier": null,
                   "displayName": "Test",
                   "endDateTime": "2021-12-16T19:19:36.997Z",
                   "hint": "7~-",
                   "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
                   "secretText": null,
                   "startDateTime": "2021-06-16T18:19:36.997Z"
               }
           ],
      
  2. Dodaj nowe poświadczenia certyfikatu (x509) do obiektu aplikacji przy użyciu interfejsu API addKey aplikacji.

    POST ~/applications/{id}/addKey
    
  3. Natychmiast usuń wszystkie stare poświadczenia. Dla każdego starego poświadczenia hasła usuń je przy użyciu:

    POST ~/applications/{id}/removePassword
    

    Dla każdego starego poświadczenia klucza usuń je przy użyciu:

    POST ~/applications/{id}/removeKey
    
  4. Koryguj wszystkie jednostki usługi skojarzone z aplikacją. Postępuj zgodnie z tym, jeśli dzierżawa hostuje/rejestruje aplikację z wieloma dzierżawami i/lub rejestruje wiele jednostek usługi skojarzonych z aplikacją. Wykonaj podobne kroki do wymienionych powyżej:

  • GET ~/servicePrincipals/{id}

  • Znajdź wartości passwordCredentials i keyCredentials w odpowiedzi, rejestruj wszystkie stare identyfikatory keyId

  • Usuń wszystkie stare poświadczenia hasła i klucza. Używać:

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.
    

Korygowanie zasobów jednostki usługi, których dotyczy problem

Koryguj wpisy tajne usługi KeyVault, do których jednostka usługi ma dostęp, obracając je w następującym priorytecie:

  • Wpisy tajne udostępniane bezpośrednio za pomocą wywołań GetSecret .
  • Pozostałe wpisy tajne w ujawnionych magazynach kluczy.
  • Pozostałe wpisy tajne w uwidocznionych subskrypcjach.

Aby uzyskać więcej informacji, zobacz Interaktywne usuwanie i przewracywanie certyfikatów i wpisów tajnych jednostki usługi lub aplikacji.

Aby uzyskać wskazówki dotyczące usługi Azure AD SecOps dotyczące aplikacji, zobacz Przewodnik dotyczący operacji zabezpieczeń usługi Azure Active Directory dla aplikacji.

W kolejności priorytetu ten scenariusz będzie następujący:

  • Zaktualizuj dokumentacja poleceń cmdlet programu PowerShell programu Graph (Add/Remove ApplicationKey + ApplicationPassword), aby uwzględnić przykłady przerzucania poświadczeń.
  • Dodaj niestandardowe polecenia cmdlet do programu Microsoft Graph PowerShell, które upraszczają ten scenariusz.

Wyłączanie lub usuwanie złośliwych aplikacji

Aplikację można wyłączyć lub usunąć. Aby wyłączyć aplikację, w obszarze Włączone dla użytkowników do logowania przejdź do przełącznika Nie.

Aplikację można usunąć tymczasowo lub trwale w witrynie Azure Portal lub za pośrednictwem interfejsu API programu Microsoft Graph. Po usunięciu nietrwałym aplikacja może zostać odzyskana do 30 dni po usunięciu.

DELETE /applications/{id}

Aby trwale usunąć aplikację, użyj tego wywołania interfejsu API programu Microsoft Graph:

DELETE /directory/deletedItems/{id}

Jeśli wyłączysz lub usuniesz aplikację nietrwale, skonfiguruj monitorowanie w dziennikach inspekcji usługi Azure AD, aby dowiedzieć się, czy stan zmieni się z powrotem na włączony lub odzyskany.

Rejestrowanie dla włączonego:

  • Usługa — katalog podstawowy
  • Typ działania — aktualizowanie jednostki usługi
  • Kategoria — zarządzanie aplikacjami
  • Zainicjowane przez (aktor) — nazwa UPN aktora
  • Cele — identyfikator aplikacji i nazwa wyświetlana
  • Zmodyfikowane właściwości — Nazwa właściwości = włączone konto, nowa wartość = true

Rejestrowanie dla odzyskanych danych:

  • Usługa — katalog podstawowy
  • Typ działania — dodawanie jednostki usługi
  • Kategoria — zarządzanie aplikacjami
  • Zainicjowane przez (aktor) — nazwa UPN aktora
  • Cele — identyfikator aplikacji i nazwa wyświetlana
  • Zmodyfikowane właściwości — nazwa właściwości = włączone konto, nowa wartość = true

Implementowanie usługi Identity Protection dla tożsamości obciążeń

Podejrzane logowania: gdy wykrywanie ryzyka wskazuje nietypowe właściwości lub wzorce logowania, a także nietypowe dodawanie poświadczeń do aplikacji OAuth, może to być wskaźnik naruszenia zabezpieczeń. Zachowanie logowania punktów odniesienia wykrywania między 2 a 60 dniami i jest uruchamiane, jeśli podczas kolejnego logowania wystąpi co najmniej jedna z następujących nieznanych właściwości:

  • Adres IP/nazwa ASN
  • Zasób docelowy
  • Agent użytkownika
  • Zmiana adresu IP hostingu/bez hostingu
  • Kraj IP
  • Typ poświadczeń

Po wyzwoleniu tego wykrywania konto jest oznaczone jako wysokie ryzyko, ponieważ może to wskazywać na przejęcie konta dla aplikacji podmiotu. Należy pamiętać, że prawidłowe zmiany konfiguracji aplikacji czasami wyzwalają to wykrywanie.

Aby uzyskać więcej informacji, zobacz Zabezpieczanie tożsamości obciążeń za pomocą usługi Identity Protection.

Te alerty są wyświetlane w portalu usługi Identity Protection i można je wyeksportować do narzędzi SIEM za pośrednictwem interfejsów API usługi Identity Protection.

Review risks and alerts in the Identity Protection portal

Dostęp warunkowy dla ryzykownych tożsamości obciążeń

Dostęp warunkowy umożliwia blokowanie dostępu dla określonych kont, które są wyznaczane, gdy usługa Identity Protection oznacza je jako "zagrożone". Należy pamiętać, że wymuszanie za pośrednictwem dostępu warunkowego jest obecnie ograniczone tylko do aplikacji z jedną dzierżawą.

Control user access based on conditional access policy

Aby uzyskać więcej informacji, zobacz Dostęp warunkowy dla tożsamości obciążeń.

Implementowanie zasad ryzyka aplikacji

Przejrzyj ustawienia zgody użytkownika w obszarzeAplikacje> dla przedsiębiorstw w usłudze Azure Active Directory>Zgoda i uprawnienia>Ustawienia zgody użytkownika.

Select Allow user consent for apps from the options

Aby przejrzeć opcje konfiguracji, zobacz Konfigurowanie sposobu wyrażania zgody przez użytkowników na aplikacje.

Gdy deweloper aplikacji kieruje użytkowników do punktu końcowego zgody administratora z zamiarem wyrażenia zgody dla całej dzierżawy, jest to nazywane przepływem zgody administratora. Aby zapewnić prawidłowe działanie przepływu zgody administratora, deweloperzy aplikacji muszą wyświetlić listę wszystkich uprawnień we właściwości RequiredResourceAccess w manifeście aplikacji.

Większość organizacji wyłącza możliwość wyrażania zgody na aplikacje przez użytkowników. Aby umożliwić użytkownikom nadal żądanie zgody dla aplikacji i mieć możliwość przeglądu administracyjnego, zaleca się zaimplementowanie przepływu pracy zgody administratora. Wykonaj kroki przepływu pracy zgody administratora , aby skonfigurować go w dzierżawie.

W przypadku operacji z wysokim poziomem uprawnień, takich jak zgoda administratora, masz strategię uprzywilejowanego dostępu zdefiniowaną zgodnie z naszymi wskazówkami.

Zgoda krokowa oparta na ryzyku pomaga zmniejszyć narażenie użytkowników na złośliwe aplikacje. Na przykład żądania zgody dla nowo zarejestrowanych aplikacji wielodostępnych, które nie są zweryfikowane przez wydawcę i wymagają uprawnień innych niż podstawowe, są uznawane za ryzykowne. Jeśli zostanie wykryte ryzykowne żądanie zgody użytkownika, zamiast tego żądanie wymaga "kroku" zgody administratora. Ta funkcja kroku jest domyślnie włączona, ale powoduje zmianę zachowania tylko wtedy, gdy zgoda użytkownika jest włączona.

Upewnij się, że jest ona włączona w dzierżawie i zapoznaj się z ustawieniami konfiguracji opisanymi tutaj.

Odwołania

Dodatkowe podręczniki reagowania na zdarzenia

Zapoznaj się ze wskazówkami dotyczącymi identyfikowania i badania tych dodatkowych typów ataków:

Zasoby reagowania na zdarzenia