In diesem Leitfaden wird beschrieben, wie die Verschlüsselung und Entschlüsselung mithilfe der Client-side Encryption API von Google Workspace funktioniert.
Sie müssen alle von Nutzern verwendeten IdP-Dienste (Identity Provider, Identitätsanbieter) auf die Zulassungsliste setzen die Freigabe verschlüsselter Dateien. Die erforderlichen IdP-Details finden Sie normalerweise in öffentlich verfügbare .well-known-Datei; wenden Sie sich andernfalls an die Google Workspace-Administrator nach den IdP-Details.
Daten verschlüsseln
Wenn ein Google Workspace-Nutzer anfordert, clientseitig verschlüsselte Daten zu speichern oder zu speichern
(CSE)-Daten sendet Google Workspace eine wrap
-Anfrage an die URL des KACLS-Endpunkts zur Verschlüsselung. Neben den optionalen
wie Perimeter- und JWT-Anforderungsprüfungen, müssen Ihre KACLS
führen Sie die folgenden Schritte aus:
Prüfen Sie den anfragenden Nutzer.
- Validieren Sie sowohl das Authentifizierungstoken und das Autorisierungstoken.
- Prüfen Sie, ob die Autorisierungs- und Authentifizierungstokens für denselben Nutzer sind, indem Sie bei den E-Mail-Ansprüchen die Groß-/Kleinschreibung nicht berücksichtigen.
- Wenn das Authentifizierungstoken die optionale
google_email
-Anforderung enthält, Er muss mit der E-Mail-Anforderung im Autorisierungstoken verglichen werden. Dabei wird die Groß-/Kleinschreibung nicht berücksichtigt. Nutzen Sie nicht den E-Mail-Anspruch innerhalb der Authentifizierungstoken für diesen Vergleich. - Wenn im Authentifizierungstoken das optionale
google_email
-Anforderung, die E-Mail-Anforderung innerhalb des Authentifizierungstokens mit der E-Mail-Anforderung im Autorisierungstoken verglichen werden soll. wenn die Groß-/Kleinschreibung nicht berücksichtigt wird. - In Fällen, in denen Google ein Autorisierungstoken für eine E-Mail ausgibt,
die mit einem Google-Konto verknüpft sind, muss die
email_type
-Anforderung vorhanden sein. Dies ist ein entscheidender Teil der Gastzugriffsfunktion, Informationen für KACLS, um zusätzliche Sicherheitsmaßnahmen auf externen Nutzenden.- Beispiele für die Verwendung dieser Informationen durch ein KACLS:
- Um zusätzliche Logging-Anforderungen zu setzen.
- So beschränken Sie den Aussteller von Authentifizierungstokens auf einen dedizierten Gast-IdP.
- Um zusätzliche Anforderungen auf das Authentifizierungstoken anzufordern.
- Wenn ein Kunde den Gastzugriff nicht konfiguriert hat,
Dabei ist
email_type
aufgoogle-visitor
gesetzt odercustomer-idp
kann abgelehnt. Anfragen mit dememail_type
-Wertgoogle
oder mit einem nicht festgelegten Wertemail_type
sollte weiterhin akzeptiert werden.
- Prüfen Sie, ob die
role
-Anforderung im Autorisierungstoken „writer“ ist. oder „upgrader“. - Prüfen Sie, ob die
kacls_url
-Anforderung im Autorisierungstoken mit der aktuelle KACLS-URL Mit dieser Prüfung können potenzielle Man-in-the-Middle-Server, die von Insidern oder einer betrügerischen Domain konfiguriert wurden Administratoren. - Perimeterprüfung mit Authentifizierung und Autorisierung durchführen Ansprüche
Verschlüsseln Sie die folgenden Teile mit einem authentifizierten Verschlüsselungsalgorithmus:
- Datenverschlüsselungsschlüssel (Data Encryption Key, DEK)
- Die Werte
resource_name
undperimeter_id
aus dem Autorisierungstoken - Zusätzliche sensible Daten
Der Vorgang wird protokolliert, einschließlich des Nutzers, von dem er stammt,
resource_name
und den in der Anfrage übergebenen Grund.Geben Sie ein intransparentes Binärobjekt zurück, das zusammen mit Google Workspace gespeichert werden soll das verschlüsselte Objekt und wird bei jedem nachfolgenden Entpacken des Schlüssels unverändert gesendet . Oder geben Sie eine strukturierte Fehlerantwort aus.
- Das Binärobjekt sollte die einzige Kopie des verschlüsselten DEK enthalten, implementierungsspezifische Daten gespeichert werden können.
Daten entschlüsseln
Wenn ein Google Workspace-Nutzer anfordert, clientseitig verschlüsselte Daten (CSE) zu öffnen,
Google Workspace sendet eine unwrap
-Anfrage
an die URL Ihres KACLS-Endpunkts senden. Zusätzlich zu den optionalen Sicherheitseinstellungen
wie Perimeter- und JWT-Anforderungsprüfungen, die Ihr KACLS ausführen muss
führen Sie die folgenden Schritte aus:
Prüfen Sie den anfragenden Nutzer.
- Validieren Sie sowohl das Authentifizierungstoken und das Autorisierungstoken.
- Prüfen Sie, ob die Autorisierungs- und Authentifizierungstokens für denselben Nutzer sind, indem Sie bei den E-Mail-Ansprüchen die Groß-/Kleinschreibung nicht berücksichtigen.
- Wenn das Authentifizierungstoken die optionale
google_email
-Anforderung enthält, Er muss mit der E-Mail-Anforderung im Autorisierungstoken verglichen werden. Dabei wird die Groß-/Kleinschreibung nicht berücksichtigt. Nutzen Sie nicht den E-Mail-Anspruch innerhalb der Authentifizierungstoken für diesen Vergleich. - Wenn im Authentifizierungstoken das optionale
google_email
-Anforderung, die E-Mail-Anforderung innerhalb des Authentifizierungstokens mit der E-Mail-Anforderung im Autorisierungstoken verglichen werden soll. wenn die Groß-/Kleinschreibung nicht berücksichtigt wird. - In Fällen, in denen Google ein Autorisierungstoken für eine E-Mail ausgibt,
die mit einem Google-Konto verknüpft sind, muss die
email_type
-Anforderung vorhanden sein. Dies ist ein entscheidender Teil der Gastzugriffsfunktion, Informationen für KACLS, um zusätzliche Sicherheitsmaßnahmen auf externen Nutzenden.- Beispiele für die Verwendung dieser Informationen durch ein KACLS:
- Um zusätzliche Logging-Anforderungen zu setzen.
- So beschränken Sie den Aussteller von Authentifizierungstokens auf einen dedizierten Gast-IdP.
- Um zusätzliche Anforderungen auf das Authentifizierungstoken anzufordern.
- Wenn ein Kunde den Gastzugriff nicht konfiguriert hat,
Dabei ist
email_type
aufgoogle-visitor
gesetzt odercustomer-idp
kann abgelehnt. Anfragen mit dememail_type
-Wertgoogle
oder mit einem nicht festgelegten Wertemail_type
sollte weiterhin akzeptiert werden.
- Prüfen Sie, ob die
role
-Anforderung im Autorisierungstoken „reader“ lautet. oder „writer“. - Prüfen Sie, ob die
kacls_url
-Anforderung im Autorisierungstoken mit der aktuelle KACLS-URL So lassen sich potenzielle Man-in-the-Middle-Anzeigen erkennen. Server, die von Insidern oder Administratoren von betrügerischen Domains konfiguriert wurden.
Entschlüsseln Sie die folgenden Teile mit einem authentifizierten Verschlüsselungsalgorithmus:
- Datenverschlüsselungsschlüssel (Data Encryption Key, DEK)
- Die Werte
resource_name
undperimeter_id
aus dem Autorisierungstoken - Zusätzliche sensible Daten
Prüfen Sie, ob die
resource_name
im Autorisierungstoken und im entschlüsselten Blob Übereinstimmung.Führen Sie eine Perimeterprüfung mit Authentifizierungs- und Autorisierungsansprüchen durch.
Der Vorgang wird protokolliert, einschließlich des Nutzers, von dem er stammt,
resource_name
und den in der Anfrage übergebenen Grund.Geben Sie den entpackten DEK oder eine strukturierte Fehlerantwort zurück.