公网暴露的Python运行时HTTP触发Azure Function如何防恶意触发？

很多人会觉得“反正客户端证书校验不通过的请求根本执行业务逻辑，没有资源消耗”，这个认知是有偏差的：

• 就算请求最终因证书校验失败被拦截，Azure的平台网关已经完成了TLS握手、请求路由匹配、流量转发的固定流程，这部分环节已经会占用平台资源，对应产生的流量计费、请求计数都会被记录。
• 当攻击流量的规模足够大时，完全可能触发Function平台层面的全局限流规则，导致正常合法的客户端请求被连带拦截，甚至在极端情况下，大量无效请求会触发平台自动扩容逻辑，产生无意义的实例运行成本。

所有方案都是基于“端点必须公网暴露、不能改成内网调用”的前提设计，完全可以直接落地：

第一层级：把拦截节点前置到离攻击者最近的边缘侧 #

这是性价比最高的防护手段，能把90%以上的无效攻击流量挡在Function服务链路之外：

• 不要直接把Function的默认公网端点暴露给外部调用，换成自定义的独立域名，在域名前面接入Azure提供的边缘应用交付层：
  • 在边缘节点提前完成客户端证书校验，校验不通过的请求直接在边缘丢弃，根本不会把流量转发到后端的Function实例，连Function的服务主机都不会感知到这些无效请求的存在，自然不会产生触发消耗、也不会计入后端的请求计费。
  • 开启边缘WAF的内置速率限制规则，根据正常业务的请求基线设置阈值，比如单IP1分钟请求超过120次就临时拦截10分钟，从根源上挡住高频的暴力探测、DDoS类的攻击流量。
• 把Function的触发路径从默认的/api/HttpTrigger这类固定值，改成随机长度的自定义路径，比如/process/[随机16位字符串]，可以大幅降低全网扫描器盲扫命中端点的概率。

第二层级：优化Function自身的配置，降低漏网请求的消耗 #

就算有少量流量穿到Function层，也要把无效请求的资源消耗压到最低：

• 确认你现在开启的平台级客户端证书校验，是在请求进入Python运行时之前的管道环节完成拦截，不要把证书校验逻辑写在函数业务代码里。两者的资源差异非常明显：平台级拦截的请求根本不会拉起Python运行时、不会加载函数依赖包，省掉了每一次无效请求的固定运行时开销；如果是代码内校验，那请求进来已经完成了运行时初始化，就算马上返回401，这部分的计算消耗已经产生了。
• 调整Function的实例伸缩配置：设置单实例的最大并发请求数、单区域的最大实例数上限，避免为了应付攻击流量无限制扩容，导致成本被恶意打穿。
• 开启Function平台自带的单IP访问限流规则，对请求频率超过正常业务基线的IP，直接返回429状态码，终止后续处理流程。

第三层级：减少端点被攻击者发现的概率 #

• 不要在公开的网页、开源代码仓库、公开文档里直接写Function的完整访问域名和路径，从源头减少端点被自动化爬虫、扫描器收集到的概率。
• 不要长期使用Function默认的*.azurewebsites.net域名对外提供服务，这类默认域名是全网扫描器的重点枚举目标，换成自定义专属域名后，盲扫的命中率会下降一个数量级。

补充一个常见的认知偏差：很多人觉得“开了客户端证书就等于绝对安全，被打也不会有损失”，实际上Azure Function的计费口径里，只要请求到达了平台的前置处理管道，不管最后返回的是200、401还是429，产生的出网流量、请求计数都是要计入费用的。当攻击流量达到每秒几十上百个请求的规模时，这部分无意义的成本和连带影响正常业务的风险是真实存在的，完全不属于过度顾虑。

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