Sessiebeheer en continue toegangsevaluatie implementeren

  • 3 minuten

In complexe implementaties kan het zijn dat organisaties mogelijk verificatiesessies moeten beperken. Enkele scenario's kunnen zijn:

  • Toegang tot resources vanaf een onbeheerd of gedeeld apparaat.
  • Toegang tot gevoelige informatie vanuit een extern netwerk.
  • Gebruikers met hoge prioriteit of leidinggevenden.
  • Kritieke bedrijfstoepassingen.

Met de controles voor voorwaardelijke toegang kunt u beleidsregels maken die gericht zijn op specifieke gebruiksscenario's binnen uw organisatie zonder dat dit van invloed is op alle gebruikers.

Voordat u meer informatie krijgt over het configureren van het beleid, gaan we de standaardconfiguratie bekijken.

Aanmeldingsfrequentie van gebruikers

Met aanmeldingsfrequentie wordt de periode gedefinieerd voordat een gebruiker wordt gevraagd zich opnieuw aan te melden wanneer hij of zij toegang probeert te krijgen tot een resource.

De standaardconfiguratie van Microsoft Entra ID voor de aanmeldingsfrequentie van gebruikers is een voortschrijdend venster van 90 dagen. Het lijkt vaak verstandig om gebruikers om inloggegevens te vragen, maar het kan een averechtse uitwerking hebben: gebruikers die zijn getraind om hun inloggegevens in te voeren zonder erbij na te denken, kunnen deze onbedoeld invoeren in een kwaadwillend venster.

Het kan alarmerend klinken om een gebruiker niet te vragen zich opnieuw aan te melden; in werkelijkheid zal elke schending van IT-beleid de sessie intrekken. Enkele voorbeelden zijn een wachtwoordwijziging, een niet-compatibel apparaat of een account uitgeschakeld. U kunt ook de sessies van gebruikers expliciet intrekken met behulp van PowerShell. De standaardconfiguratie van Microsoft Entra-id komt neer op 'gebruikers niet vragen hun referenties op te geven als de beveiligingspostuur van hun sessies niet is gewijzigd.'

De instelling voor aanmeldingsfrequentie werkt met apps die OAUTH2- of OIDC-protocollen hebben geïmplementeerd volgens de standaarden. De meeste apps voor Windows, Mac en mobiel, met inbegrip van de volgende webtoepassingen, voldoen aan de instelling.

  • Word, Excel, PowerPoint Online
  • OneNote Online
  • Office.com
  • Microsoft 365-beheerportal
  • Exchange Online
  • SharePoint en OneDrive
  • Teams-webclient
  • Dynamics CRM Online
  • Azure Portal

De instelling voor aanmeldingsfrequentie werkt ook met SAML-toepassingen, zolang ze hun eigen cookies niet verwijderen en regelmatig worden omgeleid naar de Microsoft Entra-id voor verificatie.

Aanmeldingsfrequentie van gebruikers en meervoudige verificatie

De aanmeldingsfrequentie werd eerder alleen toegepast op de eerste-factorauthenticatie op apparaten die lid waren van Microsoft Entra, hybride Microsoft Entra, en Microsoft Entra geregistreerd. Onze klanten hadden geen gemakkelijke manier om meervoudige verificatie (MFA) opnieuw af te dwingen op die apparaten. Op basis van feedback van klanten zal de aanmeldingsfrequentie ook voor MFA gelden.

Diagram van het aanmeldingsproces voor meervoudige verificatie met aanmeldingsfrequentie.

Aanmeldingsfrequentie van gebruikers en apparaat-id's

Als u microsoft Entra hebt toegevoegd, hybride Microsoft Entra-gekoppelde apparaten of geregistreerde Microsoft Entra-apparaten, wanneer een gebruiker zijn apparaat ontgrendelt of zich interactief aanmeldt, voldoet deze gebeurtenis ook aan het aanmeldingsfrequentiebeleid. In de volgende twee voorbeelden wordt de aanmeldingsfrequentie van gebruikers ingesteld op één uur:

Voorbeeld 1:

  • Om 00:00 uur meldt een gebruiker zich aan bij het Windows 10 Microsoft Entra-apparaat en begint hij aan een document dat is opgeslagen in SharePoint Online.
  • De gebruiker blijft gedurende een uur aan hetzelfde document op het apparaat werken.
  • Om 01:00 uur wordt de gebruiker gevraagd zich opnieuw aan te melden op basis van de aanmeldingsfrequentievereiste in het beleid voor voorwaardelijke toegang dat is geconfigureerd door de beheerder.

Voorbeeld 2:

  • Om 00:00 uur meldt een gebruiker zich aan bij het Windows 10 Microsoft Entra-apparaat en begint hij aan een document dat is opgeslagen in SharePoint Online.
  • Om 00:30 uur krijgt de gebruiker een pauze, waardoor het apparaat wordt vergrendeld.
  • Om 00:45 uur komt de gebruiker terug van zijn/haar pauze en ontgrendelt het apparaat.
  • Om 01:45 uur wordt de gebruiker gevraagd zich opnieuw aan te melden op basis van de aanmeldingsfrequentievereiste in het beleid voor voorwaardelijke toegang dat is geconfigureerd door de beheerder, aangezien de laatste aanmelding om 00:45 uur gebeurde.

De persistentie van browsesessies

Met een permanente browsersessie kunnen gebruikers aangemeld blijven na het sluiten en opnieuw openen van hun browservenster. Met de standaard microsoft-entra-id voor persistentie van browsersessies kunnen gebruikers op persoonlijke apparaten kiezen of ze de sessie willen behouden door de optie Aangemeld blijven weer te geven. na geslaagde verificatie.

Validatie

Gebruik het hulpprogramma What-If om een aanmelding van de gebruiker naar de doeltoepassing en andere voorwaarden te simuleren op basis van de wijze waarop u uw beleid hebt geconfigureerd. De besturingselementen voor verificatiesessiebeheer worden weergegeven in de resultaten van het hulpprogramma.

Schermopname van de resultaten van het hulpprogramma What If voor voorwaardelijke toegang.

Beleidsimplementatie

Om ervoor te zorgen dat uw beleid werkt zoals verwacht, is de aanbevolen best practice om het te testen voordat het in productie wordt geïmplementeerd. Gebruik idealiter een testtenant om te controleren of uw nieuwe beleid werkt zoals bedoeld.

Continue toegangsevaluatie (CAE)

Het verlopen en vernieuwen van tokens is een standaardmechanisme in de branche. Wanneer een clienttoepassing zoals Outlook verbinding maakt met een service zoals Exchange Online, worden de API-aanvragen geautoriseerd met behulp van OAuth 2.0-toegangstokens. Toegangstokens zijn standaard één uur geldig, wanneer ze verlopen, wordt de client omgeleid naar De Microsoft Entra-id om ze te vernieuwen. Deze vernieuwingsperiode biedt de mogelijkheid om beleidsregels voor gebruikerstoegang opnieuw te beoordelen. Bijvoorbeeld: we kunnen ervoor kiezen om het token niet te vernieuwen vanwege een beleid voor voorwaardelijke toegang of omdat de gebruiker is uitgeschakeld in de map.

Er is echter vertraging tussen wanneer voorwaarden voor een gebruiker worden gewijzigd en wanneer beleidswijzigingen worden afgedwongen. Tijdige reactie op beleidsschendingen of beveiligingsproblemen vereist echt een 'gesprek' tussen de tokenverlener en de relying party (verlichte app). Dit tweerichtingsgesprek biedt ons twee belangrijke mogelijkheden. De vertrouwende partij kan zien wanneer eigenschappen veranderen, zoals netwerklocatie, en dit aan de tokenverlener melden. Het biedt de tokenuitgever ook een manier om de vertrouwende partij te laten stoppen met het accepteren van tokens voor een bepaalde gebruiker wegens een inbreuk op het account, deactivering, of andere zorgen. Het mechanisme voor dit gesprek is continue toegangsevaluatie (CAE).

Voordelen

Er zijn verschillende belangrijke voordelen voor continue toegangsevaluatie.

  • Gebruikersbeëindiging of wachtwoordwijziging/opnieuw instellen: het intrekken van gebruikerssessies wordt in bijna realtime afgedwongen.
  • Netwerklocatie gewijzigd: beleidsregels voor voorwaardelijke toegang worden in bijna realtime afgedwongen.
  • Tokenexport naar een computer buiten een vertrouwd netwerk kan worden voorkomen met locatiebeleid voor voorwaardelijke toegang.

Proces voor evaluatie en intrekking

Diagram van de processtroom wanneer een toegangstoken wordt ingetrokken en een client de toegang opnieuw moet verifiëren.

  1. Een CAE-capabele client presenteert referenties of een verversingstoken aan Microsoft Entra ID met het verzoek om een toegangstoken voor een bepaalde resource.
  2. Een toegangstoken wordt samen met andere artefacten naar de client geretourneerd.
  3. Een beheerder trekt alle vernieuwingstokens voor de gebruiker expliciet in. Er wordt een intrekkingsevenement verzonden naar de resourceprovider van Microsoft Entra ID.
  4. Er wordt een toegangstoken gepresenteerd aan de resourceprovider. De resourceprovider evalueert de geldigheid van het token en controleert of er een intrekkings gebeurtenis voor de gebruiker is. De resourceprovider gebruikt deze informatie om te besluiten om toegang te verlenen tot de resource of niet.
  5. In het geval van het diagram weigert de resourceprovider de toegang en stuurt hij een 401+ claimuitdaging terug naar de client.
  6. De CAE-compatibele client begrijpt de uitdaging met betrekking tot de 401+ claim. Het slaat de caches over en gaat terug naar stap 1, waarbij het vernieuwingstoken samen met de claim-uitdaging terug wordt gestuurd naar Microsoft Entra ID. Microsoft Entra ID evalueert vervolgens alle voorwaarden opnieuw en vraagt de gebruiker om in dit geval opnieuw te verifiëren.