Daten verschlüsseln und entschlüsseln

In diesem Leitfaden wird beschrieben, wie die Verschlüsselung und Entschlüsselung mit der Google Workspace Client-side Encryption API funktioniert.

Sie müssen alle Identitätsanbieterdienste (Identity Provider, IdP) auf die Zulassungsliste setzen, die von Nutzern verwendet werden, die verschlüsselte Dateien freigeben. Normalerweise finden Sie die erforderlichen IdP-Details in der öffentlichen .well-known-Datei. Andernfalls können Sie den Google Workspace-Administrator der Organisation um die Informationen zum IdP bitten.

Daten verschlüsseln

Wenn ein Google Workspace-Nutzer anfordert, clientseitig verschlüsselte (CSE) Daten zu speichern oder zu sichern, sendet Google Workspace eine wrap-Anfrage zur Verschlüsselung an die KACLS-Endpunkt-URL (Key Access Control List Service). Zusätzlich zu optionalen Sicherheitsprüfungen wie Perimeter- und JWT-Anspruchsprüfungen müssen Ihre KACLS die folgenden Schritte ausführen:

  1. Validieren Sie den anfragenden Nutzer.

    • Validieren Sie sowohl das Authentifizierungstoken als auch das Autorisierungstoken.
    • Prüfen Sie, ob Autorisierungs- und Authentifizierungstokens 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 mit dem Anspruch „email“ im Autorisierungstoken verglichen werden. Dabei muss die Groß-/Kleinschreibung ignoriert werden. Verwenden Sie für diesen Vergleich nicht den E-Mail-Claim im Authentifizierungstoken.
    • In Szenarien, in denen das Authentifizierungstoken den optionalen google_email-Anspruch nicht enthält, sollte der E-Mail-Anspruch im Authentifizierungstoken mit dem E-Mail-Anspruch im Autorisierungstoken verglichen werden. Dabei sollte eine Methode verwendet werden, bei der die Groß-/Kleinschreibung keine Rolle spielt.
    • Wenn 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 Gastzugriffsfunktion und liefert wertvolle Informationen für KACLS, um zusätzliche Sicherheitsmaßnahmen für externe Nutzer zu erzwingen.
      • Hier einige Beispiele dafür, wie ein KACLS diese Informationen verwenden kann:
      • Zusätzliche Anforderungen an das Logging festzulegen.
      • So beschränken Sie den Aussteller von Authentifizierungstokens auf einen bestimmten Gast-IdP:
      • Zusätzliche Ansprüche für das Authentifizierungstoken sind erforderlich.
      • Wenn ein Kunde keinen Gastzugriff konfiguriert hat, können alle Anfragen abgelehnt werden, bei denen email_type auf google-visitor oder customer-idp gesetzt ist. Anfragen mit einem email_type von google oder einem nicht festgelegten email_type sollten weiterhin akzeptiert werden.
    • Wenn das Authentifizierungstoken die optionale Anforderung delegated_to enthält, muss es auch die Anforderung resource_name enthalten. Diese beiden Anforderungen müssen mit den Anforderungen delegated_to und resource_name im Autorisierungstoken verglichen werden. Die delegated_to-Ansprüche sollten mit einem nicht berücksichtigenden Ansatz verglichen werden und die resource_name in den Tokens sollte mit der resource_name des Vorgangs übereinstimmen.
    • Prüfen Sie, ob der Anspruch role im Autorisierungstoken writer oder upgrader ist.
    • Prüfen Sie, 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.
    • Führen Sie eine Perimeterprüfung mit Authentifizierungs- und Autorisierungsansprüchen durch.

  2. Verschlüsseln Sie die folgenden Teile mit einem Algorithmus für authentifizierte Verschlüsselung:

    • Datenverschlüsselungsschlüssel (Data Encryption Key, DEK)
    • Die Werte resource_name und perimeter_id aus dem Autorisierungstoken
    • Weitere vertrauliche Daten

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

  4. Gibt ein undurchsichtiges binäres Objekt zurück, das von Google Workspace zusammen mit dem verschlüsselten Objekt gespeichert und bei jedem nachfolgenden Entschlüsselungsvorgang unverändert gesendet wird. Oder Sie senden eine strukturierte Fehlerantwort.

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

Daten entschlüsseln

Wenn ein Google Workspace-Nutzer anfordert, clientseitig verschlüsselte Daten zu öffnen, sendet Google Workspace eine unwrap-Anfrage zur Entschlüsselung an die KACLS-Endpunkt-URL. Zusätzlich zu optionalen Sicherheitsprüfungen wie Perimeter- und JWT-Anforderungsprüfungen muss Ihr KACLS die folgenden Schritte ausführen:

  1. Validieren Sie den anfragenden Nutzer.

    • Validieren Sie sowohl das Authentifizierungstoken als auch das Autorisierungstoken.
    • Prüfen Sie, ob Autorisierungs- und Authentifizierungstokens 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 mit dem Anspruch „email“ im Autorisierungstoken verglichen werden. Dabei muss die Groß-/Kleinschreibung ignoriert werden. Verwenden Sie für diesen Vergleich nicht den E-Mail-Claim im Authentifizierungstoken.
    • In Szenarien, in denen das Authentifizierungstoken den optionalen google_email-Anspruch nicht enthält, sollte der E-Mail-Anspruch im Authentifizierungstoken mit dem E-Mail-Anspruch im Autorisierungstoken verglichen werden. Dabei sollte eine Methode verwendet werden, bei der die Groß-/Kleinschreibung keine Rolle spielt.
    • Wenn 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 Gastzugriffsfunktion und liefert wertvolle Informationen für KACLS, um zusätzliche Sicherheitsmaßnahmen für externe Nutzer zu erzwingen.
      • Hier einige Beispiele dafür, wie ein KACLS diese Informationen verwenden kann:
      • Zusätzliche Anforderungen an das Logging festzulegen.
      • So beschränken Sie den Aussteller von Authentifizierungstokens auf einen bestimmten Gast-IdP:
      • Zusätzliche Ansprüche für das Authentifizierungstoken sind erforderlich.
      • Wenn ein Kunde keinen Gastzugriff konfiguriert hat, können alle Anfragen abgelehnt werden, bei denen email_type auf google-visitor oder customer-idp gesetzt ist. Anfragen mit einem email_type von google oder einem nicht festgelegten email_type sollten weiterhin akzeptiert werden.
    • Wenn das Authentifizierungstoken die optionale Anforderung delegated_to enthält, muss es auch die Anforderung resource_name enthalten. Diese beiden Anforderungen müssen mit den Anforderungen delegated_to und resource_name im Autorisierungstoken verglichen werden. Die delegated_to-Ansprüche sollten mit einem nicht berücksichtigenden Ansatz verglichen werden und die resource_name in den Tokens sollte mit der resource_name des Vorgangs übereinstimmen.
    • Prüfen Sie, ob der Anspruch role im Autorisierungstoken reader oder writer ist.
    • Prüfen Sie, ob die Anforderung kacls_url im Autorisierungstoken mit der aktuellen KACLS-URL übereinstimmt. So können potenzielle Man-in-the-Middle-Server erkannt werden, die von Insidern oder betrügerischen Domainadministratoren konfiguriert wurden.

  2. Entschlüsseln Sie die folgenden Teile mit einem Algorithmus für authentifizierte Verschlüsselung:

    • Datenverschlüsselungsschlüssel (Data Encryption Key, DEK)
    • Die Werte resource_name und perimeter_id aus dem Autorisierungstoken
    • Weitere vertrauliche Daten

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

  4. Führen Sie eine Perimeterprüfung mit Authentifizierungs- und Autorisierungsansprüchen durch.

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

  6. Geben Sie das entpackte DEK oder eine strukturierte Fehlerantwort zurück.