首页 / 资讯中心 / 文章详情

医院网络安全建设规划:从资产梳理到主动防御

医院网络安全建设规划:从资产梳理到主动防御 ★ FEATURED ARTICLE
简介《医院网络安全建设规划》是一份针对医疗机构信息安全整体规划的完整方案文档适合医院信息科人员、网络安全工程师及医疗信息化项目管理者参考。内容依据等级保护基本要求围绕设计原则、网络结构分析、业务系统分析、等保建设流程及安全风险需求等模块展开涵盖访问控制、防火墙与入侵检测、数据备份恢复等落地策略并附有清晰目录结构便于直接套用或裁剪。资源为单个docx文件大小121KB虽体量不大但胜在层级完整、要点密集。目前已有1334人学习下载适合正在推进医院网络安全合规建设或需要编写类似规划方案的读者借鉴。1. 医院网络安全建设规划先回答“建什么”再谈“怎么建”医院网络安全建设规划最容易被理解成“买设备、装盒子”。我参与过多家医院的安全整改真正的问题从来不是设备数量而是规划顺序先看清网络是什么结构、哪些资产在跑、谁在访问、出了事能不能恢复再谈部署什么安全产品。这篇笔记按“理解现状→架构设计→分阶段落地→避坑→进阶运营”的顺序展开适合正在做等保整改、新院区网络建设或安全事件复盘的信息科、安全工程师和项目经理参考。规划的价值不在方案多厚而在每一步都能对上业务和预算。2. 先摸清家底医院网络为什么不能照搬企业安全方案2.1 医院网络的三重复杂度业务系统、设备、人员医院网络与企业办公网最大的区别是业务系统的不可中断性。挂号、缴费、医嘱、影像调阅这些系统一旦中断直接影响诊疗流程。HIS、LIS、PACS、EMR是核心它们之间还有大量接口检验申请、报告回传、计费联动。任何一个环节出问题临床科室的反馈速度比什么都快。设备维度更特殊。除了常规的PC工作站和打印机病房里有输液泵、监护仪、呼吸机、血液透析机这些设备大多嵌着嵌入式系统有的连密码都不能改有的系统版本停更多年。它们以前是“孤立设备”现在越来越多通过网口或无线接入医院内网成为安全建设里最容易漏掉的部分。人员维度同样复杂医生、护士、行政人员、药剂师、影像技师外网使用习惯各不相同。还有一类是外部接口人员包括医保链路、上级卫生平台、第三方检验机构的数据交换。这么多角色在一个网络里跑安全边界画在哪里、访问规则怎么定就不是一套办公网模板能套用的事了。在医院做过一次资产盘点后我才发现光一个病区就能找出五六种不同厂商的物联网终端很多设备连管理员都不知道联网了。这就是医院网络安全建设难的第一层不是不想管是根本不知道网里到底有什么。2.2 合规基线从哪里来等保、数据安全法、电子病历规范医院网络安全规划绕不开合规。目前对医院最直接的要求是网络安全等级保护等保大型综合医院的核心业务系统一般按三级定级。注意二级和三级的差距不只是测评项数量而是“纵深防御”的要求三级要求入侵防范、安全审计、集中管控还有异地备份和灾难恢复。数据安全方面医疗健康数据属于敏感个人信息数据安全法和个人信息保护法对收集、存储、传输、使用都有约束。电子病历应用管理规范也要求对病历数据的访问留痕、修改可控。这些合规要求落到技术上就是日志要留存、访问要审计、数据要加密、备份要有效。等保三级在技术层面核心是五块安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心。落实到医院场景物理环境对应机房和弱电间管理通信网络对应加密和带宽保障区域边界对应防火墙和访问控制计算环境对应主机加固和终端防护管理中心对应日志平台和集中运维。规划时把这五块映射到具体设备和制度才不会漏项。等保层面医院主要落地点典型风险安全物理环境机房、弱电间、UPS、门禁弱电间开放任何入室维护不用登记安全通信网络骨干链路、跨院区专线关键链路无冗余单点故障全断安全区域边界防火墙、WAF、访问控制策略分区不彻底HIS和办公网直通安全计算环境服务器加固、终端EDR、数据库审计补丁滞后默认口令留存安全管理中心统一日志平台、集中监控、堡垒机日志分散告警无人看合规和安全的边界经常被混淆。我的判断是合规是底线不是天花板。通过等保测评只说明你满足了基本要求不代表安全建设“做完”了。很多医院通过等保测评后把安全投入停了第二年再评测时发现新增的物联网设备根本不在保护范围内系统漏洞也早已积压。所以我更愿意把等保看成规划的起点而不是终点。3. 医院网络安全架构分区、边界、准入三层一起定3.1 网络分区把HIS、办公、外联、物联网设备分开跑常见分区做法是六类核心业务区HIS、EMR、数据库等、影像存储区PACS大流量、办公区、外联区医保、卫生平台专线、互联网服务区官网、挂号平台后端、物联网设备区。分区之间用防火墙做策略隔离默认只放行业务必需的端口。我一般建议核心业务区内部再细分应用服务器和数据库服务器至少要分在两个网段。常见翻车案例是Web服务器和数据库在同一个区域攻击者拿到Web权限后内网数据库等于裸奔。下面是一段用常见防火墙命令行做分网段策略控制的示意生产环境里各品牌产品的语法不同但你只需要理解背后的最小权限逻辑# 网段定义示意 # 核心业务区应用段10.1.0.0/24 # 核心业务区数据库段10.1.1.0/24 # 办公区10.2.0.0/16 # 物联网设备区10.8.0.0/16 # 仅允许办公区访问应用服务器的 HTTP/HTTPS 端口 firewall-cmd --permanent --zonecore_app --add-source10.2.0.0/16 firewall-cmd --permanent --zonecore_app --add-servicehttps firewall-cmd --permanent --zonecore_app --add-servicehttp # 仅允许应用服务器访问数据库段的 1433、1521 端口 firewall-cmd --permanent --zonecore_db --add-source10.1.0.0/24 firewall-cmd --permanent --zonecore_db --add-rich-rulerule familyipv4 source address10.1.0.0/24 port port1433 protocoltcp accept firewall-cmd --permanent --zonecore_db --add-rich-rulerule familyipv4 source address10.1.0.0/24 port port1521 protocoltcp accept firewall-cmd --permanent --zonecore_db --set-targetREJECT firewall-cmd --reload这段配置的逻辑很简单办公区只能到应用服务器的网页端口应用服务器只能到数据库的两个业务端口其它访问全部丢弃。核心参数是端口和来源网段1433是SQL Server默认端口1521是Oracle默认端口医院HIS后台数据库最常见就是这两类。刻意把数据库段默认目标设为REJECT而不是ACCEPT是为了保证“没写放行的都不通”。PACS影像区比较特殊。影像调阅的特点是流量大、延迟敏感如果在这条链路串联深度检测设备很容易成为瓶颈。常见做法是对PACS区做ACL白名单控制限制只有特定科室网段能访问影像服务器不做内容深度检测。这是“业务优先”和“安全可控”的折中。3.2 边界防护与访问控制最小化原则的落地姿势医院互联网出口是最容易被突破的位置。挂号、缴费、互联网医院的业务都暴露在公网上这里不是放一台防火墙就完事。Web业务前端要单独部署WAF重点拦SQL注入、越权访问、恶意扫描出口防火墙只放行必要端口并启用入侵防御模块。办公区对外访问的管控也是痛点。常见做法是部署上网行为管理设备按角色设定访问策略医生可以访问医学文献站点行政人员只放开办公必需站点全院统一封禁高风险下载站和未知应用下载。策略制定时建议让临床科室提需求而不是安全工程师自己拍脑袋否则后面必定被绕过。远程接入场景是另一个重点。疫情之后不少医院允许医生在家调阅影像、审核报告这类远程访问直接暴露到公网风险很高。我建议不要老想着开端口映射而是用“接入网关”方式外部设备必须先完成身份校验、确认终端合规才进入内网。不要给任何个人终端发放长期的、超高权限的通道这是血泪经验换来的。3.3 终端安全与准入医护工作站和医疗物联网设备谁都不能漏终端是医院安全建设最容易见效的一层。医护工作站数量多、使用时间长、U盘使用频繁补丁经常因为业务不能中断而拖欠。常见做法是部署统一终端管理系统把杀毒、补丁、外设管控收在一套平台里。更关键的是准入控制设备接入网络时必须通过身份校验和安全状态检查没装杀毒、补丁严重缺失的终端先隔离再修复。医疗物联网设备怎么管这部分最像黑匣子系统不开放、端口搞不清楚、漏洞通报都查不到。常见做法是给物联网设备规划独立VLAN分段后加白名单策略。比如输液泵业务只需要和数据采集服务器通信那就只放行这一个目标IP和端口。注意很多老设备不支持802.1X认证也没有可安装的终端安全客户端。应对办法是给这些设备单独划一个“例外网段”网段里只允许管理员手动登记的MAC地址上线通过接入交换机的端口安全特性限制端口只能通过指定设备。这样既兼容老设备又不至于让整个物联网区变成不设防区域。4. 分阶段实施路线从摸底、加固到监测和数据恢复4.1 先做资产梳理与基础加固清理账号、补丁与弱口令第一步是资产梳理。别相信之前的台账我做过的项目里旧台账和实际网络的出入程度几乎每次都出乎意料。用扫描工具结合科室访谈把每个网段的存活主机、开放端口、操作系统版本摸一遍。首次扫描建议避开业务高峰选择凌晨执行避免对老旧设备造成压力。# 资产发现示例扫描指定网段的开放端口与服务版本 nmap -sS -sV -O 10.8.0.0/16 -p 1-10000 -oX iot_assets.xml --open参数说明-sS是SYN半开扫描速度快且对目标主机的连接日志影响小-sV做服务版本探测帮你看清设备开了什么服务-O做操作系统指纹识别适合分辨打印机、网关类和PC类设备--open只输出开放的端口减少噪音。扫描结果导出为XML后续可以直接导入资产管理系统比Excel手工登记省事。资产清单建立后基础加固的优先级是清理默认账号、清除弱口令、关闭不必要的远程管理端口、统一补丁策略。补丁切忌一把梭数据库和PACS这类核心系统必须先在一台测试机验证再灰度观察最后窗口期升级。系统类型测试周期灰度观察全量时间回滚预案数据库HIS/Oracle5个工作日3天双休日凌晨升级前保留完整镜像与备份应用服务器Web/接口3个工作日2天工作日晚间保留上一个发布版本包终端工作站1个工作日1天分批推送卸载补丁或恢复系统还原点这张表是我们每次做加固都用的节奏关键是回滚预案先写好再动手。别到了凌晨一点发现业务起不来才翻安装包后悔药在这行基本不存在。4.2 再补监测与响应日志、流量与终端告警怎么串联资产清完、加固做完之后第二步是解决“看不见”的问题。医院网络里安全设备再多如果日志散落在各个盒子里不汇总告警就永远不会被看到。我一般建议先搭统一日志平台把防火墙、服务器安全日志、数据库审计日志集中收集再配合流量探针做双向流量检测。日志集中之后分析能力是瓶颈。安全团队往往没有专职人员盯着屏幕那就先做条件告警登录失败次数、异常端口扫描、非工作时间的访问行为这些都是基础指标。下面这段脚本的思路很简单用Python统计安全日志里登录失败的来源IP超过阈值自动打印告警适合每天早晨的例行巡检。# 登录失败集中分析从安全日志中快速发现暴力破解来源 import re from collections import Counter log_file /var/log/his_secure.log pattern re.compile(rFailed password.*?from (\d\.\d\.\d\.\d)) with open(log_file) as f: ip_list pattern.findall(f.read()) ip_counter Counter(ip_list) print(登录失败来源 TOP 10) for ip, count in ip_counter.most_common(10): if count 20: # 超过 20 次即触发告警 print(f告警 IP {ip} 失败次数 {count})这段代码的核心就是正则找到失败登录来源IP用Counter按次数统计阈值可以根据内网规模自行调整。医院内网几百个终端的话单IP失败超过20次基本可以判定为扫描或暴力破解。脚本不需要多高大上能每天自动跑一遍、把结果推到值班群就比装一堆没人看的SOC大屏管用。流量监测层面建议在核心交换机上做端口镜像把流量引到检测设备。目的是看清东西向流量里的异常行为一台工作站在凌晨大量访问数据库服务器的1433端口说明大概率已经有问题。主机层面部署EDR重点监测命令执行、内存注入、勒索行为特征医疗行业近年翻车最多的就是勒索加密EDR对这种攻击的拦截率远高于传统杀毒软件。4.3 最后夯实数据保护与恢复力备份、恢复与灾难演练安全建设的最后一块拼图不是“防得住”而是“坏了能回得来”。医院的核心数据全部集中在数据库和影像系统里备份策略至少要覆盖三块HIS数据库、EMR数据库、PACS影像数据。备份要分三份本地一份、异机一份、异地一份这句口诀写进制度里都不会错。备份最容易出的问题是任务状态显示成功但恢复时数据不可用。因此备份系统一定要配自动校验定期做恢复测试。下面这段Shell脚本是我常用的备份完整性检查思路#!/bin/bash # 数据库备份完整性检查检查文件是否存在并判断大小是否符合预期 BACKUP_FILE/backup/his_db_$(date %F).bak MIN_SIZE1073741824 # 1GB 为最低预期阈值按实际业务调整 if [ ! -f $BACKUP_FILE ]; then echo $(date) 备份缺失 /var/log/backup_check.log exit 1 fi SIZE$(stat -c%s $BACKUP_FILE) if [ $SIZE -lt $MIN_SIZE ]; then echo $(date) 备份文件异常大小 ${SIZE} 字节 /var/log/backup_check.log exit 1 fi echo $(date) 备份文件存在大小 ${SIZE} 字节校验通过 /var/log/backup_check.log脚本逻辑很直白检查昨天的备份文件在不在、大小是否低于预期阈值。MIN_SIZE要参考历史备份实际大小设置设置得太小等于没检查设置得太大又容易误报。生产环境里建议把脚本加入crontab每天执行结果单独保留不仅自己看测评时也能拿出来当整改证据。数据恢复力提升的关键动作是每季度选一个核心系统做完整恢复演练不要每次都选同一个系统。我一个同行跟我说过他们的教训连续两个季度都拿测试库做恢复演示结果真出事了PACS恢复流程走不通业务停了六个小时。灾难恢复的路径只有真的跑过一遍才知道通不通。5. 医院网络安全建设避坑指南五条高频踩坑记录5.1 坑一安全设备买完就“透明化”策略没人维护现象防火墙、WAF、日志审计都装了打开配置一看规则全部是ALLOW ANY设备日志里只有上线告警没有攻击日志。安全设备在网络上“透明”地跑着形同虚设。原因采购阶段只看品牌和预算上线阶段没有明确策略负责人。厂商实施完就算交差医院信息科没人能维护策略默认“不挡业务”的宽松配置最安全。解决在项目验收时把“策略配置清单”作为交付物明确每一条放行规则的责任人、有效期和备注。每季度做一次策略复查把三个月内没有命中记录的规则清理掉。另外要求厂商在交付时做一次攻击模拟验证证明设备真的能拦。5.2 坑二准入太严临床科室用脚投票绕过安全现象护士站打印机的IP变了因为老设备不支持准入认证被交换机的端口安全策略阻断。护士长直接拔掉安全设备的网线或者找厂商人员偷偷把准入策略关闭。最终安全团队一次巡检才发现某个区域的准入功能已经离线几周。原因准入策略一刀切没有区分台式机、打印机、医疗设备的不同能力。老设备不支持的协议强行套用导致业务中断一线的第一反应就是绕过。解决先按设备类型划分等级支持客户端的终端走完整准入流程打印机和老设备走MAC白名单例外通道。准入上线前在医院信息科内部模拟重跑一遍业务流程让护士长、收费处、药房这些关键岗位签字确认。宁可多花一周做兼容性测试也不要上线当天翻车。5.3 坑三备份任务天天成功恢复时才发现是假数据现象某医院系统故障后DBA抱着备份磁带准备恢复发现备份文件只有几十KB数据库备份其实是“截断日志”的产物根本不完整。原因备份软件定时任务写的是“备份成功”就算完但没人检查备份内容的完整性。数据库的完整备份、差异备份策略配置错误又没有做恢复验证问题就被掩盖了。解决每周自动校验备份文件大小和可还原性每季度做一次正式恢复演练演练记录存档。恢复演练不要只起一个实例看能不能起来要实际查询关键表的数据量对照生产库做一致性比对。5.4 坑四医疗物联网设备成了漏网的黑匣子现象内网流量监测显示某病房区的监护仪在非业务时间段向外部IP发起大量连接。排查后发现是设备厂商在设备里内置了远程维护模块而该设备的网段根本没有出网管控。原因设备科采购医疗设备时只看临床功能不评估网络安全风险。物联网设备自身没有防护能力接入网络后既没人登记也没人监测。解决在设备采购环节增加信息安全评估表要求厂商提供设备开放端口、通信目标地址、是否存在后门账号等说明。上线前由信息科做一次协议分析确认设备只和院内服务器通信不需要访问外网的设备一律在防火墙上禁止出网。5.5 坑五应急预案写得漂亮实战演练全员发懵现象应急预案文档里写着“感染勒索病毒后断网、上报、恢复”但真到演练时没人说得清该断哪台交换机、备份在哪台机器上、值班电话打给谁。整个应急流程拖了40分钟才启动。原因预案停留在“流程指导”层面没有落到具体执行人、具体设备IP、具体备份路径。信息科分工模糊安全厂家、网络管理员、系统管理员各自为战。解决把预案里的“相关责任人”改成“姓名电话备用电话操作手册”的三位一体。把关键动作做成一张A4卡片打印后贴在机房和值班室第一步断哪些IP段、第二步通知谁、第三步从哪里拉起备份。每半年做一次全员参与的桌面推演让每个人都熟悉自己的动作。6. 从合规达标到主动防御日常运营的三件小事医院安全建设落地以后最难的不是建设而是维持。把安全从“项目”变成“日常”我建议先做好三件事。第一件每周固定做一次漏洞扫描与结果复盘。扫描工具可以很便宜甚至可以开源关键是有人看结果。把每次扫描发现的新漏洞分成“必须修”“可以等”“仅记录”三档必须修的漏洞在两周内闭环。不要求清零但要求每周下降。第二件每月做一次攻击面复盘。把防火墙策略变更记录翻出来看看这个月新增了哪些放行规则是不是每次都有业务申请单对应。没有对应申请单的规则一律列为清理对象。这是防止策略反复“开大口”的有效办法。第三件每季度做一次小规模攻防演练。不用追求复杂剧本就从最简单的开始模拟一台办公终端被钓鱼、模拟HIS数据库被暴力破解。演练的核心不是防守方能不能赢而是流程能不能跑通、告警有没有人响应、响应时间是多少。我记得有一次在和一家医院信息科的同行交流时他说过一句话安全运营的成败往往不是看设备多贵而是看出了问题之后团队是能在半小时内定位到源头还是花一天时间互相打电话。后来我把这句话变成了自己衡量安全建设效果的标尺。每次做完一个项目的规划和落地我都会问团队一个问题现在如果有一台工作站中毒了我们能在多久内发现、定位并处置如果答案是模糊的那就说明建设还没收尾。安全运营不是依赖某一次爆发性的整改而是靠这些不起眼的日常动作一点点把底子养厚希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?
咨询建站