Ochrana duševního vlastnictví MSSP v Microsoft Sentinelu
Tento článek popisuje metody, které můžou poskytovatelé spravovaných služeb zabezpečení (MSSP) použít k ochraně duševního vlastnictví vyvinutého v Microsoft Sentinelu, jako jsou analytická pravidla Microsoft Sentinelu, dotazy proaktivního vyhledávání, playbooky a sešity.
Způsob, který zvolíte, závisí na tom, jak si každý z vašich zákazníků koupí Azure; bez ohledu na to, jestli pracujete jako poskytovatel cloudových řešení (CSP), nebo zákazník má účet smlouva Enterprise (EA)/průběžné platby (PAYG). Následující části popisují každou z těchto metod samostatně.
Poskytovatelé cloudových řešení (CSP)
Pokud azure znovu prodávají jako poskytovatele cloudových řešení (CSP), spravujete předplatné Azure zákazníka. Díky AOBO (Admin-On-Behalf-Of) mají uživatelé ve skupině Agenti pro správu z vašeho tenanta MSSP udělený přístup vlastníka k předplatnému Azure zákazníka a ve výchozím nastavení nemá žádný přístup.
Pokud jiní uživatelé z tenanta MSSP mimo skupinu Agenti pro správu potřebují přístup k prostředí zákazníka, doporučujeme používat Azure Lighthouse. Azure Lighthouse umožňuje uživatelům nebo skupinám udělit přístup ke konkrétnímu oboru, jako je skupina prostředků nebo předplatné, pomocí jedné z předdefinovaných rolí.
Pokud potřebujete poskytnout uživatelům zákazníků přístup k prostředí Azure, doporučujeme jim udělit přístup na úrovni skupiny prostředků, a ne na úrovni celého předplatného, abyste mohli podle potřeby zobrazit nebo skrýt části prostředí.
Příklad:
Zákazníkovi můžete udělit přístup k několika skupinám prostředků, ve kterých se nacházejí jejich aplikace, ale pracovní prostor Služby Microsoft Sentinel můžete ponechat v samostatné skupině prostředků, kde zákazník nemá přístup.
Tato metoda umožňuje zákazníkům zobrazit vybrané sešity a playbooky, což jsou samostatné prostředky, které se můžou nacházet ve vlastní skupině prostředků.
I s udělením přístupu na úrovni skupiny prostředků mají zákazníci přístup k datům protokolů pro prostředky, ke kterým mají přístup, jako jsou protokoly z virtuálního počítače, i bez přístupu k Microsoft Sentinelu. Další informace najdete v tématu Správa přístupu k datům Microsoft Sentinelu podle prostředků.
Tip
Pokud potřebujete zákazníkům poskytnout přístup k celému předplatnému, možná budete chtít zobrazit pokyny v smlouva Enterprise s (EA) / průběžných platbách (PAYG).
Ukázková architektura CSP pro Microsoft Sentinel
Následující obrázek popisuje, jak můžou oprávnění popsaná v předchozí části fungovat při poskytování přístupu zákazníkům CSP:
Na tomto obrázku:
Uživatelé s přístupem vlastníka k předplatnému CSP jsou uživatelé ve skupině Agenti pro správu v tenantovi Microsoft Entra.
Další skupiny z programu MSSP získají přístup k prostředí zákazníka přes Azure Lighthouse.
Přístup zákazníků k prostředkům Azure spravuje Azure RBAC na úrovni skupiny prostředků.
To umožňuje poskytovatelům msSP podle potřeby skrýt komponenty služby Microsoft Sentinel, jako jsou analytická pravidla a dotazy proaktivního vyhledávání.
Další informace najdete také v dokumentaci ke službě Azure Lighthouse.
smlouva Enterprise (EA) / Průběžné platby (PAYG)
Pokud zákazník nakupuje přímo od Microsoftu, zákazník už má úplný přístup k prostředí Azure a nemůžete skrýt nic, co je v předplatném Azure zákazníka.
Místo toho můžete chránit duševní vlastnictví, které jste vytvořili v Microsoft Sentinelu, a to v závislosti na typu prostředku, který potřebujete chránit:
Analytická pravidla a dotazy proaktivního vyhledávání
Analytická pravidla i dotazy proaktivního vyhledávání jsou obsaženy v Microsoft Sentinelu, a proto je nelze oddělit od pracovního prostoru Microsoft Sentinelu.
I když má uživatel oprávnění čtenáře Microsoft Sentinelu, může dotaz zobrazit. V takovém případě doporučujeme místo tenanta zákazníka hostovat vaše analytická pravidla a dotazy proaktivního vyhledávání ve vašem vlastním tenantovi MSSP.
K tomu potřebujete pracovní prostor ve vlastním tenantovi s povolenou službou Microsoft Sentinel a také potřebujete zobrazit pracovní prostor zákazníka přes Azure Lighthouse.
Pokud chcete vytvořit analytické pravidlo nebo dotaz proaktivního vyhledávání v tenantovi MSSP, který odkazuje na data v tenantovi zákazníka, musíte použít workspace následující příkaz:
workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’
Při přidávání workspace příkazu do analytických pravidel zvažte následující:
V pracovním prostoru zákazníka nejsou žádná upozornění. Pravidla vytvořená tímto způsobem nevytvoří upozornění ani incidenty v pracovním prostoru zákazníka. Výstrahy i incidenty existují pouze v pracovním prostoru MSSP.
Vytvořte samostatná upozornění pro každého zákazníka. Při použití této metody také doporučujeme pro každého zákazníka použít samostatná pravidla upozornění, protože příkaz pracovního prostoru se v každém případě liší.
Název zákazníka můžete přidat do názvu pravidla upozornění a snadno identifikovat zákazníka, u kterého se upozornění aktivuje. Samostatná upozornění můžou mít za následek velký počet pravidel, která můžete chtít spravovat pomocí skriptování nebo microsoft Sentinelu jako kódu.
Příklad:
Vytvořte samostatné pracovní prostory MSSP pro každého zákazníka. Vytvoření samostatných pravidel pro každého zákazníka a detekce může způsobit dosažení maximálního počtu analytických pravidel pro váš pracovní prostor (512). Pokud máte mnoho zákazníků a očekáváte dosažení tohoto limitu, můžete pro každého zákazníka vytvořit samostatný pracovní prostor MSSP.
Příklad:
Důležité
Klíčem k úspěšnému použití této metody je použití automatizace ke správě velké sady pravidel napříč vašimi pracovními prostory.
Další informace najdete v tématu Pravidla analýzy mezi pracovními prostory.
Workbooks
Pokud jste vytvořili sešit Microsoft Sentinelu, který nechcete, aby ho zákazník zkopíroval, hostujte ho v tenantovi MSSP. Ujistěte se, že máte přístup k pracovním prostorům zákazníka přes Azure Lighthouse, a pak nezapomeňte sešit upravit tak, aby používal tyto pracovní prostory zákazníků.
Příklad:
Další informace najdete v tématu Sešity mezi pracovními prostory.
Pokud chcete, aby zákazník mohl zobrazit vizualizace sešitu a přitom zachovat tajný kód, doporučujeme sešit exportovat do Power BI.
Export sešitu do Power BI:
- Usnadňuje sdílení vizualizací sešitů. Zákazníkovi můžete poslat odkaz na řídicí panel Power BI, kde může zobrazit hlášená data, aniž by vyžadoval přístupová oprávnění Azure.
- Povolí plánování. Nakonfigurujte Power BI tak, aby pravidelně odesílala e-maily, které obsahují snímek řídicího panelu.
Další informace najdete v tématu Import dat protokolu služby Azure Monitor do Power BI.
Playbooky
Playbooky můžete chránit následujícím způsobem v závislosti na tom, kde byla vytvořena analytická pravidla aktivující playbook:
Analytická pravidla vytvořená v pracovním prostoru MSSP Nezapomeňte vytvořit playbooky v tenantovi MSSP a získat všechna data incidentů a výstrah z pracovního prostoru MSSP. Playbooky můžete připojit při každém vytvoření nového pravidla v pracovním prostoru.
Příklad:
Analytická pravidla vytvořená v pracovním prostoru zákazníka Azure Lighthouse slouží k připojení analytických pravidel z pracovního prostoru zákazníka k playbooku hostovaného v pracovním prostoru MSSP. V tomto případě playbook získá z pracovního prostoru zákazníka data výstrahy a incidentu a všechny další informace o zákaznících.
Příklad:
V obou případech, pokud playbook potřebuje přístup k prostředí Azure zákazníka, použijte uživatele nebo instanční objekt, který má tento přístup přes Lighthouse.
Pokud ale playbook potřebuje přístup k prostředkům mimo Azure v tenantovi zákazníka, jako je Id Microsoft Entra, Office 365 nebo XDR v programu Microsoft Defender, vytvořte instanční objekt s příslušnými oprávněními v tenantovi zákazníka a pak tuto identitu přidejte do playbooku.
Poznámka:
Pokud používáte pravidla automatizace společně s playbooky, musíte nastavit oprávnění pravidla automatizace pro skupinu prostředků, ve které jsou playbooky aktivní. Další informace najdete v tématu Oprávnění pro pravidla automatizace ke spouštění playbooků.
Další kroky
Další informace naleznete v tématu: