Cripta e decripta i dati

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

Devi aggiungere a una lista consentita tutti i servizi del provider di identità (IdP) utilizzati dagli utenti che condividono file criptati. In genere, 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 ottenere i dettagli dell'IdP.

Criptare i dati

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

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

    • Convalidare sia il token di autenticazione sia il token di autorizzazione.
    • Verificare che i token di autorizzazione e autenticazione siano per lo stesso utente eseguendo una corrispondenza senza distinzione tra maiuscole e minuscole sulle attestazioni email.
    • Quando il token di autenticazione contiene l'attestazione facoltativa google_email, questa deve essere confrontata con l'attestazione email nel token di autorizzazione utilizzando un approccio senza distinzione tra maiuscole e minuscole. Non utilizzare l'attestazione email all'interno del token di autenticazione per questo confronto.
    • Negli scenari in cui il token di autenticazione non include l'attestazione facoltativa google_email, l'attestazione email all'interno del token di autenticazione deve essere confrontata con l'attestazione email nel token di autorizzazione utilizzando un metodo senza distinzione tra maiuscole e minuscole.
    • Negli scenari in cui Google emette un token di autorizzazione per un'email non associata a un Account Google, deve essere presente l'attestazione email_type. Questa è una parte fondamentale della funzionalità Accesso ospite, che fornisce informazioni preziose al KACLS per applicare misure di sicurezza aggiuntive agli utenti esterni.
      • Ecco 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 attestazioni 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 attestazioni 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.
    • Verificare che l'attestazione role nel token di autorizzazione sia writer o upgrader.
    • Verificare che l'attestazione kacls_url nel token di autorizzazione corrisponda all'URL KACLS corrente. Questo controllo consente di rilevare potenziali server man-in-the-middle configurati da insider o amministratori di dominio non autorizzati.
    • Eseguire un controllo del perimetro utilizzando sia le attestazioni di autenticazione sia quelle di autorizzazione.

  2. Criptare 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. Registrare l'operazione, incluso l'utente che l'ha avviata, il resource_name e il motivo passato nella richiesta.

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

    • L'oggetto binario deve contenere l'unica copia della DEK criptata e può contenere dati specifici dell'implementazione.

Decriptare i dati

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

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

    • Convalidare sia il token di autenticazione sia il token di autorizzazione.
    • Verificare che i token di autorizzazione e autenticazione siano per lo stesso utente eseguendo una corrispondenza senza distinzione tra maiuscole e minuscole sulle attestazioni email.
    • Quando il token di autenticazione contiene l'attestazione facoltativa google_email, questa deve essere confrontata con l'attestazione email nel token di autorizzazione utilizzando un approccio senza distinzione tra maiuscole e minuscole. Non utilizzare l'attestazione email all'interno del token di autenticazione per questo confronto.
    • Negli scenari in cui il token di autenticazione non include l'attestazione facoltativa google_email, l'attestazione email all'interno del token di autenticazione deve essere confrontata con l'attestazione email nel token di autorizzazione utilizzando un metodo senza distinzione tra maiuscole e minuscole.
    • Negli scenari in cui Google emette un token di autorizzazione per un'email non associata a un Account Google, deve essere presente l'attestazione email_type. Questa è una parte fondamentale della funzionalità Accesso ospite, che fornisce informazioni preziose al KACLS per applicare misure di sicurezza aggiuntive agli utenti esterni.
      • Ecco 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 attestazioni 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 attestazioni 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.
    • Verificare che l'attestazione role nel token di autorizzazione sia reader o writer.
    • Verificare che l'attestazione kacls_url nel token di autorizzazione corrisponda all'URL KACLS corrente. Questo consente di rilevare potenziali server man-in-the-middle configurati da insider o amministratori di dominio non autorizzati.

  2. Decriptare 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. Verificare che il resource_name nel token di autorizzazione e il blob decriptato corrispondano.

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

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

  6. Restituire la DEK scapsulata o una risposta di errore strutturata.