Aanbevolen procedures voor Azure Enclave

In dit artikel worden de belangrijkste concepten en aanbevolen procedures voor Azure Enclave beschreven.

Azure Enclave versnelt en stroomlijnt de implementatie en het beheer van veilige, geïsoleerde en compatibele cloudomgevingen. Deze omgevingen zijn ontworpen om de meest gevoelige missiekritische taken en workloads te ondersteunen in zowel commerciële als air-gapped omgevingen.

Voor het bouwen en uitvoeren van workloads in Azure Enclave zijn enkele belangrijke concepten vereist, waaronder:

De Azure Enclave-productgroep, technische teams en veldteams hebben de volgende best practices en conceptuele artikelen ontwikkeld. De artikelen zijn gemaakt om eigenaren en ontwikkelaars van community's en enclaves te helpen belangrijke concepten beter te begrijpen en de juiste functies te implementeren.

Azure-configuratie

Lees deze installatiestappen door om te bepalen of deze configuratiestappen passen bij uw Azure Enclave-gebruiksscenario's.

Resourcegroepen voor Network Watcher configureren

Om mogelijke problemen met het aanmaken van virtuele netwerkstroomlogs te voorkomen, zorg ervoor dat je de instructies voor het starten volgt om toegang te configurerenNetworkWatcherRG.

Netwerk- en organisatieontwerppatronen voor Azure Enclave

Multitenantie

Netwerkontwerp

Azure Enclave combineert de mogelijkheden en flexibiliteit van verschillende Azure netwerkproducten in een vereenvoudigde gebruikersinterface, waaronder:

  • Azure Virtual WAN
  • Azure Firewall
  • Azure Virtueel Netwerk
  • Netwerkbeveiligingsgroepen

Azure Enclave doet de volgende algemene aanbevelingen:

  • Gemeenschappen moeten worden ingezet wanneer u netwerkvereisten hebt waarvoor een Azure Firewall nodig is, de intelligente firewallbeveiligingsservice van Azure op basis van Platform-as-a-Service.
  • Communities moeten worden ingezet wanneer u vereisten hebt op het gebied van organisatorische scheiding of gegevensgevoeligheid om een hub-and-spoke Virtual WAN van een ander hub-and-spoke Virtual WAN te scheiden.
  • Community's moeten worden geïmplementeerd wanneer u netwerkvereisten hebt om systemen te ondersteunen die meerdere Azure regio's omvatten, waarbij elke regio een eigen Azure Firewall vereist. Meer informatie over multi-hubs Azure Firewall use cases.
  • Communities moeten worden geïmplementeerd wanneer u netwerkvereisten hebt voor de ondersteuning van een groot aantal systemen in een gedistribueerd wide area network (hub-and-spoke). Meer informatie over Azure Virtual WAN.
  • Enclaves moeten worden geïmplementeerd wanneer u netwerkvereisten hebt om vergelijkbare workloads te implementeren als onderdeel van hetzelfde particuliere netwerk.
  • Enclaves moeten worden geïmplementeerd wanneer u workloadvereisten hebt die een virtueel netwerk nodig hebben en zich binnen dezelfde Virtual WAN bevinden als een bestaande community.

Overwegingen bij het ontwerpen van communitynetwerk

Volg, waar mogelijk, de documentatie over aanbevolen procedures voor de service Azure bij het plannen van uw communitynetwerken. Deze aanbevolen procedures opnemen:

Overwegingen bij het ontwerpen van enclave-netwerken

Volg, waar mogelijk, de documentatie over aanbevolen procedures voor de service Azure bij het plannen van uw enclavenetwerken. Deze aanbevolen procedures opnemen:

Meer informatie over algemene aanbevolen procedures voor Azure netwerken.

Workloadimplementatie

  • Workloads zijn gekoppeld aan een beheerde resourcegroep waar enclavebijdragers Azure resources kunnen implementeren.
  • Standaard worden alle Azure Enclave-workloads beheerd door ingebouwde Azure Policy initiatieven
  • Werkbelastingen die zijn gekoppeld aan een community met een aangepaste governanceconfiguratie gebruiken deze specifieke configuratie in plaats van de standaardgovernanceconfiguratie van Azure Enclave.
  • Overwegingen voor het benoemen van Azure resources

Compliance

U bent volledig verantwoordelijk voor het naleven van alle toepasselijke wetten en voorschriften. Informatie in online documentatie van Microsoft vormt geen juridisch advies. U moet uw juridische adviseur raadplegen voor vragen over de naleving van regelgeving.

Zie Azure complianceaanbiedingen voor meer informatie.

Beveiligingsontwerppatronen voor Azure Enclave

Houd rekening met deze beveiligingsontwerppatronen bij het ontwerpen van uw Azure Enclave-omgevingen.

Beveiligingsgrenzen

Azure Enclave maakt gebruik van een diepgaande verdedigingsbenadering als het gaat om cyberbeveiliging. Wanneer u een community en enclaves implementeert, brengt Azure Enclave verschillende lagen netwerkisolatie, beveiliging, toegangsbeheer en logboekregistratie en bewaking tot stand.

Gedeelde beveiligingsverantwoordelijkheden

Als service op Azure streeft Azure Enclave er ook naar om het model voor gedeelde verantwoordelijkheid in de cloud te handhaven. Voor Azure Enclave zijn workloads uw verantwoordelijkheid. De gedeelde verantwoordelijkheid van Azure geldt ook voor workloads als u PaaS-services in uw workloads hebt geïmplementeerd.

Uw gemeenschappen en enclaves zijn een gedeelde verantwoordelijkheid. Community's en enclaves maken gebruik van een model voor gedeelde verantwoordelijkheid waarbij de Azure Enclave-resourceprovider uw beveiligde, vooraf geconfigureerde hub-and-spoke-netwerkomgeving maakt. U beheert deze netwerkomgeving door enclave-eindpunten, community-eindpunten, transithubs of enclaveverbindingen te maken. Met bepaalde preview-versies van Azure Enclave kunt u ook handmatig wijzigingen aanbrengen in het netwerk via onderliggende besturingselementen die worden geleverd door Azure Virtual WAN, Azure Virtual Network en andere onderliggende Azure-netwerkservices.

Azure Enclave-governance is ook een gedeelde verantwoordelijkheid. De Azure Enclave-resourceprovider maakt een beveiligde, vooraf geconfigureerde lijst met Azure Policy initiatieven per workloadimplementatie. communities kunnen nu echter de Azure Policy-initiatieven van de community aanpassen, waarmee de vooraf geconfigureerde lijst voor de workload wordt overschreven. Ondanks de beleidsvereisten behoudt u de mogelijkheid om handmatige uitzonderingen te maken voor deze Azure Policy Initiatieftoewijzingen, afhankelijk van hun nalevings- of governancevereisten.

best practices voor Azure beveiliging

Azure Enclave raadt het volgende aan Microsoft Azure best practices en patronen voor beveiliging te volgen voor het implementeren van Azure resources en het implementeren van workloads.

U moet de aanbevolen procedures voor Azure beveiliging volgen: Cloud Adoption Framework voor het organiseren van uw systemen, cloudinfrastructuur, IT-personeel en teamstructuren, en trainingstrainingen voor cyberbeveiliging.

Gegevensexfiltratie via Domain Name System

Gegevensexfiltratie via DNS (Domain Name System) vertegenwoordigt een belangrijk beveiligingsprobleem voor organisaties, omdat het gebruikmaakt van een protocol dat doorgaans wordt toegestaan via firewalls en zelden wordt gecontroleerd op schadelijke activiteiten. Aanvallers kunnen GEBRUIKMAKEN van DNS-query's om gevoelige gegevens te extraheren uit gecompromitteerde systemen door informatie binnen domeinnamen te coderen of door DNS-tunnelingtechnieken te gebruiken. Deze methode is insidioot omdat DNS-verkeer legitiem lijkt en vaak traditionele hulpprogramma's voor beveiligingsbewaking omzeilt.

Bij exfiltratieaanvallen op basis van DNS-gegevens coderen kwaadwillende actoren gestolen gegevens in DNS-query's, vaak met behulp van technieken zoals labelen van subdomeinen of TXT-recordquery's. Een aanvaller kan bijvoorbeeld gevoelige gegevens opsplitsen in segmenten en elk segment insluiten als subdomein in DNS-query's voor door aanvallers beheerde domeinen. De gegevens kunnen worden geëxtraheerd uit DNS-logboeken op de DNS-server van de aanvaller. Met deze methode kunt u geleidelijk exfiltratie van grote gegevenssets uitvoeren terwijl een laag profiel behouden blijft, omdat de DNS-query's worden weergegeven als normale aanvragen voor naamomzetting.

Adressering van gegevensexfiltratie met Azure DNS beveiligingsbeleid

Azure DNS Beveiligingsbeleid biedt uitgebreide bescherming tegen exfiltratieaanvallen op basis van DNS-gegevens door gedetailleerde controle te bieden over DNS-verkeer binnen Azure virtuele netwerken. Met deze service kunnen organisaties proactieve beveiligingsmaatregelen implementeren waarmee verdachte DNS-activiteiten kunnen worden gedetecteerd, gewaarschuwd en geblokkeerd voordat gegevens kunnen worden geëxfileerd.

Azure DNS Beveiligingsbeleid heeft betrekking op exfiltratie van DNS-gegevens via verschillende belangrijke mechanismen. Ten eerste biedt het de mogelijkheid om DNS-verkeersregels te maken waarmee query's naar bekende schadelijke domeinen of verdachte domeinpatronen kunnen worden geblokkeerd die vaak worden gebruikt in exfiltratiepogingen. Organisaties kunnen blokkeringslijsten onderhouden van domeinen die zijn gekoppeld aan opdracht- en beheerinfrastructuur- of gegevensexfiltratieservices. Ten tweede biedt de service uitgebreide mogelijkheden voor DNS-logboekregistratie waarmee alle DNS-query's en antwoorden in beveiligde virtuele netwerken worden vastgelegd. Met deze logboekregistratie kunnen beveiligingsteams DNS-verkeerspatronen analyseren en mogelijke exfiltratiepogingen identificeren. Ten derde biedt de beleidsengine ondersteuning voor domeinfiltering met jokertekens, zodat organisaties volledige categorieën verdachte domeinen kunnen blokkeren of acceptatielijsten kunnen implementeren voor goedgekeurde DNS-bestemmingen.

De implementatie van Azure DNS Beveiligingsbeleid maakt meerdere beveiligingslagen tegen exfiltratie van DNS-gegevens. Verkeersregels kunnen worden geconfigureerd met verschillende prioriteitsniveaus, waardoor complexe beveiligingsbeleidsregels worden afgestemd op de beveiliging met operationele vereisten. De service biedt ondersteuning voor realtime blokkeren van schadelijke query's en biedt gedetailleerde logboeken voor forensische analyse en opsporing van bedreigingen. Bovendien zorgen virtuele netwerkkoppelingen ervoor dat DNS-beveiligingsbeleid consistent wordt toegepast op alle resources binnen beveiligde netwerksegmenten, waardoor een uitgebreide beveiligingsperimeter ontstaat die moeilijk kan worden omzeild door aanvallers.

Voor Azure Enclave-implementaties moet Azure DNS beveiligingsbeleid worden geïntegreerd als onderdeel van de algehele beveiligingsarchitectuur. Organisaties moeten DNS-beveiligingsbeleid configureren om DNS-verkeer van enclaveworkloads te bewaken en te beheren, zodat gevoelige gegevens beveiligd blijven, zelfs als er inbreuk wordt gemaakt op afzonderlijke workloads. Regelmatig controleren en bijwerken van DNS-domeinlijsten, gecombineerd met continue bewaking van DNS-logboeken, biedt doorlopende beveiliging tegen veranderende op DNS gebaseerde bedreigingen en helpt de beveiligingsintegriteit van de Azure Enclave-omgeving te behouden.

Meer informatie vindt u in de documentatie voor DNS-beveiligingsbeleid.

DNS-beveiligingsbeleid volgens het 'standaard weigeren'-principe implementeren

Voor maximale beveiliging in Azure Enclave-omgevingen moeten organisaties een 'standaard weigeren, toestaan op uitzondering'-benadering voor DNS-filtering implementeren. Dit beveiligingsmodel zorgt ervoor dat alle DNS-query's worden geblokkeerd, tenzij dit expliciet is toegestaan, waardoor de sterkste beveiliging wordt geboden tegen exfiltratie en communicatie tussen opdrachten en besturingselementen.

De standaardbenadering voor weigeren wordt geïmplementeerd met behulp van een DNS-regelstructuur met twee lagen binnen Azure DNS beveiligingsbeleid:

Stap 1: De standaardregel voor weigeren maken Maak een DNS-domeinlijst met alleen het hoofddomein . (punt). Dit jokertekendomein komt overeen met alle mogelijke DNS-query's. Koppel deze domeinlijst aan een DNS-verkeersregel die is geconfigureerd met:

  • Prioriteit: 65000 (laagste prioriteit)
  • Actie: Blokkeren
  • Lijst met domeinen: hoofddomein (.)

Deze regel fungeert als de catch-all die alle DNS-query's blokkeert die niet expliciet zijn toegestaan door regels met een hogere prioriteit.

Stap 2: regels voor toegestane lijsten maken Maak afzonderlijke DNS-domeinlijsten met specifieke domeinen die vereist zijn voor legitieme bedrijfsactiviteiten. Dit zijn onder andere:

  • Essentiële Azure services (bijvoorbeeld *.azure.com, *.microsoft.com)
  • Bedrijfsdomeinen en vertrouwde niet-Microsoft-services
  • Updateservices van besturingssysteem
  • Domeinen van certificeringsinstantie

Koppel de acceptatielijsten aan DNS-verkeersregels die zijn geconfigureerd met:

  • Prioriteit: 500-1000 (hogere prioriteit dan standaard weigeren)
  • Actie: toestaan
  • Domeinlijsten: specifieke goedgekeurde domeinen

Regelverwerking op basis van prioriteit Azure DNS Beveiligingsbeleid verwerkt regels in prioriteitsvolgorde (lagere getallen = hogere prioriteit). Wanneer een DNS-query wordt uitgevoerd:

  1. Het systeem evalueert eerst regels voor toestaan met hoge prioriteit (prioriteit 500-1000)
  2. Als het domein overeenkomt met een acceptatielijst, is de query toegestaan
  3. Als er geen allow regels overeenkomen, loopt de query door naar de standaardregel voor weigeren (prioriteit 65000) en wordt het verkeer geblokkeerd

Deze aanpak biedt verschillende beveiligingsvoordelen:

  • Zero trust model: er zijn geen DNS-query's toegestaan, tenzij expliciet geautoriseerd
  • Gedetailleerd beheer: Organisaties kunnen nauwkeurig bepalen welke domeinen toegankelijk zijn
  • Audittrail: Alle geblokkeerde query's worden geregistreerd, waardoor u inzicht verleent in mogelijke bedreigingen
  • Incrementele updates: nieuwe goedgekeurde domeinen kunnen worden toegevoegd aan acceptatielijsten zonder de standaardregel voor weigeren te wijzigen

Voorbeeld van implementatie:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

Organisaties die deze aanpak implementeren, moeten beginnen met een uitgebreide inventarisatie van vereiste domeinen en de lijst met toegestane domeinen geleidelijk verfijnen op basis van operationele behoeften en beveiligingslogboeken. Regelmatige controle van geblokkeerde query's helpt bij het identificeren van legitieme domeinen die mogelijk moeten worden toegevoegd aan de acceptatielijsten en tegelijkertijd een sterke beveiligingspostuur behouden.

Standaard-DNS-beleid voor weigeren implementeren met Windows DNS-server

Voor omgevingen die geen gebruik kunnen maken van Azure DNS-beveiligingsbeleid of on-premises DNS-beheer vereisen, kan vergelijkbare deny-by-default-beveiliging worden geïmplementeerd met behulp van Windows DNS-server met dns-beleidsfuncties. Deze benadering biedt vergelijkbare beveiliging tegen exfiltratie van DNS-gegevens, terwijl de compatibiliteit met bestaande Windows infrastructuur behouden blijft.

Windows DNS-server (Windows Server 2016 en hoger) ondersteunt dns-beleidsfunctionaliteit waarmee organisaties geavanceerde DNS-filterregels kunnen implementeren. Het deny-by-default model kan worden bereikt via een combinatie van DNS-beleidsregels en zoneconfiguraties.

Beheerde resourcegroepen in Azure Enclave

De resourcegroepen die resources bevatten die worden beheerd door Azure Enclave.

Door de community beheerde resourcegroep

De door de community beheerde resourcegroep bevat de infrastructuurresources die worden beschreven in Wat is een community?

De naam van de door de community beheerde resourcegroep volgt deze naamconventie: myCommunityName-HostedResources-<GUID>. Elke community-implementatie maakt deze resourcegroep aan en plaatst de community-infrastructuur daarin. Wanneer u uw community verwijdert, verwijdert de Azure Enclave-resourceprovider automatisch de door de community beheerde resourcegroep.

Schermopname van een voorbeeld van de community-resources die worden beheerd door Azure Enclave.

De door de community beheerde resourcegroep heeft de volgende beperkingen:

  • U kunt geen bestaande resourcegroep opgeven voor de door de community beheerde resourcegroep.
  • U kunt geen ander abonnement opgeven voor de door de community beheerde resourcegroep.
  • U kunt de naam van de door de community beheerde resourcegroep niet wijzigen nadat de community is gemaakt.
  • U kunt geen namen opgeven voor de beheerde resources binnen de door de community beheerde resourcegroep.
  • U kunt de door Azure gemaakte tags van beheerde resources binnen de door de community beheerde resourcegroep niet wijzigen of verwijderen.

Als u door Azure gemaakte tags, hulpbronnen en andere eigenschappen van hulpbronnen in de door de community beheerde resourcegroep wijzigt of verwijdert, kunt u onverwachte resultaten zien. Naarmate Azure Enclave de levenscyclus van infrastructuur in de door de community beheerde resourcegroep beheert, kunnen wijzigingen uw enclave mogelijk verplaatsen naar een niet-ondersteunde status.

Een veelvoorkomend scenario waarin u resources wilt wijzigen, is via tags. Met Azure Enclave kunt u tags maken en wijzigen die worden doorgegeven aan resources in de door de community beheerde resourcegroep. U kunt aangepaste tags maken of wijzigen, bijvoorbeeld om een bedrijfseenheid of kostenplaats toe te wijzen. Dit kan ook worden bereikt door Azure beleid te maken met een bereik voor de door de community beheerde resourcegroep.

Note

Als u geen door de community beheerde resourcegroepvergrendeling hebt ingeschakeld, kunt u elke resource in de door de community beheerde resourcegroep rechtstreeks wijzigen. Het rechtstreeks wijzigen van resources in de door de community beheerde resourcegroep kan ertoe leiden dat uw enclave instabiel of niet meer reageert.

Door enclave beheerde resourcegroep

De beheerde enclaveresourcegroep bevat de infrastructuurresources die worden beschreven in Wat is een enclave?

De naam van de door de enclave beheerde resourcegroep volgt deze naamconventie: myEnclaveName-HostedResources-<GUID>. Elke enclave-implementatie maakt deze resourcegroep aan en plaatst de enclave-infrastructuur daarin. Wanneer u uw enclave verwijdert, verwijdert de Azure Enclave-resourceprovider automatisch de beheerde enclaveresourcegroep.

Schermopname van een voorbeeld van de enclave-resources die worden beheerd door Azure Enclave.

De door de enclave beheerde resourcegroep heeft de volgende beperkingen:

  • U kunt geen bestaande resourcegroep opgeven voor de door enclave beheerde resourcegroep.
  • U kunt niet een ander abonnement opgeven voor de door enclave beheerde resourcegroep.
  • U kunt de naam van de door de enclave beheerde resourcegroep niet wijzigen nadat de enclave is gemaakt.
  • U kunt geen namen opgeven voor de beheerde resources in de door enclave beheerde resourcegroep.
  • U kunt tags die door Azure zijn aangemaakt van beheerde resources binnen de door enclave beheerde resourcegroep niet wijzigen of verwijderen.

Als u door Azure aangemaakte tags, resources en andere resource-eigenschappen wijzigt of verwijdert in de beheerde-resourcegroep van de enclave, kunt u onverwachte resultaten krijgen, zoals netwerk-, toegangs- en bewakingsfouten. Naarmate Azure Enclave de levenscyclus van infrastructuur in de beheerde enclaveresourcegroep beheert, kunnen wijzigingen uw enclave mogelijk verplaatsen naar een niet-ondersteunde status.

Een veelvoorkomend scenario waarin u resources wilt wijzigen, is via tags. Met Azure Enclave kunt u tags maken en wijzigen die worden doorgegeven aan resources in de door Enclave beheerde resourcegroep. U kunt aangepaste tags maken of wijzigen, bijvoorbeeld om een bedrijfseenheid of kostenplaats toe te wijzen. Resourcetags kunnen ook worden toegepast door Azure-beleid te maken met als bereik de beheerde resourcegroep van de enclave.

Warning

Het wijzigen van resources in de beheerde resourcegroep van de enclave kan ertoe leiden dat uw enclave instabiel wordt of niet meer reageert.

Resourcegroep voor workload

De workload is gekoppeld aan een of meer resourcegroepen waar u uw Azure resources kunt maken en organiseren.

Een resourcegroep toevoegen aan een workload

Als u een nieuwe resourcegroep toevoegt, moet de gebruiker normaal gesproken machtigingen hebben om een nieuwe resourcegroep te maken. De rollen Abonnement Owner of Contributor hebben deze machtiging, maar de persoon die de resourcegroep voor de workload maakt, heeft deze bevoorrechte machtiging mogelijk niet of niet nodig. Azure Enclave probeert drie manieren om de nieuwe resourcegroep te maken, variërend van de hoogste tot de laagste gebruikersmachtigingsvereisten, wat flexibiliteit biedt voor de gebruiker:

  • Optie 1: Vereist de meest bevoegde machtigingen voor de persoon die de workload maakt of bijwerkt, wat volledige controle biedt, maar verhoogde toegang vereist.
  • Optie 2: Omvat handmatige instellingen door de gebruiker om ons Mission Enclave toepassingseigendom te verlenen op abonnementsniveau, wat mogelijk niet overeenkomt met uw voorkeuren.
  • Optie 3: Vereist geen machtigingen voor de gebruiker of de Mission Enclave toepassing, waardoor het de eenvoudigste methode is, maar een strikte 1:1-relatie tussen de resourcegroep en de workload wordt opgelegd.

Elke optie heeft voordelen en beperkingen, evenwichtsbeheer, gemak en flexibiliteit om aan verschillende behoeften te voldoen. Deze opties worden één voor één beoordeeld, te beginnen met optie 1, en de eerste optie die slaagt, wordt gebruikt om de nieuwe resourcegroep te maken.

Nadat u één workloadresourcegroep hebt gemaakt met optie 3, ziet u een waarschuwing dat optie 3 niet kan worden gebruikt voor de volgende workloadresourcegroepen voor die workload. U kunt ook een nieuwe workload maken en vervolgens een nieuwe resourcegroep voor workloads maken door opnieuw optie 3 te gebruiken.

Voeg een resourcegroep toe aan uw enclave:

  1. Open de Azure portalpagina voor de workload.
  2. Selecteer Manage en vervolgens Resource Groups.
  3. Selecteer Add a resource group.
  4. Selecteer Create new in het zijvenster dat wordt geopend de naam van de nieuwe lege resourcegroep op te geven of selecteer de Resource Group vervolgkeuzelijst om een bestaande resourcegroep te kiezen.
  5. Selecteer OK en vervolgens Save.

Hoe verschilt een workloadresourcegroep van andere Azure resourcegroepen?

Een resourcegroep voor workloads is een essentieel onderdeel van de beveiliging en compliance van Azure Enclave, omdat daar uw belangrijke resources worden aangemaakt. Omdat deze workloadresourcegroepen zijn gekoppeld aan een workload en de workload is gekoppeld aan een enclave, beheert Azure Enclave het verwijderen van beheerde workloadresourcegroepen.

Daarnaast wordt beleid toegepast op de resourcegroepen van de werkbelasting. Net zoals het communitybeleid doorwerkt naar de enclave, werkt het enclavebeleid door naar de workload-resources en workload-resourcegroepen. Wanneer u een nieuwe resourcegroep voor workloads maakt, worden de rollen ingesteld op het enclaveniveau en overgeërfd van het abonnement. Sommige van deze beleidsregels worden overgenomen van de community en u kunt ook beleidsregels maken in de enclave die omlaag stromen naar workloads en workloadresourcegroepen.

Resources ordenen in resourcegroepen voor werkbelasting

Als u uw resources wilt splitsen in twee resourcegroepen, kunt u een van de volgende opties kiezen:

  • deze resources verdelen over twee resourcegroepen die aan dezelfde workload zijn gekoppeld
  • verdeel die resources over twee werkbelastingen, elk met een of meer resourcegroepen

Werkbelasting verwijderen

Wanneer het verwijderen van een workload wordt aangevraagd, worden de resourcegroepen van de workload gecontroleerd om te verifiëren dat ze leeg zijn. Als resourcengroepen voor workloads bronnen bevatten, mislukt het verwijderen van de aangevraagde workload en wordt er een fout weergegeven. Als u de workload en de resourcegroepen voor workloads wilt verwijderen, moet u eerst de resourcegroepen voor workloads leegmaken. Lege workloadresourcegroepen helpen voorkomen dat belangrijke resources per ongeluk worden verwijderd.

Het verwijderen van een resource die is gekoppeld aan de workload, volgt hetzelfde gedrag. Als er bijvoorbeeld wordt gevraagd om een community te verwijderen, maar niet alle resourcegroepen voor workloads leeg zijn, wordt er een fout weergegeven. Maak de resourcegroepen van de werkbelasting leeg en probeer het opnieuw.

De beheerde resourcegroep van de workload heeft de volgende beperkingen:

  • U kunt geen bestaande resourcegroep opgeven voor de door de workload beheerde resourcegroep.
  • U kunt geen ander abonnement opgeven voor de door workload beheerde resourcegroep.
  • U kunt de naam van de beheerde resourcegroep van de workload niet wijzigen nadat de workload is gemaakt.
  • U kunt door Azure aangemaakte tags van beheerde resources binnen de door de workload beheerde resourcegroep niet wijzigen of verwijderen.

Een veelvoorkomend scenario waarin u resources wilt wijzigen, is via tags. Met Azure Enclave kunt u tags maken en wijzigen die worden doorgevoerd naar resources in de door workload beheerde resourcegroep. U kunt aangepaste tags maken of wijzigen, bijvoorbeeld om een bedrijfseenheid of kostenplaats toe te wijzen. Tags toevoegen kan ook worden gerealiseerd door Azure-beleidsregels te maken met als bereik de beheerde resourcegroep van de workload.

Andere best practices voor Azure

Wanneer u uw community's, enclaves en workloads in Azure bouwt, is het belangrijk om rekening te houden met de volgende universele ontwerpprincipes:

  • Last updated on