Szyfrowanie i odszyfrowywanie danych

Z tego przewodnika dowiesz się, jak działa szyfrowanie i odszyfrowywanie przy użyciu interfejsu Google Workspace Client-side Encryption API.

Do listy dozwolonych musisz dodać wszystkie usługi dostawcy tożsamości używane przez użytkowników udostępnianie zaszyfrowanych plików. Wymagane dane dostawcy tożsamości można zwykle znaleźć w publicznie dostępny plik .well-known; W przeciwnym razie skontaktuj się z administratora Google Workspace, aby uzyskać szczegółowe informacje o dostawcy tożsamości.

Zaszyfruj dane

Gdy użytkownik Google Workspace prosi o zapisanie lub przechowywanie danych zaszyfrowanych po stronie klienta (szyfrowanie po stronie klienta), Google Workspace wysyła wrap na adres URL punktu końcowego KACLS w celu zaszyfrowania. Oprócz opcjonalnego kontroli zabezpieczeń, takich jak kontrole granicy i tokena JWT, KACLS musi wykonaj te czynności:

  1. Sprawdź użytkownika, który wysłał żądanie.

    • zweryfikować token uwierzytelniania. i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania są przypisane do tego samego użytkownika przez dopasowania bez rozróżniania wielkości liter w roszczeniach adresów e-mail.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację google_email, musi być porównywana z roszczeniem adresu e-mail w tokenie autoryzacji . Nie używaj adresu e-mail z roszczeniem w atrybucie token uwierzytelniania na potrzeby tego porównania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnego parametru Żądanie google_email, żądanie e-maila w tokenie uwierzytelniania należy porównywać z roszczeniem adresu e-mail w tokenie autoryzacji, .
    • W sytuacjach, gdy Google wystawia token autoryzacji dla adresu e-mail, który nie jest powiązane z kontem Google, musi występować roszczenie email_type. Stanowi to kluczowy element funkcji dostępu dla gości, ponieważ zapewnia informacji, dzięki którym KACLS może egzekwować dodatkowe zabezpieczenia na zewnątrz użytkowników.
      • Oto kilka przykładów wykorzystania tych informacji przez KACLS:
      • Nałożyć dodatkowe wymagania dotyczące logowania.
      • ograniczenie wystawcy 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, gdzie email_type ma wartość google-visitor lub customer-idp może być odrzucono. Żądania z wartością email_type o wartości google lub z nieskonfigurowaną wartością Opcja email_type powinna być nadal akceptowana.
    • Sprawdź, czy deklaracja role w tokenie autoryzacji ma wartość „writer” (zapisujący). lub „uaktualniacz”.
    • Sprawdź, czy deklaracja kacls_url w tokenie autoryzacji jest zgodna z obecny URL KACLS. Ta kontrola umożliwia wykrywanie potencjalnych serwery typu „man in the middle” skonfigurowane przez osoby wtajemniczone lub wrogą domenę; Google Workspace for Education.
    • Sprawdzanie granicy przy użyciu uwierzytelniania i autoryzacji roszczeniami.

  2. Zaszyfruj te części za pomocą uwierzytelnionego algorytmu szyfrowania:

    • Klucz szyfrowania danych (DEK)
    • Wartości resource_name i perimeter_id z tokena autoryzacji
    • Wszelkie dodatkowe dane wrażliwe

  3. Zarejestruj operację, w tym nazwę użytkownika, który ją uruchomił, oraz operacje resource_name i powód podany w żądaniu.

  4. Zwróć nieprzejrzysty obiekt binarny do przechowywania przez Google Workspace zaszyfrowany obiekt i wysłany w takiej postaci, w jakiej jest, podczas każdego kolejnego wyodrębniania klucza . Możesz też wysłać ustrukturyzowaną odpowiedź na błąd.

    • Obiekt binarny powinien zawierać jedyną kopię zaszyfrowanego klucza DEK, i można w niej zapisywać dane związane z implementacją.
.

Odszyfrowywanie 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 zabezpieczeń takie jak testy granicy i tokena JWT, KACLS musi wykonać te kroki:

  1. Sprawdź użytkownika, który wysłał żądanie.

    • zweryfikować token uwierzytelniania. i token autoryzacji.
    • Sprawdź, czy tokeny autoryzacji i uwierzytelniania są przypisane do tego samego użytkownika przez dopasowania bez rozróżniania wielkości liter w roszczeniach adresów e-mail.
    • Gdy token uwierzytelniania zawiera opcjonalną deklarację google_email, musi być porównywana z roszczeniem adresu e-mail w tokenie autoryzacji . Nie używaj adresu e-mail z roszczeniem w atrybucie token uwierzytelniania na potrzeby tego porównania.
    • W sytuacjach, gdy token uwierzytelniania nie zawiera opcjonalnego parametru Żądanie google_email, żądanie e-maila w tokenie uwierzytelniania należy porównywać z roszczeniem adresu e-mail w tokenie autoryzacji, .
    • W sytuacjach, gdy Google wystawia token autoryzacji dla adresu e-mail, który nie jest powiązane z kontem Google, musi występować roszczenie email_type. Stanowi to kluczowy element funkcji dostępu dla gości, ponieważ zapewnia informacji, dzięki którym KACLS może egzekwować dodatkowe zabezpieczenia na zewnątrz użytkowników.
      • Oto kilka przykładów wykorzystania tych informacji przez KACLS:
      • Nałożyć dodatkowe wymagania dotyczące logowania.
      • ograniczenie wystawcy 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, gdzie email_type ma wartość google-visitor lub customer-idp może być odrzucono. Żądania z wartością email_type o wartości google lub z nieskonfigurowaną wartością Opcja email_type powinna być nadal akceptowana.
    • Sprawdź, czy deklaracja role w tokenie autoryzacji ma wartość „reader” lub „writer”.
    • Sprawdź, czy deklaracja kacls_url w tokenie autoryzacji jest zgodna z obecny URL KACLS. Umożliwia to wykrywanie potencjalnego trybu „man in the middle” serwerów skonfigurowanych przez osoby wtajemniczające lub nieuczciwych administratorów 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
    • Wszelkie dodatkowe dane wrażliwe

  3. Sprawdź, czy resource_name w tokenie autoryzacji i odszyfrowanym obiekcie blob dopasowania.

  4. Sprawdzaj granicę, używając deklaracji uwierzytelniania i autoryzacji.

  5. Zarejestruj operację, w tym nazwę użytkownika, który ją uruchomił, oraz operacje resource_name i powód podany w żądaniu.

  6. Zwraca nieopakowany plik DEK lub ustrukturyzowaną odpowiedź na błąd.

.