一、ISO 27799:2016 9.4.2 标准原文
条款原文：应通过安全的登录程序控制访问。放在医院环境中，本条不仅涉及用户名和密码输入界面，更包括登录前身份提示是否适当、失败处理是否安全、远程接入是否强化验证、共享终端是否及时锁定、会话是否在离人后失效等一整套进入系统的机制。
理解重点：本条不是单纯要求“做个登录框”，而是要求机构把进入系统这一瞬间做成既能识别真实身份、又不向未授权人员泄露过多信息、同时适配临床效率的受控入口。
二、条款深度解读
2.1 安全登录程序是访问控制的第一道真实边界
在很多文章里，安全登录程序常被写成一句很空的话，例如“设置安全登录界面、防止未授权访问”。真正的问题是，这句话并没有回答医院现场最难处理的部分。安全登录程序不仅决定能不能进去，还决定系统是否会在入口阶段泄露用户名有效性、是否支持暴力尝试、是否允许在离人情况下继续保持会话、是否能区分院内终端和院外远程风险、是否在高频使用环境下给出足够顺手但不失真的认证方式。
对医疗机构而言，入口控制失败带来的后果通常不只是个人隐私泄露。它还可能让病区工作站上的上一班登录状态被下一位人员沿用，让远程登录门户成为批量尝试入口，让值班期间的操作主体无法还原，甚至让某些高风险会话在公共区域长时间暴露。换言之，登录程序的设计直接决定后续日志记录是否值得信任。
2.2 医疗场景中的安全登录，必须同时解决效率和留痕问题
| 场景 | 常见薄弱点 | 风险后果 | 控制重点 |
|---|---|---|---|
| 病区共享工作站 | 长时间保持登录、离人不锁屏 | 后续人员沿用他人会话访问患者信息 | 短时自动锁定、快速实名重新认证 |
| 远程值班与会诊 | 远程门户重试无限制、来源不受控 | 外部暴力尝试、异常登录难发现 | MFA、来源限制、重试限制、风险告警 |
| 门诊高峰 | 登录耗时长，人员倾向于不退出 | 共用会话成为默认做法 | 单点登录、刷卡登录、快速切换身份 |
| 设备维护和后台管理 | 默认账号界面暴露、失败提示过细 | 泄露系统内部结构和可尝试对象 | 隐藏敏感信息、统一入口、强化审计 |
这张表说明，安全登录不是纯技术团队的界面设计问题，而是对医疗工作流程的适配问题。如果入口太复杂，一线就会选择不退出；如果入口太宽松，院外风险会直接穿透；如果错误提示太细，系统会主动帮助攻击者判断用户名是否存在；如果超时机制一刀切过短，又可能逼迫人员频繁寻找绕过方法。好的登录程序不是取一个中间值，而是按场景差异化设计控制。
2.3 一个合格的登录程序，至少应做到“能证实、少暴露、留痕清、易回收”
所谓“能证实”，是指登录过程足以确认当前操作者身份，尤其在远程、高风险和高敏感访问场景中不能只靠单一弱认证。所谓“少暴露”，是指登录界面和错误反馈不向外泄露过多系统信息，例如不明确提示“该用户不存在”或“密码错误次数还剩几次”之类细节。所谓“留痕清”，是指成功登录、失败尝试、锁定、解锁、会话超时和异常来源都要有记录，并能关联到用户和终端。所谓“易回收”，则是指登录机制应支持快速失效和统一控制，便于离岗、异常和调查时立刻收口。
医院特别容易忽视“会话结束”其实也是登录程序的一部分。若用户认证很严格，但登录后长时间离开终端、系统不自动锁定、浏览器保留会话，整体风险依然很高。对于公共区域、自助终端、护士站和会诊室，这一点尤其重要。没有被控制的会话，本质上等于一段没有边界的持续登录。
2.4 本条与 9.3.1、9.2.4 的分工很清楚：这里重点是程序设计而非用户自律
9.3.1 讲用户如何正确使用认证信息，9.2.4 讲组织如何管理这些信息，而 9.4.2 更关注系统入口本身是否设计得安全。也就是说，即便用户完全遵守规则，如果登录程序允许无限重试、默认展示用户名列表、远程门户无二次验证、离人后不锁屏，机构仍然不符合本条要求。把责任全部归给“用户应注意保密”是对条款理解过浅的表现。
对医院来说，最成熟的做法往往不是要求所有人忍受低效登录，而是让高频临床场景采用更顺手的实名认证方式，让院外和高风险场景叠加强认证，让终端离人即锁、回到系统即需重新验证。入口机制设计得越贴近业务，违规绕过空间就越小。
三、实施要点
- 对院内终端、远程接入、后台管理、供应商维护等不同入口设计不同强度的登录控制。
- 控制登录失败反馈，不泄露不必要的账户存在性和系统结构信息。
- 对远程和高风险访问启用多因素认证、来源限制、重试限制和异常告警。
- 为共享终端配置短时锁屏、快速实名重新登录和会话自动失效机制。
- 将登录成功、失败、锁定、解锁、超时和异常来源全部纳入日志审计。
- 定期抽查已登录无人值守终端、长期存活会话和异常登录模式，验证入口控制是否真正生效。
四、常用工具与实施方法
| 工具/方法 | 适用场景 | 实施重点 | 关键输出 |
|---|---|---|---|
| 单点登录与刷卡认证 | 病区、门诊、护理站 | 缩短重复登录时间，同时保持个人身份唯一 | 接入配置、会话日志 |
| 多因素认证 | 远程办公、远程会诊、管理后台 | 提升院外接入和高风险入口的身份确认强度 | MFA 策略、认证记录 |
| 会话超时与自动锁定 | 共享终端、公共区域终端 | 防止用户离开后会话长期暴露 | 超时配置、抽查记录 |
| 登录审计与异常告警 | 全院主要系统和门户 | 关注异常尝试、异地登录、批量失败与夜间模式 | 审计报表、处置工单 |
五、典型案例
案例一：病区共享终端长期保持上一个用户登录状态
某医院病区工作站因交接频繁，医护人员普遍选择不退出系统，导致终端常年保持已登录状态。表面上效率提高了，实际上任何经过终端的人都可能在前一个人的会话中查看患者信息或完成操作。这里暴露的不是用户懒惰，而是登录程序没有为高频共享场景提供更合适的实名快速切换机制。后来医院引入刷卡加短时锁屏模式，登录效率提升的同时，身份边界也恢复了。
案例二：远程登录门户未限制异常重试和来源
另一家机构的远程门户对登录失败次数和来源地址没有有效限制，且错误提示会明确区分用户名不存在和密码错误。外部扫描很快就能识别有效账号，并持续尝试口令。虽然最终未造成重大事件，但审查时已经足以说明登录程序设计存在明显缺陷。整改后，机构统一调整了失败反馈、启用多因素认证并限制外部来源，入口风险大幅下降。
六、成文信息与审核证据
- 各类登录入口的安全设计说明和适用范围定义。
- 远程接入、多因素认证、失败限制、锁屏超时等配置记录。
- 登录失败、账号锁定、异常来源和会话超时的审计证据。
- 共享终端与公共区域终端的抽查记录和整改材料。
- 围绕登录机制优化开展的需求评估、风险分析和变更记录。
- 因登录程序缺陷引发的事件、投诉或审计发现及闭环整改记录。
审核 9.4.2 时，检查者往往会直接测试终端离开后多久锁定、错误登录提示显示什么内容、远程入口是否有强化认证，而不是只看制度。入口控制能否被现场复核，是这一条最关键的判定方式。
七、常见误区及踩坑提醒
| 误区 | 常见表现 | 正确做法 |
|---|---|---|
| 有登录框就算安全登录 | 忽略失败限制、错误反馈、会话超时和远程风险 | 把进入、失败、维持和退出全过程都纳入设计 |
| 为了效率只能长期保持登录 | 共享终端离人不锁屏 | 通过快速实名切换而不是长期挂会话解决效率问题 |
| 远程入口与院内入口可以同样处理 | 院外接入未加更强验证 | 按场景和风险差异化设置登录强度 |
| 错误提示越详细越方便用户 | 明确告诉攻击者用户名是否存在 | 控制反馈粒度，避免暴露不必要信息 |
八、结论
9.4.2 的重点是把系统入口做成真正受控的边界，而不是一个形式上的登录界面。对医院而言，安全登录程序必须同时满足身份确认、信息最少暴露、会话可控和临床可用这四个条件，缺一不可。
做得好的登录程序，会让不同场景下的人员都能以适当方式快速进入系统，同时保证离人后会话不会持续暴露、院外接入不会轻易被试探、错误反馈不会反向帮助攻击者。做得差的程序，则会逼着一线绕过流程，或者让系统入口本身成为风险源。
因此，本条的真正价值不在“多一道认证”，而在于让每一次进入系统都发生在清楚、可记录、可回收的边界之内，这正是医疗信息系统可信运行的起点。