电信级IT系统技术要求.doc

1 数据一致性要求CRM和BOSS解耦后，业务运营支撑系统与业务平台间交互更加复杂，数据跨系统分布情况凸显，大量关键数据分别存储在两个或多个系统中，数据入口和出口不一致，多系统同时对数据进行操作，增加数据不一致风险。为此，数据一致性管理提出了如下建设目标：1、 确保跨系统分布的数据在CRM、BOSS及相关网元间的一致性。2、 确保跨系统业务流程在CRM、BOSS及相关网元间的业务一致性。3、 根据数据的业务特性，采用适当手段，提升数据同步的实时性。本规范通过对CRM、BOSS及相关网元间的数据分布和数据交互关系的分析，对不同情况产生的数据差异问题，采用不同的数据一致性保障手段，对数据一致性保障手段定义、适用范围等进行阐述，并对实现原则等提出明确技术要求。1.1 数据一致性原则数据一致性管理是针对CRM、BOSS系统及相关网元间存在的数据差异问题采取的技术和管理手段。CRM、BOSS及相关网元间的数据一致性通过业务完整性和数据稽核与同步等手段保证。不同阶段产生的数据一致性问题，应采用不同保障手段，从事前、事中、事后三方面考虑。事前数据一致性主要通过优化设计的手段保证，并遵循如下保障原则：1、 合理的数据分布设计，是指在实施CRM和BOSS的过程中，充分考虑到跨系统流程和跨系统数据分布对系统造成的影响，合理分布数据，尽量避免不必要的数据复制和同步，避免冗余数据，尽量在一个平台存储和管理数据。2、 合理的跨系统流程设计，是指在满足业务需求的基础上，尽量避免采用同步的通讯机制和不可靠的传输机制。3、 合理的应用分布，是指充分考虑冗余、复用机制，合理采用多进程、多线程，提高数据处理的实时性。4、 合理的同步策略，对于在多个平台存储同一数据的情况，应尽量考虑以其中的一个平台作为标准进行同步。事中数据一致性主要通过业务完整性相关手段进行保障；事后数据一致性通过订单数据 稽核、数据稽核与同步等方式实施保证。下面章节将对事中、事后一致性保障手段做详细介绍。1.2 业务完整性要求业务完整性是保障业务正常流转的一种手段。由于存在跨系统的业务流程，任何一个环节的错误都可能导致业务办理的失败，导致用户的满意度下降。因此，必然要有一定的手段和流程设计来保证业务完整性。业务完整性通过全局事务控制、回退机制和重发机制三种技术手段实现。1、全局事务控制全局事务是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务。例如，一个客户开户的事务中可能更新CRM、BOSS等几个不同的数据库，对这些数据库的操作发生在系统的各处，但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。在一分布事务环境中，全局事务交易由中间件通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交。全局事务控制由数据库和中间件配合保证事务的一致性，应用程序的逻辑相对简单。但是对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。2、回退机制回退机制提供CRM、BOSS未完成事务的撤销操作，是对事务完整性的一个补充手段，保证了系统间交易结果的一致性，是保障异步传输机制的重要手段。用于通知接收方先前交易未按预定流程完成，应取消处理结果。回退机制解决了多个节点之间交易的一致性问题，可分为自动回退和手动回退。在回退机制中应能满足如下要求：(1) 提供单笔或批量回退操作。(2) 保证回退数据的正确性。(3) 回退逻辑应避免隔单处理。 3、重发机制重发机制是一种前向纠错的手段，用于保证业务处理流程完整性。一般会采取自动请求的方式。重发机制是和回退机制完全相反的操作，保证后端流程的正常进行。例如：发起方提交工单失败后，能将失败工单存储起来，在一定时间内自动将工单再次提交，也要支持人工处理，用于保证业务处理流程完整性。重发机制多用在异步处理方式，支持重发次数、重发间隔时间的可配置，如服务开通工单重处理。2 备份性能指标数据备份是指用特殊的备份软件，能够在不影响正常业务运营的前提下将BOSS系统涉及的各种数据（包括数据库和文件系统中的数据）备份到备份设备上的过程。数据备份须符合不能影响正常业务运营的原则。数据备份包括全量备份和增量备份。2.1 全量备份性能指标指标项要求数据（不含服务使用记录和详单）备份周期= 7天服务使用记录和详单数据备份周期= 1个月备份完成时间= 12个月原始服务使用记录要求在线保存时间= 3个月原始服务使用记录要求离线保存时间= 6个月详单记录要求在线保存时间= 6个月详单记录要求离线保存时间= 36个月异常服务使用记录要求在线保存时间= 3个月异常服务使用记录要求离线保存时间= 12个月结算数据（包括漫游结算和网间结算）要求在线保存时间= 4个月结算数据（包括漫游结算和网间结算）要求离线保存时间= 12个月全量备份性能指标表指标项说明：(1) 数据（不含服务使用记录和详单）备份周期：这里的数据是指不包括原始话单和详单的各种BOSS系统数据，包括但不局限于用户信息、订购信息、各种局数据信息、用户帐单信息和累积量信息等。备份周期是指相邻两次备份操作启动时间的间隔。(2) 服务使用记录和详单数据备份周期：服务使用记录是指数据库详单和原始话单文件记录。备份周期是指相邻两次备份操作启动时间的间隔。(3) 备份完成时间：是指从备份启动到备份完成所需要的时间。(4) 备份数据保持周期：是指备份生成的数据从生成到删除的时间间隔。(5) 原始服务使用记录要求在线保存时间：原始服务使用记录是指采集到的原始话单；在线保存是指在BOSS主机文件系统上进行保存。(6) 原始服务使用记录要求离线保存时间：原始服务使用记录是指采集到的原始话单；离线保存是指在磁带等外部存储上进行保存。(7) 详单记录要求在线保存时间：详单记录是指经过BOSS系统处理在数据库中进行保存的清单记录；在线保存是指在BOSS主机文件系统上进行保存。(8) 详单记录要求离线保存时间：详单记录是指经过BOSS系统处理在数据库中进行保存的清单记录；离线保存是指在磁带等外部存储上进行保存。(9) 异常服务使用记录要求在线保存时间：异常服务使用记录是指BOSS系统无法正常处理的话单记录；在线保存是指在BOSS主机文件系统上进行保存。(10) 异常服务使用记录要求离线保存时间：异常服务使用记录是指BOSS系统无法正常处理的话单记录；离线保存是指在磁带等外部存储上进行保存。(11) 结算数据（包括漫游结算和网间结算）要求在线保存时间：结算数据是指BOSS处理的用于网间和漫游结算的详单记录；在线保存是指在BOSS主机文件系统上进行保存。(12) 结算数据（包括漫游结算和网间结算）要求离线保存时间：结算数据是指BOSS处理的用于网间和漫游结算的详单记录；离线保存是指在磁带等外部存储上进行保存。2.2 增量备份性能指标指标项要求数据（含服务使用记录）备份周期= 1天 备份完成时间= 1个月增量备份性能指标表指标项说明：(1) 数据（含服务使用记录）备份周期：是指BOSS系统数据库和文件系统中涉及的全部数据。备份周期是指相邻两次备份操作启动时间的间隔。(2) 备份完成时间：是指从备份启动到备份完成所需要的时间。(3) 备份数据保持周期：是指备份生成的数据从生成到删除的时间间隔。3 业务连续性要求业务连续性是指业务运营支撑系统应对风险具有自动调整和快速反应的能力，以保证业务的连续运转。现有BOSS通过容灾系统的建设，提高了业务连续性的能力，但在CRM系统和BOSS解耦后出现了以下新问题，对业务连续性提出了新的挑战：1、 新增大量跨系统流程及长流程，系统间依赖关系增大，导致系统稳定性下降。2、 数据的跨系统分布，增加数据不一致的风险，导致业务失败。3、 CRM系统与BOSS的处理性能不匹配，造成系统瓶颈，导致系统性能下降甚至业务中断等。4、 为此，必须对CRM系统和BOSS的业务连续性提出更高的要求，为系统持续可靠运行提供保障。本章节通过对业务连续性的风险分析和业务影响分析，明确相关业务的RTO和RPO指标要求；从满足业务连续性要求出发，明确应用设计、IT基础设施规划、日常保障、快速备份恢复、故障恢复、组织保障等方面的相关要求。3.1 业务连续性分析业务连续性分析从风险分析、业务影响分析两个方面对影响业务连续运转的因素进行分析，提出相关业务的RTO和RPO指标要求。3.1.1 风险分析风险是指可能导致系统中止运行、业务中断，并给企业和客户造成重大影响的潜在事件或事故。风险分析的对象通常为“基础设施与技术”、“人为因素”和“不可抗力”三个层面。同时，依据风险的来源又分为内部原因和外部原因，具体如下表所示。基础设施和技术人为因素不可抗力内部员工外部人员气候自然灾害硬件故障技术缺陷电源故障空调损坏消防设施毁坏通讯线路中断跨系统长流程问题系统间处理能力匹配问题数据不一致风险病毒误操作盗窃蓄意破坏粗心或无知辞职情绪波动病毒黑客攻击误操作入室行窃蓄意破坏间谍活动示威活动消防灌水严寒冰雪恶劣气候崩塌雷击龙卷风海啸交通堵塞中断水位过高地震火灾塌方飞行器撞击爆炸火山爆发内部原因外部原因风险类型分类描述表本次规范的关注重点是针对CRM与BOSS解耦在基础设施与技术方面对业务连续性的影响，特别是跨系统长流程问题、系统间处理能力匹配问题、数据不一致风险问题等三个方面，确定业务连续性相关的应用设计，IT基础设施规划，日常保障等要求。3.1.2 业务影响分析本节根据业务中断对客户或企业的影响程度，对CRM系统和BOSS的业务级别进行分类，并提出相应的业务连续性指标要求。1、业务级别分类按照业务中断对客户和企业造成的负面影响程度，将业务分类为三个级别：最关键业务、关键业务和非关键业务。(1) 最关键业务是指客户最敏感的业务，此类业务的中断，将会极大降低客户的满意度，对企业形象造成重大负面影响，如缴费，停开机等。在特殊情况下，如发生地震，雪灾等自然灾害时，应考虑根据客户服务的实际情况对最关键业务的范围进行调整。(2) 关键业务是指业务中断将会对客户感知造成较严重影响的业务，及其所依赖的业务，如开户等。(3) 非关键业务是指由于该业务中断，将会对企业运营和客户感知产生一般或较小影响或基本没有影响的业务。如综合结算、合作伙伴管理等业务。根据以上的业务级别分类标准，CRM系统和BOSS业务级别分类如下：系统一级功能二级功能三级功能四级功能业务级别BOSS产品管理产品目录管理非关键产品创建关键产品变更关键产品退出关键配置管理关键发布管理关键版本管理关键BOSS服务开通服务开通定单管理关键工单管理关键开通与激活关键BOSS采集预处理关键BOSS融合计费关键BOSS综合帐务帐务管理缴费管理最关键销帐管理关键帐户资金管理关键帐单管理关键欠费管理关键帐务核算关键发票管理关键帐务处理关键信用管理关键积分管理关键BOSS综合结算非关键BOSS合作伙伴管理非关键BOSS基础管理系统管理操作权限管理关键安全管理非关键操作日志管理非关键系统备份与清理非关键应用运维工具非关键软件版本控制管理非关键系统监控非关键业务局数据管理关键数据一致性管理非关键计费帐务稽核非关键统计报表非关键业务级别分类表2、业务连续性的指标要求业务连续性的指标有两个，即恢复时间目标（RTO）和恢复点目标（RPO）。恢复时间目标（Recovery Time Objective，以下简称RTO）：表示了从灾难发生直到业务流程再次运行（即被恢复）的时间。RTO从低到高分为5个级别，其中1级为最高级别：级别恢复时间要求（1级）2小时内恢复（2级）4小时内恢复（3级）8小时内恢复（4级）1天恢复（5级）可恢复，但无时间要求恢复点目标（Recovery Point Objective，以下简称RPO）：是灾难发生后业务能够容忍的数据丢失量，或者说灾难发生造成的数据丢失量。RPO从低到高分为5个级别，其中1级为最高级别：级别可容忍丢失的数据（1级）无数据损失（2级）30分钟内的数据损失（3级）4小时内的数据损失（4级）8小时内的数据损失（5级）一天之内的数据损失在CRM系统和BOSS中，各业务功能与业务连续性指标的对应关系如表所示。系统一级功能二级功能三级功能四级功能RPO 级别RTO级别BOSS产品管理产品目录管理44产品创建21产品变更21产品退出21配置管理21发布管理21版本管理21BOSS服务开通服务开通类定单管理11工单管理11开通与激活11BOSS采集预处理22BOSS融合计费22BOSS综合帐务帐务管理缴费管理11销帐管理11帐户资金管理11帐单管理33欠费管理11帐务核算22发票管理33帐务处理22信用管理11积分管理22BOSS综合结算44BOSS合作伙伴管理44BOSS基础管理系统管理操作权限管理11安全管理33操作日志管理33系统备份与清理44应用运维管理43软件版本控制管理33系统监控44业务局数据管理22数据一致性管理44计费帐务稽核44统计报表44业务功能与业务连续性指标对应关系表在CRM系统和NG1-BOSS系统实现时，根据此表确定业务连续性保障方式。3.2 业务连续性保障业务连续性保障是指确保业务连续的机制，包括：系统高可用性的规划和设计、运维保障、故障恢复、容灾系统建设、组织保障等方面。3.2.1 高可用性业务应用的高可用性和IT基础设施的高可靠性是实现业务连续性的基础，因此对业务应用的设计和IT基础设施的规划提出如下要求：1、应用设计原则(1) 保证数据的合理分布，数据的一致性以及数据操作事务的完整性。(2) 合理规划和设计跨系统流程，保证流程执行的畅通和完整性。(3) 具备良好的可伸缩性，通过合理配置资源，消除性能不匹配所导致的系统瓶颈。(4) 应用系统接口应具备高可靠性。2、IT基础设施规划原则(1) 网络应规划足够的网络带宽，保证接入设备与链路的冗余备份，以及接口的稳定性。(2) 服务器应保证容错机制、高可用性，支持负载均衡，并预留一定的处理扩展能力。(3) 存储设备应具备内部容错机制和数据保护机制。3.2.2 运维保障在CRM系统的日常运行维护过程中，应采用各种流程、技术手段加大对系统异常的监控和处理，预防系统异常对业务连续性的影响。1、日常保障手段(1) 通过日常系统监控和系统维护，提高系统运行稳定性。(2) 通过数据稽核，实现数据一致性和完整性，保证业务可靠性。(3) 通过软件版本管理等手段，确保应用系统的可靠性。2、通过备份与恢复手段，保证应用和数据的可恢复性。3.2.3 故障恢复系统出现故障导致业务中断后，应通过容灾提供业务恢复，容灾恢复有三个等级，即业务级容灾、应用级容灾和数据级容灾，其关系如图所示。1、 数据级容灾仅能保证数据的完整性，业务恢复时间很长（一般在3天以上）。2、 应用级容灾包含数据级容灾，灾难发生后业务能够比较快速地恢复（一般在一天之内）。3、 业务级容灾包含应用级容灾，是最高层次的容灾，灾难发生后业务几乎不受影响（一般小于30分钟）；由于业务级容灾投资较高，本次规范中的业务级容灾只涵盖最关键业务。容灾层次关系图故障恢复方式包括本地应急接管，异地容灾接管，本地备份恢复。本地应急接管是指通过启用本地应急系统，部分接管生产系统，保证关键业务连续性的方式，适用于业务级容灾。异地容灾接管是指通过启用容灾系统，全面接管生产系统，保证整体业务连续性的方式，适用于应用级容灾。本地备份恢复是指使用本地备份数据恢复生产系统，保证整体业务连续性的方式，适用于数据级容灾。3.2.4 业务连续性保障体系架构1、系统定位业务连续性保障体系由本地应急系统和容灾系统组成，本地应急系统、容灾系统与生产系统相互配合共同保证整体业务连续性。本地应急系统是本地关键业务快速恢复的手段，通过启动本地应急系统可保证关键业务的连续性。容灾系统是建立在异地容灾中心的一套整体生产系统恢复体系，通过启动容灾系统可以全面接管生产系统，实现业务系统连续性。生产系统、本地应急系统和容灾系统三者之间关系如图所示。容灾系统关系图2、系统拓扑结构根据生产系统、本地应急系统和容灾系统三者的定位和关系，落实到容灾系统的实现，网络拓扑示意图如图所示。容灾系统网络拓扑图本地应急系统与生产系统共同布署在生产中心，其处理能力应根据业务需求决定。本地应急系统要求配备独立的服务器、数据库和存储设备等，并与生产系统的服务器、数据库和存储设备等相对隔离。容灾系统布署在远程容灾中心，其与生产系统的结构和部署一致。为了提高设备的利用率和节省投资，在满足业务需求的前提下，容灾系统的性能不作过高要求。在生产中心与容灾中心之间，应具备足够的带宽，以及链路的高可用性和高可靠性，以满足数据同步的要求。容灾系统应具有路由控制和负载均衡功能，以保证系统切换后，外部系统的正常接入访问。3、切换原则当CRM生产系统或NG1-BOSS生产系统发生故障需要切换时，生产系统、本地应急系统、容灾系统三者之间的切换原则如下：(1) 生产系统的最关键业务发生故障而且故障修复时间小于最高级别RTO恢复时间要求的情况下，生产系统应切换到本地应急系统。(2) 生产系统发生故障的其它情况，通过决策、审批后可切换到容灾系统。(3) 生产系统修复后，应从本地应急系统/容灾系统回切回生产系统。(4) 当本地应急系统的持续工作时间大于最高级别RTO恢复时间要求但生产系统故障仍未修复时，应通过决策、审批后从本地应急系统切换到容灾系统。数据的一致性是保证业务连续性和完整性的基础，为了确保正常切换和业务顺利运转，容灾系统数据流向及处理原则如图所示。容灾系统数据流向其中：(1) 在生产系统运行期间，生产系统应同步最关键业务数据到本地应急系统，以保证本地应急系统的数据有效性。(2) 在本地应急系统回切到生产系统时，为保证恢复后的生产系统顺利运转，必须按照本地应急系统上的操作日志，在生产系统上批量地重做业务。(3) 在本地应急系统切换到容灾系统时，也必须按照本地应急系统上的操作日志，在容灾系统上批量地重做业务。(4) 在生产系统运行期间，容灾系统的数据必须同生产系统保持一致，可采用定点复制、连续复制的方式，从生产系统向容灾系统同步数据。(5) 容灾系统回切到生产系统时，必须将容灾系统的数据状态同步到生产系统。3.2.5 组织保障1、人员编制容灾中心与生产中心处于不同局址，包括完整的机房环境、配套设备、系统设备、应用软件等，因此要求人员必须冗余。省公司应配备专职的维护和管理人员，以备发生灾难和重大故障的时候，确保容灾中心系统的可用性并能按照灾难恢复要求的时间完成系统切换。省公司应根据容灾系统的功能和建设的模型，全面衡量容灾中心的工作量，确定容灾中心的人员编制。在进行该组织结构制定时,应根据省公司的具体人事编制来补充扩编。2、组织结构容灾系统的管理组织结构，按照其功能以及灾难恢复和日常管理的流程需求划分，应分别建立省公司领导组、省公司执行组、分公司领导组等，如图所示：容灾系统管理人员组织架构其中：(1) 省公司领导组下设省公司执行组和分公司领导组。(2) 省公司执行组下设系统组、业务组、行政管理组。(3) 系统组和业务组下面设生产中心组和容灾中心组。(4) 分公司领导组下设分公司执行组。每个组都应该指定相关的人员负责。(5) 组长应指定一名组员担任副组长，在组长不能履行其职责期间，副组长代理行使组长职责。3、灾难规划文档灾难恢复规划文档作为最重要的容灾系统文档之一，必须精、准、简，并保证其时效性。确保灾难恢复小组成员及其他相关人员对该文档的正确理解和掌握。其中针对进入灾难状态，上报及通知手段，评估灾难影响范围，恢复业务系统管理及恢复业务系统流程等应最少准备有容灾组织结构职责及通知手册、IT系统映射表、执行组灾难恢复手册、系统组/业务组灾难恢复手册四类文件。4、容灾培训通过容灾培训，可确保：(1) 相关人员及时准确地了解系统结构，熟悉测试、演习、灾难恢复流程。(2) 明确自身职责。(3) 沟通、协作顺畅。(4) 提高各组织人员的工作技能和灾难应对能力。5、相关流程为了保证业务的的连续性，还需要建立行之有效的业务连续性计划、灾难恢复机制和危机应对流程，包括：预警流程、应急切换流程、容灾切换流程、应急回切流程、容灾回切流程、日常管理等等。4 安全要求4.1 网络安全1、网络系统支持入侵检测的功能，对检测到非法行为立即做出响应，响应的方式包括：(1) 记录非法事件过程。(2) 记录日期和时间。(3) 记录事件的源和目标。(4) 报告网络管理员。(5) 重新配置防火墙。(6) 自动终止入侵过程。(7) 发出电子邮件或短信警告。(8) 执行用户指定的操作。(9) 向管理控制台发出警报。2、网络系统支持定期检查安全漏洞，并根据检查的结果更正网络安全漏洞和系统中的错误配置。3、门户系统与外部系统的连接应设置防火墙和接口服务器。(1) 防火墙可采用双机热备份方式。(2) 通过防火墙，拒绝外部非法IP地址的访问。(3) 对网络服务如FTP，HTTP等的使用进行控制。(4) 监视外部网络对内部网络的访问活动，并进行详细的记录。(5) 有效地抵御如IP欺骗攻击、PING攻击、碎片攻击、DoS攻击等多种攻击手段。(6) 有效防止远程用户未经认证登录门户网站。(7) 必须支持动态和静态的内部网与外部网之间的地址转换、映射。(8) 防火墙应具有健全的审计和告警功能。(9) 防火墙应具有网络流量分析的功能。4、必须通过防火墙等措施对进入内部网络的数据包进行扫描过滤，能够根据用户、IP地址、访问类型等方式进行访问规则限制。5、各子网间或远程用户传输中的数据应该进行安全保护，利用加密等方式保证数据不被非法截获，并提供身份认证和授权等功能。4.2 系统安全1、系统应具有多层次的防病毒能力。(1) 支持对各种类型的文件都可以进行病毒的查杀工作，包括对远程子网中的服务器、工作站都可以进行全面的病毒防范。(2) 能够自动进行病毒代码库的更新，保证对发现的病毒能够在全网络范围内进行清除。2、系统应具备访问权限的识别和控制功能，提供多级密码口令或使用硬件密钥等保护措施。(1) 对系统管理员、数据库管理员及其它管理员必须授予不同级别的管理权限。(2) 应限制用户访问主机资源，不同部门或类型的用户访问相应的文件或应用。(3) 对于需要登录系统访问的用户，应通过产品提供的安全策略强制实现用户口令安全规则，如限制口令长度、限定口令修改时间间隔等，保证其身份的合法性。4、应充分保障操作系统的安全性。(1) 操作系统应符合C2级以上安全标准。(2) 提供完整的操作系统监控、报警和故障处理能力。(3) 应定期对文件、帐户、组、口令的配置进行检测。(4) 应定期对可执行程序作完整性检查，以防止被恶意修改。(5) 应能检测操作系统内部是否有木马程序驻留。(6) 能够监控应用程序的运行情况。5、系统应提供完备的日志记录功能，日志至少保留3年。6、系统应具有安全审计功能，审计周期不得少于1个月。4.3 应用系统安全1、 对于用户身份安全应支持门户网站的安全管理，支持多种安全防范手段，包括：基于PKI（公钥）密码体系的认证、动态密码令牌认证、矩阵口令卡认证、一次性手机短信密码认证、软键盘输入等多种方式或多种方式组合。2、 应用系统的用户管理、权限管理应充分利用操作系统和数据库的安全性。应用软件运行时须有完整的日志记录。3、 不允许以明文方式保存用户密码或系统使用的各类密码。4、 为保证安全性，口令不允许以明码的形式显示在输出设备上，应能对口令进行如下限制：最小口令长度、强制修改口令的时间间隔、口令的唯一性、口令过期失效后允许入网的宽限次数。5、 应用系统应支持操作失效时间的配置，当操作员在所配置的时间内没有对界面进行任何操作则该应用自动失效。6、 应用系统应提供完善的审计功能，对系统关键数据的每一次增加、修改和删除都能记录相应的修改时间、操作人和修改前的数据记录。7、 应用程序的源代码不允许放在运行主机上，应另行存放，并具有版本控制能力。8、 各应用软件目录设置及其访问权限应有相应的规范，以保证系统的安全性和可维护性。9、 接口程序连接登录必须进行认证（根据用户名、密码认证）。4.4 服务接口安全门户网站系统与各业务平台通过服务接口相互调用时，需确保调用的安全、可信。Web服务接口、WSRP接口须提供各安全层面的技术支持手段。包括：1、SSL：在门户和业务平台应用之间传递机密数据时，须支持对数据进行加密。提供业内标准的SSL v3，支持HTTP头加密标准、加密cookies和HTTP压缩。2、WS-Security：Web服务也必须在Web容器内得到安全保护。门户网站支持WS-Security，加密关键的Web服务头信息，以实现不可否认的服务请求。4.5 安全管理措施1、 禁止在生产系统中使用未经批准的应用程序，禁止在生产系统上加载无关软件，严禁擅自修改系统的有关参数。2、 用于开发、测试的系统必须与生产系统严格分开。3、 监视系统运行记录，及时审查日志文件，认真分析告警信息，及时掌握运行状况，对系统可能发生的故障做好应急方案。4、 软件程序的修改或增加功能时，须提出修改理由、方案、实施时间，报上级主管部门批准。程序修改后，须在测试系统上进行调试，确认无误经批准后方可投入生产应用。5、 软件修改、升级前后的程序版本须存档备查，软件修改、升级时须有应急补救方案。6、 制定各项访问控制措施，包括对网络、主机、数据库等的访问。对所有路由器、交换机的密码及配置应由网络管理员掌握，统一进行配置。对各类主机的管理和对用户以及文件系统的分配、访问权限设置等工作统一由主机管理员执行。对所有数据库的管理和对表、视图、记录和域的授权工作统一由数据库管理员执行。7、 建立严格的机房安全管理制度。非工作人员未经许可不准进入机房，任何人不准将有关门户网站资料泄密、任意抄录或复制。8、 参照国际安全标准ISO17799来采购信息安全产品和服务，确保采用的安全产品符合中华人民共和国有关信息安全的法律和规范。5 能力要求1、维护性要求维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。系统的可维护性主要有以下几个方面：(1) 应用系统应采用构件化设计思想，系统框架与业务逻辑分离。要求具备开放的体系架构。(2) 应用系统应支持通过统一的图形界面访问系统各构件、接口的版本信息及相应的功能说明。(3) 应用系统每一个功能实现都应在设计与需求文件中跟踪到相应的内容。需求文件中的每一个需求都应能跟踪到该需求所涉及的设计元素及最终的功能实现。(4) 应用系统出现异常错误报告时，必须能够提供详细的异常信息和明确的错误编号，并能在系统的相应维护手册中查到错误处理方法与步骤。(5) 当系统负荷加大时，应在不更改整个系统架构的前提下，确保正常的服务质量。(6) 应用系统必须支持各构件的单独升级，建议实现在线升级功能。应用软件中的任一模块更新、加载时，在不改变与上下模块接口的前提下，应不影响业务运转和服务。2、易用性要求易用性是指在用户或运维人员进行操作过程中，给予的感知能以操作人员所期待的方式进行展现、运行。系统的易用性主要有以下几个方面的要求：(1) 应用系统必须提供统一的图形用户界面风格。(2) 应用系统对普通用户的操作界面应以B/S 方式实现。(3) 应用系统应支持同时打开多个管理窗口以对不同任务进行并行的操作。(4) 应用系统应支持在一个业务过程中的所有功能界面都有返回上一个操作的快捷链接。(5) 应用系统应支持通过键盘即可完成一个界面窗口内的主要操作。(6) 应用系统应支持通过Tab 键或回车键可以访问到同一个窗口的所有控件对象。(7) 应用系统应支持对于常用功能设置快捷键以方便功能间的切换。快捷键的功能定义应在全系统保持一致。(8) 应用系统应采用分页机制显示查询结果，并显示返回的记录数目、当前页和总页数。(9) 应用系统发现用户提交有误信息，应明确提示用户错误的原因，并把界面控制焦点置于发生错误的控件对象上。(10) 应用系统的操作界面应明确标识出必填的输入信息。(11) 在导致系统数据发生变化的操作执行之前，系统应明确提示用户确认。(12) 对于复杂的信息结构，系统应采用分栏的机制在同一个窗口中显示不同的信息内容，并自动刷新不同部分的信息内容。(13) 当应用系统正在执行用户提交的请求而无法返回时，应明确标识系统处于繁忙阶段。(14) 应用系统功能菜单应按照功能域、功能组的分类方法进行组织。(15) 对于操作员无权限使用的菜单功能，应用系统应不显示该菜单或将其设置为不可用状态。(16) 系统应提供在线帮助功能，对于每一个操作功能都能查找到相应的使用说明。(17) 操作员登录系统后，系统应能主动提醒等待该操作员处理的任务。(18) 随系统提交的文档应包括完善的、针对不同级别用户的应用