应用系统设计之安全性原则

由于银行应用系统中涉及资金、客户信息等重要、敏感的数据，应用系统始终面临着外部和内部攻击的威胁，为此需要采取有效的手段确保应用系统安全。

一、访问控制安全

（一）“严禁”原则

严禁使用明文或在程序/脚本文件中写死密码，应用系统中涉及的任何密码，均严禁使用明文，并严禁将密码写在代码/脚本文件中。严禁在网页源码中暴露应用处理逻辑，严禁在网页源代码中出现类似SQL、脚本、条件判断等应用处理逻辑。

严禁在超链接中出现参数信息，严禁基于Web的应用将数据库连接用户、密码等重要参数信息放在超链接中，超链接中参数信息、服务调用信息应进行变形（乱码）或者隐藏，以防止SQL注入攻击，避免黑客猜测数据库表结构、数据库连接用户和密码。严禁应用系统设计留有“后门”，严禁以维护、技术支持或者特殊操作为由，设计违反或者绕过安全规则的任何类型的入口和设计文档中未说明的任何模式的隐藏入口。

（二）必须原则

身份识别是信息安全服务的基础，基本原则是要做到用户区分的唯一性，认证是基于身份识别的，身份识别最常见的形式就是用户ID，与密码组合标识一个用户身份。

密码分为交易密码和用户登录密码等。应用系统应对交易密码的全部使用环节进行硬加密，包括密码的产生、密码录入、密码修改、密码的传输、密码的保存。应用系统应支持联机密钥修改，避免加密设备密钥变更对应用系统正常运行的影响。

应用系统应对系统的使用用户密码进行加密（可以是软加密），包括密码的产生、密码录入、密码修改、密码的传输、密码的保存。软加密时应确保软加密算法具有足够的强度，并且确保密钥存储安全，对密钥的访问应严格控制。同时，还应采取必要的措施，确保软加密算法的安全。

必须保证密码安全传递，应用系统应建立完善的密码传递机制，如采用硬件转加密、密码信封等方式，确保密码在系统和使用用户（人）之间的安全传递。

应用系统必须设计密码强度检查机制，密码错误次数限制等措施，避免用户使用简单密码，防止黑客对密码进行暴力破解。，必须提供用户账户锁定功能，当用户帐户几次登录尝试失败后，必须禁用该帐户并将事件写入日志。同时必须提供用户帐户解锁功能。必须在设计阶段将这些策略明确下来。

必须支持密码有效期，密码不应固定不变。作为常规密码维护的一部分，通过设置密码有效期强制应用系统用户对密码进行定期更改。在应用程序设计阶段，必须考虑提供这种类型的功能。，必须对前端输入信息进行验证

将输入验证策略作为应用程序设计的核心要素。应假定所有的输入都是恶意的，不要依赖于客户端的验证，虽然使用客户端验证可以减少客户端和服务器之间的信息传递次数。

要做到限制、拒绝或者净化输入，输入验证的首选方法是从开始就限制允许输入的内容。按照已知的有效类型、模式和范围验证数据要比通过查找已知有害字符的数据验证方法容易。设计应用程序时，应了解应用程序需要输入什么内容。与潜在的恶意输入相比，有效数据的范围通常是更为有限的集合。为了使防御更为彻底，可能还需要拒绝已知的有害输入，达到净化输入的效果。

（三）尽可能原则

尽可能实现用户的权限最小化，应用用户的权限最小化，控制应用用户对文件、数据的访问，记录并统计登录历史；对重要信息资源设置敏感标记并控制对设置敏感标记资源的操作。

二、运行安全

（一）“严禁”原则

为方便使用，无论是软件还是硬件，都存在缺省配置参数，比如访问权限、网络服务端口号、用户ID及密码等。如果在系统上线前不对缺省配置进行修改或者禁止，就会遗留安全隐患。为此，应用系统上线前，必须调整、修改系统缺省配置，尤其诸如用户ID、密码等涉及系统安全的缺省参数。

（二）“必须”原则

应用系统必须关闭所有未用网络端口，尤其要关闭能够远程控制系统的网络端口，如Windows远程桌面管理端口。以防止黑客利用系统应用缺陷，通过网络端口攻击、渗透。

应用系统交付前必须进行信息安全评估，信息系统安全已经是银行面临的重大问题，监管部门对信息系统安全问题是零容忍。信息系统安全包括对外安全和对内安全。所谓对外安全是能够有效避免来自互联网等外部系统的攻击、渗透；所谓对内安全是指能够有效避免来自银行内部的攻击，包括运维人员的违法、违规、违章操作等。

应用系统在交付时，必须提交对信息系统安全的评估报告，说明系统采取了哪些安全措施，经过了何种安全测试及结果；说明系统还存在哪些安全隐患；说明在运维时还需执行何种安全防护措施；等等。必须假设外部系统是不安全的，如果需要从一个不能完全控制的系统接收数据，则接收到的任何数据都应该被认为是不安全的。当接收用户输入的时候，这一点尤其重要。用户是从用户界面或应用程序客户端执行命令的，许多攻击者都是利用服务端缺陷，通过绕过客户端，将有恶意的数据发送给服务器。

“缓冲区溢出”是一个众所周知的安全问题，其根本原因是向一个内存空间（可能是栈，也可能是堆）复制比内存空间大的数据量。包括静态缓冲区溢出、堆溢出、数组索引越界、格式化字符串缺陷、Unicode和ANSI的缓冲区大小不匹配等多种情况。通常这些情况是在用像C/C++这样可以灵活操纵内存的语言编写程序造成的。必须严格检查这类程序代码，消除“缓冲区溢出”隐患。

（三）“尽可能”原则

尽可能具有防木马程序设计，应用系统尽可能设计必要的措施防止木马程序对密码的截取。，尽可能使用成熟稳定版本的软件或者工具，软件产品或者工具升级换代非常的迅速，虽然新的版本会带来很多功能上的提升，但是也可能隐藏着新的缺陷。所以尽可能在功能满足的情况下使用经过验证的成熟稳定的版本。

尽可能保证关键信息安全传递，应用系统尽可能完善各种关键信息（例如：磁道信息、卡片校验码、制卡文件等）传递机制，如采用硬件转加密、密码信封等方式，确保关键信息在系统和使用用户（人）之间的安全传递。尽可能提供安全审计功能，在应用系统中发生的各种与安全相关的事件，应尽可能记录下来。审计记录应包括安全事件的主体、客体、时间、事件类型、事件内容、事件结果等内容。应提供审计记录查询、分类、分析和存储保护；能对特定安全事件进行报警；确保审计记录不被破坏或非授权访问。应为安全管理中心提供接口；对不能由系统独立处理的安全事件，提供由授权主体调用的接口。并提供审计功能的启动和关闭功能。