Google 边缘：完整解析

这个月，机队的大门搬了家。我们托管的每个应用收到的每个请求，如今都要先经过同一道全球边缘——Google 的边缘——才会触及应用服务器。此前两篇文章提到过其中的片段（我们的 WAF 基线、区域选择）；这篇给出完整图景：一个请求在进门路上要穿过什么。

整支机队共用一扇大门

我们服务的每个域名都解析到 Google 全球负载均衡器上的专用地址：访客连接最近的 Google 接入点，随后一路行驶在 Google 自家的网络上。证书由 Google 签发并轮换，严格传输安全（HSTS）开启，而整个边缘都是声明式配置——经过评审、有版本、可复现，与平台上的一切一样。

最容易挺过去的攻击，是从未抵达你的那一次。

抵达之前，先受检查

每个应用身前立着同一副盔甲。基于频率的封禁守着每个登录——一分钟内五次尝试，这个地址就要暂停十分钟——查询卫兵会在请求触及应用之前丢弃带有明显注入特征的请求。Google 预置的 OWASP 规则集并行评估每个请求；支付 webhook 则被刻意排除在模式匹配之外：它们改用服务商签名来认证——因为分不清真实付款与攻击的规则，是会砸掉你营收的规则。

签名的域名，有门禁的门

地址本身如今也是边界的一部分：我们的十五个域名都放在 Google Cloud DNS 上，每个区域都做了 DNSSEC 签名——解析器可以验证自己对话的是真正的域，而不是冒名顶替者。我们自己的运维界面——机队的面板，乃至通往机器的 SSH——只向经过验证的 Google 身份敞开，绝不向公开互联网上的一个密码敞开。而保持匿名的，恰恰只有我们声明为匿名的东西：健康检查端点与支付 webhook，登记在机队清单里，仅此而已。