Sophos Central API-Zugangsdaten sicher verwalten
Sophos Central lässt sich über APIs automatisieren und an SIEM-, RMM-, Reporting- oder Versicherungsplattformen anbinden. Dafür werden keine persönlichen Administratorkonten verwendet, sondern eigene API Credentials aus Client ID und Client Secret.
Diese Zugangsdaten sind Maschinenidentitäten. Wer ein Secret besitzt, kann alle API-Aktionen ausführen, welche die zugewiesene Service-Principal-Rolle erlaubt. Ein Secret gehört deshalb wie ein privilegiertes Kennwort behandelt und darf weder in Skripten, Tickets, E-Mails noch in Git-Repositories landen.
API Credentials und Integration Credential Manager unterscheiden
Unter Global Settings > Access Control gibt es zwei ähnlich klingende Bereiche:
| Bereich | Aufgabe |
|---|---|
| API Credentials | Technische Identität, mit der eine Anwendung die Sophos-Central-APIs aufruft |
| Integration Credential Manager | Zugangsdaten fremder Produkte, die Sophos für Integrationen wie Data Ingestion oder Response Actions verwendet |
Für ein eigenes Skript, eine SIEM-Abfrage oder einen API-Client werden API Credentials erstellt. Zugangsdaten eines Drittprodukts, die Sophos Central selbst benutzen soll, gehören dagegen in den Integration Credential Manager.
Voraussetzungen und Verantwortlichkeit
Nur ein Super Admin kann API Credentials erstellen und verwalten. Die spätere Anwendung authentifiziert sich unabhängig von diesem persönlichen Admin. Wird der Admin deaktiviert, bleibt die technische Identität bestehen, bis sie abläuft oder gelöscht wird.
Vor der Erstellung werden Zweck, Eigentümer, Zielsystem, benötigte Rolle, Ablauftermin und Notfallkontakt dokumentiert. Pro Anwendung und Umgebung wird ein eigenes Credential verwendet. Ein gemeinsames Secret für Backup-Skript, SIEM und externe Dienstleister verhindert eine gezielte Sperrung und erschwert die Ursachenanalyse.
Passende Service-Principal-Rolle wählen
Sophos stellt mehrere Rollen bereit:
- Service Principal Read-Only liest Tenant-Daten, darf sie aber nicht verändern und keine Live-Discover-Abfragen ausführen.
- Service Principal Management kann Benutzer und Benutzergruppen abfragen, erstellen, ändern und löschen, Alerts abfragen und bearbeiten, Endpoints abfragen und Aktionen wie einen Scan auslösen sowie globale Endpoint-Protection-Einstellungen ansehen und ändern. Zusätzlich verwaltet die Rolle Administratoren, Rollen und Security Policies, hat aber keinen Live-Discover-Query-Zugriff.
- Service Principal Forensics erstellt, startet und löscht Live-Discover-Abfragen.
- Service Principal Active Directory Sync ist ausschliesslich für die AD-Synchronisation vorgesehen und darf keine anderen API-Aufgaben ausführen.
- Service Principal Firewall beschränkt die Identität auf die Firewall-Verwaltung und darf ausserhalb davon keine Central-API-Aufgaben ausführen.
- Service Principal Super Admin besitzt umfassende Lese-, Schreib- und Löschrechte sowie Query-Zugriff.
Die Auswahl beginnt immer bei der kleinsten Rolle. Eine Reporting- oder Cyber-Versicherungs-Integration erhält Read-Only. AD Sync erhält die eigens dafür vorgesehene Rolle. Super Admin wird nur eingesetzt, wenn dokumentierte API-Endpunkte tatsächlich umfassende Schreibrechte benötigen und keine engere Rolle funktioniert.
Credential erstellen
Der Pfad lautet Global Settings > Access Control > API Credentials. Beim ersten Aufruf müssen die Nutzungsbedingungen bestätigt werden.
- Add Credential öffnen.
- Einen eindeutigen Namen und eine Beschreibung mit Anwendung, Umgebung und Eigentümer erfassen.
- Die minimal benötigte Service-Principal-Rolle auswählen.
- Credential erstellen und Client ID sowie Client Secret unmittelbar übernehmen.
- Secret in einem Unternehmens-Secret-Store ablegen und den temporären Zwischenspeicher leeren.
Das Client Secret wird nur einmal angezeigt. Es lässt sich später nicht erneut einblenden. Ist es verloren, wird kein bestehendes Secret wiederhergestellt, sondern ein neues Credential erstellt und das alte nach erfolgreicher Umstellung gelöscht.
Authentifizierung kontrolliert testen
Der erste Test besteht nicht aus einer produktiven Schreibaktion. Zuerst wird über den Sophos-Identity-Endpunkt ein OAuth-Access-Token bezogen. Danach liefert der whoami-Endpunkt Tenant-ID, API-Host und Datentyp des Kontos. Erst dann wird ein ungefährlicher Leseaufruf gegen den für den Tenant gelieferten API-Host ausgeführt.
Ein API-Host wird nicht aus einem Beispiel kopiert. Sophos betreibt mehrere Datenregionen, deshalb muss die von whoami gelieferte URL verwendet werden. Auch Tenant-ID und Organisation-ID sind nicht austauschbar.
Für den Test werden mindestens folgende Fälle dokumentiert:
- Authentifizierung mit der neuen Identität funktioniert.
- Der erwartete Tenant wird zurückgegeben.
- Erlaubte Leseoperationen funktionieren.
- Eine nicht erlaubte Operation wird mit
403 Forbiddenabgewiesen. - Audit Logs oder Integrationsprotokolle zeigen den Test nachvollziehbar.
Ablauf und Rotation betreiben
Sophos sendet keine Warnung, wenn ein API Credential abläuft. Nach dem Ablauf kann es nicht mehr zur Authentifizierung verwendet werden und wird automatisch aus Central entfernt. Monitoring muss daher ausserhalb von Central stattfinden.
Ein sauberer Rotationsablauf arbeitet mit kurzer Überlappung:
- Neues Credential mit identischer oder engerer Rolle erstellen.
- Anwendung auf Client ID und Secret des neuen Credentials umstellen.
- Authentifizierung und fachliche Funktion testen.
- Altes Credential löschen.
- Änderung in Audit Log, Secret-Register und Betriebsdokumentation prüfen.
Das alte Credential bleibt nicht vorsorglich monatelang aktiv. Wenn eine Anwendung nur einen Secret-Satz unterstützt, wird ein Wartungsfenster geplant.
Alte SIEM-API-Tokens ablösen
API Token Management ist die frühere Authentifizierung für die SIEM Integration API. Sophos stellt dort keine neuen Tokens mehr aus und verlängert bestehende Laufzeiten nicht mehr. Vorhandene Tokens funktionieren nur bis zu ihrem Ablauf.
Eine noch damit arbeitende Integration wird deshalb nicht bis zum letzten Tag belassen. Man inventarisiert Token, Zielsystem, Ablaufdatum und verwendete Endpunkte, erstellt ein passendes API Credential, stellt die Anwendung um und prüft den vollständigen Datenfluss. Erst nach erfolgreicher Parallelkontrolle wird der alte Token entfernt.
Der Wechsel von einem Legacy-Token auf API Credentials ist keine reine Umbenennung. OAuth-Authentifizierung, whoami, Regional-Host und Rollenmodell müssen von der Integration unterstützt werden. Ein SIEM-Connector wird daher anhand seiner aktuellen Herstelleranleitung und nicht mit einem alten Token-Beispiel konfiguriert.
Externe Dienstleister und Drittzugriff
Für eine externe Stelle wird eine eigene Service Principal Read-Only-Identität erstellt, sofern reine Leserechte genügen. Client ID und Secret werden über einen getrennten, verschlüsselten Kanal übertragen. Der Zugriff erhält einen festgehaltenen Endtermin und wird nach Projektende gelöscht.
Ein solcher Drittzugriff kann über die API insbesondere Alerts und Events, Ergebnisse des Account Health Check, Gerätedetails und Policy-Konfigurationen lesen. Read-Only verhindert das Hinzufügen, Ändern und Löschen in Central, begrenzt aber nicht automatisch, welche der lesbaren Daten die Drittplattform tatsächlich abruft oder speichert. Vor der Freigabe werden daher Datenumfang, Verwendungszweck, Speicherort, Aufbewahrung und Löschung vertraglich geklärt.
Die Erstellung folgt dem normalen Pfad Global Settings > Access Control > API Credentials > Add Credential. Beim ersten Aufruf werden die Nutzungs- und Datenschutzbedingungen bestätigt, als Rolle wird Service Principal Read-Only gewählt und Client ID sowie das nur einmal sichtbare Client Secret werden unmittelbar sicher übernommen. Die Übertragung erfolgt über einen freigegebenen verschlüsselten Kanal, beispielsweise das HTTPS-Portal des Anbieters, nicht per E-Mail oder Tickettext.
Der API-Host wird nicht aus einer statischen Regionaltabelle kopiert. Die Anwendung ermittelt über whoami den für genau diesen Tenant gültigen API-Host. Damit bleibt die Integration auch dann korrekt dokumentiert, wenn Sophos Regionen oder Endpunkte ändert. Sobald der Drittanbieter keinen Zugriff mehr benötigt, wird das Credential gelöscht; damit ist die API-Berechtigung unmittelbar widerrufen.
Ein Export des persönlichen Super-Admin-Kontos, eine gemeinsame API-Identität für mehrere Kunden oder ein Secret im Supportticket ist nicht vertretbar. Der Dienstleister muss zudem offenlegen, wo das Secret gespeichert, wie es geschützt und wann es gelöscht wird.
Fehler gezielt eingrenzen
401 Unauthorized
Meist sind Client ID, Secret, Token-Endpunkt oder OAuth-Request falsch. Auch ein abgelaufenes und bereits entferntes Credential führt zu diesem Fehler. Zuerst wird geprüft, ob das Credential in Central noch vorhanden ist und ob die Anwendung wirklich den neuesten Secret-Satz nutzt.
403 Forbidden
Die Authentifizierung war erfolgreich, aber die Rolle erlaubt die Aktion nicht. Statt sofort Super Admin zu vergeben, wird der benötigte API-Endpunkt der passenden Service-Principal-Rolle zugeordnet.
Richtiger Token, falsche Datenregion
Der Zugriffstoken allein bestimmt nicht den fachlichen API-Host. Die Anwendung muss den von whoami gelieferten Regional-Host verwenden. Ein fest eingetragener Host aus einer anderen Region verursacht Fehler oder Abfragen gegen die falsche Plattformgrenze.
Integration fällt ohne Warnung aus
Wenn Central keinen offenen Alert zeigt, werden Ablaufdatum, letzter erfolgreicher API-Aufruf und Secret-Version im Zielsystem geprüft. Ablaufüberwachung gehört in das externe Monitoring.
Regelmässige Kontrolle
Mindestens quartalsweise werden Name, Eigentümer, Rolle, letzter Gebrauch, Ablauf und Zielsystem jedes Credentials geprüft. Nicht zuordenbare oder ungenutzte Identitäten werden gelöscht. Nach einem Verdacht auf Secret-Abfluss wird das Credential sofort gesperrt, durch ein neues ersetzt und das Audit Log auf ungewöhnliche Aktionen untersucht.
Die persönlichen Administratorrechte werden separat nach Sophos Central Administrationsrollen richtig zuweisen kontrolliert. API Credentials ersetzen weder MFA noch einen persönlichen, nachvollziehbaren Admin-Zugang.