信息系统开发安全管控办法.docx
《信息系统开发安全管控办法.docx》由会员分享，可在线阅读，更多相关《信息系统开发安全管控办法.docx（8页珍藏版）》请在冰点文库上搜索。
信息系统开发安全管控办法
信息系统开发安全管控办法
信息系统开发平安管控方法之相关制度和职责,1?
范围本标准规定了信息系统开发阶段､测试阶段､试运行阶段和上线阶段的管理内容与要求｡本标准适用于公司自主开发及委外开发信息系统的管理｡2?
规范性引用文件下列文件中的条款通过...
1?
范围
本标准规定了信息系统开发阶段､测试阶段､试运行阶段和上线阶段的管理内容与要求｡
本标准适用于公司自主开发及委外开发信息系统的管理｡
2?
规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款｡凡是注明日期的引用文件,其随后全部的修改单（不包括勘误的内容）或修订版均不适用于本标准｡凡是不注明日期的引用文件,其最新版本适用于本标准｡
国务院令（第339号）计算机软件疼惜条例
国务院令（第147号）中华人民共和国计算机信息系统平安疼惜条例
Q/JYG/GL-SB-16-2021.a《投资项目管理方法》
3?
术语和定义
信息系统:
是指由计算机及其相关的配套设备､设施（含网络）构成的,依据确定的应用目标和规则对信息进行采集､加工､存储､传输､检索等处理的人机系统｡
信息系统一般由三部分组成:
硬件系统（计算机硬件系统和网络硬件系统）､系统软件（计算机系统软件和网络系统软件）､应用软件（包括由其处理､存储的信息）｡
4?
职责
4.1?
XXXX部门
4.1.1?
负责公司信息系统开发各阶段文档的审批工作;
4.1.2?
负责组织公司新开发信息系统的测试工作;
4.1.3?
负责公司信息系统上线与终止的验收工作｡
4.2?
卷烟厂计算机中心
4.2.1?
负责本厂信息系统开发各阶段文档的审批工作;
4.2.2?
负责组织本厂新开发信息系统的测试工作;
4.2.3?
负责本厂信息系统上线与终止的验收工作｡
4.3?
各实施部门或单位
4.3.1?
负责本单位信息系统开发过程中的需求提出､测试及验收等工作｡
5?
管理内容与要求
5.1?
总体要求
5.1.1?
信息系统开发须遵循《计算机软件疼惜条例》､《中华人民共和国计算机信息系统平安疼惜条例》｡
5.1.2?
信息系统开发过程中项目单位（承接信息系统开发的单位）须提交相应的平安需求､平安设计､平安测试等资料并经过XXXX部门审批,否则不予立项或验收｡
5.1.3?
信息系统开发范围的变更（增加或缩减）､新技术的用法､新产品或新版本的接受､新的开发工具和环境须经过XXXX部门审批｡
5.2?
信息系统开发生命周期管理要求
5.2.1?
系统需求收集和分析阶段
a）?
技术可行性分析
依据业务上提出的需求,信息系统归口管理部门应从技术开发的角度分析是否现有的技术手段和技术力气是否可以达到业务上要求的系统功能,主要包括:
人员技术力气分析（指公司内的系统开发队伍是否有足够的软件开发的技术力气来完成系统开发的任务,或第三方外包的开发公司是否具有开发应用系统的技术力气）､计算机软件和硬件分析（指公司现有的软件和硬件的性能是否足够满意开发相应的系统的要求）､管理力气分析（指现有的技术开发管理制度和管理流程是否成熟且标准化,是否足够系统开发的要求）｡
b）?
需求可行性分析:
信息系统归口管理部门应对该申请部门所提需求进行可行性分析,以推断需求是否明确,是否吻合实际,是否能在确定的时间范围实现｡
c）?
经济可行性分析:
信息系统归口管理部门应依据业务需求和技术手段的分析,确认投资的数额在可把握和可承受的范围内｡
d）?
平安可行性分析:
信息系统归口管理部门应明确该系统的平安建设范围和内容,设定平安性指标要求,合理判定该信息系统是否吻合公司的网络及信息平安要求｡
5.2.2?
设计阶段平安管理
a）?
单点访问:
任何用户假如愿望访问应用系统中的某一个部分,则务必通过统一且唯一的认证授权方式以及流程｡
b）?
人员职责和权限的划分:
系统务必具有基于人员职责的用户授权管理以确保每个用户可以访问到其权利范围内的应用系统部分,也要确保每个用户无法访问其权限范围以外的应用系统部分｡
c）?
疼惜敏感系统的平安性:
通过将应用系统中敏感信息保存在服务器端以进行集中的加密平安管理,确保客户端系统本身并不能存储任何信息敏感的数据｡
d）?
确保访问层的平安性:
系统在要确保系统模块本身平安性的同时,还需考虑模块与模块之间的通讯的平安性｡模块与模块之间的平安性包括:
应用系统内部模块之间的平安､应用系统内部模块和外部模块之间的平安性,如主机和客户端之间通讯的平安性,服务器和服务器间通讯的平安性,本地系统和异地系统之间通讯的平安性｡
e）?
确保日志管理机制健全:
要求建立可以依据状况自由设置的日志管理机制,即日志纪录的范围和具体程度可以依据需求自行定制,且可实现在应用系统用法过程中进行日志的定制和记录,并保留全部系统开发相关程序库的更新审核纪录｡
f）?
新系统的容量规划:
容量规划是指确定系统的总体规模,性能和系统弹性｡容量规划应充分考虑:
系统的预期存储容量和在给定的周期里面猎取生成和存储的数据量;在线进程的数量和估量可能的占用资料;系统和网络的相应时间和性能,即端对端系统;系统弹性要求和设计用法率､峰值､槽值和平均值等;平安措施如加密解密数据对系统的影响等;7*24小时运作要求和可接受的系统宕机次数（维护或者设备更新导致的务必性宕机）｡
5.2.3?
开发阶段平安管理
a）?
通用要求
1）?
输入验证:
在客户机/服务器环境下,系统需进行服务端的验证而禁止客户端的验证（如基于Javascript的验证）,并在字符有效性检查之前设置边界检查验证以及环境变量提取数据验证｡
2）?
命名规范:
规范变量､函数的命名;规范程序的书写格式等｡
3）?
SQL语句:
假如应用程序需求连接后端数据库,用法存储过程而不能在代码中用法SQL语句｡
4）?
说明代码:
当应用程序在实际环境中开头应用时,应当删除全部的说明代码｡
5）?
错误信息:
全部为用户显示的错误信息不应暴露任何关于系统､网络或应用程序的敏感信息｡
6）?
URL内容:
对于web应用,不能在URL上暴露任何重要信息,如密码､服务器名称､IP地址或者文件系统路径等｡
b）?
变更要求
1）?
信息系统归口管理部门应对更改进行严格的把握,在系统开发的每一个阶段（可行性争辩､需求分析､设计､编码､测试､培训等）的每一个更改实施前经过评审与授权｡
2）?
信息系统归口管理部门应当建立更改把握审批程序,对更改的申请､评审､测试､批准､更改的方案的提出和实施提出明确要求并严格的实施,确保平安性与把握程序不被损害,确保任何的改动都是经过审批的｡
3）?
更改的程序应考虑以下方面:
清楚确认全部的需求更改的应用系统､信息､数据库和相关的硬件设备;清楚的确认更改的缘由（业务上的详细流程和详细的需求或开发上的需求）;由授权的用户提交更改的申请;保留相关的授权登记记录;在正式的实施之前,更改的方案务必经过评审并通过正式的批准;确保授权的用户在实施之前确认并接受更改的内容;确保在实施的过程中,尽量的削减对现行的商务运作系统的影响;确保建立的文件系统在完成各项更改时得到修改,旧文件被很好的归档或处置;保证全部的应用系统升级的版本的把握;确保全部的更改情求的审核跟踪;确保用户用法手册作相应的必要的更改;确保更改的实施选择了适当的时机以确保更改的实施不会干扰正常的商务运作｡
c）?
版本把握要求
1）?
程序清单:
信息系统归口管理部门应在任何时候对于程序清单务必进行严格的把握并且准时地进行更新;对应用系统开发源程序的打印的资料､电子版本或者是相关的报告都务必进行把握,纸质的文件应当保存在一个平安的环境下,如保险柜等,电子文档则应进行确定的加密;
2）?
版本升级把握:
当软件的版本由于更新,修改等操作需求升级时,务必先向相关负责人员提交申请;信息系统归口管理部门应对升级的应用系统进行测试,确认系统的各种平安特性;信息系统归口管理部门应确认对应用系统的版本升级,即确认当前的版本为最新版本,旧的版本需进行归档,不得任凭丢弃或删除;信息系统归口管理部门应制定相关的升级方案,确保将系统升级对业务的影响降至最低｡
d）?
开发审计:
信息系统归口管理部门应对开发日志及开发人员权限进行每月审核｡
5.2.4?
测试阶段平安管理
a）?
测试前平安检测:
信息系统归口管理部门应组织开发人员进行代码审核,检查､消退程序代码潜在的平安漏洞｡
b）?
信息系统归口管理部门应设计具体的测试方案,测试范围,测试方法和测试工具,应充分考虑与其他系统的互操作性测试中对其他系统的影响,选择适当的时间､方法｡并对应用系统存在的弱点威逼进行平安检查,如:
假冒身份､恶意篡改､信息泄露､拒绝服务､特权提升等｡
c）?
信息系统归口管理部门应在测试系统功能正常运行的基础上,还需测试系统的模块和模块之间､功能和功能之间的接口的正确性､负载力气及水平､系统承受压力及峰值､测试环境等｡
5.3?
开发､测试及验收过程平安指导规范
5.3.1?
开发环境平安
a）?
信息系统归口管理部门应对项目文档､代码的存储进行备份,以确保在发生意外时,可有效复原;
b）?
信息系统归口管理部门应对项目文档和代码版本管理和访问把握;
c）?
信息系统归口管理部门应对用于开发的服务器､个人电脑的配置做好严格的平安防护措施｡
5.3.2?
文档平安
a）?
文档内容的平安:
信息系统归口管理部门应对文档内容进行以下几个的规范:
需求解释书中应明确描述应用系统的平安需求;设计解释书中应有针对平安需求的设计,并进行评审;在测试大纲或者测试方案中应有平安性测试方案,并以此进行平安性测试;开发各阶段输出的文档应对平安要求的执行状况进行描述｡
b）?
文档自身的平安:
信息系统归口管理部门应对文档设定密级及读者范围,以限定其访问范围,文档的访问把握应有相应的授权机制｡
5.3.3?
源代码管理
a）?
信息系统归口管理部门应依据协议执行源代码的管理,源代码管理应保存全部的历史版本,以便查阅｡
b）?
信息系统归口管理部门应对全部的程序源代码及设置支持文件等打包进行平安检查并存档｡
c）?
对于托付第三方开发的应用系统（或功能､模块等）的代码文件或设置文件,在需求对其进行修改时,务必经过投资装备部批准后,才能交给修改人进行修改｡修改完毕需通过平安检查才可以提交,通过检查后的源代码（或设置文件）提交至XXXX部门,由专人进行更新和归档｡
d）?
其他源代码规范:
应用系统需对函数入口参数的合法性和精确性进行检查;应严格遵循Fail-Safe原则,即当发生意外事故时,务必能自动切换到平安的疼惜模式｡（当应用系统的登录验证机制不能正常运行时,系统务必自动拒绝全部登录恳求,而非接受全部登录恳求）;应禁止接受担忧全的登录密码,并允许系统管理员强制密码设定规则;全部缺省平安设置务必能同时满意系统正常运行和系统平安两方面的要求;在全部警告或提示对话窗口中应用法精确､明白的描述性语言,并供应有关关怀链接;在接受用户输入时,务必有数据合法性检查,并严格规定输入数据的字符长度;在输入密码等敏感信息时,用法特别符号来代替输入的字符;应禁止用法XX和验证的代码,在用法第三方代码时,应对代码平安性进行评估和测试;如密码由应用系统生成,则务必保证有足够的长度和随机性,如密码由用户生成,则应用系统应有密码平安策略来拒绝接受“担忧全的”密码;应禁止以明文方式传递用户密码;应测试用的“后门”,应在发布版中去除;应说明代码中无用的代码;应规范代码的格式,并对代码进行版本把握,确保代码的可用性;应禁止在程序中添加隐蔽“恶意”的代码,防止与应用系统相关的程序员对系统的非授权修改｡
5.3.4?
需求分析
a）?
信息系统归口管理部门应在需求分析阶段确定应用系统的平安要求,并对其进行具体描述,制定项目平安需求解释书,并指导整个项目设计､实现､测试环节｡
b）?
在需求分析阶段应明确以下与平安相关的需求:
用户数､终端数､在线并发数;用户角色的划分和权限的支配;应用系统性能要求;应用系统可用性要求;现有网络现状和网络性能要求;数据量估量､数据存储方式和周期;系统平安级别和数据保密性要求;其他对网络､存储､服务器､终端､操作系统､数据库､数据等方面的平安需求｡
5.3.5?
应用平安功能设计
a）?
认证失败处理:
连续失败登录后锁定该帐号,帐号锁定后可由系统管理员解锁,也可以在一段时间后自动解锁,并通知用户认证失败｡
b）?
授权:
应用系统应包含用户权限支配和管理功能设计｡如:
系统读､写､执行权限设计;系统查看､配置､修改､删除､登录､运行等权限设计;数据访问范围的角色设计;应用功能模块用法权限的设计;限制用户对系统级资源的访问,系统级的资源包括:
文件､文件夹､注册表项､ActiveDirectory对象､数据库对象､大事日志的系统资源;程序应用法尽可能小的权限;数据库访问应当用法低权限数据库账号（如选择,删除,更新,插入等）通过参数化的存储过程来访问;应用启动进程的权限尽可能小;应用用法的系统账号（运行环境中的）应当有尽可能低的权限｡应避开“Administrator”,“root”,“sa”,“sysman”,“Supervisor”或其它全部的特权用户被用来运行应用系统或连接到网站服务器,数据库或中间件｡
c）?
输入输出验证:
为了防止攻击者绕过客户端挺直验证,在服务器端进行验证时,务必用法服务器端代码执行验证;依据已知的有效类型､模式和范围验证数据;应限制用户输入并验证数据的类型､长度､格式和范围｡
d）?
数据加密:
应用系统应用法公开并且经过验证和测试的加密方法;应避开向算法传递明文数据,并避开修改存储该数据;应确保所用法的密钥长度和密钥空间能供应足够的平安级别;对于大量数据加密,应用法对称的加密,提高加密的速度并削减资源消耗;对于少量存储的敏感数据用法非对称加密,确保数据的平安性;应对密钥的存储进行严格疼惜｡
5.3.6?
测试平安
a）?
信息系统测试人员需明确记录测试目的､平安要点､测试参加人员､测试流程,并编写测试大纲,包括对应用系统的帐号､口令的平安测试;
b）?
信息系统测试人员需对应用系统的平安功能点进行测试,确保平安功能的有效性､正确性;
c）?
信息系统测试人员需对对应用系统反抗攻击的力气进行测试;
d）?
信息系统测试人员需对数据传输的平安性､物理环境等进行测试,测试数据如选择真实数据,应限定测试的人员,并在测试完成后全部删除和具体记录测试过程中发觉的问题｡
5.3.7?
系统部署平安
a）?
信息系统归口管理部门应规划应用系统部署需求的资源需求:
应用系统部署的软件､硬件的资源要求;应用系统部署的网络要求;物理链路（光纤､五类线）资源;网络设备资源（HUB､Switch）､上联网络节点端口;IP地址;上联网络带宽;应用系统部署的有关部门､人员要求;其它资源的具体清单｡
b）?
信息系统归口管理部门应确保应用系统部署的环境平安:
确保应用系统部署的硬件平安､操作系统平安;确保应用系统部署的帐号､口令平安;确保吻合应用系统部署的平安策略要求（如访问把握）;确保应用系统部署的物理环境平安（如电力）;应了解脆弱的网络或者主机的配置缺陷｡
c）?
信息系统归口管理部门应确保应用系统部署的过程平安:
确保应用系统部署过程的操作平安;对应用系统部署所在的系统进行平安备份;只对部署所需求的帐号供应最小的访问权限,防止进行其它与部署无关的活动;部署的过程应有业务人员在场,对部署的操作需求经业务人员的确认;对部署的操作过程应进行记录;应确保应用系统部署过程的安装平安｡
d）?
应用系统部署的其它平安问题:
记录应用系统部署的具体过程;应用系统部署的时间进度支配;分析应用系统部署可能存在的风险,并制定风险规避方案;明确全部参加人员的工作职责;与全部参加人员签订保密协议,禁止泄漏部署有关的重要内容｡
e）?
信息系统归口管理部门需明确应用系统部署后的升级验收标准,并在验收之前做系统测试（如系统联通性测试）,管理员应确保应用系统的验收标准和要求得到清晰地定义､记录和测试｡管理员还应考虑以下的管理措施:
性能和计算机容量需求;错误复原和重新启动程序及意外事故的处理方案;有效的人工操作程序;业务连续性支配;证明新应用系统的安装不会对现有系统有负面影响,尤其是在高峰处理时段;证明已经考虑到新系统对该组织整体平安性的影响;应用系统的操作用法手册;支配人员培训｡
5.3.8?
日志设计
a）?
日志的内容应尽可能具体､精确,但应平衡性能要求｡应为日志文件设计不同的具体程度供系统管理员或用户选择｡
b）?
为日志文件设计输出界面,允许以不同的格式输出日志文件或允许挺直输出日志文件到数据库｡
c）?
日志文件中的每条数据记录应要求有日期和时间（精确到秒）｡
d）?
应利用操作系统或其他监控系统的日志文件对应用系统在发生异样时供应日志记录｡
管理人职责管理员职责管理处职责
管理局职责管理层职责管理所职责
升级会员 