Säkerhetsöverväganden för verksamhetskritiska arbetsbelastningar i Azure

Säkerhet är en av de grundläggande designprinciperna och även ett viktigt designområde som måste behandlas som ett förstklassigt problem inom den verksamhetskritiska arkitekturprocessen.

Eftersom huvudfokus för en verksamhetskritisk design är att maximera tillförlitligheten så att programmet förblir högpresterande och tillgängligt, fokuserar de säkerhetsöverväganden och rekommendationer som tillämpas inom det här designområdet på att minimera hot med kapacitet att påverka tillgängligheten och hindra den övergripande tillförlitligheten. Till exempel är lyckade Denial-Of-Service-attacker (DDoS) kända för att ha en katastrofal inverkan på tillgänglighet och prestanda. Hur ett program minimerar dessa attackvektorer, till exempel SlowLoris, påverkar den övergripande tillförlitligheten. Programmet måste därför vara helt skyddat mot hot som är avsedda att direkt eller indirekt äventyra programmets tillförlitlighet så att det verkligen är verksamhetskritiskt.

Det är också viktigt att notera att det ofta finns betydande kompromisser som är kopplade till en förstärkt säkerhetsstatus, särskilt när det gäller prestanda, driftsflexibilitet och i vissa fall tillförlitlighet. Till exempel medför införandet av infogade virtuella nätverksinstallationer (NVA) för nästa generations brandväggsfunktioner (NGFW), till exempel djup paketinspektion, en betydande prestandaförseningar, ytterligare driftkomplexitet och en tillförlitlighetsrisk om skalbarhets- och återställningsåtgärder inte är nära anpassade till programmets. Det är därför viktigt att ytterligare säkerhetskomponenter och metoder som är avsedda att minimera viktiga hotvektorer också är utformade för att stödja tillförlitlighetsmålet för ett program, vilket utgör en viktig aspekt av de rekommendationer och överväganden som presenteras i det här avsnittet.

Viktigt

Den här artikeln är en del av azure Well-Architected verksamhetskritiska arbetsbelastningsserie . Om du inte är bekant med den här serien rekommenderar vi att du börjar med en verksamhetskritisk arbetsbelastning?

verksamhetskritiska öppen källkod projekt

Referensimplementeringarna är en del av ett öppen källkod projekt som är tillgängligt på GitHub. Kodtillgångarna använder en Nolltillit modell för att strukturera och vägleda säkerhetsdesignen och implementeringsmetoden.

Justering med den Nolltillit modellen

Microsoft Nolltillit-modellen tillhandahåller en proaktiv och integrerad metod för att tillämpa säkerhet i alla lager i ett program. De vägledande principerna för Nolltillit strävar efter att explicit och kontinuerligt verifiera varje transaktion, kontrollera lägsta behörighet, använda intelligens och avancerad identifiering för att svara på hot i nära realtid. Den fokuserar slutligen på att eliminera förtroende inom och utanför programperimetern, vilket framtvingar verifiering för allt som försöker ansluta till systemet.

Designöverväganden

När du utvärderar programmets säkerhetsstatus börjar du med dessa frågor som grund för varje övervägande.

• Kontinuerlig säkerhetstestning för att validera åtgärder för viktiga säkerhetsrisker.

  • Utförs säkerhetstestning som en del av automatiserade CI/CD-processer?
  • Om inte, hur ofta utförs specifik säkerhetstestning?
  • Mäts testresultat mot önskad säkerhetsstatus och hotmodell?

• Säkerhetsnivå i alla lägre miljöer.

  • Har alla miljöer inom utvecklingslivscykeln samma säkerhetsstatus som produktionsmiljön?

• Autentisering och auktoriseringskontinuitet i händelse av ett fel.

  • Kommer programmet att kunna fortsätta att fungera om autentiserings- eller auktoriseringstjänster är tillfälligt otillgängliga?

• Automatiserad säkerhetsefterlevnad och reparation.

  • Kan ändringar av viktiga säkerhetsinställningar identifieras?
  • Automatiseras svar för att åtgärda icke-kompatibla ändringar?

• Hemlig genomsökning för att identifiera hemligheter innan kod checkas in för att förhindra hemliga läckor via källkodslagringsplatser.

  • Är autentisering till tjänster möjligt utan att ha autentiseringsuppgifter som en del av koden?

• Skydda programvaruleveranskedjan.

  • Är det möjligt att spåra vanliga säkerhetsrisker och exponeringar (CVE) i använda paketberoenden?
  • Finns det en automatiserad process för att uppdatera paketberoenden?

• Livscykeler för dataskyddsnycklar.

  • Kan tjänsthanterade nycklar användas för dataskydd?
  • Hur är den säkra och tillförlitliga nyckellivscykeln om kundhanterade nycklar krävs?

• CI/CD-verktyg bör kräva Microsoft Entra tjänstens huvudnamn med tillräcklig åtkomst på prenumerationsnivå för att underlätta kontrollplansåtkomst för Azure-resursdistributioner till alla miljöprenumerationer som betraktas.

  • När programresurser är låsta i privata nätverk finns det en privat dataplansanslutningssökväg så att CI/CD-verktyg kan utföra distributioner och underhåll på programnivå.
    • Detta medför ytterligare komplexitet och kräver en sekvens i distributionsprocessen via nödvändiga privata byggagenter.

Designrekommendationer

• Använd Azure Policy för att framtvinga säkerhets- och tillförlitlighetskonfigurationer för alla tjänster, vilket säkerställer att alla avvikelser antingen åtgärdas eller förbjuds av kontrollplanet vid konfigurationen, vilket bidrar till att minska hot som är associerade med "skadliga administratörsscenarier".

• Använd Microsoft Entra Privileged Identity Management (PIM) i produktionsprenumerationer för att återkalla varaktig kontrollplansåtkomst till produktionsmiljöer. Detta minskar avsevärt risken för "skadliga administratörsscenarier" genom ytterligare "kontroller och saldon".

• Använd Azure Managed Identities för alla tjänster som stöder funktionen, eftersom det underlättar borttagningen av autentiseringsuppgifter från programkoden och tar bort den operativa belastningen för identitetshantering för kommunikation mellan tjänster.

• Använd Microsoft Entra rollbaserad åtkomstkontroll (RBAC) för auktorisering av dataplan med alla tjänster som stöder funktionen.

• Använd Microsofts identitetsplattform autentiseringsbibliotek från första part i programkoden för att integrera med Microsoft Entra ID.

• Överväg säker tokencachelagring för att möjliggöra en degraderad men tillgänglig upplevelse om den valda identitetsplattformen inte är tillgänglig eller bara delvis är tillgänglig för programauktorisering.

  • Om providern inte kan utfärda nya åtkomsttoken, men fortfarande validerar befintliga, kan programmet och de beroende tjänsterna fungera utan problem tills deras token upphör att gälla.
  • Cachelagring av token hanteras vanligtvis automatiskt av autentiseringsbibliotek (till exempel MSAL).

• Använd Infrastruktur som kod (IaC) och automatiserade CI/CD-pipelines för att driva uppdateringar av alla programkomponenter, även under felsituationer.

  • Se till att CI/CD-verktygstjänstens anslutningar skyddas som kritisk känslig information och bör inte vara direkt tillgängliga för något tjänstteam.
  • Använd detaljerad RBAC på CD-pipelines för produktion för att minska riskerna för "skadlig administratör".
  • Överväg att använda manuella godkännandegrindar i pipelines för produktionsdistribution för att ytterligare minska riskerna för "skadlig administratör" och ge ytterligare teknisk säkerhet för alla produktionsändringar.
    • Ytterligare säkerhetsgrindar kan komma i en kompromiss när det gäller flexibilitet och bör utvärderas noggrant, med hänsyn till hur smidighet kan upprätthållas även med manuella grindar.

• Definiera en lämplig säkerhetsstatus för alla lägre miljöer för att säkerställa att viktiga säkerhetsrisker minimeras.

  • Tillämpa inte samma säkerhetsstatus som produktion, särskilt när det gäller dataexfiltrering, såvida inte regelkrav föreskriver behovet av att göra det, eftersom detta avsevärt kommer att äventyra utvecklarnas flexibilitet.

• Aktivera Microsoft Defender för molnet (kallades tidigare Azure Security Center) för alla prenumerationer som innehåller resurserna för en verksamhetskritisk arbetsbelastning.

  • Använd Azure Policy för att framtvinga efterlevnad.
  • Aktivera Azure Defender för alla tjänster som stöder funktionen.

• Använd DevSecOps och implementera säkerhetstestning i CI/CD-pipelines.

  • Testresultaten bör mätas mot en kompatibel säkerhetsstatus för att informera om godkännanden av versioner, oavsett om de är automatiserade eller manuella.
  • Tillämpa säkerhetstestning som en del av CD-produktionsprocessen för varje version.
    • Om säkerhetstestning av varje version äventyrar driftsflexialiteten kontrollerar du att en lämplig säkerhetstestningstakt tillämpas.

• Aktivera genomsökning av hemligheter och beroenden i källkodslagringsplatsen.

Hotmodellering

Hotmodellering ger en riskbaserad metod för säkerhetsdesign med hjälp av identifierade potentiella hot för att utveckla lämpliga säkerhetsminskningar. Det finns många möjliga hot med varierande sannolikhet för förekomst, och i många fall kan hoten kedjas på oväntade, oförutsägbara och till och med kaotiska sätt. Den här komplexiteten och osäkerheten är anledningen till att traditionella teknikkravsbaserade säkerhetsmetoder i stort sett är olämpliga för verksamhetskritiska molnprogram. Förvänta dig att processen med hotmodellering för ett verksamhetskritiskt program är komplex och orubblig.

För att hjälpa dig att navigera i de här utmaningarna bör du använda en djupskyddsmetod i lager för att definiera och implementera kompenserande åtgärder för modellerade hot, med tanke på följande defensiva lager.

1. Azure-plattformen med grundläggande säkerhetsfunktioner och kontroller.
2. Programarkitekturen och säkerhetsdesignen.
3. Säkerhetsfunktioner som är inbyggda, aktiverade och distribuerbara tillämpas på säkra Azure-resurser.
4. Programkod och säkerhetslogik.
5. Operativa processer och DevSecOps.

Anteckning

När du distribuerar i en Azure-landningszon bör du vara medveten om att ytterligare ett hotreduceringslager genom etablering av centraliserade säkerhetsfunktioner tillhandahålls av implementeringen av landningszonen.

Designöverväganden

STRIDE tillhandahåller ett enkelt riskramverk för utvärdering av säkerhetshot över viktiga hotvektorer.

• Falsk identitet: Personifiering av personer med auktoritet. Till exempel en angripare som utger sig för att vara en annan användare med hjälp av deras -
  • Identitet
  • Autentisering
• Manipulering av indata: Ändring av indata som skickas till programmet eller brott mot förtroendegränserna för att ändra programkoden. Till exempel en angripare som använder SQL-inmatning för att ta bort data i en databastabell.
  • Dataintegritet
  • Validering
  • Blocklisting/allowlisting
• Avvislighet av åtgärd: Möjlighet att motbevisa åtgärder som redan vidtagits och programmets förmåga att samla in bevis och driva ansvar. Till exempel borttagning av kritiska data utan möjlighet att spåra till en skadlig administratör.
  • Granskning/loggning
  • Signering
• Avslöjande av information: Få tillgång till begränsad information. Ett exempel är en angripare som får åtkomst till en begränsad fil.
  • Kryptering
  • Dataexfiltrering
  • Man-in-the-middle-attacker
• Denial of Service: Skadliga programstörningar för att försämra användarupplevelsen. Till exempel en DDoS botnet-attack, till exempel Slowloris.
  • DDoS
  • Botnets
  • CDN- och WAF-funktioner
• Utökade privilegier: Få privilegierad programåtkomst via autentiseringsexploateringar. En angripare manipulerar till exempel en URL-sträng för att få åtkomst till känslig information.
  • Fjärrkodkörning
  • Auktorisering
  • Isolering

Designrekommendationer

• Allokera teknisk budget inom varje sprint för att utvärdera potentiella nya hot och implementera åtgärder.

• Medvetna ansträngningar bör tillämpas för att säkerställa att säkerhetsreduceringar samlas in inom ett gemensamt teknikkriterier för att öka konsekvensen i alla programtjänstteam.

• Börja med en tjänst efter hotmodellering på tjänstnivå och förena modellen genom att konsolidera trådmodellen på programnivå.

Skydd mot nätverksintrång

Det är viktigt att förhindra obehörig åtkomst till ett verksamhetskritiskt program och omfattande data för att upprätthålla tillgänglighet och skydda dataintegriteten.

Designöverväganden

• Nolltillit förutsätter ett intrångstillstånd och verifierar varje begäran som om den kommer från ett okontrollerat nätverk.

  • En avancerad nätverksimplementering utan förtroende använder mikrosegmentering och distribuerade ingress-/utgående mikroperimeter.

• Azure PaaS-tjänster används vanligtvis via offentliga slutpunkter. Azure tillhandahåller funktioner för att skydda offentliga slutpunkter eller till och med göra dem helt privata.

  • Azure Private Link/privata slutpunkter ger dedikerad åtkomst till en Azure PaaS-resurs med privata IP-adresser och privata nätverksanslutningar.
  • Virtual Network tjänstslutpunkter ger åtkomst på tjänstnivå från valda undernät till valda PaaS-tjänster.
  • Virtual Network Injection tillhandahåller dedikerade privata distributioner för tjänster som stöds, till exempel App Service via en App Service-miljön.
    • Trafik på hanteringsplanet flödar fortfarande via offentliga IP-adresser.

• För tjänster som stöds hanterar Azure Private Link med privata Azure-slutpunkter dataexfiltreringsrisker som är associerade med tjänstslutpunkter, till exempel en skadlig administratör som skriver data till en extern resurs.

• När du begränsar nätverksåtkomsten till Azure PaaS-tjänster med hjälp av privata slutpunkter eller tjänstslutpunkter krävs en säker nätverkskanal för att distributionspipelines ska få åtkomst till både Azure-kontrollplanet och dataplanet för Azure-resurser för att distribuera och hantera programmet.

  • Privata lokala byggagenter som distribuerats till ett privat nätverk eftersom Azure-resursen kan användas som proxy för att köra CI/CD-funktioner över en privat anslutning. Ett separat virtuellt nätverk bör användas för byggagenter.
    • Anslutning till privata byggagenter från CI/CD-verktyg krävs.
  • En annan metod är att ändra brandväggsreglerna för resursen direkt i pipelinen för att tillåta en anslutning från en offentlig IP-adress för Azure DevOps-agenten, där brandväggen sedan tas bort när uppgiften har slutförts.
    • Den här metoden gäller dock endast för en delmängd av Azure-tjänster. Detta är till exempel inte möjligt för privata AKS-kluster.
  • För att utföra utvecklar- och administrativa uppgifter i programtjänstens hopprutor kan du använda.

• Slutförandet av administrations- och underhållsaktiviteter är ytterligare ett scenario som kräver anslutning till dataplanet för Azure-resurser.

• Tjänst Connections med motsvarande Microsoft Entra tjänstens huvudnamn kan användas i Azure DevOps för att tillämpa RBAC via Microsoft Entra ID.

• Tjänsttaggar kan tillämpas på nätverkssäkerhetsgrupper för att underlätta anslutningen med Azure PaaS-tjänster.

• Programsäkerhetsgrupper omfattar inte flera virtuella nätverk.

• Paketinsamling i Azure Network Watcher är begränsad till en maximal period på fem timmar.

Designrekommendationer

• Begränsa åtkomsten till det offentliga nätverket till det absoluta minimum som krävs för att programmet ska uppfylla sitt affärssyfte för att minska den externa attackytan.

  • Använd Azure Private Link för att upprätta privata slutpunkter för Azure-resurser som kräver säker nätverksintegrering.
  • Använd värdbaserade privata byggagenter för CI/CD-verktyg för att distribuera och konfigurera Azure-resurser som skyddas av Azure Private Link.
    • Microsoft-värdbaserade agenter kommer inte att kunna ansluta direkt till nätverksintegrerade resurser.

• När du hanterar privata byggagenter öppnar du aldrig en RDP- eller SSH-port direkt till Internet.

  • Använd Azure Bastion för att ge säker åtkomst till Azure Virtual Machines och för att utföra administrativa uppgifter på Azure PaaS via Internet.

• Använd en DDoS-standardskyddsplan för att skydda alla offentliga IP-adresser i programmet.

• Använd Azure Front Door med brandväggsprinciper för webbprogram för att leverera och skydda globala HTTP/S-program som sträcker sig över flera Azure-regioner.

  • Använd validering av rubrik-ID för att låsa offentliga programslutpunkter så att de endast accepterar trafik från Azure Front Door-instansen.

• Om ytterligare krav för nätverkssäkerhet online, till exempel djup paketinspektion eller TLS-inspektion, kräver användning av Azure Firewall Premium eller Virtuell nätverksinstallation (NVA) kontrollerar du att den är konfigurerad för maximal hög tillgänglighet och redundans.

• Om det finns krav på paketinsamling använder du Network Watcher paket för att samla in trots det begränsade avbildningsfönstret.

• Använd nätverkssäkerhetsgrupper och programsäkerhetsgrupper för att mikrosegmentera programtrafik.

  • Undvik att använda en säkerhetsinstallation för att filtrera trafikflöden inom program.
  • Överväg att använda Azure Policy för att framtvinga specifika NSG-regler alltid är associerade med programundernät.

• Aktivera NSG-flödesloggar och mata in dem i Traffic Analytics för att få insikter om interna och externa trafikflöden.

• Använd Azure Private Link/privata slutpunkter, där de är tillgängliga, för att skydda åtkomsten till Azure PaaS-tjänster i programdesignen. Information om Azure-tjänster som stöder Private Link finns i Azure Private Link tillgänglighet.

• Om privat slutpunkt inte är tillgänglig och dataexfiltreringsrisker är godtagbara använder du Virtual Network tjänstslutpunkter för att skydda åtkomsten till Azure PaaS-tjänster inifrån ett virtuellt nätverk.

  • Aktivera inte tjänstslutpunkter för virtuellt nätverk som standard i alla undernät eftersom detta medför betydande dataexfiltreringskanaler.

• För hybridprogramscenarier får du åtkomst till Azure PaaS-tjänster lokalt via ExpressRoute med privat peering.

Anteckning

När du distribuerar i en Azure-landningszon bör du vara medveten om att nätverksanslutningen till lokala datacenter tillhandahålls av implementeringen av landningszonen. En metod är att använda ExpressRoute som konfigurerats med privat peering.

Dataskydd

Kryptering är ett viktigt steg mot att säkerställa dataintegritet och är i slutändan en av de viktigaste säkerhetsfunktionerna som kan användas för att minimera en mängd olika hot. Det här avsnittet innehåller därför viktiga överväganden och rekommendationer som rör kryptering och nyckelhantering för att skydda data utan att äventyra programmets tillförlitlighet.

Designöverväganden

• Azure Key Vault har transaktionsgränser för nycklar och hemligheter, med begränsning som tillämpas per valv inom en viss period.

• Azure Key Vault tillhandahåller en säkerhetsgräns eftersom åtkomstbehörigheter för nycklar, hemligheter och certifikat tillämpas på valvnivå.

  • Key Vault åtkomstprinciptilldelningar beviljar behörigheter separat till nycklar, hemligheter eller certifikat.
    • Detaljerade behörigheter på objektnivå till en specifik nyckel, hemlighet eller certifikat är nu möjliga.

• När en rolltilldelning har ändrats finns det en svarstid på upp till 10 minuter (600 sekunder) för rollen som ska tillämpas.

  • Det finns en gräns på 2 000 Azure-rolltilldelningar per prenumeration.

• Azure Key Vault underliggande maskinvarusäkerhetsmoduler (HSM) har FIPS 140-validering.

  • En dedikerad Azure Key Vault hanterad HSM är tillgänglig för scenarier som kräver FIPS 140-2 Nivå 3-efterlevnad.

• Azure Key Vault ger hög tillgänglighet och redundans för att upprätthålla tillgängligheten och förhindra dataförlust.

• Under en redundansväxling i en region kan det ta några minuter för Key Vault-tjänsten att redundansväxla.

  • Under en redundansväxling är Key Vault i skrivskyddat läge, så det går inte att ändra egenskaper för nyckelvalvet, till exempel brandväggskonfigurationer och inställningar.

• Om privat länk används för att ansluta till Azure Key Vault kan det ta upp till 20 minuter innan anslutningen återupprättas under en regional redundansväxling.

• En säkerhetskopia skapar en ögonblicksbild från tidpunkt av en hemlighet, nyckel eller certifikat som en krypterad blob som inte kan dekrypteras utanför Azure. Om du vill hämta användbara data från bloben måste de återställas till en Key Vault i samma Azure-prenumeration och azure-geografi.

  • Hemligheter kan förnyas under en säkerhetskopia, vilket orsakar matchningsfel.

• Med tjänsthanterade nycklar utför Azure viktiga hanteringsfunktioner, till exempel rotation, vilket minskar programåtgärdernas omfattning.

• Regleringskontroller kan föreskriva användning av kundhanterade nycklar för tjänstkrypteringsfunktioner.

• När trafiken flyttas mellan Azure-datacenter används MACsec-datalänklagerkryptering på den underliggande nätverksmaskinvaran för att skydda data under överföring utanför de fysiska gränser som inte kontrolleras av Microsoft eller för Microsofts räkning.

Designrekommendationer

• Använd tjänsthanterade nycklar för dataskydd där det är möjligt, vilket tar bort behovet av att hantera krypteringsnycklar och hantera operativa uppgifter som nyckelrotation.

  • Använd endast kundhanterade nycklar när det finns ett tydligt regelkrav för att göra det.

• Använd Azure Key Vault som en säker lagringsplats för alla hemligheter, certifikat och nycklar om ytterligare krypteringsmekanismer eller kundhanterade nycklar behöver övervägas.

  • Etablera Azure Key Vault med principerna för mjuk borttagning och rensning aktiverade för att tillåta kvarhållningsskydd för borttagna objekt.
  • Använd HSM-säkerhetskopierade Azure Key Vault SKU för programproduktionsmiljöer.

• Distribuera en separat Azure Key Vault-instans inom varje regional distributionsstämpel, vilket ger fördelar med felisolering och prestanda genom lokalisering, samt navigera i skalningsgränser som införts av en enda Key Vault instans.

  • Använd en dedikerad Azure Key Vault-instans för globala programresurser.

• Följ en modell med lägsta behörighet genom att begränsa auktoriseringen för att permanent ta bort hemligheter, nycklar och certifikat till specialiserade anpassade Microsoft Entra roller.

• Se till att krypteringsnycklar och certifikat som lagras i Key Vault säkerhetskopieras, vilket ger en offlinekopia i den osannolika händelsen Key Vault blir otillgänglig.

• Använd Key Vault certifikat för att hantera anskaffning och signering av certifikat.

• Upprätta en automatiserad process för nyckel- och certifikatrotation.

  • Automatisera processen för hantering och förnyelse av certifikat med offentliga certifikatutfärdare för att underlätta administrationen.
    • Ange aviseringar och meddelanden för att komplettera automatiserade certifikatförnyelser.

• Övervaka nyckel-, certifikat- och hemlighetsanvändning.

  • Definiera aviseringar för oväntad användning i Azure Monitor.

Principdriven styrning

Säkerhetskonventioner är i slutändan endast effektiva om de tillämpas konsekvent och holistiskt i alla programtjänster och team. Azure Policy tillhandahåller ett ramverk för att framtvinga säkerhets- och tillförlitlighetsbaslinjer, vilket säkerställer fortsatt efterlevnad av vanliga tekniska kriterier för ett verksamhetskritiskt program. Mer specifikt utgör Azure Policy en viktig del av kontrollplanet för Azure Resource Manager (ARM), vilket kompletterar RBAC genom att begränsa vilka åtgärder behöriga användare kan utföra och kan användas för att genomdriva viktiga säkerhets- och tillförlitlighetskonventioner för de plattformstjänster som används.

Det här avsnittet kommer därför att utforska viktiga överväganden och rekommendationer kring användningen av Azure Policy driven styrning för ett verksamhetskritiskt program, vilket säkerställer att säkerhets- och tillförlitlighetskonventioner tillämpas kontinuerligt.

Designöverväganden

• Azure Policy tillhandahåller en mekanism för att främja efterlevnad genom att tillämpa säkerhets- och tillförlitlighetskonventioner, till exempel användning av privata slutpunkter eller användning av Tillgänglighetszoner.

Anteckning

När du distribuerar inom en Azure-landningszon bör du vara medveten om att tillämpningen av centraliserade baslinjeprinciptilldelningar sannolikt kommer att tillämpas i implementeringen för hanteringsgrupper och prenumerationer för landningszoner.

• Azure Policy kan användas för att driva automatiserade hanteringsaktiviteter, till exempel etablering och konfiguration.

  • Registrering av resursprovider.
  • Validering och godkännande av enskilda Azure-resurskonfigurationer.

• Azure Policy tilldelningsomfång avgör täckningen och platsen för Azure Policy definitioner informerar återanvändningen av anpassade principer.

• Azure Policy har flera gränser, till exempel antalet definitioner i ett visst omfång.

• Det kan ta flera minuter innan körningen av DINE-principer (Deploy If Not Exist) inträffar.

• Azure Policy tillhandahåller viktiga indata för efterlevnadsrapportering och säkerhetsgranskning.

Designrekommendationer

• Mappa regel- och efterlevnadskrav till Azure Policy definitioner.

  • Om det till exempel finns krav på datahemvist bör en princip tillämpas för att begränsa tillgängliga distributionsregioner.

• Definiera vanliga tekniska kriterier för att samla in säkra och tillförlitliga konfigurationsdefinitioner för alla azure-tjänster som används, vilket säkerställer att dessa kriterier mappas till Azure Policy tilldelningar för att framtvinga efterlevnad.

  • Använd till exempel en Azure Policy för att framtvinga användningen av Tillgänglighetszoner för alla relevanta tjänster, vilket säkerställer tillförlitliga distributionskonfigurationer inom regionen.

Referensimplementeringen Verksamhetskritisk innehåller en mängd olika säkerhets- och tillförlitlighetsinriktade principer för att definiera och tillämpa ett exempel på vanliga tekniska kriterier.

• Övervaka tjänstkonfigurationsavvikelser i förhållande till vanliga tekniska kriterier med hjälp av Azure Policy.

För verksamhetskritiska scenarier med flera produktionsprenumerationer under en dedikerad hanteringsgrupp prioriterar du tilldelningar i hanteringsgruppens omfång.

• Använd inbyggda principer där det är möjligt för att minimera driftkostnaderna för att underhålla anpassade principdefinitioner.

• När anpassade principdefinitioner krävs ska du se till att definitionerna distribueras i lämpligt omfång för hanteringsgrupper så att det går att återanvända över omfattande miljöprenumerationer för att tillåta återanvändning av principer i produktionsmiljöer och lägre miljöer.

  • När du justerar programöversikten med Azure-översikter kan du använda tillgängliga Microsoft-resurser för att utforska om kritiska anpassade definitioner kan införlivas som inbyggda definitioner.

Anteckning

När du distribuerar inom en Azure-landningszon bör du överväga att distribuera anpassade Azure Policy definitioner inom det mellanliggande företagets rothanteringsgruppsomfång för att möjliggöra återanvändning i alla program inom den bredare Azure-egendomen. I en landningszonmiljö tillämpas vissa centraliserade säkerhetsprinciper som standard inom högre hanteringsgruppsomfång för att framtvinga säkerhetsefterlevnad i hela Azure-egendomen. Azure-principer bör till exempel tillämpas för att automatiskt distribuera programvarukonfigurationer via VM-tillägg och framtvinga en kompatibel baslinjekonfiguration av virtuella datorer.

• Använd Azure Policy för att framtvinga ett konsekvent taggningsschema i programmet.
  • Identifiera nödvändiga Azure-taggar och använd append-principläget för att framtvinga användning.

Om programmet prenumererar på Microsoft Mission-Critical Support ser du till att det tillämpade taggningsschemat ger meningsfull kontext för att utöka supportupplevelsen med djup programtolkning.

• Exportera Microsoft Entra aktivitetsloggar till den globala Log Analytics-arbetsyta som används av programmet.
  • Se till att Azure-aktivitetsloggar arkiveras i det globala lagringskontot tillsammans med driftdata för långsiktig kvarhållning.

I en Azure-landningszon matas Microsoft Entra aktivitetsloggar också in på den centraliserade plattformens Log Analytics-arbetsyta. Den måste utvärderas i det här fallet om Microsoft Entra ID fortfarande krävs på den globala Log Analytics-arbetsytan.

• Integrera säkerhetsinformation och händelsehantering med Microsoft Defender för molnet (kallades tidigare Azure Security Center).

IaaS-specifika överväganden när du använder Virtual Machines

I scenarier där användning av IaaS-Virtual Machines krävs måste vissa detaljer beaktas.

Designöverväganden

• Avbildningar uppdateras inte automatiskt när de har distribuerats.
• Uppdateringar installeras inte automatiskt på virtuella datorer som körs.
• Bilder och enskilda virtuella datorer är vanligtvis inte förstärkta direkt.

Designrekommendationer

• Tillåt inte direkt åtkomst via det offentliga Internet att Virtual Machines genom att ge åtkomst till SSH, RDP eller andra protokoll. Använd alltid Azure Bastion och jumpboxar med begränsad åtkomst till en liten grupp användare.
• Begränsa direkt internetanslutning med hjälp av nätverkssäkerhetsgrupper, (Azure)-brandväggen eller Application Gateways (nivå 7) för att filtrera och begränsa utgående trafik.
• För flernivåprogram bör du överväga att använda olika undernät och använda nätverkssäkerhetsgrupper för att begränsa åtkomsten däremellan.
• Prioritera användningen av autentisering med offentlig nyckel när det är möjligt. Lagra hemligheter på en säker plats som Azure Key Vault.
• Skydda virtuella datorer med hjälp av autentisering och åtkomstkontroll.
• Tillämpa samma säkerhetsmetoder som beskrivs för verksamhetskritiska programscenarier.

Följ och tillämpa säkerhetsmetoder för verksamhetskritiska programscenarier enligt beskrivningen ovan, när det är tillämpligt, samt rekommenderade säkerhetsmetoder för IaaS-arbetsbelastningar i Azure.

Nästa steg

Granska metodtipsen för operativa procedurer för verksamhetskritiska programscenarier.

Operativa procedurer