Azure Arc Kubernetes 和服务器教程（二）

最新推荐文章于 2025-11-05 10:39:20 发布

原创最新推荐文章于 2025-11-05 10:39:20 发布 · 534 阅读

9 ·

CC 4.0 BY-SA版权

License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译

文章标签：

#VKDoc

VKDoc 专栏收录该内容

2045 篇文章

订阅专栏

原文：Azure Arc-Enabled Kubernetes and Servers

协议：CC BY-NC-SA 4.0

六、混合服务器监控解决方案

本章描述了基于 Azure Monitor 平台服务的独立端到端服务器监控解决方案。前几章帮助你构建了基于 Azure 的管理框架；现在我们用它做一些有价值的、划算的事情。该解决方案为 Azure 订阅中的 Azure 虚拟机和 Azure Arc 服务器提供服务器基础架构监控。当受监控的服务器停机或出现严重问题时，该解决方案会通知您的团队。

该解决方案包含一组 Azure 微服务，用于探测和评估服务器操作系统的可用性、配置和性能。它在监控核心服务器功能(可用性、配置和性能)方面与现有的行业标准工具不相上下。作为一个云原生解决方案，通过新颖的 Azure Connected Machine Agent(Azure Arc)将云框架扩展到非云端点，这是无与伦比的。

该解决方案代表了一种新的行业范式:通过免费的云服务管理平台提供合适的低成本服务器监控。该解决方案提供无限的规模和全球可用性。成功地从更昂贵的遗留应用中迁移服务器监控工具的组织将获得竞争优势。

解决方案高级功能

将解决方案架构视为具有三个主要特性:管理控制平面、规则集和通知工作流。下面将描述这些功能，以及解决方案中构成该功能的 Azure 服务。

提供监控、安全、访问和治理的管理控制平面
- 蔚蓝灯塔和蔚蓝商业市场
- Azure Arc 和 Azure 资源管理器(ARM)
- Azure 策略
- Azure 虚拟机扩展
- 微软管理代理(MMA)/Azure 管理代理(AMA)
一组从托管计算机收集和分析数据的监视器和规则
- Azure 日志分析
- Azure VM Insights 来宾运行状况
- Azure 自动化(更新和配置管理)
- Azure 计划查询警报规则
响应警报的方法，例如执行自动化工作流和向票务系统发送警报通知
- Azure 警报操作组
- Azure 警报操作规则
- Azure 逻辑应用

监视什么:部署在此解决方案中的一组经过管理的监视器和规则—可从 Azure Monitor 实现有效的服务器操作系统监视—包括检测来自 Windows Server OS 的 System Center Operations Center(SCOM)管理包中包含的规则和警报生成监视器的最常见警报。

成本:交付特定监控服务的 Azure 消耗成本可以估计为每台服务器每月 5 美元。这一估计符合 Azure pricing calculator 的建议，即大多数服务器每月产生 1 GB 到 3 GB 的日志摄取量(在较便宜的地区 1.30 美元= 1 GB，在较贵的地区 5.10 美元= 3 GB)。根据您所在的市场和货币，每台服务器 5 美元是一个保守且有效的整数。

解决方案图

图 6-1 展示了交付解决方案特性的 Azure 服务。以下是图表的可视化指南:

img/506033_1_En_6_Fig1_HTML.png

图 6-1

由 Azure Arc 和 Azure Policy 支持的 Azure 监控解决方案

从右下方开始， Azure AD 用户或 Azure Lighthouse 服务提供商安全组是将访问 Azure 订阅的身份。
Azure RBAC (基于角色的访问控制)用于将 Azure AD 用户与 Azure 订阅中的安全角色相关联。在 Azure Lighthouse 场景中，客户接受了将服务提供商员工与客户 Azure 订阅中的委托安全权限相关联的提议。
授权用户或服务主体使用他们的 RBAC 或委托访问权将 Azure 策略分配给 Azure 虚拟机和 Azure Arc 服务器。
该策略使计算机受到使用 MMA 的 Azure Monitor (中间)的监控，并将它们连接到日志分析工作区(中间右侧)。
Azure VM Extensions 安装 AMA，并将虚拟机连接到虚拟机来宾运行状况监视器(中间左侧)。
继续向左，虚拟机客户健康 警告和紧急状态变化触发逻辑应用的启动，其有条件地创建警报通知(红色三角形)。
警报规则(左上)按计划运行，寻找指示问题的日志或度量数据。
Azure Monitor 警报操作规则选择性地抑制由预定警报规则(左上角)产生的警报**；这就是您如何解决计算机特定的预设警报规则覆盖问题。**
从中间向右侧移动，安装在日志分析工作区的日志分析解决方案包括与 Azure Automation 账户的链接。
自动化帐户中的解决方案包括更新管理(右上)和配置管理解决方案(上中)。

特定监控功能

回答问题该解决方案监控什么？，提供以下具体列表。监视器和警报选项以及警报阈值源自 Windows Server SCOM 管理包的默认监视配置文件。

规则和监控列表

Azure Monitor 心跳失败(最近 5 分钟内两次或更少的心跳)。
逻辑磁盘传输(读取和写入)延迟太高。
每秒内存页数太高。
逻辑磁盘可用空间不足。
可用内存太低。
总 CPU 利用率百分比太高。
逻辑磁盘当前队列长度太长。
服务进入不可预测的状态。
检测到重复的 IP 地址。
NTFS —文件系统损坏。
在计算机上检测到恶意软件威胁。
检测到意外关机。
一项核心 Windows 服务已停止(监视 12 项特定服务)。
以前运行的 Windows 服务已经停止。

除了向规则和监控列表中的产品发出警报之外，该解决方案还部署了以下高价值产品:

Azure Automation 更新解决方案在所有位置的所有 Windows 和 Linux 服务器上提供特定于服务器和整个组织的已安装和缺失/需要的更新视图。
Azure Automation 配置管理解决方案对软件、文件系统、Windows 注册表、Windows 服务器和 Linux 守护进程执行检查。记录更改，自动显示更改检测前后的读数。
安装 Azure Monitor 工作簿是为了在当前、趋势和历史可用性和性能数据中提供基于图表的可视化帮助。工作簿可以部署为 Azure 仪表板，用于管理显示。

蔚蓝灯塔

Azure Lighthouse 是专门为服务提供商创建的，但它也适用于拥有多个 Azure AD 租户的大型组织。在企业和学术场景中，“共享服务”或“教师”所在的租户可以使用“服务提供商”灯塔委托来无缝管理其他 Azure AD 租户(如“客户”下属、“学生”或合作伙伴公司)拥有的 Azure 订阅。

Azure Lighthouse 允许一对多的方法，服务提供商员工和 Azure 工件，如监控规则和 ARM 模板，在许多客户租户之间共享。也就是说，一个 Azure AD 租户(服务提供商)获得对属于不同租户(客户)的 Azure 订阅的委托权限。当服务提供商向客户提供“优惠”时，就会发生这种情况。然后，客户接受该提议，并将他们的订阅和/或资源组委托给服务提供商租户中存在的并且在提议中指定的特定 Azure AD 安全组。

Azure Lighthouse 提供了一种可撤销的、单向的、可验证的、细粒度的信任，它消除了每个服务提供商员工在客户域中存在重复帐户(或者更糟，共享帐户)的需要。客户审计日志显示在客户订阅中有活动的服务提供商员工的实际姓名。如果服务提供商对所有员工登录强制实施多因素身份验证(MFA ),该解决方案允许服务提供商保证只有 MFA 访问发生在客户资源上。

在本章描述的解决方案中，任何 Azure Lighthouse 的参与都是可选的。然而，如果使用 Azure Lighthouse，该解决方案对于所有多租户监控场景都完全有效。

弧蓝

在最初的 Microsoft Azure“经典”或原始 Azure 数据中心结构控制器取得成功后，发现了扩展和其他限制。微软必须发明一种方法来管理和协调超大规模的全球 Azure 云。由此产生的“V2”技术被称为 Azure 资源管理器(ARM)，有时也被称为 Azure 控制平面，它为今天的所有 Azure 提供动力。把 ARM 想象成 Azure 自己的操作系统，即“主控制器”。我们使用以 JSON 格式编写的文档与 ARM 进行基本通信，也称为 ARM 模板。

ARM 在管理 IT 对象和服务方面被证明是超可扩展和高度可靠的。Azure Arc 是一个新概念的名称，它将 ARM 的规模经济和优势扩展到 Azure 之外的对象。在这个解决方案中，Azure Arc 服务器对象是在 Azure 订阅中创建的，对于 ARM 来说，它类似于 Azure 虚拟机。对于 ARM，两个对象都是计算机，并且计算机管理范例可以跨环境应用。由于 Azure Arc，ARM 可以将 Azure 监控计算机的策略应用于 Azure 虚拟机和非 Azure 服务器。

从管理的角度来看，Azure Arc 使非云服务器变得模糊。经济意义在于，使用 Azure Arc 管理非云服务器将产生成本效益。这些好处来自免费使用 Azure 管理功能，如策略、标签和资源组—，以及消费(或交付)其他云服务，如监控、安全和备份，几乎没有附带或中间“管理工具”成本。

Azure Arc 服务器

正如我们在第四章第四章“Azure Arc 服务器:入门”中所介绍的，Azure Arc 在非 Azure 计算机—上安装了一个应用，即用于非 Azure 计算机—的Azure Connected Machine Agent，它与默认情况下在每个 Azure 虚拟机上运行的 in-AzureWindows Azure Guest Agent执行相同的功能。Windows Azure Guest Agent 本质上是一个用于管理 Azure VM 的带外管理通道。Windows Azure 访客代理为 Azure VM 做的主要事情是安装和维护 Azure VM 扩展，这些扩展是实际执行监控工作的小程序和服务。Azure Arc 的 Azure Connected Machine 代理为非 Azure 计算机做同样的事情。Azure Arc 代理将非 Azure 服务器作为混合机器对象连接到 Azure 控制平面。

在此解决方案中，您不需要在服务器上安装监控代理。相反，你可以在非 Azure 服务器上安装 Azure Arc 代理。然后配置 Azure 策略，通过 Azure Arc 在计算机上安装监控代理。Azure 策略补救任务实际上使用 Azure AD 中的服务主体安装监控代理，该服务主体是在分配策略时创建的。在图 6-2 中，此 Windows 服务器上列出的所有管理应用都是由第一个列出的代理 Azure Arc 代理(Azure Connected Machine Agent)安装或验证的。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-2

此 Azure Arc 服务器上的 Azure Connected Machine 代理使用 Azure VM 扩展安装了其他程序

Azure Arc 服务器是使用运行在被装载的服务器上的脚本注册的。脚本登录到运行 onboarding 脚本的个人或服务主体的 Azure AD 租户。然后，如果个人或服务具有适当的安全访问权限，则会在指定的 Azure 订阅、资源组和 Azure 区域中创建 Azure Arc 服务器的 ARM 资源记录(ARM 对象)。Azure Arc 服务器被静默地颁发一个数字证书，该证书充当计算机对 Azure 的唯一身份提供者。

Azure 策略

Azure 策略在 Azure 虚拟机和 Azure Arc 服务器之间一致地应用监控和管理设置。具体来说，在该解决方案中，所有位置的所有 Windows 和 Linux 服务器—和云—都通过同一个策略计划来评估其对核心监控目标的合规性。当服务器准备好开始被监控时，部署一个 Azure Policy initiative，将服务器连接到订阅中的 Azure Monitor 实例(图 6-3 )。

核心监控目标是通过在每台计算机上安装两个软件，将每台计算机连接到选定的 Azure Log Analytics 工作区:(1)微软监控代理(MMA)和(2)依赖代理。依赖代理补充了 MMA，并为 VM Insights 中的服务地图集成提供了网络级信息。

img/506033_1_En_6_Fig3_HTML.jpg

图 6-3

Azure Policy 向所有位置的所有服务器推出启用 Azure 虚拟机监控策略计划

有一个内置的 azure policy initiativeenable azure monitor for****VM(策略➤创作➤定义)捆绑了十个策略。八项政策能够部署不存在的补救任务:

将日志分析代理部署到 Windows Azure Arc 计算机。
部署—将日志分析代理配置为在 Windows 虚拟机上启用。
将日志分析代理部署到 Linux Azure Arc 机器。
为 Linux 虚拟机部署日志分析代理。
将依赖关系代理部署到 Windows Azure Arc 计算机。
部署-配置要在 Windows 虚拟机上启用的依赖关系代理。
将依赖代理部署到混合 Linux Azure Arc 机器上。
为 Linux 虚拟机部署依赖关系代理。
两个策略属于 AuditifNotExist 类型，用于在发现非标准 Azure VM 映像类型时进行标记，否则会阻止自动补救。
应为列出的虚拟机映像启用日志分析代理。
应为列出的虚拟机映像启用依赖关系代理。

Azure 策略分配

Enable Azure Monitor for VMs 计划分配给订阅和/或资源组，是在所有计算机上推送安装和集中配置 MMA 和依赖代理的主要工具。如果计算机不符合核心监控目标，这样做还可以检测配置漂移。

在分配计划时，会创建一个托管身份，这是一个 Azure AD Enterprise 应用注册(服务主体)。服务主体被自动授予 Azure 订阅或资源组中的日志分析贡献者角色。服务主体将有一个随机显示名称，如“27c1377f005d47578cecc397”。

您可以通过返回编辑方案分配来定位服务主体名称；在补救选项卡上是主体 ID 框，带有 GUID，如“75943696-0879-432d-98e 6-AE 0aa 439 ed 05”。该 GUID 与企业应用的对象 ID(服务主体)相匹配。您可以使用 Azure PowerShell 命令 Get-AzADServicePrincipal 将该对象 ID 交叉引用回 Azure AD 服务主体的名称(通过输出进行了演示):

PS /home> Get-AzADServicePrincipal -ObjectId 75943696-0879-432d-98e6-ae0aa439ed05

ServicePrincipalNames : {57aa357a-8f37-44c5-8fb5-ade220354465, https://identity.azure.net/TzdI8YgzhpY339TyesufBsnmeXGgqUM56HhUnrT8S2k=}
ApplicationId         : e0ba357a-8f37-44c5-8fb5-ade220354564
ObjectType            : ServicePrincipal
DisplayName           : 27c1377f005d47578cecc397
Id                    : 75943696-0879-432d-98e6-ae0aa439ed05

要使修复任务正常工作，服务主体的显示名称应位于订阅或资源组➤访问控制(IAM) ➤角色分配中的日志分析贡献者下。

Azure 策略实施间隔

以下是将导致策略资源被评估的时间或事件:

在具有策略分配的范围内创建、更新或删除资源。
策略或计划被新分配给一个范围。
更新已经分配给范围的策略或计划。
在每 24 小时一次的标准符合性评估周期中。

Tip

您可以使用以下 Azure PowerShell 命令在资源组中触发按需 Azure 策略实施:

Start-AzPolicyComplianceScan -ResourceGroupName '<rgname>' -AsJob

Azure 策略合规性

Azure 策略分配的目标是通过补救任务和可选豁免的组合实现 100%的合规状态(图 6-4 )。当低于 100%合规状态时，不合规的特定计算机和策略的列表可在策略➤合规➤倡议➤不合规资源中找到。

不符合的资源列表是解决方案部署期间的工作列表，用于识别需要补救的计算机。部署解决方案后，监控合规性保持在 100%,当计算机和策略不合规时，采取必要措施恢复 100%合规性。

img/506033_1_En_6_Fig4_HTML.png

图 6-4

在资源组中 100%合规的情况下启用 Azure Monitor for VMs 策略计划

Azure 策略:补救任务

将 Enable Azure Monitor for VMs 计划分配给订阅或资源组后，新创建的资源(Azure VMs 和 Azure Arc 服务器)如果不符合，将自动进行补救。为现有资源创建修复任务，将必要的代理推送到各自的目标。大多数服务器不会为目标日志分析工作区安装和配置 Microsoft 管理代理(MMA)或依赖关系代理。事实上，Azure Policy 对于预先存在的资源是一个两步过程:分配策略来识别不符合的资源，然后启动补救任务来修复问题。

遵循此协议使用 Azure 策略部署解决方案:

在策略➤合规性方面，选择为虚拟机启用 azure monitor】计划。
点击创建修复任务。
对于要修复的策略，选择为 Windows 虚拟机部署日志分析代理。
请确保范围正确(一台计算机、一个资源组或一个订阅)。
请在补救前检查重新评估资源符合性。
推补救。
从步骤 2 开始重复，并选择为 Windows 虚拟机部署依赖代理。
重复步骤 4、5 和 6。
如果合适，再次从步骤 2 开始重复为 Linux 虚拟机部署日志分析代理，然后为 Linux 虚拟机部署依赖代理。
在第一波修复任务之后，对故障进行分类和修复，根据需要重复修复任务，直到所有计算机都符合要求。视情况创建例外(下一章介绍)以提高合规百分比。

未列出的图像

当 ARM 不知道虚拟机操作系统磁盘的确切来源时，默认策略对不符合的进行“故障保护”。如果某些计算机标记了未列出的的虚拟机映像(OS)的审计策略，则有必要克隆内置方案，并为日志分析代理和依赖关系代理策略创建带有自定义策略的自定义方案。自定义策略将添加您组织的自定义 osDisk.creationOption 值，以便策略接受并继续修复。

例如，以下 JSON 代码在拼接到的"policyRule":部分时，将允许使用附加和上传的磁盘映像:

              {
                "allOf": [
                  {
                    "field": "Microsoft.Compute/virtualMachines/storageProfile.osDisk.createOption",
                    "equals": "Attach"
                  }
                ]
              },
              {
                "allOf": [
                  {
                    "field": "Microsoft.Compute/virtualMachines/storageProfile.osDisk.createOption",
                    "equals": "FromImage"
                  }
                ]
              },

多个管理组

如果 MMA 代理在修复任务期间由于多个管理组而出现故障，您可以使用 Azure PowerShell/Cloud Shell 手动安装 MMA 的 VM 扩展。以下示例自定义脚本添加了" " stoponmultipleconconnections " = $ false "标志。

     Connect-AzAccount

     $PublicSettings = @{"workspaceId" = " fd75fd75-f70c-4fe5-bd39-afa5f70cafa5";"stopOnMultipleConnections" = $false}
     $ProtectedSettings =@{'workspaceKey' = 1234abcdxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1234abcd=='}

     Set-AzVMExtension -ResourceGroupName "MyResourceGroup" `
     -VMName "MyAzureVM" `
     -Publisher Microsoft.EnterpriseCloud.Monitoring `
     -ExtensionType MicrosoftMonitoringAgent  `
     -TypeHandlerVersion 1.0 `
     -Settings $PublicSettings `
     -ProtectedSettings $ProtectedSettings `
     -Location "eastus2 `
     -Name MicrosoftMonitoringAgent

对于 Azure Arc 服务器，如果有大量计算机需要修改的 VM 扩展安装策略，请克隆内置策略，并为日志分析代理创建一个带有自定义策略的自定义方案。用以下代码替换策略的内置“资源”部分:

                "resources": [
                  {
                    "name": "[concat(parameters('vmName'), '/', variables('vmExtensionName'))]",
                    "type": "Microsoft.HybridCompute/machines/extensions",
                    "location": "[parameters('location')]",
                    "apiVersion": "2019-12-12",
                    "properties": {
                      "publisher": "[variables('vmExtensionPublisher')]",
                      "type": "[variables('vmExtensionType')]",
                      "settings": {
                        "workspaceId": "[reference(parameters('logAnalytics'), '2015-03-20').customerId]",
                        "stopOnMultipleConnections": "false"
                      },
                      "protectedSettings": {
                        "workspaceKey": "[listKeys(parameters('logAnalytics'), '2015-03-20').primarySharedKey]"
                      }
                    }
                  }
                ],

Azure 策略:豁免

可以将策略分配给将始终报告不符合的计算机，但是在计算整体策略符合性时，给定细节不应减少不符合的计算机计数。换句话说，放弃政策。

遵循此协议从分配的 Azure 策略中豁免计算机:

在“策略➤合规”中，选择“为虚拟机启用 Azure Monitor”计划。
点击不合规资源。
找到要豁免的计算机并点击创建豁免按钮。
确保豁免范围(一台计算机)正确。
视情况选择弃权或减轻。
输入票号等备注，点击审核+创建，然后点击创建。

Azure 日志分析

单一日志分析工作区是该解决方案的重点。所有的监控工件都指向指定的工作区。许多 Azure 日志分析解决方案被安装在工作空间中，为解决方案做出贡献(图 6-5 ):

评价
复制
代理健康评估
ChangeTracking(由 Azure Automation 更改跟踪自动安装)
脱氧核糖核酸分析
逻辑管理
安全
服务地图
SQL 脆弱性评估
更新(由 Azure 自动化更新解决方案自动安装)
VMInsights(通过将日志分析工作区与 VM Insights 链接来自动安装)

需要手动安装的解决方案如下所示。按照以下步骤添加解决方案:

img/506033_1_En_6_Fig5_HTML.jpg

图 6-5

安装了推荐解决方案的 Azure 日志分析工作区的概述页面

在日志分析工作区➤➤综合工作区概要，点击添加按钮。
在 Marketplace，在搜索栏中粘贴解决方案的确切名称:
1. Active Directory 运行状况检查
2. AD 复制状态
3. Azure 日志分析代理运行状况
4. DNS 分析
5. 逻辑应用管理
6. 安全和审计
7. 服务地图
8. SQL 漏洞评估
找到解决方案，然后单击“创建”按钮。
选择日志分析工作区，然后再次单击创建。

日志分析工作区附加配置

在 Azure Log Analytics 工作区中安装解决方案后，还有对 Azure Log Analytics 代理配置的额外定制。为了进行有效的监控，有必要收集常见的事件日志(系统和应用)以及选定的附加磁盘和内存性能计数器。此外，您将确认工作区数据的保留期。

Windows 事件日志

在日志分析工作区➤设置➤代理配置➤窗口事件日志中，添加包含所有优先级事件的应用和系统日志(图 6-6 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-6

要收集的 Windows 事件日志

Windows 性能计数器

在日志分析工作区➤设置➤代理配置➤ Windows 性能计数器，添加如图 6-7 所示的设置。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-7

收集这些额外的 Windows 性能计数器

或者，以下 Azure PowerShell 示例脚本(Add-PerfCounters.ps1)将创建 Windows 性能计数器:

Add-PerfCounters.ps1

$ResourceGroup = "MyResourceGroup"
$WorkspaceName = "MyWorkspace"
New-AzOperationalInsightsWindowsPerformanceCounterDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "LogicalDisk" -InstanceName "*" -CounterName "Avg. Disk sec/Transfer" -IntervalSeconds 60 -Name "LogicalDisk(*)\Avg. Disk sec/Transfer"
New-AzOperationalInsightsWindowsPerformanceCounterDataSource-ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "LogicalDisk" -InstanceName "*" -CounterName "Current Disk Queue Length" -IntervalSeconds 60 -Name "LogicalDisk(*)\Current Disk Queue Length"
New-AzOperationalInsightsWindowsPerformanceCounterDataSource-ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "Memory" -InstanceName "*" -CounterName "Pages/sec" -IntervalSeconds 60 -Name "Memory(*)\Pages/sec"

数据保持

确认 Azure Log Analytics 数据的保留期符合您的预期。在默认服务中，日志将免费保留 31 天。如果选择更长的保留时间，请在日志分析工作区➤常规➤使用和估计成本➤数据保留中进行设置。(Microsoft Sentinel 包括 90 天的免费保留期。)保留数据的时间超过包含/免费保留期将产生额外的每月 Azure 订阅费用。

Tip

下面是一些估算长期保留额外成本的经验法则:

Azure 日志分析:

每月增加 50%以保留 1 年，而不是 31 天。例如:每月 100 美元保留 31 天，每月 150 美元保留 1 年

微软哨兵:

与 90 天相比，保留 1 年每月增加 20%的成本。例如:每月 1000 美元保留 90 天，每月 1200 美元保留 1 年

日志分析工作区中数据的最长保留期为 730 天(2 年)。虽然您的数据保留在工作区存储库中，但它会像当前数据一样在报告中被查询和使用。如果您的数据保留需求超过 2 年，支持的解决方案是启用从日志分析到 Azure 存储帐户或 Azure 事件中心的连续数据导出。有关其工作原理的详细信息，请访问以下 URL:

https://docs.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export

Azure 自动化

创建 Azure Automation 帐户时，会创建一个“Azure 运行方式帐户”作为 Azure AD 中的服务主体，并授予订阅的参与者角色。在自动化帐户➤帐户设置➤运行方式帐户中检查 Azure 运行方式帐户的状态。服务主体应该在 Azure 订阅中分配有 Contributor 角色。

作为一次性活动，将 Azure Automation 帐户链接到日志分析工作区➤相关资源➤自动化帐户的 Azure 日志分析工作区。

将 Azure Automation 帐户链接到 Azure Log Analytics 工作区后，为所有可用和未来的机器启用更新管理和库存解决方案，如图 6-8 所示。

img/506033_1_En_6_Fig8_HTML.png

图 6-8

为所有可用和未来的计算机启用 Azure Automation 更新管理解决方案

当一台计算机注册 Azure 自动化解决方案时，会为每台计算机悄悄地创建一个系统混合工作组。系统混合工作者组的名称类似于my computer . my domain . com _ 4 fcd 9932-4206-4 fcd-8842-4 fcd 63874 fcd。该混合工作器被授权在受监控的计算机上运行，以便收集清单、更改和更新数据，并在该选项打开的情况下安装更新。

Azure 监视器

在这个解决方案中，Azure Monitor 的两个方面用于监控服务器。这些是计划的警报规则和 Azure VM 来宾运行状况监视器。规则和监视器一起是解决方案中的主动传感器。

Azure Monitor 操作组

在导入选择的预定警报规则之前，会创建一个 Azure Monitor 操作组来接收警报并对其执行通知。导入警报规则时，会指定此操作组的名称，因此它必须在导入警报规则之前存在。

操作组:默认-预警-操作

操作组创建如下:

日志分析工作区➤监控➤警报➤管理操作➤添加操作组。
对于名称，输入默认警报操作。
对于简称，输入默认名称。
创建电子邮件类型的通知操作。
添加通知端点的电子邮件地址。
选择“是”以启用通用警报模式。
单击确定。
点击保存更改。

图 6-9 摘自 Azure Monitor 电子邮件提醒产品；这是一个计算机心跳停止的例子。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-9

Azure Monitor 发送的电子邮件警报通知的主题和正文摘要

操作组:VM Insights 运行状况警报

创建第二个操作组 VM Insights Health Alert 来启动一个逻辑应用，该应用对 Azure VM Health monitor 警报进行后处理。在创建了逻辑应用Azure-Monitor-Guest-Health-Alerting之后，将在解决方案部署的后期创建该组。动作组只有一个动作:触发逻辑应用。

Azure Monitor 计划的警报规则

计划的监控警报规则定期运行(从每 5 分钟一次到每天一次),并在日志数据中查看是否存在警告或严重警报指示器，或者是否存在正常数据指示。该解决方案包括 12 个定时预警规则(表 6-1 )。图 6-10 和 6-11 展示了实际应用中的解决方案，显示了活跃环境中一天的警报流量。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-11

所有警报列表包括平台指标和日志分析日志警报

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-10

Azure 门户中的 Azure Monitor 警报控制台

表 6-1

Azure Monitor 计划的警报规则

名字

类型/频率

情况

|
| — | — | — |
| Azure Monitor Heartbeat Failure | Metric``5m @ 1m | Whenever the total heartbeat is less than or equal to 2 [in 5 minutes] |
| Logical Disk Current Queue Length is too High | Metric``15m @ 1m | Whenever the average average_current disk queue length is greater than 32 |
| Logical Disk Transfer (reads and writes) Latency is too High | Metric``15m @ 1m | Whenever the average average_avg. disk sec/transfer is greater than 0.04 |
| Memory Pages Per Second is too High | Metric``1h @ 5m | Whenever the average average_pages/sec is greater than 5000 |
| (Core Windows Services Rollup) A service has stopped | Log``5m @ 5m | ConfigurationData | where SvcState == "Stopped" | where SvcName == "Browser" or SvcName == "DHCP" or SvcName =="DNSCache" or SvcName == "PlugPlay" or SvcName == "RpcSs" or SvcName == "lanmanserver" or SvcName == "LmHosts" or SvcName == "Eventlog" or SvcName == "MpsSvc" or SvcName == "WinRM" or SvcName == "Lanmanworkstation" | where SvcStartupType != "Disabled" |
| A previously running Windows service has stopped | Log``5m @ 5m | ConfigurationChange | where ConfigChangeType contains "WindowsServices" | where SvcStartupType contains "Auto" | where SvcState contains "Stopped" | where SvcPreviousState contains "Running" | where SvcName !in ("IaasVmProvider","edgeupdate","RemoteRegistry","sppsvc","TrustedInstaller","wuauserv") |
| A Service has Entered into an Unpredictable State | Log``5m @ 5m | Event | where (EventLog == "System" and Source == "Service Control Manager") and (EventID == 7030 or EventID == 7037) | project Computer, TimeGenerated, AlertType_s = "A Service has Entered into an Unpredictable State", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = Computer, AlertTitle_s = strcat(Computer, ": A Service has Entered into an Unpredictable State"), AlertDetails_s = strcat("Event Description:", RenderedDescription) |
| Duplicate IP Address has been Detected | Log``5m @ 5m | Event | where ( EventLog == "System" and Source == "Tcpip" ) and ( EventID == 4198 or EventID == 4199 ) | project Computer, TimeGenerated, AlertType_s = "Duplicate IP Address has been Detected", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = Computer, AlertTitle_s = strcat(Computer, ": Duplicate IP Address has been Detected"), AlertDetails_s = strcat("Event Description:", RenderedDescription) |
| Malware threat detected on computer (Defender) | Log``10m @ 10m | ProtectionStatus | summarize ThreatStatusRank=max(ThreatStatusRank) by Computer, Time=bin(todatetime(DateCollected), 10m) | summarize(Time, ThreatStatusRank) = argmax(Time, ThreatStatusRank) by Computer | where ThreatStatusRank !in (150, 470) | project Computer, Rank = ThreatStatusRank |
| NTFS - File System Corrupt | Log``30m @ 30m | Event | where EventLog == "System" and Source == "DISK" or Source == "Ntfs" and EventID == 55 | project Computer, TimeGenerated, AlertType_s = "NTFS - File System Corrupt", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = Computer, AlertTitle_s = strcat(Computer, ": NTFS - File System Corrupt"), AlertDetails_s = strcat("Event Description:", RenderedDescription) |
| One or more previously seen agents is unresponsive | Log``2h @ 2h | Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(24h) |
| Unexpected shutdown | Log``1d @ 1d | Event | where EventLog == "System" and EventID == 6008 | project Computer, TimeGenerated, AlertType_s = "Unexpected shutdown", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = strcat(Computer), AlertTitle_s = strcat(Computer, ": Unexpected Shutdown"), AlertDetails_s = strcat("Multiple shutdowns detected in the past 24 hours EventID: 6008 Event Description: ", RenderedDescription) |

Azure Monitor 计划警报规则可以使用表 6-1 中的信息手动创建为 KQL 查询，或者使用 ARM 模板导入到 Azure 订阅中。在以下 URL 查找示例 KQL 查询，以粘贴到您可能创建的预定警报规则中:

https://github.com/microsoft/AzureMonitorCommunity

图 6-12 显示了导入后在 Azure Log Analytics 工作区中运行的解决方案规则。

img/506033_1_En_6_Fig12_HTML.png

图 6-12

Azure Monitor 计划警报规则在环境中执行监控

使用 ARM 模板进行规则管理

您可能会发现创建一个预定警报规则库来导入 Azure Log Analytics 非常方便。Azure Monitor 可以使用 ARM 模板进行大规模部署和配置。每个警报规则都可以作为 ARM 模板/参数文件对导入。以下 URL 提供了不同 Azure Monitor 功能的示例模板，可以根据您的特定需求进行修改:

https://docs.microsoft.com/en-us/azure/azure-monitor/resource-manager-samples

创建可重复使用的警报规则模板库

GitHub Management toolkit URL 包含导入许多常见警报规则定义的指令，其中许多都包含在这个 Azure 监控解决方案中。点击链接，从以下网址下载用于传统日志警报 API 的警报工具包:

https://github.com/microsoft/manageability-toolkits

考虑使用这种方法来开发您的 ARM 模板库:

将可管理性工具包中的所有可用规则导入 Azure Log Analytics。
禁用开发不需要运行的规则。
评估您将在生产中使用的规则，并将其内容导出到 ARM 模板。
删除由可管理性工具包导入 Azure Monitor 的规则。
使用 ARM 模板为基于代码的管理重新导入生产规则。
使用 ARM 模板将相同的规则集部署到其他 Azure Log Analytics 工作区，或者将它们用作监控基础架构的备份/文档。

创作预设警报规则模板

日志预警规则和度量预警规则具有不同的结构。对于规则的完整部署，您需要准备以下文件:

日志警报的模板文件
度量预警的模板文件
日志预警的模板参数文件
度量预警的模板参数文件

以下网址提供了详细说明和示例模板:

使用资源管理器模板创建日志警报

https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-log-create-templates

使用资源管理器模板创建度量预警

https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-metric-create-templates

Tip

确保在通过 ARM 模板导入规则之前，预先创建将为警报执行默认通知的 Azure Monitor 操作组。(这是本章的 Azure Monitor 操作组一节中介绍的默认-警报-操作组。)如何:在模板参数文件中指定动作组的资源组 ID，在导入预警规则时自动启用您的默认通知渠道。在参数文件中，您的操作组资源组 ID 将如下所示:

"actionGroupId": {

"value": "/subscriptions/12341234-1234-1234-1234-123412341234/resourceGroups/RG-DEV-EUS/providers/microsoft.insights/actiongroups/Default-Alert-Action"

}

部署 ARM 模板以实现监控

您可以使用任何部署资源管理器模板的标准方法来部署您的 ARM 模板(从而启用监控)。以下部分描述了使用 Azure 门户和 Azure PowerShell 将计划日志和度量警报规则的标准化版本导入 Azure Log Analytics 的方法。

使用 Azure 门户导入规则模板

导航到首页➤新➤搜索市场。
键入“template”并从下拉列表中选择模板部署(使用自定义模板部署)。点击创建。
在选择模板处，点击在编辑器中构建您自己的模板。
在编辑模板，用模板文件内容替换代码视图的全部内容，点击保存。
单击编辑参数；然后在编辑参数，用模板参数文件内容替换整个代码段，点击保存。
在自定义部署界面，选择资源组，点击查看+创建，然后点击创建。

使用 Azure PowerShell 导入规则模板

为要导入的规则准备输入模板和模板参数文件；然后使用New-AzResourceGroupDeploymentcmdlet 创建部署。此示例从文件“MonitorLogAlert-template-Core service has stopped . JSON”和“MonitorLogAlert-parameters . JSON”中导入日志规则“Core service has stopped”:

New-AzResourceGroupDeployment -Name "LogAlertDeployment" -ResourceGroupName MyResourceGroup -TemplateFile "MonitorLogAlert-template-Core service has stopped.json" -TemplateParameterFile "MonitorLogAlert-parameters.json"

此示例从文件“MonitorLogAlert-template-Azure Monitor heartbeat failure-metric . JSON”和“monitormetricslalert-parameters . JSON”中导入度量规则“Azure Monitor heart beat failure”:

New-AzResourceGroupDeployment -Name "MetricAlertDeployment" -ResourceGroupName MyResourceGroup -TemplateFile "MonitorLogAlert-template-Azure Monitor heartbeat failure-metric.json" -TemplateParameterFile "MonitorMetricsAlert-parameters.json"

将您的所有部署捆绑到一个 PowerShell 脚本中，该脚本为您正在导入的每个规则运行一次 New-AzResourceGroupDeployment。将脚本与模板和模板参数 JSON 文件一起分发。通过执行 PowerShell .PS1 脚本来部署整套警报规则。

Tip

您可以对部署到相同环境的所有规则重用相同的参数文件。准备两个模板参数文件，日志规则和度量规则版本各一个；然后将这些模板文件用于所有规则部署。示例:要部署包括日志和度量类型的 12 x 规则，您需要准备 14 x 文件，其中两个是模板参数文件。

关于 ARM 模板文件中的转义字符

使用预定规则查询 ARM 模板时，注意需要用反斜杠字符()对模板文件描述和查询字段中的受保护字符("、\、和/)进行“转义”。表 6-2 列出了您需要遵循的转义符指导:

表 6-2

用反斜杠转义特殊字符

特殊字符

逸出输出

|
| — | — |
| 引号(") | " |
| 反斜杠() | \ |
| 斜线(/) | / |
| 换行 | \n |
| 回车 | \r |

以下是 ARM 模板查询和描述字段的前(未转义)和后(转义)示例:

     "query": "Event | where EventLevelName == "Error""

(转义“引号”字符)变成

     "query": "Event | where EventLevelName == \"Error\""

     "description": "Sample https://site.com link"

(转义“反斜杠”字符)变成

     "description": "Sample https:\/\/site.com link"

Azure 监控来宾虚拟机运行状况

除了本章到目前为止描述的 12 个 Azure Monitor 计划警报规则之外，在名为 Guest VM Health 的解决方案中还部署了第二个单独的监控堆栈。此功能为解决方案添加了一个针对 CPU、内存和逻辑磁盘空间的分层健康监视器，有三个警报规则，每个资源类型一个，使解决方案中产生警报的规则总数达到 15 个。

来宾虚拟机运行状况监控器补充了计划指标和日志警报规则，从而提供了一个高效的核心操作系统监控解决方案。与使用调度查询指标警报规则相比，来宾虚拟机运行状况是一种更灵活的监控这些性能指标的方式。

来宾 VM 健康特性也适用于 Linux 计算机，但是在第一版中只适用于 Ubuntu。

Tip

如果您只有 Azure Arc 服务器，则不需要安装来宾 VM 健康解决方案。然而，如果您是一个全 Azure 或混合组织，您将并行部署来宾 VM 健康到 Azure Monitor 计划警报规则。本节末尾列出了要部署的 Azure Monitor 计划警报规则，以代替来宾虚拟机运行状况数据收集规则。

Azure Monitor 代理介绍(AMA)

来宾虚拟机健康解决方案使用新的 Azure 管理代理 (AMA)，而不是系统中心运营管理器(SCOM)和 Azure 日志分析使用的经典 MMA。AMA 和 MMA 能够并且确实并行存在。在该解决方案中，所有代理组件都由各自的机器代理使用 Azure VM Extensions 进行安装。这种技术利用内置的 Windows Azure 访客代理服务在 Azure 虚拟机上执行其他代理的软件安装，并利用 Azure Connected Machine 代理在 Azure Arc 服务器上执行其他代理的软件安装。

正如经典 Azure Log Analytics 和 VM Insights 解决方案需要在 Windows VM 中安装两个软件组件(MMA 和依赖关系代理)一样，在部署来宾 VM 健康解决方案时，Windows VM 中也部署了两个不同的软件组件:

第一个是 Azure Monitoring Agent (AMA)。AMA 作为独立于 MMA 的 Windows 进程运行。AMA(代理版本 1.x)和 MMA(代理版本 10.x)都将心跳发送到同一个日志分析工作区。
另一个是来宾虚拟机健康代理。部署该代理将 Azure VM Insights 体验与新的健康监控功能相结合。这个解决方案需要 AMA；它不能单独在 MMA 上运行。

所有四个代理都由 Azure VM Extensions 安装在解决方案中，并且都创建 Windows 服务。但是，与作为应用安装并出现在控制面板➤添加/删除程序中的 MMA 和依赖关系代理不同，AMA 和来宾健康代理由 VM 扩展安装。它们的存在通过检查已安装 Azure VM 扩展的列表来指示(图 6-13 )。

img/506033_1_En_6_Fig13_HTML.png

图 6-13

Azure VM 扩展是代理的主要部署工具

在 Azure VM 的 Windows 文件系统中，将在 C:\WindowsAzure 和 C:\Packages\Plugins 文件夹中记录 AMA 和来宾健康代理的存在。图 6-14 和 6-15 从所有服务器视图和一个经历高 CPU 利用率警告状态的服务器的详细视图显示了来宾 VM 健康解决方案。

img/506033_1_En_6_Fig15_HTML.png

图 6-15

CPU 利用率处于警告状态的来宾虚拟机运行状况监视器

img/506033_1_En_6_Fig14_HTML.png

图 6-14

在资源组中的所有服务器上运行的来宾虚拟机运行状况监视器

Azure Monitor 数据收集规则

来宾 VM 健康监视器使用数据收集规则(DCR)和数据收集规则关联的组合来收集计算机上的数据。DCR 协会将 DCR 分配给一台或多台计算机。DCR 定义了收集哪些数据，而关联定义了哪些计算机将使用 DCR。图 6-16 展示了添加数据源的步骤，在该步骤中，您可以定义要收集的数据。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-16

创建自定义数据收集规则时的添加数据源步骤

如果您在使用 Azure 门户网站的计算机上启用来宾 VM Insights(在家中➤监视器➤ Insights ➤虚拟机)，将应用通用 DCR，这是具有默认设置的标准 DCR。默认设置启用严重警报，但不启用警告警报。要提供更主动的警报，请部署一个自定义 DCR，其中包括用于警报目的的警告阈值和严重阈值。要部署自定义 DCR，请使用以下 URL 上的“使用数据收集规则在 VM insights guest 虚拟机运行状况中配置大规模监控”过程:

https://docs.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-health-configure-dcr

创建自定义 DCR 时，表 6-3 中列出了推荐的设置。

表 6-3

建议的虚拟机来宾运行状况性能监视器警报阈值

班长

临界阈值

警告阈值

|
| — | — | — |
| CPU 利用率 | >90% | >80% |
| 逻辑磁盘可用空间 | <5% | <10% |
| 记忆 | < 100 MB | < 200 MB |

Azure Arc 服务器的计划警报规则(直到支持来宾虚拟机运行状况)

由于 VM 来宾健康解决方案不支持 Azure Arc 服务器，为了向非 Azure 服务器提供等效的监控，有必要增加表 6-1 中先前详述的计划警报规则。表 6-4 定义了三个额外的规则，这些规则取代了来宾 VM 健康解决方案所提供的监控，而这些监控对于 Azure Arc 服务器是不可用的。

表 6-4

Azure Arc 服务器的其他计划警报规则

| `Alert Name` | `Monitor Configuration and Threshold` | `Performance Counters to Collect` | | `Alert - High CPU Usage` | `AveCpu >85% at 30-minute intervals over a 4-hour period` | `Process(*)\% Processor Time``Sample rate: 60 seconds` | | `Low Disk Space Windows - Critical` | `Min % Free Space <10% in last 30 minutes, drives C:, E:, F:, and G:.` | `LogicalDisk(*)\% Free Space``Sample rate: 300 seconds` | | `Alert - Low Memory` | `minAvailableMB <1024 MB at 30-minute intervals over a 4-hour period` | `Memory(*)\Available Mbytes``Sample rate: 1800 seconds` |

要部署这些附加规则

按照本章前面“使用 ARM 模板进行规则管理”一节中的描述，从 GitHub 可管理性工具包中提取规则查询定义。
将列出的性能计数器添加到日志分析代理配置中，如前面图 6-7 所示。
为了避免来自 Azure VM 来宾健康中注册的计算机的双重监控和警报，请将附加规则的范围限制为仅 Azure Arc 服务器。作为一种解决方法，在警报规则的 KQL 中添加一行，排除名称模式指示它们是 Azure 虚拟机的计算机；例如，"| where Computer notcontains "AZ""不会对名称中带有字母“AZ”的计算机发出警报。
根据您的环境修改阈值，并为无法参与 Azure VM 来宾健康解决方案的计算机的生产监控部署附加规则。

Azure Monitor 数据收集规则关联

DCR 关联将计算机链接到集合规则集。关联的计算机出现在数据收集规则➤配置➤资源面板中，如图 6-17 所示。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-17

与此 DCR 关联的计算机(资源)列表。所有这些服务器将共享相同的虚拟机来宾运行状况设置

Azure 监视器操作规则

可在监控➤预警➤管理操作➤操作规则中访问，创建这些规则是为了抑制预警通知并大规模启用预警操作。在 Azure Monitor 解决方案中，两种模式中都使用了动作规则。

为操作组创建操作规则

创建了一个操作规则，在警报触发时通知管理员，以捕捉 Azure 来宾 VM 健康监视器中的状态变化。按照以下步骤创建“操作组”操作规则:

导航至日志分析➤预警➤管理行动➤行动规则，然后单击新行动规则。
范围:选择订阅。
过滤器:
1. 监控条件等于触发
2. 监控服务等于虚拟机洞察-运行状况
在此范围内定义:行动组。
行动组:VM Insights 健康警报。
名称:警报触发时通知管理员。
单击保存。

Azure 监视器操作规则(禁止):覆盖

这是 Azure Monitor 解决方案的重要组成部分；这就是为什么“覆盖”被引入来减少误报，从而减少警报疲劳。在监控➤预警➤管理活动➤活动规则中访问，这些是为禁止预警通知而创建的特定改写规则。覆盖创建起来很简单，人们可以从 Azure 门户网站上阅读。

图 6-18 显示了每日备份窗口期间性能监视器的三种覆盖，以及在上一步中创建的“警报触发时通知管理员”操作规则。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-18

部署为操作规则的特定于服务器、特定于规则的覆盖

创建禁止显示的操作规则

按照下列步骤创建禁止显示的操作规则:

img/506033_1_En_6_Fig19_HTML.png

图 6-19

选择作为覆盖目标的规则

导航到日志分析工作区➤警报➤管理操作➤操作规则，然后单击新操作规则。
范围是日志分析工作区。
请注意，与此范围匹配的规则将显示一个数字，比如 123 条警报规则。
点击过滤添加按钮(图 6-19 )。

img/506033_1_En_6_Fig20_HTML.png

图 6-20

使用警报规则名称和服务器名称创建覆盖以抑制警报

在添加过滤器，添加该信息(图 6-20 ):
1. 警报规则 Id 包含要覆盖的警报的名称(该名称必须存在于警报规则列表中)。
2. 警报上下文(有效负载)包含覆盖的计算机名称。
3. 将动作规则命名为“覆盖 - - ”。
4. 在日志分析工作区的资源组中保存操作规则，然后单击创建。

Azure 逻辑应用

Azure Logic 应用是一种云微服务，可用于调度、自动化和编排任务、业务流程和工作流。除了 Azure 自动化和 Azure 功能，Azure 逻辑应用是 Azure 监控解决方案中的主要工具。值得注意的是，Azure Logic 应用是针对 Microsoft Sentinel 事件和警报的唯一内嵌自动响应选项。

该方案中部署的一个逻辑 app 是Azure-Monitor-Guest-Health-Alerting(图 6-21 )。这个逻辑应用从 Azure VM 来宾运行状况警报中提取可操作的数据，并使结果易于人类阅读。逻辑应用对警报操作规则的输出进行后处理。

img/506033_1_En_6_Fig21_HTML.png

图 6-21

Azure Logic 应用:Azure-Monitor-Guest-Health-Alerting 格式化警报并通过电子邮件发送

作者逻辑应用

逻辑应用被指定为在 Azure VM 来宾健康警报触发时运行的 Azure Monitor 操作规则。逻辑应用由以下步骤组成:

当新警报到达时，延迟 1 分钟让警报出现在 Azure Log Analytics 数据库中。
运行 Azure Log Analytics 查询，查看在之前的 5 分钟内触发了哪些虚拟机来宾运行状况更改事件。
从报告警报的 Azure 资源的查询响应中解析 JSON。

HealthStateChangeEvent
| where ( MonitorName contains "logical-disks" and MonitorType contains "free-space" ) or ( MonitorName contains "memory" and MonitorType contains "available" ) or ( MonitorName contains "cpu" and MonitorType contains "utilization" )
| where CurrentMonitorState == "critical" or CurrentMonitorState == "warning"
| where EvaluationTimestamp > ago(5m)

运行另一个 Azure Log Analytics 查询，查看 Azure 资源的名称是什么(计算机名称)。

@{body('Run_query_and_list_results_-_HealthStateChangeEvent_')}

从计算机名的查询响应中解析出 JSON。

Heartbeat
| where ResourceId contains "@{items('For_each_-_value_in_HealthStateChangeEvent')?['_ResourceId']}"
| distinct Computer

img/506033_1_En_6_Fig22_HTML.png

图 6-22

逻辑应用末尾的发送电子邮件步骤

发送电子邮件通知(图 6-22 )，告知服务器名称、性能计数器的最后三个值以及超出的阈值。

@{body('Run_query_and_list_results_-_Find_Computer_name')}

来宾虚拟机运行状况警报:端到端

当警报触发时， Azure Monitor Acton 规则 通知管理员——当虚拟机来宾运行状况监控器出现警告或关键状态变化时运行——调用 Azure Monitor 操作组 虚拟机洞察运行状况警报，这将启动执行通知的逻辑应用Azure-Monitor-Guest-Health-Alerting。图 6-23 显示了最终电子邮件通知产品的外观。在生产中，您的解决方案可能会使用 API 连接而不是电子邮件向 ITSM 产品发出通知。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 6-23

来自 Azure Logic 应用的警报通知

Azure 工作簿

作为解决方案部署的点睛之笔，一组 Azure Monitor 工作簿被部署、配置并保存到订阅中。工作簿集中部署到日志分析工作区，而不是通用 Azure Monitor 或其他范围控制台。参见图 6-24 ( CPU 热图)中的样本工作簿。

img/506033_1_En_6_Fig24_HTML.png

图 6-24

Azure Monitor 工作簿:CPU 热图具有“蜂巢”可视化功能

建议安装八个工作簿(图 6-25 ):

img/506033_1_En_6_Fig25_HTML.jpg

图 6-25

要安装到日志分析工作区的工作簿

虚拟机性能
虚拟机更新摘要
服务器可用性
虚拟机安全和审计
CPU Heatmap
虚拟机连接记录
虚拟机网络依赖关系
虚拟机网络连接失败

从以下 URL 下载工作簿:

https://github.com/microsoft/Application-Insights-Workbooks/tree/master/Workbooks/Virtual%20Machines

工作簿从日志分析工作区安装➤通用➤工作簿➤新➤编辑➤代码视图。将工作簿模板的全部内容粘贴到代码编辑器中，然后单击保存。点击完成编辑，再点击保存。将工作簿命名为与其工作簿标题相同的名称，并作为共享工作簿保存到 Azure 订阅中。

摘要

使用 Azure 中的原生工具和服务，可以实现对服务器核心操作系统功能的经济、可靠和有效的监控。本章涵盖了以下共同创建 Azure 监控解决方案的操作。

定义服务器的核心监控要求。
使用 Azure 策略将 Azure Arc 服务器连接到 Azure 日志分析。
为监控配置 Azure 日志分析工作区。
参与并利用 Azure Automation 进行服务器操作系统更新。
使用 Azure Monitor 部署相关且可操作的警报。
1. 创建操作组以执行预警通知。
2. 部署预设警报规则。
3. 配置来宾虚拟机运行状况解决方案。
创建 Azure Monitor 操作组操作规则，以针对 VM Insights 运行状况警报状态更改发出警报。
创建 Azure Monitor 抑制操作规则以覆盖特定服务器上的特定规则。
为原始警报的后处理创作 Azure Logic 应用，以呈现更可读的警报通知。
导入 Azure 工作簿以展示服务器监控数据。

下一章“Azure Arc 服务器的法规和安全合规性”扩展了 Azure 监控解决方案，以包括 Microsoft Sentinel、Microsoft Defender for Cloud 和 Azure Arc SQL Server 集成。

七、Azure Arc 服务器的法规和安全合规性

在前一章“混合服务器监控解决方案”中，您构建了基于 Azure 的服务器管理功能。现在，您可以使用 Azure Monitor 对 Azure 虚拟机和 Azure Arc 服务器执行经济高效的服务器基础架构监控。利用 Azure 管理投资的一个平行且重要的机会是存在的:实现对监管和安全框架的遵从。本书中详细介绍的 Azure Arc 和微软监控代理以及 Azure 策略操作也是采用最佳实践微软企业安全解决方案的基础。

在这一章中，我们将展示 Azure Arc 代理如何与 Microsoft Defender for Cloud 进行通信，以提供可靠的实质性安全覆盖，包括集成的漏洞扫描。然后，您将了解 Microsoft Sentinel 如何作为一个解决方案安装在 Azure Log Analytics 中，以便为混合资产创建最佳的现代安全事故和事件管理(SIEM)。

我们将通过查看 Azure Arc SQL Server 的安全方面来结束本章。您将了解 Azure Arc server 和 Azure Arc SQL Server 如何融入更大的 Microsoft Azure Arc 路线图，以统一管理混合资源，甚至包括 Azure Stack HCI(超融合基础架构)

Microsoft Defender for Cloud for Azure Arc 服务器

微软使用 Azure 门户特性打包并交付其推荐的最佳实践和全面的企业安全解决方案:Microsoft Defender for Cloud。

在 Azure Arc 场景中，Microsoft Defender for Cloud是启用服务器工作负载保护的地方。
在这一章中，我们将重点介绍 Microsoft Defender for Cloud 的法规遵从性和Microsoft Defender for Cloud for servers组件。

微软云卫士

Microsoft Defender for Cloud是一个统一的基础设施安全管理系统，可为云中的混合工作负载—提供高级威胁保护，无论它们是否在 Azure 中—以及在本地。微软云卫士是 Azure 门户中的顶级控制台，如图 7-1 所示。

img/506033_1_En_7_Fig1_HTML.jpg

图 7-1

Microsoft Defender for Cloud 管理 Azure Arc 服务器上的工作负载保护

在了解 Microsoft Defender for Cloud 的作用时，与 Microsoft Defender for Cloud 类似的替代产品和竞争产品包括 Qualys Cloud Platform、AlienVault USM、Tripwire Enterprise、Nessus 和 Tenable.io。这些平台管理、协调和报告企业安全状况。这些产品包括或支持云工作负载保护平台(cwps)，用于保护公共云基础设施中的服务器工作负载。众所周知的 CWPPs 包括 Microsoft Defender for Cloud、Trend Micro Deep Security 和 Cloud One、VMware Carbon Black、Sophos Central 和 Palo Alto Networks Prisma Cloud。

实际上，Microsoft Defender for Cloud 是您的工具和朋友。使用它并依靠它来指导、关注和理解所有位置的所有平台的安全问题。如果你想在你的安全职责中进行尽职调查，你不能在微软 Defender for Cloud 的可用资源上投入太多。

Microsoft Defender for Cloud 将使用 Azure 策略与 Azure Arc 服务器进行交互。所应用的策略将与企业需要遵守的监管框架的适当控制相对应。这被称为覆盖或保护。Microsoft Defender for Cloud 覆盖适用于 Azure 订阅，然后 Microsoft Defender for Cloud 计划可以针对在覆盖的订阅中找到的“可保护的”资源类型启用。

面向云工作负载保护的 Microsoft Defender

Microsoft Defender for Cloud 的集成云工作负载保护平台(CWPP)，Microsoft Defender for Cloud，为 Azure 和混合资源及工作负载提供高级、智能的保护。注意图 7-1 中门户下部的微软云面卫士控件。

Microsoft Defender for Cloud 为特定的 Azure 资源类型提供安全警报和高级威胁保护，混合计算机是一种包含的资源类型。当谈到微软 Defender for Cloud 提供的基于 ARM 的安全保护时，Azure Arc 服务器是一等公民(与 Azure 虚拟机一起)。假设您正在将微软已经证明对其超大规模云安全有效的同一安全保护伞扩展到您自己的本地服务器。

图 7-2 是 Microsoft Defender for Cloud 的概述页面，并阐明了如何将各种各样的安全敏感资源(前三分之一)管理在一起，以生成跨平台安全警报的整合集合(中间三分之一)。下方三分之一的表面控制与 Microsoft Defender for Cloud 捆绑的高级保护附加功能。

img/506033_1_En_7_Fig2_HTML.jpg

图 7-2

Microsoft Defender for Cloud 是一个交付系统，用于向任何地方的服务器、应用和服务交付安全策略和实施

Microsoft Defender for Cloud 将您环境中的计算、数据和服务层抽象化，以便谨慎的Microsoft Defender for Cloud技术目标(合规性策略)可以跨这些异构资源类型应用:

面向服务器的云工作负载保护的 Microsoft Defender
Microsoft Defender for Cloud workload protection for App Service
面向存储的云工作负载保护 Microsoft Defender
Microsoft Defender for Cloud workload protection for SQL
用于 Kubernetes 的云工作负载保护的 Microsoft Defender
Microsoft Defender 为容器注册表提供云工作负载保护
Microsoft Defender for Cloud workload protection for Key Vault
用于资源管理器的云工作负载保护的 Microsoft Defender
Microsoft Defender for Cloud workload protection for DNS

面向服务器的微软云卫士

Microsoft Defender for Cloud for servers为 Windows 和 Linux 计算机增加了威胁检测和高级防御功能。作为一款产品，Microsoft Defender for Cloud workload protection for Servers 以前被称为 Azure Security Center(ASC)Standard，您可以将术语 Azure Defender for Servers 和 ASC Standard 与 Microsoft Defender for Cloud workload protection for Servers 互换使用。

使用 Microsoft Defender for Cloud 的成本很低，主要是每台服务器每月 15 美元。这是微软云工作负载保护平台的成本，在当今的网络安全市场中，这是一个巨大的价值。in-Azure 服务器和 Azure Arc 服务器的成本是一样的。Microsoft Defender for Cloud 集成了这些 Azure 服务来监控和保护 Azure Arc 服务器:

Microsoft Defender for Endpoint的集成许可证(仅限 Windows):Microsoft Defender for Cloud for servers 包括 Microsoft Defender for Endpoint。它们共同提供全面的终端检测和响应(EDR)功能。
虚拟机漏洞评估扫描:微软 Defender for Cloud 附带的漏洞扫描器由 Qualys 提供支持。(我们将在本章的下一节“Microsoft Defender for Cloud 的集成漏洞评估解决方案”中详细介绍这一点)
即时(JIT)虚拟机(VM)访问:当您为服务器启用 Microsoft Defender for Cloud 时，您可以使用即时虚拟机访问来锁定虚拟机的入站流量，从而减少受攻击的风险，同时在需要时提供连接虚拟机的便捷访问。
文件完整性监控(FIM) :当您启用 Microsoft Defender for Cloud for servers 时，您可以使用 FIM 来验证 Windows 文件、Windows 注册表和 Linux 文件的完整性。
对于 Linux，Microsoft Defender for Cloud 通过使用通用 Linux 审计框架 auditd 从台 Linux 机器收集审计记录。Microsoft Defender for Cloud 将 auditd 包中的功能集成到日志分析代理中。Microsoft Defender for Cloud 还通过识别 IaaS Linux 虚拟机上托管的非托管容器或运行 Docker 容器的其他 Linux 机器来执行 Docker 主机加固。
自适应应用控制(AAC)和自适应网络加固(ANH) : AAC 是一种智能的自动化解决方案，用于为您的机器定义已知安全应用的“允许列表”。ANH 通过根据实际流量模式强化 NSG 规则，进一步提高了安全性。

为服务器部署 Microsoft Defender 云工作负载保护

若要在您的 Azure 订阅上启用 Microsoft Defender for Cloud:

img/506033_1_En_7_Fig3_HTML.png

图 7-3

打开Microsoft Defender for Cloud以在 Azure 订阅上启用服务器工作负载保护

从微软云卫士的侧边栏中，选择入门(见图 7-3 )。
升级选项卡列出了符合入职条件的订阅。
从选择订阅以启用列表上的 Microsoft Defender for Cloud，选择要升级的订阅，然后单击升级按钮以启用 Microsoft Defender for Cloud。

角色和权限

让您的内部团队做好组织准备，开始使用 Microsoft Defender for Cloud 和 Azure 策略功能。要在生产中使用 Microsoft Defender for Cloud，您需要指定一个团队，负责从安全角度监控和治理 Azure 和非 Azure 环境。

为团队成员分配适合其工作的安全管理员、贡献者或读者角色。
就访问和使用解决方案对主要利益相关者和运营商进行培训。涵盖使用 Azure 门户、ARM 模板、Azure PowerShell、Azure CLI(命令行界面)和/或 REST API(视您的组织将如何操作 Microsoft Defender for Cloud 而定)。

Tip

只有两个 Azure RBAC 安全角色有权在订阅上启用 Microsoft Defender for Cloud:所有者和安全管理员。此外，所有者是唯一可以添加和分配法规遵从性标准的角色。

分配和自定义 Microsoft Defender for Cloud 默认策略

激活 Microsoft Defender for Cloud 向 Microsoft Defender for Cloud 资源提供商 Microsoft 注册订阅。安全。如果 Azure Security Benchmark policy initiative 既没有分配给订阅本身，也没有分配给层次结构中更高的管理组，此操作还会触发对订阅的 Azure Security Benchmark policy initiative 的分配。

Azure 安全基准

该默认策略将具有类似于“*ASC Default(subscription:2cb 51234-d53f-48 F3-1234-2 CFD 189 e 1234)*的名称 Microsoft 建议您检查此默认方案中的每个安全建议，以确定它们是否适用于您组织中的各种订阅和资源组。该政策将指派 Azure 安全基准倡议。

Azure Security Benchmark initiative 代表实现 Azure Security Benchmark v2 中定义的安全建议的策略和控件； https://aka.ms/azsecbm见。它是微软云默认策略倡议的捍卫者。该计划中有大约 200 个或更多的策略，包括检测没有安装日志分析代理的 Azure Arc 计算机的策略(图 7-4 )。

img/506033_1_En_7_Fig4_HTML.png

图 7-4

Azure 安全基准中的策略包括 Azure Arc 服务器

将 Azure 安全基准分配给包含您的 Azure Arc 服务器的订阅或资源组后，每个 Azure Arc 服务器将开始报告其合规状态。在 Azure 门户➤ Azure Arc 服务器➤运营➤策略刀片上显示了对该计划的总体遵从性和对该计划中每个特定策略的单独遵从性。

评估政策合规性

如果你遵循了本书中的步骤，你的 Azure Arc 服务器已经被 Enable Azure Monitor for VMs 策略计划覆盖(参见第 6 “混合服务器监控解决方案”一章的“Azure 策略”部分)。在这种情况下，Azure Arc 服务器策略刀片可能看起来如图 7-5 所示。

img/506033_1_En_7_Fig5_HTML.png

图 7-5

分配给 Azure Arc 服务器的 Azure 安全基准

图 7-5 中的 Azure Arc 服务器符合启用虚拟机 Azure 监控策略，但不完全符合 ASC 默认订阅策略。点击 ASC Default subscription 计划，进入该计划中所有政策的列表。服务器不符合的策略排列在顶部(图 7-6 )。

img/506033_1_En_7_Fig6_HTML.png

图 7-6

分配给 Azure Arc 服务器的 Azure 安全基准

请注意图 7-6 的顶部，服务器仅不符合计划中 199 个策略中的一个。列表顶部是一个不合规的策略:执行软件漏洞评估。Azure Arc 服务器已经符合我们在图 7-4 中看到的日志分析代理策略，因为为虚拟机启用 Azure Monitor 计划包含相同的单独策略！您需要做的唯一额外的事情是部署一个漏洞评估，我们将在本章中讨论如何做，在“集成的漏洞评估”一节中。

Tip

使用合规性标准时，需要验证或设置一些参数，甚至包括 ASC 默认值。例如，CMMC 要求您声明哪些帐户应该属于本地管理组；然后，它进行审计，以确保只有这些帐户在本地管理组中。

选择行业标准并实现合规性

Azure 拥有业内最广泛、最深入的合规产品组合。Azure 合规产品是全球性的，有 60 多种产品特定于 20 多个地区和国家。Azure 也是为关键行业的特定需求而构建的，并符合 50 多种特定于保健、政府、金融、教育、制造和媒体行业的法规遵从性产品。超过 100 个 Azure 合规产品的完整列表可在以下网址找到:

https://docs.microsoft.com/en-us/azure/compliance/

这些合规产品的子集默认包含在 Microsoft Defender for Cloud 中，或者可以轻松导入到法规遵从性控制面板中，然后分配给订阅。使用 Microsoft Defender for Cloud 中的法规遵从性仪表板，您可以将您的资源配置与行业标准、法规和基准的要求进行比较。

将特定行业和地区要求转化为可操作和可审计的安全控制的能力是 Microsoft Defender for Cloud platform 的一项战略性增值。表 7-1 列出了每个类别的产品。

表 7-1

可出现在 Microsoft Defender for Cloud Compliance 控制面板上的监管框架

现成的产品

可以添加预构建的产品

要添加一个预构建的产品，禁用一个现成的产品，或者添加一个自定义计划，请导航到 Microsoft Defender for Cloud ➤云安全➤法规遵从性，然后单击管理遵从性策略按钮，如图 7-7 所示。

img/506033_1_En_7_Fig7_HTML.jpg

图 7-7

访问管理遵从性策略功能

您可以使用预构建的产品作为指南来构建自己的定制产品。自定义产品是一种自定义策略方案，包含构成合规性标准的所有单个策略。您的定制服务可能包括许多预构建的单独策略，以及您可能添加的一些额外的定制策略，以创建一个定制的策略组合，包括一些内置策略和一些定制策略。

Tip

在本书范围之外，但网络安全专业人士感兴趣的是另一个主要的微软安全解决方案:微软合规管理器，这是微软 365 合规中心内的一个端到端合规管理解决方案。通过以下网址了解更多信息:

https://docs.microsoft.com/en-us/microsoft-365/compliance/compliance-manager

评估法规遵从性

如果您想要咨询您的组织对其中一个“现成”标准的合规性，或者在您添加了预构建或自定义标准之后，请导航到 Microsoft Defender for Cloud ➤法规合规性，然后单击与您想要查看的产品对应的选项卡。图 7-8 显示，在分配 HIPAA HITRUST 标准后，27 台虚拟机和 Azure Arc 服务器中有 11 台缺少变更单，无法在生产部署前进行补丁测试和验证。

img/506033_1_En_7_Fig8_HTML.png

图 7-8

评估组织对特定法规标准控制的遵从性

一个单独的 Azure Arc 服务器将在 Azure Arc 服务器➤设置➤安全刀片上显示 Microsoft defender for cloud integration，如图 7-9 所示。列出了基于从启用的监管标准应用的策略的建议。如果此服务器在过去 21 天内涉及任何安全事件或警报，这将反映在此页面上。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-9

Microsoft Defender for Cloudfor servers，活跃在 Azure Arc 服务器上

Microsoft Defender for Cloud 看似简单的界面隐藏了一些非常强大的安全工具。点击建议部分下的查看安全中心中其他资源的其他建议链接，将打开一个新窗口，其中包含您不遵守的所有策略的交互式视图(图 7-10 )。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-10

Microsoft Defender for Cloud适用于 Azure Arc 服务器上的活动服务器

这一观点的强大之处在于，每一项具体建议对安全性的贡献将会得到评分。影响越严重，乘以需要补救的实例数量，就会得出一个数值，帮助您确定安全工作的优先级。通过这种方式，在分布式混合环境中实施企业安全的巨大任务变得更加容易实现。抓住每一个机会补救下一个影响最大的未减轻的安全风险，直到不存在为止。

创建合规例外

当您通过执行建议的操作来补救安全风险时，您会看到合规性仪表板报告—中的结果，因为您的合规性得分提高了(评估大约每 12 小时运行一次)。但是有些政策根本不适用于您的环境，或者在尽职调查后，被视为已知风险。在这些情况下，您可以创建特定策略的例外。

For policies that are built into Microsoft Defender for Cloud and included in the secure score, you can create exemptions for one or more resources directly in the portal as follows:

图 7-11

从特定建议中免除 Azure Arc 服务器
1. 打开特定建议的“建议详细信息”页面，例如“日志分析代理应该安装在基于 Windows 的 Azure Arc 计算机上。”
2. 从页面顶部的工具栏中选择免税(图 7-11 )。
3. 单击刀片底部的豁免按钮；然后选择要豁免的资源。
4. 选择减轻或放弃并点击创建按钮。

对于其他策略，您可以按照 Azure 策略豁免的说明，直接在策略本身中创建豁免。我们在第六章“混合服务器监控解决方案”的“Azure 策略:豁免”一节中介绍了这个过程

Tip

没有明确的方法来审查 Microsoft Defender for Cloud 的现有豁免。要复查您已创建的免税，请咨询➤保单拟定➤免税。请注意，将为资源和策略的每个适用合规标准创建一个豁免。

综合脆弱性评估

概观

Microsoft Defender for Cloud 中的集成漏洞扫描器具有巨大的价值，应该包含在您组织的网络防御计划中。一般来说，漏洞扫描器是一种发现其他实体(如网络和计算机)弱点的软件。在通常的实践中，它们用于识别和检测由基于网络的资产(如防火墙、web 服务器或应用服务器)中的错误配置或有缺陷的编程引起的漏洞。

内部和外部漏洞扫描

想象一下在没有正确更新相关安全性的情况下，未能应用安全补丁或进行系统修改。这些罕见但可预测的情况为剥削创造了媒介。如果更多组织使用漏洞扫描器测试他们的环境，许多恶意入侵和勒索事件本来是可以避免的。因此，PCI DSS 11.2 以及其他法规遵从性框架要求以电子方式存储、处理和/或传输持卡人数据的组织运行内部和外部漏洞扫描。

PCI DSS 需要两种独立的漏洞扫描方法:内部和外部。外部漏洞扫描在您的网络外部执行(例如，在您的网络外围)，它可以识别网络结构中的已知弱点。内部漏洞扫描在您的网络中执行，它会查看同一网络中的其他主机以识别内部漏洞。

Microsoft Defender for 云和内部扫描

部署和使用与Microsoft Defender for Cloud for servers捆绑的集成漏洞扫描器，可以帮助您的组织在 Windows 和 Linux 服务器上实现内部扫描目标。这是通过将漏洞扫描卸载到 Qualys 云服务来实现的，如图 7-12 所示。

img/506033_1_En_7_Fig12_HTML.jpg

图 7-12

集成漏洞扫描器的工作原理。(来源:微软)

ASC 附带的漏洞扫描器由第三方服务提供商 Qualys 提供支持。Qualys 的扫描仪是业界领先的实时识别漏洞的工具。它仅适用于 Microsoft Defender 的服务器云工作负载保护。你不需要 Qualys 许可证，甚至不需要 Qualys 帐户—一切都在 Microsoft Defender for Cloud 中无缝处理。请注意，扫描仅针对运行代理的设备，没有“设备发现”或“无代理扫描”组件。

漏洞扫描器扩展工作流程如下(图 7-12 中编号的步骤):

从 Microsoft Defender for Cloud 部署 Azure 策略以执行漏洞评估。
Azure VMs 和 Azure Arc 服务器将遥测数据转发给定义区域中的 Qualys 云服务进行分析。
Qualys 的云服务进行漏洞评估，并将其结果发送给微软云卫士。
调查结果在 Microsoft Defender for Cloud 中报告，并将指导您的补救优先级和行动。

将集成扫描仪部署到您的 Azure Arc 服务器上

按照以下步骤开始使用 Qualys 漏洞扫描程序来扫描受 Microsoft Defender for Cloud 保护的服务器:

img/506033_1_En_7_Fig15_HTML.png

图 7-15

部署由 Qualys 支持的集成漏洞扫描器

如图 7-15 所示，确认正在补救的资源数量以及您正在部署由 Qualys 提供支持的 Microsoft Defender for Cloud 集成漏洞扫描器(包含在 Microsoft Defender for Cloud workload protection for servers 中),然后单击继续。

img/506033_1_En_7_Fig14_HTML.png

图 7-14

选择接收漏洞检查解决方案的计算机

在您的 Azure 门户中导航到➤微软云卫士主页。
从 Microsoft Defender for Cloud 菜单中，打开建议页面。
Type “vulnerability” in the Search recommendations box as shown in Figure 7-13. Locate and click on the recommendation “A vulnerability assessment solution should be enabled on your virtual machines.”
- 请注意，对于建议，您的部分或全部计算机将被归类为不健康资源。此列表中的“不健康”表示可以将漏洞扫描程序部署到该计算机。
- 您可能会看到一些被归类为不适用资源的计算机。此处列出的计算机不能部署漏洞扫描程序扩展。原因可能是它是 AKS 群集中的映像，它是虚拟机规模集(VMSS)的一部分，或者它没有运行集成漏洞扫描程序支持的操作系统之一。
图 7-13

找到将启用漏洞扫描的控件
一个刀片将打开，列出不健康的资源，如图 7-14 所示。请注意，您的混合资产中的所有计算机将被统一列出——Windows 和 Linux、in-Azure 和 Azure Arc。从不健康的机器列表中，选择要接收漏洞评估解决方案的机器，然后单击修复按钮。

img/506033_1_En_7_Fig16_HTML.png

图 7-16

将 Windows 和 Linux Azure Arc 服务器纳入内置漏洞评估解决方案

在修复资源页面，确认选择的资源是您想要加载到解决方案的服务器，点击修复资源按钮，如图 7-16 所示。
fix resources 命令为每台机器启动提供者类型Write servervulnerability assessment的 Azure Resource Manager (ARM)部署。
- Windows 机器将安装 WindowsAgent。ARM 部署安装的 AzureSecurityCenter 扩展。对于 Linux 机器，这个扩展被命名为 LinuxAgent。AzureSecurityCenter 。
- 你会在 Azure Arc 服务器的设置➤扩展页面上看到正在创建的扩展。你也可以在 Azure 订阅的活动日志(主页➤活动日志)中跟踪 ARM 部署的进度。
- Windows 计算机将在控制面板➤程序和功能中显示由 Qualys，Inc .发布的应用 Qualys 云安全代理。当你运行 apt list - installed 命令时，Linux 电脑会列出 qualys-cloud-agent 。
成功部署扩展后，扫描会自动开始。扫描将每隔 4 小时运行一次。这个时间间隔是不可配置的。

Tip

目标机器必须能够与 Qualys 的云服务通信。如果您控制要扫描的服务器的 Internet 访问，请将以下 IP 添加到允许列表(HTTPS 协议，TCP 端口 443):

64 . 39 . 104 . 113-哪些美国数据中心

154.59.121.74—Qualys 的欧洲数据中心

如果机器在欧洲 Azure 地区，它的工件将在 Qualys 的欧洲数据中心处理。位于其他地方的机器的工件被发送到美国数据中心。

自动化大规模部署

上一节中的步骤“将集成扫描器部署到您的 Azure Arc 服务器”，可以根据需要随时手动重复，以保持所有生产服务器注册到解决方案中。对于较大的环境，有多种大规模自动化工具可用于部署解决方案。

Azure 资源管理器(ARM)

该方法可从微软 Defender for Cloud 推荐的 blade 获得。返回图 7-14 中的视图，在页面的受影响资源部分的正上方，在修复步骤部分，点击查看修复逻辑按钮。将显示自动修复脚本内容。内容是部署解决方案的 ARM 模板；将内容复制出来，用“.”保存为文本文件。JSON”扩展。对于您的组织喜欢的任何自动化解决方案，使用 JSON 格式的模板。

Azure 策略

将自定义策略在此 GitHub URL 的虚拟机上部署 Qualys 漏洞评估解决方案导入您的 Azure 订阅:

https://github.com/Azure/Azure-Security-Center/tree/master/Remediation%20scripts/Enable%20the%20built-in%20vulnerability%20assessment%20solution%20on%20virtual%20machines%20(powered%20by%20Qualys)/Azure%20Policy

您可以在 Azure 订阅、资源组或管理组级别分配此策略(如图 7-17 所示)。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-17

分配此自定义 DeployIfNotExists 策略以启用将解决方案部署到计算机的修正任务

Azure PowerShell

使用qualys-remediate-unhealthy-VMs . PS1脚本为所有运行不正常的虚拟机部署扩展。要在新资源上安装，考虑用 Azure Automation 自动化脚本。该脚本查找 ASC 建议发现的所有不健康的机器，并执行 ARM 调用来部署解决方案。从以下 GitHub URL 下载脚本:

https://github.com/Azure/Azure-Security-Center/tree/main/Remediation%20scripts/Enable%20the%20built-in%20vulnerability%20assessment%20solution%20on%20virtual%20machines%20(powered%20by%20Qualys)/PowerShell

Azure Logic 应用

使用 Microsoft Defender for Cloud 的工作流自动化工具来触发如图 7-18 所示的逻辑应用，以便在为资源生成漏洞评估解决方案时部署扫描器。

img/506033_1_En_7_Fig18_HTML.png

图 7-18

Azure Logic 应用由微软云卫士推荐触发

基于您可以从以下 GitHub 位置部署的Install-vulnasesmentagent示例应用构建一个逻辑应用:

https://github.com/Azure/Azure-Security-Center/tree/main/Workflow%20automation/Install-VulnAssesmentAgent

在导入逻辑应用之后，您确实需要编辑逻辑应用，并使用 API 连接凭证定制创建或更新模板部署步骤，该凭证有权写入您的 Azure VM 或 Azure Arc 服务器资源。定制完成后，在 Microsoft Defender for Cloud 控制台中呈现建议的任何位置，您都可以单击触发器按钮来部署解决方案，如图 7-19 所示。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-19

手动触发逻辑应用以在机器上安装扩展

Azure REST API

要使用 REST API 部署集成漏洞评估解决方案，请对以下 URL 发出 PUT 请求，并添加相关的资源 ID: https://management.azure.com/<resourceId>/providers/Microsoft.Security/serverVulnerabilityAssessments/default?api-Version=2015-06-01-preview

触发按需扫描

您可以使用本地或远程脚本或组策略对象(GPO)从计算机本身触发按需扫描。或者，您可以在修补程序部署作业结束时将按需扫描集成到您的软件分发工具中。以下命令会触发按需扫描:

窗户

REG ADD HKLM\SOFTWARE\Qualys\QualysAgent\ScanOnDemand\Vulnerability /v "ScanOnDemand" /t REG_DWORD /d "1" /f

Linux

sudo /usr/local/qualys/cloud-agent/bin/cloudagentctl.sh action=demand type=vm

查看和补救调查结果

当漏洞评估工具报告漏洞时，Microsoft Defender for Cloud 会将调查结果和相关信息作为建议呈现。此外，调查结果还包括相关信息，如补救步骤、相关简历、CVSS 分数等。按照以下步骤查看和修复计算机上漏洞评估扫描的结果:

img/506033_1_En_7_Fig20_HTML.png

图 7-20

Microsoft Defender for Cloud将为发现的漏洞提供补救说明

在您的 Azure 门户中导航到➤微软云卫士主页。
从安全中心菜单中，打开建议页面。
在搜索建议框中键入“漏洞”。找到并单击建议“应修复虚拟机中的漏洞”
展开安全检查，在调查结果选项卡中看到您的漏洞，如图 7-20 所示。

图 7-20 还展示了 Microsoft Defender for Cloud 如何帮助您更快地实现合规性。在这个例子中，Qualys 扫描器已经识别出流行的 SSH 工具 PuTTY 的一个易受攻击的版本。扩展补救特别列出了要升级到哪个安全版本的 PuTTY，甚至还有一个下载网站的超链接。

禁用特定调查结果

如果您的组织需要忽略某个调查结果，而不是修复它，您可以选择禁用它。禁用的搜索结果不会影响您的安全分数或产生不必要的噪音。

一个示例场景可能是一个组织需要继续使用 Adobe Flash Player ，因为一个关键的业务线应用仍在使用它。在执行尽职调查以接受风险并可能实施其他缓解或保护措施后，继续禁用调查结果:

在虚拟机中的漏洞应修复的建议详细信息页面中，选择禁用规则。
选择相关范围，例如您的订阅。
定义你的标准。您可以使用以下任何标准:
- 查找 ID
- 种类
- 安全检查
- CVSS 分数(v2，v3)
- 严重
- 可修补状态

对于本例，我们使用“105943”查找与该 PuTTY 漏洞对应的 ID 。

可选地，在提供的区域输入一个调整，并点击应用规则按钮。应用于订阅的新禁用规则可能需要 30 分钟才能生效。禁用规则生效后，该项目将从调查结果列表中删除。
A list of all Disabled findings is available as seen in Figure 7-21. Notice your justification comments are preserved in the Reason column.

图 7-21

禁用的调查结果是跟踪您选择忽略的建议的一种方式

微软哨兵和 Azure Arc 服务器

每个拥有两个或更多安全数据源的组织都需要一个 SIEM(安全信息和事件管理)工具，这意味着每个组织。SIEM 是不同但安全敏感的平台发送其实时安全数据的地方，用于集中收集和分析。如果您没有实际的 SIEM 解决方案，您的 ITSM 票务系统或电子邮件收件箱可能会充当您的 SIEM。在某种程度上，所有组织都成熟到可以并且必须部署专用安全工具来执行安全事件和事故关联和调查的程度。

Microsoft Sentinel 是基于云的 SIEM，也是唯一的原生云 SIEM。竞争对手的云 SIEMs 包括 Splunk 安全云、美国电话电报公司 AlienVault USM Anywhere 和 IBM QRadar on Cloud。如果您的组织没有投资这些或类似的 SIEMs，而您已经部署了本书中描述的解决方案，如 Azure Arc、Azure Monitor、Azure Log Analytics 和 Microsoft Defender for Cloud，那么将 Microsoft Sentinel 添加到您的安全堆栈中应该是一个容易的决定。您可能会获得当今世界上最好的 SIEM，而成本只是添加第三方企业 SIEM 的一小部分。

如果您有 Azure 之外的服务器，采用 Azure Arc 的一个主要原因可能是将 Microsoft Sentinel 部署为您的企业 SIEM。如果您正在执行最佳实践 Microsoft Sentinel 部署—,并且您的 IT 资产包括本地服务器、私有云和托管服务器，或者 AWS 和/或 Google cloud 中的服务器，您应该从 Azure Arc 部署开始您的 Microsoft Sentinel 部署。推广 Microsoft Sentinel 作为 SIEM 的高级步骤如下:

在非 Azure 服务器上安装 Azure Arc 代理，使用 Azure 虚拟机拥有的虚拟机扩展为它们提供相同的带外控制。
将 Azure 策略分配给所有云中的所有服务器，这些服务器使用 VM 扩展将它们连接到特定的 Azure Log Analytics 工作区。
在你的 Azure 订阅中，在所有服务器连接的日志分析工作区中安装一个 Microsoft Sentinel 实例。

事实上就是这么简单:微软 Sentinel 是 Azure Monitor 和 Azure Log Analytics 的超集，两者都(1)将来自服务器的安全数据与来自其他平台(如防火墙和云服务登录，如 Office 365)的安全数据相关联，以及(2)处理服务器安全数据本身以发现异常和威胁指标。

将 Microsoft Sentinel 添加到日志分析实例中，对于给定的一组服务器，Azure 每月服务的成本将增加一倍。Microsoft Sentinel 是您的服务器可能已经消耗的日志量之外的附加成本。表 7-2 给你一个思路；在更高的利用率(>50gb/月)下，预承诺层提供批量折扣。(您可以从 50 GB 的利用率开始获得 100 GB 的价格折扣。)

表 7-2

Azure Monitor 与 Microsoft Sentinel 摄取成本的比较

(美国东部，90 天保留期)

天蓝色监视器

蔚蓝哨兵报

|
| — | — | — |
| 50gb/月 | $3,438.50 | 3，000.00 美元(增加 87%) |
| 100 GB/月 | $5,880.00 | 3，000.00 美元(增加 51%) |
| 200 GB/月 | $11,040.00 | 5，400.00 美元(增加 48%) |

将 Microsoft Defender for Cloud 数据导出到 Microsoft Sentinel

Microsoft Defender for Cloud 可以非常轻松地连接到 Microsoft Sentinel。有一种全功能的无成本连接模式和一种可选模式，这种模式会对日志接收产生微费用。

针对云集成的补充性 Microsoft Defender

在 Microsoft Sentinel 控制台中，导航至配置➤数据连接器。找到 Microsoft Defender for Cloud 并单击打开连接器页面按钮。在订阅列表中，移动滑块到连接位置，如图 7-22 所示。

img/506033_1_En_7_Fig22_HTML.jpg

图 7-22

一键连接 Microsoft Defender for Cloud 和 Microsoft Sentinel

图 7-22 中显示的集成将导致来自 Microsoft Defender for Cloud 的安全警报出现在安装了 Microsoft Sentinel 的 Azure Log Analytics 实例中。根据最佳实践启用的 Microsoft Sentinel 分析规则(基于 Azure 安全中心警报创建事件)将在 Microsoft Defender for Cloud 警报触发时创建 Microsoft Sentinel 事件。

实现这种集成是没有成本的；也就是说，没有 Microsoft Sentinel 数据接收费用。这种模式对于许多环境来说已经足够，当 Microsoft Defender for Cloud 发出警报时，将实时创建 Microsoft Sentinel 事件。

图 7-23 是来自 Azure Arc 服务器的微软 Defender for Cloud sourced Microsoft Sentinel 事件。可疑认证活动事件经调查发现来自 Exchange 服务器，在 IIS 日志中，有一个字典攻击试图通过 SMTP 认证来转发垃圾邮件。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-23

Azure Defender 在 Azure Arc 服务器上发现安全事件

Tip

使用 Microsoft Sentinel 接收和管理由 Microsoft 安全服务引发的事件不会产生任何数据处理成本。即使您的组织不打算将 Microsoft Sentinel 用于其他目的，连接这些服务也将为这十个异构数据源提供基本上免费的单一管理平台:

Azure 活动日志

Office 365 审核日志(SharePoint 和 Exchange 活动)

微软 365 卫士

Microsoft Defender for Office 365

微软身份卫士

Microsoft Defender for Endpoint

微软云卫士

面向云应用的 Microsoft Defender

Azure 信息保护(AIP)

用于云数据导出的附加 Microsoft Defender

除了 Microsoft Sentinel 与 Microsoft Defender for Cloud alerts 的集成之外，您还可以选择将其他 Microsoft Defender for Cloud 产品(如漏洞评估结果、安全评分和法规遵从性消息)导出到 Azure Log Analytics。如果您在同一个工作区安装了 Microsoft Sentinel，Microsoft Sentinel 也会接收额外的数据，但不会像 Microsoft Defender for Cloud alerts 那样自动支持事件创建。

启用这种日志记录模式确实会产生 Azure Log Analytics，并且可能会产生 Microsoft Sentinel 基于每 GB 容量的处理费用。虽然这些类型的消息的预期数量会产生非常小的微费用，但是对于大多数环境来说，这种成本是微不足道的(但非零)。

要启用从 Microsoft Defender for Cloud 到 Azure Log Analytics 的额外数据导出:

img/506033_1_En_7_Fig24_HTML.png

图 7-24

支持将其他Microsoft Defender for Cloud数据导出到 Azure Log Analytics 工作区

导航至主页➤ Microsoft Defender for Cloud ➤管理➤环境设置➤ ➤连续导出。
选择 Log Analytics workspace 选项卡，打开Export enabled**。**

*** 根据需要选择导出的数据类型；示例如图 7-24 所示。如果您已经启用了默认的 Microsoft Sentinel 集成，请避免导出安全警报类型，以避免对这些事件发出双重警报。

 *   选择资源组和目标工作区，点击**保存**按钮。

 **

**可选地基于日志分析查询创建 Azure Monitor 日志警报，以查看 Azure Monitor 中的导出类型并触发警报规则，例如当漏洞评估包含高优先级发现时。

使用内置向导抢先创建 Azure Monitor 警报规则:

启用连续导出后，一直滚动到连续导出设置页面的底部，并点击链接继续与 Azure Monitor 集成。
选择日志警报为导出的建议创建警报规则并点击创建按钮。
导航到主页➤日志分析工作区➤警报规则并找到规则*【azure 安全中心】新安全建议*。单击以编辑规则。
在条件部分中，每当平均自定义日志搜索大于 0 时，单击连接名称*。*
在基于部分评估的中，将周期和频率从 5 分钟更改为 60 分钟。(这将把监控规则本身的成本从每月 1.50 美元降低到每月 0.15 美元以下。)
在操作部分，单击添加操作组，然后选择并添加您的首选通知操作组。如果你还没有动作组，你可以创建一个动作组—页面顶部有一个创建动作组控件。
点击保存按钮。

Microsoft Defender for Cloud vulnerability 在报告扫描结果时会扫描 SecurityRecommendation 类型的日志数据。在每小时检查期间，如果在日志分析数据库中发现 SecurityRecomendation 类型的未来数据，您将会收到通知。

Tip

如果您只想在发现高严重性时接收警报，请按如下方式编辑警报规则中的查询:

SecurityRecommendation

| where RecommendationSeverity contains "High"

Azure Arc 服务器的 Microsoft Sentinel 分析规则

微软 Sentinel 内置了 120 多种服务和云应用的连接器。要启用的连接器的选择基于组织中的安全数据源。与 Azure Arc 服务器特别相关的微软 Sentinel 数据连接器有

微软云卫士
域名服务器(Domain Name Server)
安全事件
Windows 防火墙

这些是应用于运行 Windows 和 Linux 并执行 IaaS 角色的 Azure 虚拟机的相同连接器。当 Azure 虚拟机和 Azure Arc 服务器中的一个或两个被监控时，建议启用这些连接器。

Tip

启用安全事件数据连接器时，建议从通用事件设置开始。所有事件设置可能相当昂贵，而最小设置不提供完整的审计跟踪。

每个数据连接器在其打开的连接器页面➤后续步骤选项卡上显示一个相关分析模板的列表。以下是建议启用的分析活动规则，从相关连接器的模板列表中收集。

分析活动规则

这些 Microsoft Sentinel Analytics 警报规则与 Azure Arc 服务器尤其相关:

所有镓、铱、锌、磷、铊、铈、锶、钡和锕规则
基于 Azure Defender 警报创建事件
检测到潜在的 DGA
观察到具有高反向 DNS 查找计数的罕见客户端
Solorigate 网络信标
TI 将电子邮件实体映射到安全警报
TI 将 URL 实体映射到安全警报数据
TI 将域实体映射到安全警报

异常规则

异常规则必须在生成异常之前激活。一旦异常规则被激活，检测到的异常将被存储在 Microsoft Sentinel 工作区的日志部分的异常表中。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-25

异常表中关于 Azure Arc 服务器的条目

每个异常规则都有一个训练期，在训练期结束之前，异常不会出现在表中。你可以在每个异常规则的描述中找到训练周期(一般是 7 天或 14 天)。
一旦异常规则开始产生异常检测，如图 7-25 所示，您可以选择创建适合您环境的警报规则。

有关使用异常规则的更多信息，请参考以下参考 URL:

https://docs.microsoft.com/en-us/azure/sentinel/work-with-anomaly-rules

这些 Microsoft Sentinel 异常规则与 Azure Arc 服务器尤其相关:

尝试用户帐户和计算机暴力
用户帐户和计算机的可疑登录量
使用提升的令牌登录用户帐户的可疑数量
按登录类型划分的用户帐户可疑登录量
每种登录类型尝试的用户帐户暴力
使用提升的令牌登录计算机的可疑数量
检测机器生成的网络信标行为
异常网络容量异常
过度数据传输异常
异常 web 请求活动
每个失败原因的用户帐户暴力尝试

准备和部署逻辑应用

作为微软 Sentinel 的用户，你将需要部署一个或多个作为 Azure 逻辑应用的剧本来与微软 Sentinel 事件进行交互。Azure Logic 应用是 Microsoft Sentinel 中唯一可用于高级通知、自动化和事件工作流的机制。

定位和部署行动手册

随着时间的推移，每个生产 Microsoft Sentinel 环境都将收集和采用行动手册，以提高安全团队的效率和效力。大多数从执行基本通知操作的单一剧本开始。随着事件处理需求和自动化机会的出现，引入了更多更复杂的行动手册。

幸运的是，在创建您的自定义逻辑应用集合时，有大量的社区资源可供利用。GitHub URL 上有数百个行动手册可供导入:

https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks

剧本使用示例

作为向 Microsoft Sentinel 报告的 Azure Arc 服务器如何从行动手册中获得价值的示例，请考虑前面 URL 中的Get-GeoFromIpAndTagIncident行动手册。本行动手册将从事件中提取 IP 地址实体，并查询 Geo-IP API 以地理定位 IP 地址。它会将城市和国家写在事件标签上。在调查事件时，本行动手册将为您节省对潜在威胁的来源 IP 进行地理查找的时间。

将行动手册导入 Microsoft Sentinel 实例后，您需要编辑行动手册并为行动手册任务提供必要的安全凭证，以便行动手册有权向 Microsoft Sentinel 事件添加标记。此外，为每个任务(最低任务)编辑的设置，如下所示:

右键点击椭圆“…”控件，点击设置。
将并发控制设置为上的**，将并行度设置为 1 。**
点击完成。

然后保存行动手册，并准备好针对现有事件运行。

使用 Get-GeoFromIpAndTagIncident

要用地址对应的城市和国家代码标记包含 IP 地址的现有事件，请执行以下操作:
1. 选择事件并点击查看全部细节按钮。
2. 单击“Alerts”选项卡并一直滚动到左侧，以显示查看行动手册链接；然后点击链接。
3. 找到Get-GeoFromIpAndTagIncident剧本并点击 Run 按钮。

使用 Get-GeoFromIpAndTagIncident-Auto

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-26

两个版本的逻辑应用，一个用于手动运行，一个用于自动雇佣

要自动标记包含 IP 地址的未来事件:
1. 在 Microsoft Sentinel ➤配置➤自动化➤行动手册中，找到get-geofromipandtagincident行动手册，并单击它打开 logic 应用。
2. 点击克隆按钮，将克隆命名为Get-GeoFromIpAndTagIncident-Auto。点击创建。
3. 现在打开克隆剧本GeoFromIpAndTagIncident-Auto并点击编辑按钮。
4. 当对 Azure Sentinel 警报的响应被触发时，删除顶层任务*。(右击椭圆“…”控件并选择删除。)*
5. 当 Azure Sentinel 事件创建规则被触发时，添加触发器作为顶层任务。
6. 用新任务替换第二级任务，获取事件并使用事件臂 ID: 事件臂 ID 。
7. 用新的任务实体替换第三级任务——获取 IPs 并使用实体列表:实体。
8. 对于每 2 个，用新的替换最低级别的任务(对于每个)。
  - 选择前面步骤的输出:@body('Entities_- _Get_IPs')?['IPs']
  - 使用 URI http://ip-api.com/json/@{items('For_each_2')?['Address']} 将 HTTP GET 复制到 HTTP2 GET 步骤
  - 使用内容:@{body('HTTP_2')}将解析 JSON 复制到解析 JSON 2 步骤。还要将模式从 Parse JSON 复制并粘贴到 Parse JSON 2。
  - 创建新的最低阶步骤更新事件。
    - 事故臂 id: 事故臂 ID
    - 要添加标签的标签–1:@body('Parse_JSON_2')?['city']
    - 要添加标签的标签–2:@body('Parse_JSON_2')?['country']
9. 从逻辑应用画布中删除原始逻辑应用中剩余的任何步骤，并点击保存。图 7-26 左边显示的是原始的逻辑应用，右边显示的是编辑后的克隆。

在微软➤哨兵配置➤自动化，选择创建 ➤ 添加新规则。
将自动化规则命名为*，使用 IP 地址*对所有事件进行地理标记。
在操作中，选择运行行动手册。选择剧本Get-GeoFromIpAndTagIncident-Auto。(只有当 Azure Sentinel 事件创建规则触发触发器时，带有的剧本可供选择。)
键入一个不是最高编号订单的订单编号(这不应该是运行的最后一个自动化规则)，并点击应用按钮。

现在，当您手动运行剧本Get-GeoFromIpAndTagIncident或使自动化规则地理标记所有具有 IP 地址的事件以编程方式运行剧本Get-GeoFromIpAndTagIncident-Auto时，事件将被标记城市和国家，如图 7-27 所示。

img/506033_1_En_7_Fig27_HTML.png

图 7-27

剧本为事件添加了城市和国家标签

Tip

Get-GeoFromIpAndTagIncident 行动手册将按配置工作，但当一个或多个 IP 在私有 IP 范围内时，如 10.x 或 192.168.x，将抛出错误。为了避免错误消息，在解析 JSON (或解析 JSON 2 )之后添加一个新的条件步骤。条件步骤如下:@body('Parse_JSON')?['status']或@body('Parse_JSON_2')?['status']不包含失败。将最底层任务(添加事件标签或更新事件)移入真结果任务，并将假结果任务留空。

工作簿和仪表板

像 Azure Monitor 一样，Microsoft Sentinel 利用 Azure 工作簿进行交互式可视化。特别是对于 Azure Arc 服务器，有一些特定的工作簿模板您应该考虑保存到您的订阅中，并在您的日常安全管理职责中使用。

在 Microsoft Sentinel 控制台的威胁管理➤工作簿➤模板中找到工作簿模板。
选择您想要开始使用的每个工作簿，然后单击保存按钮。
保存的工作簿可在威胁管理➤工作簿➤我的工作簿中找到。
点击查看保存的工作簿按钮，使用您保存的工作簿。

表 7-3 列出了与 Azure Arc 服务器的每个最佳实践数据连接器相关的推荐工作簿。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-28

Windows 防火墙工作簿结合了 Azure VM 和 Azure Arc 服务器防火墙日志

表 7-3

对 Azure Arc 服务器特别有用的工作簿

数据连接器

推荐练习册

Tip

即使您的组织没有在 Windows 服务器上使用 Windows 防火墙组件，您也可以利用防火墙日志的收集来获得高价值的安全指示。图 7-29 显示了一个建议的组策略对象(GPO ),当您在 Microsoft Sentinel 中启用 Windows 防火墙数据连接器时，该对象将启用防火墙日志记录。关键设置包括:

大小限制(KB): 1，024
日志丢弃和成功连接:是

重要的是，大小限制要小(1 KB ),因为日志只有在达到选定的大小时才会上传到 Microsoft Sentinel。日志越小，Microsoft Sentinel 接收的速度越快。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-29

使用 GPO 配置 Windows 防火墙日志记录

Azure Arc SQL Server

回想一下，Azure Arc 的顶级 Azure 门户页面(图 7-30 )包括服务器和 Kubernetes 集群的菜单项，这两个 Azure Arc 特性是本书的重点。我们将通过仔细观察 Azure Arc 家族的另一个成员:Azure Arc SQL Server 来结束这一章。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-30

向您的 Azure 订阅添加 Azure Arc SQL Server

概观

一旦你开始将多种 Azure Arc 资源类型添加到你的 Azure 订阅中，微软对 Azure Arc 的愿景就能得到认可。正如 Azure Arc server 在功能上等同于 Azure VM ，本地 SQL Server 就像运行 SQL Server 的 in-Azure IaaS VM。 Azure Arc SQL Server 是在 in- Azure SQL 虚拟机和本地 SQL 服务器之间实现管理对等的一个步骤。

Azure SQL 虚拟机

与 Azure Arc server 的比较特指 Azure 提供的“Azure SQL 虚拟机”。这是基于 Windows Server 和 SQL Server IaaS 配置的高级 Microsoft Azure 服务产品。该产品的主要特征是 Azure 资源类型:

Microsoft.SqlVirtualMachine/sqlVirtualMachines

该资源类型允许从 Azure 门户或其他受支持的 Azure 管理工具(如 PowerShell 和 REST API)管理 SQL Server 应用。用于高可用性的高级 SQL 功能(如始终开启)和实用功能(如备份和修补)是从 Azure 控制平面管理的，而不是从服务器操作系统管理的。Azure 使用由 Windows Azure 访客代理安装的 VM 扩展Microsoft.SqlServer.Management.SqlIaaSAgent与 SQL 应用通信，该代理运行在所有 Azure VMs 上。

Azure Arc SQL 服务器

Azure Arc 支持的 SQL Server 允许您管理 SQL Server 的全球库存，使用 Microsoft Defender for Cloud workload protection for servers 保护 SQL Server 实例，并定期评估和调整 SQL Server 配置的运行状况。Azure Arc SQL Server 解决方案基于以下 Azure 资源类型:

Microsoft.AzureArcData/sqlServerInstances

就像 in-Azure 原始版本一样，这种资源类型允许从 Azure 门户或其他受支持的 Azure 管理工具管理 SQL Server 应用——即使 IaaS VM 或物理 SQL Server 在您的本地数据中心运行！Azure Arc SQL Server 的第一个版本使用CustomScriptExtension VM 扩展在 SQL Server 的操作系统中运行脚本。回想一下，在每个 Azure Arc 服务器上运行的是访客配置扩展服务，它在安装、修改和删除 VM 扩展时执行与 Windows Azure 访客代理相同的功能。

关注 SQL Server 评估

正如 Azure 虚拟机和 Azure Arc 服务器对统一的操作系统管理和安全性有着相同的需求一样，in-Azure 和非 Azure SQL 服务器也需要相同的应用和数据库配置评估。微软已经选择了 SQL Server 管理的按需评估方面来领导他们的 Azure Arc SQL Server 计划。如果您遵循了本书的建议，并为服务器部署了 Microsoft Defender for Cloud workload protection，那么将 Azure Arc SQL Server 的工作负载保护添加到您的安全计划中是一种自然的发展。

在本书中，我们展示了非 Azure Windows 和 Linux 服务器以及 Kubernetes 集群的管理特性中的奇偶校验是如何增加安全性并提高效率的。现在考虑一下，将统一的评估覆盖面引向所有位置的所有类型的 SQL 资源—,将会显著提高贵组织的数据库就绪性和安全性。

Azure Arc SQL Server:Azure Arc Server 的超集

图 7-31 在一个视图中显示了 Windows 和 Linux Azure Arc 服务器—以及 Windows 和 Linux Azure Arc SQL Server 资源—。

img/506033_1_En_7_Fig31_HTML.png

图 7-31

Azure Arc 服务器和 Azure Arc SQL Server 资源

在 Azure Arc server 中注册的非 Azure 服务器也运行 SQL Server，也可以选择在 Azure Arc SQL Server 中注册。这创建了两个 Azure Arc 资源:一个代表服务器本身，另一个代表 SQL Server 应用。同样，这也是微软对 in-Azure SQL 虚拟机的做法。图 7-32 是微软为了解释 Azure Arc SQL Server 如何工作而制作的。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-32

SQL Arc 扩展的工作原理。(来源:微软)

图 7-32 (混合服务器)的左边部分应该是熟悉的 Azure Arc 服务器组件，在本书第四章“Azure Arc 服务器:入门”中有描述正确的部分(日志分析、安全中心、Microsoft Sentinel)在第 6 “混合服务器监控解决方案”和本章前面的章节【Azure Arc 服务器的法规和安全合规性中有所涉及。Azure Arc SQL Server 特有的是中间的 Azure 数据服务部分。

*### 将您的 SQL Server 连接到 Azure Arc

按照以下步骤开始使用 Azure Arc SQL Server:

通过注册 Microsoft 来准备您的 Azure 订阅。使用以下方法之一的 AzureArcData 资源提供程序:
- 蓝色门户网站
  1. 在 Azure 门户中导航到主页➤订阅➤设置➤资源提供商。
  2. 搜索Microsoft.AzureArcData并选择寄存器。
- Azure PowerShell
```
Login-AzAccount
Set-AzContext -SubscriptionId <SubscriptionId>
Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData
```
- 蓝色 CLI
在你的 Azure 门户中导航到➤ Azure Arc ➤ SQL 服务器，然后点击创建。

Tip

第一次为 Azure Arc SQL Server 创建 onboarding 脚本时，在您生成脚本以“激活”Azure Arc SQL Server 的第四个页面的顶部会出现一个确认提示。你按下接受键，就再也不用想它了。它很容易被忽略。

选择要装载的 Azure Arc SQL Server 的资源组、区域和操作系统，然后单击下一步的和运行脚本**。**
将脚本复制到剪贴板，并在要加载的 SQL Server 上将内容保存为onboardazurearcsql Server script . PS1。
按如下方式准备 SQL Server:
- SQL Server 需要。NET Framework 4.7.2 或更高版本来运行 Az PowerShell cmdlets。
  1. 下载。NET Framework 4.8 在此链接:go . Microsoft . com/fwlink/？linkid = 2088631
  2. 需要重新启动系统。
- 在提升的会话中运行这些 PowerShell 命令，然后重新启动 PowerShell 会话:
```
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

Install-Module -Name Az -AllowClobber -Force

Import-Module -Name Az.Accounts
```
在提升的 PowerShell 会话中运行 onboardazurearcsql server script . PS1 脚本。
- 该脚本将安装和配置文件，并在某个时候会提示您在浏览器中输入 URL 并输入代码。
- 出现提示时，使用在您的 Azure 订阅中拥有权限的凭据登录 Azure，以在您创建脚本时选择的 Azure 资源组中创建 Azure Arc 和 Azure Arc SQL Server 资源。
- 您不必在运行脚本的计算机上使用浏览器；任何能上网的浏览器都可以。
该脚本执行以下操作:
- 使用 PowerShell 检查从您的环境到 Azure 和指定计算机的连接
- 通过部署 Azure Connected Machine 代理，将主机作为 Azure Arc 服务器启动(如果尚未启动)
- 启动 SQL Server 实例发现
- 将目标计算机上的 SQL Server 实例添加到 Azure

当脚本成功完成时，您将看到以下消息:

SQL Server - Azure Arc resource: <servername> created

在将 SQL Server 实例注册到支持 Azure Arc 的 SQL Server (preview)后，转到 Azure 门户并查看新创建的 Azure Arc 资源。您将看到一个新的机器(Azure Arc 用于每个连接的机器)和一个新的 SQL Server (Azure Arc 资源用于每个注册的 SQL Server 实例)。

图 7-33 显示了您可以在 Azure Arc SQL Server 资源的概览页面上看到的内容。箭头指向两个位置，您将在那里找到有关 SQL server 的清单信息。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-33

Azure Arc SQL Server 帮助您跨云跟踪 SQL 库存

此时，修改 Azure Arc 服务器和/或 Azure Arc SQL Server 对象上的标签，以适应贵组织中任何现有的标签管理方案。

连接 Azure Arc SQL Server for Linux

RegisterSqlServerArc 脚本将 Linux 计算机连接到 Azure Arc 服务器和 Azure Arc SQL 服务器。

复制 RegisterSqlServer。Arc.sh 到 Linux 服务器，并使该文件可执行:
运行脚本:

chmod 700 RegisterSqlServerArc.sh

出现提示时，选择 Y 安装 Azure CLI。

sudo ./RegisterSqlServerArc.sh

Tip

Azure Arc SQL Server 对 SQL Server Linux 版本的支持在当前预览版中是最低限度的。Azure Arc SQL Server 的环境健康和安全中心特性对于 Linux 是灰色的。Linux SQL Servers 的增值仅限于清单和标记功能。

Azure 资源图中的 SQL Server 清单

Azure Arc 的一个引人注目的特性是将您的混合资产的配置投影到 Azure Resource Manager (ARM)中。这意味着你可以使用 Azure 中所有你认为合适的管理工具来完成你的工作。Azure 门户中的 Azure Resource Graph Explorer 允许您浏览您的 Azure 资源，并可选择导出数据以用于其他记录和报告系统。

要使用 Azure 资源图浏览器查看您的 Azure Arc SQL Server 清单数据，请导航到此页面: https://portal.azure.com/#blade/HubsExtension/ArgQueryBlade

在搜索框中，过滤资源类型 Microsoft.azurearcdata/sqlserverinstances(SQL Server-Azure Arc)，点击资源类型填充查询窗口，点击运行查询。如图 7-34 所示的结果包括有关 SQL server 版本、版本、实例名称、TCP 端口和排序规则类型的信息。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-34

Azure 资源图浏览器中的 Azure Arc SQL Server 属性

在结果区域点击下载为 CSV ，获得如图 7-35 所示的 SQL 清单的离线记录副本。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-35

从 Azure 资源图转储的 Azure Arc SQL Server 清单

将 SQL Server 实例大规模连接到 Azure Arc

您可以使用 Azure Arc SQL Server 安装脚本在多台机器上注册 SQL Server 实例。请通过以下网址查看大规模注册方法的详细信息:

https://docs.microsoft.com/en-us/sql/sql-server/azure-arc/connect-at-scale?WT.mc_id=Portal-Microsoft_Azure_HybridData_Platform&view=sql-server-ver15

该过程与本书第五章“Azure Arc 服务器:大规模使用”中描述的过程相同，因为您将在 Azure AD 中创建一个服务主体，向服务主体授予权限，并修改大规模安装脚本以使用服务主体的凭据。

运行按需 SQL 评估

Azure Arc SQL Server 的核心是它与 SQL Server 评估的集成。Azure Arc SQL Server 提供了一种大规模部署 SQL Server 评估解决方案的机制。有两种方式将 SQL Server 评估部署到您的 Azure Arc SQL Servers:自动使用 Azure VM 扩展或通过在每个 SQL Server 上运行脚本。在图 7-36 中看到的 Azure Arc SQL Server 的环境健康页面是您开始使用这两种方法的地方。

img/506033_1_En_7_Fig36_HTML.png

图 7-36

从 Azure Arc SQL Server 环境运行状况页面配置 SQL 评估

无论您使用哪种方法，自动还是手动，该解决方案都会创建一个计划任务，每周运行一次 SQL Server 评估，并将报告数据上传到 Azure Log Analytics 工作区。

服务集线器连接

在尝试运行 SQL Server 评估之前，请参考此 URL 上的先决条件部分:

https://docs.microsoft.com/en-us/sql/sql-server/azure-arc/assess

特别是，您必须确保您已经将 Azure 订阅链接到微软服务中心并添加了 SQL Server 评估。您必须在 services hub 上注册，并且拥有通过同一启用电子邮件的帐户注册的 Azure 订阅的所有者或参与者权限。

使用托管服务帐户自动部署

当您可以使用托管服务帐户(MSA)方法时，请按照以下步骤在 Azure Arc SQL Server 上生成和查看评估:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-37

在 Azure 门户中查看 SQL Server 评估结果

指定托管服务帐户以激活“配置 SQL 评估”按钮。
- 这将通过部署 CustomScriptExtension 从门户启动评估。因为一次只能部署一个 CustomScriptExtension，所以 SQL 评估的脚本扩展将在执行后自动删除。
- 如果您已经将另一个 CustomScriptExtension 部署到宿主计算机，则不会激活“配置 SQL 评估”按钮。
以 DOMAIN\MSAname$格式输入托管服务帐户，并确认工作目录，默认情况下，该目录为 C:\sql_assessment\work_dir。
点击配置 SQL 评估按钮。
然后在 Azure Arc 服务器中安装一个名为 CustomScriptExtension 的 VM 扩展。CustomScriptExtension 在 Azure Arc SQL Server 上运行 PowerShell onboarding 脚本。
大约 1 到 2 小时后，查看 SQL 评估结果按钮将变为非灰色。点击按钮将在新的刀片中打开评估结果，如图 7-37 所示。

使用配置脚本手动部署

使用下载配置脚本方法时，按照以下步骤在 Azure Arc SQL Server 上生成和查看评估:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-38

确认 SQL 评估计划任务的每周成功运行

从 Azure Arc 服务器环境健康页面点击下载配置脚本按钮。

保存addsqlassession . PS1文件，并将其复制到 Azure Arc SQL Server。这个脚本看起来会像这样:

Add-SQLAssessmentTask -SQLServerName "WS19ArcDemo.odyssey.com" -WorkingDirectory "C:\sql_assessment\work_dir" -RunWithManagedServiceAccount $True -ScheduledTaskUsername "ODYSSEY\momActGMSA$" -ScheduledTaskPassword (new-object System.Security.SecureString)

观察如图 7-38 所示的计划任务在服务器上的路径任务计划程序➤任务计划程序库➤微软➤运营管理套件➤ AOI- < GUID > ➤评估➤ SQL 评估中创建。
在 Azure Arc SQL Server 上完成预定任务后不久，如果您返回到 Azure Arc SQL Server 的 Azure portal 页面并再次单击环境健康菜单项，您将看到如图 7-37 所示的相同报告视图。

为 SQL Server 启用 Microsoft Defender for Cloud

除了 Azure Arc SQL Server 的清单、标记和 SQL 评估优势，该解决方案还有一个额外的高价值功能。这是 Microsoft Defender for Cloud workload protection for SQL Server 在 Azure 门户中的建议和来自 Microsoft Defender for Cloud on Azure Arc SQL Server blades 的安全警报。

如图 7-39 所示，Azure Arc SQL Server 将确认 Microsoft Defender for Cloud for SQL 在处于状态，并且来自 Microsoft Defender for Cloud 的任何建议或警报都很容易找到并采取行动。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 7-39

Microsoft Defender for Cloud workload protectionfor SQL Server 为 Azure Arc SQL Server 添加了有价值的内容

正如本章前面的“Microsoft Defender for Cloud”部分所建议的，作为最佳实践，您将为所有涵盖的资源类型启用 Microsoft Defender for Cloud protection，包括 Azure Defender for SQL Server。

Microsoft Defender for Cloud workload protection for SQL Server 检测异常活动，这些异常活动表示对访问或利用数据库的异常和潜在的有害尝试。
当存在可疑的数据库活动、潜在的漏洞或 SQL 注入攻击以及异常的数据库访问和查询模式时，会触发安全警报。

摘要

本章重点介绍了 Azure Arc 如何成为组织安全服务的主要提供者。我们首先解释了 Azure Arc 如何将 Microsoft Defender for Cloud workload protection for server 的所有安全优势扩展到您的非 Azure 服务器。然后，我们详细介绍了如何使用 Qualys 的集成漏洞评估来提供内部扫描覆盖范围、查看扫描结果和补救发现。

接下来，我们介绍了如何优化配置 Microsoft Sentinel 来保护 Azure Arc 服务器。解释了选择分析和异常规则的最佳实践方法，我们深入研究了如何将 Azure Logic 应用定制为 Microsoft Sentinel 行动手册。最后，我们看了 Azure Arc 家族的另一个成员 Azure Arc SQL Server，并对微软如何在混合领域提供新的管理体验有了进一步的了解。

下一章“GitOps Insights”是关于代码形式的基础设施。将向您介绍 GitHub 平台和 GitOps 的概念。您将了解如何使用 GitOps 部署 CI/CD 解决方案，以便使用 Git 存储库在支持 Azure Arc 的 Kubernetes 集群上创建配置。***