Zero Trust-principes toepassen op een Azure Virtual WAN-implementatie

  • Artikel

Met de moderne ontwikkeling van cloud- en mobiele apparaten en andere eindpunten is het niet langer voldoende om alleen te vertrouwen op bedrijfsfirewalls en perimeternetwerken. Bij een end-to-end Zero Trust-strategie wordt ervan uitgegaan dat beveiligingsschendingen onvermijdelijk zijn. Dit betekent dat u elke aanvraag moet verifiëren alsof deze afkomstig is van een niet-gecontroleerd netwerk. Netwerken spelen nog steeds een belangrijke rol in Zero Trust om infrastructuur, toepassingen en gegevens te verbinden en te beveiligen. In het Zero Trust-model zijn er drie belangrijke doelstellingen voor het beveiligen van uw netwerken:

  • Wees klaar om aanvallen af te handelen voordat ze plaatsvinden.
  • Minimaliseer de omvang van de schade en hoe snel het verspreidt.
  • Vergroot de moeilijkheid om uw cloudvoetafdruk in gevaar te brengen.

Azure Virtual WAN maakt een wereldwijde overdrachtsnetwerkarchitectuur mogelijk door alomtegenwoordige, any-to-any-connectiviteit mogelijk te maken tussen wereldwijd gedistribueerde sets cloudworkloads in virtuele netwerken (VNets), vertakkingssites, SaaS- en PaaS-toepassingen en gebruikers. Het toepassen van een Zero Trust-benadering in Azure Virtual WAN is essentieel om ervoor te zorgen dat uw backbone veilig en beveiligd is.

Dit artikel bevat stappen voor het toepassen van de principes van Zero Trust op een Azure Virtual WAN-implementatie op de volgende manieren:

Zero Trust-principe Definitie Ontmoet door
Expliciet verifiëren Altijd verifiëren en autoriseren op basis van alle beschikbare gegevenspunten. Gebruik Azure Firewall met TLS-inspectie (Transport Layer Security) om risico's en bedreigingen te controleren op basis van alle beschikbare gegevens. Besturingselementen voor voorwaardelijke toegang zijn bedoeld om verificatie en autorisatie te bieden door diverse gegevenspunten en de Azure Firewall voert geen gebruikersverificatie uit.
Toegang met minimale bevoegdheden gebruiken Beperk gebruikerstoegang met Just-In-Time en Just-Enough-Access (JIT/JEA), op risico gebaseerd adaptief beleid en gegevensbeveiliging. Gebruikerstoegang valt buiten het bereik van implementaties van de Azure-netwerkinfrastructuur. Het gebruik van identiteitspijleroplossingen zoals Privileged Access Management, voorwaardelijke toegang en andere besturingselementen zijn de manier om dit principe te leveren.
Stel dat er sprake is van een schending Minimaliseer straal en segmenttoegang. Controleer end-to-end-versleuteling en gebruik analyse om zichtbaarheid te krijgen, detectie van bedreigingen te stimuleren en verdediging te verbeteren. Elk spoke-VNet heeft geen toegang tot andere spoke-VNets, tenzij het verkeer wordt gerouteerd via de firewall die is geïntegreerd in elke Azure Virtual WAN-hub. De firewall is standaard ingesteld op weigeren, zodat alleen verkeer wordt toegestaan door opgegeven regels. In het geval van een inbreuk of schending van één toepassing/workload, heeft het beperkte vermogen om te verspreiden vanwege de Azure Firewall die verkeersinspectie uitvoert en alleen toegestaan verkeer doorstuurt. Alleen resources in dezelfde workload worden blootgesteld aan de inbreuk in dezelfde toepassing.

Zie het overzicht van zero trust toepassen op azure-infrastructuur voor meer informatie over het toepassen van de principes van Zero Trust in een Azure IaaS-omgeving.

Zie NIST Special Publication 800-207 voor een branchediscussie over Zero Trust.

Azure Virtual WAN

Azure Virtual WAN is een netwerkservice die een groot aantal netwerk-, beveiligings- en routeringsfuncties samenbrengt om één operationele interface te bieden. Enkele van de belangrijkste functies zijn:

  • Geavanceerde routeringsfuncties
  • Integratie van 'bump-in-the-wire'-beveiliging via Azure Firewall of ondersteunde NVA's (Network Virtual Appliances) in de hub
  • Versleutelde ExpressRoute

Een Zero Trust-benadering voor Azure Virtual WAN vereist configuratie van verschillende onderliggende services en onderdelen uit de eerder vermelde zero Trust-principetabel. Hier volgt een lijst met stappen en acties:

  • Implementeer Azure Firewall of ondersteunde NGFW-NVA's (Next Generation Firewall) binnen elke Virtual WAN-hub.
  • Configureer inter-VNet- en on-premises vertakkingsroutering om een Zero Trust-omgeving te maken door al het verkeer naar beveiligingsapparaten in de hubs te verzenden voor inspectie. Configureer de routering om filters en beveiliging te bieden voor bekende bedreigingen.
  • Zorg ervoor dat er geen resources in de spokes rechtstreeks toegang hebben tot internet.
  • Bieden microsegmentatie van toepassingen in spoke-netwerken, samen met een microperimeterstrategie voor inkomend/uitgaand verkeer.
  • Biedt waarneembaarheid voor netwerkbeveiligingsevenementen.

Referentiearchitectuur

In het volgende diagram ziet u een algemene referentiearchitectuur die een veelgebruikte omgeving laat zien en hoe u de principes van Zero Trust toepast op Azure Virtual WAN.

Diagram van de referentiearchitectuur voor Azure Virtual Desktop.

Azure Virtual WAN kan worden geïmplementeerd in Basic- en Standard-typen. Voor het toepassen van Zero Trust-principes voor Azure Virtual WAN met Azure Firewall of een NGFW is het standaardtype vereist.

De referentiearchitectuur voor Azure Virtual WAN met beveiligde hubs omvat:

  • Eén logisch Virtual WAN.
  • Twee beveiligde virtuele hubs, één per regio.
  • Een exemplaar van Azure Firewall Premium dat in elke hub is geïmplementeerd.
  • Ten minste één Azure Firewall Premium-beleid.
  • Punt-naar-site (P2S) en site-naar-site-VPN-gateways (S2S) en ExpressRoute-gateways.
  • P2S-, S2S- en ExpressRoute-verbonden vertakkingen.
  • Een VNet met gedeelde services met kerninfrastructuurresources die niet kunnen worden geïmplementeerd in een Virtual WAN-hub, zoals aangepaste DNS-VM's of Azure DNS Private Resolver, Active Directory-domein Services [AD DS]-domeincontrollers, Azure Bastion en andere gedeelde resources.
  • Workload-VNets met Azure-toepassing Gateway, Azure Web Application Firewall (WAF) en privé-eindpunten, indien nodig.

Azure Virtual WAN ondersteunt de integratie van een beperkte set firewalls van derden in de hubs als alternatief voor systeemeigen Azure Firewall. In dit artikel wordt alleen Azure Firewall beschreven. Wat is opgenomen in de VNet-Shared Services-spoke in de referentiearchitectuur is slechts een voorbeeld van wat u kunt implementeren. Microsoft beheert Azure Virtual WAN-hubs en u kunt er niets anders in installeren, behalve wat Azure Firewall en ondersteunde NVA's expliciet toestaan.

Deze referentiearchitectuur is afgestemd op de architectuurprincipes die worden beschreven in het artikel Cloud Adoption Framework voor virtual WAN-netwerktopologie.

Routeringsbeveiliging

Het beveiligen van routedoorgifte en isolatie van on-premises omgevingen is een essentieel beveiligingselement dat moet worden beheerd.

Afgezien van verkeerssegmentatie is routeringsbeveiliging een essentieel onderdeel van elk netwerkbeveiligingsontwerp. Routeringsprotocollen vormen een integraal onderdeel van de meeste netwerken, waaronder Azure. U moet uw infrastructuur beschermen tegen de inherente risico's voor routeringsprotocollen, zoals onjuiste configuraties of schadelijke aanvallen. Het BGP-protocol dat wordt gebruikt voor VPN of ExpressRoute biedt zeer uitgebreide mogelijkheden om uw netwerk te beschermen tegen ongewenste routeringswijzigingen, waaronder de aankondiging van te specifieke routes of te brede routes.

De beste manier om uw netwerk te beveiligen, is het configureren van uw on-premises apparaten met het juiste routebeleid en routetoewijzingen om ervoor te zorgen dat alleen toegestane voorvoegsels worden doorgegeven aan uw netwerk vanuit Azure. U kunt bijvoorbeeld:

  • Blokkeer binnenkomende voorvoegsels die te algemeen zijn.

    Als azure vanwege een onjuiste configuratie algemene voorvoegsels zoals 0.0.0.0.0/0 of 10.0.0.0.0/8 gaat verzenden, kan dit verkeer aantrekken dat anders in uw on-premises netwerk blijft.

  • Binnenkomende voorvoegsels blokkeren die te specifiek zijn.

    Onder bepaalde omstandigheden krijgt u enkele lange IPv4-voorvoegsels van Azure (netwerkvoorvoegsellengte 30 tot 32), die doorgaans zijn opgenomen in andere minder specifieke voorvoegsels en daarom niet vereist. Als u deze voorvoegsels weglaat, kunnen uw on-premises routeringstabellen niet onnodig groot worden.

  • Blokkeer binnenkomende voorvoegsels die zich niet in Azure bevinden, tenzij u Azure als transitnetwerk gebruikt.

    Als u Azure niet gebruikt om verkeer tussen uw on-premises locaties te transporteren (bijvoorbeeld met technologieën zoals ExpressRoute Global Reach), geeft een on-premises voorvoegsel dat vanuit Azure wordt aangekondigd een routeringslus aan. Als u alleen Azure-voorvoegsels in uw on-premises routers gebruikt, wordt u beschermd tegen dit soort routeringslussen.

  • Blokkeer uitgaande voorvoegsels die niet on-premises zijn.

    Als u uw on-premises netwerk niet gebruikt voor transit tussen Azure-regio's, moet u geen reclame maken voor azure-voorvoegsels die u niet on-premises gebruikt. Als u dit niet doet, loopt u het risico om routeringslussen te maken, met name gezien het feit dat eBGP-implementaties in de meeste routers alle voorvoegsels opnieuw adverteren op niet-voorkeurskoppelingen. Dit heeft het effect van het terugsturen van Azure-voorvoegsels naar Azure, tenzij u eBGP meerdere paden hebt geconfigureerd.

Logische architectuur

Azure Virtual WAN is een verzameling hubs en services die beschikbaar worden gesteld in een hub. U kunt zoveel virtuele WAN's implementeren als u nodig hebt. In een Virtual WAN-hub zijn er meerdere services zoals VPN, ExpressRoute, Azure Firewall of een geïntegreerde NVA van derden.

In het volgende diagram ziet u de logische architectuur van de Azure-infrastructuur voor een Azure Virtual WAN-implementatie, zoals weergegeven in het Cloud Adoption Framework.

Diagram van de onderdelen van azure Virtual WAN-topologie en Azure-abonnementen.

Het merendeel van de resources bevindt zich in het connectiviteitsabonnement. U implementeert alle Virtual WAN-resources in één resourcegroep in het connectiviteitsabonnement, inclusief wanneer u in meerdere regio's implementeert. Azure VNet-spokes bevinden zich in de abonnementen voor de landingszone. Als u azure Firewall-beleid voor overname en hiërarchie gebruikt , moeten het bovenliggende beleid en het onderliggende beleid zich in dezelfde regio bevinden. U kunt nog steeds een beleid toepassen dat u in de ene regio hebt gemaakt op een beveiligde hub vanuit een andere regio.

Wat staat er in dit artikel?

In dit artikel worden de stappen beschreven voor het toepassen van de principes van Zero Trust in de Referentiearchitectuur van Azure Virtual WAN.

Stap Taak Zero Trust-principe(en) toegepast
1 Azure Firewall-beleid maken. Expliciet verifiëren
Stel dat er sprake is van een schending
2 Converteer uw Azure Virtual WAN-hubs naar beveiligde hubs. Expliciet verifiëren
Stel dat er sprake is van een schending
3 Beveilig uw verkeer. Expliciet verifiëren
Stel dat er sprake is van een schending
4 Beveilig uw spoke-VNets. Stel dat er sprake is van een schending
5 Controleer uw gebruik van versleuteling. Stel dat er sprake is van een schending
6 Beveilig uw P2S-gebruikers. Stel dat er sprake is van een schending
7 Bewaking, controle en beheer configureren. Stel dat er sprake is van een schending

U moet stap 1 en 2 in volgorde uitvoeren. De andere stappen kunnen in elke volgorde worden uitgevoerd.

Stap 1: Azure Firewall-beleid maken

Voor zelfstandige Azure Firewall-implementaties in een klassieke hub- en spoke-architectuur moet ten minste één Azure-beleid worden gemaakt in Azure Firewall Manager en gekoppeld aan de Azure Virtual WAN-hubs. Dit beleid moet worden gemaakt en beschikbaar worden gesteld voordat een hub wordt geconverteerd. Zodra het beleid is gedefinieerd, wordt het toegepast op Azure Firewall-exemplaren in stap 2.

Azure Firewall-beleid kan worden gerangschikt in een bovenliggende en onderliggende hiërarchie. Voor een klassiek hub- en spoke-scenario of een beheerd Azure Virtual WAN moet u een hoofdbeleid definiëren met een algemene set IT-beveiligingsregels om verkeer toe te staan of te weigeren. Vervolgens kan voor elke hub een onderliggend beleid worden gedefinieerd om hubspecifieke regels te implementeren via overname. Deze stap is optioneel. Als regels die op elke hub moeten worden toegepast identiek zijn, kan één beleid worden toegepast.

Voor Zero Trust is een Premium Azure Firewall-beleid vereist en moet dit de volgende instellingen bevatten:

  • DNS-proxy : u moet Azure Firewall configureren als een aangepaste DNS-server voor spoke-VNets die de echte DNS beveiligen die zich in een gedeelde service-spoke of on-premises bevindt. Azure-firewalls fungeren als een DNS-proxy, luisteren naar UDP-poort 53 en sturen DNS-aanvragen door naar de DNS-servers die zijn opgegeven in de beleidsinstellingen. Voor elke spoke moet u een DNS-server op het niveau van het virtuele netwerk configureren die verwijst naar het interne IP-adres van de Azure Firewall in de Virtual WAN-hub. U moet geen netwerktoegang verlenen vanuit spokes en vertakkingen naar de aangepaste DNS.

  • TLS-inspectie moet zijn ingeschakeld voor deze scenario's:

    • Uitgaande TLS-inspectie om te beschermen tegen schadelijk verkeer dat wordt verzonden van een interne client die wordt gehost in Azure naar internet.

    • TLS-inspectie oost-west om verkeer op te nemen dat naar of van on-premises vertakkingen en tussen Virtual WAN-spokes gaat, waardoor uw Azure-workloads worden beschermd tegen mogelijk schadelijk verkeer dat vanuit Azure wordt verzonden.

  • Inbraakdetectie en preventiesysteem (IDPS) moet zijn ingeschakeld in de modus Waarschuwing en Weigeren.

  • Bedreigingsinformatie moet zijn ingeschakeld in de modus Waarschuwing en Weigeren.

Als onderdeel van het maken van het beleid moet u de benodigde DNAT-regels (Destination Network Address Translation), netwerkregels en toepassingsregels maken om alleen de netwerkstromen in te schakelen voor expliciet toegestaan verkeer. Als u TLS-inspectie wilt inschakelen voor geselecteerde doelen, moet voor de bijbehorende toepassingsregel de instelling TLS-inspectie zijn ingeschakeld. Bij het maken van regels in regelsverzamelingen moet u het meest beperkende doel- en doeltype gebruiken.

Stap 2: Uw Azure Virtual WAN-hubs converteren naar beveiligde hubs

De kern van de Zero Trust-benadering voor Azure Virtual WAN is het concept van beveiligde Virtual WAN-hub (beveiligde hub). Een beveiligde hub is een Azure Virtual WAN-hub met een geïntegreerde Azure Firewall. Het gebruik van ondersteunde beveiligingsapparaten van derden wordt ondersteund als alternatief voor Azure Firewall, maar wordt niet beschreven in dit artikel. U kunt deze virtuele apparaten gebruiken om al het verkeer naar noord-zuid, oost-west en internetverkeer te inspecteren.

We raden Azure Firewall Premium aan voor Zero Trust en dat u deze configureert met het Premium-beleid dat wordt beschreven in stap 1.

Notitie

Het gebruik van DDoS Protection wordt niet ondersteund met een beveiligde hub.

Zie Azure Firewall installeren in een Virtual WAN-hub voor meer informatie.

Stap 3: Uw verkeer beveiligen

Zodra u al uw Azure Virtual WAN-hubs hebt bijgewerkt om hubs te beveiligen, moet u routeringsintentie en beleid configureren voor zero trust-principes. Met deze configuratie kan de Azure Firewall in elke hub verkeer tussen spokes en vertakkingen in dezelfde hub en tussen externe hubs aantrekken en inspecteren. U moet uw beleid configureren voor het verzenden van zowel internetverkeer als privéverkeer via de Azure Firewall of uw NVA van derden. De optie Inter-hub moet ook zijn ingeschakeld. Dit is een voorbeeld.

Voorbeeld van het routeringsbeleid van Azure Firewall.

Wanneer het routeringsbeleid 'Privéverkeer' is ingeschakeld, wordt VNet-verkeer in en uit de Virtual WAN-hub, inclusief verkeer tussen hubs, doorgestuurd naar de volgende hop Azure Firewall of NVA die is opgegeven in het beleid. Gebruikers met RBAC-bevoegdheden (Role-Based Access Control) kunnen virtual WAN-routeprogrammering voor spoke-VNets overschrijven en een aangepaste door de gebruiker gedefinieerde route (UDR) koppelen om de hubfirewall te omzeilen. Om dit beveiligingsprobleem te voorkomen, moeten RBAC-machtigingen voor het toewijzen van UDR's aan spoke-VNet-subnetten worden beperkt tot centrale netwerkbeheerders en niet worden gedelegeerd aan de eigenaren van de landingszone van de spoke-VNets. Als u een UDR wilt koppelen aan een VNet of subnet, moet een gebruiker de rol Netwerkbijdrager of een aangepaste rol hebben met de actie Microsoft.Network/routeTables/join/action of machtiging.

Notitie

In dit artikel wordt Azure Firewall voornamelijk overwogen voor zowel internetverkeer als privéverkeer. Voor internetverkeer kan een externe, ondersteunde NVA voor beveiliging worden gebruikt of een SECaaS-provider (Security as a Service) van derden. Voor privéverkeer kunnen door derden ondersteunde beveiligings-NVA's worden gebruikt als alternatief voor Azure Firewall.

Notitie

Aangepaste routetabellen in Azure Virtual WAN kunnen niet worden gebruikt in combinatie met routeringsintentie en beleid en mogen niet worden beschouwd als een beveiligingsoptie.

Stap 4: Uw spoke-VNets beveiligen

Elke Azure Virtual WAN-hub kan een of meer VNets hebben die zijn verbonden met VNet-peering. Op basis van het landingszonemodel in het Cloud Adoption Framework bevat elk VNet een workload voor landingszones, toepassingen en services die een organisatie ondersteunen. Azure Virtual WAN beheert de verbinding, de routedoorgifte en koppeling en de uitgaande en binnenkomende routering, maar kan geen invloed hebben op de beveiliging binnen VNets. Zero Trust-principes moeten binnen elk spoke-VNet worden toegepast volgens de richtlijnen die zijn gepubliceerd in Zero Trust-principes toepassen op een virtueel spoke-netwerk en andere artikelen, afhankelijk van het resourcetype, zoals virtuele machines en opslag. Houd rekening met de volgende elementen:

Omdat de hub in Azure Virtual WAN is vergrendeld en beheerd door Azure, kunnen daar geen aangepaste onderdelen worden geïnstalleerd of ingeschakeld. Sommige resources die normaal gesproken in de hub worden geïmplementeerd, moeten in een klassiek hub- en spoke-model worden geplaatst in een of meer spokes die fungeren als gedeelde resourcenetwerken. Voorbeeld:

  • Azure Bastion:Azure Bastion ondersteunt Azure Virtual WAN, maar moet worden geïmplementeerd in een virtueel spoke-netwerk omdat de hub wordt beperkt en beheerd door Azure. Vanuit de Azure Bastion-spoke kunnen gebruikers resources in andere VNets bereiken, maar hiervoor is een IP-verbinding vereist die beschikbaar is met de Standard-SKU van Azure Bastion.
  • Aangepaste DNS-servers: DNS-serversoftware kan worden geïnstalleerd op elke virtuele machine en fungeren als DNS-server voor alle spokes in Azure Virtual WAN. De DNS-server moet worden geïnstalleerd in een spoke-VNet dat alle andere spokes rechtstreeks bedient, of via de DNS-proxyfunctie die wordt aangeboden door de Azure Firewall die is geïntegreerd in de Virtual WAN-hub.
  • Azure Privé-DNS Resolver: implementatie van een Azure Privé-DNS Resolver wordt ondersteund in een van de spoke-VNets die zijn verbonden met Virtual WAN-hubs. Azure Firewall die is geïntegreerd in de Virtual WAN-hub, kan deze resource als aangepaste DNS gebruiken wanneer u de functie DNS-proxy inschakelt.
  • Privé-eindpunten: dit resourcetype is compatibel met Virtual WAN, maar moet worden geïmplementeerd in een spoke-VNet. Dit biedt connectiviteit met elk ander virtueel netwerk of een andere vertakking die is verbonden met hetzelfde Virtual WAN, als de geïntegreerde Azure Firewall de stroom toestaat. Instructies voor het beveiligen van verkeer naar privé-eindpunten met behulp van de Azure Firewall die is geïntegreerd in een Virtual WAN-hub, vindt u in Beveiligd verkeer dat is bestemd voor privé-eindpunten in Azure Virtual WAN.
  • Azure Privé-DNS Zone (koppelingen): dit type resource bevindt zich niet binnen een virtueel netwerk, maar moet eraan worden gekoppeld om correct te kunnen functioneren. Privé-DNS Zones kunnen niet worden gekoppeld aan Virtual WAN-hubs. In plaats daarvan moeten ze zijn verbonden met het spoke-VNet met aangepaste DNS-servers of een Azure Privé-DNS Resolver (aanbevolen) of rechtstreeks naar de spoke-VNets waarvoor de DNS-records uit die zone zijn vereist.

Stap 5: Uw versleuteling controleren

Azure Virtual WAN biedt enkele mogelijkheden voor verkeersversleuteling via zijn eigen gateways voor verkeer dat het Microsoft-netwerk binnenkomt. Indien mogelijk moet versleuteling worden ingeschakeld op basis van het gatewaytype. Houd rekening met het volgende standaardversleutelingsgedrag:

  • Virtual WAN S2S VPN Gateway biedt versleuteling bij het gebruik van IPsec /IKE (IKEv1 en IKEv2) VPN-verbinding.

  • Virtual WAN P2S VPN Gateway biedt versleuteling bij het gebruik van gebruikers-VPN-verbinding via OpenVPN of IPsec/IKE (IKEv2).

  • De Virtual WAN ExpressRoute-gateway biedt geen versleuteling, daarom zijn dezelfde overwegingen van zelfstandige ExpressRoute van toepassing.

    • Alleen voor ExpressRoute-circuits die boven op ExpressRoute Direct zijn ingericht, is het mogelijk om macsec-versleuteling van het platform te gebruiken om de verbindingen tussen uw edge-routers en de edge-routers van Microsoft te beveiligen.

    • Versleuteling kan tot stand worden gebracht met behulp van een IPsec/IKE VPN-verbinding van uw on-premises netwerk naar Azure via de persoonlijke peering van een Azure ExpressRoute-circuit. Routeringsintentie en beleidsregels ondersteunen nu deze configuratie met extra configuratiestappen die vereist zijn, zoals wordt uitgelegd in Encrypted ExpressRoute.

  • Voor SD-WAN-apparaten (Software-Defined WAN) van derden en NVA's die zijn geïntegreerd in virtual WAN-hub, moeten specifieke versleutelingsmogelijkheden worden geverifieerd en geconfigureerd volgens de documentatie van de leverancier.

Zodra het verkeer de Azure-netwerkinfrastructuur via een van de gateways of een SD-WAN/NVA heeft ingevoerd, is er geen specifieke Virtual WAN-service of -mogelijkheid die netwerkversleuteling biedt. Als verkeer tussen een hub en het bijbehorende virtuele netwerk en hub-naar-hub niet-versleuteld is, moet u indien nodig versleuteling op toepassingsniveau gebruiken.

Notitie

Virtual WAN-spokes bieden geen ondersteuning voor VNet-naar-VNet-versleuteling met behulp van Azure VPN Gateway, omdat een spoke is vereist voor het gebruik van de externe gateway van de Virtual WAN-hub.

Stap 6: uw P2S-gebruikers beveiligen

Azure Virtual WAN is een netwerkservice die een groot aantal netwerk-, beveiligings- en routeringsfuncties samenbrengt om één operationele interface te bieden. Vanuit het perspectief van een gebruikersidentiteit bevindt het enige aanraakpunt met Virtual WAN zich in de verificatiemethode die wordt gebruikt om een gebruiker P2S VPN toe te staan. Er zijn verschillende verificatiemethoden beschikbaar, maar we raden u aan de algemene Zero Trust-principes van Microsoft Entra-verificatie te volgen. Met Microsoft Entra ID kunt u Multi-Factor Authentication (MFA) en voorwaardelijke toegang zero trust-principes toepassen op clientapparaten en gebruikersidentiteiten.

Notitie

Microsoft Entra-verificatie is alleen beschikbaar voor gateways die gebruikmaken van het OpenVPN-protocol. Dit wordt alleen ondersteund voor OpenVPN-protocolverbindingen en vereist de Azure VPN-client.

Azure Virtual WAN en Azure Firewall bieden geen verkeersroutering en -filtering op basis van gebruikersaccounts of groepsnamen, maar het is mogelijk om verschillende groepen gebruikers verschillende groepen IP-adressen toe te wijzen. Vervolgens kunt u regels definiëren voor de geïntegreerde Azure Firewall om gebruikers of groepen te beperken op basis van hun toegewezen P2S-IP-adresgroep.

Als u uw P2S-gebruikers onderverdeelt in verschillende groepen op basis van netwerktoegangsvereisten, raden we u aan deze te onderscheiden op netwerkniveau en ervoor te zorgen dat ze alleen toegang hebben tot een subset van het interne netwerk. U kunt meerdere IP-adresgroepen maken voor Azure Virtual WAN. Zie Gebruikersgroepen en IP-adresgroepen configureren voor P2S-gebruikers-VPN's voor meer informatie.

Stap 7: Bewaking, controle en beheer configureren

Azure Virtual WAN biedt uitgebreide bewakings- en diagnostische mogelijkheden met Azure Monitor. Aanvullende details en topologie kunnen worden verkregen met behulp van een gericht, vooraf samengesteld bewakingsdashboard in Azure Portal met de naam Azure Monitor Insights voor Virtual WAN. Deze bewakingshulpprogramma's zijn niet specifiek voor beveiliging. De Azure Firewall die in elke Virtual WAN-hub is geïmplementeerd, biedt het integratiepunt voor Zero Trust en beveiligingsbewaking. U moet diagnostische gegevens en logboekregistratie configureren voor Azure Firewall , net zoals Azure Firewalls buiten Virtual WAN.

Azure Firewall biedt de volgende bewakingshulpprogramma's die u moet gebruiken om beveiliging en juiste toepassing van Zero Trust-principes te garanderen:

Azure Firewall kan ook worden geïntegreerd met Microsoft Defender voor Cloud en Microsoft Sentinel. We raden u ten zeerste aan beide hulpprogramma's correct te configureren en deze actief te gebruiken voor Zero Trust op de volgende manieren:

  • Met Microsoft Defender voor Cloud integratie kunt u de all-upstatus van de netwerkinfrastructuur en netwerkbeveiliging op één plaats visualiseren, inclusief Azure-netwerkbeveiliging in alle VNets en virtuele hubs verspreid over verschillende regio's in Azure. In één oogopslag ziet u het aantal Azure Firewalls, firewallbeleid en Azure-regio's waarin Azure Firewalls worden geïmplementeerd.
  • Een Microsoft Sentinel-oplossing voor naadloze Integratie van Azure Firewall biedt detectie en preventie van bedreigingen. Zodra de oplossing is geïmplementeerd, is ingebouwde aanpasbare bedreigingsdetectie mogelijk boven op Microsoft Sentinel. De oplossing bevat ook een werkmap, detecties, opsporingsquery's en playbooks.

Training voor beheerders

De volgende trainingsmodules helpen uw team met de vaardigheden die nodig zijn om Zero Trust-principes toe te passen op uw Azure Virtual WAN-implementatie.

Inleiding tot Azure Virtual WAN

Training Inleiding tot Azure Virtual WAN
Beschrijf hoe u een WAN (Wide Area Network) maakt met behulp van software-gedefinieerde Azure Virtual WAN-netwerkservices.

Start >

Inleiding tot Azure Firewall

Training Inleiding tot Azure Firewall
Beschrijf hoe Azure Firewall Azure VNet-resources beveiligt, waaronder de Azure Firewall-functies, regels, implementatieopties en beheer met Azure Firewall Manager.

Start >

Inleiding tot Azure Firewall Manager

Training Inleiding tot Azure Firewall Manager
Beschrijf of u Azure Firewall Manager kunt gebruiken om centraal beveiligingsbeleid en routebeheer te bieden voor uw cloudbeveiligingsperimeter. Evalueer of Azure Firewall Manager u kan helpen uw cloudperimeter te beveiligen.

Start >

Netwerkbeveiliging ontwerpen en implementeren

Training Netwerkbeveiliging ontwerpen en implementeren
U leert hoe u netwerkbeveiligingsoplossingen zoals Azure DDoS, netwerkbeveiligingsgroepen, Azure Firewall en Web Application Firewall ontwerpt en implementeert.

Start >

Zie deze resources in de Microsoft-catalogus voor meer training over beveiliging in Azure:
Beveiliging in Azure

Volgende stappen

Zie deze aanvullende artikelen voor het toepassen van Zero Trust-principes op Azure:

Verwijzingen

Raadpleeg deze koppelingen voor meer informatie over de verschillende services en technologieën die in dit artikel worden genoemd.

Azure Virtual WAN

Beveiligingsbasislijnen

Goed ontworpen frameworkbeoordeling

Azure-beveiliging

Technische illustraties

U kunt de illustraties downloaden die in dit artikel worden gebruikt. Gebruik het Visio-bestand om deze illustraties te wijzigen voor uw eigen gebruik.

PDF | Visio

Klik hier voor aanvullende technische illustraties.