利用 Microsoft Sentinel 工作区设计提高云安全性

云安全性是许多企业面临的一个重要挑战，尤其是在数据和工作负载分散在多个云平台和本地环境的情况下。为了有效地监视、检测和响应各种威胁，企业需要一个集中化、可扩展和灵活的安全信息和事件管理（SIEM）解决方案。

Microsoft Sentinel 是一种云原生的 SIEM 服务，它可以帮助企业收集、分析和响应来自不同数据源的安全事件。Microsoft Sentinel 原生集成了成熟的 Azure 服务，例如 Log Analytics 和逻辑应用。Microsoft Sentinel 可以借助 AI 丰富调查和检测工作。

要使用 Microsoft Sentinel，企业需要设计一个合适的工作区体系结构，以满足他们的业务和技术需求。工作区是存储和处理安全数据的容器，它们可以根据租户、区域、合规性、访问和成本等因素进行配置。

在本文中，我们将介绍一些常见的 Microsoft Sentinel 工作区设计方案，以及如何根据不同的场景选择最佳实践。

示例 1：多个租户和区域

假设你是一家跨国企业，总部位于伦敦，拥有两个 Azure AD 租户（由于收购而产生），并在三个不同的区域（美国东部、欧洲北部和日本西部）托管 Azure 资源。你有严格的数据主权要求，要求将欧洲生成的所有数据保留在欧洲区域。你需要从多种数据源收集安全事件，包括 Office 365、Azure AD、Azure 活动、Azure PaaS 服务、本地 VM 和网络设备等。你有一个 SOC 团队和一个运营团队，他们需要访问不同的数据集。

对于这种情况，建议的 Microsoft Sentinel 工作区设计如下：

• 使用一个独立的 Log Analytics 工作区供运营团队使用，该工作区仅包含 SOC 团队不需要的数据，例如性能、容器或指标数据。
• 使用两个 Microsoft Sentinel 工作区（每个 Azure AD 租户各有一个），用于从 Office 365、Azure 活动、Azure AD 和所有 Azure PaaS 服务引入数据。这些连接器需要在各自的租户内工作。
• 将来自本地数据源的所有其他数据路由到两个 Microsoft Sentinel 工作区中的一个。这些数据可以使用 Log Analytics 代理、Syslog 收集器或 CEF 收集器收集。
• 使用 Azure Lighthouse 帮助管理不同租户中的多个 Microsoft Sentinel 实例。
• 使用资源上下文 RBAC 和表级别 RBAC 来控制不同团队对不同工作区和数据表的访问权限。

这种设计可以满足以下需求：

• 遵守数据主权要求，将欧洲数据存储在欧洲区域。
• 支持多个租户级别的连接器，如 Office 365 和 Azure AD。
• 避免跨区域的带宽成本，将数据发送到与资源相同的区域。
• 分隔 SOC 数据和非 SOC 数据，以提高安全性和成本效益。
• 为不同的团队提供适当的访问权限，以保护数据的机密性和完整性。

下图演示了这种设计的示意图：

示例 2：使用多个云的单个租户

假设你是一家总部位于纽约市的企业，在美国各地设有办事处。你已开启云历程，但仍然需要部署第一个 Azure 登陆区域并迁移首批工作负载。你在 AWS 上已有一些工作负载，你打算使用 Microsoft Sentinel 来监视这些工作负载。你有一个 Azure AD 租户，没有合规性要求，但需要从多种数据源收集安全事件，包括 Azure AD、Azure 活动、Azure VM、AWS CloudTrail 和 AKS 等。你有一个 SOC 团队和一个运营团队，他们需要访问不同的数据集。    对于这种情况，建议的 Microsoft Sentinel 工作区设计如下：

• 使用一个 Microsoft Sentinel 工作区，用于从所有数据源引入数据。这可以简化管理和分析，并节省成本。
• 使用 Log Analytics 代理、Syslog 收集器或 CEF 收集器来收集来自本地和 Azure VM 的数据。
• 使用 AWS CloudTrail 连接器来收集来自 AWS 的数据。
• 使用 AKS 连接器来收集来自 AKS 的数据。
• 使用表级别 RBAC 来控制不同团队对不同数据表的访问权限。

这种设计可以满足以下需求：

• 支持单个租户级别的连接器，如 Azure AD 和 Azure 活动。
• 支持跨云的数据收集，如 AWS CloudTrail 和 AKS。
• 使用单个工作区来实现集中化和简化的安全管理和分析。
• 为不同的团队提供适当的访问权限，以保护数据的机密性和完整性。

下表比较了使用单个工作区和使用多个工作区的成本差异：

示例 3：多个租户和区域，使用集中化安全性

假设你是一家安全托管服务提供商（MSSP），为多个客户提供安全监视和响应服务。你有一个 Azure AD 租户，用于管理你自己的云资源和 Microsoft Sentinel 实例。你的客户分布在不同的地理位置，并且有自己的 Azure AD 租户和云资源。你需要从所有客户的数据源收集安全事件，并使用一个集中化的 Microsoft Sentinel 实例来管理和分析这些事件。你需要遵守客户的合规性要求，并保护客户数据的隔离和安全性。

对于这种情况，建议的 Microsoft Sentinel 工作区设计如下：

• 使用一个 Microsoft Sentinel 工作区，用于从所有客户引入数据。这可以简化管理和分析，并节省成本。
• 使用 Azure Lighthouse 来管理不同租户中的多个 Log Analytics 工作区。这些工作区用于从每个客户的租户级别数据源（例如 Office 365 和 Azure AD）收集数据，并将其转发到 MSSP 的 Microsoft Sentinel 工作区
• 使用 Log Analytics 代理、Syslog 收集器或 CEF 收集器来收集来自每个客户的本地和云 VM 的数据，并将其直接发送到 MSSP 的 Microsoft Sentinel 工作区。
• 使用资源上下文 RBAC 和表级别 RBAC 来控制 MSSP 团队对不同客户数据的访问权限。

这种设计可以满足以下需求：

• 支持多个租户级别的连接器，如 Office 365 和 Azure AD。
• 支持跨租户和跨区域的数据收集，并遵守客户的合规性要求。
• 使用单个工作区来实现集中化和简化的安全管理和分析。
• 保护客户数据的隔离和安全性，通过控制访问权限和加密数据。

下图演示了这种设计的示意图：

Microsoft Sentinel 工作区设计是一个重要的步骤，它可以影响企业的云安全性效率和成本。根据不同的业务和技术需求，企业可以选择使用单个或多个工作区，以及如何配置和管理这些工作区。本文介绍了一些常见的 Microsoft Sentinel 工作区设计方案，以及如何根据不同的场景选择最佳实践。希望这些方案能够为你提供一些参考和启发，帮助你设计适合你的企业的 Microsoft Sentinel 工作区体系结构。

如果你喜欢这篇博客，请给我一个赞👍，并分享给你的朋友和同事。如果你有任何问题或建议，请在下方留言，我会尽快回复你。谢谢你的阅读和支持！