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:
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
lubcustomer-idp
, mogą zostać odrzucone. Żądania z wartościąemail_type
o wartościgoogle
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.
Zaszyfruj te części za pomocą uwierzytelnionego algorytmu szyfrowania:
- Klucz szyfrowania danych (DEK)
- Wartości
resource_name
iperimeter_id
z tokena autoryzacji - Dodatkowe dane wrażliwe
Zarejestruj operację, w tym nazwę użytkownika, który ją rozpoczął,
resource_name
oraz powód przekazany w żądaniu.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:
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
lubcustomer-idp
, mogą zostać odrzucone. Żądania z wartościąemail_type
o wartościgoogle
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.
Odszyfruj te części za pomocą uwierzytelnionego algorytmu szyfrowania:
- Klucz szyfrowania danych (DEK)
- Wartości
resource_name
iperimeter_id
z tokena autoryzacji - Dodatkowe dane wrażliwe
Sprawdź, czy
resource_name
w tokenie autoryzacji i odszyfrowanym obiekcie blobowym są zgodne.Przeprowadź sprawdzenie granicy przy użyciu deklaracji dotyczących uwierzytelniania i autoryzacji.
Zarejestruj operację, w tym nazwę użytkownika, który ją rozpoczął,
resource_name
oraz powód przekazany w żądaniu.Zwraca rozpakowany plik DEK lub uporządkowaną odpowiedź o błędzie.