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 klanttenant. De stapsgewijze instructies helpen u de vereiste herstelactie uit te voeren om informatie te beschermen en verdere risico's te minimaliseren.
- Vereisten: 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.
- Werkstroom: 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 andere lees- en referentiemateriaal.
Vereisten
Voordat u begint met het onderzoek, moet u ervoor zorgen dat u over de juiste hulpprogramma's en machtigingen beschikt om gedetailleerde informatie te verzamelen.
Als u identiteitsbeveiligingssignalen wilt gebruiken, moet de tenant een licentie hebben voor Microsoft Entra ID P2.
- Inzicht in de identiteitsbeveiligingsrisicoconcepten
- Inzicht in de identiteitsbeveiligingsonderzoeksconcepten
Een account met ten minste de rol Beveiligingsbeheerder .
De mogelijkheid om Microsoft Graph Explorer te gebruiken en (in zekere mate) vertrouwd te zijn met de Microsoft Graph API.
Raak vertrouwd met de concepten voor toepassingscontrole (onderdeel van https://aka.ms/AzureADSecOps).
Zorg ervoor dat alle Enterprise-apps in uw tenant een eigenaar hebben ingesteld voor verantwoordelijkheid. Bekijk de concepten over het overzicht van app-eigenaren en het toewijzen van app-eigenaren.
Maak uzelf vertrouwd met de concepten van het app-toestemmingsonderzoek (onderdeel van https://aka.ms/IRPlaybooks).
Zorg ervoor dat u de volgende Microsoft Entra-machtigingen begrijpt:
Raak vertrouwd met de concepten van detectie van identiteitsrisico's voor workloads.
U moet een volledige Microsoft 365 E5-licentie hebben om Microsoft Defender voor Cloud Apps te kunnen gebruiken.
- Inzicht in de concepten van anomaliedetectiewaarschuwingsonderzoek
Vertrouwd raken met het volgende beleid voor toepassingsbeheer:
Zorg dat u vertrouwd raakt met het volgende beleid voor app-governance:
Vereiste hulpprogramma's
Installeer voor een effectief onderzoek de volgende PowerShell-module en de toolkit op uw onderzoekscomputer:
Workflow
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, microsoft Entra-aanmeldingslogboeken of een detectie van identiteitsbeveiliging. 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 Microsoft Entra ID P2-licentiesuite beschikbaar of geconfigureerd hebben. In dit playbook worden andere automatiseringsmogelijkheden gemarkeerd, indien van toepassing.
Toepassingstype bepalen
Het is belangrijk om het type toepassing (meerdere of één tenant) vroeg in de onderzoeksfase te bepalen om de juiste informatie op te halen die nodig is om contact op te halen met de eigenaar van de toepassing. Zie Tenancy in Microsoft Entra ID voor meer informatie.
Toepassingen met 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 aan de eigenaar van de toepassing te melden en te melden.
Toepassingen met één tenant
Zoek de contactgegevens van de eigenaar van de toepassing binnen uw organisatie. U vindt deze op het tabblad Eigenaren in de sectie Bedrijfstoepassingen . Uw organisatie kan ook een database met deze gegevens hebben.
U kunt deze Microsoft Graph-query ook uitvoeren:
GET https://graph.microsoft.com/v1.0/applications/{id}/owners
Identity Protection controleren - riskante workloadidentiteiten
Deze functie is in preview op het moment van schrijven van dit playbook en licentievereisten 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 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. U kunt ook prompts in natuurlijke taal gebruiken om inzicht te krijgen in riskante workloadidentiteiten met Microsoft Security Copilot in Microsoft Entra.
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, Microsoft Sentinel of het SIEM-systeem (Security Information and Event Management) van uw organisatie naar het volgende in de sectie Aanmeldingen van 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 zich voordoen 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 Microsoft Entra ID Identity Protection - riskante workloadidentiteiten hebt geïmplementeerd, controleert u de detecties van verdachte aanmeldingen en lekreferenties. Zie bewaringen van identiteitsrisico's voor werkbelastingen voor meer informatie.
De doelresource controleren
Controleer binnen aanmeldingen van de service-principal ook de resource waartoe de service-principal toegang had tijdens de verificatie. Het is belangrijk om invoer te krijgen van de eigenaar van de toepassing, omdat ze bekend zijn met de resources waartoe de service-principal toegang moet hebben.
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 updatetoepassing: certificaten en geheimenbeheer.
- Controleer of er nieuw gemaakte of onverwachte referenties zijn toegewezen aan de service-principal.
- Controleer op referenties voor service-principals met behulp van Microsoft Graph API.
- Controleer zowel de toepassing als de bijbehorende service-principal-objecten.
- Controleer een aangepaste rol die u hebt gemaakt of gewijzigd. Let op de machtigingen die hieronder zijn gemarkeerd:
Als u app-beheer hebt geïmplementeerd in Microsoft Defender voor Cloud Apps, 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 identiteitsgeschiedenis van de gebruiker of workload.
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.
Afwijkende app-configuratiewijzigingen zoeken
- Controleer de API-machtigingen die aan de app zijn toegewezen om ervoor te zorgen dat de machtigingen consistent zijn met wat er voor de app wordt verwacht.
- Controleer auditlogboeken (filter activity by Update Application or Update Service Principal).
- Controleer of de verbindingsreeks 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 beleidsregels allemaal zijn ingeschakeld. Zie het OAuth-app-beleid voor meer informatie. U kunt ook informatie bekijken over de prevalentie van apps en recente activiteit op het tabblad Onderzoek>OAuth-apps.
Controleren op verdachte toepassingsrollen
- U kunt ook de auditlogboeken gebruiken. Filter Activiteit op Roltoewijzing van app toevoegen 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 commerciële galerietoepassingen (gepubliceerde en geverifieerde versies) worden gebruikt.
Controleren op indicaties van openbaarmaking van keyCredential-eigenschappen
Controleer uw tenant op mogelijke openbaarmaking van keyCredential-eigenschappen zoals beschreven in CVE-2021-42306.
Als u betrokken Microsoft Entra-toepassingen wilt identificeren en herstellen die zijn gekoppeld aan beïnvloede Automation Uitvoeren als-accounts, gaat u naar de richtlijnen voor herstel in GitHub-opslagplaats.
Belangrijk
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. Deze stappen helpen het risico aan te pakken, maar voer verder onderzoek uit 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 voor het verkrijgen van toegang tot systemen via het gebruik van toepassingen. De eerste is dat een toepassing wordt toegestaan door een beheerder of gebruiker, meestal via een phishing-aanval. Deze methode maakt deel uit van de eerste toegang tot een systeem en wordt vaak 'toestemming phishing' genoemd.
De tweede methode omvat een al gecompromitteerd beheerdersaccount dat een nieuwe app maakt voor persistentie, gegevensverzameling en om onder de radar te blijven. Een gecompromitteerde beheerder kan bijvoorbeeld een OAuth-app maken met een schijnbaar onschuldige naam, detectie voorkomen en langetermijntoegang tot gegevens toestaan zonder dat er een account nodig is. Deze methode wordt vaak gezien in nationale staatsaanvallen.
Hier volgen enkele van de stappen die kunnen worden ondernomen om verder te onderzoeken.
Controleer Microsoft 365 Unified Audit Log (UAL) op phishing-indicaties voor de afgelopen zeven dagen
Wanneer aanvallers schadelijke of gecompromitteerde toepassingen gebruiken als een middel voor persistentie 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
- Toestemmingsbeheerders
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 zeven 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.
Toepassingstoestemming voor de gemarkeerde toepassing controleren
Auditlogboeken controleren
Als u alle toestemmingstoestemmingen voor die toepassing wilt zien, filtert u activiteit op toestemming voor de toepassing.
De auditlogboeken van het Microsoft Entra-beheercentrum 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": "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) Log Analytics gebruiken
AuditLogs
| where ActivityDisplayName == "Consent to application"
Zie het Playbook Application Consent Grant Investigation voor meer informatie.
Bepalen of er verdachte toestemming van de eindgebruiker is voor de toepassing
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.
Gebruik LogAnalytics om apps te vinden die zijn toegestaan door gebruikers 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 beheerderstoestemming)
Het controleren van de machtigingen die zijn verleend aan een toepassing of service-principal, kan een tijdrovende taak zijn. Begin met het begrijpen van de potentieel riskante machtigingen in Microsoft Entra-id.
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 Microsoft Entra gebruiken, filteren op Toestemming voor de toepassing. Klik in de sectie Details van auditlogboek op Eigenschappen gewijzigd en controleer vervolgens de ConsentAction.Permissions:
Insluitingsstappen
Nadat u een of meer toepassingen of workloadidentiteiten hebt geïdentificeerd als schadelijk of gecompromitteerd, wilt u mogelijk niet onmiddellijk de referenties voor deze toepassing uitrollen, noch wilt u de toepassing onmiddellijk verwijderen.
Belangrijk
Voordat u de volgende stap uitvoert, moet uw organisatie de beveiligingsimpact en de bedrijfsimpact van het uitschakelen van een toepassing afwegen. Als het bedrijfseffect 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.
Gecompromitteerde toepassing uitschakelen
Een typische insluitingsstrategie omvat het uitschakelen van aanmeldingen voor de geïdentificeerde toepassing, om uw incidentresponsteam of de betreffende bedrijfseenheidtijd te geven om de impact van verwijdering of het rollen van sleutels te evalueren. Als uw onderzoek ertoe leidt dat u denkt dat de referenties van het beheerdersaccount ook worden aangetast, moet dit type activiteit worden gecoördineerd met een verwijderingsgebeurtenis om ervoor te zorgen dat alle routes voor toegang tot de tenant gelijktijdig worden afgesloten.
U kunt ook de volgende Microsoft Graph 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-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
}
Herstelstappen
Service-principals herstellen
Geef alle referenties weer 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 id is doorgegeven, is de object-id van de toepassing.
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": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333", "secretText": null, "startDateTime": "2021-06-16T18:19:36.997Z" } ],
Voeg een nieuwe certificaatreferentie (x509) toe aan het toepassingsobject met behulp van de addKey-API van de toepassing.
POST ~/applications/{id}/addKeyVerwijder onmiddellijk alle oude referenties. Verwijder deze voor elke oude wachtwoordreferentie met behulp van:
POST ~/applications/{id}/removePasswordVerwijder deze voor elke oude sleutelreferentie met behulp van:
POST ~/applications/{id}/removeKeyHerstel alle service-principals die aan de toepassing zijn gekoppeld. Volg deze stap als uw tenanthosts/registreert een toepassing met meerdere tenants en/of meerdere service-principals registreert die aan de toepassing zijn gekoppeld. Voer vergelijkbare stappen uit als wat eerder wordt vermeld:
GET ~/servicePrincipals/{id}
Find passwordCredentials and keyCredentials in the response, record all old keyIds
Verwijder alle oude wachtwoord- en sleutelreferenties. Gebruik:
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, met 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 verwijderen en rollen van certificaten en geheimen van een service-principal of toepassing voor meer informatie.
Zie de Handleiding voor beveiligingsbewerkingen van Microsoft Entra voor toepassingen voor Microsoft Entra SecOps-richtlijnen voor toepassingen.
In volgorde van prioriteit is dit scenario:
- Werk Graph PowerShell-cmdlets (Add/Remove ApplicationKey + ApplicationPassword) bij met voorbeelden voor referentieroll-over.
- Voeg aangepaste cmdlets toe aan Microsoft Graph PowerShell die dit scenario vereenvoudigt.
Schadelijke toepassingen uitschakelen of verwijderen
Een toepassing kan worden uitgeschakeld of verwijderd. Als u de toepassing wilt uitschakelen, verplaatst u de wisselknop onder Ingeschakeld voor gebruikers om zich aan te melden 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 tot 30 dagen na verwijdering worden hersteld.
DELETE /applications/{id}
Als u de toepassing definitief wilt verwijderen, gebruikt u deze Microsoft Graph API-aanroep:
DELETE /directory/deletedItems/{id}
Als u de toepassing uitschakelt of als u de toepassing voorlopig verwijdert, stelt u bewaking in microsoft Entra-auditlogboeken in om te zien of de status weer wordt ingeschakeld of hersteld.
Logboekregistratie voor ingeschakeld:
- Service - Core Directory
- Activiteitstype - Service-principal bijwerken
- Categorie - Toepassingsbeheer
- Gestart door (actor) - UPN van actor
- Doelen - App-id en weergavenaam
- Gewijzigde eigenschappen - Eigenschapsnaam = account ingeschakeld, nieuwe waarde = true
Logboekregistratie voor hersteld:
- Service - Core Directory
- Activiteitstype - Service-principal toevoegen
- Categorie - Toepassingsbeheer
- Gestart door (actor) - UPN van actor
- Doelen - App-id en weergavenaam
- Gewijzigde eigenschappen - Eigenschapsnaam = account ingeschakeld, nieuwe waarde = true
Notitie
Microsoft schakelt wereldwijd toepassingen uit die zijn servicevoorwaarden schenden. In die gevallen worden deze toepassingen weergegeven DisabledDueToViolationOfServicesAgreement in de disabledByMicrosoftStatus eigenschap van de gerelateerde toepassing en resourcetypen van de service-principal in Microsoft Graph. Als u wilt voorkomen dat ze in uw organisatie in de toekomst opnieuw worden geïnstantieerd, kunt u deze objecten niet verwijderen.
Identity Protection implementeren voor workloadidentiteiten
Microsoft detecteert risico's voor workloadidentiteiten voor aanmeldingsgedrag en offline-indicatoren van inbreuk.
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 diagnostische instellingen of de Identity Protection-API's.
Voorwaardelijke toegang voor riskante workloadidentiteiten
Met voorwaardelijke toegang kunt u de toegang blokkeren voor specifieke accounts die u aanwijst wanneer Identity Protection deze als 'risico' markeert. De afdwinging via voorwaardelijke toegang is momenteel beperkt tot toepassingen met één tenant.
Zie Voorwaardelijke toegang voor workloadidentiteiten voor meer informatie.
Beleid voor toepassingsrisico's implementeren
Instellingen voor gebruikerstoestemming controleren
Controleer de instellingen voor gebruikerstoestemming onder Microsoft Entra ID>Enterprise-toepassingen>voor gebruikerstoestemmingsinstellingen.
Zie Configureren hoe gebruikers toestemming geven voor apps om de configuratieopties te bekijken.
Stroom voor beheerderstoestemming implementeren
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 voor hun gebruikers uit om toestemming te geven voor toepassingen. Als u gebruikers de mogelijkheid wilt geven om nog steeds toestemming te vragen voor toepassingen en beheerdersbeoordelingsmogelijkheden te hebben, is het raadzaam om de werkstroom voor beheerderstoestemming te implementeren. Volg de stappen voor de werkstroom voor beheerderstoestemming om deze in uw tenant te configureren.
Voor bewerkingen met hoge bevoegdheden, zoals beheerderstoestemming, hebt u een strategie voor bevoegde toegang gedefinieerd in onze richtlijnen.
Instellingen voor stapsgewijze toestemming op basis van risico's controleren
Stapsgewijze toestemming op basis van risico's helpt de blootstelling van gebruikers aan schadelijke apps te verminderen. Toestemmingsaanvragen voor nieuw geregistreerde multitenant-apps die niet door de uitgever zijn geverifieerd en waarvoor niet-basismachtigingen zijn vereist, worden bijvoorbeeld als riskant beschouwd. Als er een riskante gebruikerstoestemmingsaanvraag wordt gedetecteerd, is voor de aanvraag een 'step-up' vereist voor beheerderstoestemming. Deze stapfunctie is standaard ingeschakeld, maar 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.
Verwijzingen
- Playbooks voor reactie op incidenten
- App-toestemming verlenen
- Risico's van Microsoft Entra ID Protection
- Microsoft Entra-beveiligingsbewakingshandleiding
- Concepten voor toepassingscontrole
- Configureren hoe gebruikers toestemming geven voor toepassingen
- Werkstroom voor beheerderstoestemming configureren
- Ongebruikelijke toevoeging van referenties aan een OAuth-app
- Workloadidentiteiten beveiligen met Identity Protection
- Holistische gecompromitteerde identiteitssignalen van Microsoft
Aanvullende playbooks voor reactie op incidenten
Bekijk richtlijnen voor het identificeren en onderzoeken van deze aanvullende typen aanvallen:
Resources voor reactie op incidenten
- Overzicht van Microsoft-beveiligingsproducten en -resources voor nieuwe rollen en ervaren analisten
- Planning voor uw Security Operations Center (SOC)
- Microsoft Defender XDR-incidentrespons
- Microsoft Defender voor Cloud (Azure)
- Reactie op microsoft Sentinel-incidenten
-
Microsoft Incident Response team guide shares best practices for security teams and leaders
- Handleidingen voor het reageren op incidenten van Microsoft helpen beveiligingsteams verdachte activiteiten te analyseren