Bewerken

Delen via

Infrastructuur voor hybride berichten met verbeterde beveiliging - webtoegang

Microsoft Entra ID
Microsoft 365
Office 365

De oplossing in dit artikel biedt een manier om uw berichtenservice (webversie van Outlook of Exchange Configuratiescherm) te beveiligen wanneer postvakken worden gehost in Exchange Online of Exchange On-Premises.

Architectuur

In deze architectuur verdelen we de oplossing in twee gebieden, waarin de beveiliging wordt beschreven voor:

  • Exchange Online, aan de rechterkant van het diagram.
  • Exchange on-premises in een hybride of niet-hybride scenario aan de linkerkant van het diagram.

Schermopname van een architectuur voor verbeterde beveiliging in een webtoegangsscenario.

Een Visio-bestand van deze architectuur downloaden.

Algemene notities

  • Deze architectuur maakt gebruik van het federatieve Microsoft Entra-identiteitsmodel. Voor de wachtwoord-hashsynchronisatie en passthrough-verificatiemodellen zijn de logica en de stroom hetzelfde. Het enige verschil is gerelateerd aan het feit dat Microsoft Entra-id de verificatieaanvraag niet omleidt naar on-premises Active Directory Federation Services (AD FS).
  • Het diagram toont toegang tot de webversie van Outlook-service die overeenkomt met een .../owa-pad. Exchange-beheercentrum (of Exchange Configuratiescherm) gebruikerstoegang die overeenkomt met een .../ecp-pad volgt dezelfde stroom.
  • In het diagram geven stippellijnen basisinteracties weer tussen lokale Active Directory-, Microsoft Entra Connect-, Microsoft Entra-id-, AD FS- en web-toepassingsproxy-onderdelen. Meer informatie over deze interacties vindt u in vereiste poorten en protocollen voor hybride identiteiten.
  • Door Exchange on-premises bedoelen we Exchange 2019 met de nieuwste updates, postvakrol. Door Exchange Edge on-premises bedoelen we Exchange 2019 met de nieuwste updates, edge-transportrol. We nemen de Edge-server in het diagram op om aan te geven dat u deze in deze scenario's kunt gebruiken. Het is niet betrokken bij het werk met clientprotocollen die hier worden besproken.
  • In een echte omgeving hebt u niet slechts één server. U hebt een matrix met gelijke taakverdeling van Exchange-servers voor hoge beschikbaarheid. De scenario's die hier worden beschreven, zijn geschikt voor die configuratie.

Stroom van Exchange Online-gebruiker

  1. Een gebruiker probeert toegang te krijgen tot webversie van Outlook service via https://outlook.office.com/owa.

  2. Exchange Online leidt de gebruiker om naar Microsoft Entra-id voor verificatie.

    Als het domein federatief is, stuurt Microsoft Entra ID de gebruiker om naar het lokale AD FS-exemplaar voor verificatie. Als de verificatie slaagt, wordt de gebruiker teruggeleid naar de Microsoft Entra-id. (Om het diagram eenvoudig te houden, hebben we dit federatieve scenario weggelaten.)

  3. Als u meervoudige verificatie wilt afdwingen, past Microsoft Entra ID een Beleid voor voorwaardelijke toegang van Azure toe met een meervoudige verificatievereiste voor de browserclienttoepassing. Zie de implementatiesectie van dit artikel voor informatie over het instellen van dat beleid.

  4. Het beleid voor voorwaardelijke toegang roept Meervoudige Verificatie van Microsoft Entra aan. De gebruiker ontvangt een aanvraag om meervoudige verificatie te voltooien.

  5. De gebruiker voltooit meervoudige verificatie.

  6. Microsoft Entra ID leidt de geverifieerde websessie om naar Exchange Online en de gebruiker heeft toegang tot Outlook.

Stroom van exchange on-premises gebruiker

  1. Een gebruiker probeert toegang te krijgen tot de webversie van Outlook-service via een https://mail.contoso.com/owa URL die verwijst naar een Exchange-server voor interne toegang of naar een web-toepassingsproxy-server voor externe toegang.

  2. Exchange on-premises (voor interne toegang) of web-toepassingsproxy (voor externe toegang) leidt de gebruiker om naar AD FS voor verificatie.

  3. AD FS maakt gebruik van geïntegreerde Windows-verificatie voor interne toegang of biedt een webformulier waarin de gebruiker referenties voor externe toegang kan invoeren.

  4. Ad FS roept Microsoft Entra multifactor authentication aan om de verificatie te voltooien als reactie op een AF DS-toegangsbeheerbeleid. Hier volgt een voorbeeld van dat type AD FS-toegangsbeheerbeleid:

    Schermopname van een voorbeeld van een AD FS-toegangsbeheerbeleid.

    De gebruiker ontvangt een aanvraag om meervoudige verificatie te voltooien.

  5. De gebruiker voltooit meervoudige verificatie. AD FS leidt de geverifieerde websessie om naar Exchange on-premises.

  6. De gebruiker heeft toegang tot Outlook.

Als u dit scenario voor een on-premises gebruiker wilt implementeren, moet u Exchange en AD FS configureren om AD FS in te stellen om aanvragen voor webtoegang vooraf te verifiëren. Zie AD FS-verificatie op basis van claims gebruiken met webversie van Outlook voor meer informatie.

U moet ook integratie van AD FS en Microsoft Entra multifactor authentication inschakelen. Zie Azure MFA configureren als verificatieprovider met AD FS voor meer informatie. (Voor deze integratie is AD FS 2016 of 2019 vereist.) Ten slotte moet u gebruikers synchroniseren met Microsoft Entra ID en hen licenties toewijzen voor Meervoudige Verificatie van Microsoft Entra.

Onderdelen

  • Microsoft Entra-id. Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer van Microsoft. Het biedt moderne verificatie die is gebaseerd op EvoSTS (een beveiligingstokenservice die wordt gebruikt door Microsoft Entra ID). Deze wordt gebruikt als een verificatieserver voor Exchange Server on-premises.

  • Meervoudige verificatie van Microsoft Entra. Meervoudige verificatie is een proces waarbij gebruikers tijdens het aanmeldingsproces worden gevraagd om een andere vorm van identificatie, zoals een code op hun mobiele telefoon of een vingerafdrukscan.

  • Voorwaardelijke toegang van Microsoft Entra. Voorwaardelijke toegang is de functie die door Microsoft Entra ID wordt gebruikt om organisatiebeleid af te dwingen, zoals meervoudige verificatie.

  • AD FS. AD FS maakt federatief identiteits- en toegangsbeheer mogelijk door digitale identiteit en rechtenrechten te delen over de grenzen van beveiliging en ondernemingen met verbeterde beveiliging. In deze architectuur wordt het gebruikt om aanmelding voor gebruikers met federatieve identiteit mogelijk te maken.

  • Web toepassingsproxy. Web toepassingsproxy verifieert vooraf de toegang tot webtoepassingen met behulp van AD FS. Het werkt ook als een AD FS-proxy.

  • Exchange Server. Exchange Server host gebruikerspostvakken on-premises. In deze architectuur worden tokens gebruikt die zijn uitgegeven aan de gebruiker door Microsoft Entra ID om toegang tot postvakken te autoriseren.

  • Active Directory-services. Active Directory-services slaan informatie op over leden van een domein, inclusief apparaten en gebruikers. In deze architectuur behoren gebruikersaccounts tot Active Directory-services en worden ze gesynchroniseerd met Microsoft Entra-id.

Scenariodetails

Enterprise Messaging Infrastructure (EMI) is een belangrijke service voor organisaties. Overstappen van oudere, minder veilige verificatiemethoden en autorisatie naar moderne verificatie is een kritieke uitdaging in een wereld waarin werken op afstand gebruikelijk is. Het implementeren van meervoudige verificatievereisten voor toegang tot de berichtenservice is een van de meest effectieve manieren om aan die uitdaging te voldoen.

In dit artikel wordt een architectuur beschreven om uw beveiliging in een webtoegangsscenario te verbeteren met behulp van Meervoudige Verificatie van Microsoft Entra.

In de volgende architecturen worden scenario's beschreven waarmee u uw berichtenservice (webversie van Outlook of Exchange Configuratiescherm) kunt beveiligen wanneer postvakken worden gehost in Exchange Online of Exchange On-Premises.

Zie de volgende artikelen voor meer informatie over het toepassen van meervoudige verificatie in andere scenario's voor hybride berichten:

In dit artikel worden geen andere protocollen besproken, zoals IMAP of POP. We raden u niet aan deze te gebruiken om gebruikerstoegang te bieden.

Potentiële gebruikscases

Deze architectuur is relevant voor de volgende scenario's:

  • Verbeter de beveiliging van EMI.
  • Een Zero Trust-beveiligingsstrategie aannemen.
  • Pas uw standaard hoge beveiligingsniveau toe voor uw on-premises berichtenservice tijdens de overgang naar of co-existentie met Exchange Online.
  • Dwing strikte beveiligings- of nalevingsvereisten af in gesloten of zeer beveiligde organisaties, zoals organisaties in de financiële sector.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Beschikbaarheid

De algehele beschikbaarheid is afhankelijk van de beschikbaarheid van de betrokken onderdelen. Zie deze resources voor meer informatie over beschikbaarheid:

De beschikbaarheid van on-premises oplossingsonderdelen is afhankelijk van het geïmplementeerde ontwerp, de beschikbaarheid van hardware en uw interne bewerkingen en onderhoudsroutines. Zie de volgende bronnen voor informatie over beschikbaarheid over sommige van deze onderdelen:

Tolerantie

Zie de volgende bronnen voor informatie over de tolerantie van de onderdelen in deze architectuur.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Zie de volgende bronnen voor informatie over de beveiliging van de onderdelen in deze architectuur:

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

De kosten van uw implementatie zijn afhankelijk van uw Microsoft Entra-id en microsoft 365-licentiekosten. Totale kosten omvatten ook kosten voor software en hardware voor on-premises onderdelen, IT-bewerkingen, training en onderwijs en projectuitvoering.

Voor de oplossing is ten minste Microsoft Entra ID P1 vereist. Zie Prijzen van Microsoft Entra voor meer informatie over prijzen.

Zie prijzen voor Exchange Server voor meer informatie over Exchange.

Zie Prijzen en licenties voor Windows Server 2022 voor informatie over AD FS en web-toepassingsproxy.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid van uw workload om op een efficiënte manier te schalen om te voldoen aan de eisen die gebruikers erop stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

Prestaties zijn afhankelijk van de prestaties van de betrokken onderdelen en de netwerkprestaties van uw bedrijf. Zie De prestaties van Office 365 afstemmen met basislijnen en prestatiegeschiedenis voor meer informatie.

Zie de volgende bronnen voor informatie over on-premises factoren die van invloed zijn op de prestaties voor scenario's met AD FS-services:

Schaalbaarheid

Zie Planning voor AD FS-servercapaciteit voor informatie over de schaalbaarheid van AD FS.

Zie de voorkeursarchitectuur van Exchange 2019 voor informatie over de schaalbaarheid van Exchange Server on-premises.

Dit scenario implementeren

Voer de volgende stappen op hoog niveau uit om dit scenario te implementeren:

  1. Begin met de webtoegangsservice. Verbeter de beveiliging met behulp van een Beleid voor voorwaardelijke toegang van Azure voor Exchange Online.
  2. Verbeter de beveiliging van webtoegang voor on-premises EMI met ad FS-verificatie op basis van claims.

Beleid voor voorwaardelijke toegang instellen

Als u een Microsoft Entra-beleid voor voorwaardelijke toegang wilt instellen dat meervoudige verificatie afdwingt, zoals beschreven in stap 3 van de stroom van de onlinegebruiker eerder in dit artikel:

  1. Configureer Office 365 Exchange Online of Office 365 als een cloud-app:

    Schermopname van het configureren van Office als een cloudtoepassing.

  2. Configureer de browser als een client-app:

    Schermopname van het toepassen van het beleid op de browser.

  3. Pas de vereiste voor meervoudige verificatie toe in het venster Verlenen :

    Schermopname van het toepassen van de vereiste voor meervoudige verificatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen