信息系统应用开发安全基本要求

信息系统应用开发安全基本要求1范围为了提高XX公司信息通信分公司（以下简称''公司〃）信息系统应用开发的安全性，全面规范系统需求分析、设计、开发、测试、验收、使用及系统测评等过程，特制定本要求。适用范围本要求适用于公司信息系统应用开发和建设。信息系统应用开发安全基本要求包括范围如下：系统的需求分析、设计、开发、测试、验收等工程过程与运行维护过程系统的安全功能模块需求系统的安全审计与监控2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，使用本标准的相关部门、单位及人员要研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。——中华人民共和国计算机信息系统安全保护条例——中华人民共和国国家安全法—中华人民共和国保守国家秘密法——ISO27001标准/ISO27002指南—公通字[2007]43号信息安全等级保护管理办法——GB/T20269-2006信息安全技术信息系统安全管理要求Q/HD212.07—2007计算机信息系统管理标准Q/HD212.04—2007软件开发与维护管理标准3术语和定义下列术语和定义适用于本标准程序是计算机的一组指令，经过编译和执行才能最终完成程序设计的动作。程序设计的最终结果是软件。4原则对系统进行安全设计和部署必须遵循以下原则：可控性：应尽可能地降低应用系统中各功能模块与安全模块结合过程的风险。独立性：应保持相关功能模块与安全模块之间底层接口，避免功能实现上的交叉和二次编程开发。适用性：增强应用系统安全模块是根据业务安全需要，最大程度地提供便捷可靠的结合方式与第三方安全系统结合。应用安全架构5应用安全架构应用安全架构是由系统安全服务、协议、各种类型的接口组件与身份策略管理构成。应用系统根据业务职能部门的需求不可能做到统一，因此，必然选择不同的开发平台、协议、接口组件，对身份、策略管理要求也必然不同。在本规范中，只对安全服务中的认证、授权、监控、审计、密钥管理、隐私性、安全服务提出具体的要求，对其他如协议、接口组件、身份、策略管理等根据业务需求进行定义。6安全服务需求安全服务是应用安全架构的核心，包括认证、授权、监控、审计、密钥管理、隐私性、安全服务等部分。6.1认证6.1.1应用系统认证应包括正式的注册、登录认证和注销，能够对不同用户的访问权限进行严格的访问控制。具体要求包括以下内容：6.1.2根据应用程序采用合适的认证方式，对于安全要求较低的系统可以采取传统的用户名、密码认证方式，对于安全要求较高的应用系统应该采取如双因素认证、数字证书认证等安全性较高的认证方式。应确保应用系统帐号与操作系统账号分离。6.1.3应使用唯一的用户标识符（用户ID），使用户与其操作相关联，并对其行为负责；确实必要时，作为例外情况，才允许使用用户组账号，并采取额外的控制措施。6.1.4应马上修改或注销已经更换岗位或离开公司的用户帐号。6.1.5应确保用户账户灵活设置，并可修改口令，口令位数必须限制在8位以上，系统具备禁止使用弱口令能力，管理员要定期核查并删除多余、闲置的用户ID或账户。6.1.6应具备认证审计功能，审计成功和失败的认证。可根据安全认证策略自定义超时自动退出的时间、限制连续登录失败的次数、记录登录用户的名称、时间（以服务器端的为准）、成功与否（如果失败，要记录原因）、IP地址等。6.1.7对于安全要求较高的系统应使用公司内部统一PKI/CA身份认证系统作为应用系统身份鉴别方式之一。6.2授权6.2.1对应用系统的访问或者进行某些特殊操作，例如：用户访问应用系统或者进行系统管理时，会用到一些特殊的账户，一旦这些帐户被非法用户窃取，对整个系统的危害是非常巨大的，对于这些管理帐户除了应该遵循一般用户的安全规定外，还需要进行如下限制：6.2.应用系统至少具有系统管理员和日志管理员，并将权限进行分离。系统管理员只是对系统的管理与授权，不能对日志审计进行管理、审计，不能管理日志功能的开启、关闭、删除等操作。日志管理员对应用系统无权做维护日志以外的操作。系统管理员和日志管理员不得为同一人。6.2.3应用系统能根据用户或用户组设置不同的系统功能操作权限和数据访问权限。6.2.4应用系统应将管理员用户与普通用户的权限分离。6.2.5应用系统与数据库应处于安全区域，对数据库的访问应具备授权、使用、拒绝等策略。6.2.6对于与应用系统相关的数据库，尽量删除或禁用各种缺省用户名。无法做到的，增加相应密码的长度和复杂性。安装数据库后，必须消除数据库各种已知的漏洞。6.2.7应用系统应对管理账户的登录、操作和授权等进行日志记录。6.2.8应用系统对用户的授权应由用户申请，部门审批后，提交应用系统管理部门操作。6.2.9对各种管理员的授权，应由应用系统管理部门严格管理，不得出现一人兼任多种管理员的情况。6.2.10应用系统中的权限应基于“使用需要”，逐个事件进行分配，即以完成其岗位职责的要求为依据，因某个特定事件而分配的特定权限，应在事件结束后立即收回。6.2.11应用系统上线之前，需提交各种管理员和用户的权限范围和工作要求的文档。6.2.12应用系统应尽量对管理权限进行分割，把不同的管理权限赋予不同的账户，避免权限的过于集中，从制度上保障应用系统的安全。6.2.13应用系统应保留所有人员使用的日志记录，不得包含任何隐含帐号、隐含申请授权流程和不受日志记录的使用手段。6.2.14应确保应用系统在授权成功之前不提供访问服务。6.2.15应用系统能够对单个用户的会话数进行限制。对登陆用户在一定时间内没有动作进行自动退出，同时可以对同一时间最大并发数进行限制。6.3密钥管理6.3.1应用系统应根据业务所涉及信息的价值和系统的等级来选择不同的数据传输方式来保证数据的传输安全。同时应保护所有的密钥免遭修改、丢失和毁坏以及防范密钥泄露。密钥管理应注意以下几点：6.3.2需要加密的应用系统应采用国家规定的、未被破解的密码算法进行加密;6.3.3分发密钥给用户时应同时附上对密钥的保管和使用的说明，在说明中要强调丢失密钥及时报告的重要性。要建立保证用户离开公司归还并注销密钥的机制;6.3.4密钥管理系统应具备存储管理密钥以及恢复用户丢失的加密密钥能力;6.3.5密钥管理系统应采用适当强度的加密算法对密钥进行加密归档，严禁采用明文保存密钥。6.3.6密钥管理系统应记录和审核与密钥管理相关的活动。6.3.7隐私性6.3.8如果应用系统有显示用户他人信息的界面，则同时应具备用户自己选择个人信息是否公开来保障个人隐私的功能。6.4安全服务应用系统应具备对相关信息的输入、输出检查，消息验证以及脆弱性检查的能力，确保应用系统安全。6.4.1输入检查为保证应用系统的安全性、正确性及适用性，在开发过程中需对加入到应用系统中的数据严格进行代码检查，避免无效或非法数据对系统造成危害。如在ASP、.NET和JAVA应用中，应特别强调过滤用户通过WEB(包括地址栏和表单等)提交数据中的特殊字符和限制用户提交数据的长度。应用系统应具备输入验证机制，包括对数据类型(字符串、整型)、格式、长度、范围的验证，对空值(Null-Value)的处理，对字符集、地区、模式、上下文环境、表单字段、脚本、值的合法性和有效性的校验，确保正确处理输入数据，避免应用程序在出现输入错误的形式运行。6.4.2消息验证消息验证是一种用来检测对电子消息的非法修改或破坏的技术，如会话劫持(SessionHijack)、篡改和伪造。该技术可以用物理设备或软件算法实现。应用系统应验证重要信息文件与记录是否被篡改以及下载/上传的重要数据的完整性。例如通过对重要数据进行数字签名。应用系统应具备自定义会话控制或批次控制能力，确保输入更新前后数据文件的一致性，例如：检查操作前后文件打开和关闭的数目是否一致。应用系统应具备对信息数据执行操作前后对象信息验证以及差额是否正常。6.4.3输出净化尽管数据的输入和处理是正确的，但输出仍然可能包含内部错误（如内存不足、空指针异常、系统调用失败、数据访问失败和网络超时等）或输入回显注释和标记。因此，应用系统的输出数据应当被验证，以确保数据处理的正确性与合理性。输出验证包括：应用系统的输出数据应在规定的范围内，并通过测试输出数据是否真实合理审查。应用系统应为用户或后续操作应用系统提供充足的信息，以确定信息的准确性、完整性、精确性和分类级别；例如：在输出数据时提供帮助信息。应用系统应具备错误处理机制，并存储为日志便于审计。应用系统应具备验证输出数据的测试程序，并明确规定数据输出过程中特定用户人员的职责。6.4.4脆弱性检查与管理应用系统开发方应随时关注与所提交应用系统相关的技术脆弱性的信息，评估这些脆弱性对该应用系统及所处环境的威胁程度，并及时采取适当的措施来加以防范。建立有效的技术脆弱性管理过程应遵循如下要求：应用系统开发方对系统相关技术脆弱点检查后，一般以提供补丁的形式来解决问题，在安装补丁之前要在仿真环境下进行测试与评估，确保有效和不会导致负面影响，如果没有可用的补丁或者安装补丁风险过大，应向用户提供相关具体控制措施，如关闭与脆弱性有关的服务和功能，或向用户说明监视的方法，以检测或预防可能的攻击；必须定义、建立与技术脆弱性管理相关的角色和职责，包括脆弱性监视、脆弱性风险评估、打补丁、记录、归档和协调等；应用系统开发方必须明确，对应用系统相关的技术脆弱性公告，按照技术脆弱性需要解决的紧急程度，给出明确的反应要求；必须做好应用系统技术脆弱性管理过程的记录和归档工作；6.5日志监控应用系统应具备基本的处理信息日志记录功能，支持向第三方审计系统发送日志，支持将指定类型的日志以短信方式发送到用户手机的功能，在打开所有日志记录功能的情况下，应用系统及所驻留的硬件支持保存达到国家规定的至少六十天的日志的要求。日志记录的范围包括：6.5.1对授权访问的用户名、日期和时间、动作（如修改、删除、发送、其他功能操作等）、访问的文件等。6.5.2对所有特殊权限帐户的登录和操作、授权等。6.5.3对系统的启动和终止、各组件服务停止和启动以及服务所需的I/O设备的装配/拆卸等。6.5.4对未授权的访问尝试包括失败的或被拒绝的用户活动、失败的或被拒绝的涉及数据和其他资源的活动。6.5.5应用系统支持对各种监督功能的打开和关闭。6.5.6应用系统对用户各种操作监督的详细程度应根据业务所涉及信息的价值、敏感度、关键程度和资金情况等综合因素来确定。7开发管理要求应用系统的安全控制、安全性都是通过系统的开发设计予以实现的，在设计阶段采取控制措施远比在实施过程中或者实施结束之后落实控制措施更有效。若在系统设计阶段未充分考虑系统的安全性，则系统本身就存在着先天性不足。因此，在应用系统设计阶段，应正确识别、确认、批准所有安全需求，并将之文档化。在外包软件开发时，应注意以下几点要求：应选择信誉与质量保证能力好的软件承包商。应具有软件许可权协议、代码所有关系以及知识产权申明文件。应具有工作质量和准确性的检验，并保留检查权利。应对承包方违约时采取相关控制措施。应具备代码质量的合同要求，如对编程标准的要求。应对系统上线之前进行测试，包括后门、逻辑炸弹和特洛伊代码等的检测，并保留检测文件。对于在现场环境下开发的应用系统，必须在独立的开发环境下进行，在实际上线之前必须经过严格的测试，并保存详细的测试结果。7.1开发过程安全要求7.1.1变更控制要求为减少开发过程中的变更对应用系统造成的安全风险，应在系统开发阶段（如:计划需求、设计、编码、测试）实施严格的变更控制，对变更的申请、审核、测试、批准、执行计划与具体实施提出明确要求，确保系统安全性与控制措施不受损害。变更控制必须包括以下内容：应具备详细的变更方案并获得正式批准，及时识别所有要求，便于发布变更通知。应确保是由授权用户提交变更申请，并保留授权级别变更记录。应具备审查变更控制措施和流程的完整性，确保未被修改和破坏。应选择恰当的变更时间，确保在具体实施过程中最大限度地减少业务影响。应确保操作系统的更改不会对应用系统的安全性和完整性造成不良影响。应确保系统文档在每次修改后得到及时更新，并确保旧文档被正确归档和处置。7.1.2软件包控制要求在基于第三方系统开发情况下应尽量避免修改原厂商提供的软件包，如必须修改，应注意以下几点：应评估软件包内置的控制措施和完整性流程遭受破坏的风险。应征得原厂商的同意，并由原厂商提供标准的升级程序来实现软件包的更改。应考虑修改带来的软件维护责任方面的潜在负面影响。如修改必不可少，则应保留原始软件，并在原始系统的清洁拷贝上进行。应全面测试所作的修改，并记录在案，以便必要时重新升级。7.1.3恶意代码控制要求后门、逻辑炸弹和特洛伊代码都属于恶意代码范畴，对应用系统具有重大的潜在威胁。在应用系统的原始采购、开发、使用和维护过程中，应采取如下防范控制措施：仅从信誉卓著的厂商处购买软件，并通过国家和电力行业权威机构评估测试的软件产品。应购买能够提供源代码的系统，在投入使用之前应检查所有源代码，并对审计包括后门、木马、病毒等文件存档。在应用系统正式使用后，必须严格控制对源代码的访问和修改。应使用可靠人员操作关键应用系统，并不得随意运行未经检测的软件。7.2代码控制安全要求7.2.1在操作系统中控制要求为最大限度地降低操作系统遭受破坏的风险，应考虑采取如下控制措施：应确保程序运行库(operationalprogramlibaries)升级只能由指定的管理员在获取授权后予以完成