Szyfrowanie i odszyfrowywanie danych

Ten przewodnik opisuje, jak działa szyfrowanie i odszyfrowywanie za pomocą interfejsu Google Workspace Client-side Encryption API.

Musisz dodać do listy dozwolonych wszystkie usługi dostawcy tożsamości używane przez użytkowników udostępniających zaszyfrowane pliki. Wymagane szczegółowe informacje o dostawcy tożsamości można zwykle znaleźć w publicznie dostępnym pliku .well-known. W przeciwnym razie skontaktuj się z administratorem Google Workspace w organizacji, aby uzyskać szczegółowe informacje o dostawcy tożsamości.

Szyfrowanie danych

Gdy użytkownik Google Workspace poprosi o zapisanie lub przechowywanie danych zaszyfrowanych po stronie klienta, Google Workspace wyśle żądanie wrap szyfrowania na adres URL punktu końcowego usługi listy kontroli dostępu do kluczy (KACLS). Oprócz opcjonalnych kontroli bezpieczeństwa, takich jak kontrole oparte na obwodzie i na roszczeniach JWT, KACLS musi wykonać te czynności:

  1. Sprawdź, czy użytkownik wysyłający prośbę jest uprawniony.

    • Sprawdź zarówno token uwierzytelniania, jak i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania należą do tego samego użytkownika, porównując roszczenia dotyczące adresu e-mail bez uwzględniania wielkości liter.
    • Jeśli token uwierzytelniania zawiera opcjonalne roszczenie google_email, musi ono zostać porównane z roszczeniem dotyczącym adresu e-mail w tokenie autoryzacji z uwzględnieniem wielkości liter. Nie używaj roszczenia dotyczącego adresu e-mail w tokenie uwierzytelniającym na potrzeby tego porównania.
    • W sytuacjach, w których token uwierzytelniania nie zawiera opcjonalnego roszczenia google_email, roszczenie dotyczące adresu e-mail w tokenie uwierzytelniania należy porównać z roszczeniem dotyczącym adresu e-mail w tokenie autoryzacji, używając metody bez uwzględniania wielkości liter.
    • W sytuacjach, w których Google wydaje token autoryzacji dla adresu e-mail, który nie jest powiązany z kontem Google, musi być obecne roszczenie email_type. Jest to kluczowy element funkcji dostępu gościa, który dostarcza usłudze KACLS cennych informacji umożliwiających egzekwowanie dodatkowych środków bezpieczeństwa w przypadku użytkowników zewnętrznych.
      • Oto kilka przykładów wykorzystania tych informacji przez KACLS:
      • nakładać dodatkowe wymagania dotyczące logowania;
      • Aby ograniczyć wystawcę tokena uwierzytelniającego do dedykowanego dostawcy tożsamości dla gości.
      • Wymaganie dodatkowych roszczeń w tokenie uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu dla gości, wszystkie żądania, w których parametr email_type ma wartość google-visitor lub customer-idp, mogą zostać odrzucone. Prośby z wartością email_type równą google lub z nieustawionym parametrem email_type powinny być nadal akceptowane.
    • Jeśli token uwierzytelniania zawiera opcjonalne roszczenie delegated_to, musi też zawierać roszczenie resource_name. Te 2 roszczenia muszą być porównywane z roszczeniami delegated_to i resource_name w tokenie autoryzacji. Roszczenia delegated_to należy porównywać bez uwzględniania wielkości liter, a wartość resource_name w tokenach powinna być zgodna z wartością resource_name operacji.
    • Sprawdź, czy roszczenie role w tokenie autoryzacji ma wartość writer lub upgrader.
    • Sprawdź, czy roszczenie kacls_url w tokenie autoryzacji jest zgodne z bieżącym adresem URL usługi KACLS. Ta kontrola umożliwia wykrywanie potencjalnych serwerów typu „man-in-the-middle” skonfigurowanych przez osoby z wewnątrz organizacji lub nieuczciwych administratorów domen.
    • Przeprowadź kontrolę obwodową za pomocą roszczeń uwierzytelniania i autoryzacji.

  2. Zaszyfruj te części za pomocą algorytmu szyfrowania z uwierzytelnianiem:

    • Klucz szyfrujący dane (DEK)
    • Wartości resource_name i perimeter_id z tokena autoryzacji
    • inne dane wrażliwe,

  3. Zarejestruj operację, w tym użytkownika, który ją zainicjował, resource_name i przyczynę przekazaną w żądaniu.

  4. Zwraca nieprzezroczysty obiekt binarny, który ma być przechowywany przez Google Workspace obok zaszyfrowanego obiektu i wysyłany w stanie nienaruszonym w ramach kolejnych operacji odszyfrowywania klucza. Możesz też wyświetlić odpowiedź o określonej strukturze.

    • Obiekt binarny powinien zawierać tylko kopię zaszyfrowanego klucza DEK. Można w nim przechowywać dane specyficzne dla implementacji.

Odszyfrowywanie danych

Gdy użytkownik Google Workspace poprosi o otwarcie danych zaszyfrowanych po stronie klienta, Google Workspace wyśle unwrap żądanie do adresu URL punktu końcowego KACLS w celu odszyfrowania. Oprócz opcjonalnych kontroli bezpieczeństwa, takich jak kontrole obwodowe i kontrole oparte na roszczeniach JWT, usługa KACLS musi wykonać te czynności:

  1. Sprawdź, czy użytkownik wysyłający prośbę jest uprawniony.

    • Sprawdź zarówno token uwierzytelniania, jak i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania należą do tego samego użytkownika, porównując roszczenia dotyczące adresu e-mail bez uwzględniania wielkości liter.
    • Jeśli token uwierzytelniania zawiera opcjonalne roszczenie google_email, musi ono zostać porównane z roszczeniem dotyczącym adresu e-mail w tokenie autoryzacji z uwzględnieniem wielkości liter. Nie używaj roszczenia dotyczącego adresu e-mail w tokenie uwierzytelniającym na potrzeby tego porównania.
    • W sytuacjach, w których token uwierzytelniania nie zawiera opcjonalnego roszczenia google_email, roszczenie dotyczące adresu e-mail w tokenie uwierzytelniania należy porównać z roszczeniem dotyczącym adresu e-mail w tokenie autoryzacji, używając metody bez uwzględniania wielkości liter.
    • W sytuacjach, w których Google wydaje token autoryzacji dla adresu e-mail, który nie jest powiązany z kontem Google, musi być obecne roszczenie email_type. Jest to kluczowy element funkcji dostępu gościa, który dostarcza usłudze KACLS cennych informacji umożliwiających egzekwowanie dodatkowych środków bezpieczeństwa w przypadku użytkowników zewnętrznych.
      • Oto kilka przykładów wykorzystania tych informacji przez KACLS:
      • nakładać dodatkowe wymagania dotyczące logowania;
      • Aby ograniczyć wystawcę tokena uwierzytelniającego do dedykowanego dostawcy tożsamości dla gości.
      • Wymaganie dodatkowych roszczeń w tokenie uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu dla gości, wszystkie żądania, w których parametr email_type ma wartość google-visitor lub customer-idp, mogą zostać odrzucone. Prośby z wartością email_type równą google lub z nieustawionym parametrem email_type powinny być nadal akceptowane.
    • Jeśli token uwierzytelniania zawiera opcjonalne roszczenie delegated_to, musi też zawierać roszczenie resource_name. Te 2 roszczenia muszą być porównywane z roszczeniami delegated_to i resource_name w tokenie autoryzacji. Roszczenia delegated_to należy porównywać bez uwzględniania wielkości liter, a wartość resource_name w tokenach powinna być zgodna z wartością resource_name operacji.
    • Sprawdź, czy roszczenie role w tokenie autoryzacji ma wartość reader lub writer.
    • Sprawdź, czy roszczenie kacls_url w tokenie autoryzacji jest zgodne z bieżącym adresem URL usługi KACLS. Umożliwia to wykrywanie potencjalnych serwerów typu „man-in-the-middle” skonfigurowanych przez osoby z wewnątrz organizacji lub nieuczciwych administratorów domen.

  2. Odszyfruj te części za pomocą algorytmu szyfrowania z uwierzytelnianiem:

    • Klucz szyfrujący dane (DEK)
    • Wartości resource_name i perimeter_id z tokena autoryzacji
    • inne dane wrażliwe,

  3. Sprawdź, czy znak resource_name w tokenie autoryzacji i odszyfrowanym obiekcie blob jest taki sam.

  4. Przeprowadź kontrolę obwodową za pomocą roszczeń dotyczących uwierzytelniania i autoryzacji.

  5. Zarejestruj operację, w tym użytkownika, który ją zainicjował, resource_name i przyczynę przekazaną w żądaniu.

  6. Zwróć wyodrębniony klucz DEK lub odpowiedź z błędem strukturalnym.