Netwerkbeveiliging implementeren
Netwerkbeveiliging wordt gedefinieerd als het proces voor het beveiligen van resources tegen onbevoegde toegang of aanvallen door besturingselementen toe te passen op netwerkverkeer. Hoewel besturingselementen op verschillende manieren kunnen worden toegepast, is het doel ervoor te zorgen dat alleen legitiem verkeer is toegestaan.
Hieronder ziet u een voorbeeld van een architectuurweergave van een HDInsight-cluster dat is geïmplementeerd met netwerkbeveiliging en een bijbehorende discussie over hoe dit wordt bereikt. De zwarte pijlen vertegenwoordigen inkomend verkeer en de blauwe pijlen vertegenwoordigen uitgaand verkeer
Het doel van het bovenstaande ontwerp is ervoor te zorgen dat alleen netwerkverkeer dat afkomstig is van vertrouwde bronnen het HDInsight-cluster kan bereiken en netwerkverkeer dat van het HDInsight-cluster vertrekt, naar een vertrouwde bestemming gaat. Bovendien is netwerkverkeer dat opslag- en metastore-services bereikt, beperkt tot verkeer dat afkomstig is van HDInsight.
Laten we inzoomen op de details van het bovenstaande ontwerp door naar de volgende gebieden te kijken
- Binnenkomende beveiliging en clustertoegang
- Uitgaande beveiliging
- VNet-service-eindpunten.
Binnenkomende beveiliging
Binnenkomende netwerkbeveiliging wordt bereikt met behulp van een netwerkbeveiligingsgroep (NSG) die is toegewezen aan het subnet. De NSG maakt gebruik van HDInsight-servicestags en IP-bereiken om binnenkomend verkeer naar vertrouwde bronnen te beperken.
In de bovenstaande weergave worden twee sets inkomende beveiligingsregels gemaakt in de netwerkbeveiligingsgroep. De eerste beveiligingsregel voor binnenkomend verkeer maakt gebruik van de HDInsight-servicetag om inkomend verkeer van de status- en beheerservices van HDInsight toe te staan. De tweede beveiligingsregel voor inkomend verkeer is een IP-bereik waarmee gebruikers binnen een bepaald IP-adresbereik toegang hebben tot specifieke poorten in HDInsight (bijvoorbeeld SSH-poort 22).
Binnenkomende netwerkbeveiliging wordt bereikt met behulp van NSG-regels in het subnet waarin het HDInsight-cluster wordt geïmplementeerd. Hieronder ziet u een voorbeeld van hoe de regels van deze NSG kunnen worden gemaakt.
Maak indien nodig een VNet met meerdere subnetten. Een van deze subnetten is bedoeld om het HDInsight-cluster te hosten en wordt gekoppeld aan de NSG.
Maak een netwerkbeveiligingsgroep (NSG). In de NSG bevinden zich twee sets beveiligingsregels, inkomend en uitgaand, onder de sectie Instellingen aan de linkerkant. We gebruiken de sectie Inkomende beveiligingsregels en voegen aanvullende regels toe aan de bestaande set regels.
Identificeer de regio waarin uw HDInsight-service wordt geïmplementeerd en op basis van de regio de servicetags identificeren die moeten worden gebruikt. Afhankelijk van de regio en het niveau van beperkende machtigingen, kunnen er permutaties en combinaties van servicetags zijn die u moet toepassen om het doel te bereiken. Klik op Toevoegen om extra inkomende beveiligingsregels in de netwerkbeveiligingsgroep te maken en servicetags toe te wijzen op basis van de implementatieregio.
Hieronder ziet u een voorbeeld van de combinatie van regio-naar-servicetags. De uitgebreide lijst met regio's voor combinaties van servicetags vindt u in servicetags voor netwerkbeveiligingsgroepen (NSG) voor Azure HDInsight.
| Type servicetag | Land/regio | Regio | Servicetag | Beschrijving |
|---|---|---|---|---|
| Globaal | N.v.t. | N.v.t. | HDInsight | Eén globale servicetag voor HDInsight |
| Regionaal | Verenigde Staten | VS - west 2 | HDInsight.WestUS2 | Enkele servicetag |
| Regionaal | Verenigde Staten | VS - oost 2 | HDInsight.EastUS2 HDInsight.WestUS HDInsight.EastUS | Combinatie van servicetags |
| Regionaal | China | China - noord | HDInsight.ChinaNorth HDInsight.ChinaEast | Combinatie van servicetags |
- Op basis van uw ontwerpvereisten kunt u nu extra regels toevoegen aan de sectie Regels voor inkomend verkeer van andere vertrouwde bronnen.
HDInsight-clustertoegang met geïmplementeerd met een VNet
Vanuit een beveiligingspunt zijn doorgaans alle openbare eindpunten naar het HDInsight-cluster niet toegankelijk. In dat geval zijn er meerdere alternatieve manieren om toegang te krijgen tot een HDInsight-cluster in een VNet en worden ze weergegeven in de onderstaande voorbeeldweergave. HDInsight-clusters die zijn gemaakt in een VNet, maken zowel openbare als privé-eindpunten met gelijke taakverdeling beschikbaar.
In netwerkpad 1 wordt de toegang tot het cluster geblokkeerd via algemeen openbaar internet, maar NSG-regels kunnen worden gemaakt om specifieke clients buiten Azure beveiligde toegang tot het cluster via een openbaar eindpunt via https via poort 443 toe te staan met behulp van https://< clustername.azurehdinsight.net>.
In netwerkpad 2 wordt een jumpbox gemaakt binnen het VNet waarin het HDInsight-subnet zich bevindt om de NSG te omzeilen. Gebruikers kunnen RDP gebruiken in deze jumpbox en vervolgens toegang krijgen tot het privé-eindpunt van HDInsight met <clusternaam> via poort 443 met behulp van https://< clustername.azurehdinsight.net>.
In netwerkpad 3 worden NSG-regels gewijzigd voor een client buiten Azure om ssh-toegang tot het cluster te krijgen via het openbare eindpunt via poort 22 met behulp van https://< clustername-ssh.azurehdinsight.net>.
Uitgaande beveiliging
Verkeer dat afkomstig is van HDInsight, moet naar meerdere bestemmingen zijn toegestaan om de service goed te laten functioneren. U moet echter ook voorzichtig zijn om ervoor te zorgen dat deze bestemmingen worden vertrouwd.
De afhankelijkheden van uitgaand verkeer van HDInsight worden gedefinieerd met FQDN's (Fully Qualified Domain Names) en hebben geen statische IP-adressen. Aangezien de IP-adressen van de FQDN's kunnen worden gewijzigd, kunnen NSG's niet worden gebruikt om uitgaand verkeer van een HDInsight-cluster te beheren. Vandaar dat de Azure Firewall-service, of een door de klant gehost virtueel netwerkapparaat , wordt gebruikt om uitgaand verkeer te beheren dat afkomstig is van een cluster. In praktische scenario's wordt verkeer dat uit het HDInsight-subnet stroomt gekanaald met behulp van een door de gebruiker gedefinieerde route (UDR) naar een virtueel netwerkapparaat of een Azure Firewall waarmee uitgaand verkeer wordt toegestaan op basis van beveiligingsregels die zijn gedefinieerd met de HDInsight-servicetag.
In het onderstaande voorbeeld ziet u dat uitgaand verkeer van het HDInsight-subnet naar een Azure Firewall stroomt, waarbij een evaluatie van de HDInsight-servicetag wordt uitgevoerd om ervoor te zorgen dat uitgaand verkeer dat is bestemd voor een vertrouwde bestemming. Hoewel verkeer is toegestaan voor Metastores, Storage en HDInsight Management IP enzovoort, wordt verkeer naar niet-goedgekeurde internetbestemmingen geblokkeerd. Hoewel de bestemmingen in de HDInsight-servicetag worden onderhouden door Microsoft, kunnen klanten met specifieke vereisten voor uitgaand verkeer waaraan niet wordt voldaan door de HDInsight-servicetag ervoor kiezen om hun eigen servicetag te maken van een gepubliceerde in HDInsight FQDN's die ze kunnen onderhouden en bijwerken. Details over routetabelconfiguraties en firewallinstellingen kunnen worden gecontroleerd op de pagina Uitgaand verkeer beperken voor HDInsight
De onderstaande stappen zijn nodig om beperkingen voor uitgaand verkeer in te schakelen:
- Een Azure-firewall maken
- Toepassings- en uitgaande beveiligingsnetwerkregels toevoegen aan de firewall
- Een door de gebruiker gedefinieerde route maken
Service-eindpunten voor virtueel netwerk
Service-eindpunten voor virtuele netwerken breiden de identiteit van een VNet uit naar een Azure-service. Het inschakelen van VNet-service-eindpunten op een service verleent toegang tot de service vanuit een specifieke combinatie van VNet/subnet en stuurt vervolgens verkeer van dat subnet naar de service via een optimaal en veilig pad. Resources zoals opslagaccount en SQL Metastores waartoe de HDInsight-service toegang nodig heeft, kunnen worden beveiligd via VNET-service-eindpunten, zoals wordt weergegeven in de onderstaande voorbeeldarchitectuur.
In dit voorbeeld worden VNet-service-eindpunten geconfigureerd in ADLS Gen2 Storage en de Hive Metastore-service (op Azure SQL Server) en worden verkeer vanaf het HDInsight-VNet toegestaan.
De stappen voor het maken van VNet-service-eindpunten worden uitgebreid beschreven in de sectie Data Access Security.
