Szyfrowanie i odszyfrowywanie danych

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

Na liście dozwolonych musisz umieścić wszystkie usługi dostawcy tożsamości używane przez użytkowników do udostępniania zaszyfrowanych plików. 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 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 (CSE), Google Workspace wysyła prośbę wrap o szyfrowanie do adresu URL punktu końcowego KACLS. Oprócz opcjonalnych kontroli bezpieczeństwa, takich jak kontrola perymetryczna i kontrola na podstawie atrybutów JWT, KACLS musi wykonać te czynności:

  1. Sprawdź, czy użytkownik, który wysłał prośbę, jest prawidłowy.

    • Sprawdź token uwierzytelniania i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania dotyczą tego samego użytkownika, porównując oświadczenia e-maila bez uwzględniania wielkości liter.
    • Jeśli token uwierzytelniania zawiera opcjonalne roszczenie google_email, należy go porównać z roszczeniem adresu e-mail w tokenie autoryzacji, nie zwracając uwagi na wielkość liter. W tym porównaniu nie używaj atrybutu e-mail w tokenie uwierzytelniania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnego roszczenia google_email, żądanie adresu e-mail w tokenie uwierzytelniania powinno być porównane z żądaniem adresu e-mail w tokenie autoryzacji, przy użyciu metody ignorującej wielkość liter.
    • W sytuacjach, gdy 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óra dostarcza cennych informacji do list kontroli dostępu do kluczy, aby zapewnić dodatkowe środki bezpieczeństwa użytkownikom zewnętrznym.
      • Oto kilka przykładów sposobów, w jaki KACLS może wykorzystywać te informacje:
      • Aby nałożyć dodatkowe wymagania dotyczące rejestrowania.
      • Aby ograniczyć wystawcę tokenu uwierzytelniania do dedykowanego dostawcy tożsamości dla gości.
      • Aby wymagać dodatkowych roszczeń w tokenie uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu gościa, wszystkie żądania, w których zasada email_type ma wartość google-visitor lub customer-idp, mogą zostać odrzucone. Prośby z wartością email_type równą google lub z nieokreślonym email_type powinny nadal być akceptowane.
    • Sprawdź, czy role w tokenie autoryzacji to „writer” (autor) lub „upgrader” (uaktualniacz).
    • Sprawdź, czy kacls_url w tokenie autoryzacji odpowiada bieżącemu adresowi URL usługi KACLS. Ta kontrola umożliwia wykrywanie potencjalnych serwerów typu man-in-the-middle skonfigurowanych przez osoby z dostępem do sieci wewnętrznej lub nieuprawnionych administratorów domen.
    • Przeprowadzanie kontroli obwodowej przy użyciu zarówno oświadczeń uwierzytelniania, jak i oświadczeń autoryzacji.

  2. Szyfruj te elementy przy użyciu uwierzytelnionego algorytmu szyfrowania:

    • 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ą wykonał, resource_name oraz powód przekazany w żądaniu.

  4. Zwracanie obiektu binarnego, który ma być przechowywany przez Google Workspace, obok zaszyfrowanego obiektu i wysyłany w niezmienionej postaci w przypadku każdej kolejnej operacji odszyfrowywania klucza. Możesz też wyświetlić odpowiedź na błąd o określonej strukturze.

    • Obiekt binarny powinien zawierać jedyną kopię zaszyfrowanego klucza DEK. Może on przechowywać dane specyficzne dla implementacji.

Odszyfrowanie danych

Gdy użytkownik Google Workspace poprosi o otwarcie danych zaszyfrowanych po stronie klienta, Google Workspace wysyła żądanie unwrap do adresu URL punktu końcowego KACLS w celu odszyfrowania. Oprócz opcjonalnych kontroli bezpieczeństwa, takich jak kontrola obwodu i kontrola na podstawie twierdzeń JWT, KACLS musi wykonać te czynności:

  1. Sprawdź, czy użytkownik, który wysłał prośbę, jest uprawniony.

    • Sprawdź token uwierzytelniania i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania dotyczą tego samego użytkownika, porównując oświadczenia e-maila bez uwzględniania wielkości liter.
    • Jeśli token uwierzytelniania zawiera opcjonalne roszczenie google_email, należy go porównać z roszczeniem adresu e-mail w tokenie autoryzacji, nie zwracając uwagi na wielkość liter. W tym porównaniu nie używaj atrybutu e-mail w tokenie uwierzytelniania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnego roszczenia google_email, żądanie adresu e-mail w tokenie uwierzytelniania powinno być porównane z żądaniem adresu e-mail w tokenie autoryzacji, przy użyciu metody ignorującej wielkość liter.
    • W sytuacjach, gdy 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óra dostarcza cennych informacji do list kontroli dostępu do kluczy, aby zapewnić dodatkowe środki bezpieczeństwa użytkownikom zewnętrznym.
      • Oto kilka przykładów sposobów, w jaki KACLS może wykorzystywać te informacje:
      • Aby nałożyć dodatkowe wymagania dotyczące rejestrowania.
      • Aby ograniczyć wystawcę tokenu uwierzytelniania do dedykowanego dostawcy tożsamości dla gości.
      • Aby wymagać dodatkowych roszczeń w tokenie uwierzytelniania.
      • Jeśli klient nie skonfigurował dostępu gościa, wszystkie żądania, w których zasada email_type ma wartość google-visitor lub customer-idp, mogą zostać odrzucone. Prośby z wartością email_type równą google lub z nieokreślonym email_type powinny nadal być akceptowane.
    • Sprawdź, czy role w tokenie autoryzacji to „reader” (czytnik) lub „writer” (pisarz).
    • Sprawdź, czy kacls_url w tokenie autoryzacji odpowiada bieżącemu adresowi URL usługi KACLS. Umożliwia to wykrywanie potencjalnych serwerów typu man-in-the-middle skonfigurowanych przez osoby z dostępem do sieci wewnętrznej lub nieuprawnionych administratorów domen.

  2. Odszyfruj te elementy za pomocą uwierzytelnionego algorytmu szyfrowania:

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

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

  4. Wykonaj kontrolę obwodu, używając zarówno oświadczenia uwierzytelniającego, jak i oświadczenia autoryzującego.

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

  6. Zwracaj nieopakowany DEK lub uporządkowaną odpowiedź na błąd.