金融等保中，访问控制是一道闸门，审计日志是一台摄像头，一个决定谁能进、能碰哪些数据，一个记录进入系统后做了哪些操作，两者缺一个，等保测评就难以真正过关。
金融机构的信息系统里跑着客户资产、交易流水、信贷记录这些敏感数据，访问控制管的是入口，审计日志盯的是过程，二者配合才构成完整的安全闭环，下面从等保2.0的实际要求出发,把这两块内容拆开讲清楚。
金融等保2.0访问控制要求有哪些？先从身份鉴别说起
很多金融机构做整改时，第一件事就是补身份鉴别的课，过去不少系统靠“账号+静态密码”打天下，密码一旦泄露，攻击者就像拿着主人钥匙进了家门，等保2.0对三级系统的身份鉴别提出了明确要求，其中最核心的是远程管理必须采用双因子认证。
身份鉴别不是输个密码就完事
金融行业的身份鉴别有几个硬性动作：
- 双因子认证：密码之外再加一道验证，常见组合是动态口令、U盾、数字证书，银行核心系统的运维人员几乎都配备了动态令牌,这就是为了满足这条要求。
- 首次登录强制改密：厂商交付系统时自带的默认密码是攻击者最爱试的入口，系统验收时若还存在初始密码,测评机构通常会直接扣分。
- 登录失败处理：连续输错密码多次后锁定账号，并设置合理的解锁机制，没有这个机制,暴力破解就能无限尝试。
权限管控要落到“人”而不是“账号”
等保2.0里专门强调了三权分立：系统管理员、安全管理员、审计管理员三个角色要分开，不能一个人既负责运维又负责审计，常见的问题是，柜员、客户经理、运维人员共用一个数据库账号，出了数据泄露事件，日志里只看到账号名,根本定位不到具体的人。
权限分配上执行最小权限原则，一个客户经理只需要看自己名下客户的资料，就不该有权限查询全行客户信息，很多金融等保三级整改方案中，账号治理往往是第一期的重点任务,干的就是这件事。
登录通道和接口调用同样要卡
访问控制不只在应用系统里,网络层面同样要管：
- 运维通道：生产环境必须经过堡垒机登录，不能直连数据库服务器，堡垒机记录在线会话，再加上访问控制的来源IP限制,才能有效约束运维行为。
- API接口：金融场景中大量支付、查询接口对外提供服务，接口鉴权不能只靠一个token走天下，每个接口的调用方、权限范围、调用频率都要有独立控制。
等保测评审计日志保留多久？存储方案怎么选才合规
审计日志在等保里对应的要求是安全审计，它解决的是事后追溯的问题，很多运维人员会在测评前才想起来查日志，结果发现磁盘空间不够、日志被覆盖,或者日志文件格式打不开。
等级保护标准对审计日志的底线要求
按照《网络安全法》第二十一条的规定，网络日志留存时间不少于六个月，等保测评也以此为参照，金融行业实操中，半年是底线，多数机构保留一年以上,部分地区监管要求更严格。
审计日志至少要覆盖以下范围：
- 登录日志：成功登录、失败登录、登录IP、登录时间
- 操作日志：敏感数据的查询、导出、修改行为
- 权限变更日志：账号新增、删除、权限提升操作
- 系统配置变更：防火墙规则调整、数据库参数修改、设备配置变更
- 数据库操作：增删改查语句及影响行数
日志保护的核心不是存储大小，是防篡改
审计日志最怕的不是量太大，而是被人改掉或删掉，行业共识认为，日志如果只存在本地且用同一个管理员账号管理，那它就没有证据效力，等保测评专家检查日志时，重点看两点：完整性和不可抵赖性。
存储层面要做到三个物理隔离：
- 独立存储：日志服务器与生产环境隔离，不能和生产系统共用磁盘
- 时间同步：所有设备接入统一的NTP时间源，保证日志时间戳一致
- 访问隔离：写日志的账号和日常运维账号分开，审计管理员单独持有日志访问权限
金融等保整改中常见的日志配置路径
具体到系统层面，日志审计的配置路径并不复杂,难点在于长期维护。
Linux服务器：修改 /etc/rsyslog.conf，配置远程日志服务器地址，将日志实时转发到集中日志平台，同时配置 logrotate 日志轮转策略，防止单个日志文件过大，关键一条：把重启服务加入开机自启,避免服务器重启后日志转发失效。
Windows服务器：在组策略中开启“审核登录事件”和“审核对象访问”，事件查看器中设置日志大小上限，并启用“达到最大值时存档日志”策略。
数据库：以 MySQL 为例，开启 general_log 或安装 audit_log 插件，同时保留 binlog 用于数据操作追溯，金融核心系统一般会额外部署数据库审计设备，旁路镜像流量,这种方案的优点是审计行为对业务完全透明。
访问控制与审计日志的联动：一道闸门配一台摄像头
访问控制和审计日志不是两张皮，真正能扛住事件的系统,一定是两者联动起来运作的。
举个具体场景：某银行信贷系统做夜间批量更新,运维人员在凌晨两点通过本机终端登录生产数据库执行了删表操作。
- 访问控制层面：凌晨两点不在运维窗口期内，来源IP不在允许列表中，登录请求应该被拦下，如果拦截规则失效,这次登录本身就是违规的。
- 审计日志层面：记录了登录时间、来源IP、执行语句、影响行数，即使影响已经发生，也能精确定位到操作者、操作内容和操作时间,为后续追责提供依据。
访问控制做得松，审计日志再完善也只能记录事故结果，记录不了事故原因，反过来，只有访问控制没有日志，等于有了门禁却没监控，出了事找不到人，两者配合的价值在于：让每次越权操作都能被看见、被追溯。
从整改顺序看，资源有限的情况下优先做访问控制，因为账号管理混乱时，日志系统本身也可能被攻击者利用同一个漏洞清理干净，先把密码策略、账号清理、双因子认证这些基础工作做完，再上集中日志平台,整个链路才会可控。
| 维度 | 访问控制 | 审计日志 |
|---|---|---|
| 回答的问题 | 谁能进系统 | 进来了做了什么 |
| 失效后果 | 系统被非法进入 | 事故无法溯源 |
| 部署优先级 | 高 | 中 |
| 日常维护重点 | 权限变更审批 | 日志完整性校验 |
金融等保中对访问控制与审计日志的常见疑问
等保测评中审计日志保留多久算合格？
按《网络安全法》和等级保护要求，六个月是底线，金融行业出于业务追溯和纠纷处理的考虑，普遍保留一年以上，存储成本高可以通过冷热分离解决，把超过三个月的日志归档到廉价存储,但绝不能删除。
访问控制做严格后审计日志数量反而变少，正常吗？
正常，访问控制拦掉了大量非法尝试，审计日志里可疑登录和越权操作的记录会明显减少，但用户正常操作的记录一条不能少，测评专家更关注的是事件发生后能不能完整还原操作链路,而不是日志数量多少。
金融行业等保三级整改，先上双因子认证还是先上日志审计？
先做账号治理，再上双因子认证，日志审计同步规划，双因子认证解决的是入口问题，但如果账号本身还处于“一个柜员账号多人用”的状态，认证做得再严也定位不到具体的人，账号权限理清了，双因子才有意义,日志也才能落在真实的操作者身上。
访问控制把不合适的人挡在门外，审计日志把进来的人做的事一笔一笔记清楚，金融等保的最终目的不是拿一张测评报告，而是让每一次高风险操作都能被定位到具体的人、具体的时间和具体的行为，这套逻辑对任何规模的金融机构都适用，早一天补上,就早一天安心。