Onderzoek naar gecompromitteerde en schadelijke toepassingen

Dit artikel bevat richtlijnen voor het identificeren en onderzoeken van schadelijke aanvallen op een of meer toepassingen in een tenant van een klant. De stapsgewijze instructies helpen u bij het nemen van de vereiste herstelactie om informatie te beschermen en verdere risico's te minimaliseren.

  • Voorwaarden: Behandelt de specifieke vereisten die u moet voltooien voordat u het onderzoek start. Logboekregistratie die bijvoorbeeld moet worden ingeschakeld, rollen en machtigingen die vereist zijn, zijn onder andere vereist.
  • Workflow: Toont de logische stroom die u moet volgen om dit onderzoek uit te voeren.
  • Onderzoeksstappen: Bevat een gedetailleerde stapsgewijze handleiding voor dit specifieke onderzoek.
  • Insluitingsstappen: Bevat stappen voor het uitschakelen van de aangetaste toepassingen.
  • Herstelstappen: Bevat stappen op hoog niveau voor het herstellen/beperken van een schadelijke aanval op aangetaste toepassingen.
  • Verwijzingen: Bevat aanvullende lees- en referentiemateriaal.

Vereisten

Voordat u begint met het onderzoek, moet u de juiste hulpprogramma's en machtigingen hebben om gedetailleerde informatie te verzamelen over de toepassingen die u vermoedt te worden aangetast door de kwaadaardige aanval.

Vereiste hulpprogramma's

Voor een effectief onderzoek installeert u de volgende PowerShell-module en de toolkit op uw onderzoekscomputer:

Werkstroom

Detailed flow of the investigation steps

Onderzoeksstappen

Voor dit onderzoek wordt ervan uitgegaan dat u een indicatie hebt voor een mogelijk inbreuk op een toepassing in de vorm van een gebruikersrapport, azure AD-aanmeldingslogboeken of identiteitsbeveiligingsdetectie. Zorg ervoor dat u alle vereiste stappen voltooit en inschakelt.

Dit playbook wordt gemaakt met de bedoeling dat niet alle Microsoft-klanten en hun onderzoeksteams de volledige Microsoft 365 E5- of Azure AD Premium P2-licentiesuite beschikbaar hebben of geconfigureerd in de tenant die wordt onderzocht. We zullen echter aanvullende automatiseringsmogelijkheden markeren, indien van toepassing.

Toepassingstype bepalen

Het is belangrijk om vroeg in de onderzoeksfase te bepalen welk type toepassing (meerdere of één tenant) nodig is om de juiste informatie op te halen die nodig is om contact op te nemen met de eigenaar van de toepassing. Zie Tenancy in Azure Active Directory voor meer informatie.

Toepassingen voor meerdere tenants

Voor toepassingen met meerdere tenants wordt de toepassing gehost en beheerd door een derde partij. Identificeer het proces dat nodig is om problemen met de eigenaar van de toepassing te melden.

Toepassingen met één tenant

Zoek de contactgegevens van de eigenaar van de toepassing binnen uw organisatie. U vindt deze onder het tabblad Eigenaren in de sectie Bedrijfstoepassingen . Uw organisatie kan ook een database hebben met deze informatie.

U kunt deze Microsoft Graph-query ook uitvoeren:

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

Identiteitsbeveiliging controleren - riskante workloadidentiteiten

Deze functie is in preview op het moment van schrijven van dit playbook en licentievereisten zijn van toepassing op het gebruik ervan. Riskante workloadidentiteiten kunnen de trigger zijn om een service-principal te onderzoeken, maar kunnen ook worden gebruikt om verder te onderzoeken naar andere triggers die u mogelijk hebt geïdentificeerd. U kunt de risicostatus van een service-principal controleren met behulp van het tabblad Identity Protection - riskante workloadidentiteiten of u kunt Microsoft Graph API gebruiken.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Controleren op ongebruikelijk aanmeldingsgedrag

De eerste stap van het onderzoek is het zoeken naar bewijs van ongebruikelijke verificatiepatronen in het gebruik van de service-principal. Zoek in Azure Portal, Azure Monitor, Azure Sentinel of het SIEM-systeem (Security Information and Event Management) van uw organisatie naar het volgende in de sectie Aanmeldingen voor de service-principal :

  • Locatie: wordt de service-principal geverifieerd vanaf locaties\IP-adressen die u niet zou verwachten?
  • Fouten: zijn er een groot aantal verificatiefouten voor de service-principal?
  • Tijdstempels: zijn er geslaagde verificaties die optreden op tijdstippen die u niet zou verwachten?
  • Frequentie: is er een verhoogde frequentie van verificaties voor de service-principal?
  • Lekreferenties: zijn er toepassingsreferenties vastgelegd en gepubliceerd op een openbare bron, zoals GitHub?

Als u Identity Protection - riskante workloadidentiteiten hebt geïmplementeerd, controleert u de detecties van verdachte aanmeldingen en lekken van referenties. Zie bewaringen van identiteitsrisico's voor werkbelastingen voor meer informatie.

De doelresource controleren

Controleer in de aanmeldingen van de service-principal ook de resource waartoe de service-principal tijdens de verificatie toegang heeft. Het is belangrijk om invoer te hebben van de eigenaar van de toepassing, omdat ze bekend zijn met welke resources de service-principal toegang moet hebben.

Check the Resource for Service Principal

Controleren op abnormale referentiewijzigingen

Gebruik auditlogboeken om informatie op te halen over referentiewijzigingen in toepassingen en service-principals. Filter op categorie op toepassingsbeheer en activiteit op toepassing bijwerken: certificaten en geheimenbeheer.

  • Controleer of er nieuw gemaakte of onverwachte referenties zijn toegewezen aan de service-principal.
  • Controleer op referenties op service-principal met behulp van Microsoft Graph API.
  • Controleer zowel de toepassing als de bijbehorende service-principalobjecten.
  • Controleer een aangepaste rol die mogelijk is gemaakt of gewijzigd. Let op de machtigingen die hieronder zijn gemarkeerd:

Check custom roles that may be created or modified

Als u de app-governance-invoegtoepassing hebt geïmplementeerd, controleert u de Azure-portal op waarschuwingen met betrekking tot de toepassing. Zie Aan de slag met detectie en herstel van app-bedreigingen voor meer informatie.

Als u Identity Protection hebt geïmplementeerd, controleert u het rapport Risicodetecties en in de gebruikers- of workloadidentiteit 'risicogeschiedenis'.

Risk Detection portal

Als u Microsoft Defender voor Cloud Apps hebt geïmplementeerd, controleert u of het beleid 'Ongebruikelijke toevoeging van referenties aan een OAuth-app' is ingeschakeld en controleert u op geopende waarschuwingen. Zie Ongebruikelijke toevoeging van referenties aan een OAuth-app voor meer informatie.

Daarnaast kunt u query's uitvoeren op de servicePrincipalRiskDetections - en user riskDetections-API's om deze risicodetecties op te halen.

Zoeken naar afwijkende app-configuratiewijzigingen

  • Controleer de API-machtigingen die zijn toegewezen aan de app om ervoor te zorgen dat de machtigingen consistent zijn met wat er voor de app wordt verwacht.
  • Controleer auditlogboeken ( filteractiviteit op toepassing bijwerken of service-principal bijwerken).
  • Controleer of de verbindingsreeksen consistent zijn en of de afmeldings-URL is gewijzigd.
  • Controleer of de domeinen in de URL in overeenstemming zijn met de domeinen die zijn geregistreerd.
  • Bepaal of iemand een niet-geautoriseerde omleidings-URL heeft toegevoegd.
  • Bevestig het eigendom van de omleidings-URI waarvan u de eigenaar bent om ervoor te zorgen dat deze niet is verlopen en is geclaimd door een kwaadwillende persoon.

Als u Microsoft Defender voor Cloud Apps hebt geïmplementeerd, controleert u de Azure-portal op waarschuwingen met betrekking tot de toepassing die u momenteel onderzoekt. Niet alle waarschuwingsbeleidsregels zijn standaard ingeschakeld voor OAuth-apps, dus zorg ervoor dat deze allemaal zijn ingeschakeld. Zie het OAuth-app-beleid voor meer informatie. U kunt ook informatie bekijken over de evaluatie van apps en recente activiteiten op het tabblad OAuth-apps voor onderzoek>.

Controleren op verdachte toepassingsrollen

  • Dit kan ook worden onderzocht met behulp van de auditlogboeken. Filter activiteit door app-roltoewijzing toe te voegen aan service-principal.
  • Controleer of de toegewezen rollen hoge bevoegdheden hebben.
  • Controleer of deze bevoegdheden nodig zijn.

Controleren op niet-geverifieerde commerciële apps

  • Controleer of er commerciële galerietoepassingen (gepubliceerde en geverifieerde versies) worden gebruikt.

Controleren op indicaties van de openbaarmaking van keyCredential-eigendomsgegevens

Controleer uw tenant op mogelijke openbaarmaking van keyCredential property information zoals beschreven in CVE-2021-42306.

Als u betrokken Azure AD-toepassingen wilt identificeren en herstellen die zijn gekoppeld aan betrokken Automation-Run-As-accounts, gaat u naar de richtlijnen voor herstel naar github-opslagplaats.

Belangrijk

Bewijs van inbreuk: Als u bewijs van inbreuk ontdekt, is het belangrijk om de stappen uit te voeren die zijn gemarkeerd in de secties voor insluiting en herstel. Dit helpt bij het oplossen van het risico, maar zal nader onderzoek nodig hebben om inzicht te krijgen in de bron van het compromis om verdere impact te voorkomen en ervoor te zorgen dat slechte actoren worden verwijderd.

Er zijn twee primaire methoden om toegang te krijgen tot systemen via het gebruik van toepassingen. De eerste omvat een toepassing die wordt toegestaan door een beheerder of gebruiker, meestal via een phishing-aanval. Dit zou deel uitmaken van de eerste toegang tot een systeem en wordt vaak 'toestemming phishing' genoemd.

De tweede methode omvat een al aangetast beheerdersaccount waarmee een nieuwe app wordt gemaakt voor persistentie, gegevensverzameling en om onder de radar te blijven. Een OAuth-app kan bijvoorbeeld worden gemaakt door een gecompromitteerde beheerder met een schijnbaar onschuldige naam, waardoor detectie wordt vermeden en langdurige toegang tot gegevens wordt toegestaan zonder dat hiervoor een account nodig is. Dit wordt vaak gezien bij nationale aanvallen.

Hieronder vindt u enkele van de stappen die kunnen worden uitgevoerd om verder te onderzoeken.

Controleer M365 Unified Audit Log (UAL) op phishing-indicaties voor de afgelopen 7 dagen

Wanneer aanvallers schadelijke of gecompromitteerde toepassingen gebruiken als persistentiemiddel of om gegevens te exfiltreren, is er een phishingcampagne betrokken. Op basis van de resultaten uit de vorige stappen moet u de identiteiten van:

  • Toepassingseigenaren
  • Beheerders van toestemming

Bekijk de identiteiten voor indicaties van phishingaanvallen in de afgelopen 24 uur. Verhoog deze periode indien nodig tot 7, 14 en 30 dagen als er geen directe aanwijzingen zijn. Zie het Playbook Phishing Investigation voor een gedetailleerd playbook voor phishingonderzoek.

Zoeken naar schadelijke toepassingstoestemmingen voor de afgelopen 7 dagen

Om een toepassing toe te voegen aan een tenant, spoofen aanvallers of beheerders om toestemming te geven voor toepassingen. Zie het Playbook Application Consent Grant Investigation voor meer informatie over de tekenen van een aanval.

Auditlogboeken controleren

Als u alle toestemmingstoestemmingen voor die toepassing wilt zien, filtert u Activiteit op Toestemming voor de toepassing.

  • De auditlogboeken van de Azure AD-portal gebruiken

  • Microsoft Graph gebruiken om query's uit te voeren op de auditlogboeken

    a) Filteren op een bepaald tijdsbestek:

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

b) Filter de auditlogboeken op vermeldingen in het auditlogboek 'Toestemming voor toepassingen':

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) Log Analytics gebruiken

AuditLogs
| where ActivityDisplayName == "Consent to application"

Zie het Playbook Application Consent Grant Investigation voor meer informatie.

Een gebruiker kan een toepassing machtigen om toegang te krijgen tot bepaalde gegevens in de beveiligde resource, terwijl deze als die gebruiker fungeert. De machtigingen die dit type toegang toestaan, worden 'gedelegeerde machtigingen' of gebruikerstoestemming genoemd.

Als u apps wilt vinden die door gebruikers zijn toegestaan, gebruikt u LogAnalytics om de auditlogboeken te doorzoeken:

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

Controleer auditlogboeken om te bepalen of de verleende machtigingen te breed zijn (tenantbrede of door de beheerder toestemming gegeven)

Het controleren van de machtigingen die aan een toepassing of service-principal zijn verleend, kan een tijdrovende taak zijn. Begin met het begrijpen van de mogelijk riskante machtigingen in Azure AD.

Volg nu de richtlijnen voor het inventariseren en controleren van machtigingen in het onderzoek naar toestemming van de app.

Controleer of de machtigingen zijn verleend door gebruikersidentiteiten die dit niet mogen doen, of of de acties zijn uitgevoerd op vreemde datums en tijden

Controleren met auditlogboeken:

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

U kunt ook de Auditlogboeken van Azure AD gebruiken, filteren op Toestemming voor de toepassing. Klik in de sectie Details van het auditlogboek op Eigenschappen gewijzigd en controleer vervolgens de ConsentAction.Permissions:

Use the Azure AD Audit Logs

Insluitingsstappen

Zodra u een of meer toepassingen of workloadidentiteiten hebt geïdentificeerd als kwaadaardig of aangetast, wilt u de referenties voor deze toepassing mogelijk niet meteen uitrollen, noch wilt u de toepassing onmiddellijk verwijderen. Het wordt ten zeerste aanbevolen om de best practice-richtlijnen voor incidentrespons te volgen.

Belangrijk

Voordat u de volgende stap uitvoert, moet uw organisatie de beveiligingsimpact en de bedrijfsimpact van het uitschakelen van een toepassing afwegen. Als de bedrijfsimpact van het uitschakelen van een toepassing te groot is, kunt u overwegen om de herstelfase van dit proces voor te bereiden en over te stappen.

Aangetaste toepassing uitschakelen

Een typische insluitingsstrategie omvat het uitschakelen van aanmeldingen bij de geïdentificeerde toepassing, om uw incidentresponsteam of de betrokken bedrijfseenheid tijd te geven om de impact van verwijdering of sleutelverloop te evalueren. Als uw onderzoek ertoe leidt dat er ook inbreuk is gemaakt op referenties voor beheerdersaccounts, moet dit type activiteit worden gecoördineerd met een verwijderingsgebeurtenis om ervoor te zorgen dat alle routes voor toegang tot de tenant tegelijkertijd worden afgekapt.

Toggle to disable users to sign-in

U kunt ook de volgende PowerShell-code gebruiken om de aanmelding bij de app uit te schakelen:

# 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
}

Herstelstappen

Service-principals herstellen

  1. Vermeld alle referenties die zijn toegewezen aan de riskante service-principal. De beste manier om dit te doen, is door een Microsoft Graph-aanroep uit te voeren met GET ~/application/{id} waar de doorgegeven id de object-id van de toepassing is.

    • Parseert de uitvoer voor referenties. De uitvoer kan passwordCredentials of keyCredentials bevatten. Noteer de keyIds voor iedereen.

      "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. Voeg een nieuwe certificaatreferentie (x509) toe aan het toepassingsobject met behulp van de addKey-API van de toepassing.

    POST ~/applications/{id}/addKey
    
  3. Verwijder onmiddellijk alle oude referenties. Verwijder deze voor elke oude wachtwoordreferentie met behulp van:

    POST ~/applications/{id}/removePassword
    

    Voor elke oude sleutelreferentie verwijdert u deze met behulp van:

    POST ~/applications/{id}/removeKey
    
  4. Herstel alle service-principals die aan de toepassing zijn gekoppeld. Volg dit als uw tenanthosts/registers een toepassing met meerdere tenants registreren en/of meerdere service-principals registreren die aan de toepassing zijn gekoppeld. Voer vergelijkbare stappen uit als hierboven vermeld:

  • GET ~/servicePrincipals/{id}

  • Find passwordCredentials and keyCredentials in the response, record all old keyIds

  • Verwijder alle oude wachtwoord- en sleutelreferenties. Gebruiken:

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

Betrokken service-principalresources herstellen

Herstel KeyVault-geheimen waartoe de service-principal toegang heeft door ze te roteren, in de volgende prioriteit:

  • Geheimen die rechtstreeks worden weergegeven met GetSecret-aanroepen .
  • De rest van de geheimen in blootgestelde KeyVaults.
  • De rest van de geheimen voor weergegeven abonnementen.

Zie Interactief de certificaten en geheimen van een service-principal of toepassing verwijderen en implementeren voor meer informatie.

Zie de handleiding voor Azure Active Directory-beveiligingsbewerkingen voor toepassingen voor Azure AD SecOps voor richtlijnen voor toepassingen.

In volgorde van prioriteit zou dit scenario het volgende zijn:

  • Update Graph PowerShell-cmdlets (Add/Remove ApplicationKey + ApplicationPassword) met voorbeelden voor referentie-roll-over.
  • Voeg aangepaste cmdlets toe aan Microsoft Graph PowerShell waarmee dit scenario wordt vereenvoudigd.

Schadelijke toepassingen uitschakelen of verwijderen

Een toepassing kan worden uitgeschakeld of verwijderd. Als u de toepassing wilt uitschakelen, verplaatst u onder Ingeschakeld voor gebruikers om zich aan te melden de wisselknop naar Nee.

U kunt de toepassing tijdelijk of permanent verwijderen in Azure Portal of via de Microsoft Graph API. Wanneer u voorlopig verwijdert, kan de toepassing maximaal 30 dagen na verwijdering worden hersteld.

DELETE /applications/{id}

Als u de toepassing permanent wilt verwijderen, gebruikt u deze Microsoft Graph API-aanroep:

DELETE /directory/deletedItems/{id}

Als u de toepassing uitschakelt of voorlopig verwijdert, stelt u bewaking in azure AD-auditlogboeken in om te zien of de status weer wordt ingeschakeld of hersteld.

Logboekregistratie voor ingeschakeld:

  • Service - Kernmap
  • Activiteitstype - Service-principal bijwerken
  • Categorie - Toepassingsbeheer
  • Geïnitieerd door (actor) - UPN van actor
  • Doelen - app-id en weergavenaam
  • Gewijzigde eigenschappen - Eigenschapsnaam = account ingeschakeld, nieuwe waarde = true

Logboekregistratie voor hersteld:

  • Service - Kernmap
  • Activiteitstype - Service-principal toevoegen
  • Categorie - Toepassingsbeheer
  • Geïnitieerd door (actor) - UPN van actor
  • Doelen - app-id en weergavenaam
  • Gewijzigde eigenschappen - Eigenschapsnaam = account ingeschakeld, nieuwe waarde = true

Identity Protection implementeren voor workloadidentiteiten

Verdachte aanmeldingen: wanneer risicodetectie ongebruikelijke aanmeldingseigenschappen of patronen aangeeft, evenals ongebruikelijke toevoeging van referenties aan een OAuth-app, kan dit een indicatie zijn van inbreuk. Het aanmeldingsgedrag voor detectiebasislijnen tussen 2 en 60 dagen en wordt geactiveerd als een of meer van de volgende onbekende eigenschappen optreden tijdens een volgende aanmelding:

  • IP-adres/ASN
  • Doelbron
  • Gebruikersagent
  • Ip-adreswijziging voor hosting/niet-hosting
  • IP-land
  • Referentietype

Wanneer deze detectie wordt geactiveerd, wordt het account gemarkeerd als hoog risico, omdat dit kan duiden op accountovername voor de onderwerptoepassing. Houd er rekening mee dat de legitieme wijzigingen in de configuratie van een toepassing deze detectie soms activeren.

Zie Workloadidentiteiten beveiligen met Identity Protection voor meer informatie.

Deze waarschuwingen worden weergegeven in de Identity Protection-portal en kunnen worden geëxporteerd naar SIEM-hulpprogramma's via de Identity Protection-API's.

Review risks and alerts in the Identity Protection portal

Voorwaardelijke toegang voor riskante workloadidentiteiten

Met voorwaardelijke toegang kunt u de toegang blokkeren voor specifieke accounts die u aangeeft wanneer Identity Protection deze markeert als 'risico'. Houd er rekening mee dat de afdwinging via voorwaardelijke toegang momenteel beperkt is tot toepassingen met één tenant.

Control user access based on conditional access policy

Zie Voorwaardelijke toegang voor workloadidentiteiten voor meer informatie.

Beleid voor toepassingsrisico's implementeren

Controleer de instellingen voor gebruikerstoestemming onder Azure Active Directory Enterprise-toepassingen>>Toestemming en machtigingen>gebruikerstoestemmingsinstellingen.

Select Allow user consent for apps from the options

Zie Configureren hoe gebruikers toestemming geven voor apps om de configuratieopties te bekijken.

Wanneer een toepassingsontwikkelaar gebruikers omwijst naar het eindpunt voor beheerderstoestemming met de intentie om toestemming te geven voor de hele tenant, wordt dit de stroom voor beheerderstoestemming genoemd. Om ervoor te zorgen dat de stroom voor beheerderstoestemming goed werkt, moeten toepassingsontwikkelaars alle machtigingen vermelden in de eigenschap RequiredResourceAccess in het toepassingsmanifest.

De meeste organisaties schakelen de mogelijkheid uit voor hun gebruikers om toestemming te geven voor toepassingen. Om gebruikers de mogelijkheid te bieden om nog steeds toestemming te vragen voor toepassingen en om een beheerbeoordelingsmogelijkheid te hebben, is het raadzaam om de werkstroom voor beheerderstoestemming te implementeren. Volg de werkstroomstappen voor beheerderstoestemming om deze in uw tenant te configureren.

Voor bewerkingen met hoge bevoegdheden, zoals beheerderstoestemming, hebt u een strategie voor bevoegde toegang gedefinieerd volgens onze richtlijnen.

Op risico's gebaseerde stapsgewijze toestemming helpt de blootstelling van gebruikers aan schadelijke apps te verminderen. Toestemmingsaanvragen voor nieuw geregistreerde apps met meerdere tenants die niet door de uitgever zijn geverifieerd en waarvoor niet-basismachtigingen zijn vereist, worden bijvoorbeeld als riskant beschouwd. Als er een riskante aanvraag voor gebruikerstoestemming wordt gedetecteerd, is voor de aanvraag een 'step-up' vereist voor beheerderstoestemming. Deze stapsgewijze mogelijkheid is standaard ingeschakeld, maar dit resulteert in een gedragswijziging alleen wanneer toestemming van de gebruiker is ingeschakeld.

Zorg ervoor dat deze is ingeschakeld in uw tenant en controleer de configuratie-instellingen die hier worden beschreven.

Referenties

Aanvullende playbooks voor incidentrespons

Bekijk de richtlijnen voor het identificeren en onderzoeken van deze aanvullende typen aanvallen:

Resources voor incidentrespons