Leitfaden für personenbezogene Daten, die in Log Analytics und Application Insights gespeichert sind

Log Analytics ist ein Datenspeicher, der wahrscheinlich auch personenbezogene Daten enthält. Application Insights speichert die Daten auf einer Log Analytics-Partition. In diesem Artikel erfahren Sie, wo sich solche Daten üblicherweise in Log Analytics und Application Insights befinden und welche Möglichkeiten Sie im Zusammenhang mit diesen Daten haben.

Hinweis

Im Rahmen dieses Artikels bezieht sich Protokolldaten auf Daten, die von einem Log Analytics-Arbeitsbereich gesendet werden, während Anwendungsdaten Daten bezeichnet, die von Application Insights gesammelt werden. Wenn Sie eine arbeitsbereichsbasierte Application Insights-Ressource verwenden, gelten die Informationen zu Protokolldaten, bei Verwendung der klassischen Application Insights-Ressource gelten jedoch die Informationen zu Anwendungsdaten.

Hinweis

Informationen über Anzeigen oder Löschen von personenbezogenen Daten finden Sie unter Anträge betroffener Personen für Azure im Rahmen der DSGVO. Weitere Informationen zur DSGVO finden Sie im Abschnitt zur DSGVO im Microsoft Trust Center und im Abschnitt zur DSGVO im Service Trust Portal.

Strategie für den Umgang mit personenbezogenen Daten

Die Gestaltung der Strategie für den Umgang mit personenbezogenen Daten liegt letztendlich bei Ihnen und Ihrem Unternehmen. Im Anschluss finden Sie einige mögliche Herangehensweisen. Diese sind absteigend nach technischer Präferenz sortiert:

  • Sorgen Sie nach Möglichkeit dafür, dass Daten, die als „personenbezogen“ betrachtet werden können, gar nicht erst gesammelt oder aber verschleiert, anonymisiert oder anderweitig verändert werden. Dies ist mit Abstand die bevorzugte Vorgehensweise und erspart die Erstellung einer wirksamen und äußerst kostspieligen Datenverarbeitungsstrategie.
  • Sollte diese Vorgehensweise nicht möglich sein, versuchen Sie, die Daten zu normalisieren, um die Auswirkungen auf die Datenplattform und auf die Leistung zu verringern. Statt beispielsweise eine explizite Benutzer-ID zu protokollieren, erstellen Sie Nachschlagedaten, die den Benutzernamen und die dazugehörigen Details mit einer internen ID korrelieren, die dann an anderer Stelle protokolliert werden kann. Wenn Sie daraufhin von einem Benutzer gebeten werden, seine personenbezogenen Informationen zu löschen, muss ggf. nur die entsprechende Zeile in der Nachschlagetabelle gelöscht werden.
  • Falls personenbezogene Daten gesammelt werden müssen, erstellen Sie einen Prozess basierend auf dem Bereinigungs-API-Pfad und dem vorhandenen Abfrage-API-Pfad, um allen Vorschriften zu genügen, die möglicherweise im Zusammenhang mit dem Exportieren und Löschen personenbezogener Daten eines Benutzers gelten.

Wo befinden sich personenbezogene Daten in Log Analytics?

Log Analytics ist ein flexibler Datenspeicher, der zwar ein Schema für die Daten vorgibt, jedoch für jedes Feld das Überschreiben mit benutzerdefinierten Werten zulässt. Darüber hinaus können beliebige benutzerdefinierte Schemas erfasst werden. Daher ist es unmöglich zu sagen, wo genau personenbezogene Daten in Ihrem jeweiligen Arbeitsbereich vorhanden sind. Bei den folgenden Speicherorten handelt es sich jedoch um gute Ausgangspunkte für die Suche in Ihrem Datenbestand:

Protokolldaten

  • IP-Adressen: Log Analytics erfasst verschiedenste IP-Informationen für viele verschiedene Tabellen. Die folgende Abfrage zeigt beispielsweise alle Tabellen, in denen in den letzten 24 Stunden IPv4-Adressen erfasst wurden:
    search * 
    | where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' //RegEx originally provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
    | summarize count() by $table
    
  • Benutzer-IDs: Benutzer-IDs befinden sich in verschiedensten Lösungen und Tabellen. Mit dem Suchbefehl können Sie Ihr gesamtes Dataset nach einem bestimmten Benutzernamen durchsuchen:
    search "[username goes here]"
    
    Wichtig: Suchen Sie nicht nur nach lesbaren Benutzernamen, sondern auch nach GUIDs, die direkt zu einem bestimmten Benutzer zurückverfolgt werden können.
  • Geräte-IDs: Geräte-IDs sind mit Benutzer-IDs vergleichbar und werden gelegentlich als „privat“ betrachtet. Verwenden Sie die gleiche Vorgehensweise, die weiter oben für Benutzer-IDs angegeben ist, um Tabellen zu ermitteln, bei denen dies ggf. relevant ist.
  • Benutzerdefinierte Daten: In Log Analytics stehen verschiedene Erfassungsmethoden zur Verfügung: benutzerdefinierte Protokolle und benutzerdefinierte Felder, die HTTP-Datensammler-API und benutzerdefinierte Daten, die im Rahmen von Systemereignisprotokollen erfasst werden. Alle diese Optionen können personenbezogene Daten enthalten und müssen auf entsprechende Daten untersucht werden.
  • Durch die Lösung erfasste Daten: Da es sich bei dem Lösungsmechanismus um einen Mechanismus mit offenem Ende handelt, empfiehlt es sich, alle von Lösungen generierten Tabellen zu überprüfen, um die Compliance zu gewährleisten.

Anwendungsdaten

  • IP-Adressen: Obwohl Application Insights standardmäßig alle IP-Adressfelder mit „0.0.0.0“ verschleiert, ist es durchaus üblich, diesen Wert mit der tatsächlichen Benutzer-IP zu überschreiben, um Sitzungsinformationen zu speichern. Mithilfe der folgenden Analytics-Abfrage kann nach allen Tabellen gesucht werden, die in den letzten 24 Stunden in der Spalte für die IP-Adresse andere Werte als „0.0.0.0“ enthalten haben:
    search client_IP != "0.0.0.0"
    | where timestamp > ago(1d)
    | summarize numNonObfuscatedIPs_24h = count() by $table
    
  • Benutzer-IDs: Standardmäßig verwendet Application Insights zufällig generierte IDs für Benutzer und die Sitzungsnachverfolgung. Allerdings werden diese Felder häufig überschrieben, um eine ID zu speichern, die für die Anwendung größere Relevanz hat, z.B. Benutzernamen, AAD-GUIDs usw. Diese IDs werden häufig als personenbezogene Daten angesehen und sollten deshalb entsprechend gehandhabt werden. Wir empfehlen, diese IDs immer zu verschleiern oder zu anonymisieren. Felder, in denen diese Werte häufig vorkommen, sind beispielsweise „session_Id“, „user_Id“, „user_AuthenticatedId“, „user_AccountId“ sowie „customDimensions“.
  • Benutzerdefinierte Daten: Application Insights ermöglicht es Ihnen, eine Gruppe benutzerdefinierter Dimensionen an einen beliebigen Datentyp anzufügen. Bei diesen Dimensionen kann es sich um beliebige Daten handeln. Ermitteln Sie mithilfe der folgenden Abfrage alle benutzerdefinierten Dimensionen, die in den letzten 24 Stunden gesammelt wurden:
    search * 
    | where isnotempty(customDimensions)
    | where timestamp > ago(1d)
    | project $table, timestamp, name, customDimensions 
    
  • Daten im Speicher und während der Übertragung: Application Insights erfasst Ausnahmen, Anforderungen, Abhängigkeitsaufrufe und Ablaufverfolgungen. Personenbezogene Daten können häufig auf Code- und HTTP-Aufrufebene gesammelt werden. Überprüfen Sie die Tabellen für Ausnahmen, Anforderungen, Abhängigkeiten und Ablaufverfolgungen, um solche Daten zu ermitteln. Verwenden Sie nach Möglichkeit Telemetrieinitialisierer, um diese Daten zu verschleiern.
  • Aufzeichnungen des Momentaufnahmedebuggers: Mithilfe des Features Momentaufnahmedebugger in Application Insights können Sie Debugmomentaufnahmen erfassen, sobald eine Ausnahme in der Produktionsinstanz Ihrer Anwendung abgefangen wird. Momentaufnahmen zeigen die gesamte Stapelüberwachung, die zu den Ausnahmen führt, sowie die Werte für lokale Variablen in jedem Schritt im Stapel. Leider ermöglicht dieses Feature weder das selektive Löschen von Fangpunkten noch den programmgesteuerten Zugriff auf Daten innerhalb der Momentaufnahme. Falls die Standardaufbewahrungsrate für Momentaufnahmen Ihren Compliancevorgaben nicht entspricht, wird empfohlen, das Feature zu deaktivieren.

Exportieren und Löschen personenbezogener Daten

Wie bereits weiter oben im Abschnitt Strategie für den Umgang mit personenbezogenen Daten erwähnt, wird dringend empfohlen, die Datensammlungsrichtlinien nach Möglichkeit so zu strukturieren, dass personenbezogene Daten gar nicht erst gesammelt oder aber verschleiert, anonymisiert oder anderweitig verändert werden, sodass sie nicht mehr als „personenbezogen“ anzusehen sind. Der Umgang mit den Daten ist in erster Linie mit Kosten für Sie und Ihr Team verbunden: Sie müssen eine Strategie ausarbeiten und automatisieren sowie eine Schnittstelle entwickeln, über die Ihre Kunden mit ihren Daten interagieren können. Außerdem fallen laufende Wartungskosten an. Darüber hinaus bedeutet dies einen hohen Rechenaufwand für Log Analytics und Application Insights, und eine hohe Anzahl gleichzeitiger Abfrage- oder Bereinigungs-API-Aufrufe kann sich negativ auf alle anderen Interaktionen mit Log Analytics-Funktionen auswirken. Allerdings gibt es tatsächlich einige Szenarien, in denen personenbezogene Daten erfasst werden müssen. In diesen Fällen sollten Sie die Daten wie in diesem Abschnitt beschrieben handhaben.

Hinweis

Dieser Artikel enthält eine ausführliche Vorgehensweise zum Löschen personenbezogener Daten vom Gerät oder aus dem Dienst, die Sie bei Ihren Pflichten gemäß der DSGVO unterstützen kann. Allgemeine Informationen zur DSGVO finden Sie im Abschnitt zur DSGVO im Microsoft Trust Center und im Abschnitt zur DSGVO im Service Trust Portal.

Anzeigen und Exportieren

Sowohl für das Anzeigen als auch für das Exportieren von Datenanforderungen sollte die Log Analytics-Abfrage-API oder die Application Insights-Abfrage-API verwendet werden. Die Logik, mit der die Daten in eine geeignete Form konvertiert werden, um sie für Ihre Benutzer bereitzustellen, muss von Ihnen selbst implementiert werden. Azure Functions eignet sich hervorragend zum Hosten einer solchen Logik.

Wichtig

Obwohl die Mehrzahl der Bereinigungsvorgänge wesentlich schneller als die SLA ausgeführt werden kann, ist – aufgrund der starken Auswirkung auf die verwendete Datenplattform – die formelle SLA für die Ausführung von Bereinigungsvorgängen auf 30 Tage festgelegt. Diese SLA erfüllt die DSGVO-Anforderungen. Dies ist ein automatisierter Prozess. Es gibt daher keine Möglichkeit, eine schnellere Verarbeitung eines Vorgangs anzufordern.

Löschen

Warnung

Löschvorgänge in Log Analytics sind destruktiv und unumkehrbar. Seien Sie bei der Ausführung äußerst vorsichtig.

Im Rahmen der Vorgehensweisen für den Datenschutz haben wir einen API-Pfad für die Bereinigung verfügbar gemacht. Dieser Pfad sollte aufgrund der Risiken im Zusammenhang mit seiner Verwendung, möglichen Leistungseinbußen sowie einer möglichen Verzerrung von Aggregationen, Messungen und anderen Aspekten Ihrer Log Analytics-Daten möglichst selten verwendet werden. Alternative Methoden für den Umgang mit personenbezogenen Daten finden Sie im Abschnitt Strategie für den Umgang mit personenbezogenen Daten.

Hinweis

Nachdem der Löschvorgang durchgeführt wurde, kann nicht auf die Daten zugegriffen werden, solange der Status des Löschvorgangs ausstehend lautet.

Das Bereinigen ist ein Vorgang, der hohe Berechtigungen erfordert, und weder eine App noch ein Benutzer in Azure (einschließlich des Ressourcenbesitzers) ist zur Ausführung berechtigt, sofern nicht in Azure Resource Manager explizit eine entsprechende Rolle zugewiesen wurde. Dies ist die Rolle Datenpurger, die aufgrund des möglichen Datenverlusts sehr zurückhaltend vergeben werden sollte.

Wichtig

Zur Verwaltung von Systemressourcen werden Bereinigungsanforderungen auf 50 Anforderungen pro Stunde gedrosselt. Sie sollten die Ausführung von Bereinigungsanforderungen in Batches einbinden, indem Sie einen einzelnen Befehl senden, dessen Prädikat alle Benutzeridentitäten enthält, die bereinigt werden müssen. Verwenden Sie den in-Operator, um mehrere Identitäten anzugeben. Sie sollten die Abfrage ausführen, bevor Sie die Bereinigungsanforderung ausführen, um zu überprüfen, ob die Ergebnisse erwartet werden.

Nachdem die Azure Resource Manager-Rolle zugewiesen wurde, sind zwei neue API-Pfade verfügbar:

Protokolldaten

  • POST purge: Verwendet ein Objekt, das Parameter der zu löschenden Daten angibt, und gibt eine Verweis-GUID zurück.

  • GET purge status: Der Aufruf von „POST purge“ gibt einen Header vom Typ „x-ms-status-location“ zurück, der eine URL enthält, die Sie zum Ermitteln des Status Ihrer Bereinigungs-API aufrufen können. Beispiel:

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-version=2015-03-20
    

Wichtig

Die Mehrzahl der Bereinigungsvorgänge wird wahrscheinlich deutlich schneller ausgeführt als in unserer SLA angegeben. Aufgrund der starken Auswirkungen auf die von Log Analytics verwendete Datenplattform wurde die formelle SLA für die Ausführung von Bereinigungsvorgängen aber auf 30 Tage festgelegt.

Anwendungsdaten

  • POST purge: Verwendet ein Objekt, das Parameter der zu löschenden Daten angibt, und gibt eine Verweis-GUID zurück.

  • GET purge status: Der Aufruf von „POST purge“ gibt einen Header vom Typ „x-ms-status-location“ zurück, der eine URL enthält, die Sie zum Ermitteln des Status Ihrer Bereinigungs-API aufrufen können. Beispiel:

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-05-01
    

Wichtig

Obwohl die Mehrzahl der Bereinigungsvorgänge wesentlich schneller als die SLA ausgeführt werden kann, ist aufgrund der starken Auswirkung auf die von Application Insights verwendete Datenplattform die formelle SLA für die Ausführung von Bereinigungsvorgängen auf 30 Tage festgelegt.

Nächste Schritte