安全审计包括哪些内容

刚接手安全这块的人，常被一句「做次审计」卡住：审什么、从哪开始、做到什么程度算完？这篇不讲标准条文，只按一个能落地的顺序，把资产、账号权限、密钥凭据、数据链路、日志与响应这几块拆开讲；每块给你该收集的东西和该问的问题。边界也说清楚：哪些属于审计范围，哪些其实该交给合规或法务，别一个人硬扛。

刚接手安全这块的人，常被一句「做次审计」卡住：审什么、从哪开始、做到什么程度算完？网上搜到的答案要么是标准条文，要么是卖工具的软文，看完还是不知道明天该干什么。

这篇不讲标准条文，只按一个能落地的顺序，把资产、账号权限、密钥凭据、数据链路、日志与响应这几块拆开讲；每块告诉你该收集什么、该问谁、什么情况可以少做。边界也说清楚：哪些属于审计范围，哪些其实该交给合规或法务，别一个人硬扛。

先划范围：安全审计到底审什么

安全审计的对象不是「把工具装一遍」，而是搞清楚三件事：有哪些资产、谁在什么条件下能碰到它们、碰完之后留下什么痕迹。工具只是手段，装完不代表审完。

资产清单

你负责的域名、服务器、数据库、第三方服务账号，写成一张表并指定每项的负责人

访问路径

从外网到数据之间经过几层，每层谁能进、靠什么进

数据分类

哪些是用户数据、哪些是内部资料、哪些丢了也没事，分三档就够用

最小可用范围建议先覆盖四块：对外暴露面、有账单权限的凭据、能碰到用户数据的链路、能改配置的人。这四块之外的东西，第一轮可以先放进「观察名单」，别一上来铺全套，铺不开也守不住。

• 写一页《本次审计范围说明书》，列出审哪些系统、明确不审哪些、谁签字确认
• 不适用情形：纯内部使用、无外网暴露、不碰用户数据的小工具站，可以只做凭据与备份两项就收工
• 范围一旦定下来就别中途扩，扩了要重新确认签字，否则结论没人认

账号、权限与密钥：审计里最容易出问题的一块

这块的核心是按人查，不是按系统查。系统视角看每个系统都挺正常，换成人视角就会发现问题：某人已经换岗半年，但旧系统的管理员权限还在。

1. 拉账号清单从各平台后台导出账号列表，按人合并，标出每个账号的用途和最后登录时间。
2. 比对本职权限拿账号清单去和岗位职责对一遍，超出本职的先记录，不要当场删，确认没人依赖后再处理。
3. 标注高风险凭据能直接产生账单或读写用户数据的凭据单独拉一张表，写清用途、有效期和撤销方式。
4. 确认处置顺序先处理能造成直接损失的，再处理配置不规范的；每处理一项，留一条记录。

密钥泄露后的处置顺序、轮换周期与最小权限的交接做法，站内已有专门文章讲透，这篇不重复展开，只提醒一句：审计发现的问题要能落到「谁在什么时间之前处理完」，否则报告就是摆设。

数据链路与日志：东西到底流到哪去了

链路审计最实用的办法是跟着一次真实请求走一遍：用户输入进去，经过哪些服务，在哪里落盘，谁能读，保留多久。每经过一段，记一行，最后就是一张数据流向图。

• 输入项：用户到底提交了哪些字段，有没有夹带不该收的
• 中间服务：请求经过哪些内部或第三方服务，各自会存一份吗
• 落盘位置：数据存在哪台机器、哪个库、有没有备份到别处
• 读取权限：谁能查这些数据，是走后台还是直接连库
• 保留期限：存多久，到期谁负责清，清没清怎么验证
• 日志内容：日志里有没有把敏感字段原样写进去

日志这块盯两个点就够：有没有不该出现的敏感内容，留存时间是不是和你对外承诺的一致。承诺存三个月，实际存半年，这也是问题。

哪些数据能发、哪些别发，属于数据边界问题，本分区另有专文讲透；这里只判断链路上有没有留下多余的副本，不展开讲合规口径。不适用情形：如果整个环境本地推理、根本不出网，重点就不再是传输加密，而是本地访问控制和存储介质的管理。

出报告：写什么、多久做一次

报告别写成问题罗列。每一条发现都按五栏写：发现、影响、建议、负责人、复查时间。缺最后一栏的，下次审计一定还能看到它。

分级用「能不能直接造成损失」比打分更实用：能直接刷账单、能直接读到用户数据的排第一档；配置不规范但没有实际暴露面的排后面。打分体系容易陷入为了凑分而凑分。

节奏上，小团队半年做一次全量就够，遇到三类事件再做定向复查：关键人员变动、上线新系统或新接口、接入新的第三方服务。报告里涉及价格、套餐口径的数字，到站内 /price-watch 核对当时的数字再写，不要凭记忆。