Szyfrowanie i odszyfrowywanie danych

W tym przewodniku opisano, jak działa szyfrowanie i odszyfrowywanie za pomocą interfejsu Google Workspace Client-side Encryption API.

Musisz umieścić na liście dozwolonych wszystkie usługi dostawcy tożsamości, z których korzystają użytkownicy udostępniający zaszyfrowane pliki. Wymagane informacje o dostawcy tożsamości można zwykle znaleźć w dostępnym publicznie pliku .well-known. W przeciwnym razie skontaktuj się z administratorem Google Workspace organizacji, aby uzyskać szczegółowe informacje o dostawcy tożsamości.

Zaszyfruj dane

Gdy użytkownik Google Workspace wysyła prośbę o zapisanie lub przechowywanie danych zaszyfrowanych po stronie klienta, Google Workspace wysyła żądanie wrap do adresu URL punktu końcowego KACLS w celu szyfrowania. Oprócz opcjonalnych kontroli zabezpieczeń, takich jak kontrole zabezpieczeń i opartych na deklaracji JWT, KACLS musi wykonać te czynności:

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

    • Zweryfikuj token uwierzytelniania i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania są przeznaczone dla tego samego użytkownika, stosując dopasowanie bez rozróżniania wielkości liter do deklaracji e-mail.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację google_email, należy go porównać z deklaracją adresu e-mail w tokenie autoryzacji. Wielkość liter nie jest rozróżniana. W tym porównaniu nie używaj deklaracji w e-mailu w tokenie uwierzytelniania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnego deklaracji google_email, treści e-maila zawarte w tokenie uwierzytelniania należy porównać z deklaracją dotyczącą e-maila w tokenie autoryzacji, stosując metodę bez rozróżniania wielkości liter.
    • W sytuacjach, gdy Google wystawia token autoryzacji dla adresu e-mail niepowiązanego z kontem Google, musi pojawić się deklaracja email_type. Jest to kluczowy element funkcji dostępu dla gości i dostarcza cennych informacji dla KACLS, które pozwalają wdrożyć dodatkowe środki bezpieczeństwa w odniesieniu do użytkowników zewnętrznych.
      • Oto kilka przykładów wykorzystania tych informacji w pliku KACLS:
      • Aby wprowadzić dodatkowe wymagania dotyczące logowania.
      • Ograniczyć wydawcę tokena uwierzytelniania do dedykowanego dostawcy tożsamości gościa.
      • Aby wymagać dodatkowych deklaracji tokena uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu gościa, wszystkie żądania, w których email_type ma wartość google-visitor lub customer-idp, mogą zostać odrzucone. Żądania z wartością email_type o wartości google lub nieskonfigurowaną wartością email_type powinny nadal być akceptowane.
    • Sprawdź, czy żądanie role w tokenie autoryzacji to „writer” lub „upgrader”.
    • Sprawdź, czy żądanie kacls_url w tokenie autoryzacji jest zgodne z bieżącym adresem URL KACLS. Ta weryfikacja pozwala na wykrywanie potencjalnych serwerów typu „man in the middle” skonfigurowanych przez osoby wtajemniczone lub nieuczciwych administratorów domen.
    • Sprawdź granicę, używając zarówno żądań uwierzytelniania, jak i żądań autoryzacji.
  2. Zaszyfruj te części za pomocą uwierzytelnionego algorytmu szyfrowania:

    • Klucz szyfrowania danych (DEK)
    • Wartości resource_name i perimeter_id z tokena autoryzacji
    • Dodatkowe dane wrażliwe
  3. Zarejestruj operację, w tym nazwę użytkownika, który ją rozpoczął, resource_name oraz powód przekazany w żądaniu.

  4. Zwraca nieprzejrzysty obiekt binarny, który ma być przechowywany przez Google Workspace obok zaszyfrowanego obiektu i wysyłany w niezmienionej postaci podczas każdej kolejnej operacji rozpakowywania klucza. albo wyświetlanie odpowiedzi o błędzie strukturalnym.

    • Obiekt binarny powinien zawierać jedyną kopię zaszyfrowanego pliku DEK. Można w nim przechowywać dane związane z implementacją.

Odszyfrowywanie danych

Gdy użytkownik Google Workspace prosi o otwarcie danych zaszyfrowanych po stronie klienta, Google Workspace wysyła do adresu URL punktu końcowego KACLS żądanie unwrap w celu ich odszyfrowania. Oprócz opcjonalnych kontroli zabezpieczeń, takich jak kontrole granicy i oparte na deklaracji JWT, KACLS musi wykonać te czynności:

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

    • Zweryfikuj token uwierzytelniania i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania są przeznaczone dla tego samego użytkownika, stosując dopasowanie bez rozróżniania wielkości liter do deklaracji e-mail.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację google_email, należy go porównać z deklaracją adresu e-mail w tokenie autoryzacji. Wielkość liter nie jest rozróżniana. W tym porównaniu nie używaj deklaracji w e-mailu w tokenie uwierzytelniania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnego deklaracji google_email, treści e-maila zawarte w tokenie uwierzytelniania należy porównać z deklaracją dotyczącą e-maila w tokenie autoryzacji, stosując metodę bez rozróżniania wielkości liter.
    • W sytuacjach, gdy Google wystawia token autoryzacji dla adresu e-mail niepowiązanego z kontem Google, musi pojawić się deklaracja email_type. Jest to kluczowy element funkcji dostępu dla gości i dostarcza cennych informacji dla KACLS, które pozwalają wdrożyć dodatkowe środki bezpieczeństwa w odniesieniu do użytkowników zewnętrznych.
      • Oto kilka przykładów wykorzystania tych informacji w pliku KACLS:
      • Aby wprowadzić dodatkowe wymagania dotyczące logowania.
      • Ograniczyć wydawcę tokena uwierzytelniania do dedykowanego dostawcy tożsamości gościa.
      • Aby wymagać dodatkowych deklaracji tokena uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu gościa, wszystkie żądania, w których email_type ma wartość google-visitor lub customer-idp, mogą zostać odrzucone. Żądania z wartością email_type o wartości google lub nieskonfigurowaną wartością email_type powinny nadal być akceptowane.
    • Sprawdź, czy żądanie role w tokenie autoryzacji to „reader” (czytnik) lub „writer”.
    • Sprawdź, czy żądanie kacls_url w tokenie autoryzacji jest zgodne z bieżącym adresem URL KACLS. Umożliwia to wykrywanie potencjalnych serwerów typu „man in the middle” skonfigurowanych przez osoby wtajemniczone lub nieuczciwe administratorzy domeny.
  2. Odszyfruj te części za pomocą uwierzytelnionego algorytmu szyfrowania:

    • Klucz szyfrowania danych (DEK)
    • Wartości resource_name i perimeter_id z tokena autoryzacji
    • Dodatkowe dane wrażliwe
  3. Sprawdź, czy resource_name w tokenie autoryzacji i odszyfrowanym obiekcie blobowym są zgodne.

  4. Przeprowadź sprawdzenie granicy przy użyciu deklaracji dotyczących uwierzytelniania i autoryzacji.

  5. Zarejestruj operację, w tym nazwę użytkownika, który ją rozpoczął, resource_name oraz powód przekazany w żądaniu.

  6. Zwraca rozpakowany plik DEK lub uporządkowaną odpowiedź o błędzie.