Daten verschlüsseln und entschlüsseln

In diesem Leitfaden wird beschrieben, wie die Verschlüsselung und Entschlüsselung mit der clientseitigen Verschlüsselungs-API von Google Workspace funktioniert.

Sie müssen alle Identitätsanbieterdienste (Identity Provider, IdP) auf eine Zulassungsliste setzen, die von Nutzern verwendet werden, die verschlüsselte Dateien freigeben. Normalerweise finden Sie die erforderlichen IdP-Details in der öffentlich verfügbaren .well-known-Datei. Andernfalls wenden Sie sich an den Google Workspace-Administrator der Organisation, um die IdP-Details zu erhalten.

Daten verschlüsseln

Wenn ein Google Workspace-Nutzer anfordert, clientseitig verschlüsselte (client-side encryption, CSE) Daten zu speichern, sendet Google Workspace eine wrap-Anfrage zur Verschlüsselung an die KACLS-Endpunkt-URL (Key Access Control List Service) Ihres Unternehmens. Zusätzlich zu optionalen Sicherheitsprüfungen wie perimeter- und JWT-anspruchsbasierten Prüfungen muss Ihr KACLS die folgenden Schritte ausführen:

1. Den anfragenden Nutzer validieren.

   • Sowohl das Authentifizierungs token als auch das Autorisierungs token validieren.
   • Prüfen, ob die Autorisierungs- und Authentifizierungstoken für denselben Nutzer gelten, indem Sie die E‑Mail-Ansprüche ohne Berücksichtigung der Groß-/Kleinschreibung vergleichen.
   • Wenn das Authentifizierungstoken den optionalen Anspruch google_email enthält, muss es ohne Berücksichtigung der Groß-/Kleinschreibung mit dem E‑Mail-Anspruch im Autorisierungstoken verglichen werden. Verwenden Sie für diesen Vergleich nicht den E‑Mail-Anspruch im Authentifizierungstoken.
   • In Szenarien, in denen das Authentifizierungstoken den optionalen Anspruch google_email nicht enthält, sollte der E‑Mail-Anspruch im Authentifizierungstoken ohne Berücksichtigung der Groß-/Kleinschreibung mit dem E‑Mail-Anspruch im Autorisierungstoken verglichen werden.
   • In Szenarien, in denen Google ein Autorisierungstoken für eine E‑Mail-Adresse ausstellt, die nicht mit einem Google-Konto verknüpft ist, muss der Anspruch email_type vorhanden sein. Dies ist ein wichtiger Bestandteil der Funktion für den Gastzugriff und liefert wertvolle Informationen für KACLS, um zusätzliche Sicherheitsmaßnahmen für externe Nutzer zu erzwingen.
     • Einige Beispiele dafür, wie ein KACLS diese Informationen verwenden kann:
     • Zusätzliche Protokollierungsanforderungen auferlegen.
     • Den Aussteller des Authentifizierungstokens auf einen bestimmten Gast-IdP beschränken.
     • Zusätzliche Ansprüche für das Authentifizierungstoken festlegen.
     • Wenn ein Kunde den Gastzugriff nicht konfiguriert hat, können alle Anfragen abgelehnt werden, bei denen email_type auf google-visitor oder customer-idp festgelegt ist. Anfragen mit einem email_type von google oder mit einem nicht festgelegten email_type sollten weiterhin akzeptiert werden.
   • Wenn das Authentifizierungstoken den optionalen Anspruch delegated_to enthält, muss es auch den Anspruch resource_name enthalten. Diese beiden Ansprüche müssen mit den Ansprüchen delegated_to und resource_name im Autorisierungstoken verglichen werden. Die delegated_to-Ansprüche sollten ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden und der resource_name in den Token muss mit dem resource_name des Vorgangs übereinstimmen.
   • Prüfen, ob der Anspruch role im Autorisierungstoken writer oder upgrader ist.
   • Prüfen, ob die Anforderung kacls_url im Autorisierungstoken mit der aktuellen KACLS-URL übereinstimmt. Mit dieser Prüfung können potenzielle Man-in-the-Middle-Server erkannt werden, die von Insidern oder betrügerischen Domainadministratoren konfiguriert wurden.
   • Eine Perimeterprüfung mit Authentifizierungs- und Autorisierungsansprüchen durchführen.

2. Die folgenden Teile mit einem authentifizierten Verschlüsselungsalgorithmus verschlüsseln:

   • Datenverschlüsselungsschlüssel (Data Encryption Key, DEK)
   • Die Werte resource_name und perimeter_id aus dem Autorisierungstoken
   • Alle zusätzlichen sensiblen Daten

3. Den Vorgang protokollieren, einschließlich des Nutzers, der ihn initiiert hat, des resource_name und des in der Anfrage übergebenen Grunds.

4. Ein undurchsichtiges binäres Objekt zurückgeben, das von Google Workspace zusammen mit dem verschlüsselten Objekt gespeichert und bei allen nachfolgenden Vorgängen zum Entschlüsseln des Schlüssels unverändert gesendet werden soll. Oder eine strukturierte Fehler antwort senden.

   • Das binäre Objekt sollte die einzige Kopie des verschlüsselten DEK enthalten. Implementierungsspezifische Daten können darin gespeichert werden.

Hinweis: Speichern Sie den DEK nicht in Ihrem KACLS-System. Verschlüsseln Sie ihn stattdessen und geben Sie ihn im Objekt wrapped_key zurück, um Abweichungen während der Lebensdauer der Datei zu vermeiden. Google sendet keine Löschanfragen an den KACLS, wenn Objekte gelöscht werden.

Daten entschlüsseln

Wenn ein Google Workspace-Nutzer anfordert, clientseitig verschlüsselte (client-side encryption, CSE) Daten zu öffnen, sendet Google Workspace eine unwrap-Anfrage zur Entschlüsselung an die KACLS-Endpunkt-URL Ihres Unternehmens. Zusätzlich zu optionalen Sicherheitsprüfungen wie perimeter- und JWT-anspruchsbasierten Prüfungen muss Ihr KACLS die folgenden Schritte ausführen:

1. Den anfragenden Nutzer validieren.

   • Sowohl das Authentifizierungs token als auch das Autorisierungs token validieren.
   • Prüfen, ob die Autorisierungs- und Authentifizierungstoken für denselben Nutzer gelten, indem Sie die E‑Mail-Ansprüche ohne Berücksichtigung der Groß-/Kleinschreibung vergleichen.
   • Wenn das Authentifizierungstoken den optionalen Anspruch google_email enthält, muss es ohne Berücksichtigung der Groß-/Kleinschreibung mit dem E‑Mail-Anspruch im Autorisierungstoken verglichen werden. Verwenden Sie für diesen Vergleich nicht den E‑Mail-Anspruch im Authentifizierungstoken.
   • In Szenarien, in denen das Authentifizierungstoken den optionalen Anspruch google_email nicht enthält, sollte der E‑Mail-Anspruch im Authentifizierungstoken ohne Berücksichtigung der Groß-/Kleinschreibung mit dem E‑Mail-Anspruch im Autorisierungstoken verglichen werden.
   • In Szenarien, in denen Google ein Autorisierungstoken für eine E‑Mail-Adresse ausstellt, die nicht mit einem Google-Konto verknüpft ist, muss der Anspruch email_type vorhanden sein. Dies ist ein wichtiger Bestandteil der Funktion für den Gastzugriff und liefert wertvolle Informationen für KACLS, um zusätzliche Sicherheitsmaßnahmen für externe Nutzer zu erzwingen.
     • Einige Beispiele dafür, wie ein KACLS diese Informationen verwenden kann:
     • Zusätzliche Protokollierungsanforderungen auferlegen.
     • Den Aussteller des Authentifizierungstokens auf einen bestimmten Gast-IdP beschränken.
     • Zusätzliche Ansprüche für das Authentifizierungstoken festlegen.
     • Wenn ein Kunde den Gastzugriff nicht konfiguriert hat, können alle Anfragen abgelehnt werden, bei denen email_type auf google-visitor oder customer-idp festgelegt ist. Anfragen mit einem email_type von google oder mit einem nicht festgelegten email_type sollten weiterhin akzeptiert werden.
   • Wenn das Authentifizierungstoken den optionalen Anspruch delegated_to enthält, muss es auch den Anspruch resource_name enthalten. Diese beiden Ansprüche müssen mit den Ansprüchen delegated_to und resource_name im Autorisierungstoken verglichen werden. Die delegated_to-Ansprüche sollten ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden und der resource_name in den Token muss mit dem resource_name des Vorgangs übereinstimmen.
   • Prüfen, ob der Anspruch role im Autorisierungstoken reader oder writer ist.
   • Prüfen, ob die Anforderung kacls_url im Autorisierungstoken mit der aktuellen KACLS-URL übereinstimmt. Mit dieser Prüfung können potenzielle Man-in-the-Middle-Server erkannt werden, die von Insidern oder betrügerischen Domainadministratoren konfiguriert wurden.

2. Die folgenden Teile mit einem authentifizierten Verschlüsselungsalgorithmus entschlüsseln:

   • Datenverschlüsselungsschlüssel (Data Encryption Key, DEK)
   • Die Werte resource_name und perimeter_id aus dem Autorisierungstoken
   • Alle zusätzlichen sensiblen Daten

3. Prüfen, ob der resource_name im Autorisierungstoken und im entschlüsselten Blob übereinstimmen.

4. Eine Perimeterprüfung mit Authentifizierungs- und Autorisierungsansprüchen durchführen.

5. Den Vorgang protokollieren, einschließlich des Nutzers, der ihn initiiert hat, des resource_name und des in der Anfrage übergebenen Grunds.

6. Den entschlüsselten DEK oder eine strukturierte Fehler antwort zurückgeben.

Hinweis: Informationen zum Entschlüsseln von Google Datenexport -Anfragen finden Sie unter privilegedunwrap.