Obsługa Sophos Central Integration Credential Manager
Integration Credential Manager zarządza danymi dostępowymi zewnętrznych produktów, których Sophos Central używa do integracji. Przykładami są tokeny API lub konta dla Data Ingestion i Response Actions.
Nie należy go mylić z API Credentials. API Credentials umożliwiają zewnętrznej aplikacji dostęp do Sophos Central. W Credential Manager Sophos Central przechowuje natomiast dane dostępowe służące do uzyskania dostępu do produktu zewnętrznego.
Kiedy używać Credential Manager
Credential tworzy się w tym miejscu, gdy obsługiwana integracja Sophos potrzebuje dostępu do produktu zewnętrznego, a odpowiedni typ Credential jest dostępny w Central. Manager może ponownie wykorzystywać dane dostępowe w kilku podobnych integracjach i pokazuje Health, ostatnie użycie, uprawnienia oraz funkcje integracji mające dostęp.
Nie można w nim przechowywać dowolnego typu sekretu. Dla nieobsługiwanych integracji właściwym miejscem pozostaje centralny firmowy magazyn sekretów.
Wcześniejsze planowanie uprawnień
Przed utworzeniem określa się:
- produkt zewnętrzny i instancję docelową,
- dozwolone działania Read lub Write,
- funkcje Sophos z dostępem do Credential,
- właściciela technicznego i kontakt awaryjny,
- datę wygaśnięcia i procedurę rotacji,
- limit nieaktywności,
- test i wycofanie.
Dostęp Write przyznaje się tylko wtedy, gdy Response Actions są rzeczywiście potrzebne i zostały również ograniczone w produkcie zewnętrznym. Integracja, która tylko odczytuje telemetrię, nie otrzymuje uprawnień do zmian.
Tworzenie Credential
Ścieżka prowadzi przez Global Settings > Access Control > Integration Credential Manager. Przycisk Add otwiera stronę Type, gdzie w polu Credential Type wybiera się obsługiwany typ, na przykład Okta API Token, i potwierdza przez Next.
Na stronie Details wprowadza się nazwę i opis, uprawnienie Read lub Write, a w sekcji Integrations with Access wybiera wyłącznie potrzebne funkcje Sophos, na przykład Data Ingestion lub Response Action. Opcjonalnie określa się Inactivity limit i, jeśli dany typ je obsługuje, Expiration date. Po prawej stronie, po ocenie skutków dla bezpieczeństwa, potwierdza się informację Vendor and Product documentation and disclaimer.
Jeśli pole Disclaimer nie zostanie potwierdzone na stronie Details, Central ponownie umożliwi potwierdzenie na kolejnej stronie. Bez świadomego potwierdzenia Credential nie zostanie udostępniony produkcyjnie. Dodatkowe okno nie zastępuje wewnętrznej kontroli dostępu do produktu zewnętrznego.
Na stronie Credential wprowadza się wartości wymagane przez produkt zewnętrzny, w przykładzie Okta są to URL i API Token. Wartości pochodzą z właściwej konfiguracji produktu, a nie z obcego przykładu. Save tworzy Credential. Następnie sprawdza się docelową integrację, Health i Usage oraz wykonuje test działania integracji. Alternatywnie obsługiwana integracja może podczas konfiguracji utworzyć Credential z uprawnieniami domyślnymi, które później zawęża się w Manager.
Również samo konto zewnętrzne otrzymuje zasadę najmniejszych uprawnień. Wąskie ustawienie w Central nie kompensuje nadmiernie uprzywilejowanego konta w produkcie zewnętrznym.
Monitorowanie Health i użycia
Widok listy pokazuje:
- Healthy, Partially healthy lub Unhealthy,
- myślnik zamiast symbolu Health oraz tekst Awaiting usage po najechaniu, jeśli Credential nigdy nie został użyty,
- Last accessed z ostatnim użyciem i możliwymi ostrzeżeniami o nieaktywności,
- Used by z funkcjami integracji, które mogą używać Credential,
- Credential type,
- ostrzeżenia przed Suspend lub Purge.
Zielony stan Credential potwierdza tylko poprawne działanie techniczne. Nie dowodzi, że dane napływają w całości ani że Response Action działa prawidłowo pod względem biznesowym. Dlatego sprawdza się zdarzenie testowe, znacznik czasu i wynik w systemie docelowym.
Strona szczegółów pokazuje też Vendor, Vendor Identifier, Permissions i Integration Access. Usage pokazuje liczbę Requests i czas ostatniego żądania. Logs zawiera tylko 250 najnowszych zdarzeń i można go filtrować według stanu, typu integracji i okresu. Dlatego istotne błędy przenosi się przed nadpisaniem do monitoringu operacyjnego lub zgłoszenia do pomocy technicznej.
Edycja, blokowanie i usuwanie Credential
Aby edytować Credential, w Global Settings > Access Control > Integration Credential Manager otwiera się jego nazwę i wybiera Actions > Edit. Central pokazuje te same strony co podczas tworzenia. Na Details można zmienić nazwę, opis, uprawnienia, dostęp integracji, limit nieaktywności i ewentualnie termin wygaśnięcia. Na Credential zastępuje się właściwe wartości dostawcy zewnętrznego. Po zapisaniu testuje się Health, Usage i działanie. Used by oraz Integration Access pokazują funkcje integracji, lecz nie zastępują własnego spisu konkretnych instancji, które trzeba sprawdzić przed zmianą.
Ręczne zablokowanie wykonuje się po wybraniu Credential przez Actions > Suspend i ponownym potwierdzeniu ostrzeżenia o użyciu. Jest ono przydatne przy podejrzeniu przejęcia lub kontrolowanej diagnostyce, ale zatrzymuje użycie danych i reakcji przez wszystkie zależne integracje. Actions > Unsuspend ponownie aktywuje Credential i resetuje okres nieaktywności do sześciu miesięcy albo wartości skonfigurowanej indywidualnie.
W przypadku niepotrzebnych Credentials najpierw przełącza się wszystkie zależności. Następnie wybiera się Credential, Actions > Delete i potwierdza ostrzeżenie. Usunięcie nie unieważnia automatycznie powiązanego konta ani tokenu w produkcie zewnętrznym. Dostęp trzeba usunąć lub rotować także tam.
Nieaktywność, Suspend i Purge
Domyślnie Credential zostaje zawieszony po sześciu miesiącach, czyli 180 dniach nieaktywności, a po roku trwale wyczyszczony (Purge). W Actions > Edit > Inactivity limit można na przykład wybrać Suspend po roku i Purge po dwóch latach. Zmiana natychmiast uruchamia nowy okres i usuwa istniejące ostrzeżenia.
Przed wydłużeniem limitu nieaktywności ustala się, czy integracja jest nadal potrzebna. Rzadko uruchamiana funkcja awaryjna wymaga udokumentowanego testu, a nie nieograniczonego sekretu.
Central ostrzega 90 dni przed Suspend. Przed Purge wysyła ostrzeżenia 90, 60, 30 i 7 dni wcześniej. Wymaga to reguł alertów e-mail dla Credential Manager. Super Admin otwiera Global Settings > Platform > Notification Settings > Configure Email Alerts i sprawdza odbiorców, częstotliwość oraz typy alertów. Włączenie pierwszej Custom Rule wyłącza dotychczasowe ustawienia odbiorców, dlatego potrzebnych administratorów i listy dystrybucyjne należy jawnie dodać do właściwej reguły.
Opcja Actions > Reset inactivity limit resetuje pozostały okres nieaktywności do sześciu miesięcy lub wartości skonfigurowanej. Actions > Unsuspend ponownie aktywuje zablokowany Credential i również resetuje ten okres. Wcześniej sprawdza się zewnętrzny sekret, uprawnienia i zależne integracje. Unsuspend nie naprawia wygasłego ani unieważnionego tokenu.
Ręczny Suspend zatrzymuje przesyłanie danych we wszystkich korzystających integracjach. Purge lub usunięcie może trwale przerwać kilka integracji, jeśli Credential jest używany wielokrotnie.
Kontrolowana wymiana wartości Credential
Credential Manager nie rotuje sam sekretu w produkcie zewnętrznym. Jeśli dostawca obsługuje wymianę, jego udokumentowaną procedurę koordynuje się z aktualizacją w Central w oknie serwisowym:
- Spisać konkretne instancje, Used by, Integration Access i ostatnie użycie.
- Przygotować wartość zastępczą zgodnie z dokumentacją produktu zewnętrznego.
- Zaktualizować Credential w Central przez Actions > Edit.
- Sprawdzić Health, Usage i objęte zmianą funkcje integracji.
- Unieważnić starą wartość dopiero po udanej kontroli i zgodnie z procedurą dostawcy.
- Sprawdzić dzienniki audytu i integracji.
Tylko produkt zewnętrzny określa, czy stara i nowa wartość mogą działać równolegle. Jeśli nie jest to udokumentowane, nie obiecuje się bezprzerwowej zmiany, lecz planuje i monitoruje możliwą przerwę.
Typowe problemy
Stan pozostaje Awaiting usage
Credential nie jest przypisany do aktywnej integracji, integracja nie wykonała jeszcze przebiegu albo wybrano niewłaściwy zestaw Credential. Należy sprawdzić przypisanie i zdarzenie testowe.
Credential jest Healthy, ale brakuje danych
Należy sprawdzić okres, źródło danych, integrację, filtry i uprawnienia w produkcie zewnętrznym. Health nie potwierdza każdej oczekiwanej ilości danych.
Zmiana przerywa kilka integracji
Credential jest używany ponownie. Used by wstępnie pokazuje zakres wpływu; dodatkowo trzeba ustalić we własnym spisie wszystkie konkretne instancje i przetestować je wspólnie.
Delete ostrzega o możliwym użyciu
Ostrzeżenia nie należy pomijać. Najpierw trzeba przełączyć lub usunąć wszystkie powiązane integracje, a następnie skasować Credential.