如何配置Azure权限实现跨订阅复制数据库且不开放生产额外权限

方案1：自定义RBAC角色（最优，零开发成本） #

这是最直接的实现方式，完全不需要额外开发服务，仅通过Azure原生RBAC能力即可满足需求：

• 你不需要匹配内置角色，直接在生产订阅scope下创建仅包含数据库复制最小权限的自定义角色即可，权限范围完全可控，不会给生产环境开放额外权限：
  • 如果使用Azure SQL DB，允许的操作（Actions）仅配置以下3条：

    Microsoft.Sql/servers/read
    Microsoft.Sql/servers/databases/read
    Microsoft.Sql/servers/databases/copy/action
    

  • 如果使用Azure MySQL/PostgreSQL等其他托管数据库，替换为对应资源的copy/action权限即可
• 自定义角色的可分配范围（AssignableScopes）仅限定为生产订阅，不要扩大到更高层级的管理组
• 将该自定义角色分配给开发人员的AAD用户组即可，开发人员仅拥有源生产库的读取、复制权限，目标开发订阅本身已有contributor权限，可正常写入复制的数据库实例

方案2：Azure自动化账户Runbook（无需自定义开发服务，适合不想修改生产RBAC分配的场景） #

如果你们不想直接给开发人员分配生产订阅的角色，可直接使用Azure原生的自动化服务，比你自研C#托管工具的成本低很多：

• 创建独立的Azure自动化账户，为账户的系统托管标识分配方案1中提到的最小复制权限
• 在自动化账户中创建PowerShell/CLI类型的Runbook脚本，仅暴露源库资源ID、目标订阅ID、目标库名称三个可输入参数，脚本逻辑固定为跨订阅复制操作
• 给开发人员仅分配该Runbook的Microsoft.Automation/automationAccounts/runbooks/read和Microsoft.Automation/automationAccounts/runbooks/jobs/write权限，开发人员仅能填写参数触发复制任务，无法接触到生产环境的任何凭证，也不能修改生产资源

自研方案合理性说明 #

你提到的C#托管工具+服务账号+API的方案属于过度设计，上述两个原生方案已经可以覆盖需求，不需要额外投入开发、运维自定义服务的成本。

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