Ochrana duševního vlastnictví MSSP ve službě Microsoft Sentinel

Tento článek popisuje metody, které mohou poskytovatelé spravovaných služeb zabezpečení (MSSP) používat k ochraně duševního vlastnictví vyvinutého v Microsoft Sentinelu, jako jsou analytická pravidla Microsoft Sentinelu, dotazy pro proaktivní vyhledávání, playbooky a sešity.

Způsob, který zvolíte, bude záviset na tom, jak si každý z vašich zákazníků koupí Azure. bez ohledu na to, jestli jste poskytovatel Cloud Solutions Provider (CSP),nebo má zákazník účet smlouva Enterprise (EA)/pay-as-you-go (PAYG). Následující části popisují každou z těchto metod samostatně.

Poskytovatelé cloudových řešení (CSP)

Pokud přehodíte Azure jako poskytovatele CLOUD Solutions Provider (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 zákazník nemá ve výchozím nastavení 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žít Azure Lighthouse. Azure Lighthouse umožňuje udělit uživatelům nebo skupinám přístup ke konkrétnímu oboru, jako je skupina prostředků nebo předplatné, pomocí jedné z předdefinových rolí.

Pokud potřebujete uživatelům zákazníků poskytnout přístup k prostředí Azure, doporučujeme jim udělit přístup na úrovni skupiny prostředků, nikoli na úrovni celého předplatného, abyste podle potřeby mohli zobrazit nebo skrýt části prostředí.

Například:

• Můžete zákazníkovi udělit přístup k několika skupinám prostředků, ve kterých se nacházejí jeho aplikace, ale pracovní prostor Microsoft Sentinelu můžete ponechat v samostatné skupině prostředků, ve které 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 mohou nacházet ve vlastní skupině prostředků.

I s udělením přístupu na úrovni skupiny prostředků budou mít zákazníci stále přístup k datům protokolu pro prostředky, ke kterým mají přístup, jako jsou protokoly z virtuálního počítače, a to i bez přístupu k Microsoft Sentinelu. Další informace najdete v tématu Správa přístupu k datům Služby Microsoft Sentinel podle prostředků.

Ukázková architektura poskytovatele 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 MSSP Azure AD.

• Ostatní skupiny z MSSP díky skupině 100 000 000 000 000 000 Azure Lighthouse.

• Přístup zákazníků k prostředkům Azure spravuje Azure RBAC na úrovni skupiny prostředků.

  To umožňuje mssp skrýt komponenty Microsoft Sentinelu podle potřeby, jako jsou analytická pravidla a dotazy pro proaktivní vyhledávání.

Další informace najdete také v dokumentaci Azure Lighthouse .

Enterprise smlouvy o úrovni služeb (EA) / předplatná (PAYG)

Pokud zákazník nakupuje přímo od Microsoftu, 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 chraňte své duševní vlastnictví, které jste vyvinuli v Microsoft Sentinelu, následujícím způsobem v závislosti na typu prostředku, který potřebujete chránit:

Analytická pravidla a dotazy pro proaktivní vyhledávání

Analytická pravidla a dotazy pro proaktivní vyhledávání jsou součástí služby Microsoft Sentinel, a proto je nelze oddělit od pracovního prostoru Microsoft Sentinelu.

I když má uživatel jenom oprávnění Čtenář Microsoft Sentinelu, bude moct dotaz zobrazit. V takovém případě doporučujeme hostovat analytická pravidla a dotazy pro proaktivní vyhledávání ve vašem vlastním tenantovi MSSP místo zákaznického tenanta.

K tomu budete potřebovat pracovní prostor ve vlastním tenantovi s povolenou službou Microsoft Sentinel a také budete muset zobrazit pracovní prostor zákazníka prostřednictvím Azure Lighthouse.

Pokud chcete vytvořit analytické pravidlo nebo dotaz proaktivní vyhledávání v tenantovi MSSP, který odkazuje na data v tenantovi zákazníka, musíte použít workspace příkaz následujícím způsobem:

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 nevytváří upozornění ani incidenty v pracovním prostoru zákazníka. Upozornění i incidenty budou existovat pouze ve vašem 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 používat samostatná pravidla upozornění pro každého zákazníka a detekci, protože příkaz pracovního prostoru se v každém případě bude lišit.

  K názvu pravidla upozornění můžete přidat jméno zákazníka, abyste mohli snadno identifikovat zákazníka, ve kterém se upozornění aktivuje. Samostatné výstrahy můžou mít za následek velký počet pravidel, která můžete chtít spravovat pomocí skriptování, nebo Microsoft Sentinel jako kód.

  Napří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, že dosáhnete 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, že tento limit dosáhnete, můžete pro každého zákazníka vytvořit samostatný pracovní prostor MSSP.

  Například:

  

Workbooks

Pokud jste vyvinuli sešit Microsoft Sentinelu, který nechcete zákazníkovi kopírovat, hostte ho ve svém tenantovi MSSP. Ujistěte se, že máte přístup k pracovním prostorům zákazníků prostřednictvím Azure Lighthouse, a pak sešit upravte tak, aby tyto pracovní prostory zákazníků používat.

Například:

Další informace najdete v tématu Sešity mezi pracovními prostory.

Pokud chcete, aby si zákazník mohl zobrazit vizualizace sešitu a zároveň 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 bez vyžadování přístupových oprávnění Azure.
• Povolí plánování. Nakonfigurujte Power BI, aby pravidelně odesílaly e-maily, které obsahují snímek řídicího panelu.

Další informace najdete v tématu Import Azure Monitor protokolování dat 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, která playbook aktivují:

• 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 upozornění z pracovního prostoru MSSP. Playbooky můžete připojit vždy, když ve svém pracovním prostoru vytvoříte nové pravidlo.

  Například:

  

• Analytická pravidla vytvořená v pracovním prostoru zákazníka Pomocí Azure Lighthouse připojit analytická pravidla z pracovního prostoru zákazníka k playbooku hostovanému v pracovním prostoru MSSP. V takovém případě playbook získá data o výstrahách a incidentech a všechny další informace o zákazníku z pracovního prostoru zákazníka.

  Napří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 Azure AD, Office 365 nebo Microsoft 365 Defender, budete muset vytvořit instanční objekt s příslušnými oprávněními v tenantovi zákazníka a pak tuto identitu přidat do playbooku.

Další kroky

Další informace naleznete v tématu:

• Technický playbook Microsoft Sentinelu pro MSSP
• Správa více tenantů v Microsoft Sentinelu jako MSSP
• Rozšíření Microsoft Sentinelu napříč pracovními prostory a tenanty
• Vizualizace a monitorování dat
• Kurz: Nastavení automatizovaných reakcí na hrozby ve službě Microsoft Sentinel