Zero Trust-principes toepassen op een virtueel spoke-netwerk in Azure
Samenvatting: Als u Zero Trust-principes wilt toepassen op een virtueel spoke-netwerk in Azure, moet u gebruikmaken van op rollen gebaseerd toegangsbeheer (RBAC), subnetten en virtuele machines isoleren (resourcegroepen, netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen), verkeer en resources binnen het VNet en virtuele-machinetoepassingen beveiligen en geavanceerde detectie van bedreigingen, waarschuwingen en beveiliging inschakelen.
In dit artikel leest u hoe u de principes van Zero Trust kunt toepassen op een virtueel spoke-netwerk (VNet) voor IaaS-workloads in Azure op de volgende manieren:
| Zero Trust-principe | Definitie | Ontmoet door |
|---|---|---|
| Expliciet verifiëren | Altijd verifiëren en autoriseren op basis van alle beschikbare gegevenspunten. | Gebruik toepassingsbeveiligingsgroepen om te controleren of afzonderlijke NIC's machtigingen hebben om via specifieke kanalen te communiceren. |
| Toegang met minimale bevoegdheden gebruiken | Beperk gebruikerstoegang met Just-In-Time en Just-Enough-Access (JIT/JEA), op risico gebaseerd adaptief beleid en gegevensbeveiliging. | Schakel 3389/RDP-toegang niet standaard in op elk kanaal. Gebruik de juiste rolmachtigingen voor de spoke-context. |
| Stel dat er sprake is van een schending | Minimaliseer straal en segmenttoegang. Controleer end-to-end-versleuteling en gebruik analyse om zichtbaarheid te krijgen, detectie van bedreigingen te stimuleren en verdediging te verbeteren. | Beperk onnodige communicatie tussen resources. Zorg ervoor dat u zich kunt aanmelden bij netwerkbeveiligingsgroepen en dat u goed inzicht hebt in afwijkend verkeer. Wijzigingen in netwerkbeveiligingsgroepen bijhouden. |
Dit artikel maakt deel uit van een reeks artikelen die laten zien hoe u de principes van Zero Trust kunt toepassen in een omgeving in Azure met een spoke-VNet dat als host fungeert voor een workload op basis van een virtuele machine. Zie het overzicht van Zero Trust toepassen op Azure IaaS voor meer informatie.
Referentiearchitectuur
In het volgende diagram ziet u een algemene referentiearchitectuur voor workloads op basis van IaaS.
In het diagram:
- Een spoke-VNet bevat onderdelen ter ondersteuning van een IaaS-toepassing die bestaat uit virtuele machines.
- De IaaS-toepassing is een toepassing met drie lagen, bestaande uit twee virtuele machines voor elke laag: front-end, toepassing en gegevens.
- Elke laag bevindt zich in een toegewezen subnet met een toegewezen netwerkbeveiligingsgroep.
- Elke virtuele-machinerol wordt toegewezen aan een toepassingsbeveiligingsgroep die overeenkomt met de rol.
- Toegang tot de toepassing wordt geboden via een Application Gateway in een eigen subnet.
De toepassing die wordt weergegeven in de referentiearchitectuur volgt de architectuurstijl N-laag
In het volgende diagram ziet u de onderdelen van een resourcegroep voor een spoke-VNet in een Azure-abonnement, gescheiden van het abonnement voor het hub-VNet.
In het diagram bevinden alle onderdelen van het spoke-VNet zich in een toegewezen resourcegroep:
- Eén VNet
- Eén Azure-toepassing Gateway (App GW), inclusief een Web Application Firewall (WAF)
- Drie netwerkbeveiligingsgroepen, één voor elke toepassingslaag
- Drie toepassingsbeveiligingsgroepen, één voor elke toepassingslaag
Wat staat er in dit artikel?
Zero Trust-principes worden toegepast in de architectuur, van tenant- en directoryniveau tot de toewijzing van virtuele machines aan toepassingsbeveiligingsgroepen. In de volgende tabel worden de aanbevelingen voor het beveiligen van deze architectuur beschreven.
| Stap | Taak | Zero Trust-principe(en) toegepast |
|---|---|---|
| 1 | Gebruik op rollen gebaseerd toegangsbeheer (RBAC) van Microsoft Entra of stel aangepaste rollen in voor netwerkresources. | Toegang met minimale bevoegdheden gebruiken |
| 2 | De infrastructuur isoleren in een eigen resourcegroep. | Stel dat er sprake is van een schending |
| 3 | Maak een netwerkbeveiligingsgroep voor elk subnet. | Toegang met minimale bevoegdheden gebruiken Stel dat er sprake is van een schending |
| 4 | Maak een toepassingsbeveiligingsgroep voor elke virtuele-machinerol. | Expliciet verifiëren Toegang met minimale bevoegdheden gebruiken Stel dat er sprake is van een schending |
| 5 | Verkeer en resources in het VNet beveiligen: |
Expliciet verifiëren Toegang met minimale bevoegdheden gebruiken Stel dat er sprake is van een schending |
| 6 | Beveiligde toegang tot het VNet en de toepassing. | Toegang met minimale bevoegdheden gebruiken Stel dat er sprake is van een schending |
| 7 | Geavanceerde detectie van bedreigingen, waarschuwingen en beveiliging inschakelen. | Stel dat er sprake is van een schending |
Stap 1: Microsoft Entra RBAC gebruiken of aangepaste rollen instellen voor netwerkresources
U kunt ingebouwde Microsoft Entra RBAC-rollen gebruiken voor netwerkbijdragers. Een andere benadering is echter het gebruik van aangepaste rollen. Spoke-netwerkbeheerders hebben geen volledige toegang nodig tot netwerkresources die zijn verleend door de rol Microsoft Entra RBAC Network Contributor, maar hebben meer machtigingen nodig dan andere algemene rollen. U kunt een aangepaste rol gebruiken om de toegang te beperken tot alleen wat er nodig is.
Een eenvoudige manier om dit te implementeren, is door de aangepaste rollen te implementeren die zijn gevonden in de referentiearchitectuur van de Azure-landingszone.
De specifieke rol is de aangepaste rol Netwerkbeheer heeft de volgende machtigingen:
- Alles lezen in het bereik
- Acties met de netwerkprovider
- Acties met de ondersteuningsprovider
- Acties met de resourceprovider
U kunt deze rol maken met behulp van de scripts voor de aangepaste rollen of via Microsoft Entra-id met het proces dat wordt beschreven in aangepaste Azure-rollen - Azure RBAC.
Stap 2: Infrastructuur isoleren in een eigen resourcegroep
Door netwerkresources te isoleren van reken-, gegevens- of opslagresources, vermindert u de kans op ontbloeding van machtigingen. Door ervoor te zorgen dat alle gerelateerde resources zich in één resourcegroep bevinden, kunt u één beveiligingstoewijzing maken en logboekregistratie en bewaking voor deze resources beter beheren.
In plaats van dat de spoke-netwerkresources beschikbaar zijn in meerdere contexten in een gedeelde resourcegroep, maakt u er een toegewezen resourcegroep voor. De referentiearchitectuur die in dit artikel wordt ondersteund, illustreert dit concept.
In de afbeelding worden resources en onderdelen in de referentiearchitectuur onderverdeeld in toegewezen resourcegroepen voor virtuele machines, opslagaccounts, hub-VNet-resources en spoke-VNet-resources.
Met een toegewezen resourcegroep kunt u een aangepaste rol toewijzen met behulp van het volgende proces: Zelfstudie: Een gebruiker toegang verlenen tot Azure-resources met behulp van Azure Portal - Azure RBAC.
Aanvullende aanbevelingen:
- Verwijs naar een beveiligingsgroep voor de rol in plaats van benoemde personen.
- Toegang tot de beveiligingsgroep beheren via uw identiteitsbeheerpatronen voor ondernemingen.
Als u geen beleid gebruikt waarmee het doorsturen van logboeken voor resourcegroepen wordt afgedwongen, configureert u dit in het activiteitenlogboek voor de resourcegroep: Navigeer naar Activiteitenlogboek exporteren activiteitenlogboeken > en selecteer vervolgens + Diagnostische instelling toevoegen.
Selecteer in het scherm Diagnostische instelling alle logboekcategorieën (met name beveiliging) en verzend deze naar de juiste logboekbronnen, zoals een Log Analytics-werkruimte voor waarneembaarheid of een opslagaccount voor langetermijnopslag.
Democratisering van abonnementen
Hoewel dit niet rechtstreeks is gerelateerd aan netwerken, moet u uw abonnements-RBAC op een vergelijkbare manier plannen. Naast het logisch isoleren van resources per resourcegroep, moet u het abonnement ook isoleren op basis van bedrijfsgebieden en portfolio-eigenaren. Het abonnement als beheereenheid moet beperkt worden beperkt.
Zie ontwerpprincipes voor Azure-landingszones voor meer informatie over de democratisering van abonnementen: Cloud Adoption Framework.
U configureert diagnostische gegevens uit de beveiligingscategorie diagnostische instelling in Azure Monitor, zoals hier wordt weergegeven.
Zie Diagnostische instellingen voor meer informatie over het controleren van deze logboeken en waarschuwingen.
Stap 3: Een netwerkbeveiligingsgroep maken voor elk subnet
Azure-netwerkbeveiligingsgroepen worden gebruikt om netwerkverkeer tussen Azure-resources in een Azure-VNet te filteren. Het is raadzaam om een netwerkbeveiligingsgroep toe te passen op elk subnet, dat standaard wordt afgedwongen via Azure Policy bij het implementeren van Azure-landingszones. Een netwerkbeveiligingsgroep bevat beveiligingsregels waarmee binnenkomend netwerkverkeer naar, of uitgaand netwerkverkeer van, diverse typen Azure-resources kan worden toegestaan of geweigerd. Voor elke regel kunt u de bron en het doel, de poort en het protocol opgeven.
Voor een toepassing met meerdere lagen op basis van virtuele machines wordt aangeraden een toegewezen netwerkbeveiligingsgroep (NSG) te maken in de volgende afbeelding voor elk subnet dat als host fungeert voor een virtuele-machinerol.
In het diagram:
- Elke laag van de toepassing wordt gehost in een toegewezen subnet, zoals de front-endlaag, de app-laag en de gegevenslaag.
- Voor elk van deze subnetten wordt een netwerkbeveiligingsgroep geconfigureerd.
Het configureren van netwerkbeveiligingsgroepen op een andere manier dan in de afbeelding kan leiden tot een onjuiste configuratie van sommige of alle netwerkbeveiligingsgroepen en kan problemen bij het oplossen van problemen opleveren. Het kan ook lastig maken om te controleren en te registreren.
Een netwerkbeveiligingsgroep maken met behulp van dit proces: Een Azure-netwerkbeveiligingsgroep maken, wijzigen of verwijderen
Zie netwerkbeveiligingsgroepen om te begrijpen hoe u deze kunt gebruiken om de omgeving te beveiligen.
Stap 4: Een toepassingsbeveiligingsgroep maken voor elke virtuele-machinerol
Met behulp van toepassingsbeveiligingsgroepen kunt u netwerkbeveiliging configureren als een natuurlijk verlengstuk van de structuur van een toepassing, waarbij u virtuele machines kunt groeperen en netwerkbeveiligingsbeleid kunt definiëren op basis van die groepen. U kunt het beveiligingsbeleid op grote schaal opnieuw gebruiken zonder handmatig onderhoud van expliciete IP-adressen. Het platform verwerkt de complexiteit van expliciete IP-adressen en meerdere regelsets, zodat u zich kunt richten op uw bedrijfslogica.
Identificeer binnen uw workload de specifieke virtuele-machinerollen. Vervolgens bouwt u een toepassingsbeveiligingsgroep voor elke rol. In de referentiearchitectuur worden drie toepassingsbeveiligingsgroepen weergegeven.
In het diagram:
- Er worden drie toepassingsbeveiligingsgroepen gemaakt ter ondersteuning van deze app, één voor elke laag: front-end, app en gegevens.
- Elke virtuele machine wordt toegewezen aan de bijbehorende toepassingsbeveiligingsgroep voor de rol (rode tekst in het diagram).
Zie het overzicht van Azure-toepassingsbeveiligingsgroepen voor meer informatie over toepassingsbeveiligingsgroepen en het toewijzen hiervan aan virtuele machines.
Notitie
Als u load balancers gebruikt, is het IP-adres van de load balancer in de netwerkbeveiligingsgroepen vereist, omdat toepassingsbeveiligingsgroepen geen load balancer kunnen bereiken.
Stap 5: Verkeer en resources binnen het VNet beveiligen
In deze sectie worden de volgende aanbevelingen behandeld:
- Regels voor weigeren volgens basislijn implementeren voor netwerkbeveiligingsgroepen
- Toepassingsspecifieke regels implementeren voor toepassingsbeveiligingsgroepen
- Beheerverkeer plannen in het VNet
- Stroomlogboekregistratie voor netwerkbeveiligingsgroepen implementeren
Regels voor weigeren volgens basislijn implementeren voor netwerkbeveiligingsgroepen
Een belangrijk element van Zero Trust is het minst benodigde toegangsniveau. Netwerkbeveiligingsgroepen hebben standaard regels toegestaan. Door een basislijn van regels voor weigeren toe te voegen, kunt u het minste toegangsniveau afdwingen.
Zodra deze is ingericht, maakt u een regel voor weigeren in elk van de regels voor inkomend en uitgaand verkeer, met een prioriteit van 4096. Dit is de laatste aangepaste prioriteit die beschikbaar is, wat betekent dat u nog steeds het resterende bereik hebt om acties toestaan te configureren.
Navigeer in de netwerkbeveiligingsgroep naar uitgaande beveiligingsregels en selecteer Toevoegen. Vul het volgende in:
- Bron: Elke
- Poortbereiken van bron: *
- Bestemming: alle
- Service: Aangepast
- Doelpoortbereiken: *
- Protocol: elk
- Actie: Weigeren
- Prioriteit: 4096
- Naam: DenyAllOutbound
- Beschrijving: hiermee wordt al het uitgaande verkeer geweigerd, tenzij specifiek is toegestaan.
Dit is een voorbeeld.
Herhaal dit proces met regels voor inkomend verkeer, waarbij u de naam en beschrijving zo nodig aanpast. U ziet dat er op het tabblad Inkomende beveiligingsregels een waarschuwingsteken op de regel staat, zoals hier wordt weergegeven.
Als u op de regel klikt en naar beneden schuift, ziet u meer details, zoals hier wordt weergegeven.
Dit bericht bevat de volgende twee waarschuwingen:
- Azure Load Balancers hebben standaard geen toegang tot resources met behulp van deze netwerkbeveiligingsgroep.
- Andere resources in dit VNet hebben standaard geen toegang tot resources met behulp van deze netwerkbeveiligingsgroep.
Voor ons doel in Zero Trust is dit hoe het moet zijn. Het betekent dat alleen omdat er iets op dit VNet staat, niet betekent dat het directe toegang heeft tot uw resources. Voor elk verkeerspatroon moet u een regel maken die deze expliciet toestaat. Dit moet u doen met de minste hoeveelheid machtigingen. Als u dus specifieke uitgaande verbindingen voor beheer hebt, zoals Active Directory-domein Services-domeincontrollers (AD DS), privé-DNS-VM's of specifieke externe websites, moeten ze hier worden beheerd.
Alternatieve regels voor weigeren
Als u Azure Firewall gebruikt om uw uitgaande verbindingen te beheren, kunt u in plaats van uitgaand alles weigeren uit te voeren, alle uitgaande verbindingen open laten. Als onderdeel van de Azure Firewall-implementatie stelt u een routetabel in waarmee de standaardroute (0.0.0.0/0) naar de firewall wordt verzonden, die verkeer buiten het VNet afhandelt.
U kunt vervolgens alle uitgaande VNet's weigeren of in plaats daarvan alle uitgaande items toestaan (maar items beveiligen met hun regels voor inkomend verkeer).
Lees meer over Azure Firewall en routetabellen om te begrijpen hoe u deze kunt gebruiken om de beveiliging van de omgeving verder te verbeteren.
Regels voor beheer van virtuele machines
Als u virtuele machines wilt configureren met Aanmelding bij Microsoft Entra, Antimalware en automatische updates ingeschakeld, moet u de volgende uitgaande verbindingen toestaan. Veel van deze zijn per FQDN, wat betekent dat Azure Firewall nodig is voor FQDN-regels, of u maakt een complexer plan. Azure Firewall wordt aanbevolen.
De uitgaande verbindingen zijn:
- Op poort 443:
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Op poort 80:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- Op poort 123:
- time.windows.com
- Op poort 1688:
- Azkms.core.windows.net
Toepassingsspecifieke regels implementeren voor toepassingsbeveiligingsgroepen
Definieer verkeerspatronen met de minste hoeveelheid machtigingen en volg alleen expliciet toegestane paden. Hier volgt een voorbeelddiagram van het gebruik van toepassingsbeveiligingsgroepen voor het definiëren van netwerkverkeerspatronen in de netwerkbeveiligingsgroepen voor een spoke-VNet dat samen met een hub-VNet wordt gebruikt. Dit is de aanbevolen configuratie.
Een ander voorbeeld: hier volgt een configuratie voor een zelfstandig spoke-VNet waarin de Web Application Firewall wordt geplaatst in het Application Gateway-subnet van het spoke-VNet.
U hebt de volgende regels voor netwerkbeveiligingsgroepen nodig:
- Internetverkeer toestaan in het APP GW-subnet (HTTPS 443).
- Verkeer van het APP GW-subnet naar de virtuele machines in de front-endlaag (HTTPS 433) toestaan.
- Verkeer van de virtuele machines in de front-endlaag naar de load balancer van de app-laag (HTTPS 443) toestaan.
- Verkeer van de load balancer van de app-laag naar de virtuele machines in de app-laag (HTTPS 443) toestaan.
- Verkeer van de virtuele machines in de app-laag naar de load balancer van de gegevenslaag (SQL 1433) toestaan.
- Verkeer van de load balancer van de gegevenslaag naar de virtuele machines in de gegevenslaag (SQL 1433) toestaan.
- Verkeer toestaan tussen virtuele machines in de gegevenslaag (SQL 1433)
Configureer eerst het SQL-patroon en herhaal het proces vervolgens met de resterende lagen. De volgende secties zijn de configuraties voor de regels die netwerkverkeer beperken voor één toepassingslaag.
Regel 5: Verkeer van virtuele machines in de app-laag toestaan naar de load balancer van de gegevenslaag (SQL 1433)
Navigeer in de netwerkbeveiligingsgroep voor het subnet van de app-laag naar Binnenkomende beveiligingsregels en selecteer Toevoegen. Vul de lijst in met het volgende:
- Bron: Toepassingsbeveiligingsgroep
- Beveiligingsgroepen voor brontoepassingen: Selecteer de beveiligingsgroep van uw bedrijfslaag
- Bronpoortbereiken: 1433 (soms kan bronverkeer afkomstig zijn van verschillende poorten en als dit patroon optreedt, kunt u bronpoortbereiken toevoegen aan * om een bronpoort toe te staan. Doelpoort is belangrijker en sommige aanbevelingen zijn om altijd * te gebruiken voor bronpoort)
- Doel: IP-adressen
- Doel-IP-adressen/CIDR-bereiken: het expliciete IP-adres van de load balancer
- U moet hier het expliciete IP-adres gebruiken omdat u een load balancer niet kunt koppelen aan een toepassingsbeveiligingsgroep.
- U kunt uw IP-schema plannen of de load balancer implementeren en verwijzen naar het IP-adres waaraan het is toegewezen.
- Service: MS SQL
- Doelpoortbereiken: Dit wordt automatisch ingevuld voor poort 1433
- Protocol: dit wordt automatisch geselecteerd voor TCP
- Actie: toestaan
- Prioriteit: Een waarde tussen 100 en 4096. U kunt beginnen met 105.
- Naam: Allow-App-Tier-to-Data-LB-Inbound
- Beschrijving: Hiermee staat u binnenkomende toegang vanuit de load balancer van de gegevenslaag toe naar de virtuele machines in de app-laag.
U ziet na voltooiing dat er een blauw pictogram is voor informatieve waarschuwingen op de regel. Als u op de regel klikt, wordt het volgende bericht weergegeven:
- 'Regels die toepassingsbeveiligingsgroepen gebruiken, kunnen alleen worden toegepast wanneer de toepassingsbeveiligingsgroepen zijn gekoppeld aan netwerkinterfaces in hetzelfde virtuele netwerk.'
Dit is een voorbeeld.
De regel is alleen van toepassing wanneer deze toepassingsbeveiligingsgroep in dit netwerk wordt gebruikt.
Ga ten slotte in dezelfde netwerkbeveiligingsgroep naar uitgaande beveiligingsregels en selecteer Toevoegen. Vul de lijst in zoals in het voorbeeld, waarbij Inkomend wordt gewijzigd in Uitgaand.
Regel 6: Verkeer van load balancer van gegevenslaag naar virtuele machines in de gegevenslaag toestaan (SQL 1433)
Navigeer in de netwerkbeveiligingsgroep voor het subnet van de gegevenslaag naar Binnenkomende beveiligingsregels en selecteer Toevoegen. Vul de lijst in met het volgende:
- Bron: IP-adres
- Bron-IP-adres: het IP-adres van de load balancer
- Bronpoortbereiken: 1433
- Bestemming: Toepassingsbeveiligingsgroep
- Beveiligingsgroepen voor doeltoepassingen: Selecteer uw toepassingsbeveiligingsgroep in de gegevenslaag
- Service: MS SQL
- Doelpoortbereiken: Dit wordt automatisch ingevuld voor poort 1433.
- Protocol: Dit wordt automatisch geselecteerd voor TCP.
- Actie: toestaan
- Prioriteit: Een waarde tussen 100 en 4096. U kunt beginnen met 105.
- Naam: Allow-SQL-LB-to-SQL-VMs-Inbound
- Beschrijving: Hiermee staat u binnenkomende toegang tot de virtuele machines in de sql-gegevenslaag toe vanuit de load balancer van de gegevenslaag.
Navigeer in dezelfde netwerkbeveiligingsgroep naar uitgaande beveiligingsregels en selecteer Toevoegen. Vul de lijst in zoals in het voorbeeld is uitgevoerd, waarbij inkomend wordt gewijzigd in Uitgaand.
Regel 7: verkeer toestaan tussen virtuele machines in de gegevenslaag (SQL 1433)
Navigeer in de netwerkbeveiligingsgroep voor het subnet van de gegevenslaag naar Binnenkomende beveiligingsregels en selecteer Toevoegen. Vul de lijst in met het volgende:
- Bron: Toepassingsbeveiligingsgroep
- Beveiligingsgroepen voor doeltoepassingen: Selecteer uw toepassingsbeveiligingsgroep in de gegevenslaag
- Bronpoortbereiken: 1433
- Bestemming: Toepassingsbeveiligingsgroepen
- Beveiligingsgroepen voor doeltoepassingen: Selecteer uw toepassingsbeveiligingsgroep in de gegevenslaag
- Service: MS SQL
- Doelpoortbereiken: Dit wordt automatisch ingevuld voor poort 1433.
- Protocol: Dit wordt automatisch geselecteerd voor TCP.
- Actie: toestaan
- Prioriteit: Een waarde tussen 100 en 4096. U kunt beginnen met 105.
- Naam: Allow-SQL-VM-to-SQL-VM-Inbound
- Beschrijving: Hiermee staat u binnenkomende toegang toe tussen virtuele machines in de SQL-gegevenslaag.
Navigeer in dezelfde netwerkbeveiligingsgroep naar uitgaande beveiligingsregels en selecteer Toevoegen. Vul de lijst in als de vorige lijst en wijzig inkomend in uitgaand verkeer.
Met deze drie regels hebt u het Zero Trust-verbindingspatroon gedefinieerd voor één toepassingslaag. U kunt dit proces herhalen zoals vereist voor extra stromen.
Beheerverkeer plannen in het VNet
Naast het toepassingsspecifieke verkeer moet u het beheerverkeer plannen. Beheerverkeer is echter meestal afkomstig van buiten het spoke-VNet. Er zijn aanvullende regels vereist. Eerst moet u de specifieke poorten en bronnen begrijpen waaruit het beheerverkeer afkomstig is. Over het algemeen moet al het beheerverkeer stromen van een firewall of andere NVA die zich in het hubnetwerk voor de spoke bevindt.
Raadpleeg de volledige referentiearchitectuur in het artikel Zero Trust toepassen op azure IaaS-overzichtsartikel .
Dit varieert op basis van uw specifieke beheerbehoeften. Regels op de firewallapparaten en -regels in de netwerkbeveiligingsgroep moeten echter worden gebruikt om expliciet verbindingen toe te staan aan zowel de platformnetwerkzijde als de netwerkzijde van de workload.
Stroomlogboekregistratie voor netwerkbeveiligingsgroepen implementeren
Zelfs als uw netwerkbeveiligingsgroep onnodig verkeer blokkeert, betekent dit niet dat aan uw doelstellingen wordt voldaan. U moet nog steeds het verkeer observeren dat zich buiten uw expliciete patronen voordoet, zodat u weet of er een aanval plaatsvindt.
Als u logboekregistratie van netwerkbeveiligingsgroepen wilt inschakelen, volgt u de zelfstudie: Netwerkverkeersstroom naar en van een virtuele machine vastleggen op basis van de bestaande netwerkbeveiligingsgroep die is gemaakt.
Notitie
- Het opslagaccount moet de richtlijnen van het Zero Trust-opslagaccount volgen.
- De toegang tot de logboeken moet zo nodig worden beperkt.
- Ze moeten zo nodig ook naar Log Analytics en Sentinel stromen.
Inkomend webverkeer beveiligen met IDPS
Naast de besturingselementen in uw virtuele spoke-netwerk kunt u ook een Azure Firewall gebruiken om extra inspectie toe te passen. Hoewel de functie Web Application Firewall voor Azure Front Door en Application Gateway verkeer inspecteert op veelvoorkomende webaanvallen, kan het gebruik van Azure Firewall een dieper inspectieniveau bieden.
Voor het gebruik van elk signaal dat beschikbaar is en centrale zichtbaarheid van netwerkverkeer wilt behouden, wordt het routeren van verkeer van uw Application Gateway naar Azure Firewall aanbevolen. Vervolgens kan het verkeer worden gecontroleerd op aanvullende signalen en wordt het gedrag in de logboeken vastgelegd. Meer informatie over deze configuratie vindt u in het artikel Zero-trust-netwerk voor webtoepassingen met Azure Firewall en Application Gateway. Zie Azure Firewall Premium configureren voor Zero Trust voor meer informatie over het instellen van dit gedrag.
Stap 6: Toegang tot het VNet en de toepassing beveiligen
Het beveiligen van de toegang tot het VNet en de toepassing omvat:
- Verkeer in de Azure-omgeving beveiligen naar de toepassing.
- Meervoudige verificatie en beleid voor voorwaardelijke toegang gebruiken voor gebruikerstoegang tot de toepassing.
In het volgende diagram ziet u beide toegangsmodi in de referentiearchitectuur.
Verkeer beveiligen binnen de Azure-omgeving voor het VNet en de toepassing
Veel van het werk van beveiligingsverkeer in de Azure-omgeving is al voltooid. Beveiligde verbindingen tussen opslagbronnen en de virtuele machines worden geconfigureerd in Zero Trust-principes toepassen op Azure-opslag.
Zie Zero Trust-principes toepassen op een virtueel hubnetwerk in Azure om de toegang van hubbronnen tot het VNet te beveiligen.
Meervoudige verificatie en beleid voor voorwaardelijke toegang gebruiken voor gebruikerstoegang tot de toepassing
Het artikel: Zero Trust-principes toepassen op virtuele machines raadt aan om toegangsaanvragen rechtstreeks te beveiligen voor virtuele machines met meervoudige verificatie en voorwaardelijke toegang. Deze aanvragen zijn waarschijnlijk afkomstig van beheerders en ontwikkelaars. De volgende stap is het beveiligen van toegang tot de toepassing met meervoudige verificatie en voorwaardelijke toegang. Dit geldt voor alle gebruikers die toegang hebben tot de app.
Als de toepassing nog niet is geïntegreerd met Microsoft Entra ID, raadpleegt u eerst Toepassingstypen voor het Microsoft Identity Platform.
Voeg vervolgens de toepassing toe aan het bereik van uw identiteits- en apparaattoegangsbeleid.
Wanneer u meervoudige verificatie configureert met voorwaardelijke toegang en gerelateerd beleid, gebruikt u de aanbevolen beleidsset voor Zero Trust als richtlijn. Dit omvat beleidsregels voor het 'beginpunt' waarvoor het beheer van apparaten niet is vereist. In het ideale voorbeeld worden de apparaten die toegang hebben tot uw virtuele machines beheerd en kunt u het niveau Enterprise implementeren. Dit wordt aanbevolen voor Zero Trust. Zie Common Zero Trust-identiteits- en apparaattoegangsbeleid voor meer informatie.
In het volgende diagram ziet u de aanbevolen beleidsregels voor Zero Trust.
Stap 7: Geavanceerde detectie en beveiliging van bedreigingen inschakelen
Uw spoke-VNet dat is gebouwd op Azure, is mogelijk al beveiligd door Microsoft Defender voor Cloud (MDC) omdat andere resources uit uw IT-bedrijfsomgeving die wordt uitgevoerd in Azure of on-premises ook worden beveiligd.
Zoals vermeld in de andere artikelen uit deze reeks, is Microsoft Defender voor Cloud een hulpprogramma voor cloudbeveiligingspostuurbeheer (CSPM) en CWP (Cloud Workload Protection) dat beveiligingsaanaanbieding, waarschuwingen en geavanceerde functies zoals Adaptive Network Hardening biedt om u te helpen bij de voortgang van uw cloudbeveiligingstraject. Als u beter wilt visualiseren waar Defender voor Cloud past in het grotere Microsoft-beveiligingslandschap, raadpleegt u Microsoft Cybersecurity Reference Architectures.
In dit artikel wordt niet in detail Microsoft Defender voor Cloud besproken, maar het is belangrijk om te begrijpen dat Microsoft Defender voor Cloud werkt op basis van Azure-beleid en logboeken die zijn opgenomen in een Log Analytics-werkruimte. Zodra dit is ingeschakeld voor de abonnementen met uw spoke-VNet en de bijbehorende resources, kunt u aanbevelingen zien om hun beveiligingspostuur te verbeteren. U kunt deze aanbevelingen verder filteren op MITRE-tactiek, resourcegroep, enzovoort. Overweeg de oplossing van aanbevelingen die een grotere impact hebben op de beveiligingsscore van uw organisatie te prioriteren.
Hier volgt een voorbeeld in de Microsoft Defender voor Cloud-portal.
Als u ervoor kiest om een van de Defender voor Cloud-abonnementen te onboarden die Geavanceerde workloadbeveiligingen bieden, bevat het adaptieve aanbevelingen voor netwerkbeveiliging om uw bestaande regels voor netwerkbeveiligingsgroepen te verbeteren. Dit is een voorbeeld.
U kunt de aanbeveling accepteren door Afdwingen te selecteren. Hiermee maakt u een nieuwe regel voor netwerkbeveiligingsgroepen of wijzigt u een bestaande regel.
Aanbevolen training
- Uw Azure-resources beveiligen met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)
- Azure Monitor configureren en beheren
- Netwerkbeveiligingsgroepen configureren
- Netwerkbeveiliging ontwerpen en implementeren
- Toegang tot uw toepassingen beveiligen met behulp van Azure Identity Services
Zie deze resources in de Microsoft-catalogus voor meer training over beveiliging in Azure:
Beveiliging in Azure | Microsoft Learn
Volgende stappen
Zie deze aanvullende artikelen voor het toepassen van Zero Trust-principes op Azure:
- Overzicht van Azure IaaS
- Azure Virtual Desktop
- Azure Virtual WAN
- IaaS-toepassingen in Amazon Web Services
- Microsoft Sentinel en Microsoft Defender XDR
Technische illustraties
Deze poster biedt in één oogopslag een overzicht van de onderdelen van Azure IaaS als referentie- en logische architecturen, samen met de stappen om ervoor te zorgen dat voor deze onderdelen de principes 'nooit vertrouwen, altijd verifiëren' van het Zero Trust-model worden toegepast.
| Item | Beschrijving |
|---|---|
 PDF | Visio Bijgewerkt in maart 2024 |
Gebruik deze afbeelding samen met dit artikel: Zero Trust-principes toepassen op azure IaaS-overzicht Verwante oplossingsgidsen |
Deze poster bevat de referentie- en logische architecturen en de gedetailleerde configuraties van de afzonderlijke onderdelen van Zero Trust voor Azure IaaS. Gebruik de pagina's van deze poster voor afzonderlijke IT-afdelingen of specialiteiten of pas met de Microsoft Visio-versie van het bestand de diagrammen voor uw infrastructuur aan.
| Item | Beschrijving |
|---|---|
 PDF | Visio Bijgewerkt in maart 2024 |
Gebruik deze diagrammen samen met de artikelen die hier beginnen: Zero Trust-principes toepassen op azure IaaS-overzicht Verwante oplossingsgidsen |
Klik hier voor aanvullende technische illustraties.