简介这份PDF方案面向医院信息科、医疗信息化建设者与安全合规负责人围绕等保2.0三级要求梳理医疗行业数据安全从规划到落地的完整思路适用于智慧医疗场景下的合规自查与建设参考。资源包共1个文件为PDF格式文档压缩包约2.21MB内容以技术要求与建设分类为主线按物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个层面逐项展开。文档对每个安全控制点都给出对标产品、技术措施与测评检查内容例如关闭非必要系统服务与高危端口、借助数据库防火墙与数据库防水坝屏蔽默认端口、通过运维一体机监控CPU与内存等资源并设定阈值报警在应用与数据层面则涵盖身份唯一标识、多因素认证、登录失败处理、最小权限与三权分立、表级列级细粒度管控、透明加密保障数据完整性等要点。目前已有121人学习可帮助读者快速建立医疗等保建设的落地框架。1. 医院等保2.0数据安全建设方案从过测评到扛得住医院信息科最常见的场景是测评机构进场前两周安全厂商递来一份几百页的建设方案设备清单和拓扑图一个不少测评顺利通过。可 HIS 主库里几十万条患者身份证号还是明文躺着一个运维账号依然能SELECT *把患者主索引整表拉走。根子在于把数据安全当成边界防护来做——边界能挡外部扫描挡不住内部越权和数据本身裸奔。医疗场景还有自己的约束HIS、LIS、PACS、EMR 耦合紧停机窗口以分钟计设备厂商远程维护频繁影像调阅对延迟敏感任何让挂号变慢的改造都会被临床推翻。所以这份建设方案不能照抄互联网那一套得按数据在哪、谁能碰、碰了留什么痕迹来设计。下面按控制项拆解、分类分级、加密脱敏、审计运营、测评自查五步推进把等保2.0条款落成能跑的命令、能改的 SQL 和能交付的证据面向医院信息科工程师和医疗行业安全交付方。2. 等保2.0三级要求怎么拆成医院数据安全的技术控制点2.1 从 GB/T 22239-2019 条款到可交付技术动作的映射等保2.0把数据相关要求分散在安全通信网络安全计算环境安全管理制度几层医院做方案最容易漏的是安全计算环境里数据完整性、保密性、备份恢复这三条因为它们必须落到具体数据对象上没法靠一台设备交差。对着等保2.0标准全文逐条核的时候建议先做一张映射表横向是条款纵向是医院各套系统中间填谁改、改什么、留什么证据。控制项医院落地场景技术动作测评证据安全通信网络·通信传输医护工作站连 HIS、移动护理 PDA 回传体征全链路启用 TLS数据库明文端口不对外开放抓包结果、证书清单安全计算环境·数据完整性医嘱、检验结果、电子病历归档关键字段加 SM3/HMAC 校验值读写时比对校验脚本输出日志安全计算环境·数据保密性患者身份、诊断、传染病报告字段级加密加密钥集中管理密文样本、密钥台账安全计算环境·数据备份恢复HIS 主库、LIS 结果库、PACS 影像库全量加增量、异地存放、定期恢复演练恢复演练报告、RPO/RTO 记录个人信息保护预约挂号接口、科研导出、第三方对账脱敏输出、最小必要采集、访问留痕脱敏前后对比、接口调用日志安全审计数据库、操作系统、核心应用日志集中采集留存不少于 6 个月现场检索审计日志证据这一列最关键。测评老师不会看你买了什么设备而是让你现场演示一条患者记录是怎么被加密、被审计、被脱敏的。所以映射表填完之后每一条都要能对应到一条可复现的命令或者一个可查询的日志表。2.1.1 三级与二级在医院场景下的实际差异二级对数据保密性只要求重要数据在传输过程中不被泄露三级明确加了存储环节要求采用密码技术保证重要数据在传输和存储过程中的保密性——这条是医院从二级升三级时最容易被卡的地方。另外三级多了个人信息保护条款要求仅采集和处理业务必需的个人信息落到处方、检验申请单这类表单上就是不能因为字段预留就多存一个身份证号。判断自己要走哪一级先看医院年门诊量、床位规模和是否属于区域平台节点再对照评审细则确认。2.2 医院数据分类分级的判据与四级模型分类分级是整套方案的底座级别定错后面的加密强度、备份周期、审批流程全跟着错。医院的健康医疗数据按行业指南可以分到五级实际落地用四级更容易执行也更容易跟 HIS 的字段权限对齐。级别数据示例控制强度1 公开科室介绍、专家出诊表完整性校验2 内部排班、设备台账、药品库存访问控制禁止外发3 敏感住院号、就诊记录、检验结果、影像索引存储加密、脱敏输出、访问留痕4 核心身份证号、生物特征、传染病报告、精神科病历强加密、双人授权、单独审计判据不要只靠字段名字段名可以随便起。下面这段脚本同时看字段名和采样内容命中即定级采样只保留脱敏后的前若干字符避免打标工具本身变成泄露源。# classify.py —— 医院数据分类分级规则引擎 import re from dataclasses import dataclass, field # (敏感类型, 字段名关键词, 内容正则, 级别) RULES [ (身份证号, [id_card, sfzh, cert_no], r\d{17}[\dXx], 4), (手机号, [phone, mobile, tel], r1[3-9]\d{9}, 3), (住院号, [inpatient_no, zyh], rZY\d{8}, 3), (诊断编码, [diagnosis, icd], r^[A-Z]\d{2}\.\d{1,2}, 4), (影像索引, [study_uid, dicom], r1\.2\.840\.\d, 3), ] LEVEL_NAME {1: 公开, 2: 内部, 3: 敏感, 4: 核心} dataclass class Column: table: str name: str samples: list field(default_factorylist) # 已脱敏样本不给原文 def classify(col: Column): for label, keys, pattern, level in RULES: name_hit any(k in col.name.lower() for k in keys) val_hit any(re.search(pattern, str(s)) for s in col.samples if s) if name_hit or val_hit: return {table: col.table, column: col.name, type: label, level: LEVEL_NAME[level], by: 字段名 if name_hit else 内容} return {table: col.table, column: col.name, type: 未命中, level: 公开, by: -}RULES里每项四个位置参数分别是敏感类型名、字段名匹配关键词、内容正则和定级name_hit和val_hit是或关系任一命中就定级命中的判据会写进结果方便复核。级别用中文名输出是为了直接喂给后面的策略表不用再做一次映射。采样值必须先用上一节的脱敏函数处理过再传进来否则脚本自己就是一条泄露通道。2.3 加密与脱敏的选型算法、密钥、性能的三角平衡医院里没有全库加密这种选项。PACS 一天几百 GB 影像、HIS 高峰期每秒上千笔事务全库 TDE 一开磁盘 IO 直接顶满挂号就要排队。通用做法是分层传输统一 TLS核心字段做字段级加密海量影像和日志用文件级或者卷级加密密钥统一放密码机或密钥管理系统。算法适用位置相对开销说明AES-256-GCM字段级加密、接口出参1.0有硬件指令加速通用性最好SM4-GCM需要国密合规的存量改造略高于 AES分组长度同为 128 位软实现要实测SM3 / HMAC-SHA256完整性校验、检索令牌低不可逆不能当加密用SM2 / RSA-2048密钥封装、签名高只用于包密钥和验签别拿来加密业务字段# crypto_field.py —— 字段级加密密钥从密钥管理系统取 import os, base64 from cryptography.hazmat.primitives.ciphers.aead import AESGCM def load_key(key_id: str) - bytes: # 禁止硬编码DEK 由 KMS 下发到进程环境只驻留内存 return bytes.fromhex(os.environ[fDEK_{key_id}]) def encrypt_field(plain: str, key_id: str, aad: bytes) - str: nonce os.urandom(12) # GCM 推荐 96 位随机数 ct AESGCM(load_key(key_id)).encrypt(nonce, plain.encode(), aad) return v1:{}:{}.format(key_id, base64.b64encode(nonce ct).decode()) def decrypt_field(token: str, aad: bytes) - str: ver, key_id, blob token.split(:) # ver 预留算法轮换位 raw base64.b64decode(blob) return AESGCM(load_key(key_id)).decrypt(raw[:12], raw[12:], aad).decode()aad传表名.列名作用是绑定密文归属把 patient 表的密文挪到别的列上解密会直接失败能防住跨字段重放。nonce每次随机生成绝不复用密文前缀带版本号和key_id是为了将来轮换密钥时能共存两代密文不用一次性全量重加密。密文会比明文长 40% 左右改字段长度时预留余量否则上线当天就会撞上 varchar 截断。3. HIS/LIS/PACS 数据安全改造的实操路径3.1 数据库最小权限与三权分立怎么落到 SQL医院数据库权限失控的典型症状是业务账号拥有 DBA 权限因为早期部署时图省事。三权分立的落地方式是把系统管理员、安全管理员、审计管理员拆成互斥角色谁都不能同时具备建表、授权和看审计日志三项能力。-- PostgreSQL三权分立 业务账号最小权限 CREATE ROLE db_admin LOGIN PASSWORD x1; -- 只管建表、调优 CREATE ROLE sec_admin LOGIN PASSWORD x2; -- 只管授权 CREATE ROLE audit_admin LOGIN PASSWORD x3; -- 只读审计日志 CREATE ROLE his_app LOGIN PASSWORD x4; -- 业务账号 GRANT CONNECT ON DATABASE hisdb TO his_app; GRANT USAGE ON SCHEMA public TO his_app; GRANT SELECT, INSERT, UPDATE ON patient, visit, orders TO his_app; REVOKE DELETE ON patient FROM his_app; -- 患者主索引禁止物理删除 -- 审计日志只给审计员反过来把 DBA 的读权限收回 GRANT SELECT ON audit.pg_audit_log TO audit_admin; REVOKE ALL ON audit.pg_audit_log FROM db_admin;REVOKE DELETE这条容易被忽略。医院数据被删的后果比被读更严重患者主索引、医嘱、检验结果都应该是逻辑删除加状态位物理删除权限只保留给归档流程的专用账号。MySQL 侧对应的是审计插件或者general_log加外部采集general_log开销大只适合临时排查长期跑建议用企业版审计或者中间件层记录。给完权限后用\dp或者查询information_schema.role_table_grants导一遍基线以后每次变更都跟基线比对。3.2 存量患者数据加密迁移怎么做到不停机存量数据的加密改造是整件事里风险最高的一步HIS 不允许长时间停写。稳妥的做法是六步走加影子列、代码双写、历史回填、密文校验、切换读路径、最后删原列。全程原列仍在任何一步出问题可以立刻回滚到明文读。3.2.1 回填批大小、锁等待与失败重试的参数设置回填脚本的本质是给一张大表做逐行 UPDATE批大小和休眠时间是两个必调参数。单批 500 到 2000 行比较合适太小跑不完太大容易把长事务拖到分钟级阻塞挂号写入。每批之间sleep 0.05到0.2秒让 WAL 和主从复制跟上。# backfill.sh —— 分批回填可中断可重跑 BATCH1000 while true; do # 只取还没加密的行id 用主键游标避免 OFFSET 越翻越慢 ROWS$(psql -d hisdb -tAc SELECT id FROM patient WHERE id_card_enc IS NULL AND id ${LAST_ID:-0} ORDER BY id LIMIT ${BATCH}) [ -z $ROWS ] break psql -d hisdb -c SELECT enc_backfill($ROWS) # 存储过程内做加密回写 LAST_ID$(echo $ROWS | tail -1) # 观察锁等待超过 3 秒就放慢节奏 WAIT$(psql -d hisdb -tAc SELECT count(*) FROM pg_locks WHERE NOT granted) [ $WAIT -gt 0 ] sleep 1 || sleep 0.1 done用主键游标而不是OFFSET是因为在千万行的表上翻页到后面时OFFSET会退化成全表扫描越跑越慢。每批结束查一次pg_locks里未授予的锁有阻塞就自动降速这是防止业务侧超时的便宜保险。回填完成后跑一遍一致性校验把密文解密回明文跟备份里的原值做哈希比对统计不一致行数结果为 0 才能进入切读阶段。3.3 PACS 影像与对外接口的数据防泄漏PACS 的泄露面主要在两个地方影像文件本身带着患者姓名和检查号DICOM 头里对外提供的查询接口把整个患者对象原样返回。影像文件建议在归档层做卷级加密DICOM 头里的身份字段在导出时重写接口层则统一走脱敏装饰器。# desensitize.py —— 接口出参脱敏 from functools import wraps MASKERS { id_card: lambda v: v[:6] ******** v[-4:], phone: lambda v: v[:3] **** v[-4:], name: lambda v: v[0] * * (len(v) - 1), } KEY_TYPE {id_card: id_card, phone: phone, patient_name: name} def walk(node): if isinstance(node, dict): out {} for k, v in node.items(): if k in KEY_TYPE and v: # 命中敏感键就打码 out[k] MASKERS[KEY_TYPE[k]](str(v)) else: out[k] walk(v) return out if isinstance(node, list): return [walk(i) for i in node] return node def masked(*nodes): def deco(fn): wraps(fn) def wrapper(*a, **kw): data fn(*a, **kw) return {k: (walk(v) if k in nodes else v) for k, v in data.items()} return wrapper return deco masked(patient) # 只脱敏 patient 节点医生端内部字段保持原样 def get_patient(pid): return {patient: {patient_name: 张三, id_card: 110101199001011234, phone: 13800001111}, visit: {dept: 心内科}}KEY_TYPE把外部字段名映射到打码器改字段名只要改这张表不用动walk的递归逻辑。masked的入参决定脱敏哪几个节点这样同一份数据给院内医生看和给第三方对账看可以挂不同的装饰器而不是写两套接口。脱敏必须做在服务端出口前端隐藏字段毫无意义抓一下响应包就全出来了。4. 数据安全风险评估与常态化运营怎么搭4.1 资产-威胁-脆弱性三要素打分数据安全风险评估不是每年填一次表就完事得有一套能重复跑的量化口径否则一次评估一个分数没法纵向对比。常用的做法是按资产、威胁、脆弱性三个维度打分风险值等于可能性乘影响都取 1 到 5 的整数。资产数据类型威胁脆弱性可能性影响风险值HIS 主库患者身份加诊疗内部越权导出权限过大、无审计4520预约挂号接口身份、联系方式外部批量爬取无频次限制4312PACS 归档影像及 DICOM 头运维误拷贝无外发管控248科研导出库去标识化病历二次识别脱敏不彻底3412风险值 15 以上进整改清单10 到 14 进观察清单并设定复查日期10 以下记录留档。这张表每季度重算一次重点看可能性这一列有没有变化——权限收紧了、审计上线了可能性就该往下调不然整张表很快失去参考价值。4.2 数据库审计日志的采集与异常查询告警等保三级要求审计记录留存不少于 6 个月医院一天的数据库审计日志量在千万行量级直接堆在一张表里半年后连按时间查都费劲。采集侧用 pgAudit 或者数据库审计设备落库侧按月分区老分区做压缩归档查询走分区裁剪。# audit_anomaly.py —— 审计日志异常检测 import re from collections import defaultdict # 审计设备导出的行时间 账号 库 返回行数 SQL LINE re.compile(r^(?Pts[\d\-] [\d:.])\s(?Puser\S)\s r(?Pdb\S)\s(?Prows\d)\s(?Psql.)$) BIZ_USERS {his_app, lis_app, pacs_app} def load(path): for ln in open(path, encodingutf-8): m LINE.match(ln.strip()) if m: r m.groupdict() r[rows] int(r[rows]) r[hour] int(r[ts][11:13]) yield r def detect(rows): alerts, cnt [], defaultdict(int) for r in rows: cnt[r[user]] 1 # 规则一凌晨单次返回超过 5 万行疑似批量拖库 if 0 r[hour] 6 and r[rows] 50000: alerts.append((夜间批量读取, r[user], r[rows])) # 规则二非业务账号碰患者表疑似越权或运维操作 if r[user] not in BIZ_USERS and patient in r[sql].lower(): alerts.append((非业务账号访问患者表, r[user], r[sql][:60])) # 规则三单账号出现次数过高疑似自动化遍历 for u, c in cnt.items(): if c 200: alerts.append((高频访问, u, c)) return alerts三条规则的阈值都要按自己医院的基线调。比如夜间批量读取如果医院本身有凌晨的批量结算任务那条规则天天误报就得把biz_users里的结算账号排除或者把行数阈值提到实际峰值的 1.5 倍。告警只推给安全管理员不推 DBA避免权限混同。4.2.1 日志留存六个月的存储与检索方案按天分区保留最近 30 天在线可查30 天到 180 天转冷存压缩超过 180 天按制度销毁并留销毁记录。建分区表时用PARTITION BY RANGE (log_time)查询侧必须带上时间条件否则分区裁剪失效一条查询能扫半年数据。审计日志本身也是敏感数据谁都读等于没审计读取权限只给审计管理员。4.3 备份恢复演练的验证脚本与 RTO/RPO 记录备份没做过恢复演练等于没有备份。等保测评要的是恢复演练报告和 RPO/RTO 实测值不是备份策略截图。下面这个脚本每月跑一次把恢复耗时和关键表行数直接输出成证据。#!/bin/bash # restore_check.sh —— 每月恢复演练产出 RPO/RTO 证据 set -euo pipefail BACKUP_DIR/backup/hisdb TARGET$(ls -t ${BACKUP_DIR}/*.dump | head -1) # 取最新全量备份 echo RPO(小时)$(( ( $(date %s) - $(stat -c %Y $TARGET) ) / 3600 )) START$(date %s) pg_restore -d hisdb_restore -j 4 --clean --if-exists $TARGET # -j 按 CPU 核数给 END$(date %s) for t in patient visit orders; do # 抽查关键表行数 echo ${t}: $(psql -d hisdb_restore -tAc select count(*) from ${t}) done echo RTO(秒)$(( END - START ))RPO用备份文件时间戳到当前时间的差值算直观反映最坏情况下会丢多少数据RTO只算恢复本身耗时不含决策和审批时间写进报告时要注明口径。抽查行数必须跟生产库当天的快照比对行数对不上说明备份链里有增量丢失比恢复失败更危险因为它不会报错。5. 等保测评前两周的自查技巧与高频扣分项测评前两周不要再去改架构改动带来的风险远大于多拿的那两分。这时候该做的是把已有措施跑通一遍、留下可演示的证据。最省事的自查办法是写一组一票否决检查每条对应一条命令跑完截图归档。下面这几条是医院场景里被扣分最多的。检查项核查方式期望结果敏感字段是否还有明文正则扫表见下方 SQL命中数为 0业务账号是否越权导出role_table_grants比对基线无 DELETE、无 DDL审计日志是否可检按患者 ID 反查操作记录能返回完整时间线备份是否可恢复抽查一份备份恢复到测试库行数与生产一致默认口令是否清理核对数据库、堡垒机、设备账号无出厂口令明文扫描这条最实用加密改造做没做到位一条 SQL 就能看出来。-- 扫描 patient 表残留明文加密后的密文带 v1: 前缀不会命中正则 SELECT count(*) AS plain_cnt FROM patient WHERE id_card ~ ^\d{17}[\dXx]$ OR phone ~ ^1[3-9]\d{9}$; -- 期望 0大于 0 说明还有存量明文回填脚本没跑完或漏了列如果这条查出来不是 0先别急着重新跑全量回填先按列统计分布GROUP BY一下看是某些科室的数据没覆盖还是某一批任务中断在半路定位到批次再续跑比全量重来省几个小时。另外两个高频扣分点容易被忽视。一是密钥管理和数据放在同一台机器上加密等于没加密钥至少要落到独立的密码设备或者独立管理节点。二是审计日志的时间没跟 NTP 对齐几台设备时间差几分钟事件时间线就对不上测评现场演示时会很难看提前把数据库、操作系统、审计设备的时钟源统一。把这些检查项做进月度巡检脚本每次跑完自动归档测评时直接调历史记录比临时补材料省事得多。本文还有配套的精品资源点击获取
