Cripta e decripta i dati

Questa guida descrive il funzionamento della crittografia e della decrittografia utilizzando l'API Client-Side Encryption di Google Workspace.

Devi inserire nella lista consentita tutti i servizi provider di identità (IdP) utilizzati dagli utenti la condivisione di file criptati. In genere, puoi trovare i dettagli dell'IdP richiesti un file .well-known disponibile al pubblico; in caso contrario, contatta il Amministratore di Google Workspace per i dettagli dell'IdP.

Cripta i dati

Quando un utente di Google Workspace richiede di salvare o archiviare con crittografia lato client dei dati di servizio (CSE), Google Workspace invia un wrap richiesta all'URL dell'endpoint KACLS per la crittografia. Oltre alla sezione facoltativa come i controlli perimetrali e basati su attestazioni JWT, i controlli KACLS devono segui questi passaggi:

  1. Convalida l'utente che ha inviato la richiesta.

    • Convalida entrambi i token di autenticazione e il token di autorizzazione.
    • Verifica che i token di autorizzazione e autenticazione siano per lo stesso utente una corrispondenza senza distinzione tra maiuscole e minuscole nelle rivendicazioni email.
    • Se il token di autenticazione contiene la dichiarazione facoltativa google_email, deve essere confrontato con la richiesta email nel token di autorizzazione senza distinzione tra maiuscole e minuscole. Non utilizzare il reclamo via email nei il token di autenticazione per questo confronto.
    • Negli scenari in cui il token di autenticazione non ha l'opzione facoltativa Attestazione google_email, la rivendicazione email all'interno del token di autenticazione deve essere confrontato con la richiesta email nel token di autorizzazione, senza distinzione tra maiuscole e minuscole.
    • Nei casi in cui Google emette un token di autorizzazione per un'email non associata a un Account Google, deve essere presente la rivendicazione email_type. Si tratta di una parte fondamentale della funzionalità di accesso come ospite, in quanto fornisce informazioni per KACLS per applicare misure di sicurezza aggiuntive su utenti.
      • Ecco alcuni esempi di come un KACLS può utilizzare queste informazioni:
      • Imporre ulteriori requisiti di logging.
      • Per limitare l'emittente del token di autenticazione a un IdP ospite dedicato.
      • Per richiedere ulteriori attestazioni sul token di autenticazione.
      • Se un cliente non ha configurato l'accesso come ospite, tutte le richieste dove email_type è impostato su google-visitor o customer-idp può essere rifiutato. Richieste con email_type di google o con un valore non impostato email_type dovrebbe continuare a essere accettato.
    • Verifica che la dichiarazione role nel token di autorizzazione sia "writer" o "upgrader".
    • Verifica che l'attestazione kacls_url nel token di autorizzazione corrisponda a URL KACLS corrente. Questo controllo consente di rilevare potenziali Server man in the middle configurati da addetti ai lavori o da domini non autorizzati Google Workspace for Education.
    • Esegui un controllo del perimetro sia utilizzando autenticazione che autorizzazione rivendicazioni.

  2. Cripta le seguenti parti utilizzando un algoritmo di crittografia autenticato:

    • Chiave di crittografia dei dati (DEK, Data Encryption Key)
    • I valori resource_name e perimeter_id del token di autorizzazione
    • Altri dati sensibili

  3. Registra l'operazione, incluso l'utente che l'ha originata, resource_name e il motivo passato nella richiesta.

  4. Restituire un oggetto binario opaco che verrà archiviato da Google Workspace insieme l'oggetto criptato e inviato così com'è in qualsiasi successivo unwrapping della chiave operativa. In alternativa, invia una risposta di errore strutturato.

    • L'oggetto binario deve contenere l'unica copia della DEK criptata possono essere archiviati dati specifici dell'implementazione.
di Gemini Advanced.

Decripta i dati

Quando un utente di Google Workspace richiede di aprire dati con crittografia lato client, Google Workspace invia una richiesta unwrap all'URL dell'endpoint KACLS per la decrittografia. Oltre alla sicurezza facoltativa come i controlli perimetrali e basati su attestazioni JWT, i tuoi KACLS devono eseguire segui questi passaggi:

  1. Convalida l'utente che ha inviato la richiesta.

    • Convalida entrambi i token di autenticazione e il token di autorizzazione.
    • Verifica che i token di autorizzazione e autenticazione siano per lo stesso utente una corrispondenza senza distinzione tra maiuscole e minuscole nelle rivendicazioni email.
    • Se il token di autenticazione contiene la dichiarazione facoltativa google_email, deve essere confrontato con la richiesta email nel token di autorizzazione senza distinzione tra maiuscole e minuscole. Non utilizzare il reclamo via email nei il token di autenticazione per questo confronto.
    • Negli scenari in cui il token di autenticazione non ha l'opzione facoltativa Attestazione google_email, la rivendicazione email all'interno del token di autenticazione deve essere confrontato con la richiesta email nel token di autorizzazione, senza distinzione tra maiuscole e minuscole.
    • Nei casi in cui Google emette un token di autorizzazione per un'email non associata a un Account Google, deve essere presente la rivendicazione email_type. Si tratta di una parte fondamentale della funzionalità di accesso come ospite, in quanto fornisce informazioni per KACLS per applicare misure di sicurezza aggiuntive su utenti.
      • Ecco alcuni esempi di come un KACLS può utilizzare queste informazioni:
      • Imporre ulteriori requisiti di logging.
      • Per limitare l'emittente del token di autenticazione a un IdP ospite dedicato.
      • Per richiedere ulteriori attestazioni sul token di autenticazione.
      • Se un cliente non ha configurato l'accesso come ospite, tutte le richieste dove email_type è impostato su google-visitor o customer-idp può essere rifiutato. Richieste con email_type di google o con un valore non impostato email_type dovrebbe continuare a essere accettato.
    • Verifica che la dichiarazione role nel token di autorizzazione sia "lettore" o "writer".
    • Verifica che l'attestazione kacls_url nel token di autorizzazione corrisponda a URL KACLS corrente. Ciò consente il rilevamento di potenziali configurati da addetti ai lavori o amministratori di dominio non autorizzati.

  2. Decripta le seguenti parti utilizzando un algoritmo di crittografia autenticato:

    • Chiave di crittografia dei dati (DEK, Data Encryption Key)
    • I valori resource_name e perimeter_id del token di autorizzazione
    • Altri dati sensibili

  3. Controlla che resource_name nel token di autorizzazione e nel blob decriptato corrispondono.

  4. Eseguire un controllo del perimetro utilizzando sia le attestazioni di autenticazione che quelle di autorizzazione.

  5. Registra l'operazione, incluso l'utente che l'ha originata, resource_name e il motivo passato nella richiesta.

  6. Restituisce la DEK senza wrapper o una risposta a un errore strutturato.

di Gemini Advanced.