我将会从技术角度人性角度安全角度去告诉你我们为什么要做审计以及如何做好一个审计模块当然本篇不是架构篇而是思想篇我相信本篇文章会为你带来更高的视角去俯瞰去感悟。技术角度一个优秀的审计模块需要围绕着 “记录、存储、分析、防篡改” 等四个核心环节展开。1、记录最好采用无侵入性设计比如采用拦截器记录要素 谁Who、在何时When、对什么资源What、做了什么操作How/Action、结果如何Success/Fail以及操作环境IP、设备、位置。这些仅是最简单的5W1H)通常还需要操作前后改动的变化。以及风险评估。数据来自哪里通常是敏感数据的访问、系统配置的变更、高危接口的调用、权限的分配等。2、存储这个通常就要看情况而定了。高频率型比如记录全量日志所有人的所有操作这种情况通常需要结合消息队列MQ进行削峰填谷和做缓冲了。低频率型比如企业内部系统的业务级审计就是只针对管理员、运营、风控、财务等关键角色的 “高风险改动”那么审计模块的设计就应该秉持**“精准抓要害、不做无效记录”**的原则。由于超低频这时通常直接放入数据即可。3、分析这个需结合情况而定看是否需要了。因为你可以结合设计设计具体的规则。举个简单的例子如连续5次登录失败、凌晨进行批量数据导出、异地 IP 权限变更触发实时告警通过邮件、企微、钉钉。4、防篡改这个是相当重要的毕竟审计就是为了排查隐患所以其中一条铁律就是不可更改。复杂方法通常采用哈希链技术。计算第一个哈希块的哈希值并且后续日志计算哈希值时都会依赖前一个简单方法将表设计为只读、只可添加、不可删除和修改最好也能对审计日志做哈希计算在核实的时候可以同步校验数据是否被篡改。人性角度刚接触审计模块时为了懒省事我就常常幻想我只提供一个“接收日志”的接口把所有的包袱都甩给业务方让调用者自己去查旧值、查新值、比对差异再传给我这样我就可以省很多事情。但若真这么设计这个审计模块在企业内部大概率会流产或者沦为摆设。原因很简单人性是趋利的业务开发人员最讨厌麻烦。如果改动一个财务金额他们还要额外写几十上百行代码去查历史、对比字段、组装数据调用自己的接口他们要么会漏掉审计要么会敷衍传入一堆垃圾数据。所以为了让模块真正落地我们的审计模块应该提供“半自动化”的组件而不是一个冷冰冰的 API 接口。我这里拿go语言举例子其他什么语言、框架也都适用去实现微服务架构。就可以这样设计。-------------------------------------------------------------------------|Common 公共基础库(全公司共享的 Go Mod)||||----------------------------------------------------------|||1.audit.Record 记录包|----|2.send 异步发送包(内置生产者)|||----------------------------------------------------------|------------------------------------------------------------------------|(引入依赖)v-------------------------------(异步投递:Kq/Kafka 或 RPC)|业务微服务(如:财务/风控/运营)|-----------------------------------------------------------------|v--------------------------------|3.审计中心微服务(独立)||||------------------------|||audit-mq/audit-rpc|||-----------------------|||(写入)||v||[审计专用数据库]|||(查询)||v||------------------------|||audit-api(展示端)|||------------------------|-------------------------------|v[运营后台/风控看板]你的sdk通常会放到common公用包里面当作一个SDK。packageauditimport(contextencoding/jsonruntime/debugtime://github.com)// Options 审计配置项typeOptionsstruct{Modulestring// 模块名称如财务模块、风控模块Actionstring// 操作动作如修改放款金额、调整黑名单BizIDstring// 业务主键ID如订单号、用户IDFetchOldfunc(ctx context.Context)(interface{},error)// 业务方提供的查旧数据函数}// Record 核心闭包包装器funcRecord(ctx context.Context,opts Options,bizFuncfunc()error)error{// 1. 从 go-zero 的 Context 中捞出当前操作人的信息通过 JWT 传递过来的operator,_:ctx.Value(username).(string)ifoperator{operatorsystem_unknown// 兜底机制}// 2. 在修改前安全地查询旧数据varoldDataStrstring{}ifopts.FetchOld!nil{// 给查询旧数据加上严格的超时限制如 500毫秒防止数据库卡死影响业务oldCtx,cancel:context.WithTimeout(ctx,500*time.Millisecond)// 使用 defer recover 机制防止业务方写的 FetchOld 函数自己发生 panic 导致整机崩溃func(){deferfunc(){ifr:recover();r!nil{logx.WithContext(ctx).Errorf([Audit Panic] FetchOld panic: %v, stack: %s,r,string(debug.Stack()))oldDataStr{_audit_err: fetch old data panic}}}()ifoldData,err:opts.FetchOld(oldCtx);errniloldData!nil{ifbytes,mErr:json.Marshal(oldData);mErrnil{oldDataStrstring(bytes)}}elseiferr!nil{logx.WithContext(ctx).Errorf([Audit Error] 获取旧数据失败: %v,err)oldDataStr{_audit_err: fetch old data database timeout or error}}}()cancel()}// 3. 执行真正的业务逻辑即业务方传进来的修改数据库操作err:bizFunc()iferr!nil{// 关键点如果业务本身报错了如余额不足、数据库主键冲突审计不记录直接返回错误returnerr}// 4. 业务执行成功后再次安全地查询新数据varnewDataStrstring{}ifopts.FetchOld!nil{newCtx,cancel:context.WithTimeout(ctx,500*time.Millisecond)func(){deferfunc(){ifr:recover();r!nil{newDataStr{_audit_err: fetch new data panic}}}()ifnewData,err:opts.FetchOld(newCtx);errnilnewData!nil{ifbytes,mErr:json.Marshal(newData);mErrnil{newDataStrstring(bytes)}}}()cancel()}// 5. 异步发送给审计中心绝对不能阻塞正常的业务响应gofunc(){deferfunc(){recover()}()// 确保异步协程不会挂掉整个进程// 组装最终的审计日志结构体logData:map[string]interface{}{operator:operator,module:opts.Module,action:opts.Action,biz_id:opts.BizID,old_data:oldDataStr,new_data:newDataStr,change_time:time.Now().Format(2006-01-02 15:04:05),}// 调用投递方法可以直接写库也可以通过 go-queue 发送给 KafkasendToAuditCenter(logData)}()returnnil}funcsendToAuditCenter(datamap[string]interface{}){// 这里实现你的上报逻辑// 方式A如果系统小可以直接用 gorm/sqlx 往 audit_log 表里一条 insert// 方式B如果高并发可以用 go-zero 自带的 MQ 组件发送到消息队列}开发者的接入方式func(l*UpdateFinanceLogic)ChangeSalary(req*types.ChangeSalaryReq)error{// 显式调用你的闭包包装器err:audit.Record(l.ctx,audit.Options{Module:财务模块,Action:调整员工薪资,BizID:string(req.EmployeeID),// 业务方只需要告诉你怎么拿这个员工的数据FetchOld:func(ctx context.Context)(interface{},error){returnl.svcCtx.SalaryModel.FindOne(ctx,req.EmployeeID)},},func()error{// 这里是原本他们写的、真正的业务更新代码returnl.svcCtx.SalaryModel.Update(l.ctx,model.Salary{EmployeeID:req.EmployeeID,Amount:req.NewAmount,})})returnerr}安全角度这个其实就是写审计模块的初衷。一、国家层面满足法律与行业监管合规合规很多行业尤其是金融、医疗、政务、SaaS没有审计模块属于违法或无法通过认证。法律要求 国家网络安全等级保护等保明确要求系统必须保留至少 6个月 以上的审计日志。上市公司 需要满足 SOX萨班斯法案等合规审计证明公司的数据没有被内部高管随意操纵。这些都是很正常的。二、公司层面抓出内鬼和故障定位事后追责当系统出现问题或数据被恶意篡改时审计模块是唯一的线索来源。删库跑路 数据库被人恶意清空审计模块能精准定位到是哪个员工账号、在哪个 IP 地址、用什么终端执行了该命令。数据改错 财务系统里的订单金额被修改了审计可以查出是由于哪个操作员手误修改还是系统接口异常导致的变动。三、防范与未然审计模块配合告警系统可以变成主动防御的武器。异地登录 某个平时在上海办公的账号突然凌晨3点在海外 IP 登录。疯狂拖库 某个普通员工的账号突然在 1 分钟内连续下载了 500 次客户敏感数据。审计模块抓取到这些异常后会立刻触发告警甚至直接冻结账号。当然了这个得看具体的需求了不是超大型超正规的一般都不会需要这些。