Przejdz do tresci
Avanet

Konfiguracja Google Workspace OIDC na Sophos Firewall

Sophos Firewall

W SFOS 23.0 można skonfigurować Google Workspace jako dostawcę tożsamości OpenID Connect (OIDC) dla WebAdmin, Captive Portal, VPN Portal oraz Remote Access IPsec i SSL VPN. Google weryfikuje tożsamość; firewall dodatkowo pobiera informacje o członkostwie w grupach i stosuje własne uprawnienia użytkowników, VPN i administratorów. Dlatego samo pomyślne logowanie w Google nie zapewnia jeszcze dostępu administratora ani dostępu do sieci wewnętrznej.

Szybka ścieżka: Przygotuj klienta internetowego Google OAuth i delegowane konto usługi, w Authentication > Servers utwórz serwer OpenID Connect z ustawieniem IdP vendor: Google Workspace, dodaj w Google wyświetlone tam adresy URL wywołań zwrotnych, zaimportuj grupy i przełącz tylko potrzebne usługi w Authentication > Services. Następnie sprawdź logowanie, uprawnienia i logi przy użyciu konta pilotażowego. Zachowaj przetestowany lokalny dostęp awaryjny.

Ta instrukcja opisuje konfigurację SFOS 23, a nie gwarantuje obsługi w konkretnym wydanym buildzie firmware. Przed aktualizacją zastosuj własny plan aktualizacji firmware i tworzenia kopii zapasowych. Chromebook SSO i Google Directory Sync dla Sophos Fusion to inne integracje, które nie zastępują tego serwera OIDC na firewallu.

Wymagania i granice bezpieczeństwa

Ustal odpowiedzialności i zabezpiecz dotychczasową konfigurację

Potrzebne są projekt Google Cloud, konto Google Workspace z dostępem Super Admin na potrzeby konfiguracji oraz administrator firewalla. Cloud Console zarządza klientem OAuth, interfejsami API i kontem usługi; Google Admin Console zarządza użytkownikami, grupami i Domain-wide delegation.

Przed pilotażem przygotuj kopię zapasową konfiguracji i przetestowany lokalny dostęp odzyskiwania. Dodatkowo zapisz dotychczasowe serwery uwierzytelniania i ich kolejność dla każdej usługi, nazwy hostów portali, zezwolenia Device Access, przypisania grup i VPN oraz istniejące profile administratorów. Podczas zmian pozostaw dostępną otwartą sesję administratora z pełnymi uprawnieniami; ze względu na możliwość przekroczenia limitu czasu sesji nie zastępuje ona drugiej ścieżki dostępu.

Przed pierwszym logowaniem pilotażowym dla każdej objętej zmianą lokalnej tożsamości zapisz w Authentication > Users, czy konto już istnieje, a także jego dotychczasowy User type, przypisany Profile i status konta. Ten spis poszczególnych kont stanowi część dokumentacji stanu sprzed zmian: późniejsza zmiana mapowania IdP lub roli Google nie przywraca automatycznie poprzedniego stanu istniejących lokalnych kont administratorów.

Przy planowaniu uprawnień nadal obowiązują zasady dotyczące indywidualnych kont administratorów i profili Device Access. Google SSO nie zastępuje ani zasady najmniejszych uprawnień, ani ograniczania źródeł dostępu do zarządzania.

Używaj jednej spójnej nazwy hosta

Nazwa portalu musi należeć do domeny, którą można zarejestrować, z publiczną domeną najwyższego poziomu. Pojedyncza nazwa, taka jak firewall, lub domena lokalna, taka jak firewall.local, nie nadaje się do przekierowań Google OAuth. Używaj tego samego FQDN do dostępu do portalu, URI przekierowania i automatycznych przekierowań portalu. Sprawdź rozwiązywanie nazw DNS oraz zaufany certyfikat HTTPS zgodny z nazwą z sieci, z których faktycznie korzystają klienci.

fw.example.com służy tu wyłącznie jako przykład dokumentacyjny i należy go zastąpić własnym prawidłowym FQDN. Nie jest to gotowy URI przekierowania. Ścieżkę wywołania zwrotnego i port usługi skopiuj później bez zmian z Show URLs, zamiast składać je na podstawie przykładu. W tym procesie również przy ręcznym wprowadzaniu używaj FQDN, a nie adresu IP.

Sprawdź ograniczenia przed przełączeniem

  • Dla każdej usługi uwierzytelniania można wybrać tylko jeden serwer dostawcy tożsamości OIDC. Dlatego istniejącego przypisania Entra nie można po prostu uzupełnić: trzeba je świadomie zastąpić lub pozostawić bez zmian.
  • Użytkownicy z tej samej domeny nie mogą być synchronizowani jednocześnie przez Active Directory i Google Workspace. Istniejący użytkownicy i grupy wymagają odpowiednich obiektów w Google; starymi obiektami, których nie da się przypisać, nadal trzeba zarządzać ręcznie.
  • Mechanizm MFA firewalla nie jest używany dla Google OIDC. Wymaganie MFA konfiguruje się w Google i faktycznie sprawdza podczas pilotażu. Lokalne konta awaryjne zachowują własne zabezpieczenia.
  • W klastrze HA Google SSO obecnie nie obsługuje logowania do WebAdmin na urządzeniu Auxiliary. Dlatego nadal potrzebna jest niezależna lokalna ścieżka dostępu do zarządzania.
  • Dla Google SSO z Sophos Connect przewidziano Windows i klienta w wersji 2.4 lub nowszej. Obsługa Entra w macOS nie oznacza zatwierdzenia obsługi Google Workspace.

Tylko jeśli planowane jest korzystanie z Context-Aware Access (CAA): Przed pilotażem sprawdź, czy każdy przewidziany użytkownik ma licencję lub edycję obsługującą CAA, czy CAA jest obsługiwane dla konkretnej aplikacji i procesu logowania oraz czy wymagana polityka jest faktycznie przypisana do aplikacji i grupy użytkowników lub jednostki organizacyjnej. Użytkownicy korzystający z innych edycji nie podlegają polityce CAA, nawet jeśli jest ona przypisana do tej samej grupy lub jednostki organizacyjnej; samo Endpoint Verification nie potwierdza uprawnienia do korzystania z CAA. CAA jest opcjonalne, a zwykłe logowanie Google OIDC nie wymaga licencji premium. Dokumentacja Google dotycząca SAML nie potwierdza obsługi procesu Sophos OIDC. Przed dopuszczeniem do użytkowania potwierdź oczekiwane działanie za pomocą nowych pozytywnych i negatywnych testów logowania dla konkretnej aplikacji, użytkowników i warunków; brak obsługi lub nieoczekiwanie pomyślne logowanie w teście negatywnym blokuje dopuszczenie procesu chronionego przez CAA.

Przygotuj Google Workspace

Utwórz klienta internetowego OAuth

  1. W Google Cloud Console > APIs & Services > Credentials wybierz właściwy projekt. Jeśli Google najpierw wymaga skonfigurowania ekranu zgody OAuth, dokończ tę konfigurację dla własnej organizacji i zatwierdzonej grupy użytkowników; nie włączaj ogólnego dostępu zewnętrznego wyłącznie na potrzeby testu.
  2. Otwórz Create credentials > OAuth client ID i wybierz Application type: Web application.
  3. Nadaj czytelną nazwę, na przykład SFOS-Google-SSO-Pilot, i utwórz klienta.
  4. Natychmiast zapisz Client ID i Client secret w zatwierdzonym magazynie sekretów. Nie kopiuj sekretu na zrzuty ekranu, do zgłoszeń ani do dokumentacji zmiany.

Identyfikator klienta OAuth identyfikuje firewall podczas logowania. Nie jest to numeryczny identyfikator konta usługi, który później będzie potrzebny do delegacji. URI przekierowania dodaj dopiero po wygenerowaniu ich przez firewall.

Skonfiguruj konto usługi i pobieranie grup

Logowanie i pobieranie grup korzystają z różnych mechanizmów dostępu: klient OAuth służy do interaktywnego logowania, a konto usługi pozwala firewallowi pobierać informacje z katalogu Google. Google nie przekazuje członkostwa w grupach jako części standardowej odpowiedzi logowania OIDC.

  1. W Google Cloud Console > IAM & admin > Service accounts > Create service account utwórz dedykowane konto dla tej integracji, na przykład sfos-directory-reader.
  2. Nie przyznawaj ogólnych ról Owner ani Editor jako rzekomego wymagania. Dodatkowe uprawnienia IAM zatwierdzaj tylko dla wykazanej potrzeby.
  3. W szczegółach konta usługi zapisz numeryczny Unique ID.
  4. W Keys > Add key > Create new key wybierz typ JSON. Zabezpiecz pobrany klucz prywatny na potrzeby późniejszego przesłania do firewalla i unikaj niekontrolowanych kopii pobranego pliku.
  5. W APIs & Services > Library wyszukaj Admin SDK API i włącz go przyciskiem Enable.

⚠️ Jeśli pojawi się komunikat Service account key creation is disabled, wstrzymaj konfigurację. Nie wyłączaj zasad organizacji w całej organizacji, aby kontynuować tę instrukcję. Osoba odpowiedzialna za bezpieczeństwo Google musi zatwierdzić ograniczony, udokumentowany wyjątek; w przeciwnym razie integracja pozostaje zablokowana. Opisana tutaj konfiguracja Sophos wymaga pliku klucza JSON; nie wskazuje się innej metody uwierzytelniania jako niezweryfikowanego zamiennika.

Ogranicz Domain-wide delegation

  1. Jako upoważniony Super Admin otwórz Google Admin Console > Security > Access and data control > API controls.
  2. W Domain-wide delegation > Manage domain wide delegation > Add new wpisz Unique ID konta usługi jako Client ID, a nie identyfikator klienta internetowego OAuth.
  3. W OAuth scopes (comma-delimited) wpisz dwa wymagane zakresy uprawnień do odczytu:
https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly
  1. Jeśli również WebAdmin ma korzystać z uwierzytelniania Google, dodaj ten zakres:
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly
  1. Zapisz delegację przyciskiem Authorize i sprawdź identyfikator oraz pełną listę zakresów.

Adresy URL zakresów są stałymi identyfikatorami API, a nie wartościami przykładowymi. Jeśli włączono Multi-party approval, delegację musi zatwierdzić dodatkowy Super Admin. Zastosowanie zmian może potrwać do 24 godzin; w tym czasie nie twórz pochopnie drugiej delegacji z szerszymi uprawnieniami. Domain-wide delegation umożliwia dostęp w imieniu innych użytkowników w dzierżawie Workspace, dlatego mimo uprawnień tylko do odczytu jest zezwoleniem istotnym dla bezpieczeństwa. Wyznacz właściciela odpowiedzialnego za konto usługi, identyfikator klucza, delegowane konto administratora, cel i termin przeglądu.

Przygotuj osobne grupy administratorów firewalla

Na początek, dla przejrzystości, zaleca się mapowanie grup. W Google Admin Console > Directory > Groups utwórz grupę przeznaczoną wyłącznie dla administratorów firewalla i dodaj tylko administratorów uczestniczących w pilotażu. Na przykład grupę SFOS-NOC-ReadOnly można przypisać do wcześniej sprawdzonego profilu tylko do odczytu. Nazwa i adres grupy są wartościami właściwymi dla danej organizacji; zwykła grupa pracowników lub VPN nie otrzymuje uprawnień WebAdmin.

Alternatywnie w Account > Admin roles można przypisać niestandardowe lub wstępnie zdefiniowane role administratorów Google i użyć Roles w konfiguracji serwera na firewallu. Role niestandardowe przypisuje się za pomocą dokładnej nazwy roli; role wstępnie zdefiniowane wymagają specjalnej wartości IdP, a nie po prostu widocznej etykiety. Potwierdzony przykład to Groups admin → _GROUPS_ADMIN_ROLE. Role administratorów Google mogą jednocześnie przyznawać uprawnienia w Google Admin Console. Dlatego nie przydzielaj ich wyłącznie jako wygodnej etykiety dla firewalla; dedykowana grupa jest zwykle rozwiązaniem o węższym zakresie uprawnień.

Skonfiguruj serwer OIDC na firewallu

Klient, przekierowania i punkty końcowe

  1. Otwórz WebAdmin za pomocą planowanego FQDN i przejdź do Authentication > Servers > Add.
  2. Wybierz Server type: OpenID Connect, jednoznaczną Server name i IdP vendor: Google Workspace.
  3. Wpisz Client ID i Client secret klienta internetowego OAuth.
  4. W Redirect URIs wybierz Use firewall URL. Firewall używa nazwy hosta z bieżącego adresu URL WebAdmin. Alternatywnie wybierz Enter manually i wpisz własny, sprawdzony FQDN.
  5. Otwórz Show URLs i skopiuj pełne adresy URL dla Web admin console, Captive portal lub VPN portal and remote access, zależnie od faktycznie planowanych usług.
  6. Pozostaw automatycznie ustawioną Issuer URL https://accounts.google.com i użyj Discover/Reset endpoint URLs. Pola Authorization URL, Token URL, Logout URL, JWKS URL i User info URL są uzupełniane przez mechanizm Discovery, a nie na podstawie domysłów.

Tożsamość, grupa awaryjna i uprawnienia administratorów

W User attributes pola Display name i Username obsługują wartości name lub email; udokumentowana wartość domyślna w obu przypadkach to name. Pole Email address jest wstępnie ustawione na email. Podejmij decyzję przed pierwszym logowaniem pilotażowym: email może ułatwić przypisanie do jednoznacznego adresu logowania Workspace, ale musi być zgodne z istniejącymi tożsamościami na firewallu. Nie zmieniaj później wartości atrybutów przy okazji innych prac, ponieważ może to spowodować inne przypisania kont.

Przy korzystaniu wyłącznie z VPN lub Captive Portal pozostaw IdP authentication for firewall administrators wyłączone. Dla WebAdmin świadomie włącz tę opcję i utwórz każde przypisanie z IdP attribute, dokładną wartością IdP value i Device access profile. Wartości grup lub ról pobieraj z własnej konfiguracji Google, a nie zgaduj na podstawie przykładowej nazwy.

Firewall sprawdza reguły mapowania od góry do dołu i używa pierwszego pasującego profilu. Dlatego użytkownika należącego do kilku grup administratorów trzeba osobno przetestować. Bez pasującego przypisania administratora dana tożsamość nie otrzymuje dostępu do WebAdmin i może zostać utworzona jako zwykły użytkownik.

W Fallback group wybierz celowo ograniczoną grupę użytkowników. Jeśli grupa Google nie istnieje na firewallu, używana jest ta grupa awaryjna. Nawet jeśli serwer jest wybrany w Firewall authentication methods, ustawienie Default group nie zastępuje tego przypisania awaryjnego OIDC. Grupa VPN z szerokimi uprawnieniami nie jest bezpieczną grupą domyślną na taką sytuację.

Sprawdź konto usługi i ustaw jednakowe nazwy hostów

  1. W Service account credentials > Email address wpisz adres superadministratora Google Workspace przewidzianego do tego dostępu. W tym miejscu nie należy wpisywać adresu e-mail konta usługi.
  2. W JSON private key > Browse wybierz zabezpieczony plik klucza JSON dedykowanego konta usługi.
  3. Uruchom Test connection. Test sprawdza połączenie sieciowe i uprawnienia aplikacji. Nie potwierdza jeszcze poprawnego logowania użytkownika ani przypisania administratora.
  4. Zapisz przyciskiem Save.
  5. Przez Go to Admin and user settings ustaw w When redirecting users to the captive portal or other interactive pages identyczny FQDN portalu: Use the firewall’s configured hostname lub Use a different hostname, odpowiednio do własnej konfiguracji. Zapisz przyciskiem Apply.
  6. W Google Cloud Console > APIs & Services > Credentials otwórz klienta internetowego OAuth i w Authorized redirect URIs > Add URI wpisz każdy wcześniej skopiowany pełny adres URL wywołania zwrotnego. Zapisz przyciskiem Save i porównaj znak po znaku.

Udostępnij grupy, usługi i VPN

Zaimportuj grupy i przypisz polityki

W Authentication > Servers otwórz Assistant for importing groups serwera Google. Można zaimportować wszystkie grupy lub wybrać konkretne grupy według Display name i Mail. Na potrzeby pilotażu wybierz tylko grupy obejmujące wymaganych użytkowników. W kreatorze można przypisać Surfing quota, Access time, Network traffic i Traffic shaping wszystkim lub poszczególnym grupom.

Czas na firewallu i w Google musi być zsynchronizowany, w przeciwnym razie może się nie powieść już sam import grup. Po imporcie sprawdź nazwy grup i przewidziane polityki. Dla IPsec lub SSL VPN nowe grupy trzeba dodatkowo dodać do odpowiednich polityk VPN. Pomyślny import nie oznacza jeszcze uprawnień VPN.

Przełącz uwierzytelnianie dla poszczególnych usług

W Authentication > Services wybierz serwer Google tylko dla potrzebnych metod:

  • Administrator authentication methods: WebAdmin.
  • Firewall authentication methods: Captive Portal.
  • VPN portal authentication methods: VPN Portal.
  • VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: Remote Access IPsec; nazwa listy nie oznacza obsługi OIDC dla każdego wymienionego w niej starszego protokołu.
  • SSL VPN authentication methods: Remote Access SSL VPN.

Przeciągnij serwer na początek listy dla wybranej usługi i użyj Apply dla każdej usługi. Porównaj kolejność i lokalną metodę awaryjną z wcześniej udokumentowanym stanem; nie usuwaj przy okazji Local dla indywidualnych lokalnych kont administratorów. Niepotrzebne usługi pozostaw bez zmian.

Sophos Connect i dostępność

Google SSO używa portu VPN Portal również do komunikacji zdalnego dostępu. W tym zastosowaniu w Administration > Device access > Local service ACL trzeba zezwolić na dostęp do VPN Portal z WAN. Świadomie zaplanuj dozwolone źródła i faktycznie wymaganą dostępność; nie otwieraj w tym celu WebAdmin w WAN. Sposób ograniczania dostępu opisano w Device Access i Local Service ACL.

Przy użyciu pliku provisioning IPsec, SSL VPN i VPN Portal muszą korzystać z tego samego serwera Google. Wartość gateway odpowiada FQDN, za pomocą którego wygenerowano przekierowania. Bez pliku provisioning SSL VPN i VPN Portal również muszą używać tego samego serwera; IPsec może korzystać z innego serwera Google. Dlatego w istniejących plikach VPN nie należy bez sprawdzenia zmieniać wyłącznie jednego pola uwierzytelniania.

Po skonfigurowaniu lub zmianie konfiguracji Google użytkownicy Windows muszą ponownie zaimportować swój plik konfiguracji do Sophos Connect 2.4 lub nowszej wersji. Dopiero wtedy należy przetestować nowe połączenie. Na współdzielonych urządzeniach końcowych trzeba wymusić ponowne logowanie SSO dla kolejnych użytkowników; istniejąca sesja Google nie może niezauważenie zalogować następnej osoby.

Opcjonalnie: bezpieczne korzystanie z Captive Portal

Dla odpowiedniej reguły firewalla opartej na użytkownikach wymagane są Match known users i Use web authentication for unknown users. W Authentication > Web authentication > Captive portal behavior dla tego przebiegu obsługi portalu włącz Show web page after sign-in, wybierz In new browser window i wyłącz Use insecure HTTP instead of HTTPS. Zapisz ustawienia za pomocą Apply; OIDC nie obsługuje tego niezabezpieczonego trybu HTTP.

Użytkownicy pozostawiają okno Captive Portal otwarte, aby móc jawnie się wylogować. Brak aktywności ani zamknięcie karty nie kończą tutaj sesji Google SSO tak jak w przypadku innych metod portalu. Po wylogowaniu strona wylogowania Google pozostaje widoczna. Credential login z nazwą użytkownika i hasłem nie zastępuje tego procesu Google OIDC opartego na tokenach.

Przeprowadź odbiór logowania i uprawnień

Odbiór rozdziela połączenie, tożsamość i autoryzację. Dokumentuj wszystkie testy wraz z czasem, kontem, usługą, wersją klienta i oczekiwanym wynikiem, nie zapisując sekretów ani tokenów.

  1. Pomyślnie wykonaj Test connection i import wybranych grup. Następnie otwórz prywatne okno przeglądarki, używając przewidzianego FQDN.
  2. Zaloguj administratora pilotażowego przez Google i sprawdź oczekiwane wymaganie MFA. W Authentication > Users tożsamość, status administratora i przypisany profil muszą być poprawne.
  3. Przeprowadź test pozytywny wymaganych menu i test negatywny zablokowanego obszaru. Konto tylko do odczytu nie może zapisywać zmian. Zwykłe konto VPN nie może logować się do WebAdmin.
  4. Sprawdź konto pasujące do kilku reguł mapowania. Profil musi odpowiadać udokumentowanej pierwszej pasującej regule, a nie roli uznawanej za najsilniejszą.
  5. Zaloguj się osobno do VPN Portal i zestaw tunel IPsec lub SSL VPN z nowo zaimportowaną konfiguracją Sophos Connect. Zatwierdzony zasób wewnętrzny musi być dostępny; zasób, do którego nie udzielono dostępu, musi pozostać zablokowany.
  6. Wyloguj się i sprawdź ponownie w nowej sesji. Logowanie Google, dostęp do portalu i tunel VPN to odrębne kryteria powodzenia.
  7. Skoreluj zdarzenia WebAdmin w Log viewer > Admin oraz logowania Captive Portal, VPN Portal, IPsec i SSL VPN w Log viewer > Authentication. Do dalszej analizy w Advanced Shell dostępny jest plik oauth_sso_svc.log; nie zakłada się konieczności używania poleceń debugowania ani restartu.
  8. Ponownie sprawdź niezależny lokalny dostęp odzyskiwania, zanim przeniesiesz kolejnych użytkowników.

Konta administratorów są tworzone lub aktualizowane tylko przy pomyślnym logowaniu do WebAdmin. Logowanie do VPN lub Captive Portal nie synchronizuje roli administratora. Dlatego zmiany ról Google należy odbierać na podstawie nowego logowania do WebAdmin, a nie pomyślnie zestawionego tunelu.

Precyzyjnie diagnozuj błędy

Google zgłasza redirect_uri_mismatch

Porównaj właściwy pełny adres URL z Show URLs z Authorized redirect URIs faktycznie używanego klienta OAuth: schemat, FQDN, port i ścieżka muszą być dokładnie zgodne. Następnie sprawdź, czy przeglądarka używa tej samej nazwy hosta i czy automatyczne przekierowanie portalu wskazuje tę nazwę. Po poprawieniu konfiguracji przetestuj nowe logowanie; ani przekierowania z symbolami wieloznacznymi, ani przejście na adres IP nie są rozwiązaniem.

Test connection lub import grup kończy się niepowodzeniem

Najpierw sprawdź czas systemowy i połączenie sieciowe. Następnie zweryfikuj Admin SDK API, prawidłowy plik klucza JSON, właściwe delegowane konto Super Admin oraz Domain-wide delegation z numerycznym identyfikatorem konta usługi i wymaganymi zakresami. Jeśli brakuje grup, dodatkowo sprawdź filtr importu Display name/Mail. Błędu nie rozwiązuje się przez przyznanie ogólnych uprawnień Cloud Owner ani dodatkowych zakresów zapisu.

Logowanie Google działa, ale WebAdmin odmawia dostępu

Sprawdź członkostwo w grupie lub przypisanie roli w Google, IdP authentication for firewall administrators, dokładną wartość IdP value, kolejność mapowania i lokalny Device access profile. Następnie wykonaj nowe logowanie do WebAdmin i sprawdź Log viewer > Admin. Wcześniejsze logowanie VPN nie potwierdza ani mapowania, ani aktualizacji konta administratora.

Portal działa, ale tunel lub zasób wewnętrzny nie

Sprawdź wersję Windows i Sophos Connect, ponownie zaimportowany plik konfiguracji, dostępność VPN Portal i przypisanie serwera dla każdej usługi. Następnie sprawdź członkostwo grup w politykach VPN oraz reguły dla zasobu docelowego. Log viewer > Authentication pokazuje logowanie; sam wpis o pomyślnym uwierzytelnieniu nie potwierdza, że ruch danych jest dozwolony.

Context-Aware Access lub ponowne logowanie działa inaczej niż oczekiwano

Warunki Google CAA oparte na urządzeniu wymagają obsługiwanego procesu w przeglądarce i faktycznie dostępnych danych weryfikacji urządzenia końcowego. W opisanej ścieżce testowej używa się Google Chrome z Endpoint Verification. Pomyślnego logowania Sophos Connect nie należy traktować jako dowodu, że sprawdzono każdy warunek CAA oparty na urządzeniu.

CAA jest sprawdzane podczas uwierzytelniania i nie kończy już aktywnej sesji firewalla. Również interwał ponownego uwierzytelniania Google nie wymusza ponownego logowania aktywnej sesji VPN firewalla. Sprawdź nowe uwierzytelnianie po kontrolowanym wylogowaniu lub rozłączeniu; istniejące sesje wymagają osobnej obsługi podczas odbierania dostępu użytkownikowi.

Eksploatacja, odbieranie dostępu i wycofanie zmian

Zmianę grup lub ról sprawdzaj przez nowe logowanie oraz test pozytywny i negatywny. Przy usuwaniu osoby z administracji sama zmiana roli Google nie wystarcza: SFOS nie przekształca automatycznie istniejącego konta administratora z powrotem w zwykłego użytkownika. Po sprawdzeniu zależności, przy użyciu innego działającego konta administratora, trzeba usunąć dane konto administratora z firewalla. Przy następnym zwykłym logowaniu firewall może utworzyć użytkownika ponownie. Aktywne sesje WebAdmin i VPN kontroluj i kończ osobno; odebranie członkostwa w grupie nie jest potwierdzonym sposobem natychmiastowego unieważnienia sesji.

Dla sekretu OAuth i klucza konta usługi określ właściciela, bezpieczne miejsce przechowywania, przeglądy i rotację. Podczas planowanej rotacji stary klucz pozostaje dostępny tylko tak długo, jak wymaga tego udokumentowana ścieżka wycofania zmian. Najpierw sprawdź nowe dane uwierzytelniające za pomocą Test connection, pobierania grup i nowego logowania, a dopiero potem unieważnij stare dane. Natomiast w przypadku kompromitacji postępuj zgodnie z własnym procesem obsługi incydentów, nie przedłużając ważności danych dla wygodnego wycofania zmian.

Jeśli pilotaż się nie powiedzie, z otwartej sesji administratora z pełnymi uprawnieniami lub przez lokalny dostęp odzyskiwania przywróć dokładnie zapisane wcześniejsze przypisania usług i kolejność serwerów. Przywróć również poprzedni stan zmienionych nazw hostów portali, Device Access, polityk grup/VPN i mapowań administratorów. Następnie przetestuj lokalne logowanie administratora i dotychczasową ścieżkę VPN w nowych sesjach.

Dodatkowo, korzystając z niezależnie dostępnej ścieżki dostępu administratora z pełnymi uprawnieniami, porównaj każde objęte zmianą konto w Authentication > Users ze spisem poszczególnych kont. W przypadku kont istniejących przed pilotażem jawnie przywróć dotychczasowy User type, przypisany Profile i status konta; jeśli wymaga to usunięcia i ponownego utworzenia konta, najpierw sprawdź wszystkie zależności i zabezpiecz dotychczasowe przypisania. Usuń wyłącznie obiekty administratorów i użytkowników utworzone podczas pilotażu, po sprawdzeniu ich zależności dotyczących grup, VPN, polityk i innych elementów. Przywrócenie poprzedniego mapowania serwera lub usunięcie roli Google nie zastępuje tego uporządkowania kont ani nie kończy istniejącej sesji. Dlatego aktywne sesje WebAdmin, portali i VPN sprawdzaj i kończ osobno. Na koniec w nowych sesjach potwierdź działanie dotychczasowego lokalnego dostępu administratora i dostępu VPN oraz odmowę dostępu tożsamości pilotażowej, która nie ma już uprawnień; w przypadku przywróconych kont istniejących przed pilotażem sprawdź zachowanie pierwotnych uprawnień i odmowę dostępu w zakresie dodatkowych uprawnień przyznanych wyłącznie podczas pilotażu.

Dopiero gdy wycofanie zmian działa i żadne inne usługi nie są zależne od tych elementów, usuń w kontrolowany sposób URI przekierowania, zezwolenia delegacji i dane uwierzytelniające utworzone wyłącznie na potrzeby pilotażu. Nie usuwaj współdzielonych klientów ani kont usług bez sprawdzenia zależności. Pełną kopię zapasową konfiguracji przywracaj tylko w zatwierdzonym oknie odzyskiwania, ponieważ może ona cofnąć również niezależne zmiany na firewallu.