信息系统的安全风险有哪些方面

做安全排查最容易卡在两处：一是不知道从哪下手，对着系统看半天说不出风险在哪；二是列了一堆名词，却分不清哪些是自己能改、哪些要拉人。这篇不堆概念，而是把信息系统常见的风险维度摆成一张清单，配上优先级和验证动作，让你扫一遍就能定出本周先修哪几项。

做安全排查最容易卡在两处：一是不知道从哪下手，对着系统看半天说不出风险在哪；二是列了一堆名词，却分不清哪些是自己能改、哪些要拉人。这篇不堆概念，而是把信息系统常见的风险维度摆成一张清单，配上优先级和验证动作，让你扫一遍就能定出本周先修哪几项。

判断标准很简单：你能不能说清这条链路从外到内经过了哪些环节、每个环节谁有权碰。说不清的那一层，就先当成未知风险处理，别用「看着没问题」糊过去。下面按层拆开，再给排查顺序和复查节奏。

先把风险按「层」摆开，别混成一锅

按物理与环境、网络与边界、主机与系统、应用与接口、数据与账号、人与流程这六层归位，一层一层过，比按「严重不严重」排更容易漏项少。每层只问两个问题：这层的入口在哪、谁有权碰它。入口越多、权限越散，风险越集中。

链路

从外部请求一路走到数据落库经过的所有环节，画不出来就说明有盲区

入口

任何能让外部或内部人员发起操作的地方，包括后台、API、跳板机

权限散

同一个人或多个角色都能碰同一资源，且没人能说清为什么需要

排优先级：先修能被打穿的，再修合规缺件

优先看三类：暴露在公网的入口、权限过大的账号、没留痕的操作。这三类同时出现，通常就是最该先动手的地方。合规类缺件（协议、备案、审计记录）排在后面，但别拖：它们平时不出事，出事时是举证材料。

1. 第一步 列出口把对外域名、开放端口、第三方回调挨个列出来，逐个确认是否还需要开着；不需要的直接关，比加固更快
2. 第二步 收账号拉出全部账号清单，标记出管理员、共享账号、离职未回收账号；共享账号优先拆成实名账号
3. 第三步 补留痕确认关键操作是否有日志、日志是否可查；没有的先开最小可用记录，而不是等整改方案
4. 第四步 排合规把监管要求单独列一张表，标出外部检查节点，按节点倒排，不要混进技术加固队列

一张自查表：每项写清「看什么、怎么验、谁负责」

看什么：账号清单、开放端口、对外域名、第三方接入、日志留存开关、备份恢复记录。怎么验：不要只看配置页，实际登录一次、实际发一次请求、实际恢复一次备份，能跑通才算数。谁负责：每项落到一个人名而不是一个部门；没人认领的项直接标红——比漏检更危险的是查到了没人改。

• 排查顺序建议：出口先于入口，先看往外发的调用和回传
• 账号先于配置，配置写错能改，账号放错收不回
• 留痕先于加固，没日志就不知道加固有没有生效
• 每项写清验证动作，比如「用普通账号登录后台，看是否被拦」
• 每项写清责任人，用姓名不用部门，避免互相等

给一家 5 人小团队举例：他们可能没有专职安全岗，就按上面每条只留一个负责人，技术负责人兼三到四项，运营负责人只盯账号和第三方接入，这样一张表就能跑起来。规模更大的团队把这张表按系统拆开即可。

日志与留证：排查的终点是能说明白发生过什么

确认三件事：记了什么、留多久、谁能看。三者缺一，事后都说不清。敏感字段进日志前先处理，别为了排查方便把原始数据攒一堆；处理方式去 /tools/quality-check 和相关脱敏页面核对当时的口径。

• 关键操作留痕设成默认，而不是出事后再开，临时开日志往往已经晚了
• 日志本身也要有访问控制，谁能删日志是比谁能看日志更危险的问题
• 定期做一次「假想事后复盘」：随便挑一条操作，看能不能顺着日志还原出来
• 日志留存时长按业务和监管要求取较长者，别按存储成本取较短者

排查的目标不是把风险清单写满，而是出事后你能拿出一条说得通的链路。

多久复查一次，以及什么情况必须立刻重查

固定节奏复查负责的层，频率按系统对外程度定，对外越多查得越勤；具体的时间间隔不必照搬别人，去 /tools/speed-test 和站内运维相关页面看当时的建议值再定。触发式重查的几种情况：换人、换域名、接第三方、上新品、被通报。

复查时重点看「上次的问题改了没有」，没改的升级处理，不要重新从头扫一遍冲淡重点。想把外部依赖的风险也一起过一遍，可以顺带看看中转站可信度那类站内页面，判断标准同样适用。