物理隔离网络里的日志留存架构，核心答案就一句话：采用“分域采集、单向传输、集中存储、独立审计”的四层模型，在隔离网内部搭建一套与互联网物理断开、但内部各业务区之间通过安全数据交换节点互联的日志管理平台。这套架构不是简单把服务器日志堆一起，而是要考虑如何在不破坏物理隔离边界的前提下，把分散在交换机、防火墙、服务器、数据库里的日志安全地汇聚到一个可审计的“黑匣子”里。
日志留存架构的底层逻辑：为什么物理隔离网不能照搬互联网方案
很多人在内网改造时，习惯把互联网那套“Agent采集→Kafka→ES→SIEM”的日志链路直接搬进来，结果发现根本跑不通，原因很简单：物理隔离网络有两条硬约束。
第一条硬约束是边界不可穿透。 隔离网与外部网络之间没有路由、没有防火墙策略，甚至网线都是断开的，任何需要“上云”或“外传”的日志方案，哪怕只是心跳同步,都会破坏隔离属性。
第二条硬约束是内部横向流量可信度低。 物理隔离不等于内部绝对安全，近几年大量安全事件恰恰发生在隔离内网，比如通过U盘摆渡、运维人员违规操作、内部人员恶意篡改，所以日志不只是给等保检查看的，更是给事后溯源用的，如果日志本身被攻击者删了,那整个架构就是白搭。
行业共识认为，物理隔离网络的日志留存，本质是在“不联网”的前提下，构建一个内部闭环的审计数据管道，这个管道的每一环都必须有冗余、有校验、有防篡改能力。
物理隔离网络日志留存架构怎么搭：四层模型拆解
接下来直接讲实操，这套架构分四层,每一层都有明确的设备选型和数据流路径。
第一层：采集层日志源的“毛细血管”
采集不是装个Agent那么简单,物理隔离网里常见的日志源包括：
- 网络设备：华为、H3C、锐捷交换机的syslog
- 安全设备：防火墙、IDS/IPS的告警日志
- 主机系统：Windows事件日志、Linux的/var/log/messages
- 数据库：Oracle、MySQL、达梦的审计日志
- 中间件：Nginx、Tomcat、WebLogic访问日志
- 业务应用：关键业务系统自定义的操作日志
采集方式要按设备类型区分：
| 日志类型 | 采集协议 | 推荐做法 |
|---|---|---|
| 网络/安全设备 | syslog | 设备主动发送到日志服务器，避免装Agent影响性能 |
| Windows主机 | WMI或agent | 推荐用只读域账号配合winlogbeat，别用抓包方式 |
| Linux主机 | agent（rsyslog转发） | 在每台机器配置转发规则，统一输出到内部队列 |
| 数据库 | 开启数据库审计功能 | 将审计日志路径映射到宿主机文件，由agent采集 |
| 业务日志 | 日志文件采集 | 使用filebeat实现断点续传，防止丢日志 |
这里有个坑必须提醒：物理隔离网里很多老设备不支持TLS加密的syslog传输，如果日志被中间人截获，可能导致敏感信息泄露，建议在采集层到汇聚层之间，如果条件允许，用kafka的SSL认证做加密，否则至少要在交换机上做ACL,只允许日志源到采集服务器特定端口单向通信。
第二层：汇聚层日志的“交通枢纽”
汇聚层要解决两个问题：高并发写入和格式标准化。
高并发方面，不建议直接让上万台设备往一套ES集群里写，应该先引入Kafka或RabbitMQ做缓冲，采集Agent把日志写到Kafka的topic里，下游消费者按需拉取，这样即使ES集群短暂不可用,日志也不会丢。
格式标准化方面，这是最耗时但最有价值的步骤，各家的日志格式五花八门：华为的syslog里时间戳带年份，Cisco的却只有月日；Windows事件ID和Linux的message完全两套语言，你需要写一套解析规则，把时间戳统一成ISO8601格式，把IP字段、用户名字段、事件类型字段都映射到统一字段名。
具体操作路径：
- 在Kafka中创建“raw_log”“parsed_log”“alert_log”三个topic
- 部署Logstash或Vector，配置grok规则解析原始日志
- 解析后写入parsed_log，同时将安全事件类日志复制到alert_log
- 解析失败的数据存到“dead_letter”目录，定期人工查看
第三层：存储层日志留多久、存哪里
等保三级物理隔离网络日志留存要求，这个搜索词的答案很简单：日志留存时间不少于六个月，关键操作日志建议保存一年以上。 但存储架构不能只按容量规划,要考虑查询性能和防篡改。
我推荐做冷热分层存储：
- 热存储：保存最近7天的日志，用SSD磁盘，挂载在Elasticsearch集群上,用于日常检索和告警追踪。
- 温存储：保存7天到3个月的数据，用普通SATA盘，索引做按月滚动,保留主要检索字段。
- 冷存储：超过3个月的数据，导出为Gzip压缩的JSON文件，存到备份服务器或磁带库,只保留文件名索引。
存储容量估算公式： 单日日志量（GB）= 设备数 × 单台日均日志量（MB） / 1024，一个5000人的中型企业，内网设备约2000台，平均每台每天产生500MB日志，一天就是约1TB，六个月大概需要180TB的原始容量，算上ES副本（至少一份副本），实际存储规划应该在
360TB以上。
注意，物理隔离网里没有云对象存储可用，所以备份和归档都得靠本地磁盘阵列，建议用独立的NAS或SAN，不要跟ES集群共用存储,否则IO互相干扰。
内网日志集中管理平台选型：自研还是买商业产品
物理隔离环境日志审计方案，市面上有几种选择,我直接对比优劣：
| 方案 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| 商业SIEM（如Splunk、QRadar） | 功能全、报告模板多 | 贵，且对物理隔离环境的定制支持差 | 大型央企、金融核心系统 |
| 开源ELK/EFK栈 | 免费、灵活、社区活跃 | 需要较强技术团队维护，桶License限制 | 有一定开发能力的单位 |
| 自研采集+开源检索 | 完全可控、无授权问题 | 开发周期长，时间戳解析容易出错 | 有定制化需求且预算紧张 |
选型时有三个关键点：第一，确认产品是否支持离线部署，很多商业软件需要联网授权，物理隔离环境根本激活不了，第二，看采集器是否轻量，别选那种动辄占用500MB内存的Agent，内网服务器资源普遍紧张，第三，问清楚是否提供国产化适配，信创环境下，你要接麒麟系统、达梦数据库、东方通中间件,没有适配会哭死。
日志防篡改与审计溯源：这是架构的“安全底座”
日志留存不只是存下来，还要保证它没被人改过,物理隔离网里常见的防篡改手段有三种：
哈希链校验
每10分钟生成一个带时间戳的哈希值，下一个哈希值包含上一个的哈希值，形成区块链式结构，任何一条日志被改动，后面的哈希全部对不上，业内专家指出,这种机制在政府内网中已逐步普及。
只读存储介质
用WORM光盘或者不可变磁盘，日志写入后硬件层面禁止覆盖和删除，缺点是一次性写入，无法修改格式,所以通常只用于归档层。
双副本异地存储
在隔离网络的不同区域各放一套日志服务器，定时交叉校验，重点是要让两套服务器的存储路径、访问账号完全不同,防止攻击者同一时间控制两个点。
审计溯源的操作路径：当安全事件发生时，登录日志平台的“审计工作台”，按时间范围、源IP、目标IP、事件类型进行组合查询，查到原始日志后，点击“查看哈希链”，确认日志未被篡改，然后导出带电子签名的证据包，这个证据包在后续汇报和处罚违规人员时,具备法律效力。
运维落地中的常见坑与对策
坑一：日志采集Agent在物理隔离网络里无法自动升级。
很多Agent默认从公网拉取更新包，在隔离网里，建议通过内部的软件分发系统推送升级包，或者直接禁用自动升级,改为固定版本手工验证后更新。
坑二：NTP时间不同步导致日志顺序错乱。 物理隔离网如果没有内部NTP服务器，各设备时间都会漂移，必须在隔离网内搭建一台NTP时间服务器，并让所有设备以它为准,否则审计时按时间排序会看到大量倒序记录。
坑三：忘了给日志平台本身做备份。 日志平台自身也产生日志，比如登录日志、配置变更日志，这些平台日志要单独用一个syslog通道送出去，存到另一个位置,别存放在平台自己那里。
坑四：容量规划赶不上业务增长。 内网业务系统越加越多，日志量每月增长10%都不奇怪，建议每季度做一次日志量趋势分析，当存储使用率达到70%时就要提前扩容。
物理隔离网络日志留多久合适：等保与行业标准
除了等保三级要求六个月，金融行业银保监会要求网络日志至少保存一年以上，部分涉及核心交易系统的需要保存三年，医疗行业根据《网络安全法》和等级保护2.0，建议重要日志保存不少于六个月，涉及患者隐私数据的操作日志建议保存两年以上，具体留多久，还是那句话：六个月是底线，一年是稳妥，关键业务三年不嫌多。
Q&A：物理隔离网络日志留存架构常见疑问
问题1：物理隔离网络里的日志能不能通过单向光闸传出去做分析？
可以，但必须使用单向导入设备（光闸），光闸保证数据只能从内网流向分析区，反向无法通信，这样做的代价是需要在内网侧缓存日志，光闸是文件级传输，吞吐量有限，不适合高频小日志，更稳妥的做法是只把去标识化后的统计数据传出去,原始日志永远留在内网。
问题2：日志平台自身被入侵怎么办？
把日志平台当作核心资产单独防护，一是给日志平台单独划分安全域，严格控制访问来源；二是开启双因素认证，只有审计员和平台管理员能登录；三是将关键操作日志实时同步到另一个只读的备份节点，最坏情况下，攻击者删除了主库日志,备份节点还有副本可以追溯攻击轨迹。
问题3：开源ELK和商业产品在物理隔离环境下选哪个好？
没有绝对答案，如果团队规模在5人以下、业务系统少于50套，开源ELK完全够用，因为日志量不大，ES单节点也能扛住，如果单位需要过等保且业务至关重要，建议买商业产品，报告功能和合规模板能省下大量人工核对时间，选型前务必做一次POC测试，让厂商在隔离环境下跑通采集、存储、查询全流程,再下结论。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/621260.html
