Udostępnij za pośrednictwem

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

  • Artykuł

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 ułatwiają podjęcie wymaganych działań naprawczych 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ływ 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 zawierające: zawiera kroki wyłączania naruszonych aplikacji.
  • Kroki odzyskiwania: zawiera ogólne kroki dotyczące odzyskiwania/eliminowania złośliwego ataku na naruszone aplikacje.
  • Dokumentacja: zawiera inne materiały do czytania i materiałów referencyjnych.

Wymagania wstępne

Przed rozpoczęciem badania upewnij się, że masz odpowiednie narzędzia i uprawnienia do zbierania szczegółowych informacji.

Wymagane narzędzia

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

Przepływ pracy

Szczegółowy schemat blokowy kroków badania.

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 firmy Microsoft Entra 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 mają pełny pakiet licencji Microsoft 365 E5 lub Microsoft Entra ID P2 dostępny lub skonfigurowany. Ten podręcznik wyróżnia inne możliwości automatyzacji, jeśli jest to konieczne.

Określanie typu aplikacji

Ważne jest, aby określić typ aplikacji (wielodostępnej lub pojedynczej) na początku fazy 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 Microsoft Entra ID.

Aplikacje wielodostępne

W przypadku aplikacji wielodostępnych 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żesz ją 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 usługi Identity Protection — ryzykowne tożsamości obciążeń

Ta funkcja jest dostępna w wersji zapoznawczej podczas pisania tego podręcznika i wymagań dotyczących licencjonowania, które mają 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 zidentyfikowanych wyzwalaczy. Stan ryzyka jednostki usługi można sprawdzić przy użyciu karty Identity Protection — ryzykownych tożsamości obciążeń lub możesz użyć interfejsu API programu Microsoft Graph.

Zrzut ekranu przedstawiający stronę portalu Szczegóły wykrywania ryzyka.

Zrzut ekranu przedstawiający stronę interfejsu użytkownika szczegóły wykrywania ryzyka.

Przykład interfejsu API programu Graph wykrywania ryzyka jednostki usługi.

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 Microsoft Sentinel lub systemie zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) wybranej organizacji wyszukaj następujące elementy w sekcji Logowania główne usługi:

  • Lokalizacja — czy jednostka usługi uwierzytelnia się z lokalizacji\adresów IP, których nie oczekujesz?
  • Błędy — czy istnieje duża liczba niepowodzeń uwierzytelniania dla jednostki usługi?
  • Znaczniki czasu — czy występują pomyślne uwierzytelnienia występujące w czasie, którego nie można oczekiwać?
  • Częstotliwość — czy istnieje zwiększona częstotliwość uwierzytelniania dla jednostki usługi?
  • Wyciek 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ę Microsoft Entra ID Identity Protection — ryzykowne tożsamości obciążeń, sprawdź wykrycia podejrzanych logów i poświadczeń wycieku. Aby uzyskać więcej informacji, zobacz zatrzymanie ryzyka związanego z tożsamością obciążenia.

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 uzyskać dane wejściowe od właściciela aplikacji, ponieważ znają zasoby, do których jednostka usługi powinna uzyskiwać dostęp.

Zrzut ekranu przedstawiający sposób sprawdzania zasobu dla jednostki usługi.

Sprawdzanie nietypowych zmian poświadczeń

Użyj dzienników inspekcji, aby uzyskać informacje na temat zmian 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ą utworzoną lub zmodyfikowaną rolę niestandardową. Zanotuj uprawnienia oznaczone poniżej:

Zrzut ekranu przedstawiający sposób sprawdzania utworzonych lub zmodyfikowanych ról niestandardowych.

Jeśli wdrożono nadzór nad aplikacjami w usłudze Microsoft Defender dla Chmury Apps, sprawdź witrynę Azure Portal, aby uzyskać 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 "Wykrywanie ryzyka" i w tożsamości użytkownika lub obciążenia "historia ryzyka".

Zrzut ekranu przedstawiający interfejs użytkownika portalu wykrywania ryzyka.

Jeśli wdrożono Microsoft Defender dla Chmury Apps, upewnij się, że zasady "Nietypowe dodawanie poświadczeń do aplikacji OAuth" jest włączone i sprawdź otwarte alerty.

Aby uzyskać więcej informacji, zobacz Nietypowe dodawanie poświadczeń do aplikacji OAuth.

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

Wyszukaj nietypowe zmiany konfiguracji aplikacji

  • Sprawdź uprawnienia interfejsu API przypisane do aplikacji, aby upewnić się, że uprawnienia są zgodne z oczekiwaniami aplikacji.
  • Sprawdź dzienniki inspekcji (filtruj działanie według aktualizacji aplikacji lub jednostki usługi aktualizacji).
  • Sprawdź, czy parametry połączenia są spójne i czy adres URL wylogowania został zmodyfikowany.
  • Sprawdź, czy domeny w adresie URL są zgodne z tymi 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 Microsoft Defender dla Chmury Apps, sprawdź witrynę Azure Portal pod kątem alertów dotyczących 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 o częstości występowania aplikacji i ostatnich działaniach na karcie Badanie>aplikacji OAuth.

Sprawdzanie podejrzanych ról aplikacji

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

Sprawdzanie niezweryfikowanych aplikacji komercyjnych

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

Sprawdzanie pod kątem wskazania 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 firmy Microsoft Entra skojarzone z kontami Uruchom jako usługi Automation, przejdź do repozytorium GitHub ze wskazówkami dotyczącymi korygowania.

Ważne

Jeśli odkryjesz dowody naruszenia, ważne jest, aby wykonać kroki wyróżnione w sekcjach zawierania i odzyskiwania. Te kroki pomagają wyeliminować ryzyko, ale przeprowadzić dalsze badania, aby zrozumieć źródło naruszenia, 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. Ta metoda jest częścią 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 administrator z naruszeniem zabezpieczeń może utworzyć aplikację OAuth z pozornie nieszkodliwą nazwą, unikając wykrywania i zezwalania na długoterminowy dostęp do danych bez konieczności posiadania konta. Ta metoda jest często spotykana w atakach państwowych w kraju.

Poniżej przedstawiono niektóre kroki, które można wykonać w celu dalszego zbadania.

Sprawdź ujednolicony dziennik inspekcji platformy Microsoft 365 (UAL) pod kątem wskazówek dotyczących wyłudzania informacji z ostatnich siedmiu 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 ustaleń z poprzednich kroków należy przejrzeć tożsamości:

  • Właściciele aplikacji
  • Administratorzy zgody

Przejrzyj tożsamości pod kątem wskazówek dotyczących 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 żadnych natychmiastowych wskazówek. Aby uzyskać szczegółowy podręcznik badania wyłudzania informacji, zobacz podręcznik badania wyłudzania informacji.

Wyszukiwanie zgody złośliwych aplikacji w ciągu ostatnich siedmiu dni

Aby uzyskać aplikację dodaną 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 udzielania zgody aplikacji na badanie.

Sprawdzanie dzienników inspekcji

Aby wyświetlić wszystkie udzielanie zgody dla tej aplikacji, przefiltruj pozycję Działanie według zgody na aplikację.

  • Korzystanie z dzienników inspekcji centrum administracyjnego firmy Microsoft Entra

  • 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": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "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 udzielania zgody aplikacji na badanie.

Użytkownik może autoryzować aplikację w celu uzyskania 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, które są wyrażane przez użytkowników, 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łym dzierżawie lub w przypadku zgody administratora)

Przeglądanie uprawnień przyznanych aplikacji lub jednostki usługi może być czasochłonnym zadaniem. Zacznij od zrozumienia potencjalnie ryzykownych uprawnień w identyfikatorze Entra firmy Microsoft.

Teraz postępuj zgodnie ze wskazówkami dotyczącymi sposobu wyliczania i przeglądania uprawnień w badaniu 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 też 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 firmy Microsoft Entra, filtrując według opcji Zgoda na aplikację. W sekcji Szczegóły dziennika inspekcji kliknij pozycję Zmodyfikowane właściwości, a następnie przejrzyj sekcję ConsentAction.Permissions:

Zrzut ekranu przedstawiający sposób korzystania z dzienników inspekcji firmy Microsoft Entra.

Kroki zawierania

Po zidentyfikowaniu co najmniej jednej aplikacji lub tożsamości obciążenia jako złośliwych lub naruszonych zabezpieczeniach może nie być natychmiast konieczne wprowadzenie poświadczeń dla tej aplikacji ani natychmiastowe usunięcie aplikacji.

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.

Zrzut ekranu przedstawiający sposób wyłączania logowania użytkownika.

Możesz również użyć następującego kodu programu PowerShell programu Microsoft Graph, 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-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

Kroki odzyskiwania

Korygowanie jednostek usługi

  1. Wyświetl listę wszystkich poświadczeń przypisanych do ryzykownych jednostek usługi. Najlepszym sposobem na 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": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
             "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ą. Wykonaj ten krok, jeśli dzierżawa hostuje/rejestruje aplikację wielodostępną i/lub rejestruje wiele jednostek usługi skojarzonych z aplikacją. Wykonaj podobne kroki do wymienionych wcześniej:

  • GET ~/servicePrincipals/{id}

  • Znajdź hasłoCredentials i keyCredentials w odpowiedzi, rejestruj wszystkie stare identyfikatory keyId

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

    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 funkcjach KeyVaults.
  • Pozostałe wpisy tajne w uwidocznionych subskrypcjach.

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

Aby uzyskać wskazówki dotyczące aplikacji firmy Microsoft Entra SecOps, zobacz Przewodnik po operacjach zabezpieczeń firmy Microsoft dla aplikacji.

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

  • Aktualizacja poleceń cmdlet programu PowerShell programu Graph (Dodawanie/usuwanie klucza aplikacji i aplikacjiPassword) w celu uwzględnienia przykładów 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 przenieś przełącznik do pozycji 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ę nietrwałą, skonfiguruj monitorowanie w dziennikach inspekcji firmy Microsoft Entra, 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 w celu odzyskania:

  • 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

Uwaga

Firma Microsoft globalnie wyłącza aplikacje, które mogą naruszać warunki użytkowania usługi. W takich przypadkach te aplikacje są wyświetlane DisabledDueToViolationOfServicesAgreement we disabledByMicrosoftStatus właściwości powiązanej aplikacji i typach zasobów jednostki usługi w programie Microsoft Graph. Aby zapobiec ponownemu utworzeniu wystąpienia w organizacji w przyszłości, nie można usunąć tych obiektów.

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

Firma Microsoft wykrywa ryzyko związane z tożsamościami obciążeń w ramach zachowania logowania i wskaźników naruszenia bezpieczeństwa w trybie offline.

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 pomocą ustawień diagnostycznych lub interfejsów API usługi Identity Protection.

Zrzut ekranu przedstawiający sposób przeglądania zagrożeń i alertów w portalu usługi Identity Protection.

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". Wymuszanie za pośrednictwem dostępu warunkowego jest obecnie ograniczone tylko do aplikacji z jedną dzierżawą.

Zrzut ekranu przedstawiający sposób kontrolowania dostępu użytkowników na podstawie zasad dostępu warunkowego.

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 obszarze Microsoft Entra ID>Dla aplikacji>dla przedsiębiorstw Zgoda i uprawnienia>Ustawienia zgody użytkownika.

Zrzut ekranu przedstawiający sposób zezwalania na zgodę użytkownika na aplikacje.

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 znany jako przepływ zgody administratora. Aby upewnić się, że przepływ zgody administratora działa prawidłowo, 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 wysokimi uprawnieniami, takich jak zgoda administratora, masz strategię uprzywilejowanego dostępu zdefiniowaną w naszych wskazówkach.

Zgoda na krok po kroku 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ą nieudostępnych uprawnień, 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 jest włączona zgoda użytkownika.

Upewnij się, że jest ona włączona w dzierżawie i przejrzyj ustawienia konfiguracji opisane tutaj.

Informacje

Dodatkowe podręczniki reagowania na zdarzenia

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

Zasoby reagowania na zdarzenia