网络安全基础实战：威胁建模、身份认证与攻击面收敛

安全这件事我做了不少年见过太多团队在同一个地方摔倒花大价钱买了设备、上了系统、做了等保测评结果一个随手写的拼接 SQL 或者一个没设过期时间的令牌就把整套防线打穿了。网络安全基础这四个字听起来像是入门课的内容但我自己的体会恰恰相反——真正把基础吃透的人极少大多数事故的根因都落在最基础的那几层上资产没盘清、密码学概念混淆、身份认证形同虚设、输入没校验、日志没留存。这篇东西不是教科书式的名词罗列我想按一个从业者的思路把网络安全到底在防什么、每一层的关键原理是什么、实操中哪些地方最容易翻车这条线捋一遍。适合刚入行的同学建立框架也适合写了几年业务代码、但没系统接触过安全的开发者补齐盲区。看完你至少能做到两件事知道自己的系统暴露面在哪以及知道遇到具体问题时该往哪个方向查。1. 先把安全拆开从一句被误读的口号说起1.1 买了设备不等于安全安全是持续的过程我刚入行那会儿最常听到的一句话是我们上了防火墙应该没问题了。这句话的问题不在于防火墙没用而在于它把安全当成了一次性的采购行为。安全本质上是一个持续对抗的过程你今天堵住的口子明天可能因为一次业务迭代重新打开你今天认为无害的内部接口半年后可能因为组织架构调整变成了对外暴露的入口。设备只是把某些攻击的成本抬高它不会让攻击消失。更现实的判断标准是你能不能回答如果现在有人已经进来了我怎么发现、怎么止损、怎么复盘。如果这三个问题一个都答不上来那设备再多也只是心理安慰。我在实际项目里推的第一件事从来不是买工具而是让团队把我们有哪些东西和这些东西出问题会怎样写下来。这个过程很枯燥但它决定了后面所有工作的方向。1.2 CIA 三要素的落地读法别背定义看场景机密性、完整性、可用性这三个词几乎所有教材都会讲但真正用起来的时候很多人只会背不会用。我的读法是把它当成一把尺子用来判断某个具体决策的取舍。比如一个内部的配置中心机密性要求高不高如果里面存了数据库口令那就很高可用性要求高不高如果所有服务启动都依赖它那就极高。这两个判断会直接决定你是给它做双活、还是给它做加密存储、还是两者都要。再看一个反例有人给一个只读的商品详情接口上了严格的加密和签名校验结果每次请求多花 30 毫秒页面首屏明显变慢。这就是没做取舍——这个接口的机密性要求本来就低信息是公开的完整性要求中等别被篡改价格展示就行可用性和性能反而是重点。安全措施要跟着资产等级走而不是一刀切地全上最严的配置。1.3 木桶效应与成本边界钱该花在最短的那块板上安全建设里最浪费钱的做法是把一个已经很结实的环节继续加固而放任最薄弱的环节敞着。我见过一个系统登录做了多因子认证、传输用了高强度套件、密码存储用了慢哈希乍看很专业但它的后台管理接口只靠一个固定的 URL 路径做隐藏任何人拿到路径就能直接调。这种情况下前面所有的加固投入等于零。判断短板的方法很朴素把攻击路径画出来看每一步的成本。攻击者一定走成本最低的那条路。如果撬开一个员工的弱口令比破解加密便宜一万倍那你的加密做得再好也没有意义。安全的投入应该优先填平最容易走通的那条路而不是把已经走不通的路再堵一遍。2. 威胁建模先搞清楚谁会打你、从哪打进来2.1 资产清单连自己有什么都不知道就别谈保护资产清单这件事说起来简单做起来烦。服务器、域名、数据库、对象存储、第三方接口、员工账号、代码仓库、CI 流水线凭证全都算资产。我见过的最典型问题是影子资产某个业务线自己申请了一台云主机做测试用完没关上面还挂着一个默认口令的数据库安全团队的花名册里根本没有这台机器。等到出事的时候日志里出现一个陌生 IP查了半天才发现是自家资产。实操上我建议至少维护三张表一是对外暴露的域名和端口清单二是内部核心数据存放位置清单三是能接触到这些数据的人和账号清单。这三张表不需要多精美一个共享文档就行关键是有人负责更新并且每次上线新服务时必须登记。这个动作看着笨但它能挡掉一大半我们不知道有这个服务的事故。2.2 攻击面盘点从端口、入口一路盘到人的疏忽攻击面可以粗略分成四层。第一层是网络层开放的端口、对外发布的协议、边界设备的策略第二层是应用层登录入口、上传入口、回调入口、管理后台、调试接口第三层是数据层数据库的访问来源、备份文件的存放位置、导出功能第四层是人钓鱼邮件、弱口令、随手把密钥贴到聊天工具里。这四层里最容易被低估的是第四层和调试接口。我处理过的一个案例某服务在生产环境留了一个健康检查接口本来只返回一个状态码后来有人为了排查方便给它加了个参数可以返回最近的错误堆栈再后来又有人加了个参数可以执行一条诊断命令。三个临时方便叠加起来这个接口就变成了一个不需要认证的远程命令入口。每一次为了方便先加上的改动都要问一句这个参数如果被外部知道最坏的结果是什么。2.3 用假设已被入侵的视角倒推防护点正向思考容易漏反向思考往往更有效。假设攻击者已经拿到了一个普通员工的账号他能看到什么假设他已经拿到了一个服务的数据库读权限他能横向到哪假设他已经能在一台机器上执行命令他能摸到哪些凭证这种倒推能暴露很多平时想不到的问题。比如很多系统里普通员工的账号能直接读到全量客户数据因为反正内部人。再比如很多机器上存着部署用的密钥权限是全局的一旦某台机器被拿下等于整个环境的部署权限都丢了。倒推的价值在于它逼你面对防线被突破之后还有没有第二道、第三道这个真问题而不是停留在我的墙很厚的自我安慰上。3. 密码学地基哈希、对称、非对称各管什么3.1 哈希不是加密这个混淆害了很多人我面试过不少人问用户密码你们怎么存回答加密存。再问那密钥放哪就答不上来了。这就是把哈希和加密混为一谈的典型表现。加密是可逆的有密钥就能还原哈希是不可逆的只能验证不能还原。密码存储必须用哈希而且必须是专为密码设计的慢哈希因为它要抵抗离线暴力破解——攻击者拿到数据库之后可以在本地用显卡集群每秒试几亿次。普通哈希比如常见的快速摘要算法用于密码存储是危险的原因是太快了。同样一台机器快速摘要每秒能算上亿次慢哈希设计上会消耗更多内存和计算每秒只能算几千次攻击成本直接抬高几个数量级。实操上选型时关注三个参数算法本身、迭代次数或工作因子、以及盐的处理方式。盐必须是每个用户独立的随机值随哈希一起存它的作用是让相同的密码产生不同的结果防止彩虹表和批量碰撞。存储格式示例算法$参数$盐$哈希值 $argon2id$v19$m65536,t3,p4$c29tZXNhbHQ$RdescudvJCsgt3ubbdWRWJTmaaJObG注意哈希算法和参数会随硬件进步而过时所以要设计成可升级的——用户下次登录时用新参数重新算一遍并更新存储值这样不用强制所有人改密码也能平滑迁移。3.2 对称加密管速度非对称加密管协商对称加密用同一把钥匙加解密速度快适合加密大量数据非对称加密用一对公私钥公钥加密私钥解密或私钥签名公钥验证速度慢几个数量级但解决了钥匙怎么安全地交给对方这个死结。实际系统里几乎不会只用其中一种而是组合使用用非对称加密协商出一个临时的对称密钥然后用这个对称密钥加密真正的业务数据。这也是传输层加密的基本思路。这里有个常被忽略的点非对称加密解决的是密钥分发但它本身不解决对方是谁的问题。你拿到一个公钥怎么确认这个公钥真的属于你想通信的那一方而不是中间人伪造的这就引出了证书体系。理解这条链路比记住具体算法名字重要得多。3.3 数字签名与证书链信任是怎么被签出来的数字签名的逻辑是发送方用自己的私钥对内容的摘要做运算接收方用发送方的公钥验证。因为私钥只有发送方有所以验证通过就说明内容确实来自他并且没被改过。但前提是公钥得可信。证书的作用就是这个——由一个有公信力的机构用自己的私钥给你的公钥签名证明这个公钥确实属于这个域名。验证的时候是一层层往上走的服务器证书 → 中间证书 → 根证书。根证书内置在操作系统或浏览器的信任库里。这条链上任何一环出问题验证都会失败。实操中最常见的三类故障证书链不完整服务器只发了站点证书没发中间证书浏览器可能能自动补但某些客户端补不了、证书过期尤其是自动化续期失败后没人发现、域名不匹配用了通配符证书但层级对不上。3.4 落地时的参数选择与常见误用参数选择上我的建议是别自己发明跟着主流库的默认值走并定期升级。自己拼加密逻辑是事故高发区比如用了加密但没做完整性校验导致密文可被篡改、用了固定的初始化向量导致相同明文产生相同密文泄露模式信息、把密钥硬编码在代码里并提交到仓库。密钥管理这块最朴素的原则是密钥和密文分开存放密钥的访问权限独立控制并且有轮换机制。我见过把密钥写进配置文件、配置文件和代码一起进仓库、仓库权限是全公司可读的情况这种环境下加密基本等于没做。轮换机制也不能省一旦怀疑泄露能快速换掉并且不影响业务这个能力要在平时就演练过。4. 身份与权限绝大多数事故都出在这道门4.1 三种认证因子与多因子的真实落地认证因子分三类你知道的口令、你拥有的设备、令牌、你是什么指纹、人脸。多因子的意思是至少跨两类而不是密码加一个密保问题——那本质还是第一类强度提升有限。实际落地里最常见的是口令加一次性验证码或者口令加设备绑定。落地时的坑主要在体验和兜底上。比如强制定期改密码这条老规矩现在越来越多实践表明它的收益有限、副作用明显用户会在末尾加数字循环使用。更有效的做法是首次登录强制设置足够长度的口令、检测是否出现在已知泄露库中、对异常登录新设备、异地、非常用时段触发二次验证。另外一定要设计好丢失设备的恢复流程否则用户被锁在外面业务方会来施压让你开后门最后往往就真的开了个后门。4.2 会话与令牌管理里的细节陷阱用户登录成功之后服务端怎么记住这个人已经登录了这里有大量细节。基于会话的方式服务端存状态客户端只拿一个随机标识基于令牌的方式状态编码在令牌里服务端验签即可。两种都能用但坑不一样。会话方式的坑在于标识的生成必须用密码学安全的随机源不能用时间戳或者自增 ID 拼一拼会话过期时间要合理且用户主动退出时要服务端失效不能只清客户端。令牌方式的坑在于无法主动失效——令牌签发后在过期前一直有效所以过期时间要短配合刷新令牌使用另外签名密钥一旦泄露等于所有人都能伪造身份所以密钥要严格管理。提示令牌里不要放敏感信息。令牌通常是 Base64 编码而不是加密的任何人拿到都能解开看内容。把用户角色、手机号、内部 ID 塞进去等于把内部结构公开了。4.3 最小权限与越权两类最隐蔽的漏洞越权分两种。一种是水平越权A 用户能操作 B 用户的数据一种是垂直越权普通用户能调用管理员接口。这两类漏洞的隐蔽性在于功能看起来是正常的——接口能返回数据页面能正常展示只是返回了不该返回的那份。防御的核心只有一条服务端每个涉及资源的操作都必须校验当前登录者是否有权操作这个具体资源而不能只校验是否登录。这条说起来简单但在实际代码里经常被漏掉因为前端已经按用户过滤了列表后端就默认传上来的 ID 一定是自己的。这种信任前端的假设是所有越权漏洞的温床。漏洞类型典型表现校验要点水平越权改 URL 里的 ID 就能看别人的订单校验资源归属不信任入参 ID垂直越权普通账号直接调管理接口成功每个接口独立鉴权不靠前端隐藏菜单批量泄露列表接口返回了超出需要的字段输出白名单按需返回5. 应用层的典型攻击面与防御思路5.1 注入类问题根子在把数据当成了代码注入的本质是拼接。用户输入本来是数据但被拼进了命令字符串里数据库或者操作系统就把它当成了指令的一部分执行。SQL 注入、命令注入、模板注入本质是同一类问题只是宿主不同。理解了这一点防御思路就很统一想尽一切办法让数据和代码分离。SQL 这块标准做法是参数化查询把语句结构和参数值分开传递由驱动负责转义和类型绑定而不是自己拼字符串。命令执行这块能不用拼接就不用必须用时用参数数组形式传参而不是整串命令并且对输入做严格的白名单校验只允许字母数字、长度限制。模板这块用户可控的内容不要当成模板去渲染只当普通文本输出。# 错误字符串拼接输入直接进语句 cursor.execute(select * from orders where id order_id) # 正确参数化由驱动处理类型与转义 cursor.execute(select * from orders where id %s, (order_id,)) # 命令执行用参数数组避免整串拼接 subprocess.run([convert, src_path, -resize, 200x200, dst_path], checkTrue)5.2 跨站脚本输出编码比输入过滤更可靠跨站脚本的成因是用户可控内容被当成 HTML 或脚本执行了。很多人的第一反应是我在输入的时候过滤掉尖括号和关键词这条路走不通因为过滤规则永远追不上构造方式而且过度过滤会破坏正常业务比如用户就想输入一个数学表达式。正确的思路是在输出的时候按上下文编码输出到 HTML 正文做实体编码输出到属性做属性编码输出到 JS 字符串做 JS 编码输出到 URL 做 URL 编码。同一份数据在不同位置需要不同的处理方式这是关键。在此之上再叠一层内容安全策略限制页面能加载和执行哪些来源的脚本即使有人注入成功执行也会被拦住。Content-Security-Policy: default-src self; script-src self; object-src none; base-uri self这条策略的含义是默认只允许同源资源脚本只允许同源禁止插件类内容禁止改写 base 标签。上线前一定要先观察再收紧直接上最严策略很容易把业务打挂正确的做法是先跑报告模式收集违规再逐步切换到拦截模式。5.3 跨站请求伪造与同源策略的关系跨站请求伪造的前提是浏览器会自动带上凭证比如 Cookie攻击者只需要诱导用户访问一个页面页面里自动发一个请求到目标站点浏览器就会带着用户的登录态把请求发出去服务端看起来像是一次正常操作。防御的关键是让请求无法被第三方页面构造出来。常见做法有三种校验来源头看请求是从哪个站点发起的、使用同步令牌服务端下发一个随机值请求时必须带上第三方页面拿不到、以及把会话 Cookie 设置为不允许跨站携带。三者可以叠加使用成本都不高。这里要特别提醒一句同源策略管的是页面能不能读响应不管请求能不能发出去所以光靠同源策略挡不住伪造请求必须做上面那些校验。5.4 文件上传、反序列化与服务端请求伪造文件上传的坑不在于能不能传上去而在于传上去之后能不能被执行、能不能被访问到。防御要做三件事校验真实类型看文件头而不是看扩展名、把文件存到不可执行的目录、对外访问时强制以附件形式下载并设置正确的类型头。另外要限制大小和数量防止磁盘被打满。反序列化的问题在于反序列化过程本身可能触发对象构造和析构逻辑攻击者可以构造出执行链路。防御上最有效的是不反序列化不可信数据如果必须用就限定允许的类型白名单。服务端请求伪造则是指服务端被诱导去请求了内网地址防御的关键是对目标地址做解析后的校验注意要校验解析后的 IP而不是只校验域名否则会被解析绕过并且禁止访问内网网段和本机地址。6. 传输与边界握手过程与暴露面收敛6.1 握手到底在做什么为什么它解决了信任问题握手的过程可以简化成四步客户端说我想连你这是我支持的算法列表服务端回选这个算法这是我的证书客户端验证证书链和域名验证通过后双方协商出一个共享的会话密钥之后所有数据用这个会话密钥加密。关键点在于会话密钥是用非对称方式协商出来的从来没有在网络上明文传输过而且每次连接都是新的这就是所谓的前向安全——即使某天服务器的长期私钥泄露攻击者也无法解密之前录下的历史流量。理解了这个流程你就能明白很多故障的根因。比如证书链不完整会导致部分客户端验证失败算法套件配置不当可能导致握手直接失败证书域名不匹配在浏览器上会有明显提示但在程序调用里可能只是一个莫名其妙的连接错误。6.2 证书校验的常见坑别关掉校验我在代码评审里最怕看到的一行是跳过证书校验。它通常是在开发阶段为了让自签证书能跑通而加的然后就一路带到了生产。关掉校验意味着你完全失去了对对面是谁的判断能力中间人可以毫无阻碍地截获和篡改所有通信内容。正确的做法是把内部签发机构的根证书装到信任库里而不是关校验。开发环境用一个独立的配置开关并且这个开关在生产配置里必须是关闭状态最好由构建流程强制检查。另外要注意某些语言的默认行为是宽松的比如对过期证书不敏感所以显式配置校验策略是必要的。6.3 端口与暴露面能不开的就不开暴露面收敛是最便宜也最有效的防护手段。原则很简单对公网只开必须的端口其它一律拒绝对内部也按需开放不要图省事全放通。实操中经常发现的问题是一台机器上装了数据库、缓存、管理后台全都监听在所有网卡上边界设备的策略又比较宽松结果这些服务全都间接暴露了。建议做法是让服务默认只监听本机或内网网卡确实需要对外时再单独配置定期做一次外部视角的端口扫描从外面看看到底开了什么——这个动作比内部的配置检查更接近真实情况。同时要把管理类入口单独隔离出来比如后台管理只允许从固定的办公网段访问而不是全互联网可访问然后靠一个登录框来挡。7. 日志、监控与应急看不见的攻击等于没防7.1 日志要记什么才有用日志的价值不在于多而在于出事的时候能不能还原出发生了什么。我的经验是至少要覆盖这几类认证事件登录成功失败、来源 IP、账号、时间、权限变更谁给谁加了什么权限、敏感数据访问谁在什么时候查了哪些记录、导出了多少、关键配置变更改了什么、谁改的、异常输入被拦截的注入尝试、越权尝试。这里有个很容易忽略的点日志里不要记录明文密码、完整令牌、完整身份证号这类内容。日志系统往往权限更宽、留存更久反而成了泄露源。对敏感字段要做脱敏只保留能定位问题的部分。7.2 从告警到处置链路要能跑通很多团队的告警是发了但没人看。原因通常是告警太多、噪音太大看的人疲劳了。我的建议是先把告警收敛到少数几条真正需要人介入的规则上比如短时间大量登录失败非工作时段的管理操作从非常用地访问敏感接口数据库导出量异常。宁可少而准也不要多而杂。更重要的是处置流程要事先定好谁来看、看到了怎么判断、判断为真之后第一步做什么通常是隔离而不是立刻删日志、通知谁、多久内要给结论。这些东西写在纸上出事的时候才不会乱。7.3 一次小规模入侵的排查复盘虚构场景假设某天发现一个内部接口在凌晨被大量调用。排查链路我一般这么走先从网关日志里定位调用来源 IP 和账号再看这个账号最近的登录记录是不是从异地登录、是不是失败了很多次才成功然后看这个账号的权限是怎么来的是默认分配的还是某次变更给的接着看这个接口背后的数据被访问了哪些、量有多大最后看这台机器上有没有可疑的进程或者新建的账号。这个链路的价值在于它是有顺序的先确定是谁再确定怎么进来的再确定拿了什么最后确定还在不在。顺序反了很容易陷入细节。我踩过的一个坑是一上来就去翻系统日志找可疑进程翻了两个小时没头绪结果回到网关日志三分钟就看到了异常账号。排查要从最容易拿到证据的地方开始。8. 给刚入门的同学一条可执行的路线8.1 学习顺序先建框架再钻细节我不建议一上来就啃攻击技术那样容易变成只会用工具、不懂原理。更合理的顺序是先把网络基础打牢HTTP 协议、TCP 握手、DNS 解析、同源策略这几块必须真懂然后理解认证与权限的模型接着学密码学的基本概念重点是什么时候该用哪种而不是推导数学再学应用层的常见漏洞类型和成因最后再去看攻击与测试方法。这个顺序的好处是你在学攻击的时候脑子里已经有一个正常应该是什么样的参照能立刻判断出哪里不对。反过来先学攻击往往只是记住了一堆招式换个场景就不会用了。8.2 环境搭建自己搭一遍比看十篇文章管用我强烈建议每个人自己搭一套小环境一台虚拟机装个 Web 服务写一个带登录、带列表、带上传的小应用然后自己试着从各个角度去找问题——改改 URL 里的 ID、在输入框里塞点特殊字符、看看返回头里有什么、看看 Cookie 上有没有安全属性。这个过程不需要任何高级工具浏览器加一个抓包工具就够了。搭环境的意义在于你会亲眼看到我改了一个参数服务端就把别人的数据返回给我了这种场景这种冲击感是看文章得不到的。而且在自己搭的环境里折腾没有任何合规风险可以放开了试。8.3 习惯比技术更重要最后说几个我认为最重要的习惯。第一看到任何用户输入先在脑子里过一遍这个东西会流到哪里去——是进数据库、进命令、进模板、还是进日志流向不同处理方式不同。第二任何临时方便的改动都要留一个明确的回收计划调试接口、宽松的策略、跳过的校验都要记下来并在上线前处理掉。第三默认不信任包括不信任前端传来的参数、不信任内部网络的调用方、不信任第三方返回的数据。这三条听起来很虚但它们能挡掉的真实问题比任何单一技术点都多。我自己复盘过的事故里绝大多数不是因为用了什么高深的攻击手法而是因为某个环节默认信任了不该信任的东西。把这条变成肌肉记忆基础就算过关了。