区块链电子签章应用平台建设方案文档格式.docx
- 文档编号:21625732
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:21
- 大小:83.97KB
区块链电子签章应用平台建设方案文档格式.docx
《区块链电子签章应用平台建设方案文档格式.docx》由会员分享,可在线阅读,更多相关《区块链电子签章应用平台建设方案文档格式.docx(21页珍藏版)》请在冰豆网上搜索。
2.总体设计
2.1.总体目标
采用信息化手段,通过计算机应用软件、区块链技术建设区块链电子签章应用平台,深入推进“互联网+政务服务”工作的决策部署,围绕区块链电子印章制发、使用、维权等各环节,全面推进企业区块链电子印章在政务服务领域跨行业、跨区域、跨层级应用,大力拓展企业区块链电子印章在商务领域应用范围,从而构建“互联网+”环境下政府新型管理方式,逐步减少企业纸质执照和实体印章使用需求,建立程序更便利、资源更集约的政务服务新模式,营造更加便捷高效的营商环境。
2.2.设计原则
根据系统特点和要求,在“先进性、实用性、标准化、开放性、整体性、共享性、安全性、保密性、可靠性、经济性、可扩展性、可维护性”等十二个方面提出原则性要求如下:
(1)先进性
系统采用国际先进的软件体系结构,先进的技术标准,保证系统的生命力。
系统的建设应以“高起点、高标准”严格要求,在系统设计上,首先应当具有前瞻性。
(2)实用性
系统结合实际的业务处理流程以及业务管理工作流程,设计结构合理、功能实用、符合实际业务需要的系统。
系统的设计在运行环境、使用操作等方面以实用为主,以方便使用和维护为出发点。
(3)标准化
系统建设采用的软件平台、数据标准、开发技术应符合公认的标准,符合国家、地方的有关标准与规范。
采用标准的数据描述语言以及标准的通信协议,适应以后的数据交换标准以及系统间互连的标准协议等。
(4)开放性
软件体系结构上,应充分考虑系统的开放性。
以模块化设计和基于组件的多层结构体系保证系统的开放性和灵活性。
(5)整体性
系统建设需进行整体的规划完善,通过科学的分布实施,建立全面覆盖业务,符合要求的系统。
系统建设具有整体性,即内容上全包括、数据上全部共享、流程上相互衔接、管理上协调统一。
(6)共享性
系统通过搭建共享平台接口进行数据共享,同时,系统提取和分析的信息库也能以标准的数据接口开放给其他部门使用,打破部门壁垒、信息孤岛,为业务管理提供有力的依据和手段。
(7)安全性
从身份验证到资源授权访问再到数据的安全性。
系统提供网络层和应用层的安全手段,防止系统外部成员的非法侵入以及操作人员的越级操作,从多个角度、环节考虑,确保系统和数据的安全。
(8)保密性
系统在权限功能规划上要考虑全责明晰,建立合理的可分配权限,使内容、功能管理有效、有序,减少人为的操作风险。
系统的访问和操作具备可回溯性,操作人员进行了哪些操作都有记录可查。
(9)可靠性
本系统为多部门使用的系统,系统需健壮、无故障运行周期长,应具有较高的性能可靠性。
(10)经济性
系统在规划和实施过程中,必须立足于现状,着眼于未来,遵循“统筹规划、分布实施、整合资源”的原则,避免系统的重复建设以及资源浪费。
(11)可扩展性
系统可以根据实际情况进行灵活的配置和组合,能方便地进行功能的调整以及系统的升级、扩展,以适应业务的不断发展和更新。
(12)可维护性
将应用与技术分离,建设方维护人员可自行维护本系统,如人员岗位的调整、工作流程的变化等,不需要对软件本身进行任何重新编码,通过维护模块的调整即可实现。
2.3.总体架构
系统主要由“1个规范、1个数据库、1个系统”构成。
“一个规范”即数据标准规范,根据电子签章管理要求,基于国家、省、市相关技术标准规范编制一套适应电子签章管理建设要求和实际情况的标准规范体系。
;
“一个数据库”即“电子印章基础信息资源库”,作为整个项目的基础数据支撑;
“一个系统”面向电子印章管理工作,实现区块链电子签章应用平台,主要包括:
区块链基础平台、基础服务引擎、应用开放平台、印章综合管理、印章移动终端服务等功能。
系统总体架构主要包括感知层、网络层、数据层、服务层、平台层、应用层、政策法规、安全标准等层面。
项目建设基于信息标准,实现信息数据的集中部署,要做到以下五个方面的统一:
●统一数据标准(数据系统架构、数据库结构、数据表);
●统一基础信息(文字、图片、音视频、虚拟素材等);
●统一地理信息(位置信息、GPS数据、电子地图);
●统一交换接口(内部数据交换接口规范、开放数据接口规范);
●统一技术平台(硬件、软件、网络、安全)。
感知层:
通过各类数据采集和感知技术,如:
RFID、条形码、传感器、摄像头等,实现数据采集和存储,为整个系统治理应用体系提供基础数据的支撑;
网络层:
构建应用级物联、感知、互联、通信、卫星网络,为数据信息的传输流通起到支撑作用;
数据层:
建立以基础地理信息服务、基础设施服务为一体的空间数据服务体系,为平台建设奠定空间信息基础与数据支持;
统一服务平台:
系统业务处理的逻辑平台,它通过对数据核心层的调用访问业务数据,实现不同的功能模块,满足不同的业务需求;
所有业务功能在此统一平台上得到良好的封装和定义,以Web、手机终端服务的形式,运作在平台上,为用户提供各类信息服务;
应用层:
对于应用层,提供多样化的界面逻辑,实现对业务逻辑的应用。
2.4.应用架构
区块链电子签章应用平台的应用架构主要包括数据采集、平台数据、应用支撑、应用系统等。
系统主体采用B/S框架,辅助功能可采用小程序解决,兼容目前主流的系统,包括浏览器(系统能在IE各版本、chrome、firefox等主流浏览器下,应用功能均可正常运行),最大限度降低系统的部署、维护成本,提高系统的易用性。
平台数据库采用分步式数据库,并兼顾数据库节点路由规则的扩容改造及易维护性,采用J2EE架构开发。
系统部署于Linux操作系统下,web服务器采用apache/nginx,系统采用严格的静态、动态分离的结构设计,采用负载均衡技术,并提供基于HTML5的访问页面。
使用Tomcat服务器中间件系统作为Web服务解析动态页面。
采用预分析等缓冲技术提高系统效率。
2.5.数据库设计
2.5.1.历史数据库设计
历史数据库用来存储实时数据库的历史数据。
实时数据库中只有各种设备的当前值(状态),而以前的实时数据要存储在历史数据库中,以备日后查询。
为了可以精确获取每个数据采集仪的任何时候状态,历史数据库中要保存所有节点的全部采样数据。
历史数据库系统采用大型商用关系型数据库。
历史数据库系统是整个应用程序的数据层。
它为各种客户提供所需要的历史数据。
历史数据库系统采用双机备用方式。
历史数据服务库系统的功能包括:
采样历史数据的存储;
计算各种分析所需的统计数据;
记录变位、SOE等随机性数据;
记录用户对应用程序的操作的日信息;
存储用户权限等安全信息;
提供Web发布所需的各种历史数据。
历史数据库系统的数据源由实时数据库系统提供,在实时数据库系统中,已经对数据质量、数据一致性、完整性作了处理,因此由实时数据库系统提供给历史数据库系统的数据均为有效数据。
实时数据库系统负责定时的将有效数据送给历史数据库系统的代理程序,随机数据在产生的时候送给代理程序,代理程序负责将数据写入历史库中。
同时代理程序负责定时对采样数据进行统计、计算并将结果存入数据库中。
历史数据系统示意图
2.5.2.历史数据
由实时数据库提供的采样数据存储在历史数据库中。
这些数据按类别、时间存储在数据库不同的历史表中。
I数据表命名规则
历史数据表名称按照一定的命名规则:
类型名称+时间。
如:
2001年7月10日的模拟量采样数据表应命名为SmpAna20010710,这张表将存储这一天的所有的模拟量采样数据。
以上设计主要基于对采样数据的查询方式,主要是要某一个量在某一段具体时间内的数据。
数据不存放在一个数据表中,可以大减少检索的次数。
当检索一个数据的时候,是先从系统数据表中检索出这张表的位置,然后定位这张表,再检索需要的数据。
而不必从一个大表中反复的检索、查找和定位。
这种检索方式也近似于字典查找的算法理论。
对于计算、统计数据也采用近似的处理方式。
II数据表索引(Index)
数据库的索引是一个B型树的数据结构。
当写入一记录时,数据库会对记录产生一个索引值,并在系统索引表(Sysindexes)中产生一条索引记录。
在检索一条记录时,从树的根节点到树叶的搜索方式进行,从而对有索引的记录加快检索速度。
但同时也降低了写入的速度。
对于采样数据,主要是记录值,因此可以考虑用没索引的表来表示。
III数据压缩存储
采样数据可能是一些不断重复的量。
重复记录会加大存储的空间和记录的行数。
因此可考虑数据变化时才存储,记录一个状态(值),并记录这个状态(值)重复的次数。
也就是:
数值—变化的压缩方式。
具体设计如下例:
如有一个模拟量,前一次的值如果和本次的值相同,则在记录中的次数计数器加1,否则添加一条记录。
2.5.3.统计数据
历史数据的存储方式同样是将数据按类分散在不同的表中,表要具有统一的命名规则。
数据统计是将各种采样数据计算生成所需要的一些统计数据。
数据统计与采样数据记录是同步进行的。
也就是说,当从实时数据库中取得采样数据并写入到采样记录表中的时候,就会触发一系列的统计和计算工作。
有一系列的中间结果产生出来,当在时间上满足要求的时候,就会将这个中间结果记录到相应的统计数据表中。
统计计算工作用ORACLE的触发器(Trigger)来完成,当采样数据更新时,会触发一系列的事件产生,事件驱动一系列的处理程序来处理是否写入数据库,更新统计数据的中间结果等。
2.5.4.临时表
临时表具有与普通表完全一样的属性,所不同的是它存储在Tempdb中而不放在当前数据库中,当用户连接并创建使用时它存在,当用户断开后临时表也会自动删除。
全局性临时表(以##开头作为标识):
会各所有连接到数据库的用户开放,每一个用户均可以访问,只有当所有的用户都断开后,全局性临时表才会自动删除。
临时表的设计主要是为了考虑提高对报表、查询速度的要求。
通过组态的报表或定制的某个查询,是对固定的一些参数进行数据检索,这些量使用的频率最高。
考虑减少在无关的数据堆中检索的次数,因此想把这些用户最关心的数据量的记录放在一个专门的地方。
由于数据源的记录本来已在数据库中存在,而同样的数据在数据库中不应该重复,所以考虑将这样的数据放在临时表中,且为全局性临时表,为所有的数据连接用户开放。
临时表中的记录是最近一个时间段的数据和最近使用过的数据。
处理临时表中记录的算法应是先进先出的原则和最久不使用原则。
新数据将最老的数据并且最久没有使用过的数据覆盖。
临时表中的数据始终保持最新和最新使用过的数据。
这些数据也是用户使用频率最高的数据,这样可以提高报表、查询的检索数据速度。
2.5.5.数据冗余处理
数据冗余采用磁盘阵列的方式来实现。
数据冗余示意图
2.5.6.数据库安全
数据库安全性问题一直是系统安全的关键。
数据库安全性问题应包括两个部分:
(1)数据库数据的安全
它应能确保当数据库系统DownTime时,当数据库数据存储媒体被破坏时以及当数据库用户误操作时,数据库数据信息不至于丢失。
数据安全的解决,主要有系统双机热备份、数据库的备份和恢复等办法,本系统的数据安全,纳入信息中心的系统安全体系,共享一些硬件设施,实现数据的备份等。
(2)用户角色的管理:
这是保护数据库系统安全的重要手段之一。
它通过建立不同的用户组和用户口令验证,可以有效地防止非法的Oracle用户进入数据库系统,造成不必要的麻烦和损坏;
另外在Oracle数据库中,可以通过授权来对Oracle用户的操作进行限制,即允许一些用户可以对Oracle服务器进行访问,也就是说对整个数据库具有读写的权利,而大多数用户只能在同组内进行读写或对整个数据库只具有读的权利。
在此,特别强调对SYS和SYSTEM两个特殊账户的保密管理。
为了保护Oracle服务器的安全,应保证$ORACLE_HOME/bin目录下的所有内容的所有权为Oracle用户所有。
为了加强数据库在网络中的安全性,对于远程用户,应使用加密方式通过密码来访问数据库,加强网络上的DBA权限控制,如拒绝远程的DBA访问等。
2.6.标准化体系设计
标准化工作是组织、协调项目顺利发展的重要手段,也是系统的重要组成部分。
通过制定和贯彻执行各类技术标准,就能从技术上、组织管理上把各方面有机的联系起来,形成一个统一的整体,保证项目有条不紊的进行。
国内外信息化的实践证明,信息化建设必须有标准化的支持,尤其要发挥标准化的导向作用,以确保其技术上的协调一致和整体效能的实现。
因此,标准体系建设在系统实施过程中具有非常重要的意义,是系统设计和工程建设的重要基石。
为保证标准体系建设的顺利进行,制定以下总体目标:
1.系统标准化建设将与国家信息化建设标准保持一致性;
2.建立并不断完善系统标准体系;
3.制定系统关键基础标准,为系统互联互通、信息共享、信息安全打好基础;
4.建立系统标准贯彻实施机制,为标准的实施提供有效服务。
为了完成标准体系建设目标,本着“统筹规划、面向应用、突出重点、分工协作”的方针,依托现有资源和信息化工作的基础,坚持自主制定与采用国际标准相结合,加强与示范应用的有机结合,强化标准实施与监督力度。
系统标准体系主要由六个体系构成:
(1)应用系统体系
应用服务体系是由业务应用系统组成,是面向用户服务的,包括本期建设的基建项目建设综合管理信息系统。
(2)应用支撑服务体系
支撑服务体系由系统基本功能服务模块构成,为业务应用系统提供基础性的基本功能服务(例如数据交换(共享)、日志服务、消息服务、表单服务、短信、视频、电子地图引擎等)。
根据业务需求,系统通过数据交换平台实时或定期采集其他业务系统的数据,并对数据进行分类过滤处理。
(3)资源数据体系
资源数据体系为系统提供业务数据(例如基础信息数据、重点监控数据、主题数据、视频数据、目录资源数据、GIS数据等)支持服务。
(4)基础设施体系
基础支持体系为系统运行提供硬件和系统软件基础环境支持,由系统基础网络、服务器主机等系统硬件组织和操作系统、应用服务器系统、数据库管理系统等基础软件组织组成。
(5)安全保障体系
系统安全保障体系为系统各层提供安全运行保障。
例如包括认证、系统防火墙系统、病毒系统、数据备份系统、入侵检测系统等。
(6)运维保障服务体系
运维保障服务体系为系统建设提供运行维护,保障系统正常运行,业务连续,不断优化系统功能等。
3.系统设计
3.1.区块链基础平台
在电子签章应用平台中,需要解决数据在采集、存储、共享、使用过程中的可信存证能力,确保数据不被篡改、使用情况上链、数据问题可追溯。
为此,需要充分利用区块链的可追溯、防篡改、分布式的技术特性,将区块链应用为可信分布式账本,完成基于共享的可信数据账本的分布式业务协作建设。
该模式下,应用将关键的业务数据写入区块链,多个参与方可根据业务数据属性在链上准实时查询检索业务数据。
平台通过搭建基于私有云的区块链联盟链平台,基于主流联盟链技术(HyperledgerFabric)搭建区块链平台服务,帮助平台中的数据采集和共享平台以及其他业务系统的区块链应用场景快速构建稳定、安全的生产级区块链环境,减少在区块链部署、管理、运维、应用开发等方面的挑战,使用户专注于核心业务创新,通过通用的区块链API及SDK与各类应用系统实现无缝对接,实现业务快速上链。
平台包括以下功能:
(1)支持一键式快速创建和部署生产级区块链环境,提供图形化的区块链管理运维能力,实现参与方和业务的动态添加,简化区块链的部署流程和应用配置,加速基于区块链业务应用的开发、测试和上线。
(2)提供完善的联盟治理,包括联盟机构邀请,联盟管理员审批,有效地保护联盟链隐私。
(3)可基于虚拟机或物理机进行部署,同时支持动态扩容,节点扩展,灵活地管理联盟。
(4)可靠性高。
可实现业务的可靠受理,峰值业务缓冲,基于PBFT的共识技术提供高可用的拜占庭容错能力,支持共识状态自动恢复,区块数据互备恢复,数据存储自动均衡,节点服务自动路由。
(5)隐私安全。
控制台用户是基于角色的访问控制,区块链节点用户使用PKI认证体系。
区块链节点支持传输层安全性协议(TLS)。
区块链账本数据支持的数据隔离和隐私保护机制,能满足“不同人访问不同数据”的需求。
(6)可信存证。
区块链电子签章应用平台印章制发过程、印章领取过程、印章使用过程,全流程电子数据通过可信存证有效固证。
3.2.基础服务引擎
统一印章底层引擎是企业印章管理(小程序端)、印章管理门户的底层支持模块,对上提供相关的基础能力,对下对接区块链平台。
向上为印章管理平台提供基础能力,向下对接相关区块链应用,将上层印章管理门户产生的相关业务数据统一汇总并推送至区块链中,形成可信的数字存证。
3.2.1.数据交换引擎
印章印模数据将通过“公安印章治安管理信息系统”获取,为保障数据同步的整体稳定性与持续可检测,系统将提供数据交换引擎。
数据交换引擎将“公安印章治安管理信息系统”获取的数据资源转换为本系统使用的数据库类型,使系统能够稳定使用。
3.2.2.印章管理引擎
通过与“公安印章治安管理信息系统”打通,实现印章印模数据同步接收后,将电子印章同步推送至电子印章服务商,电子印章服务商依据相关信息与印模图片产生电子印章数据。
电子印章的相关数据符合国家相关标准,同时产生的电子印章数据会同步推送至公安完成电子印章数据备案。
备案后的电子印章数据可通过平台在“公安治安管理信息系统”中查询与验证。
同时整个电子印章的制作过程将会上链存储,保证当前电子印章数据可靠可信。
3.2.3.在线验真组件
为电子印章用户、电子印章应用系统提供统一验真服务。
支持用户直接在本平台对签署的PDF文件进行验真,应用系统可通过服务商提供的开放服务对文档进行验真。
验真过程符合国家电子签名与电子印章验证规范,验证内容包括电子印章完整性、电子印章有效性、数字证书有效性、电子签章完整性等内容。
同时针对电子签章的用章记录,也可通过区块链存证数据进行签署记录的查验。
3.2.4.服务商管理组件
提供面向服务商管理的基础能力集成,支持各个电子印章服务商接入平台并提供对应服务。
组件包含标准的服务商对接技术参数,电子印章服务商能够参照标准指标更新服务,接入本系统。
3.2.5.印章场景引擎
提供印章场景信息可视化更新模块,印章场景更新过程,能够按照实际展示的样式对场景内容进行编辑更新,印章场景信息更新完成后将得到与编辑过程相同的样式。
3.2.6.信息上链引擎
3.2.6.1.印章上链服务
对于印章的生命周期进行上链服务,关键信息包含:
印章唯一标识、印章所属企业信息、印模图片信息、长宽信息、印章类型信息(电子法定名称章、电子财务章、电子发票章、业务专用章、电子合同章)、印章状态(未备案、未领取、已领取、报废)等信息。
上链后的信息可通过区块链查验服务进行验证。
3.2.6.2.签署记录上链服务
对于印章的使用进行上链服务,关键信息包含:
印章唯一标识、印章相关信息、签署文件摘要信息、签署场景所属信息、签署方信息。
上链后的签署记录信息可通过区块链查验服务进行验证。
3.2.7.统一用户权限引擎
为系统管理员提供统一的用户权限管理引擎,超级管理员能够集中设置系统管理员的角色、权限。
系统管理员实际的操作权限与统一用户权限引擎配置的角色权限相同。
3.2.8.系统审计引擎
系统审计组件是支持系统审计功能的核心组件,面向平台中各类用户可操作功能提供通用的审计模块接入能力。
接入后的用户使用相应功能时,将会产生对应的审计数据并统一保存到审计组件中。
审计组件通用数据字段包含“操作时间、操作类型、操作人、操作结果”。
3.2.9.应用安全引擎
系统提供完整的应用安全策略,包含网络通信安全、主机安全、数据安全、业务安全等全面信息安全能力。
3.3.应用开放平台
应用开放平台面向政务服务系统与开发者提供电子印章相关应用的开放能力,方便相关开发者能够更方便的匹配相关的场景,为政务服务系统提供建设支撑。
3.3.1.服务商注册
第三方电子印章相关服务商需要在本系统中进行注册,获取本系统的账号后方能进行系统对接。
3.3.2.服务商接入申请
为了确保接入系统的服务商具有足够的服务能力,完成账号注册后,服务商需要提交相关资料,并通过管理人员的审核后,才能接入本系统。
3.3.2.1.服务商接入说明
系统提供服务商接入的操作流程说明与技术文档说明,计划接入系统的服务商能够根据操作流程说明准备需要审核的相关材料信息;
根据技术文档说明自行准备好相关对接接口。
为规范服务商接入系统的相关要求,避免不符合资质要求的服务商接入系统。
系统提供完整的服务商接入要求说明,服务商能够参照相关说明对自身提供的相关服务能力进行自查。
(1)接入流程说明
系统提供服务商接入的操作流程说明,计划接入系统的服务商能够根据操作流程说明准备需要审核的相关材料信息。
(2)技术文档说明
系统提供服务商接入的技术文档说明,计划接入系统的服务商能够根据技术文档说明自行准备好相关对接接口。
(3)服务商开放服务能力要求
为保障服务商的服务能力符合系统接入要求,服务商应当自行核对服务商开放服务能力要求中提出的具体服务内容,确保提供的服务内容质量。
对于不满足服务商开放服务能力要求的服务商,系统管理员在核查后,有权将相关服务商的服务进行下架处理。
(4)服务商应用安全服务能力要求
为保障服务商的应用安全能力符合系统接入要求,服务商应当自行核对服务商应用安全服务能力要求中提出的具体应用安全内容,确保提供安全的服务内容。
对于不满足服务商应用安全服务能力要求的
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 区块 电子 签章 应用 平台 建设 方案