Aanbevelingen voor netwerken en connectiviteit

Artikel
11/15/2023

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

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

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

U kunt uw identiteitscontroles versterken door op het netwerk gebaseerde toegangsbeheermaatregelen te implementeren. Naast op identiteit gebaseerd toegangsbeheer heeft netwerkbeveiliging een hoge prioriteit voor het beveiligen van assets. De juiste besturingselementen voor netwerkbeveiliging kunnen een diepgaand verdedigingselement bieden dat kan helpen bij het detecteren en onder controle houden van bedreigingen, en om te voorkomen dat aanvallers toegang krijgen tot uw workload.

Definities

Termijn	Definitie
Oost-west-verkeer	Netwerkverkeer dat zich binnen een vertrouwde grens bevindt.
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	Binnenkomend workloadverkeer.
Netwerk filteren	Een mechanisme waarmee netwerkverkeer wordt toegestaan of geblokkeerd op basis van opgegeven regels.
Netwerksegmentatie of -isolatie	Een strategie die een netwerk opsplitst in kleine, geïsoleerde segmenten, met beveiligingscontroles die aan de grenzen worden toegepast. Deze techniek helpt resources te beschermen tegen vijandige netwerken, zoals internet.
Netwerktransformatie	Een mechanisme dat netwerkpakketten muteert om ze te verdoezelen.
Noord-zuidverkeer	Netwerkverkeer dat zich verplaatst van een vertrouwde grens naar externe netwerken die mogelijk vijandig zijn en vice versa.

Belangrijke ontwerpstrategieën

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

Segment. Deze techniek isoleert verkeer op afzonderlijke netwerken door grenzen toe te voegen. Verkeer van en naar een toepassingslaag passeert bijvoorbeeld een grens 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 instelt voor het isoleren van vijandige netwerken. De besturingselementen aan deze rand moeten zeer effectief zijn, omdat deze grens uw eerste verdedigingslinie is.

Virtuele netwerken bieden een logische grens. Standaard kan een virtueel netwerk 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 deze 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.
Filter. Deze strategie helpt ervoor te zorgen dat verkeer dat een grens binnenkomt, wordt verwacht, toegestaan en veilig is. Vanuit een Zero-Trust perspectief worden met filteren expliciet alle beschikbare gegevenspunten op netwerkniveau gecontroleerd. U kunt regels op de grens plaatsen om te controleren op specifieke voorwaarden.

Op headerniveau 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. Validatiecontroles kunnen een SQL-injectieaanval aan het licht brengen.
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 het ene moment uitschakelen en het opnieuw tot stand laten komen op een andere hop met een certificaat dat strikter wordt beheerd.

De verkeersstromen classificeren

De eerste stap bij het classificeren van stromen is het bestuderen van een schema van uw workloadarchitectuur. Bepaal vanuit het schema de intentie en kenmerken van de stroom met betrekking tot de functionele bruikbaarheid 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 dan het vereiste niveau van nabijheid tot die 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 via 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 kan worden geopend via een particulier netwerk, zoals een virtueel particulier netwerk (VPN). Het wordt alleen weergegeven via een of meer privé-IP-adressen en mogelijk via een privé-DNS-server.

In een particulier netwerk is er geen zichtlijn van 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 moet u ernaar streven om zoveel mogelijk van de workload privé te houden. Deze benadering dwingt pakketten af om een privégrens te passeren 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.

Richting van het verkeer

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

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

Bereik van invloed

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

Inkomend en uitgaand verkeer kan zowel noord-zuidverkeer zijn.

Neem bijvoorbeeld 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 rekening houdt met het hubnetwerk binnen uw controlesfeer, wordt noord-zuidverkeer uitgebreid naar de firewall in de hub, omdat de volgende hop het internet is, dat mogelijk 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-west-verkeer.

Als u diepgaande verdediging wilt bieden, moet u end-to-end controle houden over beveiligingsmechanismen 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 ligt de rand tussen de openbare en privé-IP-adresruimten aanzienlijk verder van de workload dan in het diagram van de openbare cloud. 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 te identificeren op de communicatiepaden van uw netwerksegmenten. Wanneer u uw netwerkbeveiliging diepgaand ontwerpt voor alle segmenten en alle verkeerstypen, gaat u ervan uit dat er op alle punten sprake is van een inbreuk. Gebruik een combinatie van verschillende gelokaliseerde netwerkbesturingselementen op 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 uitgebreide controle, governance en controle van verkeer biedt. Voor inkomend verkeer dwingt u af dat al het verkeer van internet via een virtueel netwerkapparaat (NVA) of een webtoepassingsfirewall gaat.

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 om de behoeften van uw workload te ondersteunen.
U wordt aangeraden zoveel 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 partnerfirewalls en webtoepassingsfirewalls zijn beschikbaar in Azure Marketplace.

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

Compromis: partnermogelijkheden bieden vaak geavanceerde functies die bescherming bieden tegen geavanceerde, maar meestal ongebruikelijke aanvallen. De configuratie van partneroplossingen kan complex en kwetsbaar zijn, omdat deze oplossingen niet kunnen worden geïntegreerd met de infrastructuurcontrollers van de cloud. Vanuit het oogpunt van kosten 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 meer informatie over de beschikbare opties voor Azure.

Beveiliging van virtueel netwerk en subnet ontwerpen

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

Verplaatsen naar privé-IP-adresruimten, wat u kunt bereiken met behulp van virtuele netwerken. Beperk de zichtlijn van het netwerk, zelfs binnen uw eigen particuliere netwerken.
Minimaliseer het aantal openbare DNS-vermeldingen dat u gebruikt om minder van uw workload beschikbaar te maken.
Netwerkstroombeheer voor inkomend verkeer en uitgaand verkeer toevoegen. Verkeer dat niet wordt vertrouwd, is niet toegestaan.

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. Verbreed het bereik met alleen segmenten die met elkaar moeten communiceren via netwerktoegang.

U kunt virtuele netwerken segmenteren door subnetten te maken. De criteria voor deling moeten opzettelijk zijn. Wanneer u services in een subnet op dezelfde plaats opsnaalt, 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 om het binnenkomende en uitgaande verkeer van elk subnet te controleren. Gebruik de drie belangrijkste strategieën die eerder in dit artikel zijn besproken, in Belangrijke ontwerpstrategieën. Controleer of de stroom verwacht, toegestaan en veilig is. Als u deze informatie wilt controleren, definieert u firewallregels die zijn gebaseerd op het protocol, de bron en de bestemming 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 besturingselementen of besturingselementen op serviceniveau bouwen. Een goed begrip hebben van de bron en het doel bij elke hop. Vooral begrijpen hoe uw gegevensvlak wordt weergegeven.

Als uitgangspunt moet u bepalen of elke service beschikbaar is op internet. Als dat zo is, kunt u plannen hoe u de toegang wilt beperken. Als dat niet zo is, plaatst u deze in een virtueel netwerk.

Servicefirewalls

Als u verwacht dat een service wordt blootgesteld aan 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 naast firewalls op netwerkniveau ook een firewall op basis van een host. 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 van uw virtuele netwerk toegewezen. 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. Deze 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 vanaf 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 beschikbaar gemaakte 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.

Afweging: 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.

Beveiligen tegen DDoS-aanvallen (Distributed Denial of Service)

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

Een DDoS-aanval is meestal een groot, wijdverbreid, geografisch verspreid misbruik van de bronnen van uw systeem, waardoor het moeilijk is om de bron te achterhalen 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 toe te voegen aan uw netwerk.

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 uitgaand communiceren met internet. Maar inkomende communicatie is standaard beperkt.

Virtual Network biedt functies voor het filteren van verkeer. U kunt de toegang op het niveau van het virtuele netwerk beperken 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 inkomend en uitgaand verkeer via openbare IP-adressen. Afhankelijk van de service of topologie stelt u deze adressen in of wijst Azure ze toe. Andere mogelijkheden voor inkomend en uitgaand verkeer zijn 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 per se 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 kunt 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 bevat:
- Doelnetwerkadresomzetting (DNAT) of port forwarding.
- Handtekeningdetectie van inbraakdetectie en -preventiesysteem (IDPS).
- Sterke netwerkregels voor laag 3, laag 4 en FQDN (Fully Qualified Domain Name).
Notitie

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

Als u geen virtuele WAN-topologie gebruikt, moet u een UDR met een NextHopType van implementeren op het privé-IP-adres van Internet uw NVA. UDR's worden toegepast op subnetniveau. Subnet-naar-subnetverkeer loopt standaard niet door de NVA.

U kunt Azure Firewall ook tegelijkertijd gebruiken voor inkomend verkeer. Het kan HTTP- en HTTPS-verkeer routeren. In SKU's met een hogere laag biedt Azure Firewall TLS-beëindiging, zodat u inspecties op nettoladingniveau 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 FQDN-servicetags waar dit praktisch is. 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 FQDN-regel voor het toestaan van de infrastructuur alleen als uw workload absolute controle over uitgaand verkeer vereist. Het overschrijven van deze regel brengt een betrouwbaarheidsovereending met zich mee, omdat de azure-platformvereisten voor services veranderen.
Afweging: Azure Firewall kunnen van invloed zijn op uw prestaties. Regelvolgorde, hoeveelheid, TLS-inspectie en andere factoren kunnen aanzienlijke latentie veroorzaken.

Dit kan ook van invloed zijn op de betrouwbaarheid van uw workload. Er kan last zijn van SNAT-poortuitputting (Source Network Address Translation). Voeg zo nodig openbare IP-adressen toe om dit probleem op te lossen.

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 binnenkomende filtering 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 OWASP Top 10-document. Azure Web Application Firewall biedt ook andere beveiligingsfuncties die zijn gericht op laag 7, zoals snelheidsbeperking, SQL-injectieregels en scripting tussen sites.

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 Application 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 uit. Voor uw edge-beveiligingsoplossing zijn 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 in en uit stroomt aan de perimeter van een subnet. Een netwerkbeveiligingsgroep heeft een standaardregelset die te ruim is toegestaan. Met de standaardregels wordt bijvoorbeeld geen firewall ingesteld 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 binnenkomend verkeer of inkomend verkeer:
- Virtueel netwerkverkeer van directe, gekoppelde en VPN-gatewaybronnen is toegestaan.
- Azure Load Balancer statustests zijn toegestaan.
- Al het andere verkeer wordt geblokkeerd.
Voor uitgaand of uitgaand verkeer:
- Virtueel netwerkverkeer voor het omleiden, peeren 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 deze zijn moeilijk te onderhouden.

Maar voor Azure-services kunt u servicetags gebruiken om bron- en doel-IP-adresbereiken samen te vatten. Een beveiligingsvoordeel van servicetags is dat ze ondoorzichtig zijn voor de gebruiker en dat de verantwoordelijkheid wordt ge offload naar Azure. U kunt ook een toepassingsbeveiligingsgroep toewijzen als een doeltype waarnaar verkeer moet worden gerouteerd. Dit type benoemde groep bevat resources die vergelijkbare binnenkomende of uitgaande toegangsbehoeften hebben.

Risico: servicetagbereiken zijn zeer breed, zodat ze geschikt zijn voor een zo breed mogelijk scala aan klanten. Updates naar servicetags blijven achter bij wijzigingen in de service.

In de voorgaande afbeelding worden netwerkbeveiligingsgroepen toegepast op de NIC. Internetverkeer en subnet-naar-subnet-verkeer worden geweigerd. De netwerkbeveiligingsgroepen worden toegepast met de VirtualNetwork tag. In dit geval hebben de subnetten van peered netwerken dus een directe zichtlijn. De brede definitie van de VirtualNetwork tag kan aanzienlijke gevolgen hebben voor de beveiliging.

Wanneer u servicetags gebruikt, gebruikt u indien mogelijk regionale versies, zoals Storage.WestUS in plaats van Storage. Door deze aanpak 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. Binnenkomende tags staan meestal verkeer toe van alle hostingworkloads, zoals AzureFrontDoor.Backend, of van Azure ter ondersteuning van serviceruntimes, zoals LogicAppsManagement. Op dezelfde manier staat uitgaande tags verkeer toe naar alle hostingworkloads of vanuit Azure om serviceruntimes te ondersteunen.

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

Informatie	Voorbeeld
Protocol	Tcp (Transmission Control Protocol), UDP
IP-adres van bron	Toegang tot het subnet toestaan vanuit <source-IP-address-range>: 4575/UDP
Bronpoort	Inkomend verkeer naar het subnet toestaan vanaf <servicetag>: 443/TCP
IP-adres van doel	Uitgaand verkeer van het subnet naar <destination-IP-address-range>: 443/TCP toestaan
Doelpoort	Uitgaand verkeer van het subnet naar <servicetag> toestaan: 443/TCP

Samenvatting:

Wees nauwkeurig wanneer u regels maakt. Sta alleen verkeer toe dat nodig is om uw toepassing te laten functioneren. Weiger al het andere. Deze benadering beperkt de netwerk zichtlijn 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 betekent niet dat toegestane stromen buiten het bereik van een aanval vallen. Omdat netwerkbeveiligingsgroepen op laag 3 en 4 op de OSI-stack (Open Systems Interconnection) werken, bevatten ze alleen informatie over de vorm en richting. Als uw workload bijvoorbeeld DNS-verkeer naar internet moet toestaan, gebruikt u een netwerkbeveiligingsgroep van Internet:53:UDP. In dit geval kan een aanvaller mogelijk gegevens via UDP op poort 53 exfiltreren 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. Voor gedetailleerde filters is het veiliger om extra netwerkbeveiligingsgroepen te maken. Stel ten minste één netwerkbeveiligingsgroep in.
- Als u een netwerkbeveiligingsgroep toevoegt, ontgrendelt u veel diagnostische hulpprogramma's, zoals stroomlogboeken en netwerkverkeersanalyse.
- 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 deze minimaal impact heeft.

Azure-servicefirewalls

De meeste Azure-services bieden een firewall op serviceniveau. Deze functie inspecteert inkomend verkeer naar de service vanuit opgegeven CIDR-bereiken (Classless Inter-Domain Routing). Deze firewalls bieden voordelen:

Ze bieden een basisbeveiligingsniveau.
Dit heeft 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.

Maar er zijn ook beveiligingsproblemen met betrekking tot deze firewalls en er zijn beperkingen verbonden aan het leveren 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 firewallregelsets 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. Als u dit doet, worden alle afhankelijke services binnen het bereik van de regels opgenomen.

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 dan onbereikbaar via internet. Privé-eindpunten worden niet voor alle SKU's ondersteund.

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

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

Compromis: Service-SKU's met privé-eindpunten zijn duur. Privé-eindpunten kunnen bewerkingen bemoeilijken vanwege netwerk-obscuriteit. 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 bepaalde 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 particuliere 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 de Azure Portal. Azure Bastion verbetert de beveiliging van RDP- en SSH-verbindingen. Een typisch gebruiksvoorbeeld is om verbinding te maken met een jumpbox in hetzelfde virtuele netwerk of een virtueel peernetwerk. Als u Azure Bastion gebruikt, hoeft de VM geen openbaar IP-adres meer te hebben.

Azure DDoS Protection

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

Hoger gelaagde SKU's van DDoS Protection zijn beschikbaar, maar zijn niet gratis. De schaal en capaciteit van het wereldwijd geïmplementeerde Azure-netwerk bieden bescherming tegen veelvoorkomende aanvallen op netwerklagen. Technologieën zoals permanente verkeersbewaking en realtime beperking bieden deze mogelijkheid.

Zie het Overzicht van Azure DDoS Protection voor meer informatie.

Voorbeeld

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

IT-omgeving

Dit voorbeeld bouwt voort op de IT-omgeving (Information Technology) die is vastgesteld in de beveiligingsbasislijn (SE:01). Deze benadering biedt een breed inzicht in netwerkbeheer die worden toegepast op verschillende perimeters om verkeer te beperken.

Netwerkaanvalpersoons. Verschillende persona's kunnen worden beschouwd 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 via een VPN is verbonden met de on-premises omgeving. Configureer met HET IPSec-protocol om beveiligde communicatie mogelijk te maken.
Openbare toegang tot de toepassing. Plaats een Waf (Web Application Firewall) voor de toepassing 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. Zorg voor DDoS-beveiliging voor uw hele VNet.
Netwerktopologie. Een netwerktopologie, zoals hub-spoke, is veiliger en optimaliseert de kosten. Het hubnetwerk biedt gecentraliseerde firewallbeveiliging voor alle peer-spokes.
Privé-eindpunten: overweeg om openbaar toegankelijke services toe te voegen aan uw particuliere netwerk met behulp van privé-eindpunten. Deze maken een netwerkkaart (NIC) in uw privé-VNet en verbinden met de Azure-service.
TLS-communicatie. Beveilig gegevens die onderweg zijn door te communiceren via TLS.
Netwerkbeveiligingsgroep (NSG): beveilig segmenten binnen een VNet met NSG, een gratis resource die inkomende en uitgaande TCP/UDP-communicatie filtert op basis van IP- en poortbereiken. 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 wordt 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 for Cloud.
Microsoft Defender for Cloud. Microsoft Defender for Cloud biedt veel oplossingen voor workloadbeveiliging, waaronder netwerkaanbevelingen voor uw omgeving.
Traffic Analytics: bewaak uw netwerkbesturingselementen met Traffic Analytics. Dit wordt geconfigureerd via Network Watcher, onderdeel van Azure Monitor, en aggregeren binnenkomende en uitgaande treffers in uw subnetten die zijn verzameld door NSG.

Architectuur voor een workload in een container

In deze voorbeeldarchitectuur worden de netwerkbesturingselementen gecombineerd die in dit artikel worden beschreven. In het voorbeeld wordt niet de volledige architectuur weergegeven. In plaats daarvan richt het zich op beheeropties 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 webtoepassingsfirewalls.

Communicatie met alle PaaS-services vindt plaats 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 basisniveau of een hoger niveau van firewallbeveiliging.

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

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

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging

Aanbevelingen voor netwerken en connectiviteit