如何阻止Azure订阅所有者修改特定资源组？

需求背景 #

我们正在探索如何保护订阅内的部分Azure资源，防止包括订阅所有者在内的用户篡改。目标是标准化供其他团队用于工程工作的订阅。曾考虑为团队提供类似Owner和Contributor的自定义RBAC角色，仅缩减部分权限，但这种方法实施难度高，且无法覆盖所有场景——有些场景下移除权限可行，但另一些场景中需要授予权限，同时限制其仅用于特定资源。

我们偏好的设计方案是：在每个标准化订阅中创建一个命名固定的资源组（RG），将用户不得修改或删除的资源放入该组，探索阻止订阅所有者篡改该RG及其资源的方法。

已尝试的方案 #

• 移除操作/权限不可行：用户需要这些操作/权限来管理同类型的其他资源（例如，禁止用户创建/修改/删除资源组并不现实）
• 定义Azure Resource Policy拒绝对该RG的所有操作：该方案无效
• 定义Azure Resource Policy要求保留标准资源：无法阻止删除操作
• 使用预览版Blueprints创建锁定（非Resource Lock类型）的RG并应用拒绝分配

存在缺陷的备选方案 #

• 依赖Policy在必要资源被销毁时进行报告（并可能重新部署）
  • 这些资源与安全和合规相关——Policy最终能检测到资源缺失，但删除与检测之间的时间差可能导致订阅存在风险
• 拒绝用户的资源锁定权限，独占锁定该RG使其无法解锁
  • 当RG被解锁时将失去保护，需协调解锁、应用更新、重新锁定，并验证解锁期间未混入其他内容，流程复杂
• 为每个团队的订阅分配单个RG，并仅在RG级别授予权限
  • 若RG支持嵌套可能可行，但剥夺Azure工程师的资源组管理权限不合理，且可能导致RG因包含多个部署而臃肿
• Blueprints作为选项
  • 同样存在协调资源解锁与重新锁定的问题；此外我们的IaC平台是Terraform，Blueprints属于另一层IaC，需分析如何仅用Blueprints创建保护机制，同时让Terraform负责大部分工作

内容的提问来源于stack exchange，提问作者STW