Delen via

Soevereiniteitsvereisten evalueren

  • Artikel

Het Microsoft Cloud Adoption Framework voor Azure is een raamwerk voor de volledige levenscyclus dat cloudarchitecten, IT-professionals en zakelijke besluitvormers helpt hun doelstellingen voor cloudadoptie te bereiken. Het biedt best practices, documentatie en tools die helpen bij het creëren en implementeren van bedrijfs- en technologiestrategieën voor de cloud. Organisaties in de openbare sector die strikte soevereiniteitsvereisten hebben, kunnen hun soevereiniteitsdoelstellingen opnemen in hun planningsinspanningen, zodat strategische beslissingen over de adoptie van de cloud worden afgestemd op die soevereiniteitsvereisten.

In dit artikel worden gebieden belicht waarop organisaties mogelijk hun soevereiniteitsvereisten willen evalueren, identificeren en documenteren, en worden aanbevelingen gedaan voor waar deze vereisten kunnen passen in hun bredere planningsinspanningen die verband houden met het Cloud Adoption Framework voor Azure.

Soevereine gegevens identificeren

Vereisten voor gegevenssoevereiniteit kunnen onder meer bestaan uit mandaten om het eigendom van gegevens te behouden en methoden te specificeren voor de opslag, het gebruik en de overdracht van gegevens. Soms omvatten de vereisten voor gegevenssoevereiniteit ook beperkingen of mandaten met betrekking tot de locatie van gegevens. Het begrijpen van deze vereisten in een vroeg stadium van het cloudtraject van een organisatie kan helpen bij het vaststellen van gemeenschappelijke ontwerppatronen voor gegevenssoevereiniteit, in plaats van te verwachten dat eigenaren van workloads oplossingen ontwikkelen om aan de soevereiniteitsvereisten te voldoen.

Organisaties die het Cloud Adoption Framework voor Azure volgen, identificeren kandidaatworkloads die tijdens de planningsfase naar de cloud willen migreren en ontwerpen vervolgens de omgeving om deze workloads te hosten tijdens de gereedheidsfase. Met deze activiteiten kan een organisatie soevereine gegevenstypen identificeren die een speciale behandeling vereisen in de doelstatuscloudomgeving.

Microsoft gebruikt vele soorten gegevens, zoals persoonlijke gegevens die aan Microsoft worden verstrekt en klantgegevens die naar cloudservices worden geüpload om online en professionele services te leveren. De verantwoordelijkheden op het gebied van gegevensbescherming van Microsoft zijn gedocumenteerd in het addendum voor gegevensbeveiliging (DPA) voor producten en services van Microsoft en opgenomen in de overeenkomsten van een organisatie met Microsoft. De DPA specificeert de verschillende gegevenstypen die Microsoft beheert en beschrijft de praktijken die Microsoft gebruikt om deze gegevenstypen te beschermen.

Veel organisaties beschikken over bestaande gegevensbeheerprogramma's die vereisten specificeren voor de omgang met gevoelige gegevens en kunnen deze informatie gebruiken om te bepalen of de vereisten voor gegevenssoevereiniteit van toepassing zijn op alle of slechts een subset van gegevensclassificaties. Wanneer een organisatie gegevens uploadt en onderhoudt in een cloudservice, is het de verantwoordelijkheid van de organisatie om de gegevens nauwkeurig te classificeren, labelen en beheren volgens hun vereisten voor gegevensverwerking. Sommige organisaties willen de adoptie van de cloud misschien gebruiken als een kans om hun gegevensclassificatieprogramma's te herzien.

Zie voor meer informatie over hoe gegevensclassificatie van toepassing is op cloudadoptie Gegevensclassificatie in Azure en Handleidingen voor cloudgovernance.

Voorbeelden van vereisten voor gegevenssoevereiniteit

Organisaties met strikte vereisten voor gegevenssoevereiniteit moeten mogelijk rekening houden met enkele van de volgende representatieve scenario's wanneer ze workloads naar de cloud migreren.

Labels voor gegevensclassificatie

Classificatielabels identificeren resources met speciale verwerkingsvereisten. Hoewel classificatielabels op documenten worden toegepast, kunnen ze ook op activa worden toegepast. Klanten kunnen de native tagging-functies in Azure gebruiken om classificatielabels toe te passen op resources zoals rekenservices en gegevensarchieven en op logische structuren in Azure, zoals abonnementen en beheergroepen.

Zie Taggen in Azure en Microsoft Purview eDiscovery-oplossingen voor meer informatie.

Gegevensclassificatiegrenzen

Wanneer een organisatie ervoor kiest om gegevens (of toepassingen) van een vergelijkbare classificatie samen te voegen, wordt vaak een beveiligingsperimeter geïmplementeerd die dient als grens van de locatie waar gegevensopslag is toegestaan. Wanneer klanten workloads in Azure implementeren, kunnen ze abonnementen en beheergroepen gebruiken om logische grenzen te creëren binnen de cloudomgeving van de organisatie. Deze grenzen helpen de vertrouwelijkheidsrisico's die verband houden met onbevoegde toegang en de privacyrisico's die verband houden met de aggregatie en toekenning van gegevens te beperken.

Organisaties die strenge eisen stellen aan de gegevenssoevereiniteit willen wellicht overwegen of ze hun omgeving willen organiseren in een hiërarchisch model, waarbij hogere niveaus van bevoegdheden lagere bevoegdheidsniveaus overnemen (bijvoorbeeld zoals in het Bell-LaPadula-model), of dat ze er de voorkeur aan geven een niet-hiërarchisch model te implementeren waarin verplichte toegangscontroles worden gebruikt om grenzen te creëren die delen van de omgeving op te delen ten opzichte van de rest van de omgeving. Beslissingen over hoe een organisatie de grenzen van gegevensclassificatie beheert, zijn van cruciaal belang bij het ontwerpen van landingszones in de gereedheidsfase van het Cloud Adoption Framework voor Azure.

Zie voor meer informatie Beheergroepen in Azure en Gegevensbeheer.

Gegevensresidentie

Organisaties die moeten voldoen aan de vereisten voor gegevenslocatie moeten speciale aandacht besteden aan welke Azure-services ze nodig hebben om een workload te ondersteunen, en waar deze services geografisch beschikbaar zijn. Azure-services worden geïmplementeerd in regio's die netwerkverbindingen met lage latentie en functies zoals beschikbaarheidszones ondersteunen. Deze regio's zijn gegroepeerd in geografische gebieden, die extra functies voor veerkracht en noodherstel bieden.

Als een organisatie de gegevenslocatie voor haar workload moet behouden, moet ervoor worden gezorgd dat de gebruikte Azure-services beschikbaar zijn in de gewenste regio en geografie. Bovendien worden sommige services wereldwijd geïmplementeerd en bieden ze geen gegevenslocatie binnen een bepaalde regio of geografie voor de gegevens die in die service zijn opgeslagen.

Zie de volgende artikelen voor meer informatie over gegevenslocatie, Azure-regio's en beschikbaarheidszones en regionale beschikbaarheid van Azure-services:

Eigendom, bewaren en overdraagbaarheid van gegevens

Klanten met strikte eisen op het gebied van gegevenssoevereiniteit hebben vaak veel vragen over wie eigenaar blijft van gegevens die zijn opgeslagen in Azure, wie toegang heeft tot die gegevens en wat er met die gegevens gebeurt als een klant ervoor kiest de workload naar een ander platform te verplaatsen. Deze vereisten kunnen qua reikwijdte en specificiteit variëren, maar hebben meestal betrekking op de fundamentele vraag wat er met gegevens gebeurt als u deze host in een Microsoft Cloud Service.

Om deze vragen op een hoog niveau te helpen beantwoorden en klanten een startpunt te geven voor het identificeren van hun vereisten inzake gegevenssoevereiniteit die van toepassing zijn op cloudserviceproviders, heeft Microsoft een reeks artikelen gepubliceerd over het beschermen en beheren van klantgegevens waarin veel van deze vragen worden beantwoord. Deze artikelen zijn online beschikbaar in het Vertrouwenscentrum.

Zie Gegevensbeheer in Microsoft voor meer informatie.

Operationele soevereiniteit in de cloud behouden

Vereisten voor operationele soevereiniteit kunnen van invloed zijn op de manier waarop een omgeving in Azure wordt ontworpen, bijgewerkt en beheerd. Daarom is het belangrijk om een duidelijk inzicht te hebben in deze vereisten voordat de technische ontwerpen worden afgerond als onderdeel van de gereedheidsfase van het Cloud Adoption Framework voor Azure. Algemene vereisten voor operationele soevereiniteit kunnen het volgende omvatten:

  • Beperkingen voor de locatie en nationaliteit van administratief personeel.
  • Toegangscontrolevereisten die toegang met bevoegdheden door cloudserviceproviders beperken.
  • Mandaten voor hoge beschikbaarheid en herstel na noodgevallen.

Het is belangrijk om de bedoeling en de risico's die deze vereisten beperken duidelijk te begrijpen, aangezien aan veel van deze vereisten in de cloud wordt voldaan met behulp van andere methoden dan gewoonlijk on-premises worden gebruikt.

Nadat de organisatie de vereisten voor operationele soevereiniteit heeft geïdentificeerd, kunnen de juiste technische en administratieve soevereiniteitscontroles worden geselecteerd om het juiste niveau van risicobeperking en zekerheid te bieden. Bij het selecteren van soevereiniteitscontroles is het belangrijk om te begrijpen dat het selecteren van enkele mogelijkheden die extra operationele soevereiniteit kunnen bieden, de opties van een organisatie voor het adopteren van andere Azure-services beperkt.

Een organisatie die confidential computing nodig heeft voor haar Azure-workloads, moet bijvoorbeeld haar architectuurkeuzen beperken tot services die kunnen worden uitgevoerd op in Confidential computing in Azure, zoals vertrouwelijke virtuele machines of vertrouwelijke containers. Om deze reden is het vaak een goed idee om vereisten voor operationele soevereiniteit te koppelen aan een bepaalde gegevensclassificatie, in plaats van een aanpak te hanteren waarbij alle workloads en gegevens moeten voldoen aan de meest restrictieve reeks soevereiniteitsvereisten.

Bovendien zijn sommige vereisten voor operationele soevereiniteit, zoals Autarky (bijvoorbeeld het onafhankelijk van externe netwerken en systemen kunnen functioneren), onhaalbaar in hyperscale cloud-computingplatforms zoals Azure, die afhankelijk zijn van regelmatige platformupdates om systemen in een optimale staat te houden.

Voorbeelden van vereisten voor operationele soevereiniteit

Enkele veel voorkomende vereisten voor operationele soevereiniteit, met voorbeelden van relevante Azure-services en -mogelijkheden die aan deze vereisten kunnen voldoen, zijn als volgt:

Softwarebeveiliging

Softwarebeveiligingsvereisten kunnen ontwikkelingsactiviteiten omvatten, zoals het toepassen van specifieke cryptografische beveiligingen, het uitvoeren van codecontroles en het uitvoeren van testen voor toepassingsbeveiliging en -penetratie. Het kan ook operationele processen omvatten, zoals de implementatie van toegangscontroles, het gebruik van encryptietechnologieën en het monitoren van beveiligingsgebeurtenissen.

Microsoft biedt verschillende mogelijkheden om klanten te helpen voldoen aan de vereisten voor operationele soevereiniteit voor door Microsoft ontwikkelde en door de klant ontwikkelde software. Microsoft volgt de Secure Development Lifecycle (SDL) bij het ontwikkelen van software op platformniveau voor Azure. De 12 praktijken van de SDL zijn opgenomen in de technische processen en procedures van Microsoft en worden regelmatig beoordeeld als onderdeel van de assurance-activiteiten van Microsoft. Daarnaast biedt Microsoft mogelijkheden om klanten te helpen de Secure Development Lifecycle-praktijken te implementeren als onderdeel van hun softwareontwikkelingslevenscyclus.

Zie Levenscyclus voor Microsoft-beveiligingsontwikkeling en Best practices voor veilige ontwikkeling in Azure voor meer informatie.

Infrastructuurbeveiliging

Workloads die in Azure worden uitgevoerd, kunnen profiteren van de vele functies die Microsoft heeft ontwikkeld om de integriteit van het platform te garanderen. De functies omvatten de firmware, software en hostinfrastructuur. Organisaties kunnen vereisten voor operationele soevereiniteit hebben om hun gegevens te isoleren van cloudoperators. Azure biedt mogelijkheden die klanten kunnen gebruiken om te profiteren van de flexibiliteit en veerkracht van de openbare cloud, terwijl ze tegelijkertijd geïsoleerd blijven van cloudserviceproviders en hun administratief personeel. Organisaties met vereisten met betrekking tot attest op hardwareniveau, verificatie van de software-integriteit (bijvoorbeeld veilig opstarten) en veilig sleutelbeheer kunnen de platformintegriteit en beveiligingspraktijken van Microsoft beoordelen en toegang krijgen tot auditdocumentatie om de implementatie van deze functies te valideren.

Zie Platformintegriteit en -beveiliging en Azure-infrastructuurbeveiliging voor meer informatie.

Encryptie voor gegevens in rust, gegevens in transit en gegevens in gebruik kan helpen te voldoen aan een breed scala aan vereisten voor operationele soevereiniteit met betrekking tot de vertrouwelijkheid en privacy van gegevens. Organisaties die deze functies nodig hebben, moeten echter plannen maken voor het maken en beheren van encryptiesleutels. Azure biedt een breed scala encryptiemodellen voor gegevens in rust waaruit klanten kunnen kiezen, van encryptiemethoden aan de clientzijde die zero-knowledge-encryptie bieden voor gegevens die in de cloud worden gehost, tot door service beheerde sleutels die de hoogste mate van interoperabiliteit bieden met native cloudservices.

Bovendien kunnen organisaties die de behoefte aan vertrouwen in platformonderdelen zoals het hostbesturingssysteem, de kernel, de hypervisor en het administratief personeel willen minimaliseren, encryptie voor gegevens in gebruik implementeren. Confidential computing in Azure omvat verschillende computerservices die worden geïmplementeerd in op hardware gebaseerde enclaves voor beveiliging die gegevens in het geheugen versleutelen met behulp van Intel Software Guard Extensions (SGX) of AMD Secure Encrypted Virtualization (SEV-SNP).

Organisaties met vereisten voor operationele soevereiniteit waarvoor de implementatie van versleuteling vereist is, moeten vertrouwd raken met de volgende versleutelingsfuncties in Azure:

Bewerkingen en tolerantie

Vereisten voor operationele beveiliging kunnen van toepassing zijn op zowel software op platformniveau die door Microsoft is gemaakt en beheerd om het Azure-platform te bedienen, als op door de klant beheerde software die deel uitmaakt van een workload. Het gedeelde verantwoordelijkheidsmodel voor cloud-computing verschuift de administratieve verantwoordelijkheid van de klant naar de cloudserviceprovider. Afhankelijk van het cloudservicetype dat wordt gebruikt, is Microsoft mogelijk verantwoordelijk voor het beheren en bijwerken van de bare-metal-infrastructuur in onze datacentra, besturingssystemen en serviceruntimes. De organisatie voor beveiligingsengineering van Microsoft implementeert een operationeel beveiligingsprogramma dat voortbouwt op de praktijken van de Microsoft Secure Development Lifecycle (SDL) met operationele beveiligingspraktijken. De praktijken omvatten beheer van geheimen, penetratietesten en beveiligingsmonitoring, geïmplementeerd door het Microsoft Security Response Center.

In zeldzame gevallen kan Microsoft toegang tot klantgegevens nodig hebben om een probleem op te lossen dat van invloed kan zijn op de services. Klanten met vereisten voor operationele soevereiniteit met betrekking tot wijzigingsbeheer en toegangsbeheer met bevoegdheden willen mogelijk Klanten-lockbox voor Azure inschakelen, zodat ze de toegangsaanvragen kunnen goedkeuren als onderdeel van de ondersteuningsworkflows van Microsoft.

Bovendien kunnen klanten met strikte vereisten voor de goedkeuring en planning van platformsoftware-updates Azure Dedicated Hosts overwegen, waarmee klanten onderhoudsconfiguraties kunnen gebruiken om platformonderhoudsactiviteiten op hostniveau te controleren. Bovendien moeten klanten hun tolerantievereisten beoordelen om te bepalen of er op soevereiniteit gebaseerde beperkingen zijn voor de services en regio's die worden gebruikt om workloads te hosten.

Vereisten voor operationele soevereiniteit met betrekking tot de continuïteit van de bedrijfsvoering (bijvoorbeeld vereisen dat workloads worden geïmplementeerd in configuraties met hoge beschikbaarheid om de uptime te behouden), kunnen conflicteren met vereisten voor gegevenssoevereiniteit met betrekking tot gegevenslocatie (bijvoorbeeld het beperken van workloads tot een geografische grens die geen diverse locaties biedt).

Organisaties moeten deze vereisten vroegtijdig evalueren en nadenken over de beste manier om deze vereisten in evenwicht te brengen.