Täglicher Betrieb

Aufgaben, die MSSP-Betreiber gegen eine laufende SocTalk-Installation ausführen. Falls noch nicht geschehen, lesen Sie zuerst die MSSP-UI-Tour — sie katalogisiert jede unten referenzierte Seite.

Untersuchungs-Warteschlange

Öffnen Sie Investigations, um aktive Fälle für jeden Mandanten in einer Ansicht zu sehen. Filter: Mandant, Schweregrad. Klicken Sie auf eine Zeile für die Fall-Zeitachse, die Konversation und die Vorschläge.

Vorschlags-Prüfungs-Warteschlange

Reviews ist die mandantenübergreifende Warteschlange von KI-Vorschlägen, die auf einen Menschen warten. Genehmigen / Ablehnen / Mehr-Infos aktualisieren jeweils die Prüfungszeile in der Datenbank (und dem Audit-Log). Es gibt keine Outbox in V1 — die Executor- / nachgelagerte Benachrichtigungs-Pipeline steht auf der Roadmap.

Mandant hängt in provisioning

Symptom: die Mandantenzeile eines neuen Kunden verbleibt länger als 15 Min. im Zustand provisioning.

1. Prüfen Sie den Status des Helm-Release:

   helm status tenant-<slug> -n tenant-<slug>

2. Prüfen Sie die Pod-Ereignisse:

   kubectl -n tenant-<slug> get events --sort-by=.lastTimestamp | tail -30

3. Häufige Ursachen:
   • StorageClass fehlt oder Provisioner ausgefallen → PVCs hängen in Pending. Stellen Sie Storage bereit; kubectl describe pvc zeigt den Grund.
   • ResourceQuota zu klein für die Anforderung des Wazuh-Indexers. Erhöhen Sie die ResourceQuota des Mandanten via helm upgrade mit neuen Werten.
   • Image-Pull-Fehler → prüfen Sie Registry-Authentifizierung und Firewall.

Wenn ein Provisioning-Versuch nicht wiederherstellbar ist, außer Betrieb nehmen und erneut versuchen:

# Aus der MSSP-UI: Mandantendetail → Decommission → force=true
# Oder via API:
curl -X POST https://mssp.../api/mssp/tenants/<id>:decommission?force=true

Mandant im Zustand degraded

degraded wird vom Provisioning-Controller bei einem Provisioning-Fehler gesetzt oder explizit via API gesetzt. In diesem Release gibt es keine automatische Degradations-Schleife basierend auf dem Alter des Adapter-Heartbeats; die Metrik soctalk_tenant_adapter_heartbeat_age_seconds dient Ihrem Alerting.

1. Prüfen Sie den Adapter-Pod:

   kubectl -n tenant-<slug> logs deploy/soctalk-adapter --tail=200

2. Prüfen Sie den NetworkPolicy-Egress (der Adapter muss die soctalk-system-API erreichen):

   hubble observe --from-pod tenant-<slug>/soctalk-adapter-<pod>

3. Starten Sie den Adapter neu:

   kubectl -n tenant-<slug> rollout restart deploy/soctalk-adapter

Wenn die Data Plane gesund ist, der Adapter aber soctalk-system immer noch nicht erreichen kann, inspizieren Sie die adapter-egress-NetworkPolicy.

Pro-Mandant-LLM-Schlüssel rotieren

1. MSSP-Admin → Kundendetail → Settings → LLM → neuen Schlüssel einfügen → Save (oder PATCH /api/mssp/tenants/{id}/llm).
2. SocTalks maßgeblicher Speicher ist IntegrationConfig.llm_api_key_plain in Postgres. Der Provisioning-Controller materialisiert diesen Wert in Secret/tenant-llm-key im Mandanten-Namespace (eingebunden vom runs-worker-Deployment) und spiegelt optional eine Referenz nach soctalk-system/<tenant-id>-llm zu Audit-Zwecken.
3. SocTalk startet nach Best-Effort das soctalk-runs-worker-Deployment in tenant-<slug> neu, damit der neue Schlüssel bei der nächsten Untersuchungs-Übernahme wirksam wird.

Data-Plane-Bootstrap-Secrets rotieren

Es gibt in diesem Release kein soctalk-cli rotate-*-Kommando — dieser Weg war in früheren Entwürfen dokumentiert. Heute:

• Wazuh- / TheHive- / Cortex-Admin-Passwörter: patchen Sie das relevante Secret im Mandanten-Namespace und starten Sie dann den betroffenen Pod neu. Der Bootstrap-Rerun der Chart beim Pod-Start übernimmt die neue Zugangsinformation.
• Wazuh-authd-Shared-Secret: patchen Sie Secret/wazuh-authd-secret in tenant-<slug>, starten Sie den Wazuh-Manager neu. Alle bestehenden Agenten müssen sich mit dem neuen Secret neu registrieren; verteilen Sie es über Ihren üblichen sicheren Kanal.

Eine Wrapper-CLI für diese Rotationen steht auf der Roadmap.

Analytics

Analytics rollt Triage-Volumen, Vorschlagsergebnisse, MTTR und Budgetverbrauch pro Mandant auf. Nutzen Sie es für Kapazitätsplanung, Modellbewertung und SLA-Prüfung.

Audit-Log-Prüfung

Das MSSP-weite Audit-Log liegt in UI → Audit-Tab. Filtern Sie nach Mandant, Akteur, Aktion oder Zeitstempel. Für Compliance-Exporte nutzen Sie die API:

curl 'https://mssp.../api/audit?since=2026-01-01&tenant=<id>' > audit.json

Datenbank-Wiederherstellung (Disaster Recovery)

Backups werden extern MSSP-verwaltet (Velero, Cluster-Snapshots, externes pg_dump). Zum Wiederherstellen:

1. Stoppen Sie die SocTalk-API:

   kubectl -n soctalk-system scale deploy soctalk-system-api --replicas=0

   (Die V1-Chart bündelt den Orchestrator in den API-Pod — kein separates soctalk-system-orchestrator-Deployment.)
2. Stellen Sie die Postgres-Daten aus Ihrem Backup wieder her.
3. Starten Sie die API neu: kubectl -n soctalk-system scale deploy soctalk-system-api --replicas=2 (oder Ihre übliche Replica-Anzahl).

Die PVCs der Mandanten-Data-Plane folgen demselben Muster: pro Namespace wiederherstellen, dann helm upgrade des Mandanten-Release, um sie wieder anzubinden.

Notfall: einen Mandanten sofort deaktivieren

Die UI-Suspend-Aktion setzt in diesem Release den Mandantenzustand auf suspended und hindert den Orchestrator daran, neue Untersuchungen zu planen — aber sie skaliert keine Workloads. Für eine tatsächliche Abschaltung führen Sie die untenstehenden Schritte aus (alle Deployments skalieren + eine Deny-All-NetworkPolicy zur doppelten Absicherung anwenden):

# 1. Alle Workloads im Mandanten-Namespace auf null skalieren. Dies ist der
#    definitive Stopp — Pods verschwinden.
kubectl -n tenant-<slug> get deploy,statefulset -o name \
  | xargs -I {} kubectl -n tenant-<slug> scale {} --replicas=0

# 2. Deny-All zur doppelten Absicherung, damit alles, was wieder hochkommt (z. B.
#    von einem hängenden, abgleichenden Operator), eingesperrt ist.
kubectl -n tenant-<slug> apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: emergency-deny-all }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
EOF

Kehren Sie den Vorgang um, indem Sie die NetworkPolicy löschen, die Workloads wieder auf ihre ursprünglichen Replica-Anzahlen hochskalieren und in der UI Resume aufrufen. Resume aktualisiert in diesem Release ebenfalls nur den DB-Zustand — es stellt die Replica-Anzahlen nicht für Sie wieder her.

Verdacht auf mandantenübergreifendes Datenleck

Wenn Sie mandantenübergreifenden Zugriff vermuten:

1. Prüfen Sie die jüngsten Läufe der RLS-Testsuite; sie bestehen in CI bei jedem Release.
2. Sondieren Sie die DB direkt:

   kubectl -n soctalk-system exec -it statefulset/soctalk-system-postgres -- \
     psql -U soctalk_app -d soctalk \
     -c "SET app.current_tenant_id='<tenant-a>'; SELECT tenant_id FROM events LIMIT 5;"

3. Wenn ein Leck bestätigt ist, eröffnen Sie einen P1-Vorfall. RLS plus FORCE ROW LEVEL SECURITY ist die letzte Verteidigungslinie; ein ungepatchtes Leck deutet auf einen Anwendungsfehler oder eine Fehlkonfiguration einer Postgres-Rolle hin.

Häufige Fehler

• Migrationen als soctalk_app ausführen. Migrationen benötigen soctalk_admin-Zugangsdaten; unter soctalk_app schlagen sie fehl.
• soctalk-tenant-Werte direkt in Helm bearbeiten. Dies umgeht SocTalks Datenbankzustand; gehen Sie über die API.
• tenant-*-Namespaces von Hand anlegen. Die erforderlichen Labels sind dann nicht vorhanden und SocTalk erkennt den Namespace nicht. Nutzen Sie den Tenant-Create-Flow.