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 do adresu URL punktu końcowego usługi listy kontroli dostępu do kluczy (KACLS) w celu zaszyfrowania danych. 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 dla gości, 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:
      • nałożenia dodatkowych wymagań dotyczących 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ł, interfejs 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 dla gości, 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:
      • nałożenia dodatkowych wymagań dotyczących 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ł, interfejs resource_name i przyczynę przekazaną w żądaniu.

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