Datasekretess för analys i molnskala i Azure

Med analys i molnskala kan organisationer fastställa de optimala dataåtkomstmönstren så att de passar deras krav samtidigt som personliga data skyddas på flera nivåer. Personuppgifter innehåller all information som unikt kan identifiera individer, till exempel körkortsnummer, personnummer, bankkontouppgifter, passnummer, e-postadresser med mera. Många regler finns idag för att skydda användarnas integritet.

För att skydda datasekretess med en molnmiljö som Azure kan du börja med att skapa ett datasekretessschema som anger principer för dataåtkomst. Dessa principer kan definiera den underliggande arkitektur som dataprogrammet finns på, definiera hur dataåtkomst auktoriseras och ange vilka rader eller kolumner som kan nås när de har beviljats.

Skapa klassificeringsschema för datasekretess

Klassificering	beskrivning
Offentliga	Vem som helst kan komma åt data och de kan skickas till vem som helst. Öppna till exempel myndighetsdata.
Endast intern användning	Endast anställda kan komma åt data och de kan inte skickas utanför företaget.
Konfidentiellt	Data kan bara delas om de behövs för en viss uppgift. Data kan inte skickas utanför företaget utan ett sekretessavtal.
Känslig (personliga data)	Data innehåller privat information, som endast måste maskeras och delas på grundval av behovsbe veta under en begränsad tid. Data kan inte skickas till obehörig personal eller utanför företaget.
Begränsad	Data kan endast delas med namngivna personer som är ansvariga för dess skydd. Till exempel juridiska dokument eller affärshemligheter.

Innan du matar in data måste du kategorisera data som antingen konfidentiella eller under eller känsliga (personliga data):

• Data kan sorteras i konfidentiellt eller nedan om det inte finns några begränsningar för vilka kolumner och rader som är synliga för olika användare.
• Data kan sorteras i känsliga (personliga data) om det finns begränsningar för vilka kolumner och rader som är synliga för olika användare.

Viktigt!

En datauppsättning kan ändras från konfidentiell eller under till känslig (personuppgifter) när data kombineras med andra dataprodukter som tidigare hade en lägre klassificering. När data måste vara beständiga bör de flyttas till en angiven mapp som överensstämmer med dess sekretessnivå och registreringsprocessen.

Skapa en Azure-principuppsättning

När du har mappat din dataklassificering bör du justera klassificeringen med lokala reglerade branschprincipkrav och dina interna företagsprinciper. Det här steget hjälper dig att skapa en Azure-principuppsättning som styr vilken infrastruktur som kan distribueras, platsen där den kan distribueras och anger nätverk och krypteringsstandarder.

För reglerade branscher utvecklade Microsoft många initiativ för regelefterlevnadsprinciper som fungerar som baslinje för efterlevnadsramverk.

För dataklassificering, som följer samma regler för kryptering och tillåtna infrastruktur-SKU:er, och principinitiativ kan data ligga i samma landningszon.

För begränsade data rekommenderar vi att du är värd för data i en dedikerad datalandningszon under en hanteringsgrupp där du kan definiera en högre uppsättning krav för infrastruktur, till exempel kundhanterade nycklar för kryptering och begränsningar för inkommande eller utgående trafik som tillämpas på landningszonen.

Kommentar

Vägledningen har utvärderat hur du placerar känsliga (personliga data) och konfidentiella eller under data i samma datalandningszon men olika lagringskonton. Detta kan dock göra lösningen komplicerad på nätverksskiktet, till exempel med nätverkssäkerhetsgrupper.

Alla distribuerade datastyrningslösningar bör begränsa vem som kan söka efter begränsade data i katalogen.

Du bör också överväga att implementera villkorsstyrd åtkomst för Microsoft Entra-ID för alla datatillgångar och tjänster och just-in-time-åtkomst för begränsade data för att förbättra säkerheten.

Kryptering

Förutom att definiera principer för plats och tillåtna Azure-tjänster bör du överväga krypteringskraven för var och en av dataklassificeringarna.

• Vilka är dina krav för nyckelhantering?
• Vilka är dina krav för att lagra dessa nycklar?
• Vilka är dina krav, per klassificering för vilande datakryptering?
• Vilka är dina krav, per klassificering, för data vid överföringskryptering?
• Vilka är dina krav, per klassificering, för data som används kryptering?

För nyckelhantering kan krypteringsnycklar vara plattformshanterade eller kundhanterade. Microsofts dokumenterade nyckelhantering i Azure som hjälper dig att välja en nyckelhanteringslösning. Mer information finns i Översikt över nyckelhantering i Azure och Så här väljer du rätt lösning för nyckelhantering.

Microsoft publicerade dokumentation som förklarar azure-datakryptering i vila och datakrypteringsmodeller som hjälper dig att förstå de krypteringsalternativ som är tillgängliga.

Microsoft ger kunderna möjlighet att använda TLS-protokollet (Transport Layer Security) för att skydda data när de reser mellan molntjänsterna och kunderna. Mer information finns i Kryptering av data under överföring.

Om ditt scenario kräver att data förblir krypterade i bruk syftar Hotmodellen för konfidentiell databehandling i Azure till att minimera förtroendet eller ta bort möjligheten för en molnleverantörsoperatör eller andra aktörer i klientorganisationens domän att komma åt kod och data under körningen.

De senaste erbjudandena om konfidentiell databehandling i Azure finns i Produkter för konfidentiell databehandling i Azure.

Datastyrning

När du har definierat principerna för distribution av tillåtna Azure-tjänster måste du bestämma hur du beviljar åtkomst till dataprodukten.

Om du har en datastyrningslösning som Microsoft Purview eller Azure Databricks Unity Catalog kan du skapa datatillgångar/produkter för berikade och kuraterade datasjölager. Se till att du anger behörigheterna i datakatalogen för att skydda dessa dataobjekt.

Microsoft Purview är ett centralt sätt att hantera, skydda och kontrollera:

• Åtkomst till data
• Datalivscykel
• Interna och externa policyer och föreskrifter
• Principer för datadelning
• Identifiera känsliga (personuppgifter)
• Insikter om skydd och efterlevnad
• Principer för dataskyddsrapportering

Mer information om hur du hanterar läs- eller ändringsåtkomst med Microsoft Purview finns i Begrepp om ägarprinciper för Microsoft Purview-data.

Oavsett om du bestämmer dig för att implementera Microsoft Purview eller någon annan datastyrningslösning är det viktigt att använda Microsoft Entra-ID-grupper för att tillämpa principer på dataprodukter.

Det är viktigt att använda rest-API:et för datastyrningslösningar för att registrera en ny datauppsättning. Dataprogramteam skapar dataprodukter och registrerar dem i datastyrningslösningen för att identifiera känsliga (personliga data). Datastyrningslösningen importerar definitionen och nekar all åtkomst till data tills teamen har konfigurerat sina åtkomstprinciper.

Använda mönster för att skydda känsliga data

Det finns flera mönster som kan användas beroende på vilka data, tjänster och principer du behöver implementera för skydd av känsliga data.

Flera kopior

För varje dataprodukt som klassificeras som känslig (personuppgifter) skapas två kopior av dess pipeline. Den första kopian klassificeras som konfidentiell eller nedan. Den här kopian har alla känsliga kolumner (personliga data) borttagna och skapas under mappen konfidentiellt eller nedan för dataprodukten. Den andra kopian skapas i mappen känsliga (personliga data) och innehåller alla känsliga data. Varje mapp tilldelas en Microsoft Entra ID-läsare och en Säkerhetsgrupp för Microsoft Entra-ID-skrivare.

Om Microsoft Purview används kan du registrera båda versionerna av dataprodukten och använda principer för att skydda data.

Den här processen separerar känsliga (personliga data) och konfidentiella eller under data, men en användare som har beviljats åtkomst till känsliga (personliga data) kommer att kunna fråga alla rader. Din organisation kan behöva titta på andra lösningar som ger säkerhet på radnivå för att filtrera rader.

Säkerhet på radnivå och kolumnnivå

Om du behöver filtrera rader som användarna ser kan du flytta dina data till en beräkningslösning som använder säkerhet på radnivå.

Det är viktigt att du väljer rätt Azure-tjänst eller Microsoft Fabric-lösning för ditt specifika användningsfall för att förhindra omkonstruktion. En OLTP-databas är olämplig för omfattande analys, precis som en lösning som är skräddarsydd för stordataanalys inte kan uppnå svarstider på millisekunder som krävs av ett e-handelsprogram.

För att arbeta med lösningar som stöder säkerhet på radnivå skapar dataprogramteamen olika Microsoft Entra-ID-grupper och tilldelar behörigheter baserat på datakänsligheten.

Vi går vidare med scenariot genom att ange att det, tillsammans med säkerhet på radnivå, finns ett behov av att begränsa åtkomsten till vissa kolumner. Dataprogramteamen skapade de fyra Microsoft Entra-ID-grupperna med skrivskyddad åtkomst enligt följande tabell:

Grupp	Behörighet
DA-AMERICA-HRMANAGER-R	Visa Nordamerika HR-personaldatatillgång med löneinformation.
DA-AMERICA-HRGENERAL-R	Visa Nordamerika HR-personaldatatillgång utan löneinformation.
DA-EUROPE-HRMANAGER-R	Visa Datatillgång för Personaldata i Europa med löneinformation.
DA-EUROPE-HRGENERAL-R	Visa datatillgång för Personaldata i Europa utan löneinformation.

Den första nivån av begränsningar skulle stödja dynamisk datamaskering, vilket döljer känsliga data från användare utan behörighet. En fördel med den här metoden är att den kan integreras i en datamängds registrering med ett REST-API.

Den andra nivån av begränsningar är att lägga till säkerhet på kolumnnivå för att hindra icke-HR-chefer från att se löner och säkerhet på radnivå för att begränsa vilka rader europeiska och Nordamerika n teammedlemmar kan se.

Kolumnkryptering

Dynamisk datamaskering maskerar data vid presentationen, men vissa användningsfall kräver att lösningen aldrig har åtkomst till klartextdata.

SQL Always Encrypted är en kraftfull funktion som introduceras av Microsoft och som förbättrar säkerheten för känsliga data som lagras i SQL Server-databaser. SQL Always Encrypted säkerställer att känsliga data som lagras i SQL Server-databaser förblir säkra och skyddade mot obehörig åtkomst. Den här funktionen hjälper till att upprätthålla maximal datasekretess och regelefterlevnad genom att kryptera data både i vila och under överföring.

Genom att utföra krypterings- och dekrypteringsåtgärder på klientsidan ser Always Encrypted till att känsliga data förblir skyddade mot obehörig åtkomst. Dess enkla integrerings- och efterlevnadsfördelar gör det till ett viktigt verktyg för organisationer som vill skydda sina mest värdefulla datatillgångar.

Nästa steg

Organisera medlemmar i datadriftsteamet