Azure Monitor 日志数据安全
本文介绍 Azure Monitor 如何收集、处理和保护日志数据，并介绍可用于进一步保护 Azure Monitor 环境的安全功能。 本文中的信息特定于 Azure Monitor 日志，并补充有关 Azure 信任中心的信息。
Azure Monitor 日志使用以下方法安全地管理你基于云的数据：
- 数据隔离
- 数据保留
- 物理安全性
- 事件管理
- 合规性
- 安全标准认证
如有任何有关以下任何信息（包括 Azure 支持选项的安全政策）的疑问、建议或问题，请与我们联系。
使用 TLS 安全地发送数据
为确保传输到 Azure Monitor 的数据的安全性，我们强烈建议你将代理配置为至少使用传输层安全性 (TLS) 1.3。 我们发现旧版 TLS/安全套接字层 (SSL) 容易受到攻击，尽管出于向后兼容，这些协议仍可正常工作，但我们不建议使用，并且行业即将放弃对这些旧协议的支持。
PCI 安全标准委员会规定 2018 年 6 月 30 日是停用旧版 TLS/SSL 并升级到更安全协议的截止时间。 在 Azure 放弃旧版支持后，如果代理无法通过最低版本 TLS 1.3 进行通信，则你无法将数据发送到 Azure Monitor 日志。
除非必要，建议不要将代理显式设置为仅使用 TLS 1.3。 最好允许代理自动检测、协商和利用未来的安全标准。 否则，你可能会错过更新标准的增强安全性，并且如果因支持更新的标准而弃用 TLS 1.3，则可能会遇到问题。
特定于平台的指南
| 平台/语言 | 支持 | 更多信息 |
|---|---|---|
| Linux | Linux 分发版往往依赖于 OpenSSL 来提供 TLS 1.2 支持。 | 请检查 OpenSSL 变更日志，确认你的 OpenSSL 版本是否受支持。 |
| Windows 8.0 - 10 | 受支持，并且默认已启用。 | 确认是否仍在使用默认设置。 |
| Windows Server 2012 - 2016 | 受支持，并且默认已启用。 | 确认是否仍在使用默认设置 |
| Windows 7 SP1 和 Windows Server 2008 R2 SP1 | 受支持，但默认未启用。 | 有关启用方法的详细信息，请参阅传输层安全性 (TLS) 注册表设置页。 |
数据隔离
Azure Monitor 引入数据后，数据将在该服务的每个组件上都保持逻辑隔离。 所有数据按工作区进行标记。 此标记方式贯穿数据的整个生命周期，在服务的每个层强制实施。 数据存储在所选区域的群集存储中的专用数据库内。
数据保留
编入索引的日志搜索数据基于定价计划进行存储和保留。 有关详细信息，请参阅 Log Analytics 定价。
在履行订阅协议的过程中，Azure 会根据协议条款保留数据。 在删除客户数据时，不会销毁任何物理驱动器。
下表列出了可用的一些解决方案并提供了它们会收集的数据类型示例。
| 解决方案 | 数据类型 |
|---|---|
| 容量和性能 | 性能数据和元数据 |
| 更新管理 | 元数据和状态数据 |
| 日志管理 | 用户定义的事件日志、Windows 事件日志和/或 IIS 日志 |
| 更改跟踪 | 软件库存、Windows 服务和 Linux 守护程序元数据，以及 Windows/Linux 文件元数据 |
| SQL 和 Active Directory 评估 | WMI 数据、注册表数据、性能数据和 SQL Server 动态管理视图结果 |
下表显示了数据类型的示例：
| 数据类型 | Fields |
|---|---|
| 警报 | Alert Name、Alert Description、BaseManagedEntityId、Problem ID、IsMonitorAlert、RuleId、ResolutionState、Priority、Severity、Category、Owner、ResolvedBy、TimeRaised、TimeAdded、LastModified、LastModifiedBy、LastModifiedExceptRepeatCount、TimeResolved、TimeResolutionStateLastModified、TimeResolutionStateLastModifiedInDB、RepeatCount |
| 配置 | CustomerID、AgentID、EntityID、 ManagedTypeID、ManagedTypePropertyID、CurrentValue、ChangeDate |
| 事件 | EventId、EventOriginalID、BaseManagedEntityInternalId、RuleId、PublisherId、PublisherName、FullNumber、Number、Category、ChannelLevel、LoggingComputer、EventData、EventParameters、TimeGenerated、TimeAdded 注意： 当将具有自定义字段的事件写入到 Windows 事件日志中时，Log Analytics 会收集它们。 |
| Metadata | BaseManagedEntityId、ObjectStatus、OrganizationalUnit、ActiveDirectoryObjectSid、PhysicalProcessors、NetworkName、IPAddress、ForestDNSName、NetbiosComputerName、VirtualMachineName、LastInventoryDate、HostServerNameIsVirtualMachine、IP Address、NetbiosDomainName、LogicalProcessors、DNSName、DisplayName、DomainDnsName、ActiveDirectorySite、PrincipalName、OffsetInMinuteFromGreenwichTime |
| 性能 | ObjectName、CounterName、PerfmonInstanceName、PerformanceDataId、PerformanceSourceInternalID、SampleValue、TimeSampled、TimeAdded |
| 状态 | StateChangeEventId、StateId、NewHealthState、OldHealthState、Context、TimeGenerated、TimeAdded、StateId2、BaseManagedEntityId、MonitorId、HealthState、LastModified、LastGreenAlertGenerated、DatabaseTimeModified |
物理安全性
Azure Monitor 由 Azure 人员管理，所有活动都将被记录下来并且可被审核。 Azure Monitor 作为 Azure 服务运行，满足所有 Azure 符合性与安全要求。 可以在 Azure 安全概览的第 18 页上查看有关 Azure 资产的物理安全性的详细信息。 对于不再负责 Azure Monitor 的任何人员，系统会在一个工作日内更改该人员对安全区域的物理访问权限，包括传输和终止。 可在 Microsoft 数据中心阅读有关我们使用的全球物理基础设施的信息。
事件管理
Azure Monitor 具有所有 Azure 服务都遵循的事件管理流程。 总而言之，我们：
- 使用共担责任模型，其中一部分安全职责归于 Azure，一部分安全职责归于客户
- 管理 Azure 安全事件：
- 在检测到事件时启动调查
- 由即时事件响应团队成员评估事件的影响和严重性。 基于证据，评估有可能会进一步上报给安全响应团队。
- 由安全响应专家诊断事件，指导进行技术或取证调查，确定抑制、缓解和解决威胁的各种策略。 如果安全团队认为客户数据可能已泄漏给非法或未经授权的个人，会同时开始并行执行客户事件通知过程。
- 稳定事件并从中恢复。 事件响应团队会创建用于缓解问题的恢复计划。 诸如隔离受影响的系统之类的危机管理步骤可能会立即执行，同时开始进行诊断。 可能会计划眼前的风险解决之后采取的长期缓解措施。
- 关闭事件，并进行事后调查。 事件响应团队会进行事后调查，概述事件的细节，旨在修订策略、过程和流程以防止事件的再次发生。
- 通知客户安全事件：
- 确定受影响客户的范围，并向受影响的任何人提供尽可能详细的通知
- 创建一条向客户提供足够详细信息的通知，以便他们可以执行对其终端的调查，并履行他们对其最终用户所做的任何承诺，同时不会不当地延迟通知流程。
- 必要时确认并声明事件。
- 告知客户事件通知，不会无故拖延，并遵循任何法律或合同承诺。 将以 Azure 选择的任何方式（包括电子邮件）向一个或多个客户的管理员发送安全事件的通知。
- 进行团队准备和培训：
- 会要求 Azure 员工完成安全和认知培训，这有助于他们识别并报告可疑的安全问题。
- 基于 Azure 服务运作的运营商对于访问承载客户数据的敏感系统有额外的培训义务。
- Azure 安全响应人员会接受针对其所担当角色的专门培训
如果客户数据出现大量丢失（虽然这种情况非常罕见），Azure 会在一天内通知每个客户。
有关 Azure 如何响应安全事件的详细信息，请参阅在云中进行 Azure 安全响应。
合规性
Azure Monitor 软件开发和服务团队的信息安全和监管计划支持其业务需求，并遵循 Azure 信任中心和 Microsoft 信任中心合规性中所述的法律和法规。 其中还介绍了 Azure Monitor 日志如何建立安全要求、识别安全控制、管理和监控风险。 每年，我们都会对策略、标准、过程和指导原则进行评审。
每个开发团队成员都会接受正式的应用程序安全培训。 在内部，我们将版本控制系统用于软件开发。 每个软件项目都受版本控制系统保护。
Microsoft 有安全性和合规性团队，负责对 Microsoft 的所有服务进行监控和评估。 由信息安全管理人员组成该团队，他们与开发 Log Analytics 的工程团队没有任何关联。 安全专员有其自己的管理链，负责对产品和服务进行独立评估，以确保安全性和合规性。
Microsoft 会向 Microsoft 董事会呈报有关所有信息安全计划的年度报告。
为了获得各种认证，Log Analytics 软件开发和服务团队正积极与 Microsoft 法律和合规团队以及其他行业合作伙伴合作。
认证和证明
Azure Log Analytics 满足以下要求：
- ISO/IEC 27001
- ISO/IEC 27018:2014
- ISO 22301
- PCI 安全标准委员会制定的支付卡行业（PCI 标准）数据安全标准 (PCI DSS)。
- 服务组织控制 (SOC) 1 类型 1 和 SOC 2 类型 1 标准
- HIPAA 和 HITECH（对于具有 HIPAA 业务合作协议的公司）
- Windows 通用工程标准
- Microsoft 可信计算
- 作为一项 Azure 服务，Azure Monitor 使用的组件满足 Azure 符合性要求。 可以通过阅读 Microsoft 信任中心合规性了解详细信息。
注意
在部分认证/证明中，Azure Monitor 日志使用其以前的名称 Operational Insights 列出。
云计算安全数据流
下图将云安全体系结构显示为公司的信息流以及信息移动到 Azure Monitor（最终在 Azure 门户中呈现）时如何确保它的安全。 有关每一步的详细信息，请遵循该图所示。
1. 注册 Azure Monitor 并收集数据
要使组织能够将数据发送到 Azure Monitor，请配置在 Azure 虚拟机中运行的，或者在自己环境或其他云提供程序中的虚拟机或物理机上运行的 Windows/Linux 代理。 如果使用 Operations Manager，请通过管理组配置 Operations Manager 代理。 用户（可能是你、其他个别用户，也可能是一组用户）会创建一个或多个 Log Analytics 工作区，并使用以下帐户之一注册代理：
在 Log Analytics 工作区中对数据进行收集、聚合、分析和呈现。 工作区主要用作划分数据的一种方式，每个工作区都是唯一的。 例如，可能希望生产数据受一个工作区管理，测试数据受另一个工作区管理。 工作区还有助于管理员控制用户对数据的访问。 每个工作区可以有多个与它关联的用户帐户，每个用户帐户可以访问多个 Log Analytics 工作区。 基于数据中心区域创建工作区。
对于 Operations Manager，Manager 管理组会与 Azure Monitor 服务建立连接。 然后，可以配置允许管理组中的哪些代理托管系统收集数据以及向服务发送数据。 根据已启用的解决方案，这些解决方案的数据可直接从 Operations Manager 管理服务器发送到 Azure Monitor 服务，或者出于在代理管理系统上收集的数据量，直接从代理发送到服务。 对于不受 Operations Manager 监视的系统，每个系统可以安全地直接连接到 Azure Monitor 服务。
会对已连接系统与 Azure Monitor 服务之间的所有通信进行加密。 TLS (HTTPS) 协议用于加密。 遵循 Microsoft SDL 过程，已确保 Log Analytics 是最新的，加密协议也是最新的。
每种类型的代理都会收集 Azure Monitor 的日志数据。 收集的数据类型取决于工作区的配置及 Azure Monitor 的其他功能。
2.从代理发送数据
将所有代理类型注册到加密密钥，会在代理和 Azure Monitor 之间使用基于证书的身份验证和 TLS 以及端口 443 建立安全连接。 Azure Monitor 使用机密存储生成和维护密钥。 私钥每隔 90 天会进行轮换、存储在 Azure 中，并受遵循严格的法规和合规性操作的 Azure Operations 管理。
借助 Operations Manager，注册到 Log Analytics 工作区的管理组可与 Operations Manager 管理服务器建立安全 HTTPS 连接。
对于在 Azure 虚拟机上运行的 Windows 或 Linux 代理，只读存储密钥用于读取 Azure 表中的诊断事件。
由于任何代理会向与 Azure Monitor 集成的 Operations Manager 管理组报告，因此，如果管理服务器出于任何原因无法与该服务通信，收集的数据将存储在管理服务器本地的临时缓存中。 管理服务器尝试在两小时内每隔八分钟重新发送数据。 对于绕过管理服务器直接发送到 Azure Monitor 的数据，行为与 Windows 代理一致。
Windows 或管理服务器代理缓存的数据受操作系统的凭据存储的保护。 如果服务在两小时后无法处理数据，代理会将该数据加入队列。 如果队列已满，代理会开始丢弃数据类型，从性能数据开始。 代理队列限制是一个注册表项，因此必要时可以对它进行修改。 向服务发送（绕过 Operations Manager 管理组数据库）已收集的数据时会先对数据进行压缩，因此不会向数据库添加任何负载。 已收集的数据完成发送后，会从缓存中删除它。
如上所述，来自管理服务器或直连代理的数据通过 TLS 发送到 Azure 数据中心。 可以选择使用 ExpressRoute 为数据提供额外的安全性。 借助 ExpressRoute，可以从网络服务提供商提供的现有 WAN 网络（例如多协议标签交换 (MPLS) VPN）直接连接到 Azure。 有关详细信息，请参阅 ExpressRoute 和代理流量是否使用 Azure ExpressRoute 连接？。
3. Azure Monitor 服务接收并处理数据
Azure Monitor 服务通过使用 Azure 身份验证对证书和数据完整性进行验证，来确保传入数据来自受信任的源。 然后，将未处理的原始数据存储在最终将静态存储该数据的地区中的 Azure 事件中心内。 存储的数据类型取决于导入的并用于收集数据的解决方案的类型。 然后，Azure Monitor 服务处理原始数据并将其引入数据库。
存储在数据库中的已收集数据的保留期取决于所选的定价计划。 对于“免费”层，收集的数据可以使用 7 天。 对于付费层，收集的数据默认情况下可以使用 31 天，但可以延长到 730 天。 数据在 Azure 存储中采用静态加密存储，以确保数据机密性，数据通过本地冗余存储 (LRS) 或支持的区域中的区域冗余存储 (ZRS) 在本地区域内进行复制。 过去两周的数据也存储在基于 SSD 的缓存中，此缓存未加密。
数据库存储中的数据在引入后将无法更改，但可以通过“清除”API 路径将其删除。 尽管该数据无法更改，但某些认证要求数据保持不可变且不能在存储中更改或删除。
4. 使用 Azure Monitor 访问数据
若要访问 Log Analytics 工作区，请使用组织帐户或先前设置的 Microsoft 帐户登录到 Azure 门户。 门户与 Azure Monitor 服务之间的所有流量通过安全 HTTPS 通道发送。 使用门户时，会在用户客户端（Web 浏览器）上生成会话 ID，会将数据存储在本地缓存中，直到该会话终止。 终止后，会删除该缓存。 不会自动删除不包含个人身份信息的客户端 Cookie。 会话 Cookie 标记为 HTTPOnly，并且受到保护。 在预先确定的空闲期过后，会终止 Azure 门户会话。
客户管理的安全密钥
使用 Azure 管理的密钥对 Azure Monitor 中的数据进行加密。 可以使用客户管理的加密密钥来保护工作区中的数据和保存的查询。 Azure Monitor 中的客户管理的密钥使你能够更灵活地管理对日志的访问控制。
配置后，引入到链接工作区的新数据会使用 Azure 密钥保管库或 Azure 密钥保管库托管的“HSM”中存储的密钥进行加密。
专用链接网络
使用 Azure 专用链接网络，你可以通过专用终结点将 Azure 平台即服务 (PaaS) 服务（包括 Azure Monitor）安全地链接到虚拟网络。
防篡改和不可变性
Azure Monitor 是一个追加型数据平台，但其中包含出于合规性目的删除数据的预配。 可以在 Log Analytics 工作区上设置锁定，以阻止可能删除数据的所有活动：清除、表删除以及表级或工作区级数据保留更改。 但是，仍可删除此锁。
为了完全防止监视解决方案被篡改，建议将数据导出到不可变存储解决方案。
常见问题
本部分提供常见问题的解答。
代理流量是否使用 Azure ExpressRoute 连接？
到 Azure Monitor 的流量使用 Microsoft 对等互连 ExpressRoute 线路。 有关不同类型的 ExpressRoute 流量的说明，请参阅 ExpressRoute 文档。