某石油天然气股份公司应用系统开发安全管理通则(编辑修改稿)

某石油天然气股份公司应用系统开发安全管理通则(编辑修改稿)内容摘要：

何用户如果希望访问应用系统中的某一个部分，则必须通过统一的且唯一的认证授权方式以及流程。 人员职责和权限的定义 由于不是所有的人员对于某一个应用系统都具有同样的访问或使用的权限，因此系统必须具有基于人员职责的用户授权管理以确保每个用户可以访问到其权利范围内的应用系统部分。 同样的，也要确保每个用户无法访问其权限范围以外的应用系统部分。 确保敏感系统的安全性 通过将应用系统中敏感的信息保存在服务器端以进行集中的加密的安全管理，确保客户端系统本身并不能存储任何信息敏感的数据。 确保访问层的安全性 应用系统不仅仅要确保系统模块本身的安全性，同时也要考虑模块与模块之间的通讯的安全性。 这种模块与模块之间的安全性不仅仅包括了应用系统内部模块之间的安全，也包括了应用系统内部模块和外部模块之间的安全性，如主机和客户端之间通讯的安全性。 服务器和服务器间通讯的安全性，本地系统和异地系统之间通讯的安全性。 确保日志管理机制健全 要求建立可以根据情况自由设置的日志管理机制，也就是说日志纪录的范围和详细程度可以根据需求自行定制，且可以实现在应用系统使用过程中进行日志的定制和记录。 保留所有系统开发相关 的程序库的更新审核纪录。 新系统的容量规划 容量规划是指确定系统的总体规模，性能和系统弹性。 容量规划的具体内容可能有所不同，但一般需要考虑以下方面： a) 系统的预期存储容量和在给定的周期里面获取生成和存储的数据量。 b) 在线进程的数量和估计可能的占用资料 c) 对于系统和网络的相应时间和性能，即端对端系统 d) 系统弹性要求和设计使用率 峰值，槽值和平均值等 e) 安全措施例如加密解密数据对系统的影响。 f) 24x7 运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须性宕机） 规划容量的时候关于系统使用的信息了解得越多越好。 近来 ，由于互联网站得使用以指数形式增长，容量规划变动效果不是非常显著，有时甚至毫无用处。 原因在于很难估计实际的负载。 在容量估计的时候需要尽量将情况设想得复杂一些。 错误 !文档中没有指定样式的文字。 14 系统开发阶段安全规范 系统开发语言安全规范 程序员可以使用很多指导规范来防止应用程序中的普通的安全问题。 其中许多可以应用于任何一个编程语言，但某些是针对特定的语言的。 特定语言的指导规范主要集中在 Perl， Java 和 C/C++语言。 大多数情况下，一般的错误可以通过下功夫或者对基本的问题有很好的理解来避免。 这些本可以避免的错误常常会导致很多安全漏洞， 从而威胁信息的保密性、完整性和可用性。 通用规范 输入验证 在客户机 /服务器环境下，进行服务端的验证而不是客户端的验证（例如基于Javascript 的验证）。 通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。 有了代理服务器，攻击者可以在数据被客户端“验证”后修改数据（与“ maninthemiddle”攻击类似）。 在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。 如果输入中包含无效的字符，应用程序应该返回错误页面并说明输入中包含无效 字符。 这样进行验证的原因是定义无效的字符集比较困难，并且一些不应该有效的字符通常不会被指出。 另外，边界检查（例如字符串的最大长度）应该在字符有效性检查以前进行。 边界分析可以防止大多数缓冲区溢出漏洞。 必须提到的是从环境变量获得的数据也需要进行验证。 同时避免在环境变量中存放敏感数据（例如密码）。 某些 Unix 系统（例如 FreeBSD）包含 ps 命令，可以让用户看到任何当前进程的环境变量，这常常会暴露保密性信息。 SQL 语句 如果应用程序需要连接后端数据库，使用存储过程而不要在代码中使用 SQL语句。 使用程序以外的 嵌入在代码中的 SQL 语句调用特别危险。 难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的 SQL 攻击。 当然，输入验证有助于缓解这种风险。 注释代码 (mented code) 当应用程序在实际环境中开始应用时，应该删除所有的注释代码。 注释代码是用来调试或者测试的，它们不是最终应用程序的一部分。 无论如何应该在实际的环境中删除它们来避免意外的执行（一般注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，所以强烈建议执行这项工作）。 错误消息 所有为用户显示的错误信息都不应该暴露任何关 于系统、网络或应用程序的敏感信息。 如果可能的话，最好使用包含编号的一般的错误信息，这种信息只有开发者和 /或支持小组才能理解。 一般的错误信息的例子是“发生了错误（代码 1234），请您与系统维护部门联系。 ” URL 内容 对于 web 应用，不要在 URL 上暴露任何重要信息，例如密码、服务器名称、 IP地址或者文件系统路径（暴露了 web 服务器的目录结构）。 这些信息可以在攻击时使用。 例如下面就是一个不安全的 URL： PASSWORDamp。 file=/home/USER/ 设置 PATH 变量 设置 PATH 为一个已知的值，而不是仅仅使用启动时的缺省值。 攻击者可以在攻击应用程序时使用 PATH 变量，例如试图执行一个任意的程序。 这些也可以应用于大多数其他的语言。 Perl语言安 全规范 多年以来， Perl 已经成为用于系统管理和 Web CGI 开发的功能最强的编程语言之一（几乎可以使用 Perl 做任何功能的程序）。 但其扩展应用，即作为 Inter 上CGI 的开发工具，使得它经常成为 web 服务器上的攻击目标。 另外，大多数 CGI脚本有着比一般用户更高的权限，导致它更容易受攻击。 下面列举了一些开发者（特别是 CGI 程序员）可以使用的主动的预防性的措施来增强 Perl 代码的整体安全性（请注意：这不是 web 服务器 CGI 脚本安全性的指导原则）。 Taint 验证 Perl 版本 包含一个叫做 Taint Checking 的数据验证措施。 如果起用该功能，它就不允许通过用户输入（任何程序外的输入）来操纵其他的外部程序（例如通过管道将数据导入另一个程序执行））。 一般而言，程序员不能信任输入脚本和程序的数据（叫做 Tainted 数据 ），因为无法保证它不会产生危害（有意或者无意的）。 Taint 验证可以通过在命令行参数加入“ T”来开启。 例如你可以在 Perl 脚本的第一行这样加入“ T”： !usr/bin/perl5 T Tainted 数据包括命令行参数、环境变量和来自文件的数据。 引用 tainted 数据的变量也成 为 tainted 数据。 如果脚本试图通过不安全的方式来使用 tainted 数据会产生一个致命错误（对这种情况称为“不安全的依赖” (Insecure dependency)或者其他的说法）。 启用 tainted 验证在有些情况下会导致脚本停止运行，常 错误 !文档中没有指定样式的文字。 16 常是由于 Perl 解释器要求所有脚本引用的外部程序的完全路径必须在 PATH环境变量中列出，同时 PATH 中包含的每个目录除了目录的所有者及相应的所有者用户组外无法修改。 Taint 验证对于环境比较敏感，这就可能会导致大多数程序员不愿使用它，但是只要可能的话，应该使用 taint 验 证，特别是代码执行其他程序功能时（例如在 CGI 脚本的情况下）。 安全模块 如果不但输入数据不可信而且实际的代码也不可信会产生什么情况。 例如用户从网站上下载了一个 ActiveX 控件，而它实际是一个特洛伊木马 (Trojan horse)。 这种情况下 taint 验证就不起作用。 安全模块让程序员可以在 Perl 脚本中将不同的代码模块与安全对象联系。 每个安全对象对于运行的每块代码建立了一个限制的环境。 这与 chroot 在一个进程中只能在整体目录结构的一个子目录中运行类似。 而 saft 对象限制 perl 代码只能在 perl 包结构的 某些特定包中运行。 如何使用安全模式超出了本文的范围，但是程序员应该在任何时候尽量使用这一功能。 警告参数 (w) 使用 w 参数可以在 Perl 解释脚本时显示所有的警告信息。 警告可以对以下情况产生：只使用了一次的变量或者完全没有使用过得变量，未定义的文件句柄，未关闭的文件句柄，或者将非数值变量传递到数据变量。 该功能不是针对安全处理的，但是可以有助于调试直接或者间接对安全有危害的错误。 一般推荐总是使用 w 参数。 可以在 taint 验证时在第一行这样使用 w 参数： !usr/bin/perl5 Tw Java 语言安全规范 自从 1995 年发布以来， Java 成为简单或者复杂网络应用的有效编程语言。 它在设计时充分考虑了安全问题，因此它具有的限制特征有：收集不再使用的内存碎片的垃圾收集器，严格的“ sandbox”安全模型，以及在特定主机上限制应用程序的活动的安全管理器。 下面的使用中相关的规范： 不要在标准输出上打印消息 在实际的 Inter 系统中避免使用 ()或者 ()打印日志和错误消息，原因是当消息打印到标准输出时，无法立即确定消息发生的地点。 而且它有可能将敏感信息透露给攻击者。 封装 Java 中，如果没有使用访问标识符 (access modifier(private、 protected 或者 public))来声明类、方法和属性，那么它的默认访问范围是包，并且同一包中的所有类都能访问它。 必须记住虽然包有封装功能，但它只有在每部分加载到包的代码都由授权用户控制时才起作用。 恶意的用户可以加入他们自己的类，从而对于包中的所有类、方法和属性都有完全的访问权限。 Java 的政策文件支持两种控制包访问权限的前缀。 accessClassInPackage defineClassInPackage 所有标准库中的类都默认是可以公共访问的（除了由“ sun”开头的类）。 为了保证一个包的安全性，必须修改 ${JAVA HOME}/jre/lib/security 文件夹中的 文件。 该文件中的重要行是： =sun. 虽然该方法有作用，但是也有问题。 例如程序员在 文件中定义包的安全时必须十分小心。 在 中的值是字符型的，“ sun.”将保护“ ”等包，但是不会对 “ sun”或者“ sunshine”等包进行保护。 另一个方法是使用 JAR 密封 (sealing)。 JAR(Java ARchive)文件是一些类的打包压缩格式的文件，与常用的 ZIP 格式类似。 如果从一个密封 (sealing)的 JAR 文件中加载一个类时，随后同一个包的类只能从该 JAR 文件加载。 为了起用密封(sealing)，必须在建立 JAR 文件时这样设置密封 (seal)参数： Sealed: true 使用密封 (sealing)的 JAR 文件比权限 (permission) 设置更好，因为它不需要安装安全管理器 (security manager)。 政策文件 Java 内建的安全管理器是对应用程序进行限制的一个方便的工具。 很多情况下需要编制一个定制的安全管理器， 及以后的版本提供了 描述 设置的方法而不是 实施它们。 这是通过 Java 政策文件实现的。 可以用政策文件以相对模块化的方式控制文件系统和网络的访问。 例如可以限制应用程序只能修改名字是foo 的文件。 推荐使用 Java 政策文件和安全管理器而不是重新创建一个类或者系统来限制对主机和网络的访问。 C/C++ 语言安全规范 C 本质上是不安全的编程语言。 例如如果不谨慎 使用的话，其大多数标准的字符串库函数有可能被用来进行缓冲区攻击或者格式字符串攻击。 但是，由于其灵活性、快速和相对容易掌握，它是一个广泛使用的编程语言。 下面是针对开发安全的 C 语言程序的一些规范。 缓冲区溢出 避免使用不执行边界检查的字符串函数，因为它们可能被用来进行缓冲区溢出攻击。 下面是应该避免使用的函数。 同时，也列出了每个函数相应的比较安全的替换方式。  不使用 strcpy()，使用 strncpy() 错误 !文档中没有指定样式的文字。 18  不使用 strcat()，使用 strncat()  不使用 sprintf()，使用 snprintf()  不使用 gets()，使用 fgets() 在上面的前三个中函数中，每个替代函数的“ n”表示了使用的缓冲区的大小。 最后一个函数的“ f”，表示格式，它允许用户指定期望的输入的格式。 这些替换方程强制程序员定义使用的缓冲区的尺寸以及确定输入的类型。 格式化字符串攻击（ Format String Attack）。