Zarządzasz 200 maszynami wirtualnymi z systemami Windows i Linux w trzech regionach. Wymagania: 1) Zespoły ds. bezpieczeństwa i operacji potrzebują dostępu opartego na rolach do logów dla każdego regionu, ale Ty potrzebujesz możliwości uruchamiania scentralizowanych zapytań dla wszystkich maszyn wirtualnych. 2) Zachowaj SecurityEvent przez 180 dni, ale liczniki wydajności (Perf) tylko przez 30 dni. 3) Zbieraj tylko określone identyfikatory zdarzeń systemu Windows i filtruj szumiące dane w momencie zbierania. Jaki projekt obszaru roboczego i zbierania danych należy zalecić?

Ta opcja spełnia wszystkie wymagania. Wdrożenie jednego obszaru roboczego Log Analytics na region umożliwia regionalne RBAC dla zespołów bezpieczeństwa i operacji. Agent Azure Monitor (AMA) z regułami zbierania danych (DCR) pozwala na filtrowanie zdarzeń Windows i transformacje podczas pozyskiwania, redukując szum. Konfiguracja przechowywania dla poszczególnych tabel (SecurityEvent na 180 dni, Perf na 30 dni) spełnia wymagania dotyczące retencji. Zapytania KQL między obszarami roboczymi umożliwiają scentralizowaną analizę. Pozostałe opcje są nieprawidłowe, ponieważ: Opcja z jednym globalnym obszarem roboczym uniemożliwia regionalne RBAC i nie pozwala na różne okresy przechowywania dla poszczególnych tabel. Opcja z obszarem roboczym na zespół aplikacji nie spełnia wymagań dotyczących regionalnego RBAC ani filtrowania podczas pozyskiwania, a eksportowanie do ADLS Gen2 komplikuje scentralizowane zapytania. Opcja z Event Hubs i Stream Analytics jest zbyt złożona i nie wykorzystuje natywnych funkcji Log Analytics do przechowywania i zapytań. Opcja z Azure Sentinel nie pozwala na różne okresy przechowywania dla poszczególnych tabel i nie filtruje podczas pozyskiwania.