服务器安全审计平时看着像是走流程，一旦发生安全事件，有没有审计日志，排查追踪的难度差距巨大。攻击者入侵时间、使用账号、修改的内容、是否横向渗透到其他主机，这些关键线索全部保存在日志中。缺少日志，排查只能依靠猜测。
审计日志覆盖范围比多数人预想的更广。操作系统层面，登录记录、sudo提权操作、账号新增删除、计划任务改动、服务启停，属于基础日志。Web服务器的访问日志、错误日志，可以发现异常请求，大量404报错、异常URL参数、单一IP高频访问这类行为都能捕捉。数据库慢查询日志、审计日志，用来识别拖库或者批量异常查询。网络设备的防火墙日志、交换机端口流量，辅助判断异常外联行为。云服务器额外存在云平台层面操作审计，控制台开关机、修改安全组、重置密码这类操作，云厂商审计服务都会记录，很多人会忽略这一层日志。
日志收集分为两种方式。第一种在每台主机部署agent，像Filebeat、Fluentd、NXLog，读取本地日志文件，发送到集中存储。第二种不部署agent，设备直接通过syslog向外推送日志，网络设备、防火墙、老旧系统用这个方式更简便。两种方案能够组合使用，agent适合系统与应用日志，syslog更适合基础设施设备。集中存储可选方案不少，Elasticsearch搭配Kibana是经典组合，Loki加Grafana资源占用更低，Graylog开箱体验更好。选型结合团队技术栈与日志总量，没有统一标准答案。
审计重点首先关注登录行为。短时间同一IP大量失败登录，基本属于暴力破解。账号成功登录之后的后续操作更值得留意，平时只有只读权限的账号突然执行写入操作，或者服务账号在非工作时段登录。sudo命令执行记录同样重要，记录谁在何时提权执行哪些指令，排查内部误操作、内部威胁时，这条线索价值很高。账号变更不能漏掉，新建账号、修改密码、调整用户组、删除账号，这类操作有可能是攻击者留下后门。
文件完整性属于另一块审计维度。系统核心文件、配置文件、Web站点目录，一旦改动需要及时告警。AIDE、Tripwire、osquery这类工具可以生成文件哈希基线，定期比对，文件发生变更触发告警。配置修改尤为关键，攻击者经常修改配置关闭安全策略，新增流量转发规则。仅依靠日志不一定能捕获全部改动，文件完整性检查作为补充手段。
网络审计容易被忽略。服务器对外发起连接，目标是陌生境外IP或者非常规端口，大概率存在数据外泄风险。内网主机之间横向连接同样要关注，Web服务器突然访问数据库服务器22端口，就需要进一步核查。NetFlow、Zeek、Suricata能够采集网络流量数据，和日志结合分析，还原完整攻击链路。
日志采集完成之后，三个问题需要处理。时间同步，不同机器时区、系统时间不一致，合并检索日志时时序错乱。NTP时间同步是基础，所有服务器、网络设备统一指向同一个时间源。日志留存周期满足合规要求，等保三级要求日志至少保存180天，金融行业要求更长，需要提前规划存储容量。日志本身安全也需要管控，集中存储系统做好访问权限控制，防止攻击者入侵后删除日志。传输过程使用TLS加密，存储开启完整性校验，避免日志被篡改。
告警规则不用一次性配置齐全。优先设置几条核心规则：同一账号短时间多次登录失败、非工作时段管理员账号登录、关键配置文件变更、服务器主动外联高风险区域、日志采集中断。这几条覆盖常见安全事件，误报数量相对可控。规则运行一段时间，结合实际告警情况调整阈值，新增规则。一次性配置几百条规则，很容易造成告警疲劳，真正高危告警被大量无效信息淹没。
审计日志的价值不在于收集总量，而是安全事件发生时，可以快速检索到对应记录。检索速度、日志字段丰富度、关联查询能力，决定审计系统实用性。平时可以做模拟排查演练，假设主机被入侵，测试能否十分钟内依靠日志还原攻击者操作路径。多次演练之后，补齐缺失环节，比单纯对照清单逐项勾选更有实际意义。