本文介绍使用 Azure 基于角色的访问控制（Azure RBAC）的一些最佳做法。 这些最佳做法派生自我们在 Azure RBAC 方面的经验以及客户（如自己）的体验。
使用 Azure RBAC，可以在团队中实现职责分离，仅向用户授予他们执行作业所需的访问权限。 相较于在 Azure 订阅或资源中为每个人提供不受限制的权限，您可以仅在特定范围内允许某些操作。
规划访问控制策略时，最佳做法是向用户授予完成工作的最低特权。 即使最初似乎更方便操作，也应避免在更广泛的范围内分配更大的角色。 创建自定义角色时，仅包括用户所需的权限。 通过限制角色和范围，可以对在安全主体受到入侵的情况下会面临风险的具体资源进行限制。
下图显示了使用 Azure RBAC 的建议模式。
有关如何分配角色的信息，请参阅 使用 Azure 门户分配 Azure 角色。
最多只能有 3 个订阅所有者，这样可降低被入侵的所有者做出违规行为的可能性。 可以在 Microsoft Defender for Cloud 中监视此建议。
某些角色标识为 特权管理员角色。 请考虑执行以下作来改善安全状况：
- 删除不必要的特权角色分配。
- 避免在可以改用 作业功能角色 时分配特权管理员角色。
- 如果必须分配特权管理员角色，请使用范围较窄的范围，例如资源组或资源，而不是更广泛的范围，例如管理组或订阅。
- 如果您正在分配一个具有创建角色指定权限的角色，建议添加一个条件来约束该角色指定。
有关详细信息，请参阅列出或管理特权管理员角色分配。
若要保护特权帐户免受恶意网络攻击，可以使用 Microsoft Entra Privileged Identity Management （PIM）降低特权的暴露时间，并通过报告和警报提高对其使用情况的可见性。 PIM 通过提供对 Microsoft Entra ID 和 Azure 资源的实时特权访问来帮助保护特权帐户。 访问可以有时间限制，之后自动撤销特权。
有关详细信息，请参阅什么是 Microsoft Entra Privileged Identity Management？。
若要使角色分配更易于管理，请避免将角色直接分配给用户。 而是将角色分配给组。 将角色分配给组而不是用户，这也有助于最大程度地减少角色分配的数量，因为每个订阅都有限制角色分配的数量。
角色名称可能会更改几次，例如：
- 你使用的是自己的自定义角色，你决定更改角色名称。
- 你使用的是预览角色，其名称中带有“（预览）”。 释放角色后，将重命名该角色。
即使重命名了角色，角色 ID 也不会更改。 如果使用脚本或自动化来创建角色分配，最佳做法是使用唯一的角色 ID 而非角色名称。 这样一来，即使角色重命名，脚本仍可以使用。
有关详细信息，请参阅 使用唯一角色 ID 和 Azure PowerShell 分配角色 ， 并使用唯一角色 ID 和 Azure CLI 分配角色。
创建自定义角色时，可以使用通配符 （*） 字符定义权限。 建议显式指定 Actions 和 DataActions，而不要使用通配符 (*) 字符。 通过未来可能的授予 Actions 或 DataActions 的新增访问和权限，可能会出现不必要的通配符使用行为。 有关详细信息，请参阅 Azure 自定义角色。