Aanbevelingen voor het bouwen van een segmentatiestrategie
Is van toepassing op aanbeveling van Well-Architected Framework Security-controlelijst:
| SE:04 | Maak opzettelijke segmentatie en perimeters in uw architectuurontwerp en de footprint van de workload op het platform. De segmentatiestrategie moet netwerken, rollen en verantwoordelijkheden, workloadidentiteiten en resourceorganisatie omvatten. |
|---|
Een segment is een logisch gedeelte van uw oplossing dat als één eenheid moet worden beveiligd. Een segmentatiestrategie definieert hoe een eenheid moet worden gescheiden van andere eenheden met een eigen set beveiligingsvereisten en -maatregelen.
In deze handleiding worden de aanbevelingen beschreven voor het bouwen van een uniforme segmentatiestrategie. Met behulp van perimeters en isolatiegrenzen in workloads kunt u een beveiligingsbenadering ontwerpen die voor u werkt.
Definities
| Termijn | Definitie |
|---|---|
| Containment | Een techniek om de straal in te houden als een aanvaller toegang krijgt tot een segment. |
| Toegang met minimale bevoegdheden | Een Zero Trust principe dat gericht is op het minimaliseren van een set machtigingen voor het voltooien van een taakfunctie. |
| Perimeter | De vertrouwensgrens rond een segment. |
| Organisatie van resources | Een strategie om gerelateerde resources te groeperen op stromen binnen een segment. |
| Rol | Een set machtigingen die nodig zijn om een taakfunctie te voltooien. |
| Segment | Een logische eenheid die is geïsoleerd van andere entiteiten en wordt beschermd door een set beveiligingsmaatregelen. |
Belangrijke ontwerpstrategieën
Het concept van segmentatie wordt vaak gebruikt voor netwerken. Hetzelfde onderliggende principe kan echter overal in een oplossing worden gebruikt, inclusief het segmenteren van resources voor beheerdoeleinden en toegangsbeheer.
Met segmentatie kunt u een beveiligingsbenadering ontwerpen die diepgaande verdediging toepast op basis van de principes van het Zero Trust-model. Zorg ervoor dat een aanvaller die het ene netwerksegment schendt, geen toegang kan krijgen tot een ander netwerksegment door workloads te segmenteren met verschillende identiteitsbesturingselementen. In een beveiligd systeem blokkeren identiteits- en netwerkkenmerken onbevoegde toegang en verbergen ze de assets zodat ze niet beschikbaar worden gesteld. Hier volgen enkele voorbeelden van segmenten:
- Abonnementen die workloads van een organisatie isoleren
- Resourcegroepen die workloadassets isoleren
- Implementatieomgevingen die implementaties in fasen isoleren
- Teams en rollen die functiefuncties isoleren met betrekking tot de ontwikkeling en het beheer van workloads
- Toepassingslagen die isoleren op workloadhulpprogramma
- Microservices die de ene service van de andere isoleren
Houd rekening met deze belangrijke elementen van segmentatie om ervoor te zorgen dat u een uitgebreide strategie voor diepgaande verdediging bouwt:
De grens of perimeter is de ingangsrand van een segment waar u beveiligingsbesturingselementen toepast. Perimeterbesturingselementen moeten de toegang tot het segment blokkeren, tenzij expliciet is toegestaan. Het doel is om te voorkomen dat een aanvaller de perimeter doorbreekt en de controle over het systeem krijgt. Een toepassingslaag kan bijvoorbeeld het toegangstoken van een eindgebruiker accepteren wanneer deze een aanvraag verwerkt. Maar voor de gegevenslaag is mogelijk een ander toegangstoken vereist met een specifieke machtiging, die alleen de toepassingslaag kan aanvragen.
Containment is de afsluitrand van een segment dat laterale verplaatsing in het systeem voorkomt. Het doel van insluiting is om het effect van een inbreuk te minimaliseren. Een virtueel Azure-netwerk kan bijvoorbeeld worden gebruikt voor het configureren van routerings- en netwerkbeveiligingsgroepen om alleen verkeerspatronen toe te staan die u verwacht, waardoor verkeer naar willekeurige netwerksegmenten wordt vermeden.
Isolatie is de praktijk van het groeperen van entiteiten met vergelijkbare garanties om ze te beschermen met een grens. Het doel is eenvoudig beheer en de beheersing van een aanval binnen een omgeving. U kunt bijvoorbeeld de resources die betrekking hebben op een specifieke workload in één Azure-abonnement groepeer en vervolgens toegangsbeheer toepassen, zodat alleen specifieke workloadteams toegang hebben tot het abonnement.
Het is belangrijk om het onderscheid tussen perimeters en isolatie te noteren. Perimeter verwijst naar de locatiepunten die moeten worden gecontroleerd. Isolatie gaat over groeperen. Een aanval actief in de hand houden door deze concepten samen te gebruiken.
Isolatie betekent niet het maken van silo's in de organisatie. Een uniforme segmentatiestrategie zorgt voor afstemming tussen de technische teams en stelt duidelijke verantwoordelijkheidslijnen vast. Clarity vermindert het risico op menselijke fouten en automatiseringsfouten die kunnen leiden tot beveiligingsproblemen, operationele downtime of beide. Stel dat er een beveiligingsschending is gedetecteerd in een onderdeel van een complex bedrijfssysteem. Het is belangrijk dat iedereen begrijpt wie verantwoordelijk is voor die resource, zodat de juiste persoon wordt opgenomen in het triageteam. De organisatie en belanghebbenden kunnen snel bepalen hoe op verschillende soorten incidenten moet worden gereageerd door een goede segmentatiestrategie te maken en te documenteren.
Afweging: Segmentatie introduceert complexiteit omdat er sprake is van overhead in het beheer. Er is ook een afweging in de kosten. Er worden bijvoorbeeld meer resources ingericht wanneer implementatieomgevingen die naast elkaar worden uitgevoerd, worden gesegmenteerd.
Risico: Microsegmentatie boven een redelijke limiet verliest het voordeel van isolatie. Wanneer u te veel segmenten maakt, wordt het lastig om communicatiepunten te identificeren of geldige communicatiepaden binnen het segment toe te staan.
De identiteit als de perimeter
Verschillende identiteiten, zoals personen, softwareonderdelen of apparaten, hebben toegang tot workloadsegmenten. Identiteit is een perimeter die de primaire verdedigingslinie moet zijn voor het verifiëren en autoriseren van toegang over isolatiegrenzen heen, ongeacht waar de toegangsaanvraag vandaan komt. Gebruik identiteit als perimeter om het volgende te doen:
Toegang toewijzen per rol. Identiteiten hebben alleen toegang nodig tot de segmenten die nodig zijn om hun werk te doen. Minimaliseer anonieme toegang door inzicht te krijgen in de rollen en verantwoordelijkheden van de aanvragende identiteit, zodat u weet welke entiteit toegang tot een segment aanvraagt en met welk doel.
Een identiteit kan verschillende toegangsbereiken hebben in verschillende segmenten. Overweeg een typische omgevingsinstelling, met afzonderlijke segmenten voor elke fase. Identiteiten die zijn gekoppeld aan de ontwikkelaarsrol hebben lees-schrijftoegang tot de ontwikkelomgeving. Naarmate de implementatie wordt verplaatst naar fasering, worden deze machtigingen beperkt. Tegen de tijd dat de workload wordt gepromoveerd naar productie, is het bereik voor ontwikkelaars beperkt tot alleen-lezentoegang.
Overweeg toepassings- en beheeridentiteiten afzonderlijk. In de meeste oplossingen hebben gebruikers een ander toegangsniveau dan ontwikkelaars of operators. In sommige toepassingen kunt u verschillende identiteitssystemen of mappen gebruiken voor elk type identiteit. Overweeg het gebruik van toegangsbereiken en het maken van afzonderlijke rollen voor elke identiteit.
Wijs toegang met minimale bevoegdheden toe. Als de identiteit toegang heeft, bepaalt u het toegangsniveau. Begin met de minste bevoegdheden voor elk segment en verbreed dat bereik alleen wanneer dat nodig is.
Door de minste bevoegdheden toe te passen, beperkt u de negatieve effecten als de identiteit ooit wordt aangetast. Als de toegang wordt beperkt door tijd, wordt de kwetsbaarheid voor aanvallen verder verkleind. Tijdsgebonden toegang is met name van toepassing op kritieke accounts, zoals beheerders of softwareonderdelen die een gecompromitteerde identiteit hebben.
Op rollen gebaseerd toegangsbeheer (RBAC) resulteert ook in beheeroverhead. Het bijhouden van identiteiten en hun toegangsbereiken kan complex worden in roltoewijzingen. De tijdelijke oplossing is om rollen toe te wijzen aan beveiligingsgroepen in plaats van afzonderlijke identiteiten.
Zie Identiteits- en toegangsbeheer voor informatie over identiteitsbeheer.
In tegenstelling tot netwerktoegangsbeheer valideert identiteit toegangsbeheer op het moment van toegang. Het wordt ten zeerste aanbevolen om regelmatig toegangsbeoordeling uit te voeren en een goedkeuringswerkstroom te vereisen om bevoegdheden te verkrijgen voor kritieke impactaccounts. Zie Bijvoorbeeld Identiteitssegmentatiepatronen.
Netwerken als perimeter
Identiteitsperimeter's zijn netwerkneutraal, terwijl netwerkperimeter de identiteit verbeteren, maar nooit vervangen. Netwerkperimeters worden ingesteld om blast radius te beheren, onverwachte, verboden en onveilige toegang te blokkeren en workloadresources te verbergen.
Hoewel de primaire focus van de identiteitsperimeter de minste bevoegdheden is, moet u ervan uitgaan dat er sprake is van een schending wanneer u de netwerkperimeter ontwerpt.
Maak softwaregedefinieerde perimeters in uw netwerkvoetafdruk met behulp van Azure-services en -functies. Wanneer een workload (of delen van een bepaalde workload) in afzonderlijke segmenten wordt geplaatst, kunt u het verkeer van of naar die segmenten beheren om communicatiepaden te beveiligen. Als een segment is gecompromitteerd, wordt het ingesloten en wordt voorkomen dat het zich lateraal verspreidt via de rest van uw netwerk.
Denk als een aanvaller om voet aan de grond te krijgen binnen de workload en besturingselementen in te stellen om verdere uitbreiding tot een minimum te beperken. De besturingselementen moeten aanvallers detecteren, bevatten en voorkomen dat ze toegang krijgen tot de hele workload. Hier volgen enkele voorbeelden van netwerkbesturingselementen als een perimeter:
- Definieer uw randperimeter tussen openbare netwerken en het netwerk waar uw workload wordt geplaatst. Beperk de zichtlijn van openbare netwerken tot uw netwerk zoveel mogelijk.
- Implementeer gedemilitariseerde zones (DMZ's) voor de toepassing met de juiste besturingselementen via firewalls.
- Maak microsegmentatie binnen uw particuliere netwerk door delen van de workload te groeperen in afzonderlijke segmenten. Veilige communicatiepaden tussen deze paden tot stand brengen.
- Maak grenzen op basis van intentie. Segmenteer bijvoorbeeld functionele netwerken van werkbelastingen uit operationele netwerken.
Zie Netwerksegmentatiepatronen voor veelvoorkomende patronen met betrekking tot netwerksegmentatie.
Privéconnectiviteit verandert het architectuurontwerp, waarbij vaak meer onderdelen worden toegevoegd, zoals jumpboxs voor persoonlijke toegang tot rekenknooppunten.
Omdat netwerkperimeter's zijn gebaseerd op controlepunten of hops op het netwerk, kan elke hop een potentieel storingspunt zijn. Deze punten kunnen van invloed zijn op de betrouwbaarheid van het systeem.
Zie Netwerken en connectiviteit voor meer informatie over netwerkbeheer.
Rollen en verantwoordelijkheden
Segmentatie die verwarring en beveiligingsrisico's voorkomt, wordt bereikt door duidelijk de verantwoordelijkheidslijnen binnen een workloadteam te definiëren.
Documenteer en deel rollen en functies om consistentie te creëren en communicatie te vergemakkelijken. Groepen of afzonderlijke rollen aanwijzen die verantwoordelijk zijn voor belangrijke functies. Houd rekening met de ingebouwde rollen in Azure voordat u aangepaste rollen voor objecten maakt.
Houd rekening met consistentie bij het aanpassen van verschillende organisatiemodellen bij het toewijzen van machtigingen voor een segment. Deze modellen kunnen variëren van één gecentraliseerde IT-groep tot voornamelijk onafhankelijke IT- en DevOps-teams.
Organisatie van resources
Met segmentatie kunt u workloadresources isoleren van andere onderdelen van de organisatie of zelfs binnen het team. Azure-constructies, zoals beheergroepen, abonnementen, omgevingen en resourcegroepen, zijn manieren om uw resources te ordenen die segmentatie bevorderen. Hier volgen enkele voorbeelden van isolatie op resourceniveau:
- Polyglot-persistentie omvat een combinatie van technologieën voor gegevensopslag in plaats van één databasesysteem ter ondersteuning van segmentatie. Gebruik polyglot-persistentie voor scheiding door verschillende gegevensmodellen, scheiding van functies zoals gegevensopslag en analyse, of om te scheiden door toegangspatronen.
- Wijs voor elke server één service toe bij het organiseren van uw rekenproces. Dit isolatieniveau minimaliseert de complexiteit en kan helpen bij het inperken van een aanval.
- Azure biedt ingebouwde isolatie voor sommige services, bijvoorbeeld scheiding van rekenkracht en opslag. Zie Isolatie in de openbare Azure-cloud voor andere voorbeelden.
Azure-facilitering
Bepaalde Azure-services zijn beschikbaar voor gebruik bij het implementeren van een segmentatiestrategie, zoals beschreven in de volgende secties.
Identiteit
Azure RBAC ondersteunt segmentatie door de toegang te isoleren per taakfunctie. Alleen bepaalde acties zijn toegestaan voor bepaalde rollen en bereiken. Aan taakfuncties die alleen het systeem hoeven te observeren, kunnen bijvoorbeeld leesmachtigingen worden toegewezen versus machtigingen voor inzenders waarmee de identiteit resources kan beheren.
Zie Best practices voor RBAC voor meer informatie.
Netwerken
Virtuele netwerken: Virtuele netwerken bieden insluiting van resources op netwerkniveau zonder verkeer tussen twee virtuele netwerken toe te voegen. Virtuele netwerken worden gemaakt in privéadresruimten binnen een abonnement
Netwerkbeveiligingsgroepen (NSG): een mechanisme voor toegangsbeheer voor het beheren van verkeer tussen resources in virtuele netwerken en externe netwerken, zoals internet. Implementeer door de gebruiker gedefinieerde routes (UDR) om de volgende hop voor verkeer te beheren. NSG's kunnen uw segmentatiestrategie naar een gedetailleerd niveau tillen door perimeters te maken voor een subnet, een virtuele machine (VM) of een groep vm's. Zie Subnetten voor meer informatie over mogelijke bewerkingen met subnetten in Azure.
Toepassingsbeveiligingsgroepen (ASG's): MET ASG's kunt u een set VIRTUELE machines groepeer onder een toepassingstag en verkeersregels definiëren die vervolgens worden toegepast op elk van de onderliggende VM's.
Azure Firewall: een cloudeigen service die kan worden geïmplementeerd in uw virtuele netwerk of in Azure Virtual WAN hub-implementaties. Gebruik Azure Firewall om verkeer tussen cloudresources, internet en on-premises resources te filteren. Gebruik Azure Firewall of Azure Firewall Manager om regels of beleidsregels te maken waarmee verkeer wordt toegestaan of geweigerd met behulp van besturingselementen van laag 3 tot laag 7. Filter internetverkeer met behulp van Azure Firewall en derden door verkeer via externe beveiligingsproviders te leiden voor geavanceerde filtering en gebruikersbeveiliging. Azure ondersteunt de implementatie van virtuele netwerkapparaten, wat helpt bij segmentering van firewalls van derden.
Voorbeeld
Hier volgen enkele veelvoorkomende patronen voor het segmenteren van een workload in Azure. Kies een patroon op basis van uw behoeften.
Dit voorbeeld bouwt voort op de IT-omgeving (Information Technology) die is vastgesteld in de beveiligingsbasislijn (SE:01). In het onderstaande diagram ziet u segmentatie op het niveau van de beheergroep die door een organisatie wordt uitgevoerd.
Identiteitssegmentatiepatronen
Patroon 1: Groeperen op basis van functietitels
Een manier om beveiligingsgroepen te organiseren, is op functie, zoals softwaretechnicus, databasebeheerder, site reliability engineer, technicus voor kwaliteitsbewaking of beveiligingsanalist. Deze aanpak omvat het maken van beveiligingsgroepen voor uw workloadteam op basis van hun rollen, zonder rekening te houden met het werk dat moet worden uitgevoerd. Beveiligingsgroepen RBAC-machtigingen verlenen, staand of Just In Time (JIT), op basis van hun verantwoordelijkheden in de workload. Wijs human- en serviceprincipes toe aan beveiligingsgroepen op basis van de toegang die ze nodig hebben.
Lidmaatschap is zeer zichtbaar op het niveau van de roltoewijzing, waardoor u gemakkelijk kunt zien waartoe een rol toegang heeft. Elke persoon is meestal lid van slechts één beveiligingsgroep, waardoor onboarding en offboarding eenvoudig zijn. Tenzij functietitels echter perfect overlappen met verantwoordelijkheden, is groepering op basis van titels niet ideaal voor implementatie met minimale bevoegdheden. Het kan zijn dat u implementatie combineert met groepering op basis van functies.
Patroon 2: Groeperen op basis van functies
Groeperen op basis van functies is een organisatiemethode voor beveiligingsgroepen die discreet werk weerspiegelt dat moet worden uitgevoerd, zonder rekening te houden met uw teamstructuur. Met dit patroon verleent u RBAC-machtigingen voor beveiligingsgroepen, staand of JIT, indien nodig, op basis van hun vereiste functie in de workload.
Wijs human- en serviceprincipes toe aan beveiligingsgroepen op basis van de toegang die ze nodig hebben. Gebruik waar mogelijk bestaande homogene groepen als leden van de op functies gebaseerde groepen, zoals groepen uit patroon 1. Voorbeelden van op functies gebaseerde groepen zijn:
- Operators voor productiedatabases
- Preproductiedatabaseoperators
- Operators voor rotatie van productiecertificaten
- Operators voor rotatie van preproductiecertificaten
- Productie live-site/triage
- Preproductie van alle toegang
Deze benadering handhaaft de striktste toegang met minimale bevoegdheden en biedt beveiligingsgroepen waarvan het bereik duidelijk is, waardoor het eenvoudig is om lidmaatschappen te controleren ten opzichte van de uitgevoerde taken. Vaak bestaat er een ingebouwde Azure-rol die overeenkomt met deze taakfunctie.
Lidmaatschap wordt echter ten minste één laag geabstraheerd, waardoor u naar de id-provider moet gaan om te begrijpen wie zich in de groep bevindt wanneer u vanuit het perspectief van de resource kijkt. Daarnaast moet één persoon meerdere lidmaatschappen onderhouden hebben voor volledige dekking. De matrix van overlappende beveiligingsgroepen kan complex zijn.
Patroon 2 wordt aanbevolen om de toegangspatronen de focus te geven, niet het organigram. Organigrammen en lidrollen veranderen soms. Door het identiteits- en toegangsbeheer van uw workload vast te leggen vanuit een functioneel perspectief, kunt u uw teamorganisatie abstraheren van het veilige beheer van de workload.
Netwerksegmentatiepatronen
Patroon 1: Segmentatie binnen een workload (zachte grenzen)
In dit patroon wordt de workload in één virtueel netwerk geplaatst met behulp van subnetten om grenzen te markeren. Segmentatie wordt bereikt met behulp van twee subnetten, één voor database en één voor webworkloads. U moet NSG's configureren waarmee Subnet 1 alleen mag communiceren met Subnet 2 en Subnet 2 om alleen met internet te communiceren. Dit patroon biedt beheer op laag 3-niveau.
Patroon 2: Segmentatie binnen een workload
Dit patroon is een voorbeeld van segmentatie op platformniveau. Workloadc-omponents worden verspreid over meerdere netwerken zonder peering tussen hen. Alle communicatie wordt gerouteerd via een tussenpersoon die fungeert als een openbaar toegangspunt. Het workloadteam is eigenaar van alle netwerken.
Patroon 2 biedt insluiting, maar heeft de extra complexiteit van het beheer en de grootte van virtuele netwerken. De communicatie tussen de twee netwerken vindt plaats via het openbare internet, wat een risico kan zijn. Er is ook latentie bij openbare verbindingen. De twee netwerken kunnen echter worden gekoppeld, waardoor segmentatie wordt verbroken door ze te verbinden om een groter segment te maken. Peering moet worden uitgevoerd wanneer er geen andere openbare eindpunten nodig zijn.
| Overwegingen | Patroon 1 | Patroon 2 |
|---|---|---|
| Connectiviteit en routering: hoe elk segment communiceert | Systeemroutering biedt standaardconnectiviteit met workloadonderdelen. Geen enkel extern onderdeel kan communiceren met de workload. | Binnen het virtuele netwerk, hetzelfde als patroon 1. Tussen netwerken gaat het verkeer via het openbare internet. Er is geen directe verbinding tussen de netwerken. |
| Filteren van verkeer op netwerkniveau | Verkeer tussen de segmenten is standaard toegestaan. Gebruik NSG's of ASG's om verkeer te filteren. | Binnen het virtuele netwerk, hetzelfde als patroon 1. Tussen de netwerken kunt u zowel inkomend als uitgaand verkeer filteren via een firewall. |
| Onbedoeld geopende openbare eindpunten | Netwerkinterfacekaarten (NIC's) krijgen geen openbare IP-adressen. Virtuele netwerken worden niet blootgesteld aan internet-API Management. | Hetzelfde als patroon 1. Het beoogde openbare eindpunt op één virtueel netwerk, dat onjuist kan worden geconfigureerd om meer verkeer te accepteren. |
Organisatie van resources
Azure-resources organiseren op basis van eigendomsverantwoordelijkheid
Overweeg een Azure-estate die meerdere workloads en gedeelde serviceonderdelen bevat, zoals virtuele hubnetwerken, firewalls, identiteitsservices en beveiligingsservices zoals Microsoft Sentinel. Onderdelen in de omgeving moeten worden gegroepeerd op basis van hun functionele gebieden, workloads en eigendom. Gedeelde netwerkresources moeten bijvoorbeeld worden gegroepeerd in één abonnement en worden beheerd door een netwerkteam. Onderdelen die zijn toegewezen aan afzonderlijke workloads, moeten zich in hun eigen segment bevinden en kunnen verder worden verdeeld op basis van toepassingslagen of andere organisatieprincipes.
Verleent toegang tot het beheren van resources binnen afzonderlijke segmenten door RBAC-roltoewijzingen te maken. Het cloudnetwerkteam kan bijvoorbeeld beheerderstoegang krijgen tot het abonnement dat hun resources bevat, maar niet tot afzonderlijke workloadabonnementen.
Een goede segmentatiestrategie maakt het mogelijk om eenvoudig de eigenaren van elk segment te identificeren. Overweeg het gebruik van Azure-resourcetags om aantekeningen te maken bij resourcegroepen of abonnementen met het eigenaarsteam.
Toegangsbeheer configureren en controleren
Verleent de juiste toegang op basis van behoefte door duidelijk segmenten voor uw resources te definiëren.
Houd rekening met het principe van minimale bevoegdheden wanneer u beleid voor toegangsbeheer definieert. Het is belangrijk om onderscheid te maken tussen besturingsvlakbewerkingen (beheer van de resource zelf) en gegevensvlakbewerkingen (toegang tot de gegevens die door de resource zijn opgeslagen). Stel dat u een workload hebt die een database met gevoelige informatie over werknemers bevat. U kunt beheertoegang verlenen aan sommige gebruikers die instellingen moeten configureren, zoals databaseback-ups of gebruikers die de prestaties van de databaseserver bewaken. Deze gebruikers mogen echter geen query's kunnen uitvoeren op de gevoelige gegevens die zijn opgeslagen in de database. Selecteer machtigingen die het minimale bereik verlenen dat gebruikers nodig hebben om hun taken uit te voeren. Controleer regelmatig roltoewijzingen voor elk segment en verwijder toegang die niet meer nodig is.
Notitie
Sommige zeer bevoorrechte rollen, zoals de rol van eigenaar in RBAC, bieden gebruikers de mogelijkheid om andere gebruikers toegang te verlenen tot een resource. Beperk het aantal gebruikers of groepen waaraan de rol van eigenaar is toegewezen en controleer regelmatig auditlogboeken om ervoor te zorgen dat ze alleen geldige bewerkingen uitvoeren.
Verwante koppelingen
- Isolatie in de openbare Azure-cloud
- Aanbevelingen voor RBAC
- Overzicht van virtuele netwerken
- ASG's
- Azure Firewall
- Overzicht van Firewall Manager
Controlelijst voor beveiliging
Raadpleeg de volledige set aanbevelingen.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor