Entity Framework DbContext是否应使用比迁移权限更低的用户运行？

我们常说的两类迁移方案，本质区别是权限分配：

• 启动自动执行迁移：要求业务应用的数据库账号持有DDL（表结构修改、创建、删除类）权限，代码中通常调用dbContext.Database.Migrate()实现
• 权限分离方案：业务应用的数据库账号仅保留DML（数据增删改查）权限，迁移由独立程序/脚本在发布前置阶段执行，仅该迁移流程持有DDL权限

以下几类场景下，权限分离方案是必要且值得投入的：

• 高合规要求的敏感业务场景
  金融、医疗、政务等涉及公民敏感信息的系统，等保、行业合规规范明确要求遵循最小权限原则，必须严格隔离Schema修改权限与普通业务操作权限。这种权限隔离同时满足审计要求，避免业务侧的任何漏洞直接影响数据库核心结构。
• 多副本集群部署的分布式应用
  当你的应用采用多实例集群部署时，启动时自动执行迁移极易出现并发冲突，轻则迁移执行失败，重则损坏表结构。独立执行迁移可以保证整个发布流程中Schema变更仅执行一次，随后再滚动升级业务实例，完全规避并发风险。
• 第三方私有化部署的商用产品
  面向客户私有化交付的商用软件，客户侧DBA几乎不会给业务应用开放DDL权限，所有表结构变更都需要提前审核、由DBA单独执行。这种场景下你必须输出独立的迁移程序或者SQL脚本，适配客户的运维管控要求。
• 可用性要求极高的核心业务系统
  核心业务系统无法接受启动时迁移失败导致整体服务不可用的风险。将迁移作为发布的前置步骤执行，一旦迁移失败直接终止发布流程，不会影响线上正在运行的业务，故障影响面被压缩到最低。

针对大家讨论的防护效果争议：现代ORM确实已经能拦截绝大多数SQL注入攻击，且权限隔离无法阻止攻击者写入垃圾数据，但二者的故障恢复成本有量级差距：垃圾数据可以通过备份、校验规则快速清理，而表结构被篡改/删除后，整体服务会完全不可用，数据恢复难度和业务损失要大得多。

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