
“系统出错了!”
信息科李主任刚上班,就接到药房电话。
药房馮主任在电话里嚷:”为什么我登录系统,提示’密码过期’?我昨天还能用!”
李主任心里一沉。
药房系统,用的是全院统一的”管理员账户”——用户名admin_yaofang,密码是Yaofang@2023。
这个密码一年前就该过期了,但冯主任一直没改。不是他不想改,是改了之后,药房十几台电脑都要手动更新密码,很麻烦。
而且,这套密码,从2023年用到现在,从来没出过问题。
但今天,突然提示密码过期。
李主任查了一下密码策略:密码有效期是180天。Yaofang@2023是2023年10月设置的,到今天已经超过500天了。
奇怪,为什么系统突然开始强制改密码?
他打开密码策略配置——有效期还是180天,但”密码历史记录”被改成了”记住5次”。而且,”密码必须复杂性”被开启。
“有人动过密码策略。”李主任说。
他查变更日志,发现是上周安全加固时,小吴改的。
小吴来了,解释:”我发现全院所有科室的管理员密码,都是’科室名@年份’,太简单了。我就把策略调严了:必须大小写字母+数字+符号,8位以上,180天过期,不能重复使用。”
“但药房不知道啊,”李主任说,”他们没收到通知。”
“系统登录的时候会提示。”
“但提示了为什么不改?冯主任说,他点了’确定’,登录还是失败。”
小吴查了一下:”哦,新密码策略要求密码不能包含用户名。冯主任如果设成’Yaofang@2024’,就包含了’Yaofang’,不符合策略,所以设失败。”
李主任明白了:这是一个典型的”好心办坏事”——安全策略变严了,但用户不知道怎么设置合格的新密码,导致集体被锁。
1. “万能密码”的发现
但这件事,只是冰山一角。
当天下午,老周来信息科做客,李主任跟他抱怨:”我们这权限管理,一团糟。”
老周问有多乱。
李主任打开用户管理后台,给老周看:
发现一:存在”万能账户”
– 有个用户叫admin_backup,密码是Admin@123456
– 这个账户的权限是”超级管理员”,但没人知道是谁创建的
– 最后一次登录是半年前,但账户状态是”启用”
李主任说:”这个账户是V2.0时代留下的,那时开发商留的后门。V3.0迁移时忘了删。”
发现二:科室共用账户严重
– 药房:admin_yaofang(5人知道密码)
– 住院处:admin_zhuyuan(3人知道密码)
– 财务科:admin_caiwu(4人知道密码)
– 检验科:admin_jianyan(2人知道密码)
密码都是”科室名@年份”,而且五年没改过。
“为什么这么乱?”
“因为一旦改密码,所有科室电脑都要同步更新,很麻烦。而且我们系统没有单点登录,每个科室都要独立账户。”李主任说。
发现三:权限虚高
– 门诊挂号岗的账户,有”删除挂号记录”权限
– 护士站的账户,有”修改药品价格”权限
– 医嘱开立岗的账户,有”删除医嘱”权限
“这些高权限,是出厂设置,我们没细调。”
老周看着后台,摇头:”这就像一个家,钥匙分给所有邻居,而且钥匙上贴着’万能’两个字。”
2. 老周的建议:三管齐下
老周给李主任提了三个建议:
1. 清理账户,最小权限原则
– 删除所有未使用的账户(尤其是admin_backup)
– 所有账户按角色分配权限:挂号员只能挂号,收费员只能收费,护士只能执行医嘱
– 每个角色,只给”必须”的权限,不给的权限,一个都不要给
2. 推广单点登录(SSO)
– 医院职工用一个账号(工号)登录所有系统
– 密码只需改一次,所有系统同步更新
– 极大减少”共用账户”现象
3. 建立账户生命周期管理
– 新员工入职,自动创建账户
– 员工调岗,自动调整权限
– 员工离职,24小时内禁用账户
– 定期(每季度)审计所有账户,清理僵尸账户
3. 实施中的”人性化”难题
但实施起来,困难重重。
第一关:清理”admin_yaofang”这类共用账户
李主任在信息科会上提出:药房今后不再使用admin_yaofang,改为每人一个独立账户。
冯主任当场反对:”我们药房十几个人,每人一个账号,那密码怎么管理?出问题谁负责?”
“你们现在共用一个密码,出了问题谁负责?”李主任反问。
“现在也没出问题啊。”
“刚才的密码过期事件,不就是问题吗?”
冯主任不说话了。
李主任提出妥协方案:
– 先为药房所有在职人员创建独立账户
– 保留admin_yaofang账户,但降权为”只读”
– 过渡期一个月,期间两种账号都可以登录,但鼓励用个人账号
– 一个月后,禁用admin_yaofang
冯主任勉强同意。
但执行时,很多人不配合——”用哪个账号不是用?为什么非要改?”
李主任只有硬着头皮,一家家科室去沟通,解释安全风险。
第二关:角色权限细化
老周带着实施团队,开始梳理所有岗位的权限。
工作量巨大:医院有五十多个岗位,每个岗位有上百个操作权限。他们要做的,是为每个岗位,设计”最小必要权限集”。
比如”挂号员”:
– ✅ 能创建门诊挂号记录
– ✅ 能查询患者历史就诊
– ✅ 能退号
– ❌ 不能修改挂号费(财务的事)
– ❌ 不能删除挂号记录(数据安全)
– ❌ 不能开医嘱(业务隔离)
但细化后,业务部门又有意见:
“我们有时候需要帮病人改个联系方式,为什么不能’修改患者信息’?”
“我们偶尔要退号,为什么’删除挂号记录’不行?”
老周的解释是:权限分配,不是按”当前需求”,而是按”职责边界”。
如果挂号员需要频繁改患者信息,那应该增加一个”患者信息维护岗”,而不是给挂号员这个权限。否则,每个人都是全能,出了事谁的责任?
但医院觉得这样太”死板”,影响效率。
老周让步:增设一个”高级挂号员”角色,权限比普通挂号员多几条(如修改患者联系方式),申请这个角色需要科室主任批准。
4. SSO上线后,各部门”不习惯了”
三个月后,单点登录系统上线。
所有科室,终于只有一个账号、一个密码。
理论上,密码安全度提高了——统一密码策略要求:12位,大小写+数字+符号,90天过期,不能和历史密码重复。
但实施后,负面反馈来了:
“密码太复杂了,记不住!”
“三个月就过期,太频繁了!”
“我手机不能记密码,每次都要问同事!”
冯主任更是直接找到李主任:”药房现在有两个人同时操作一台电脑,一个人输入密码登录,另一个人就用同一个账号继续操作。这跟以前共用账户有什么区别?”
李主任哑口无言。
这是”安全”与”便利”的永恒矛盾。
5. 老周的平衡之道
老周听完李主任的抱怨,说:”我们是不是把目标定错了?”
“什么目标?”
“我们以为目标是’安全’,其实目标应该是‘可控的安全’。”
“什么意思?”
“绝对的安全,会带来绝对的不便。比如每个操作都要二次验证,那业务就不用做了。安全措施,必须考虑用户的接受度。”
老周调整了策略:
1. 密码策略适度放松
– 长度从12位改为10位
– 复杂度要求保留,但增加”密码短语”支持(允许用句子,如”IloveHIS2024!”)
– 过期时间从90天延长到180天
2. 增加”二次认证”选择性
– 对于普通操作,只用密码
– 对于高危操作(删除、修改价格、批量导出),强制手机验证码
– 这样,日常使用不受影响,高危操作有保护
3. 推广”扫码登录”
– 每个科室电脑,贴一个二维码
– 职工用自己的手机扫码,免密登录
– 手机有生物识别(指纹/面容),安全和便利兼顾
4. 定期安全培训
– 教职工识别钓鱼邮件
– 教育密码管理常识(不要写在便签上)
– 通报安全事件案例
6. 一年后的变化
一年后,李主任再次盘点权限管理:
– 共用账户:从原来的12个,减少到2个(特殊场景,已申请保留)
– 个人账户:全院95%职工有独立账户
– 僵尸账户:清理了37个(离职未禁用)
– 权限事故:0次
– 密码相关求助电话:从每月20+次,降到2-3次
冯主任现在也适应了:”用扫码登录,确实方便。而且密码一年才改一次,能接受。”
老周来检查时,李主任说:”我现在觉得,权限管理不是’技术活’,是’管理学活’。你不仅要懂技术,还要懂人心。”
“怎么讲?”
“技术方案再完美,如果用户不接受,就是废纸。你不能指望医院人员都有IT专业素养。你必须把安全措施,做得像呼吸一样自然——用户甚至感觉不到’我在遵守安全规则’,这才是成功的。”
7. “最小权限”不是”最小信任”
李主任后来在一次省内HIS安全交流会上,分享了他的心得:
“很多领导觉得,权限管理是’防着自己人’。其实不是。
是‘明确责任边界’。
当每个人只有自己的权限,干了什么操作都能追溯到人,出了问题,就知道是谁的责任。
反过来,如果大家用的是同一个账户,出了事,互相甩锅,查不清。
所以,最小权限原则,表面上是限制,实际上是保护——保护了守规矩的人,也约束了不守规矩的人。
而且,给了每个人独立的账户,是对他们的尊重——’你是独立的个体,有你的职责和权限’。
共用账户,意味着’你只是系统的一个使用者,没有身份’。
这是两回事。”
互动话题
你们单位的账号密码管理是什么情况?有没有”万能密码”?
> 基于真实医院场景改编,人物均为化名
立即免费试用门诊系统:https://app.kmhis.com/
International Version:https://app.kmhis.com/multi/
了解软佳门诊管理系统详情:https://www.kmhis.com/outpatient-management-system.html
支持8种语言:简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语
说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想,要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。
你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。
