卫健委医院密码合规检查：LIS实验室与医保平台密码评估实战
某三甲医院接到卫健委组织的网络安全与密码应用检查通知，信息科按经验准备了一套材料：HIS、EMR、门户的材料都齐，密评报告也在有效期内。检查当天，专家组看完材料后问了两句："LIS 的检验仪器接口是怎么保护的？""医保结算接口的报文签名用的什么密钥、谁在管？" ------两句话问住了全场。材料里确实没有这两块，因为历次自查都没把 LIS 与医保接口当成"要评估的对象"，可检查恰恰盯的就是这类平时不在视野里、但数据流转最频繁的系统。
医院做密码合规，目光往往集中在 HIS、EMR、门户这些"主角"上，而 LIS（实验室信息系统）与医保接口这两类"配角"，才是检查时最容易翻车的地方：它们接口多、跨系统、与其他单位强耦合、平时没人专门管安全。这篇按检查现场式写：先复盘一次检查暴露的问题，再讲清检查依据，然后分别拆 LIS 与医保接口两类系统的失分点与达标做法，最后给举证材料清单与验收清单。
全文结构：
- 一、检查现场：两句话问住全场
- 二、先分清：检查依据与查什么
- 三、LIS 实验室系统：为什么是重灾区
- 四、医保平台接口：为什么容易失分
- 五、密码能力怎么落：两类系统的共同底座
- 六、两类系统的举证材料怎么准备
- 七、高频被问的六个问题
- 八、验收清单
一、检查现场：两句话问住全场
把现场复盘成一张表，问题就清楚了------两类系统的失分点高度相似，都指向同一件事：接口层没人认领。
| 被查对象 | 现场暴露的问题 | 本质 |
|---|---|---|
| LIS 实验室系统 | 检验仪器到工作站的数据明文传输；工作站账号共用；检验结果库明文落盘 | 接口与终端长期缺管 |
| 医保平台接口 | 报文签名有无说不清；密钥在配置文件里；接口日志不全 | 跨单位接口无密码治理 |
| 共同点 | 都不在"往年自查对象清单"里 | 边界系统被当成次要系统 |
为什么这两类系统特别容易被漏？因为在医院的组织分工里，它们通常有三重"身份模糊"：
- 归属模糊 ：LIS 由检验科业务驱动、信息科代管；医保接口由医保办对接、信息科实现------业务归属清楚，安全归属模糊；
- 改造窗口模糊 ：HIS 改造有明确项目、有预算；LIS 与医保接口的小改动散落在日常运维里，没人专门为它们立项目；
- 风险感知模糊 ：仪器接口走的是院内网、医保接口是"专线"，于是默认"网络可控就等于安全"，忽略了数据本身有没有被保护。
检查要问的，正是这些模糊地带。
二、先分清：检查依据与查什么
依据 ：《密码法》确立了关键信息基础设施使用商用密码保护并开展密码应用安全性评估的要求；《商用密码管理条例》（2023-07-01 施行）明确了商用密码应用安全性评估的制度地位；卫生健康领域有《医疗卫生机构网络安全管理办法》（国卫规划发〔2022〕29号 ，由国家卫生健康委、国家中医药局、国家疾控局联合印发），对医疗卫生机构的网络安全责任、密码应用等提出要求。技术依据是 GB／T 39786-2021《信息安全技术 信息系统密码应用基本要求》，配套的 **GB／T 43206-2023《信息安全技术 信息系统密码应用测评要求》**规定了测评单元与判定方法。
检查关注的四个层面（与密评口径一致）：
| 层面 | 落到 LIS / 医保接口上问什么 |
|---|---|
| 物理和环境 | 实验室工作站、医保前置机的机房/机柜访问是否受控 |
| 网络和通信 | 仪器到工作站、医院到医保平台的通信用了什么保护 |
| 设备和计算 | 工作站与前置机的登录鉴别、日志完整性 |
| 应用和数据 | 检验结果与结算数据的存储、传输、操作不可否认性 |
三个判断原则（现场答辩时用得上）：
- "在内网"不等于"已保护" 。检查看的是数据本身的密码保护，不是网络拓扑。院内网一样要做传输加密，专线一样要做报文签名；
- "接口"是评估对象，不是"技术细节"。LIS 与医保接口承载的正是敏感数据流转，属于应用和数据层面的评估范围；
- 高风险项优先清零。明文存储、密钥失管、使用未获认证的密码产品，这几类通常直接触发高风险判定，先改这些，再补中低风险项。
三、LIS 实验室系统：为什么是重灾区
LIS 的结构决定了它的暴露面：一头连着检验仪器，一头连着 HIS 与临床 。仪器侧往往是厂商自带的通信协议（有的还很老旧），临床侧是标准接口------两头都不在信息科的日常改造范围内。
四个典型失分点与达标做法：
| # | 失分点 | 现场表现 | 达标做法 |
|---|---|---|---|
| 1 | 仪器到工作站的传输未保护 | 仪器串口/网上传检验原始数据，明文 | 在工作站侧做加密接入或链路加密；无法改造的仪器用前置加密网关兜住 |
| 2 | 工作站账号共用 | 一个"检验科"账号多人使用 | 一人一账号，关键操作叠加第二因素（数字证书介质） |
| 3 | 检验结果明文落库 | 直连数据库能看到明文结果 | 敏感字段加密落盘，密钥外置管理 |
| 4 | 检验数据外发无管控 | 导出 Excel 发给科研或外院 | 导出走审批 + 脱敏，外发通道受控 |
其中第 1 项最难也最关键 。现实情况是：很多检验仪器设备厂商的通信协议不支持加密，仪器也不能随便改配置（涉及设备验证与合规）。可行的路径是在接收侧兜底 ------工作站或前置机上部署加密接入能力，仪器怎么发不变，数据一落地就是密文、往外转发就走加密通道。改造困难的场景，防护点就往可控的一侧移。
第 2 项常被当成"管理问题"忽略，但检查时它就是设备和计算层面的身份鉴别问题。共用的后果是审计日志失去意义------出了问题查不到具体是谁。达标做法是一人一账号 + 关键操作（结果审核、报告修改、数据导出）叠加第二因素。
给 LIS 场景的两条实操建议：
- 先理清仪器清单再谈方案。不同仪器、不同协议、不同年代，方案必须分类设计。先出一张"仪器---协议---改造可行性"的清单，再定每类的接入方式；
- 把检验科拉进项目组。LIS 的安全改造必然影响检验流程，没有检验科参与，方案上线就会被业务否定。
四、医保平台接口：为什么容易失分
医保接口的特点是跨单位、跨网络、强耦合 ：医院侧有前置机与接口服务，对端是医保平台，中间往往还有专线或 VPN。它失分的原因和 LIS 不同------不是"没人管"，而是"以为已经在管了"。
四个典型失分点：
| # | 失分点 | 现场表现 | 达标做法 |
|---|---|---|---|
| 1 | 报文完整性无保障 | 接口有加密通道，但报文没有签名，篡改无法发现 | 关键报文加数字签名，防篡改且可追溯来源 |
| 2 | 密钥管理说不清 | 密钥写在配置文件里、多人可见、从不轮换 | 密钥纳入统一管理平台，按周期轮换并留痕 |
| 3 | 身份鉴别单向 | 只验医院侧身份，不验对端节点 | 双向身份鉴别（人 + 节点/设备） |
| 4 | 接口日志不全 | 只记了调用时间与结果，没记数据流向与操作人 | 日志覆盖主体、对象、结果，且完整性受保护 |
为什么"有加密通道"还会失分 ：因为检查问的不只是"传得安不安全"，还有"数据有没有被改过、出了问题能不能证明是谁发的 "。通道加密解决的是"路上被看"，签名解决的是"被改"和"不认账"------这是两件事。医保结算数据涉及资金，后者的重要性不低于前者。
第 2 项是现场最常被追问的："密钥谁在管？多久换一次？记录在哪？"如果答的是"在配置文件里，系统管理员管"，基本就到此为止了。达标状态是：密钥由统一平台纳管、根密钥由硬件密码模块保护、轮换有周期有记录、访问有审计。
第 4 项的隐蔽性最强 ：接口日志往往只记录了"某时调用成功"，但没记"哪个账号、对哪笔数据、做了什么操作"。检查要的是能还原一次业务操作------这在医保场景里尤其重要，因为涉及费用与结算，事后核查是常态。
五、密码能力怎么落：两类系统的共同底座
LIS 与医保接口的失分点看起来分散，但落到工程上会收敛成同一组能力------鉴别、加密、密钥、审计、防勒索五件事，两类系统的答案是一样的：
| 能力需求 | 对应做法 | 承接方式 |
|---|---|---|
| 工作站与前置机的身份鉴别 | 一人一账号 + 关键操作第二因素（数字证书介质） | 统一身份认证（安当 ASP ）+ 国密介质（安当 UKEY） |
| 检验结果库、结算数据的密文落盘 | 库侧/文件侧透明加密，应用与检验软件零改造 | 安当 TDE |
| 仪器接口的兜底加密、接口报文保护 | 接收侧加密接入 + 报文签名与验签 | 由加密集成能力承接（安当 DSI），签名能力由密码设备提供 |
| 密钥集中管理 | 密钥统一纳管、根密钥硬件保护、轮换留痕 | 安当 KSP + 安当 HSM |
| 防勒索与终端数据保护 | 异常加密行为阻断、终端留存管控 | 安当 RDM |
两条落地经验：
- 改造困难的环节把防护点往可控侧移。仪器不能改、对端平台不能改，就在自己能控的一侧兜底------这是 LIS 与医保接口改造能真正落地的前提；
- 密钥必须先收口再谈其他。两类系统的密钥一旦散落在配置文件与脚本里，后面的轮换、审计、举证都无从谈起。密钥统一纳管是这套底座的起点，也是检查现场被追问最多的一环。
六、两类系统的举证材料怎么准备
检查时，能被证明的才算做过。两类系统要准备的材料清单：
| 材料类别 | LIS 需要准备 | 医保接口需要准备 |
|---|---|---|
| 清单类 | 仪器清单（型号/协议/改造可行性）、工作站清单 | 接口清单（用途/协议/对端）、前置机清单 |
| 设计类 | 数据流图（仪器→工作站→LIS→HIS） | 接口数据流图（含签名与加密位置） |
| 加密类 | 加密范围说明、算法与密钥管理说明 | 通道加密配置、报文签名机制说明 |
| 密钥类 | 密钥台账、轮换记录、权限分配 | 密钥台账、轮换记录、交接记录 |
| 鉴别类 | 账号清单、第二因素使用记录 | 账号与节点身份清单、双向鉴别配置 |
| 审计类 | 关键操作日志样例（审核/修改/导出） | 接口调用日志样例（含操作人与数据对象） |
| 制度类 | LIS 安全操作规程、检验数据外发流程 | 接口运维制度、密钥管理制度 |
现场怎么自证（占位示意，接口按实际）：检查现场最有力的材料是"能当场跑出来"的记录，准备时就该把这几条命令跑通、结果留档：
bash
# 自证一：检验结果在库里是不是真密文（直连数据库看原始值）
psql -h lis-db.example -U auditor -c \
"select sample_no, substr(result_value,1,24) as raw from lis_result limit 5;"
# → 期望：result_value 显示为密文编码，不是明文检验值
# 自证二：医保接口报文验签（用对端公钥验证一笔历史报文）
curl -s -X POST "$MIB_API/v1/verify" -H "Authorization: Bearer $TOKEN" \
-d '{"msgId":"<历史报文号>","algorithm":"SM2withSM3"}' | jq '{valid, signer, signedAt}'
# → 期望：valid=true 且能返回签名主体与时间，证明防篡改与可追溯
# 自证三：接口密钥是否已收口（配置文件里不该有明文密钥）
grep -rl 'appSecret\|privateKey\|aes_key' /opt/interface/conf/ 2>/dev/null
# → 期望：查不到明文密钥；密钥由统一管理平台按标识调用三条准备经验：
- 材料与系统状态必须一致。制度写"密钥每季度轮换"，日志里就得有每季度的记录；对不上时，宁可先把制度改成实际状态，再逐步收紧；
- 能有系统截图/导出记录的，别用手工台账。检查现场很可能要求当场演示导出，手工台账容易被追问细节；
- 数据流图是最值钱的一份材料 。一张清晰的"数据从哪来、经过谁、到哪去、每段怎么保护"的图，能省掉大量解释成本------画不出这张图，说明自己也没梳理清。
七、高频被问的六个问题
| # | 现场提问 | 想确认什么 | 应答要点 |
|---|---|---|---|
| 1 | 仪器接口是明文还是有保护？ | 是否存在未保护的传输 | 说明改造可行性分类 + 兜底方案（接收侧加密接入） |
| 2 | 检验数据导出谁批？ | 数据外发是否有管控 | 审批流程 + 脱敏规则 + 外发留痕 |
| 3 | 医保报文签名用的什么算法？ | 是否国密 + 是否真做了签名 | 算法类型（SM2/SM3）+ 验签机制 + 演示 |
| 4 | 接口密钥谁在管、多久轮换？ | 密钥是否失管 | 统一平台纳管 + 轮换周期 + 可导出的记录 |
| 5 | 接口日志能查到具体操作人吗？ | 审计能否还原操作 | 日志字段说明 + 现场导出样例 |
| 6 | 前置机登录怎么鉴别的？ | 设备与计算层面是否达标 | 一人一账号 + 第二因素 + 审计 |
答辩的一条通用原则 ：答不上来时不要编，说清现状 + 整改计划与时间点。检查的本质是评估风险与整改意愿，一个"目前是明文，已列入本季度整改计划，方案已评审"的回答，比含糊其辞的"应该是加密的"要安全得多。
八、验收清单
| # | 检查项 | 达标判定 |
|---|---|---|
| 1 | 边界系统纳入自查范围 | LIS、医保接口等均列入自查对象清单 |
| 2 | 数据流图完整 | 两类系统均有数据流图，标注每段保护方式 |
| 3 | 仪器接口有保护 | 仪器到工作站的传输加密或接收侧兜底加密 |
| 4 | 工作站身份鉴别 | 一人一账号，关键操作有第二因素 |
| 5 | 检验结果存储加密 | 敏感字段密文落盘，抽样直连数据库可验证 |
| 6 | 检验数据外发管控 | 导出走审批与脱敏，外发通道受控且有留痕 |
| 7 | 医保报文完整性 | 关键报文有数字签名，可验签、可溯源 |
| 8 | 医保接口通道加密 | 通道加密确认，抓包不可读 |
| 9 | 双向身份鉴别 | 医院侧与对端节点身份均被验证 |
| 10 | 密钥集中管理 | 密钥纳入统一平台，根密钥硬件保护，轮换留痕 |
| 11 | 接口日志可还原 | 日志含操作人、数据对象、结果，完整性受保护 |
| 12 | 前置机日志完整性 | 前置机关键日志有完整性保护，不可随意删改 |
| 13 | 密码产品合规 | 使用的密码产品有认证证书且型号对应 |
| 14 | 整改闭环 | 发现问题有整改计划与责任人，历史问题有闭环记录 |
LIS 与医保接口这两类系统之所以总在检查时翻车，不是因为技术难，而是因为它们长期处在"业务有人管、安全没人认领"的模糊地带 。破解办法也很朴素：把它们明确列入自查对象、画出数据流图、按段补上密码保护、把密钥收口到统一管理------四件事做完，检查时被问住的概率会大幅下降。医院密码合规真正的短板，往往不在主角系统，而在这些每天高频流转、却从未被认真评估过的边界系统。
你们医院自查时把 LIS 和医保接口算进去了吗？这两类系统整改时最难推动的是哪一环，评论区聊聊。
文章作者：安当加密技术负责人