洛谷 B3869：[GESP202309 四级] 进制转换 ← 字符串
2026/10/24 5:12:09
摘要：很多企业的管理员密码不在系统里，而在 Excel、文本文档，甚至一张小纸条上。据 Forrester 估计，80% 的数据泄露事件与特权凭据有关（该数字为机构估算，口径见文中说明）。本文讲清三件事：把密码存在 Excel 里在技术上到底错在哪、堡垒机与 PAM 的能力边界、以及特权账号治理的六步闭环怎么落地。
一句话结论：堡垒机管的是"人进门之后做了什么"，PAM 管的是"钥匙本身放在哪、谁在用、用完有没有换"。前者是行为审计，后者是账号治理——这两件事不能互相替代。
一、为什么把密码存在 Excel 里是"不可治理"的？
企业把管理员密码存在 Excel 里，通常不是不知道风险，而是没有更好的办法——系统太多、账号太杂、每次改密都要挨个通知。
但这件事在技术上有四个硬伤，和"安全意识"无关：
失效点 | 具体表现 | 后果 |
无法轮换 | 一个密码用了三年，改了要通知一圈人 | 一旦泄露，泄露的是"三年内的全部历史" |
无法审计 | 谁在什么时候看了这张表，没有任何记录 | 出了事无法定位，也无法排除内部人员 |
无法回收 | 人走了，密码还在他手机相册里 | 离职账号成了长期后门 |
无单一真相源 | 5 个人各存一份，改了一次只改了自己那份 | 出现"哪个才是对的"的争论，最后靠试 |
一句话：Excel 里的密码不是"弱密码"，是根本没有生命周期。它不会被换、不会被收回、不会被记录。
二、80% 这个数字到底能不能用？
"80% 的数据泄露和特权凭据有关"这句话流传很广，需要说清楚三件事，否则容易被当成营销话术。
第一，这是个估算值，不是统计普查。这个数字的常见出处是 Forrester 的研究估计，属于"研究机构基于样本与建模的估算"，不是对全球所有泄露事件的逐起核对。
第二，它的表述是"与特权凭据有关"，不是"由特权凭据直接导致"。一起泄露事件里，攻击者可能先用钓鱼拿到普通账号，再通过提权、凭据窃取拿到特权账号。这时事件"涉及"特权凭据，但入口不是它。
第三，不同机构的同类研究口径不同，给出的比例也不完全一致。所以正确的用法是：
把它当作排序依据（身份与凭据是高价值目标，应该优先投入），而不是当作精确比例（不要说"80% 的泄露都是因为密码没管好"）。
这个区分很重要。技术社区对数据的容忍度取决于你有没有说清口径——标了口径的估算值可以被引用，没标口径的精确数字会被当成编造。
三、堡垒机能替代 PAM 吗？
传统堡垒机的价值很实在：统一入口、全程录屏、命令审计。合规检查里它是标配。
但它解决的是另一个问题。
维度 | 传统堡垒机 | PAM（特权账号管理） |
核心对象 | 人的行为 | 账号与凭据本身 |
解决的问题 | 谁在什么时间做了什么操作 | 这个账号在谁手里、密码是什么、多久没换 |
密码形态 | 运维人员知道密码，或通过堡垒机代填 | 密码托管在平台，人不需要知道 |
轮换能力 | 一般不负责，靠人工或脚本 | 自动轮换，改完自动生效 |
账号台账 | 通常只有"能登录的账号" | 覆盖资产、账号、证书的完整台账 |
典型盲区 | 账号被复制到本地、离职未回收、多人共用 | —— |
合规定位 | 运维审计（等保的操作审计要求） | 账号治理（凭据管理、最小权限、可追溯） |
关键差别在"密码在谁手里"。
堡垒机的模型是：你知道密码，通过堡垒机登录，堡垒机记录你做了什么。 PAM 的模型是：你不需要知道密码，平台替你连，平台记录你做了什么，而且密码每隔一段时间自己换。
联软科技渠道运营负责人梁光耀在 10 月 20 日的 UniPAM 线上渠道推介会上把这个差别说得很直白：
"传统的堡垒机审计已无法满足当前需求，市场正升级为对高效运维与特权账号体系治理的双重诉求。"
注意这句话的边界：它说的不是"堡垒机没用了"，而是"只做审计不够了"。这两个判断差别很大——前者是替代，后者是补位。
四、PAM 是什么？六步闭环怎么走
如果只记一句话：PAM 是把"密码"从人的记忆和文档里，搬到一套有生命周期管理的系统里。
联软的 UniPAM 方案把这个过程拆成六步：
步骤 | 做什么 | 判断做没做到的标准 |
1 发现 | 扫描资产、账号、证书，摸清有多少个特权账号 | 能不能列出"长期未使用""未授权""共享使用"的账号清单 |
2 托管 | 把凭据收进平台的密码保险箱，加密存储 | 平台之外是否还存在明文密码（含脚本、配置文件） |
3 授权 | 按最小权限分配，走工单审批 | 临时授权是否有到期时间，到期是否自动失效 |
4 访问 | 通过统一入口连接，不落地本地工具 | 运维人员是否需要知道密码；是否需要装客户端 |
5 自动化 | 定期自动改密、证书到期提醒 | 改密是否影响业务；失败是否有回滚 |
6 审计 | 会话录像、命令记录、操作留痕 | 事后能否按人、按资产、按时间检索回放 |
这六步里最容易做残的是第 5 步。前四步是"管起来"，第五步才是"管下去"——没有自动轮换，半年后密码又会回到"三年没换"的状态。
五、自动改密为什么不会中断业务？
这是 PAM 落地时被问得最多的问题，也是很多项目卡住的地方。技术上它靠的是"身份网关"这个中间层。
原理：部署 PAM 后，业务服务器不再直接持有数据库密码，而是通过 PAM 的身份网关访问数据库。密码统一托管在 PAM 里。
改密时发生的是这样一串动作：
- PAM 生成新密码，先拿它去实际连接一次数据库，校验新密码可用；
- 校验通过，才在平台内切换为新密码；
- 业务服务器下次连接时，走的是 PAM 网关，由 PAM 用新密码完成认证——业务侧不需要改任何配置；
- 如果校验失败，保留原密码，不切换。
这解决了两个长期痛点：
- 业务系统不用跟着改配置文件（这是过去自动改密最大的阻力）；
- 改密失败不会把业务打死（有回滚）。
一个必要的提醒：这条链路成立的前提是"业务确实走了 PAM 网关"。如果有应用是硬编码直连数据库、绕过网关的，那它仍然会受影响。所以实施第一步不是部署，是摸清有哪些连接绕过了网关。
六、先治理哪几类特权账号？
PAM 上线后最常见的困境是"账号太多，不知道从哪开始"。建议按风险排序，先清这五类：
账号类型 | 特征 | 识别方法 | 处置建议 |
僵尸账号 | 长期未登录，但仍然有效 | 查最近 90/180 天无登录记录的特权账号 | 先禁用观察，确认无业务依赖后删除 |
共享账号 | 多人共用一个管理员账号 | 同一账号多地区、多时段、多终端登录 | 拆分为个人账号 + 按需授权 |
未授权账号 | 不在台账里，但确实存在 | 资产扫描结果与账号台账做差集 | 逐个确认归属，无主的直接清理 |
离职遗留 | 人员已离职，账号仍在 | HR 名单与账号清单比对 | 建立离职联动流程，不靠人工 |
硬编码凭据 | 密码写在脚本、配置文件、代码里 | 代码仓库与配置文件扫描 | 改为调用凭据接口，不落地明文 |
这张表的用法：不要等 PAM 部署完再清理。发现和托管是并行的——先扫出清单，边清边托管，否则项目会陷在"账号还没理清"的前置条件里。
七、部署时有哪些实际约束？
选型时容易被忽略的是"用起来顺不顺手"，因为不顺手的工具最后会被绕过。
维度 | 需要确认的点 |
客户端 | 是否需要安装本地客户端？纯 Web 运维能覆盖多少场景 |
协议支持 | SSH、Telnet、RDP、VNC、Web 是否都支持；数据库侧 MySQL、Oracle、Redis 等是否覆盖 |
跳板机 | 是否需要额外部署独立跳板机（多一层转发 = 多一个故障点、多一份成本） |
敏感数据 | Web 运维界面能否做字段脱敏（手机号、身份证等），让运维"看得到数据、看不到完整值" |
临时人员 | 外包/临时运维能否发"一次性授权链接"，到期自动失效并全程留痕 |
信创适配 | 是否支持信创环境平滑替换，替换过程是否需要停机 |
这几项里，"免客户端"和"免跳板机"是最影响落地成败的两条——它们决定的不是技术先进性，而是运维人员愿不愿意用。一个需要装客户端、还要再跳一次的工具，最后一定会被人想办法绕开。
八、采购 PAM 该看哪五条标准？
如果你正在评估 PAM，可以用这五条去问，都是能当场验证的：
- 能不能说清"绕过的连接"：有没有工具能列出不经过网关的直连？（这条最容易被跳过，但它决定自动改密会不会出事）
- 改密失败会不会兜底：改密前是否校验新密码可用？失败是否保留原密码？
- 临时授权有没有"到期"：给外包的权限，是永久有效还是有时限、到期自动失效？
- 审计能不能按"人"查：给定一个人名，能不能查出他半年内访问过的全部资产与操作？
- 证书有没有人管：服务器证书的到期时间，是靠人记还是系统提醒？（证书过期导致业务中断，是比密码泄露更常见的事故）
九、常见问题
Q1：堡垒机已经买了，还需要 PAM 吗？需要，但两者是补位不是替代。堡垒机解决"操作可审计"，PAM 解决"凭据可治理"。如果你们现在的痛点是"不知道谁有管理员密码""离职账号没回收""密码三年没换"，那堡垒机帮不上，这是 PAM 的范畴。
Q2：PAM 上线要停机吗？不需要整体停机，但要排变更窗口。真正需要窗口的是"把现有密码改掉并托管"这一步，建议分批做，先从一个影响面小的系统开始。
Q3：业务系统很多，怎么保证都能接进来？先做连接关系测绘：哪些应用直连数据库、哪些走中间件、哪些硬编码。绕过网关的那部分，是实施的重点，也是项目工期的真实变量。
Q4：自动改密后，应用连不上数据库怎么办？这就是"身份网关"要解决的问题——应用连的是网关，不是数据库，密码由网关代填。前提是应用走网关。硬编码直连的应用需要改造或单独处理。
Q5：外包人员临时进来，怎么控制？用临时授权链接：一次性、有时限、到期自动失效，全程录像可回查。比"给个账号用完再改密码"要可靠得多——后者依赖人记得改。
Q6：运维人员会不会因为不方便而绕过 PAM？会，这是真实的项目风险。判断标准很简单：如果一个操作在 PAM 里要 5 步、在本地要 1 步，那它一定会被绕过。所以选型时"免客户端、免跳板机、Web 直接运维"不是加分项，是必需项。
Q7：控制台密码、数据库密码、证书，都要放进 PAM 吗？优先级是：先放"能直接接触到核心数据的"（数据库、核心业务系统管理员），再放"基础设施类"（网络设备、虚拟化平台），最后是证书。证书单独说一句——它的风险不是泄露，是过期，建议第一轮就把有效期纳入统一台账。
十、结语
特权账号管理这件事，难的不是技术，是改变一个已经运行了很多年的习惯。
把密码从 Excel 搬进系统，技术上一天能做完；但让运维人员接受"我不知道密码也能干活"，通常要几个月。
所以判断一个 PAM 项目成不成，看的不是上线了多少个账号，而是一句话：
半年之后，还有没有人需要知道密码？
如果还需要，那这套系统就只是换了个地方存密码。
数据来源与口径
- Forrester 关于特权凭据与数据泄露关联性的研究估计（80% 为机构估算值，非普查统计，不同机构口径存在差异）
- 联软科技 UniPAM 线上渠道推介会公开内容（2026 年 10 月 20 日）
说明：本文涉及的选型标准为通用方法论，不构成对具体产品的评价；文中产品能力描述以官方文档为准。
原创声明：本文为原创内容，转载请