Microsoft Sentinel unterstützt mehrere Konten pro Konnektor: Prüfungen vor der Zentralisierung

Microsoft hat am 31. August 2026 Multi-Account-Unterstützung für drei Microsoft-Sentinel-Konnektoren angekündigt: Auth0, CrowdStrike Falcon und Salesforce Service Cloud. Für Sicherheitsteams ist das eine praktische Änderung. Mehrere Konten derselben Quelle erfordern nicht mehr zwingend einen eigenen Konnektortyp oder eine improvisierte Umgehung pro Verbindung.

Die Zentralisierung ist jedoch kein folgenloser Klick. Jede Verbindung authentifiziert und fragt unabhängig ab, Daten können in einer gemeinsamen Tabelle landen und Quellbenennung, Berechtigungen, API-Limits sowie Ingestionskosten werden wichtiger. Vor dem zweiten Konto braucht es daher ein Konzept, mit dem Ereignisse zuverlässig unterscheidbar bleiben.

Was genau hinzugekommen ist

Die Ankündigung betrifft Auth0, CrowdStrike Falcon und Salesforce Service Cloud. Microsoft nennt sie als erste Konnektoren mit Unterstützung des Multi-Account-Musters. Daraus folgt nicht, dass jeder Sentinel-Konnektor automatisch beliebig viele Konten akzeptiert. Für jede weitere Quelle ist die aktuelle Dokumentation des konkreten Konnektors zu prüfen.

In der Verwaltungsoberfläche lassen sich mehrere getrennte Verbindungen desselben Typs erstellen. Jede hat eigene Verbindungsdaten und einen eigenen Status. Das hilft etwa einer Unternehmensgruppe, einem Team mit mehreren Service-Tenants oder einer Organisation, die ein Produktionskonto von einem weiteren Anbieterkonto trennt.

Wie das Multi-Account-Muster funktioniert

Die Dokumentation zum Content Connector Framework beschreibt eine gemeinsame Konnektordefinition, Datensammlungsregel, einen Sammelendpunkt und eine Zieltabelle. Jede vom Benutzer erstellte Verbindung erhält dennoch eine eindeutige ARM-Ressource vom Typ dataConnectors. Diese Grenze ist für Deployment, Audit und Fehleranalyse entscheidend: Zwei Konten sind kein gemeinsamer Satz von Zugangsdaten.

Die Verbindungen fragen unabhängig voneinander ab. Werden Daten in einer gemeinsamen Tabelle gespeichert, benötigen Analyseregeln und Hunting-Abfragen ein Feld, das Quellkonto oder Tenant unterscheidet. Ohne diesen Kontext kann eine Ansicht vollständig wirken, obwohl der Analyst ein Ereignis keiner organisatorischen Grenze zuordnen kann.

Was die Funktion nicht löst

• sie erstellt keine Berechtigungen im Quelldienst und wählt nicht automatisch Least Privilege;
• sie beseitigt keine API-Limits oder Bedingungen des Anbieters;
• sie garantiert nicht, dass eine gemeinsame Erkennungsregel jedes Konto korrekt trennt;
• sie verhindert keinen Anstieg von Ingestionsvolumen und Kosten;
• sie ersetzt kein Monitoring von Konnektorstatus, Verzögerung oder Authentifizierungsfehlern;
• sie bedeutet nicht, dass jeder andere Sentinel-Konnektor denselben Ablauf unterstützt.

Praktischer Ablauf vor der zweiten Verbindung

1. Konten und Eigentümer erfassen. Für jede Quelle Umgebung, fachlichen Eigentümer, Sicherheitsteam und Zugriffsverantwortlichen dokumentieren.
2. Eindeutige Kennung entwerfen. Prüfen, welches Feld in der Zieltabelle Konto, Tenant oder anderen Quellkontext kennzeichnet und ob es in allen Ereignissen befüllt ist.
3. Getrennte Zugangsdaten vorbereiten. Kein gemeinsames Geheimnis ohne Eigentümer verwenden. Rechte auf das Nötige begrenzen und Rotation dokumentieren.
4. Ein Konto testen. Erstes und jüngstes Ereignis, Ingestionszeit, erwartete Datensätze und Lücken prüfen.
5. Tagesvolumen messen. Aus dem Piloten Ingestion, Aufbewahrung und Abfragelast schätzen und später mit realen Werten vergleichen.
6. API-Limits prüfen. Jede Verbindung fragt unabhängig ab; mehrere Verbindungen können die Aufrufe desselben API erhöhen.
7. Erkennungen anpassen. Quellkontokontext in Hunting-Abfragen, Analyseregeln und Dashboards ergänzen, wo er die Bewertung ändert.
8. Rückweg vorbereiten. Festlegen, wie eine Verbindung deaktiviert wird, ohne Historie zu löschen oder andere Konten zu unterbrechen.

Kosten, Grenzen und Datenqualität

Microsoft nennt für dieses Konnektormuster kein separates festes Verbindungslimit, empfiehlt aber ausdrücklich, die Skalierung in der eigenen Umgebung zu validieren. Praktische Grenzen können Quell-API, Datenvolumen, Plattformlimits oder Verarbeitungszeit sein. „Kein konnektorspezifisches Limit“ ist keine Zusage unbegrenzter Kapazität.

Jede Verbindung erzeugt unabhängige Polling-Vorgänge. Liefert das neue Konto zusätzliche Ereignisse, steigen auch Ingestion und mögliche Kosten. Vor dem Produktivbetrieb sollten Datensatzanzahl pro Konto, Verzögerung, Konnektorfehler und Kosten im gleichen Zeitraum beobachtet werden. Eine gemeinsame Tabelle vermeidet fragmentierte Schemas, verlangt aber diszipliniertes Filtern.

Sicherheitsgrenzen

Geheimnisse, Token und Schlüssel gehören weder in Tickets noch in Wikis oder Audit-Zusammenfassungen. Sie werden im vorgesehenen Secret Store abgelegt, der Zugriff wird begrenzt und die Rotation folgt der Richtlinie des Quelldiensts. Beim Stilllegen eines Kontos werden nur die zugehörige Verbindung und Zugangsdaten entfernt; gemeinsame Komponenten können von anderen Verbindungen weiter genutzt werden.

Für kritische Quellen gehören auch Negativtests dazu: abgelaufene Zugangsdaten, API-Throttling, unvollständige Antworten und verspätete Daten. Der Status „Connected“ allein beweist nicht, dass alle erwarteten Ereignisse die Tabelle erreichen.

Checkliste für Administratoren

• jede Verbindung zeigt Eigentümer und Quellkonto;
• jede Verbindung hat minimal nötige Rechte und eine eigene Rotation;
• Ereignisse lassen sich in der Tabelle nach Konto trennen;
• Erkennungen nutzen den richtigen Kontext und mischen keine unabhängigen Tenants;
• Volumen, Verzögerung, Fehler, API-Limits und Kosten werden überwacht;
• das sichere Trennen eines einzelnen Kontos ist dokumentiert.

Wann fachliche Unterstützung sinnvoll ist

Mehrere Konten in einem Workspace sind nur dann wertvoll, wenn Daten- und Verantwortungsgrenzen klar bleiben. Yenwa unterstützt mit Cybersecurity-Leistungen beim Entwurf von Quellen, Erkennungen und Betriebskontrollen. Für Cloud-Dienste können wir Pilot, Ingestionsschätzung und Prüfung möglicher blinder Flecken vorbereiten.

Zentralisieren Sie die Sichtbarkeit, nicht die Unklarheit. Jedes Ereignis muss der richtigen Quelle, dem richtigen Eigentümer und der richtigen Verbindung zugeordnet werden können.