密码策略守住身份入口

晨会前 20 分钟，运维负责人小李被问了一个很普通的问题：昨晚那次配置变更，到底是谁登录平台改的？

他打开审计记录，看到的是一个长期共用的运维账号。登录来源能查到，操作时间也能查到，但账号背后到底是哪位同事、哪家外包、哪次临时协助，没人敢马上下结论。

更麻烦的是，这个账号的密码已经很久没有换过。几个人都知道，浏览器里也可能保存过。复盘会还没开始，问题就已经从“谁改错了配置”，变成了“这个身份入口到底还能不能信”。

密码策略不是为了让登录页显得更安全，而是为了让账号、口令、会话和审计能连成一条可追溯的治理链。

病根

很多系统做安全整改时，会把密码策略拆成几个孤立配置：密码几位，复杂度几类，多久换一次，输错几次锁定，超时多久退出。

这些配置都重要，但如果只看配置项，容易漏掉更深的问题：身份入口有没有形成闭环。

一个松散的身份入口通常会同时出现几类断点：

• 账号能登录，但不一定能对应到具体责任人
• 密码足够好记，也就足够容易被猜或复用
• 登录失败没有成本，攻击者可以持续试错
• 会话长期有效，人离开了权限还留在现场
• 事后有日志，但日志无法把账号风险和操作行为连起来

等保关注密码策略，真正要压住的就是这些断点。

一、账号唯一

小李最先卡住的不是密码复杂度，而是账号身份。

共享账号在运维现场很常见。公共管理员账号方便多人协作，临时测试账号方便排查问题，外包账号方便短期交付。它们的问题不会每天暴露，但一旦进入审计，就会立刻放大。

谁登录了？谁执行了？谁修改了？

如果日志里只有一个公共账号，后面的权限划分、责任确认和复盘整改都会变得含糊。审计不是没有数据，而是数据无法指向明确的人。

BK Lite 的系统管理以用户、组织、角色和数据权限作为统一治理底座，用户在同域下以用户名唯一。这个能力先解决身份入口的第一层问题：让账号、组织归属和后续权限关系有可维护的对象。

二、口令质量

账号能对应到人以后，第二个问题是口令本身能不能扛住猜测和复用。

弱口令的风险不在于“不专业”，而在于攻击成本太低。公司简称加年份、手机号后几位、常见管理员密码，都可能被字典攻击覆盖。更常见的是撞库：某个外围系统泄露了一组账号密码，攻击者拿它去试核心系统。

复杂度提高猜测成本，有效期缩短泄露后的可用时间。这两件事不能互相替代。

只复杂但长期不换，挡不住已泄露口令继续有效；只定期更换但允许简单密码，又容易变成几个弱口令来回循环。

BK Lite 的密码策略支持复杂度、长度、有效期、失败锁定和提醒周期配置。默认长度范围为 8 到 20，要求包含大写、小写、数字、特殊字符四类，有效期 180 天，到期前 7 天提醒。密码变更后，系统会更新密码变更时间，并重置错误计数与锁定状态。

三、失败锁定

复盘继续往下走，小李还要确认另一个细节：昨晚有没有异常失败登录。

如果登录入口允许无限重试，攻击者不需要马上成功。他可以低频、分散、长期地尝试，把爆破隐藏在日常访问噪声里。失败次数限制和锁定时长的意义，就是把无限试错变成有限窗口。

BK Lite 支持失败重试次数和锁定时长配置。登录失败按次累计，超过阈值后锁定账号，锁定到期或改密后解除。默认策略为失败 3 次锁定，锁定 180 分钟。

这里的锁定不是万能防护。它不能替代泄露后的改密，也不能替代异常登录排查。但它能显著提高持续试错的成本，让攻击者无法把登录入口当成没有代价的猜测接口。

四、会话边界

账号和密码都处理了，还剩一个经常被忽略的问题：登录成功以后怎么办。

运维后台、配置平台、审计入口通常都有较高权限。如果人已经离开，会话还留在浏览器里，旁人接手电脑、远程桌面未断开、浏览器被复用，都可能让一次合法登录变成后续冒用。

登录有效期和超时退出处理的就是这段空白。

BK Lite 的登录设置支持 OTP 开关与登录有效期配置。登录有效期负责收住会话生命周期，OTP 则为高风险入口增加第二个有效凭据。密码可能被猜中、被钓鱼、被复用，OTP 的价值在于降低“拿到密码即可进入”的风险。

五、身份来源

到了组织层面，密码策略还会遇到一个更现实的难题：账号分散。

账号分布在不同系统里，离职停用、组织调整、权限回收都会变慢。每个系统各自维护口令策略，也会让安全要求在执行层面变得不稳定。

BK Lite 支持 BK-Lite 默认认证源和企业微信认证源，支持认证源新增、编辑、删除、启停，以及用户与组织同步。认证源管理不是为了让登录方式变多，而是为了让身份来源、组织归属和后续权限治理能回到统一链路里。

技术洞察

密码策略要真正发挥作用，至少要同时回答四个问题：

• 可识别：账号是否能对应到明确身份，而不是公共账号
• 可限制：弱口令、长期口令和无限重试是否被系统策略收住
• 可增强：高风险入口是否有 OTP 或认证源治理来补单一口令短板
• 可追溯：登录失败、成功登录和后续操作是否能形成审计证据链

这四件事缺一层，身份入口都会留下空档。

BK Lite 的切入点

BK Lite 不是把密码策略做成孤立页面，而是把它放在系统管理的身份治理能力里承接。

在用户与组织层，平台维护用户、组织、角色和数据权限，用户在同域下以用户名唯一，让账号先具备可治理对象。

在安全策略层，平台支持密码复杂度、长度、有效期、失败锁定、提醒周期、OTP 和登录有效期配置，让口令和会话不只依赖人工制度。

在认证源层，平台支持 BK-Lite 默认认证源和企业微信认证源，支持认证源启停与用户组织同步，让身份来源更容易统一维护。

在审计层，平台提供登录日志和操作日志。登录日志记录成功/失败、用户名、来源 IP、操作系统、浏览器、位置和失败原因；操作日志记录跨应用的新增、修改、删除、执行操作，支持按模块、类型、时间范围筛选，并支持导出。

这些能力组合在一起，才能把“小李查不到是谁登录”的问题，从事后争论拉回系统治理。

自查清单

如果要检查一个系统的密码策略是否真正接近等保的治理思路，可以先问这些问题：

检查点	要看的不是
账号是否唯一	只看有没有用户名
密码是否有复杂度	只看是否允许设置密码
密码是否有有效期	只靠制度提醒用户改密
失败是否会锁定	只记录失败但不限制重试
会话是否会退出	只要登录成功就长期有效
是否支持增强鉴别	所有入口都只靠静态密码
是否有认证源管理	每个系统各自维护身份
是否有审计日志	只能查登录，不能关联后续操作

结语

等保盯密码策略，不是因为密码配置最好检查，而是因为身份入口最容易被低成本打穿。

弱口令、共享账号、长期有效密码、无限重试、会话遗留和日志不可追溯，看起来是不同问题，最后都会落到同一个结果：系统知道有人进来过，却说不清这个身份是否可信，也说不清后续动作该如何追责。

把密码策略做好，真正守住的是身份治理的第一道门。