Delen via

Voorwaardelijke toegang: doelbronnen

Doelresources (voorheen Cloud-apps, acties en verificatiecontext) zijn belangrijke signalen in een beleid voor voorwaardelijke toegang. Met beleid voor voorwaardelijke toegang kunnen beheerders maatregelen toewijzen aan specifieke toepassingen, services, acties of authenticatiecontext.

  • Beheerders kunnen kiezen uit de lijst met toepassingen of services die ingebouwde Microsoft-toepassingen en alle geïntegreerde Microsoft Entra-toepassingen bevatten, waaronder galerie, niet-galerie en toepassingen die zijn gepubliceerd via toepassingsproxy.
  • Beheerders kunnen ervoor kiezen om beleid te definiëren dat niet is gebaseerd op een cloudtoepassing, maar op een gebruikersactie , zoals Beveiligingsgegevens registrerenof apparaten registreren of toevoegen, waardoor voorwaardelijke toegang besturingselementen rond deze acties kan afdwingen.
  • Beheerders kunnen profielen voor het doorsturen van verkeer vanuit Global Secure Access richten voor verbeterde functionaliteit.
  • Beheerders kunnen verificatiecontext gebruiken om een extra beveiligingslaag in toepassingen te bieden.

Schermopname van beleid voor voorwaardelijke toegang en het deelvenster doelbronnen.

Microsoft-cloudtoepassingen

Beheerders kunnen een voorwaardelijk toegangsbeleid toewijzen aan cloud-apps van Microsoft, zolang de servicehoofdpersoon in hun tenant verschijnt, met uitzondering van Microsoft Graph. Microsoft Graph fungeert als een overkoepelende resource. Gebruik Doelgroeprapportage om de onderliggende services te bekijken en deze services in uw beleid te richten. Sommige apps, zoals Office 365 en Windows Azure Service Management-API , bevatten meerdere gerelateerde onderliggende apps of services. Wanneer er nieuwe Microsoft-cloudtoepassingen worden gemaakt, worden deze weergegeven in de app-kiezerlijst zodra de service-principal in de tenant is gemaakt.

Office 365

Microsoft 365 biedt cloudservices voor productiviteit en samenwerking, zoals Exchange, SharePoint en Microsoft Teams. Microsoft 365-cloudservices zijn diep geïntegreerd om soepele samenwerkingservaringen te garanderen. Deze integratie kan verwarring veroorzaken bij het maken van beleidsregels, omdat sommige apps zoals Microsoft Teams afhankelijk zijn van andere toepassingen, zoals SharePoint of Exchange.

De Office 365-suite maakt het mogelijk om u op al deze services tegelijk te richten. U wordt aangeraden de nieuwe Office 365-suite te gebruiken in plaats van afzonderlijke cloud-apps te gebruiken om problemen met serviceafhankelijkheden te voorkomen.

Als u zich richt op deze groep toepassingen, kunt u problemen voorkomen die kunnen optreden vanwege inconsistent beleid en afhankelijkheden. Bijvoorbeeld: de Exchange Online-app is gekoppeld aan traditionele Exchange Online-gegevens, zoals e-mail, agenda en contactgegevens. Gerelateerde metagegevens kunnen worden weergegeven via verschillende resources, zoals zoeken. Om ervoor te zorgen dat alle metagegevens zoals bedoeld worden beveiligd, moeten beheerders beleidsregels toewijzen aan de Office 365-app.

Beheerders kunnen de volledige Office 365-suite of specifieke Office 365-cloud-apps uitsluiten van het beleid voor voorwaardelijke toegang.

Een volledige lijst met alle services die zijn opgenomen, vindt u in het artikel Apps die zijn opgenomen in het Office 365-app-pakket voor voorwaardelijke toegang.

Windows Azure Service Management-API

Wanneer u zich richt op de Microsoft Azure Service Management API-toepassing, wordt beleid afgedwongen voor tokens die zijn uitgegeven aan een set services die nauw zijn gekoppeld aan de portal. Deze groepering omvat de toepassings-id's van:

  • Azure Resource Manager
  • Azure Portal, dat ook betrekking heeft op het Microsoft Entra-beheercentrum
  • Azure Data Lake
  • API voor Application Insights
  • API voor Loganalyse

Omdat het beleid wordt toegepast op de Azure-beheerportal en API, kunnen alle services of clients die afhankelijk zijn van de Azure-API indirect worden beïnvloed. Voorbeeld:

  • Azure-CLI
  • Azure Data Factory-portal
  • Azure DevOps
  • Azure Event Hubs
  • Azure PowerShell
  • Azure Service Bus (een cloud-gebaseerde berichtendienst van Microsoft)
  • Azure SQL Database
  • Azure Synapse
  • Klassieke implementatiemodel-API's
  • Microsoft 365-beheercentrum
  • Microsoft IoT Central
  • SQL Beheerde Instantie
  • Beheerdersportal voor Visual Studio-abonnementen

Notitie

De Windows Azure Service Management API-toepassing is van toepassing op Azure PowerShell, waarmee de Azure Resource Manager-API wordt aangeroepen. Het is niet van toepassing op Microsoft Graph PowerShell, waarmee de Microsoft Graph API wordt aangeroepen.

Zie Voorwaardelijke toegang: MFA vereisen voor Azure-beheer voor meer informatie over het instellen van een voorbeeldbeleid voor Windows Azure Service Management-API.

Aanbeveling

Voor Azure Government moet u zich richten op de Azure Government Cloud Management API-toepassing.

Microsoft-beheerportal

Wanneer een beleid voor voorwaardelijke toegang gericht is op de Microsoft-beheerportal cloud-app wordt het beleid afgedwongen voor tokens die zijn uitgegeven aan toepassings-id's van de volgende Microsoft-beheerportals:

  • Azure Portal
  • Exchange-beheercentrum
  • Microsoft 365-beheercentrum
  • Microsoft 365 Defender-portal
  • Microsoft Entra-beheercentrum
  • Microsoft Intune-beheercentrum
  • Microsoft Purview-nalevingsportal
  • Microsoft Teams-beheercentrum

We voegen voortdurend meer beheerportals toe aan de lijst.

Notitie

De Microsoft Admin Portals-app is alleen van toepassing op interactieve aanmeldingen op de vermelde beheerportals. Aanmeldingen bij de onderliggende resources of services, zoals Microsoft Graph of Azure Resource Manager-API's, vallen niet onder deze toepassing. Deze resources worden beveiligd door de Windows Azure Service Management API-app . Dankzij deze groepering kunnen klanten overstappen op het MFA-acceptatietraject voor beheerders zonder dat dit van invloed is op automatisering die afhankelijk is van API's en PowerShell. Wanneer u klaar bent, raadt Microsoft aan een beleid te gebruiken waarvoor beheerders MFA altijd moeten uitvoeren voor uitgebreide beveiliging.

Andere toepassingen

Beheerders kunnen in Microsoft Entra geregistreerde toepassingen toevoegen aan het beleid voor voorwaardelijke toegang. Deze toepassingen kunnen het volgende omvatten:

Notitie

Omdat het beleid voor voorwaardelijke toegang de vereisten voor toegang tot een service instelt, kunt u dit niet toepassen op een clienttoepassing (openbaar/systeemeigen). Met andere woorden, het beleid wordt niet rechtstreeks ingesteld op een clienttoepassing (openbaar/systeemeigen), maar wordt toegepast wanneer een client een service aanroept. Een beleidsset in de SharePoint-service is bijvoorbeeld van toepassing op alle clients die SharePoint aanroepen. Een beleid dat is ingesteld op Exchange is van toepassing op de poging om toegang te krijgen tot e-mail met de Outlook-client. Daarom zijn clienttoepassingen (openbaar/systeemeigen) niet beschikbaar voor selectie in de app-kiezer en is voorwaardelijke toegang niet beschikbaar in de toepassingsinstellingen voor de clienttoepassing (openbaar/systeemeigen) die is geregistreerd in uw tenant.

Sommige toepassingen worden helemaal niet weergegeven in het selectiemenu. De enige manier om deze toepassingen op te nemen in een beleid voor voorwaardelijke toegang is door alle resources (voorheen 'Alle cloud-apps') op te nemen of de ontbrekende service-principal toe te voegen met behulp van de Cmdlet New-MgServicePrincipal PowerShell of met behulp van de Microsoft Graph API.

Informatie over voorwaardelijke toegang voor verschillende clienttypen

Voorwaardelijke toegang is van toepassing op resources niet op clients, behalve wanneer de client een vertrouwelijke client is die een id-token aanvraagt.

  • Publieke klant
    • Openbare clients zijn clients die lokaal worden uitgevoerd op apparaten zoals Microsoft Outlook op het bureaublad of mobiele apps zoals Microsoft Teams.
    • Beleidsregels voor voorwaardelijke toegang zijn niet van toepassing op de openbare client zelf, maar zijn van toepassing voor de resources die door de openbare clients zijn aangevraagd.
  • Vertrouwelijke cliënt
    • Voorwaardelijke toegang is van toepassing op de resources die door de client zijn aangevraagd en de vertrouwelijke client zelf als er een id-token wordt aangevraagd.
    • Bijvoorbeeld: Als Outlook Web een token aanvraagt voor bereiken Mail.Read en Files.Read, worden beleidsregels voor voorwaardelijke toegang toegepast voor Exchange en SharePoint. Als Outlook Web bovendien een id-token aanvraagt, past voorwaardelijke toegang ook het beleid voor Outlook Web toe.

Aanmeldingslogboeken voor deze clienttypen bekijken vanuit het Microsoft Entra-beheercentrum:

  1. Meld u aan bij het Microsoft Entra-beheercentrum als minimaal een rapportlezer.
  2. Blader naar Entra IDBewaking & gezondheidAanmeldingslogboeken.
  3. Voeg een filter toe voor het clientreferentietype.
  4. Pas het filter aan om een specifieke set logboeken weer te geven op basis van de clientreferenties die in de aanmelding worden gebruikt.

Zie het artikel Openbare client en vertrouwelijke clienttoepassingen voor meer informatie.

Alle resources

Het toepassen van beleid voor voorwaardelijke toegang op alle resources (voorheen 'Alle cloud-apps') zonder dat er app-uitsluitingen zijn, resulteert in het afdwingen van het beleid voor alle tokenaanvragen van websites en services, waaronder profielen voor het doorsturen van verkeer van globale beveiligde toegang. Deze optie omvat toepassingen die niet afzonderlijk zijn gericht op beleid voor voorwaardelijke toegang, zoals Windows Azure Active Directory (00000002-00000-0000-c000-0000000000000).

Belangrijk

Microsoft raadt aan een basislijnbeleid voor meervoudige verificatie te maken dat is gericht op alle gebruikers en alle resources (zonder app-uitsluitingen), zoals wordt uitgelegd in Meervoudige verificatie vereisen voor alle gebruikers.

Gedrag voor voorwaardelijke toegang wanneer een beleid voor alle resources een app-uitsluiting heeft

Als een app wordt uitgesloten van het beleid, zijn bepaalde scopes met lage rechten eveneens uitgesloten van handhaving van het beleid, om te voorkomen dat gebruikers per ongeluk de toegang wordt ontzegd. Deze scopes maken oproepen naar de onderliggende Graph API, zoals Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) en Microsoft Graph (00000003-0000-0000-c000-000000000000), mogelijk voor toegang tot gebruikersprofiel- en groepslidmaatschapsinformatie die vaak door applicaties wordt gebruikt als onderdeel van authenticatie. Bijvoorbeeld: wanneer Outlook een token voor Exchange aanvraagt, wordt ook gevraagd om het User.Read bereik om de basisaccountgegevens van de huidige gebruiker weer te geven.

De meeste apps hebben een vergelijkbare afhankelijkheid, daarom worden deze scopen met lage bevoegdheden automatisch uitgesloten wanneer een app-uitsluiting in een beleid voor alle resources plaatsvindt. Deze uitsluitingen met beperkte bevoegdheden staan geen toegang tot gegevens toe buiten basisgebruikersprofiel en groepsinformatie. De uitgesloten toepassingsgebieden worden als volgt opgesomd, toestemming is nog steeds vereist voor apps om deze machtigingen te gebruiken.

  • Native clients en single-page applicaties (SPA's) hebben toegang tot de volgende scopes met lage machtigingen:
    • Azure AD Graph: email, offline_access, openid, profileUser.Read
    • Microsoft Graph: email, offline_access, openid, profile, User.ReadPeople.Read
  • Vertrouwelijke clients hebben toegang tot de volgende low privilege scopes als ze zijn uitgesloten van een All resources policy.
    • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.AllUser.ReadBasic.All
    • Microsoft Graph: email, , offline_access, openid, profile, User.Read, , User.Read.AllUser.ReadBasic.AllPeople.ReadPeople.Read.AllGroupMember.Read.AllMember.Read.Hidden

Voor meer informatie over de genoemde toepassingsgebieden, zie Microsoft Graph-machtigingen referentie en toepassingsgebieden en machtigingen in het Microsoft Identity Platform.

Bescherming van directory-informatie

Als het aanbevolen MFA-beleid volgens de basislijn zonder app-uitsluitingen niet kan worden geconfigureerd vanwege zakelijke redenen en het beveiligingsbeleid van uw organisatie directorygerelateerde bereiken met lage bevoegdheden moet bevatten (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), dan is het alternatief om een afzonderlijk voorwaardelijk toegangsbeleid voor Windows Azure Active Directory te maken (00000002-0000-0000-c000-000000000000). Windows Azure Active Directory (ook wel Azure AD Graph genoemd) is een resource die gegevens vertegenwoordigt die zijn opgeslagen in de directory, zoals gebruikers, groepen en toepassingen. De Windows Azure Active Directory-resource is opgenomen in alle resources , maar kan afzonderlijk worden gericht op beleid voor voorwaardelijke toegang met behulp van de volgende stappen:

  1. Meld u aan bij het Microsoft Entra-beheercentrum als een kenmerkdefinitiebeheerder en kenmerktoewijzingsbeheerder.
  2. Blader naaraangepaste beveiligingskenmerken van >.
  3. Maak een nieuwe kenmerkset en kenmerkdefinitie. Zie Aangepaste beveiligingskenmerkdefinities toevoegen of deactiveren in Microsoft Entra-id voor meer informatie.
  4. Blader naar Entra ID>Enterprise-applicaties.
  5. Verwijder het toepassingstypefilter en zoek naar toepassings-id die begint met 00000002-0000-0000-c000-000000000000.
  6. SelecteerAangepaste beveiligingskenmerken> van Windows Azure Active Directory>: toewijzing toevoegen.
  7. Selecteer de kenmerkset en kenmerkwaarde die u wilt gebruiken in het beleid.
  8. Blader naarEntra ID>Voorwaardelijke Toegang>Beleid.
  9. Een bestaand beleid maken of wijzigen.
  10. Selecteer onder Doelresources>Resources (voorheen cloud-apps)>Opnemen>Resources selecteren> en filter bewerken.
  11. Pas het filter aan om de kenmerkenset en definitie van eerder op te nemen.
  12. Het beleid opslaan

Alle internetbronnen met Global Secure Access

Met de optie Alle internetbronnen met globale beveiligde toegang kunnen beheerders zich richten op het profiel voor het doorsturen van internetverkeer vanuit Microsoft Entra Internet Access.

Met deze profielen in Global Secure Access kunnen beheerders definiëren en bepalen hoe verkeer wordt gerouteerd via Microsoft Entra-internettoegang en Microsoft Entra-privétoegang. Profielen voor het doorsturen van verkeer kunnen worden toegewezen aan apparaten en externe netwerken. Zie het artikel Beleid voor voorwaardelijke toegang toepassen op het Microsoft 365-verkeersprofiel voor een voorbeeld van hoe u beleid voor voorwaardelijke toegang toepast op deze verkeersprofielen.

Zie het artikel Global Secure Access Traffic Forwarding-profielen voor meer informatie over deze profielen.

Gebruikersacties

Gebruikersacties zijn taken die een gebruiker uitvoert. Op dit moment ondersteunt voorwaardelijke toegang twee gebruikersacties:

  • Beveiligingsgegevens registreren: met deze gebruikersactie kan beleid voor voorwaardelijke toegang worden afgedwongen wanneer gebruikers die zijn ingeschakeld voor gecombineerde registratie, proberen hun beveiligingsgegevens te registreren. Meer informatie vindt u in het artikel Gecombineerde registratie van beveiligingsgegevens.

Notitie

Wanneer beheerders een beleid toepassen dat gebruikersacties voor het registreren van beveiligingsgegevens target, en het gebruikersaccount een gastaccount van een persoonlijk Microsoft-account (MSA) is, vereist het gebruik van de optie 'Meervoudige verificatie vereisen' dat de MSA-gebruiker beveiligingsgegevens registreert bij de organisatie. Als de gastgebruiker afkomstig is van een andere provider, zoals Google, wordt de toegang geblokkeerd.

  • Apparaten registreren of eraan deelnemen: met deze gebruikersactie kunnen beheerders beleid voor voorwaardelijke toegang afdwingen wanneer gebruikers apparaten registreren of toevoegen aan Microsoft Entra-id. Het biedt granulariteit bij het configureren van meervoudige verificatie voor het registreren of samenvoegen van apparaten in plaats van een tenantbreed beleid dat momenteel bestaat. Er zijn drie belangrijke overwegingen met deze gebruikersactie:
    • Require multifactor authentication is het enige toegangsbeheer dat beschikbaar is met deze gebruikersactie. Alle het andere beheer is uitgeschakeld. Deze beperking voorkomt conflicten met toegangsregels die afhankelijk zijn van de Microsoft Entra-apparaatregistratie of niet gelden voor de Microsoft Entra-apparaatregistratie.
    • Client apps, Filters for devicesen Device state voorwaarden zijn niet beschikbaar voor deze gebruikersactie omdat ze afhankelijk zijn van Microsoft Entra-apparaatregistratie om beleid voor voorwaardelijke toegang af te dwingen.

Waarschuwing

Wanneer een beleid voor voorwaardelijke toegang is geconfigureerd met de gebruikersactie Apparaten registreren of toevoegen, moet u De instellingen voor hetapparaatoverzicht>> van > - Require Multifactor Authentication to register or join devices with Microsoft Entra instellen op Nee. Anders worden de beleidsregels voor voorwaardelijke toegang met deze gebruikersactie niet correct afgedwongen. Meer informatie over deze apparaatinstelling vindt u in Apparaatinstellingen configureren.

Verificatiecontext

Een verificatiecontext kan worden gebruikt om gegevens en acties in toepassingen verder te beveiligen. Deze toepassingen kunnen uw eigen aangepaste toepassingen zijn, aangepaste LOB-toepassingen (Line-Of-Business), toepassingen zoals SharePoint of toepassingen die worden beveiligd door Microsoft Defender voor Cloud-apps.

Een organisatie kan bijvoorbeeld bestanden bewaren op SharePoint-sites, zoals het lunchmenu of hun geheime BBQ-sausrecept. Iedereen heeft mogelijk toegang tot de lunchmenusite, maar gebruikers die toegang hebben tot de geheime BBQ sauce-receptsite, moeten mogelijk toegang hebben vanaf een beheerd apparaat en akkoord gaan met specifieke gebruiksvoorwaarden.

De context voor verificatie werkt met gebruikers of workload-identiteiten, maar niet binnen hetzelfde beleid voor voorwaardelijke toegang.

Verificatiecontexten configureren

Authenticatiecontexten worden beheerd onder Entra ID>Voorwaardelijke Toegang>Authenticatiecontext.

Schermopname van het beheer van verificatiecontexten.

Maak nieuwe verificatiecontextdefinities door Nieuwe verificatiecontext te selecteren. Organisaties zijn beperkt tot een totaal van 99 verificatiecontextdefinities c1-c99. Configureer de volgende kenmerken:

  • Weergavenaam is de naam die wordt gebruikt om de verificatiecontext te identificeren in Microsoft Entra ID en in toepassingen die verificatiecontexten gebruiken. We raden namen aan die kunnen worden gebruikt voor resources, zoals vertrouwde apparaten, om het aantal benodigde verificatiecontexten te verminderen. Een beperkte set vermindert het aantal omleidingen en zorgt voor een betere gebruikerservaring van begin tot eind.
  • Beschrijving bevat meer informatie over het beleid. Deze informatie wordt gebruikt door beheerders en beheerders die verificatiecontexten toepassen op resources.
  • Het selectievakje Publiceren naar apps adverteert, wanneer ingeschakeld, de authenticatiecontext aan apps en maakt deze beschikbaar voor toewijzing. Als er niet op gecontroleerd wordt, is de authenticatiecontext niet beschikbaar voor downstream-bronnen.
  • ID is alleen-lezen en wordt gebruikt in tokens en apps voor contextdefinities voor authenticatie die specifiek zijn voor aanvragen. Hier vermeld voor troubleshooting en gebruiksscenario's bij ontwikkeling.

Toevoegen aan beleid voor voorwaardelijke toegang

Beheerders kunnen gepubliceerde verificatiecontexten selecteren in hun beleid voor voorwaardelijke toegang onder Toewijzingen>Cloud-apps of -acties en verificatiecontext selecteren in het menu Selecteren wat dit beleid van toepassing is .

Schermopname die laat zien hoe u een verificatiecontext voor voorwaardelijke toegang toevoegt aan een beleid

Een verificatiecontext verwijderen

Wanneer u een verificatiecontext verwijdert, moet u ervoor zorgen dat er geen toepassingen meer gebruik van maken. Anders wordt de toegang tot app-gegevens niet meer beveiligd. U kunt deze vereiste bevestigen door aanmeldingslogboeken te controleren voor gevallen waarin het beleid voor voorwaardelijke toegang voor de verificatiecontext wordt toegepast.

Als u een verificatiecontext wilt verwijderen, moet er geen beleid voor voorwaardelijke toegang zijn toegewezen en mag deze niet worden gepubliceerd naar apps. Deze vereiste helpt voorkomen dat een verificatiecontext die nog steeds wordt gebruikt, per ongeluk wordt verwijderd.

Bronnen labelen met verificatiecontexten

Zie de volgende artikelen voor meer informatie over het gebruik van een verificatiecontext in toepassingen.

Volgende stappen