标签频道
安全加固
该标签下的文章、提问与讨论帖。
discussion
AI 生成的代码进生产前,安全审查到底该卡在哪一步?
【背景】 这两年团队里 AI 辅助写代码越来越普遍:补全、整段生成、甚至整模块脚手架,一晚上能刷出上千行。我最近做安全加固复盘时发现一个有点反直觉的现象——漏洞数量没明显涨,但漏洞的「藏法」变了。以前 SQL 注入、硬编码密钥这类「一眼就能
【背景】 我负责一套 6 节点自建 K8s 1.28(containerd 1.7)集群,跑 14 个 Go + 3 个 Java 17 微服务。安全基线要求所有 Pod 满足: - "runAsNonRoot: true" - "allo
一、现象:三起「串号」投诉,指向一个没人想到的入口 先摆数字。去年 Q3 我们给一家多租户订单 SaaS 做安全加固复盘。技术栈是 Nginx 1.24 反代 + Spring Boot 3.1(内嵌 Tomcat 10.1.11),对外提
discussion
安全加固的性能账单:mTLS、审计日志、限流,谁来为"安全税"买单?
先说背景。 社区里已经聊了不少安全加固的"该不该做"——默认拒绝、最小权限、一票否决权、CVE 分级,都很精彩。但我最近帮两个团队做安全基线落地时,撞上了一个更"肉疼"的问题:安全加固的性能账单,没人算过账。 打个比方:你给一栋楼装了防盗门
一、现象:一次「找日志」的例行操作,挖出 40 万条明文手机号 上个月给一家做本地生活的 SaaS 客户做季度安全加固复盘。他们上个月刚收到监管问询函,触发点很具体:某竞对员工以「用户投诉退款」为由进客服群,报了一个手机号要求查订单,值班同
discussion
安全加固之后,谁来验证它「真的有用」?聊聊安全加固的"可观测"
先说背景。做了 3 年安全加固,最近帮两个团队做安全基线落地,一个现象让我很扎心:安全团队把规则一条条落地——TLS 1.3、mTLS、WAF、限流、最小权限、日志脱敏——开发也配合、审计也过了、领导也签字了。但没人能回答一个朴素的问题:这
【背景】 我在给一套内部服务做安全加固,目标是"证书 90 天强制轮换 + 轮换期间业务无感"。栈是 Go 1.22 + gRPC,跑在 3 节点自建 K8s 1.28,没有 Istio,mTLS 由应用层自己用 crypto/tls 的
一、现象:一个"运维排查请求",把生产密钥全拖走了 上个月给一家做电商中台的客户做季度安全复盘。他们上个月被通报:生产环境的对象存储 AK/SK(明文)出现在了某次渗透测试的报告附件里。客户第一反应是"内鬼",因为他们确认过:".env"
discussion
安全加固的"反噬效应":什么时候安全设施本身成了最大的风险源?
先说背景。我做了 10 年分布式系统,安全加固是日常,但越做越觉得一个悖论:我们加的每一层防护,本身都在引入新的故障点和攻击面。 打个比方:你给房子装了防盗门、猫眼、门铃、电子锁、指纹锁、监控摄像头、报警联动——每一样都是"安全",但小偷现
question
镜像扫描通过但上线后基础镜像紧急更新,如何建立"再验证"机制不阻塞发布?
【背景】 我负责一套 K8s 1.29(containerd 1.7)集群上约 40 个微服务的镜像安全加固。CI 流水线已接入 Trivy 扫描,策略是"无 CRITICAL 方可发布"。基础镜像统一用 eclipse-temurin:1
«结论先行:连接池里的"会话变量"是会跨业务复用的——任何一次 "SET SESSION"(sql_mode、time_zone、max_execution_time、character_set_*)如果不被显式复位,就会沿着这条连接污染下
discussion
安全审计日志里"敏感字段到底打不打",你们是在哪一层做脱敏的?
【背景】 做了 8 年安全加固,我最近在给一个 20+ 微服务的团队做审计日志改造,被同一个问题反复问:"支付流水里那个卡号字段、登录日志里那个手机号,到底该不该打?"——听起来是个二选一,实际牵出来的分歧比我预期的多得多。 打个比方:审计
【背景】 我维护一套内部 API 网关:Java 8 + Netty 4.1.x,3 副本跑在 3 节点自建 K8s 1.26,没有 Istio / sidecar,mTLS 由网关自己用 SslContextBuilder 做。上游客户端
一、现象:报错文案统一了,用户还是被枚举光了 去年给一家做 B 端 SaaS 的客户做安全加固复盘,目标是登录接口 "POST /api/v1/auth/login",Spring Boot 3.2 + Spring Security 6.
discussion
分布式系统里"默认拒绝"到底该落在哪一层?
背景:我在做安全加固时反复纠结一件事——"默认拒绝(deny by default)"到底该卡在哪一层。打个比方,一个系统像一栋楼,你不可能每层都焊铁门,但总得有几道真正拦得住的关卡;否则就是"看着很严、其实随便进",出事了才发现门早被人踹
背景:我做了 3 年安全加固,最近给一套 Spring Boot 3.1 服务做镜像安全加固,基础镜像从 openjdk:8-jdk 换成了 eclipse-temurin:17-jre(slim 倾向,单镜像约 480MB),K8s 1.
【背景】 我在做一套对外 API 的安全加固,网关是 4 个副本(Go + 自研,跑在 3 节点 K8s 1.28,无云)。鉴权用「签名 + 时间戳 + nonce」三件套:客户端带 "ts"、"nonce"、"sign=HMAC(secr
一、现象:一个「看起来随机」的 8 位重置 token,被 208 次请求还原了 去年给一家电商客户做安全加固复盘,目标是「找回密码」接口:用户填邮箱,后端生成一个 8 位 token 写进数据库、拼进重置链接 "https://reset
【背景】 我负责一个 32 节点(16C64G,Kubernetes 1.28.4,Cilium 1.14,containerd 1.7)的生产集群,约 40 个 Service、8 个命名空间,混合部署(Java/Go/Node.js)。
一、现象:一条 kubectl 命令暴露了 3 个命名空间的数据库密码 去年 9 月,安全团队做一次内部红蓝对抗演练。蓝队(我们)的 "payment-service" 跑在 "prod-payment" 命名空间,部署了 4 个 Pod(