Windows 11 提供 Copilot Pro 订阅通道
Windows 11 提供 Copilot Pro 订阅通道
Copilot 在数字世界人尽皆知，早先在手机上安装了 Copilot，当希望订阅Copilot Pro时总会遇到失败。但今天在 Windows 11 上（22631.3227）可以在“设置”应用中的“主页”看到 Microsoft Copilot Pro 订阅提示。点击“获取 Copilot Pro”即可转向至订阅流程，首先确认所在地区，才可进行下一步订阅的执行。
此外，在“账户”中也会看到 Copilot Pro 的订阅提示。同理会先让用户确认当前所在的位置，才能进行后续的操作。我们也可以直接访问 Corpilot Pro 站点获取更详尽的信息。
如果尚未订阅 Copilot Pro，也是可以使用免费版本的，如下图所示，我们可以基于生成式对话模式进行 AI 交流寻求帮助。但是……
但是……如果我们一旦订阅 Copilot Pro，那可就不得了了！首先允许我们在高峰时段优先访问 GPT-4 和 GPT-4 Turbo。如果我们已经订阅了 Microsoft 365 家庭版或个人版，那么可以在 Word、Excel、Outlook、PowerPoint 和 OneNote 中使用 Copilot 为我们更快的创建、编辑内容，例如：起草文档、总结电子邮件、创建演示文稿等。此外，我们还可以使用 Microsoft Designer（以前称之为 Bing Image Creator）每天进行 100 次提升的 AI 图像创作。
心动不如行动，每月 20美金！即可添加一个副驾助手帮我们提升个人效率！
解读 Updating Microsoft Secure Boot keys
解读 Updating Microsoft Secure Boot keys
微软官方最近发布了一篇文章 - “Updating Microsoft Secure Boot keys”引起了 gOxiA 的关注。内容主要涉及 UEFI 设备用于安全启动的密钥更新，对于那些在组织中执行桌面标准化和安全的 IT 人员需要特别关注。今天本文将与大家分享文中涉及到的一些技术知识！
首先，我们需要对 UEFI 有个大致的认识，UEFI 即 统一可扩展固件接口，基于标准的 UEFI 规范的启动加载程序通用框架，参与 UEFI 规范的技术公司目前已经超过了140家，其中就包括大家熟知的多个硬件大厂。在过去我们的计算机加电开机时由 BIOS 启动进行初始化，但现在 UEFI 接管了这一切，它将控制 PC 的启动过程，然后将控制传递给 Windows 或其他操作系统。可以说 UEFI 环境是启动 Windows 设备并运行 OS 的最小启动 OS。对于现代64位计算机基本上都已经默认使用 UEFI，大众所了解的可能更多的是 UEFI 提供了更加友好的图形化配置界面，甚至还提供额外的一些功能，对于启动计算机速度更快，更适用于 SSD。但 UEFI 优点远不止这些，在 UEFI 2.3.1 规范的固件还具有以下优点：
- 能够支持 Windows 10 安全功能，例如：Secure Boot、Defender Credential Guard 和 Defender Exploit Guard
- 启动和恢复的速度更快
- 能够更轻松地支持大硬盘驱动器（＞ 2TB）或超过4个分区的驱动器
- 支持多播部署
- 支持 UEFI 固件驱动程序、应用程序和选项 ROM
从下图我们可以了解到适用于 Windows 的 UEFI 组件，涉及到 Windows 的 UEFI 协议还可以参考 https://learn.microsoft.com/zh-cn/windows-hardware/drivers/bringup/uefi-protocols-for-windows 进行学习和了解。
此外，我们还需要了解一个名词 - SoC，即：系统级芯片，也称为片上系统。比较抽象化，它将集成电路的设计、系统集成、芯片设计、生产、封装、测试等等集成在了一起，现代电脑目前都已经采用 SoC 技术，而用于运行在 SoC 上的 Windows 则对 UEFI 也有着最低的要求，从 Windows 10 1703 开始，微软要求遵守 UEFI 2.3.1c 规范。
现在我们再来了解 Secure Boot - 安全启动，它也是一个行业安全标准，旨在确保使用受设备制造商信任的软件进行设备启动。当电脑启动时，固件会检查每个启动软件的签名，也包括 UEFI 固件驱动程序、EFI应用程序和操作系统。如果签名有效，则电脑继续启动，并最终将控制权移交至操作系统，其保护过程可参考下图所示。
对于具有安全启动的电脑，其启动顺序如下：
- 打开电脑，将会根据平台密钥检查签名
- 如果固件不受信任，则 UEFI 必须启动 ROM 特定的恢复过程，以还原受信任的固件
- 如果 Windows 启动管理器出现问题，固件将尝试启动 Windows 启动管理器的备份副本，如果此措施仍然失败，则固件必须启动 OEM 特定的补救过程
- 在 Windows 启动管理器开始运行后，如果驱动程序或 NTOS 内核出现问题，则会加载 Windows RE（恢复环境）
- Windows 加载反恶意软件
- Windows 加载其他内核驱动程序并初始化用户态进程
综上，安全启动这一过程将极大降低 Boot rootkit 带来的风险。此外，利用 Intune 的设备管理策略还可以设定阻止那些未启用安全启动的设备访问工作或学校资源。
正如前面介绍的，安全启动是一个行业标准，所以不止 Windows 在使用，其他诸如 Linux 发行版也都有提供支持。在 Windows 平台上要支持安全启动需要满足以下各项要求：
- UEFI 2.3.1 勘误表 C 变量，必须将变量设置为 SecureBoot=1，且 SetupMode=0，并使用所需的签名数据库（EFI_IMAGE_SECURITY_DATABASE），包括有效的 KEK 数据库中设置的 PK 来启动安全预配的电脑。
- UEFI 2.3.1 第27部分，平台必须公开一个符合 UEFI 2.3.1 第 27 部分所述配置文件的接口。
- UEFI 签名数据库，平台必须在 UEFI 签名数据库（db）中预配正确的密钥，使 Windows 能够启动。平台还必须支持在经过身份验证的情况下对数据库进行安全更新。安全变量的存储必须与正在运行的操作系统相互隔离，以防在不经受检测的情况下修改这些变量。
- 固件签名，必须至少使用 RSA-2048 和 SHA-256 加密算法为所有固件组件签名。
- 启动管理器，打开电源时，系统必须开始执行固件中的代码，并根据算法策略使用公钥加密法来验证启动顺序中所有映像的签名，直到验证了 Windows 启动管理器为止。
- 回滚保护，系统必须防止固件回滚到旧版本。
- EFI_HASH_PROTOCOL，平台提供 UEFI_HASH_PROTOCOL 用于卸载加密哈希运算负载，并提供 EFI_RNG_PROTOCOL（由 Microsoft 定义）用于访问平台熵。
对于涉及到的签名证书相关的数据文件，如：签名数据库（db）、吊销的签名数据库（dbx）和密钥注册密钥数据库（KEK）会事先由设备 OEM 厂商写入到固件的非易失性RAM中（NV-RAM）。
签名数据库 (db) 和吊销的签名数据库 (dbx) 将列出 UEFI 应用程序、操作系统加载程序（例如 Microsoft 操作系统加载程序或启动管理器）以及可在设备上加载的 UEFI 驱动程序的签名者或映像哈希。
吊销的列表包含不再受信任且不可加载的项。 如果映像哈希位于这两个数据库中，则吊销的签名数据库 (dbx) 优先。
密钥注册密钥数据库 (KEK) 是单独的签名密钥数据库，可用于更新签名数据库和吊销的签名数据库。 Microsoft 要求在 KEK 数据库中包含指定的密钥，以便 Microsoft 将来可向签名数据库添加新的操作系统，或者向吊销的签名数据库添加已知错误的映像。
添加这些数据库并完成最终的固件验证和测试后，OEM 将锁定固件以避免对其进行编辑（但使用正确密钥进行签名的更新，或者由使用固件菜单的实际用户所做的更新除外），然后生成平台密钥 (PK)。 PK 可用于对 KEK 的更新进行签名或关闭安全启动。
OK，现在回看微软官方文章就可以更清晰的了解其意图！微软与其生态系统合作伙伴将准备替换掉用于安全启动的旧证书，自2024年2月13日起，新数据库更新将作为所有启用安全启动的设备的可选服务更新提供，因为到2026年之前用于安全启动的相关证书将过期。微软也特别强调了为本次更新微软和OEM合作伙伴所作出的努力。
如果准备着手计划更新，建议如下：
- 在大规模更新前，应在具有相同固件和规格的单个设备上测试验证。
- 从 OEM 获取最新版本的固件更新。
- 确保每台设备都执行 Bitlocker 密钥备份。
手动更新的步骤很简单：
- 系统已经安装了2024年2月的累计更新。
- 修改注册表键值，将“HKLM\\SYSTEM\\CurrentControlSetControl\\SecureBoot”下“AvailableUpdates”的值改为“0x40”
- 重启系统两次已确保更新执行并使用更新的数据库启动。
对于计划批量执行的企业环境，可以参考以下命令制作脚本或任务序列。
- Set-ItemProperty -Path “HKLM:\\SYSTEM\\CurrentControlSetControl\\SecureBoot” -Name “AvailableUpdates” -Value 0x40
- Start-ScheduledTask -TaskName “Microsoft\\Windows\\PI\\Secure-Boot-Update”
验证安全启动数据库更新是否成功，可以执行以下 PowerShell 命令，如果结果为 False 则表示失败或未更新。
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
通过事件查看器可以关注相关的事件 ID 进行审计。
事件日志：系统
事件源：TPM-WMI
事件ID：1032、1033、1034、1035、1036、1795、1796
要查看安全启动状态，非常简单，只需要打开运行对话框，输入 msinfo32 并运行，在打开的系统信息窗格中选择系统摘要，在右侧即可看到安全启动状态。
官方参考：
HOWTO: 通过 Intune 配置 Windows 客户端拒绝向移动存储写入数据
HOWTO: 通过 Intune 配置 Windows 客户端拒绝向移动存储写入数据
在企业环境下一些 Windows 客户端将受到严格的管控，尤其是在一些涉及敏感数据的场景中，通常需要禁止将本机数据写入到 USB 等移动存储设备中，以避免数据泄露。如果企业正在使用 Intune 管理这些客户端和策略，那将很轻松的能够实现这些需求，并且提供了更为灵活全面的管控方案。今天就跟随 gOxiA 来做这个配置实践，首先登录 Microsoft Intune 管理中心，进入“设备 – Windows - 配置文件”，然后“创建”配置文件，“平台”这里选择“Windows 10 和更高版本”，“配置文件类型”选择“设置目录”。
进入“创建配置文件”向导页面，先为配置文件填入一个名称，本例为“Deny Removable Storage Write Access”。
然后，找到“Storage”类别（也可以通过搜索找到），然后选中“Remove Disk Deny Write Access”，之后将左侧内容窗格中的配置启用 - “Enabled”即可。
OK！到这里主要配置完成，是不是非常轻松便捷！但是我们从备注中可以了解到，一旦启用该配置，将拒绝所有移动存储的写入。对于那些希望允许将数据写入移动存储已启用 Bitlocker To Go 的组织，则建议改用“Computer Configuration\Administrative Templates\Windows Components\Bitlocker Drive Encryption\Removable Data Drivers”进行配置，如果希望改用则继续关注后面的截图。
我们可以搜索“Bitlocker”分类，找到“Administrative Templates\Windows Components\Bitlocker Drive Encryption\Removable Data Drives”，勾选“Deny write access to removable drives not protected by Bitlocker”，这里我们应当留意它的子选项“Do not allow write access to devices configured in another organization”，这将禁止写入到非授权的设备，即使它已经使用 Bitlocker。此外，我们还要注意，这个分类配置会被前面的“Remove Disk Deny Write Access”覆盖，所以不能同时配置。
OK，一旦决定采用的限制方案即可完成配置进入配置文件分配的页面，最后宣告完成。
如果您希望创建更为复杂的限制策略，可以搜索“Removable”，在“Removable Storage Access”分类中提供了多达38个策略，其中我们可以使用“Custom Classes”为特定设备配置禁止访问的权限。通过“Device Installation Restrictions”还可以允许安装特定的设备进行更为复杂全面的管控，多管齐下的方案总有能够适配组织安全需求的。
最后，如果我们推送了“Remove Disk Deny Write Access”策略，并希望在客户端上验证是否应用了该策略，可以通过事件日志查看器找到“Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider”，并查阅事件ID813的日志，其中能够看到相关的记录。
