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.

Med tanke på att huvudfokus för en verksamhetskritisk design är att maximera tillförlitligheten så att programmet förblir högpresterande och tillgängligt, kommer de säkerhetsöverväganden och rekommendationer som tillämpas inom det här designområdet att fokusera på att minimera hot med kapacitet att påverka tillgängligheten och hindra övergripande tillförlitlighet. 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 för att vara verkligt verksamhetskritisk till sin natur.

Det är också viktigt att notera att det ofta finns betydande kompromisser i samband med en härdad säkerhetsstatus, särskilt när det gäller prestanda, driftsflexibilitet och i vissa fall tillförlitlighet. Till exempel kommer införandet av inline Network Virtual Appliances (NVA) för nästa generations brandväggsfunktioner (NGFW), till exempel djup paketinspektion, att medföra en betydande prestandaavgift, 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.

Justering med Nulta pouzdanost-modellen

Microsoft Nulta pouzdanost-modellen ger en proaktiv och integrerad metod för att tillämpa säkerhet i alla lager i ett program. De vägledande principerna för Nulta pouzdanost strävar efter att explicit och kontinuerligt verifiera varje transaktion, kontrollera minsta behörighet, använda intelligens och avancerad identifiering för att svara på hot i nära realtid. Det är i slutändan centrerat på att eliminera förtroende inom och utanför programperimeter, vilket framtvingar verifiering för allt som försöker ansluta till systemet.

Utformningsbeaktanden

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 verifiera å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 specifika säkerhetstester?
  • Mäts testresultaten mot en ö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?

• Autentiserings- 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 i 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öjlig utan att ha autentiseringsuppgifter som en del av koden?

• Skydda programvaruförsörjningskedjan.

  • Går det att spåra vanliga sårbarheter och exponeringar (CVE) inom 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 anses vara tänkta.

  • 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 ger 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 konfigurationstillfället, vilket bidrar till att minimera hot som är associerade med scenarier med "skadlig administratör".

• 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 scenarier med "skadlig administratör" 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 tjänst-till-tjänst-kommunikation.

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

• Använd Microsoft platforma za identitete-autentiseringsbibliotek från första part i programkoden för att integrera med Microsoft Entra-ID.

• Överväg cachelagring av säker token för att möjliggöra en degraderad men tillgänglig upplevelse om den valda identitetsplattformen inte är tillgänglig eller endast 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 köra 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 med "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 vid 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 anger 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 resurser 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.

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

  • Testresultat bör mätas mot en kompatibel säkerhetsstatus för att informera 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 driftsflexiiteten ska du se till att en lämplig säkerhetstestningstakt tillämpas.

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

Hotmodellering

Hotmodellering ger en riskbaserad metod för säkerhetsdesign med identifierade potentiella hot för att utveckla lämpliga säkerhetsreduceringar. Det finns många möjliga hot med varierande sannolikheter för förekomst, och i många fall kan hot länkas 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 till stor del är olämpliga för verksamhetskritiska molnprogram. Förvänta dig att processen med hotmodellering för ett verksamhetskritiskt program ska vara komplex och orubblig.

För att hjälpa till att navigera i dessa utmaningar bör en djupgående metod i lager användas 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. Inbyggda, aktiverade och distributionsbara säkerhetsfunktioner tillämpas på säkra Azure-resurser.
4. Programkod och säkerhetslogik.
5. Operativa processer och DevSecOps.

Utformningsbeaktanden

STRIDE tillhandahåller ett enkelt riskramverk för att utvärdera säkerhetshot mellan 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
• Manipulationsindata: Ändring av indata som skickas till programmet eller intrång i förtroendegränser 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
• Avvisning 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
• Informationsupplysning: 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 auktoriseringsexploateringar. Till exempel kan en angripare manipulera en URL-sträng för att få åtkomst till känslig information.
  • Fjärrkörning av kod
  • 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 användas för att säkerställa att säkerhetsreduceringar samlas in inom ett gemensamt teknikkriterier för att skapa konsekvens 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.

Utformningsbeaktanden

• Nulta pouzdanost förutsätter ett tillstånd som har brutits 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 privat nätverksanslutning.
  • Tjänstslutpunkter för virtuellt nätverk ger åtkomst på tjänstnivå från valda undernät till valda PaaS-tjänster.
  • Virtuell nätverksinmatning tillhandahåller dedikerade privata distributioner för tjänster som stöds, till exempel App Service via en App Service-miljö.
    • Trafik på hanteringsplanet flödar fortfarande via offentliga IP-adresser.

• För tjänster som stöds hanterar Azure Private Link med hjälp av 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 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 distribueras till ett privat nätverk eftersom Azure-resursen kan användas som proxy för att köra CI/CD-funktioner via en privat anslutning. Ett separat virtuellt nätverk ska 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 i farten i pipelinen så att en anslutning från en offentlig IP-adress för Azure DevOps-agenten tillåts, och brandväggen tas sedan 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 dem.

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

• Tjänstanslutningar med motsvarande Microsoft Entra-tjänsthuvudnamn 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 till Azure PaaS-tjänster.

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

• Paketinsamling i Azure Network Watcher är begränsad till högst 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.

• Öppna aldrig en RDP- eller SSH-port direkt till Internet när du hanterar privata byggagenter.

  • 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 som kommer från Azure Front Door-instansen.

• Om ytterligare säkerhetskrav för in-line-nätverk, till exempel djup paketinspektion eller TLS-inspektion, kräver användning av Azure Firewall Premium eller Virtuell nätverksinstallation (NVA) kontrollerar du att det är konfigurerat 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 att 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 inom 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 risken för dataexfiltrering är acceptabel använder du tjänstslutpunkter för virtuellt nätverk för att skydda åtkomsten till Azure PaaS-tjänster inifrån ett virtuellt nätverk.

  • Aktivera inte tjänstslutpunkter för virtuella 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.

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.

Utformningsbeaktanden

• 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 den roll som ska tillämpas.

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

• Underliggande maskinvarusäkerhetsmoduler i Azure Key Vault (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 regions redundansväxling kan det ta några minuter innan Key Vault-tjänsten redundansväxlar.

  • Under en redundansväxling kommer Key Vault att vara i skrivskyddat läge, så det går inte att ändra nyckelvalvsegenskaper som 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 en 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 blobben måste de återställas till ett Key Vault inom samma Azure-prenumeration och Azure-geografi.

  • Hemligheter kan förnyas under en säkerhetskopia, vilket orsakar ett 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änkskiktskryptering 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, till exempel 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 beaktas.

  • 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-backad 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änserna 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 minst behörighet genom att begränsa auktoriseringen till 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ängligt.

• Använd Key Vault-certifikat för att hantera certifikatanskaffning och signering.

• 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- och certifikatanvändning och hemlig anvä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 med 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), som kompletterar RBAC genom att begränsa vilka åtgärder behöriga användare kan utföra och kan användas för att tillämpa viktiga säkerhets- och tillförlitlighetskonventioner för användningsbaserade plattformstjänster.

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.

Utformningsbeaktanden

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

• 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.

• Tilldelningsomfånget för Azure Policy avgör täckningen och platsen för Azure Policy-definitioner informerar om å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) körs.

• 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 ett vanligt teknikkriterier 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 det här villkoret mappas till Azure Policy-tilldelningar för att framtvinga efterlevnad.

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

Referensimplementeringen för 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 driften av tjänstkonfiguration i förhållande till de vanliga tekniska kriterierna 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 definitioner distribueras i lämpligt hanteringsgruppsomfång så att de kan återanvändas i olika miljöprenumerationer för att möjliggöra återanvändning av principer i produktionsmiljöer och lägre miljöer.

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

• Använd Azure Policy för att framtvinga ett konsekvent taggningsschema i programmet.
  • Identifiera nödvändiga Azure-taggar och använd tilläggsprinciplä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 Även Microsoft Entra-aktivitetsloggar in i den centraliserade plattformens Log Analytics-arbetsyta. Det 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 virtuella datorer

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

Utformningsbeaktanden

• 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 härdade direkt.

Designrekommendationer

• Tillåt inte direkt åtkomst via offentligt Internet till virtuella datorer 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ägg eller Application Gateways (nivå 7) för att filtrera och begränsa utgående trafik.
• För program med flera nivåer bör du överväga att använda olika undernät och använda nätverkssäkerhetsgrupper för att begränsa åtkomsten mellan.
• 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.

Gå vidare

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