背景：一次突如其来的网络合规检查
上个月，我们公司接到监管部门通知，要对内部网络系统做一次全面的合规性检查。说实话，一开始大家都觉得是走个过场，结果检查组第一天就发现了问题——日志留存不足180天，且访问控制策略存在越权现象。
这事儿让我意识到，很多企业嘴上说着“合规”，实际上连基本要求都没做到位。今天就拿我们这次整改过程做个案例分享，希望能帮到正在踩坑或还没踩坑的同行。
问题一：日志记录不完整
检查人员抽查了三台核心服务器，发现其中一台应用服务器的日志只保留了90天。按照《网络安全法》和等保2.0的要求，日志必须留存不少于180天。我们原本用的是本地存储轮转，磁盘满了就自动覆盖旧日志。
解决办法很简单但容易被忽视：把日志集中采集到SIEM平台，并设置不可删除策略。我们用了ELK（Elasticsearch + Logstash + Kibana）搭建了一套轻量级日志中心。
<input type="file" path="/var/log/app/*.log">
<codec> json </codec>
</input>
<output>
elasticsearch {
hosts => ["es-server:9200"]
index => "app-logs-%{+YYYY.MM.dd}"
document_type => "logs"
}
</output>配置上线后，配合NAS做冷备归档，确保半年内任何时间点都能查到原始记录。
问题二：权限管理混乱
更尴尬的是权限问题。有个开发同事为了调试方便，给自己开了数据库最高权限，而且长期没收回。检查组直接指出这是典型的“过度授权”，属于高风险项。
我们马上推行RBAC模型，重新梳理了所有账号的角色和权限边界。比如普通运维只能看监控面板，DBA操作数据库必须通过堡垒机审计，每次登录都绑定工单系统。
顺便提一句，别小看堡垒机这种“老古董”设备，真出事的时候，它的操作录像就是自证清白的关键证据。
问题三：外部接口未备案
还有一个隐藏较深的问题：我们有个对外提供查询服务的API接口，一直没在网信部门做ICP/IP地址备案。虽然功能正常，但从合规角度看，这就是“黑户”。
补备案流程其实不复杂，但需要准备材料：域名证书、服务器租用合同、法人身份证、安全负责人信息。我们花了三天时间补齐资料，最终完成补录。
这件事提醒我们，业务上线不能只盯着功能跑通，合规动作也得同步跟上。就像开店要办营业执照一样，网络服务也不能无证运营。
整改后的变化
现在再回头看那次检查，反而觉得来得及时。不只是应付监管，整个团队的安全意识明显提升了。比如新项目立项时，第一件事就是拉个合规清单，逐项打勾确认。
技术本身没有对错，关键是怎么用。把合规当成一种习惯，比临时抱佛脚强得多。下次如果还有检查组来，我大概可以笑着请他们喝杯茶了。