Zero Trust-principes toepassen op een virtueel spoke-netwerk met Azure PaaS-services

  • Artikel

Dit artikel helpt u de principes van het Zero Trust-beveiligingsmodel toe te passen op een PaaS-workload met behulp van virtuele Azure-netwerken (VNets) en privé-eindpunten 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 bedreigingsdetectie in Azure Firewall en Azure-toepassing Gateway om verkeer te valideren en om te controleren of het verkeer acceptabel is.
Toegang met minimale bevoegdheden gebruiken Beperk gebruikerstoegang met Just-In-Time en Just-Enough-Access (JIT/JEA), op risico gebaseerd adaptief beleid en gegevensbeveiliging. Verminder inkomend verkeer naar en uitgaand verkeer van Azure-services naar uw privénetwerk. Gebruik netwerkbeveiligingsgroepen om alleen specifieke toegangsbeheerobjecten vanuit uw VNet toe te staan. Gebruik een centraal Azure Firewall-exemplaar om verkeer zonder VNet-verkeer toegang te verlenen tot de Azure-service.
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 aanmeldt bij netwerkbeveiligingsgroepen en dat u goed inzicht hebt in afwijkend verkeer. Wijzigingen in netwerkbeveiligingsgroepen bijhouden.

Zie het overzicht Zero Trust toepassen op Azure IaaS voor meer informatie over het toepassen van de principes van Zero Trust in een Azure IaaS-omgeving.

Zero Trust zelfstandig of spoke-netwerk voor Azure PaaS-services

Veel PaaS-services bevatten hun eigen functionaliteit voor inkomend en uitgaand verkeer. U kunt deze besturingselementen gebruiken om netwerktoegang tot PaaS-servicebronnen te beveiligen zonder dat hiervoor infrastructuur nodig is, zoals VNets. Voorbeeld:

  • Azure SQL Database heeft een eigen firewall die kan worden gebruikt om specifieke CLIENT-IP-adressen toe te staan die toegang nodig hebben tot de databaseserver.
  • Azure-opslagaccounts hebben een configuratieoptie waarmee verbindingen vanuit een specifiek VNet worden toegestaan of dat openbare netwerktoegang wordt geblokkeerd.
  • Azure-app Service ondersteunt toegangsbeperkingen voor het definiëren van een lijst met toegestane/weigeringen op basis van prioriteit waarmee de netwerktoegang tot uw app wordt bepaald.

Voor begeleide implementaties van Zero Trust zijn deze systeemeigen toegangscontroles echter vaak niet voldoende. Hierdoor ontstaat een verspreiding van toegangsbeheer en logboekregistratie die het beheer kunnen vergroten en de zichtbaarheid kunnen verminderen.

Daarnaast kunnen PaaS-services FQDN's (Fully Qualified Domain Names) gebruiken die worden omgezet in een dynamisch toegewezen openbaar IP-adres dat wordt toegewezen vanuit een groep openbare IP-adressen in een specifieke regio voor een type service. Hierdoor kunt u geen verkeer van of naar een specifieke PaaS-service toestaan met behulp van hun openbare IP-adres, wat kan veranderen.

Microsoft raadt u aan privé-eindpunten te gebruiken. Een privé-eindpunt is een VNet-interface die gebruikmaakt van een privé-IP-adres van uw VNet. Deze netwerkinterface maakt privé en op een veilige manier verbinding met een service die door Azure Private Link mogelijk wordt gemaakt. Door een privé-eindpunt in te schakelen, brengt u de service naar uw VNet.

Afhankelijk van uw oplossingsscenario hebt u mogelijk nog steeds openbare inkomende toegang tot uw PaaS-services nodig. Maar tenzij u dat doet, raadt Microsoft aan dat al het verkeer privé blijft om potentiële beveiligingsrisico's te elimineren.

Deze handleiding bevat instructies voor een specifieke referentiearchitectuur, maar de principes en methoden kunnen indien nodig worden toegepast op andere architecturen.

Referentiearchitectuur

In het volgende diagram ziet u een algemene referentiearchitectuur voor op PaaS gebaseerde workloads.

Diagram van de referentiearchitectuur voor op PaaS gebaseerde workloads.

In het diagram:

  • Een spoke-VNet bevat onderdelen ter ondersteuning van een PaaS-toepassing.
  • De PaaS-toepassing is een toepassing met twee lagen die gebruikmaakt van Azure-toepassing Services voor een web-app/front-end en een Azure SQL Database voor relationele databases.
  • Elke laag bevindt zich in een toegewezen subnet voor inkomend verkeer met een toegewezen netwerkbeveiligingsgroep.
  • De weblaag bevat een toegewezen subnet voor uitgaand verkeer.
  • Toegang tot de toepassing wordt geboden via een Application Gateway in een eigen subnet.

In het volgende diagram ziet u de logische architectuur van deze onderdelen binnen een Azure-abonnement.

Diagram van onderdelen binnen een Azure-abonnement.

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 (met de naam NSG in het diagram) voor de database-, toepassings- en front-endlagen
  • Twee toepassingsbeveiligingsgroepen (met de naam ASG in het diagram)
  • Twee privé-eindpunten

Daarnaast worden resources voor het hub-VNet geïmplementeerd in het juiste connectiviteitsabonnement.

Wat staat er in dit artikel?

Zero Trust-principes worden toegepast in de architectuur, van tenant- en directoryniveau tot de toewijzing van VM's aan toepassingsbeveiligingsgroepen. In de volgende tabel worden de aanbevelingen voor het beveiligen van deze architectuur beschreven.

Stap Taak
1 Maak gebruik van Microsoft Entra RBAC of stel aangepaste rollen in voor netwerkresources.
2 De infrastructuur isoleren in een eigen resourcegroep.
3 Maak een netwerkbeveiligingsgroep voor elk subnet.
4 Verkeer en resources in het VNet beveiligen:
  • Implementeer basislijnregels voor weigeren voor netwerkbeveiligingsgroepen.
  • Plan het beheerverkeer naar het VNet.
  • Stroomlogboekregistratie voor netwerkbeveiligingsgroepen implementeren.
5 Beveilig inkomend en uitgaand verkeer voor Azure PaaS-services.
6 Beveiligde toegang tot het VNet en de toepassing.
7 Geavanceerde detectie van bedreigingen, waarschuwingen en beveiliging inschakelen.

In deze handleiding wordt ervan uitgegaan dat u al een Azure-toepassing Service en Azure SQL Database hebt geïmplementeerd in hun eigen resourcegroepen.

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 om aangepaste rollen te gebruiken. Spoke-VNet-netwerkbeheerders hebben geen volledige toegang nodig tot netwerkresources die zijn verleend door de rol Microsoft Entra RBAC-netwerkbijdrager, maar hebben meer machtigingen nodig dan andere algemene rollen. Een aangepaste rol kan worden gebruikt om alleen toegang te krijgen tot wat 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 die kan worden gebruikt, is de aangepaste rol Netwerkbeheer , die de volgende machtigingen heeft:

  • Alles lezen in het bereik
  • Acties met de netwerkprovider
  • Acties met de ondersteuningsprovider
  • Acties met de resourceprovider

Deze rol kan worden gemaakt met behulp van de scripts in de GitHub-opslagplaats azure Landing Zone Reference Architecture of kan worden gemaakt via Microsoft Entra ID met aangepaste Azure-rollen.

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 de spoke-netwerkresources beschikbaar te maken in meerdere contexten in een gedeelde resourcegroep, maakt u een toegewezen resourcegroep. In het volgende architectuurdiagram ziet u deze configuratie.

Diagram van het isoleren van infrastructuur in een eigen resourcegroep.

In het diagram worden resources en onderdelen in de referentiearchitectuur onderverdeeld in toegewezen resourcegroepen voor toepassingsservices, Azure SQL-databases, opslagaccounts, hub-VNet-resources en spoke-VNet-resources.

Met een toegewezen resourcegroep kunt u een aangepaste rol toewijzen met behulp van de zelfstudie Een gebruiker toegang verlenen tot Azure-resources.

Aanvullende aanbevelingen:

  • Verwijs naar een beveiligingsgroep voor de rol in plaats van benoemde personen.
  • Beheer de toegang tot de beveiligingsgroep via uw bedrijfsidentiteitsbeheerprocedures.

Als u geen beleid gebruikt waarmee het doorsturen van logboeken voor resourcegroepen wordt afgedwongen, configureert u dit in het activiteitenlogboek voor de resourcegroep:

  1. Zoek de resourcegroep in Azure Portal.
  2. Navigeer naar activiteitenlogboek -> Activiteitenlogboeken exporteren en selecteer vervolgens + Diagnostische instelling toevoegen.
  3. 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. Hier volgt een voorbeeld:

Voorbeeld van de diagnostische instelling.

Zie Diagnostische Instellingen voor meer informatie over het controleren van deze logboeken en waarschuwingen.

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 de ontwerpprincipes voor de Azure-landingszone voor meer informatie.

Stap 3: Een netwerkbeveiligingsgroep maken voor elk subnet

Azure-netwerkbeveiligingsgroepen worden gebruikt om netwerkverkeer tussen Azure-resources in een Azure-VNet te filteren. Het wordt aanbevolen om een netwerkbeveiligingsgroep toe te passen op elk subnet. Dit wordt standaard afgedwongen via Azure-beleid 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 bron- en doel-IP-adressen, een protocol (zoals TCP of UDP) en een poort opgeven.

Voor toepassingen met meerdere lagen wordt aangeraden een toegewezen netwerkbeveiligingsgroep ('NSG' in het volgende diagram) te maken voor elk subnet dat als host fungeert voor een netwerkonderdeel.

Diagram van toegewezen netwerkbeveiligingsgroepen voor elk subnet.

In het diagram:

  • Elke laag van de toepassing heeft een toegewezen inkomend subnet, zoals een voor de weblaag en een andere voor de gegevenslaag.
  • Azure-toepassing Services heeft een toegewezen uitgaand subnet voor een specifieke toepassingsservice.
  • Voor elk van deze subnetten wordt een netwerkbeveiligingsgroep geconfigureerd.

Het configureren van netwerkbeveiligingsgroepen op een andere manier dan in het diagram 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.

Zie Een Azure-netwerkbeveiligingsgroep maken, wijzigen of verwijderen om de instellingen van uw netwerkbeveiligingsgroepen te beheren.

Lees meer over netwerkbeveiligingsgroepen om te begrijpen hoe ze kunnen worden gebruikt om uw omgevingen te beveiligen.

Stap 4: Verkeer en resources binnen het VNet beveiligen

In deze sectie worden de volgende aanbevelingen beschreven:

  • Regels voor weigeren volgens basislijn implementeren voor netwerkbeveiligingsgroepen
  • Toepassingsspecifieke regels implementeren
  • 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 voor toestaan . 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 toegestane acties te configureren.

Hiervoor gaat u in de netwerkbeveiligingsgroep naar Uitgaande beveiligingsregels en selecteert u 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.

Voorbeeld van uitgaande beveiligingsregels.

Herhaal dit proces met regels voor inkomend verkeer, waarbij u de naam en beschrijving zo nodig aanpast.

Op het tabblad Inkomende beveiligingsregels wordt een waarschuwingsmelding weergegeven op de regel. Dit is een voorbeeld.

Voorbeeld van binnenkomende beveiligingsregels.

Klik op de regel en schuif naar beneden om meer details weer te geven. Hier volgt een voorbeeld:

Voorbeeld van regeldetails.

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. Maak voor elk verkeerspatroon expliciet een regel die dit toestaat. U moet dit doen met de minste hoeveelheid machtigingen.

Als u 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

Notitie

De aanbevelingen in deze sectie zijn alleen van toepassing op het web-uitgaande subnet.

Als u Azure Firewall gebruikt om uw uitgaande verbindingen te beheren, kunt u in plaats van weigeren uitgaande verbindingen alternatieve regels voor uitgaande verbindingen maken. Als onderdeel van de Azure Firewall-implementatie stelt u een routetabel in waarmee standaardrouteverkeer (0.0.0.0/0) naar de firewall wordt verzonden. Hiermee wordt verkeer buiten het VNet verwerkt.

Vervolgens kunt u een regel voor het weigeren van alle uitgaande VNet's maken of een regel voor uitgaand verkeer toestaan, maar items beveiligen met hun inkomende regels.

Zie Azure Firewall - en routetabellen om te begrijpen hoe ze kunnen worden gebruikt om de beveiliging van de omgeving verder te verbeteren.

Toepassingsspecifieke regels implementeren

Definieer verkeerspatronen met de minste hoeveelheid machtigingen en volg alleen expliciet toegestane paden. Met behulp van subnetten als bronnen definieert u netwerkpatronen in de netwerkbeveiligingsgroepen. Dit is een voorbeeld.

Diagram van netwerkpatronen in netwerkbeveiligingsgroepen.

Gebruik de netwerkbeveiligingsgroepen beheren: maak een beveiligingsregelproces om regels toe te voegen aan uw netwerkbeveiligingsgroepen.

Voeg de volgende regels toe om dit scenario te beveiligen:

Netwerkbeveiligingsgroep voor subnet Richting Bron Brondetails Bronpoort Doel Doeldetails Service Naam van netwerkbeveiligingsgroep Beschrijving van netwerkbeveiligingsgroep
App Service-subnet Inkomend IP-adressen Het privé-IP-adresbereik van uw toepassingsgatewaysubnet 443 IP-adressen Het expliciete IP-adres van het privé-eindpunt van uw App Service MS SQL AllowGWtoAppInbound Hiermee staat u binnenkomende toegang tot de App Service vanuit de Application Gateway toe.
Subnet voor App Service-integratie Uitgaand IP-adressen Het IP-adresbereik van uw App Service-integratiesubnet 1433 IP-adressen Het expliciete IP-adres van het privé-eindpunt van uw SQL DB MS SQL AllowApptoSQLDBOutbound Hiermee staat u uitgaande toegang tot het privé-EINDPUNT van SQL toe vanuit het App Service Integration-subnet.
Azure SQL-subnet Inkomend IP-adressen Het IP-adresbereik van uw App Service-integratiesubnet 1433 IP-adressen Het expliciete IP-adres van het privé-eindpunt van uw SQL DB MS SQL AllowApptoSQLDBInbound Hiermee staat u binnenkomende toegang tot het privé-EINDPUNT van SQL toe vanuit het Subnet van App Service-integratie.

Notitie

Soms kan bronverkeer afkomstig zijn van verschillende poorten en als dit patroon optreedt, kunt u bronpoortbereiken toevoegen aan '*' om een bronpoort toe te staan. De doelpoort is belangrijker en sommige aanbevelingen zijn om altijd '*' te gebruiken voor de bronpoort.

Notitie

Gebruik voor prioriteit een waarde tussen 100 en 4000. U kunt beginnen bij 105.

Dit is een aanvulling op de regels voor netwerkbeveiligingsgroepen in uw Application Gateway-subnet.

Met deze 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. Omdat beheerverkeer doorgaans buiten het spoke-VNet afkomstig is, zijn er echter meer regels vereist. Begrijp eerst de specifieke poorten en bronnen waaruit het beheerverkeer afkomstig is. Normaal gesproken moet al het beheerverkeer stromen van een firewall of een ander virtueel netwerkapparaat (NVA) dat zich in het hubnetwerk voor de spoke bevindt.

Zie Het overzicht van Zero Trust toepassen op Azure IaaS voor de volledige referentiearchitectuur.

Uw configuratie varieert op basis van uw specifieke beheerbehoeften. U moet echter regels gebruiken voor firewallapparaten en regels in de netwerkbeveiligingsgroep om verbindingen expliciet toe te staan aan zowel de platformnetwerk- als workloadnetwerknetwerkzijde.

Implementaties plannen

Omdat uw toepassingsservices en -databases nu gebruikmaken van privénetwerken, moet u plannen hoe code- en gegevensimplementaties voor deze resources werken. Voeg regels toe om uw privé-buildservers toegang te geven tot deze eindpunten.

Stroomlogboekregistratie voor netwerkbeveiligingsgroepen implementeren

Zelfs als uw netwerkbeveiligingsgroep onnodig verkeer blokkeert, betekent dit niet dat aan uw doelstellingen wordt voldaan. Als u een aanval wilt detecteren, moet u nog steeds het verkeer observeren dat zich buiten uw expliciete patronen bevindt.

Het verkeer naar de privé-eindpunten wordt niet geregistreerd, maar als andere services later worden geïmplementeerd in de subnetten, helpt dit logboek bij het detecteren van de activiteiten.

Als u logboekregistratie van netwerkbeveiligingsgroepen wilt inschakelen, volgt u de zelfstudie: Netwerkverkeersstroom naar en van een virtuele machine voor de bestaande netwerkbeveiligingsgroep voor de privé-eindpunten vastleggen.

Notitie

Houd rekening met deze aanbevelingen:

  • U moet de toegang tot de logboeken zo nodig beperken.

  • Logboeken moeten naar behoefte naar Log Analytics en Microsoft Sentinel stromen.

Stap 5: Inkomend en uitgaand verkeer beveiligen voor Azure PaaS-services

Deze sectie bevat twee stappen die nodig zijn om inkomend en uitgaand verkeer voor uw PaaS-services te beveiligen:

  • Implementeer privé-eindpunten voor inkomend verkeer naar uw services.
  • Implementeer VNet-integratie zodat uw toepassingsservice kan communiceren met uw VNet.

Daarnaast moet u ook rekening houden met uw DNS-configuratie om de omzetting van namen toe te staan.

Privé-eindpunten implementeren voor inkomend verkeer

Hoewel u met veel services privé-eindpunten kunt maken op basis van de resourcespecifieke blade in Azure Portal, is het een consistentere ervaring om een privé-eindpunt te maken op basis van het maken van een eigen resource. Hiervoor moeten resources al worden geïmplementeerd. Zodra de implementatie is uitgevoerd, kunt u het privé-eindpunt maken.

Wanneer u de privé-eindpunten implementeert, configureert u deze als volgt:

  • Plaats ze in de specifieke resourcegroep die de bovenliggende resources bevat om resources met een vergelijkbare levenscyclus samen te houden en centrale toegang te bieden.
  • Plaats ze in het juiste subnet in het VNet op basis van hun rol.
  • Voor de Azure-toepassing-service kunt u privé-eindpunten configureren voor zowel de normale front-end als het SCM-eindpunt, dat wordt gebruikt voor implementaties en beheer.

Als onderdeel van deze implementatie moet u er ook voor zorgen dat de servicespecifieke firewall is ingesteld om binnenkomend verkeer te weigeren. Hiermee worden pogingen bij openbaar inkomend verkeer geweigerd.

Voor de Azure SQL-database beheert u de IP-firewallregels op serverniveau. Zorg ervoor dat openbare netwerktoegang is ingesteld op Uitschakelen vanuit het netwerkpaneel in Azure Portal.

Voor de Azure-toepassing Service stelt het toevoegen van het privé-eindpunt de firewall op serviceniveau in om binnenkomende toegang standaard te blokkeren. Zie Privé-eindpunten gebruiken voor App Service-apps voor meer informatie.

VNet-integratie implementeren voor uitgaand verkeer

Naast de privé-eindpunten voor inkomend verkeer, schakelt u VNet-integratie in. Voor elk App Service-plan kan VNet-integratie zijn ingeschakeld. Hierdoor wordt een heel subnet voor de App Service toegewezen. Zie Uw app integreren met een Azure-VNet voor meer informatie.

Zie VNet-integratie inschakelen in Azure-app Service om uw App Service te configureren. Zorg ervoor dat u het in uw subnet plaatst dat is aangewezen voor uitgaand verkeer.

DNS-overwegingen

Als onderdeel van het gebruik van privé-eindpunten schakelt u DNS-omzetting van de FQDN's van de resources in op hun nieuwe privé-IP-adressen. Zie DNS-configuratie voor privé-eindpunten voor instructies om dit op verschillende manieren te implementeren.

Notitie

DNS-omzetting moet van toepassing zijn op al het verkeer. Resources in hetzelfde VNet kunnen alleen worden omgezet als ze de juiste DNS-zones gebruiken.

Stap 6: Toegang tot het VNet en de toepassing beveiligen

Het beveiligen van de toegang tot het VNet en toepassingen zijn onder andere:

  • Verkeer beveiligen binnen de Azure-omgeving naar de toepassing
  • Meervoudige verificatie (MFA) en beleid voor voorwaardelijke toegang gebruiken voor gebruikerstoegang tot toepassingen.

In het volgende diagram ziet u beide toegangsmodi in de referentiearchitectuur.

Diagram van 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. Zie Zero Trust-principes toepassen op Azure Storage om beveiligde verbindingen tussen opslagbronnen en de VM's te configureren.

Zie Zero Trust-principes toepassen op een hub-VNet in Azure om de toegang van hubbronnen tot het VNet te beveiligen.

MFA- en beleid voor voorwaardelijke toegang gebruiken voor gebruikerstoegang tot toepassingen

In het artikel Zero Trust toepassen op virtuele machines wordt aanbevolen hoe u toegangsaanvragen rechtstreeks kunt beveiligen voor VM's met MFA en voorwaardelijke toegang. Deze aanvragen zijn waarschijnlijk afkomstig van beheerders en ontwikkelaars. De volgende stap is het beveiligen van toegang tot toepassingen met MFA en voorwaardelijke toegang. Dit geldt voor alle gebruikers die toegang hebben tot de toepassing.

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 MFA configureert met beleid voor voorwaardelijke toegang en gerelateerd beleid, gebruikt u de aanbevolen beleidsset voor Zero Trust als richtlijn. Dit omvat beleidsregels voor uitgangspunten waarvoor het beheer van apparaten niet is vereist. In het ideale voorbeeld worden de apparaten die toegang hebben tot uw VM's beheerd en kunt u het enterprise-niveau 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.

Diagram van aanbevolen beleidsregels voor identiteit en apparaattoegang voor Zero Trust.

Stap 7: Geavanceerde detectie en beveiliging van bedreigingen inschakelen

Uw spoke-VNet dat is gebouwd op Azure, kan worden beveiligd door Microsoft Defender voor Cloud omdat andere resources uit uw IT-bedrijfsomgeving die in Azure of on-premises worden uitgevoerd, ook worden beveiligd.

Zoals vermeld in de andere artikelen uit deze reeks, is Defender voor Cloud een CSPM-hulpprogramma (Cloud Security Posture Management) en CWP (Cloud Workload Protection) dat aanbevelingen voor beveiliging, waarschuwingen en geavanceerde functies biedt, zoals adaptieve netwerkbeveiliging, om u te helpen bij de voortgang van uw cloudbeveiligingstraject.

In dit artikel wordt Defender voor Cloud niet gedetailleerd beschreven, maar het is belangrijk om te begrijpen dat Defender voor Cloud werkt op basis van Azure-beleid en logboeken die zijn opgenomen in een Log Analytics-werkruimte. Zodra de abonnementen zijn ingeschakeld 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 en andere. Overweeg prioriteit te geven aan het oplossen van aanbevelingen die een grotere invloed hebben op de beveiligingsscore van uw organisatie. Dit is een voorbeeld.

Voorbeeld van Microsoft Defender voor Cloud aanbevelingen.

Er zijn Defender voor Cloud plannen die geavanceerde workloadbeveiliging bieden met aanbevelingen voor adaptieve netwerkbeveiliging om uw bestaande regels voor netwerkbeveiligingsgroepen te verbeteren. Dit is een voorbeeld.

Voorbeeld van aanbevelingen voor netwerkbeveiliging.

U kunt de aanbeveling accepteren door Afdwingen te selecteren. Hiermee maakt u een nieuwe regel voor netwerkbeveiligingsgroepen of wijzigt u een bestaande regel.

Volgende stappen

Zie deze aanvullende artikelen voor het toepassen van Zero Trust-principes op Azure:

Verwijzingen