Bezpieczne zarządzanie danymi uwierzytelniającymi API Sophos Central
Sophos Central można automatyzować przez API oraz integrować z platformami SIEM, RMM, raportowania lub ubezpieczeniowymi. Nie używa się do tego osobistych kont administratorów, lecz osobnych API Credentials, składających się z Client ID i Client Secret.
Te dane uwierzytelniające są tożsamościami maszynowymi. Osoba posiadająca Secret może wykonywać wszystkie operacje API dozwolone przez przypisaną rolę Service Principal. Secret należy więc traktować jak uprzywilejowane hasło i nie wolno umieszczać go w skryptach, zgłoszeniach, wiadomościach e-mail ani repozytoriach Git.
Różnica między API Credentials a Integration Credential Manager
W sekcji Global Settings > Access Control znajdują się dwa podobnie brzmiące obszary:
| Obszar | Zadanie |
|---|---|
| API Credentials | Tożsamość techniczna, za pomocą której aplikacja wywołuje API Sophos Central |
| Integration Credential Manager | Dane uwierzytelniające produktów zewnętrznych, których Sophos używa w integracjach takich jak Data Ingestion lub Response Actions |
Dla własnego skryptu, zapytania SIEM lub klienta API tworzy się API Credentials. Dane uwierzytelniające produktu zewnętrznego, z których ma korzystać samo Sophos Central, należą natomiast do Integration Credential Manager.
Wymagania i odpowiedzialność
Tylko Super Admin może tworzyć i zarządzać API Credentials. Później aplikacja uwierzytelnia się niezależnie od tego osobistego administratora. Jeśli administrator zostanie dezaktywowany, tożsamość techniczna pozostaje aktywna do czasu wygaśnięcia lub usunięcia.
Przed utworzeniem dokumentuje się cel, właściciela, system docelowy, wymaganą rolę, termin wygaśnięcia i kontakt awaryjny. Dla każdej aplikacji i środowiska używa się osobnego Credential. Wspólny Secret dla skryptu kopii zapasowej, SIEM i zewnętrznego usługodawcy uniemożliwia selektywne zablokowanie i utrudnia analizę przyczyny.
Wybór właściwej roli Service Principal
Sophos udostępnia kilka ról:
- Service Principal Read-Only odczytuje dane Tenanta, ale nie może ich zmieniać ani wykonywać zapytań Live Discover.
- Service Principal Management może odczytywać, tworzyć, zmieniać i usuwać użytkowników oraz grupy użytkowników, odczytywać i edytować Alerts, odczytywać Endpoints i uruchamiać działania, takie jak skanowanie, a także wyświetlać i zmieniać globalne ustawienia Endpoint Protection. Ponadto rola zarządza administratorami, rolami i Security Policies, ale nie ma dostępu do zapytań Live Discover.
- Service Principal Forensics tworzy, uruchamia i usuwa zapytania Live Discover.
- Service Principal Active Directory Sync jest przeznaczona wyłącznie do synchronizacji AD i nie może wykonywać innych zadań API.
- Service Principal Firewall ogranicza tożsamość do zarządzania Firewallem i nie pozwala wykonywać poza tym innych zadań API Central.
- Service Principal Super Admin ma szerokie uprawnienia do odczytu, zapisu i usuwania oraz dostęp do zapytań.
Wybór zawsze zaczyna się od najmniejszej roli. Integracja raportowa lub ubezpieczeniowa otrzymuje Read-Only. AD Sync otrzymuje rolę przeznaczoną specjalnie do tego celu. Super Admin stosuje się tylko wtedy, gdy udokumentowane punkty końcowe API rzeczywiście wymagają szerokich uprawnień do zapisu i nie działa żadna węższa rola.
Tworzenie Credential
Ścieżka to Global Settings > Access Control > API Credentials. Przy pierwszym otwarciu należy zaakceptować warunki użytkowania.
- Otworzyć Add Credential.
- Wprowadzić jednoznaczną nazwę i opis zawierający aplikację, środowisko i właściciela.
- Wybrać minimalną wymaganą rolę Service Principal.
- Utworzyć Credential i natychmiast przejąć Client ID oraz Client Secret.
- Zapisać Secret w firmowym Secret Store i wyczyścić tymczasowy schowek.
Client Secret jest wyświetlany tylko raz. Później nie można go ponownie wyświetlić. Jeśli zostanie utracony, nie odzyskuje się istniejącego Secretu, lecz tworzy nowe Credential, a stare usuwa po udanej migracji.
Kontrolowany test uwierzytelniania
Pierwszy test nie powinien polegać na operacji zapisu w środowisku produkcyjnym. Najpierw pobiera się OAuth Access Token z punktu końcowego Sophos Identity. Następnie punkt końcowy whoami zwraca Tenant ID, API Host i typ danych konta. Dopiero wtedy wykonuje się nieszkodliwe wywołanie odczytu do API Host zwróconego dla danego Tenanta.
API Host nie jest kopiowany z przykładu. Sophos obsługuje wiele regionów danych, dlatego trzeba użyć adresu URL zwróconego przez whoami. Tenant ID i Organization ID również nie są zamienne.
W ramach testu dokumentuje się co najmniej następujące przypadki:
- Uwierzytelnianie nową tożsamością działa.
- Zwracany jest oczekiwany Tenant.
- Dozwolone operacje odczytu działają.
- Niedozwolona operacja zostaje odrzucona kodem
403 Forbidden. - Audit Logs lub protokoły integracji pokazują test w sposób możliwy do prześledzenia.
Zarządzanie wygaśnięciem i rotacją
Sophos nie wysyła ostrzeżenia o wygaśnięciu API Credential. Po wygaśnięciu nie można go już użyć do uwierzytelniania i zostaje automatycznie usunięte z Central. Monitoring musi więc odbywać się poza Central.
Prawidłowa rotacja wykorzystuje krótkie nakładanie się okresów ważności:
- Utworzyć nowe Credential z identyczną lub węższą rolą.
- Przełączyć aplikację na Client ID i Secret nowego Credential.
- Przetestować uwierzytelnianie i działanie merytoryczne.
- Usunąć stare Credential.
- Sprawdzić zmianę w Audit Log, rejestrze sekretów i dokumentacji operacyjnej.
Stare Credential nie pozostaje zapobiegawczo aktywne przez wiele miesięcy. Jeśli aplikacja obsługuje tylko jeden zestaw sekretów, planuje się okno serwisowe.
Zastępowanie starych tokenów API SIEM
API Token Management to wcześniejsza metoda uwierzytelniania dla SIEM Integration API. Sophos nie wydaje już nowych tokenów i nie przedłuża ważności istniejących. Istniejące tokeny działają tylko do wygaśnięcia.
Integracji, która nadal ich używa, nie pozostawia się więc do ostatniego dnia. Należy zinwentaryzować token, system docelowy, datę wygaśnięcia i używane punkty końcowe, utworzyć odpowiednie API Credential, przełączyć aplikację i sprawdzić pełny przepływ danych. Stary token usuwa się dopiero po udanej kontroli równoległej.
Przejście z Legacy Token na API Credentials nie jest zwykłą zmianą nazwy. Integracja musi obsługiwać uwierzytelnianie OAuth, whoami, Regional Host i model ról. Dlatego SIEM Connector konfiguruje się na podstawie aktualnej instrukcji producenta, a nie starego przykładu z tokenem.
Zewnętrzni usługodawcy i dostęp stron trzecich
Dla podmiotu zewnętrznego tworzy się osobną tożsamość Service Principal Read-Only, jeśli wystarczają prawa odczytu. Client ID i Secret przekazuje się oddzielnym, szyfrowanym kanałem. Dostęp otrzymuje udokumentowaną datę końcową i jest usuwany po zakończeniu projektu.
Taki dostęp strony trzeciej może przez API odczytywać w szczególności Alerts and Events, wyniki Account Health Check, szczegóły urządzeń i konfiguracje Policy. Read-Only uniemożliwia dodawanie, zmienianie i usuwanie w Central, ale nie ogranicza automatycznie zakresu danych, które zewnętrzna platforma rzeczywiście pobiera lub przechowuje. Przed udzieleniem dostępu należy więc umownie ustalić zakres danych, cel użycia, miejsce przechowywania, retencję i usuwanie.
Tworzenie odbywa się standardową ścieżką Global Settings > Access Control > API Credentials > Add Credential. Przy pierwszym otwarciu potwierdza się warunki użytkowania i ochrony danych, wybiera rolę Service Principal Read-Only, a następnie natychmiast bezpiecznie przejmuje Client ID oraz widoczny tylko raz Client Secret. Dane przekazuje się zatwierdzonym szyfrowanym kanałem, na przykład portalem HTTPS dostawcy, a nie wiadomością e-mail ani tekstem zgłoszenia.
API Host nie jest kopiowany ze statycznej tabeli regionów. Aplikacja ustala za pomocą whoami API Host właściwy dokładnie dla tego Tenanta. Dzięki temu dokumentacja integracji pozostaje poprawna nawet wtedy, gdy Sophos zmieni regiony lub punkty końcowe. Gdy dostawca zewnętrzny nie potrzebuje już dostępu, Credential zostaje usunięte, co natychmiast odbiera uprawnienie API.
Eksport osobistego konta Super Admin, wspólna tożsamość API dla wielu klientów ani Secret w zgłoszeniu do pomocy technicznej nie są dopuszczalne. Usługodawca musi ponadto ujawnić, gdzie przechowuje Secret, jak go chroni i kiedy go usuwa.
Precyzyjna diagnostyka błędów
401 Unauthorized
Najczęściej błędne są Client ID, Secret, Token Endpoint lub OAuth Request. Ten błąd powoduje również wygasłe i już usunięte Credential. Najpierw sprawdza się, czy Credential nadal istnieje w Central i czy aplikacja rzeczywiście używa najnowszego zestawu sekretów.
403 Forbidden
Uwierzytelnianie powiodło się, ale rola nie pozwala na tę operację. Zamiast od razu nadawać Super Admin, należy przypisać wymagany punkt końcowy API do właściwej roli Service Principal.
Właściwy token, niewłaściwy region danych
Sam Access Token nie określa merytorycznego API Host. Aplikacja musi korzystać z Regional Host zwróconego przez whoami. Host innego regionu wpisany na stałe powoduje błędy albo zapytania do niewłaściwej granicy platformy.
Integracja przestaje działać bez ostrzeżenia
Jeśli Central nie pokazuje otwartego Alert, sprawdza się datę wygaśnięcia, ostatnie udane wywołanie API i wersję Secret w systemie docelowym. Monitorowanie wygaśnięcia należy do zewnętrznego monitoringu.
Regularna kontrola
Co najmniej raz na kwartał sprawdza się nazwę, właściciela, rolę, ostatnie użycie, wygaśnięcie i system docelowy każdego Credential. Tożsamości, których nie można przypisać lub które nie są używane, należy usunąć. Po podejrzeniu wycieku Secret Credential natychmiast się blokuje, zastępuje nowym i analizuje Audit Log pod kątem nietypowych działań.
Osobiste prawa administratorów kontroluje się oddzielnie zgodnie z artykułem Prawidłowe przypisywanie ról administracyjnych Sophos Central. API Credentials nie zastępują MFA ani osobistego, identyfikowalnego dostępu administratora.