保护 Azure 环境
现在你已了解如何控制环境并保护部署管道，可以考虑禁用对受控环境的人工访问。 在本单元中，你将了解如何构建用户对 Azure 环境的权限。 包括如何在紧急情况下允许访问，以及如何审核 Azure 资产中发生的任何更改。
阻止人工访问
通过阻止对受控环境的人工访问，可以确保意外或恶意更改无法绕过团队的审查和自动化部署过程。 如果不阻止人工访问，可能会有人无意中绕过你花费大量时间在整个存储库和管道中规划和实现的控制措施。
如果没有阻止控制措施，也很容易有人意外破坏某些内容。 例如，假设用户打开了两个 Azure 门户副本。 一个用于测试环境，另一个用于生产环境。 当用户在浏览器标签页之间来回切换时，他们很容易意外地对生产环境进行本打算对测试环境进行的更改。
若要阻止人工访问，可以使用 Azure 基于角色的访问控制 (RBAC)。 在 RBAC 中创建角色分配，以定义：
- 哪些用户、组或服务主体可以访问一组定义的 Azure 资源（范围）。
- 这些用户、组或服务主体在访问资源时可以执行的操作（角色）。
Azure RBAC 提供许多内置角色类型，包括：
- 读者，对环境具有只读访问权限。
- 参与者，可以修改资源。
- 所有者，可以修改资源并向他人授予访问权限。
在适当的范围内授予访问权限非常重要。 如果组织遵循为每个环境使用专用 Azure 订阅的建议做法，请考虑使用 Azure 管理组来简化角色分配的范围。 如果组织对所有环境使用单个 Azure 订阅，请避免向人授予对整个订阅的访问权限，因为所有资源（包括受控环境）都将继承该权限。
提示
角色分配是 Azure 资源管理器 (ARM) 资源。 这意味着可以在代码中配置 Azure RBAC 角色分配，例如使用 Bicep。
规划角色分配时，需要确定对组织有意义的内容。 例如，假设组织为每个环境创建单独的订阅。 可以选择向管理员和开发人员授予对受控环境的读者访问权限。 使用该角色，他们可以访问 Azure 门户中的生产环境，以查看资源的配置、查看指标和日志，并调查问题或 bug，而不会对环境进行任何更改。
下面介绍如何针对 Azure 管理员以及编写代码和脚本的开发人员，为玩具公司的环境配置角色分配：
| 环境名称 | 控制级别 | 管理员权限 | 开发人员权限 |
|---|---|---|---|
| 开发 | 受控 | 读取器 | 读取器 |
| 测试 | 受控 | 读取器 | 读取器 |
| 过渡 | 受控 | 读取器 | 读取器 |
| 生产 | 受控 | 读取器 | 读取器 |
| 演示 | 不受控 | 所有者 | 参与者 |
| 性能测试 | 不受控 | 所有者 | 无 |
| 渗透测试 | 不受控 | 所有者 | 无 |
| PR 审查 | 不受控 | “所有者” | “所有者” |
| 开发沙盒 | 不受控 | “所有者” | “所有者” |
规划角色分配时，请确保对其进行全面测试。 有时，管理操作可能需要不明显的权限。 为团队成员提供使用计划使用的权限测试其所有日常工作的机会。 查看他们遇到的任何问题。
定期审核角色分配。 确保未意外向错误的人员的授予访问权限或授予过宽的访问权限。
数据平面访问
Azure 中有两种类型的操作：
- 控制平面操作，用于管理订阅中的资源。
- 数据平面操作，用于访问资源公开的功能。
例如，可使用控制平面操作创建存储帐户。 可使用数据平面操作连接到存储帐户并访问其中包含的数据。
阻止用户直接访问 Azure 资源时，还要考虑此限制如何应用于数据平面操作。 例如，部署过程可能会将存储帐户的密钥存储在管理员可以访问的位置。 管理员可能会使用该密钥绕过控制措施并直接访问存储帐户的数据平面。
越来越多的 Azure 资源支持使用 Microsoft Entra ID 配置其数据平面访问控制。 这种支持可降低意外泄露密钥或授予数据平面访问权限的可能性。 最好尽可能使用 Microsoft Entra ID 进行数据平面访问。
紧急访问
有时，会发生紧急情况，有人需要快速访问生产环境来调查或解决问题。 在发生紧急情况之前，请务必计划和排练如何应对这些紧急情况。 你不会想在中断期间仓促地做出响应。
可以考虑的一种方法是使用应急帐户，它是一种特殊的用户帐户，其权限级别高于用户通常拥有的权限。 它被命名为应急帐户，因为它需要一些不寻常的东西才能获得其凭据，类似于打破火警面板上的玻璃。 你可以为操作员提供一种安全的方式来获取对应急帐户凭据的访问权限。 然后，这些操作员可以使用该帐户登录以执行紧急更改。
使用应急帐户的步骤顺序为：
- 用户尝试使用其普通帐户执行紧急更改，但操作被阻止，因为普通用户帐户没有足够的权限。
- 用户获取应急帐户的凭据，并以该用户身份登录。
- 用户（以应急帐户的身份）获准执行该操作。
使用应急帐户需要高度的纪律。 该帐户应仅供真正的紧急情况使用。 请仔细管理和保护其凭据，因为该帐户具有很高的特权。 最好经常更改应急帐户的凭据，以最大程度减少它们被公开或泄露的可能性。
应急帐户通常在团队中共享，因此很难跟踪使用过这些帐户的人员以及这些用户执行的操作。 另一种使用不受限帐户的方法是采用 Microsoft Entra Privileged Identity Management (PIM) 功能。 它允许暂时向用户自己的帐户授予更高级别的权限。
使用 PIM 的步骤顺序为：
用户尝试使用其普通帐户执行紧急更改，但操作被阻止，因为普通用户帐户没有足够的权限。
用户联系 PIM 并请求临时提升权限。
PIM 可能会对用户的身份执行额外的验证，或者请求某人批准，具体取决于为组织配置的方式。
如果请求获得授权，PIM 将暂时更新用户的权限。
用户获准执行操作。
经过定义的时间段后，PIM 将撤销其授予用户的提升权限。
PIM 和 Azure 都会编写全面的审核日志，以帮助你了解谁请求了提升的权限以及请求原因。 这些日志还会跟踪用户被授予权限后在环境中执行的操作。
注意
PIM 需要 Microsoft Entra ID 的高级许可证。
紧急事件结束后
在紧急事件结束后，必须有一个恢复正常操作的流程。 你应该避免在经历过长时间之后才按照此过程操作，否则可能会忘记重要信息或使配置处于不安全状态。
仔细查看 Azure 和 PIM 审核日志，了解在受控环境中执行的更改，尤其是生产环境。
重要
使用 PIM 或应急帐户的人可能有机会向其常规用户帐户授予比其应有权限更广泛的访问权限。 他们还可以使用临时权限来获取对数据平面密钥的访问权限，这些密钥可在撤销权限后继续使用。
请仔细审核应急帐户或 PIM 的所有使用情况。 撤销或轮换可能在紧急情况下公开的任何密钥。
在紧急情况发生不久之后，将基础结构即代码资产与在紧急情况下进行的任何更改重新同步。 例如，假设在解决紧急问题的过程中，管理员手动增加了 Azure 应用服务计划的 SKU。 更新部署模板，以在资源配置中包含新的 SKU。 否则，在管道的下一次常规部署期间，SKU 可能会重置为以前的值，并导致另一次中断。
审核对 Azure 环境的更改
此外，最好还在整个 Azure 环境中配置审核和日志记录，并监视特定事件或威胁。
请考虑使用安全信息和事件管理 (SIEM) 工具，例如 Microsoft Sentinel。 可以使用此工具从 Azure 资产，甚至从 Azure DevOps、GitHub 以及其他系统收集和分析日志。 可以使用 Sentinel 监视对 Azure 资源的意外或未经授权的更改。 还可以导入管道的审核日志，并在事件发生时触发警报，例如当管理员更改存储库中的分支保护策略时。