Cripta e decripta i dati

Questa guida descrive il funzionamento della crittografia e della decrittografia utilizzando l'API Crittografia lato client di Google Workspace.

Devi inserire nella lista consentita tutti i servizi del provider di identità (IdP) utilizzati dagli utenti che condividono file criptati. Normalmente, puoi trovare i dettagli dell'IdP richiesti nel file .well-known disponibile pubblicamente; in caso contrario, contatta l'amministratore di Google Workspace dell'organizzazione per richiedere i dettagli dell'IdP.

Criptare i dati

Quando un utente Google Workspace richiede di salvare o archiviare dati con crittografia lato client (CSE), Google Workspace invia una richiesta wrap all'URL dell'endpoint del servizio dell'elenco di controllo dell'accesso per le chiavi (KACLS) per la crittografia. Oltre ai controlli di sicurezza facoltativi, come quelli basati sulle rivendicazioni perimetrali e JWT, il tuo KACLS deve eseguire i seguenti passaggi:

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

    • Convalida sia il token di autenticazione sia il token di autorizzazione.
    • Verifica che i token di autorizzazione e autenticazione siano per lo stesso utente eseguendo una corrispondenza senza distinzione tra maiuscole e minuscole per le rivendicazioni email.
    • Quando il token di autenticazione contiene l'attestazione facoltativa google_email, deve essere confrontata con l'attestazione email nel token di autorizzazione utilizzando un approccio che non fa distinzione tra maiuscole e minuscole. Non utilizzare la rivendicazione dell'email all'interno del token di autenticazione per questo confronto.
    • Negli scenari in cui il token di autenticazione non include l'attributo google_email facoltativo, l'attributo email all'interno del token di autenticazione deve essere confrontato con l'attributo email nel token di autorizzazione, utilizzando un metodo che non fa distinzione tra maiuscole e minuscole.
    • Negli scenari in cui Google rilascia un token di autorizzazione per un'email non associata a un Account Google, deve essere presente l'attestazione email_type. Questo costituisce una parte fondamentale della funzionalità Accesso ospite, fornendo informazioni preziose per consentire agli elenchi di controllo dell'accesso per le chiavi di applicare misure di sicurezza aggiuntive agli utenti esterni.
      • Di seguito sono riportati alcuni esempi di come un KACLS può utilizzare queste informazioni:
      • Per imporre requisiti di logging aggiuntivi.
      • Per limitare l'emittente del token di autenticazione a un IdP ospite dedicato.
      • Per richiedere rivendicazioni aggiuntive sul token di autenticazione.
      • Se un cliente non ha configurato l'accesso ospite, tutte le richieste in cui email_type è impostato su google-visitor o customer-idp possono essere rifiutate. Le richieste con un email_type di google o con un email_type non impostato devono continuare a essere accettate.
    • Quando il token di autenticazione contiene l'attestazione facoltativa delegated_to, deve contenere anche l'attestazione resource_name e queste due attestazioni devono essere confrontate con le attestazioni delegated_to e resource_name nel token di autorizzazione. Le rivendicazioni delegated_to devono essere confrontate utilizzando un approccio senza distinzione tra maiuscole e minuscole e il resource_name nei token deve corrispondere al resource_name dell'operazione.
    • Verifica che la rivendicazione role nel token di autorizzazione sia writer o upgrader.
    • Verifica che l'attestazione kacls_url nel token di autorizzazione corrisponda all'URL KACLS attuale. Questo controllo consente di rilevare potenziali server man-in-the-middle configurati da insider o amministratori di dominio malintenzionati.
    • Esegui un controllo del perimetro utilizzando sia le rivendicazioni di autenticazione che di autorizzazione.

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

    • Chiave di crittografia dei dati (DEK)
    • I valori resource_name e perimeter_id del token di autorizzazione
    • Eventuali dati sensibili aggiuntivi

  3. Registra l'operazione, inclusi l'utente che l'ha avviata, il resource_name e il motivo indicato nella richiesta.

  4. Restituisce un oggetto binario opaco da archiviare da Google Workspace insieme all'oggetto criptato e inviato così com'è in qualsiasi operazione di scarto della chiave successiva. In alternativa, fornisci una risposta di errore strutturata.

    • L'oggetto binario deve contenere l'unica copia della DEK criptata, in cui possono essere memorizzati dati specifici dell'implementazione.

Decriptare i dati

Quando un utente Google Workspace richiede di aprire dati criptati lato client (CSE), Google Workspace invia una richiesta unwrap all'URL dell'endpoint KACLS per la decriptazione. Oltre ai controlli di sicurezza facoltativi, come i controlli perimetrali e basati sulle rivendicazioni JWT, il tuo KACLS deve eseguire i seguenti passaggi:

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

    • Convalida sia il token di autenticazione sia il token di autorizzazione.
    • Verifica che i token di autorizzazione e autenticazione siano per lo stesso utente eseguendo una corrispondenza senza distinzione tra maiuscole e minuscole per le rivendicazioni email.
    • Quando il token di autenticazione contiene l'attestazione facoltativa google_email, deve essere confrontata con l'attestazione email nel token di autorizzazione utilizzando un approccio che non fa distinzione tra maiuscole e minuscole. Non utilizzare la rivendicazione dell'email all'interno del token di autenticazione per questo confronto.
    • Negli scenari in cui il token di autenticazione non include l'attributo google_email facoltativo, l'attributo email all'interno del token di autenticazione deve essere confrontato con l'attributo email nel token di autorizzazione, utilizzando un metodo che non fa distinzione tra maiuscole e minuscole.
    • Negli scenari in cui Google rilascia un token di autorizzazione per un'email non associata a un Account Google, deve essere presente l'attestazione email_type. Questo costituisce una parte fondamentale della funzionalità Accesso ospite, fornendo informazioni preziose per consentire agli elenchi di controllo dell'accesso per le chiavi di applicare misure di sicurezza aggiuntive agli utenti esterni.
      • Di seguito sono riportati alcuni esempi di come un KACLS può utilizzare queste informazioni:
      • Per imporre requisiti di logging aggiuntivi.
      • Per limitare l'emittente del token di autenticazione a un IdP ospite dedicato.
      • Per richiedere rivendicazioni aggiuntive sul token di autenticazione.
      • Se un cliente non ha configurato l'accesso ospite, tutte le richieste in cui email_type è impostato su google-visitor o customer-idp possono essere rifiutate. Le richieste con un email_type di google o con un email_type non impostato devono continuare a essere accettate.
    • Quando il token di autenticazione contiene l'attestazione facoltativa delegated_to, deve contenere anche l'attestazione resource_name e queste due attestazioni devono essere confrontate con le attestazioni delegated_to e resource_name nel token di autorizzazione. Le rivendicazioni delegated_to devono essere confrontate utilizzando un approccio senza distinzione tra maiuscole e minuscole e il resource_name nei token deve corrispondere al resource_name dell'operazione.
    • Verifica che la rivendicazione role nel token di autorizzazione sia reader o writer.
    • Verifica che l'attestazione kacls_url nel token di autorizzazione corrisponda all'URL KACLS attuale. Ciò consente di rilevare potenziali server man-in-the-middle configurati da utenti malintenzionati o amministratori di dominio non autorizzati.

  2. Decrittografa le seguenti parti utilizzando un algoritmo di crittografia autenticata:

    • Chiave di crittografia dei dati (DEK)
    • I valori resource_name e perimeter_id del token di autorizzazione
    • Eventuali dati sensibili aggiuntivi

  3. Verifica che il resource_name nel token di autorizzazione e nel blob decriptato corrispondano.

  4. Esegui un controllo del perimetro utilizzando sia le rivendicazioni di autenticazione che quelle di autorizzazione.

  5. Registra l'operazione, inclusi l'utente che l'ha avviata, il resource_name e il motivo indicato nella richiesta.

  6. Restituisce la DEK decriptata o una risposta di errore strutturata.