Badanie naruszonych 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 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, role i uprawnienia wymagane, między innymi.
- 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 umożliwiające odzyskanie/złagodzenie złośliwego ataku na naruszone aplikacje.
- Odwołania: 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.
Aby korzystać z sygnałów ochrony tożsamości, dzierżawa musi mieć licencję na usługę Azure Active Directory (Azure AD) Premium P2.
Konto z następującymi rolami katalogu:
- Administrator globalny
- Administrator zabezpieczeń
Możliwość korzystania z Eksploratora programu Microsoft Graph i znajomości (w pewnym stopniu) w usłudze Microsoft interfejs Graph API.
Zapoznaj się z pojęciami dotyczącymi inspekcji aplikacji (część ).https://aka.ms/AzureADSecOps
Upewnij się, że wszystkie aplikacje dla przedsiębiorstw w dzierżawie mają właściciela ustawionego na potrzeby odpowiedzialności. Zapoznaj się z pojęciami dotyczącymi przeglądu właścicieli aplikacji i przypisywania właścicieli aplikacji.
Zapoznaj się z pojęciami dotyczącymi badania udzielania zgody aplikacji (część ).https://aka.ms/IRPlaybooks
Upewnij się, że znasz następujące uprawnienia Azure AD:
Zapoznaj się z pojęciami dotyczącymi wykrywania ryzyka tożsamości obciążenia.
Aby korzystać z Microsoft Defender for Cloud Apps, musisz mieć pełną licencję Microsoft 365 E5.
- Omówienie pojęć związanych z badaniem alertów wykrywania anomalii
Zapoznaj się z następującymi zasadami zarządzania aplikacjami:
Zapoznaj się z następującymi zasadami ładu aplikacji:
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
Kroki badania
W przypadku tego badania przyjęto założenie, że istnieje wskazanie potencjalnego naruszenia zabezpieczeń aplikacji w postaci raportu użytkownika, Azure AD przykład dzienników logowania lub wykrywanie 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 zestaw licencji Microsoft 365 E5 lub Azure AD — wersja Premium P2 dostępny lub skonfigurowany. Jednak w razie potrzeby wyróżnimy inne możliwości automatyzacji.
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 Azure Active Directory.
Aplikacje wielodostępne
W przypadku aplikacji wielodostępnych aplikacja jest hostowana i zarządzana przez inną firmę. Zidentyfikuj proces potrzebny do skontaktowania się z właścicielem aplikacji i zgłaszania problemów.
Aplikacje z jedną dzierżawą
Znajdź dane kontaktowe właściciela aplikacji w organizacji. Możesz 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 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ń licencyjnych dotyczących 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. Możesz sprawdzić stan ryzyka jednostki usługi przy użyciu karty Tożsamości Protection — ryzykowne tożsamości obciążenia lub użyć usługi Microsoft interfejs Graph API.
Sprawdzanie nietypowego zachowania logowania
Pierwszym krokiem badania jest wyszukanie dowodów na nietypowe wzorce uwierzytelniania w użyciu jednostki usługi. W ramach Azure Portal, Usługi Azure Monitor, Azure Sentinel lub systemu zarządzania informacjami o zabezpieczeniach i zdarzeniami (SIEM) wybranego przez organizację 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 oczekujesz?
- Błędy — istnieje duża liczba niepowodzeń uwierzytelniania dla jednostki usługi?
- Znaczniki czasu — czy występują pomyślne uwierzytelnienia występujące czasami, których 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, takich jak GitHub?
Jeśli wdrożono usługę Identity Protection — ryzykowne tożsamości obciążeń, sprawdź wykrywanie podejrzanych poświadczeń logowania i przecieków. Aby uzyskać więcej informacji, zobacz zatrzymania ryzyka związanego z tożsamościami obciążenia.
Sprawdzanie zasobu docelowego
W obszarze Logowania jednostki usługi sprawdź również zasób , do którego jednostka usługi uzyskiwała dostęp podczas uwierzytelniania. Ważne jest, aby dane wejściowe od właściciela aplikacji były znane zasobom, do których jednostka usługi powinna uzyskiwać dostęp.
Sprawdzanie nietypowych zmian poświadczeń
Użyj dzienników inspekcji, aby uzyskać informacje o zmianach poświadczeń w aplikacjach i jednostkach usługi. Filtruj dla 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 interfejs Graph API firmy Microsoft.
- Sprawdź zarówno aplikację, jak i skojarzone obiekty jednostki usługi.
- Sprawdź dowolną rolę niestandardową , która mogła zostać utworzona lub zmodyfikowana. Zanotuj uprawnienia oznaczone poniżej:
Jeśli wdrożono dodatek ładu aplikacji, sprawdź Azure Portal alertów dotyczących 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".
Jeśli wdrożono Microsoft Defender for Cloud 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żesz wysyłać zapytania do 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 działanie 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 Microsoft Defender for Cloud Apps, sprawdź 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 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, których dotyczy problem, 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 wykonać w celu dalszej analizy.
Sprawdź ujednolicony dziennik inspekcji platformy Microsoft 365 (UAL) pod kątem wskazania 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 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 zgody aplikacji dla oflagowanych 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 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.
Ustal, czy wystąpiła podejrzana zgoda użytkownika końcowego na aplikację
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 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 Azure AD, filtrując według zgody na aplikację. W sekcji Szczegóły dziennika inspekcji kliknij pozycję Zmodyfikowane właściwości, a następnie przejrzyj sekcję ConsentAction.Permissions:
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ę.
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.
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
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" } ],
Dodaj nowe poświadczenia certyfikatu (x509) do obiektu aplikacji przy użyciu interfejsu API addKey aplikacji.
POST ~/applications/{id}/addKeyNatychmiast usuń wszystkie stare poświadczenia. Dla każdego starego poświadczenia hasła usuń je przy użyciu:
POST ~/applications/{id}/removePasswordDla każdego starego poświadczenia klucza usuń je przy użyciu:
POST ~/applications/{id}/removeKeyKoryguj 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żyj polecenia:
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 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 Azure Portal lub za pośrednictwem witryny Microsoft interfejs Graph API. 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 usługi Microsoft interfejs Graph API:
DELETE /directory/deletedItems/{id}
Jeśli wyłączysz lub usuniesz aplikację nietrwale, skonfiguruj monitorowanie w dziennikach inspekcji 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
Uwaga: Firma Microsoft globalnie wyłącza aplikacje, które naruszają warunki użytkowania usługi. W takich przypadkach te aplikacje będą 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 przypadku zachowania logowania i wskaźników naruszenia zabezpieczeń 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.
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ą.
Aby uzyskać więcej informacji, zobacz Dostęp warunkowy dla tożsamości obciążeń.
Implementowanie zasad ryzyka aplikacji
Przeglądanie ustawień zgody użytkownika
Przejrzyj ustawienia zgody użytkownika w obszarzeAplikacje> dla przedsiębiorstw w usłudze Azure Active Directory>Zgoda i uprawnienia>Ustawienia zgody użytkownika.
Aby przejrzeć opcje konfiguracji, zobacz Konfigurowanie sposobu wyrażania zgody przez użytkowników na aplikacje.
Implementowanie przepływu zgody administratora
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.
Przeglądanie ustawień zgody na podstawie ryzyka
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
- Podręczniki reagowania na zdarzenia
- Udzielanie zgody aplikacji
- Azure AD ryzykiem związanym z usługą Identity Protection
- Przewodnik monitorowania zabezpieczeń Azure AD
- Pojęcia dotyczące inspekcji aplikacji
- Konfigurowanie sposobu, w jaki użytkownicy wyrażają zgodę na aplikacje
- Konfigurowanie przepływu pracy zgody administratora
- Nietypowe dodawanie poświadczeń do aplikacji OAuth
- Zabezpieczanie tożsamości obciążeń za pomocą usługi Identity Protection
- Holistyczne sygnały tożsamości z naruszonymi zabezpieczeniami firmy Microsoft
Dodatkowe podręczniki reagowania na zdarzenia
Zapoznaj się ze wskazówkami dotyczącymi identyfikowania i badania tych dodatkowych typów ataków:
- Wyłudzanie informacji
- Spray haseł
- Udzielanie zgody aplikacji
- Microsoft DART ransomware approach and best practices (Podejście i najlepsze rozwiązania firmy Microsoft do oprogramowania wymuszającego okup dart firmy Microsoft
Zasoby reagowania na zdarzenia
- Omówienie produktów i zasobów zabezpieczeń firmy Microsoft dla nowych i doświadczonych analityków
- Planowanie usługi Security Operations Center (SOC)
- Microsoft 365 Defender reagowanie na zdarzenia
- Microsoft Defender for Cloud (Azure)
- Reagowanie na zdarzenia w usłudze Microsoft Sentinel