项目编号：KF2016001XX项目业务需求说明书V1.0XX银行XX分行XX项目组2016年5月修订文档历史记录权复制或利用。

目录1引言 (5)1.1目的 (5)1.2项目背景及目标 (5)1.3业务术语 (5)1.4参考资料 (5)2业务系统的总体描述 (5)2.1系统描述 (5)2.2与其它业务系统关系 (5)3性能需求 (5)4安全需求 (6)4.1访问控制 (6)4.1.1用户管理 (6)4.1.2用户认证 (6)4.1.3用户授权 (6)4.1.4会话控制 (6)4.2数据保护 (7)4.2.1重点保护数据 (7)4.2.2数据完整性 (7)4.2.3加密技术及服务 (7)4.2.4密钥管理 (7)4.3编码安全 (7)4.3.1设计和编码要求 (8)4.3.2保护机密性要求 (9)4.4安全日志 (11)4.4.1安全日志的内容 (11)4.4.2安全日志禁止记录的内容 (11)4.4.3安全日志的格式规范 (11)4.4.4安安全日志的保存与归档 (11)4.5部署准备 (11)4.5.1清理调试信息 (11)4.5.2清理WEB源代码注释 (11)4.5.3清理不需要的代码 (12)4.5.4网络服务管理 (12)4.6开发环境管理 (12)4.6.1开发环境的软件版本控制及变更 (12)4.6.2开发环境安全管理软件防护 (12)4.6.3第三方交付物的安全使用 (12)4.6.4开发环境用户权限管理 (12)4.6.5运行环境的完整性保护 (12)4.6.6其它软件资源的完整性 (13)5运行维护需求 (13)5.1可操作性 (13)5.2数据备份与清理 (13)5.3日志管理 (13)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使代码简单、最小化和易于修改开发时应尽量使代码简单、最小化和易于修改。

使用结构化的编程语言，避免使用递归和Go to声明。

使用简单的代码，清除不必要的功能，防止采用信息隐藏方式进行数据保护。

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清理不需要的代码上线部署前必须清理软件程序代码中不需要的代码和那些不能完成任何功能的代码。