Microsoft Azure Well-Architected Framework är en uppsättning vägledande grundsatser som kan användas för att utvärdera en lösning genom kvalitetspelarna för arkitekturens utmärkthet:
Den här artikeln avslutar den här serien. Läs introduktionen.
Den här vägledningen i den här serien innehåller väldefinierade principer i alla designval. Den här artikeln sammanfattar dessa alternativ. Implementeringen av GitHub: Azure Kubernetes Service (AKS) baslinjekluster för reglerade arbetsbelastningar visar dessa principer, i förekommande fall.
PCI DSS 3.2.1-arbetsbelastningar kräver att du är en välkonstruerad lösning. Även om det är viktigt att anpassa infrastrukturen till PCI-kraven stoppas inte efterlevnaden av värdinfrastrukturen. Att inte ta itu med kvalitetspelarna, särskilt säkerhet, kan äventyra efterlevnaden. Väldefinierade lösningar kombinerar både infrastruktur- och arbetsbelastningsperspektiven för att komma fram till den noggrannhet som krävs för att uppnå kompatibla resultat.
Tillförlitlighet
Tillförlitligheten för reglerade miljöer måste vara förutsägbar så att de kan förklaras konsekvent i granskningssyfte. Följ de grundläggande riktlinjerna i tillförlitlighetsprinciperna. Metodtips för en reglerad miljö sammanfattas i de här avsnitten.
Återställningsmål och haveriberedskap
På grund av den känsliga karaktären hos de data som hanteras i reglerade arbetsbelastningar är återställningsmål och mål för återställningspunkter viktiga att definiera. Vad är acceptabel förlust av CHD? Återställningsinsatser inom CDE omfattas fortfarande av standardkraven. Förvänta dig fel och ha en tydlig återställningsplan för de fel som överensstämmer med roller, ansvarsområden och berättigad dataåtkomst. Problem med livewebbplatser är inte motiverade för att avvika från några regler. Detta är särskilt viktigt i en fullständig haveriberedskapssituation. Ha tydlig dokumentation om haveriberedskap som följer kraven och minimerar oväntad CDE- eller CHD-åtkomst. Efter återställningen granskar du alltid stegen för återställningsprocessen för att säkerställa att ingen oväntad åtkomst har inträffat. Dokumentera affärsmotiveringar för dessa instanser.
Återställning
Om du lägger till strategier för återhämtning och återställning i din arkitektur kan du förhindra behovet av ad hoc-åtkomst till CDE. Systemet bör kunna återställas själv vid det definierade återställningspunktobjektet utan behov av direkt mänsklig inblandning. På så sätt kan du eliminera onödig exponering av CHD, även för de personer som har behörighet att ha nödåtkomst. Återställningsprocessen måste vara granskningsbar.
Hantera säkerhetsrelaterade risker
Granska säkerhetsrisker eftersom de kan vara en källa till arbetsbelastningsavbrott och dataförlust. Investeringarna i säkerhet påverkar även arbetsbelastningens tillförlitlighet.
Driftsprocesser
Tillförlitligheten omfattar alla operativa processer i och i anslutning till CDE. Väldefinierade, automatiserade och testade processer för problem som bildskapande och jump box management-faktor i en välkonstruerad lösning.
Säkerhet
Följ de grundläggande riktlinjerna i principerna för säkerhetsdesign. Metodtips för en reglerad miljö sammanfattas i de här avsnitten.
Kontroll
Styrningsimplementeringen drivs av efterlevnadskraven i PCI-DSS 3.2.1. Detta påverkar de tekniska kontrollerna för att upprätthålla segmentering, komma åt resurser, identifiera sårbarheter och viktigast av allt skydda kunddata.
Strategi för segmentering av företag
För att upprätthålla fullständig isolering rekommenderar vi att du distribuerar den reglerade infrastrukturen i en fristående prenumeration. Om du har flera prenumerationer som är nödvändiga för efterlevnad bör du överväga att gruppera dem under en hanteringsgruppshierarki som tillämpar relevanta Azure-principer enhetligt i dina prenumerationer inom omfånget. I prenumerationen använder du relaterade Azure-principer på prenumerationsnivå för att samla in de breda principer som ska gälla för alla kluster i korthållardatamiljön (CDE). Tillämpa relaterade Azure-principer på resursgruppsnivå för att samla in principer som gäller för en specifik klusterinstans. Dessa principer skapar kärnskyddsmekanismerna i en landningszon.
Isolera PCI-arbetsbelastningen (inom omfånget) från andra arbetsbelastningar (utanför omfånget) när det gäller åtgärder och anslutningar. Du kan skapa isolering genom att distribuera separata kluster. Eller använd segmenteringsstrategier för att upprätthålla separationen. Till exempel använder klustren separata nodpooler så att arbetsbelastningar aldrig delar en virtuell noddator (VM).
Principframtvingande
Framtvinga säkerhetskontroller genom att aktivera Azure-principer. I den här reglerade arkitekturen kan du till exempel förhindra felkonfiguration av korthållardatamiljön. Du kan tillämpa en Azure-princip som inte tillåter offentliga IP-allokeringar på de virtuella datornoderna. Sådana allokeringar identifieras och rapporteras eller blockeras.
Information om principer som du kan aktivera för AKS finns i Inbyggda Azure Policy-definitioner för Azure Kubernetes Service.
Azure tillhandahåller flera inbyggda principer för de flesta tjänster. Granska de här inbyggda principdefinitionerna i Azure Policy och tillämpa dem efter behov.
Efterlevnadsövervakning
Efterlevnaden måste övervakas och upprätthållas systematiskt. Regelbundna efterlevnadsattester utförs. Att veta om dina molnresurser är i kompatibilitet hjälper dig att förbereda för attesteringar och granskning.
Dra nytta av instrumentpanelen för regelefterlevnad i Microsoft Defender för molnet. Genom att kontinuerligt övervaka instrumentpanelen kan du hålla reda på arbetsbelastningens efterlevnadsstatus.
Nätverkssäkerhet
I en topologi med nav-ekrar ger separata virtuella nätverk för varje entitet grundläggande segmentering i nätverksfotavtrycket. Varje nätverk segmenteras ytterligare i undernät.
AKS-klustret utgör kärnan i CDE. Den ska inte vara tillgänglig från offentliga IP-adresser och anslutningen måste skyddas. Vanliga flöden in och ut ur CDE kan kategoriseras som:
- Inkommande trafik till klustret.
- Utgående trafik från klustret.
- Klustertrafik mellan poddar.
För att uppfylla kraven i en reglerad miljö distribueras klustret som ett privat kluster. I det här läget är trafiken till och från det offentliga Internet begränsad. Även kommunikationen med DEN AKS-hanterade Kubernetes API-servern är privat. Säkerheten förbättras ytterligare med strikta nätverkskontroller och IP-brandväggsregler.
- Nätverkssäkerhetsgrupper (NSG:er) för att skydda kommunikationen mellan resurser i ett nätverk.
- Azure Firewall för att filtrera all utgående trafik mellan molnresurser, Internet och lokalt.
- Azure Application Gateway är integrerat med Azure Web Application Framework för att filtrera all inkommande trafik från internet som Azure Application Gateway fångar upp.
- Kubernetes NetworkPolicy tillåter endast vissa sökvägar mellan poddarna i klustret.
- Azure Private Link för att ansluta till andra PaaS-tjänster (Azure Platform as a Service), till exempel Azure Key Vault och Azure Container Registry för operativa uppgifter.
Övervakningsprocesser finns på plats för att se till att trafiken flödar som förväntat och att eventuella avvikelser identifieras och rapporteras.
Mer information om nätverkssäkerhet finns i Nätverkssegmentering.
Datasäkerhet
PCI-DSS 3.2.1 kräver att alla korthållardata (CHD) aldrig är tydliga, oavsett om de överförs eller lagras.
Eftersom den här arkitekturen och implementeringen fokuserar på infrastruktur och inte på arbetsbelastningen visas inte datahantering. Här följer några väldefinierade rekommendationer.
Vilande data
Data måste krypteras via krypteringsalgoritmer av branschstandard.
- Lagra inte data i korthållarmiljön.
- Kryptera utanför lagringsskiktet.
- Skriv endast krypterade data till lagringsmediet.
- Lagra inte nycklarna i lagringsskiktet.
Alla data i Azure Storage krypteras och dekrypteras med hjälp av stark kryptografi. Självhanterade krypteringsnycklar föredras.
Om du behöver lagra data tillfälligt bör du använda samma överväganden för dessa data. Vi rekommenderar starkt att du aktiverar funktionen för värdkryptering i AKS. Du kan framtvinga kryptering av tillfälliga data med inbyggda Azure-principer.
När du väljer en lagringsteknik kan du utforska kvarhållningsfunktionerna. Kontrollera att alla data tas bort på ett säkert sätt när den konfigurerade tiden upphör att gälla.
Standarden kräver också att känsliga autentiseringsdata (SAD) inte lagras. Kontrollera att data inte exponeras i loggar, filnamn, cacheminnen och andra data.
Data under överföring
All kommunikation med entiteter som interagerar med CDE måste vara över krypterade kanaler.
- Endast HTTPS-trafik måste tillåtas flöda till CDE. I den här arkitekturen nekar Azure Application Gateway all trafik via port 80.
- Kryptera och dekryptera helst inte data utanför CDE. Om du gör det bör du betrakta den entiteten som en del av CDE.
- I CDE tillhandahåller du säker kommunikation mellan poddar med mTLS. Du kan välja att implementera ett tjänstnät för detta ändamål.
- Tillåt endast säkra chiffer och TLS 1.2 eller senare.
Identitet
Följ dessa säkerhetsprinciper när du utformar åtkomstprinciper:
- Börja med nollförtroendeprinciper. Gör undantag efter behov.
- Bevilja minsta möjliga behörighet – tillräckligt för att slutföra en uppgift.
- Minimera stående åtkomst.
Rollbaserad åtkomstkontroll i Kubernetes (RBAC) hanterar behörigheter till Kubernetes-API:et. AKS stöder dessa Kubernetes-roller. AKS är helt integrerat med Microsoft Entra ID. Du kan tilldela Microsoft Entra-identiteter till rollerna och även dra nytta av andra funktioner.
Zero-Trust-åtkomst
Kubernetes RBAC-, Azure RBAC- och Azure-tjänster implementerar neka alla som standard. Åsidosätt den inställningen med försiktighet, vilket ger åtkomst till endast de entiteter som behöver den. Ett annat område för att implementera Noll förtroende är att inaktivera SSH-åtkomst till klusternoderna.
Minsta behörighet
Du kan använda hanterade identiteter för Azure-resurser och poddar och begränsa dem till förväntade uppgifter. Azure Application Gateway måste till exempel ha behörighet att hämta hemligheter (TLS-certifikat) från Azure Key Vault. Den får inte ha behörighet att ändra hemligheter.
Minimera stående åtkomst
Minimera stående åtkomst med hjälp av just-in-time-gruppmedlemskap för Microsoft Entra. Härda kontrollen med principer för villkorlig åtkomst i Microsoft Entra-ID. Det här alternativet stöder många användningsfall, till exempel multifaktorautentisering, begränsning av autentisering till enheter som hanteras av din Microsoft Entra-klientorganisation eller blockerar atypiska inloggningsförsök.
Hemlighetshantering
Lagra hemligheter, certifikat, nycklar och lösenord utanför CDE. Du kan använda inbyggda Kubernetes-hemligheter eller ett hanterat nyckelarkiv, till exempel Azure Key Vault. Om du använder ett hanterat arkiv kan du använda hemliga hanteringsuppgifter, till exempel nyckelrotation och certifikatförnyelse.
Kontrollera att åtkomsten till nyckelarkivet har en kombination av nätverks- och åtkomstkontroller. När du aktiverar hanterade identiteter måste klustret autentisera sig mot Key Vault för att få åtkomst. Dessutom får anslutningen till nyckelarkivet inte vara via det offentliga Internet. Använd ett privat nätverk, till exempel Private Link.
Kostnadsoptimering
Följ de grundläggande riktlinjerna i principerna för kostnadsoptimering.
På grund av efterlevnadskraven och de strikta säkerhetskontrollerna är en tydlig kompromiss kostnaden. Vi rekommenderar att du upprättar inledande uppskattningar med hjälp av priskalkylatorn.
Här är en övergripande representation av kostnadspåverkan för de viktigaste resurserna som används i den här arkitekturen.
De viktigaste drivrutinerna är vm-skalningsuppsättningar som utgör nodpoolerna och Azure Firewall. En annan deltagare är Log Analytics. Det finns också inkrementella kostnader som är kopplade till Microsoft Defender för molnet, beroende på ditt val av planer.
Ha en tydlig förståelse för vad som utgör priset för en tjänst. Azure spårar mätningsanvändning. Här är en detaljvisning av Azure Firewall för den här arkitekturen.
Kostnaden som är kopplad till vissa resurser, till exempel Azure Firewall, kan spridas över flera affärsenheter eller program. Ett annat sätt att optimera kostnaden kan vara att vara värd för ett kluster med flera klientorganisationer i en organisation, vilket maximerar densiteten med arbetsbelastningsdiversitet. Vi rekommenderar dock inte den här metoden för reglerade arbetsbelastningar. Prioritera alltid efterlevnad och segmentering framför kostnadsfördelar.
För att hålla sig inom budgetbegränsningarna är vissa sätt att kontrollera kostnaderna genom att justera Azure Application Gateway-infrastrukturen, ange antalet instanser för automatisk skalning och minska loggutdata så länge de fortfarande uppfyller granskningsspåret som krävs av PCI-DSS 3.2.1. Utvärdera alltid dessa val mot kompromisser om andra aspekter av designen som gör att du kan uppfylla ditt serviceavtal. Kan du till exempel fortfarande skala på rätt sätt för att möta trafiktoppar?
När du skapar grupper med Azure-resurser använder du taggar så att de kan spåras mot kostnad. Använd kostnadshanteringsverktyg som Azure Advisor och Microsoft Cost Management för att spåra och analysera kostnader.
Överväg att aktivera AKS-kostnadsanalys för detaljerad klusterinfrastrukturkostnadsallokering av Kubernetes-specifika konstruktioner.
Driftseffektivitet
Följ de grundläggande riktlinjerna i principerna för driftskvalitet. Metodtips för en reglerad miljö sammanfattas i de här avsnitten.
Uppdelning av roller
Det är viktigt att säkerställa en tydlig uppdelning av uppgifter för reglerade miljöer. Ha definitioner av roller och ansvarsområden baserat på arbetsbelastningens behov och interaktion med CDE. Du kan till exempel behöva en infrastrukturoperatörs- eller platstillförlitlighetsteknikerroll (SRE) för åtgärder relaterade till klustret och beroende tjänster. Rollen ansvarar för att upprätthålla säkerhet, isolering, distribution och observerbarhet. Formalisera dessa definitioner och bestäm vilka behörigheter som dessa roller behöver. SRI:er är till exempel mycket privilegierade för klusteråtkomst men behöver läsåtkomst till arbetsbelastningsnamnområden.
Arbetsbelastningsisolering
PCI-DSS 3.2.1 kräver isolering av PCI-arbetsbelastningen från andra arbetsbelastningar när det gäller åtgärder. I den här implementeringen segmenteras arbetsbelastningarna inom omfång och utanför omfånget i två separata användarnodpooler. Programutvecklare för omfångs- och utvecklare för arbetsbelastningar utanför omfånget kan ha olika uppsättningar med behörigheter. Dessutom kommer det att finnas separata kvalitetsgrindar. Koden inom omfånget omfattas till exempel av upprätthållande av efterlevnad och attestering, medan koden utanför omfånget inte är det. Det finns också ett behov av att ha separata bygg-pipelines och versionshanteringsprocesser.
Operativa metadata
Krav 12 i PCI DSS 3.2.1-standarden kräver att du underhåller information om arbetsbelastningsinventering och dokumentation om personalåtkomst. Vi rekommenderar starkt att du använder Azure-taggar eftersom du kan sortera miljöinformation med Azure-resurser, resursgrupper och prenumerationer.
Underhåll information om godkända lösningar som ingår i infrastrukturen och arbetsbelastningen. Detta inkluderar en lista över vm-avbildningar, databaser och lösningar från tredje part som du väljer att använda för CDE. Du kan till och med automatisera processen genom att skapa en tjänstkatalog. Den tillhandahåller självbetjäningsdistribution med hjälp av de godkända lösningarna i en specifik konfiguration, som följer pågående plattformsåtgärder.
Överskådlighet
För att uppfylla krav 10 är observerbarhet i CDE avgörande för efterlevnad. Aktivitetsloggar innehåller information om åtgärder som rör konto- och hemlig hantering, hantering av diagnostikinställningar, serverhantering och andra resursåtkomståtgärder. Alla loggar registreras med datum, tid, identitet och annan detaljerad information. Behåll loggar i upp till ett år genom att konfigurera principer för datakvarhållning och arkivering i Azure Monitor-loggar.
Kontrollera att loggar endast används av roller som behöver dem. Log Analytics och Microsoft Sentinel har stöd för olika rollbaserade åtkomstkontroller för att hantera åtkomst till spårningsloggar.
Svar och reparation
Azure Monitoring Services, Azure Monitor och Microsoft Defender för molnet, kan generera meddelanden eller aviseringar när de identifierar avvikande aktivitet. Dessa aviseringar innehåller kontextinformation som allvarlighetsgrad, status och aktivitetstid. När aviseringar genereras har du en reparationsstrategi och granskar förloppet. Vi rekommenderar att du centraliserar data i en SIEM-lösning (säkerhetsinformation och händelsehantering), eftersom integrering av data kan ge omfattande aviseringskontext.
I vyn Säkerhetsaviseringar i Microsoft Defender för molnet har du åtkomst till alla aviseringar som Microsoft Defender för molnet identifierar på dina resurser. Ha en sorteringsprocess för att åtgärda problemet. Samarbeta med säkerhetsteamet för att förstå hur relevanta aviseringar kommer att göras tillgängliga för arbetsbelastningsägarna.
Prestandaeffektivitet
Följ de grundläggande riktlinjerna i principerna för prestandaeffektivitet. Metodtips för en reglerad miljö sammanfattas i de här avsnitten.
Skalning
Om du observerar hur miljön anpassas till ändrade krav kommer det att indikera det förväntade körningsbeteendet för miljön under hög belastning. Automatisk skalning av resurser i arbetsbelastningen minimerar mänsklig interaktion i CDE. En extra säkerhetsförmån är att minska attackytan hela tiden. Du kan maximera fördelen genom att dra nytta av resurser som stöder metoden skala till noll. AKS har till exempel stöd för att skala ned användarnodpoolerna till 0. Mer information finns i Skala användarnodpooler till 0.
Partitionering
Partitionering är en nyckelfaktor för prestandaeffektivitet i reglerade arbetsbelastningar. Att ha diskreta komponenter möjliggör skarp definition av ansvar och hjälper till med exakta kontroller, till exempel nätverksprinciper. På samma sätt som med alla segmenteringsstrategier isolerar partitionering komponenter och styr effekten av explosionsradien på oväntade fel eller systemkompromisser.
Arkitektur för delat ingenting
Arkitekturen shared-nothing är utformad för att ta bort konkurrens mellan samlokaliserade arbetsbelastningar. Det här är också en strategi för att ta bort enskilda felpunkter. I en reglerad miljö måste komponenter isoleras av logiska eller fysiska gränser. Detta överensstämmer med arkitekturen shared-nothing, vilket resulterar i skalbarhetsfördelar. Det gör det också möjligt att rikta in sig på relevanta säkerhetskontroller och strängare granskningsfunktioner för de olika komponenterna.
Lätta arbetsbelastningar
Komplexiteten i arbetsbelastningar är svår att dokumentera och granska. Sträva efter enkelhet på grund av prestandafördelarna och förenklade regler för granskning. Ompröva val som har mer bredd än vad som behövs, eftersom det ökar attackytan och risken för missbruk eller felkonfiguration.