2026企业密码管理最佳实践

前言

本人现在在一家大型制造业公司从事风险管理、安全架构工作。弱密码相关的治理在今年是我重点解决的一个课题，在过去一年取得了一定的成效。鉴于网上很少有文章从企业实践角度介绍密码管理，本人希望能分享自己在密码管理中领悟的一些经验。

密码管理的典型问题

用户是企业信息安全中最难控制的一环，而用户接触信息安全最高频的场景就是设置密码。随着部分企业疏于密码管理，用户为了提高输入效率、方便记忆，往往设置弱密码、将密码保存在文件中；如果文件不当外发（也有可能是用户手动在外部保存），则进一步导致密码泄露。

考虑到这一点，对于红队来说，获取已泄露的密码、弱密码喷洒等手段，是渗透性价比极高的手段。在网络攻防中，因为密码管理不佳导致的网络边界突破、内网横向移动仍然非常常见。这些是我搜集的一些资讯（也包含一些除密码管理外、身份管理的其他领域内容），说明了当前企业密码管理的典型问题：

现状	证据
1. 密码 / 凭证泄露仍然极其严重	SpyCloud 2026 报告显示，仅 2025 年地下犯罪数据中就重新捕获 53 亿组 username/password 凭证，同比增长 65%；同时发现 1810 万个 API Key / Token。在已泄露企业凭证中，约 80% 包含明文密码。SpyCloud
2. 密码及 Password Pattern 复用严重	SpyCloud 2026 对地下泄露数据分析发现，42% 的企业账号存在密码复用。大量密码还呈现年份、流行词、数字等高度可预测模式，使一个泄露密码或已知企业密码 Pattern 可以扩展到其他账号。SpyCloud
3. MFA 已普及，但覆盖仍明显不足，强 MFA 使用率更低	Okta 2025 数十亿次 Workforce Authentication 遥测显示，MFA 用户覆盖率约 70%，即仍约 30% 用户没有 MFA；真正具备抗钓鱼能力的 FastPass / WebAuthn / Smart Card 等认证方式仅覆盖 14% 用户。Okta
4. SSO / 统一认证已经普及，但全量接入比例仍低	JumpCloud 企业调查显示，虽然约 87% 的组织已经在部分资源中部署 SSO，但真正做到 全组织范围 SSO 的仅约 35%；其余仍存在大量本地账号、独立密码和认证孤岛。JumpCloud
5. Internet-facing 后台 / 管理服务仍大量存在，外部暴露治理困难	Unit 42 对 265 家全球组织的外部攻击面观测发现，平均每家企业每月新增 300+ 个 Internet-exposed service，这些新增资产贡献约 32% 的新增高危/严重暴露；超过 23% 的 Internet-connected exposures 涉及关键 IT/安全基础设施，其中明确包括路由器、防火墙、VPN 等设备的公网管理登录页面。Unit 42
6. 密码策略仍大量停留在“复杂度检查”，缺少真正的弱密码 / Pattern 过滤	Georgia Tech 对 20,000+ 真实网站密码策略实测发现：88% 允许已泄露密码、72% 允许字典词、约 71% 允许序列/重复字符/用户名等明显 Pattern，39% 甚至允许 123456。也就是说，大量系统仍无法阻止攻击者最容易用于 password spraying 的密码。Georgia Tech Faculty
7. 密码、Token、API Key 等硬编码问题非常普遍	GitGuardian 2026 扫描数据显示，32.2% 的企业内部代码仓库至少包含一个 Secret，约为公共仓库 5.6% 的近 6 倍；此外约 28% 的 Secret 泄露事件完全发生在代码仓库之外，如协作工具和生产力平台。GitGuardian

过时的密码策略需要修正

根据NIST SP 800-63B-4 正式版，在不牺牲安全性的前提下，企业的密码策略可以进行适时的调整，以提高可用性：

1、密码作为单因素认证时，最低长度应为15个字符；作为多因素认证的一部分时，可以允许更短的密码，但不得少于8个字符；

2、取消复杂性（大小写、数字、特殊字符）的要求，但是对于易被猜测的组合进行管控（“Password1!”很可能比“I had salmon for dinner today”更容易被猜测）；

3、不再强制要求定期修改密码，仅要求在有泄露风险时进行更换。同时，需要对已泄露密码数据库做强制检查；

4、禁止向未认证访问者提供密码提示。

当然，最安全的密码，是纯随机的长密码。但是对于企业而言，你不能要求所有用户使用这样的密码，过于强势的密码管理措施，使得用户不得不将密码记录在文件中，反而增加了密码泄露的风险。不要试图让密码变得越来越复杂，而是让密码越来越难被猜、越来越难被复用、越来越难单独使用，并最终让越来越少的场景需要密码。

另一方面，身份安全仅仅是信息安全的一个部分。你尽可以以最高的成本解决密码管理问题，但是当解决密码问题的成本超过其他领域的成本时，你还会认为这是划算的吗？作为安全管理人员，应当以性价比（经济成本和时间成本）尽可能高的方式降低企业的信息安全风险。

长期解决思路

建立良好的DevSecOps体系

企业需要建立良好的DevSecOps体系，提供一整套的系统性方案，以解决以上问题。简单的多个措施的组合，并不能彻底解决密码管理问题。

非互联网企业常出现一种情况，IT部门话语权不足，或者是部分信息系统不在IT的管理范围内。根据 ITIL 4 的最佳实践，IT 不再只是支撑业务的角色；今天的 IT 就是业务的一部分。IT 服务的失败，即意味着业务失败。因此任何涉及到信息系统的业务，都应当加入DevSecOps的纳管内容，这一点应当向企业（不只是企业，应当是任何组织）的最高管理者深刻说明。

具体而言，在当前，理想的密码管理相关的措施有以下内容：

• 建立统一的身份认证体系：使用统一的 IdP / UAA / SSO 认证系统，能够直接或间接的方式接入绝大多数的业务系统（直接接入，如直接通过 OIDC、SAML 等协议接入，间接接入，如作为网关实现代理认证），并支持多种认证方式（支持双因素认证，手机短信或客户端验证码、刷工牌、硬件密钥等）。该认证系统也应当使用安全的架构和密码算法，应用 NIST SP 800-63B-4 密码策略。
• 技术上，对于传统账密登录，健全的密码管理应当有以下功能：1、创建用户时生成纯随机一次性密码，使用外部平台交由用户（不应直接展示于注册页面，避免账号冒领）；2、用户第一次登录修改密码，对密码的强度进行校验（计算密码熵值，或使用正则、弱密码库等方案），禁止使用弱密码；3、系统使用哈希算法将密码保存为密码哈希，而非保存密码明文；4、登录凭证应当使用Bearer或更强的算法，不应使用Basic认证方法，避免直接从流量获取密码明文，凭证应当定时刷新；
• 建立良好的系统上线、系统引入流程。自开发的系统，需要经过多道的、多角度的安全审查；外部供应商的系统引入，需要经过安全评估和审查。这些流程就要包括关于身份安全的检查，比如：安全架构评估，确认使用到的业务访问入口、管理员后台入口、中间件管理入口、OT认证等，对所有涉及到鉴权的内容进行身份安全评估；代码审计检查是否有密码、重要token硬编码；安全渗透进行密码喷洒、默认口令渗透等。
• 建立良好的安全运营管理：安全运营人员应尽关心、尽职审查，从各种角度（网络流量审查、扫描器、渗透等）发现身份安全风险，经由仔细的风险评估后进行整改、系统性优化。对于大型公司，有必要组建专门的团队，定期地、全面地收集信息泄露情报（或购买情报服务），并对泄露的来源进行安全处置。
• 安全审查和审计：系统的运营流程应当定期经过审查，日常运营也应受到安全部门的监控和审计。攻击者的行为能够及时被发现，也确保密码重置等流程没有被绕过的风险。

行动措施

以下措施，根据组织的大小、信息安全架构完善程度，优先级也应当经由风险评估后，进行自定义排序。仅代表个人的观点。

立即做

• 搜集情报或购买情报服务，监测组织在公网、暗网的威胁情报，针对已泄露的密码、凭证等风险做立即的阻断；
• 收缩暴露在公网的废弃服务、高危服务。任何后台服务、中间件服务都极不推荐暴露于公网！
• 清理默认账号和默认密码，对于网络设备、中间件、数据库、IoT，排查并修改默认密码。
• 为管理员、邮箱、远程访问及关键系统账号强制启用现有可用的 MFA。

尽快做

• 建立企业统一的、安全的 IdP / UAA / SSO，已有的系统如果不能支持全部系统的接入、不能实现多种鉴权的方式、其他功能不完善导致存在风险等，也应当按照前文DevSecOps所描述的内容进行升级。所有开放至公网的门户、登录口，优先集成企业 IdP / UAA / SSO；
• 建立密码黑名单，阻止特定易被猜测的密码Pattern；
• 加强安全人员对于系统开发、引入和上线的检查，按照前文DevSecOps所描述的内容进行安全加固。
• 建立和完善安全事件响应流程，对于发现密码已泄露、发现攻击者通过密码成功渗透等事件，能够快速响应和处理。

安排做

• 完成DevSecOps全流程的闭环和持续运行；
• 减少密码和长期凭证的存在本身：IdP / UAA / SSO 认证系统使用除密码外的多种因素认证，建立成熟的凭证管理机制（此处不表）；
• 作为安全人员，学习、更新和实践最新的信息安全最佳实践；