Udostępnij za pośrednictwem

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

  • Artykuł

Ten artykuł zawiera wskazówki dotyczące identyfikacji i badania złośliwych ataków na co najmniej jedną aplikację dzierżawy 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 zapobiegające: zawiera instrukcje, jak wyłączyć naruszone aplikacje.
  • 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. Upewnij się, że ukończono i włączono wszystkie wymagane kroki wstępne.

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 Obiekt 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

Sprawdź usługę Identity Protection — ryzykowne tożsamości związane z obciążeniem

Ta funkcja jest dostępna w wersji zapoznawczej w momencie pisania tego podręcznika, a do jej użycia mają zastosowanie wymagania dotyczące licencjonowania. Ryzykowne tożsamości robocze mogą być wyzwalaczem do zbadania jednostki usługi, ale mogą również służyć do dalszego zbadania innych zidentyfikowanych wyzwalaczy. Stan ryzyka głównego obiektu zabezpieczeń można sprawdzić przy użyciu karty Identity Protection — ryzykowne tożsamości obciążenia lub można użyć interfejsu API Microsoft Graph. Możesz również użyć monitów języka naturalnego, aby uzyskać wgląd na temat ryzykownych tożsamości związanych z obciążeniem za pomocą Microsoft Security Copilot w Microsoft Entra.

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

Zrzut ekranu przedstawiający stronę interfejsu użytkownika z szczegółami 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 głównego użytkownika usługi. W portalu Azure, Azure Monitor, Microsoft Sentinel lub systemie zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) wybranym przez organizację, wyszukaj następujące elementy w sekcji logowania głównej aplikacji usługi:

  • Lokalizacja — czy jednostka usługi uwierzytelnia się z lokalizacji\adresów IP, których nie oczekujesz?
  • Błędy — czy występuje duża liczba niepowodzeń uwierzytelniania dla głównego konta 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 głównej 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ążenia, sprawdź wykrycia podejrzanych logowań i wycieku poświadczeń. Aby uzyskać więcej informacji, zobacz zatrzymanie ryzyka związanego z tożsamością obciążenia.

Sprawdzanie zasobu docelowego

W ramach logowań zasadniczego serwisu, sprawdź również Zasób, do którego uzyskiwała 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 Service Principal (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. Filtrowanie kategorii przez zarządzanie aplikacjami oraz działania przez aktualizację aplikacji – zarządzanie certyfikatami i tajemnicami.

  • Sprawdź, czy nowo utworzone lub nieoczekiwane poświadczenia są przypisane do głównego elementu usługi.
  • Sprawdź poświadczenia na Service Principal przy użyciu Microsoft Graph API.
  • Sprawdź zarówno aplikację, jak i skojarzone obiekty jednostki usługi.
  • Sprawdź każdą niestandardową rolę, którą utworzyłeś lub zmodyfikowałeś. 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 funkcję Identity Protection, sprawdź raport "Wykrywanie ryzyka" oraz "historię ryzyka" w tożsamości użytkownika lub obciążenia.

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

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

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

Ponadto można wykonywać zapytania dotyczące servicePrincipalRiskDetections i riskDetections API 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 audytu (filtruj działanie według Aktualizuj aplikację lub Aktualizuj jednostkę usługi).
  • 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 wygasł i nie został przejęty przez przeciwnika.

Ponadto, jeśli wdrożono Microsoft Defender for Cloud Apps, sprawdź portal Azure pod kątem alertów dotyczących obecnie 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.

Sprawdź podejrzane role aplikacji

  • Możesz również użyć dzienników inspekcji. Filtruj Działanie według Dodaj przypisanie roli aplikacji do jednostki usługi głównej.
  • 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 komercyjnej galerii aplikacji (opublikowane i zweryfikowane wersje).

Sprawdź oznaki 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 naprawić dotknięte problemem aplikacje Microsoft Entra powiązane z dotkniętymi problemem kontami Uruchom jako usługi Automation, przejdź do GitHub Repo ze wskazówkami naprawczymi.

Ważne

Jeśli odkryjesz dowody naruszenia bezpieczeństwa, ważne jest, aby wykonać kroki wyróżnione w sekcjach izolacji i przywracania. 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 zatwierdzeniu aplikacji przez administratora lub użytkownika, zwykle poprzez atak phishingowy. 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 prowadzonych przez państwa.

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 powinieneś przejrzeć tożsamości:

  • Właściciele aplikacji
  • Administratorzy zgody

Przejrzyj identyfikacje, czy są oznaki ataków phishingowych 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 udzielonych zgód złośliwym aplikacjom w ciągu ostatnich siedmiu dni

Aby dodać aplikację do dzierżawy, atakujący podszywają się pod użytkowników lub administratorów, aby wyrazić zgodę na aplikacje. Aby dowiedzieć się więcej na temat oznak ataku, zobacz Przewodnik śledztwa w sprawie zatwierdzania zgód aplikacji.

Sprawdzanie dzienników inspekcji

Aby wyświetlić wszystkie przyznane zgody dla tej aplikacji, przefiltruj pozycję Działanie według zgoda 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, na które użytkownicy wyrazili zgodę, użyj usługi Log Analytics, aby wyszukać dzienniki audytu.

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 użytkowników, którzy nie powinni mieć tej możliwości, czy też akcje zostały wykonane w dziwnych datach i godzinach.

Sprawdź 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 opanowania

Po zidentyfikowaniu jednej lub więcej aplikacji lub tożsamości obciążenia jako złośliwych lub naruszonych, możesz nie chcieć od razu zmieniać poświadczeń tej aplikacji ani natychmiast jej usuwać.

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 zapobiegania obejmuje wyłączenie logowania do zidentyfikowanej aplikacji, aby dać zespołowi ds. reagowania na zdarzenia lub odpowiedniej jednostce biznesowej czas na ocenę wpływu usunięcia lub zmiany 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 PowerShell 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 głównych elementów usługi

  1. Wyświetl listę wszystkich poświadczeń przypisanych do ryzykownego podmiotu usługi. Najlepszym sposobem na to jest wykonanie wywołania Microsoft Graph za pomocą GET ~/application/{id}, gdzie przekazany identyfikator to identyfikator obiektu aplikacji.

    • Przeanalizuj dane wyjściowe w poszukiwaniu 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 za pomocą:

    POST ~/applications/{id}/removeKey

  4. Koryguj wszystkie jednostki usługi skojarzone z aplikacją. Wykonaj ten krok, jeśli dzierżawa hostuje lub rejestruje aplikację wielodostępną i/lub rejestruje wiele podmiotów usługi skojarzonych z aplikacją. Wykonaj podobne kroki do wymienionych wcześniej:

  • GET ~/servicePrincipals/{id}

  • Znajdź poświadczenia hasła i poświadczenia klucza w odpowiedzi, rejestruj wszystkie stare identyfikatory klucza

  • 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

Napraw sekrety usługi w KeyVault, do których główna jednostka usługi ma dostęp, zmieniając je w następującym porządku priorytetowym:

  • Sekrety ujawniane bezpośrednio za pomocą wywołań GetSecret.
  • Pozostałe sekrety w ujawnionych KeyVaultach.
  • Pozostałe tajemnice w ujawnionych subskrypcjach.

Aby uzyskać więcej informacji, zobacz Interaktywne usuwanie i odnawianie certyfikatów i sekretów głównej instancji usługi lub aplikacji.

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

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

  • Aktualizacja poleceń cmdlet Graph PowerShell (Dodawanie/usuwanie klucza aplikacji i hasła aplikacji) w celu uwzględnienia przykładów odnawiania 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 tymczasowym usunięciu 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 tymczasowo usuniesz aplikację, skonfiguruj monitorowanie w dziennikach inspekcji Microsoft Entra, aby dowiedzieć się, czy stan powróci do włączonego lub odzyskanego.

Włączono rejestrowanie

  • Usługa — katalog podstawowy
  • Typ działania — aktualizowanie głównej jednostki usługi
  • Kategoria — zarządzanie aplikacjami
  • Zainicjowane przez (uczestnik) — UPN uczestnika
  • 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) — 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 tworzeniu tych obiektów w organizacji w przyszłości, nie można ich usunąć.

Wdrożenie ochrony tożsamości dla tożsamości aplikacji

Microsoft wykrywa ryzyko związane z tożsamościami w kontekście obciążeń na podstawie zachowania przy logowaniu oraz wskaźników naruszenia bezpieczeństwa 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ążenia.

Implementowanie zasad ryzyka aplikacji

Przejrzyj ustawienia zgody użytkownika w obszarze Microsoft Entra ID>aplikacje 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 przekierowuje użytkowników do punktu końcowego zgody administratora z zamiarem wyrażenia zgody dla całej dzierżawy, nazywa się to admin consent flow. 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 dotyczące zgody administratora w przepływie pracy, 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 wielodzierżawowych, które nie są zweryfikowane przez dostawcę i wymagają zaawansowanych uprawnień, są uznawane za ryzykowne. Jeśli zostanie wykryte ryzykowne żądanie zgody użytkownika, wówczas wymaga ono przejścia na zgodę 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 Twoim środowisku i przejrzyj ustawienia konfiguracji opisane tutaj.

Źródła

Dodatkowe scenariusze reagowania na incydenty

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

Zasoby reagowania na zdarzenia