Azure Function配置自动回滚，关联Get Web App Publishing Profile事件求助

1. 追踪事件的实际触发源 #

• 深挖活动日志细节：查看Get Web App Publishing Profile事件的完整上下文，重点关注客户端IP、用户代理和操作ID。通过操作ID可以关联到同一会话中的其他操作，排查是否有后续的配置修改动作，或者是否是某个自动化流程的一部分。
• 排查自动化部署管道：检查你的GitHub Actions、Azure DevOps Pipeline、本地脚本或第三方部署工具，看是否存在定期运行的任务。尤其是旧的管道配置，可能仍保留着针对FUNCTIONS_EXTENSION_VERSION ~2的设置，在获取发布配置文件时附带覆盖了当前的应用设置。
• 定位服务主体身份：你看到的随机GUID是Azure AD服务主体的ID，在Azure AD的「企业应用」中搜索这个GUID，找到对应的服务主体。查看它的权限配置、最近登录记录和操作历史，就能确定是哪个系统、脚本或第三方服务在使用这个身份执行操作。
• 启用诊断日志：给Function App开启App Service诊断日志，配置记录所有应用设置变更的请求细节，包括请求头、身份验证信息等。下次出现配置回滚时，就能从日志中获取更完整的溯源数据。

2. 将相关配置设为只读以阻止变更 #

• 使用Azure资源锁：给Function App添加ReadOnly资源锁（注意不是CanNotDelete锁），这会阻止所有修改资源配置的操作，包括应用设置的变更。但要注意，只读锁会限制所有修改动作，包括正常的部署更新，所以需要确保你的部署流程不需要修改这些核心配置，或者在部署阶段临时解锁，完成后重新上锁。
• 用基础设施即代码固化配置：把FUNCTIONS_EXTENSION_VERSION和FUNCTIONS_WORKER_RUNTIME的正确值写入ARM模板或Bicep文件，每次部署时强制应用这些配置。同时在部署管道中添加校验步骤，提前检查这两个设置的值是否符合预期，若发现被篡改则自动修正。
• 限制RBAC权限：在Azure RBAC中，收紧能修改Function App应用设置的权限。只给必要的用户或服务主体分配「网站参与者」或更低权限的角色，移除不必要的高权限角色（比如「贡献者」）。同时监控角色分配的变更，防止未授权的权限添加。

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