Google Storage审计日志：如何定位PERMISSION_DENIED请求发起者

从你贴的日志片段可以直接定位问题根源：protoPayload.authenticationInfo是完全空的对象结构。
正常携带合法GCP身份（服务账号、登录用户）发起的请求，这个字段会强制填充请求主体的邮箱、唯一ID信息。日志里抓不到身份，不是审计日志配置漏采字段，而是请求方从一开始就没有提供任何合法认证凭证，属于完全的匿名请求，自然无法在日志里提取到固定的身份标识。

• 第一优先级：提取全量日志里的来源IP。你当前截取的片段没有展示requestMetadata的完整字段，Cloud Logging留存的原始日志中，这个节点下一定会包含callerIp值，这是溯源最核心的硬线索：
  • 如果IP归属公开的互联网扫描器IP段，说明是无差别公网GCS探测，没有特定目标指向
  • 如果IP落在自有网络、关联GCP项目、已知合作方的出口IP范围内，可以直接定位到对应责任方
• 结合用户代理信息缩小范围。你看到的Blob/1 (cr/340918833)不对应正规的商用客户端：Blob/1是Chrome浏览器内部Blob资源的标记头，cr/340918833是Chromium 34.0版本的旧代码提交号，目前使用这个UA的请求基本来自两类场景：
  • 无差别爬虫脚本硬编码的伪装UA，没有实际的程序版本对应关系
  • 网页端前端脚本，在用户访问包含你桶地址的公开页面时，自动发起的跨域探测请求
• 顺着固定触发规律倒查行为。你提到请求每隔1-2天固定触发一次，可以对照这个时间点回溯操作记录：
  • 对应时间点是否有过公网传播该桶名的操作
  • 历史上是否给桶开过临时公共访问权限，被扫描器爬取到桶名后，会按固定周期重试探权限

注意：这类匿名storage.buckets.get请求只要没给桶配置公共访问权限，就不会造成任何数据泄露，本质是公网扫描器的常规探测行为，不需要为了这类请求单独调整桶的安全配置。

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