护网—2026公布三起案例：权限、数据导出、测试系统都要查

全文约 2700 字，预计阅读 8 分钟。

10月31日公开的“护网—2026”三起案例，涉及医疗机构权限与导出管理、来访登记系统防护、联网测试系统管理。对政企单位而言，应当沿着账号、数据流转和系统生命周期查到具体责任人，并用实际配置与日志验证整改结果。

一、先看清三起案件，问题分别发生在哪里

这次通报中的问题，出现在日常查询、数据导出、访客登记和业务测试这些熟悉的工作环节。

据10月31日的公开转载，公安部网安局公布了三起不履行数据安全保护义务或网络安全保护义务案。[1][2] 公布日期可以核实，具体检查、违法行为及处罚决定的日期，不能统一当作10月31日。

漳州某医疗机构：系统权限管理混乱，工作人员能够跨权限操作；部分人员导出1800余条工作数据，存于缺乏有效安全防护的互联网电脑。属地公安机关依据《数据安全法》作出行政处罚，并责令改正。[1]

龙岩某公司：自建访客登记系统存有姓名、来访事由等个人信息，却因被视为非核心系统，未落实有效技术保护与管理措施，数据面临安全风险。公安机关依据《数据安全法》予以行政处罚，并责令改正。[2]

泉州某公司：联网测试话务系统防护不足，测试结束后仍未下线，遭入侵后被利用外呼。公安机关依据《网络安全法》处罚并责令限期改正；入侵行为另案处理。[2]

公开通报没有披露三案的具体罚款金额。医疗机构与访客系统案例描述了保护缺失及风险，不宜扩写成“已泄露多少条”；话务系统一案则明确出现了入侵和功能被滥用。三种状态应当分开表述。

同样，没有依据把这次通报称为“全国统一进入案例公开期”。对单位管理者更有价值的，是用这三起案件检验自己的日常工作流程。

二、医疗机构：数据离开系统后，保护有没有跟过去

医疗机构一案有两个值得连起来看的环节：系统内能够越权操作，系统外的导出文件又落到了防护不足的联网电脑上。

这提示我们，检查不能止于“数据库有没有访问控制”。系统里原本有效的保护，可能在导出为表格后失去作用。一个人在系统中能查什么、能导出什么，以及导出后可以保存在哪里，应当能够对应起来。

以下是据案情提出的实施建议，并非通报认定涉事机构存在的全部问题。

先抽一个普通岗位账号，在授权测试范围内核对三个能力：能否访问本岗位以外的数据，能否批量导出，导出操作能否追溯到具体操作者。测试应使用模拟数据或经过批准的样本，不为排查再次扩大真实数据的流转范围。

再追一份实际导出任务：业务用途是什么，审批是否覆盖数据范围，接收电脑是否纳管，保存期限由谁确定，任务结束后的文件如何处置。需要核查的是一整条流转路径，而不只是申请表上有没有签字。

把“谁能看、谁能导、导到哪里”一起核对。权限表与实际功能不一致时，应由业务负责人、信息部门和系统维护单位共同确认调整，避免单方面关权限影响诊疗或正常业务。

对导出文件，需要根据数据性质和使用目的确定必要范围，采取适当的脱敏、加密和访问限制，并确认接收端具备相应保护。不能因为文件还在“本单位电脑”上，就默认它处于受控环境。

导出审批应落实到数据范围、接收终端和保存期限。这三项明确之后，技术措施与人员责任才有具体落点。

三、来访登记：“小系统”也要有人接手安全责任

访客登记系统往往只有少量页面，业务负责人也可能不把它列入核心系统清单。但系统规模与其中数据是否需要保护，是两个问题。

从这个案例出发，单位可以把来访登记、会议预约、考勤及其他辅助业务系统列入一次补充盘点。这是排查建议，不代表通报涉及了这些其他系统。

盘点时，至少问清楚：谁在使用、谁负责维护、部署在哪里、收集什么数据、哪些地址能访问、是否还需要继续运行。自建系统、采购系统、云上服务和供应商代运维系统，都应能够找到对应的业务与维护负责人。

把辅助业务系统纳入资产清单，并明确责任人。不能只在采购或上线时留下一份文档，之后账号谁管、补丁谁打、合同到期谁接手都没有答案。

验收也不宜只收一句“已加固”。可以要求维护方提供脱敏后的访问控制配置、账号清单、更新记录与抽样日志，证明措施确实覆盖正在运行的实例。

如果系统由第三方维护，合同和保密协议可以明确责任，但还需要有执行记录。交付一套软件之后，管理账号、远程维护入口和数据副本是否仍由供应商持有，都值得核查。

四、测试系统：测试结束，网络暴露也要结束

泉州话务系统一案的关键，是联网测试留下了可被利用的服务，随后发生真实入侵与外呼滥用。

测试服务器即便没有完整生产数据，也可能拥有真实能力。例如，对外通信、调用其他接口或使用业务凭据。这里列举的是一般排查方向，不能当成涉案系统未经披露的技术细节。

建议把测试环境的管理拆成上线、使用和退出三个节点。

上线前，确定允许访问的来源、必要端口、测试账号和到期时间；测试中，关注异常登录、调用量及对外通信；结束后，由责任人确认服务是否需要保留，而不是等有人想起才处理。

测试到期后，核验服务、访问入口和业务能力是否关闭。只退出浏览器或停掉一个页面，不足以证明后台进程、云安全组、域名映射及远程维护通道已经收敛。仍需长期保留的环境，应说明用途、落实管理和重新确认访问范围。

对于话务、短信等带有外发能力的系统，建议结合业务设置调用权限、额度限制和异常告警。阈值应按实际业务确定，不应把某个统一数字套到所有单位。

如果已出现异常外拨或其他入侵迹象，先控制受影响功能，保全日志并按流程报告。操作时兼顾业务连续性和取证需要，避免在尚未保留必要证据时直接重装或清空系统。

五、把排查结果变成可以验收的四份记录

三起案例分别发生在不同场景，但单位可以用同一组问题推动整改：对象是否找全、责任是否明确、措施是否生效、证据是否留存。

下面四份记录，是本文建议的落地方式，不是对所有单位新增一套法定表格。

一份资产责任清单。写明系统用途、部署位置、业务负责人、维护方和运行状态，把仍联网的测试环境与辅助系统一起纳入。

一份账号权限核对记录。以岗位为依据，核对实际查询、导出和管理权限；记录异常账号如何收回，调整后哪些业务场景通过了验证。人员转岗或离职后，还要检查权限是否随之变化。

一份数据导出流转记录。说明导出的必要性、数据范围、批准人、接收位置、保护措施和到期处理情况。记录中避免复制整份敏感数据作为“证明材料”，以免台账本身成为新的副本堆积点。

一份整改复核记录。每个问题对应责任人、完成期限、实施动作和复核证据。涉及生产变更时，先确认备份、维护窗口及回退条件；完成后验证正常业务和限制措施是否同时生效。

例如，权限收敛后，应检查越权访问是否被阻止、正常岗位能否继续工作；测试服务下线后，应从原有访问路径核验是否仍可达；终端防护部署后，应确认客户端在线及策略实际生效。

以配置、受控验证和日志确认整改效果。截图可以辅助说明，但不能仅凭一张软件安装截图，就认定数据保护已经到位。

六、可直接转给业务与运维负责人的便签

请各业务负责人及维护单位核查三类事项：岗位账号是否存在不必要的查询、导出或管理权限；导出文件是否存放于未经确认的联网终端；辅助系统及测试环境是否遗漏在资产管理之外。请逐项反馈对象、责任人、问题、措施、完成时间及复核证据；发现入侵或数据安全事件迹象时，立即按本单位预案处置并履行相应报告程序。

这次通报给出的现实提醒是：一次查询、一份导出文件、一个暂时保留的测试入口，都可能需要持续的安全管理。

对照案例排查时，不妨从一个普通账号、一项导出任务和一台测试服务器开始。沿着实际操作走一遍，比只问“制度有没有、设备买没买”，更容易看见保护措施在哪里中断。

信息来源与核验方式 [1] 新华网，2026年10月31日，《公安网安部门公布多起不履行数据安全保护义务案》，页面注明来源为公安部网安局微信公众号：https://www.xinhuanet.com/legal/20261031/1d688fa336e4456b92b59d978a28437f/c.html [2] 西藏自治区党委网信办，2026年10月31日，《涉及重要网络系统和数据安全 3起典型案例公布》，页面注明来源为中国新闻网、内容援引公安部网安局：https://wxb.xzdw.gov.cn/wlaq/zljg/202610/t20261031_705231.html 本文以公开通报核对案情与处罚表述，未获得三案完整行政处罚决定书；不推定具体罚款金额、未公开泄露规模及未披露攻击手法。文中实施步骤、抽查方法和验收记录为作者基于案例提出的建议，不代表官方新增统一检查要求。资料核验截至2026年11月1日。