金税三期工程架构服务需求

金税三期工程 架构管控 项目 第 1 页 /共 34 页 目录 第 1 章 .3 1.1. 总体战略目标 . 3 1.2. 总体技术目标 . 4 1.3. 总体架构要求 . 5 第 2 章 应用设计约束 .6 2.1. 规划思路 . 6 2.2. 纳税人渠道 . 6 2.2.1. 功能约束 .6 2.2.2. 技术约束 .7 2.3. 纳税服务应用支撑 . 9 2.3.1. 功能约束 .9 2.3.2. 技术约束 .9 第 3 章 数据设计约束 .11 3.1. 规划策略 . 11 3.2. 数据分类 . 11 3.3. 数据质量 . 12 第 4 章 集成约束 . 13 4.1. 界面集成 . 13 4.2. 应用集成 . 13 4.3. 数据集成 . 14 4.4. 安全集成 . 14 第 5 章 非功能性约束 . 16 5.1. 范围 . 16 5.2. 系统性能 . 16 5.3. 可靠性 . 17 5.4. 可用性 . 18 5.5. 易用性 . 18 5.6. 可维护性 . 18 5.7. 可扩展性 . 20 5.8. 可伸缩性 . 20 5.9. 可移植性 . 20 5.10. 可重用性 . 20 第 6 章 安全性约束 . 21 6.1. 安全等级要求 . 21 6.2. 策略和措施 . 21 6.3. 应用层安全 . 22 6.3.1. 应用系统安全设计要求 . 22 6.3.2. 应用开发安全要求 . 23 金税三期工程 架构管控 项目 第 2 页 /共 34 页 6.3.3. 身份认证系统 . 23 6.3.4. Web 安全防护 . 24 6.3.5. 数据层安全 . 24 6.4. 终端安全策略 . 24 6.5. 系统层安全 . 25 6.6. 网络层安全 . 26 6.6.1. 网络结构安全 . 26 6.6.2. 划分子安全域 . 26 6.6.3. 网络访问控制 . 26 6.6.4. 恶意代码防范 . 27 6.6.5. 网络安全审计 . 27 6.6.6. 边界完整性检查 . 27 6.6.7. 入侵防范 . 27 6.6.8. 网络设备安全防范 . 28 6.7. 物理层安全 . 28 第 7 章 部署约束 . 29 第 8 章 架构管控约束 . 30 第 9 章 标准约束 . 32 9.1. 标准体系概述 . 32 9.2. 系统标准遵循说明 . 33 金税三期工程 架构管控 项目 第 3 页 /共 34 页 第 1章 金税三期概述 1.1. 总体战略目标 金税三期工程的业务战略目标是： 统一税收执法； 统 一纳税服务； 统一 管理决策 ； 统一征管数据实时监控。 首先，统一税收执法是在国家税法统一的前提下，以总局统一的政策管理为依托，包括国、地税税收执法尺度的统一，为纳税人提供公平、公正的税收环境。在现阶段，公平、公正是对纳税人最好的服务。同时，统一税收执法，也是现阶段实现应收尽收，保证税款及时入库的有效保证。 其次，统一纳税服务，不是简单的建立一个平台，而是保证服务目标、服务内容、服务水平的一致，避免不同地区、不同税务人员对同类事项执法不一、口径各异和服务差异。 第三，统一 管理决策 ，是采用科学的方法，利用数据集 中和信息共享手段，为各级领导提供一致的管理和决策依据。 第四，建立在全国大集中基础上的统一实时的征管数据监控，是促进统一执法、统一服务、统一 管理决策 的手段保障。 在国内外新的经济形势下，为了实现四个统一的战略目标 ,总局确定了信息管税的总体战略，信息管税就是以税收风险管理理念为指导，以现代信息技术为依托，以对涉税信息的采集、应用为主线，优化资源配置，完善税源管理体系，加强业务与技术的高度融合，着力解决征纳双方信息不对称问题，不断提高税法遵从度和税收征收率。 其中，信息管税是一项系统工程 ,必然要涉及到税务管理的 思想观念、制度机制、业务流程、组织机构等一系列变化。 如下图所示： 金税三期工程 架构管控 项目 第 4 页 /共 34 页 这里的“全国大集中”，涵盖 核心业务系统 全国集中部署和应用，统一业务需求管理、统一应用开发和运行维护管理。 1.2. 总体技术目标 金税三期工程建设的主要内容是：计划用四年时间，在现有资源基础上，通过制度、业务和技术创新，完成“一个平台、两级处理、三个覆盖、四个系统”的建设，进一步强化纳税服务和税务管理，提高税法遵从度和税收征收率，降低税收成本，为税收法律法规的统一执行提供有力保障。上述目标 可具体概括为“一门户、三网、四平台、七库”，具体描述如下： 1、“一门户”是通过实施全国数据大集中，优化业务流程和功能配置，统一国地税征管系统，为全国各级税务人员提供统一的内部门户和工作平台，实现全国税收业务的统一、规范管理。 2、“三网”是建成税收征管业务网络、行政办公网络、涉密网络，这三个网络全国国、地税统一建设，具备强大的信息采集、存储、处理、交换等功能，安全可靠程度高，确保各项税收业务与管理在统一、安全、稳定的网络化信息平台支撑下平稳运行。 3、“四平台”是指建设全国统一的纳税服务平台、征管和行管业 务操作平台、 管理决统一税收执法 统一纳税服务 统一管理决策 统一征管数据实时监控 统一全国征管数据标准、口径 统一国、地税核心征管应用系统版本 实现全国征管数据大集中 统一、规范全国的纳税服务平台 以 SOA 技术整合行政管理系统 以流程管理理念开发征管系统 以风险管理理念开发管理决策系统 建设网络实时开具的电子发票平台 金税三期的业务战略 总体战略 树立税收风险管理理念 以数据的采集和分析为核心 以健全税源管理体系为落脚点 加强业务、技术高度融 合 信息管税 金税 三期的六个亮点 信息管税 金税三期工程 架构管控 项目 第 5 页 /共 34 页 策 平台，这四大平台能使广大纳税人方便、快捷地办理各项税费事宜，广大基层税务人员高效、简洁地处理各项业务，使各级税务管理者及时有效地实施管理与决策。 4、“七库”是指在总局、省局两级建立并逐步完善法人涉税数据库、自然人涉税数据库、发票数据库、第三方信息数据库、税收风险管理数据库、税务机构数据库（包括财务、固定资产等）和人力资源数据库、税收法规数据库（包括文件、档案等）这七个数据库，并进行数据的集中存储和处理，同时建立第三方信息共享机制，实时、完整、准确地掌握纳税人涉税费信息和税务机构、人员等 情况，以利于提高税收服务与管理水平。 1.3. 总体架构要求 总体架构既包含业务、应用、数据、技术、安全 等方面的框架，也包括架构管控 的体系。一方面，作为框架，总体架构定义了业务、应用、数据、技术、安全等架构的目标蓝图，还包括相关模型，及各部分的指南、设计准则，项目需要根据总体架构的约束来实现其 应用；另一方面，作为架构管控 ，它指明了项目在进行项目实施的时候需要遵守的标准、规范，可以参考的相关架构资源以 及需要遵守的架构管控流程，以确保项目的实施符合金税三期的总体规划 。 总体架构主要由业务架构、应用架构、数据架构、技术架 构（包括系统软件、基础设施等）、安全架构、运维架 构、标准、架构 管控 体系等组成，这些总体架构的内容将构成对项目 架 构方面的约束，项目需要在这些架构的约束下进行业务需求分析、设计以及 实现。 金税三期工程 架构管控 项目 第 6 页 /共 34 页 第 2章 应用 设计 约束 2.1. 规划思路 按照 金税三期总体 应用架构 规划设计 ，纳税服务系统由 服务渠道、 纳税服务应用支撑两部分 组成，其中服务渠道包括 大厅、网络 、 电话 、 短信、邮寄、自助终端 ，在整体金税三期应用环境的位置如下图中 红色框 部分所示。 但综合考虑业务的连续性耦合度要求和项目 划分及 实施的情况，大厅 、自助终端以及邮寄 的建设划入核心征管系统项目。 下面 重点对 纳税人渠道 和 纳税服务应用支撑 的功能 约束 和技术约束 进行说明 。 2.2. 纳税服务 渠道 2.2.1. 功能约束 纳税 服务 渠道 从技术手段主要包括网络、电话、短信以及邮寄，从支撑的业务范围 主要 包括 三类服务，一是面向包括纳税人在内的所有公众提供的静态信息服务，它是宣传税务局形象的窗口；二是为纳税人提供信息 交互服务的通道 ；三是纳税人办税的 重 要 服务形式 ，它是一个虚拟的 办税服务 渠道 。 渠道的技术实现要求支持以下几类形式 ，其中 大厅、自助终端、 邮寄类渠道由核心征金税三期工程 架构管控 项目 第 7 页 /共 34 页 管来负责处理 ： 网络 ： 提 供基于网站的 各类 服务 ，包括通知公告发布、纳税人互动交流以及在线业务办理的相关功能 等 。 电话 ： 提供基于电话语音的各类服务， 包括通知公告发布、纳税人互动交流以及在线业务办理的相关功能 等 。 短信 ： 提供 统一的短信 服务，包括通知公告发布、 业务 交互 等服务 等 。 此外要求能够接入未来的各类商业纳税人端渠道，提供统一的技术和数据接入标准。 渠道服务 主要包括以下 内容 ： 通知公告 ：对纳税人提供各类通知公告的机制。 税法宣传 ： 包括税法法规和办税指南 等 。 预约： 提供对各类预约业务的支持。 涉税公告： 包括定额公示公告、非正常户公告 、欠税公告、催报催缴和违法违章公告 等 。 电子邮件： 在网络 渠道中 提供电子邮件 的 方式实现同纳税人的交互。 互动交流： 包括 咨询 、举报投诉建议、 评价 调查、在线访谈和电子导税员 等 。 涉税查询： 包括发票查询、登记信息查询、欠税查询、信用等级查询和发票真伪查询 等 。 个性化服务： 包括涉税提醒和受理反馈信息 等 。 在线办税： 包括税费申报、实时缴款、财务会计报表、网上认证、网上抄税、委托代征、出口退税申报和网上开票 等 。 所有渠道必须 提供统一规范标准的接口 支持各种形式的数据导入 。 具体 功能 参见业务需求。 2.2.2. 技术约束 服务渠道 建设统一的 信息访问入口，包括静态信息服务、 信息交互服务和 办税服务，统一访问后台所有需要访问的应用系统和信息资源，并为用户提供个性化服务。 服务渠道提供 门户框架、内容管理、 短信、电话语音、安全认证 、系统集成 等 功能 ， 具体 如下： 名称 定义 技术约束 金税三期工程 架构管控 项目 第 8 页 /共 34 页 名称 定义 技术约束 门户框架 提供各类网站页面开发、部署、运行、 管理以及集成的框架环境。 考虑到 网络渠道 需要加载的业务未来将会不断增加，要求必须能够提供完整的门户框架来保证不同类型业务的扩展需求。 纳税人个人门户管理机制 提供界面布局、样式以及内容的个性化定制机制。同时包括纳税人的个性信息、个 人涉税记录等各类能够进行个性化定制的功能和信息机制。 为了更好的提升纳税人的交互体验，方便纳税人网上办税，要求提供纳税人个人门户空间机制，允许其在一定范围内根据个人喜好进行功能和信息层面的定制。 内容管理机制 提供完整的 网络 信息 采集、审核、存储、 全文 检索、发布平台环境，实现对各类信息的统一管理 。 内容管理是实现 渠道 信息公开类业务的关键性技术，要求必须提供能够满足全国集中规模下的内容管理平台环境。 短信 机制 提供完整短信平台，实现基于短信的信息发布、提醒通知 、业务交互 等功能 短信方式是实现对纳税人主动服务 的一种重要手段，因此要求必须提供能够满足全国集中规模下的 短信 管理平台环境 。 电话 语音机制 提供完整的基于电话的语音服务平台，实现同纳税人的互动交流以及相关业务办理等功能。 要求必须提供能够 满足全国集中规模下的 电话语音 管理平台环境 。 可靠的 认证 机制 提供可靠的认证方式，以保证整个 渠道 的访问的安全性。 要求必须提供满足安全策略要求的认证方式，支持总局统一的安全认证机制。 数字 签名及 数据 加密 提供 数字 签名及 数据 加密机制 。 为了保障网上涉税业务中纳税人的权利和义务， 服务渠道 必须提供符合全局安全性要求和标准的数 字 签名和 数据加密机制 。 页面表单 提供页面表单的缓存管理，避免页面重复生成带来的性能开销，提升交互的响应时间 。 对于大量的静态信息页面以及频繁使用的各类业务模板 ,要求采用页面缓存机制来提升性能 。 代码缓存机制 提供代码缓存机制 ,降低大量代码数据对网络、磁盘 IO 的消耗，提升系统整体的性能 。 考虑到全国大集中模式下各类代码数据会急剧增加，因此必须在客户端提供不同策略的代码缓存机制，有效缓减海量代码带来的性能问题 。 并发控制 并发控制是提升系统可靠性，降低系统性能风险的关键性机制。通过并发控制，及时掌握系统 当前的用户访问流量，进行监控预警。并发控制作为前端的一个总控点，需要保证健壮和稳定，并且支持分布式部署。 考虑到全国大集中模式下 各类渠道 的业务量会逐年上升，因此必须提供并发控制来有效保障系统的可靠性 。 金税三期工程 架构管控 项目 第 9 页 /共 34 页 2.3. 纳税服务应用支撑 2.3.1. 功能约束 纳税服务应用支撑 是提供给税务干部进行 纳税人交互类服务处理的 统一 、 集成 、多种服务渠道共享 的 平台，它主要包括 例如 集成的联络界面、纳税人 接触历史 管理、 渠道集成、功能集成、 服务管理等内容 . 集成的联络管理界面： 提供一个以纳税人为中心来组织纳税人各类信息的统一的界面视图，便于税务干部 迅速、准确的处理纳税人提出的各类服务请求； 接触历史管理 ： 为税务干部提供完整的纳税人和税务局之间发生交互行为的历史信息； 渠道 服务 集成 ： 必须提供统一的渠道接入标准，同时 能够 根据需要 接入 或者访问多种服务渠道， 并 能把来自不同渠道的 交互类 服务 请求进行统一管理 ； 功能集成： 能够实现将服务信息内容与核心征管、 行政管理、 风险管理和知识库等进行相应功能集成。 数据集成： 纳税服务应用支撑必须保留能够支撑纳税人进行各类查询的业务明细数据和业务状态数据，根据各类业务数据的特性提供相应的数据同步策略和机制。 交互 类 服务 ： 实现各类 渠道的咨询、预约、通知通告、评价调查、提示提醒、举报投诉等交互服务的处理； 查询 类 服务： 为 各类渠道 提供纳税人 相关的业务状态以及业务明细数据 的查询服务。 服务 质量 管理： 对 税务干部提供 纳税人 的 服务 进行质量 管理， 如服务评价、服务满意度调查、服务监督 等。 2.3.2. 技术约束 纳税服务应用支撑 技术约束包括以下几个部分 ： 名称 定义 技术约束 流程处理机制 实现 纳税服务应用支撑 中相关服务的流程定义、运行、监控和维护机制。 与总局指定的流程管理平台能兼容和互操作。 金税三期工程 架构管控 项目 第 10 页 /共 34 页 名称 定义 技术约束 界面集成支持 支持统一的业务工作门户和外网纳税服务门户进行界面层集成，界面层的设计和开发必须遵循界面集成标准。 总局会建设全局统一的业务工作门户和外部纳税服务门户，实现所有业务系统界面层的一体化展现，以及面向纳税人的纳税服务门户，要求 纳税服务应用支撑 的界面环境必须能够实现与业务工作门户和外部纳税服务门户的完全融合 渠道集成机制 对于各类服务渠道，需要提供完备的管理机制，定义和维护渠道的接入协议、接入报文规范、接入安全机制、服务质量等特性 纳税服务应用支撑 信息来源众多，涉及到征管、 管理决策、行政办公、 网络 ，12366、短信、电话、外部门反馈等多个信息来源渠道，针对这些 众多的信息来源渠道， 纳税服务应用支撑 平台需要提供完善的渠道集成机制。 服务监控机制 实现对各类型 纳税人 服务的实时监控，使得纳税人和税务干部能够实时掌握关键服务的动态执行过程 、结果 ，以及服务提醒。 纳税服务应用支撑 是集成以纳税人为中心的各类服务，要求提供服务监控服务机制，使税务干部和纳税人能够实施掌握关键服务的流程，执行状态，并能够为其相关业务平台提供服务提醒功能或者提醒机制。 符合服务集成封装机制 符合全局的服务注册、调用以及管理标准，能够很方便的将内部业务逻辑根据需求封装为全局性服务，以供其他系统进行 消费 所有需要提供给外部各应用的业务接口，必须符合全局的应用集成体系所定义的服务集成标准，从而保证各类对外暴露的服务能够被其他应用所共享 知识库集成机制 提供与知识库进行衔接的集成机制 一方面 ， 纳税服务应用支撑 利用知识库的知识为纳税人提供服务， 另一方面 纳税服务应用支撑 形成的知识 纳入知识库管理 。 金税三期工程 架构管控 项目 第 11 页 /共 34 页 第 3章 数据设计约束 3.1. 规划策略 在金税三期的大集中战略指导下， 纳税服务系统 数据设计 应遵循以下 关键 策略： 性能优先 考虑到全国大集中后各类渠道业务量将会持续增长，因此数据设计必须以性能为关键设计原则进行优先考虑，充分考虑数 据 模型设计和物理 分布给性能带来的影响。 共享 状态 信息 集中管理 各渠道需要共享的各类业务数据，例如纳税人基本信息、业务状态信息等，统一由 纳税服务应用支撑 集中管理，以服务的方式提供给各渠道使用。对于各类渠道业务的状态信息，例如纳税人咨询交流状态、业务办理状态等过程信息将统一由 纳税服务应用支撑 进行集中管理，以服务方式提供给各渠道使用。 渠道共享信息的范围和手段必须从性能角度去分析，如果性能不能满足建议采用渠道冗余存储的方式。 业务明细数据集中管理 针对各类纳税人查询的明细数据，考虑到未来全国大集中带来的查询性能压力 ，因此要求各类渠道查询必须用到相关业务明细数据集中 可以 由核心系统同步到纳税服务应用支撑。提供合理的数据复制策略，在不影响核心系统性能的情况下，保证业务 明 细数据的及时性 、一致性和完整性 。 采用适当的数据库设计，避免全国数据大集中的性能瓶颈。如支持缓存数据、根据内聚性按照那个某种业务属性进行数据库拆分等。 3.2. 数据分类 纳税服务系统 至少包含以下类型的数据： 静态类 服务 信息 外网网站数据是指外网网站采集和发布的信息，它用于 支持总局外部网站的静态类应金税三期工程 架构管控 项目 第 12 页 /共 34 页 用 主数据 包括纳税人基本信息、纳税人状态信息、代码信息等数据的副本 ，这类数据原则上统一由 纳税服务应用支撑 进行存储管理 ； 业务交易明细数据 包括各类涉税查询的业务明细数据，对于实时性要求不高的各类交易明细数据 可以 将其统一同步集中存储到纳税服务应用支撑。 渠道 交易类数据 包括受理各类网上办税业务时产生的 本地数据、 临时缓存 和暂存 数据，如 纳税人的本地渠道数据、申报临时数据、 网上预约、网上申报 暂存 记录 等 信息 ； 交互服务类数据 为纳税人提供交互类服务时产生的数据，例如咨询历史记录、调查信息、投诉举报信息等等。 3.3. 数据质量 数据质量 管理应遵循“事前预防、事中监控、事后补救”的设计思 路： 事前预防，指在数据录入时提供在线帮助，提示数据的录入规范； 事中监控，指在数据录入端引入对数据项的校验功能，包括数据格式校验、逻辑关系校验等，对录入错误及时发现并提示修改，有效避免错误数据的进入； 事后补救，指数据录入后，基于标准进行数据质量的审计，对错误数据提供更正界面，以避免后台数据库调整；同时，制定规范的数据更正流程，确保数据修改的高效执行和安全管理。 金税三期工程 架构管控 项目 第 13 页 /共 34 页 第 4章 集成约束 金税三期 纳税服务 系统 项目要遵循架构设计约束 ，在应用架构、集成架构、数据架构、安全架构设计等方面要求遵循金税三期相关技术规范和标准。 整体的集成环境说明及相关要求和策略请参见应用总集成架构需求文档，下面给出纳税服务系统需要遵循的相关集成要求。 4.1. 界面集成 服务渠道 的主要用户是纳税人 ， 纳税服务应用支撑 的主要用户是税务人员 ，它们在界面集成的要求上 有些区别 ， 主要的界面集成要求如下 ： 针对 纳税服务应用支撑 的界面集成要求： 要求 纳税服务应用支撑 遵循总局统一内部工作门户集成标准 ； 要求 纳税服务应用支撑 支持统一单点登录控制 ； 要求 纳税服务应用支撑 支持统一的用户管理； 针对 网络 渠道 的界面集成要求： 要求 网络 渠道 遵循总局统一外网门户集成标准 ，即静态信息 服 务 、办税信息服务和交互信息服务符合 外网 门户框架的 集成标准 ； 要求 网络 渠道 遵循安全架构要求 4.2. 应用集成 纳税服务 系统 应用集成包括 渠道系统 与 前置系统 的集成以及渠道系统与 纳税服务应用支撑 系统的应用集成 ，要求遵循总局统一的应用集成架构设计规范和标准。 1、 要求 必须遵循总局应用集成架构制定的服务协议标准。 2、 要求所有应用系统中需要被外部应用调用的功能必须将其暴露为共享服务，注册发布到全局的应用集成平台之中。 3、 要求渠道 采用总局集成标准接口与 总局前置进行集成 ，所有涉及渠道与核心系统的交互都必须通过前置来进行，不能直接访问核心系统。 4、 要求 纳税服务应用支撑 采用总局集成标准接口与 各类渠道进行集成。 金税三期工程 架构管控 项目 第 14 页 /共 34 页 5、 要求 纳税服务应用支撑 采用总局集成标准接口与 后台系统集成，如核心征管、知识库、风险管理、行政管理等 。 4.3. 数据集成 纳税服务 系统 涉及到的数据库有 总局外网网站数据 、 外部应用业务数据 和 纳税服务应用支撑 数据库，内部各数据库之间存在多种数据交换 模式，同 核心征管 系统与管理决策系统 之间还存在数据 层 交互。 数据集成应用场景的不同，需要采用不同的数据集成策略，但都必须遵循以下数据集成原则，同时 在数据库设计时遵循总局统一的数据集成规范和标准。 1、 对于海量数据，有较高的实时性要求，如主库同备份库之间数据集成、同构库间的数据同步复制、总局到省局的数据库下发等要求采用物理库表级的集成策略。 2、 对于批量或异构数据，实时性要求不高，集成逻辑比较复杂，需要大量转换的如生产库到 ODS（面向各类主题的统一操作型数据存储数据库）， ODS 到数据仓库；生产库到历史库；有非结构库到结构化库要求基于 ETL（数据的抽取、转换、装载）的批量集成策略。 3、 对于 基于文件的非结构或半结构化数据，如总局同省局的跨层级交换、总局同外部机构间的 数据交换、其他涉及到文件交换的场景等要求基于消息报文的集成策略。 4、 对于 小数据量，实时性要求高，如应用系统间的实时数据访问、构建虚拟的数据视图等要求可以基于数据服务的集成策略。 4.4. 安全集成 纳税服务 系统 安全集成包括与总局和省局应用安全支撑平台等几方面内容集成，安全集成要求遵循总局总体应用安全支撑体系规划要求。 1.认证管理要求 要求支持总局指定的认证管理机制； 纳税服务应用支撑 必须遵循全局的用户管理 要求支持认证与权限分离，支持多种身份鉴别机制，例如 CA、用户名 /密码、动态口令、 IP 等等 ，未来可以灵活扩展； 金税三期工程 架构管控 项目 第 15 页 /共 34 页 所 有渠道必须遵循全局标准的前置接入安全标准 . 2.数据安全要求 必须遵循全局标准的数据签名和加密标准 必须遵循全局标准的数据通道安全标准 金税三期工程 架构管控 项目 第 16 页 /共 34 页 第 5章 非功能性约束 5.1. 范围 非功能需求规定了系统必须满足的服务水平、系统非运行时间的属性以及系统必须遵守的约束。非功能需求适用于整个系统、系统的几个部分或特定的用例。 非功能需求虽然不直接影响系统功能，但在用户和系统支持人员对该业务系统的认可方面具有很大的影响。 非功能需求包含许多方面。主要的非功能需求包括以下几方面： 系统性能 可靠性 可用性 易用性 可维护性 可扩展性 可伸缩 性 可移植性 可重用性 5.2. 系统性能 交易可以定义为：一个交易是当一个单一角色跨越系统边界触发一个事件并执行一定数量的处理和数据库访问，它将影响架构中的所有服务器层。交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。 根据业务处理类型的不同，把交易划分为三类：交互类业务、查询类业务和大数据量批处理类业务，分别给出响应时间要求的参考值，包括峰值响应时间、平均响应时间。 交互类业务 日常交易指传统的大厅交互业务，如申报、发票销售、税务登记等，具有较高的响应要求。 金税三期工程 架构管控 项目 第 17 页 /共 34 页 业务复杂性 平均响应时间 参考值（秒） 峰 值响应时间 参考值（秒） 日常交易 3 秒 5 秒 备注：以上交易如果涉及与其它系统之间交互，响应时间应包括系统之间交互的时间 ；以上给出的响应时间 为 参考值， 查询类业务 查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，在此给出一个参考范围。 简单查询 如登记资料查询、 业务清册、 申报表查询等。 复杂查询如多表数据关联统计分析查询类报表等等。 如有特殊要求，可以在具体用例文档中单独给出响应时间要求。 备注：业务处理过程的交互操作的响应时间参见上面交互类业务的相关指标。 大数据量、批处理业务 批量交易指一次完成多笔业务处理的交易，如批量扣缴等，由于批量交易的数据量不确定，需要根据具体的情况确定响应时间。 业务复杂性 平均响应时间 参考值（秒） 峰值响应时间 参考值（秒） 批量交易 视提交数据量、业务处理量而定 5.3. 可 靠性 1、 最大宕机时间 网络渠道 ： 最大宕机时间 1 小时 。 纳税服务应用支撑 ： 最大宕机时间 1 小时 。 12366 系统 参考 12366 系统现有非功能性需求。 短信 ：最大宕机时间 8 小时。 电子邮件 ：最大宕机时间 8 小时。 2、 系统备份 金税三期工程 架构管控 项目 第 18 页 /共 34 页 提供备份系统，防止单点故障 3、 灾难恢复备份 遵循 金税三期工程容灾设计方案。 5.4. 可用性 业务 系统 应满足 7 24 小时可以使用。 5.5. 易用性 1、 易理解 a) 系统所有的业务功能界面风格和操作流程一致； b) 业务表单尽量做到所见即所得； c) 界面美观、简洁、高效；界面各部件的布局应该保持合理性和一致性； d) 界面风格一致，颜色调和、提示清晰、窗口大小适当，使用方便。 e) 在选择快捷键、缩写、暗示和图标时应符合 税务行业为 习惯。 2、 易操作 a) 常用操作有快捷键支持，大部分操作能够在小键盘内完成； b) 信息录入能够完全通过键盘完成； c) 无论逻辑步骤还是操作步骤都应避免繁杂。 3、 易学习 a) 提供在线帮助，系统关键业务 操作应提供在线帮助文档和提示信息，使操作人员能够快速直观的利用这些信息进行相应的业务操作，并 对各种状态和操作结果进行及时的反馈和提示。 b) 提供符合税务行业习惯， 详细、易读、易理解 的操作 使用手册 4、 需遵循“金税三期”工程的界面集成标准规范； 5.6. 可 维护 性 1、 可配置 a) 人员机构的可维护 金税三期工程 架构管控 项目 第 19 页 /共 34 页 系统应具备人员 /机构等基础信息的维护功能，系统应该能够快速的对人员 /机构信息进行维护和调整操作。 b) 岗位权限的可维护性 系统应具备岗位权限的维护功能，系统应该能够快速的对岗位权限进行权限赋予和回收等维护操作。 c) 业务流程的可维护性 系统主要业务 流程应具备维护功能，可根据业务规则的变化快速的对业务流程进行调整维护操作。 d) 服务接口的可维护性 系统主要业务功能应提供标准的服务交换接口，可通过开关配置快速的提供对外服务能力。 e) 参数指标的可维护性 系统应具备规范、完善的参数指标的管理功能，具备针对系统运行基础性能参数进行配置和维护的功能。 2、 可监 控 a) 提供日志审计功能 系统每个组件应具备规范、完善的的日志管理功能，具备多级日志搜集开关、有效 /失效开关、性能指标搜集开关以及开配置参数表。 b) 业务流水机制 为保证 关键 业务一致性，建议考虑 采用 流水机制。 c) 标准监控协议支 持 符合业界主流监控软件的接口规范，能够将监控数据方便的接入 到监控软件中 ，便于集中监控和管理； 3、 可读 、易于修改 要求在系统的建设过程中要有规范、清晰、完整和详细的文档，如业务需求阶段要有业务用例模型、业务活动图、业务规则、表证单书等；系统需求分析阶段要求有系统用例模型、用例文档、规则说明等；概要设计阶段要求有宏观设计文档；详细设计阶段要求有类图、时序图等；编码阶段要求有程序设计说明、变量定义说明等；测试阶段要有测试用例、测试记录等。 金税三期工程 架构管控 项目 第 20 页 /共 34 页 4、 易于升级 要求数据库、应用服务器、开发工具能方便地进行版本升级，具有向下 兼容性；易于升级也要求客户端的升级工作量较小， 建议采用 浏览器客户端 而不是 GUI 客户端 。 5.7. 可扩展性 在设计上必须具有适应业务变化的能力，当系统新增业务功能或现有业务功能改变时（界面的改变、业务实体变化、业务流程变化、规则的改变、代码改变等），应尽可能的保证业务变化造成的影响局部化。 系统应提供一个弹性的架构，支持使用配置而免编程的方式对业务流程、业务表单、查询统计等功能的定制与调整。 5.8. 可 伸缩性 当系统容量发生变化时，应能通过各个层次的扩充，保证系统合理的响应时间和吞吐量，支持负载的划分与均衡。 5.9. 可移植性 应用 系统硬件平台无关性，支持主流的硬件平台和操作系统。 5.10. 可重用性 可重用性主要是指软件产品在不同的系统建设中可以被重复利用的程度。 要提高系统的可重用性，应采用构件化的设计思想，即在提供标准化的服务接口的前提下可以替换各种可选的实现，而不会影响系统其他部分的实现，以此将系统可重用部分可能的变更充分的局部化 金税三期工程 架构管控 项目 第 21 页 /共 34 页 第 6章 安全性约束 6.1. 安全等级要求 纳税服务系统安全等级建议定为二级，最终级别以总局的定级结果为准，系统在设计上和部署上要不低于二级等级保护的标准。 6.2. 策略和措施 针对总局纳税服务系统采用的安全技术策略和对应的技术措施如 下所示： 安全技术策略 技术措施 物理安全保护策略 通过符合相关标准进行机房的建设和改造实现 网络安全策略 严格控制对纳税服务系统的访问 采用防火墙作为边界隔离措施，实现不同网络边界的访问控制 对内网纳税服务系统的各种攻击进行检测、分析和响应 采用网络入侵检测技术（ IDS） 记录互联用户对纳税服务系统的访问行为，并分析响应 采用网络审计系统实现 对网络病毒进行防范 采用网络防病毒系统 网络的端口和协议进行检测 采用漏洞扫描系统 在网络入口处对网络病毒进行拦截 采用防病毒网关 在网 络入口处对异常网络流量进行清洗 采用防产品 主机系统安全策略 主机的入侵防护策略、检测主机入侵攻击 采用网络防病毒软件的客户端的主动防御功能 加强核心数据库主机的加固和防护 采用主机防护产品 加强操作系统和数据自身的安全 主机系统加固 对主机系统存在的漏洞查找 采用漏洞扫描系统 防止计算机病毒入侵主机 采用防病毒系统 对操作系统和数据的日志进行分析，查找非法调用 采用主机与数据库综合审计系统 应用安全策略 加强应用系统自身的强壮性 开发时对安全需求进行分析、采用安全架构设计、 安全编程 对程序的代码进行检测，查找程序漏洞 采用应用系统漏洞扫描和代码审计 对核心应用系统进行双因子认证 采用身份认证体系 防止网站被非法篡改 采用网页方篡改系统 防止注入和跨占攻击 采用应用防火墙 金税三期工程 架构管控 项目 第 22 页 /共 34 页 安全技术策略 技术措施 防止网站的被挂木马程序和被攻击，监控网站的运行状况 采用网站的实时监控系统 数据安全策略 防止数据丢失、错误和非法篡改 采用数据备份与恢复体系和相关技术 保障关键业务数据的传输安全 、采用数字证书并实现数字签名 、对未采用数字证书的用户提供的访问机制，采用 加速器解决访问性能 6.3. 应用层安全 6.3.1. 应用系统安全设计要求 应该单独编写安全性设计说明概要。 应用系统架构设计时要进行安全可行性分析并通过评审。 应用系统安全性设计至少要包括以下内容： 认证与授权服务： 必须有单独的登录控制模块对登录用户进行身份标识和鉴别；需要支持多种的身份认证方式，如 CA 证书方式，用户名密码方式和其它多因子认证方式。 程序资源访问控制安全 ： 根据用户的身份和对系统的使用情况将用户分成不同的用户组； 为不同的用户或用户组分配不同的系统资源（如对象、数据等）访问权限； 用户只能访问到自己 有权限访问的系统资源（如对象、数据等）。 功能性安全： 明确各个功能的流程上的安全措施， 如是否需要审核，文件上传最大限制等。 数据域安全 数据域安全包括两个层次，其一是行级数据域安全，即用户可以访问哪些业务记录，一般以用户所在单位为条件进行过滤；其二是字段级数据域安全，即用户可以访问业务记录的哪些字段； 金税三期工程 架构管控 项目 第 23 页 /共 34 页 应用日志与审计 为关键的系统流程设计日志审计功能； 日志记录用户对系统敏感资源（如保密数据或文件等）的访问情况； 对过期的日志进行备份； 日志具有查阅的功能，但不可以修改。 6.3.2. 应用开发安全要求 安全编程 对于总局有标准和制定工具的，要采用总局标准和工具进行开发； 对于总局未指定的，需要对采用的标准和工具进行安全性评估； 接口安全 接口要遵循总局的接口标准规范。 数据传输的机密性 对敏感数据要采用加密传输技术。必要时要采用二次认证方式，实现对数据的保护。 安全审计 系统要支持审计，审计模块至少包括以下内容：事件的日期、时间、发起者信息、类型、描述和结果等内容，审计记录的内容应当尽可能保证详细以便于事后问题的最终和审计检查。 安全测试 系统上线前要进行安全测试和评估。 6.3.3. 身份认证系统 利用总局统一建设的基于 PKI 基础设施为纳税人提供应用系统的身份认证功能。纳税人身份认证系统的推广使用采用先试点再逐步推广的策略。 针对内部用户利用 总局统一建设的基于 PKI 基础设施为 内部操作人员 提供应用系统的身份认证功能。 金税三期工程 架构管控 项目 第 24 页 /共 34 页 6.3.4. Web 安全防护 对 web 我们建议采用以下三种措施进行防范： 利用 IDS 对 SQL 注入和跨站攻击进行实时，并通知防火墙进行阻断。 在网站服务器前部署两台 Web 应用防火墙，来防范来自应用层的风险。 通过在重要网站服务器安装网站防篡改软件，实现对网站页面的保护。 6.3.5. 数据层安全 1、针对远征用户（如出差在外的税务工作人员）通过 SSL VPN 接入业务专网。 SSL VPN最大的好处之一就是不需要安装客户端程序，远程用户可以随时随地从任何浏览器上安全的接入到内部网络，安全地访问应用程序，因此降低了管理员维护客户端的成本。 利用 SSL VPN 实现： 1）用户身份认证，防止外部人员非法接入。 2）数据传输安全：通过加密，保护在互联网上传输数据的安全。 基于安全性的考虑 SSL VPN 设备部署在互联网接入区的防火墙的 DMZ 区。 2、利用 https 协议为使用网上发票的用户提供数据传输加密，以保护纳税人的隐私信息和敏感数据。通常的做法是将 SSL 运算 放在提供发票服务的主机上，由于 SSL 运算极耗资源，即使是功能最强大的服务器也无法达到很高的速度。这样，在上网的高峰时刻，等待时间会越来越长，有时一些交易根本无法完成，这种情况下，需要部署 SSL 加速器，来实现 SSL 加速。 3、根据 应用系统 的实际需要部署服务器密码机，为应用系统的 提供统一的、高性能、与具体协议和设备无关的多密码算法作业服务 ，实现应用数据的 保密、防抵赖、完整性等安全保密服务 。 6.4. 终端安全策略 1、防病毒软件 进行全网终端计算机的病毒防范。 2、个人防火墙 防止对终端的非法访问。 金税三期工程 架构管控 项目 第 25 页 /共 34 页 3、 终端安全管理和 补丁管理 6.5. 系统层安全 总局 主机的安全设计主要从操作系统和数据库和等两个方面来考虑。根据等级保护三级的防护要求主要从以下几个方面对主机的安全进行防护： 身份鉴别 对登录操作系统和数据库系统的用户进行身份标识和鉴别，杜绝默认帐号，不合规则的帐号登录访问；操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点，口令应有复杂度要求并定期更换；启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施，三次登录失败帐号会被锁定。为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性。 对服务器进行远程管理需要采用安全的模式， 针对系统管理员除用户名和密码外，还需要采用数字证书或者 UKEY 等其他身份鉴别手段。 访问控制 建立标记规则，在服务器等实体资产上粘贴属性标签，文档介质类粘贴或打印密级等标记，对于电子数据使用文件名或文件注释进行标记。建立访问控制策略，依据最小原则授予用户权限，操作系统和数据库系统要使用不同的特权用户，对用户权限分配应当定期检查。 严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令；及时删除多余的、过期的帐户，避免共享帐户的存在。 安全审计 由于 开 启操作系统和数据库的审计功能 会影响系统的性能 ， 建议在核心交换安全域配置主机数据库综合审计系统对主机和数据库信息进行审计 入侵防范 通过部署主机防火墙设备或者主机 防病毒软件中的入侵检测模块 监视外来的入侵行为并记录，定期进行系统升级和安全加固。 恶意代码防范 在主机上安装防病毒产品。 资源控制 金税三期工程 架构管控 项目 第 26 页 /共 34 页 Windows 系统通过本地安全策略限制登录 IP， Unix 系统可通过 TCP Wrapper 工具进行访问 IP 限制。使用监控管理软件对服务器的 CPU、硬盘、内存、网络等资源的使用情况进行监视，设置系统资源过低报警的门限值。 6.6. 网 络层安全 6.6.1. 网络结构安全 网络架构的安全性具体表现在： 纳税服务平台设计采用高安全级别的设计理念，按照生产平台的 管理 和 服务 等 功能定位，依照业务种类、服务对象和安全性要求不同 ，划分不同区域层次，每个区域和层次相对独立，相互不干扰。不同分区边缘部署防火墙，区域内部实现统一的安全策略，完成 2到 7 层的安全立体防护体系。 6.6.2. 划分子安全域 1、对纳税服务系统网络结构 通过防火墙、 VLAN、安全设备策略 进行进一步可以化为6 个安全子域分别为：互联网接入安全域、对外公共服务安全域（ DMZ）、认证服务安全域、纳税服务系统交换安全域、 纳税服务系统数据库安全域、纳税服务系统管理安全域， 2、对纳税服务系统数据安全域和纳税服务系统 DMZ 安全域进行进一步细化，将安全域落实在具体的业务系统上，各安全域之间采用 VLAN 实现边界隔离和访问控制。具体如下： 安全域 描述 纳税服务系统 web/APP安全域 主要包括纳税服务系统门 户网站、网络发票和渠道 等子系统。 SSL VPN 安全域 为远程办公人员提供安全访问内网的区域 网络发票数据安全域 网络发票数据库所在区域 渠道 数据安全域 渠道 票数据库所在区域 6.6.3. 网络访问控制 通过防火墙和 VLAN 对总局纳 税服务系统划分的各个安全域进行访问控制。总局纳税服务系统的防火墙配置： 金税三期工程 架构管控 项目 第 27 页 /共 34 页 总局纳税服务系统接入区配置 2 台万兆防火墙，限制来自外界的风险。 在纳税服务系统数据库区前配置 2 台千兆防火墙，以保护纳税服务系统数据的安全。 Web/APP 安全域根据服务器的性质，利用交换机划分出多个 VLAN 利用 ACL 进行访问控制。利用 LVAN 实现认证纳税服务系统和纳税服务系统管理区的访问控制。 6.6.4. 恶意代码防范 在纳税服务系统接入区部署两台防病毒网关，部署两台抗 DDOS 系统（设备），对流量进行清洗和病毒过滤， 在纳税服务系统的服务器部署网络 防病毒软件和互联网（纳税服务系统）接入区的防病毒网关，抗 DDOS 系统共同组成 三层病毒扫描架构的立体网络防病毒体系。 6.6.5. 网络 安全审计 在纳税服务系统的 web 服务器区部署一台网络审计，对访问 Web 区域的网络行为进行审计。 另外，搭建专门的日志服务器，将网络设备、安全设备等产生的日志进行存储和审计。 6.6.6. 边界完整性检查 利用非法外联监控和非法内接监控设备来进行网络边界完整性检查。对于非法内联，应能够对非授权设备私自联到内部网络的行为进行检查，准确定出位置，并对其进行有效阻断。对于非法外连，应能够对内部网络用户私自联到 （ 比如拨号连接） 外部网络的行为进行检查，准确定出位置，并对其进行有效阻断。 6.6.7. 入侵防范 在纳税服务系统 web/APP 安全域接口交换机上配置 1 台千兆 IDS，监视互联网引入的安全威胁；在数据库区部署 1 台 IDS，监视该区域的安全威胁。 金税三期工程 架构管控 项目 第 28 页 /共 34 页 6.6.8. 网络设备安全防范 重要的网络设备可以使用两种或两种以上组合的鉴别技术来进行身份鉴别，如密码、令牌、生物识别技术等；对与 核心 的网络设备建议不使用网络登录或者限制登录终端，网络登录要使用加密方式以防止窃听。 6.7. 物理层安全 总保证计算环境能满足相应的机房场地选择要求、机房防火、供配电、空调降温 、防水与防潮、防静电、接地与防雷击等要求，并对通信线路进行安全防护，保证设备的防盗和防毁及安全可用，以及保证记录介质安全。 金税三期工程 架构管控 项目 第 29 页 /共 34 页 第 7章 部署约束 从整体上来看，纳税服务系统分为总局和省局两级部署： 其中 总局包括 网络、短信、电话 和 纳税服务应用支撑 ； 省局 主要 包括 省局自建的 网络 渠道及 12366。 总局和省局逻辑部署示意图如下： 短信渠道电话 渠道网络 渠道 网络 渠道数据库省 局 网络 渠道 网络数据库省 局 1 2 3 6 6 金税三期工程 架构管控 项目 第 30 页 /共 34 页 第 8章 架构管控约束 金税三期工程实施阶段的架构管控具有重要的意义：它确保所有项目的架构设计对总体架构的遵从和符合，最终保障工程整体架构的一致性。 架构管控只针对架构设计，不管理项目的业务需求、进度质 量。架构管控内容包括前面各章所述的规划要求。 在项目实施过程中，我们将架构管控工作分为五个阶段： 1. 项目启动阶段：管控组协助项目组，编制项目的架构管控计划，对管控的关键时间点、内容、方式、参与人员等进行审查。 2. 需求分析阶段：管控组 对项目涉及的架构规划内容提供资料，或进行培训。 3. 架构设计阶段： 管控组派驻管控人员进入项目组；项目组可以提出架构需求中涉及的问题，管控组予以协助；管控人员可以参与项目架构设计，以全程把控；管控组根据计划，在项目实施关键时间点，对项目执行架构遵循审核，如果没有通过审核，将不允许进入下 一阶段；项目组应开放开发配置库，以便管控组抽查。 4. 开发测试阶段 ： 管控 组支持金税三期工程完成应用系统的集成测试。 5. 运行验收阶段：管控组参与项目验收，就开发商的架构遵循度提出评估意见，对项目的验收产生决定性的影响。 在项目实施过程中，管控组将依照架构管控流程进行规范管理。该流程对项目设计的架构进行遵循度评审，确保项目对总体架构规划及标准等的一致性。 架构管控流程的主要环节如下： 制定管控计划 在某一具体项目的初始阶段，项目组的架构师和派驻项目组的架构组管控人员，需要先根据项目里程碑计划，制定架构管控计划。计划的 描述要素包括：架构管控的阶段名称、开始时间、完成时间、关键工作、参与人员和交付物。 架构管控计划需要提交至项目管理组和总体架构组来进行审核，审核通过的计划需要提交工程办正式批准。 管控计划跟踪 在架构管控计划审批后，总体架构组派专人进驻项目，负责日常化和计划性相结合的持续跟踪、监控；重点关注架构设计的偏差、风险、问题和产生上述情况的原因，并上报金税三期工程 架构管控 项目 第 31 页 /共 34 页 工程办。 项目按计划执行过程中，在每周召开的项目例会上，项目组长要了解架构管控工作情况以及存在的问题，对存在问题分析是否需要总体架构组协助解决，并明确解决方案和责任人 。项目例会要保留会议纪要；重大架构问题和变更需要报送工程办决策。 架构审核 架构组根据管控计划，针对特定的项目从架构、标准等方面进行阶段性审核，揭示项目存在的架构风险和问题；或针对特定的架构问题事件，进行深入调查，分析问题的根本原因。架构审核结束后需按要求提交架构审核报告。 在架构管控流程中，项目组的相关职责如下：负责项目架构管控计划的编写；负责项目架构管控计划的执行；负责项目架构管控计划的变更执行。同时，项目组的架构师应负责项目架构设