DB52∕T 1541.5-2021 政务数据平台 第5部分：安全技术规范(贵州省).pdf

《DB52∕T 1541.5-2021 政务数据平台 第5部分：安全技术规范(贵州省).pdf》由会员分享，可在线阅读，更多相关《DB52∕T 1541.5-2021 政务数据平台 第5部分：安全技术规范(贵州省).pdf（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 ICS 01.040.03 CCS A 12 DB52 贵州省地方标准 DB52/T 1541.52021 政务数据平台 第 5 部分：安全技术规范 Governmental data platformPart5:Security technical specification 2021-08-18 发布 2021-12-01 实施贵州省市场监督管理局 发 布 DB52/T 1541.52021 I 目 次 前言.II 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 4 缩略语.2 5 基本框架.2 6 要求.4 7 标准规范.7 8 运维管理.7 DB52/T 1541.5202

2、1 II 前 言 本文件按照GB/T 1.1-2020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。本文件是 DB52/T 1541 的第 5 部分。DB52/T 1541 已经发布以下部分：第 2 部分：数据归集规范；第 3 部分：数据存储规范；第 4 部分：接口规范；第 5 部分：安全技术规范；第 6 部分：面向全网搜索应用的数据处理规范；第 7 部分：运维管理规范；第 8 部分：运营机构服务规范。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由贵州省大数据发展管理局提出并归口。本文件起草单位：贵州省机械电子产品质量检验检测院、贵州中软云

3、上数据技术服务有限公司、云上贵州大数据产业发展有限公司、贵州省信息中心、贵州省量子信息和大数据应用技术研究院。本文件主要起草人：刘荣飞、刘彦嘉、王珂、杨建国、黄明峰、韦超、李勇、张中、刘军、潘伟杰、邵建平、韩朱旸、钟凯馨、唐昶、张洋、孙瑾、宿睿智、王静、王世均。DB52/T 1541.52021 1 政务数据平台 第 5 部分：安全技术规范 1 范围 本文件规定了政务数据平台安全的基本框架、要求、标准规范、管理体系等。本文件适用于政务数据平台（以下简称“平台”）安全的规划、建设和管理。2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅

4、该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 18336(所有部分)信息技术 安全技术 信息技术安全性评估准则 GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求 GB/T 22240-2020 信息安全技术 网络安全等级保护定级指南 GB/T 28448-2019 信息安全技术 网络安全等级保护测评要求 DB52/T 1126-2016 政府数据 数据脱敏工作指南 DB52/T 1540.6-2021 政务数据 安全技术规范 GB/Z 20986-2007 信息安全技术 信息安全事件分类分级指南 3 术语和定义 下

5、列术语和定义适用于本文件。3.1 政务数据 government data 政务部门及其技术支撑单位在履行职责过程中依法采集、生成、存储、管理的各类数据资源。注：根据可传播范围，政务数据一般包括可共享政务数据、可开放公共数据及不宜开放共享政务数据。来源：GB/T 38664.1-2020，3.1 3.2 政务数据平台 government data platform 依托政务云计算平台搭建，承载政务数据并支撑数据统筹存储、统筹治理、统筹应用和统筹安全的基础信息技术平台。DB52/T 1541.52021 2 3.3 网络安全 cyber security 通过采取必要措施，防范对网络的攻击、侵

6、入、干扰、破坏和非法使用以及意外事故，使网络处于稳定可靠运行的状态，以及保障网络数据的完整性、保密性、可用性的能力。来源：GB/T 22239-2019，3.1 3.4 数据安全 data security 采用技术和管理措施来保护数据的保密性、完整性和可用性等。来源：GB/T 39477-2020，3.1 3.5 数据生命周期 data lifecysle 将原始数据转化为可用于行动的知识的一组过程。4 缩略语 下列缩略语适用于本文件。ACL：访问控制列表（Access Control Lists）CC：挑战黑洞，DDoS攻击的一种常见类型（Challenge Collapsar）DDoS：

7、分布式拒绝服务攻击（Distributed Denial of Service attacks）FTP：文件传输协议（File Transfer Protocol）HTTP：超文本传输协议（Hyper Text Transfer Protocol）HTTPS：超文本传输安全协议（Hyper Text Transfer Protocol over Secure Socket Layer）IDC：互联网数据中心（Internet Data Center）IP：互联网协议（Internet Protocol）RDP：远程桌面协议（Remote Display Protocol）SQL：结构化查询语言

8、（Structured Query Language）SSH：安全外壳协议（Secure Shell）SSL：安全套接层（Secure Sockets Layer）VPN：虚拟专用网络（Virtual Private Network）Web：全球广域网（World Wide Web）5 基本框架 5.1 框架 政务数据平台安全技术框架见图1，内容包括物理安全、网络安全、主机安全、应用安全、数据安全及安全标准规范、安全运维管理。DB52/T 1541.52021 3 图1 政务数据平台安全技术框架 5.2 物理安全 为平台提供机房及物理设备运行环境的访问控制、消防管理、电力管理、温湿度管理等安全

9、防护。5.3 网络安全 为平台提供网络访问控制、网络入侵防护、网络安全隔离、网络日志审计等安全防护。5.4 主机安全 为平台提供主机防护、端口扫描、系统加固、操作日志审计等安全防护。5.5 应用安全 为平台提供Web应用防护、网页防篡改、漏洞扫描、Web业务审计等安全防护。5.6 数据安全 为平台提供数据生命周期安全管理、数据库防护、数据库审计、数据备份与恢复等安全防护。5.7 安全标准规范 为平台安全规划、建设、安全运维、安全风险管理等提供标准支撑。5.8 安全运维管理 为平台提供安全运维、安全评估、应急管理等运维管理措施。DB52/T 1541.52021 4 6 要求 6.1 物理安全

10、机房环境物理安全应满足T3机房相关要求。注：T3机房为国际上关于IDC机房建设评级的第三级机房，即可并行维护数据中心机房，机房总体要求可提供 99.98的可用性，每年停机时间最多为1.6小时。6.2 网络安全 6.2.1 网络访问控制 6.2.1.1 应在网络边界部署访问控制设备，并启用访问控制功能。6.2.1.2 只允许被授权的服务和协议经过网络进行传输，未经授权的数据包将被自动丢弃。6.2.1.3 应控制网络流量，限制网络最大流量数和网络最大连接数。6.2.1.4 应控制网络边界，使用 ACL 技术对网络进行安全隔离。6.2.2 网络入侵防护 6.2.2.1 在网络边界部署入侵防护设备，启

11、用入侵防护功能。6.2.2.2 对常见的端口扫描、IP 碎片攻击、网络蠕虫等网络扫描和网络攻击进行阻断。6.2.2.3 宜部署流量清洗设备抵御各类基于网络层、传输层及应用层的 DDoS 攻击，对恶意流量进行拦截和清洗处理。6.2.3 网络安全隔离 6.2.3.1 通过网闸、物理隔离等方式，实现跨互联网、政务外网、政务内网等不同网络区域的网络安全隔离及数据交换使用。6.2.3.2 互联网与政务外网跨网通信，宜通过网闸方式进行隔离。6.2.3.3 政务内网和其他网络应通过物理方式进行隔离。6.2.4 网络日志审计 6.2.4.1 应部署网络安全审计系统，实现对所有访问业务系统的行为审计。6.2.4

12、.2 审计内容应包括源 IP、目的 IP、是否访问成功、端口协议等。6.2.4.3 网络日志应留存 6 个月以上。6.3 主机安全 6.3.1 主机防护 6.3.1.1 应在主机上部署主机防护系统，启用主机防护相关功能。6.3.1.2 应进行密码暴力破解防护，对主机操作系统的 SSH、RDP、Telnet 等端口以及 FTP、MySQL、MS SQL Server 等常用程序进行监控。6.3.1.3 应支持网站后门检测，对 PHP、ASP、JSP、.NET、JAVA 等代码写的代码进行检测，将检测出来的后门进行访问控制和隔离操作，防止后门的再次利用。6.3.1.4 应支持异地登录检测，根据登录

13、情况，识别常用的登录区域，当出现其他地域尝试登录情况立即预警。6.3.2 端口扫描 DB52/T 1541.52021 5 6.3.2.1 应定期对主机开放的端口进行扫描，仅开放对外提供服务的端口，降低系统被入侵的风险。6.3.2.2 应对远程控制、网络协同等敏感端口进行监控和管理。6.3.3 系统加固 6.3.3.1 应定期对主机操作系统的安装组件和安全配置进行检查，关闭无关组件和不安全服务。6.3.3.2 应合理设置操作系统密码强度策略、文件及目录权限等，及时安装操作系统补丁。6.3.4 操作日志审计 6.3.4.1 应定期查看主机操作日志，对异常日志进行原因分析。6.3.4.2 宜部署堡

14、垒机，运维人员通过堡垒机对服务器、网络设备、安全设备等进行运维操作。6.3.4.3 操作日志应留存 6 个月以上。6.4 应用安全 6.4.1 Web 应用防护 6.4.1.1 应部署 Web 应用防火墙，启用相关防护功能。6.4.1.2 应对 Web 应用进行 HTTP/HTTPS 访问流量分析。6.4.1.3 应对 SQL 注入、脚本木马、上传漏洞等网络攻击进行监测和旁路拦截。6.4.1.4 应对 Web 应用系统漏洞进行分析，并及时修复漏洞。6.4.2 网页防篡改 6.4.2.1 应部署支持国产密码算法的网页防篡改系统，启用相关功能，保护静态区域文件和动态区域文件。6.4.2.2 应对发

15、现的网页内容修改、删除等非法操作及时预警并进行保护。6.4.3 漏洞扫描 应定期对Web应用、操作系统、数据库、中间件等的密码文件、目录和文件权限、共享文件系统、系统漏洞等进行扫描，并对薄弱环节及时进行修复和处理。6.4.4 Web 业务审计 6.4.4.1 应部署 Web 业务安全审计系统，启用安全审计功能，完整记录 Web 业务系统的访问行为。6.4.4.2 业务日志应留存 6 个月以上。6.5 数据安全 6.5.1 数据生命周期安全管理 6.5.1.1 数据采集 6.5.1.1.1 应明确数据采集的渠道及外部数据源，并对外部数据源的合法性进行确认。6.5.1.1.2 应明确数据采集范围、

16、数量和频度，确保不收集与提供服务无关的个人信息和重要数据。6.5.1.1.3 应跟踪和记录数据采集过程，支持数据采集操作过程的可追溯。6.5.1.1.4 应采用技术手段对采集数据的完整性进行校验。6.5.1.1.5 应采用国产密码算法对采集数据进行加密，保障数据采集安全性。6.5.1.2 数据访问 DB52/T 1541.52021 6 6.5.1.2.1 应制定数据访问策略，明确应用系统、人员访问数据时使用的账号、权限、范围。6.5.1.2.2 应对数据的违规访问进行识别和阻止。6.5.1.2.3 应对用户进行有效安全授权和访问控制。6.5.1.2.4 应采用国产密码算法对访问人员进行身份鉴

17、别和身份认证。6.5.1.3 数据传输 6.5.1.3.1 用户访问应用系统应采用 SSL 加密方式，如 HTTPS 等。6.5.1.3.2 用户运维管理接入应采用 SSL、VPN 加密方式。6.5.1.3.3 用户访问主机应采用 SSH 方式。6.5.1.3.4 应对传输数据的完整性进行检测。6.5.1.3.5 应采用国产密码算法对传输数据进行加密。6.5.1.4 数据存储 6.5.1.4.1 数据存储应采用多重备份机制，当数据因存储载体（如硬盘）出现故障时，不会引起数据丢失和影响系统正常使用。6.5.1.4.2 应支持数据自动备份和自动还原机制，保障业务数据的可用性。6.5.1.4.3 数

18、据存储应采用基于国产密码算法的加密方式进行存储。6.5.1.5 数据使用 6.5.1.5.1 数据共享 6.5.1.5.1.1 共享数据的脱敏规则应按 DB52/T 11262016 的规定进行。6.5.1.5.1.2 对涉及隐私保护、重要敏感数据的共享，应优先采用服务接口方式。6.5.1.5.1.3 应制定数据服务接口安全控制策略，提供对数据服务接口的安全限制和安全控制措施，如身份鉴别、授权策略、访问控制机制、签名、时间戳、安全协议等，并对数据服务接口调用的参数进行限制或过滤。6.5.1.5.1.4 应对数据交换两端进行用户身份鉴别或设备认证，保证数据交换两端身份的真实性。6.5.1.5.1

19、.5 记录并保存数据交换日志，数据操作行为可管可控并全程留痕，保证审计日志的完整性和真实性，防范数据伪造、篡改或者窃取，确保任何数据泄密泄露事故及风险可追溯到相关责任单位和责任人。6.5.1.5.2 数据开放 6.5.1.5.2.1 开放数据的脱敏规则应按 DB52/T 11262016 的规定进行。6.5.1.5.2.2 应根据数据开放的需求和目标，按照最小授权原则，制定明确的数据开放访问控制策略。6.5.1.5.2.3 应采用密码技术进行数据开放过程保护，采用的密码技术应遵循相关国家标准和行业标准。6.5.1.5.2.4 应对数据开放利用情况与多源数据融合利用的风险进行评估、预警和管理。6

20、.5.1.5.2.5 应在数据开放过程中完整记录开放日志，定期进行安全审计。6.5.1.6 数据销毁 应遵循GB/T 39477-2020中6.3.4的有关要求。6.5.2 数据库防护 DB52/T 1541.52021 7 6.5.2.1 应部署数据库防火墙，启用数据库防护功能。6.5.2.2 应对 SQL 注入攻击、SQL 权限提升溢出攻击、数据库连接 CC 攻击、SQL 资源耗尽攻击、数据库口令暴力破解等进行检测和阻断。6.5.3 数据库审计 应部署数据库审计系统，完整记录数据库的操作日志，并对操作日志进行审计分析。6.5.4 数据备份与恢复 应遵循DB52/T 1540.6中7.3.2

21、的有关要求。7 标准规范 应建立网络、平台、数据、应用、运维等安全标准规范，保障平台的安全稳定运行。8 运维管理 8.1 人员管理 8.1.1 应制定运维人员储备计划，满足运维服务需求。8.1.2 运维人员应具备网络、应用、数据等安全运维能力，并获得国家颁发相关有效证书，如 CISP。8.1.3 应对运维人员进行背景审查和岗前培训，保障运维人员正常履行安全运维职责。8.1.4 应制定年度培训计划，对运维人员进行必要的技能、业务、安全意识等安全培训和能力考核。8.1.5 应与运维人员签署保密协议，内容至少包括保密范围、保密期限等。8.1.6 应对运维人员账号实行权限管理，并定期修改账号密码。8.

22、2 安全运维 8.2.1 应建立运维管理制度，包括网络与系统管理、数据和介质管理、安全管理、监控管理、检查审计、人员管理等。8.2.2 应设置专职的安全运维岗位，规定岗位职责及技能要求，包括但不限于安全管理岗、基础安全运维岗、网络安全运维岗、安全测试岗等。8.2.3 应对各系统、服务程序的运行状态进行实时监控，保障平台的正常运行。8.3 安全评估 8.3.1 平台等级评定应按 GB/T 22239-2019、GB/T 22240-2020 的规定进行。8.3.2 平台安全评估应按 GB/T 18336 和 GB/T 28448-2019 的规定进行。8.3.3 应根据等级评定和安全评估结果，对平台安全问题进行整改，降低安全风险。8.4 应急管理 8.4.1 应制定应急预案，内容包括组织体系及职责、安全事件分级分类、应急响应流程、报告流程、预防措施、保障措施等。8.4.2 安全事件分级分类按 GB/Z 20986-2007 执行。8.4.3 应按照应急预案每年开展应急演练，并记录演练情况，保存演练记录。_ DB52/T 1541.5-2021