突发事件预警短信发布平台(主系统端)采购
突发事件预警短信发布平台(主系统端)采购
项目名称 | (略) 市突发事件分区预警信息短信发布系统 * 期突发事件预警短信发布平台(主系统端)项目 | 采购类型 | 非协议采购 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
采购人名称 | (略) | 采购方式 | 公开招标 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
财政预算限额(元) | 点击查看>> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
项目背景 | 按照国家、省和市的建设要求和规划,在 (略) 市政府指示和突发预警相关单位的通力 (略) 下,由 (略) 主持建设《 (略) 市突发事件分区预警信息短信发布平台》 * 期自 * 年4 (略) 以来作为突发信息发布系统 (略) 分,主 (略) 会公众发布 (略) 市突发事件预警短信的职能。通过电信、联通、移动 * 大运营商用户的全覆盖,建立了高度集中、自动化程度高的信息发布通道,实现了对海量用户信息的及时有效下发。 随着自然灾害和突发事件风险日益增高和管理要求的进 * 步细化,对市突发事件分区预警信息短信发布平台提出了更高的要求, * 期系统在实际应用中也暴露出 * 些问题:当前仅基于地理空间的精细化发送能力无法满足业务发展的要求;对系统整体 (略) 改造提升;现有安全防护能力已不能满足 (略) 络安全形势, (略) 络安全等级保护 * 级要求,项目在建设时未覆盖深汕特别 (略) 区等问题。因此,需要通过 (略) 市突发事件分区预警短信发布平台 * 期的升级建设,以解决以上问题。通过升级改造,对系统整体的安全加固和强化,完善系统各项安全设计、运维、开发、管理等工作,降低系统受非法侵入及破坏的风险,避免安全漏洞导致 (略) 会影响,同时使 (略) (包括深汕特别 (略) 区)对自然灾害、事故灾难、公共卫生事件 * 大类突发公共事件信息的接收、处理、及时发布和反馈能力提高到新的水平,提升 (略) 市预警短信精准发布能力,增加 (略) 市精准人群预警短信发布功能和全市指定区域触发式自动预警功能,完善预警短信发送数据实时反馈与评估功能,提 (略) 台的安全保护能力,并将深汕特别 (略) 区纳入预警发布范围,实现预警信息“报得早、审得快、发得出、传得畅、收得到、用得好”。 (略) (略) 会公众能够及时获取预警信息,公众的避险能力与防灾减灾意识的提升,最大限度地保障人民群众生命财产安全。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
投标人资质要求 | (1)具有独立法人资格或具有独立承担民事责任的能力的其它组织(提供营业执照或事业单位法人证等法人证明扫描件,原件备查)。(2)本项目不接受联合体投标,不接受投标人选用进口产品参与投标。(3)参与本项目投标前 * 年内,在经营活动中没有重大违法记录(由供应商在《政府采购投标及履约承诺函》中作出声明)。(4)参与本项目政府采购活动时不 (略) 门禁止参与政府采购活动且在有效期内的情况(由供应商在《政府采购投标及履约承诺函》中作出声明)。(5)具备《中华人民共和国政府采购法》第 * 十 * 条第 * 款的条件(由供应商在《政府采购投标及履约承诺函》中作出声明)。(6)未被列 (略) 人、重大税收违法案件当事人名单、政府采购严 (略) 为记录名单(由供应商在《政府采购投标及履约承诺函》中作出声明)。注:“信用中国”、“中 (略) ”以及“ (略) 市政 (略) ”为供应商信用信息的查询渠道,相关信息以中标通知书发出前的查询结果为准。备注:如联合体投标,投标人还必须提供《联合体投标协议》(格式自定),《联合体投标协议》须明确牵头人,并载明联合体各方承担的工作和义务。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
服务类清单 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
具体技术要求 | 1. 投标人须对本项目的货 (略) 整体响应,任何 (略) (略) 的响应都被视为无效投标。 2. 招标文件中,如标有“★”的条款均为必须完全满足指标, (略) 实质性响应,投标人若有 * 项带“★”的条款未响应或不满足,将 (略) 理。 3. 招标文件中,如标有“▲”的条款均为评审的重要评分指标, (略) 分“▲”重要条款未响应或不满足,将导致其响应性评审严重扣分。 * 、项目概况 (略) 市突发事件分区预警信息短信发布平台(主系统端)主要包括主系统端应用系统、 (略) 安全管理平台升级、基础支 (略) 分。 主系统端应用系统包括短信发布平台功能升级、系统安全升级、基本功能升级、组网及监控功能、系统的可拓展性功能 * 大方面, (略) 市发展的需要(发送能力覆盖深汕特别 (略) 区)以及突发事件分区预警信息发布的新需求对发布平台做出了全方位的设计与规划,通过人工智能技术等手段充分实现各项业务功能的智能化,实现突发事件发布系统和突发事件短信发布平台的 * 体化建设,采用目前先进的微服务架构打造成为 * 个 * 体化的的综合突发事件预警信息发布平台。 (略) 安全管理平台按照国家信息安全等级保护标准作为方案设计依据,基于有效的安全评估,从安全技术、安全管理、安全运维 * 个层面建立起科学的结构化的信息安全保障体系,从而保证业务系统能够 (略) 和不断完善和发展,适应 (略) 市突发事件预警短信发布平台不断扩展的业务应用和管理需求,并通过 * 级等保测评。 (略) 主系统端基础支撑系统建设,采购 * 批系统服务端、系 (略) 络安全设备,实现对主系统端应用系统、安全管理平台升级的基础支撑,保障突发事件分区预警信息短信发布平台 * 期系统落 (略) 。 其中针对5G消息预警信息发布、全网发布 (略) 理、基于 * 维地理信息的发布方式、全渠道数据接口和反馈机制、系统安全保 (略) 了深化设计。 * 、项目建设目标和内容 2.1 项目目标 ( * ) 建成 * 种自动精细化发布能力,实现自动定点发布预警信息、主动触发发布预警信息、针对特定人群发布预警信息、5G消息预警信息发布。 ( * ) 建成智能化发布能力, (略) 发布 (略) 理、指定区域触发式自动预警、基于 * 维地理信息的风险等级判识技术。 ( * ) 建成气象灾害风险监测预警秒级发布能力,结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,优化审核流程,做到自动生成、自动决策、人工审核后的秒级发布。 ( * ) 全面提升突发预警信息发布管理能力,形成突发预警信息发布评估评价机制、建设发布数据多维度数据统计和展示模块、建立和完善全渠道数据接口和反馈机制;逐步健全预警信息公开机制和深汕区预警信息发布机制。 ( * ) 提升信息安全级别至等保 * 级,项目建成后要求最终通过第 * 方安全测评机构的等级保护 * 级保障能力测评。 2.2 项目建设内容 2.2.1. 主系统端应用系统 2.2.1.1 短信发布平台功能升级 2.2.1.1.1地理范围精准发布能力提升 精准发布能力 * 期升级的主要功能内容包括自定义任意区域预警制作、自定义任意区域突发预警短信协议扩展、发送区域优先级智能调度、基于地理空间及事件属性的突发事件影响智能分析、自定义任 (略) 关升级等相关子模块,相关模块主要功能如下: * 是自定义任意区域预警制作模块,该模块是系统的核心交互模块,负责实现系统短信预警任务的辅助制作、编辑、审核、查询等功能,在保留 * 期的选择方式上,增加自定义选择方式,解决之前无法实现高精度的任意多边形区域预警信息的发送问题。实现自定义多边形区域发送,支持最小分辨率精度1平方公里。 * 是自定义任意区域突发预警短信协议扩展。当所选的区域为多个地理空间不相连的多边形自定义区域时,由于自定义任意区域突发预警短信发送涉及到同时调用 * 大运营商的接口,因此本次升级需要对短信 (略) 重新升级定义,使之可以满足自定义任意区域发送的业务目标。 * 是气象灾害风险监测预警发布功能,结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,优化审核流程,做到自动生成、自动决策、人工审核后的秒级发布。从而缩短整体流程,极大提高发送的决策和响应速度。 (略) 数据超灾害风险阈值, (略) (略) 智能生成发送区域和突发预警信息。 * 是发送区域优先级智能调度功能, (略) 发送的区域较大时,由于时效不 * ,且短信通 (略) 有 * 定的延时,而某些突发预警事件是随时间和环境因素的影响会发生变化;实际业务会需要对临近突发事件发生地点范 (略) 优先发送,因此需要根据事件影响、地理属性、相关要素等, (略) 分解,对分解后的多边形智能编排不同的优先等级,确保在受影响路径上距离越近的区域用户可以更早更及时的收到预警信息,争取宝贵的应对时间。 * 是基于地理空间及事件属性的突发事件影响智能分析,通过结合空间分析、重点防护区缓冲区分析等地理分析模型,在 * 维地理信息引擎基础上,完成对典型灾害信息空间分析流程的建模。当典型灾害发生后,系统通过GIS空间分析,智能判断灾害影响范围等级区域,以供值班人员参考。 * 是自定义任 (略) 关升级,由于相关的地理范围精准能力提升, (略) (略) 关已经不能适应 * 期的需求,通过自定义任意区域突发预警短信协议扩展后,协调 * 大运营商升级现 (略) 关,使之满足 * 期各种灵活发送的要求。 * 是实现发布区域划定的自动约束审查。由于运营商平台对短信发布范围区域大小和数量有 * 定的限制规则,因此需要系统对短信 (略) 自动约束筛查,提示用户修正不合理的区域范围。自动约束审查针对 (略) 筛查,例如不能单独的圈选出某个 (略) 门,例如不能单独的选出市 (略) 发送, (略) 络信息存在安全隐患。 2.2.1.1.2特定人群精确靶向发送功能 * 期系统只能按照地理位置发送预警信息,在 * 些 (略) 景下, (略) 限,但是学生及家长并不是聚集在某个特定的区域而是分散在全市。所以需要按照某种属 (略) 分类,针对特 (略) 发送。特定人群靶向发送功能共分为 * 个子模块,包括人群数据采集模块和面向靶向人群突发事件短信制作与发布模块及自定义靶向人群模块。 人群数据采集模块是实现特定人群靶向发送功能的基础核心模块。人群数据采集模块首要目标是特定人群数据采集方法的建立,并且根据方法建立相关的采集模型,采集功能的设计采用标签方 (略) 职业识别,然后按照采集模型针对教育、医疗、渔业等 (略) 采集,同时还需要设计定期或触发任务对 (略) 更新,由于人群身份的复杂性, (略) 采集的 (略) 对比 (略) 采集人群数据的准确性;对以保证特定人群的靶向价值,在系统中通过web的方式对人群数据的 (略) 管理和触发,在 * 期项目中没有做特定人群数据的区分,导致突发事件发生时只形成区域人群的广播,而没有根据事件对职业人群影响 (略) 区分,因此本期系统将特定人群数据采集和分类作为重要精细化作业 (略) 建设。 面向靶向人群突发事件短信制作与发布模块实现首先选择确定要发送的特定人群,例如学生人群、户外活动爱好者等,综合考虑预警的等级、种类、风险程度、发展趋势以及特定人群和涉及的地理空间范围,例如台风来临,需 (略) 停课预警,这里选择的特定人群就是学生,学生是分布在全市的,但是还可以进 * 步指定区域属性,例如只是对沿海区 (略) 停课预警,这样发送的针对性更强,特别是还可以和上 * 节提到的任 (略) 组合发送,则突发预警的靶向更明确、精准程度更高。 自定义靶向人群模块是平 (略) 、委、 (略) 灵活发送需要的功能模块,各局、委、 (略) 登入系统,填写发送的内容、时间、范围、级别、目标人群数据(手机号码清单列表)等信息后,通过系统管理端的审核流程后, (略) 短信的发布。自定义靶向人群作为高精度模式是特定靶向人群发送的有效补充,可以 (略) 、委、 (略) 信息多头发布、重复发布的难点和问题。 本期计划实现具体特定人群包括:学生家人人群、海上作业人群和和来深境外人群,其中受众较广的人群通过LBS服务大数据分析来智能筛选和确定,部分要求目标绝对准确、且难以通过LBS数据得到结果的人群,则需要相关单位机构提供原始人员信息,系统 (略) 使用。 2.2.1.1.3与覆盖深汕特别 (略) 区对接 * 期系统建设时深汕特别 (略) 区未纳入覆盖范围。深汕特别 (略) 区依山面海,拥有漫长的海岸线,台风等不良气候频发,突发事件分区预警发布系统的缺失,将不利于深汕特别 (略) 区群众应对各种突发 (略) 会发展,将会对人民生命财产产生严重隐患。 * 期覆盖深汕 (略) 区将解决这个隐患。与深汕特别 (略) 区对接主要包括以下重要工作: * 是对深汕特 (略) 及用户 (略) 采集入库,并形成增量的用户分布情况数据库,用户分布情况数 (略) (略) 位置及号码 (略) 关联。 * 是对 (略) 区对应街道的边界信息应先予以确定, (略) 及用户数据时需要 (略) 的GPS经纬度 (略) 计算、统计、分析,做到高准确度和高效率的获取最新的用户分布情况基础数据。 * 是对深汕特别 (略) 区 (略) 初始化升级,包括深汕特别 (略) 区地图底图采集与制作,多种地图底图、并且支持最大缩放等级 * 级;还需 (略) 政规划对 (略) 区分镇规划的边界数据采集与制作,实现区域分级管理; (略) 、景区、重点 (略) 所 (略) 所影响边界的采集和制作;还需要针对深汕特别 (略) 区的特点,定义突发事件相关影响要素的集成和展现;完成数据采集工作后,对所采集的深汕特别 (略) 区 (略) 交叉对比验证, (略) 有采集、加工数据的正确,同时保证符合精度要求。 2.2.1.1.4气象灾害风险监测预警智能发布 结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,优化审核流程,做到自动生成、自动决策、人工审核后的秒级发布。从而缩短整体流程,极大提高发送的决策和响应速度。 (略) 数据超灾害风险阈值, (略) (略) 智能生成发送区域和突发预警信息。 与短临系统(PONDS)、预警预报业务 * 体化平台等业务联动,结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,自动进入预设的发布流程,人工审核后的快速发布,解决自动在灾害影响区域面向基层防灾人员精准发布预警信息。 2.2.1.1.5预警信息实时反馈和评估 目前 * (略) 端是采用调用接口的方式采集运营商发送状态报告信息,并入库生成报表。由于 * 大运营 (略) 理环节均 (略) 系统中实现,导致了反馈数据不稳定甚至超时等各种问题,主系统端比较难以获得准确、实时的发送反馈报告, (略) 监控的实效性和准确性有 * 定滞后。 * 期升级将采用主动式 (略) 状态,这样可 (略) 的时效性统计指标更加客观真实,比如满足发送成功数达到预计发送人数的 * %即认为发送完成,对于预警任务的影响评估有重要意义。 预警信息实时反馈和评估在 * 期平台中除了改善 * 期的统计时效以及准确性问题外,还需要合并统计突发事件预 (略) 站、广播、电视台、手机短信、手机客户端、微博、微信、热线电话、户外LED显示屏、交通诱导屏、车载电视等 * 种预警信息快速发布渠道的实时反馈,形成 * 套科学有效的办法,对预警 (略) 综合、量化的评估,以更好的 (略) 门或值班人员今后的预警信息发送任务的策略制定提供基础数据支撑。 2.2.1.1.6全市指定区域触发式自动预警功能 * 期系统的建设以实现短信发送作业为主,为进 * 步提升预警效率, * 期建设增加了全市指定区域触发式自动预警功能的建设,实现特定区域触发预警的智能机制,开发内容包括触发式自动预警条件配置管理、触发预 (略) 理和触发预警发布、编辑、归档功能。 触发式自动预警条件配置管理用于定义触发条件和规则,包括服务器端规则配置和web管理配置页面的开发,并且需要将自动触发预警任务集成到主系统的短信发布作业流程中; 触发预 (略) 理是由后台监听 (略) (略) 理,监听程序获取到触发信息,根据规则判断其触发等级、类别、目标,自动生成预警任务; 触发式自动预 (略) 人工介入,实施编辑确认、审核、发布等工作流程,包括自动预警发布、编辑、归档功能的前端页面和后台服务;并集成到主 (略) 流程; 2.2.1.1.7地理信息引擎升级 * 期平台使用的是 * 维地图地理信息引擎,展示效果比较单 * ,功能相对简单有限。 * 期将升级为 * 维地理信息引擎,可以为突发事件短信的制作者提供更为全面、 (略) 市地理信息,有助于对于要发送的信息范围、 (略) 综合性评估,此外, * 维空间地理信息引擎后台还可以充分利用建筑物分布、对应的人群密度等 (略) 智能分析后,为突发事件发送决策提供可靠的辅助信息。地理信息引擎主要包括以下几个方面的升级: * 是地理信息引擎升级,采用 * 维地图来提供更丰富的展示界面。 * 维地图是目前发展的 * 个主流方向,目前主流的商业地图都支持 * 维地图。 * 维地图由于具有空间感可以给操作人员提供更多的地形地貌等信息,有利于操作人员更好的做出预警决策。 * 维地图由于数据量大 (略) 理及大量的带宽,近年 (略) 络技术的飞速发展为 * 维地图的采用打下了良好的基础。 * 维引擎升级采用Cesium引擎作为基础框架,Cesium是 * 个基于JavaScript编写的著名开源地图引擎。其采用MIT许可协议,允许被授权人有权利使用、复制、修改、合并、 (略) 、散布、再授权及贩售软体及软体的副本。 * 是与数字 (略) 空间基础信息平台集成。 (略) 空间基础信息平台以3S(遥感RS、地理信息系统GIS、全球定位系统GPS)等技术为基础,整合 (略) 市空间基础信息, (略) 门、企业、公众提供空间信息在线共享交换服务。 (略) 市空间信 (略) 格标准已 * 日发布, * 日开始实施, (略) 市空间信 (略) 格标准规定了 (略) 市统 (略) 格的术语和定义、划分原则、 (略) 格数据。它的内容包括: (略) 格单元划分原则,网格划分的技术流程,成果表达,网格编码的规则和方法, (略) 格单元数据要求等。 为保护投资,统 * 标准,充分利用现有成果,本次升级需要充分考虑地 (略) 分与数字 (略) 空间基础信息平台集成,避免重复制作 * 维、 * 维数据,充分利用数字 (略) 空间基础信息平台已有的 * 维、 * 维地理信息,包括地名标注、行政区域图、交通图、卫星影像地图、 * 维建筑物模型等。 在本次地理信息引擎升级中,保持与现有空间数据标准统 * 衔接,充分利用现有数据的建设成果,平台支持集成数字 (略) 空间基础信息平台的相关数据,如政务版电子地图服务、专题地图服务、在线地址匹配服务等开放的服务接口和数据。 集成的方式主要为数据集成, (略) 络地图服务(WMS)请求数字 (略) 空间基础信息平台返回相应的地图(包括PNG,GIF,JPEG等栅格形式或者是SVG和WEB CGM等矢量形式)。 (略) 络协议HTTP,所支持的操作是由URL定义的。 * (略) 政网格化管理融合。网格化 (略) 政区域按照 * 定的标准划 (略) 格, (略) 格成为政 (略) 会的基本单元, (略) 市管理和数字化平台,将城市管理辖区按照 * 定的标准划 (略) 格的管理方式。 (略) 市目前已 (略) 了网格化管理的相关标准。 (略) 格金字塔模型规范了各区、街道、 (略) 格化定义。 (略) 格金字塔骨架 (略) 格、 (略) 格和统 * 。 (略) 市突发事件分区预警短信发布平台作为 (略) 市突发事件发布管理的支撑业务平台承担了自然灾害、事故灾难、公共卫生事件 * 大类突发事件的发布任务,是 (略) 门 (略) 和数 (略) 平台,为充分与 (略) 格化管理体系相融合,做到管理单元可直接对接市级其他相关业务平台, * 期短信平台需要按 (略) 市统 (略) (略) 网格化定义,遵循 (略) 市统 (略) 格编码的规则和方法, * 期 (略) 格化管理 (略) 格化的配置管理功能、运营商数据接口以 (略) 格化选择、制作、 (略) 等功能。 2.2.1.1.8实现富媒体发送功能 (略) 市目前已经 (略) 络全市覆盖,随着5G建设的推进5G终端的普及,本期建设需要全面实现对5G消息的支持,实现基于5G的突发预警信息的发布功能,通过富媒体消息实现基于手机原生系统的格式化解析,按预定的卡片格式、字体大小颜色展现不同类型、等级的突发事件预警信息内容。 2.2.1.1.9突发事件预警信息平台 * 体化建设 目前 (略) 的突发事件预警信息发布由突发事件预警信息和突发事件预警信息短信发布平台两个平台组成,突发事件预 (略) 站、广播、电视台、腾讯TIPS弹窗、手机短信、手机客户端、微博、微信、热线电话、户外LED显示屏、交通诱导屏、车载电视等 * 种预警信息快速发布渠道。由于手机短信渠道的安全等级要求更高以及影响覆盖的范围极为广泛, * 期的短信发布 (略) 络专线与运营商对接按照 * 级等 (略) 建设的,与突发事件预警信 (略) (略) 段和服务器上,两者之间通过接口实现数据的互联互通。 本期建设需要针对性设计将两个 (略) 合并,并采用微服务架构设计,融合两个系统的核心功能,统 * 按等保 (略) 设计和重构,使之满足突发事件预警信息综合发布的集约性、安全性、便利性、数据的 * 致性等各方面要求。 2.2.1.2 系统安全升级 2.2.1.2.1应用安全升级 * 级等保要求采用两种或两种以上组合的鉴别技 (略) 身份鉴别,且其中 * 种鉴别技术至少应使用动态口令、密码技术或生物技术来实现。因此本项目除了需要传统的用户名密码登录方式外,需要升级用户管理及身份验证策略,使之达到 * 级等保的技术规范要求。本期计划采用生物特征识别(指纹识别)的技术作为第 * 种用户身份鉴别技术。 身份鉴别的相关安全要求主要通过用户管理模块升级来实现,支持生物识别特征的录入与配置管理功能, * 期系统需要采用生物识别设备(指纹设备)作为加强的第 * 种身份识别技术,开发识别设备页面控件,调用设备的SDK开发支持H5页面的插件、控件; (略) 页端生物设别设备的调用,从 (略) 要求的1+1多种验证机制。 * 期平台采用了传统的基于密码口令、令牌Token的认证模式,按照安全等级 * 级的要求“应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技 (略) 身份鉴别,且其中 * 种鉴别技术至少应使用密码技术来实现。”,本期平台需要采购指纹采集与设别设备,补充 * 种鉴别技术使之满足 * 级等保的要求。 2.2.1.2.2日志审计功能升级 实现事务日志(日常事务操作,如:预警短信息的发、改、查等事件,不限于系统登录、退出。)记录功能, 集中审计可综合各种安全设备的安全事件,以统 * 的审计结果向用户提供可定制的报表, (略) 络安全总体状况。 统 * 日志审计管 (略) 系统安全监测,并为安全计算环境、安全区域边界、 (略) (略) 统 * 的监控与告警。 日志集中审计内容包括: 1、日志监视:实时监视接收到的事件的状况,如最近日志列表、系统风险状况等;监控事件状况的同时也可以 (略) 参数,以配合 (略) 络的状态;日志监视支持以图形化方式实时监控日志流量、系统风险等变化趋势。 2、日志管理:日志管理实现对多种日志格式的统 * 管理。通过SNMP、SYSLOG或者其它的日志接口采集管理对象的日志信息,转换为统 * 的日志格式,再统 * 管理、分析、报警;自动完成日志数据的格式解析和分类;提供日志数据的存储、备份、恢复、删除、导入和导出操作等功能。日志管理支持分布式日志级联管理, (略) 的日志数据可以发送 (略) 进行集中管理 3、审计分析:集中审计可综合各种安全设备的安全事件,以统 * 的审计结果向用户提供可定制的报表, (略) 络安全总体状况,重点突出,简单易懂;生成多种形式的审计报表,报表支持表格和多种图形表现形式;用户可以通过IE浏览器访问,导出审计结果。可设定定时生成日志统计报表,并自动保存以备审阅或自动通过邮件发送给指定收件人,实现对安全审 (略) 理。 2.2.1.2.3数据库安全升级 * 期平台数据库安全升级目标主要为通过多种手段实现对数据库存储的安全设计、规划、运维, (略) 有数据的安全,最终达 (略) 规定的安全标准,具体安全升级包括如下几方面内容: 1.数据库安全权限设计及改造 通过不同的用户权限设计实现不同等级的存取控制管理权限,对于绝无必要的用户,清理出数据库;规范数据库管理软件,实现管理软件的标准、统 * 化。 2.数据库日志安全备份与审计功能 建立备份机制,对于业务系统搭建NBU、DP、DSG等备份管理软件,针对业务情况、系统压力、带库资源等创建合适的备份策略, (略) 突发事件发 (略) 备份。 3.数据库防篡改功能实现,表结构增加校验码,实现存储的防篡改校验功能,保证关键数据的安全性,数据库必须提供防篡改功能设计,增加校验验证方式,以防止关键信息被恶意篡改从而导致系统发送了被人为篡改后的信息。 4.采用数据 (略) 理,在各种不可预见的事故导致数据库损坏数据丢失等故障后,可及时恢复最新的备份数据。 5.数据库配置文件以及通讯端口采用 (略) 理;防止连入数据库的应用程序存在后门,造成数据库安全隐患,所有数据库连接必须使 (略) (略) 理,以保证数据传输过程中的安全性。通过使用门户监控登录数据库,禁止对数据库的直接操作。对已经 (略) (略) 规范化、统 * 化的管理, (略) 权限复核操作, (略) 属IP、 (略) 权限梳理工作。 (略) 安全培训,增强员工的系统安全观念,做到细心操作。 6.数据库配置文件采用D (略) 加密,在应用 (略) 解密,杜绝数据库连接信息明文存储在相关系统文件中,导致数据库相关账户、密码泄露,造成安全隐患。 7.数据库数据加密存储,加密算法使用SM1、SM2、SM3、SM4等国密算法;对于系统关键的表关键数据,使用加密算法使用SM1、SM2、SM3、SM4等 (略) 存储。 2.2.1.2.4系统管理安全升级 由于项目 * 期的稳 (略) 署要求的提升,要求系统管理 (略) 升级,以达到 * 级等保的安全防护要求,具体如下: * 是通过构建新的负载均衡系统建立有效的负载均衡机制,可以采用多种负载均衡机制,将大量的并发访问或数据流量分担到多台 (略) 理,进而减少用户等待响应的时间, (略) 理能力。 * 是实现对 (略) 状况的健康检查机制,确保提供服务的正确。全面的健康检查机制不仅可以有效的监控到服务进程的有效性,即对应用端口提供服 (略) 健康检查,同时,对于 (略) 错误也同样可以提供有效的检查机制,从而避免了客户端可以访问到服务器,但得不到响应的情况的出现。 * 是应用程序保护功能;通过额外的守护进程对应用 (略) 保护,防止系 (略) 文件在未经授权的情况下被修改。应用程序保护功能还包括恶意代码防范管理,建立恶 (略) ,进行防恶意代码软件的统 * 管理,并根据情况建 (略) 。恶 (略) 实现:杀毒策略统 * 集中配置;自 (略) 恶意代码库升级;定制统 * 客户端策 (略) ;进行集中病毒报警等。 * 是系统初始数据管理配置功能安全升级;应用系统备份与恢复:应用系统的定期备份与恢复管理,识别需要定期备份的重要业务信息、软件版本,规定备份信息的备份方式、备份频度、存储介质、保存期等;根据数据的重要性及 (略) 的影响,制定数据的备份策略和恢复策略, (略) 备份与恢复策略。 * 是对系统安全定期巡检并生成巡检报告;通过系统管理员对系统的服务器、网络设备、安全设备、 (略) 统 * 的定期巡检, (略) 概要、系统异常分析、系统安全警报等,生成详实的巡检报告,跟踪并保障系统的正 (略) 。 * 是及时对操作系统、应用层支撑 (略) 升级管理; (略) 补 * 管理, (略) 系统补 * 安装。注意应首先在测试环境中测试通过,并对 (略) 备份后,方可实施系统补 * 程序的安装。 2.2.1.3 基本功能升级 2.2.1.3.1系统管理功能升级 由于使用突发短信平台群发信息的发送单位逐步增加,不可避免的涉及到 * 些具体业务审批流程的调整和变更,本期建设需要增加短信发布主系统端审批流程自定义配置管理,管理员可动态配置发布流程及节点以及采用的验证方式等,使之适应不同发送主体、不同类别、不同级别的发送业务流程。 本项目需要与 * 大运营 (略) 集成,在软件开发工程中, (略) * 些版本的迭代,因此本平台的生产 (略) (略) 严格的隔离。为防止在软件开发、调试过程中,产生误操作,本期建设需要增加 * 个生产与测试环境同步控制模块,同步控制模块采用软硬件结合的手段,防止在测试环境调试误触发导致接入生产环境而错误发送短信。 2.2.1.3.2整体界面升级 (1)项目采用模块化的开发模。在体系结构方面,总体采用前后端分离的微服务架构来实现。后台主要用于各类突发事件的影响分析、发布制作、审核、跟踪、监控、反馈统计等业务数据流程操作。前端则通过良好的交互式设计,在满足功能要求的同时做到简洁、美观,安全性强。 (2)在保障系统稳定性和高效性的基础上,依据项目模块 (略) 统 * 设计,系统交互设计包括原型设计和高保真界面设计。 (3)系统会产生大量的图形数据以及大数据分析结果数据,在设计阶段需要考虑前端客户浏览器的承载能力,做到各类图形、报表、地理栅格图片等数据流畅、快速的加载和展现。 (4)客户端作为B/S结构程序(前台程序),为用户的操作平台。它将系统的操作界面与复杂业务功能实现合 * 为 * ,实现各种数据的人机交互的可视化展示;系统均衡地将任务分配在服务器端与客户端,各司其责, (略) 。 (5)充分利用HTML5的优势对 (略) 整体优化,合理优化显示界面内容并提高人机交互操作的便捷程度。 (6)短信制作编辑管理界面、发布监控界面、统计报表以及其他系统界面。短信制作编辑管理界面最主要升级是要可以支持任意区域的自定义矩形及精准发布人群,并且可以支持 * 维与 * 维的操作界面。其他的如监控界面和统计报表等也要适应这 (略) 改动升级。 2.2.1.3.3 突发 * 张图功能升级 突发 * 张图是突发预警短信发布系统的总览入口界面,系统基于统 * 标准的地理信息系统为核心,以电子地图为主体架构,叠加突发应急管理相关资源、风险隐患信息情况、实时监测监控、各类突发事件影响过程、突发事件各类渠道包括短信发送等反馈状态和发送进度等数据图层。 (略) 中的突发事件实时的反馈,这些数据通过后端收集、排序、分析,增强准确性和精度,通过大数据可视化的各种技术手段,以图文并茂言简意赅的方式集中显示在大屏幕上。突发 * 张图功能升级主要包括了地理引擎从 * 维升级到 * 维以及整体界面的升级。同时也对现有服务 (略) 升级,目前服务端主要采取了轮询查询的模式,新升级将数据的刷新技术方式统 * 改为Websockets方式实现,Websockets方式不仅可以优化现有的接口效率,还可以大大降低客户端的资源消耗,提升用户体验和使用效率。 2.2.1.3.4系统提醒功能 全方位监控,不但包括对运营商的监控,也包括对主系统端的各种监控, (略) 状态、网络状态、机房状态等的监控。当发现有异常时能够以邮件或者短信、微信、浏览器声音警告弹窗的方式通知主要管理人员,确保系 (略) 。实际上,主系统端将成为 * 个预警 (略) ,对本系统有关的各种设备、网络、短信 (略) 全方位的监控管理,确保系统安全稳定可靠,能够真正的为突发事件预警做好技术保障。 2.2.1.3.5共享方案升级 (略) 市突发事件分区预警短信平台是作为全市的面向广泛市民而建设的预警渠道,在业务和数据上 (略) 、办、委等政府的业务或业务系统互连互通,本期建设为最终可以解决消除信息孤岛多头发布的问题,实现全市统 * 平台发布;因此,在保证信息安全的前提下,需要从系统层面、业务层面、数据层面多方面考虑数据的互通共享。 数据层共享主要是指相关突发事件预警信息及发送反馈报表上传到 (略) 的共享。这个是基础层面的共享,依 (略) 对信息系统建设的要求,做到最基本的业务数据共享。 (略) 过程中通过与运营商接口对接可以采集、获取反馈数据,其中可供共享的数据包括用户分布数据和突发事件预警短信发送统计数据。 系统级共享是指用 (略) 主系统端与其他需要接 (略) 系统集成和自动接入的相应服务端口,为各单位现存的系统 (略) 的API及相关协议标准,以达到快速集成的目标,这种方式接入单位不需要人工 (略) (略) 操作,而是按照各单位 (略) 操作,操作完成后,系统调用后端API实现预警信息的提交。 2.2.1.3.6与业务系统的深度对接 目前发送的短信预警,其中自然灾害类的占据了比较大的比例,自然灾害又以气象灾害为主, (略) 内建设有相关预报预警系统。由于目前没有直接与之集成, (略) 值班人员发布信息时,需要手动或复制粘贴发布内容以及目标区域等,效率较低且容易出错。本期升级后,系统与其他灾害信息系统集成的功能主要通过消息服务的机制,制定统 * 的消息服务协议,连接到各个灾害预警信息来源系统,自动实时的接收灾害信息,并按照设计的业务逻辑将原始的灾害信息通过智能化手段转化为最终预警信息的草稿, (略) 页、短信等方式通知到突发值班人员予以人工确认后, (略) 相关操作。与其他平台集成后,后台任务实时跟 (略) 中心数据库,获取灾害信息,为自动预警触发功能提供基础,同时提升了预警信息发布中转环节的延时,保证了信息在流转过程中的准确性,不会因为人为的错误导致错发误发预警信息。 与系统之间的通讯主要采取定义统 * 的标准协议来完成,遵循《国家突发事件预警信息发布系统管理平台与终端管理平台接口规范(GBT 点击查看>> 7)》和《突发事件预警信息发布系统数据交换规范》(SZDB_Z * — * )》等。 2.2.1.4 组网及监控功能 2.2.1.4. (略) 服务 系统 * 期基于应用特点的考虑,将整个系统的流程设计为任务管 (略) 两段式结构,因此系统和设备也是根据这 * (略) 部署;主系统端作为预警任务的发起方,完成内容编辑审核以后形成发给运营商的任务指令,由运营商端应用理解 (略) 执行, (略) 情况定时反馈给主系统端,这 * 结构优点是业务分工清晰明了、流程简单,缺点是任务的管理精度小,数据反馈不及时,执行过程对于任务发起人来说是 * 个系统黑盒子。 * 期平台将采用以主系统端应用为核心的 (略) 署方式, (略) 络以及相关监控微服务组件,对整个平台包括运营商端的基础支撑的 (略) 组网以及监控服务,模块可实时对 (略) 络状况、核心服 (略) 健康检查, (略) 络或服务节点发生故障时,可以第 * 时间发出警告信息,提醒值 (略) 理。 2.2.1.4.2监控客户端 监控客户端程序:客户端需针对不同的服 (略) 定制开发,读取每个系统 (略) 参数,包括各个系统与装备间的通信状态、 (略) 状态、数据到报状态、机房环境参数、经过质控后的数据状态、 (略) 状态等。客户端需要具备以下功能: 服务监控是监控客户端重要的环节,服 (略) 络状态、资源使用情况、各项参数指标是否正常等极大的影响着数据能否稳 (略) 理。服务器监控的内容包含服务器基本配置信息 (略) 状态监控以及异常信息采集。 (略) 理机(服务器)常见的监控类别及参数表: 表7?6服务器监控信息表
监控 (略) (略) ,按照预设的规则定时对读取服务器各项参数、配置状态并推送到监控服务端服务器,进 * 步 (略) 数据监控信 (略) 理。 2.2.1.4.3监控服务器 监控服务端主要对各个客户端传输回 (略) 接收和管理, (略) (略) 质量分析。服务端需要具备以下几个功能。 1.信息采集接收,信息采集接收服 (略) 有客户端建立TCP/IP连接, (略) 有客户端采集发送的警告信息、监控信息,在收到客户端数据后, (略) 解析并完成分类,按照预设的存储规则,存储到数据库中,同时通知后续的质量控制 (略) (略) 理分析。 2.客户端管理,客户端管理是监控服务端通过远程方式有效管 (略) 的客户端的有效手段。使用远程管理的方式管理人员只需要在值班室 (略) 有客户端软件的管理,而不需要对每台客 (略) 现场的管理配置。 3.监控服务端负责接收客户端推送的相关 (略) (略) 理,对不同的信息类别,如 * 般信息、配置及状态信息和警告信息等,分别存入指定的数据库中,同 (略) 需要系统接口,对信息予 (略) 理。例如警告信息则需要调用提醒接口最终把相关信息推送到值班人员。 2.2.1.4.4 网络监控 网络监控, (略) 与 (略) 网络内的 (略) (略) 的监视和控制,应包含如下基本功能:网络状态监控、流量监控、 (略) 分离流量带宽限制、并发连接数限制、FTP命令监视、TELNET命令监视、 (略) 为审计、操作员审计、软网关功能等。 网络监控的目的, * 在于安全, (略) 为监控可以准确记录各终端的操作时间以及日志,保 (略) 安全。 * 在于故障诊断, (略) 与运营商是通过 (略) 组建的 (略) ,其网络连接比较复杂, (略) 络状态监控可以迅速定位故障点,对 (略) 络故障予以快速解决。 网络监控除了输出各类监控报表外, (略) 络拓扑状态图,通过图形的方式,简单快捷 (略) 络的状态。 2.2.1.5系统的可拓展性功能 2.2.1.5.1发送目标地理区域和精度的可拓展 (略) 市未来发展的变化,发送目标地理区域采用可拓展设计实现,从整体设计上应做到无论后续 (略) 市做任何区域的调整、发送区域范围定义精度的进 * 步升级,都可以轻松通过后台管理工具实现同步的数据变更空间范围和精度的配置操作,充分满足目标发送目标地理区域、精度的可拓展性需求。 通过配置管理模块实现目标发送地理区域的任意扩展,包括在地理上相连或不相连的区域,通过地理空间的可配置管理,可以实现对目标发送地理范围的参数化配置,通过管理端新增、删减、变更地理空间的定义,同时还支持边界信息的GEOJSON格式导入、导出功能。地理区域的管理功能还包括对子区域、街道、 (略) 、POI数据的管理与维护功能。同时本期平台定义的最小发送范围为1平方公里司地理区域,随着 (略) 络的建设,可以预见在不久的将来,基站密度将大大提升,由此基础数据可能从现在的1平方公里精度升级到 * 米甚至 * 米。在系统接口规范设计以及前端操作限制策略上,均采用可配置文件,通过调整配置文件的参数,做到灵活适应不同的区域精度。 2.2.1.5.2靶向人群的可拓展功能 本期设计目标的靶向人群定义主要人群为学生和家长人群、渔业海上沿海作业人群、境外来深人群。而随着需求和系统在全市的推广,必然会涉及到更多种类的人群定义,因此需要实现人群的灵活定义功能,系统可以通过配置增加、删除、变更人群的定义,包括人群标定的方法以及管理主体。标定的方法主要包括实现采用大数据算法基础参数配置标定,和同时精确人群数据标定两种。采用大数据算法在系统层面上,要实现算法的可扩展升级、 (略) 署等特性,允许在需要的时候通过完善相关算法达到标定精度提升的目标。精确人群标定则主要以采集相关人群的号码资源,定期采集统 * 入库、集中管理应 (略) ,精确的人群数据主 (略) (略) 会团体组织提供原始数据,平台通过提供接口管理界面或系统接口或人工导入方式向导充分满足人群原始数据的新增、更新、清理等业务需求,, (略) 委办人群数据的导入导出等管理功能。特定靶向人群的可拓展性在 (略) 重点设计,考虑多种可能性,通过制定统 * 规范的数据交换标准、数据格式、接口参数来实现。 2.2.1.5.3与预警发布单位、运营商和其他系统集成的可拓展功能 * 期采用多单位多用户设计,上线后可满足 (略) 市其他发布单位、组织的突发事件预警信息的发布需要,登录到本平台使用系统的单位会增多,因此 * 期涉及上需要满足其他用户单位的拓展性要求, * 期通过升级平台的组织管理、用户管理、鉴权管理、分级安全管理等模块来实现使用单位的新增、配置;从而达到使用单位( (略) 门)的可拓展性。 此外,主系统端实现上述可配置、扩展拓展性后,不可忽略的还有对接 * 大运营商接口的配置与扩展,因此在接口的设计和实现上,要充分考虑接口规范的适应性,包括接口本身的协议定义以及运营商配置功能。 主系统端作为 (略) 市突发事件分区预警短信发布的中枢平台,目前已 (略) 业务 * 体化平台、市应急发布平台、 * 大运营商子系统、等系统平台实现系统接口的集成与对接,随着进 * 步在全市其他单位的推广使用,可能接入的系统会越来越多。因此在适应与其他系统集成拓展性方面要充分从基础业务、数据交换、门户对接等几方面考虑对与其他系统集成的拓展性。在解决方案上,本系统属于主系统,需要针对可能出现的 (略) 框架支持设计,制定完备、清晰的接口标准,规范化系统集成技术标准;提供主要语言SDK以及API调用说明手册等各类技术文档,从而为后续需要集成的其他单位的系统平台提供快捷、稳定、简易的系统级集成和数据交换方案。 通过 (略) 市突发事件预警信息发布系统,本平台可以实现与市政府管 (略) 等系统的接入。 与系统之间的通讯主要采取定义统 * 的标准协议来完成,遵循《国家突发事件预警信息发布系统管理平台与终端管理平台接口规范(GBT 点击查看>> 7)》和《突发事件预警信息发布系统数据交换规范》(SZDB_Z * — * )》等。 2.2.1.5.4预警短信语言的可拓展功能 语言可拓展性主要是指根据 (略) 属国籍,可以相应发送对应母语的短息内容。 (略) 作为具有国际影 (略) 市,与世界各地的沟通日益增加, 常驻或临时来深的外籍人士也是 * 个不可忽略的群体,为使在深外籍人士及时、准确地能接收到突发事件预警信息,保证信息公开透明,保障外籍人士知情权, (略) 短信发送时,需要考虑短信内容的多语言支持。针对 (略) 日韩居民数量大特点,在实现中英文预警内容的基础上,进 * 步拓展日、韩等多国语言以适应对外籍人士母语发送预警的需要。 多语言可拓展主要通过模板化方式在编码阶段实现,通过对应语言,允许发布单位录入多语言版本的短信内容,在面向外籍 (略) 靶向发送时,根据人群国籍属性实现指定语言版本的定向发送。 2.2.2 (略) 安全管理平台升级 在 * 期建设架构下,规划本期安全管理平台升级建设内容。根据现状分析与需求分析,本项目将按照《信息安全技术 信息系统等级保护安全设计技术要求》和《信 (略) 络安全等级保护基本要求GB∕T 点击查看>> 9》(即最新的“等保2.0”标准)规范的标准实现平台安全保护能力的提高,具体包括: (1) (略) : (略) 是 (略) 市突发事件预警短信发布平台的建设方,主要负责平台的建设和安全运维,因此需要重点保障系统自身的安全和使用好 (略) 提供的安全能力,保障系统达到 * 级等保的安全要求。 (2)市大数 (略) :大数 (略) 是平台承载环境的提供方,主要保障物联环境和云平台的安全性达到等保 * 级的要求, (略) 提供满足 * 级等保必备的安全能力,帮助平台满足 * 级等保的安全要求。 因此,本平台主系统端等级保护 * 级建设设计, (略) (略) , (略) 署在 (略) 市政务云平台。主备系统端的信息 (略) 由市政务云提供,向其申请安全服务各 * 套用于主备系统的安全保护。主系统端信息安全服务主要包括访问控制、WEB安全、漏洞扫描、审计服务、数据库安全、防病毒等服务。 主要的建设内容如下: 1、 (略) 署模式,将平 (略) 署到市政务云上,由市政务云平台 (略) 需的等保 * 级标准的安全服务。本次建设中,基础设施的安全由大数 (略) 负责,包含访问控制、WEB安全、安全审计及其他等保 * 级必要的安全措施。 2、 (略) 端基础支撑系统建设,购 (略) 操作终端、4套热备容灾软件和1台身份认证设备保 (略) 操作终端的主机安全和身份认证;在 * (略) 署1台防火墙、综合日志收集探针、攻击检测防御探针、异常流量检测防御探针、基础设施运维管理软件和数据加密系统; 3、对安全 (略) 升级,提升了漏洞和事件管理能力,通过安全探针 (略) 署对漏 (略) 统 * 收集、分析和管理。 在等保2.0 * 级中, (略) 集中管控存在如下要求: 应对安全设备、网络设备和服 (略) (略) 集中监测; 根据等保2.0 * 级中关 (略) 集中管控的要求,应对分散在各个设备上的 (略) 收集汇总和集中分析,并保证审计记录的留存时间符合法律法规要求; (略) 络中发生的各类 (略) 识别、报警和分析 平台 * 期建设缺少满足这 * 要求的功能,因此平台 * 期将针对这 (略) 集中升级。 安全管理平台图示 2.2.3 主系统端基础支撑系统 (略) 端基础支撑系统建设,购置热备容灾软件(包括2台接口系统、2台预警发布系统、2台数据库系统、1台存储系统)、 (略) 操作终端和4台身份认证设备保 (略) 操作终端的主机安全和身份认证;在 * (略) 署1台防火墙、综合日志收集探针、攻击检测防御探针、异常流量检测防御探针、基础设施运维管理软件和数据加密系统;采用大数 (略) 提供的政务云服务,保障物联环境和云平台的安全性达到等保 * 级的要求。 主系统端基础支撑系统清单如下:
* 、项目建设依据 3.1建设依据 3.1.1 政策依据 1. 《 (略) 办公厅关于印发国家突发事件应急体系建设“十 * * ”规划的通知》(国办发﹝ * ﹞2号) 2. 《国家 (略) 会发展第十 * 个 * 年规划纲要》( * 日十届全国人大 * 次会议审议批准) 3. 《国家突发公共事件总体应急预案》( (略) * 日发布) 4. 《“十 * * ”期间国家突发公共事件应急体系建设规划》 5. 《国家突发事件预警信息 (略) 管理办法(试行)》(国办秘函〔 * 〕 * 号) 6. 《全国地质灾害防治“十 * * ”规划》( * (略) 长办公会审议通过) 7. 《 (略) 省 (略) 会发展第十 * 个 * 年规划纲要》( * 日省十届人大 * 次会议审议批准) 8. 《印发 (略) 省突发事件预警信息发布管理办法的通知》(粤府办[ * ] * 号) 9. 《 (略) 省<国家突发事件预警信息 (略) 管理办法(试行)>实施细则》(粤办函〔 * 号) * .《 (略) 省气象发展“十 * * ”规划》(粤发改农经〔 * 号) * .《 (略) 市人民政府办公厅关于印发 (略) 市全面深化气象管理体制改革实施细则的通知》 * .《 (略) 市人民政府办公厅关于印发突发事件预警信息发布若干规定的通知》深府办函〔 * 〕 * 号 * .《深汕特别 (略) 区气象发展规划( 点击查看>> 年)》 * .《 (略) 市人民政府办公厅关于印发 (略) 市突发事件预警信息 (略) 办法的通知》深府办函〔 * 号 * .《关于信息安全等级保护工作的实施意见》(公通字[ * ] * 号); * .《信息安全等级保护管理办法》(公通字[ * ] * 号); * .《预报司关于确定国家突发公共事件预警信息发布系统(国家级和省级)信息系统安全等级保护级别的通知》气预函〔 * 〕 * 号: ?信息系统的安全保护等级由两个定级要素决定:等级保护对象 (略) 侵害的客体和对客体造成侵害的程度。由于 (略) 市突发事件预警发布系统对 (略) 市几千万手机 (略) 短信,受到破坏后,可能被利用以 (略) 市突发事 (略) 名义向几千万手机用户发送反动信息或诈骗信息,对社会秩序和公共利益造成严重损害,应定为 * 级。 ?各省(区、市) (略) 和公 (略) 要按照确定的等级,向当地公安机关备案,并按照第 * 级要求,做好该系统的安全防护工作。 3.1.2 技术标准 1. 《中华 (略) 络安全法》 2. 《国家突发事件预警信息发布系统管理平台与终端管理平台接口规范》(GBT 点击查看>> 7); 3. 《突发事件预 (略) 建设规范-平台构建(DB * T * * )》 4. 《突发事件预 (略) 建设规范-岗位设 (略) (DB * T * * )》 5. 《突发事件预 (略) 建设规范-信息发布与传播(DB * T * * )》 6. 《突发事件预警信息发布管理规范》(SZDB/Z 点击查看>> ) 7. 《突发事件预警信息发布系统数据交换规范》(SZDB/Z * — * ) 8.《信 (略) 络安全等级保护基本要求》GB∕T 点击查看>> 9 9.《信 (略) 络安全等级保护安全设计技术要求 GBT 点击查看>> 9》 * .《信息安全技术 信息系统安全等级保护实施指南》GB/T 点击查看>> 0; * .《信息安全技术 信息系统安全等级保护定级指南》GB/T 点击查看>> 8; * .《信息安全技术 信息系统安全等级保护测评要求》GB/T 点击查看>> 9; * .《信息安全技术 信息系统安全等级保护体系框架》GA/T 点击查看>> ; * .《信息安全技术 信息系统安全等级保护基本模型》GA/T 点击查看>> ; * .《信息安全技术 信息技术安全性评估准则》GB/T 点击查看>> 1; * .《信息安全技术 信息安全风险评估规范》GB/T 点击查看>> 7; 3.1.3 其他依据 1. (略) 省突发公共事件预警信息发布系统备案证明 2. 编制按照国家、行业的有关标准、规范及《 (略) 市政府投资信息化工程 (略) 性研究报告编制指南》《 (略) 市政府投资信息化工程建设项目初步设计及概算编制指南》和《国家发展改革委关于发布<项目申请报告通用文本>发改投资[ * 号》进行设计。 3. (略) (略) 有限公司与 (略) (略) 合同; 4. (略) 提供并承诺其真实性的资料; 5. 项目其它调研资料。 * 、服务要求 4.1 主系统端应用系统服务要求 4.1.1 日常运维 为保证项目建成后7× * (略) ,配置不 (略) 维护人员,根据项目规划,系统运维服务包括信息化系统软硬件维护。 1、★日常驻点服务:非公众假期星期 * 至星期 * 的9: * - * : * 为日常驻点服务时间。 2、 (略) 和指导:根据故障的类别、故障对系统性能和服务的影响,将技术服务请求按照紧迫性分为 * 个等级:紧急故障服务请求、重大故障服务请求和 * 般故障服务请求,等级由招标方确定。在接到故障申告、咨询或技术服务请求后,根据故障类型的不同,安排相应的技术支援工程师立即予以电话指导,电话技术指导服务为7天* * 小时。 3、现场支持:在接到技术支持服务请求后, (略) 和指导无法解决系统发生的技术故障, (略) 支持的情况下,收到故障报告服务请求后,在1个小 (略) ,,立即解决问题。对于由于软件或硬件缺陷引起的紧急故障,提供临时解决方案,并在1天时间内最终解决。对紧急故障,将组织 * 级技术支援体系下的技术专家小组,提供每周7天、每天 * 小 (略) 服务。 4、应急运维服务:需提供高级技术人员2名纳入平台系统运维保障岗管理,在启动 * 级或更高级别的 (略) 应急响应时,该运维保障岗需到岗提供7天* * 小时不间断技术支持, (略) 应急响应降级或取消。 5、对系统作定期或不定期技术巡检服务并建立完整的技术维护档案,将每次技术维护的类型、日期、维护内容、维护措施、维护人员、故障原因、处理结果等要素详细记录并归纳入库并形成完整的维护档案库。 6、通过日常维护及巡检等服务,查找不利于 (略) 的因素或诱发系统故障的因素,如是系统缺陷引起的,应 (略) 系统软件升级并向用户发出升级预告。如是业务应用或管理上引起的,则对用户提出有针对性管理建议或意见。 7、对与突发事件预警信息发布系统相关的接口和渠道 (略) 定期巡检,保证系统 (略) 。 4.1.2 (略) 维护 政务云即将上线云管平台。云管 (略) 分配账号, (略) 侧通过账号登录云管平台,对部署在政务云的 (略) 日常的运维监控管理; * 旦发现问题后,云管平台上可查看到相应告警信息,可 (略) 置;比如登录服务器做相应操作;如果需要大数 (略) (略) 理,可以在云管平台上按流程提交申请。 (略) 维护方案主要包括硬件设备的维护、安全维护、应用系统维护等。 具体如下: 1. 硬件设备的维护 1)硬件日常维护 包括定期对 (略) 灰尘清理,状态观测, (略) 件的日常操作维护。 2)硬件故障诊断及排除 当硬件设备出现故障后,若经判 (略) 维修, (略) 维修,同时更换备品备件以 (略) 正常。 3)硬件迁移、添加、调整、升级 当 (略) 变更,以及 (略) 调整时,需要对 (略) 变更,进行硬件的迁移或者添加。系统功能提升,硬件设备也应根据系 (略) 调整和升级。 2. 网络维护 1)故障管理 (略) (略) 理常见问题的解决方式。 2)资源管理 (略) 络中的设备(如网络中设备、单板、端口、接口、链路等)资源的基本情况, (略) 络中的异常资源信息。 3)网络性能管理 为了更好地 (略) (略) ,承建单位提供管理员必须掌握的性能指标,并能 (略) 长时间监控分析,做到提前预防,防患未然。 3. 安全维护 (略) 业务系统 (略) 中提供服务,日常至少1人服务,紧急保障任务,需至少2人服务,每季度形成安全运维报告。 为了保证业务系 (略) ,需要建立以下机制: 1)对 (略) 岗前培训; 2)限定 * 般用户权限,防止非 (略) 络; 3)及时升级防病毒软件,加强病毒防范意识; 4)通过设置访问控制, (略) 安全; 5)及时增加安全补 * ,建立和实施有效的用户口令和访问控制等制度; 6)及时对 (略) 备份。 4. 应用系统维护 1)应用系统巡检 为了保证系 (略) ,需要按周、按月 (略) (略) 巡检, (略) 存在的潜在异常,保证系 (略) 。 2)应用系统升级 随着技术的日新月异,需要定期对系统软件以及功能性 (略) 升级优化, (略) 的性能。 3)故障保障 (略) 后,随着用户量的增加和不可预知的用户频繁调用程序,可能会导致系统出现异常,需要制定详细的平台故障应急方案来应对,最大程度上保证系统的 (略) 。 4)日志统计 由管理员每天审计和审核日志记录情况, (略) 出现的故障要记录详细情况。系统日志应保留 * 年时间,在 * 年之后系统管理员确定后方可删除。 4.1.3 (略) 维护 数据是本项目应用系统运转的基础和运转的成果,通过建立严格的数据库备份与恢复机制,保障数 (略) ,同时建立 (略) 维护方案, (略) 的现势性。 1. 数据库的备份与恢复 数据库的备份与恢 (略) 维护管理中非常重要的环节,务必做好应用数据库的完全备份和增量备份。 1)完全备份 最近 * 月的完全备份应保存在备份 * 体机上。 完全备份应在非 (略) 。暂定每周 * 下午6: * ~8: * ,备份后应做好备份记录。 2)增量备份 在数据库服务器上对数据库做每天的增量备份。 3)应用数据的恢复 当数据丢失,可先根据增量备份的数据用整个数据库替换的方式恢复;如果采用增量方式不能完整恢复数据,应采用最近的全备份数据完成数据恢复。 2. 数据更新维护机制 针对本项目的系统数据,通过应急更新、定期更新、共建共享更新、联动更新 * 种模 (略) 更新维护。 4.1.4 重大服务保障 根据 (略) 的要求及相关规定,在重大灾害天气过程中提供系统的应急维护工作, 服务提供商应成立专门驻点维护组,确保 (略) ,在重大天气时 (略) 应急维护,重大 (略) 全程跟进8次以上。其主要包括以下内容: 针对台风、暴雨等重大灾害天气, (略) 市气象台 * 旦启动 * 级响应,需提供全天 (略) 跟踪服务。在此期间,派驻 (略) 进行 * 小时驻点服务,保障台风黄色等高级别预警信息的正常发布,以及突发事件预警信息发布系统相关各个渠道的正常传输。系统运维以及信息安全保障;针对系统提供日常维护及信息安全和应急维护服务;要求服务提供商成立专门驻点维护组,确保 (略) ,在重大天气时 (略) 应急维护,重大 (略) 全程跟进8次以上。 4.2 (略) 安全管理平台服务要求 4.2.1平台软件维保 ★提供 * 年的平台软件维保服务,当设备发生故障时售后技术服务人员将在第 * (略) 进行设备检查与维护,对信息安全系统平 (略) 诊断和修复,保障平台的 (略) 4.2.2平台安全检测服务 平台升级上线前, (略) 专项的漏洞扫描和渗透测试,对平台的 (略) 检查并及时对发现的 (略) 修复,确保平台自身的安全。 4.2.3 平台配置优化 提供 * 年的平台策略优化服务,通过 (略) 人员对平台业务流程和 (略) 分析,并根据分析结果对平台各项 (略) 配置优化,并根据实际的安全需求不断对入侵防御、资产监控、网络攻击监测、网络安全漏洞检 (略) 优化,平台可以满足等级保护的要求,并与 (略) 的人员、业务流程相结合,有效支撑突发事件分区预警信息发布短信平台的安全。 4.3 主系统端基础支撑系统服务要求 4.3.1政务云安全策略申请及优化服务 根据等级保护 * 级的安全要求,向市大数 (略) 申请虚拟防火墙(vFW)服务、边界防火墙服务、抗DDoS服务等云 (略) 策略配置,并根据实际的安全需求不断对云WAF、云防火墙等安全设 (略) 优化,保障申请的安全服务的能力最大化,可以有效保障 (略) 市突发事件分区预警短信发布平台的安全。 4.3.2 硬件维保服务 针对基础支撑系统购买的安全管理平台攻击检测防御探针、安全管理平台异常流量检测防御探针、安全管理平台基础设施运维管理、安全管理平台综合日志收集探针和数据加密系统等安全设备提供 * 年硬件维保服务,设备出现问题后,售后人员将在1 (略) 响应, * 小时内完成 (略) 置。 4.4主系统端与运营商端服务边界界定 由运营商保障突发事件预警信息发布平台 (略) 络区域的基础设施安全、网络环境安全、应用系统安全和数据安全, (略) 保 (略) (略) 络环境安全、应用系统安全和数据安全及提供各项安全策略的配置。
为保障平台业务连续可用,运营商应为平台业务安全提供必要的保障措施: (1) 当平台发生故障时,运营商应第 * 时 (略) 进行故障排查分析,确认故障源; (2) 当平台故障原因确认发生在运营商端时,运营商应第 * 时间响应,及时 (略) ; (3) (略) 络安全事件,需要 (略) 理时,运营商 (略) (略) 置; (4) 当平台运 (略) 络安全事件时,运营商应及时响应采取措施恢复平台安全。 * 项目分项清单 5.1主系统端应用系统功能清单
5.2 (略) 安全管理平台升级功能清单
5.3 主系统端基础支撑系统
* 、实质性条款
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
商务需求 | * 、服务期限:_项目建设期为 * 年,建设期之后 * 年为免费维护期。 * 年7月份前完成短信发布平台功能 (略) (略) 署。 1、★建设工期为 * 年。监理单位签发开工令后 * 年内完成设备供货、设备安装调试、 (略) 署及项目验收工作。 2、★建设期满后 * 年为免费维护期,时间自最终验收合格并交付使用之日起计算。 * 、服务地点:_ (略) __ * 、投标报价要求 1.本项目服务费采用包干制,应包括服务成本、法定税费和企业的利润。由投标供应商根 (略) 提 (略) 测算投标报价; * 经中标,报价总价作为中标供应商与采购人签定的合同金额,合同期限内不做调整。 2.投标供应商应当根据本企 (略) 决定报价,但不得以低于其企业成本的报价投标。评标时, (略) 认为投标人的报价明显低于其他通过符合性审查投标人的报价,有可能影响产品质量或者不能诚信履约的,应当要求 (略) 合理的时间内提供书面说明,必要时提交相关证明材料;投标人不能证明其报价合理性的, (略) 应当将其作 (略) 理。 3.投标供应商的报价不得等于及超过项目预算金额。 4.投标人的投标报价, (略) 文件及 (略) 列的 (略) (略) ,不得以任何理由予以重复,并以投标人在投标文件中提出的综合单价或总价为依据。 5.除非采购人通过修改采购文件予以更正,否则,投标供应商应毫无例外地 (略) 列的清单中项目和数量填报综合单价和合价。投标供应商未填综合单价或合价的项目,在实施后,将不得以支付,并视作该项费用已包括在其它有价款的综合单价或合价内。 6.投标供应商应先到项目地点踏勘以充分了解项目的位置、情况、道路及任何其它足以影响投标报价的情况,任何因忽视或误解项目情况而导致的索赔或服务期限延长申请将不获批准。 7.投标供应商不得期望通过索赔等方式获取补偿,否则,除可能遭到拒绝外,还可能将 (略) 为记录在案,并可能影响其以后参加政府采购的项目投标。各投标供应商在报价时,应充分考虑报价的风险。 * 、付款方式:_____按照完成服务工作进度和工作量制定分期付款方式_, (略) 有关规定支付。 * 、其他商务需求 ( * )安全保密要求。要求参与本工程建 (略) 人员都必须是政治可靠、责任心强的人员,而且在本工程的整个建设工作当中,建设都必须严守秘密,对于泄密的要追究当事人及单位责任,造成严重后果的除终止合同外,并追究当事人和单位领导的相关责任。建设公司需与该项目建设人员购买相应的保险签订保密协议书。 ( * )开展半年度和年度的项目建设工作总结和计划下 * 步工作。要求项目负责人开展年度和半年度项目建设总结,总结建设工作,分析问题,提出下 * 步工作计划。 * 、质量考核验收标准 1.质量考核验收标准:
注:★项目最终实施方案要求以经过专家评审通过的深化设计结果为准。 * 、违约责任 根据情况制定 ,违约金: (1)因承建单位造成合同期内安全、质量事故的,除承担相应法律责任外,建设单位可视情节严重程度 (略) 以 * 元的罚款,并通报批评。 (2) (略) 罚: 1)承建方未按照建设要点、日常建设和过程建设完成并提交相关工作文档的, (略) 罚建设费 点击查看>> 元/次,建设单位同时保留追究承建单位相应法律责任的权利。 2)建设单位每季度对建设工作 (略) * 次评价,如有两次服务质量评价不合格,建设单位有权中止合同,并将履约评价提交 (略) 。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
评标信息 |
说明 1.根据《 (略) (略) (略) 关于印发< (略) 市政府采购落实支持企业复工复产政策的实施细则>的通知》(深府购〔 * 〕 * 号)的规定,1. (略) 保证明。对于评审时需考察人员情况的政府采购项目,投标人无 (略) 保证明。 (略) 至 * 日;2.顺延既有认证证书有效期。对于评审时需考察投标人资质、认证等情况的政府采购项目,投标人提供的证书已到期的(到期时间为 * 日至 * 日),视同在有效期范围内;3.鼓励采购人积极运用公共信用信息,明确对信用记录良好的投标人(特别是中小微企业)免收履约保证金,确需收取履约保证金的,列明通过保函等非现金方式收取;4.在采购合同中明确对上述企业加大首付款或预付款比例,具体由采购人根据项目实际情况确定。 2.采购人拟采购的服务(工程)中,如涉及《关于调整优化节能产品环境标志产品 (略) 机制的通知》(财库〔 * 〕9号)中的产品,要依据该 (略) 。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
其他 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
附件 | 附件4: (略) 市突发事件分区预警信息短信发布系统 * 期(主系统端) (略) 申报书( * ).doc |
项目名称 | (略) 市突发事件分区预警信息短信发布系统 * 期突发事件预警短信发布平台(主系统端)项目 | 采购类型 | 非协议采购 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
采购人名称 | (略) | 采购方式 | 公开招标 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
财政预算限额(元) | 点击查看>> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
项目背景 | 按照国家、省和市的建设要求和规划,在 (略) 市政府指示和突发预警相关单位的通力 (略) 下,由 (略) 主持建设《 (略) 市突发事件分区预警信息短信发布平台》 * 期自 * 年4 (略) 以来作为突发信息发布系统 (略) 分,主 (略) 会公众发布 (略) 市突发事件预警短信的职能。通过电信、联通、移动 * 大运营商用户的全覆盖,建立了高度集中、自动化程度高的信息发布通道,实现了对海量用户信息的及时有效下发。 随着自然灾害和突发事件风险日益增高和管理要求的进 * 步细化,对市突发事件分区预警信息短信发布平台提出了更高的要求, * 期系统在实际应用中也暴露出 * 些问题:当前仅基于地理空间的精细化发送能力无法满足业务发展的要求;对系统整体 (略) 改造提升;现有安全防护能力已不能满足 (略) 络安全形势, (略) 络安全等级保护 * 级要求,项目在建设时未覆盖深汕特别 (略) 区等问题。因此,需要通过 (略) 市突发事件分区预警短信发布平台 * 期的升级建设,以解决以上问题。通过升级改造,对系统整体的安全加固和强化,完善系统各项安全设计、运维、开发、管理等工作,降低系统受非法侵入及破坏的风险,避免安全漏洞导致 (略) 会影响,同时使 (略) (包括深汕特别 (略) 区)对自然灾害、事故灾难、公共卫生事件 * 大类突发公共事件信息的接收、处理、及时发布和反馈能力提高到新的水平,提升 (略) 市预警短信精准发布能力,增加 (略) 市精准人群预警短信发布功能和全市指定区域触发式自动预警功能,完善预警短信发送数据实时反馈与评估功能,提 (略) 台的安全保护能力,并将深汕特别 (略) 区纳入预警发布范围,实现预警信息“报得早、审得快、发得出、传得畅、收得到、用得好”。 (略) (略) 会公众能够及时获取预警信息,公众的避险能力与防灾减灾意识的提升,最大限度地保障人民群众生命财产安全。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
投标人资质要求 | (1)具有独立法人资格或具有独立承担民事责任的能力的其它组织(提供营业执照或事业单位法人证等法人证明扫描件,原件备查)。(2)本项目不接受联合体投标,不接受投标人选用进口产品参与投标。(3)参与本项目投标前 * 年内,在经营活动中没有重大违法记录(由供应商在《政府采购投标及履约承诺函》中作出声明)。(4)参与本项目政府采购活动时不 (略) 门禁止参与政府采购活动且在有效期内的情况(由供应商在《政府采购投标及履约承诺函》中作出声明)。(5)具备《中华人民共和国政府采购法》第 * 十 * 条第 * 款的条件(由供应商在《政府采购投标及履约承诺函》中作出声明)。(6)未被列 (略) 人、重大税收违法案件当事人名单、政府采购严 (略) 为记录名单(由供应商在《政府采购投标及履约承诺函》中作出声明)。注:“信用中国”、“中 (略) ”以及“ (略) 市政 (略) ”为供应商信用信息的查询渠道,相关信息以中标通知书发出前的查询结果为准。备注:如联合体投标,投标人还必须提供《联合体投标协议》(格式自定),《联合体投标协议》须明确牵头人,并载明联合体各方承担的工作和义务。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
服务类清单 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
具体技术要求 | 1. 投标人须对本项目的货 (略) 整体响应,任何 (略) (略) 的响应都被视为无效投标。 2. 招标文件中,如标有“★”的条款均为必须完全满足指标, (略) 实质性响应,投标人若有 * 项带“★”的条款未响应或不满足,将 (略) 理。 3. 招标文件中,如标有“▲”的条款均为评审的重要评分指标, (略) 分“▲”重要条款未响应或不满足,将导致其响应性评审严重扣分。 * 、项目概况 (略) 市突发事件分区预警信息短信发布平台(主系统端)主要包括主系统端应用系统、 (略) 安全管理平台升级、基础支 (略) 分。 主系统端应用系统包括短信发布平台功能升级、系统安全升级、基本功能升级、组网及监控功能、系统的可拓展性功能 * 大方面, (略) 市发展的需要(发送能力覆盖深汕特别 (略) 区)以及突发事件分区预警信息发布的新需求对发布平台做出了全方位的设计与规划,通过人工智能技术等手段充分实现各项业务功能的智能化,实现突发事件发布系统和突发事件短信发布平台的 * 体化建设,采用目前先进的微服务架构打造成为 * 个 * 体化的的综合突发事件预警信息发布平台。 (略) 安全管理平台按照国家信息安全等级保护标准作为方案设计依据,基于有效的安全评估,从安全技术、安全管理、安全运维 * 个层面建立起科学的结构化的信息安全保障体系,从而保证业务系统能够 (略) 和不断完善和发展,适应 (略) 市突发事件预警短信发布平台不断扩展的业务应用和管理需求,并通过 * 级等保测评。 (略) 主系统端基础支撑系统建设,采购 * 批系统服务端、系 (略) 络安全设备,实现对主系统端应用系统、安全管理平台升级的基础支撑,保障突发事件分区预警信息短信发布平台 * 期系统落 (略) 。 其中针对5G消息预警信息发布、全网发布 (略) 理、基于 * 维地理信息的发布方式、全渠道数据接口和反馈机制、系统安全保 (略) 了深化设计。 * 、项目建设目标和内容 2.1 项目目标 ( * ) 建成 * 种自动精细化发布能力,实现自动定点发布预警信息、主动触发发布预警信息、针对特定人群发布预警信息、5G消息预警信息发布。 ( * ) 建成智能化发布能力, (略) 发布 (略) 理、指定区域触发式自动预警、基于 * 维地理信息的风险等级判识技术。 ( * ) 建成气象灾害风险监测预警秒级发布能力,结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,优化审核流程,做到自动生成、自动决策、人工审核后的秒级发布。 ( * ) 全面提升突发预警信息发布管理能力,形成突发预警信息发布评估评价机制、建设发布数据多维度数据统计和展示模块、建立和完善全渠道数据接口和反馈机制;逐步健全预警信息公开机制和深汕区预警信息发布机制。 ( * ) 提升信息安全级别至等保 * 级,项目建成后要求最终通过第 * 方安全测评机构的等级保护 * 级保障能力测评。 2.2 项目建设内容 2.2.1. 主系统端应用系统 2.2.1.1 短信发布平台功能升级 2.2.1.1.1地理范围精准发布能力提升 精准发布能力 * 期升级的主要功能内容包括自定义任意区域预警制作、自定义任意区域突发预警短信协议扩展、发送区域优先级智能调度、基于地理空间及事件属性的突发事件影响智能分析、自定义任 (略) 关升级等相关子模块,相关模块主要功能如下: * 是自定义任意区域预警制作模块,该模块是系统的核心交互模块,负责实现系统短信预警任务的辅助制作、编辑、审核、查询等功能,在保留 * 期的选择方式上,增加自定义选择方式,解决之前无法实现高精度的任意多边形区域预警信息的发送问题。实现自定义多边形区域发送,支持最小分辨率精度1平方公里。 * 是自定义任意区域突发预警短信协议扩展。当所选的区域为多个地理空间不相连的多边形自定义区域时,由于自定义任意区域突发预警短信发送涉及到同时调用 * 大运营商的接口,因此本次升级需要对短信 (略) 重新升级定义,使之可以满足自定义任意区域发送的业务目标。 * 是气象灾害风险监测预警发布功能,结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,优化审核流程,做到自动生成、自动决策、人工审核后的秒级发布。从而缩短整体流程,极大提高发送的决策和响应速度。 (略) 数据超灾害风险阈值, (略) (略) 智能生成发送区域和突发预警信息。 * 是发送区域优先级智能调度功能, (略) 发送的区域较大时,由于时效不 * ,且短信通 (略) 有 * 定的延时,而某些突发预警事件是随时间和环境因素的影响会发生变化;实际业务会需要对临近突发事件发生地点范 (略) 优先发送,因此需要根据事件影响、地理属性、相关要素等, (略) 分解,对分解后的多边形智能编排不同的优先等级,确保在受影响路径上距离越近的区域用户可以更早更及时的收到预警信息,争取宝贵的应对时间。 * 是基于地理空间及事件属性的突发事件影响智能分析,通过结合空间分析、重点防护区缓冲区分析等地理分析模型,在 * 维地理信息引擎基础上,完成对典型灾害信息空间分析流程的建模。当典型灾害发生后,系统通过GIS空间分析,智能判断灾害影响范围等级区域,以供值班人员参考。 * 是自定义任 (略) 关升级,由于相关的地理范围精准能力提升, (略) (略) 关已经不能适应 * 期的需求,通过自定义任意区域突发预警短信协议扩展后,协调 * 大运营商升级现 (略) 关,使之满足 * 期各种灵活发送的要求。 * 是实现发布区域划定的自动约束审查。由于运营商平台对短信发布范围区域大小和数量有 * 定的限制规则,因此需要系统对短信 (略) 自动约束筛查,提示用户修正不合理的区域范围。自动约束审查针对 (略) 筛查,例如不能单独的圈选出某个 (略) 门,例如不能单独的选出市 (略) 发送, (略) 络信息存在安全隐患。 2.2.1.1.2特定人群精确靶向发送功能 * 期系统只能按照地理位置发送预警信息,在 * 些 (略) 景下, (略) 限,但是学生及家长并不是聚集在某个特定的区域而是分散在全市。所以需要按照某种属 (略) 分类,针对特 (略) 发送。特定人群靶向发送功能共分为 * 个子模块,包括人群数据采集模块和面向靶向人群突发事件短信制作与发布模块及自定义靶向人群模块。 人群数据采集模块是实现特定人群靶向发送功能的基础核心模块。人群数据采集模块首要目标是特定人群数据采集方法的建立,并且根据方法建立相关的采集模型,采集功能的设计采用标签方 (略) 职业识别,然后按照采集模型针对教育、医疗、渔业等 (略) 采集,同时还需要设计定期或触发任务对 (略) 更新,由于人群身份的复杂性, (略) 采集的 (略) 对比 (略) 采集人群数据的准确性;对以保证特定人群的靶向价值,在系统中通过web的方式对人群数据的 (略) 管理和触发,在 * 期项目中没有做特定人群数据的区分,导致突发事件发生时只形成区域人群的广播,而没有根据事件对职业人群影响 (略) 区分,因此本期系统将特定人群数据采集和分类作为重要精细化作业 (略) 建设。 面向靶向人群突发事件短信制作与发布模块实现首先选择确定要发送的特定人群,例如学生人群、户外活动爱好者等,综合考虑预警的等级、种类、风险程度、发展趋势以及特定人群和涉及的地理空间范围,例如台风来临,需 (略) 停课预警,这里选择的特定人群就是学生,学生是分布在全市的,但是还可以进 * 步指定区域属性,例如只是对沿海区 (略) 停课预警,这样发送的针对性更强,特别是还可以和上 * 节提到的任 (略) 组合发送,则突发预警的靶向更明确、精准程度更高。 自定义靶向人群模块是平 (略) 、委、 (略) 灵活发送需要的功能模块,各局、委、 (略) 登入系统,填写发送的内容、时间、范围、级别、目标人群数据(手机号码清单列表)等信息后,通过系统管理端的审核流程后, (略) 短信的发布。自定义靶向人群作为高精度模式是特定靶向人群发送的有效补充,可以 (略) 、委、 (略) 信息多头发布、重复发布的难点和问题。 本期计划实现具体特定人群包括:学生家人人群、海上作业人群和和来深境外人群,其中受众较广的人群通过LBS服务大数据分析来智能筛选和确定,部分要求目标绝对准确、且难以通过LBS数据得到结果的人群,则需要相关单位机构提供原始人员信息,系统 (略) 使用。 2.2.1.1.3与覆盖深汕特别 (略) 区对接 * 期系统建设时深汕特别 (略) 区未纳入覆盖范围。深汕特别 (略) 区依山面海,拥有漫长的海岸线,台风等不良气候频发,突发事件分区预警发布系统的缺失,将不利于深汕特别 (略) 区群众应对各种突发 (略) 会发展,将会对人民生命财产产生严重隐患。 * 期覆盖深汕 (略) 区将解决这个隐患。与深汕特别 (略) 区对接主要包括以下重要工作: * 是对深汕特 (略) 及用户 (略) 采集入库,并形成增量的用户分布情况数据库,用户分布情况数 (略) (略) 位置及号码 (略) 关联。 * 是对 (略) 区对应街道的边界信息应先予以确定, (略) 及用户数据时需要 (略) 的GPS经纬度 (略) 计算、统计、分析,做到高准确度和高效率的获取最新的用户分布情况基础数据。 * 是对深汕特别 (略) 区 (略) 初始化升级,包括深汕特别 (略) 区地图底图采集与制作,多种地图底图、并且支持最大缩放等级 * 级;还需 (略) 政规划对 (略) 区分镇规划的边界数据采集与制作,实现区域分级管理; (略) 、景区、重点 (略) 所 (略) 所影响边界的采集和制作;还需要针对深汕特别 (略) 区的特点,定义突发事件相关影响要素的集成和展现;完成数据采集工作后,对所采集的深汕特别 (略) 区 (略) 交叉对比验证, (略) 有采集、加工数据的正确,同时保证符合精度要求。 2.2.1.1.4气象灾害风险监测预警智能发布 结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,优化审核流程,做到自动生成、自动决策、人工审核后的秒级发布。从而缩短整体流程,极大提高发送的决策和响应速度。 (略) 数据超灾害风险阈值, (略) (略) 智能生成发送区域和突发预警信息。 与短临系统(PONDS)、预警预报业务 * 体化平台等业务联动,结合实况监测数据与短临预报产品形成预报和实况双驱动,智能生成突发预警信息,自动进入预设的发布流程,人工审核后的快速发布,解决自动在灾害影响区域面向基层防灾人员精准发布预警信息。 2.2.1.1.5预警信息实时反馈和评估 目前 * (略) 端是采用调用接口的方式采集运营商发送状态报告信息,并入库生成报表。由于 * 大运营 (略) 理环节均 (略) 系统中实现,导致了反馈数据不稳定甚至超时等各种问题,主系统端比较难以获得准确、实时的发送反馈报告, (略) 监控的实效性和准确性有 * 定滞后。 * 期升级将采用主动式 (略) 状态,这样可 (略) 的时效性统计指标更加客观真实,比如满足发送成功数达到预计发送人数的 * %即认为发送完成,对于预警任务的影响评估有重要意义。 预警信息实时反馈和评估在 * 期平台中除了改善 * 期的统计时效以及准确性问题外,还需要合并统计突发事件预 (略) 站、广播、电视台、手机短信、手机客户端、微博、微信、热线电话、户外LED显示屏、交通诱导屏、车载电视等 * 种预警信息快速发布渠道的实时反馈,形成 * 套科学有效的办法,对预警 (略) 综合、量化的评估,以更好的 (略) 门或值班人员今后的预警信息发送任务的策略制定提供基础数据支撑。 2.2.1.1.6全市指定区域触发式自动预警功能 * 期系统的建设以实现短信发送作业为主,为进 * 步提升预警效率, * 期建设增加了全市指定区域触发式自动预警功能的建设,实现特定区域触发预警的智能机制,开发内容包括触发式自动预警条件配置管理、触发预 (略) 理和触发预警发布、编辑、归档功能。 触发式自动预警条件配置管理用于定义触发条件和规则,包括服务器端规则配置和web管理配置页面的开发,并且需要将自动触发预警任务集成到主系统的短信发布作业流程中; 触发预 (略) 理是由后台监听 (略) (略) 理,监听程序获取到触发信息,根据规则判断其触发等级、类别、目标,自动生成预警任务; 触发式自动预 (略) 人工介入,实施编辑确认、审核、发布等工作流程,包括自动预警发布、编辑、归档功能的前端页面和后台服务;并集成到主 (略) 流程; 2.2.1.1.7地理信息引擎升级 * 期平台使用的是 * 维地图地理信息引擎,展示效果比较单 * ,功能相对简单有限。 * 期将升级为 * 维地理信息引擎,可以为突发事件短信的制作者提供更为全面、 (略) 市地理信息,有助于对于要发送的信息范围、 (略) 综合性评估,此外, * 维空间地理信息引擎后台还可以充分利用建筑物分布、对应的人群密度等 (略) 智能分析后,为突发事件发送决策提供可靠的辅助信息。地理信息引擎主要包括以下几个方面的升级: * 是地理信息引擎升级,采用 * 维地图来提供更丰富的展示界面。 * 维地图是目前发展的 * 个主流方向,目前主流的商业地图都支持 * 维地图。 * 维地图由于具有空间感可以给操作人员提供更多的地形地貌等信息,有利于操作人员更好的做出预警决策。 * 维地图由于数据量大 (略) 理及大量的带宽,近年 (略) 络技术的飞速发展为 * 维地图的采用打下了良好的基础。 * 维引擎升级采用Cesium引擎作为基础框架,Cesium是 * 个基于JavaScript编写的著名开源地图引擎。其采用MIT许可协议,允许被授权人有权利使用、复制、修改、合并、 (略) 、散布、再授权及贩售软体及软体的副本。 * 是与数字 (略) 空间基础信息平台集成。 (略) 空间基础信息平台以3S(遥感RS、地理信息系统GIS、全球定位系统GPS)等技术为基础,整合 (略) 市空间基础信息, (略) 门、企业、公众提供空间信息在线共享交换服务。 (略) 市空间信 (略) 格标准已 * 日发布, * 日开始实施, (略) 市空间信 (略) 格标准规定了 (略) 市统 (略) 格的术语和定义、划分原则、 (略) 格数据。它的内容包括: (略) 格单元划分原则,网格划分的技术流程,成果表达,网格编码的规则和方法, (略) 格单元数据要求等。 为保护投资,统 * 标准,充分利用现有成果,本次升级需要充分考虑地 (略) 分与数字 (略) 空间基础信息平台集成,避免重复制作 * 维、 * 维数据,充分利用数字 (略) 空间基础信息平台已有的 * 维、 * 维地理信息,包括地名标注、行政区域图、交通图、卫星影像地图、 * 维建筑物模型等。 在本次地理信息引擎升级中,保持与现有空间数据标准统 * 衔接,充分利用现有数据的建设成果,平台支持集成数字 (略) 空间基础信息平台的相关数据,如政务版电子地图服务、专题地图服务、在线地址匹配服务等开放的服务接口和数据。 集成的方式主要为数据集成, (略) 络地图服务(WMS)请求数字 (略) 空间基础信息平台返回相应的地图(包括PNG,GIF,JPEG等栅格形式或者是SVG和WEB CGM等矢量形式)。 (略) 络协议HTTP,所支持的操作是由URL定义的。 * (略) 政网格化管理融合。网格化 (略) 政区域按照 * 定的标准划 (略) 格, (略) 格成为政 (略) 会的基本单元, (略) 市管理和数字化平台,将城市管理辖区按照 * 定的标准划 (略) 格的管理方式。 (略) 市目前已 (略) 了网格化管理的相关标准。 (略) 格金字塔模型规范了各区、街道、 (略) 格化定义。 (略) 格金字塔骨架 (略) 格、 (略) 格和统 * 。 (略) 市突发事件分区预警短信发布平台作为 (略) 市突发事件发布管理的支撑业务平台承担了自然灾害、事故灾难、公共卫生事件 * 大类突发事件的发布任务,是 (略) 门 (略) 和数 (略) 平台,为充分与 (略) 格化管理体系相融合,做到管理单元可直接对接市级其他相关业务平台, * 期短信平台需要按 (略) 市统 (略) (略) 网格化定义,遵循 (略) 市统 (略) 格编码的规则和方法, * 期 (略) 格化管理 (略) 格化的配置管理功能、运营商数据接口以 (略) 格化选择、制作、 (略) 等功能。 2.2.1.1.8实现富媒体发送功能 (略) 市目前已经 (略) 络全市覆盖,随着5G建设的推进5G终端的普及,本期建设需要全面实现对5G消息的支持,实现基于5G的突发预警信息的发布功能,通过富媒体消息实现基于手机原生系统的格式化解析,按预定的卡片格式、字体大小颜色展现不同类型、等级的突发事件预警信息内容。 2.2.1.1.9突发事件预警信息平台 * 体化建设 目前 (略) 的突发事件预警信息发布由突发事件预警信息和突发事件预警信息短信发布平台两个平台组成,突发事件预 (略) 站、广播、电视台、腾讯TIPS弹窗、手机短信、手机客户端、微博、微信、热线电话、户外LED显示屏、交通诱导屏、车载电视等 * 种预警信息快速发布渠道。由于手机短信渠道的安全等级要求更高以及影响覆盖的范围极为广泛, * 期的短信发布 (略) 络专线与运营商对接按照 * 级等 (略) 建设的,与突发事件预警信 (略) (略) 段和服务器上,两者之间通过接口实现数据的互联互通。 本期建设需要针对性设计将两个 (略) 合并,并采用微服务架构设计,融合两个系统的核心功能,统 * 按等保 (略) 设计和重构,使之满足突发事件预警信息综合发布的集约性、安全性、便利性、数据的 * 致性等各方面要求。 2.2.1.2 系统安全升级 2.2.1.2.1应用安全升级 * 级等保要求采用两种或两种以上组合的鉴别技 (略) 身份鉴别,且其中 * 种鉴别技术至少应使用动态口令、密码技术或生物技术来实现。因此本项目除了需要传统的用户名密码登录方式外,需要升级用户管理及身份验证策略,使之达到 * 级等保的技术规范要求。本期计划采用生物特征识别(指纹识别)的技术作为第 * 种用户身份鉴别技术。 身份鉴别的相关安全要求主要通过用户管理模块升级来实现,支持生物识别特征的录入与配置管理功能, * 期系统需要采用生物识别设备(指纹设备)作为加强的第 * 种身份识别技术,开发识别设备页面控件,调用设备的SDK开发支持H5页面的插件、控件; (略) 页端生物设别设备的调用,从 (略) 要求的1+1多种验证机制。 * 期平台采用了传统的基于密码口令、令牌Token的认证模式,按照安全等级 * 级的要求“应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技 (略) 身份鉴别,且其中 * 种鉴别技术至少应使用密码技术来实现。”,本期平台需要采购指纹采集与设别设备,补充 * 种鉴别技术使之满足 * 级等保的要求。 2.2.1.2.2日志审计功能升级 实现事务日志(日常事务操作,如:预警短信息的发、改、查等事件,不限于系统登录、退出。)记录功能, 集中审计可综合各种安全设备的安全事件,以统 * 的审计结果向用户提供可定制的报表, (略) 络安全总体状况。 统 * 日志审计管 (略) 系统安全监测,并为安全计算环境、安全区域边界、 (略) (略) 统 * 的监控与告警。 日志集中审计内容包括: 1、日志监视:实时监视接收到的事件的状况,如最近日志列表、系统风险状况等;监控事件状况的同时也可以 (略) 参数,以配合 (略) 络的状态;日志监视支持以图形化方式实时监控日志流量、系统风险等变化趋势。 2、日志管理:日志管理实现对多种日志格式的统 * 管理。通过SNMP、SYSLOG或者其它的日志接口采集管理对象的日志信息,转换为统 * 的日志格式,再统 * 管理、分析、报警;自动完成日志数据的格式解析和分类;提供日志数据的存储、备份、恢复、删除、导入和导出操作等功能。日志管理支持分布式日志级联管理, (略) 的日志数据可以发送 (略) 进行集中管理 3、审计分析:集中审计可综合各种安全设备的安全事件,以统 * 的审计结果向用户提供可定制的报表, (略) 络安全总体状况,重点突出,简单易懂;生成多种形式的审计报表,报表支持表格和多种图形表现形式;用户可以通过IE浏览器访问,导出审计结果。可设定定时生成日志统计报表,并自动保存以备审阅或自动通过邮件发送给指定收件人,实现对安全审 (略) 理。 2.2.1.2.3数据库安全升级 * 期平台数据库安全升级目标主要为通过多种手段实现对数据库存储的安全设计、规划、运维, (略) 有数据的安全,最终达 (略) 规定的安全标准,具体安全升级包括如下几方面内容: 1.数据库安全权限设计及改造 通过不同的用户权限设计实现不同等级的存取控制管理权限,对于绝无必要的用户,清理出数据库;规范数据库管理软件,实现管理软件的标准、统 * 化。 2.数据库日志安全备份与审计功能 建立备份机制,对于业务系统搭建NBU、DP、DSG等备份管理软件,针对业务情况、系统压力、带库资源等创建合适的备份策略, (略) 突发事件发 (略) 备份。 3.数据库防篡改功能实现,表结构增加校验码,实现存储的防篡改校验功能,保证关键数据的安全性,数据库必须提供防篡改功能设计,增加校验验证方式,以防止关键信息被恶意篡改从而导致系统发送了被人为篡改后的信息。 4.采用数据 (略) 理,在各种不可预见的事故导致数据库损坏数据丢失等故障后,可及时恢复最新的备份数据。 5.数据库配置文件以及通讯端口采用 (略) 理;防止连入数据库的应用程序存在后门,造成数据库安全隐患,所有数据库连接必须使 (略) (略) 理,以保证数据传输过程中的安全性。通过使用门户监控登录数据库,禁止对数据库的直接操作。对已经 (略) (略) 规范化、统 * 化的管理, (略) 权限复核操作, (略) 属IP、 (略) 权限梳理工作。 (略) 安全培训,增强员工的系统安全观念,做到细心操作。 6.数据库配置文件采用D (略) 加密,在应用 (略) 解密,杜绝数据库连接信息明文存储在相关系统文件中,导致数据库相关账户、密码泄露,造成安全隐患。 7.数据库数据加密存储,加密算法使用SM1、SM2、SM3、SM4等国密算法;对于系统关键的表关键数据,使用加密算法使用SM1、SM2、SM3、SM4等 (略) 存储。 2.2.1.2.4系统管理安全升级 由于项目 * 期的稳 (略) 署要求的提升,要求系统管理 (略) 升级,以达到 * 级等保的安全防护要求,具体如下: * 是通过构建新的负载均衡系统建立有效的负载均衡机制,可以采用多种负载均衡机制,将大量的并发访问或数据流量分担到多台 (略) 理,进而减少用户等待响应的时间, (略) 理能力。 * 是实现对 (略) 状况的健康检查机制,确保提供服务的正确。全面的健康检查机制不仅可以有效的监控到服务进程的有效性,即对应用端口提供服 (略) 健康检查,同时,对于 (略) 错误也同样可以提供有效的检查机制,从而避免了客户端可以访问到服务器,但得不到响应的情况的出现。 * 是应用程序保护功能;通过额外的守护进程对应用 (略) 保护,防止系 (略) 文件在未经授权的情况下被修改。应用程序保护功能还包括恶意代码防范管理,建立恶 (略) ,进行防恶意代码软件的统 * 管理,并根据情况建 (略) 。恶 (略) 实现:杀毒策略统 * 集中配置;自 (略) 恶意代码库升级;定制统 * 客户端策 (略) ;进行集中病毒报警等。 * 是系统初始数据管理配置功能安全升级;应用系统备份与恢复:应用系统的定期备份与恢复管理,识别需要定期备份的重要业务信息、软件版本,规定备份信息的备份方式、备份频度、存储介质、保存期等;根据数据的重要性及 (略) 的影响,制定数据的备份策略和恢复策略, (略) 备份与恢复策略。 * 是对系统安全定期巡检并生成巡检报告;通过系统管理员对系统的服务器、网络设备、安全设备、 (略) 统 * 的定期巡检, (略) 概要、系统异常分析、系统安全警报等,生成详实的巡检报告,跟踪并保障系统的正 (略) 。 * 是及时对操作系统、应用层支撑 (略) 升级管理; (略) 补 * 管理, (略) 系统补 * 安装。注意应首先在测试环境中测试通过,并对 (略) 备份后,方可实施系统补 * 程序的安装。 2.2.1.3 基本功能升级 2.2.1.3.1系统管理功能升级 由于使用突发短信平台群发信息的发送单位逐步增加,不可避免的涉及到 * 些具体业务审批流程的调整和变更,本期建设需要增加短信发布主系统端审批流程自定义配置管理,管理员可动态配置发布流程及节点以及采用的验证方式等,使之适应不同发送主体、不同类别、不同级别的发送业务流程。 本项目需要与 * 大运营 (略) 集成,在软件开发工程中, (略) * 些版本的迭代,因此本平台的生产 (略) (略) 严格的隔离。为防止在软件开发、调试过程中,产生误操作,本期建设需要增加 * 个生产与测试环境同步控制模块,同步控制模块采用软硬件结合的手段,防止在测试环境调试误触发导致接入生产环境而错误发送短信。 2.2.1.3.2整体界面升级 (1)项目采用模块化的开发模。在体系结构方面,总体采用前后端分离的微服务架构来实现。后台主要用于各类突发事件的影响分析、发布制作、审核、跟踪、监控、反馈统计等业务数据流程操作。前端则通过良好的交互式设计,在满足功能要求的同时做到简洁、美观,安全性强。 (2)在保障系统稳定性和高效性的基础上,依据项目模块 (略) 统 * 设计,系统交互设计包括原型设计和高保真界面设计。 (3)系统会产生大量的图形数据以及大数据分析结果数据,在设计阶段需要考虑前端客户浏览器的承载能力,做到各类图形、报表、地理栅格图片等数据流畅、快速的加载和展现。 (4)客户端作为B/S结构程序(前台程序),为用户的操作平台。它将系统的操作界面与复杂业务功能实现合 * 为 * ,实现各种数据的人机交互的可视化展示;系统均衡地将任务分配在服务器端与客户端,各司其责, (略) 。 (5)充分利用HTML5的优势对 (略) 整体优化,合理优化显示界面内容并提高人机交互操作的便捷程度。 (6)短信制作编辑管理界面、发布监控界面、统计报表以及其他系统界面。短信制作编辑管理界面最主要升级是要可以支持任意区域的自定义矩形及精准发布人群,并且可以支持 * 维与 * 维的操作界面。其他的如监控界面和统计报表等也要适应这 (略) 改动升级。 2.2.1.3.3 突发 * 张图功能升级 突发 * 张图是突发预警短信发布系统的总览入口界面,系统基于统 * 标准的地理信息系统为核心,以电子地图为主体架构,叠加突发应急管理相关资源、风险隐患信息情况、实时监测监控、各类突发事件影响过程、突发事件各类渠道包括短信发送等反馈状态和发送进度等数据图层。 (略) 中的突发事件实时的反馈,这些数据通过后端收集、排序、分析,增强准确性和精度,通过大数据可视化的各种技术手段,以图文并茂言简意赅的方式集中显示在大屏幕上。突发 * 张图功能升级主要包括了地理引擎从 * 维升级到 * 维以及整体界面的升级。同时也对现有服务 (略) 升级,目前服务端主要采取了轮询查询的模式,新升级将数据的刷新技术方式统 * 改为Websockets方式实现,Websockets方式不仅可以优化现有的接口效率,还可以大大降低客户端的资源消耗,提升用户体验和使用效率。 2.2.1.3.4系统提醒功能 全方位监控,不但包括对运营商的监控,也包括对主系统端的各种监控, (略) 状态、网络状态、机房状态等的监控。当发现有异常时能够以邮件或者短信、微信、浏览器声音警告弹窗的方式通知主要管理人员,确保系 (略) 。实际上,主系统端将成为 * 个预警 (略) ,对本系统有关的各种设备、网络、短信 (略) 全方位的监控管理,确保系统安全稳定可靠,能够真正的为突发事件预警做好技术保障。 2.2.1.3.5共享方案升级 (略) 市突发事件分区预警短信平台是作为全市的面向广泛市民而建设的预警渠道,在业务和数据上 (略) 、办、委等政府的业务或业务系统互连互通,本期建设为最终可以解决消除信息孤岛多头发布的问题,实现全市统 * 平台发布;因此,在保证信息安全的前提下,需要从系统层面、业务层面、数据层面多方面考虑数据的互通共享。 数据层共享主要是指相关突发事件预警信息及发送反馈报表上传到 (略) 的共享。这个是基础层面的共享,依 (略) 对信息系统建设的要求,做到最基本的业务数据共享。 (略) 过程中通过与运营商接口对接可以采集、获取反馈数据,其中可供共享的数据包括用户分布数据和突发事件预警短信发送统计数据。 系统级共享是指用 (略) 主系统端与其他需要接 (略) 系统集成和自动接入的相应服务端口,为各单位现存的系统 (略) 的API及相关协议标准,以达到快速集成的目标,这种方式接入单位不需要人工 (略) (略) 操作,而是按照各单位 (略) 操作,操作完成后,系统调用后端API实现预警信息的提交。 2.2.1.3.6与业务系统的深度对接 目前发送的短信预警,其中自然灾害类的占据了比较大的比例,自然灾害又以气象灾害为主, (略) 内建设有相关预报预警系统。由于目前没有直接与之集成, (略) 值班人员发布信息时,需要手动或复制粘贴发布内容以及目标区域等,效率较低且容易出错。本期升级后,系统与其他灾害信息系统集成的功能主要通过消息服务的机制,制定统 * 的消息服务协议,连接到各个灾害预警信息来源系统,自动实时的接收灾害信息,并按照设计的业务逻辑将原始的灾害信息通过智能化手段转化为最终预警信息的草稿, (略) 页、短信等方式通知到突发值班人员予以人工确认后, (略) 相关操作。与其他平台集成后,后台任务实时跟 (略) 中心数据库,获取灾害信息,为自动预警触发功能提供基础,同时提升了预警信息发布中转环节的延时,保证了信息在流转过程中的准确性,不会因为人为的错误导致错发误发预警信息。 与系统之间的通讯主要采取定义统 * 的标准协议来完成,遵循《国家突发事件预警信息发布系统管理平台与终端管理平台接口规范(GBT 点击查看>> 7)》和《突发事件预警信息发布系统数据交换规范》(SZDB_Z * — * )》等。 2.2.1.4 组网及监控功能 2.2.1.4. (略) 服务 系统 * 期基于应用特点的考虑,将整个系统的流程设计为任务管 (略) 两段式结构,因此系统和设备也是根据这 * (略) 部署;主系统端作为预警任务的发起方,完成内容编辑审核以后形成发给运营商的任务指令,由运营商端应用理解 (略) 执行, (略) 情况定时反馈给主系统端,这 * 结构优点是业务分工清晰明了、流程简单,缺点是任务的管理精度小,数据反馈不及时,执行过程对于任务发起人来说是 * 个系统黑盒子。 * 期平台将采用以主系统端应用为核心的 (略) 署方式, (略) 络以及相关监控微服务组件,对整个平台包括运营商端的基础支撑的 (略) 组网以及监控服务,模块可实时对 (略) 络状况、核心服 (略) 健康检查, (略) 络或服务节点发生故障时,可以第 * 时间发出警告信息,提醒值 (略) 理。 2.2.1.4.2监控客户端 监控客户端程序:客户端需针对不同的服 (略) 定制开发,读取每个系统 (略) 参数,包括各个系统与装备间的通信状态、 (略) 状态、数据到报状态、机房环境参数、经过质控后的数据状态、 (略) 状态等。客户端需要具备以下功能: 服务监控是监控客户端重要的环节,服 (略) 络状态、资源使用情况、各项参数指标是否正常等极大的影响着数据能否稳 (略) 理。服务器监控的内容包含服务器基本配置信息 (略) 状态监控以及异常信息采集。 (略) 理机(服务器)常见的监控类别及参数表: 表7?6服务器监控信息表
监控 (略) (略) ,按照预设的规则定时对读取服务器各项参数、配置状态并推送到监控服务端服务器,进 * 步 (略) 数据监控信 (略) 理。 2.2.1.4.3监控服务器 监控服务端主要对各个客户端传输回 (略) 接收和管理, (略) (略) 质量分析。服务端需要具备以下几个功能。 1.信息采集接收,信息采集接收服 (略) 有客户端建立TCP/IP连接, (略) 有客户端采集发送的警告信息、监控信息,在收到客户端数据后, (略) 解析并完成分类,按照预设的存储规则,存储到数据库中,同时通知后续的质量控制 (略) (略) 理分析。 2.客户端管理,客户端管理是监控服务端通过远程方式有效管 (略) 的客户端的有效手段。使用远程管理的方式管理人员只需要在值班室 (略) 有客户端软件的管理,而不需要对每台客 (略) 现场的管理配置。 3.监控服务端负责接收客户端推送的相关 (略) (略) 理,对不同的信息类别,如 * 般信息、配置及状态信息和警告信息等,分别存入指定的数据库中,同 (略) 需要系统接口,对信息予 (略) 理。例如警告信息则需要调用提醒接口最终把相关信息推送到值班人员。 2.2.1.4.4 网络监控 网络监控, (略) 与 (略) 网络内的 (略) (略) 的监视和控制,应包含如下基本功能:网络状态监控、流量监控、 (略) 分离流量带宽限制、并发连接数限制、FTP命令监视、TELNET命令监视、 (略) 为审计、操作员审计、软网关功能等。 网络监控的目的, * 在于安全, (略) 为监控可以准确记录各终端的操作时间以及日志,保 (略) 安全。 * 在于故障诊断, (略) 与运营商是通过 (略) 组建的 (略) ,其网络连接比较复杂, (略) 络状态监控可以迅速定位故障点,对 (略) 络故障予以快速解决。 网络监控除了输出各类监控报表外, (略) 络拓扑状态图,通过图形的方式,简单快捷 (略) 络的状态。 2.2.1.5系统的可拓展性功能 2.2.1.5.1发送目标地理区域和精度的可拓展 (略) 市未来发展的变化,发送目标地理区域采用可拓展设计实现,从整体设计上应做到无论后续 (略) 市做任何区域的调整、发送区域范围定义精度的进 * 步升级,都可以轻松通过后台管理工具实现同步的数据变更空间范围和精度的配置操作,充分满足目标发送目标地理区域、精度的可拓展性需求。 通过配置管理模块实现目标发送地理区域的任意扩展,包括在地理上相连或不相连的区域,通过地理空间的可配置管理,可以实现对目标发送地理范围的参数化配置,通过管理端新增、删减、变更地理空间的定义,同时还支持边界信息的GEOJSON格式导入、导出功能。地理区域的管理功能还包括对子区域、街道、 (略) 、POI数据的管理与维护功能。同时本期平台定义的最小发送范围为1平方公里司地理区域,随着 (略) 络的建设,可以预见在不久的将来,基站密度将大大提升,由此基础数据可能从现在的1平方公里精度升级到 * 米甚至 * 米。在系统接口规范设计以及前端操作限制策略上,均采用可配置文件,通过调整配置文件的参数,做到灵活适应不同的区域精度。 2.2.1.5.2靶向人群的可拓展功能 本期设计目标的靶向人群定义主要人群为学生和家长人群、渔业海上沿海作业人群、境外来深人群。而随着需求和系统在全市的推广,必然会涉及到更多种类的人群定义,因此需要实现人群的灵活定义功能,系统可以通过配置增加、删除、变更人群的定义,包括人群标定的方法以及管理主体。标定的方法主要包括实现采用大数据算法基础参数配置标定,和同时精确人群数据标定两种。采用大数据算法在系统层面上,要实现算法的可扩展升级、 (略) 署等特性,允许在需要的时候通过完善相关算法达到标定精度提升的目标。精确人群标定则主要以采集相关人群的号码资源,定期采集统 * 入库、集中管理应 (略) ,精确的人群数据主 (略) (略) 会团体组织提供原始数据,平台通过提供接口管理界面或系统接口或人工导入方式向导充分满足人群原始数据的新增、更新、清理等业务需求,, (略) 委办人群数据的导入导出等管理功能。特定靶向人群的可拓展性在 (略) 重点设计,考虑多种可能性,通过制定统 * 规范的数据交换标准、数据格式、接口参数来实现。 2.2.1.5.3与预警发布单位、运营商和其他系统集成的可拓展功能 * 期采用多单位多用户设计,上线后可满足 (略) 市其他发布单位、组织的突发事件预警信息的发布需要,登录到本平台使用系统的单位会增多,因此 * 期涉及上需要满足其他用户单位的拓展性要求, * 期通过升级平台的组织管理、用户管理、鉴权管理、分级安全管理等模块来实现使用单位的新增、配置;从而达到使用单位( (略) 门)的可拓展性。 此外,主系统端实现上述可配置、扩展拓展性后,不可忽略的还有对接 * 大运营商接口的配置与扩展,因此在接口的设计和实现上,要充分考虑接口规范的适应性,包括接口本身的协议定义以及运营商配置功能。 主系统端作为 (略) 市突发事件分区预警短信发布的中枢平台,目前已 (略) 业务 * 体化平台、市应急发布平台、 * 大运营商子系统、等系统平台实现系统接口的集成与对接,随着进 * 步在全市其他单位的推广使用,可能接入的系统会越来越多。因此在适应与其他系统集成拓展性方面要充分从基础业务、数据交换、门户对接等几方面考虑对与其他系统集成的拓展性。在解决方案上,本系统属于主系统,需要针对可能出现的 (略) 框架支持设计,制定完备、清晰的接口标准,规范化系统集成技术标准;提供主要语言SDK以及API调用说明手册等各类技术文档,从而为后续需要集成的其他单位的系统平台提供快捷、稳定、简易的系统级集成和数据交换方案。 通过 (略) 市突发事件预警信息发布系统,本平台可以实现与市政府管 (略) 等系统的接入。 与系统之间的通讯主要采取定义统 * 的标准协议来完成,遵循《国家突发事件预警信息发布系统管理平台与终端管理平台接口规范(GBT 点击查看>> 7)》和《突发事件预警信息发布系统数据交换规范》(SZDB_Z * — * )》等。 2.2.1.5.4预警短信语言的可拓展功能 语言可拓展性主要是指根据 (略) 属国籍,可以相应发送对应母语的短息内容。 (略) 作为具有国际影 (略) 市,与世界各地的沟通日益增加, 常驻或临时来深的外籍人士也是 * 个不可忽略的群体,为使在深外籍人士及时、准确地能接收到突发事件预警信息,保证信息公开透明,保障外籍人士知情权, (略) 短信发送时,需要考虑短信内容的多语言支持。针对 (略) 日韩居民数量大特点,在实现中英文预警内容的基础上,进 * 步拓展日、韩等多国语言以适应对外籍人士母语发送预警的需要。 多语言可拓展主要通过模板化方式在编码阶段实现,通过对应语言,允许发布单位录入多语言版本的短信内容,在面向外籍 (略) 靶向发送时,根据人群国籍属性实现指定语言版本的定向发送。 2.2.2 (略) 安全管理平台升级 在 * 期建设架构下,规划本期安全管理平台升级建设内容。根据现状分析与需求分析,本项目将按照《信息安全技术 信息系统等级保护安全设计技术要求》和《信 (略) 络安全等级保护基本要求GB∕T 点击查看>> 9》(即最新的“等保2.0”标准)规范的标准实现平台安全保护能力的提高,具体包括: (1) (略) : (略) 是 (略) 市突发事件预警短信发布平台的建设方,主要负责平台的建设和安全运维,因此需要重点保障系统自身的安全和使用好 (略) 提供的安全能力,保障系统达到 * 级等保的安全要求。 (2)市大数 (略) :大数 (略) 是平台承载环境的提供方,主要保障物联环境和云平台的安全性达到等保 * 级的要求, (略) 提供满足 * 级等保必备的安全能力,帮助平台满足 * 级等保的安全要求。 因此,本平台主系统端等级保护 * 级建设设计, (略) (略) , (略) 署在 (略) 市政务云平台。主备系统端的信息 (略) 由市政务云提供,向其申请安全服务各 * 套用于主备系统的安全保护。主系统端信息安全服务主要包括访问控制、WEB安全、漏洞扫描、审计服务、数据库安全、防病毒等服务。 主要的建设内容如下: 1、 (略) 署模式,将平 (略) 署到市政务云上,由市政务云平台 (略) 需的等保 * 级标准的安全服务。本次建设中,基础设施的安全由大数 (略) 负责,包含访问控制、WEB安全、安全审计及其他等保 * 级必要的安全措施。 2、 (略) 端基础支撑系统建设,购 (略) 操作终端、4套热备容灾软件和1台身份认证设备保 (略) 操作终端的主机安全和身份认证;在 * (略) 署1台防火墙、综合日志收集探针、攻击检测防御探针、异常流量检测防御探针、基础设施运维管理软件和数据加密系统; 3、对安全 (略) 升级,提升了漏洞和事件管理能力,通过安全探针 (略) 署对漏 (略) 统 * 收集、分析和管理。 在等保2.0 * 级中, (略) 集中管控存在如下要求: 应对安全设备、网络设备和服 (略) (略) 集中监测; 根据等保2.0 * 级中关 (略) 集中管控的要求,应对分散在各个设备上的 (略) 收集汇总和集中分析,并保证审计记录的留存时间符合法律法规要求; (略) 络中发生的各类 (略) 识别、报警和分析 平台 * 期建设缺少满足这 * 要求的功能,因此平台 * 期将针对这 (略) 集中升级。 安全管理平台图示 2.2.3 主系统端基础支撑系统 (略) 端基础支撑系统建设,购置热备容灾软件(包括2台接口系统、2台预警发布系统、2台数据库系统、1台存储系统)、 (略) 操作终端和4台身份认证设备保 (略) 操作终端的主机安全和身份认证;在 * (略) 署1台防火墙、综合日志收集探针、攻击检测防御探针、异常流量检测防御探针、基础设施运维管理软件和数据加密系统;采用大数 (略) 提供的政务云服务,保障物联环境和云平台的安全性达到等保 * 级的要求。 主系统端基础支撑系统清单如下:
* 、项目建设依据 3.1建设依据 3.1.1 政策依据 1. 《 (略) 办公厅关于印发国家突发事件应急体系建设“十 * * ”规划的通知》(国办发﹝ * ﹞2号) 2. 《国家 (略) 会发展第十 * 个 * 年规划纲要》( * 日十届全国人大 * 次会议审议批准) 3. 《国家突发公共事件总体应急预案》( (略) * 日发布) 4. 《“十 * * ”期间国家突发公共事件应急体系建设规划》 5. 《国家突发事件预警信息 (略) 管理办法(试行)》(国办秘函〔 * 〕 * 号) 6. 《全国地质灾害防治“十 * * ”规划》( * (略) 长办公会审议通过) 7. 《 (略) 省 (略) 会发展第十 * 个 * 年规划纲要》( * 日省十届人大 * 次会议审议批准) 8. 《印发 (略) 省突发事件预警信息发布管理办法的通知》(粤府办[ * ] * 号) 9. 《 (略) 省<国家突发事件预警信息 (略) 管理办法(试行)>实施细则》(粤办函〔 * 号) * .《 (略) 省气象发展“十 * * ”规划》(粤发改农经〔 * 号) * .《 (略) 市人民政府办公厅关于印发 (略) 市全面深化气象管理体制改革实施细则的通知》 * .《 (略) 市人民政府办公厅关于印发突发事件预警信息发布若干规定的通知》深府办函〔 * 〕 * 号 * .《深汕特别 (略) 区气象发展规划( 点击查看>> 年)》 * .《 (略) 市人民政府办公厅关于印发 (略) 市突发事件预警信息 (略) 办法的通知》深府办函〔 * 号 * .《关于信息安全等级保护工作的实施意见》(公通字[ * ] * 号); * .《信息安全等级保护管理办法》(公通字[ * ] * 号); * .《预报司关于确定国家突发公共事件预警信息发布系统(国家级和省级)信息系统安全等级保护级别的通知》气预函〔 * 〕 * 号: ?信息系统的安全保护等级由两个定级要素决定:等级保护对象 (略) 侵害的客体和对客体造成侵害的程度。由于 (略) 市突发事件预警发布系统对 (略) 市几千万手机 (略) 短信,受到破坏后,可能被利用以 (略) 市突发事 (略) 名义向几千万手机用户发送反动信息或诈骗信息,对社会秩序和公共利益造成严重损害,应定为 * 级。 ?各省(区、市) (略) 和公 (略) 要按照确定的等级,向当地公安机关备案,并按照第 * 级要求,做好该系统的安全防护工作。 3.1.2 技术标准 1. 《中华 (略) 络安全法》 2. 《国家突发事件预警信息发布系统管理平台与终端管理平台接口规范》(GBT 点击查看>> 7); 3. 《突发事件预 (略) 建设规范-平台构建(DB * T * * )》 4. 《突发事件预 (略) 建设规范-岗位设 (略) (DB * T * * )》 5. 《突发事件预 (略) 建设规范-信息发布与传播(DB * T * * )》 6. 《突发事件预警信息发布管理规范》(SZDB/Z 点击查看>> ) 7. 《突发事件预警信息发布系统数据交换规范》(SZDB/Z * — * ) 8.《信 (略) 络安全等级保护基本要求》GB∕T 点击查看>> 9 9.《信 (略) 络安全等级保护安全设计技术要求 GBT 点击查看>> 9》 * .《信息安全技术 信息系统安全等级保护实施指南》GB/T 点击查看>> 0; * .《信息安全技术 信息系统安全等级保护定级指南》GB/T 点击查看>> 8; * .《信息安全技术 信息系统安全等级保护测评要求》GB/T 点击查看>> 9; * .《信息安全技术 信息系统安全等级保护体系框架》GA/T 点击查看>> ; * .《信息安全技术 信息系统安全等级保护基本模型》GA/T 点击查看>> ; * .《信息安全技术 信息技术安全性评估准则》GB/T 点击查看>> 1; * .《信息安全技术 信息安全风险评估规范》GB/T 点击查看>> 7; 3.1.3 其他依据 1. (略) 省突发公共事件预警信息发布系统备案证明 2. 编制按照国家、行业的有关标准、规范及《 (略) 市政府投资信息化工程 (略) 性研究报告编制指南》《 (略) 市政府投资信息化工程建设项目初步设计及概算编制指南》和《国家发展改革委关于发布<项目申请报告通用文本>发改投资[ * 号》进行设计。 3. (略) (略) 有限公司与 (略) (略) 合同; 4. (略) 提供并承诺其真实性的资料; 5. 项目其它调研资料。 * 、服务要求 4.1 主系统端应用系统服务要求 4.1.1 日常运维 为保证项目建成后7× * (略) ,配置不 (略) 维护人员,根据项目规划,系统运维服务包括信息化系统软硬件维护。 1、★日常驻点服务:非公众假期星期 * 至星期 * 的9: * - * : * 为日常驻点服务时间。 2、 (略) 和指导:根据故障的类别、故障对系统性能和服务的影响,将技术服务请求按照紧迫性分为 * 个等级:紧急故障服务请求、重大故障服务请求和 * 般故障服务请求,等级由招标方确定。在接到故障申告、咨询或技术服务请求后,根据故障类型的不同,安排相应的技术支援工程师立即予以电话指导,电话技术指导服务为7天* * 小时。 3、现场支持:在接到技术支持服务请求后, (略) 和指导无法解决系统发生的技术故障, (略) 支持的情况下,收到故障报告服务请求后,在1个小 (略) ,,立即解决问题。对于由于软件或硬件缺陷引起的紧急故障,提供临时解决方案,并在1天时间内最终解决。对紧急故障,将组织 * 级技术支援体系下的技术专家小组,提供每周7天、每天 * 小 (略) 服务。 4、应急运维服务:需提供高级技术人员2名纳入平台系统运维保障岗管理,在启动 * 级或更高级别的 (略) 应急响应时,该运维保障岗需到岗提供7天* * 小时不间断技术支持, (略) 应急响应降级或取消。 5、对系统作定期或不定期技术巡检服务并建立完整的技术维护档案,将每次技术维护的类型、日期、维护内容、维护措施、维护人员、故障原因、处理结果等要素详细记录并归纳入库并形成完整的维护档案库。 6、通过日常维护及巡检等服务,查找不利于 (略) 的因素或诱发系统故障的因素,如是系统缺陷引起的,应 (略) 系统软件升级并向用户发出升级预告。如是业务应用或管理上引起的,则对用户提出有针对性管理建议或意见。 7、对与突发事件预警信息发布系统相关的接口和渠道 (略) 定期巡检,保证系统 (略) 。 4.1.2 (略) 维护 政务云即将上线云管平台。云管 (略) 分配账号, (略) 侧通过账号登录云管平台,对部署在政务云的 (略) 日常的运维监控管理; * 旦发现问题后,云管平台上可查看到相应告警信息,可 (略) 置;比如登录服务器做相应操作;如果需要大数 (略) (略) 理,可以在云管平台上按流程提交申请。 (略) 维护方案主要包括硬件设备的维护、安全维护、应用系统维护等。 具体如下: 1. 硬件设备的维护 1)硬件日常维护 包括定期对 (略) 灰尘清理,状态观测, (略) 件的日常操作维护。 2)硬件故障诊断及排除 当硬件设备出现故障后,若经判 (略) 维修, (略) 维修,同时更换备品备件以 (略) 正常。 3)硬件迁移、添加、调整、升级 当 (略) 变更,以及 (略) 调整时,需要对 (略) 变更,进行硬件的迁移或者添加。系统功能提升,硬件设备也应根据系 (略) 调整和升级。 2. 网络维护 1)故障管理 (略) (略) 理常见问题的解决方式。 2)资源管理 (略) 络中的设备(如网络中设备、单板、端口、接口、链路等)资源的基本情况, (略) 络中的异常资源信息。 3)网络性能管理 为了更好地 (略) (略) ,承建单位提供管理员必须掌握的性能指标,并能 (略) 长时间监控分析,做到提前预防,防患未然。 3. 安全维护 (略) 业务系统 (略) 中提供服务,日常至少1人服务,紧急保障任务,需至少2人服务,每季度形成安全运维报告。 为了保证业务系 (略) ,需要建立以下机制: 1)对 (略) 岗前培训; 2)限定 * 般用户权限,防止非 (略) 络; 3)及时升级防病毒软件,加强病毒防范意识; 4)通过设置访问控制, (略) 安全; 5)及时增加安全补 * ,建立和实施有效的用户口令和访问控制等制度; 6)及时对 (略) 备份。 4. 应用系统维护 1)应用系统巡检 为了保证系 (略) ,需要按周、按月 (略) (略) 巡检, (略) 存在的潜在异常,保证系 (略) 。 2)应用系统升级 随着技术的日新月异,需要定期对系统软件以及功能性 (略) 升级优化, (略) 的性能。 3)故障保障 (略) 后,随着用户量的增加和不可预知的用户频繁调用程序,可能会导致系统出现异常,需要制定详细的平台故障应急方案来应对,最大程度上保证系统的 (略) 。 4)日志统计 由管理员每天审计和审核日志记录情况, (略) 出现的故障要记录详细情况。系统日志应保留 * 年时间,在 * 年之后系统管理员确定后方可删除。 4.1.3 (略) 维护 数据是本项目应用系统运转的基础和运转的成果,通过建立严格的数据库备份与恢复机制,保障数 (略) ,同时建立 (略) 维护方案, (略) 的现势性。 1. 数据库的备份与恢复 数据库的备份与恢 (略) 维护管理中非常重要的环节,务必做好应用数据库的完全备份和增量备份。 1)完全备份 最近 * 月的完全备份应保存在备份 * 体机上。 完全备份应在非 (略) 。暂定每周 * 下午6: * ~8: * ,备份后应做好备份记录。 2)增量备份 在数据库服务器上对数据库做每天的增量备份。 3)应用数据的恢复 当数据丢失,可先根据增量备份的数据用整个数据库替换的方式恢复;如果采用增量方式不能完整恢复数据,应采用最近的全备份数据完成数据恢复。 2. 数据更新维护机制 针对本项目的系统数据,通过应急更新、定期更新、共建共享更新、联动更新 * 种模 (略) 更新维护。 4.1.4 重大服务保障 根据 (略) 的要求及相关规定,在重大灾害天气过程中提供系统的应急维护工作, 服务提供商应成立专门驻点维护组,确保 (略) ,在重大天气时 (略) 应急维护,重大 (略) 全程跟进8次以上。其主要包括以下内容: 针对台风、暴雨等重大灾害天气, (略) 市气象台 * 旦启动 * 级响应,需提供全天 (略) 跟踪服务。在此期间,派驻 (略) 进行 * 小时驻点服务,保障台风黄色等高级别预警信息的正常发布,以及突发事件预警信息发布系统相关各个渠道的正常传输。系统运维以及信息安全保障;针对系统提供日常维护及信息安全和应急维护服务;要求服务提供商成立专门驻点维护组,确保 (略) ,在重大天气时 (略) 应急维护,重大 (略) 全程跟进8次以上。 4.2 (略) 安全管理平台服务要求 4.2.1平台软件维保 ★提供 * 年的平台软件维保服务,当设备发生故障时售后技术服务人员将在第 * (略) 进行设备检查与维护,对信息安全系统平 (略) 诊断和修复,保障平台的 (略) 4.2.2平台安全检测服务 平台升级上线前, (略) 专项的漏洞扫描和渗透测试,对平台的 (略) 检查并及时对发现的 (略) 修复,确保平台自身的安全。 4.2.3 平台配置优化 提供 * 年的平台策略优化服务,通过 (略) 人员对平台业务流程和 (略) 分析,并根据分析结果对平台各项 (略) 配置优化,并根据实际的安全需求不断对入侵防御、资产监控、网络攻击监测、网络安全漏洞检 (略) 优化,平台可以满足等级保护的要求,并与 (略) 的人员、业务流程相结合,有效支撑突发事件分区预警信息发布短信平台的安全。 4.3 主系统端基础支撑系统服务要求 4.3.1政务云安全策略申请及优化服务 根据等级保护 * 级的安全要求,向市大数 (略) 申请虚拟防火墙(vFW)服务、边界防火墙服务、抗DDoS服务等云 (略) 策略配置,并根据实际的安全需求不断对云WAF、云防火墙等安全设 (略) 优化,保障申请的安全服务的能力最大化,可以有效保障 (略) 市突发事件分区预警短信发布平台的安全。 4.3.2 硬件维保服务 针对基础支撑系统购买的安全管理平台攻击检测防御探针、安全管理平台异常流量检测防御探针、安全管理平台基础设施运维管理、安全管理平台综合日志收集探针和数据加密系统等安全设备提供 * 年硬件维保服务,设备出现问题后,售后人员将在1 (略) 响应, * 小时内完成 (略) 置。 4.4主系统端与运营商端服务边界界定 由运营商保障突发事件预警信息发布平台 (略) 络区域的基础设施安全、网络环境安全、应用系统安全和数据安全, (略) 保 (略) (略) 络环境安全、应用系统安全和数据安全及提供各项安全策略的配置。
为保障平台业务连续可用,运营商应为平台业务安全提供必要的保障措施: (1) 当平台发生故障时,运营商应第 * 时 (略) 进行故障排查分析,确认故障源; (2) 当平台故障原因确认发生在运营商端时,运营商应第 * 时间响应,及时 (略) ; (3) (略) 络安全事件,需要 (略) 理时,运营商 (略) (略) 置; (4) 当平台运 (略) 络安全事件时,运营商应及时响应采取措施恢复平台安全。 * 项目分项清单 5.1主系统端应用系统功能清单
5.2 (略) 安全管理平台升级功能清单
5.3 主系统端基础支撑系统
* 、实质性条款
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
商务需求 | * 、服务期限:_项目建设期为 * 年,建设期之后 * 年为免费维护期。 * 年7月份前完成短信发布平台功能 (略) (略) 署。 1、★建设工期为 * 年。监理单位签发开工令后 * 年内完成设备供货、设备安装调试、 (略) 署及项目验收工作。 2、★建设期满后 * 年为免费维护期,时间自最终验收合格并交付使用之日起计算。 * 、服务地点:_ (略) __ * 、投标报价要求 1.本项目服务费采用包干制,应包括服务成本、法定税费和企业的利润。由投标供应商根 (略) 提 (略) 测算投标报价; * 经中标,报价总价作为中标供应商与采购人签定的合同金额,合同期限内不做调整。 2.投标供应商应当根据本企 (略) 决定报价,但不得以低于其企业成本的报价投标。评标时, (略) 认为投标人的报价明显低于其他通过符合性审查投标人的报价,有可能影响产品质量或者不能诚信履约的,应当要求 (略) 合理的时间内提供书面说明,必要时提交相关证明材料;投标人不能证明其报价合理性的, (略) 应当将其作 (略) 理。 3.投标供应商的报价不得等于及超过项目预算金额。 4.投标人的投标报价, (略) 文件及 (略) 列的 (略) (略) ,不得以任何理由予以重复,并以投标人在投标文件中提出的综合单价或总价为依据。 5.除非采购人通过修改采购文件予以更正,否则,投标供应商应毫无例外地 (略) 列的清单中项目和数量填报综合单价和合价。投标供应商未填综合单价或合价的项目,在实施后,将不得以支付,并视作该项费用已包括在其它有价款的综合单价或合价内。 6.投标供应商应先到项目地点踏勘以充分了解项目的位置、情况、道路及任何其它足以影响投标报价的情况,任何因忽视或误解项目情况而导致的索赔或服务期限延长申请将不获批准。 7.投标供应商不得期望通过索赔等方式获取补偿,否则,除可能遭到拒绝外,还可能将 (略) 为记录在案,并可能影响其以后参加政府采购的项目投标。各投标供应商在报价时,应充分考虑报价的风险。 * 、付款方式:_____按照完成服务工作进度和工作量制定分期付款方式_, (略) 有关规定支付。 * 、其他商务需求 ( * )安全保密要求。要求参与本工程建 (略) 人员都必须是政治可靠、责任心强的人员,而且在本工程的整个建设工作当中,建设都必须严守秘密,对于泄密的要追究当事人及单位责任,造成严重后果的除终止合同外,并追究当事人和单位领导的相关责任。建设公司需与该项目建设人员购买相应的保险签订保密协议书。 ( * )开展半年度和年度的项目建设工作总结和计划下 * 步工作。要求项目负责人开展年度和半年度项目建设总结,总结建设工作,分析问题,提出下 * 步工作计划。 * 、质量考核验收标准 1.质量考核验收标准:
注:★项目最终实施方案要求以经过专家评审通过的深化设计结果为准。 * 、违约责任 根据情况制定 ,违约金: (1)因承建单位造成合同期内安全、质量事故的,除承担相应法律责任外,建设单位可视情节严重程度 (略) 以 * 元的罚款,并通报批评。 (2) (略) 罚: 1)承建方未按照建设要点、日常建设和过程建设完成并提交相关工作文档的, (略) 罚建设费 点击查看>> 元/次,建设单位同时保留追究承建单位相应法律责任的权利。 2)建设单位每季度对建设工作 (略) * 次评价,如有两次服务质量评价不合格,建设单位有权中止合同,并将履约评价提交 (略) 。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
评标信息 |
说明 1.根据《 (略) (略) (略) 关于印发< (略) 市政府采购落实支持企业复工复产政策的实施细则>的通知》(深府购〔 * 〕 * 号)的规定,1. (略) 保证明。对于评审时需考察人员情况的政府采购项目,投标人无 (略) 保证明。 (略) 至 * 日;2.顺延既有认证证书有效期。对于评审时需考察投标人资质、认证等情况的政府采购项目,投标人提供的证书已到期的(到期时间为 * 日至 * 日),视同在有效期范围内;3.鼓励采购人积极运用公共信用信息,明确对信用记录良好的投标人(特别是中小微企业)免收履约保证金,确需收取履约保证金的,列明通过保函等非现金方式收取;4.在采购合同中明确对上述企业加大首付款或预付款比例,具体由采购人根据项目实际情况确定。 2.采购人拟采购的服务(工程)中,如涉及《关于调整优化节能产品环境标志产品 (略) 机制的通知》(财库〔 * 〕9号)中的产品,要依据该 (略) 。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
其他 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
附件 | 附件4: (略) 市突发事件分区预警信息短信发布系统 * 期(主系统端) (略) 申报书( * ).doc |
最近搜索
无
热门搜索
无