MsSP-intellectueel eigendom beveiligen in Microsoft Sentinel
Notitie
Azure Sentinel heet nu Microsoft Sentinel en we zullen deze pagina's in de komende weken bijwerken. Meer informatie over recente beveiligingsverbeteringen van Microsoft.
In dit artikel worden de methoden beschreven die beheerde beveiligingsserviceproviders (MSP's) kunnen gebruiken om intellectueel eigendom te beschermen dat ze in Microsoft Sentinel hebben ontwikkeld, zoals Microsoft Sentinel-analyseregels, hunting-query's, playbooks en werkmappen.
De methode die u kiest, is afhankelijk van hoe elk van uw klanten Azure koopt. of u nu als een Cloud Solutions Provider (CSP)of de klant een Enterprise Agreement-account (EA)/Pay-as-you-go (PAYG) heeft. In de onderstaande secties worden deze methoden afzonderlijk beschreven.
Cloud Solutions Providers (CSP)
Als u Azure opnieuw verkoopt als een Cloud Solutions Provider (CSP), beheert u het Azure-abonnement van de klant. Dankzij Admin-On-Behalf-Of (AOBO)krijgen gebruikers in de groep Admin Agents van uw MSSP-tenant eigenaarstoegang tot het Azure-abonnement van de klant en heeft de klant standaard geen toegang.
Als andere gebruikers van de MSSP-tenant, buiten de groep Beheerdersagents, toegang moeten hebben tot de klantomgeving, raden we u aan om de Azure Lighthouse. 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 gebruikers van klanten toegang wilt geven tot de Azure-omgeving, wordt u aangeraden hen toegang te verlenen op het niveau van de resourcegroep in plaats van het hele abonnement, zodat u delen van de omgeving naar behoefte kunt weergeven/verbergen.
Bijvoorbeeld:
U kunt de klant toegang verlenen tot verschillende resourcegroepen waarin hun toepassingen zich bevinden, maar de Microsoft Sentinel-werkruimte nog steeds in een afzonderlijke resourcegroep houden, 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 met het verlenen van toegang op het niveau van de resourcegroep hebben klanten nog steeds toegang tot logboekgegevens voor de resources die ze kunnen openen, zoals logboeken van een VM, zelfs zonder toegang tot Microsoft Sentinel. Zie Toegang tot Microsoft Sentinel-gegevens beheren per resource voor meer informatie.
Tip
Als u uw klanten toegang wilt bieden tot het hele abonnement, kunt u de richtlijnen bekijken in Enterprise Agreements (EA) / Betalen per gebruik (PAYG).
Microsoft Sentinel CSP-voorbeeldarchitectuur
In de volgende afbeelding wordt beschreven hoe de machtigingen die in de vorige sectie worden beschreven, kunnen werken bij het verlenen van toegang aan CSP-klanten:
In deze afbeelding:
De gebruikers met eigenaarstoegang tot het CSP-abonnement zijn de gebruikers in de groep Admin Agents in de MSSP Azure AD-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 zo nodig verbergen, zoals analyseregels en hunting-query's.
Zie voor meer informatie ook de Azure Lighthouse documentatie.
Enterprise Agreements (EA) / Betalen per uur (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 heeft.
Bebeveiligen in plaats daarvan uw intellectueel eigendom dat u in Microsoft Sentinel als volgt hebt ontwikkeld, afhankelijk van het type resource dat u moet beveiligen:
Analyseregels en zoekquery's
Analyseregels en zoekquery's zijn beide opgenomen 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 nog steeds bekijken. In dit geval raden we u aan uw Analytics-regels en hunting-query's te hosten in uw eigen MSSP-tenant, in plaats van de tenant van de klant.
Hiervoor moet u een werkruimte in uw eigen tenant hebben met Microsoft Sentinel ingeschakeld en moet u ook de werkruimte van de klant zien via Azure Lighthouse.
Als u een analyseregel of hunting-query wilt maken in de MSSP-tenant die verwijst naar gegevens in de tenant van de klant, moet u de instructie workspace als volgt gebruiken:
workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’
Wanneer u een instructie workspace toevoegt aan uw analyseregels, moet u rekening houden met het volgende:
Geen waarschuwingen in de werkruimte van de klant. Met regels die op deze manier zijn gemaakt, worden er geen waarschuwingen of incidenten gemaakt in de werkruimte van de klant. Zowel waarschuwingen als incidenten bestaan alleen in uw MSSP-werkruimte.
Maak afzonderlijke waarschuwingen voor elke klant. Wanneer u deze methode gebruikt, raden we u ook aan afzonderlijke waarschuwingsregels voor elke klant en detectie te gebruiken, omdat de werkruimte-instructie in elk geval anders is.
U kunt de naam van de klant toevoegen aan de naam van de waarschuwingsregel om eenvoudig 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:
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 bereikt (512). Als u veel klanten hebt en verwacht deze limiet te bereiken, kunt u voor elke klant een afzonderlijke MSSP-werkruimte maken.
Bijvoorbeeld:
Belangrijk
De sleutel tot het gebruik van deze methode is het gebruik van automatisering voor het beheren van een grote set regels in uw werkruimten.
Zie Analyseregels voor meerdere werkruimten voor meer informatie
Werkmappen
Als u een Microsoft Sentinel-werkmap hebt ontwikkeld die uw klant niet wilt kopiëren, host u de werkmap in uw MSSP-tenant. Zorg ervoor dat u toegang hebt tot uw klantwerkruimten via Azure Lighthouse en wijzig vervolgens de werkmap zodat deze werkruimten van klanten worden gebruikt.
Bijvoorbeeld:
Zie Werkmappen voor meerdere werkruimten voor meer informatie.
Als u wilt dat de klant de werkmapvisualisaties kan bekijken terwijl het codegeheim blijft behouden, wordt u aangeraden de werkmap te exporteren naar Power BI.
Uw werkmap exporteren naar Power BI:
- Maakt het gemakkelijker om de werkmapvisualisaties te delen. U kunt de klant een koppeling sturen naar het Power BI dashboard, waar ze de gerapporteerde gegevens kunnen bekijken zonder azure-toegangsmachtigingen.
- Hiermee schakelt u planning in. Configureer Power BI regelmatig e-mailberichten te verzenden die een momentopname van het dashboard voor die tijd bevatten.
Zie Import Azure Monitor log data into Power BI (Logboekgegevens importeren in Power BI) voor meer Power BI.
Playbooks
U kunt uw playbooks als volgt beveiligen, afhankelijk van waar de analyseregels die de 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 op krijgt. U kunt de playbooks koppelen wanneer u een nieuwe regel in uw werkruimte maakt.
Bijvoorbeeld:
Analyseregels die zijn gemaakt in de werkruimte van de klant. Gebruik Azure Lighthouse om analyseregels van de werkruimte van de klant te koppelen 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:
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 Azure AD, Office 365 of Microsoft 365 Defender, moet u een service-principal maken met de juiste machtigingen in de tenant van de klant en die identiteit vervolgens toevoegen aan het playbook.
Notitie
Als u automatiseringsregels samen met uw playbooks gebruikt, moet u de machtigingen voor de automatiseringsregel instellen voor de resourcegroep waarin de playbooks zich afspelen. Zie Machtigingen voor automatiseringsregels voor het uitvoeren van playbooks voor meer informatie.
Volgende stappen
Zie voor meer informatie: