Share via

Datenschutz für Analysen auf Cloudebene in Azure

  • Artikel

Mit Analysen auf Cloudebene können Organisationen die besten Muster für ihre Anforderungen ermitteln und gleichzeitig personenbezogene Daten auf mehreren Ebenen schützen. Personenbezogene Daten sind alle Daten, anhand derer Einzelpersonen identifiziert werden können, z. B. Führerscheinnummern, Sozialversicherungsnummern, Bankkontonummern, Reisepassnummern, E-Mail-Adressen usw. Heutzutage bestehen viele Vorschriften für den Datenschutz der Benutzer.

Klassifizierungsschema für die Datenvertraulichkeit

Klassifizierung Beschreibung
Öffentlich Jeder kann auf die Daten zugreifen, und die Daten können an jeden gesendet werden (z. B. offene Verwaltungsdaten).
Nur interne Verwendung. Nur Mitarbeiter können auf die Daten zugreifen, und die Daten können nicht an Empfänger außerhalb des Unternehmens gesendet werden.
Vertraulich Die Daten können nur geteilt werden, wenn sie für einen bestimmten Vorgang erforderlich sind. Ohne Geheimhaltungsvereinbarung können die Daten nicht an Empfänger außerhalb des Unternehmens gesendet werden.
Vertraulich (personenbezogene Daten) Die Daten enthalten private Informationen, die maskiert und nur nach dem Need-to-know-Prinzip für eine begrenzte Zeit geteilt werden dürfen. Die Daten können nicht an nicht autorisierte Mitarbeiter oder an Personen außerhalb des Unternehmens gesendet werden.
Eingeschränkt Die Daten können nur mit benannten Personen geteilt werden, die für den Schutz der Daten verantwortlich sind (z. B. juristische Dokumente oder Geschäftsgeheimnisse).

Vor der Erfassung von Daten müssen Sie die Daten als mit geringem bis mittleren Vertraulichkeitsgrad oder als vertraulich (personenbezogene Daten) kategorisieren:

  • Daten können mit geringem bis mittleren Vertraulichkeitsgrad kategorisiert werden, wenn ein Benutzer Zugriff auf die Datenressource auf der Ebene angereicherter oder kuratierter Daten erhält. Die Benutzer können alle Spalten und Zeilen anzeigen.

  • Daten können als vertraulich (personenbezogene Daten) kategorisiert werden, wenn Einschränkungen bezüglich der Spalten und Zeilen gelten, die für unterschiedliche Benutzer angezeigt werden.

Wichtig

Ein Dataset kann sich von mit geringem bis mittleren Vertraulichkeitsgrad in vertraulich (personenbezogene Daten) ändern, wenn Daten kombiniert werden. Wen Daten persistent sein müssen, sollten sie in einen eigenen Ordner kopiert werden, der der Vertraulichkeitsklassifizierung und dem Prozess für das Onboarding der Daten entspricht.

Mit geringem bis mittleren Vertraulichkeitsgrad

Wir erstellen für jedes Datenprodukt, für das das Onboarding durchgeführt wurde, zwei Data Lake-Ordner auf den angereicherten und kuratierten Ebenen: mit geringem bis mittleren Vertraulichkeitsgrad und vertraulich (personenbezogene Daten). Mithilfe von Zugriffssteuerungslisten aktivieren wir die Passthrough-Authentifizierung von Microsoft Azure Directory (Microsoft Entra ID).

Wenn ein Datenanwendungsteam das Onboarding einer mit geringem bis mittleren Vertraulichkeitsgrad klassifizierten Datenressource durchführt, können Benutzerprinzipalnamen und Dienstprinzipalobjekte zu zwei Microsoft Entra-Gruppen hinzugefügt werden (eine für Lese-/Schreibzugriff und die andere für schreibgeschützten Zugriff). Diese beiden Microsoft Entra-Gruppen müssen während des Onboardingprozesses erstellt und im entsprechenden Datenproduktordner mit Containern vom Typ mit geringem bis mittleren Vertraulichkeitsgrad für Rohdaten und angereicherte Daten sortiert werden.

Dieses Muster ermöglicht es jedem Computeprodukt, das die Microsoft Entra-Passthrough-Authentifizierung unterstützt, eine Verbindung mit dem Data Lake herzustellen und angemeldete Benutzer*innen zu authentifizieren. Wenn Benutzer*innen Mitglied der Microsoft Entra-Gruppe der Datenressource sind, können sie über die Microsoft Entra-Passthrough-Authentifizierung auf die Daten zugreifen. Sie ermöglicht es Benutzern innerhalb der Gruppe, die gesamte Datenressource ohne Richtlinienfilter zu lesen. Der Zugriff kann dann mit entsprechenden Protokollen und Microsoft Graph genau überwacht werden.

Empfehlungen zum Data Lake-Layout finden Sie unter Bereitstellen von drei Azure Data Lake Storage Gen2-Konten für jede Datenzielzone.

Hinweis

Beispiele für Computeprodukte sind Azure Databricks, Azure Synapse Analytics, Apache Spark und bedarfsgesteuerte Azure Synapse SQL-Pools mit aktivierter Microsoft Entra-Passthrough-Authentifizierung.

Vertrauliche (personenbezogene) Daten

Für vertrauliche (personenbezogene) Daten muss das Unternehmen mittels Richtlinie, Datenkopien oder Compute beschränken, was für die Benutzer angezeigt wird. In diesem Fall muss die Organisation erwägen, die Zugriffssteuerung auf die Computeebene zu verschieben oder in sie zu injizieren. Es gibt vier verschiedene Ansätze für den Schutz von Daten in Analysen auf Cloudebene.

Beispielszenario

Im folgenden Beispiel werden Optionen zum Schützen vertraulicher (personenbezogener Daten) beschrieben:

Eine Datenanwendung erfasst ein Personaldatenprodukt der Personalabteilung für Nordamerika und Europa. In dem Anwendungsfall dürfen für europäische Benutzer nur europäische Personaldatensätze und für nordamerikanische Benutzer nur nordamerikanische Personaldatensätze angezeigt werden. Außerdem dürfen Spalten mit Gehaltsdaten nur für Personalverantwortliche angezeigt werden.

Die ersten beiden Optionen bieten eine Möglichkeit, vertrauliche (personenbezogene) Daten zu behandeln, und sie ermöglichen den Integrationsteams und Datenproduktteams auch die Steuerung der Identifizierung und Zugriffsbeschränkung. Dies kann für eine kleine Analyseplattform ausreichen. In der Datenverwaltungszielzone für ein großes Unternehmen mit Hunderten von Datenprodukten sollte jedoch eine Richtlinien-Engine verwendet werden. Richtlinien-Engines unterstützen das zentrale Verwalten, Sichern und Steuern:

  • Zugriff auf Daten
  • Verwalten des Datenlebenszyklus
  • Interne und externe Richtlinien und Vorschriften
  • Richtlinien für die Datenfreigabe
  • Identifizieren von vertraulichen (personenbezogenen) Daten
  • Einblicke in Schutz und Konformität
  • Richtlinien für die Berichterstellung zum Datenschutz

In der Regel wird eine Richtlinien-Engine in einen Datenkatalog wie Azure Purview integriert. Azure Marketplace bietet Lösungen von Drittanbietern, und einige Anbieter verwenden Azure Synapse und Azure Databricks, um Informationen zu verschlüsseln und zu entschlüsseln und Sicherheit auf Zeilen- und Spaltenebene zu bieten. Im Januar 2022 wurde für Azure Purview eine Public Preview für Zugriffsrichtlinien zur Steuerung des Zugriffs auf Daten veröffentlicht, die in Blobspeicher oder in ADLS Gen2 (Azure Data Lake Storage) gespeichert sind. Siehe Datasetbereitstellung durch Datenbesitzer für Azure Storage (Vorschau).

Von der Richtlinien-Engine sollten Microsoft Entra-Gruppen verwendet werden, um Richtlinien auf Datenprodukte anzuwenden. Von jeder Richtlinienlösung, die Datenschutz bietet, wird erwartet, dass sie vertrauliche (personenbezogene) Daten mit einem Token versieht und immer über Attributzugriffssteuerung eine Überprüfung durchführt, damit die Benutzer die Token aus den Spalten entfernen können, auf die sie zugreifen müssen.

Wie erwähnt, ist es für eine erfolgreiche Implementierung einer Richtlinien-Engine wichtig, dass sie in den Datenkatalog integriert wird, und für DevOps muss eine REST-API verwendet werden, um das Onboarding eines neuen Datasets durchzuführen. Wenn Datenanwendungsteams Lesedatenquellen erstellen, werden diese im Datenkatalog registriert und helfen dabei, vertrauliche (personenbezogene) Daten zu identifizieren. Die Richtlinien-Engine muss die Definition importieren und den Zugriff auf Daten verweigern, bis die Teams die entsprechenden Zugriffsrichtlinien eingerichtet haben. All dies sollte über einen REST-API-Workflow aus der IT-Service-Management-Lösung erfolgen.

Option 2: Versionen für „Mit geringem bis mittleren Vertraulichkeitsgrad“ und „Vertraulich (personenbezogene Daten)“

Für jedes Datenprodukt, das als Vertraulich (personenbezogene Daten) klassifiziert ist, werden durch die zugehörige Pipeline zwei Kopien erstellt. Eine vom Typ Mit geringem bis mittleren Vertraulichkeitsgrad, in der alle als Vertraulich (personenbezogene Daten) klassifizierten Spalten entfernt werden und die unter dem Ordner confidential or below (Mit geringem bis mittleren Vertraulichkeitsgrad) für das Datenprodukt erstellt wird. Die andere Kopie wird im Ordner sensitive (personal data) (Vertraulich (personenbezogene Daten)) für das Datenprodukt erstellt und enthält alle vertraulichen Daten. Jedem Ordner wird eine Microsoft Entra-Sicherheitsgruppe vom Typ „Lesen“ und eine Microsoft Entra-Sicherheitsgruppe vom Typ „Schreiben“ zugewiesen. Mithilfe der Datenzugriffsverwaltung kann ein Benutzer Zugriff auf das Datenprodukt anfordern.

Dadurch werden zwar vertrauliche (personenbezogene) Daten und Daten mit geringem bis mittleren Vertraulichkeitsgrad voneinander getrennt, allerdings kann ein Benutzer, dem über die Passthrough-Authentifizierung von Active Directory Zugriff auf die vertraulichen (personenbezogenen) Daten gewährt wurde, alle Zeilen abfragen. Wenn Sie Sicherheit auf Zeilenebene benötigen, müssen Sie Option 1: Richtlinien-Engine (empfohlen) oder Option 3: Azure SQL-Datenbank, SQL Managed Instance oder SQL-Pools in Azure Synapse Analytics verwenden.

Option 3: Azure SQL-Datenbank, SQL Managed Instance oder SQL-Pools in Azure Synapse Analytics

Eine Datenanwendung verwendet SQL-Datenbank, SQL Managed Instance oder SQL-Pools in Azure Synapse Analytics, um die Datenprodukte in eine Datenbank zu laden, die Sicherheit auf Zeilenebene, Sicherheit auf Spaltenebene und dynamische Datenmaskierung unterstützt. Die Datenanwendungsteams erstellen unterschiedliche Microsoft Entra-Gruppen und weisen Berechtigungen zu, die die Vertraulichkeit der Daten unterstützen.

Für den Anwendungsfall dieses Szenarios müssen Datenanwendungsteams die vier folgenden Microsoft Entra-Gruppen mit schreibgeschütztem Zugriff erstellen:

Group Berechtigung
DA-AMERICA-HRMANAGER-R Anzeigen der Personaldatenressource des Personalwesens für Nordamerika mit Gehaltsinformationen.
DA-AMERICA-HRGENERAL-R Anzeigen der Personaldatenressource des Personalwesens für Nordamerika ohne Gehaltsinformationen.
DA-EUROPE-HRMANAGER-R Anzeigen der Personaldatenressource des Personalwesens für Europa mit Gehaltsinformationen.
DA-EUROPE-HRGENERAL-R Anzeigen der Personaldatenressource des Personalwesens für Europa ohne Gehaltsinformationen.

Die erste Ebene der Einschränkungen unterstützt die dynamische Datenmaskierung, durch die für Benutzer ohne Berechtigungen vertrauliche Daten ausblendet werden. Dieser Ansatz bietet den Vorteil, dass er mit einer REST-API in das Onboarding eines Datasets integriert werden kann.

Die zweite Ebene besteht im Hinzufügen von Sicherheit auf Spaltenebene, um zu verhindern, dass für Mitarbeiter, die keine Personalverantwortliche sind, Gehälter angezeigt werden, und im Hinzufügen von Sicherheit auf Zeilenebene, um die Zeilen einzuschränken, die für europäische und nordamerikanische Teammitglieder angezeigt werden.

Zusätzlich zur transparenten Datenverschlüsselung umfasst die Sicherheitsstufe die Verschlüsselung der Datenspalte und die Entschlüsselung beim Lesen.

Die Tabellen können mit dem Apache Spark-Connector für SQL Server und Azure SQL in Azure Databricks verfügbar gemacht werden.

Option 4: Azure Databricks

Option 4 ist die Verwendung von Azure Databricks zum Untersuchen vertraulicher (personenbezogener) Daten. Die Verwendung einer Kombination aus Fernet-Verschlüsselungsbibliotheken, benutzerdefinierten Funktionen (User-Defined Functions, UDFs), Databricks-Geheimnissen, Tabellenzugriffssteuerung und dynamischen Ansichtsfunktionen hilft beim Verschlüsseln und Entschlüsseln von Spalten.

Im Blogbeitrag Enforcing Column-level Encryption and Avoiding Data Duplication With PII (Erzwingen von Verschlüsselung auf Spaltenebene und Vermeiden von Datenduplizierung mit PII, in englischer Sprache) wird Folgendes erläutert:

Der erste Schritt in diesem Prozess besteht im Schützen der Daten durch Verschlüsselung während der Erfassung. Eine mögliche Lösung ist die Python-Bibliothek „Fernet“. Für Fernet wird symmetrische Verschlüsselung verwendet, die mit mehreren kryptografischen Standardprimitiven erstellt wird. Diese Bibliothek wird in einem Verschlüsselungs-UDF verwendet, mit dem Sie jede Spalte in einem Datenrahmen verschlüsseln können. Um den Verschlüsselungsschlüssel zu speichern, verwenden Sie Databricks-Geheimnisse mit Zugriffssteuerungen, um nur dem Datenerfassungsprozess den Zugriff darauf zu erlauben. Sobald die Daten in die Delta Lake-Tabellen geschrieben wurden, können personenbezogene Datenspalten, die Werte wie Sozialversicherungsnummer, Telefonnummer, Kreditkartennummer und andere Bezeichner enthalten, durch einen nicht autorisierten Benutzer nicht gelesen werden.

Sobald Sie die vertraulichen Daten geschrieben und geschützt haben, benötigen Sie eine Möglichkeit für berechtigte Benutzer, die sensiblen Daten zu lesen. Zunächst muss ein permanentes benutzerdefiniertes UDF erstellt werden, das der Hive-Instanz hinzugefügt wird, die in Databricks ausgeführt wird. Damit ein UDF dauerhaft ist, muss es in Scala geschrieben werden. Glücklicherweise verfügt Fernet auch über eine Scala-Implementierung, die Sie für Ihre entschlüsselten Lesevorgänge verwenden können. Dieses UDF greift auch auf dasselbe Geheimnis zu, das im verschlüsselten Schreibvorgang für die Entschlüsselung verwendet wird, und wird in diesem Fall der Spark-Konfiguration des Clusters hinzugefügt. Dies erfordert, dass Sie Clusterzugriffssteuerungen für berechtigte und nicht berechtigte Benutzer hinzufügen, um ihren Zugriff auf den Schlüssel zu steuern. Sobald das UDF erstellt wurde, können Sie es in Ihren Ansichtsdefinitionen für berechtigte Benutzer verwenden, um die entschlüsselten Daten anzuzeigen.

Mit dynamischen Ansichtsfunktionen können Sie nur eine Ansicht erstellen und die verschlüsselten oder entschlüsselten Werte basierend auf der Databricks-Gruppe zurückgeben, zu der sie gehören.

Im vorherigen Beispiel erstellen Sie zwei dynamische Ansichtsfunktionen, eine für Nordamerika und eine für Europa, und implementieren die Verschlüsselungstechniken in diesem Notebook.

Ansicht für Nordamerika:

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

Ansicht für Europa:

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

Hierfür aktivieren Sie im Arbeitsbereich die Tabellenzugriffssteuerung von Azure Databricks und wenden die folgenden Berechtigungen an:

  • Gewähren Sie DA-AMERICA-HRMANAGER-R und DA-AMERICA-HRGENERAL-R Microsoft Entra-Gruppenzugriff auf die vhr_us-Ansicht.
  • Gewähren Sie DA-EUROPE-HRMANAGER-R und DA-EUROPE-HRGENERAL-R Microsoft Entra-Gruppenzugriff auf die vhr_eu-Ansicht.

Da Spalten verschlüsselt sind und sich im Arbeitsbereich mit geringem bis mittleren Vertraulichkeitsgrad nicht entschlüsseln lassen, kann in den Arbeitsbereichen mit der Klassifizierung vertraulich oder geheim weiterhin die Microsoft Entra-Passthrough-Authentifizierung verwendet werden, und Benutzer*innen können den Lake entsprechend ihren Berechtigungen erkunden.

Wenn Tabellenzugriff verwendet wird, werden Teams, die Zugriff benötigen, dem Azure Databricks-Arbeitsbereich hinzugefügt. In Azure Databricks werden Dienstprinzipale zum Zuordnen zu Azure Data Lake Storage verwendet, die Daten werden jedoch weiterhin mit der Azure Databricks-Tabellenzugriffssteuerung geschützt.

Wenn neue Datenprodukte bereitgestellt werden, muss ein Teil des DevOps-Prozesses Skripts ausführen, um die Tabellenberechtigungen im Azure Databricks-Arbeitsbereich einzurichten und diesen Berechtigungen die richtigen Microsoft Entra-Gruppen hinzuzufügen.

Hinweis

Die Azure Databricks-Tabellenzugriffssteuerung kann nicht mit der Microsoft Entra-Passthrough-Authentifizierung kombiniert werden. Aus diesem Grund können Sie nur einen Azure Databricks-Arbeitsbereich verwenden und stattdessen die Tabellenzugriffssteuerung nutzen.

Eingeschränkte Daten

Neben der Implementierung von Optionen für vertrauliche oder eingeschränkte Daten empfiehlt es sich auch, streng vertrauliche Daten in einer dedizierten Datenzielzone und Datenverwaltungszielzone zu hosten.

Dies ermöglicht das Erfüllen spezieller Anforderungen, z. B. Just-in-Time-Zugriff, kundenseitig verwaltete Verschlüsselungsschlüssel und Einschränkungen für eingehende oder ausgehende Daten, die auf die Zielzone angewendet werden. In der Anleitung wurde das Aufbewahren von Daten dieses Typs in derselben Datenzielzone, jedoch in unterschiedlichen Speicherkonten, bewertet. Hierdurch kann die Lösung jedoch in der Netzwerkschicht kompliziert werden, z. B. mit Netzwerksicherheitsgruppen.

Mit der dedizierten Datenverwaltungszielzone für eingeschränkte Daten muss eine Verbindung hergestellt werden, um die Daten in der Datenzielzone für eingeschränkte Daten zu katalogisieren. Sie sollte einschränken, wer im Katalog nach diesen Daten suchen kann.

Nächste Schritte