Sophos Central Integration Credential Manager betreiben
Der Integration Credential Manager verwaltet Zugangsdaten fremder Produkte, welche Sophos Central für Integrationen verwendet. Beispiele sind API-Tokens oder Konten für Data Ingestion und Response Actions.
Er ist nicht mit API Credentials zu verwechseln. API Credentials erlauben einer externen Anwendung den Zugriff auf Sophos Central. Im Credential Manager speichert Sophos Central dagegen Zugangsdaten, um auf ein Drittprodukt zuzugreifen.
Wann der Credential Manager passt
Ein Credential wird dort angelegt, wenn eine unterstützte Sophos-Integration Zugang zu einem externen Produkt benötigt und dieser Credential-Typ in Central verfügbar ist. Der Manager kann Zugangsdaten über mehrere gleichartige Integrationen wiederverwenden und zeigt Health, letzte Nutzung, Berechtigungen sowie die Integrationsfunktionen mit Zugriff.
Nicht jeder beliebige Secret-Typ lässt sich dort speichern. Für nicht unterstützte Integrationen bleibt der zentrale Unternehmens-Secret-Store massgebend.
Berechtigungen vorab planen
Vor der Erstellung werden festgelegt:
- Drittprodukt und Zielinstanz,
- erlaubte Read- oder Write-Aktionen,
- Sophos-Funktionen mit Zugriff auf das Credential,
- technischer Owner und Notfallkontakt,
- Ablaufdatum und Rotationsverfahren,
- Inaktivitätslimit,
- Test und Rückbau.
Write-Zugriff wird nur erteilt, wenn Response Actions tatsächlich benötigt und im Drittprodukt ebenfalls eingeschränkt sind. Eine Integration, die nur Telemetrie liest, erhält keine Änderungsrechte.
Credential anlegen
Der Pfad lautet Global Settings > Access Control > Integration Credential Manager. Add öffnet zuerst die Seite Type, auf der unter Credential Type ein unterstützter Typ, beispielsweise Okta API Token, gewählt und mit Next bestätigt wird.
Auf Details werden Name und Beschreibung, Read- oder Write-Berechtigung sowie unter Integrations with Access nur die benötigten Sophos-Funktionen ausgewählt, beispielsweise Data Ingestion oder Response Action. Optional folgen Inactivity limit und, falls für diesen Typ vorhanden, Expiration date. Rechts wird der Hinweis unter Vendor and Product documentation and disclaimer nach Prüfung der Sicherheitsfolgen bestätigt.
Wird die Disclaimer-Checkbox auf Details noch nicht bestätigt, bietet Central die Bestätigung auf der nächsten Seite nochmals an. Ohne bewusste Bestätigung wird das Credential nicht produktiv freigegeben; der zusätzliche Dialog ist kein Ersatz für die interne Prüfung des Drittanbieterzugangs.
Auf der Seite Credential werden die vom Drittprodukt verlangten Werte eingetragen, im Okta-Beispiel URL und API Token. Diese Werte stammen aus der jeweiligen Produktkonfiguration und nicht aus einem fremden Beispiel. Save erstellt das Credential; danach werden die vorgesehene Integration, Health und Usage kontrolliert und die Integration fachlich getestet. Alternativ kann eine unterstützte Integration während ihres Setups ein Credential mit Standardberechtigungen anlegen, das später im Manager enger konfiguriert wird.
Das externe Konto selbst erhält ebenfalls Least Privilege. Eine enge Einstellung in Central kompensiert kein überprivilegiertes Konto im Drittprodukt.
Health und Nutzung überwachen
Die Listenansicht zeigt:
- Healthy, Partially healthy oder Unhealthy,
- einen Bindestrich statt des Health-Symbols und beim Hover Awaiting usage, wenn es noch nie verwendet wurde,
- Last accessed mit der letzten Verwendung und möglichen Inaktivitätswarnungen,
- Used by mit den Integrationsfunktionen, die das Credential verwenden können,
- den Credential type,
- Warnungen vor Suspendierung oder Purge.
Ein grüner Credential-Status belegt nur, dass die technische Verwendung funktioniert. Er bestätigt nicht, dass Daten vollständig eintreffen oder eine Response Action fachlich korrekt wirkt. Deshalb werden Testevent, Zeitstempel und Ergebnis im Zielsystem geprüft.
Auf der Detailseite stehen zusätzlich Vendor, Vendor Identifier, Permissions und Integration Access. Usage zeigt Anzahl und letzten Zeitpunkt der Requests. Logs enthält nur die 250 jüngsten Ereignisse und lässt sich nach Status, Integrationstyp und Zeitraum filtern. Für eine längere Nachvollziehbarkeit werden relevante Fehler deshalb vor dem Überschreiben in das betriebliche Monitoring oder einen Supportfall übernommen.
Credential bearbeiten, sperren oder löschen
Für eine Bearbeitung wird unter Global Settings > Access Control > Integration Credential Manager der Credentialname geöffnet und Actions > Edit gewählt. Central zeigt dieselben Setupseiten wie bei der Erstellung. Auf Details lassen sich Name, Beschreibung, Berechtigungen, Integrationszugriff, Inaktivitätslimit und gegebenenfalls Ablauf ändern; auf Credential werden die eigentlichen Drittanbieterwerte ersetzt. Nach dem Speichern folgen Health-, Usage- und Funktionstests. Used by und Integration Access zeigen Integrationsfunktionen, ersetzen aber kein eigenes Inventar der konkreten Integrationsinstanzen, die man vor einer Änderung prüfen muss.
Eine manuelle Sperre erfolgt nach Auswahl des Credentials mit Actions > Suspend und erneuter Bestätigung der Nutzungswarnung. Sie ist sinnvoll bei Kompromittierungsverdacht oder zur kontrollierten Fehleranalyse, stoppt aber die Daten- und Response-Nutzung sämtlicher abhängiger Integrationen. Actions > Unsuspend reaktiviert den Credential und setzt seine Inaktivitätsfrist auf sechs Monate oder den individuell konfigurierten Wert zurück.
Für nicht mehr benötigte Credentials wird zuerst jede Abhängigkeit umgestellt. Danach folgen Auswahl, Actions > Delete und Bestätigung der Warnung. Löschen widerruft nicht automatisch das zugehörige Konto oder Token im Drittprodukt; auch dort wird der Zugang entfernt oder rotiert.
Inaktivität, Suspendierung und Purge
Standardmässig wird ein Credential nach sechs Monaten beziehungsweise 180 Tagen Inaktivität suspendiert und nach einem Jahr endgültig bereinigt (Purge). Unter Actions > Edit > Inactivity limit lässt sich beispielsweise eine Suspendierung nach einem und ein Purge nach zwei Jahren wählen. Eine Änderung startet die neue Frist sofort und entfernt bestehende Warnungen.
Vor dem Verlängern eines Inaktivitätslimits wird geklärt, ob die Integration noch benötigt wird. Eine selten ausgelöste Notfallaktion braucht einen dokumentierten Funktionstest, nicht einfach ein unbegrenztes Secret.
Central warnt 90 Tage vor der Suspendierung. Vor einem Purge folgen Warnungen 90, 60, 30 und 7 Tage vorher. Dafür müssen E-Mail-Alert-Regeln für den Credential Manager konfiguriert sein. Ein Super Admin öffnet dazu Global Settings > Platform > Notification Settings > Configure Email Alerts und prüft Empfänger, Frequenz und Alert-Typen. Beim Aktivieren der ersten Custom Rule werden bestehende Empfängereinstellungen deaktiviert; benötigte Administratoren und Verteiler gehören deshalb ausdrücklich in eine passende Regel.
Mit Actions > Reset inactivity limit wird die verbleibende Inaktivitätsfrist wieder auf sechs Monate oder den konfigurierten Wert gesetzt. Actions > Unsuspend reaktiviert ein gesperrtes Credential und setzt dieselbe Frist neu. Vorher werden externes Secret, Berechtigungen und abhängige Integrationen geprüft; ein Unsuspend repariert kein abgelaufenes oder widerrufenes Token.
Eine manuelle Suspendierung stoppt die Datenübertragung aller verwendenden Integrationen. Ein Purge oder Löschen kann mehrere Integrationen dauerhaft unterbrechen, wenn das Credential wiederverwendet wird.
Credential-Werte kontrolliert ersetzen
Der Credential Manager rotiert ein Secret im Drittprodukt nicht selbst. Wenn der jeweilige Anbieter einen Austausch unterstützt, wird dessen dokumentiertes Verfahren in einem Wartungsfenster mit dem Central-Update koordiniert:
- Konkrete Integrationsinstanzen, Used by, Integration Access und letzte Nutzung erfassen.
- Nach der Dokumentation des Drittprodukts einen Ersatzwert bereitstellen.
- Das Credential über Actions > Edit in Central aktualisieren.
- Health, Usage und die betroffenen Integrationsfunktionen prüfen.
- Den alten Wert erst nach erfolgreicher Prüfung und gemäss Anbieterverfahren widerrufen.
- Audit- und Integrationslogs kontrollieren.
Ob alter und neuer Wert überlappen dürfen, bestimmt allein das Drittprodukt. Ist keine Überlappung dokumentiert, wird kein unterbrechungsfreier Wechsel versprochen; die mögliche Unterbrechung wird eingeplant und überwacht.
Typische Fehlerbilder
Status bleibt Awaiting usage
Credential ist noch keiner aktiven Integration zugewiesen, die Integration hat noch keinen Lauf ausgeführt oder der falsche Credential-Satz wurde gewählt. Zuweisung und Testevent prüfen.
Credential ist gesund, aber Daten fehlen
Zeitraum, Datenquelle, Integration, Filter und Berechtigungen im Drittprodukt kontrollieren. Health bestätigt nicht jede fachliche Datenmenge.
Eine Änderung unterbricht mehrere Integrationen
Das Credential wird wiederverwendet. Used by ist der erste Hinweis auf den Wirkungsbereich; zusätzlich werden alle konkreten Integrationsinstanzen aus dem eigenen Inventar ermittelt und gemeinsam getestet.
Delete meldet mögliche Nutzung
Die Warnung wird nicht übergangen. Erst alle verknüpften Integrationen umstellen oder entfernen, danach das Credential löschen.