Beispielarchitektur für die Verwendung eines DLP-Proxys zum Abfragen einer Datenbank mit sensiblen Daten

In diesem Dokument wird beschrieben, wie Sie mit Cloud Data Loss Prevention (Cloud DLP) das Risiko minimieren, dass in Google Cloud-Datenbanken gespeicherte sensible Daten Nutzern preisgegeben werden, diese Nutzer aber trotzdem noch aussagekräftige Daten abfragen können.

Sensible Daten können in Ihrem gesamten Unternehmen vorhanden sein. Daten, die erhoben, verarbeitet und weitergegeben werden, können Informationen wie personenbezogene Daten enthalten, die externen und internen Richtlinien oder Vorschriften unterliegen. Neben den angemessenen Sicherheitskontrollen zur Einschränkung des Zugriffs auf sensible Daten können Sie diese Verfahren auch verwenden, um die genutzten Daten zu schützen. Die De-Identifikation trägt mithilfe von Verfahren wie Datenmaskierung, Bucketing und Tokenisierung dazu bei, ein ausgewogenes Verhältnis zwischen Nutzbarkeit und Datenschutz zu finden.

Die Tokenisierung ersetzt sensible Daten durch Ersatzwerte, die als Tokens bezeichnet werden. Diese stellen den ursprünglichen sensiblen (Roh-) Wert dar, wenn die Daten abgefragt oder angezeigt werden. Dieser Vorgang wird manchmal als Pseudonymisierung oder Ersatz bezeichnet. Das Konzept der Tokenisierung ist z. B. in der Finanzbranche und im Gesundheitswesen weit verbreitet, um das Risiko der Verwendung von Daten zu reduzieren, den Compliance-Bereich zu verringern und Preisgabe sensibler Daten an Personen oder Systeme zu minimieren, die sie nicht benötigen.

Mit Cloud DLP können Sie sensible Daten in Batches und in Echtzeit klassifizieren und de-identifizieren. Bei der Klassifizierung werden vertrauliche Informationen identifiziert und es wird bestimmt, um welchen Typ es sich handelt. In diesem Dokument wird erläutert, wo Sie diese Verfahren zur De-Identifikation anwenden können und wie Sie einen Proxy für diese Aufgaben verwenden.

Das folgende Diagramm veranschaulicht das in diesem Dokument beschriebene Szenario.

Architektur der in Cloud Storage gespeicherten Daten, die über ETL aufgenommen und dann von Nutzern abgefragt werden.

In diesem Szenario sind die von der Abfrage zurückgegebenen Ergebnisse Rohdaten, sodass sensible Daten angezeigt werden und möglicherweise personenbezogene Daten für den Nutzer verfügbar sind, der die Abfrage ausführt. Sie sollten Ihre Anwendung so entwickeln, dass nicht autorisierte Abfragen sensibler Daten geprüft und verhindert werden.

DLP-Proxyarchitektur

Eine Möglichkeit zum Schutz personenbezogener Daten besteht darin, alle Abfragen und Ergebnisse über einen Dienst weiterzugeben, der die Ergebnisse parst, prüft und diese dann entweder mithilfe von Cloud DLP analysiert oder de-identifiziert, bevor die angeforderten Daten an den Nutzer zurückgegeben werden. In diesem Dokument wird dieser Dienst als DLP-Proxy bezeichnet.

Die DLP-Proxyanwendung akzeptiert eine SQL-Abfrage als Eingabe, führt diese Abfrage in der Datenbank aus und wendet dann Cloud DLP auf die Ergebnisse an, bevor sie an den Nutzer zurückgegeben werden, der die Daten anfordert.

Das folgende Diagramm veranschaulicht die Architektur der DLP-Proxyanwendung.

Architektur der DLP-Proxyanwendung mit Befehlen zur Datentransformation.

Mit Cloud DLP können Sie detailliert die zu prüfenden Datentypen konfigurieren und wie diese Daten anhand dieser Prüfergebnisse oder der Datenstruktur (z. B. Feldnamen) transformiert werden. Zur Vereinfachung der Erstellung und Verwaltung der Konfiguration verwenden Sie Cloud DLP-Vorlagen. Die DLP-Proxyanwendung verweist auf Vorlagen zur Prüfung und zur De-Identifikation.

Mithilfe von Vorlagen können Sie Konfigurationsinformationen mit Cloud DLP erstellen und beibehalten. Vorlagen bieten sich an, wenn Sie Konfigurationsinformationen von der Implementierung Ihrer Anfragen entkoppeln möchten, zum Beispiel den Gegenstand der Prüfung und dessen De-Identifikation. Weitere Informationen zu Vorlagen finden Sie in den Cloud DLP-Vorlagen.

Cloud-Audit-Logs ist ein integrierter Logging-Dienst von Google Cloud, der in dieser Architektur verwendet wird. Als Erstes stellt Cloud-Audit-Logs einen Audit-Trail von Aufrufen der DLP API bereit. Die Audit-Logeinträge umfassen Informationen darüber, wer den API-Aufruf getätigt hat und für welches Cloudprojekt er ausgeführt wurde. Darüber hinaus sind Details zur Anfrage, einschließlich der Frage, ob eine Vorlage als Teil der Anfrage verwendet wurde, enthalten. Wenn Sie die Audit-Datei mithilfe der Konfigurationsdatei der Anwendung aktivieren, zeichnet Cloud-Audit-Logs als Nächstes eine Zusammenfassung der Prüfergebnisse auf.

Cloud Key Management Service (Cloud KMS) ist ein in der Cloud gehosteter Schlüsselverwaltungsdienst von Google Cloud, mit dem Sie kryptografische Schlüssel für Ihre Clouddienste verwalten können.

Cloud DLP-Methoden für die Tokenisierung und die Datumsverschiebung verwenden Kryptografie, um die Ersatzwerte zu generieren. Bei diesen kryptografischen Methoden werden die Werte mit einem Schlüssel auf konsistente Weise verschlüsselt, um die referenzielle Integrität zu wahren, bei umkehrbaren Methoden zur Aufhebung der Tokenisierung. Sie können diesen Schlüssel direkt an Cloud DLP senden, wenn der Aufruf erfolgt, oder ihn mit Cloud KMS zusammenfassen. Das Zusammenfassen Ihres Schlüssels in Cloud KMS bietet eine weitere Ebene der Zugriffssteuerung und -prüfung und ist daher die bevorzugte Methode für Produktionsbereitstellungen.

In einer Produktionskonfiguration sollten Sie beim Zuweisen von Berechtigungen das Prinzip der geringsten Berechtigung verwenden. Das folgende Diagramm veranschaulicht ein Beispiel für dieses Prinzip.

Produktionskonfiguration mit drei Personen und ihren Berechtigungen.

Das obige Diagramm zeigt drei Personen in einer typischen Produktionskonfiguration mit unterschiedlichen Rollen und unterschiedlichem Zugriff auf die Rohdaten:

  • Infrastrukturadministrator: Der Proxy wird installiert und konfiguriert, sodass er Zugriff auf die Rechenumgebung hat, auf der der Cloud DLP-Proxy installiert ist.
  • Datenanalyst: Hat Zugriff auf den Client, der eine Verbindung zum DLP-Proxy herstellt.

  • Sicherheitsadministrator: Klassifiziert die Daten, erstellt die Cloud DLP-Vorlagen und konfiguriert Cloud KMS.

Weitere Informationen zur Verschlüsselung und Entschlüsselung von Daten mit Cloud KMS finden Sie unter Daten verschlüsseln und entschlüsseln. Weitere Informationen zur Verwendung eines zusammengefassten Schlüssels finden Sie im deindentification.java-Codebeispiel.

Für den in diesem Dokument verwendeten DLP-Proxy werden diese Informationen alle in einer Cloud DLP-De-Identifikationsvorlage konfiguriert.

Schutz personenidentifizierbarer Informationen durch Prüfung, Maskierung und Tokenisierung

Es gibt zwei Strategien, die Sie implementieren können, um das Risiko der Preisgabe personenbezogener Daten in diesem Szenario zu verringern.

In der Datenbank gespeicherte Rohdaten

Wenn Ihre Anwendung Rohdaten in einer Datenbank speichert, können Sie den DLP-Proxy verwenden, um die an den Nutzer zurückgegebenen Ergebnisse zu verarbeiten und alle sensiblen Daten automatisch zu prüfen. Alternativ können Sie die Abfrageergebnisse in Echtzeit maskieren, wie im folgenden Diagramm dargestellt.

Architektur, bei der Abfrageergebnisse in Echtzeit maskiert werden

Diese Konfiguration erfordert, dass Sie einen SQL-Client verwenden, der eine Verbindung zum DLP-Proxy herstellt. Wenn Sie die Überwachung für Ihre Anwendung aktivieren, wird in Cloud-Audit-Logs ein Log mit einer Zusammenfassung der Prüfergebnisse erstellt. Diese Zusammenfassung gibt an, welche Art von vertraulichen Informationen in der Abfrage zurückgegeben wurden.

In de-identifizierter Form gespeicherte Daten

Wenn Sie die Rohdaten nicht speichern möchten, können Sie die Daten für Ihre Anwendung in einer de-identifizierten oder maskierten Form speichern, indem Sie die De-Identifikationstransformationen während des ETL-Prozesses in der Datenbank ausführen, wie im folgenden Diagramm dargestellt.

Architektur, in der Abfrageergebnisse während des ETL-Prozesses maskiert werden

Das obige Diagramm veranschaulicht den grundlegenden Ablauf, bei dem Daten überprüft und maskiert werden, bevor sie in die Datenbank aufgenommen werden. Wenn ein Nutzer diese Daten abfragt, kann er nur die maskierte Version sehen, selbst wenn er Zugriff auf Rohdaten der Datenbank hat.

Wenn Sie zulassen, dass dem Nutzer nicht maskierte Daten angezeigt werden, müssen Sie einen Client verwenden, der eine Verbindung zu einer Instanz des DLP-Proxys herstellen kann, die über die Berechtigung zum Maskieren der Daten verfügt, wie im folgenden Diagramm dargestellt.

Architektur, bei der Sie einen Client verwenden, um eine Verbindung zum DLP-Proxy herzustellen und nicht maskierte Daten anzuzeigen.

Das obige Diagramm zeigt, wie Sie einen Client verwenden können, um eine Verbindung zum DLP-Proxy herzustellen, damit dem Client nicht maskierte Daten angezeigt werden können.

Weitere Informationen