网站运维者必知的5大云安全防护盲区
|
跟产品吵。去年五月，灰度开关没推完，前端在凌晨三点发了个钉钉问“CDN缓存策略是不是又改了”，我回了个“没动”，两分钟后他撤回消息——撤回得比我们SLA还快。监控大屏上右下角那条“/metrics/jvm/gc-pause”曲线，抖了一下，就一下，像被静电打中，没人截图，也没人提。我原以为是grafana刷新抖动，结果查日志发现是AWS Lambda冷启动触发了WAF里一个没开的日志采样开关，连带把S3 access log的加密密钥轮转日志也冲进ELK乱序索引里。这事儿我说不准，但那个密钥轮转ID后缀是“-20230514-legacy”，而我们上一次密钥轮转文档签批日期是二〇二二年十一月十七日——这个我敢打包票。
文章配图，仅供参考 第一个盲区：WAF后面还藏着个WAF。不是指多层代理，是CDN厂商自己悄悄加的“增强防护模块”，默认勾选，关不掉，只给个“联系客服关闭”的按钮，点进去跳转到一个连SSL证书都过期的页面。去年五月出事那天，我们排查504超时，追到边缘节点返回499，再往下追——结果发现Cloudflare WAF拦截了请求，但响应头里写的却是“cf-ray: xxxxx@sin”，而真正拦截它的，是阿里云ALB后面那个叫“智能云盾（非标准版）”的模块，它把同一个请求拦截了两次，第二次拦截居然还走了一遍签名验签，导致下游服务拿到的是带双层X-Forwarded-For、三段Host头、且User-Agent被base64 encode再decode失败后变成“MzYtYjE=”的破玩意儿。PM当时拿着Fiddler截图问我：“这UA怎么看着像Base64解错一半？”我还没说话，测试把一杯水放我桌上，说“你嘴唇起皮了”。她没喝，就放那儿，杯子上印着公司logo，少了一块蓝漆，像被砂纸磨过。第二个盲区：云数据库的审计日志，不等于行为日志。DBA上周才刚吼完：“你们查不到我删表？audit_log=ON，binary_log=ON，慢日志全开！”——可他忘了一件事：RDS Proxy的连接池复用里，所有PREPARE语句都被proxy重写成COM_QUERY，timestamp字段统一塞成连接建立时间；而MySQL Audit Plugin记录的event_time，取的是语句进parser那一刻，不是execute那一刻。我们上个月上线新风控规则，要查某条异常登录关联的所有SELECT，结果在日志里捞出来的时间戳全挤在同一个毫秒，排序全是乱的。我翻了三天代码，才发现我们风控引擎发的是prepare+execute，而DBA查日志用的工具默认按event_time分页，分着分着就把真正执行的那批语句全筛没了。他去倒了杯水，杯子没拿稳，水洒在键盘托上，滴滴答答响了四十二秒。 第三个盲区：HTTPS卸载位置决定攻击面厚度。有些客户坚持在ALB上做SSL卸载，理由是“后端服务不用配证书，运维简单”。可他们不知道，当ALB把ClientHello里的ALPN协议列表原样透传给后端，而我们的gRPC服务恰好启用了h2+http/1.1双栈，攻击者就能伪造一个恶意ALPN扩展，触发ALB的TLS解析器和后端HTTP/2解帧器之间的时间差——去年五月，就是靠这个差，在ALB日志里看不到任何异常（毕竟握手成功），但在后端服务的access log里能看到一批“0.000s”耗时的200响应，其中半数Content-Length是-1。这事我没跟DBA吵，但跟测试吵了半小时——她说“抓包里确实有RST，但Wireshark显示TCP层面没问题”，我说“那你把tshark过滤条件里的tcp.flags.reset==0删了再试试”。她试了，然后把笔记本合上，说：“工资真不高，但活儿真不少。” 第四个盲区：对象存储的ACL和Bucket Policy不是并集，是博弈。S3兼容接口里，minio、腾讯COS、七牛Kodo……每个厂对x-amz-acl和policy里Effect: Allow的覆盖逻辑都不一样。去年五月有个紧急需求，要临时共享一份脱敏报表给合作方，运维在控制台勾了个“公共读”，结果五分钟后告警狂震——因为Policy里有一条“Resource: arn:aws:s3:::xxx/”没加条件限制，而ACL生效后，所有GetObject都绕过了Policy的条件判断。更绝的是，七牛的控制台UI里，“设置为公共读”按钮旁边一行小字写着“仅对当前Object生效”，但我们批量PUT的时候压根没校验header，结果上传时自动加了x-qiniu-grant-read: everyone——而Qiniu Policy的Deny优先级低于ACL的Grant，所以Policy里的deny语句直接被无视。我查源码看到这儿，手抖把咖啡泼在裤子上。咖啡杯上印的logo，少了一块蓝漆，跟前面那杯一模一样。 第五个盲区：云函数的超时配置不是保护伞，是掩体。Lambda也好，FC也罢，设成300秒超时，不等于你能扛住300秒的恶意流控。当函数内发起外部HTTP调用，超时由客户端库、DNS解析、连接池、TLS握手、服务端处理层层叠套；而云厂商只管“函数执行时间”，不管它里面有没有挂个sync.WaitGroup死等。去年五月那次，我们的函数卡在等待一个下游HTTP 200响应，可对方服务实际已返回RST，只是TCP FIN被丢包了，于是函数死等——直到300秒超时抛Exception，触发重试。结果三次重试全撞在同一个丢包链路上，形成雪崩。而告警系统根本没报“函数超时率突增”，因为指标埋点只统计了“InvocationCount”和“Duration”，没采“PendingInvocations”和“Throttles”的关系。oncall手机震了一下，我没接，但屏幕亮着，锁屏壁纸是去年团建照，背景里有个人手里举着烤串，串上插着三颗青椒。 说了五个，其实还有第六个，不想写了。KPI里今年有项叫“安全防护覆盖率”，定义模糊，没说算WAF、还是算IAM policy、还是把Terraform代码里所有allow全部grep出来除以总行数。前两天跟架构组开会，他们提议把云安全扫描从CI阶段挪到prod环境每小时跑一次，理由是“能发现运行时配置漂移”。我没说话，盯着大屏上看一条无关曲线又抖了一下。我原以为是采集脚本出错，结果发现是有人手动改了k8s集群节点上的ntpd服务，把clock sync interval从64秒改成八秒。这事跟我无关，但挺有意思。 现在，去检查你们WAF背后有没有第二个WAF。别信控制台开关状态，ssh进去cat一遍/usr/local/nginx/conf/vhost/.conf。如果没权限——那就先申请权限，别等出事再吵。别的，随缘。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
