摘要做特权账号管理PAM这行久了最近被问得最多的一个问题是“我们现在用的是CyberArk能不能换成国产的切换会不会出大事”说实话这个问题前几年还有人犹豫这两年问的人明显多了。原因不复杂——预算要控、服务要跟得上、合规卡得越来越严。但真正动手迁的人不多核心顾虑就一个怕切到一半业务断了账号乱了回不去了。我们团队这两年做了不少从CyberArk到海颐的迁移项目累计迁了超过5万个用户、50万个特权账号最快的两周搞定复杂的做了两个月。这篇文章把实际踩过的坑和验证过的做法整理出来给正在评估PAM国产化迁移的团队一个参考。一、先搞清楚你迁的不是软件是一整套权限关系很多人一开始把迁移想得太简单以为就是把账号导出来再导进去。真正做过就知道PAM里存的不只是账号密码而是一张**谁—能用什么账号—按什么规则用的关系网**。具体来说迁移范围至少覆盖三层人这一层用户、用户组、谁对哪个密码箱有权限、能做什么操作查看审批改密钥匙这一层特权账号本身、账号归属于哪个密码箱、密码箱之间的层级关系规则这一层平台策略、密码复杂度规则、改密周期、审批流程、会话审计策略这三层是绑在一起的。只迁账号不迁权限迁完所有人都用不了只迁权限不迁规则等于裸奔。所以我们的做法是迁移前先把新旧平台的对象映射关系建出来用户对用户、用户组对用户组、密码箱对密码箱、平台策略对平台策略一一对应清楚了再动手。这里有个容易踩的坑CyberArk里有些自定义平台Platform和海颐的平台模型不是完全一一对应的需要提前做适配方案不能等到迁移执行时才发现对不上。二、迁移五步走摸底比执行更重要我们把整个迁移过程拆成五步听起来常规但每一步都有实际讲究。第一步摸底评估——别跳过这步省了后面全是雷上来先盘点清楚现有多少用户、多少用户组、多少特权账号、多少密码箱、多少条平台策略、多少个审批流程。还要搞清楚哪些账号是高频使用的核心账号哪些是僵尸账号可以顺便清理。摸底的输出不是一张统计表就完了而是要能回答几个问题迁移总量多大哪些对象依赖关系最复杂哪些账号迁错了影响最大有没有历史遗留的脏数据需要先处理我们遇到过一个客户摸底时发现有近20%的账号已经没人在用了直接在迁移前清理掉迁移动作量少了五分之一。第二步方案准备——定映射、定顺序、定窗口映射关系在摸底的基础上细化到每一类对象。迁移顺序也有讲究我们一般是先迁组织结构和用户再迁密码箱和账号最后迁策略和规则因为后面的对象依赖前面的对象存在。试点范围建议选一个业务影响相对可控、但有代表性的部门或系统先跑通全流程验证映射关系、验证工具、验证回退方案再扩大范围。切换窗口要和业务方提前对齐避开月结、批处理、重大活动这些时间点。迁移前应形成一份映射表例如原平台对象目标平台对象转换规则无法直接映射时如何处理CyberArk Safe海颐密码箱按业务或责任部门对应拆分、合并或新建Safe 成员密码箱成员保留用户用户组关系无对应用户时暂停迁移Safe 权限目标平台权限按最小权限重新核对进入人工复核清单账号 Platform目标平台策略按资产类型和管理方式匹配先建立策略再迁账号用户组目标平台用户组保留有效成员关系处理重名和目录差异这里不建议只追求“结构看起来一样”。真正要确认的是业务语义一致。例如原平台某项权限允许用户使用账号但不能查看密码目标平台就应实现等价的业务控制而不是因为权限名称相近就直接对应。高风险权限、共享账号和核心系统密码箱最好由原平台管理员、目标平台实施人员和业务责任人共同确认。第三步可视化工具迁移——别用人工导用迁移助手这一步是整个过程里最体现平稳的地方。我们用海颐的迁移助手工具来执行不是把数据导出成Excel再人工导入而是工具直接建立新旧平台的连接按映射关系分批自动迁移。这么做的好处有几个敏感信息全程加密传输不会明文落地到中间文件减少泄露风险迁移过程可视化每个对象的状态是未迁移“迁移中”“成功”失败一目了然失败的对象会有明确的错误提示可以针对性处理后重跑不用整批重来所有迁移操作有明细记录后面核对和审计都用得上分批的粒度根据项目规模来大项目可能按部门或系统拆成十几批小项目两三批就搞定。每批迁完做一次快速校验确认没问题再进下一批。第四步并行验证——新旧平台对着查这步不能省“迁移成功”只代表工具完成了一次写入不代表账号已经可以安全、正常地使用。建议在正式切换前保留并行验证阶段从对象数量、权限关系和真实业务操作三个层面核对用户、用户组、密码箱和账号数量是否符合预期关键字段是否完整账号与密码箱归属是否正确用户组成员和密码箱权限是否一致管理员、运维人员和审计人员能否执行各自应有的操作密码验证、变更或调和流程是否符合目标策略目标系统连接、会话访问和审计记录是否正常日志、告警及外部系统联动是否有效失败对象是否已单独处理并再次验证。对于核心业务抽样不应只抽“迁移成功”的普通账号。管理员账号、服务账号、共享账号、跨部门密码箱和特殊策略账号更值得优先验证。第五步切换验收——试运行没问题了再正式交接并行验证通过后进入切换阶段。切换不是把旧系统一关就完事而是确认所有用户已经在新平台上正常操作确认旧平台不再有新的变更比如新建账号、改权限保留旧平台一段时间的只读访问作为兜底正式验收交付迁移报告、映射表、验证记录旧系统什么时候下线建议和业务方约定一个观察期比如一到三个月观察期内新平台运行稳定再彻底下线。三、怎么保证平稳四个关键设计上面说的是流程流程之外有几个设计层面的东西是保证迁移不出大事的关键。第一全程加密。特权账号的密码本身就是最高敏感级别的信息迁移过程中绝对不能明文落地。迁移助手在数据传输和临时存储环节都做加密处理避免人工导出导入带来的泄露风险。这个说起来是常识但真要落地工具层面得支持才行。第二结构一致。海颐在产品设计上采用了和CyberArk相似的独立保险箱Safe模型这意味着密码箱的层级、账号归属、权限分配这些核心概念是对得上的迁移时不需要做根本性的结构转换。如果两个产品的核心模型差异太大迁移的复杂度和出错概率会指数级上升。第三状态可视。迁移过程中最怕的就是不知道迁到哪了、不知道哪些成功了哪些失败了。迁移助手的可视化面板把每个对象的状态都标清楚项目组随时可以看进度出了问题第一时间定位不用靠猜。第四记录可追。每一个对象的迁移结果、时间、操作人、错误信息都有明细记录。这些记录在迁移过程中用来核对迁移结束后用来做审计和交付后面如果有用户说我某个账号怎么不对可以直接查迁移记录定位是迁移时的问题还是后续操作的问题。四、一些真实数据和经验说几个我们实际项目里的数据供评估周期和工作量时参考累计迁移用户规模超过10000累计迁移特权账号超过500000参考迁移周期从约2周到2个月不等主要取决于账号规模、组织结构复杂度和定制化策略的多少行业覆盖金融、能源、运营商、交通航空、政府、中外企业等不同行业的合规要求和审批流程差异比较大会影响周期几个比较实在的经验摸底一定要做细。我们做过的项目里后面出问题的十有八九是摸底时没摸清楚比如漏了某个自定义平台、没发现某个特殊的审批流程。摸底多花一两天后面能省一两周。不要试图一次性全迁。再小的项目也建议至少分两批先迁一批验证流程再迁剩下的。大项目按部门或系统拆批每批独立验证。并行验证期别省。有些客户着急上线想把并行期压缩到几天我们一般不建议。至少覆盖一个完整的业务周期很多问题只有在实际使用中才会暴露。回退方案要提前准备好但最好用不上。每一批迁移前都确认回退路径保留旧平台的数据和访问权限。实际上我们做的项目里正式切换后需要回退的情况很少但有回退方案在整个团队心里都踏实。用户培训不能只发个手册。切换前后要组织实际操作培训特别是审批人、密码箱管理员这些角色他们的操作习惯变了如果不培训好切换后第一周全是求助电话。五、写在最后PAM迁移这件事本质上不是换个软件而是一次权限体系的平稳切换。它考验的不是某个工具好不好用而是整个迁移方案有没有把人—账号—规则这三层关系都理清楚有没有把每一步的验证和回退都做到位。从CyberArk到海颐的迁移我们做下来的感受是只要方法对、工具到位、流程走细这件事是可规划、可验证、可回退的不需要推倒重来的勇气。如果你的团队正在评估PAM国产化迁移建议第一步先做一次迁移摸底评估——确认迁移对象和规模、选一个试点范围、形成周期和风险方案。把底摸清楚了后面的决策就有依据了。有迁移方面的问题欢迎在评论区交流。参考资料CyberArk Identity Security Platform Shared Services Updates用户、特权账号、Safes 与 Safe 权限生命周期管理https://www.cyberark.com/resources/identity-security/cyberark-identity-security-platform-shared-services-updates-december-2022CyberArk PAM Administration Training用户、策略、Safes、账号、工作流与发现等管理对象https://training.cyberark.com/learn/course/external/view/elearning/3/PrivilegedAccessManagementPAMAdministration-Self-PacedNIST NCCoEPrivileged Account Managementhttps://www.nccoe.nist.gov/financial-services/privileged-account-management