自动化Azure SQL数据库部署时，如何处理环境专属安全权限？

1. 拆分架构与权限配置，不让权限进DACPAC #

DACPAC默认会同步所有数据库对象，包括角色、用户和权限，这是冲突的根源。解决办法是：

• CI阶段生成DACPAC时，只打包表、视图、存储过程这些核心业务架构对象，把角色、用户、登录名和权限设置排除在外。具体可以在SQL Server Data Tools(SSDT)的项目设置里，在“部署选项”中勾选“忽略用户”“忽略数据库角色”“忽略登录名”，或者在发布配置文件里配置对应忽略规则。
• 单独用SQL脚本管理每个环境的权限，比如给dev、staging、prod各写一份Permissions.sql，CD流水线先部署DACPAC，再执行对应环境的权限脚本。这样不同环境的权限可以独立维护，不会被DACPAC覆盖或搞出冲突。

2. 给每个环境配专属部署账号，遵循最小权限原则 #

• 别用同一个账号部署所有环境，给dev、staging、prod分别创建独立的部署服务账号，只给这个账号刚好能完成DACPAC部署的权限就行。比如别直接给db_owner，可以用db_ddladmin（管架构变更）加db_securityadmin（如果需要调整权限的话），或者更细的权限组合，确保它只能改架构，碰不了现有角色权限。
• 绝对别用生产环境的服务器管理员账号去部署，既容易出冲突，也有安全风险。

3. 用环境专属的发布配置文件做差异化控制 #

• 给每个环境单独做发布配置文件（.publish.xml），在里面设好专属规则：比如生产环境里，开BlockOnPossibleDataLoss=True防止数据丢失，同时设IgnorePermissions=True、IgnoreRoleMembership=True，让DACPAC别碰生产环境的权限配置。
• CI/CD流水线里用变量动态选配置文件，比如Azure DevOps里，通过阶段变量指定SqlPublishProfilePath参数就行。

4. 生产环境用影子部署或滚动部署降低风险 #

如果生产环境权限碰不得，试试这两种方式：

• 影子部署：在生产库旁边搭一个一模一样的影子库，先把DACPAC部署到影子库，验证权限和功能都没问题后，再把业务流量切到影子库，原生产库留作备份。
• 滚动部署：先升级只读副本，验证没问题后再逐步升级主库，减少权限冲突对业务的影响。

5. 给权限变更加审批流程 #

• 不管哪个环境，新增角色、改权限这类操作都得走审批，别让未经确认的权限修改混进部署流程。
• CD流水线里给权限脚本的执行加人工审批环节，尤其是生产环境，必须确认没问题再执行。

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