Teilen über

Verwalten personenbezogener Daten in Azure Monitor Log und Application Insights

  • Artikel

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 wird erläutert, wo Log Analytics und Application Insights personenbezogene Daten speichern, und wie diese Daten verwaltet werden.

In diesem Artikel 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. Wenn Sie eine klassische Application Insights-Ressource verwenden, gelten die Informationen zu Anwendungsdaten.

Hinweis

Informationen zum Anzeigen oder Löschen personenbezogener Daten finden Sie in den Allgemeinen Anträgen betroffener Personen zu der DSGVO, Azure-Anträge betroffener Personen zu der DSGVO oder Windows-Anträge betroffener Personen zu der DSGVO, je nach Ihrem jeweiligen Bereich und Ihren Anforderungen. Weitere Informationen zur DSGVO finden Sie im Abschnitt zur DSGVO im Microsoft Trust Center und im Abschnitt zur DSGVO im Service Trust Portal.

Erforderliche Berechtigungen

Aktion Erforderliche Berechtigungen
Löschen von Daten aus einem Log Analytics-Arbeitsbereich Microsoft.OperationalInsights/workspaces/purge/action-Berechtigungen für den Log Analytics-Arbeitsbereich, wie sie beispielsweise von der integrierten Rolle „Log Analytics-Mitwirkender“ bereitgestellt werden

Strategie für den Umgang mit personenbezogenen Daten

Es liegt zwar an Ihnen und Ihrem Unternehmen, eine Strategie für den Umgang mit personenbezogenen Daten festzulegen, aber hier sind einige Ansätze aufgelistet, beginnend mit den aus technischer Sicht am besten bis zu den am wenigsten geeigneten:

  • Beenden Sie das Sammeln personenbezogener Daten, oder verschleiern oder anonymisieren Sie gesammelte Daten, oder passen Sie sie an, damit sie nicht als „personenbezogen“ gelten. Dies ist mit Abstand die bevorzugte Vorgehensweise und erspart Ihnen das Erstellen einer kostspieligen Datenverarbeitungsstrategie mit massiven Auswirkungen.
  • Normalisieren Sie die Daten, um negative Auswirkungen auf die Datenplattform und die Leistung zu reduzieren. Statt beispielsweise eine explizite Benutzer-ID zu protokollieren, erstellen Sie eine Suche, um den Benutzernamen und dessen Details mit einer internen ID zu korrelieren, die dann an anderer Stelle protokolliert werden kann. Wenn ein Benutzer Sie bittet, seine persönlichen Daten zu löschen, löschen Sie so nur die Zeile in der Nachschlagetabelle, die dem Benutzer entspricht.
  • Wenn Sie personenbezogene Daten sammeln müssen, erstellen Sie einen Prozess mithilfe des Lösch-API-Pfads und der vorhandenen Abfrage-API, um alle Verpflichtungen zum Exportieren und Löschen personenbezogener Daten zu erfüllen, die einem Benutzer zugeordnet sind.

Wo sich personenbezogene Daten in Log Analytics befinden

Log Analytics gibt zwar ein Schema für die Daten vor, lässt jedoch für jedes Feld das Überschreiben mit benutzerdefinierten Werten zu. Sie können auch benutzerdefinierte Schemas aufnehmen. Daher ist es unmöglich zu sagen, wo genau personenbezogene Daten in Ihrem jeweiligen Arbeitsbereich vorhanden sind. Die folgenden Speicherorte sind jedoch gute Ausgangspunkte für die Suche in Ihrem Datenbestand.

Hinweis

Einige der nachstehenden Abfragen verwenden search *, um alle Tabellen in einem Arbeitsbereich abzufragen. Die Verwendung von search *, was eine sehr ineffiziente Abfrage erzeugt, sollten Sie nach Möglichkeit vermeiden. Fragen Sie stattdessen eine bestimmte Tabelle ab.

Protokolldaten

  • IP-Adressen: Log Analytics sammelt verschiedene IP-Informationen in mehreren 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: Sie finden Benutzernamen und Benutzer-IDs in verschiedenen Lösungen und Tabellen. Mit dem Suchbefehl können Sie Ihr gesamtes Dataset nach einem bestimmten Benutzernamen oder einer Benutzer-ID durchsuchen:

    search "<username or user ID>"

    Wichtig: Suchen Sie nicht nur nach lesbaren Benutzernamen, sondern auch nach GUIDs, die zu einem bestimmten Benutzer zurückverfolgt werden können.

  • Geräte-IDs: Geräte-IDs sind mit Benutzer-IDs vergleichbar und werden gelegentlich als personenbezogene Daten betrachtet. Verwenden Sie den oben aufgeführten Ansatz für Benutzer-IDs, um Tabellen zu identifizieren, die personenbezogene Daten enthalten.

  • Benutzerdefinierte Daten: Log Analytics ermöglicht Ihnen, benutzerdefinierte Daten über benutzerdefinierte Protokolle, benutzerdefinierte Felder, die HTTP-Datensammler-API und als Teil von Systemereignisprotokollen zu sammeln. Überprüfen Sie alle benutzerdefinierten Daten auf personenbezogene Daten.

  • 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 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 Sitzungsverfolgung in Feldern wie session_Id, user_Id, user_AuthenticatedId, user_AccountId und customDimensions. Es ist jedoch üblich, diese Felder mit einer ID zu überschreiben, die für die Anwendung relevanter ist, z. B. Benutzernamen oder Microsoft Entra-GUIDs. Diese IDs werden oft als personenbezogene Daten betrachtet. Wir empfehlen, diese IDs zu verschleiern oder zu anonymisieren.

  • Benutzerdefinierte Daten: Application Insights ermöglicht es Ihnen, eine Gruppe benutzerdefinierter Dimensionen an einen beliebigen Datentyp anzufügen. Ermitteln Sie mithilfe der folgenden Abfrage benutzerdefinierte 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. Sie finden häufig personenbezogene Daten auf Code- und HTTP-Aufrufebene. Überprüfen Sie die Tabellen auf 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 Application Insights eine Ausnahme in der Produktionsinstanz Ihrer Anwendung erkennt. 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, sollten Sie das Feature deaktivieren.

Exportieren und Löschen personenbezogener Daten

Sie sollten Ihre Datenerfassungsrichtlinie unbedingt so umgestalten, dass keine personenbezogenen Daten mehr erfasst werden, dass personenbezogene Daten verschleiert oder anonymisiert oder diese Daten auf andere Weise so verändert werden, dass sie nicht mehr als personenbezogen gelten. Beim Umgang mit personenbezogenen Daten entstehen Kosten beim Definieren und Automatisieren einer Strategie, dem Erstellen einer Schnittstelle, durch die Ihre Kunden mit ihren Daten interagieren, und durch fortlaufende Wartung. Dies bedeutet auch einen hohen Rechenaufwand für Log Analytics und Application Insights, und eine hohe Anzahl gleichzeitiger Abfrage- oder Lösch-API-Aufrufe kann sich negativ auf alle anderen Interaktionen mit Log Analytics-Funktionen auswirken. Wenn Sie jedoch personenbezogene Daten sammeln müssen, befolgen Sie die Richtlinien in diesem Abschnitt.

Wichtig

Obwohl die meisten Löschvorgänge wesentlich schneller ausgeführt werden, ist aufgrund der starken Auswirkung auf die verwendete Datenplattform die formelle SLA für die Ausführung von Löschvorgängen auf 30 Tage festgelegt. Diese SLA erfüllt die DSGVO-Anforderungen. Es ist ein automatisierter Prozess, sodass es keine Möglichkeit gibt, den Vorgang zu beschleunigen.

Anzeigen und Exportieren

Verwenden Sie die Log Analytics-Abfrage-API oder die Application Insights-Abfrage-API zum Anzeigen und Exportieren von Datenanforderungen.

Hinweis

Sie können die Log Analytics-Abfrage-API nicht für die Basis- und Zusatztabellenpläne verwenden. Verwenden Sie stattdessen die API für Log Analytics/Suche.

Sie müssen die Logik zum Konvertieren der Daten in ein geeignetes Format für die Übermittlung an Ihre Benutzer implementieren. Azure Functions eignet sich hervorragend zum Hosten einer solchen Logik.

Löschen

Warnung

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

Mit der Purge API von Azure Monitor können Sie personenbezogene Daten löschen. Verwenden Sie den Löschvorgang sparsam, um potenzielle Risiken, Leistungseinbußen und die Gefahr einer Verzerrung von Aggregationen, Messungen und anderen Aspekte Ihrer Log Analytics-Daten zu vermeiden. Alternative Methoden für den Umgang mit personenbezogenen Daten finden Sie im Abschnitt Strategie für den Umgang mit personenbezogenen Daten.

Löschen ist ein Vorgang mit hohen Berechtigungen. Gewähren Sie die Rolle Datenlöscher in Azure Resource Manager mit Vorsicht, da es zu Datenverlusten kommen kann.

Um Systemressourcen zu verwalten, beschränken wir Löschanforderungen auf 50 pro Stunde. Binden Sie die Ausführung von Löschanforderungen in Batches ein, indem Sie einen einzelnen Befehl senden, dessen Prädikat alle Benutzeridentitäten enthält, die gelöscht werden müssen. Verwenden Sie den in-Operator, um mehrere Identitäten anzugeben. Führen Sie die Abfrage aus, bevor Sie die Löschanforderung ausführen, um zu überprüfen, ob die erwarteten Ergebnisse erzielt werden.

Wichtig

Die Verwendung der Log Analytics- oder Application Insights Purge-API wirkt sich nicht auf Ihre Aufbewahrungskosten aus. Um die Aufbewahrungskosten zu senken, müssen Sie den Aufbewahrungszeitraum für Ihre Daten verringern.

Protokolldaten

  • Die Arbeitsbereichslöschungs-POST-API verwendet ein Objekt, das Parameter der zu löschenden Daten angibt, und gibt eine Verweis-GUID zurück.

  • Die „Löschstatus abrufen“-POST-API gibt einen „x-ms-status-location“-Header zurück, der eine URL enthält, die Sie aufrufen können, um den Status Ihres Löschvorgangs zu ermitteln. Zum 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

Hinweis

Sie können keine Daten aus Tabellen löschen, die über die Basis- und Zusatztabellenpläne verfügen.

Anwendungsdaten

  • Die „Komponenten – Löschen“-POST-API verwendet ein Objekt, das Parameter der zu löschenden Daten angibt, und gibt eine Verweis-GUID zurück.

  • Die „Komponenten – Löschstatus abrufen“-GET-API gibt einen „x-ms-status-location“-Header zurück, der eine URL enthält, die Sie aufrufen können, um den Status Ihres Löschvorgangs zu ermitteln. 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

Nächste Schritte