Bästa praxis för Azure Enclave

Den här artikeln beskriver viktiga begrepp och metodtips för Azure Enclave.

Azure Enclave påskyndar och effektiviserar distributionen och hanteringen av säkra, isolerade och kompatibla molnmiljöer. De här miljöerna är utformade för att hantera de mest känsliga uppdragen och arbetsbelastningarna i kommersiella och isolerade miljöer.

Att skapa och köra arbetsbelastningar i Azure Enclave kräver förståelse och implementering av några viktiga begrepp, bland annat:

Produktgruppen Azure Enclave, tekniska team och fältteam utvecklade följande metodtips och konceptuella artiklar. Artiklarna skapades för att hjälpa community- och enklaverägare och utvecklare att bättre förstå viktiga begrepp och implementera lämpliga funktioner.

Azure-konfiguration

Läs igenom de här installationsstegen för att avgöra om de här konfigurationsstegen passar dina användningsfall för Azure Enclave.

Konfigurera Network Watcher resursgrupper

För att undvika eventuella problem när du skapar virtuella nätverksflödesloggar, se till att du följer komma igång-anvisningarna för att konfigurera åtkomst till NetworkWatcherRG.

Nätverks- och organisationsdesignmönster för Azure Enclave

Fleranvändarmiljö

Nätverksdesign

Azure Enclave sammanför funktioner och flexibilitet för flera Azure nätverksprodukter i ett förenklat användargränssnitt, inklusive:

  • Azure Virtual WAN
  • Azure Firewall
  • Virtuellt Azure-nätverk
  • Nätverkssäkerhetsgrupper

Azure Enclave ger följande övergripande rekommendationer:

  • Communities bör driftsättas när du har nätverkskrav för att tillhandahålla Azure Firewall, som är Azures intelligenta brandväggssäkerhetsplattform som en tjänst.
  • Communities bör driftsättas när du har krav kopplade till organisatorisk eller datamässig känslighet för att åtskilja ett Virtual WAN i hub-and-spoke-topologi från ett annat Virtual WAN i hub-and-spoke-topologi.
  • Communities bör distribueras när du har nätverkskrav för att stödja system som sträcker sig över flera Azure regioner, där varje region kräver sina egna Azure Firewall. Läs mer om användningsfall för flera hubbar Azure Firewall.
  • Communities bör driftsättas när du har nätverkskrav som ska stödja ett stort antal system i ett distribuerat WAN i hubb-och-eker-topologi. Läs mer om Azure Virtual WAN.
  • Enklaver bör driftsättas när du har nätverkskrav som innebär att liknande arbetsbelastningar behöver driftsättas inom samma privata nätverk.
  • Enklaver bör driftsättas när du har krav på arbetsbelastningar som behöver ett virtuellt nätverk och finns inom samma Virtual WAN som en befintlig community.

Designöverväganden för communitynätverk

Du bör, när det är möjligt, följa dokumentationen om bästa praxis för underliggande Azure-tjänster när du planerar dina communitynätverk. Inklusive dessa metodtips:

Designöverväganden för enklavernätverk

Du bör när det är möjligt följa dokumentationen om underliggande Azure bästa praxis för tjänsten när du planerar dina enklavernätverk. Inklusive dessa metodtips:

Läs mer om metodtips för övergripande Azure nätverk.

Distribution av arbetsbelastning

  • Arbetslaster är länkade till den hanterade resursgruppen där enklavens deltagare kan distribuera Azure-resurser.
  • Som standard styrs alla Azure Enklaver-arbetsbelastningar genom inbyggda Azure Policy initiativ
  • Arbetsbelastningar som är associerade med en community som har en anpassad styrningskonfiguration använder den här unika konfigurationen i stället för standardkonfigurationen för Azure Enclave-styrning.
  • Överväganden för namngivning Azure resurser

Compliance

Du är helt ansvarig för att se till att du följer alla tillämpliga lagar och föreskrifter. Informationen som tillhandahålls i Microsofts onlinedokumentation utgör inte juridisk rådgivning och du bör kontakta din juridiska rådgivare för eventuella frågor om regelefterlevnad.

Mer information finns i Azures efterlevnadserbjudanden.

Säkerhetsdesignmönster för Azure Enklaver

Tänk på de här säkerhetsdesignmönstren när du utformar dina Azure Enclave-miljöer.

Säkerhetsgränser

Azure Enclave använder ett djupgående skydd när det gäller cybersäkerhet. När du distribuerar en community och enklaver etablerar Azure Enclave flera lager av nätverksisolering, säkerhet, åtkomstkontroller samt loggning och övervakning.

Delat säkerhetsansvar

Som en tjänst på Azure har Azure Enclave också åtagit sig att upprätthålla modellen med delat ansvar i molnet. För Azure Enclave specifikt är arbetsbelastningar ditt ansvar. Azures delade ansvar ärvs av arbetsbelastningar om du har distribuerat PaaS-tjänster i dina arbetsbelastningar.

Dina samhällen och enklaver representerar ett delat ansvar. Gemenskaper och enklaver använder en modell med delat ansvar där resursprovidern Azure Enclave Resource Provider skapar din skyddade, förkonfigurerade nätverksmiljö av typen nav och eker. Du hanterar den här nätverksmiljön genom att skapa enklaverslutpunkter, communityslutpunkter, transithubbar eller enklaveranslutningar. Vissa förhandsversioner av Azure Enclave gör också att du kan göra ändringar i nätverket manuellt via underliggande kontroller som tillhandahålls av Azure Virtual WAN, Azure Virtual Network och andra underliggande Azure nätverkstjänster.

Azure Enklavstyrning är också ett delat ansvar. Resursprovidern Azure Enclave skapar en säker, förkonfigurerad lista över Azure Policy initiativ per arbetsbelastningsdistribution. Nu har dock communities möjlighet att anpassa communityn Azure Policy Initiatives, vilket åsidosätter den förkonfigurerade listan för arbetsbelastningen. Trots principkraven behåller du möjligheten att göra manuella undantag för dessa Azure Policy Initiativtilldelningar beroende på deras efterlevnads- eller styrningskrav.

bästa praxis för Azure säkerhet

Azure Enclave rekommenderar att du följer bästa praxis och mönster för Microsoft Azure Säkerhet för att distribuera Azure resurser och implementera arbetsbelastningar.

Du bör följa bästa praxis för Azure säkerhet – Cloud Adoption Framework för att organisera dina system, molninfrastruktur, IT-personal och teamindelningsstrukturer samt utbildningar om cybersäkerhetsmedvetenhet.

Dataexfiltrering via domännamnssystemet

Dataexfiltrering via DNS (Domain Name System) utgör ett betydande säkerhetsproblem för organisationer, eftersom det använder ett protokoll som vanligtvis tillåts via brandväggar och som sällan övervakas för skadlig aktivitet. Angripare kan utnyttja DNS-frågor för att i hemlighet extrahera känsliga data från komprometterade system genom att koda information i domännamn eller med hjälp av DNS-tunneltekniker. Den här metoden är lömsk eftersom DNS-trafik verkar legitim och ofta kringgår traditionella säkerhetsövervakningsverktyg.

I DNS-baserade dataexfiltreringsattacker kodar skadliga aktörer stulna data i DNS-frågor, ofta med hjälp av tekniker som underdomänetikettering eller TXT-postfrågor. En angripare kan till exempel dela upp känsliga data i segment och bädda in varje segment som en underdomän i DNS-frågor till angriparekontrollerade domäner. Data kan extraheras från DNS-loggar på angriparens DNS-server. Den här metoden möjliggör gradvis exfiltrering av stora datamängder samtidigt som en låg profil bibehålls, eftersom DNS-frågorna visas som vanliga namnmatchningsbegäranden.

Hantera dataexfiltrering med Azure DNS säkerhetsprincip

Azure DNS Security Policy ger ett omfattande skydd mot DNS-baserade dataexfiltreringsattacker genom att ge detaljerad kontroll över DNS-trafik inom Azure virtuella nätverk. Den här tjänsten gör det möjligt för organisationer att implementera proaktiva säkerhetsåtgärder som kan identifiera, varna på och blockera misstänkt DNS-aktivitet innan data kan exfiltrateras.

Azure DNS Säkerhetsprincip hanterar DNS-dataexfiltrering via flera viktiga mekanismer. För det första ger det möjlighet att skapa DNS-trafikregler som kan blockera frågor till kända skadliga domäner eller misstänkta domänmönster som ofta används vid exfiltreringsförsök. Organisationer kan underhålla blocklistor över domäner som är associerade med kommando- och kontrollinfrastruktur eller dataexfiltreringstjänster. För det andra erbjuder tjänsten omfattande DNS-loggningsfunktioner som samlar in alla DNS-frågor och svar i skyddade virtuella nätverk. Den här loggningen gör det möjligt för säkerhetsteam att analysera DNS-trafikmönster och identifiera potentiella exfiltreringsförsök. För det tredje stöder principmotorn filtrering av jokerteckendomäner, vilket gör det möjligt för organisationer att blockera hela kategorier av misstänkta domäner eller implementera tillåtna listor för godkända DNS-mål.

Implementeringen av Azure DNS Security Policy skapar flera lager av skydd mot DNS-dataexfiltrering. Trafikregler kan konfigureras med olika prioritetsnivåer, vilket möjliggör komplexa säkerhetsprinciper som balanserar säkerhet med driftkrav. Tjänsten stöder blockering i realtid av skadliga frågor samtidigt som detaljerade loggar för kriminalteknisk analys och hotjakt ges. Dessutom säkerställer virtuella nätverkslänkar att DNS-säkerhetsprinciper tillämpas konsekvent på alla resurser inom skyddade nätverkssegment, vilket skapar en omfattande säkerhetsperimeter som är svår för angripare att kringgå.

För Azure Enklaver-distributioner bör Azure DNS säkerhetsprincip integreras som en del av den övergripande säkerhetsarkitekturen. Organisationer bör konfigurera DNS-säkerhetsprinciper för att övervaka och kontrollera DNS-trafik från enklaverarbetsbelastningar, så att känsliga data förblir skyddade även om enskilda arbetsbelastningar komprometteras. Regelbunden granskning och uppdatering av DNS-domänlistor i kombination med kontinuerlig övervakning av DNS-loggar ger kontinuerligt skydd mot framväxande DNS-baserade hot och hjälper till att upprätthålla säkerhetsintegriteten i Azure Enclave-miljön.

Mer information finns i dokumentationen om DNS-säkerhetsprinciper.

Implementera DNS-säkerhetsprinciper med principen neka som standard

För maximal säkerhet i Azure Enklaver-miljöer bör organisationer implementera en "neka som standard, tillåt som undantag"-metod för DNS-filtrering. Den här säkerhetsmodellen säkerställer att alla DNS-frågor blockeras om det inte uttryckligen tillåts, vilket ger det starkaste skyddet mot DNS-baserad dataexfiltrering och kommunikation med kommando och kontroll.

Metoden neka som standard implementeras med hjälp av en DNS-regelstruktur med två nivåer i Azure DNS säkerhetsprincip:

Steg 1: Skapa standardregeln för neka Skapa en DNS-domänlista som endast innehåller rotdomänen . (punkt). Den här jokerteckendomänen matchar alla möjliga DNS-frågor. Associera den här domänlistan med en DNS-trafikregel som konfigurerats med:

  • Prioritet: 65000 (lägsta prioritet)
  • Åtgärd: Blockera
  • Domänlista: Rotdomän (.)

Den här regeln fungerar som catch-all som blockerar alla DNS-frågor som inte uttryckligen tillåts av regler med högre prioritet.

Steg 2: Skapa regler för tillåtna listor Skapa separata DNS-domänlistor som innehåller specifika domäner som krävs för legitima affärsåtgärder. Dessa kan vara:

  • Viktiga Azure tjänster (till exempel *.azure.com, *.microsoft.com)
  • Företagsdomäner och betrodda icke-Microsoft-tjänster
  • Uppdateringstjänster för operativsystem
  • Domäner för certifikatutfärdare

Koppla tillåtslistorna till DNS-trafikregler som har konfigurerats med:

  • Prioritet: 500–1 000 (högre prioritet än standard neka)
  • Åtgärd: Tillåt
  • Domänlistor: Specifika godkända domäner

Prioritetsbaserad regelbearbetning Azure DNS Säkerhetsprincip bearbetar regler i prioritetsordning (lägre tal = högre prioritet). När en DNS-fråga görs:

  1. Systemet utvärderar först tillåtelseregler med hög prioritet (prioritet 500–1000)
  2. Om domänen matchar en lista över tillåtna tillåts frågan
  3. Om inga allow regler matchar faller frågan igenom till standardregeln för neka (prioritet 65000) och trafiken blockeras

Den här metoden ger flera säkerhetsfördelar:

  • Noll förtroendemodell: Inga DNS-frågor tillåts om inte uttryckligen auktoriserade
  • Detaljerad kontroll: Organisationer kan exakt kontrollera vilka domäner som är tillgängliga
  • Spårningslogg: Alla blockerade frågor loggas, vilket ger insyn i potentiella hot
  • Inkrementella uppdateringar: Nya godkända domäner kan läggas till för att tillåta listor utan att ändra standardregeln för neka

Exempel på implementering:

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

Organisationer som implementerar den här metoden bör börja med en omfattande inventering av nödvändiga domäner och gradvis förfina listan över tillåtna domäner baserat på driftbehov och säkerhetsloggar. Regelbunden granskning av blockerade frågor hjälper dig att identifiera legitima domäner som kan behöva läggas till i listan över tillåtna och samtidigt upprätthålla en stark säkerhetsstatus.

Implementera DNS-principer med neka som standard i Windows DNS Server

För miljöer som inte kan använda Azure DNS säkerhetsprincip eller kräver lokal DNS-kontroll kan liknande neka som standardsäkerhet implementeras med hjälp av Windows DNS-server med DNS-principfunktioner. Den här metoden ger jämförbart skydd mot DNS-baserad dataexfiltrering samtidigt som kompatibilitet med befintlig Windows infrastruktur bibehålls.

Windows DNS Server (Windows Server 2016 och senare) stöder DNS-principfunktioner som gör det möjligt för organisationer att implementera avancerade DNS-filtreringsregler. Modellen neka som standard kan uppnås genom en kombination av DNS-principregler och zonkonfigurationer.

Hanterade resursgrupper i Azure Enclave

De resursgrupper som innehåller resurser som hanteras av Azure Enclave.

Community-hanterad resursgrupp

Den community-hanterade resursgruppen innehåller de infrastrukturresurser som beskrivs i Vad är en community?.

Namnet på resursgruppen som hanteras av communityn följer följande namngivningskonvention: myCommunityName-HostedResources-<GUID>. Varje driftsättning för communityn skapar denna resursgrupp och placerar communityinfrastruktur i den. När du tar bort communityn tar resursprovidern Azure Enclave automatiskt bort den communityhanterade resursgruppen.

Skärmbild som visar ett exempel på de communityresurser som hanteras av Azure Enclave.

Resursgruppen som hanteras av communityn har följande begränsningar:

  • Du kan inte ange en befintlig resursgrupp för den community-hanterade resursgruppen.
  • Du kan inte ange en annan prenumeration för den community-hanterade resursgruppen.
  • Du kan inte ändra namnet på den communityhanterade resursgruppen när communityn har skapats.
  • Du kan inte ange namn för de hanterade resurserna i den resursgrupp som hanteras av communityn.
  • Du kan inte ändra eller ta bort taggar som skapats av Azure för hanterade resurser i den communityhanterade resursgruppen.

Om du ändrar eller tar bort Azure skapade taggar, resurser och andra resursegenskaper i den communityhanterade resursgruppen kan du se oväntade resultat. Eftersom Azure Enclave hanterar livscykeln för infrastrukturen i den communityhanterade resursgruppen kan eventuella ändringar flytta enklaven till ett tillstånd som inte stöds.

Ett vanligt scenario där du vill ändra resurser är genom taggar. Med Azure Enclave kan du skapa och ändra taggar som vidarebefordras till resurser i den community-hanterade resursgruppen. Du kanske vill skapa eller ändra anpassade taggar, till exempel för att tilldela en affärsenhet eller ett kostnadsställe. Detta kan också uppnås genom att skapa Azure-principer med ett omfång som omfattar den community-hanterade resursgruppen.

Note

Om du inte har aktiverat låsning av communityhanterade resursgrupper kan du ändra valfri resurs direkt i den communityhanterade resursgruppen. Att ändra resurser direkt i den community-hanterade resursgruppen kan leda till att din enklav blir instabil eller slutar svara.

Enklavhanterad resursgrupp

Den enklaverhanterade resursgruppen innehåller de infrastrukturresurser som beskrivs i Vad är en enklav?.

Namnet på den enklaverhanterade resursgruppen följer den här namngivningskonventionen: myEnclaveName-HostedResources-<GUID>. Varje enklavdistribution skapar den här resursgruppen och placerar enklaverinfrastrukturen i den. När du tar bort enklaven tar resursprovidern Azure Enclave automatiskt bort den enklaverhanterade resursgruppen.

Skärmbild som visar ett exempel på enklavens resurser som hanteras av Azure Enclave.

Den enklaverhanterade resursgruppen har följande begränsningar:

  • Du kan inte ange en befintlig resursgrupp för den enklaverhanterade resursgruppen.
  • Du kan inte ange en annan prenumeration för den enklavens hanterade resursgrupp.
  • Du kan inte ändra namnet på enklavhanterad resursgrupp när enklaven har skapats.
  • Du kan inte ange namn för de hanterade resurserna i den enklavens hanterade resursgrupp.
  • Du kan inte ändra eller ta bort taggar som har skapats av Azure för de hanterade resurserna i den enklavhanterade resursgruppen.

Om du ändrar eller tar bort Azure skapade taggar, resurser och andra resursegenskaper i den enklaverhanterade resursgruppen kan du få oväntade resultat, till exempel nätverks-, åtkomst- och övervakningsfel. Eftersom Azure Enclave hanterar livscykeln för infrastrukturen i den enklaverhanterade resursgruppen kan eventuella ändringar flytta enklaven till ett tillstånd som inte stöds.

Ett vanligt scenario där du vill ändra resurser är genom taggar. Azure Enclave kan du skapa och ändra taggar som sprids till resurser i den enklaverhanterade resursgruppen. Du kanske vill skapa eller ändra anpassade taggar, till exempel för att tilldela en affärsenhet eller ett kostnadsställe. Resurstaggning kan också uppnås genom att skapa Azure principer med ett omfång för den enklaverhanterade resursgruppen.

Varning

Om du ändrar resurser i den enklaverhanterade resursgruppen kan enklaven bli instabil eller inte svara.

Resursgrupp för arbetsbelastning

Arbetsbelastningen är länkad till en eller flera resursgrupper där du kan skapa och organisera dina Azure resurser.

Lägga till en resursgrupp i en arbetsbelastning

Om du lägger till en ny resursgrupp måste användaren normalt ha behörighet att skapa en ny resursgrupp. Rollerna Owner eller Contributor på prenumerationsnivå har den här behörigheten, men personen som skapar arbetsbelastningens resursgrupp kanske inte har eller behöver den här behörigheten med utökade privilegier. Azure Enclave försöker skapa den nya resursgruppen på tre sätt, från högsta till lägsta behörighetskrav, vilket ger användaren flexibilitet:

  • Alternativ 1: Kräver de mest privilegierade behörigheterna för den enskilde som skapar eller uppdaterar arbetsbelastningen, vilket ger fullständig kontroll men kräver förhöjd åtkomst.
  • Alternativ 2: Innebär manuell konfiguration av användaren för att bevilja vårt Mission Enclave programägarskap på prenumerationsnivå, vilket kanske inte överensstämmer med dina inställningar.
  • Alternativ 3: Kräver inga behörigheter för användaren eller Mission Enclave programmet, vilket gör det till den enklaste metoden, men att införa en strikt 1:1-relation mellan resursgruppen och arbetsbelastningen.

Varje alternativ har fördelar och begränsningar, balanskontroll, bekvämlighet och flexibilitet för att passa olika behov. De här alternativen utvärderas från och med alternativ 1 och det första alternativet för att lyckas används för att skapa den nya resursgruppen.

När du har skapat en arbetsbelastningsresursgrupp med hjälp av alternativ 3 visas en varning om att alternativ 3 inte kan användas för nästa arbetsbelastningsresursgrupper för den arbetsbelastningen. Du kan också skapa en ny arbetsbelastning och sedan skapa en ny arbetsbelastningsresursgrupp med hjälp av alternativ 3 igen.

Lägg till en resursgrupp i din enklaver:

  1. Öppna Azure portalsidan för arbetsbelastningen.
  2. Välj Manage och sedan Resource Groups.
  3. Välj Add a resource group.
  4. I sidofönstret som öppnas väljer du Create new för att ange namnet på den nya tomma resursgruppen eller välj Resource Group listrutan för att välja en befintlig resursgrupp.
  5. Välj OK och sedan Save.

Hur skiljer sig en arbetsbelastningsresursgrupp från andra Azure resursgrupper?

En resursgrupp för arbetsbelastningar är en viktig komponent i Azure Enklavens säkerhet och efterlevnad eftersom det är där dina viktiga resurser skapas. Eftersom dessa arbetsbelastningsresursgrupper är länkade till en arbetsbelastning och arbetsbelastningen är länkad till en enklav, hanterar Azure Enclave borttagningen av arbetsbelastningshanterade resursgrupper.

Dessutom tillämpas principen på arbetsbelastningsresursgrupperna. På samma sätt som communityprinciperna flödar ner till enklaven flödar enklaverprinciperna ned till arbetsbelastningsresurserna och resursgrupperna för arbetsbelastningar. När du skapar en ny resursgrupp för arbetsbelastning ställs rollerna in på enklavnivån och ärvs från abonnemanget. Vissa av dessa principer ärvs från communityn och du kan också skapa principer på enklaven som flödar ned till arbetsbelastningar och resursgrupper för arbetsbelastningar.

Organisera resurser i resursgrupper för arbetsbelastningar

Om du vill dela upp dina resurser i två resursgrupper kan du välja något av följande alternativ:

  • dela upp resurserna mellan två resursgrupper som är länkade till en arbetsbelastning
  • dela upp dessa resurser mellan två arbetsbelastningar som var och en har en eller flera resursgrupper

Borttagning av arbetsbelastning

När en arbetsbelastning tas bort kontrolleras arbetsbelastningsresursgrupperna för att se till att de är tomma. Om arbetsbelastningsresursgrupper innehåller resurser misslyckas den begärda arbetsbelastningsborttagningen och ett fel visas. Om du vill ta bort arbetsbelastningen och resursgrupperna för arbetsbelastningen måste du först tömma resursgrupperna för arbetsbelastningen. Tomma arbetsbelastningsresursgrupper hjälper till att undvika oavsiktlig borttagning av viktiga resurser.

Borttagningen av en resurs som är länkad till arbetsbelastningen följer samma beteende. Om till exempel borttagning av en community begärs men inte alla resursgrupper för arbetsbelastningar är tomma, visar åtgärden ett fel. Töm arbetsbelastningsresursgrupperna och försök igen.

Den arbetsbelastningshanterade resursgruppen har följande begränsningar:

  • Du kan inte ange en befintlig resursgrupp för den arbetsbelastningshanterade resursgruppen.
  • Du kan inte ange en annan prenumeration för den arbetsbelastningshanterade resursgruppen.
  • Du kan inte ändra namnet på den hanterade resursgruppen för arbetsbelastningen när arbetsbelastningen har skapats.
  • Du kan inte ändra eller ta bort taggar som skapats av Azure för hanterade resurser i den arbetsbelastningshanterade resursgruppen.

Ett vanligt scenario där du vill ändra resurser är genom taggar. Med Azure Enclave kan du skapa och ändra taggar som vidarebefordras till resurser i arbetsbelastningens hanterade resursgrupp. Du kanske vill skapa eller ändra anpassade taggar, till exempel för att tilldela en affärsenhet eller ett kostnadsställe. Taggning kan också göras genom att skapa Azure-principer med omfång för den hanterade resursgruppen för arbetsbelastningen.

Andra rekommendationer för Azure

När du skapar dina communities, enklaver och arbetsbelastningar i Azure är det viktigt att komma ihåg följande universella designprinciper:

  • Last updated on