Delen via


Intellectueel eigendom van MSSP beveiligen in Microsoft Sentinel

In dit artikel worden de methoden beschreven die beheerde beveiligingsserviceproviders (MSSP's) kunnen gebruiken om intellectueel eigendom te beschermen dat ze hebben ontwikkeld in Microsoft Sentinel, zoals Microsoft Sentinel-analyseregels, opsporingsquery's, playbooks en werkmappen.

De methode die u kiest, is afhankelijk van hoe elk van uw klanten Azure koopt; of u nu als Cloud Solutions Provider (CSP) of de klant een Enterprise Overeenkomst (EA)/Pay-as-You-Go-account (PAYG) heeft. In de volgende secties wordt elk van deze methoden afzonderlijk beschreven.

Cloud Solutions Providers (CSP)

Als u Azure als cloudoplossingenprovider (CSP) weergeeft, beheert u het Azure-abonnement van de klant. Dankzij Beheer-On-Behalf-Of (AOBO) krijgen gebruikers in de groep Beheer Agents van uw MSSP-tenant toegang tot het Azure-abonnement van de klant en heeft de klant standaard geen toegang.

Als andere gebruikers van de MSSP-tenant, buiten de groep Beheer Agents, toegang moeten hebben tot de klantomgeving, raden we u aan Azure Lighthouse te gebruiken. Met Azure Lighthouse kunt u gebruikers of groepen toegang verlenen tot een specifiek bereik, zoals een resourcegroep of abonnement, met behulp van een van de ingebouwde rollen.

Als u klantgebruikers toegang moet bieden tot de Azure-omgeving, raden we u aan hen toegang te verlenen op resourcegroepsniveau in plaats van het hele abonnement, zodat u delen van de omgeving indien nodig kunt weergeven/verbergen.

Bijvoorbeeld:

  • U kunt de klant toegang verlenen tot verschillende resourcegroepen waar hun toepassingen zich bevinden, maar de Microsoft Sentinel-werkruimte in een afzonderlijke resourcegroep behouden, waar de klant geen toegang heeft.

  • Gebruik deze methode om klanten in staat te stellen geselecteerde werkmappen en playbooks weer te geven. Dit zijn afzonderlijke resources die zich in hun eigen resourcegroep kunnen bevinden.

Zelfs bij het verlenen van toegang op het niveau van de resourcegroep hebben klanten toegang tot logboekgegevens voor de resources die ze kunnen openen, zoals logboeken van een VIRTUELE machine, zelfs zonder toegang tot Microsoft Sentinel. Zie Toegang tot Microsoft Sentinel-gegevens beheren per resource voor meer informatie.

Tip

Als u uw klanten toegang moet geven tot het hele abonnement, kunt u de richtlijnen in Enterprise Overeenkomst s (EA) / Betalen per gebruik (PAYG) bekijken.

Voorbeeld van Microsoft Sentinel CSP-architectuur

In de volgende afbeelding wordt beschreven hoe de machtigingen die in de vorige sectie worden beschreven, kunnen werken bij het verlenen van toegang tot CSP-klanten:

Protect your Microsoft Sentinel intellectual property with CSP customers.

In deze afbeelding:

  • De gebruikers die zijn verleend met eigenaarstoegang tot het CSP-abonnement, zijn de gebruikers in de groep Beheer Agents, in de MSSP Microsoft Entra-tenant.

  • Andere groepen van de MSSP krijgen toegang tot de klantomgeving via Azure Lighthouse.

  • Klanttoegang tot Azure-resources wordt beheerd door Azure RBAC op het niveau van de resourcegroep.

    Hierdoor kunnen MSSP's Microsoft Sentinel-onderdelen indien nodig verbergen, zoals analyseregels en opsporingsquery's.

Zie ook de Documentatie van Azure Lighthouse voor meer informatie.

Enterprise Overeenkomst s (EA) / Betalen per gebruik (PAYG)

Als uw klant rechtstreeks bij Microsoft koopt, heeft de klant al volledige toegang tot de Azure-omgeving en kunt u niets verbergen dat zich in het Azure-abonnement van de klant bevindt.

Beveilig in plaats daarvan als volgt uw intellectuele eigendom dat u in Microsoft Sentinel hebt ontwikkeld, afhankelijk van het type resource dat u moet beveiligen:

Analyseregels en opsporingsquery's

Analyseregels en opsporingsquery's bevinden zich beide in Microsoft Sentinel en kunnen daarom niet worden gescheiden van de Microsoft Sentinel-werkruimte.

Zelfs als een gebruiker alleen microsoft Sentinel Reader-machtigingen heeft, kan deze de query bekijken. In dit geval raden we u aan om uw analyseregels en opsporingsquery's in uw eigen MSSP-tenant te hosten in plaats van de tenant van de klant.

Hiervoor hebt u een werkruimte in uw eigen tenant nodig waarvoor Microsoft Sentinel is ingeschakeld en moet u ook de werkruimte van de klant zien via Azure Lighthouse.

Als u een analyseregel of opsporingsquery wilt maken in de MSSP-tenant die verwijst naar gegevens in de tenant van de klant, moet u de workspace instructie als volgt gebruiken:

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

Houd rekening met het volgende wanneer u een workspace instructie toevoegt aan uw analyseregels:

  • Geen waarschuwingen in de werkruimte van de klant. Regels die op deze manier zijn gemaakt, maken geen waarschuwingen of incidenten in de werkruimte van de klant. Zowel waarschuwingen als incidenten bestaan alleen in uw MSSP-werkruimte.

  • Afzonderlijke waarschuwingen maken voor elke klant. Wanneer u deze methode gebruikt, raden we u ook aan afzonderlijke waarschuwingsregels te gebruiken voor elke klant en detectie, omdat de werkruimte-instructie in elk geval anders is.

    U kunt de naam van de klant toevoegen aan de naam van de waarschuwingsregel om de klant te identificeren waar de waarschuwing wordt geactiveerd. Afzonderlijke waarschuwingen kunnen resulteren in een groot aantal regels, die u mogelijk wilt beheren met behulp van scripting of Microsoft Sentinel als code.

    Bijvoorbeeld:

    Create separate rules in your MSSP workspace for each customer.

  • Maak afzonderlijke MSSP-werkruimten voor elke klant. Het maken van afzonderlijke regels voor elke klant en detectie kan ertoe leiden dat u het maximum aantal analyseregels voor uw werkruimte (512) bereikt. Als u veel klanten hebt en deze limiet verwacht te bereiken, kunt u een afzonderlijke MSSP-werkruimte maken voor elke klant.

    Bijvoorbeeld:

    Create a workspace and rules in your MSSP tenant for each customer.

Belangrijk

De sleutel voor het gebruik van deze methode is automatisering om een grote set regels in uw werkruimten te beheren.

Zie Analyseregels voor meerdere werkruimten voor meer informatie

Werkmappen

Als u een Microsoft Sentinel-werkmap hebt ontwikkeld die u niet wilt kopiëren door uw klant, moet u de werkmap hosten in uw MSSP-tenant. Zorg ervoor dat u toegang hebt tot uw klantwerkruimten via Azure Lighthouse en zorg ervoor dat u de werkmap wijzigt zodat deze werkruimten van de klant worden gebruikt.

Bijvoorbeeld:

Cross-workspace workbooks

Zie Werkmappen voor meerdere werkruimten voor meer informatie.

Als u wilt dat de klant de werkmapvisualisaties kan bekijken terwijl de code nog steeds geheim blijft, raden we u aan de werkmap te exporteren naar Power BI.

Uw werkmap exporteren naar Power BI:

  • Hiermee kunt u de werkmapvisualisaties gemakkelijker delen. U kunt de klant een koppeling naar het Power BI-dashboard sturen, waar ze de gerapporteerde gegevens kunnen bekijken, zonder dat hiervoor azure-toegangsmachtigingen nodig zijn.
  • Hiermee schakelt u de planning in. Configureer Power BI om periodiek e-mailberichten te verzenden die een momentopname van het dashboard bevatten voor die tijd.

Zie Logboekgegevens van Azure Monitor importeren in Power BI voor meer informatie.

Draaiboeken

U kunt uw playbooks als volgt beveiligen, afhankelijk van waar de analyseregels die het playbook activeren, zijn gemaakt:

  • Analyseregels die zijn gemaakt in de MSSP-werkruimte. Zorg ervoor dat u uw playbooks maakt in de MSSP-tenant en dat u alle incident- en waarschuwingsgegevens van de MSSP-werkruimte krijgt. U kunt de playbooks koppelen wanneer u een nieuwe regel in uw werkruimte maakt.

    Bijvoorbeeld:

    Rules created in the MSSP workspace.

  • Analyseregels die zijn gemaakt in de werkruimte van de klant. Gebruik Azure Lighthouse om analyseregels van de werkruimte van de klant toe te voegen aan een playbook dat wordt gehost in uw MSSP-werkruimte. In dit geval haalt het playbook de waarschuwings- en incidentgegevens, en eventuele andere klantgegevens, op uit de werkruimte van de klant.

    Bijvoorbeeld:

    Rules created in the customer workspace.

Als het playbook in beide gevallen toegang moet hebben tot de Azure-omgeving van de klant, gebruikt u een gebruiker of service-principal die toegang heeft via Lighthouse.

Als het playbook echter toegang moet hebben tot niet-Azure-resources in de tenant van de klant, zoals Microsoft Entra-id, Office 365 of Microsoft Defender XDR, maakt u een service-principal met de juiste machtigingen in de tenant van de klant en voegt u die identiteit vervolgens toe aan het playbook.

Notitie

Als u automatiseringsregels samen met uw playbooks gebruikt, moet u de machtigingen voor automatiseringsregels instellen voor de resourcegroep waarin de playbooks zich bevinden. Zie Machtigingen voor automatiseringsregels voor het uitvoeren van playbooks voor meer informatie.

Volgende stappen

Zie voor meer informatie: