In diesem Dokument wird beschrieben, wie Sie mit dem Schutz sensibler Daten 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 dem Schutz sensibler Daten 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.
- Inaktive Daten werden in Cloud Storage gespeichert. Zum Beispiel Daten, die von einem Partner empfangen werden.
- Daten werden über einen ETL-Prozess (Extrahieren, Transformieren und Laden) in eine SQL-Datenbank aufgenommen.
- Daten in dieser Datenbank werden von Nutzern zur Analyse abgefragt.
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 des Schutzes sensibler Daten 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 den Schutz sensibler Daten 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.
Mit dem Schutz sensibler Daten 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 Vorlagen für den Schutz sensibler Daten. Die DLP-Proxyanwendung verweist auf Vorlagen zur Prüfung und zur De-Identifikation.
Mithilfe von Vorlagen können Sie Konfigurationsinformationen mit dem Schutz sensibler Daten 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 Vorlagen für den Schutz sensibler Daten.
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 Cloud Data Loss Prevention API bereit, die Teil des Schutzes sensibler Daten sind. Die Audit-Logeinträge umfassen Informationen darüber, wer den API-Aufruf getätigt hat und für welches Google 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.
Methoden zum Schutz sensibler Daten 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 den Schutz sensibler Daten 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.
Das obige Diagramm zeigt drei Personen in einer typischen Produktionskonfiguration mit unterschiedlichen Rollen und unterschiedlichem Zugriff auf die Rohdaten:
- Infrastrukturadministrator: Installiert und konfiguriert den Proxy, sodass Zugriff auf die Rechenumgebung besteht, auf der der Proxy für den Schutz sensibler Daten installiert ist.
Datenanalyst: Hat Zugriff auf den Client, der eine Verbindung zum DLP-Proxy herstellt.
Sicherheitsadministrator: Klassifiziert die Daten, erstellt die Vorlagen für den Schutz sensibler Daten 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.
Für den in diesem Dokument verwendeten DLP-Proxy werden diese Informationen alle in einer De-Identifikationsvorlage für den Schutz sensibler Daten 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.
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.
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.
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.
Nächste Schritte
- Daten durch Tokenisierung nutzbar machen, ohne den Datenschutz zu beeinträchtigen
Sehen Sie sich die folgende technische Dokumentation zum Schutz sensibler Daten an:
Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center