Azure-services voor het beveiligen van netwerkconnectiviteit

Vaak hebben de workload en de ondersteunende onderdelen van een cloudarchitectuur toegang nodig tot externe assets. Deze assets kunnen on-premises zijn, apparaten buiten het hoofdnetwerk van het virtuele netwerk of andere Azure-resources. Deze verbindingen kunnen via internet of via netwerken binnen de organisatie zijn.

Belangrijkste punten

  • Niet-openbaar toegankelijke services beveiligen met netwerkbeperkingen en IP-firewall.
  • Gebruik netwerkbeveiligingsgroepen (NSG's) of Azure Firewall verkeer binnen het VNet te beveiligen en te controleren.
  • Gebruik Service-eindpunten of Private Link voor toegang tot Azure PaaS-services.
  • Gebruik Azure Firewall om u te beschermen tegen aanvallen met gegevens exfiltratie.
  • Beperk de toegang tot back-endservices tot een minimale set openbare IP-adressen, alleen de services die deze echt nodig hebben.
  • Gebruik Azure-besturingselementen voor oplossingen van derden voor basisbeveiligingsbehoeften. Ze zijn eenvoudig te configureren en te schalen.
  • Definieer toegangsbeleid op basis van het type workload en controlestroom tussen de verschillende toepassingslagen.

Connectiviteit tussen netwerksegmenten

Bij het ontwerpen van een workload begint u meestal met het inrichten van een Azure Virtual Network (VNet) in een privé-adresruimte die de workload heeft. Er is standaard geen verkeer toegestaan tussen twee virtuele netwerken. Als dat nodig is, definieert u de communicatiepaden expliciet. Een manier om VNets te verbinden is via peering voor virtuele netwerken.

Een belangrijk aspect is het beveiligen van de VM's in het VNet. Met de netwerkinterfaces op de VM's kunnen ze communiceren met andere VM's, internet en on-premises netwerken. Gebruik ASG's (Application Security Groups) om verkeer op VM's binnen een VNet (en subnet) te controleren. U kunt een set VM's groeperen onder een toepassingstag en verkeersregels definiëren. Deze regels worden vervolgens toegepast op elk van de onderliggende VM's.

Een VNet wordt gesegmenteerd in subnetten op basis van bedrijfsvereisten. Bied de juiste besturingselementen voor netwerkbeveiliging waarmee inkomende netwerkverkeer naar of uitgaand netwerkverkeer van binnen grotere netwerkruimte wordt toegestaan of weigeren.

U kunt VM's ook inrichten met privé-IP-adressen voor beveiliging. Profiteer van het Azure IP-adres om inkomend verkeer te bepalen, hoe en waar het wordt omgezet in het virtuele netwerk.

Een goed Azure IP-adresseringsschema biedt flexibiliteit, ruimte voor groei en integratie met on-premises netwerken. Het schema zorgt ervoor dat de communicatie werkt voor geïmplementeerde resources, dat de openbare blootstelling van systemen wordt geminimaliseerd en dat de organisatie flexibiliteit krijgt in het netwerk. Als het niet goed is ontworpen, kunnen systemen mogelijk niet communiceren en moeten er aanvullende werkzaamheden worden uitgevoerd om problemen te verhelpen.

Hoe kunt u verkeer isoleren en beveiligen binnen het VNet van de workload?


Als u de communicatie binnen een VNet wilt beveiligen, stelt u regels in die het verkeer inspecteren. Vervolgens kunt u verkeer naar of van specifieke bronnen toestaan of weigeren en deze naar de opgegeven bestemmingen door laten gaan.

Taak Controleer de regelset en controleer of de vereiste services niet per ongeluk worden geblokkeerd.

Voor verkeer tussen subnetten wordt de aanbevolen manier via netwerkbeveiligingsgroepen (NSG's) . Definieer regels op elke NSG die verkeer van en naar één IP-adres, meerdere IP-adressen of volledige subnetten controleert.

Als NSG's worden gebruikt om de toepassing te isoleren en te beveiligen, moet de regelset worden gecontroleerd om te bevestigen dat vereiste services niet per ongeluk worden geblokkeerd of dat meer toegestane toegang is toegestaan dan verwacht. Azure Firewall (en Firewall Manager) kunnen worden gebruikt voor het centraliseren en beheren van firewallbeleid.

Een andere manier is om virtuele netwerkapparaten (N NVA's) te gebruiken die het inkomende (binnenkomende) en uitgaande (uitgaande) verkeer en filters controleren op basis van regels.

Hoe routeer u netwerkverkeer via N NVA's voor het afdwingen, controleren en inspecteren van beveiligingsgrensbeleid?


Gebruik door de gebruiker gedefinieerde routes (UDR) om de volgende hop voor verkeer tussen Azure-, on-premises- en internetresources te beheren. De routes kunnen worden toegepast op het virtuele apparaat, de gateway van het virtuele netwerk, het virtuele netwerk of internet.

U moet bijvoorbeeld al het ingress-verkeer van een openbare load balancer. Eén manier is om een NVA te hosten in een subnet dat alleen verkeer toestaat als aan bepaalde criteria wordt voldaan. Dat verkeer wordt verzonden naar het subnet dat een interne load balancer die dat verkeer naar de back-endservices routeert.

U kunt ook N NVA's gebruiken voor het verkeer naar een andere verkeerssituatie. Zo wordt al het verkeer van de werkbelasting gerouteerd met behulp van UDR naar een ander subnet. Dat subnet heeft een interne load balancer die aanvragen distribueert naar de NVA (of een set NVA's). Deze NPO's sturen verkeer naar internet met behulp van hun afzonderlijke openbare IP-adressen.

Tip

Dit zijn de resources voor het voorgaande voorbeeld:

GitHub logo GitHub: Automatische failover voor virtuele netwerkapparaten.

De ontwerpoverwegingen worden beschreven in N NVA's met hoge beschikbare implementatie.

Azure Firewall kan fungeren als een NVA. Azure ondersteunt externe netwerkapparaatproviders. Ze zijn beschikbaar in Azure Marketplace.

Hoe krijgt u inzichten over uitgaand en uitgaand verkeer van deze workload?


Als algemene regel configureert en verzamelt u netwerkverkeerslogboeken. Als u NSG's gebruikt, kunt u NSG-stroomlogboeken vastleggen en analyseren om de prestaties en beveiliging te bewaken. Met de NSG-stroomlogboeken Traffic Analytics inzicht krijgen in interne en externe verkeersstromen van de toepassing.

Zie Netwerksegmentatie voor meer informatie over het definiëren van netwerkperimeters.

Kunnen het VNet en het subnet groei verwerken?


Normaal gesproken voegt u meer netwerkresources toe naarmate het ontwerp zich verder ontwikkelen. De meeste organisaties voegen uiteindelijk meer resources toe aan netwerken dan oorspronkelijk gepland. Herfactoring om ruimte te bieden aan de extra resources is een arbeidsintensief proces. Er is een beperkte beveiligingswaarde bij het maken van een zeer groot aantal kleine subnetten en het vervolgens proberen om netwerktoegangsbesturingselementen (zoals beveiligingsgroepen) toe te kennen aan elk van deze subnetten.

Plan uw subnetten op basis van rollen en functies die gebruikmaken van dezelfde protocollen. Op die manier kunt u resources toevoegen aan het subnet zonder wijzigingen aan te brengen in beveiligingsgroepen die toegangsbesturingselementen op netwerkniveau afdwingen.

Gebruik niet alle openstaande regels die uitgaand en uitgaand verkeer naar en van 0.0.0.0-255.255.255.255 toestaan. Gebruik een benadering met de minste bevoegdheden en sta alleen relevante protocollen toe. Het vermindert uw algehele netwerkaanvalsoppervlak op het subnet. Alle open regels geven een onwaar gevoel van beveiliging omdat een dergelijke regel geen beveiliging afdwingt.

De uitzondering hierop is wanneer u beveiligingsgroepen alleen wilt gebruiken voor netwerklogregistratiedoeleinden.

Ontwerp virtuele netwerken en subnetten voor groei. We raden u aan om subnetten te plannen op basis van algemene rollen en functies die gebruikmaken van algemene protocollen voor deze rollen en functies. Hierdoor kunt u resources toevoegen aan het subnet zonder wijzigingen aan te brengen in beveiligingsgroepen die toegangsbesturingselementen op netwerkniveau afdwingen.

Voorgestelde acties

Gebruik NSG of overweeg het gebruik van Azure Firewall om verkeer binnen het VNET te beveiligen en te controleren.

Lees meer

Internet edge-verkeer

Houd bij het ontwerpen van de workload rekening met de beveiliging van internetverkeer. Moet de workload of delen ervan toegankelijk zijn vanaf openbare IP-adressen? Welk toegangsniveau moet worden gegeven om onbevoegde toegang te voorkomen?

Internet edge-verkeer (ook wel Noord-Zuid-verkeer genoemd) vertegenwoordigt netwerkconnectiviteit tussen resources die worden gebruikt door de werkbelasting en internet. Er moet een strategie voor internetranden worden ontworpen om zo veel mogelijk aanvallen via internet te beperken om bedreigingen te detecteren of te blokkeren. Er zijn twee primaire opties die beveiligingsmaatregelen en bewaking bieden:

  • Azure-oplossingen zoals Azure Firewall en Web Application Firewall (WAF).

Azure biedt netwerkoplossingen om de toegang tot afzonderlijke services te beperken. Gebruik meerdere beveiligingsniveaus, zoals een combinatie van IP-filtering en firewallregels om te voorkomen dat toepassingsservices worden gebruikt door onbevoegde actoren.

  • Virtuele netwerkapparaten (N NVA's). U kunt de Azure Firewall of oplossingen van derden gebruiken die beschikbaar zijn in Azure Marketplace.

Azure-beveiligingsfuncties zijn voldoende voor veelvoorkomende aanvallen, eenvoudig te configureren en te schalen. Oplossingen van derden hebben vaak geavanceerde functies, maar kunnen lastig te configureren zijn als ze niet goed kunnen worden geïntegreerd met fabriccontrollers. Vanuit het oogpunt van kosten zijn Azure-opties doorgaans goedkoper dan partneroplossingen.

Informatie over het toepassingsplatform, zoals HTTP-banners met frameworkinformatie ( , ), wordt vaak gebruikt door kwaadwillende actoren bij het toewijzen van X-Powered-By X-ASPNET-VERSION aanvalsvectoren van de toepassing.

HTTP-headers, foutberichten en websitevoetteksten mogen geen informatie bevatten over het toepassingsplatform. Azure CDN kunnen worden gebruikt om het hostingplatform te scheiden van eindgebruikers. Azure API Management biedt transformatiebeleid waarmee u HTTP-headers kunt wijzigen en gevoelige informatie kunt verwijderen.

Voorgestelde actie

Overweeg het gebruik CDN voor de workload om de blootstelling van platformdetails aan aanvallers te beperken.

Meer informatie

Azure CDN documentatie

Communicatie met back-endservices

De meeste workloads bestaan uit meerdere lagen waar verschillende services elke laag kunnen bedienen. Veelvoorkomende voorbeelden van lagen zijn webfront-ends, bedrijfsprocessen, rapportage en analyse, back-endsinfrastructuur, en meer.

Toepassingsbronnen waarmee meerdere methoden app-inhoud kunnen publiceren (zoals FTP, Web Deploy) moeten de ongebruikte eindpunten hebben uitgeschakeld. Voor Azure Web Apps is SCM het aanbevolen eindpunt en kan SCM afzonderlijk worden beveiligd met netwerkbeperkingen voor gevoelige scenario's.

Openbare toegang tot elke workload moet verstandig worden goedgekeurd en gepland, omdat openbare toegangspunten een belangrijke mogelijke aanvalsvector vormen. Wanneer u toegang van openbare IP's tot elke back-endservice toestaat, kan het beperken van het bereik van toegestane IP's de aanvalsoppervlak van die service aanzienlijk verminderen. Als u bijvoorbeeld Azure Front Door gebruikt, kunt u back-Front Door beperken tot alleen toegestane IP's; of als een partner uw API gebruikt, beperkt u de toegang tot alleen hun benoemde openbare IP('s).

Hoe configureert u de verkeersstroom tussen meerdere toepassingslagen?


Gebruik Azure Virtual Network Subnet om afzonderlijke adresruimten toe te wijzen voor verschillende elementen of lagen binnen de workload. Definieer vervolgens verschillende toegangsbeleidsregels om verkeersstromen tussen deze lagen te beheren en de toegang te beperken. U kunt deze beperkingen implementeren via IP-filtering of firewallregels.

Moet u de toegang tot de back-infrastructuur beperken?


Beperk de toegang tot back-endservices tot een minimale set openbare IP-adressen met App Services IP-beperkingen of Azure Front Door.

Webtoepassingen hebben doorgaans één openbaar toegangspunt en bieden geen volgende API's en databaseservers via internet. Alleen een minimale set openbare IP-adressen beschikbaar maken op basis van de behoefte en alleen de personen die het echt nodig hebben. Wanneer u bijvoorbeeld gatewayservices gebruikt, zoals Azure Front Door, kunt u de toegang beperken tot een set Front Door IP-adressen en de infrastructuur volledig vergrendelen.

Voorgestelde actie

  • Publicatiemethoden voor toepassingen beperken en beveiligen.

Meer informatie

Verbinding met Azure PaaS-services

De workload moet vaak communiceren met andere Azure-services. Het kan bijvoorbeeld nodig zijn om geheimen op te halen uit Azure Key Vault. Vermijd het maken van verbindingen via het openbare internet.

Maakt de workload gebruik van veilige manieren om toegang te krijgen tot Azure PaaS-services?


Veelgebruikte benaderingen voor toegang tot PaaS-services zijn service-eindpunten of privékoppelingen. Beide benaderingen beperken de toegang tot PaaS-eindpunten alleen van geautoriseerde virtuele netwerken, waardoor gegevensindringingsrisico's en de bijbehorende gevolgen voor de beschikbaarheid van toepassingen effectief worden beperkt.

Met service-eindpunten is het communicatiepad veilig omdat u het PaaS-eindpunt kunt bereiken zonder dat u een openbaar IP-adres op het VNet nodig hebt. De meeste PaaS-services ondersteunen communicatie via service-eindpunten. Zie voor een lijst met algemeen beschikbare services Virtual Network service-eindpunten.

Een ander mechanisme is via Azure Private Link. Private Endpoint maakt gebruik van een privé-IP-adres van uw VNet, waarbij de service effectief in uw VNet wordt geplaatst. Zie Wat is Azure Private Link? voor meer informatie.

Service-eindpunten bieden toegang op serviceniveau tot een PaaS-service, terwijl Private Link directe toegang biedt tot een specifieke PaaS-resource om gegevens exfiltratierisico's te beperken, zoals schadelijke beheerderstoegang. Private Link is een betaalde service en heeft meters voor verwerkte binnenkomende en uitgaande gegevens. Privé-eindpunten worden ook in rekening gebracht.

Hoe kunt u uitgaand verkeer van Azure PaaS-services controleren wanneer Private Link niet beschikbaar is?


Gebruik NSA's en Azure Firewall (voor ondersteunde protocollen) als een omgekeerde proxy om de toegang te beperken tot alleen geautoriseerde PaaS-services voor services waar Private Link niet wordt ondersteund. Gebruik Azure Firewall bescherming tegen problemen met gegevens exfiltratie.

Connectiviteit tussen on-premises en cloud

In een hybride architectuur wordt de workload deels on-premises uitgevoerd en deels in Azure. Beveiligingscontroles hebben die verkeer controleren dat het virtuele Azure-netwerk binnenkomt vanuit een on-premises datacenter.

Hoe maakt u cross-premises connectiviteit tot stand?


Gebruik Azure ExpressRoute om cross-premises connectiviteit met on-premises netwerken in te stellen. Deze service maakt gebruik van een persoonlijke, toegewezen verbinding via een connectiviteitsprovider van derden. De particuliere verbinding breidt uw on-premises netwerk uit naar Azure. Op deze manier kunt u het risico op toegang tot de bedrijfsgegevensactiva on-premises verminderen.

Hoe krijgt u toegang tot VM's?


Gebruik Azure Bastion om u aan te melden bij uw VM's en om blootstelling van openbaar internet te voorkomen met behulp van SSH en RDP met alleen privé-IP-adressen. U kunt ook RDP-/SSH-toegang tot VM's uitschakelen en VPN, ExpressRoute gebruiken voor toegang tot deze virtuele machines voor extern beheer.

Hebben de cloud- of on-premises VM's directe internetverbinding voor gebruikers die interactieve aanmeldingen kunnen uitvoeren?


Aanvallers scannen voortdurend ip-adresbereiken van openbare cloud op open beheerpoorten en proberen goedkope aanvallen uit te voeren, zoals veelgebruikte wachtwoorden en bekende niet-gepatchte beveiligingsproblemen. Ontwikkel processen en procedures om directe internettoegang van VM's te voorkomen met logboekregistratie en bewaking om beleid af te dwingen.

Hoe wordt internetverkeer gerouteerd?


Bepalen hoe u internetverkeer routeert. U kunt on-premises beveiligingsapparaten gebruiken (ook wel geforceerd tunnelen genoemd) of connectiviteit toestaan via netwerkbeveiligingsapparaten in de cloud.

Voor een productiebedrijf kunt u cloudbronnen toestaan om een internetaanvraag rechtstreeks te starten en hierop te reageren via cloudnetwerkbeveiligingsapparaten die zijn gedefinieerd door uw strategie voor internetranden. Deze aanpak past bij het paradigma van het Nth-datacenter. Azure-datacenters maken deel uit van uw onderneming. Het schaalt beter voor een bedrijfsimplementatie, omdat hiermee hops worden verwijderd die belasting, latentie en kosten toevoegen.

Een andere optie is om al het uitgaande internetverkeer van on-premises via een site-naar-site-VPN geforceereerd te maken. Of gebruik een cross-premises WAN-verbinding. Netwerkbeveiligingsteams hebben meer beveiliging en zichtbaarheid voor internetverkeer. Zelfs wanneer uw resources in de cloud proberen te reageren op inkomende aanvragen van internet, worden de reacties geforceerd getunneld. Deze optie past bij een gebruikscase voor datacenteruitbreiding en kan goed werken voor een snel bewijs van concept, maar kan slecht worden geschaald vanwege de toegenomen verkeersbelasting, latentie en kosten. Daarom raden we u aan geforceerd tunnelen te voorkomen.

Volgende stap

Zie Azure Virtual Network User Defined Routes (UDR)voor meer informatie over het beheren van de volgende hop voor verkeer.

Zie WAF voor meer informatie over webtoepassingsfirewalls Application Gateway WAF.

Zie Netwerkapparaten voor meer Azure Marketplace netwerkapparaten.

Zie Azure site-to-site VPNof ExpressRoute voor meer informatie over cross-premises connectiviteit.

Zie RDP-/SSH-toegangtot Azure Virtual Machines voor meer informatie over het gebruik van VPN/ExpressRoute voor toegang tot deze virtuele machines voor extern beheer.

Terug het hoofdartikel: Netwerkbeveiliging