Schützen des geistigen Eigentums von MSSPs in Microsoft Sentinel

In diesem Artikel werden die Methoden beschrieben, mit denen MSSPs (Managed Security Service Providers) geistiges Eigentum schützen können, das sie in Microsoft Sentinel entwickelt haben. Beispiele hierfür wären etwa Microsoft Sentinel-Analyseregeln, Hunting-Abfragen, Playbooks und Arbeitsmappen.

Für welche Methode Sie sich entscheiden, hängt davon ab, wie Ihre Kund*innen Azure erwerben – also ob Sie als Cloudlösungsanbieter (Cloud Solutions Provider, CSP) fungieren oder ob der Kunde bzw. die Kundin über ein Konto mit Enterprise Agreement (EA)/nutzungsbasierter Bezahlung (Pay-As-You-Go, PAYG) verfügt. Die einzelnen Methoden werden in den folgenden Abschnitten beschrieben.

Cloudlösungsanbieter (Cloud Solution Providers, CSPs)

Wenn Sie Azure als Cloudlösungsanbieter (Cloud Solutions Provider, CSP) weiterverkaufen, verwalten Sie das Azure-Abonnement des Kunden. Dank Administrator im Namen von (Admin on Behalf Of, AOBO) erhalten Benutzer in der Gruppe „Administrator-Agents“ Ihres MSSP-Mandanten Besitzerzugriff auf das Azure-Abonnement des Kunden. Der Kunde hat standardmäßig keinen Zugriff.

Wenn andere Benutzer aus dem MSSP-Mandanten außerhalb der Gruppe „Administrator-Agents“ Zugriff auf die Kundenumgebung benötigen, empfiehlt sich die Verwendung von Azure Lighthouse. Mit Azure Lighthouse können Sie Benutzern oder Gruppen mithilfe einer der integrierten Rollen Zugriff auf einen bestimmten Bereich (beispielsweise eine Ressourcengruppe oder ein Abonnement) gewähren.

Wenn Sie Kundenbenutzern Zugriff auf die Azure-Umgebung gewähren müssen, empfiehlt es sich, den Zugriff nicht für das gesamte Abonnement, sondern nur auf Ressourcengruppenebene zu gewähren, damit Sie Teile der Umgebung nach Bedarf anzeigen/ausblenden können.

Beispiel:

• Sie können dem Kunden Zugriff auf mehrere Ressourcengruppen gewähren, in denen sich seine Anwendungen befinden, und den Microsoft Sentinel-Arbeitsbereich in einer separaten Ressourcengruppe platzieren, auf die der Kunde keinen Zugriff hat.

• Mit dieser Methode können Kunden bestimmte Arbeitsmappen und Playbooks anzeigen – also separate Ressourcen, die sich in ihrer eigenen Ressourcengruppe befinden.

Wenn Sie Kund*innen Zugriff auf Ressourcengruppenebene gewähren, können diese auf Protokolldaten für die Ressourcen zugreifen, auf die sie Zugriff haben (also beispielsweise auf Protokolle eines virtuellen Computers) – auch ohne Zugriff auf Microsoft Sentinel. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf Microsoft Sentinel-Daten nach Ressource.

Microsoft Sentinel: CSP-Beispielarchitektur

Die folgende Abbildung zeigt, wie die im vorherigen Abschnitt beschriebenen Berechtigungen bei der Zugriffsgewährung für CSP-Kunden verwendet werden können:

In dieser Abbildung:

• Bei den Benutzer*innen mit Zugriff als Besitzer auf das CSP-Abonnement handelt es sich um die Benutzer*innen in der Gruppe „Administrator-Agents“ im Microsoft Entra-Mandanten des MSSP.

• Anderen Gruppen des MSSP wird über Azure Lighthouse Zugriff auf die Kundenumgebung gewährt.

• Der Kundenzugriff auf Azure-Ressourcen wird per Azure RBAC auf Ressourcengruppenebene verwaltet.

  Dadurch können MSSPs Microsoft Sentinel-Komponenten wie Analyseregeln und Hunting-Abfragen nach Bedarf ausblenden.

Weitere Informationen finden Sie auch in der Dokumentation zu Azure Lighthouse.

Enterprise Agreements (EAs)/Nutzungsbasierte Bezahlung (Pay-As-You-Go, PAYG)

Wenn Ihre Kund*innen direkt bei Microsoft kaufen, haben sie bereits Vollzugriff auf die Azure-Umgebung, und Sie können nichts ausblenden, was sich im Azure-Abonnement dieser Kund*innen befindet.

Stattdessen können Sie Ihr in Microsoft Sentinel entwickeltes geistiges Eigentum wie folgt schützen (je nachdem, welche Art von Ressource Sie schützen möchten):

Analyseregeln und Hunting-Abfragen

Analyseregeln und Hunting-Abfragen sind in Microsoft Sentinel enthalten und können daher nicht vom Microsoft Sentinel-Arbeitsbereich getrennt werden.

Die Abfrage kann somit selbst von Benutzer*innen mit Berechtigungen vom Typ „Microsoft Sentinel-Leser“ angezeigt werden. In diesem Fall empfiehlt es sich, Ihre Analyseregeln und Hunting-Abfragen nicht im Kundenmandanten, sondern in Ihrem eigenen MSSP-Mandanten zu hosten.

Hierzu benötigen Sie in Ihrem eigenen Mandanten einen Arbeitsbereich mit Microsoft Sentinel-Unterstützung, und der Kundenarbeitsbereich muss für Sie über Azure Lighthouse sichtbar sein.

Um im MSSP-Mandanten eine Analyseregel oder Hunting-Abfrage mit Verweis auf Daten im Kundenmandanten zu erstellen, muss die Anweisung workspace wie folgt verwendet werden:

workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’

Berücksichtigen Sie Folgendes, wenn Sie Ihren Analyseregeln eine Anweisung vom Typ workspace hinzufügen:

• Keine Warnungen im Kundenarbeitsbereich. Durch auf diese Weise erstellte Regeln werden keine Warnungen oder Incidents im Kundenarbeitsbereich ausgelöst. Sowohl Warnungen als auch Incidents sind nur in Ihrem MSSP-Arbeitsbereich vorhanden.

• Erstellen Sie separate Warnungen für jeden Kunden. Bei Verwendung dieser Methode empfiehlt es sich auch, separate Warnungsregeln für jeden Kunden und jede Erkennung zu verwenden, da die Arbeitsbereichsanweisung von Fall zu Fall unterschiedlich ist.

  Zur problemlosen Identifizierung des Kunden, bei dem die Warnung ausgelöst wurde, können Sie den Kundennamen dem Namen der Warnungsregel hinzufügen. Separate Warnungen können zu einer großen Anzahl von Regeln führen, die Sie ggf. mithilfe von Skripts oder mit Microsoft Sentinel als Code verwalten sollten.

  Beispiel:

  

• Erstellen Sie separate MSSP-Arbeitsbereiche für jeden Kunden. Wenn Sie separate Regeln für jeden Kunden und jede Erkennung erstellen, kann es passieren, dass für Ihren Arbeitsbereich die maximal zulässige Anzahl von Analyseregeln (512) erreicht wird. Wenn Sie über viele Kunden verfügen und diesen Grenzwert wahrscheinlich erreichen werden, empfiehlt es sich, jeweils einen separaten MSSP-Arbeitsbereich für die einzelnen Kunden zu erstellen.

  Beispiel:

  

Arbeitsmappen

Wenn Sie eine Microsoft Sentinel-Arbeitsmappe entwickelt haben, die von Ihrem Kunden nicht kopiert werden soll, hosten Sie die Arbeitsmappe in Ihrem MSSP-Mandanten. Stellen Sie sicher, dass Sie über Azure Lighthouse auf Ihre Kundenarbeitsbereiche zugreifen können, und ändern Sie dann die Arbeitsmappe so, dass diese Kundenarbeitsbereiche verwendet werden.

Beispiel:

Weitere Informationen finden Sie unter Arbeitsbereichsübergreifende Arbeitsmappen.

Wenn Sie dem Kunden das Anzeigen der Arbeitsmappenvisualisierungen ermöglichen und gleichzeitig den Code geheim halten möchten, empfiehlt es sich, die Arbeitsmappe zu Power BI zu exportieren.

Das Exportieren Ihrer Arbeitsmappe zu Power BI bewirkt Folgendes:

• Es erleichtert die Freigabe von Arbeitsmappenvisualisierungen. Sie können dem Kunden einen Link zum Power BI-Dashboard senden, auf dem er die gemeldeten Daten ganz ohne Azure-Zugriffsberechtigungen anzeigen kann.
• Es ermöglicht die Verwendung von Zeitplänen. Konfigurieren Sie Power BI so, dass in regelmäßigen Abständen E-Mails mit einer Momentaufnahme des Dashboards für die entsprechende Zeit gesendet werden.

Weitere Informationen finden Sie unter Importieren von Azure Monitor-Protokolldaten in Power BI.

Playbooks

Sie können Ihre Playbooks wie folgt schützen (je nachdem, wo die Analyseregeln zum Auslösen des Playbooks erstellt wurden):

• Im MSSP-Arbeitsbereich erstellte Analyseregeln: Erstellen Sie Ihre Playbooks im MSSP-Mandanten, und achten Sie darauf, dass Sie alle Incident- und Warnungsdaten aus dem MSSP-Arbeitsbereich erhalten. Sie können die Playbooks anfügen, wenn Sie eine neue Regel in Ihrem Arbeitsbereich erstellen.

  Beispiel:

  

• Im Kundenarbeitsbereich erstellte Analyseregeln: Verwenden Sie Azure Lighthouse, um Analyseregeln aus dem Arbeitsbereich des Kunden an ein in Ihrem MSSP-Arbeitsbereich gehostetes Playbook anzufügen. In diesem Fall werden durch das Playbook die Warnungs- und Incidentdaten sowie alle anderen Kundeninformationen aus dem Kundenarbeitsbereich abgerufen.

  Beispiel:

  

In beiden Fällen muss ein Benutzer- oder Dienstprinzipal mit entsprechendem Zugriff über Lighthouse verwendet werden, wenn das Playbook auf die Azure-Umgebung des Kunden zugreifen muss.

Wenn das Playbook Zugriff auf Azure-fremde Ressourcen im Mandanten des Kunden bzw. der Kundin (also beispielsweise auf Microsoft Entra ID, Office 365 oder Microsoft Defender XDR) benötigt, erstellen Sie einen Dienstprinzipal mit den entsprechenden Berechtigungen im Kundenmandanten und fügen diese Identität dann dem Playbook hinzu.

Nächste Schritte

Weitere Informationen finden Sie unter

• Microsoft Sentinel: Technisches Playbook für MSSPs
• Verwalten mehrerer Mandanten in Microsoft Sentinel als MSSP
• Erweitern von Microsoft Sentinel auf Arbeitsbereiche und Mandanten
• Visualisieren und Überwachen Ihrer Daten
• Tutorial: Einrichten automatisierter Reaktionen auf Bedrohungen in Microsoft Sentinel