xx项目技术需求说明书.docx
《xx项目技术需求说明书.docx》由会员分享，可在线阅读，更多相关《xx项目技术需求说明书.docx（12页珍藏版）》请在冰豆网上搜索。
xx项目技术需求说明书
项目编号：
KF2016001
XX项目
业务需求说明书
V1.0
XX银行XX分行
XX项目组
2016年5月
修订文档历史记录
编号
版本号
修订内容简述
修订日期
作者
审核
本文档中所包含的信息属于机密信息，如无XX公司的书面许可，任何人都无权复制或利用。
1引言
1.1目的
本文档用于描述系统的各项功能优化需求，旨在为项目成员详细说明项目需要完成的功能，为后续的设计和开发提供基础和依据。
1.2项目背景及目标
●项目名称：
●项目提出部门：
●使用部门：
●项目背景及目标概述
1.3业务术语
本文中用到的专门术语的定义。
1.4参考资料
本文中引用的参考资料和文件。
2业务系统的总体描述
2.1系统描述
描述项目的功能，使用范围等
2.2与其它业务系统关系
描述与其它系统业务、数据、调用等方面的关系，及其影响等
3性能需求
{如系统容量，响应速度，处理能力，如交易高峰时系统吞吐量、联机交易处理时间、日终处理时间、批处理时间、数据备份和恢复时间、前后台文件传输处理时间等}
4安全需求
（参照如下内容裁剪后进行相应说明）
4.1访问控制
访问控制部分说明软件自身在用户识别和授权方面的具体要求，明确软件访问控制应具备的基本要素。
4.1.1用户管理
用户必须按类型和角色分类管理，至少分成系统维护人员、业务操作员以及软件服务对象三类。
用户身份管理要求，软件应提供相应的用户身份帐户管理机制，包括提供用户身份帐户的创建、注销、冻结/解冻、修改、查询等功能。
4.1.2用户认证
4.1.2.1口令管理
软件必须对用户的口令属性（口令长度、试探次数、口令生命期）有基本要求；
软件应该提供强制用户定期更新口令机制；
软件应具备口令保护机制。
4.1.2.2认证限制
提供限制用户的登录时间和IP地址的机制；
软件应该提供弱口令检测和警示机制。
4.1.3用户授权
应定义用户访问数据授权关系，针对不同类型用户或角色分别建立最小数据访问列表，对用户访问何种数据进行明确定义和控制。
4.1.4会话控制
对有关用户管理、认证和授权数据的会话进行加密保护。
对于会话残留信息，必须及时清理。
4.2数据保护
数据保护部分说明如何在对数据分类的基础上，选择适当的技术措施进行数据安全保护。
4.2.1重点保护数据
根据业务安全规定，重要数据要求特别保护，该类数据的传输、存取和存储，必需采取加密措施保护，仅能通过内置的软硬件加解密模块进行管制。
需要加密保护的数据可根据数据的作用、传输的环境以及外泄可能性等方面进行考虑。
需要保护第三方维护时可能接触到的数据。
4.2.2数据完整性
对于互联网和外联环境，软件应考虑对传输的数据采用必要的技术来验证数据包是否被篡改。
4.2.3加密技术及服务
各软件使用的加密服务应优先采用中国建设银行安全加密平台，各软件不应重复开发已有的加密算法。
需要重点加密保护的数据在应用层面进行传输时，应实现点到点的加密数据传输。
用于两点之间信息传输加/解密的密钥，不应被非可信的第三方获悉。
4.2.4密钥管理
用于数据、信息传输加/解密的密钥，必须设定有效期，不应采用固定密钥。
密钥采用强口令标准。
对含有私钥信息的数字证书应存放在加密机、加密IC卡或者USBKey等硬件设备中，在能够保障主机系统安全的情况下，数字证书可以PKCS#12文件方式保存，并应有强口令保护。
4.3编码安全
编码安全强调何种编码行为是要严格遵守，何种编码方式具有高隐患应予禁止，进而说明如何建立一种安全的软件编码机制。
使代码简单、最小化和易于修改，避免高危的服务、协议，数据和代码分离。
4.3.1设计和编码要求
4.3.1.1统一的安全规范
每个软件项目在设计阶段都应明确，在项目实施过程中项目组应该遵循的统一规范：
具体包括命名规则、API引用、错误处理、避免使用全局变量等。
4.3.1.2模块划分
软件应该按照安全性划分模块，审计和访问控制模块为安全可信模块，其它模块为不可信任模块。
只有安全可信模块，才能以高安全等级访问系统的敏感信息，对于其他模块限制其访问敏感信息。
4.3.1.3最小功能性
根据“没有明确允许的就默认禁止”的原则，软件应只包含那些为达到某个目标而确实需要的功能，不应包含只是在将来某个时间需要但需求说明书中没有包括的功能。
4.3.1.4对多任务、多进程加以关注
软件开发应尽量使用单任务的程序。
如果软件需要使用多任务和多进程，应该认真分析研究多任务和多进程不会发生冲突，同步所有的进程和任务以避免冲突。
同时作为结构化的编程，每个原子化组件都要保证一个入口和一个出口。
4.3.1.5界面输出最小化
软件必须保持用户界面只提供必须的功能，没有旁路，确保用户不能通过用户界面直接访问数据或者直接访问被保护对象。
4.3.1.6使代码简单、最小化和易于修改
开发时应尽量使代码简单、最小化和易于修改。
使用结构化的编程语言，避免使用递归和Goto声明。
使用简单的代码，清除不必要的功能，防止采用信息隐藏方式进行数据保护。
4.3.1.7避免高危的服务、协议
软件应禁止使用FTP，SMTP等高危方式传输文件。
4.3.1.8数据和代码分离
软件应该把数据与程序放置在不同的目录中，这里的数据包括远程下载文件
4.3.1.9重点数据传输
软件在传输重点保护数据时，应该对重点保护数据进行加密后再传输，也可使用SSL/TLS等安全、可信任协议进行加密传输。
同时可以应用HASH值等来确保数据完整性，使用数字签名来保证不可否认性。
4.3.1.10禁止赋予用户进程特权
对于软件的普通用户进程，禁止赋予该类进程特权用户权限。
特权用户类型包括：
超级用户、直接操作数据库用户、安全管理用户。
4.3.1.11使用适当的数据类型
应该小心使用数据类型，特别是在程序接口部分。
例如，在一些编程语言中signed和unsigned的数据类型是视为不同的（如C或者C++语言）。
4.3.1.12使用经过验证的安全代码
使用经过验证的安全代码模块和外部源程序，防止潜在的安全风险。
4.3.1.13使用应用中间件
中间件作为一种应用层架构，软件设计应尽可能使用中间件，要在总行选型的产品目录中选择所需的中间件。
4.3.1.14设计错误、异常处理机制
软件设计开发时应建立防止系统死锁的机制，异常情况的处理和恢复机制：
具体包括错误和异常检测、交易回滚、安全错误通知、错误和异常记录、断点保护等。
4.3.1.15提供备份机制
为保证运行数据的完整性和可用性，软件开发必须设计有效的备份策略，根据业务和系统维护需要提供定期或不定期、自动或者手动方式的备份机制。
4.3.2保护机密性要求
4.3.2.1关注应用的对象重用
对于底层系统的对象可重用性来说，应用软件需要提供对敏感的数据使用后马上覆盖的能力，这些敏感数据包括口令、安全密钥、会话密钥或者其它的高度敏感的数据。
4.3.2.2用户访问控制信息的机密性
禁止在程序代码中直接写用户名和口令等用户访问控制信息。
4.3.2.3不要在客户端存放重点保护数据
由于客户端是不可信任的，软件不要在客户端存放重点保护数据。
特别注意在使用Cookie时不要把客户重要信息储存在客户端。
4.3.2.4避免内存溢出
在对缓存区填充数据时必须进行边界检查，判断是否超出分配的空间；
对于数据库查询操作，如果查询返回的结果较多时，必须设计成分次提取；
应保证系统资源及时释放和服务连接的及时关闭；
软件程序必须检查每次内存分配是否失败；
4.3.2.5输入保护
软件必须对每次用户输入的信息长度进行检查，判断是否超出范围。
软件必须检查用户输入的内容是一个有效的数据串，而不是其它类型的对象。
检验输入数据串是否与预先定义的格式和语法一致，并完成适当的规范性检查。
软件必须对输入信息中的特殊字符（如“>”、“<”等）进行检查、处理。
软件应该采取措施保护会话，防止会话超时和会话劫持等漏洞。
应该采取措施对HTTP报文头进行检查，防止浏览器到服务端被恶意修改。
对输入的数据串进行检查，避免在输入中直接注入SQL语句。
对URL和路径名称进行检查，确定当中没有包含指向恶意代码的内容，防止攻击者利用URL的扩展进行复位向，注入等攻击。
4.3.2.6输出保护
软件应该限制返回给客户与业务办理无关的信息，防止把重点保护数据返回给不信任的用户，避免信息外泄。
检查输出是否含有非必要的信息。
检查输出是否含有不符合业务管理规定的信息。
软件还应该有错误信息保护机制，禁止将供软件维护人员使用的系统错误诊断信息提交给软件服务对象。
4.3.2.7可配置数据保护
限制非应用软件用户访问可配置数据。
4.4安全日志
日志管理部分主要从可审计角度来考虑，明确软件应记录的行为内容、记录格式以及对日志的管理办法。
4.4.1安全日志的内容
4.4.2安全日志禁止记录的内容
4.4.3安全日志的格式规范
4.4.4安安全日志的保存与归档
4.5部署准备
4.5.1清理调试信息
上线部署前必须将代码中的调试信息进行清理。
不能将带有调试选项的代码部署到生产系统中。
4.5.2清理WEB源代码注释
上线部署前必须清理html等web程序源代码中出现的与软件设计、Web服务器环境、文件系统结构相关的所有的参考和注释；这些信息包括但不限于：
（1）目录结构；
（2）Web根目录的位置；
（3）调试信息；
（4）Cookie结构；
（5）开发中涉及到的问题；
（6）开发者的姓名、email地址、电话号码等；
4.5.3清理不需要的代码
上线部署前必须清理软件程序代码中不需要的代码和那些不能完成任何功能的代码。
4.5.4网络服务管理
服务器必须对提供的服务端口进行控制。
要求在需求分析中明确说明本系统必须开放的网络服务。
在实际运行环境中必须严格按照需求中的要求实施、部署。
4.6开发环境管理
4.6.1开发环境的软件版本控制及变更
开发环境中使用的软件工具必须有版本控制：
（1）在安全需求中要求考虑开发环境变更对软件开发的影响。
开发环境变更后视变更情况对已发布的软件版本重新测试。
（2）软件开发所使用的操作系统、通信软件、数据库等必须是正式版本软件。
4.6.2开发环境安全管理软件防护
开发环境中的开发用机必须安装中国建设银行要求的相关安全管理软件。
Windows平台的开发用机要求及时进行系统及中间件补丁升级和漏洞修复。
开发用机必须安装中国建设银行规定的防病毒软件，并保持升级至最新的病毒定义码，及时增补安全补丁程序。
4.6.3第三方交付物的安全使用
第三方交付物使用前必须进行安全扫描，利用软件安全测试工具等方法检查第三方交付物是否存在安全隐患。
在确认不存在病毒、安全漏洞、可疑源码等安全问题后，方可投入使用。
4.6.4开发环境用户权限管理
应该加强对开发环境用户权限的限制，禁止在开发环境使用超级用户或者其它特权用户进行软件开发。
4.6.5运行环境的完整性保护
软件必须对运行环境进行完整性保护。
软件程序不能篡改或被利用来改变软件所运行的环境或平台中任何安全配置、安全文件和安全程序。
具体包括但不限于：
安全审计日志、监控记录、安全程序、访问控制策略、地址或服务列表、中间件等。
4.6.6其它软件资源的完整性
软件必须对其它软件资源进行完整性保护。
要求软件程序在XX的条件下，不能修改任何其它系统的文件、程序、数据。
5运行维护需求
（参照如下内容裁剪后进行相应说明）
5.1可操作性
系统须具有可维护性，提供系统维护的功能界面，系统应该具有运行状态监控（系统、应用、网络）功能。
应包括应用软件参数配置维护、应用通讯系统参数配置维护、应用系统的启/停操作、非正常数据修改、运行环境完整性检查和应用日志的管理等。
系统需提供终止问题交易等故障隔离的手段和功能，有效防止故障范围扩大。
数据维护功能应具有清晰、简单的人机交互界面，并能对数据维护过程进行安全审计。
5.2数据备份与清理
数据备份内容包括：
数据库、逻辑日志、运行日志、错误日志、应用系统技术参数、应用数据文本等。
有日常备份，日终备份或定期备份功能
数据清理：
提供对数据（包括数据库历史表、临时表、日志文件等）的清理功能，根据不同的数据清理原则设计相应合理的清理策略。
系统定期自动进行清理，释放硬盘空间。
数据恢复：
系统恢复能快速，数据基本完善，部分无法恢复数据可以进行人工补录。
5.3日志管理
描述日志的备份与清理的要求。
系统日志管理维护功能应能根据不同需求提供各种详细程度适当的日志信息。
日志信息种类应包括业务运行日志、系统运行日志、错误日志等。
业务运行日志应记录关键功能的处理痕迹；系统运行日志应记录系统启、停的详细信息；错误日志应记录应用系统所有异常情况的出错信息，出错信息要有准确的故障定位（如提供错误代码、出错程序的精确定位等），日志的备份与清理。
升级会员 