网络安全保护义务不是“上线前检查”：三类处罚案例揭示的日常管理缺口
**主关键词：**网络安全保护义务 **副关键词：**网络安全等级保护、数据安全管理、测试环境安全、企业网络安全合规
一次疏忽，可能从数据泄露延伸到违法外呼
网络安全问题并不总是从复杂的攻击开始。有时，风险藏在一台没有防护的办公电脑、一套无人维护的访客登记系统，或一台测试结束后仍连在互联网上的服务器里。近期，公安网安部门公布的三起执法案例，分别涉及医疗机构数据管理、企业来访登记系统以及话务系统测试服务器。它们指向一个共同事实：系统是否“核心”、是否仍处于测试阶段，并不会自动免除运营者应承担的安全责任。
据公安网安部门发布的案例信息，福建漳州某医疗机构存在系统权限管理混乱、工作人员跨权限操作等问题；部分人员将1800余条工作数据导出并存放于缺少有效防护的互联网电脑。福建龙岩某公司自建的来访登记系统收集访客信息，却未落实相应的数据安全技术和管理措施。福建泉州某公司则在话务系统联网测试后未及时关闭测试系统，服务器遭入侵后被攻击者利用外呼功能实施不法行为。前两起案件依照《数据安全法》处理，第三起案件依照《网络安全法》处理，均被责令改正并受到行政处罚。
这三起事件不是对所有企业处罚尺度的统一判例，也不能替代个案法律意见；但它们为管理层和IT负责人提供了清晰的自查入口：谁在使用系统、数据如何流动、互联网暴露面是否持续存在，以及异常发生后能否及时发现和处置。
义务落在运营过程，不止落在制度文件
《网络安全法》要求网络运营者按照网络安全等级保护制度履行安全保护义务，包括建立内部安全管理制度和操作规程、确定网络安全负责人、采取防范网络攻击和侵入的技术措施、监测并记录网络运行状态及网络安全事件、采取数据分类和重要数据备份加密等措施。换言之，合规不能只靠一份制度或一次测评来证明，关键是控制是否持续运行，记录是否可追溯，责任是否落实到岗位。
《数据安全法》进一步要求开展数据处理活动的组织建立全流程数据安全管理制度、开展教育培训，并采取必要的技术和管理措施；发现风险应及时补救，发生数据安全事件应立即处置并按规定报告。网络与数据安全义务有交叉，但侧重点并不完全相同：前者关注网络运行和防护责任，后者覆盖数据从收集、存储、使用到传输、提供等处理活动。企业应结合系统性质、数据类别和适用规范进行评估，而不是简单地将“做了等保”视为全部工作已经完成。
同时，法律条文及编号可能因修法而变化。本文引用的案例及法律条文应以正式公布文本为准；企业在开展整改或法律评估时，应核对当前有效版本及适用要求。本文提供的是管理与技术层面的风险梳理，不构成法律意见。
案例一：权限失控与数据导出，让敏感信息离开受控边界
医疗机构的信息系统处理病历、诊断、检验检查、用药和护理等信息。案例披露的问题不仅是“有人导出了数据”，还包括系统权限未能按职责有效隔离，以及导出的数据进入缺少有效安全防护的互联网电脑。一个环节失守，会让原本受控的业务数据进入难以管理、难以审计的终端环境。
企业可从以下控制点检查数据访问链：
- **按职责授权：**将岗位职责映射为系统角色和数据范围，避免多人共用高权限账号；转岗、离职时及时调整或停用权限。
- **让导出有边界：**只有业务必要时才允许导出；对敏感数据设置审批、脱敏或加密要求，并记录申请人、数据范围、时间、去向和用途。
- **管住终端落点：**梳理哪些设备可以接触敏感数据，落实终端防护、磁盘加密、外设控制和必要的数据防泄漏措施；为临时文件设置清理和复核机制。
- **持续复核：**定期审查高权限、长期未使用及异常时段账号，检查批量查询、集中导出等行为是否符合岗位和业务需要。
制度是否有效，要看系统能否执行授权边界、日志能否支撑调查、管理者能否及时发现例外，而不仅是员工是否签署过承诺书。
案例二：所谓“边缘系统”，也可能是个人信息入口
访客登记、考勤、会议预约等系统常被视为辅助工具，因而容易遗漏在资产盘点、补丁管理和安全评估之外。但只要系统收集或处理个人信息，就需要明确业务负责人、数据范围、保存期限、访问权限和安全措施。系统规模小，不等于风险为零；不是核心业务，也不等于可以无人维护。
建议企业建立统一的系统资产清单，并为每个系统记录至少以下信息：业务负责人、技术维护方、部署位置、互联网暴露情况、处理的数据类型、账号权限、补丁状态、日志位置、备份与恢复方式、停用条件。自建系统和采购的SaaS服务都应纳入盘点；由供应商建设或运维时，还应明确数据处理边界、访问方式、事件通报、漏洞处置和合同终止后的数据处理责任。
对低风险、小型系统，控制措施可以与风险相匹配，但底线应明确：不使用默认口令，不将管理端直接暴露于公网，及时安装安全更新，启用必要的访问控制和日志记录，并设定责任人和复核周期。发现系统不再需要时，应完成数据迁移或删除、账号回收、域名解析和公网入口清理，而不是只停止日常使用。
案例三：测试系统下线流程，是生产安全的一部分
话务系统案例的关键教训，是测试活动结束并不意味着风险自然消失。测试服务器仍可从互联网访问，且保留可被滥用的外呼能力；当攻击者取得控制权后，原本用于测试的功能可能成为对外造成影响的入口。测试环境如果连接生产网络、持有真实账号或能调用真实业务资源，其风险甚至可能接近生产系统。
IT团队可以把测试环境管理纳入变更与资产生命周期流程：
- **申请时界定范围：**记录系统负责人、测试目的、开放端口、访问来源、测试数据和预计结束时间。优先使用脱敏或合成数据，避免把生产数据直接复制到测试环境。
- **部署时采用基线：**及时安装补丁，移除默认账号和不必要服务，限制管理入口和来源地址；测试环境与生产网络之间设置明确隔离和访问控制。
- **测试期间留痕：**对管理员操作、远程访问、配置变更和关键业务调用保留日志；必要时设置异常流量或高风险行为告警。
- **结束时关闭并验收：**按清单关闭公网入口、释放临时凭据、撤销防火墙例外、回收账号、清理数据并确认服务不可访问。由申请人和系统负责人共同完成关闭确认。
- **持续发现遗留资产：**通过云资源清单、域名与证书盘点、外网暴露面检查等手段，定期识别无人认领的主机、测试站点和过期服务。
把法律义务转成可验证的证据
当企业需要证明安全措施已落实，口头说明通常不够。建议将每项关键义务映射到“责任人、技术控制、运行记录、异常处置”四类证据：
| 管理目标 | 可验证的控制 | 建议留存的证据 |
|---|---|---|
| 权限与责任清晰 | 角色权限、审批流程、离职回收 | 权限矩阵、审批记录、复核记录 |
| 防范攻击与未授权访问 | 补丁、边界控制、终端防护、身份认证 | 配置基线、漏洞整改、策略变更记录 |
| 发现异常并可追查 | 登录与操作日志、告警、审计 | 日志留存策略、告警工单、调查记录 |
| 保护数据可用性与机密性 | 分类分级、备份、加密、恢复演练 | 数据清单、备份报告、恢复测试记录 |
| 事件发生后及时处置 | 应急预案、升级和通报流程 | 演练记录、事件时间线、处置与复盘报告 |
| 测试系统及时退出 | 到期提醒、关闭验收、资产复核 | 测试申请、到期清单、关闭确认单 |
表格中的具体措施属于企业风险治理建议，企业应根据适用法律、行业要求、系统重要性及实际风险确定控制强度。日志的留存期限、数据分类和报告义务等事项，应依据当前有效法律法规、行业主管要求和适用标准核定，不宜仅凭通用清单设定。
管理层可以从四个问题开始自查
第一，企业是否掌握所有正在运行、对外提供服务或仍可从互联网访问的系统？第二，系统处理哪些个人信息、业务数据或重要数据，谁批准访问与导出？第三，是否存在已结束测试但仍在线、无人维护或保留真实业务能力的资产？第四，发生异常后，团队能否在日志、联系人和应急流程的支持下及时定位、止损、保全证据并按规定报告？
如果这些问题没有明确答案，优先工作不是再添一份制度，而是补齐资产清单、责任归属和可验证的运行控制，再根据风险排序实施整改。网络安全保护义务最终要体现在每天的配置、审批、监测、维护和复核之中。
DELine 如何协助企业落地
DELine 可结合企业现有系统与业务流程，协助开展网络与数据安全现状梳理、互联网暴露面及测试环境检查、终端与访问控制优化、网络安全等级保护相关技术整改，以及日志监测和应急响应流程建设。我们建议从资产与风险可视化入手，形成责任明确、措施可验证、整改有闭环的实施路线。
如需讨论企业网络安全建设与持续运维，可访问 DELine 官网 或通过 联系我们 与团队沟通。
本文为一般性技术与管理信息，不构成法律意见。涉及具体义务、处罚适用和整改方案时，请结合企业实际及现行有效法规向专业法律顾问或主管部门核实。