Datasekretess för analys i molnskala i Azure

Artikel
10/10/2023

Analys i molnskala gör att organisationer kan fastställa de bästa mönstren så att de passar deras krav samtidigt som personliga data skyddas på flera nivåer. Personuppgifter är alla data som kan användas för att identifiera individer, till exempel körkortsnummer, personnummer, bankkontonummer, passnummer, e-postadresser med mera. Många regler finns idag för att skydda användarnas integritet.

Klassificeringsschema för datasekretess

Klassificering	Description
Publikt	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 konfidentiella eller under eller känsliga (personliga data):

Data kan sorteras i konfidentiellt eller under om en användare får åtkomst till datatillgången i berikad eller kuraterad. Användare kan visa alla kolumner och rader.
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 (personliga data) när data kombineras. I situationer där data ska vara beständiga bör de kopieras till en separat mapp som överensstämmer med klassificeringen av datasekretess och processen för registrering av dem.

Konfidentiellt eller nedan

För varje registrerad dataprodukt skapar vi två datasjömappar i de berikade och kurerade lagren, konfidentiella eller under och känsliga (personliga data) och använder åtkomstkontrollistor för att aktivera Direktautentisering för Microsoft Azure-katalog (Microsoft Entra-ID).

Om ett dataprogramteam registrerar en konfidentiell eller under datatillgång kan användarens huvudnamn och objekt för tjänstens huvudnamn läggas till i två Microsoft Entra-grupper (en för läs-/skrivåtkomst och den andra för skrivskyddad åtkomst). Dessa två Microsoft Entra-grupper bör skapas under registreringsprocessen och sorteras i lämplig dataproduktmapp med konfidentiella eller nedanstående containrar för rådata och berikade data.

Det här mönstret gör det möjligt för alla beräkningsprodukter som stöder Microsoft Entra-direktautentisering att ansluta till datasjön och autentisera inloggade användare. Om en användare ingår i datatillgångens Microsoft Entra-grupp kan de komma åt data via Microsoft Entra-direktautentisering. Det gör att användarna i gruppen kan läsa hela datatillgången utan principfilter. Åtkomst kan sedan granskas i detalj med lämpliga loggar och Microsoft Graph.

Rekommendationer om layouten för din datasjö finns i Etablera tre Azure Data Lake Storage Gen2-konton för varje datalandningszon.

Kommentar

Exempel på beräkningsprodukter är Azure Databricks, Azure Synapse Analytics, Apache Spark och Azure Synapse SQL på begäran-pooler som är aktiverade med Microsoft Entra-direktautentisering.

Känsliga data (personuppgifter)

För känsliga (personliga data) måste företaget begränsa vad användarna kan se via princip, datakopior eller beräkning. I det här fallet måste organisationen överväga att flytta eller mata in åtkomstkontrollen i beräkningslagret. Det finns fyra alternativ för att skydda data i analys i molnskala.

Exempelscenario

I följande exempel beskrivs alternativ för att skydda känsliga (personliga data):

Ett dataprogram matar in en personaldataprodukt (HR) för Nordamerika och Europa. I användningsfallet uppmanas europeiska användare att endast se europeiska personalregister och Nordamerika n användare att endast se Nordamerika n personalregister. Det är ytterligare begränsat så att endast HR-chefer ser kolumner som innehåller lönedata.

Alternativ 1: Principmotor (rekommenderas)

De två första alternativen är ett sätt att hantera känsliga (personliga data) och de ger även kontroll till integrerings- och dataproduktteam för att identifiera och begränsa åtkomsten. Det kan räcka för en småskalig analysplattform, men en principmotor bör placeras i landningszonen för datahantering för ett stort företag med hundratals dataprodukter. Policymotorer stöder ett centralt sätt att hantera, skydda och kontrollera:

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

Vanligtvis integreras en principmotor med en datakatalog som Azure Purview. Azure Marketplace har tredjepartslösningar för leverantörer, och vissa leverantörer arbetar med Azure Synapse och Azure Databricks för att kryptera och dekryptera information samtidigt som de tillhandahåller säkerhet på radnivå och kolumnnivå. Precis som i januari 2022 har Azure Purview lanserat en offentlig förhandsversion för åtkomstprinciper för att styra åtkomsten till data som lagras i Blob och Azure Data Lake Storage (ADLS) Gen2. Se Datauppsättningsetablering efter dataägare för Azure Storage (förhandsversion).

Principmotorn bör använda Microsoft Entra-grupper för att tillämpa principer på dataprodukter. Förväntningen för alla principlösningar som tillhandahåller datasekretess är att tokenisera känsliga (personliga data) och att alltid kontrollera åtkomstkontrollen för attribut så att användaren har kan detokenisera de kolumner som de behöver komma åt.

För att en principmotor ska lyckas är det som sagt viktigt att den integreras i datakatalogen och att DevOps använder ett REST-API för att registrera en ny datauppsättning. När dataprogramteam skapar läsdatakällor registreras de i datakatalogen och hjälper till att identifiera känsliga (personliga data). Principmotorn bör importera definitionen och neka all åtkomst till data tills teamen har konfigurerat sina åtkomstprinciper. Allt detta bör göras via ett REST API-arbetsflöde från IT-tjänstens hanteringslösning.

Alternativ 2: Konfidentiella eller nedanstående och känsliga (personliga data) versioner

För varje dataprodukt som klassificeras som känslig (personuppgifter) skapas två kopior av pipelinen. En som klassificeras som konfidentiell eller under vilken alla känsliga kolumner (personliga data) tas bort och skapas under mappen konfidentiellt eller nedan för dataprodukten. Den andra kopian skapas i mappen känsliga (personliga data) för dataprodukten, som innehåller alla känsliga data. Varje mapp skulle tilldelas en Säkerhetsgrupp för Microsoft Entra-läsare och en Säkerhetsgrupp för Microsoft Entra-skrivare. Med dataåtkomsthantering kan en användare begära åtkomst till dataprodukten.

Även om detta uppfyller uppdelningen av känsliga (personliga data) och konfidentiellt eller nedan, skulle en användare som beviljats åtkomst via Active Directory genomströmningsautentisering till känsliga (personliga data) kunna köra frågor mot alla rader. Om du behöver säkerhet på radnivå måste du använda ALTERNATIV 1: Principmotor (rekommenderas) eller Alternativ 3: Azure SQL Database, SQL Managed Instance eller Azure Synapse Analytics SQL-pooler.

Alternativ 3: Sql-pooler för Azure SQL Database, SQL Managed Instance eller Azure Synapse Analytics

Ett dataprogram använder SQL Database-, SQL Managed Instance- eller Azure Synapse Analytics SQL-pooler för att läsa in dataprodukterna i en databas som stöder säkerhet på radnivå, säkerhet på kolumnnivå och dynamisk datamaskning. Dataprogramteamen skapar olika Microsoft Entra-grupper och tilldelar behörigheter som stöder datas känslighet.

I det här scenariots användningsfall skulle dataprogramteam behöva skapa följande fyra Microsoft Entra-grupper med skrivskyddad åtkomst:

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

Förutom transparent datakryptering skulle säkerhetsskiktet vara att kryptera datakolumnen och dekryptera vid läsning.

Tabellerna kan göras tillgängliga för Azure Databricks med Apache Spark-anslutningsappen: SQL Server och Azure SQL Database.

Alternativ 4: Azure Databricks

Alternativ fyra är att använda Azure Databricks för att utforska känsliga (personliga data). Med hjälp av en kombination av Fernet-krypteringsbibliotek, användardefinierade funktioner (UDF), Databricks-hemligheter, tabellåtkomstkontroll och dynamiska vyfunktioner kan du kryptera och dekryptera kolumner.

I blogginlägget beskrivs hur du framtvingar kryptering på kolumnnivå och undviker dataduplicering:

Det första steget i den här processen är att skydda data genom att kryptera dem under inmatningen och en möjlig lösning är Fernet Python-biblioteket. Fernet använder symmetrisk kryptering, som är byggd med flera vanliga kryptografiska primitiver. Det här biblioteket används i en krypterings-UDF som gör att vi kan kryptera en viss kolumn i en dataram. För att lagra krypteringsnyckeln använder vi Databricks-hemligheter med åtkomstkontroller på plats för att endast tillåta att vår datainmatningsprocess får åtkomst till den. När data har skrivits till våra Delta Lake-tabeller är personliga datakolumner med värden som personnummer, telefonnummer, kreditkortsnummer och andra identifierare omöjliga för en obehörig användare att läsa.

När du har skrivit och skyddat känsliga data behöver du ett sätt för privilegierade användare att läsa känsliga data. Det första som måste göras är att skapa en permanent UDF att lägga till i Hive-instansen som körs på Databricks. För att en UDF ska vara permanent måste den skrivas i Scala. Som tur är har Fernet även en Scala-implementering som du kan använda för dekrypterade läsningar. Den här UDF:n kommer också åt samma hemlighet som används i den krypterade skrivningen för att utföra dekrypteringen, och i det här fallet läggs den till i Spark-konfigurationen för klustret. Detta kräver att vi lägger till klusteråtkomstkontroller för privilegierade och icke-privilegierade användare för att styra deras åtkomst till nyckeln. När UDF har skapats kan vi använda den i våra vydefinitioner för privilegierade användare för att se de dekrypterade data.

Med funktioner för dynamisk vy kan du bara skapa en vy och returnera de krypterade eller dekrypterade värdena baserat på den Databricks-grupp som de tillhör.

I föregående exempel skulle du skapa två dynamiska vyfunktioner, en för Nordamerika och en annan för Europa, och implementera krypteringsteknikerna i den här notebook-filen.

Nordamerika n vy:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Europeisk vy:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

För att det ska fungera aktiverar du åtkomstkontroll för Azure Databricks-tabeller på arbetsytan och tillämpar följande behörigheter:

Bevilja DA-AMERICA-HRMANAGER-R och DA-AMERICA-HRGENERAL-R Microsoft Entra-grupper åtkomst till vhr_us vyn.
Bevilja DA-EUROPE-HRMANAGER-R och DA-EUROPE-HRGENERAL-R Microsoft Entra-grupper åtkomst till vhr_eu vyn.

Eftersom kolumner är krypterade och inte kan dekrypteras på den konfidentiella eller under arbetsytan kan de konfidentiella eller nedanstående arbetsytorna fortfarande använda Microsoft Entra-direktautentisering och tillåta användare att utforska sjön, baserat på deras behörigheter.

Där tabellåtkomst används läggs team som kräver åtkomst till Azure Databricks-arbetsytan. Azure Databricks skulle använda tjänstens huvudnamn för att mappa till Azure Data Lake Storage, men data skulle skyddas med åtkomstkontroll för Azure Databricks-tabeller.

När nya dataprodukter distribueras måste en del av DevOps-processen köra skript för att konfigurera tabellbehörigheterna på Azure Databricks-arbetsytan och lägga till rätt Microsoft Entra-grupper i dessa behörigheter.

Kommentar

Åtkomstkontroll för Azure Databricks-tabeller kan inte kombineras med Microsoft Entra-direktautentisering. Därför kan du bara använda en Azure Databricks-arbetsyta och använda tabellåtkomstkontroll i stället.

Begränsade data

Tillsammans med implementeringsalternativ för konfidentiella eller begränsade data rekommenderar vi även att du är värd för strikt konfidentiella data i en dedikerad datalandningszon och landningszon för datahantering.

Den tillåter specifika krav som just-in-time-åtkomst, kundhanterade nycklar för kryptering och begränsningar för inkommande eller utgående trafik som tillämpas på landningszonen. Vägledningen har utvärderat hur du placerar data av den här typen i samma datalandningszon men olika lagringskonton. Det kan dock göra lösningen komplicerad på nätverksskiktet, till exempel med nätverkssäkerhetsgrupper och andra.

Den dedikerade landningszonen för "begränsad" datahantering bör ansluta till katalogen av data i den "begränsade" datalandningszonen. Den bör begränsa vem som kan söka efter dessa data i katalogen.

Nästa steg

Hantering av dataåtkomst

Dela via