Szyfrowanie i odszyfrowywanie danych

Ten przewodnik opisuje, jak działa szyfrowanie i odszyfrowywanie za pomocą 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 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ć te informacje.

Szyfrowanie danych

Gdy użytkownik Google Workspace poprosi o zapisanie lub przechowywanie danych zaszyfrowanych po stronie klienta, Google Workspace wyśle żądanie wrap na adres URL punktu końcowego usługi KACLS w celu zaszyfrowania danych. Oprócz opcjonalnych kontroli bezpieczeństwa, takich jak kontrole obwodowe i kontrole oparte na deklaracjach JWT, usługa KACLS musi wykonać te czynności:

  1. Sprawdź użytkownika wysyłającego prośbę.

    • Sprawdź token uwierzytelniania i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania należą do tego samego użytkownika, dopasowując deklaracje e-maila bez uwzględniania wielkości liter.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację google_email, należy ją porównać z deklaracją e-maila w tokenie autoryzacji bez uwzględniania wielkości liter. Do tego porównania nie używaj deklaracji e-maila w tokenie uwierzytelniania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnej deklaracji google_email, deklarację e-maila w tokenie uwierzytelniania należy porównać z deklaracją e-maila w tokenie autoryzacji bez uwzględniania wielkości liter.
    • W sytuacjach, gdy Google wystawia token autoryzacji dla adresu e-mail, który nie jest powiązany z kontem Google, musi być obecna deklaracja email_type. Stanowi to kluczową część funkcji dostępu dla gości, która zapewnia usłudze KACLS cenne informacje umożliwiające egzekwowanie dodatkowych środków bezpieczeństwa w przypadku użytkowników zewnętrznych.
      • Oto kilka przykładów, jak usługa KACLS może wykorzystać te informacje:
      • Aby nałożyć dodatkowe wymagania dotyczące logowania.
      • Aby ograniczyć wystawcę tokena uwierzytelniania do dedykowanego dostawcy tożsamości dla gości.
      • Aby wymagać dodatkowych deklaracji w tokenie uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu dla gości, wszystkie żądania, w których email_type jest ustawiony na google-visitor lub customer-idp, mogą zostać odrzucone. Żądania z email_type ustawionym na google lub z nieustawionym email_type powinny być nadal akceptowane.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację delegated_to, musi też zawierać deklarację resource_name, a te 2 deklaracje należy porównać z deklaracjami delegated_to i resource_name w tokenie autoryzacji. Deklaracje delegated_to należy porównać bez uwzględniania wielkości liter, a resource_name w tokenach powinna odpowiadać resource_name operacji.
    • Sprawdź, czy deklaracja role w tokenie autoryzacji ma wartość writer lub upgrader.
    • Sprawdź, czy deklaracja kacls_url w tokenie autoryzacji jest zgodna 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 domeny.
    • Przeprowadź kontrolę obwodową za pomocą deklaracji 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
    • Wszelkie dodatkowe dane wrażliwe

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

  4. Zwróć nieprzezroczysty obiekt binarny, który ma być przechowywany przez Google Workspace obok zaszyfrowanego obiektu i wysyłany w niezmienionej postaci w każdej kolejnej operacji rozpakowywania klucza. Możesz też zwrócić ustrukturyzowaną odpowiedź o błędzie.

    • 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 na adres URL punktu końcowego usługi KACLS w celu odszyfrowania danych. Oprócz opcjonalnych kontroli bezpieczeństwa, takich jak kontrole obwodowe i kontrole oparte na deklaracjach JWT, usługa KACLS musi wykonać te czynności:

  1. Sprawdź użytkownika wysyłającego prośbę.

    • Sprawdź token uwierzytelniania i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania należą do tego samego użytkownika, dopasowując deklaracje e-maila bez uwzględniania wielkości liter.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację google_email, należy ją porównać z deklaracją e-maila w tokenie autoryzacji bez uwzględniania wielkości liter. Do tego porównania nie używaj deklaracji e-maila w tokenie uwierzytelniania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnej deklaracji google_email, deklarację e-maila w tokenie uwierzytelniania należy porównać z deklaracją e-maila w tokenie autoryzacji bez uwzględniania wielkości liter.
    • W sytuacjach, gdy Google wystawia token autoryzacji dla adresu e-mail, który nie jest powiązany z kontem Google, musi być obecna deklaracja email_type. Stanowi to kluczową część funkcji dostępu dla gości, która zapewnia usłudze KACLS cenne informacje umożliwiające egzekwowanie dodatkowych środków bezpieczeństwa w przypadku użytkowników zewnętrznych.
      • Oto kilka przykładów, jak usługa KACLS może wykorzystać te informacje:
      • Aby nałożyć dodatkowe wymagania dotyczące logowania.
      • Aby ograniczyć wystawcę tokena uwierzytelniania do dedykowanego dostawcy tożsamości dla gości.
      • Aby wymagać dodatkowych deklaracji w tokenie uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu dla gości, wszystkie żądania, w których email_type jest ustawiony na google-visitor lub customer-idp, mogą zostać odrzucone. Żądania z email_type ustawionym na google lub z nieustawionym email_type powinny być nadal akceptowane.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację delegated_to, musi też zawierać deklarację resource_name, a te 2 deklaracje należy porównać z deklaracjami delegated_to i resource_name w tokenie autoryzacji. Deklaracje delegated_to należy porównać bez uwzględniania wielkości liter, a resource_name w tokenach powinna odpowiadać resource_name operacji.
    • Sprawdź, czy deklaracja role w tokenie autoryzacji ma wartość reader lub writer.
    • Sprawdź, czy deklaracja kacls_url w tokenie autoryzacji jest zgodna 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 domeny.

  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
    • Wszelkie dodatkowe dane wrażliwe

  3. Sprawdź, czy resource_name w tokenie autoryzacji i odszyfrowanym obiekcie blob są zgodne.

  4. Przeprowadź kontrolę obwodową za pomocą deklaracji uwierzytelniania i autoryzacji.

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

  6. Zwróć rozpakowany klucz DEK lub ustrukturyzowaną odpowiedź o błędzie.