2026/9/20 1:09:59
FEATURED · 精选文章 
简介医院网络与信息系统安全自查工作报告是一份面向医疗机构信息科人员、安全管理员和审计人员的实用文档模板。内容围绕HIS服务器机房安全、卫生专网IP及存储介质管理、工作电脑病毒查杀三条主线展开并附有自查结果记录和整改建议可帮助读者快速掌握基层医院信息安全自查的完整框架与执行要点。文件包内仅包含1个doc文档大小56KB报告正文可直接参考适合用于撰写自查材料、开展安全培训或对照检查本单位安全现状。目前已有97人学习浏览。报告中不仅梳理了机房消防、用电、硬件、软件、门窗等检查维度也指出信息技术人员不足、培训不全面、应急演练不够、设备老旧等常见短板并给出增设人员、加强安全教育和升级硬件等改进思路整体具有较强的借鉴性和可操作性。1. 医院安全自查到底在查什么医院信息科每年都会收到不止一次“网络与信息系统安全自查”的通知有时来自卫健委有时来自公安网安部门有时是等保测评前的预检。多数人第一反应是写一份报告交差但真正的问题从来不是“怎么写”而是“查什么、按什么标准查、查完怎么办”。自查报告不是给领导看的文字材料而是给下一轮整改用的行动清单——这个定位想清楚整份报告的结构和内容就自然出来了。常见做法是先划边界再分域核查最后定级整改。整个流程里最花时间的不是写报告而是把资产台账摸清、把网络拓扑核对一遍、把主机和应用的日志翻出来看。这篇就按实际操作路径讲从检查依据、资产梳理、分域检查、风险定级到整改闭环覆盖一套可以直接拿去用的自查方法。2. 自查依据与范围先划定边界再动手2.1 从政策清单反推检查范围医院的自查不是凭空想象而是有明确的政策依据。常见的检查来源包括网络安全等级保护制度、数据安全法和个人信息保护法里涉及医疗数据的要求以及卫健委对医院信息化建设的相关规范。实际操作中绝大部分自查通知都会附一份检查要点表这张表就是整个自查工作的“考纲”。拿到检查要点后我一般会做一件事把检查项逐条拆解并映射到具体的信息系统上。比如“是否建立数据备份机制”对应医院信息系统、电子病历系统、检验信息系统“是否具备入侵防范能力”对应网络边界防火墙和入侵检测设备“是否对操作行为进行审计”对应数据库审计和运维审计系统。这一步的价值在于它能帮你在动手检查前先明确“查哪些系统、查哪些方面”避免检查时东一榔头西一棒子。特别是医院的信息系统往往多而杂从医院信息系统、电子病历系统到医学影像系统、检验信息系统不同系统的责任科室和安全要求都不一样逐条映射后才能形成一份可执行的检查计划。2.1.1 自查范围清单示例系统名称责任科室部署位置等保级别涉及数据检查重点医院信息系统信息科中心机房三级患者基本信息、费用数据账号权限、日志审计、备份恢复电子病历系统信息科/医务科中心机房三级病历文书、诊疗记录访问控制、数据加密、操作留痕检验信息系统检验科中心机房二级检验数据、质控数据接口安全、数据一致性医学影像系统放射科中心机房二级影像文件、报告存储安全、传输加密2.2 资产台账是自查的第一张表没有资产台账就没有自查。医院的信息资产种类很多服务器、终端、网络设备、安全设备、数据库、中间件、业务系统、移动终端都算。很多医院的信息科平时忙于处理日常故障资产台账常常停留在“大概知道有什么”的程度但真正要自查时说不清“这个系统的IP是多少、跑在什么操作系统上、责任人是谁”就很被动。资产台账里的核心字段至少包括设备名称、IP地址、操作系统/版本、所属系统、责任人、部署位置、重要程度。如果连这份表都没有就不能直接跳到漏洞扫描和日志检查否则扫出来的资产对不上业务根本无法判断风险的影响范围。建议用电子表格做第一轮摸底字段设置好后发给各科室确认再由信息科统一复核。复核的关键是“以数据为中心”所有承载患者信息的系统都要单独标识不能混在通用资产里。2.3 网络拓扑与服务清单没有拓扑图就别谈边界有了资产清单下一步是核对网络拓扑图。医院网络通常划分为多个安全域对外服务区、内部办公区、核心业务区、运维管理区。每个区域的边界上部署了防火墙、交换机ACL或安全网关区域之间通过访问控制策略隔离。自查时最重要的一个问题就是现在的流量路径和拓扑图画的是否一致。我见过不少医院的网络拓扑图停留在两三年前新增的服务器直接接在核心交换机上没有经过防火墙或者运维管理区和管理终端之间没有任何访问控制运维人员可以从办公网直接登录生产服务器。这些差异就是边界上的隐患。核对拓扑时除了看线路连接还要看服务清单哪些服务对外暴露、哪些服务只在内部开放、远程运维走的是什么通道。医疗服务对外是常态比如预约挂号、检查报告查询这些服务必须明确暴露面和保护措施。3. 分域核查实操制度、主机、网络、应用四线并行3.1 制度与人员检查记录比制度文本更重要制度检查是最容易流于形式的部分。很多医院都有一套安全管理制度但制度是否落地、是否执行、是否有记录是两回事。自查时重点查的不是制度写得好不好而是以下材料人员入职和离职是否有账号开通和回收记录、是否签署保密协议、第三方运维人员是否有授权和审批流程、安全培训是否定期开展并有签到记录。这些材料的共同特点是“留痕”。没有记录就等于没做这是自查报告里必须明确的判断逻辑。检查项目需要留痕的材料常见缺失账号管理账号开通/变更/注销申请单员工离职后账号未及时回收第三方运维运维工单、授权审批记录、设备进出机房登记远程运维无审批、无录像安全培训培训通知、课件、签到表、考核记录有培训无签到不能证明参训人员应急预案预案文本、演练方案、演练记录、演练总结有预案未演练等于纸上谈兵3.2 主机安全从 Windows 安全日志到补丁核查主机层是自查工作量最大的部分。一台台登录服务器去查不现实常见做法是用脚本批量采集关键信息。基础设施层的主机检查以 Windows Server 和 Linux 为主。Windows 机器的安全日志是最直接的证据来源登录成功/失败记录、账号权限变更、服务安装事件都在里面。用 PowerShell 可以快速导出最近30天的登录日志# 导出最近30天的安全日志中事件ID为4624(登录成功)和4625(登录失败)的记录 $startTime (Get-Date).AddDays(-30) Get-WinEvent -FilterHashtable {LogNameSecurity; StartTime$startTime; Id4624,4625} | Select-Object TimeCreated, Id, {NAccount;E{$_.Properties[5].Value}}, {NLogonType;E{$_.Properties[8].Value}} | Export-Csv -Path D:\security_log_audit.csv -NoTypeInformation -Encoding UTF8这段脚本的核心是用FilterHashtable过滤出登录相关事件4624是登录成功、4625是登录失败。LogonType字段要重点看2表示本地交互登录、3表示网络登录、10表示远程桌面登录。如果大量4625集中在非工作时间或者远程登录来源IP不是运维网段就需要重点关注。导出 CSV 是为了后续拿到电子表格里做条件筛选和数据透视比在事件查看器里翻页高效得多。Linux 主机的检查重点是账号、SSH 配置和补丁情况。一条命令就能同时检查关键项# 查看可登录账号、SSH是否允许root登录、最近安装的安全更新 awk -F: $31000 $7!/usr/sbin/nologin {print $1} /etc/passwd grep -E ^PermitRootLogin|^PasswordAuthentication /etc/ssh/sshd_config rpm -qa --last | head -20第一行是列出 UID 大于等于1000且 shell 不是 nologin 的用户作用是把所有能登录的系统账号暴露出来等保检查时特别关心是否存在无主账号或离职人员未删除的账号第二行看 SSH 是否允许 root 直接登录生产环境要求禁用 root 远程登录第三行看最近安装的软件包记录检查安全补丁是否及时更新。补丁核查在大型医院是硬骨头因为业务不能停凌晨窗口又短。实操上常见做法是核心业务系统的补丁先在测试机验证再到备机上灰度最后切换主备再补主库。自查报告里要如实反映补丁滞后的情况并给出分阶段的整改计划不要写“已全部更新”这不现实也没人信。3.3 网络边界与通信协议用扫描核验访问控制策略网络层的自查不是把防火墙策略导出来看一眼就完事而是要做“策略与实际流量”的对比验证。尤其是对外开放的服务边界要确认边界设备上放行的端口和实际对外提供服务的端口一致。一个简单有效的核验方式是在边界外做端口扫描确认对外开放的端口清单再和防火墙放行策略做对比nmap -sT -Pn -p 445,3389,22,80,443,1433,3306 医院对外IP-sT表示 TCP 连接扫描-Pn跳过主机发现直接扫端口适合检测防火墙是否对探测做了过滤。-p后面罗列的是常见高危端口445是Windows共享、3389是远程桌面、22是SSH、1433和3306分别是SQL Server和MySQL的默认端口。这些数据库和远程管理端口如果出现在外网扫描结果里属于严重问题。医疗行业的信息系统接诊、挂号、查询业务的对外端口通常是443或80其他端口原则上应该全部关闭。内网侧的检查重点是核心业务区的访问控制。常见做法是在核心交换机的镜像端口上做流量采集抓一段时间的数据统计每个业务系统对外通信的端口和协议。如果发现数据库端口在内网里被大量非应用服务器访问说明访问控制粒度太粗——正确做法是只允许应用服务器通过特定端口访问数据库而不是整个网段互通。3.4 应用与数据账号权限、数据库审计、备份恢复三件套应用层自查的核心是“谁能用、能做什么、做了是否留下痕迹”。以电子病历系统为例重点检查动态口令、密码策略、会话超时、权限分级、医生和护士的职责分离。医疗信息系统往往有几十个角色角色权限表要和实际岗位职责对得上不能出现“普通医生拥有管理员权限”这种整条链路的严重风险。数据库审计是最容易出彩的部分。主流的数据库——SQL Server、Oracle、MySQL——都有日志开关自查时先确认有没有开启再确认日志保留周期是否满足6个月要求。以 SQL Server 为例-- 检查SQL Server的登录审计级别和错误日志保留天数 SELECT name, is_login_audit_success_enabled, is_login_audit_failure_enabled FROM sys.dm_server_audit_status; EXEC xp_readerrorlog 0, 1, NLogging, NSQL Server;第一段查询的is_login_audit_success_enabled和is_login_audit_failure_enabled分别表示是否记录登录成功和失败的审计事件。医院的核心业务库通常都要求成功失败都记录只记录失败不记录成功等于不知道谁进来过。第二段查错误日志里的记录情况确认日志覆盖周期足够。备份恢复的检查不是看有没有备份文件而是要看“备份策略”和“恢复验证”。自查时要把备份任务清单拉出来检查备份类型全量、增量、日志、保留周期、备份存储位置是否异地。更关键的是问一个问题上次做恢复演练是什么时候备份不能恢复等于没有备份很多医院的备份恢复演练停留在承诺层面自查报告里要如实写清演练情况并给出当年度的演练计划。4. 隐患定级与报告撰写自查结论不能只有“基本符合”4.1 风险定级矩阵把“有问题”改成“可整改”检查过程中会发现大量问题这些问题不能简单分成“有/没有”而要按严重程度排序否则整改时不知道从哪里下手。常用的是下面的定级矩阵风险等级判定条件响应要求整改时限严重核心业务系统存在漏洞或配置不当可能导致服务中断或数据泄露立即整改1周内高关键安全机制缺失如审计未开启、备份不可用但不是直接可利用的漏洞限期整改1个月内中管理制度或流程缺口如培训记录不全、账号回收不及时计划整改3个月内低操作规范性问题如记录填写不完整日常改进6个月内每个发现的问题都要归入这个矩阵格式用“问题描述 — 发现过程 — 风险等级 — 整改建议”的列表。以第3章的检查结果举例边界扫描发现445端口对外开放就属于严重问题要写清楚“在哪个边界设备上发现、通过什么方式检测、可能造成什么影响、建议在防火墙封禁该端口”这样写出来的报告整改责任人拿到手上就知道下一步做什么。4.2 报告结构自查报告的五段式框架医院安全自查报告没有统一模板但要兼顾“给院领导看结论”和“给整改人员看任务”双重目标五段式是通用性最强的写法自查工作概述说明自查依据、时间范围、参与人员、覆盖范围自查内容与方法按制度、网络、主机、应用四个域说明查了什么、用了什么方法自查发现与风险分析按风险等级列出问题清单重点讲严重和高级别问题整改措施与计划按问题清单逐条对应整改责任人和时限工作建议需要领导层面协调的事项比如资源投入、跨部门配合4.3 证据归档截图、日志、配置备份的保存规范报告写得好不好一半看证据。发现问题的截图、扫描报告、日志导出文件、配置备份都要按“问题编号—证据类型—取证时间”的格式归档并附在提交稿里统一管理。证据归档跟着问题清单编号走每个问题配一个编号如WS-2025-001归档目录里对应一个同名文件夹。配置备份要记录当时的配置文件版本以便整改后做对比并让整改后的 diff 结果一并归档这样整个整改过程的完整链路——问题发现、问题定位、整改操作、复测验证——全都有据可查。5. 自查报告的汇报技巧与整改闭环5.1 用一张整改路线图推进跨部门协作自查报告提交后最常遇到的情况是报告交上去了整改没人管。医院里信息科的话语权有限安全问题靠信息科自己推动很难。所以报告里必须包含一个独立的“整改路线图”部分格式是一张按时间轴排列的表格优先级问题编号整改内容责任科室配合科室计划完成时间当前状态P0WS-2025-001封禁数据库端口外网暴露信息科无2025-04-07未开始P1WS-2025-002补全第三方运维审计记录信息科运维服务商2025-04-30未开始P2WS-2025-003修订账号管理制度并培训信息科人事科/医务科2025-05-31未开始这张表要放进向院领导汇报的版本里逐条说明问题是什么、不整改的风险有多大、需要哪个部门配合、卡点在哪里。写报告时把握一个原则每个问题都写成“需要决策”而不是“需要知悉”。5.2 复测验证整改结果如何留痕整改闭环的最后一步是复测。以 P0 问题为例整改动作是防火墙上封禁端口复测方法是在边界外重新执行同样的端口扫描确认端口已不可达并将前后的扫描结果放在同一份复测报告里做对比。服务器补丁整改复测进入系统确认补丁安装日期和版本号账号权限整改复测从账号管理平台导出角色权限快照做前后对比。复测记录必须有时间、操作人、整改前状态、整改后状态、验证方式这五个要素。常见的一个坑是拿“配置截图”冒充整改结果。配置截图只能说明做到了配置修改不能说明修改生效更说明不了业务未受影响。正确的验证方式是两块一是技术手段验证比如扫描、查询、模拟登录二是业务可用性确认比如由系统使用方在业务侧做一次实际操作验证。5.3 让自查报告变成年度安全运营的起点日常工作里建议每季度做一次轻量自查不再走全量核查而是抽核心业务系统和上次发现的高风险问题做定向复查。年度自查报告不要推倒重写而是以季度记录为基础做汇总这既能减轻工作负担也能防止到了年底想不起前几个月的情况。还有一个容易被忽略的点自查报告里写的整改完成时间要留有余量尤其是涉及采购或跨科室协调的事项按正常估计再放宽两周。如果报告提交后临时有新的整改要求尽量在同一个跟踪表里追加记录而不是另起一份表避免状态不一致。整改闭环的意义在于让下次检查有据可查而不是每年从零开始重新查一遍。本文还有配套的精品资源点击获取
医院网络安全自查实操指南：从资产梳理到整改闭环
简介医院网络与信息系统安全自查工作报告是一份面向医疗机构信息科人员、安全管理员和审计人员的实用文档模板。内容围绕HIS服务器机房安全、卫生专网IP及存储介质管理、工作电脑病毒查杀三条主线展开并附有自查结果记录和整改建议可帮助读者快速掌握基层医院信息安全自查的完整框架与执行要点。文件包内仅包含1个doc文档大小56KB报告正文可直接参考适合用于撰写自查材料、开展安全培训或对照检查本单位安全现状。目前已有97人学习浏览。报告中不仅梳理了机房消防、用电、硬件、软件、门窗等检查维度也指出信息技术人员不足、培训不全面、应急演练不够、设备老旧等常见短板并给出增设人员、加强安全教育和升级硬件等改进思路整体具有较强的借鉴性和可操作性。1. 医院安全自查到底在查什么医院信息科每年都会收到不止一次“网络与信息系统安全自查”的通知有时来自卫健委有时来自公安网安部门有时是等保测评前的预检。多数人第一反应是写一份报告交差但真正的问题从来不是“怎么写”而是“查什么、按什么标准查、查完怎么办”。自查报告不是给领导看的文字材料而是给下一轮整改用的行动清单——这个定位想清楚整份报告的结构和内容就自然出来了。常见做法是先划边界再分域核查最后定级整改。整个流程里最花时间的不是写报告而是把资产台账摸清、把网络拓扑核对一遍、把主机和应用的日志翻出来看。这篇就按实际操作路径讲从检查依据、资产梳理、分域检查、风险定级到整改闭环覆盖一套可以直接拿去用的自查方法。2. 自查依据与范围先划定边界再动手2.1 从政策清单反推检查范围医院的自查不是凭空想象而是有明确的政策依据。常见的检查来源包括网络安全等级保护制度、数据安全法和个人信息保护法里涉及医疗数据的要求以及卫健委对医院信息化建设的相关规范。实际操作中绝大部分自查通知都会附一份检查要点表这张表就是整个自查工作的“考纲”。拿到检查要点后我一般会做一件事把检查项逐条拆解并映射到具体的信息系统上。比如“是否建立数据备份机制”对应医院信息系统、电子病历系统、检验信息系统“是否具备入侵防范能力”对应网络边界防火墙和入侵检测设备“是否对操作行为进行审计”对应数据库审计和运维审计系统。这一步的价值在于它能帮你在动手检查前先明确“查哪些系统、查哪些方面”避免检查时东一榔头西一棒子。特别是医院的信息系统往往多而杂从医院信息系统、电子病历系统到医学影像系统、检验信息系统不同系统的责任科室和安全要求都不一样逐条映射后才能形成一份可执行的检查计划。2.1.1 自查范围清单示例系统名称责任科室部署位置等保级别涉及数据检查重点医院信息系统信息科中心机房三级患者基本信息、费用数据账号权限、日志审计、备份恢复电子病历系统信息科/医务科中心机房三级病历文书、诊疗记录访问控制、数据加密、操作留痕检验信息系统检验科中心机房二级检验数据、质控数据接口安全、数据一致性医学影像系统放射科中心机房二级影像文件、报告存储安全、传输加密2.2 资产台账是自查的第一张表没有资产台账就没有自查。医院的信息资产种类很多服务器、终端、网络设备、安全设备、数据库、中间件、业务系统、移动终端都算。很多医院的信息科平时忙于处理日常故障资产台账常常停留在“大概知道有什么”的程度但真正要自查时说不清“这个系统的IP是多少、跑在什么操作系统上、责任人是谁”就很被动。资产台账里的核心字段至少包括设备名称、IP地址、操作系统/版本、所属系统、责任人、部署位置、重要程度。如果连这份表都没有就不能直接跳到漏洞扫描和日志检查否则扫出来的资产对不上业务根本无法判断风险的影响范围。建议用电子表格做第一轮摸底字段设置好后发给各科室确认再由信息科统一复核。复核的关键是“以数据为中心”所有承载患者信息的系统都要单独标识不能混在通用资产里。2.3 网络拓扑与服务清单没有拓扑图就别谈边界有了资产清单下一步是核对网络拓扑图。医院网络通常划分为多个安全域对外服务区、内部办公区、核心业务区、运维管理区。每个区域的边界上部署了防火墙、交换机ACL或安全网关区域之间通过访问控制策略隔离。自查时最重要的一个问题就是现在的流量路径和拓扑图画的是否一致。我见过不少医院的网络拓扑图停留在两三年前新增的服务器直接接在核心交换机上没有经过防火墙或者运维管理区和管理终端之间没有任何访问控制运维人员可以从办公网直接登录生产服务器。这些差异就是边界上的隐患。核对拓扑时除了看线路连接还要看服务清单哪些服务对外暴露、哪些服务只在内部开放、远程运维走的是什么通道。医疗服务对外是常态比如预约挂号、检查报告查询这些服务必须明确暴露面和保护措施。3. 分域核查实操制度、主机、网络、应用四线并行3.1 制度与人员检查记录比制度文本更重要制度检查是最容易流于形式的部分。很多医院都有一套安全管理制度但制度是否落地、是否执行、是否有记录是两回事。自查时重点查的不是制度写得好不好而是以下材料人员入职和离职是否有账号开通和回收记录、是否签署保密协议、第三方运维人员是否有授权和审批流程、安全培训是否定期开展并有签到记录。这些材料的共同特点是“留痕”。没有记录就等于没做这是自查报告里必须明确的判断逻辑。检查项目需要留痕的材料常见缺失账号管理账号开通/变更/注销申请单员工离职后账号未及时回收第三方运维运维工单、授权审批记录、设备进出机房登记远程运维无审批、无录像安全培训培训通知、课件、签到表、考核记录有培训无签到不能证明参训人员应急预案预案文本、演练方案、演练记录、演练总结有预案未演练等于纸上谈兵3.2 主机安全从 Windows 安全日志到补丁核查主机层是自查工作量最大的部分。一台台登录服务器去查不现实常见做法是用脚本批量采集关键信息。基础设施层的主机检查以 Windows Server 和 Linux 为主。Windows 机器的安全日志是最直接的证据来源登录成功/失败记录、账号权限变更、服务安装事件都在里面。用 PowerShell 可以快速导出最近30天的登录日志# 导出最近30天的安全日志中事件ID为4624(登录成功)和4625(登录失败)的记录 $startTime (Get-Date).AddDays(-30) Get-WinEvent -FilterHashtable {LogNameSecurity; StartTime$startTime; Id4624,4625} | Select-Object TimeCreated, Id, {NAccount;E{$_.Properties[5].Value}}, {NLogonType;E{$_.Properties[8].Value}} | Export-Csv -Path D:\security_log_audit.csv -NoTypeInformation -Encoding UTF8这段脚本的核心是用FilterHashtable过滤出登录相关事件4624是登录成功、4625是登录失败。LogonType字段要重点看2表示本地交互登录、3表示网络登录、10表示远程桌面登录。如果大量4625集中在非工作时间或者远程登录来源IP不是运维网段就需要重点关注。导出 CSV 是为了后续拿到电子表格里做条件筛选和数据透视比在事件查看器里翻页高效得多。Linux 主机的检查重点是账号、SSH 配置和补丁情况。一条命令就能同时检查关键项# 查看可登录账号、SSH是否允许root登录、最近安装的安全更新 awk -F: $31000 $7!/usr/sbin/nologin {print $1} /etc/passwd grep -E ^PermitRootLogin|^PasswordAuthentication /etc/ssh/sshd_config rpm -qa --last | head -20第一行是列出 UID 大于等于1000且 shell 不是 nologin 的用户作用是把所有能登录的系统账号暴露出来等保检查时特别关心是否存在无主账号或离职人员未删除的账号第二行看 SSH 是否允许 root 直接登录生产环境要求禁用 root 远程登录第三行看最近安装的软件包记录检查安全补丁是否及时更新。补丁核查在大型医院是硬骨头因为业务不能停凌晨窗口又短。实操上常见做法是核心业务系统的补丁先在测试机验证再到备机上灰度最后切换主备再补主库。自查报告里要如实反映补丁滞后的情况并给出分阶段的整改计划不要写“已全部更新”这不现实也没人信。3.3 网络边界与通信协议用扫描核验访问控制策略网络层的自查不是把防火墙策略导出来看一眼就完事而是要做“策略与实际流量”的对比验证。尤其是对外开放的服务边界要确认边界设备上放行的端口和实际对外提供服务的端口一致。一个简单有效的核验方式是在边界外做端口扫描确认对外开放的端口清单再和防火墙放行策略做对比nmap -sT -Pn -p 445,3389,22,80,443,1433,3306 医院对外IP-sT表示 TCP 连接扫描-Pn跳过主机发现直接扫端口适合检测防火墙是否对探测做了过滤。-p后面罗列的是常见高危端口445是Windows共享、3389是远程桌面、22是SSH、1433和3306分别是SQL Server和MySQL的默认端口。这些数据库和远程管理端口如果出现在外网扫描结果里属于严重问题。医疗行业的信息系统接诊、挂号、查询业务的对外端口通常是443或80其他端口原则上应该全部关闭。内网侧的检查重点是核心业务区的访问控制。常见做法是在核心交换机的镜像端口上做流量采集抓一段时间的数据统计每个业务系统对外通信的端口和协议。如果发现数据库端口在内网里被大量非应用服务器访问说明访问控制粒度太粗——正确做法是只允许应用服务器通过特定端口访问数据库而不是整个网段互通。3.4 应用与数据账号权限、数据库审计、备份恢复三件套应用层自查的核心是“谁能用、能做什么、做了是否留下痕迹”。以电子病历系统为例重点检查动态口令、密码策略、会话超时、权限分级、医生和护士的职责分离。医疗信息系统往往有几十个角色角色权限表要和实际岗位职责对得上不能出现“普通医生拥有管理员权限”这种整条链路的严重风险。数据库审计是最容易出彩的部分。主流的数据库——SQL Server、Oracle、MySQL——都有日志开关自查时先确认有没有开启再确认日志保留周期是否满足6个月要求。以 SQL Server 为例-- 检查SQL Server的登录审计级别和错误日志保留天数 SELECT name, is_login_audit_success_enabled, is_login_audit_failure_enabled FROM sys.dm_server_audit_status; EXEC xp_readerrorlog 0, 1, NLogging, NSQL Server;第一段查询的is_login_audit_success_enabled和is_login_audit_failure_enabled分别表示是否记录登录成功和失败的审计事件。医院的核心业务库通常都要求成功失败都记录只记录失败不记录成功等于不知道谁进来过。第二段查错误日志里的记录情况确认日志覆盖周期足够。备份恢复的检查不是看有没有备份文件而是要看“备份策略”和“恢复验证”。自查时要把备份任务清单拉出来检查备份类型全量、增量、日志、保留周期、备份存储位置是否异地。更关键的是问一个问题上次做恢复演练是什么时候备份不能恢复等于没有备份很多医院的备份恢复演练停留在承诺层面自查报告里要如实写清演练情况并给出当年度的演练计划。4. 隐患定级与报告撰写自查结论不能只有“基本符合”4.1 风险定级矩阵把“有问题”改成“可整改”检查过程中会发现大量问题这些问题不能简单分成“有/没有”而要按严重程度排序否则整改时不知道从哪里下手。常用的是下面的定级矩阵风险等级判定条件响应要求整改时限严重核心业务系统存在漏洞或配置不当可能导致服务中断或数据泄露立即整改1周内高关键安全机制缺失如审计未开启、备份不可用但不是直接可利用的漏洞限期整改1个月内中管理制度或流程缺口如培训记录不全、账号回收不及时计划整改3个月内低操作规范性问题如记录填写不完整日常改进6个月内每个发现的问题都要归入这个矩阵格式用“问题描述 — 发现过程 — 风险等级 — 整改建议”的列表。以第3章的检查结果举例边界扫描发现445端口对外开放就属于严重问题要写清楚“在哪个边界设备上发现、通过什么方式检测、可能造成什么影响、建议在防火墙封禁该端口”这样写出来的报告整改责任人拿到手上就知道下一步做什么。4.2 报告结构自查报告的五段式框架医院安全自查报告没有统一模板但要兼顾“给院领导看结论”和“给整改人员看任务”双重目标五段式是通用性最强的写法自查工作概述说明自查依据、时间范围、参与人员、覆盖范围自查内容与方法按制度、网络、主机、应用四个域说明查了什么、用了什么方法自查发现与风险分析按风险等级列出问题清单重点讲严重和高级别问题整改措施与计划按问题清单逐条对应整改责任人和时限工作建议需要领导层面协调的事项比如资源投入、跨部门配合4.3 证据归档截图、日志、配置备份的保存规范报告写得好不好一半看证据。发现问题的截图、扫描报告、日志导出文件、配置备份都要按“问题编号—证据类型—取证时间”的格式归档并附在提交稿里统一管理。证据归档跟着问题清单编号走每个问题配一个编号如WS-2025-001归档目录里对应一个同名文件夹。配置备份要记录当时的配置文件版本以便整改后做对比并让整改后的 diff 结果一并归档这样整个整改过程的完整链路——问题发现、问题定位、整改操作、复测验证——全都有据可查。5. 自查报告的汇报技巧与整改闭环5.1 用一张整改路线图推进跨部门协作自查报告提交后最常遇到的情况是报告交上去了整改没人管。医院里信息科的话语权有限安全问题靠信息科自己推动很难。所以报告里必须包含一个独立的“整改路线图”部分格式是一张按时间轴排列的表格优先级问题编号整改内容责任科室配合科室计划完成时间当前状态P0WS-2025-001封禁数据库端口外网暴露信息科无2025-04-07未开始P1WS-2025-002补全第三方运维审计记录信息科运维服务商2025-04-30未开始P2WS-2025-003修订账号管理制度并培训信息科人事科/医务科2025-05-31未开始这张表要放进向院领导汇报的版本里逐条说明问题是什么、不整改的风险有多大、需要哪个部门配合、卡点在哪里。写报告时把握一个原则每个问题都写成“需要决策”而不是“需要知悉”。5.2 复测验证整改结果如何留痕整改闭环的最后一步是复测。以 P0 问题为例整改动作是防火墙上封禁端口复测方法是在边界外重新执行同样的端口扫描确认端口已不可达并将前后的扫描结果放在同一份复测报告里做对比。服务器补丁整改复测进入系统确认补丁安装日期和版本号账号权限整改复测从账号管理平台导出角色权限快照做前后对比。复测记录必须有时间、操作人、整改前状态、整改后状态、验证方式这五个要素。常见的一个坑是拿“配置截图”冒充整改结果。配置截图只能说明做到了配置修改不能说明修改生效更说明不了业务未受影响。正确的验证方式是两块一是技术手段验证比如扫描、查询、模拟登录二是业务可用性确认比如由系统使用方在业务侧做一次实际操作验证。5.3 让自查报告变成年度安全运营的起点日常工作里建议每季度做一次轻量自查不再走全量核查而是抽核心业务系统和上次发现的高风险问题做定向复查。年度自查报告不要推倒重写而是以季度记录为基础做汇总这既能减轻工作负担也能防止到了年底想不起前几个月的情况。还有一个容易被忽略的点自查报告里写的整改完成时间要留有余量尤其是涉及采购或跨科室协调的事项按正常估计再放宽两周。如果报告提交后临时有新的整改要求尽量在同一个跟踪表里追加记录而不是另起一份表避免状态不一致。整改闭环的意义在于让下次检查有据可查而不是每年从零开始重新查一遍。本文还有配套的精品资源点击获取 
