久其资产方案书

行政事业单位资产管理信息系统

建设方案建议书

北京久其软件股份有限公司

2009年7月

本文档及其所含信息为机密材料

并且由北京久其软件股份有限公司拥有

本文档中的任何部分都不得以任何手段任何形式进行复制与传播未经北京久其软件股份有限公司书面授权，不得将材料泄露给第三方

目录

1系统概述 (5)

1.1系统建设背景 (5)

1.2系统建设目标 (5)

1.2.1系统建设总体思路 (5)

1.2.2系统建设的基本原则 (5)

1.3项目范围 (6)

2系统总体设计 (6)

2.1系统架构设计 (6)

2.1.1系统逻辑结构设计 (6)

2.1.2系统部署结构设计 (9)

2.2产品技术路线及灵活配置 (11)

2.2.1产品技术路线 (11)

2.3数据安全校验机制 (12)

2.3.1需求背景 (12)

2.3.2设计策略 (12)

2.4系统权限管理 (13)

2.4.1需求背景 (13)

2.4.2设计策略 (13)

3业务模块设计 (13)

4系统安全设计 (14)

4.1概述 (14)

4.2网络安全 (14)

4.3身份认证 (15)

4.4传输安全方案 (15)

4.5应用级权限管理 (15)

4.5.1用户管理 (16)

4.5.2功能权限 (16)

4.5.3单位权限 (16)

4.5.4数据权限 (16)

4.5.5单据权限 (17)

4.6日志管理 (17)

5系统软硬件方案建议 (17)

5.1系统部署方案建议 (17)

5.1.1分布式部署 (17)

5.1.2财政部门主管部门集中部署 (18)

5.2数据库服务器推荐配置 (19)

5.3应用服务器推荐配置 (19)

5.4单位版推荐配置 (19)

5.5其他 (20)

6系统备份方案建议 (21)

6.1系统备份方案 (21)

6.1.1双机热备份 (21)

6.1.2离线备份 (21)

6.1.3应用级数据备份 (22)

6.2系统备份策略 (22)

6.2.1系统备份内容 (22)

6.2.2系统备份策略 (23)

7系统建设与实施 (23)

7.1系统建设项目管理 (23)

7.1.1项目计划管理 (23)

7.1.2项目范围核实 (24)

7.1.3项目变更控制 (24)

7.1.4项目跟踪和报告 (24)

7.1.5文档的提交和确认 (24)

7.1.6质量控制 (25)

7.1.7进度控制 (25)

7.2财政资产管理部门资源配置建议 (25)

7.3风险控制 (26)

7.3.1项目风险分析 (26)

7.4项目实施过程 (26)

7.4.1实施计划 (26)

8需财政局关注事项 (33)

8.1财政部门 (33)

8.1.1网络环境、软件硬件配置准备 (33)

8.1.2软件安装配置 (33)

8.1.3系统设置 (33)

8.2主管部门 (34)

8.2.1交换中心信息配置 (34)

8.2.2系统设置 (34)

8.3基层单位 (34)

8.3.1清查数据初始化方法 (34)

8.3.2单位编码规范 (35)

8.3.3动态数据审核 (35)

9工作建议 (35)

9.1统一认识 (35)

9.2划分权责 (36)

9.3协调统一 (36)

9.4硬件准备 (36)

10技术支持与服务方案 (37)

10.1技术支持服务体系 (37)

10.2技术支持服务方式与内容 (37)

10.2.1预防性维护 (37)

10.2.2热线电话、传真和电子邮件支持 (37)

10.2.3远程在线诊断和故障排除 (38)

10.2.4现场响应 (38)

10.2.5提供系统应急策略 (38)

1系统概述

1.1 系统建设背景

目前行政事业单位国有资产规模大，涉及单位众多，汇编范围庞大、数据量大，资产管理手段落后，在许多行政事业单位都有不同程度存在资产存量不清、账实不符、闲置浪费、配置不公、流失严重等问题。这些问题的产生的原因有多方面，资产管理信息化程度不高是其中重要原因。资产信息化相对落后，存在资产管理数据静态管理，数据信息实效性差，信息孤岛现象严重，已经不能满足对行政事业资产管理与监督的要求，通过信息化手段建立动态资产管理与监督信息化管理系统，已迫在眉睫。

随着财政部《行政单位国有资产管理暂行办法》、《事业单位国有资产管理暂行办法》两个办法的公布实施，为行政事业国有资产管理信息化建设指明了方向，同时也进一步促进了行政事业资产管理信息化进程，通过信息化管理使行政事业国有资产管理向规范化、科学化、法制化方向发展，保障行政事业单位国有资产安全完整、合理配置和有效利用。

为了推进行政事业资产管理信息化，财政部已在全国范围进行了资产清查，为建立行政事业资产管理信息系统打下了良好的基础。在金财工程相关子系统的建设为资产管理信息系统提供了良好的网络、技术、标准规范。同时各级财政部门在行政事业资产管理信息系统建设方面也作了有益的探索和建设。

1.2 系统建设目标

1.2.1系统建设总体思路

1、建立资产管理动态数据库，全面、准确、动态地反映资产的总量、构成、分布、变动等信息。以全面、彻底的资产清查结果作为初始数据来源；根据资产增减变动情况实时更新。

2、以动态数据库为基础，建立数据查询和综合分析子系统，方便、快捷地查询和分析资产占有、使用及增减变动情况，为预算管理、绩效评价和资产优化配置等提供决策支持。

3、确立资产管理工作规程，实现资产管理业务的规范化、流程化、网络化。建立“财政部门-主管部门-行政事业单位”三级管理平台，满足不同层次的管理需要；涵盖资产配置、使用、处置、收益、清查、统计、产权纠纷调处等各项管理内容；以技术手段规范资产管理行为，控制资产运营风险，防止国有资产流失；简化审批程序，提高工作效率，降低管理成本。

4、建立资产预警信息系统，及时、自动提供预警信息。

5、实现财政部门与主管部门、行政事业单位之间的资产管理信息畅通。

1.2.2系统建设的基本原则

系统从设计思想上力求在基于资产管理实际业务的基础上，紧密结合了财政部《行政单位国有资产管理暂行办法》和《事业单位国有资产管理暂行办法》，在资产配置、资产使用、

资产处置等全过程进行管理，同时充分体现了资产管理与预算管理相结合、资产管理与财务管理相结合、实物管理与价值管理相结合的管理思想。

1、体系完整。

（1）适应行政事业单位国有资产“国家统一所有、政府分级监管、单位占有使用”的管理体制，按“财政部门—主管部门—资产占有使用单位”三个监管层次，建立起满足不同级次、不同管理主体不同管理需求的行政事业资产管理信息化体系。

（2）适应行政单位资产管理、事业单位资产管理不同的管理要求，分别设计有关管理体系和管理流程。

（3）管理过程涉及从登记、领用、使用到变更、评估、处置等环节，要贯穿资产从入口到出口的整个生命周期。

2、重点突出。

（1）管理要以满足财政资产管理的需要为主，兼顾行政事业单位、主管部门资产管理的需要；以固定资产管理为主。

（2）突出行政事业资产管理和信息运用,构建行政事业单位资产管理网络平台，注重宏观管理和微观管理相结合、动态管理与静态管理相结合，构造出符合需求、科学、可行、合理的行政事业资产管理信息化系统，实现行政事业资产的安全完整和有效利用的目标。

3、安全有效。

在满足资产管理业务要求的前提下，要从逻辑、网络、数据、应用系统等多个方面建立先进、稳定、可靠的安全体系。保证系统的有效集成,实现各系统资源共享、信息交流。

要尽量兼容现有管理软件，保护已有投资，避免投资浪费。

4、有前瞻性。

要符合财政改革和资产管理改革发展的要求。界面清晰、美观大方、层次分明、功能完备、操作简便，并有灵活的数据映射机制，能满足用户个性化需求，能提供多维度、多视角的分析和透视功能。

1.3 项目范围

财政局下属347家行政事业单位。

2系统总体设计

2.1 系统架构设计

2.1.1系统逻辑结构设计

根据前面分析，我们认为，全国行政事业单位资产管理信息系统逻辑结构的总体框架图如下：

从上面的逻辑结构图可以看出，我们认为全国行政事业单位资产管理信息系统整体结构可以划分成五个层次：数据存储层、数据层、业务规则层、业务外观层和客户端。

2.1.1.1 数据存储层

数据存储层是行政事业资产动态数据库的存放，数据部署采用分布集中式，“分布”是指系统按照“分级财政”的业务处理规则，数据分布在各级财政，各级财政可以通过本级的系统完成自己职权范围的资产动态管理工作内容。“集中”是指各级财政的主管部门与行政事业单位在保留自己数据的同时，将所有数据集中到本级财政，实现本级财政相对的大集中。上、下级财政之间做到数据交换，使得上级财政能够了解下级财政资产管理的相关数据，必要时可以从全局的角度调整资产管理的重要控制数据。

根据行政事业单位资产业务管理要求，我们认为全国行政事业单位资产管理信息系统需要建设三大数据库：

各级财政资产数据库：包括本级主管部门汇总数据库、各行政事业单位重要资产明细数据，以及下级财政汇总数据。

主管部门资产数据库

各级行政事业单位资产数据库

2.1.1.2 数据存取层

数据访问执行从数据库获取数据或向数据库发送数据的功能。功能主要使用JDBC和数据库服务器存储过程来完成。

数据访问和持久性服务包括存储分布式应用程序的数据的物理数据库和该数据库中所包含的数据的接口。从“业务规则”层接收请求，通过“数据存取”层获取数据或存储数据。本系统将对数据存取进行封装和统一化处理，根据所访问的数据性质，将数据分成两类：元数据（参数）和具体数据：

元数据（参数）：是关于数据的数据，不涉及具体业务活动产生的数据，比如指标名称、指标代码、指标数据类型等信息就是元数据。

具体数据：是具体的业务数据，是由具体业务活动产生的数据，比如某年某月某个指标的预算编制数、预算调整数、预算执行数等。

在技术实现上，元数据（参数）访问和数据访问分别用元数据（参数）访问服务和数据访问服务统一实现，这种设计可减少编码量，简化系统的维护。

2.1.1.3 业务规则层（Rules层）

抽象出业务规则层是为了将相似的业务通用化处理，以尽量减少重复编码量，我们在体系结构设计上将“业务规则层”划分成两个子层次/模块：业务逻辑处理层和公共业务组件层。“业务逻辑处理层”面向具体的业务处理提供运算、审核、汇总、变换、格式化等功能，它为“业务外观层”提供服务，如数据录入表单生成、数据上报/确认、数据统计、查询等功能。

“公共业务组件层”是对具体业务的抽象，提供公共的、与具体业务无关的、可重用的组件，如业务组件、工作流引擎、公式引擎、报表制作引擎、查询引擎、指标数据存取引擎、统计图生成器等。

业务规则层是主要数据对象所在的位置，它从业务外观层接受请求，根据编码的业务规则处理请求，使用系统从“数据访问”层获取数据或将数据加载到“业务规则层”处理，将处理结果传递回“业务外观”层。

2.1.1.4 业务外观层（Facade层）

“业务外观层”是用户可感知的业务功能，如资产配置、资产使用、资产处置、资产收入等业务单据数据录入、审核、综合查询分析等业务功能。“业务外观层”用于向基础数据对象提供一致的接口，并将客户端与基础数据逻辑的更改隔离开。它存在于客户端与数据逻辑层之间。这些业务功能经过适当的归类、组合就形成了本系统中的各个业务子模块，包括资产清查、资产配置、资产处置、资产使用、资产收入管理、资产统计、综合分析、政策法规管理等。

业务外观层负责将客户端的用户界面接收的用户输入，以调用请求方式传递到“业务规则”层。将响应结果从“业务规则”层返回到客户端。同时对“业务规则层”的调用之间维护临时状态。

2.1.1.5 客户端

客户端又称用户服务层，是用户可感知和交互的界面，为了给用户提供一致的用户体验，主要包括显示数据、捕获数据、数据验证检查、为用户提供任务指南、向“业务外观层”发送用户输入、从“业务外观层”接收结果、向用户显示错误及执行语法检查。根据行政事业

资产管理信息系统所包含的业务子模块统的操作用户、操作方式、业务处理要求的不同，我们将五种客户端程序：

IE浏览器：在本项目中作为财政、主管部门的业务子系统都采用B/S结构，用户通过IE 浏览器就可以访问本系统，资产管理数据收集、资产监督管理、综合查询相关信息。

C/S/S客户端：单位软件采用“客户端/服务器（C/S/S）”对于单位版，考虑到为适应基层单位软件不同的网络和硬件资源情况、用户的操作使用习惯等因素，我们既提供B/S的浏览器资产管理功能，也提供单独的客户端程序，该客户端程序是一个完成单位自身资产管理业务,同样具备严谨的流程控制、完善数据采集逻辑，实现自动审核，完成数据层层上报。需要本地安装、本地运行，可以面向资产配置、资产使用、资产处置、资产收入管理等各类数据的采集，在网络连通的情况下将数据发送给服务器，如果网络未连通，则可以将采集的数据存储在本地文件中。

本系统提供的门户网站功能可实现信息发布和政策法规内容管理等功能，它可以将整个的资产预警信息、资产考核指标、重点关注资产监控信息、政策法规等信息资源分门别类有序组织起来，通过首页的发布区域（内容板块或栏目）展示出来。

2.1.2系统部署结构设计

我们本着“数据分布式部署、集中式管理”的原则要建立一个行政事业资产系统分布式的数据架构。

系统是采用集中式部署还是分布式部署需要考虑下面的三个因素：

用户数及其分布：如果系统的用户数很庞大，而且分布分散，宜采用分布式部署。集中式部署在负荷能力、系统的稳定性和可靠性、运行效率等方面有一定的局限性和影响。

日常处理的数据量：如果系统日常所要处理的数据量很大，宜采用分布式部署，集中式部署会由于网络通信的稳定性、带宽等因素压力很大。

地区性差异：对同一业务子系统来说，如果不同单位、不同层级的数据差别和业务个性化功能需求差别较大，宜采用分布式部署。如果采用集中式部署，系统设计/开发的难度、系统配置/权限管理的复杂度将变得异常庞大以至于难以实现。

主管部门

包含本部门的明细数据

行政事业单位资产管理系统数据“集中分布式”示意图

根据上面的数据分布及数据流向图，全国行政事业单位资产管理信息系统采用下面的部署图：

行政事业资产管理系统客

户端

对于本级财政相对大集中部署的业务子系统，我们将基于B/S结构开发，用户通过浏览器即可完成相关的业务处理和数据访问与分析。对于分布式部署的业务子系统，我们将基于C/S结构开发，开发专用的客户端程序，但对同一业务子系统的不同层级之间可实现数据

的互通和同步。

针对目前有部分行政事业单位还存在远程电话拨号进行联网，我们设计了智能离线客户端程序，满足本部门或本单位资产业务管理及数据同步。

系统主体采用B/S结构，各级用户通过浏览器录入统计数据或部分数据仓库数据，并通过浏览器完成查询、资产数据录入和分析等工作。但考虑到实际的网络设施状况，系统还提供了一个桌面客户端程序，该程序可单机运行，专用于动态资产数据的录入、审核和上传。在单机运行模式下，该客户端程序可将用户录入的数据暂存在本地，当网络连通时，该程序可将客户端暂存的数据按约定的格式发送给服务器。

桌面客户端程序需要本地安装，为减少用户安装、维护的工作量，我们将桌面客户端程序设计能自动安装、升级，每次桌面客户端程序启动后，如果网络连接正常，桌面客户端程序自动与服务器取得联系，比较当前桌面客户端程序的和服务器程序版本号，如果版本相符，则桌面客户端程序自动进入录入模式，如果版本不相符，则桌面客户端程序从服务器下载最新的程序包，桌面客户端程序将自动加载最新的程序包，这样就实现了桌面客户端程序的自动升级。

2.2 产品技术路线及灵活配置

2.2.1产品技术路线

本系统基于J2EE的多层架构和工作流、“浏览器/服务器（B/S/S）”结构及“客户端/服务器（C/S/S）”复合行政事业资产管理的应用模式，即财政、主管部门软件主要采用“浏览器/服务器（B/S/S）”，基层单位软件应可以选择使用“客户端/服务器（C/S/S）”。

它有以下特点

充分利用网络技术，构建高效、统一的行政事业资产数据采集平台、分析平台；

基于J2EE企业级应用开发框架，独立于操作系统和数据库平台，具有完全的可移植性采用XML技术，确保数据在财政部门、主管部门、行政事业单位的任何地方被一致理解；

基于开放的平台和开放的技术，如XML技术、Web Service技术，使系统很方便与金财工程其他系统整合和集成；

基于B/S技术的三层应用体系架构，允许任何合法用户，在任何时间、任何地方、以任何方法访问任何数据。可以对任何层进行单独的扩展和升级；

系统功能的参数化和元数据化，通过对不同类型业务的抽象，并以参数或元数据的形式描述具体的业务特征，使系统获得强大的定制能力，具有广泛的业务适应性，许多常规的功能需求都不需要重新开发，只需在现有功能的基础上进行特定的配置即可获得。

通过引入工作流引擎实现对业务的建模，比如登记、申报、审批等业务处理，而且业务处理流程和处理内容的变化不需要重新编程，只需通过工作流引擎的业务建模平台对业务进行重新建模即可

具有统一的统计指标体系，确保统计数据横向和纵向的一致性，并允许新的数据很方便引入；

具有非常灵活、细致的权限管理能力，可以对系统中任意粒度的资源（如数据、功能模块、查询模板、报表等）定制访问权限；

具有非常灵活的公式定义引擎，能够在横向（指标之间的逻辑）和纵向（时间轴上）表

达指标之间的任何关系，可以非常方便地定义导出指标，并利用公式审核数据的合法性和合理性；

具有非常灵活的报表制作引擎，可以生成任意格式的报表；

具有丰富的分析模型，其中包括时间序列分析技术、回归分析、专家系统和企业综合评价模型等，帮助用户对动态资产数据进行精加工和深度利用。

本系统还将提供多种形式的查询工具，比如组合条件式查询、灵活查询关键字查询、向导式查询等功能，这些查询工具都大量应用默认知识，减少用户设置工作量。

2.3 数据安全校验机制

2.3.1需求背景

由于行政事业资产管理信息系统是一个大型的网络应用系统，系统涵盖了全国的行政事业单位资产信息，同时各级财政、主管部门之间存在大量的数据交换，对数据安全的要求非常高，因此系统要求提供完善的数据安全校验机制，用户身份认证、分组权限控制、功能权限控制、数据权限控制、数据传输等权限控制和安全防护。但是从软件设计的角度出发，安全问题始终是所有应用系统最关注的核心问题之一。

从技术上分析，安全管理方案可划分成三个层面：网络层、系统层和应用层，网络层的安全涉及网络通信、网元设备的安全性；系统层的安全涉及操作系统和数据库的安全机制，网络层和系统层的安全部署方案通常在一个单位的IT基础设施规划中考虑，本方案暂不讨论。应用层的安全管理需根据具体业务需求来确定，重要包括用户身份认证、分组权限控制、功能权限控制、数据权限控制等安全管理需求。本方案只讨论应用层面的安全方案。

2.3.2设计策略

针对安全管理方面的需求，我们的设计策略如下：

设计统一的身份认证接口规范，通过信息门户子系统将各个业务子系统整合成一个统一的视图，实现系统登录的单一入口。

将本系统所有相对独立的功能模块抽象成功能资源，功能资源只有两个级别的访问控制：允许访问和禁止访问，如果用户或角色被禁止访问某个功能，该用户或该角色下所有用户将看不到该功能。数据资源控制用户/角色能够访问的数据范围和数据内容，根据行政事业资产管理的具体情况，我们将数据资源划分成五类：功能、数据、工作流、单位（即确定可访问的数据范围）、内容导航树节点、页面内容区域/子区域，对于数据资源对用户/角色提供能否读、写、完全控制或禁止访问四种操作级别。

敏感数据进行加密：采用严格的验证手段，可根据业务特点选择数字签名、CA认证、EDS信息加密、密码验证、软件安全硬加密。正对资产数据脱离安全控制或在公网传输，系统可进行相应限制。

2.4 系统权限管理

2.4.1需求背景

由于系统应用涉及财政部、各省财政厅系统众多角色及用户，如何保证有严密完善的权限体系是至关重要的。可通过权限的设置实现各级财政、主管部门的管理功能。系统权限实现多级管理员制度，根据业务工作需要，在确保系统安全的条件下权限逐级下发，由上级管理员赋予下级管理员具体管理权限。各级财政设系统管理员，对本级及下级财政所有权限内容可监控、追查，系统必须保留所有权限设置与变更的历史记录。

根据系统各个业务特点，对不同管理内容都有应不同应用权限，使得被赋予权限的用户能完成满足实际使用与管理的需要，做到权限可拆解、可合并、可继承，灵活定制，完全适应不同业务需要。应用权限的设置拆解、合并、继承的颗粒度应体现业务内控机制。

2.4.2设计策略

权限管理包括角色权限管理和用户权限管理两部分。之所以加入用户权限的设置，是因为仅仅依靠继承角色的权限，无法满足客户复杂的需求。直接对用户授予的权限优先于用户通过继承得到的权限。例如，如果用户A属于角色R，若A被授权对资源r具有读权限，而角色R被授权对资源r具有写权限，则用户A从R继承得到对资源r的写权限，但根据权限断然性，用户A最终对资源r具有读权限。这样通过对角色权限和用户权限的组合设置，就可以满足客户的需要了。

本系统将提供了功能、数据和单位、工作流四种形式的资源，对于功能资源，系统可控制能否执行该功能（即访问权限）；对于数据和单位两种资源，系统提供了读、写和完全控制三种操作级别的访问控制：

读：可以打开、浏览、甚至拷贝资源实体本身及其内容

写：能修改该资源实体的属性信息，或修改其包含内容、配置信息、关联关系等

完全控制：完全控制意味着用户除了具有“读”和“写”两种操作权限之外，可以删除数据实体本身，还可以把该资源的访问权限授予给其他用户。

另外系统还提供了一种特殊权限——“继承”权限，“继承”权限是根据资源所属的资源容器（资源组）的访问权限来继承。

3业务模块设计

建立资产管理信息系统，主要满足单位资产日常管理、主管部门、财政部门监管需求。业务模块涉及资产配置管理、使用管理、处置管理、收益管理、资产评估监督、资产清查、统计查询、预警分析等。

针对目前基层行政事业单位国有资产日常管理信息化基础薄弱的现状，系统需要实现资产条形码管理、资产盘点管理、资产台账管理、资产统计分析报表等管理。

对于财政部门、主管部门来讲，突出国有资产监管职能，在资产购置、资产处置等系统中应实现在线审核、审批，支持分级管理。满足财政、主管部门资产查询、统计、分析、监

控管理需要，提供灵活、方便、直观的统计分析功能。同时系统应满足大数据量的在财政主管部门与行政事业单位资产管理信息数据同步。

按照全国行政事业单位资产管理信息系统项目需求文档的要求，整个系统包括资产清查、资产配置、资产处置、资产使用、资产收入、资产统计报告、综合分析、政策法规、系统管理9个功能模块。

4系统安全设计

4.1 概述

通过广域网或大型局域网进行关键信息交互的用户所面临的安全问题有：

身份认证与授权在用户提交、审核、管理、报备等业务处理过程中，如何对双方进行认证，以保证交易双方身份的正确性；

保密性如何保证系统中涉及的大量需保密的信息通过网络传输过程中不被窃取；

完整性如何保证系统在业务处理中所传输的信息不被中途篡改及通过重复发送进行虚假交易；

抗抵赖在信息、材料等业务数据交互完成后，如何保证交易的任何一方无法否认已发生的交易

从技术上分析，安全部署方案可划分成三个层面：网络层、系统层和应用层，网络层的安全涉及网络通信、网元设备的安全性；系统层的安全涉及操作系统和数据库的安全机制，这部分内容已经是信息系统的标准，将结合在应用层的安全体系设计中，这里不单独列出。

对于应用层的安全性，充分结合了通信安全性和数据库安全特性，它包括三部分：身份认证、通信加密、用户权限管理。

身份认证是用户标识自己以获取对系统的访问权。一般包括三种方式：用户名/密码、证书、证书＋用户名/密码。出于成本和实用上的考虑，久其CI平台的实施方案暂时只支持用户名/密码方式。

通信加密是建立在SSL技术的基础上，保证数据在传输过程中不被篡改和非法读取。在网络传输的过程中，数据的交互以及文件、信息等数据的上传下载都将采用SSL技术来保证其不被识别、不被仿造。

本系统权限管理包括对系统所有资源的管理，包括功能、单位、数据表单、查询模板等资源的管理。

4.2 网络安全

我们建议针对本系统平台购置一台防火墙和局域网交换机，通过局域网交换机将本系统的各服务器连接成一个专用局域网络，通过防火墙进行服务网、办公网及互联网的访问控制和隔离。主要安全策略如下：

通过防火墙构建专用网络，使系统与财政部办公网、Internet隔离，所有来自外部的访问都必须先通过防火墙的检查

通过NAT隐藏内部网络上服务器的真实IP地址

通过Access List控制外部网络可以访问的内部服务器

通过Access List控制外部网络可以访问的内部服务器的服务端口

通过Access List控制外部网络哪些地址段可以访问内部哪台服务器及其端口

4.3 身份认证

认证意味着用户标识自己以获取对系统的访问权。用户可以在进入系统时立即标识自己，或在用户未标识自已的身份而尝试访问受保护的资源时由系统提问。标识／密码组合是最常见的对系统标识用户的方法。一旦认证了用户，系统就可以确定是否授权该用户访问请求的资源。

本系统B/S结构的功能模块的身份认证是建立在JAAS（Java认证与授权服务）技术的基础上，JAAS是一套安全体系规范，该规范将目前所有的身份认证技术都纳入到一个统一的体系中，如用户名/口令认证、CA认证、智能卡认证等，使得开发人员可以以一致方式开发应用而不用考虑不同认证方式的差别，最后附加相应的认证模块即可。系统支持3种认证方式：

用户名/密码

证书

证书＋用户名/密码

对于普通客户，门户通过用户名／密码对进行身份认证。对于安全性要求高的应用，可以采用证书认证方式。就实现的成本和对安全的需求而言，我们建议采用用户名／密码对进行身份认证。

4.4 传输安全方案

SSL（Secure Sockets Layer，安全套接层）是由Netscape公司开发的网络安全传输协议，是目前INTERNET上点到点之间尤其是Web浏览器与服务器之间进行安全数据通讯所采用的最主要的协议。由于SSL具有应用面广、实施成本低、安全高效、操作简单等优点，它已成为电子商务系统中应用得最广泛的协议，例如目前美国的大多数电子商务应用系统都是基于SSL协议的，其数据加密级别高于128Bit，机密强度特别高。

SSL安全代理的基本工作原理是：SSL安全代理软件与Web浏览器会自动结合，当浏览器要与远端Web服务器建立安全连接时，它向安全代理发出请求，由安全代理负责与远端Web服务器建立连接。连接建立后，浏览器与服务器之间的数据传输是经过安全代理转发完成的。这样就使得用户端与服务器端之间的数据传输则是用高强度的数据加密算法加密的。

本系统应用的Java应用中间件（包括BEA WebLogic、IBM Websphere）均自动支持SSL 技术。

4.5 应用级权限管理

权限管理包括对系统所有资源的管理，包括系统功能、组织机构单位、数据账套、基础数据、业务单据、报表等资源的管理。

权限设置分四种状态：授权、拒绝、允许、继承

4.5.1用户管理

用户管理包括两级管理，角色和用户。

用户管理是权限管理的基础，需要对用户进行分组管理，涉及到角色和用户两种对象，角色作为容器来容纳用户，用户可以属于多个角色，但角色之间不再具有从属关系。另外，系统内置了管理员角色和系统管理员，后者属于前者。用户新建的组和用户均属于普通角色和普通用户。

新建组：

(1)新增一个普通用户组；

(2) 修改组：修改普通用户组的属性信息；

(3) 删除组：删除一个普通用户组；

(4) 新建用户：新增一个普通用户；

(5) 修改用户：修改普通用户的属性信息；

(6) 删除用户：删除一个普通用户；

(7) 修改密码：修改包括系统管理员在内的用户的密码；

(8) 维护用户组和用户之间的隶属关系：包括把用户加入到某一个组，把用户从某一个组中移出。

4.5.2功能权限

功能权限管理实现对不同用户进行不同职能的划分，划分的功能模块包括参数的定义、数据表单的定义、数据填报、数据审核、数据上报/存储、数据导入/导出、分析表制作、综合统计分析和系统维护等功能。

功能权限管理是分配不同级别用户使用不同的功能及模块，功能权限包括两种操作级别：允许和不允许。如果用户对功能没有访问权限，他/她在系统的操作界面将看不到该功能项，当然也不可能调出该功能的操作界面。

4.5.3单位权限

按单位对数据访问授权可以实现划分不同层次级别数据的访问界限，划分不同级别用户访问不同数据的级次，上级单位能够访问下级单位的所有上报数据，也可以指定是否可以读、写等指标级别操作，下级单位可以通过管理员设定权限访问上级单位的数据，或者更上一级单位的数据，以及相关分析数据。

4.5.4数据权限

数据权限功能可以按系统基础数据（部门、人员、资产分类等）、报表/报表分组、指标/指标组、表单、查询模板等对用户授权。得到授权的可以访问某一范围内的数据。例如，如果系统对用户张三授权可以访问资产负债表相关指标，而没有分配其它指标的访问权限，则张三只能访问资产负债表的数据，而不能访问其它数据。

4.5.5单据权限

用户可根据人员岗位从事业务不同进行针对某种业务的对应单据的显示、编辑授权允许、拒绝权限控制，并可细化到单据数据项，如资产配置申请单、资产处置申请单等可以进行权限控制。

4.6 日志管理

系统设计了严密完善日志管理功能，系统管理员可以时时监控系统运行情况，操作人员日志管理中主要记录每次操作的用户名称；被操作的计算机名称；操作内容（比如：保存单据还是增加单据等）；操作的开始时间；结束时间，备注。

5系统软硬件方案建议

5.1 系统部署方案建议

5.1.1分布式部署

1)财政、主管部门、行政事业单位分别部署数据库,数据库间定期同步。

2)单位传输数据的时候同时传输数据到主管部门和财政部门，财政部门和主管部门分

别登录自己的数据库进行审批等业务操作。

3)如果主管部门审批之后的数据需要传输到财政部门由财政部门进行审批或备案，

那么数据会传输到财政部门，由财政部门登录自己的数据库进行审批或备案。

4)主管部门和财政部门审批的结果需要传回到单位数据库，单位进依据审批结果

进行调整或后续业务。

优点：对财政部门、主管部门数据压力小，应用效率高。

缺点：系统软硬件投资大，管理分散；

数据冗余比较大，保证数据的一致性比较困难；

适用范围：对于分布式部署适用于中央部门本级。

根据我们试点结果统计，大多数中央部门都采用这种部署模式。

5.1.2财政部门主管部门集中部署

1)财政和行政事业单位部署数据库，主管部门不部署数据库。财政和行政事业单位部

署数据库定期同步。

2) 主管部门通过网络登录到财政应用服务器，在线进行查询分析/资产管理业务/申报审批

业务事项处理。财政集中管理主管部门用户权限。

3)财政部门在线处理进行查询分析/资产管理业务/申报审批业务事项处理。

优点：在财政部门和主管单位没有数据冗余，数据能有保持一致性；数据能实时反应。软硬件投资相对较少，行政事业单位部署数据库有效减轻对财政及主管部门数据库的压力。

缺点：行政事业单位与主管部门、财政部门之间的数据时效性差；

适用范围：根据试点结果统计，地方财政部门全部采用此种部署模式

5.2 数据库服务器推荐配置

5.3 应用服务器推荐配置

5.4 单位版推荐配置

5.5 其他

在配置硬件设备时，用户良好的机房环境也是保证系统持续运行的重要条件。在选择完硬件后，用户需要及时和硬件供应商沟通，提前准备相关环境，以便顺利实施。

以P550Q和X3650服务器为例，硬件供应商所要求的准备工作：