Dela via


Utvärdera suveräna krav

Microsoft Cloud Adoption Framework för Azure är ett ramverk för hela livscykeln som hjälper molnarkitekter, IT-proffs och affärsbeslutsfattare att uppnå sina mål för molnimplementering. Det tillhandahåller metodtips, dokumentation och verktyg som hjälper till att skapa och implementera affärs- och teknikstrategier för molnet. Organisationer inom den offentliga sektorn som har strikta suveränitetskrav kan införliva sina suveränitetsmål i sina planeringsinsatser, så att strategiska beslut om molnimplementering är anpassade till dessa suveränitetskrav.

Denna artikel belyser områden där organisationer kanske vill utvärdera, identifiera och dokumentera sina suveränitetskrav, och ger rekommendationer för var dessa krav kan passa in i deras bredare planeringsinsatser kopplade till Cloud Adoption Framework för Azure.

Identifiera suveräna data

Datasuveränitetskrav kan innefatta mandat att behålla äganderätten till data och specificera metoder för lagring, användning och överföring av data. Ibland kan krav på datasuveränitet också innefatta begränsningar eller mandat när det gäller dataresidens. Att förstå dessa krav tidigt i en organisations molnresa kan hjälpa till att etablera gemensamma designmönster för datasuveränitet, snarare än att förvänta sig att arbetsbelastningsägare ska utveckla lösningar för att hantera suveränitetskrav.

Organisationer som följer Cloud Adoption Framework för Azure identifierar kandidatarbetsbelastningar för att migrera till molnet under planeringsfasen och designar sedan miljön för att vara värd för dessa arbetsbelastningar under beredskapsfasen. Dessa aktiviteter kan låta en organisation identifiera suveräna datatyper som kräver särskild hantering i mål-tillståndsmolnmiljön.

Microsoft använder många typer av data, till exempel personlig information som tillhandahålls till Microsoft och kunddata som laddas upp till molntjänster för att leverera online- och professionella tjänster. Microsofts dataskyddsansvar har dokumenterats i Microsoft Products and Services Data Protections Addendum (DPA) och ingår i en organisations avtal med Microsoft. DPA specificerar de olika datatyperna som Microsoft hanterar och beskriver de metoder som används av Microsoft för att skydda dessa datatyper.

Många organisationer har befintliga datastyrningsprogram som specificerar krav för hantering av känsliga data och kan använda denna information för att avgöra om datasuveränitetskrav gäller för alla eller bara en delmängd av dataklassificeringarna. När en organisation laddar upp och underhåller sina data i en molntjänst är det deras ansvar att korrekt klassificera, märka och hantera data enligt sina datahanteringskrav. Vissa organisationer kanske vill använda molnet som en möjlighet att granska sina dataklassificeringsprogram.

För mer information om hur dataklassificering gäller för molnimplementering, se Dataklassificering i Azure och Guider för molnstyrning.

Exempel på krav på datasuveränitet

Organisationer som har strikta krav på datasuveränitet kan behöva planera för några av följande representativa scenarier när de migrerar arbetsbelastningar till molnet.

Märkning för dataklassificering

Klassificeringsetiketter identifierar resurser med särskilda hanteringskrav. Även om klassificeringsetiketter tillämpas på dokument kan de också tillämpas på tillgångar. Kunder kan använda de inbyggda taggningsfunktionerna i Azure för att tillämpa klassificeringsetiketter på resurser såsom beräkningstjänster och datalager och för logiska strukturer i Azure, såsom prenumerationer och hanteringsgrupper.

För mer information, se Tagga i Azure och Microsoft Purview eDiscovery-lösningar.

Dartaklassificeringsgränser

När en organisation väljer att aggregera data (eller program) med en liknande klassificering, används ofta en säkerhetsperimeter för att fungera som gränsen för den plats där dataresidens är tillåten. När kunder distribuerar arbetsbelastningar i Azure kan de använda prenumerationer och hanteringsgrupper för att skapa logiska gränser inom organisationens molnmiljö. Dessa gränser hjälper till att minska konfidentialitetsrisker relaterade till obehörig åtkomst och sekretessrisker relaterade till dataaggregering och attribution.

Organisationer som har strikta krav på datasuveränitet kanske vill överväga om de vill organisera sin miljö i en hierarkisk modell, där högre nivåer av privilegier ärver lägre nivåer av privilegier (till exempel som i Bell-LaPadula-modellen), eller om de föredrar att implementera en icke-hierarkisk modell där obligatoriska åtkomstkontroller används för att skapa gränser som delar upp delar av miljön från resten av miljön. Beslut om hur en organisation hanterar dataklassificeringsgränser är avgörande när man utformar Landing Zones i beredskapsfasen av Cloud Adoption Framework för Azure.

För mer information, se Hanteringsgrupper i Azure och Datastyrning.

Dataresidens

Organisationer som måste uppfylla kraven på dataresidens bör ägna särskild uppmärksamhet åt vilka Azure-tjänster de behöver för att stödja en arbetsbelastning, samt var dessa tjänster är geografiskt tillgängliga. Azure-tjänster distribueras i regioner som stöder nätverksanslutningar med låg latens och funktioner såsom tillgänglighetszoner. Dessa regioner är grupperade i geografier, vilket ger extra funktioner för motståndskraft och katastrofåterställning.

Om en organisation behöver upprätthålla dataresidens för sin arbetsbelastning måste den säkerställa att Azure-tjänsterna som används är tillgängliga i dess föredragna region och geografi. Vissa tjänster distribueras dessutom globalt och erbjuder inte dataresidens inom en viss region eller geografi för data som lagras inom den tjänsten.

Mer information om dataresidens, Azure-regioner och tillgänglighetszoner samt regional tillgänglighet för Azure-tjänster, se följande artiklar:

Ägande, underhåll och portabilitet av data

Kunder med strikta datasuveränitetskrav har ofta många frågor om vem som behåller äganderätten till data som lagras i Azure, vem som kan komma åt den datan och vad som händer med den datan om en kund väljer att flytta sin arbetsbelastning till en annan plattform. Dessa krav kan variera i omfattning och specificitet, men de brukar vara relaterade till den grundläggande frågan om vad som händer med data när de har Microsoft Cloud Service som värd.

För att hjälpa till att hantera dessa frågor på en hög nivå och ge kunderna en utgångspunkt för att identifiera sina datasuveränitetskrav som gäller för molntjänstleverantörer, har Microsoft publicerat en serie artiklar om att skydda och hantera kunddata som tar upp många av dessa frågor, och dessa artiklar finns tillgängliga online i Trust Center.

Mer information finns i Datahantering hos Microsoft.

Behåll operativ suveränitet i molnet

Operativa suveränitetskrav kan påverka hur en miljö i Azure utformas, uppdateras och hanteras. Därför är det viktigt att ha en klar förståelse för dessa krav innan tekniska konstruktioner slutförs som en del av beredskapsfasen av Cloud Adoption Framework för Azure. Vanliga operativa suveränitetskrav kan inkludera följande:

  • Begränsningar av administrativ personals placering och nationalitet.
  • Krav på åtkomstkontroll som begränsar privilegierad åtkomst för molntjänstleverantörer.
  • Behörighet för hög tillgänglighet och haveriberedskap.

Det är viktigt att tydligt förstå avsikten och riskerna som dessa krav minskar, detta eftersom många av dessa krav uppfylls i molnet med andra metoder än vad som vanligtvis används lokalt.

Efter att organisationen har identifierat de operativa suveränitetskraven kan de välja lämpliga tekniska och administrativa suveränitetskontroller i syfte att ge rätt nivå av riskreducering och säkerhet. När du väljer suveränitetskontroller är det viktigt att förstå att val av vissa funktioner som kan ge extra operativ suveränitet begränsar en organisations möjligheter att använda andra Azure-tjänster.

Till exempel måste en organisation som kräver konfidentiell datoranvändning för sina Azure-arbetsbelastningar begränsa sina arkitekturval till tjänster som kan köras på Azure konfidentiell databehandling, såsom Confidential Virtual Machines eller Confidential Containers. Av denna anledning är det ofta en bra idé att associera operativa suveränitetskrav med en given dataklassificering, snarare än att implementera ett tillvägagångssätt där all arbetsbelastning och alla data måste uppfylla den mest restriktiva uppsättningen suveränitetskrav.

Dessutom är vissa operativa suveränitetskrav, såsom Autarky (till exempel att kunna köra oberoende av externa nätverk och system) omöjliga i hyperskaliga molnbaserade plattformar såsom Azure, som förlitar sig på regelbundna plattformsuppdateringar för att hålla systemen i ett optimalt tillstånd.

Exempel på krav för driftsuveränitet

Några vanliga driftsuveränitetskrav tillsammans med exempel på relevanta Azure-tjänster och -funktioner som kan möta dessa krav är följande:

Programvarusäkerhet

Programvarusäkerhetskrav kan innefatta utvecklingsaktiviteter, såsom att tillämpa specifika kryptografiska säkerhetsåtgärder, utföra kodgranskning samt applikationssäkerhet och penetrationstestning. Det kan också inkludera operativa processer, såsom implementering av åtkomstkontroller, användning av krypteringsteknik och övervakning av säkerhetshändelser.

Microsoft tillhandahåller olika funktioner för att hjälpa kunder att uppfylla operativa suveränitetskrav för Microsoft-utvecklad och kundutvecklad programvara. Microsoft följer Secure Development Lifecycle (SDL) vid utveckling av programvara på plattformsnivå för Azure. De 12 tillvägagångssätten i SDL finns inkorporerade i Microsofts tekniska processer och procedurer, och utvärderas regelbundet som en del av Microsofts säkerhetsaktiviteter. Dessutom tillhandahåller Microsoft kapacitet för att hjälpa kunder att använda metoderna för Secure Development Lifecycle som en del av deras programvaruutvecklingslivscykel.

För mer information, se Microsoft Secure Development Lifecycle och Metodtips för säker utveckling på Azure.

Infrastruktursäkerhet

Arbetsbelastningar som körs på Azure kan dra nytta av de många funktioner som Microsoft har utvecklat för att säkerställa plattformens integritet. Funktionerna inkluderar dess firmware, mjukvara och värdinfrastruktur. Organisationer kan ha operativa suveränitetskrav för att isolera sina data från molnoperatörer. Azure tillhandahåller funktioner som kunderna kan använda för att dra fördel av smidigheten och motståndskraften i det offentliga molnet, samtidigt som de behåller sin isolering från molntjänstleverantörer och dessas administrativa personal. Organisationer med krav relaterade till attestering på hårdvarunivå, verifiering av programvarans integritet (till exempel säker uppstart) och säker nyckelhantering, kan granska Microsofts plattformsintegritet och säkerhetspraxis och få tillgång till granskningsdokumentation för att validera implementeringen av dessa funktioner.

För mer information, se Plattformsintegritet och säkerhet och Azure-infrastruktursäkerhet.

Kryptering för vilande data, data som överförs och data som används kan hjälpa till att tillfredsställa ett brett spektrum operativa suveränitetskrav relaterade till datakonfidentialitet och integritet. Organisationer som kräver dessa funktioner måste dock planera för att skapa och hantera krypteringsnycklar. Azure tillhandahåller ett brett utbud av krypteringsmodeller för vilande data som kunderna kan välja mellan, från krypteringsmetoder på klientsidan som ger nollkunskapskryptering för data som lagras i molnet, till tjänstehanterade nycklar som erbjuder den högsta graden av interoperabilitet med inbyggda molntjänster.

Dessutom kan organisationer som vill minimera behovet av förtroende för plattformskomponenter såsom värdoperativsystemet, kerneln, hypervisorn och administrativ personal implementera kryptering av data som används. Azure konfidentiell databehandling inkluderar flera beräkningstjänster som distribueras i hårdvarubaserade säkerhetsenklaver som krypterar data i minnet med hjälp av Intel Software Guard Extensions (SGX) eller AMD Secure Encrypted Virtualization (SEV-SNP).

Organisationer med operativa suveränitetskrav som kräver implementering av kryptering bör bekanta sig med följande krypteringsfunktioner i Azure:

Åtgärder och återhämtning

Operativa säkerhetskrav kan gälla både programvara på plattformsnivå som skapats och hanteras av Microsoft för att driva Azure-plattformen, och kundhanterad programvara som är en del av en arbetsbelastning. Modellen med delat ansvar för molnbaserad databehandling flyttar det administrativa ansvaret från kunden till molntjänstleverantören. Beroende på vilken typ av molntjänst som konsumeras kan Microsoft vara ansvarigt för att hantera och uppdatera den operativsystemfria infrastrukturen i våra datacenter, operativsystem och tjänstekörtider. Microsofts säkerhetsingenjörsorganisation implementerar ett operativt säkerhetsprogram som bygger på rutinerna från Microsoft Secure Development Lifecycle (SDL) med operativa säkerhetsrutiner. Metoderna inkluderar hemlighetshantering, penetrationstestning och säkerhetsövervakning, implementerad av Microsoft Security Response Center.

I sällsynta fall kan Microsoft komma att kräva åtkomst till kunddata i syfte att felsöka ett problem som kan påverka tjänster. Kunder med operativa suveränitetskrav relaterade till ändringskontroll och privilegierad åtkomsthantering kanske vill aktivera Customer Lockbox för Azure så att de kan godkänna åtkomstförfrågningarna som en del av Microsofts supportarbetsflöden.

Dessutom kan kunder med strikta krav för godkännande och schemaläggning av plattformsprogramvaruuppdateringar vilja överväga Azure Dedicated Hosts, som tillåter kunder att använda underhållskonfigurationer för att kontrollera plattformsunderhållsaktiviteter på värdnivå. Dessutom bör kunder se över sina återhämtningskrav för att avgöra om det finns några suveränitetsbaserade begränsningar för de tjänster och regioner som används för värdskapet för arbetsbelastningar.

Operativa suveränitetskrav kring kontinuitet i verksamheten (till exempel att kräva att arbetsbelastningar ska distribueras i högt tillgängliga konfigurationer för att upprätthålla drifttid) kan komma i konflikt med datasuveränitetskrav relaterade till dataresidens (till exempel begränsning av arbetsbelastningar till ett geografiskt område som inte erbjuder olika platser).

Organisationer bör utvärdera dessa krav tidigt och överväga det bästa sättet att balansera dessa krav.