Aanbevelingen voor netwerken en connectiviteit

Artikel
11/15/2023

Is van toepassing op deze aanbeveling voor de controlelijst voor Azure Well-Architected Framework Security:

SE:06	Netwerkverkeer isoleren, filteren en beheren tussen zowel inkomend als uitgaand verkeer. Pas diepgaande verdedigingsprincipes toe met behulp van gelokaliseerde netwerkcontroles op alle beschikbare netwerkgrenzen tussen zowel oost-west- als noord-zuidverkeer.

In deze handleiding worden de aanbevelingen voor netwerkontwerp beschreven. De focus ligt op beveiligingscontroles die kwaadwillende personen kunnen filteren, blokkeren en detecteren die netwerkgrenzen overschrijden op verschillende diepten van uw architectuur.

U kunt uw identiteitscontroles versterken door maatregelen voor toegangsbeheer op basis van het netwerk te implementeren. Naast identiteitstoegangsbeheer is netwerkbeveiliging een hoge prioriteit voor het beveiligen van assets. De juiste besturingselementen voor netwerkbeveiliging kunnen een diepgaande verdediging bieden die kan helpen bij het detecteren en bevatten van bedreigingen, en om te voorkomen dat aanvallers toegang krijgen tot uw workload.

Definities

Term	Definitie
Oost-west verkeer	Netwerkverkeer dat binnen een vertrouwde grens wordt verplaatst.
Uitgaande stroom	Uitgaand workloadverkeer.
Vijandig netwerk	Een netwerk dat niet is geïmplementeerd als onderdeel van uw workload. Een vijandig netwerk wordt beschouwd als een bedreigingsvector.
Stroom voor inkomend verkeer	Inkomend workloadverkeer.
Netwerkfiltering	Een mechanisme waarmee netwerkverkeer wordt toegestaan of geblokkeerd op basis van opgegeven regels.
Netwerksegmentatie of isolatie	Een strategie waarmee een netwerk wordt verdeeld in kleine, geïsoleerde segmenten, met beveiligingscontroles die op de grenzen worden toegepast. Deze techniek helpt resources te beschermen tegen vijandige netwerken, zoals internet.
Netwerktransformatie	Een mechanisme waarmee netwerkpakketten worden gedempt om ze te verdoezelen.
Noord-zuid verkeer	Netwerkverkeer dat wordt verplaatst van een vertrouwde grens naar externe netwerken die potentieel vijandig zijn en vice versa.

Belangrijke ontwerpstrategieën

Netwerkbeveiliging maakt gebruik van obscurity om workloadassets te beschermen tegen vijandige netwerken. Resources die zich achter een netwerkgrens bevinden, worden verborgen totdat de grensbesturingselementen het verkeer markeren als veilig om vooruit te gaan. Het ontwerp voor netwerkbeveiliging is gebaseerd op drie belangrijke strategieën:

Segment. Met deze techniek wordt verkeer op afzonderlijke netwerken geïsoleerd door grenzen toe te voegen. Verkeer van en naar een toepassingslaag geeft bijvoorbeeld een grens door om te communiceren met andere lagen, die verschillende beveiligingsvereisten hebben. Lagen van segmentatie actualiseren de diepgaande verdedigingsbenadering.

De belangrijkste beveiligingsgrens is de netwerkrand tussen uw toepassing en openbare netwerken. Het is belangrijk om deze perimeter duidelijk te definiëren, zodat u een grens tot stand brengt voor het isoleren van vijandige netwerken. De besturingselementen op deze rand moeten zeer effectief zijn, omdat deze grens uw eerste verdedigingslinie is.

Virtuele netwerken bieden een logische grens. Een virtueel netwerk kan standaard niet communiceren met een ander virtueel netwerk, tenzij de grens opzettelijk is verbroken via peering. Uw architectuur moet profiteren van deze krachtige, door het platform geleverde beveiligingsmaatregel.

U kunt ook andere logische grenzen gebruiken, zoals uitgesneden subnetten binnen een virtueel netwerk. Een voordeel van subnetten is dat u ze kunt gebruiken om resources te groeperen die zich binnen een isolatiegrens bevinden en vergelijkbare beveiligingsgaranties hebben. Vervolgens kunt u besturingselementen op de grens configureren om verkeer te filteren.
Filteren. Deze strategie helpt ervoor te zorgen dat verkeer dat een grens binnenkomt, wordt verwacht, toegestaan en veilig is. Vanuit het perspectief van Zero Trust controleert filteren expliciet alle beschikbare gegevenspunten op netwerkniveau. U kunt regels op de grens plaatsen om te controleren op specifieke voorwaarden.

Op koptekstniveau kunnen de regels bijvoorbeeld controleren of het verkeer afkomstig is van een verwachte locatie of een verwacht volume heeft. Maar deze controles zijn niet voldoende. Zelfs als het verkeer verwachte kenmerken vertoont, is de nettolading mogelijk niet veilig. Bij validatiecontroles kan een SQL-injectieaanval worden weergegeven.
Transformeren. Mutate packets at the boundary as a security measure. U kunt bijvoorbeeld HTTP-headers verwijderen om het risico op blootstelling te elimineren. Of u kunt Transport Layer Security (TLS) op een bepaald moment uitschakelen en deze herstellen in een andere hop met een certificaat dat nauwkeuriger wordt beheerd.

De verkeersstromen classificeren

De eerste stap bij het classificeren van stromen is het bestuderen van een schematische architectuur van uw workloadarchitectuur. Bepaal vanuit het schema de intentie en kenmerken van de stroom met betrekking tot het functionele hulpprogramma en operationele aspecten van uw workload. Gebruik de volgende vragen om de stroom te classificeren:

Als de workload moet communiceren met externe netwerken, wat moet het vereiste nabijheidsniveau voor deze netwerken zijn?
Wat zijn de netwerkkenmerken van de stroom, zoals het verwachte protocol en de bron en vorm van de pakketten? Zijn er nalevingsvereisten op netwerkniveau?

Er zijn veel manieren om verkeersstromen te classificeren. In de volgende secties worden veelgebruikte criteria besproken.

Zichtbaarheid van externe netwerken

Openbaar. Een workload is openbaar als de toepassing en andere onderdelen bereikbaar zijn vanaf het openbare internet. De toepassing wordt weergegeven via een of meer openbare IP-adressen en openbare DNS-servers (Domain Name System).
Privé. Een workload is privé als deze alleen toegankelijk is via een particulier netwerk, zoals een virtueel particulier netwerk (VPN). Deze wordt alleen weergegeven via een of meer privé-IP-adressen en mogelijk via een privé-DNS-server.

In een particulier netwerk is er geen zicht vanaf het openbare internet naar de workload. Voor de gateway kunt u een load balancer of firewall gebruiken. Deze opties kunnen beveiligingsgaranties bieden.

Zelfs met openbare workloads wilt u zoveel mogelijk van de werkbelasting privé houden. Deze aanpak dwingt pakketten om door een privégrens te gaan wanneer ze afkomstig zijn van een openbaar netwerk. Een gateway in dat pad kan fungeren als een overgangspunt door te fungeren als een omgekeerde proxy.

Verkeersrichting

Inkomend verkeer. Inkomend verkeer is inkomend verkeer dat naar een workload of de bijbehorende onderdelen stroomt. Als u inkomend verkeer wilt beveiligen, past u de voorgaande set belangrijke strategieën toe. Bepaal wat de verkeersbron is en of deze wordt verwacht, toegestaan en veilig. Aanvallers die IP-adresbereiken van openbare cloudproviders scannen, kunnen uw verdediging binnendringen als u inkomend verkeer niet controleert of eenvoudige netwerkbeveiligingsmaatregelen implementeert.
Uitgaand verkeer. Uitgaand verkeer is uitgaand verkeer dat wegloopt van een workload of de bijbehorende onderdelen. Als u uitgaand verkeer wilt controleren, moet u bepalen waar het verkeer naartoe gaat en of de bestemming wordt verwacht, toegestaan en veilig is. De bestemming kan schadelijk zijn of zijn gekoppeld aan risico's voor gegevensexfiltratie.

U kunt ook uw blootstellingsniveau bepalen door rekening te houden met de nabijheid van uw workload bij het openbare internet. Het toepassingsplatform dient bijvoorbeeld doorgaans openbare IP-adressen. Het workloadonderdeel is het gezicht van de oplossing.

Invloedsbereik

Noord-zuid. Verkeer dat tussen een workloadnetwerk en externe netwerken stroomt, is noord-zuid-verkeer. Dit verkeer overschrijdt de rand van uw netwerk. Externe netwerken kunnen het openbare internet, een bedrijfsnetwerk of een ander netwerk zijn dat buiten uw beheerbereik valt.

Inkomend en uitgaand verkeer kan zowel noord-zuid verkeer zijn.

Denk bijvoorbeeld aan de uitgaande stroom van een hub-spoke-netwerktopologie. U kunt de netwerkrand van uw workload definiëren, zodat de hub een extern netwerk is. In dat geval is uitgaand verkeer van het virtuele netwerk van de spoke noord-zuidverkeer. Maar als u het hubnetwerk in uw beheersfeer beschouwt, wordt het noord-zuidverkeer uitgebreid naar de firewall in de hub, omdat de volgende hop het internet is, wat potentieel vijandig is.
Oost-west. Verkeer dat binnen een workloadnetwerk stroomt, is oost-west-verkeer. Dit type verkeer resulteert wanneer onderdelen in uw workload met elkaar communiceren. Een voorbeeld is verkeer tussen de lagen van een toepassing met een n-laag. In microservices is service-naar-service-communicatie oost-westverkeer.

Als u diepgaande verdediging wilt bieden, houdt u end-to-end controle over de beveiligingsmaatregelen die zijn opgenomen in elke hop of die u gebruikt wanneer pakketten interne segmenten kruisen. Voor verschillende risiconiveaus zijn verschillende risicoherstelmethoden vereist.

In het voorgaande diagram ziet u uitgebreide netwerkbeveiliging in de privécloud. In dit diagram is de grens tussen de openbare en privé-IP-adresruimten aanzienlijk verder van de workload dan in het openbare clouddiagram. Meerdere lagen scheiden de Azure-implementaties van de openbare IP-adresruimte.

Notitie

Identiteit is altijd de primaire perimeter. Toegangsbeheer moet worden toegepast op netwerkstromen. Gebruik beheerde identiteiten wanneer u op rollen gebaseerd toegangsbeheer (RBAC) van Azure gebruikt tussen onderdelen van uw netwerk.

Nadat u stromen hebt geclassificeerd, voert u een segmentatieoefening uit om firewallinjectiepunten op de communicatiepaden van uw netwerksegmenten te identificeren. Wanneer u uw netwerkbeveiliging uitgebreid ontwerpt voor alle segmenten en alle verkeerstypen, wordt ervan uitgegaan dat er op alle punten een inbreuk is opgetreden. Gebruik een combinatie van verschillende gelokaliseerde netwerkbesturingselementen voor alle beschikbare grenzen. Zie Segmentatiestrategieën voor meer informatie.

Firewalls aan de rand toepassen

Internetrandverkeer is noord-zuidverkeer en omvat inkomend en uitgaand verkeer. Als u bedreigingen wilt detecteren of blokkeren, moet een edge-strategie zoveel mogelijk aanvallen van en naar internet beperken.

Voor uitgaand verkeer verzendt u al het internetverkeer via één firewall die een verbeterd toezicht, governance en beheer van verkeer biedt. Voor inkomend verkeer dwingt u al het verkeer van internet af om via een virtueel netwerkapparaat (NVA) of een firewall voor webtoepassingen te gaan.

Firewalls zijn meestal singletons die per regio in een organisatie worden geïmplementeerd. Als gevolg hiervan worden ze gedeeld tussen workloads en eigendom van een centraal team. Zorg ervoor dat alle NVA's die u gebruikt, zijn geconfigureerd ter ondersteuning van de behoeften van uw workload.
U wordt aangeraden zo veel mogelijk systeemeigen besturingselementen van Azure te gebruiken.

Naast systeemeigen besturingselementen kunt u ook partner-NVA's overwegen die geavanceerde of gespecialiseerde functies bieden. Leverancierproducten van partnerfirewall en webtoepassingsfirewall zijn beschikbaar in Azure Marketplace.

De beslissing om systeemeigen functies te gebruiken in plaats van partneroplossingen, moet zijn gebaseerd op de ervaring en vereisten van uw organisatie.

Compromis: Partnermogelijkheden bieden vaak geavanceerde functies die kunnen beschermen tegen geavanceerde, maar meestal ongebruikelijke aanvallen. De configuratie van partneroplossingen kan complex en kwetsbaar zijn, omdat deze oplossingen niet worden geïntegreerd met de infrastructuurcontrollers van de cloud. Vanuit kostenperspectief heeft systeemeigen controle de voorkeur omdat het goedkoper is dan partneroplossingen.

Alle technologische opties die u overweegt, moeten beveiligingscontroles en bewaking bieden voor zowel inkomend als uitgaand verkeer. Zie de sectie Edge-beveiliging in dit artikel voor opties die beschikbaar zijn voor Azure.

Beveiliging van virtueel netwerk en subnet ontwerpen

Het primaire doel van een privécloud is om resources van het openbare internet te verdoezelen. Er zijn verschillende manieren om dit doel te bereiken:

Ga naar privé-IP-adresruimten, die u kunt bereiken met behulp van virtuele netwerken. Minimaliseer de netwerklijn van zicht, zelfs binnen uw eigen particuliere netwerken.
Minimaliseer het aantal openbare DNS-vermeldingen dat u gebruikt om minder werkbelasting beschikbaar te maken.
Inkomend en uitgaand netwerkstroombeheer toevoegen. Sta geen verkeer toe dat niet wordt vertrouwd.

Segmentatiestrategie

Als u de zichtbaarheid van het netwerk wilt minimaliseren, segmenteer u uw netwerk en begint u met netwerkbesturingselementen met minimale bevoegdheden. Als een segment niet routeerbaar is, kan het niet worden geopend. Breid het bereik uit zodat alleen segmenten worden opgenomen die met elkaar moeten communiceren via netwerktoegang.

U kunt virtuele netwerken segmenteren door subnetten te maken. De criteria voor de verdeling moeten opzettelijk zijn. Wanneer u services in een subnet samenvoegt, moet u ervoor zorgen dat deze services elkaar kunnen zien.

U kunt uw segmentatie baseren op veel factoren. U kunt bijvoorbeeld verschillende toepassingslagen in toegewezen segmenten plaatsen. Een andere benadering is het plannen van uw subnetten op basis van algemene rollen en functies die gebruikmaken van bekende protocollen.

Zie Segmentatiestrategieën voor meer informatie.

Subnetfirewalls

Het is belangrijk dat u het binnenkomende en uitgaande verkeer van elk subnet inspecteert. Gebruik de drie belangrijkste strategieën die eerder in dit artikel zijn besproken, in belangrijke ontwerpstrategieën. Controleer of de stroom wordt verwacht, toegestaan en veilig is. Als u deze informatie wilt controleren, definieert u firewallregels die zijn gebaseerd op het protocol, de bron en het doel van het verkeer.

In Azure stelt u firewallregels in netwerkbeveiligingsgroepen in. Zie de sectie Netwerkbeveiligingsgroepen in dit artikel voor meer informatie.

Zie Azure Virtual Network-subnetten voor een voorbeeld van een subnetontwerp.

Besturingselementen op onderdeelniveau gebruiken

Nadat u de zichtbaarheid van uw netwerk hebt geminimaliseerd, wijst u uw Azure-resources toe vanuit het perspectief van het netwerk en evalueert u de stromen. De volgende typen stromen zijn mogelijk:

Gepland verkeer of opzettelijke communicatie tussen services volgens uw architectuurontwerp. U hebt bijvoorbeeld verkeer gepland wanneer uw architectuur aanbeveelt dat Azure Functions berichten ophaalt uit Azure Service Bus.
Beheerverkeer of communicatie die plaatsvindt als onderdeel van de functionaliteit van de service. Dit verkeer maakt geen deel uit van uw ontwerp en u hebt er geen controle over. Een voorbeeld van beheerd verkeer is de communicatie tussen de Azure-services in uw architectuur en het Azure-beheervlak.

Door onderscheid te maken tussen gepland en beheerverkeer, kunt u gelokaliseerde of serviceniveaucontroles bouwen. Zorg voor een goed begrip van de bron en bestemming bij elke hop. Vooral begrijpen hoe uw gegevensvlak wordt weergegeven.

Bepaal als uitgangspunt of elke service beschikbaar is voor internet. Als dat zo is, kunt u plannen hoe u de toegang kunt beperken. Als dit niet het is, plaatst u het in een virtueel netwerk.

Servicefirewalls

Als u verwacht dat een service beschikbaar is voor internet, profiteert u van de firewall op serviceniveau die beschikbaar is voor de meeste Azure-resources. Wanneer u deze firewall gebruikt, kunt u regels instellen op basis van toegangspatronen. Zie de sectie Azure-servicefirewalls in dit artikel voor meer informatie.

Notitie

Als uw onderdeel geen service is, gebruikt u een firewall op basis van een host naast firewalls op netwerkniveau. Een virtuele machine (VM) is een voorbeeld van een onderdeel dat geen service is.

Connectiviteit met PaaS-services (Platform as a Service)

Overweeg het gebruik van privé-eindpunten om de toegang tot PaaS-services te beveiligen. Aan een privé-eindpunt wordt een privé-IP-adres toegewezen vanuit uw virtuele netwerk. Met het eindpunt kunnen andere resources in het netwerk communiceren met de PaaS-service via het privé-IP-adres.

Communicatie met een PaaS-service wordt bereikt met behulp van het openbare IP-adres en de DNS-record van de service. Die communicatie vindt plaats via internet. U kunt die communicatie privé maken.

Een tunnel van de PaaS-service naar een van uw subnetten maakt een privékanaal. Alle communicatie vindt plaats van het privé-IP-adres van het onderdeel naar een privé-eindpunt in dat subnet, dat vervolgens communiceert met de PaaS-service.

In dit voorbeeld toont de afbeelding aan de linkerkant de stroom voor openbaar weergegeven eindpunten. Aan de rechterkant wordt die stroom beveiligd met behulp van privé-eindpunten.

Zie de sectie Privé-eindpunten in dit artikel voor meer informatie.

Notitie

U wordt aangeraden privé-eindpunten te gebruiken in combinatie met servicefirewalls. Een servicefirewall blokkeert binnenkomend internetverkeer en stelt de service vervolgens privé beschikbaar voor interne gebruikers die het privé-eindpunt gebruiken.

Een ander voordeel van het gebruik van privé-eindpunten is dat u de poorten op de firewall niet hoeft te openen voor uitgaand verkeer. Privé-eindpunten vergrendelen al het uitgaande verkeer op de poort voor het openbare internet. Connectiviteit is beperkt tot resources binnen het netwerk.

Compromis: Azure Private Link is een betaalde service met meters voor binnenkomende en uitgaande gegevens die worden verwerkt. Er worden ook kosten in rekening gebracht voor privé-eindpunten.

Bescherming tegen DDoS-aanvallen (Distributed Denial of Service)

Een DDoS-aanval probeert de resources van een toepassing uit te putten om de toepassing niet beschikbaar te maken voor legitieme gebruikers. DDoS-aanvallen kunnen zich richten op elk eindpunt dat openbaar bereikbaar is via internet.

Een DDoS-aanval is meestal een enorme, wijdverspreide, geografisch verspreide misbruik van de resources van uw systeem waardoor het moeilijk is om de bron vast te stellen en te blokkeren.

Zie de sectie Azure DDoS Protection in dit artikel voor ondersteuning voor Azure om u te beschermen tegen deze aanvallen.

Azure-facilitering

U kunt de volgende Azure-services gebruiken om diepgaande verdedigingsmogelijkheden aan uw netwerk toe te voegen.

Azure Virtual Network

Virtual Network helpt uw Azure-resources veilig met elkaar, internet en on-premises netwerken te communiceren.

Standaard kunnen alle resources in een virtueel netwerk uitgaande communicatie met internet aangaan. Maar inkomende communicatie is standaard beperkt.

Virtual Network biedt functies voor het filteren van verkeer. U kunt de toegang beperken op virtueel netwerkniveau met behulp van een door de gebruiker gedefinieerde route (UDR) en een firewallonderdeel. Op subnetniveau kunt u verkeer filteren met behulp van netwerkbeveiligingsgroepen.

Edge-beveiliging

Standaard stromen zowel inkomend als uitgaand verkeer via openbare IP-adressen. Afhankelijk van de service of topologie stelt u deze adressen in of wijst Azure deze adressen toe. Andere mogelijkheden voor inkomend en uitgaand verkeer zijn onder andere het doorgeven van verkeer via een load balancer of NAT-gateway (Network Address Translation). Maar deze services zijn bedoeld voor de distributie van verkeer en niet noodzakelijkerwijs voor beveiliging.

De volgende technologiekeuzen worden aanbevolen:

Azure Firewall. U kunt Azure Firewall gebruiken aan de netwerkrand en in populaire netwerktopologieën, zoals hub-spoke-netwerken en virtuele WAN's. Doorgaans implementeert u Azure Firewall als een uitgaande firewall die fungeert als de laatste beveiligingspoort voordat verkeer naar internet gaat. Azure Firewall kan verkeer routeren dat gebruikmaakt van niet-HTTP- en niet-HTTPS-protocollen, zoals Remote Desktop Protocol (RDP), Secure Shell Protocol (SSH) en File Transfer Protocol (FTP). De functieset van Azure Firewall omvat:
- Doelnetwerkadresomzetting (DNAT) of port forwarding.
- Detectie van inbraakdetectie en -preventie (IDPS) handtekeningdetectie.
- Sterke netwerkregels voor laag 3, laag 4 en FQDN (Fully Qualified Domain Name).
Notitie

De meeste organisaties hebben een beleid voor geforceerde tunnels dat verkeer dwingt om door een NVA te stromen.

Als u geen virtuele WAN-topologie gebruikt, moet u een UDR implementeren met een van de NextHopType privé-IP-adressen van Internet uw NVA. UDR's worden toegepast op subnetniveau. Standaard stroomt subnet-naar-subnet-verkeer niet via de NVA.

U kunt Azure Firewall ook tegelijkertijd gebruiken voor inkomend verkeer. Het kan HTTP- en HTTPS-verkeer routeren. In hoger gelaagde SKU's biedt Azure Firewall TLS-beëindiging, zodat u inspecties op nettoladingsniveau kunt implementeren.

De volgende procedures worden aanbevolen:
- Schakel diagnostische instellingen in Azure Firewall in om verkeersstroomlogboeken, IDPS-logboeken en DNS-aanvraaglogboeken te verzamelen.
- Wees zo specifiek mogelijk in regels.
- Vermijd waar het praktisch is FQDN-servicetags. Maar wanneer u ze gebruikt, gebruikt u de regionale variant, waarmee communicatie met alle eindpunten van de service mogelijk is.
- Gebruik IP-groepen om bronnen te definiëren die dezelfde regels moeten delen gedurende de levensduur van de IP-groep. IP-groepen moeten uw segmentatiestrategie weerspiegelen.
- Overschrijf de infrastructuur-FQDN-regel alleen als voor uw workload absolute uitgaande toegangsbeheer is vereist. Het overschrijven van deze regel wordt geleverd met een betrouwbaarheidswijziging, omdat de vereisten van het Azure-platform voor services veranderen.
Afweging: Azure Firewall kan van invloed zijn op uw prestaties. Regelvolgorde, hoeveelheid, TLS-inspectie en andere factoren kunnen aanzienlijke latentie veroorzaken.

Er kan ook een invloed zijn op de betrouwbaarheid van uw workload. Het kan te maken hebben met SNAT-poortuitputting (Source Network Address Translation). U kunt dit probleem oplossen door zo nodig openbare IP-adressen toe te voegen.

Risico: Voor uitgaand verkeer wijst Azure een openbaar IP-adres toe. Deze toewijzing kan een downstream-impact hebben op uw externe beveiligingspoort.
Azure Web Application Firewall. Deze service ondersteunt binnenkomend filteren en is alleen gericht op HTTP- en HTTPS-verkeer.

Het biedt basisbeveiliging voor veelvoorkomende aanvallen, zoals bedreigingen die het Open Worldwide Application Security Project (OWASP) identificeert in het document OWASP Top 10. Azure Web Application Firewall biedt ook andere beveiligingsfuncties die zijn gericht op laag 7, zoals snelheidsbeperking, SQL-injectieregels en cross-site scripting.

Met Azure Web Application Firewall is TLS-beëindiging vereist, omdat de meeste controles zijn gebaseerd op nettoladingen.

U kunt Azure Web Application Firewall integreren met routers, zoals Azure-toepassing Gateway of Azure Front Door. Azure Web Application Firewall-implementaties voor dit soort routers kunnen variëren.

Azure Firewall en Azure Web Application Firewall sluiten elkaar niet wederzijds uit. Voor uw edge-beveiligingsoplossing zijn er verschillende opties beschikbaar. Zie Firewall en Application Gateway voor virtuele netwerken voor voorbeelden.

Netwerkbeveiligingsgroepen

Een netwerkbeveiligingsgroep is een laag 3- en laag 4-firewall die u toepast op het niveau van het subnet of de netwerkinterfacekaart (NIC). Netwerkbeveiligingsgroepen worden niet standaard gemaakt of toegepast.

Regels voor netwerkbeveiligingsgroepen fungeren als een firewall om verkeer te stoppen dat binnen en uit stroomt op de perimeter van een subnet. Een netwerkbeveiligingsgroep heeft een standaardregelset die te veel machtigingen heeft. De standaardregels stellen bijvoorbeeld geen firewall in vanuit het perspectief van uitgaand verkeer. Voor inkomend verkeer is geen inkomend internetverkeer toegestaan.

Als u regels wilt maken, begint u met de standaardregelset:

Voor inkomend verkeer of inkomend verkeer:
- Virtueel netwerkverkeer van directe, gekoppelde en VPN-gatewaybronnen is toegestaan.
- Statustests van Azure Load Balancer zijn toegestaan.
- Al het andere verkeer wordt geblokkeerd.
Voor uitgaand verkeer of uitgaand verkeer:
- Virtueel netwerkverkeer voor directe, gekoppelde en VPN-gatewaybestemmingen is toegestaan.
- Verkeer naar internet is toegestaan.
- Al het andere verkeer wordt geblokkeerd.

Houd vervolgens rekening met de volgende vijf factoren:

Protocol
IP-adres van bron
Bronpoort
IP-adres van doel
Doelpoort

Het ontbreken van ondersteuning voor FQDN beperkt de functionaliteit van netwerkbeveiligingsgroepen. U moet specifieke IP-adresbereiken opgeven voor uw workload en ze zijn moeilijk te onderhouden.

Maar voor Azure-services kunt u servicetags gebruiken om ip-adresbereiken van bron en doel samen te vatten. Een beveiligingsvoordeel van servicetags is dat ze ondoorzichtig zijn voor de gebruiker en dat de verantwoordelijkheid wordt overgeslagen naar Azure. U kunt ook een toepassingsbeveiligingsgroep toewijzen als doeltype om verkeer naar te routeren. Dit type benoemde groep bevat resources met vergelijkbare binnenkomende of uitgaande toegangsbehoeften.

Risico: servicetagbereiken zijn zeer breed, zodat ze geschikt zijn voor het breedst mogelijke bereik van klanten. Updates voor servicetags blijven achter bij wijzigingen in de service.

In de voorgaande afbeelding worden netwerkbeveiligingsgroepen toegepast op de NIC. Internetverkeer en subnet-naar-subnetverkeer worden geweigerd. De netwerkbeveiligingsgroepen worden met de VirtualNetwork tag toegepast. In dit geval hebben de subnetten van gekoppelde netwerken dus een directe lijn van zicht. De brede definitie van de VirtualNetwork tag kan een aanzienlijke beveiligingsimpact hebben.

Wanneer u servicetags gebruikt, gebruikt u indien mogelijk regionale versies, zoals Storage.WestUS in plaats van Storage. Door deze benadering te volgen, beperkt u het bereik tot alle eindpunten in een bepaalde regio.

Sommige tags zijn uitsluitend bedoeld voor binnenkomend of uitgaand verkeer. Andere zijn voor beide typen. Inkomende tags staan meestal verkeer van alle hostingworkloads toe, zoals AzureFrontDoor.Backend, of van Azure ter ondersteuning van serviceruntimes, zoals LogicAppsManagement. Op dezelfde manier staan uitgaande tags verkeer toe naar alle hostingworkloads of van Azure ter ondersteuning van serviceruntimes.

Beperk de regels zoveel mogelijk. In het volgende voorbeeld wordt de regel ingesteld op specifieke waarden. Elk ander type verkeer wordt geweigerd.

Gegevens	Opmerking
Protocol	Transmission Control Protocol (TCP), UDP
IP-adres van bron	Inkomend verkeer naar het subnet toestaan vanuit <bron-IP-adresbereik>: 4575/UDP
Bronpoort	Inkomend verkeer naar het subnet toestaan vanuit <servicetag>: 443/TCP
IP-adres van doel	Uitgaand verkeer van het subnet naar <doel-IP-adresbereik> toestaan: 443/TCP
Doelpoort	Uitgaand verkeer van het subnet naar <servicetag> toestaan: 443/TCP

Samenvatting:

Wees precies wanneer u regels maakt. Sta alleen verkeer toe dat nodig is om uw toepassing te laten functioneren. Alles weigeren. Deze aanpak beperkt de netwerklijn van zicht tot netwerkstromen die nodig zijn om de werking van de workload te ondersteunen. Het ondersteunen van meer netwerkstromen dan nodig is, leidt tot onnodige aanvalsvectoren en breidt het oppervlak uit.

Het beperken van verkeer impliceert niet dat toegestane stromen buiten het bereik van een aanval vallen. Omdat netwerkbeveiligingsgroepen werken op laag 3 en 4 op de OSI-stack (Open Systems Interconnect), bevatten ze alleen vorm- en richtingsgegevens. Als uw werkbelasting bijvoorbeeld DNS-verkeer naar internet moet toestaan, gebruikt u een netwerkbeveiligingsgroep van Internet:53:UDP. In dit geval kan een aanvaller gegevens mogelijk exfiltreren via UDP op poort 53 naar een andere service.
Begrijp dat netwerkbeveiligingsgroepen enigszins van elkaar kunnen verschillen. Het is gemakkelijk om de intentie van de verschillen over het hoofd te zien. Als u gedetailleerde filters wilt hebben, is het veiliger om extra netwerkbeveiligingsgroepen te maken. Stel ten minste één netwerkbeveiligingsgroep in.
- Door een netwerkbeveiligingsgroep toe te voegen, worden veel diagnostische hulpprogramma's ontgrendeld, zoals stroomlogboeken en analyse van netwerkverkeer.
- Gebruik Azure Policy om verkeer te beheren in subnetten die geen netwerkbeveiligingsgroepen hebben.
Als een subnet netwerkbeveiligingsgroepen ondersteunt, voegt u een groep toe, zelfs als dit minimaal van invloed is.

Azure-servicefirewalls

De meeste Azure-services bieden een firewall op serviceniveau. Met deze functie wordt inkomend verkeer naar de service geïnspecteerd van opgegeven CIDR-bereiken (Classless Inter-Domain Routing). Deze firewalls bieden voordelen:

Ze bieden een basisniveau van beveiliging.
Er is sprake van een acceptabele invloed op de prestaties.
De meeste services bieden deze firewalls zonder extra kosten.
De firewalls verzenden logboeken via Diagnostische gegevens van Azure, wat handig kan zijn voor het analyseren van toegangspatronen.

Er zijn echter ook beveiligingsproblemen met betrekking tot deze firewalls en er zijn beperkingen die zijn gekoppeld aan het opgeven van parameters. Als u bijvoorbeeld door Microsoft gehoste buildagents gebruikt, moet u het IP-adresbereik openen voor alle door Microsoft gehoste buildagents. Het bereik is vervolgens geopend voor uw buildagent, andere tenants en kwaadwillende personen die mogelijk misbruik maken van uw service.

Als u toegangspatronen voor de service hebt, die kunnen worden geconfigureerd als sets met firewallregels voor services, moet u de service inschakelen. U kunt Azure Policy gebruiken om dit in te schakelen. Zorg ervoor dat u de optie vertrouwde Azure-services niet inschakelt als deze niet standaard is ingeschakeld. Hierdoor worden alle afhankelijke services binnen het bereik van de regels gebracht.

Zie de productdocumentatie van afzonderlijke Azure-services voor meer informatie.

Privé-eindpunten

Private Link biedt een manier om een PaaS-exemplaar een privé-IP-adres te geven. De service is vervolgens onbereikbaar via internet. Privé-eindpunten worden niet ondersteund voor alle SKU's.

Houd rekening met de volgende aanbevelingen wanneer u privé-eindpunten gebruikt:

Configureer services die zijn gebonden aan virtuele netwerken om contact op te maken met PaaS-services via privé-eindpunten, zelfs als deze PaaS-services ook openbare toegang moeten bieden.
Promoot het gebruik van netwerkbeveiligingsgroepen voor privé-eindpunten om de toegang tot IP-adressen van privé-eindpunten te beperken.
Gebruik altijd servicefirewalls wanneer u privé-eindpunten gebruikt.
Als u, indien mogelijk, een service hebt die alleen toegankelijk is via privé-eindpunten, verwijdert u de DNS-configuratie voor het openbare eindpunt.
Houd rekening met runtime-problemen bij het implementeren van privé-eindpunten. Maar houd ook rekening met DevOps en controleproblemen.
Gebruik Azure Policy om resourceconfiguratie af te dwingen.

Compromis: Service-SKU's met privé-eindpunten zijn duur. Privé-eindpunten kunnen bewerkingen bemoeilijken vanwege netwerkvertrouwbaarheid. U moet zelf-hostende agents, jumpboxen, een VPN en andere onderdelen toevoegen aan uw architectuur.

DNS-beheer kan complex zijn in algemene netwerktopologieën. Mogelijk moet u DNS-doorstuurservers en andere onderdelen introduceren.

Virtuele netwerkinjectie

U kunt het injectieproces van het virtuele netwerk gebruiken om sommige Azure-services in uw netwerk te implementeren. Voorbeelden van dergelijke services zijn Azure-app Service, Functions, Azure API Management en Azure Spring Apps. Met dit proces wordt de toepassing geïsoleerd van internet, systemen in privénetwerken en andere Azure-services. Binnenkomend en uitgaand verkeer van de toepassing wordt toegestaan of geweigerd op basis van netwerkregels.

Azure Bastion

U kunt Azure Bastion gebruiken om verbinding te maken met een virtuele machine met behulp van uw browser en Azure Portal. Azure Bastion verbetert de beveiliging van RDP- en SSH-verbindingen. Een typische use case omvat het maken van verbinding met een jumpbox in hetzelfde virtuele netwerk of een gekoppeld virtueel netwerk. Als u Azure Bastion gebruikt, hoeft de VIRTUELE machine geen openbaar IP-adres te hebben.

Azure DDoS-beveiliging

Elke eigenschap in Azure wordt zonder extra kosten beveiligd door Azure DDoS-infrastructuurbeveiliging en zonder toegevoegde configuratie. Het beveiligingsniveau is eenvoudig, maar de beveiliging heeft hoge drempelwaarden. Het biedt ook geen telemetrie of waarschuwingen en is workloadneutraal.

SKU's met hogere lagen van DDoS Protection zijn beschikbaar, maar zijn niet gratis. De schaal en capaciteit van het wereldwijd geïmplementeerde Azure-netwerk biedt bescherming tegen veelvoorkomende netwerklaagaanvallen. Technologieën zoals always-on verkeersbewaking en realtime risicobeperking bieden deze mogelijkheid.

Zie het Overzicht van Azure DDoS Protection voor meer informatie.

Opmerking

Hier volgen enkele voorbeelden die het gebruik van netwerkbesturingselementen laten zien die in dit artikel worden aanbevolen.

IT-omgeving

Dit voorbeeld is gebaseerd op de IT-omgeving (Information Technology) die is ingesteld in de beveiligingsbasislijn (SE:01). Deze benadering biedt een breed begrip van netwerkcontroles die worden toegepast op verschillende perimeters om verkeer te beperken.

Persona's voor netwerkaanvallen. Verschillende persona's kunnen worden overwogen bij een netwerkaanval, waaronder beheerders, werknemers, klanten van klanten en anonieme aanvallers.
VPN-toegang. Een slechte actor heeft mogelijk toegang tot de on-premises omgeving via een VPN of een Azure-omgeving die is verbonden met de on-premises omgeving via een VPN. Configureer met IPSec-protocol om beveiligde communicatie in te schakelen.
Openbare toegang tot de toepassing. Zorg voor de toepassing voor een Web Application Firewall (WAF) om deze te beveiligen op laag 7 van de netwerk-OSI-laag.
Operatortoegang. Externe toegang via laag 4 van netwerk-OSI-lagen moet worden beveiligd. Overweeg het gebruik van Azure Firewall met IDP/IDS-functies.
DDoS-beveiliging. DDoS-beveiliging voor uw hele VNet hebben.
Netwerktopologie. Een netwerktopologie zoals hub-spoke, is veiliger en optimaliseert de kosten. Het hubnetwerk biedt gecentraliseerde firewallbeveiliging voor alle peered spokes.
Privé-eindpunten: Overweeg om openbaar weergegeven services toe te voegen aan uw privénetwerk met behulp van privé-eindpunten. Hiermee maakt u een netwerkkaart (NIC) in uw privé-VNet en verbindt u met de Azure-service.
TLS-communicatie. Gegevens tijdens overdracht beveiligen door te communiceren via TLS.
Netwerkbeveiligingsgroep (NSG): Beveilig segmenten binnen een VNet met NSG, een gratis resource die binnenkomende en uitgaande TCP/UDP-communicatie filtert, rekening houdend met IP- en poortbereiken. Een onderdeel van NSG is de Toepassingsbeveiligingsgroep (ASG) waarmee u tags voor verkeersregels kunt maken voor eenvoudiger beheer.
Log Analytics. Azure-resources verzenden telemetrie die wordt opgenomen in Log Analytics en vervolgens worden gebruikt met een SIEM-oplossing zoals Microsoft Sentinel voor analyse.
Microsoft Sentinel-integratie. Log Analytics is geïntegreerd met Microsoft Sentinel en andere oplossingen, zoals Microsoft Defender voor Cloud.
Microsoft Defender voor Cloud. Microsoft Defender voor Cloud biedt veel oplossingen voor workloadbeveiliging, waaronder netwerkaan aanbevelingen voor uw omgeving.
Traffic Analytics: Bewaak uw netwerkbesturingselementen met Traffic Analytics. Dit is geconfigureerd via Network Watcher, onderdeel van Azure Monitor, en voegt binnenkomende en uitgaande treffers samen in uw subnetten die zijn verzameld door NSG.

Architectuur voor een containerworkload

In deze voorbeeldarchitectuur worden de netwerkbesturingselementen gecombineerd die in dit artikel worden beschreven. In het voorbeeld wordt de volledige architectuur niet weergegeven. In plaats daarvan is het gericht op toegangsbeheer voor inkomend verkeer in de privécloud.

Application Gateway is een load balancer voor webverkeer die u kunt gebruiken om verkeer naar uw webtoepassingen te beheren. U implementeert Application Gateway in een toegewezen subnet met besturingselementen voor netwerkbeveiligingsgroepen en web application firewall-besturingselementen.

Communicatie met alle PaaS-services wordt uitgevoerd via privé-eindpunten. Alle eindpunten worden in een toegewezen subnet geplaatst. DDoS Protection helpt bij het beveiligen van alle openbare IP-adressen die zijn geconfigureerd voor een basis- of hoger niveau van firewallbeveiliging.

Beheerverkeer wordt beperkt via Azure Bastion, waarmee u beveiligde en naadloze RDP- en SSH-connectiviteit met uw VM's rechtstreeks vanuit Azure Portal via TLS kunt bieden. Buildagents worden in het virtuele netwerk geplaatst, zodat ze een netwerkweergave hebben voor werkbelastingresources, zoals rekenresources, containerregisters en databases. Deze aanpak helpt een veilige en geïsoleerde omgeving te bieden voor uw buildagents, waardoor de beveiliging voor uw code en artefacten wordt verbeterd.

Netwerkbeveiligingsgroepen op subnetniveau van de rekenresources beperken uitgaand verkeer. Geforceerde tunneling wordt gebruikt om al het verkeer via Azure Firewall te routeren. Deze aanpak helpt een veilige en geïsoleerde omgeving te bieden voor uw rekenresources, waardoor de beveiliging voor uw gegevens en toepassingen wordt verbeterd.

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging

Delen via

Aanbevelingen voor netwerken en connectiviteit