金税三期架构需求--网络发票管理系统

《金税三期架构需求—网络发票管理系统》

V1.0

金税三期工程架构管控项目组

2011年4月

修订记录

目录

第1章 金税三期总体概述 .......................................................................................................... 6 1.1. 1.2. 1.3.

总体战略目标 ......................................................................................................................... 6 总体技术目标 ......................................................................................................................... 7 总体架构要求 ......................................................................................................................... 8

第2章 总体范围说明 ................................................................................................................. 9 第3章 业务功能要求 ............................................................................................................... 10 第4章 应用系统设计要求 ........................................................................................................ 11 第5章 与周边系统交互关系 .................................................................................................... 13 第6章 系统关键技术要求 ........................................................................................................ 15 6.1. 6.2. 6.3.

运营商端网络发票开具软件 ................................................................................................ 15 运营商端网络发票业务前置 ................................................................................................ 16 税务局端数据发送前置 ....................................................................................................... 17

第7章 数据设计约束 ............................................................................................................... 19 7.1. 7.2.

规划策略 ............................................................................................................................... 19 数据分布及流向 ................................................................................................................... 19

征管系统全国集中模式 ............................................................................................... 19 7.2.2. 征管系统省级集中模式 ............................................................................................... 20 7.3. 网络发票数据分类 ............................................................................................................... 21 7.3.1. 运营商端 ....................................................................................................................... 21 7.3.2. 税务局端 ....................................................................................................................... 22 7.4. 主数据 ................................................................................................................................... 23 7.5. 数据质量 ............................................................................................................................... 23 7.2.1.

第8章 非功能性约束 ............................................................................................................... 25 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9.

范围 ....................................................................................................................................... 25 系统性能 ............................................................................................................................... 25 可靠性 ................................................................................................................................... 26 可用性 ................................................................................................................................... 26 易用性 ................................................................................................................................... 26 可维护性 ............................................................................................................................... 27 可扩展性 ............................................................................................................................... 28 可伸缩性 ............................................................................................................................... 28 可移植性 ............................................................................................................................... 28

第9章 安全性约束 ................................................................................................................... 29 9.1. 安全等级要求 ....................................................................................................................... 29 9.2. 策略和措施 ........................................................................................................................... 29 9.3. 应用层安全 ........................................................................................................................... 31 9.3.1.

应用系统安全设计要求 ............................................................................................... 31

应用开发安全要求 ....................................................................................................... 31

9.3.3. 身份认证系统 ............................................................................................................... 32 9.3.4. Web安全防护 ................................................................................................................ 32 9.4. 数据层安全 ........................................................................................................................... 32 9.5. 终端安全策略 ....................................................................................................................... 33 9.6. 系统层安全 ........................................................................................................................... 33 9.7. 网络层安全 ........................................................................................................................... 34 9.7.1. 网络结构安全 ............................................................................................................... 34 9.7.2. 划分子安全域 ............................................................................................................... 34 9.7.3. 网络访问控制 ............................................................................................................... 35 9.7.4. 恶意代码防范 ............................................................................................................... 35 9.7.5. 网络安全审计 ............................................................................................................... 35 9.7.6. 边界完整性检查 ........................................................................................................... 35 9.7.7. 入侵防范 ....................................................................................................................... 36 9.7.8. 网络设备安全防范 ....................................................................................................... 36 9.8. 系统层安全 ........................................................................................................................... 36 9.9. 物理层安全 ........................................................................................................................... 37 9.3.2. 第10章

部署约束 ..................................................................................... 错误！未定义书签。

10.1. 生产中心部署 ....................................................................................... 错误！未定义书签。 10.2. 灾备中心部署 ....................................................................................................................... 38 第11章 第12章

架构管控约束 ........................................................................................................... 38 技术开发规范约束 .................................................................................................... 42

12.1. 总体概述 ............................................................................................................................... 42 12.1.1. 目的 ............................................................................................................................... 42 12.1.2. 范围 ............................................................................................................................... 42 12.1.3. 标准规范概述 ............................................................................................................... 42 12.2. 业务流程标准 ....................................................................................... 错误！未定义书签。 12.2.1. 业务需求 ....................................................................................... 错误！未定义书签。 12.3. 业务数据标准 ....................................................................................... 错误！未定义书签。 12.3.1. 税务数据元目录标准 ................................................................... 错误！未定义书签。 12.3.2. 税务业务代码标准 ....................................................................... 错误！未定义书签。 12.4. 模型设计标准 ....................................................................................... 错误！未定义书签。 12.4.1. 关系型数据模型设计标准 ........................................................... 错误！未定义书签。 12.4.2. 关系型数据模型标准 ................................................................... 错误！未定义书签。 12.5. 集成标准 ............................................................................................... 错误！未定义书签。 12.5.1. 应用服务集成标准 ....................................................................... 错误！未定义书签。 12.5.2. 数据交换技术协议标准 ............................................................... 错误！未定义书签。 12.5.3. 税务行业数据报文设计标准 ....................................................... 错误！未定义书签。 12.6. 关键技术标准 ....................................................................................... 错误！未定义书签。 12.6.1. 总体技术路线 ............................................................................... 错误！未定义书签。 12.6.2. 二维条码应用技术标准 ............................................................... 错误！未定义书签。 12.7. 安全标准 ............................................................................................... 错误！未定义书签。

第1章 金税三期总体概述

1.1. 总体战略目标

金税三期工程的业务战略目标是：  统一税收执法；  统一纳税服务；  统一管理决策；

 统一征管数据实时监控。

首先，统一税收执法是在国家税法统一的前提下，以总局统一的政策管理为依托，包括国、地税税收执法尺度的统一，为纳税人提供公平、公正的税收环境。在现阶段，公平、公正是对纳税人最好的服务。同时，统一税收执法，也是现阶段实现应收尽收，保证税款及时入库的有效保证。

其次，统一纳税服务，不是简单的建立一个平台，而是保证服务目标、服务内容、服务水平的一致，避免不同地区、不同税务人员对同类事项执法不一、口径各异和服务差异。

第三，统一管理决策，是采用科学的方法，利用数据集中和信息共享手段，为各级领导提供一致的管理和决策依据。

第四，建立在全国大集中基础上的统一实时的征管数据监控，是促进统一执法、统一服务、统一管理决策的手段保障。

在国内外新的经济形势下，为了实现四个统一的战略目标,总局确定了信息管税的总体战略，信息管税就是以税收风险管理理念为指导，以现代信息技术为依托，以对涉税信息的采集、应用为主线，优化资源配置，完善税源管理体系，加强业务与技术的高度融合，着力解决征纳双方信息不对称问题，不断提高税法遵从度和税收征收率。

其中，信息管税是一项系统工程,必然要涉及到税务管理的思想观念、制度机制、业务流程、组织机构等一系列变化。

如下图所示：

这里的“全国大集中”，涵盖核心业务系统全国集中部署和应用，统一业务需求管理、统一应用开发和运行维护管理。

1.2. 总体技术目标

金税三期工程建设的主要内容是：计划用四年时间，在现有资源基础上，通过制度、业务和技术创新，完成“一个平台、两级处理、三个覆盖、四个系统”的建设，进一步强化纳税服务和税务管理，提高税法遵从度和税收征收率，降低税收成本，为税收法律法规的统一执行提供有力保障。上述目标可具体概括为“一门户、三网、四平台、七库”，具体描述如下：

1、“一门户”是通过实施全国数据大集中，优化业务流程和功能配置，统一国地税征管系统，为全国各级税务人员提供统一的内部门户和工作平台，实现全国税收业务的统一、规范管理。

2、“三网”是建成税收征管业务网络、行政办公网络、涉密网络，这三个网络全国国、地税统一建设，具备强大的信息采集、存储、处理、交换等功能，安全可靠程度高，确保各项税收业务与管理在统一、安全、稳定的网络化信息平台支撑下平稳运行。

3、“四平台”是指建设全国统一的纳税服务平台、征管和行管业务操作平台、管理决

策平台，这四大平台能使广大纳税人方便、快捷地办理各项税费事宜，广大基层税务人员高效、简洁地处理各项业务，使各级税务管理者及时有效地实施管理与决策。

4、“七库”是指在总局、省局两级建立并逐步完善法人涉税数据库、自然人涉税数据库、发票数据库、第三方信息数据库、税收风险管理数据库、税务机构数据库（包括财务、固定资产等）和人力资源数据库、税收法规数据库（包括文件、档案等）这七个数据库，并进行数据的集中存储和处理，同时建立第三方信息共享机制，实时、完整、准确地掌握纳税人涉税费信息和税务机构、人员等情况，以利于提高税收服务与管理水平。

1.3. 总体架构要求

总体架构既包含业务、应用、数据、技术、安全、运维等方面的框架，也包括架构管控的体系。一方面，作为框架，总体架构定义了业务、应用、数据、技术、安全、运维等架构的目标蓝图，还包括相关模型，及各部分 的指南、设计准则，项目需要根据总体架构的约束来实现其应用；另一方面，作为架构管控，它指明了项目在进行项目实施的时候需要遵守的标准、规范，可以参考的相关架构资源以及需要遵守的架构管控流程，以确保项目的实施符合金税三期的总体规划。

总体架构主要由业务架构、应用架构、数据架构、技术架构（包括系统软件、基础设施等）、安全架构、运维架构、标准、架构管控体系等组成，这些总体架构的内容将构成对项目架构方面的约束，项目需要在这些架构的约束下进行业务需求分析、设计以及实现以完成项目的目标。

第2章 总体范围说明

网络发票系统由税务局端和运营商端两部分构成。税务局端包括网络发票数据交换前置、发票查验前置和网络发票数据库，采用总局/省局两级部署模式；运营商端包括网络发票开具软件和网络发票业务前置。

下图给出了网络发票开具软件的总体构成以及在整体金税三期应用环境的位置，见图中橙色部分。

如上图所示本项目负责负责完成网络发票开具软件、网络发票业务前置和局端数据发送前置的设计与开发。

网络发票开具软件、网络发票业务前置的部署层级根据各运营商自身情况来确定，数据发送前置需要在税务局端进行总局/省局两级部署。

第3章 业务功能要求

网络发票管理系统总体业务功能如下图所示：

运营商统一开发的全国网络发票开具软件须经税务机关审核批准后方可使用，且要严格按照此标准开发和应用，在此基础上可扩展、应用其他辅助功能。按照发票管理有关规定使用发票，确保发票数据、内容的真实性。

1、 网络发票开具软件。

业务规范具体包括：发票填开、发票补打、发票作废、开票查询预警、发票存根联补录、查询与统计、空白发票异常作废、空白发票异常报告、系统维护等业务功能。详细的业务需求请参见网络发票业务需求文档。

2、 网络发票业务前置。

需要实现与税务局端网络发票管理系统的连接，负责发送发票开具信息和发票预警信息，将其推送至税务局端的数据接收前置。

3、 数据发送前置。

部署到税务局端，主要负责获取税务局端的发票发售信息以及纳税人基本信息变更内容，将其返回给网络发票开具软件。

第4章 应用系统设计要求

下图给出网络发票系统的总体应用分布，整体的策略如下:

1、整个网络发票系统由运营商端的网络发票开具软件、网络发票业务前置以及税务局端的网络发票管理系统共同构成。

2、运营商端包括网络发票开具软件和网络发票业务前置两部分，网络发票开具软件负责实现全部的纳税人端发票开具相关业务，网络发票业务前置服务实现发票的查询统计、发票监控管理信息提供服务以及与局端数据交换前置的数据交换功能。

3、税务局端网络发票管理系统总局部分由发票查验前置、数据发送前置和网络发票数据库构成，省局部分由发票查验前置、数据发送前置、数据接收前置和网络发票数据库构成。发票查验前置(总局/省局)负责为企业纳税人及社会公众提供完整的发票查验功能。数据发送前置负责为运营商端提供发票发售信息以及纳税人基本信息。数据接收前置负责接收运营商端提供的发票开具信息以及发票监控信息。

基于上述的应用分布下面给出具体的设计思路说明。

1、由各运营负责完成发票的开具相关业务、发票的查询统计业务以及发票的预警信息提供业务，发票开具数据第一次落地在运营商端并在业务规定时间内经由税局端数据接收

前置同步到税局端网络发票数据库（省局）。

2、运营商端可以保留能够支持发票查询统计业务以及发票预警信息业务的各类发票相关数据。

3、所有的发票查验统一由总局纳税服务平台来负责提供入口（省局纳税服务平台可以提供链接跳转到总局查验页面），总局发票查验前置负责受理全部的查验请求，然后根据发票信息将具体的查验请求转发到相关省局的发票查验前置进行具体的查验处理。

4、各运营商的开具数据落地后需要在业务规定时间内经由局端数据接收前置同步到网络发票数据库（省局），保证省局发票数据库数据的完整性和时效性。

5、由核心征管系统产生的的发票发售信息以及纳税人基本信息的变更内容，都将统一由税务局端的数据发送前置（总局/省局）负责提供给运营商，由运营商端的网络发票业务前置根据相关标准协议主动获取，整体的数据传输时间必须满足业务的时效要求。这样确保运营商系统在开票时不需要主动访问局端系统，降低局端系统故障对于前端开票业务的影响程度。

6、省局网络发票数据库数据的完整性和时效性完全能够满足发票管理职能，针对网络发票的各类监管、审核、比对、预警等管理类业务，建议由运营商端负责将各类预警监管信息通过税局端数据交换前置同步到省局网络发票数据库中，具体的管理类业务全部由管理决策平台来负责实现。

7、同时税局端数据接收前置负责实现网络发票总局数据库与网络发票省局数据库之间的清分和汇总功能。

8、必须实现运营商端与税务局端前置之间的流水管理和对账机制，最大程度降低故障的发生概率以及相应的应急措施。

第5章 与周边系统交互关系

针对系统划分，下图给出网络发票各系统内部以及同外部相关系统的业务交互约束，明确定义出业务交互的对象、内容以及交互技术机制等。

面URL

第6章 系统关键技术要求

基于前面的应用和数据需求，下面给出系统的关键性技术要求。

6.1. 运营商端网络发票开具软件

根据总体架构规划的内容以及功能要求, 下表给出了运营商端网络发票开具软件在具体实现中一些关键性的技术约束。

6.2. 运营商端网络发票业务前置

根据总体架构规划的内容以及功能要求, 下表给出了税务局端网络发票业务前置在具体实现中一些关键性的技术约束。

6.3. 税务局端数据发送前置

根据总体架构规划的内容以及功能要求, 下表给出了税局局端数据交换前置在具体实现中一些关键性的技术约束。

第7章 数据设计约束

7.1. 规划策略

在金税三期的大集中战略指导下，网络发票管理系统的数据库规划应遵循以下策略：  数据分级存储

网络发票开具信息等数据采用运营商、省局和总局三级存储方式。

纳税人网络发票开具明细信息首先落地在网络发票数据库（运营商端），运营商端负责缓存（缓存期限由业务需求决定）服务范围内的纳税人开具的网络发票明细信息，并向税务局端网络发票数据库（省局）同步；网络发票数据库（省局）负责存储本省开具的网络发票的明细信息，并向网络发票数据库（总局）同步；网络发票数据库（总局）集中存储全国网络发票开具明细信息，并向省局进行清分。

 数据实时性保障

运营商、省局、省局之间的数据同步频率以业务时效性要求为依据，保证传输效率、数据存储可靠，支持大批量发票的及时开具和海量数据存储。

 数据安全保障

网络发票管理系统涉及到纳税人信息、网络发票开具明细信息等关键敏感数据，这些又数据分布在运营商、省局和省局，因此设计时必须考虑数据传输和存储的安全性。

7.2. 数据分布及流向

7.2.1. 征管系统全国集中模式

核心征管系统全国集中省份的网络发票数据分布及流向如下图所示：

下面对核心征管系统全国集中省份的省局、总局、运营商之间的数据分布及数据流向进行说明：

一、 总局与运营商数据分布及流向

核心征管系统通过网络发票数据发送前置（总局/省局）将纳税人基本信息及发票发售信息等数据在业务规定时间内推送至运营商端网络发票数据交换前置。

二、 省局与运营商数据分布及流向

运营商端通过网络发票业务前置将网络发票开具信息及发票监控信息等数据在业务规定时间内推送至税务局端网络发票数据接收前置（省局），由网络发票数据接收前置（省局）将上述信息同步至网络发票数据库（省局）。

三、 总局与省局数据分布及流向

网络发票数据库（省局）将本省网络发票开具信息等数据在业务规定时间内同步至网络发票数据库（总局），总局将跨省受票发票信息清分至受票方税务局网络发票数据库（省局）。

核心征管系统将纳税人基本信息及发票发售信息等数据推送至网络发票数据库（总局），同时通过层级交换平台将纳税人基本信息等数据推送至网络发票数据库（省局）。

7.2.2. 征管系统省级集中模式

当前，针对税收征管系统仍然采用省级集中的省份，网络发票数据分布及流向如下图所示：

说明：核心征管系统未实现全国集中省份，采用该模式

下面对征管系统省级集中省份的省局、总局、运营商之间的数据分布及数据流向进行说明：

一、 省局与运营商数据分布及流向

征管系统通过网络发票数据发送前置（省局）将纳税人基本信息及发票发售信息等数据在业务规定时间内推送至运营商端网络发票业务前置；征管系统同时负责将纳税人基本信息及发票发售信息等数据推送至网络发票数据库（省局）。

运营商端网络发票业务前置将网络发票开具信息及网络发票监控信息在业务规定时间内推送至税务局端网络发票数据接收前置（省局），由网络发票数据接收前置（省局）同步至网络发票数据库（省局）。

二、 总局与省局数据分布及流向

网络发票数据库（省局）将本省网络发票开具信息等数据同步（同步频率应满足业务时效性要求）至网络发票数据库（总局），总局将跨省受票发票信息清分至受票方省局的网络发票数据库。

7.3. 网络发票数据分类

7.3.1. 运营商端

7.3.2. 税务局端

7.4. 主数据

金税工程（三期）建立税务主数据的目的，是用来描述国、地税业务实体的数据，如纳税人基本信息、纳税人状态信息、代码信息，以及个人税收管理的自然人基本信息，状态信息，代码信息等。它们是具有高业务价值、可以跨国、地税各个业务部门被重复使用的数据，并且存在于多个异构应用系统中。

金税工程（三期）的面向纳税人的主数据应包含三类信息：

 纳税人基本信息：纳税人识别号、纳税人名称、登记注册类型等；

 纳税人基础状态信息：纳税人登记状态、纳税人信用等级、增值税一般纳税人、

防伪税控纳税人和出口退税纳税人等资格、稽查案件未结、违法违章未处理和逾期未申报等状态；  代码信息。

金税工程（三期）的面向自然人主数据应包含三类信息：

 自然人基本信息：自然人识别号、自然人名称、登记类型等；

 自然人基础状态信息：自然人登记状态、自然人信用等级、违法违章未处理和逾

期未申报等状态；  代码信息。

7.5. 数据质量

数据质量管理应遵循“事前预防、事中监控、事后补救”的设计思路：  事前预防，指在数据录入时提供在线帮助，提示数据的录入规范；

 事中监控，指在数据录入端引入对数据项的校验功能，包括数据格式校验、逻辑

关系校验等，对录入错误及时发现并提示修改，有效避免错误数据的进入；  事后补救，指数据录入后，基于标准进行数据质量的审计，对错误数据提供更正

界面，以避免后台数据库调整；同时，制定规范的数据更正流程，确保数据修改的高效执行和安全管理。

网络发票项目应提出有效保证数据一致性的机制。

 从管理角度而言， 项目组应配合总局从整体上完善数据质量的管理组织和流程制

度；

 从技术手段而言，网络发票项目应提供主数据的同步机制，确保主数据在总局、

省局和运营商各系统间的一致性；提供数据完整性的业务实现机制，如冲正交易等。

第8章 非功能性约束

8.1. 范围

非功能需求规定了系统必须满足的服务水平、系统非运行时间的属性以及系统必须遵守的约束。非功能需求适用于整个系统、系统的几个部分或特定的用例。

非功能需求虽然不直接影响系统功能，但在用户和系统支持人员对该业务系统的认可方面具有很大的影响。

非功能需求包含许多方面。主要的非功能需求包括以下几方面：

 系统性能  可靠性  可用性  易用性  可维护性  可扩展性  可伸缩性  可移植性

8.2. 系统性能

响应时间是指从客户端发出请求到获得服务器响应的时间。请求响应时间一般为“网络响应时间”和“应用程序与系统响应时间”之和。

网络发票管理系统典型业务的响应时间要求如下：

网络发票在线应用系统应保证各类业务的响应时间不大于5秒。特别是网络发票开具响应时间如果大于5秒，则用户等待时间过长，难以接受，也会增加开票高峰期的系统压力。

8.3. 可靠性

1、 应保证在正常情况下和极端情况下业务逻辑的正确性。 2、 最大宕机时间

 运营商端：最大宕机时间1小时。  网络发票管理系统：最大宕机时间1小时。

3、 系统备份

提供备份系统，防止单点故障 4、 灾难恢复备份

遵循金税三期工程容灾设计方案。

8.4. 可用性

业务系统应满足7×24小时可以使用。

8.5. 易用性

1、 易理解

a) 系统所有的业务功能界面风格和操作流程一致； b) 业务表单尽量做到所见即所得；

c) 界面美观、简洁、高效；界面各部件的布局应该保持合理性和一致性； d) 界面风格一致，颜色调和、提示清晰、窗口大小适当，使用方便; e) 在选择快捷键、缩写、暗示和图标时应符合税务行业为习惯。

2、 易操作

a) 常用操作有快捷键支持，大部分操作能够在小键盘内完成； b) 信息录入能够完全通过键盘完成； c) 无论逻辑步骤还是操作步骤都应避免繁杂。

3、 易学习

a) 提供在线帮助，系统关键业务操作应提供在线帮助文档和提示信息，使操作

人员能够快速直观的利用这些信息进行相应的业务操作，并对各种状态和操作结果进行及时的反馈和提示。

b) 提供符合税务行业习惯，详细、易读、易理解的操作使用手册。

4、 需遵循“金税三期”工程的界面集成标准规范；

8.6. 可维护性

1、 可配置

a) 人员机构的可维护

系统应具备人员/机构等基础信息的维护功能，系统应该能够快速的对人员/机构信息进行维护和调整操作。 b) 岗位权限的可维护性

系统应具备岗位权限的维护功能，系统应该能够快速的对岗位权限进行权限赋予和回收等维护操作。 c) 业务流程的可维护性

系统主要业务流程应具备维护功能，可根据业务规则的变化快速的对业务流程进行调整维护操作。 d) 服务接口的可维护性

系统主要业务功能应提供标准的服务交换接口，可通过开关配置快速的提供对外服务能力。

e) 参数指标的可维护性

系统应具备规范、完善的参数指标的管理功能，具备针对系统运行基础性能参数进行配置和维护的功能。 2、 可监控

a) 提供日志审计功能

系统每个组件应具备规范、完善的的日志管理功能，具备多级日志搜集开关、有效/失效开关、性能指标搜集开关以及开配置参数表。 b) 业务流水机制

为保证关键业务一致性，建议考虑采用流水机制。 c) 标准监控协议支持

符合业界主流监控软件的接口规范，能够将监控数据方便的接入到监控软件中，便于集中监控和管理；

3、 可读、易修改

要求在系统的建设过程中要有规范、清晰、完整和详细的文档，如业务需求阶段要有业务用例模型、业务活动图、业务规则、表证单书等；系统需求分析阶段要求有系统用例模型、用例文档、规则说明等；概要设计阶段要求有宏观设计文档；详细设计阶段要求有类图、时序图等；编码阶段要求有程序设计说明、变量定义说明等；测试阶段要有测试用例、测试记录等。 4、 易于升级

要求数据库、应用服务器、开发工具能方便地进行版本升级，具有向下兼容性；易于升级也要求客户端的升级工作量较小，建议采用浏览器客户端而不是GUI客户端。

8.7. 可扩展性

在设计上必须具有适应业务变化的能力，当系统新增业务功能或现有业务功能改变时（界面的改变、业务实体变化、业务流程变化、规则的改变、代码改变等），应尽可能的保证业务变化造成的影响局部化。

系统应提供一个弹性的架构，支持使用配置而免编程的方式对业务流程、业务表单、查询统计等功能的定制与调整。

8.8. 可伸缩性

当系统容量发生变化时，应能通过各个层次的扩充，保证系统合理的响应时间和吞吐量，支持负载的划分与均衡。

8.9. 可移植性

应用系统硬件平台无关性，支持主流的硬件平台和操作系统。

第9章 安全性约束

基于链路层安全（如：VPDN）和应用层安全（如：SSL）策略实现系统平台安全、信息传输线路安全以及应用系统安全。采取的策略如下：

1) 已有安全上网线路的企业：可以通过已有的安全线路接入功能直接接入局端平台。 2) 已有其他上网线路的企业：可以通过升级方式实现具有安全线路接入功能。企业

凭税务登记证申请升级电信安全线路接入功能的资费将给予大幅度优惠，收取一定的安全线路接入资费后，给予相应的资费返还，原则上做到升级零成本。 3) 没有上网线路企业：未租用线路的企业在租用线路时自带安全线路接入功能，不

需要额外支付费用。企业也可以不租用上网线路，通过电话、短信等通讯方式接入。

4) 可以使用总局的Key身份验证，Key介质由各地自行选择。

9.1. 安全等级要求

网络发票管理系统安全等级建议定为二级，最终级别以总局的定级结果为准，系统在设计上和部署上要不低于二级等级保护的标准。

9.2. 策略和措施

针对网络发票应用系统采用的安全技术策略和对应的技术措施如下所示：

9.3. 应用层安全

9.3.1. 应用系统安全设计要求

应该单独编写安全性设计说明概要。

应用系统架构设计时要进行安全可行性分析并通过评审。

应用系统安全性设计至少要包括以下内容：

 认证与授权服务：

必须有单独的登录控制模块对登录用户进行身份标识和鉴别；需要支持多种的身份认证方式，如CA证书方式，用户名密码方式和其它多因子认证方式。

 程序资源访问控制安全 ：

 根据用户的身份和对系统的使用情况将用户分成不同的用户组；

 为不同的用户或用户组分配不同的系统资源（如对象、数据等）访问权限；

 用户只能访问到自己有权限访问的系统资源（如对象、数据等）。

 功能性安全：

明确各个功能的流程上的安全措施， 如是否需要审核，文件上传最大限制等。

 数据域安全

数据域安全包括两个层次，其一是行级数据域安全，即用户可以访问哪些业务记录，一般以用户所在单位为条件进行过滤；其二是字段级数据域安全，即用户可以访问业务记录的哪些字段；

 应用日志与审计

 为关键的系统流程设计日志审计功能；

 日志记录用户对系统敏感资源（如保密数据或文件等）的访问情况；

 对过期的日志进行备份；

 日志具有查阅的功能，但不可以修改。

9.3.2. 应用开发安全要求

 安全编程

 对于总局有标准和制定工具的，要采用总局标准和工具进行开发；

 对于总局未指定的，需要对采用的标准和工具进行安全性评估；

 接口安全

接口要遵循总局的接口标准规范。

 数据传输的机密性

对敏感数据要采用加密传输技术。必要时要采用二次认证方式，实现对数据的保护。  安全审计

系统要支持审计，审计模块至少包括以下内容：事件的日期、时间、发起者信息、类型、描述和结果等内容，审计记录的内容应当尽可能保证详细以便于事后问题的最终和审计检查。

 安全测试

系统上线前要进行安全测试和评估。

9.3.3. 身份认证系统

运营商必须提供符合国税总局金税三期PKI标准的身份认证系统。纳税人身份认证系统的推广使用采用先试点再逐步推广的策略。

9.3.4. Web安全防护

对web我们建议采用以下三种措施进行防范：

 利用IDS对SQL注入和跨站攻击进行实时，并通知防火墙进行阻断。

 在WEB服务器前部署两台Web应用防火墙，来防范来自应用层的风险。

 通过在重要WEB服务器安装网站防篡改软件，实现对网站页面的保护。

9.4. 数据层安全

1、利用https协议为使用网络发票系统的用户提供数据传输加密，以保护纳税人的隐私信息和敏感数据。通常的做法是将SSL 运算放在提供发票服务的主机上，由于SSL 运算极耗资源，即使是功能最强大的服务器也无法达到很高的速度。这样，在上网的高峰时刻，等待时间会越来越长，有时一些交易根本无法完成，这种情况下，需要部署SSL加速器，来实现SSL加速。

2、根据应用系统的实际需要部署服务器密码机，为应用系统的提供统一的、高性能、

与具体协议和设备无关的多密码算法作业服务，实现应用数据的保密、防抵赖、完整性等安全保密服务。

9.5. 终端安全策略

1、防病毒软件

进行全网终端计算机的病毒防范。

2、个人防火墙

防止对终端的非法访问。

3、终端安全管理和补丁管理

9.6. 系统层安全

总局主机的安全设计主要从操作系统和数据库和等两个方面来考虑。根据等级保护二级的防护要求主要从以下几个方面对主机的安全进行防护：

 身份鉴别

对登录操作系统和数据库系统的用户进行身份标识和鉴别，杜绝默认帐号，不合规则的帐号登录访问；操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点，口令应有复杂度要求并定期更换；启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施，三次登录失败帐号会被锁定。为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性。

对服务器进行远程管理需要采用安全的模式， 针对系统管理员除用户名和密码外，还需要采用数字证书或者UKEY等其他身份鉴别手段。

 访问控制

建立标记规则，在服务器等实体资产上粘贴属性标签，文档介质类粘贴或打印密级等标记，对于电子数据使用文件名或文件注释进行标记。建立访问控制策略，依据最小原则授予用户权限，操作系统和数据库系统要使用不同的特权用户，对用户权限分配应当定期检查。

严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令；及时删除多余的、过期的帐户，避免共享帐户的存在。

 安全审计

由于开启操作系统和数据库的审计功能会影响系统的性能，建议在核心交换安全域配置主机数据库综合审计系统对主机和数据库信息进行审计

 入侵防范

通过部署主机防火墙设备或者主机防病毒软件中的入侵检测模块监视外来的入侵行为并记录，定期进行系统升级和安全加固。

 恶意代码防范

在主机上安装防病毒产品。

 资源控制

Windows系统通过本地安全策略限制登录IP，Unix系统可通过TCP Wrapper工具进行访问IP限制。使用监控管理软件对服务器的CPU、硬盘、内存、网络等资源的使用情况进行监视，设置系统资源过低报警的门限值。

9.7. 网络层安全

9.7.1. 网络结构安全

网络架构的安全性具体表现在：

设计采用高安全级别的设计理念，按照生产平台的管理和服务等功能定位，依照业务种类、服务对象和安全性要求不同，划分不同区域层次，每个区域和层次相对独立，相互不干扰。不同分区边缘部署防火墙，区域内部实现统一的安全策略，完成2到7层的安全立体防护体系。

9.7.2. 划分子安全域

1、对网络发票管理系统网络结构通过防火墙、VLAN、安全设备策略进行进一步可以化为6个安全子域分别为：对外公共服务安全域（DMZ）、认证服务安全域、网络发票管理系统交换安全域、网络发票管理系统数据库安全域、网络发票管理系统管理安全域，

2、对网络发票管理系统数据安全域和DMZ安全域进行进一步细化，将安全域落实在具体的业务系统上，各安全域之间采用VLAN实现边界隔离和访问控制。具体如下：

详见《金税三期工程安全架构蓝图设计方案.doc》

9.7.3. 网络访问控制

通过防火墙和VLAN对总局网络发票管理系统划分的各个安全域进行访问控制。总局网络发票管理系统的防火墙配置：



 总局网络发票管理系统接入区配置2台万兆防火墙，限制来自外界的风险。 在网络发票管理系统数据库区前配置2台千兆防火墙，以保护网络发票管理系统数据的安全。

Web/APP安全域根据服务器的性质，利用交换机划分出多个VLAN利用ACL进行访问控制。利用LVAN实现认证网络发票管理系统和网络发票管理系统管理区的访问控制。

9.7.4. 恶意代码防范

在网络发票管理系统接入区部署两台防病毒网关，部署两台抗DDOS系统（设备），对流量进行清洗和病毒过滤，在网络发票管理系统的服务器部署网络防病毒软件和防病毒网关，抗DDOS系统共同组成三层病毒扫描架构的立体网络防病毒体系。

9.7.5. 网络安全审计

在网络发票管理系统的web服务器区部署一台网络审计，对访问Web区域的网络行为进行审计。

另外，搭建专门的日志服务器，将网络设备、安全设备等产生的日志进行存储和审计。

9.7.6. 边界完整性检查

利用非法外联监控和非法内接监控设备来进行网络边界完整性检查。对于非法内联，应能够对非授权设备私自联到内部网络的行为进行检查，准确定出位置，并对其进行有效

阻断。对于非法外连，应能够对内部网络用户私自联到（比如拨号连接）外部网络的行为进行检查，准确定出位置，并对其进行有效阻断。

9.7.7. 入侵防范

在网络发票管理系统web/APP安全域接口交换机上配置1台千兆IDS，监视互联网引入的安全威胁；在数据库区部署1台IDS，监视该区域的安全威胁。

9.7.8. 网络设备安全防范

重要的网络设备可以使用两种或两种以上组合的鉴别技术来进行身份鉴别，如密码、令牌、生物识别技术等；对与核心的网络设备建议不使用网络登录或者限制登录终端，网络登录要使用加密方式以防止窃听。

9.8. 系统层安全

纳税服务系统主机的安全设计主要从操作系统和数据库和等两个方面来考虑。根据不低于等级保护二级的防护要求主要从以下几个方面对主机的安全进行防护：

 身份鉴别

对登录操作系统和数据库系统的用户进行身份标识和鉴别，杜绝默认帐号，不合规则的帐号登录访问；操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点，口令应有复杂度要求并定期更换；启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施，三次登录失败帐号会被锁定。为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性。

对服务器进行远程管理需要采用安全的模式， 针对系统管理员除用户名和密码外，还需要采用数字证书或者UKEY等其他身份鉴别手段。

 访问控制

建立标记规则，在服务器等实体资产上粘贴属性标签，文档介质类粘贴或打印密级等标记，对于电子数据使用文件名或文件注释进行标记。建立访问控制策略，依据最小原则授予用户权限，操作系统和数据库系统要使用不同的特权用户，对用户权限分配应当定期检查。

严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令；及时删除多余的、过期的帐户，避免共享帐户的存在。

 安全审计

由于开启操作系统和数据库的审计功能会影响系统的性能，建议在核心交换安全域配置主机数据库综合审计系统对主机和数据库信息进行审计

 入侵防范

通过部署主机防火墙设备或者主机防病毒软件中的入侵检测模块监视外来的入侵行为并记录，定期进行系统升级和安全加固。

 恶意代码防范

在主机上安装防病毒产品。

 资源控制

Windows系统通过本地安全策略限制登录IP，Unix系统可通过TCP Wrapper工具进行访问IP限制。使用监控管理软件对服务器的CPU、硬盘、内存、网络等资源的使用情况进行监视，设置系统资源过低报警的门限值。

9.9. 物理层安全

总保证计算环境能满足相应的机房场地选择要求、机房防火、供配电、空调降温、防水与防潮、防静电、接地与防雷击等要求，并对通信线路进行安全防护，保证设备的防盗和防毁及安全可用，以及保证记录介质安全。

第10章 应用部署要求

10.1. 生产环境部署

网络发票管理系统应用系统部署要符合总局应用部署规范，WEB层/应用层采用集群负载均衡部署，数据库层采用并行处理部署；

 运营商端：部署运营商端网络发票开具软件和网络发票业务前置；

 税务局端：部署网络发票数据库、网络发票数据交换前置和发票查验前置。

税务局端网络发票管理系统采用总局/省局两级部署模式，总局部署如下图所示，考虑到总局不需要直接接收运营端的信息，因此总局税务局端无需部署针对各运营商的数据接收前置：

省局署示意如下图所示：

10.2. 灾备中心部署

网络发票采用应用级灾备，在总局灾备中心采用同级部署或降级部署，部署在省局的网络发票管理系统不在总局灾备中心部署应用级灾备。运营商端需要支持与总局灾备中心的线路对接。

第11章 架构管控约束

金税三期工程实施阶段的架构管控具有重要的意义：它确保所有项目的架构设计对总体架构的遵从和符合，最终保障工程整体架构的一致性。

架构管控只针对架构设计，不管理项目的业务需求、进度质量。税收征管项目的架构管控内容包括前面各章所述的规划要求。

在税收征管项目实施过程中，我们将架构管控工作分为五个阶段：

1. 项目启动阶段：管控组协助项目组，编制项目的《架构管控计划》，对管控的关

键时间点、内容、方式、参与人员等进行审查。

2. 需求分析阶段：管控组对项目涉及的架构规划内容提供资料，或进行培训。

3. 架构设计阶段：管控组派驻管控人员进入项目组；项目组可以提出架构需求中涉

及的问题，管控组予以协助；管控人员可以参与项目架构设计，以全程把控；管

控组根据计划，在项目实施关键时间点，对项目执行架构遵循审核，如果没有通

过审核，将不允许进入下一阶段；项目组应开放开发配置库，以便管控组抽查。

4. 开发测试阶段：管控组支持金税三期工程完成应用系统的集成测试。

5. 运行验收阶段：管控组参与项目验收，就开发商的架构遵循度提出评估意见，对

项目的验收产生决定性的影响。

在税收征管项目实施过程中，管控组将依照架构管控流程进行规范管理。该流程对项目设计的架构进行遵循度评审，确保项目对总体架构规划及标准等的一致性。

架构管控流程的主要环节如下：

 制定管控计划

在某一具体项目的初始阶段，项目组的架构师和派驻项目组的架构组管控人员，需要先根据项目里程碑计划，制定架构管控计划。计划的描述要素包括：架构管控的阶段名称、开始时间、完成时间、关键工作、参与人员和交付物。

架构管控计划需要提交至项目管理组和总体架构组来进行审核，审核通过的计划需要提交工程办正式批准。

 管控计划跟踪

在架构管控计划审批后，总体架构组派专人进驻项目，负责日常化和计划性相结合的持续跟踪、监控；重点关注架构设计的偏差、风险、问题和产生上述情况的原因，并上报

工程办。

项目按计划执行过程中，在每周召开的项目例会上，项目组长要了解架构管控工作情况以及存在的问题，对存在问题分析是否需要总体架构组协助解决，并明确解决方案和责任人。项目例会要保留会议纪要；重大架构问题和变更需要报送工程办决策。

 架构审核

架构组根据管控计划，针对特定的项目从架构、标准等方面进行阶段性审核，揭示项目存在的架构风险和问题；或针对特定的架构问题／事件，进行深入调查，分析问题的根本原因。架构审核结束后需按要求提交《架构审核报告》。

在架构管控流程中，项目组的相关职责如下：负责项目架构管控计划的编写；负责项目架构管控计划的执行；负责项目架构管控计划的变更执行。同时，项目组的架构师应负责项目架构设计，保证项目架构和标准规范符合总体规划要求，以及项目架构设计的修正。

第12章 技术开发规范约束

12.1. 总体概述

12.1.1.

目的

《网络发票系统运营商端软件开发技术规范》由国家税务总局提出，金税三期工程架构管控项目组起草，以网络发票系统业务需求和架构需求为基础，以金税三期架构标准体系为依据，明确网络发票系统运营商端软件涉及的技术标准，约束和规范网络发票系统运营商端软件的建设，以保证各运营商开发的网络发票系统软件与相关应用系统在关键技术标准体系方面的一致性。

12.1.2. 范围

《网络发票系统运营商端软件开发技术规范》的内容包括：

 业务流程标准  业务数据标准  模型设计标准  集成标准  关键技术标准  安全标准

12.1.3. 标准规范概述

根据金税三期架构标准体系，网络发票系统运营商端软件需要遵循的标准内容如下表所示，其中业务流程标准和业务数据标准由业务组提供，其他技术标准均由架构组提供。

运营商和税务端软件开发商将在项目实施阶段协助总局对上述标准内容进一步健全优化完善。

12.2. 业务流程标准

业务流程标准是从业务视角来定义各类业务流程的执行标准，从而形成各类系统能够共同参照和遵循的业务基线。

12.2.1. 业务需求

网络发票系统纳税人端基线业务需求可以作为各运营商开发网络发票系统运营商端软件的业务流程标准，包括网络发票纳税人端相关业务功能、业务流程、表证单书等。

具体参见《网络发票开票软件业务（纳税人）.doc》

12.3. 业务数据标准

业务数据标准保证不同应用系统在实施过程中能够对各类业务数据有一个统一的理解和定义，不同系统在数据的采集、共享交换以及数据库层面能够形成一致的业务语义环境。网络发票系统运营商端软件需要遵循总局统一制定的业务数据标准，包括税务数据元目录

标准以及税务业务代码标准。

12.3.1. 税务数据元目录标准

定义出描述各类税务业务数据项以及代码所需要的元数据体系，业务元数据是制定数据项标准和业务数据代码标准的基础。

具体参见《SW 2010-税务数据元（核心征管）.doc》

12.3.2. 税务业务代码标准

税务业务代码集是税务业务相关的代码数据标准,涉及税务行业各类业务代码的命名、类型、长度、分类及代码内容等信息。

具体参见《SW 2010_税务代码集.doc》

12.4. 模型设计标准

将业务数据反映到IT层面必须进行数据建模工作，主要涉及关系数据库模型设计规则和部分业务数据信息的数据模型，保证各类应用系统在模型表达方面的一致性。

12.4.1. 关系型数据模型设计标准

规定全局性的数据模型设计标准，对未来各类税务应用系统的数据交互以及数据库设计提供强制性的规范约束，保证不同应用系统在数据存储层面的设计规则一致性。网络发票系统运营商端软件需要遵循总局统一制定的关系型数据模型设计标准。

具体参见《税务数据模型设计标准.doc》

12.4.2. 关系型数据模型标准

网络发票系统运营商端软件涉及部分主数据和网络发票数据，这些信息的数据模型与税务端的数据模型一致。具体模型在系统开发设计阶段明确。

12.5. 集成标准

集成标准规定了各类应用系统必须遵循的各类技术规范，以保证系统间未来的互操作性的一致性。按照交互方式可以分为两种。一种是满足应用集成的需要，为各类应用的集成、协调工作提供标准保障，应用系统间的交互方式为接口服务调用；另一种是为各应用数据层面的可集成性提供标准保障，以满足数据交换的需要，应用系统间的交互方式为批量报文技术。

网络发票系统运营商端与税务局端交互方式均为批量报文技术。自开票企业和网络发票系统运营商端的交互方式有批量报文技术和接口服务调用两种方式。如下图所示：

 网络发票系统运营商端与税务局端交互如下表所示：

网络发票系统运营商端软件采用接口服务调用方式与其他系统进行交互需要遵循总局统一制定的应用服务集成标准。

网络发票系统运营商端软件采用批量报文技术与其它系统进行交互需要遵循总局统一制定的数据交换技术协议标准。

不管是采用应用服务集成标准还是数据交换协议技术标准，网络发票系统运营商端软件与其它系统交互的业务信息内容，均遵循总局统一制定的税务行业业务报文设计标准。

12.5.1. 数据交换技术协议标准

规定系统进行数据交换时所必须遵循的技术协议标准，提供为后期数据交换平台以及具体的交换业务开发提供强制性的约束。具体包括以下内容：数据交换方式、数据交换技术接口标准、数据交换报文结构、数据交换安全标准。

 数据交换方式如下表所示：

图3.4.1.1税务局数据发送前置

税务局数据发送前置推送纳税人基本信息、发票发售信息到运营商网络发票业务前置，采用二次握手方式。

首先税务局数据发送前置以发送回执服务的数据交互方式，发送消息通知报文，运营商网络发票业务前置接收到报文后，并给税务局数据发送前置一个回执报文。

税务局数据发送前置根据回执报文的内容，以请求服务异步模式发送业务数据报文。

图3.4.1.2税务局数据接收前置

运营商网络发票业务前置推送发票开具信息到税务局数据发送前置，采用二次握手方式。

首先运营商网络发票业务前置以发送回执服务的数据交互方式，发送消息通知报文，税务局数据发送前置接收到报文后，并给运营商网络发票业务前置一个回执报文。

运营商网络发票业务前置根据回执报文的内容，以请求服务异步模式发送业务数据报文。

具体参见《税务行业数据交换技术协议标准.doc》

12.5.2. 税务行业数据报文设计标准

税务行业采用基于XML格式的业务数据交换模型设计标准，对未来各类税务应用系统间数据交换的业务数据报文设计提供强制性的规范约束，保证不同应用系统在数据交互层面的设计一致性。

数据交换技术协议定义了数据交换的技术协议报文结构。请求服务方式、发送回执方式和发布预约方式均遵循同样的报文格式定义。

技术协议报文包括信封内容、交换环节内容、交换内容控制、返回状态、业务内容和签名体内容六个部分。

1）信封由报文的命名空间、版本、语言等组成；

2）信封内容、交换环节内容、交换内容控制由报文的标识、来源、目的、路由信息等组成；

3）业务内容是要发送的电子数据； 4）返回状态用于回执报文；

5）签名体内容是体内加签时的签名信息。

String String String String String String String true 2001-12-17T09:30:47.0Z String String true String true String true String

String String String String String String String String String

具体参见《税务行业数据交换技术协议标准.doc》、《税务行业业务报文设计标准.doc》

12.6. 关键技术标准

12.6.1.

总体技术路线

金税三期工程技术架构将遵循J2EE架构技术标准和规范，应用系统数据库中间件选型为ORACLE11g。

网络发票系统运营商端软件服务器端系统与金税三期工程的总体技术路线一致，需要遵循J2EE架构技术标准和规范，数据库中间件为ORACLE11g；客户端系统不受此限制。

12.6.2. 二维条码应用技术标准

网络发票开具时，网络发票系统运营商端软件需要提供发票票面信息生成二维条形码的功能,支持含二维条码发票的打印，作为缺省实现内容，但各省根据自身情况可以确定是否使用。二维条码包含完整的发票信息（如发票代码、发票号码、开票日期、付款方名称及证件号码、收款方名称及证件号码、金额、税额、防伪码等等）和数字签名信息，通过二维码的扫描识别可还原，便于传递和识别采集。

网络发票要素信息长度：基于金税三期网络发票业务需求表单，一张网络发票其要素信息最多不会超过500个汉字（数字和字符换算为汉字），即网络发票要素信息长度

数字签名信息长度：根据美国联邦信息处理标准FIPS PUB 186发布的数字签名标准（DSS，Digital Signature Standard），数字签名长度为320bit(等于40Bytes)，根据下面所选的二维码汉字编码效率换算为汉字不超过30个汉字，即数字签名信息长度

网络发票要素信息长度+数字签名信息长度

根据二维条码技术调研，结合二维条码容量的要求，推荐从“网格矩阵码（GM）”、“汉信码”和QR码中选择一种作为网络发票的二维码标准；

三种标准的各种关键指标比较如下表所示：