Gegevensprivacy voor analyses op cloudschaal in Azure

  • Artikel

Met analyses op cloudschaal kunnen organisaties de beste patronen bepalen die aan hun vereisten voldoen, terwijl persoonlijke gegevens op meerdere niveaus worden bewaakt. Persoonsgegevens zijn alle gegevens die kunnen worden gebruikt om personen te identificeren, zoals rijbewijsnummers, burgerservicenummers, bankrekeningnummers, paspoortnummers, e-mailadressen en meer. Er bestaan tegenwoordig veel voorschriften om de privacy van gebruikers te beschermen.

Classificatieschema voor vertrouwelijkheid van gegevens

Classificatie Omschrijving
Openbaar Iedereen heeft toegang tot de gegevens en kan naar iedereen worden verzonden. Open bijvoorbeeld overheidsgegevens.
Alleen intern gebruik Alleen werknemers hebben toegang tot de gegevens en kunnen niet buiten het bedrijf worden verzonden.
Vertrouwelijk De gegevens kunnen alleen worden gedeeld als deze nodig zijn voor een specifieke taak. De gegevens kunnen niet buiten het bedrijf worden verzonden zonder een geheimhoudingsovereenkomst.
Gevoelige (persoonlijke gegevens) De gegevens bevatten persoonlijke gegevens, die gedurende een beperkte tijd alleen moeten worden gemaskeerd en gedeeld. De gegevens kunnen niet worden verzonden naar onbevoegd personeel of buiten het bedrijf.
Beperkt De gegevens kunnen alleen worden gedeeld met benoemde personen die verantwoordelijk zijn voor de beveiliging. Bijvoorbeeld juridische documenten of handelsgeheimen.

Voordat u gegevens opneemt, moet u de gegevens categoriseren als vertrouwelijk of onder of gevoelig (persoonlijke gegevens):a1>

  • Gegevens kunnen worden gesorteerd in vertrouwelijk of lager als een gebruiker toegang krijgt tot de gegevensasset in verrijkt of gecureerd. Gebruikers kunnen alle kolommen en rijen weergeven.

  • Gegevens kunnen worden gesorteerd in gevoelige (persoonlijke gegevens) als er beperkingen zijn voor welke kolommen en rijen zichtbaar zijn voor verschillende gebruikers.

Belangrijk

Een gegevensset kan worden gewijzigd van vertrouwelijk of lager in gevoelige (persoonlijke gegevens) wanneer gegevens worden gecombineerd. In situaties waarin gegevens permanent moeten zijn, moeten ze worden gekopieerd naar een afzonderlijke map die overeenkomt met de classificatie en het proces voor vertrouwelijkheid van gegevens voor onboarding.

Vertrouwelijk of lager

Voor elk onboarded gegevensproduct maken we twee Data Lake-mappen in de verrijkte en gecureerde lagen, vertrouwelijk of onder en gevoelig (persoonlijke gegevens) en gebruiken we toegangsbeheerlijsten om Pass Through-verificatie van Microsoft Azure-directory (Microsoft Entra ID) in te schakelen.

Als een gegevenstoepassingsteam een vertrouwelijke of onderstaande gegevensasset onboardt, kunnen gebruikers-principalnamen en service-principal-objecten worden toegevoegd aan twee Microsoft Entra-groepen (één voor lees-/schrijftoegang en de andere voor alleen-lezentoegang). Deze twee Microsoft Entra-groepen moeten worden gemaakt tijdens het onboardingproces en worden gesorteerd in de juiste gegevensproductmap met vertrouwelijke of onderstaande containers voor onbewerkte en verrijkte gegevens.

Met dit patroon kan elk rekenproduct dat passthrough-verificatie van Microsoft Entra ondersteunt, verbinding maken met de data lake en aangemelde gebruikers verifiëren. Als een gebruiker deel uitmaakt van de Microsoft Entra-groep van de gegevensasset, hebben ze toegang tot de gegevens via passthrough-verificatie van Microsoft Entra. Hiermee kunnen deze gebruikers in de groep de volledige gegevensasset lezen zonder beleidsfilters. Access kan vervolgens in detail worden gecontroleerd met de juiste logboeken en Microsoft Graph.

Raadpleeg drie Azure Data Lake Storage Gen2-accounts inrichten voor elke datalandingszone voor aanbevelingen voor de indeling van uw data lake.

Notitie

Voorbeelden van rekenproducten zijn Azure Databricks, Azure Synapse Analytics, Apache Spark en Azure Synapse SQL on-demand pools die zijn ingeschakeld met Pass Through-verificatie van Microsoft Entra.

Gevoelige gegevens (persoonlijke gegevens)

Voor gevoelige (persoonlijke gegevens) moet de onderneming beperken wat gebruikers kunnen zien via beleid, gegevenskopieën of berekeningen. In dit geval moet de organisatie overwegen om het toegangsbeheer in de rekenlaag te verplaatsen of te injecteren. Er zijn vier opties voor het beveiligen van gegevens in analyses op cloudschaal.

Voorbeeldscenario

In het volgende voorbeeld worden opties beschreven voor het beveiligen van gevoelige (persoonlijke gegevens):

Een gegevenstoepassing neemt een personeelsgegevensproduct (HR) op voor Noord-Amerika en Europa. In de use-case wordt aan Europese gebruikers aanroepen om alleen europese personeelsrecords en Noord-Amerika n gebruikers te zien om alleen Noord-Amerika n personeelsrecords te zien. Het is verder beperkt, zodat alleen HR-managers kolommen met salarisgegevens zien.

De eerste twee opties bieden een manier om gevoelige (persoonlijke gegevens) te verwerken, en ze verlenen ook controle aan integraties en gegevensproductteams om de toegang te identificeren en te beperken. Het kan voldoende zijn voor een klein analyseplatform, maar er moet een beleidsengine worden geplaatst in de landingszone voor gegevensbeheer voor een grote onderneming met honderden gegevensproducten. Beleidsengines ondersteunen een centrale manier voor het beheren, beveiligen en beheren van:

  • Toegang tot gegevens
  • De levenscyclus van gegevens beheren
  • Intern en extern beleid en regelgeving
  • Beleid voor het delen van gegevens
  • Gevoelige (persoonlijke gegevens) identificeren
  • Inzichten over beveiliging en naleving
  • Beleid voor rapportage over gegevensbescherming

Normaal gesproken wordt een beleidsengine geïntegreerd met een gegevenscatalogus zoals Azure Purview. De Azure Marketplace biedt oplossingen van externe leveranciers en sommige leveranciers werken met Azure Synapse en Azure Databricks om informatie te versleutelen en ontsleutelen en tegelijkertijd beveiliging op rij- en kolomniveau te bieden. Vanaf januari 2022 heeft Azure Purview een openbare preview gelanceerd voor toegangsbeleid voor het beheren van de toegang tot gegevens die zijn opgeslagen in Blob en Azure Data Lake Storage (ADLS) Gen2. Zie Het inrichten van gegevenssets per gegevenseigenaar voor Azure Storage (preview).

De beleidsengine moet Microsoft Entra-groepen gebruiken om beleid toe te passen op gegevensproducten. De verwachting voor elke beleidsoplossing die gegevensprivacy biedt, is het tokeniseren van gevoelige (persoonlijke gegevens) en het altijd controleren via kenmerktoegangsbeheer, zodat de gebruiker detokenisatie van de kolommen waartoe ze toegang nodig hebben, kan detokeniseren.

Zoals vermeld, is het belangrijk dat een beleidsengine kan worden geïntegreerd in de gegevenscatalogus en dat DevOps een REST API gebruikt om een nieuwe gegevensset te onboarden. Wanneer teams van gegevenstoepassingen leesgegevensbronnen maken, worden ze geregistreerd in de gegevenscatalogus en kunnen ze gevoelige (persoonlijke gegevens) identificeren. De beleidsengine moet de definitie importeren en alle toegang tot gegevens weigeren totdat de teams het toegangsbeleid hebben ingesteld. Dit alles moet worden gedaan via een REST API-werkstroom van de IT-servicebeheeroplossing.

Optie 2: Vertrouwelijke of onderstaande en gevoelige (persoonlijke gegevens) versies

Voor elk gegevensproduct dat is geclassificeerd als gevoelige (persoonlijke gegevens) worden twee kopieën gemaakt door de pijplijn. Een kolom die is geclassificeerd als vertrouwelijk of lager , waarin alle gevoelige (persoonlijke gegevens) kolommen zijn verwijderd en wordt gemaakt onder de vertrouwelijke of onderstaande map voor het gegevensproduct. De andere kopie wordt gemaakt in de map gevoelige (persoonlijke gegevens) voor het gegevensproduct, waarin alle gevoelige gegevens zijn opgenomen. Aan elke map wordt een Microsoft Entra Reader-beveiligingsgroep en een Microsoft Entra Writer-beveiligingsgroep toegewezen. Met Data Access Management kan een gebruiker toegang tot het gegevensproduct aanvragen.

Hoewel dit voldoet aan het scheiden van gevoelige (persoonlijke gegevens) en vertrouwelijk of lager, kan een gebruiker via Passthrough-verificatie via Active Directory-passthrough een query uitvoeren op alle rijen. Als u beveiliging op rijniveau vereist, moet u Optie 1: Beleidsengine (aanbevolen) of Optie 3: Azure SQL Database, SQL Managed Instance of Azure Synapse Analytics SQL-pools gebruiken.

Optie 3: Azure SQL Database, SQL Managed Instance of Azure Synapse Analytics SQL-pools

Een gegevenstoepassing maakt gebruik van SQL Database-, SQL Managed Instance- of Azure Synapse Analytics SQL-pools om de gegevensproducten te laden in een database die ondersteuning biedt voor beveiliging op rijniveau, beveiliging op kolomniveau en dynamische gegevensmaskering. De datatoepassingsteams maken verschillende Microsoft Entra-groepen en wijzen machtigingen toe die de gevoeligheid van de gegevens ondersteunen.

Voor de use-case van dit scenario moeten teams voor gegevenstoepassingen de volgende vier Microsoft Entra-groepen maken met alleen-lezentoegang:

Groep Machtiging
DA-AMERICA-HRMANAGER-R Bekijk Noord-Amerika PERSONEELSgegevensasset met salarisgegevens.
DA-AMERICA-HRGENERAL-R Bekijk Noord-Amerika PERSONEELSgegevensasset zonder salarisgegevens.
DA-EUROPE-HRMANAGER-R Bekijk personeelsgegevensasset in Europa met salarisgegevens.
DA-EUROPE-HRGENERAL-R Bekijk personeelsgegevensasset van Europa zonder salarisgegevens.

Het eerste niveau van beperkingen biedt ondersteuning voor dynamische gegevensmaskering, waardoor gevoelige gegevens voor gebruikers zonder bevoegdheden worden verborgen. Een voordeel van deze aanpak is dat deze kan worden geïntegreerd in de onboarding van een gegevensset met een REST API.

Het tweede niveau is het toevoegen van beveiliging op kolomniveau om te voorkomen dat niet-HR-managers salarissen en beveiliging op rijniveau zien om te beperken welke rijen Europese en Noord-Amerika n teamleden kunnen zien.

Naast transparante gegevensversleuteling zou de beveiligingslaag de kolom met gegevens versleutelen en ontsleutelen bij lezen.

De tabellen kunnen beschikbaar worden gesteld aan Azure Databricks met Apache Spark-connector: SQL Server en Azure SQL Database.

Optie 4: Azure Databricks

Optie vier is om Azure Databricks te gebruiken om gevoelige (persoonlijke gegevens) te verkennen. Het gebruik van een combinatie van Fernet-versleutelingsbibliotheken, door de gebruiker gedefinieerde functies (UDF's), Databricks-geheimen, toegangsbeheer voor tabellen en dynamische weergavefuncties helpt bij het versleutelen en ontsleutelen van kolommen.

In het blogbericht wordt het afdwingen van versleuteling op kolomniveau en het voorkomen van gegevensduplicatie beschreven:

De eerste stap in dit proces is het beveiligen van de gegevens door deze tijdens opname te versleutelen en een mogelijke oplossing is de Fernet Python-bibliotheek. Fernet maakt gebruik van symmetrische versleuteling, die is gebouwd met verschillende standaard cryptografische primitieven. Deze bibliotheek wordt gebruikt in een versleutelings-UDF waarmee we elke kolom in een gegevensframe kunnen versleutelen. Om de versleutelingssleutel op te slaan, gebruiken we Databricks-geheimen met besturingselementen voor toegang om alleen toegang te krijgen tot het gegevensopnameproces. Zodra de gegevens naar onze Delta Lake-tabellen zijn geschreven, zijn persoonlijke gegevenskolommen met waarden zoals burgerservicenummer, telefoonnummer, creditcardnummer en andere id's onmogelijk voor een onbevoegde gebruiker om te lezen.

Zodra u de gevoelige gegevens hebt geschreven en beveiligd, hebt u een manier nodig voor bevoegde gebruikers om de gevoelige gegevens te lezen. Het eerste wat u moet doen, is een permanente UDF maken om toe te voegen aan het Hive-exemplaar dat wordt uitgevoerd op Databricks. Als u wilt dat een UDF permanent is, moet deze worden geschreven in Scala. Gelukkig heeft Fernet ook een Scala-implementatie die u kunt gebruiken voor uw ontsleutelde leesbewerkingen. Deze UDF heeft ook toegang tot hetzelfde geheim dat in de versleutelde schrijfbewerking wordt gebruikt om de ontsleuteling uit te voeren. In dit geval wordt het toegevoegd aan de Spark-configuratie van het cluster. Hiervoor moeten we clustertoegangsbeheer toevoegen voor bevoegde en niet-bevoegde gebruikers om hun toegang tot de sleutel te beheren. Zodra de UDF is gemaakt, kunnen we deze gebruiken in onze weergavedefinities voor bevoegde gebruikers om de ontsleutelde gegevens te zien.

Met dynamische weergavefuncties kunt u slechts één weergave maken en de versleutelde of ontsleutelde waarden retourneren op basis van de Databricks-groep waartoe ze behoren.

In het vorige voorbeeld maakt u twee dynamische weergavefuncties, een voor Noord-Amerika en een voor Europa, en implementeert u de versleutelingstechnieken in dit notebook.

Noord-Amerika weergave:

-- 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'

Europese visie:

-- 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'

Dit werkt alleen als u toegangsbeheer voor Azure Databricks-tabellen inschakelt in de werkruimte en de volgende machtigingen toepast:

  • Toegang tot de vhr_us weergave verlenen DA-AMERICA-HRMANAGER-R en DA-AMERICA-HRGENERAL-R Microsoft Entra-groepen.
  • Toegang tot de vhr_eu weergave verlenen DA-EUROPE-HRMANAGER-R en DA-EUROPE-HRGENERAL-R Microsoft Entra-groepen.

Omdat kolommen zijn versleuteld en niet kunnen worden ontsleuteld in de vertrouwelijke of onderstaande werkruimte, kunnen de vertrouwelijke of onderstaande werkruimten nog steeds gebruikmaken van Pass Through-verificatie van Microsoft Entra en gebruikers toestaan om het meer te verkennen, op basis van hun machtigingen.

Wanneer tabeltoegang wordt gebruikt, worden teams die toegang vereisen, toegevoegd aan de Azure Databricks-werkruimte. Azure Databricks gebruikt service-principals om toe te wijzen aan Azure Data Lake Storage, maar de gegevens worden beveiligd met toegangsbeheer voor Azure Databricks-tabellen.

Wanneer er nieuwe gegevensproducten worden geïmplementeerd, moet een deel van het DevOps-proces scripts uitvoeren om de tabelmachtigingen in de Azure Databricks-werkruimte in te stellen en de juiste Microsoft Entra-groepen aan deze machtigingen toe te voegen.

Notitie

Toegangsbeheer voor Azure Databricks-tabellen kan niet worden gecombineerd met Pass Through-verificatie van Microsoft Entra. Daarom kunt u slechts één Azure Databricks-werkruimte gebruiken en in plaats daarvan toegangsbeheer voor tabellen gebruiken.

Beperkte gegevens

Naast het implementeren van opties voor vertrouwelijke of beperkte gegevens, raden we u ook aan zeer vertrouwelijke gegevens te hosten in een toegewezen landingszone en landingszone voor gegevensbeheer.

Hiermee kunnen specifieke vereisten worden toegestaan, zoals Just-In-Time-toegang, door de klant beheerde sleutels voor versleuteling en inkomende of uitgaande beperkingen die zijn toegepast op de landingszone. De richtlijnen hebben geëvalueerd hoe u gegevens van dit type in dezelfde landingszone voor gegevens plaatst, maar verschillende opslagaccounts. Het kan echter de oplossing ingewikkeld maken op de netwerklaag, bijvoorbeeld met netwerkbeveiligingsgroepen en andere.

De toegewezen 'beperkte' landingszone voor gegevensbeheer moet verbinding maken met de catalogus van de gegevens in de 'beperkte' gegevenslandingszone. Het moet beperken wie naar deze gegevens in de catalogus kan zoeken.

Volgende stappen