Protection de la propriété intellectuelle des MSSP dans Microsoft Sentinel

Cet article décrit les méthodes que les fournisseurs de services de sécurité gérés (MSSP) peuvent utiliser pour protéger la propriété intellectuelle qu’ils ont développée dans Microsoft Sentinel, par exemple les règles d’analyse, les requêtes de chasse, les playbooks et les classeurs de Microsoft Sentinel.

La méthode que vous choisissez dépend de la manière dont chacun de vos clients achète Azure : si vous agissez en tant que fournisseur de solutions Cloud (CSP) ou si le client dispose d’un compte Contrat Entreprise (EA)/Paiement à l’utilisation (PAYG). Les sections suivantes décrivent chacune de ces méthodes séparément.

Fournisseurs de solutions Cloud (CSP)

Si vous revendez Azure en tant que fournisseur de solutions Cloud (CSP), vous gérez l’abonnement Azure du client. Grâce à la fonctionnalité AOBO (Admin-On-Behalf-Of), les utilisateurs du groupe Agents administrateurs de votre locataire MSSP disposent d’un accès Propriétaire à l’abonnement Azure du client, tandis que le client n’a aucun accès par défaut.

Si d’autres utilisateurs du locataire MSSP, en dehors du groupe Agents administrateurs, doivent accéder à l’environnement du client, nous vous recommandons d’utiliser Azure Lighthouse. Azure Lighthouse vous permet d’accorder aux utilisateurs ou aux groupes l’accès à une étendue spécifique, comme un groupe de ressources ou un abonnement, en utilisant l’un des rôles intégrés.

Si vous devez fournir aux utilisateurs clients un accès à l’environnement Azure, nous vous recommandons de leur accorder un accès au niveau du groupe de ressources, plutôt qu’à l’intégralité de l’abonnement, afin de pouvoir afficher/masquer des parties de l’environnement le cas échéant.

Par exemple :

• Vous pouvez accorder au client l’accès à plusieurs groupes de ressources où se trouvent ses applications, tout en gardant l’espace de travail Microsoft Sentinel dans un groupe de ressources distinct, auquel le client n’a pas accès.

• Utilisez cette méthode pour permettre aux clients d’afficher certains classeurs et playbooks, qui sont des ressources distinctes pouvant résider dans leur propre groupe de ressources.

Même en accordant l’accès au niveau du groupe de ressources, les clients ont toujours accès aux données de journal des ressources auxquelles ils peuvent accéder, par exemple les journaux d’une machine virtuelle, même sans accès à Microsoft Sentinel. Pour plus d’informations, consultez Gérer l’accès aux données de Microsoft Sentinel par ressource.

Conseil

Si vous devez fournir à vos clients un accès à l’ensemble de l’abonnement, vous pouvez consulter l’aide dans Contrats Entreprise (EA)/Paiement à l’utilisation (PAYG).

Exemple d’architecture CSP Microsoft Sentinel

L’image suivante illustre le fonctionnement des autorisations décrites dans la section précédente lorsque vous fournissez un accès aux clients CSP :

Dans cette image :

• Les utilisateurs ayant un accès Propriétaire à l’abonnement CSP sont les utilisateurs du groupe Agents administrateurs, dans le locataire MSSP Microsoft Entra.

• D’autres groupes du MSSP ont accès à l’environnement du client via Azure Lighthouse.

• L’accès des clients aux ressources Azure est géré par Azure RBAC au niveau du groupe de ressources.

  Cela permet aux MSSP de masquer les composants Microsoft Sentinel le cas échéant, comme les règles d’analyse et les requêtes de chasse.

Pour plus d’informations, consultez également la documentation d’Azure Lighthouse.

Contrats Entreprise (EA)/Paiement à l’utilisation (PAYG)

Si votre client achète directement auprès de Microsoft, il a déjà un accès complet à l’environnement Azure, et vous ne pouvez pas masquer quoi que ce soit qui se trouve dans l’abonnement Azure du client.

Au lieu de cela, protégez la propriété intellectuelle que vous avez développée dans Microsoft Sentinel comme suit, selon le type de ressource que vous devez protéger :

Règles d’analyse et requêtes de chasse

Les règles d’analyse et les requêtes de chasse sont contenues dans Microsoft Sentinel et ne peuvent donc pas être séparées de l’espace de travail Microsoft Sentinel.

Même si un utilisateur dispose uniquement des autorisations Lecteur Microsoft Sentinel, il peut visualiser la requête. Dans ce cas, nous vous recommandons d’héberger vos règles d’analyse et vos requêtes de chasse dans votre propre locataire MSSP, au lieu du locataire du client.

Pour ce faire, vous avez besoin d’un espace de travail dans votre propre locataire pour lequel Microsoft Sentinel est activé, et vous devez également voir l’espace de travail du client via Azure Lighthouse.

Pour créer une règle d’analyse ou une requête de chasse dans le locataire MSSP qui fait référence aux données dans le locataire du client, vous devez utiliser l’instruction workspace comme suit :

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

Lorsque vous ajoutez une instruction workspace à vos règles d’analyse, tenez compte des points suivants :

• Aucune alerte dans l’espace de travail du client. Les règles créées de cette façon ne créent pas d’alertes ni d’incidents dans l’espace de travail du client. Les alertes et les incidents existent uniquement dans votre espace de travail MSSP.

• Créer des alertes distinctes pour chaque client. Lorsque vous utilisez cette méthode, nous vous recommandons également d’utiliser des règles d’alerte distinctes pour chaque client et chaque détection, car l’instruction workspace est différente dans chaque cas.

  Vous pouvez ajouter le nom du client au nom de la règle d’alerte pour identifier facilement le client où l’alerte est déclenchée. Des alertes distinctes peuvent donner lieu à un grand nombre de règles, que vous pouvez gérer à l’aide de scripts ou de Microsoft Sentinel en tant que code.

  Par exemple :

  

• Créer des espaces de travail MSSP distincts pour chaque client. En créant des règles distinctes pour chaque client et chaque détection, vous risquez d’atteindre le nombre maximal de règles d’analyse pour votre espace de travail (512). Si vous avez de nombreux clients et que vous pensez atteindre cette limite, vous pouvez créer un espace de travail MSSP distinct pour chaque client.

  Par exemple :

  

Important

La clé de la réussite de cette méthode consiste à utiliser l’automatisation pour gérer un large ensemble de règles dans vos espaces de travail.

Pour plus d’informations, consultez l’article Règles d’analyse pour plusieurs espaces de travail.

Classeurs

Si vous avez développé un classeur Microsoft Sentinel que vous ne souhaitez pas que votre client copie, hébergez le classeur dans le locataire de votre MSSP. Assurez-vous d’avoir accès aux espaces de travail de votre client via Azure Lighthouse, puis veillez à modifier le classeur pour utiliser ces espaces de travail.

Par exemple :

Pour plus d’informations, consultez Classeurs pour plusieurs espaces de travail.

Si vous souhaitez que le client puisse afficher les visualisations du classeur tout en gardant le code secret, nous vous recommandons d’exporter le classeur vers Power BI.

Exporter votre classeur vers Power BI :

• Facilite le partage des visualisations du classeur. Vous pouvez envoyer au client un lien vers le tableau de bord Power BI, où il peut afficher les données rapportées, sans avoir besoin des autorisations d’accès Azure.
• Permet la planification. Configurez Power BI pour qu’il envoie régulièrement des e-mails contenant un instantané du tableau de bord pour cette période.

Pour plus d’informations, consultez Importation de données de journal Azure Monitor dans Power BI.

Playbooks

Vous pouvez protéger vos playbooks de la façon suivante, en fonction de l’emplacement de création des règles analytiques qui déclenchent le playbook :

• Règles d’analyse créées dans l’espace de travail MSSP. Assurez-vous de créer vos playbooks dans le locataire MSSP et vérifiez que vous recevez toutes les données d’incident et d’alerte de l’espace de travail MSSP. Vous pouvez attacher les playbooks chaque fois que vous créez une nouvelle règle dans votre espace de travail.

  Par exemple :

  

• Règles d’analyse créées dans l’espace de travail du client. Utilisez Azure Lighthouse pour attacher des règles d’analyse de l’espace de travail du client à un playbook hébergé dans votre espace de travail MSSP. Dans ce cas, le playbook obtient les données d’alerte et d’incident, ainsi que toute autre information sur le client, à partir de l’espace de travail du client.

  Par exemple :

  

Dans les deux cas, si le playbook doit accéder à l’environnement Azure du client, utilisez un utilisateur ou un principal de service disposant de cet accès via Lighthouse.

Toutefois, si le playbook doit accéder à des ressources non Azure dans le tenant du client, comme Microsoft Entra ID, Office 365 ou Microsoft Defender XDR, créez un principal de service avec les autorisations appropriées dans le tenant du client, puis ajoutez cette identité dans le playbook.

Remarque

Si vous utilisez des règles d’automatisation avec vos playbooks, vous devez définir les autorisations des règles d’automatisation sur le groupe de ressources dans lequel se trouvent les playbooks. Pour plus d’informations, consultez Autorisations de règles d’automatisation pour l’exécution de playbooks.

Étapes suivantes

Pour plus d'informations, consultez les pages suivantes :

• Playbook technique Microsoft Sentinel pour MSSP
• Gérer plusieurs locataires dans Microsoft Sentinel en tant que MSSP
• Étendre Microsoft Sentinel dans les espaces de travail et les locataires
• Visualiser et superviser vos données
• Tutoriel : Configurer des réponses automatisées aux menaces dans Microsoft Sentinel