Azure App Services健康检查安全问题与使用方案咨询

先明确一点：暴露健康检查路径不是什么不安全的设计，反而是分层架构下的必然选择，合理性主要来自三点：

• 健康检查属于基础设施层的基础探针能力，本来就不该和业务鉴权体系耦合。你给所有业务端点加OAuth校验的逻辑是面向公网业务用户的，但云平台、负载均衡的健康检查流量来自云服务商内部管控平面，本身不属于业务用户范畴；而且OAuth校验链路依赖鉴权服务、缓存、数据库等一堆下游组件，只要下游组件故障，哪怕你的应用本身进程正常、能处理核心请求，健康检查也会误判异常，触发平台误重启、误摘流量，反而放大故障。
• 合规实现的健康检查端点攻击面极小。标准的健康检查端点不接收任何用户可控参数、不执行复杂业务逻辑、不返回任何业务敏感数据/系统内部信息，通常只返回200/503状态码加几个字节的固定响应体，本身不存在SQL注入、信息泄露这类常规漏洞，所谓被利用发起DoS的风险，本质是访问控制没做到位，不是路径本身不该存在。
• 无业务鉴权的标准化健康检查路径是全行业通用的成熟实践，从K8s存活/就绪探针，到各主流云厂商的负载均衡、托管服务健康检查机制，都是基于这套逻辑设计，十几年的生产验证已经证明：只要做好访问控制，这类路径的安全风险完全可控。

别搞给健康检查加OAuth这种画蛇添足的操作，按下面四层做防护就够，都是生产验证过的方案：

• 第一层：平台层做路径级IP访问限制，从入口堵死公网访问。在App Service网络配置的访问规则里，单独给健康检查路径配置规则，仅允许AzureAppServiceManagement服务标签对应的Azure内部管控流量访问，公网所有来源的请求在平台边缘就直接返回403，根本到不了你的应用代码，这步是核心，做完公网攻击者连你健康检查路径存不存在都探测不到。
• 第二层：健康检查端点做最小化逻辑实现。代码层面不要在健康检查接口里加任何多余逻辑：不要做复杂计算、不要查询业务表、不要返回系统版本、IP、堆栈这类内部信息，最多加个核心数据库连接池的连通性判断，响应体尽量短，把这个接口的资源消耗压到最低，就算有极个别漏网的请求打过来，也根本打不出DoS效果。如果想加一层混淆，也可以把健康检查路径改成带随机字符串的自定义路径（比如/api/health/8a7d6fxxx），属于低成本的锦上添花操作。
• 第三层：应用层加轻量校验，不依赖外部服务。不要接OAuth校验逻辑，可选两个轻量校验方式：一是校验请求头里的Azure健康检查专属标识，二是在App Service配置健康检查时，加一个自定义的静态校验头（比如X-Health-Token: 你自己生成的32位以上随机字符串），应用里只校验这个头的值是否匹配，不匹配直接返回403——这个校验逻辑完全在本地内存完成，不依赖任何外部服务，不会出现误判。
• 第四层：前置防护兜底。如果你的App Service前面挂了WAF、Azure Front Door或者应用网关，直接加一条针对健康检查路径的频率限制规则，除了平台固定的探测频率（通常10-60秒1次），其他高频请求直接拦截，就算前面的配置出问题也有兜底。

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