网络安全的威胁主要来自哪些方面

刚接手安全这块的人最容易卡在一句话上：威胁到底从哪来。网上一搜全是名词堆，看完还是不知道明天该先修哪儿。这篇不列排行榜，只给一套分层框架——外部攻击面、人和账号、供应链与三方服务、内部与配置、数据泄漏后效应——每层配一个能动手的问题清单，再讲清哪些判断不适用于小团队或个人场景。

刚接手安全这块的人最容易卡在一句话上：威胁到底从哪来。网上一搜全是名词堆，看完还是不知道明天该先修哪儿。这篇不列排行榜，也不给「十大威胁」这种容易过期的东西，只给一套分层框架——外部攻击面、人和账号、供应链与三方服务、内部与配置、数据泄漏后效应——每层配一个能动手的问题清单。

框架的用法是：先照着把自家情况往里填，填不出来的那一格通常就是最该先处理的地方。填完再讲排序，以及哪些判断不适用于小团队、个人场景或合规审计场景。

先分清楚「来源」和「后果」

威胁来源指的是谁、从哪个口子进来；后果指的是丢数据、被改内容、服务停摆、被勒索。这两件事混在一张表里，清单就没法用了——你会写出「数据泄露」当来源，然后没人知道该修哪台机器、找哪个负责人。

一个可用的自查顺序是固定的三步：先列资产（有什么），再列入口（谁能碰到），最后才列后果。顺序反了，后面全乱。下面这张对照表可以先帮你把混在一起的说法拆开。

外部攻击面：暴露在公网的东西

这一层要列的是所有能被外部碰到的东西：域名与子域、开放端口、后台登录页、测试环境、对象存储桶、公开的代码仓库。这类入口的特点是数量会随时间自然增长——临时开的测试页、同事随手建的桶，往往没人记得关。

• 域名与子域：有没有已经下线但解析还在的记录
• 开放端口：是不是「先开着方便调试」然后忘了收
• 后台登录页：有没有限速、有没有异常登录告警
• 测试与预发环境：是否和正式环境共用同一套凭据
• 对象存储与代码仓库：是否误设成公开可读

判断标准不是「有没有通过漏洞扫描」，而是「这个入口有没有人负责、有没有日志、出事多久能发现」。扫描通过但没人看的入口，和没扫过差不多。纯内网部署且无远程接入的系统，这一层优先级可以往后放，但运维跳板机要单独算，它本身就是个对外或对内的关键入口。

人和账号：钓鱼、撞库、弱口令

账号类威胁的核心往往不是技术多高，而是复用密码、长期不轮换、离职没回收。撞库之所以有效，就是因为有人在多个地方用同一套账号密码；钓鱼之所以有效，是因为它借的是「看起来正常」这件事，而不是靠漏洞。

1. 给关键后台开二次验证优先覆盖管理后台、云控制台、代码仓库、支付与账单入口；开完拿一个新设备实际登录一次，确认流程走得通。
2. 把管理员账号和日常账号分开日常浏览、收信、看文档用一个号，改配置、发权限用另一个号，减少日常操作误触到高危权限。
3. 离职当天吊销账号、Token、门禁、共享文档权限一起收；收完让接手的人确认一次还能不能用，而不是只看「已操作」。
4. 盯早期信号异地登录提醒、异常时间登录、一次性大量导出，这些比事后追查有用得多。

凭证泄露之后该按什么顺序处置，站内已有文章讲透了，这里只做入口衔接：发现账号异常先别急着改密码了事，先确认这把钥匙还能打开哪些门，再决定动作顺序。相关判断可以到 /guides 找当时的检查清单对照。

供应链与第三方服务

你买的服务、用的组件、接的 API 都在你的信任边界里，它们出事等于你出事。这一层容易被忽略，是因为它不像自己服务器那样「看得见」。一家 5 人小团队可能同时用了十几项第三方服务，却没人说得清每一项拿到了什么数据。

• 这个第三方能看到哪些数据：是只读统计，还是能拿到用户凭证和原始内容
• 它留存多久：合同和数据流向里有没有写清保存期限
• 它被攻破时你怎么知道：有没有约定的通知方式，还是只能靠新闻看到
• 它挂了你的业务会不会一起挂：关键路径上有没有单点依赖
• 合同到期或换供应商时，数据怎么拿回来和删干净

小团队最典型的盲区是同一个 Key 到处填：脚本里、CI 里、同事本地环境变量里各放一份，一旦外泄波及面成倍放大。填之前该确认哪些事项，站内另有专门清单可对照，路径在 /tools，选服务时可以顺手核一下当时的可信度检测结果。

内部与配置：出事最多的其实是「设错了」

权限给多了、默认口令没改、日志没开、备份没测过恢复，这几项在真实事件里占比很高，但很少被当成「威胁」写进报告——因为它们看起来不像攻击，像疏忽。做这一层不需要什么工具，需要的是一份上线前自查表，逐条过，把「默认值」当成待办而不是已完成。

如果这套系统根本不存业务数据，条目可以精简，但账号与日志两项不退让——出问题时你至少要知道是谁动了什么。这套做法不适用于合规审计场景：审计要按制度和证据链走，不能按风险高低挑着做。

泄漏之后：数据会被怎么用

同一份数据外泄，后果差别很大：能直接盗用的（凭证类）最急，能拼出身份的次之，纯业务数据再次之。分级的目的是决定动作先后，而不是安抚情绪。很多人一出事就先写公告，结果该断的凭据还活着。

1. 先切断还在生效的凭据把 Token、密钥、会话、子账号权限挨个作废；作废后用一个旧凭据实际调一次，确认真的失效了。
2. 再评估影响范围这份数据能被哪些人碰到、能拼出什么结论，列出可能受影响的账号或客户名单。
3. 然后才是通知与留证对外说法要基于已核实的事实；不确定的部分写「正在核实」，不要替对方下结论。
4. 留证要趁早截图、账单、会话记录、时间点按统一格式存一份，放到与生产环境隔离的地方。留证方式决定了后续能不能说清，这一点比写多长的说明都重要。

按什么顺序处理，以及哪些结论不适用

排序建议很简单：能直接造成不可逆损失的先处理（凭据、对外可写入口），其次是能横向移动的（内网信任关系、跳板机），最后是纯信息暴露。不可逆的意思是，补回来也换不回已经发生的事，比如被盗用的账号、被发出去的邮件。

• 先修无主入口：没人负责、没日志的对外入口排在最前
• 再收权限：能横向移动的账号和跳板机是第二优先级
• 然后补日志：不是为了查历史，是为了下次能早点发现
• 最后处理纯信息暴露：优先级低不等于不用管，只是可以排在后面
• 合规要求是另一条线：该交的材料照交，别和风险排序混着谈

这套框架有两种明显不适用的情况。一是合规审计场景——审计按制度和证据链走，不能因为你觉得某项风险低就跳过。二是完全离线的实验环境，那里首要问题不是防外部攻击，而是别把测试数据带出去。个人和小团队可以把每层的条目砍到最少，但「谁负责、有没有日志」这两个问题不能省。

一张能落地的自查流程

框架看得再多，不如按固定顺序走一遍。下面五步可以做成一页纸，每次复核照着填，填不出来的格子就是下一次要动手的地方。

1. 列资产与入口把系统、数据、对外入口各写一行，标出谁在用；写不全没关系，先写自己知道的。
2. 标注负责人和日志情况每个入口后面写两栏：谁负责、有没有日志；空着的先圈出来。
3. 挑无主入口优先修先关掉或加固没人认领的入口，这一步通常当天就能做完好几项。
4. 做一次假想泄露演练问自己：如果这份数据今晚被拿走，明天最先做什么；答不上来的环节就是要补的环节。
5. 写成带日期的清单并定期复核做完一次不算结案，过一段时间再对照一遍，看哪些格子又变空了。

想把框架落到具体对象上，可以拿站内的资料库和检测结果做参照：各家官方 API 的价格与模型资料在 /rankings 有整理，中转站可信度检测和价格追踪在 /sites 与 /price-watch，具体数字以页面当时的显示为准，别记死一个数。