校园数据库安全防护管理细则

校园数据库安全防护管理细则第一章总则第一条为全面加强校园信息系统数据安全管理，规范数据库系统的防护措施，保障全校教学、科研、管理及服务等核心数据的机密性、完整性和可用性，依据《中华人民共和国网络安全法》、《中华人民共和国数据安全法》、《中华人民共和国个人信息保护法》以及教育部关于加强教育行业网络安全工作的相关指导意见，结合本校信息化建设实际情况，特制定本管理细则。第二条本细则适用于全校范围内所有依托校园网运行的数据库系统，包括但不限于教务管理系统、科研管理平台、财务系统、人事管理系统、一卡通系统、图书馆管理系统、校园门户网站后台数据库以及各类二级单位自建业务系统数据库。无论是部署在本地数据中心、私有云环境还是通过租赁方式使用的云数据库，均须纳入统一安全管理范畴。第三条数据库安全防护遵循“谁主管谁负责、谁使用谁负责、谁运维谁负责”的原则。坚持安全防护与信息化建设“同步规划、同步建设、同步使用”，确立以数据为中心的安全防护体系，实施分级分类管理，确保数据全生命周期的安全可控。第四条本细则所指数据库安全防护范围包括数据库操作系统、数据库管理系统（DBMS）、数据库中间件、数据库中的数据本身以及相关的网络连接环境。安全防护内容涵盖物理环境安全、逻辑访问控制、数据加密、审计追踪、备份恢复、漏洞管理及应急响应等多个维度。第二章组织架构与职责第五条网络与信息化中心（以下简称“网信中心”）是校园数据库安全防护的主管部门，负责制定和修订数据库安全管理制度及技术标准，统筹全校数据库的安全建设与运维监管，提供安全技术支撑，并定期组织安全检查与风险评估。第六条网信中心数据库安全管理组具体履行以下职责：（一）负责校园核心数据库的日常运维、安全配置基线落地及性能监控；（二）负责数据库账号权限的审核与开通，定期审计账号使用情况；（三）负责数据库安全补丁的测试与升级工作；（四）负责制定数据库备份策略并定期验证备份数据的有效性；（五）负责响应数据库安全事件，协助进行故障排查与取证。第七条各业务部门（系统使用单位）是数据库数据安全的责任主体，其主要负责人是本单位数据安全的第一责任人。各业务部门需指定专人作为数据安全管理员，负责配合网信中心开展以下工作：（一）梳理本部门业务系统数据资产，明确数据分类分级；（二）提出合理的数据库访问权限需求，并及时清理离岗人员的访问权限；（三）规范业务系统操作流程，防止因业务逻辑漏洞导致的数据泄露；（四）发现数据异常情况时立即上报，并配合应急处置。第八条建立数据库“三权分立”管理机制。在数据库管理层面，应将系统管理员、安全管理员和审计管理员职责进行分离。系统管理员负责数据库的安装、配置和维护；安全管理员负责安全策略的制定与权限分配；审计管理员负责安全审计记录的查看与分析。严禁一人兼任多职，确保权限相互制约。第三章数据分类分级管理第九条根据数据的重要程度、敏感性和泄露后对学校、师生及社会造成的影响，将校园数据库数据划分为四个安全等级：公开信息、内部信息、敏感信息、绝密信息。第十条公开信息是指可向社会公众或校园网内无条件公开的数据，如学校简介、招生简章、公开的新闻通知等。此类数据对完整性要求较高，但机密性要求较低。第十一条内部信息是指仅限校内授权人员访问，用于日常行政管理和教学运行的数据，如校内通讯录、非涉密的会议纪要、内部通知等。此类数据禁止外传，泄露会对学校工作秩序造成轻微影响。第十二条敏感信息是指包含个人隐私、学校未公开的关键业务数据，如师生身份证号、家庭住址、电话号码、银行卡号、学籍成绩、体检数据、财务薪资等。此类数据是防护的重点，泄露会对个人权益或学校声誉造成严重损害。第十三条绝密信息是指涉及国家安全、学校核心科研秘密、重大决策底稿等极高敏感度的数据，如涉密科研项目数据、未公开的核心算法、校级核心机密文件等。此类数据应存储在物理隔离或高强度逻辑隔离的专用区域，实施最高级别的安全管控。第十四条数据分类分级清单表如下：数据类别数据等级典型数据示例存储要求访问控制要求共享与导出要求公开信息一级学校新闻、公开课表、校园地图标准存储校园网开放访问允许无条件共享内部信息二级内部通知、部门工作计划、非敏感行政文档标准存储身份认证+校内IP限制需部门负责人审批敏感信息三级身份证号、成绩单、薪资、财务账号加密存储强身份认证+最小权限+动态脱敏严禁导出，特殊需求需校级审批绝密信息四级核心科研数据、涉密档案、加密私钥独立存储+高强度加密专用终端+物理隔离+多因素认证禁止任何形式的网络共享第四章身份认证与访问控制第十五条数据库访问必须实行严格的身份认证机制。严禁默认账号、空口令或弱口令存在。所有数据库管理员账号和业务账号必须设置复杂度符合要求的密码，密码长度不得少于12位，且必须包含大小写字母、数字及特殊符号，并每90天强制更换一次。第十六条对于核心数据库和包含敏感信息（三级及以上）的数据库，必须启用多因素认证（MFA）机制。通过结合密码、动态令牌、数字证书或生物特征等多种方式对用户身份进行鉴别，防止因密码泄露导致的非法入侵。第十七条严格遵循“最小权限原则”和“岗位适配原则”。数据库账号的权限授予应严格限制在完成工作任务所需的最小范围内，禁止授予DBA、ADMIN等超级管理员权限给普通业务人员或应用程序账号。第十八条实施数据库账号全生命周期管理。（一）账号申请：须填写《数据库账号申请表》，经所在部门负责人签字及网信中心审核后方可开通；（二）账号变更：人员岗位变动时，应在3个工作日内同步调整其数据库访问权限；（三）账号注销：人员离职、转岗或长期离校（超过6个月），其所属部门须立即通知网信中心注销其所有数据库访问权限。第十九条应用程序访问数据库必须使用专用服务账号，该账号仅限于应用程序连接使用，禁止通过该账号进行人工数据库操作。服务账号的权限应仅限于DML（数据操纵语言）操作，严禁授予DDL（数据定义语言）或DCL（数据控制语言）权限。第二十条严格限制数据库客户端的访问来源。通过在数据库所在操作系统或防火墙层面配置ACL（访问控制列表），仅允许授权的应用服务器IP地址或运维管理终端IP地址访问数据库端口。对于远程维护，必须通过校园网VPN接入，并记录详细的访问日志。第五章数据库系统安全配置第二十一条数据库系统在安装部署时，必须进行安全加固。关闭不必要的默认服务、端口和存储过程（如SQLServer的xp_cmdshell、Oracle的UTL_HTTP等高危组件），移除默认的示例数据库和测试表。第二十二条数据库监听器应配置为不对外广播真实版本信息。修改数据库默认端口（如MySQL默认3306，Oracle默认1521），避开常用攻击端口，降低被自动化扫描工具识别的风险。第二十三条开启数据库系统自身的资源限制功能，防止因资源耗尽导致的拒绝服务攻击。配置最大并发连接数、单个查询超时时间、单次会话CPU使用时间及内存使用上限等参数，确保异常查询不会拖垮整个数据库服务。第二十四条针对关系型数据库，需严格防范SQL注入攻击。除了在应用代码层面进行参数化查询外，数据库层面可部署数据库防火墙或启用查询白名单机制，实时检测并阻断异常的SQL语句执行。第二十五条定期进行数据库漏洞扫描。网信中心每季度至少组织一次对核心数据库系统的漏洞扫描，使用专业漏扫工具检测系统配置缺陷、弱口令、已知补丁缺失等风险。对于发现的高危漏洞，必须在7个工作日内完成修复；中低危漏洞应在30个工作日内制定修复计划并落实。第二十六条数据库补丁管理。操作系统及数据库管理系统的重要安全补丁（CriticalPatchUpdate）应密切关注厂商发布动态。补丁安装前必须在测试环境中进行充分的兼容性测试和功能验证，确认无误后方可按照变更管理流程在生产环境实施，并做好回滚预案。第六章数据加密与脱敏技术第二十七条敏感数据存储加密。对于存储在数据库中的三级及以上敏感字段（如身份证号、密码哈希值、银行卡号），必须采用国家密码管理局认可的算法（如SM4、AES-256）进行加密存储。加密密钥的管理应遵循“密钥与数据分离”原则，使用独立的密钥管理系统（KMS）或硬件安全模块（HSM）进行存储和生命周期管理，严禁将密钥明文硬编码在程序中或存放在数据库配置表中。第二十八条传输通道加密。所有数据库客户端与服务器端之间的连接，必须强制启用SSL/TLS协议进行加密传输，确保数据在网络传输过程中不被窃听或篡改。禁止使用未加密的明文传输协议（如FTP、Telnet、HTTP明文SQL调用）。第二十九条静态数据脱敏。在开发、测试、数据分析等非生产环境中使用数据时，必须对敏感数据进行静态脱敏处理。脱敏应采用不可逆算法（如替换、重排、加密截断），确保无法还原原始数据。严禁将生产环境的真实敏感数据完整复制到测试环境。第三十条动态数据脱敏。对于具备高权限运维人员或第三方审计人员查询敏感数据时，数据库应启用动态脱敏功能。根据用户权限和业务场景，实时对查询结果中的敏感字段进行掩码处理（如身份证号显示为“110***1234”），在满足运维需求的同时防止数据批量泄露。第三十一条敏感列加密表：敏感字段类型建议加密算法脱敏展示规则密钥管理要求身份证号SM4/AES-256保留前6后4，中间*号替代密钥需定期轮换（1年）手机号码SM4/AES-256保留前3后4，中间*号替代密钥需定期轮换（1年）银行卡号SM4/AES-256仅显示后4位，其余*号替代密钥需定期轮换（1年）用户密码SHA-256+Salt不可查看，仅用于比对Salt值需随机且唯一健康信息SM4国密算法仅显示脱敏标识密钥需离线存储第七章运维与变更管理第三十二条建立严格的数据库变更审批制度。任何涉及数据库结构变更（DDL）、重大数据调整（DML批量更新）、数据库配置修改的操作，均须提交《数据库变更申请单》，详细说明变更内容、原因、影响范围、测试情况及回滚方案，经网信中心技术负责人审批后方可执行。第三十三条实施运维操作双人复核机制。对于核心数据库的删除、更新、导出等高风险操作，严禁一人独立完成。必须由主操人员执行命令，复核人员现场或通过屏幕共享方式进行实时确认，确保操作指令的准确性和合规性。第三十四条限制高危操作时间。除紧急故障修复外，常规的数据库停机维护、版本升级、大规模数据导入导出等操作，必须安排在业务低峰期（通常为晚间22:00至次日6:00）进行，并提前通知相关业务部门。第三十五条第三方运维管理。确因技术复杂需外部厂商人员介入数据库运维时，必须签署严格的保密协议，明确数据安全责任。运维过程必须由校内人员全程陪同监控，操作过程须开启屏幕录制并留存至少180天。外部人员仅能通过临时授权的堡垒机进行操作，严禁直接授予数据库服务器操作系统权限。第三十六条数据库清理与归档。定期对数据库中的过期数据、冗余数据、日志表进行清理。对于具有长期保存价值但访问频率低的历史数据，应迁移至归档数据库或冷存储中，减轻核心库压力，降低数据泄露风险。第八章审计与日志监控第三十七条全面开启数据库审计功能。所有数据库系统必须部署独立的数据库审计系统或开启数据库自身的审计插件，实现对所有登录行为、SQL操作语句、访问对象、执行时间、影响行数等信息的全量记录。第三十八条审计记录内容必须包含：操作时间、操作源IP、操作终端MAC地址、数据库账号、执行的SQL语句、操作结果（成功/失败）、受影响的表名及字段名。审计记录应确保不可被篡改、不可被删除。第三十九条建立日志实时分析与告警机制。通过安全信息事件管理平台（SIIP）对接数据库审计日志，配置实时告警规则。对以下异常行为进行即时告警：（一）短时间内频繁的登录失败行为（暴力破解）；（二）非业务时间段（如深夜）的大规模数据查询或导出操作；（三）敏感表结构的变更（DROP、ALTER）；（四）特权账号（如DBA）的激活与使用；（五）单次查询返回行数超过预设阈值（如1000行）。第四十条审计日志留存。数据库审计日志须长期保存，保存期限不得少于6个月，对于涉及重大安全事件的日志应永久归档。审计日志的存储空间应纳入规划，防止因磁盘空间不足导致审计中断。第四十一条定期审计报告。网信中心每月生成数据库安全审计报告，提交至网络安全领导小组。报告内容应包括账号活跃度统计、高危操作汇总、异常事件分析及安全态势评估。对于发现的违规操作，应及时通报相关部门并责令整改。第九章备份与恢复机制第四十二条建立分级分类的数据备份策略。根据数据重要性和RTO（恢复时间目标）、RPO（数据丢失容忍度）指标，制定差异化的备份方案。第四十三条备份策略具体要求：（一）完全备份：核心数据库（教务、财务、人事等）至少每7天进行一次完全备份；（二）增量备份：每日至少进行一次增量备份或差异备份；（三）日志备份：对于开启归档模式的数据库，应每小时或每15分钟进行一次事务日志备份，确保可实现秒级或分钟级的数据恢复（PITR）。第四十四条备份存储管理。备份数据必须遵循“3-2-1”备份规则，即至少保留3份数据副本，存储在2种不同的介质上，其中1份必须保存在异地或离线环境中。严禁将备份数据仅存储在数据库服务器的本地磁盘中。第四十五条备份数据加密。所有传输到异地存储或离线存储的备份数据文件必须进行加密处理，加密密钥与生产数据密钥隔离管理，防止备份数据介质丢失导致的数据泄露。第四十六条备份恢复演练。网信中心每季度至少组织一次数据库恢复演练。随机抽取历史备份文件，在隔离的测试环境中进行恢复操作，验证备份数据的完整性和可用性。演练结束后需形成书面报告，记录演练过程、发现的问题及改进措施。第四十七条灾难恢复预案。针对极端灾难场景（如机房火灾、勒索病毒感染），制定详细的数据库灾难恢复预案（DRP），明确应急响应流程、人员职责、资源调配及业务切换顺序，确保在发生重大灾难时能在规定时间内恢复核心业务数据。第十章应急响应与处置第四十八条建立数据库安全事件应急响应组织体系，设立应急响应小组，成员包括网信中心技术人员、相关业务部门负责人及法律顾问。第四十九条明确安全事件分级。根据事件影响范围和危害程度，将数据库安全事件划分为特别重大（I级）、重大（II级）、较大（III级）和一般（IV级）四个等级。第五十条应急响应流程：（一）事件监测与发现：通过审计告警、用户举报或系统巡检发现异常；（二）事件研判与定级：由技术人员初步分析事件性质，确定等级；（三）抑制与控制：立即采取措施阻断攻击源（如封禁IP、断开网络、冻结账号），防止事态扩大；（四）根除与修复：消除安全隐患（如修补漏洞、清除后门、恢复被篡改数据）；（五）恢复与验证：恢复业务系统服务，并验证数据完整性和功能正