信息系统获取、开发及维护程序
信息系统运行及数据维护管理办法
XX 电力公司
信息系统运行及数据维护管理办法
1、信息中心是全局微机网络建设、开发、应用、管理的职能部门，负责全局的计算机自动化规划、维护、更新。
2、专业子系统数据上网，必须按照指定的上网子程序运行。
3、按照各子系统的数据变动要求，必须保证网上数据的及时性，保证数据为最新数据。
4、未联网的微机数据上网，应按照要求，将上网数据交由信息中心进行上网处理。
5、任何单位和个人未经允许，不得随意增删、修改局网络服务器的目录、文件、用户权限和口令。
6、微机工作站禁止运行与工作无关的各种游戏软件，禁止使用光盘进行一切娱乐活动。
7、上网微机必须严格遵守操作规定，防止病毒感染微机和网络系统，以免造成不必要的损失。
8、各部室必须设工作站专责人进行数据、软件及硬件的管理。
9、保证工作站的安全运行，为所在部室提供正确的数据信息。
10、各工作站在运行中，对于出现的软件与硬件故障、计算机病毒等问题，工作站专责人负责记录并及时向信息中心报告，以便尽快解决。
11、工作站专责人要及时向信息中心发送信息，保证网上数据的准
确、完善。
12、工作站专责人负责所在部门软件的开发、维护、更新和完善。
13、专责人负责工作站的环境卫生，机器设备定期清扫，并填写运行记录。
14、严格遵守其他计算机制度和保密制度。
信息系统开发过程
信息系统开发过程信息系统开发是指根据特定的需求和目标，采取一系列的工程方法和技术手段，设计、实现和维护信息系统的过程。
在信息化时代，信息系统对于企业的发展至关重要，因此，了解信息系统开发过程的各个环节和步骤是非常必要的。
一、需求分析阶段需求分析阶段是信息系统开发的第一步，也是最为关键的一步。
在这个阶段中，开发团队必须与用户进行充分的沟通和交流，了解用户的真实需求和期望。
通过需求调研、访谈和观察等方式，确定系统需求，明确系统功能和性能指标，并进行需求文档的编写。
同时，需求分析人员还需要考虑系统的可行性，包括技术可行性、经济可行性和操作可行性等。
二、概要设计阶段在需求分析阶段确定系统需求后，下一步是进行概要设计。
概要设计是指在需求的基础上，对系统的总体结构和模块进行设计，包括系统的架构、模块划分和模块之间的关系等。
概要设计的结果是制定概要设计文档，为后续的详细设计和编码提供指导。
三、详细设计阶段详细设计阶段是在概要设计的基础上，对系统的具体功能和模块进行详细的设计。
在这个阶段，需要针对每个模块进行详细的设计，包括设计模式的选择、算法的设计和数据结构的定义等。
详细设计的结果是制定详细设计文档，为编码和测试提供依据。
四、编码与单元测试阶段在详细设计完成后，开发人员开始进行编码工作。
编码是将设计文档中的设计思路转化为代码的过程，开发人员需要按照编码规范和设计要求，使用合适的编程语言和开发工具，进行代码的编写。
完成编码后，需要进行单元测试，确保编写的代码符合设计要求，并且能够达到预期的功能。
五、集成测试阶段在单元测试通过后，系统进入集成测试阶段。
在这个阶段，各个模块被逐步地组合在一起进行测试，检查模块之间的接口是否正常，是否能够协同工作。
通过集成测试，可以发现并解决系统的集成问题，确保整个系统的功能正常。
六、系统测试阶段系统测试是对整个系统进行全面的测试和验证。
在这个阶段，需要执行各种测试案例，验证系统的功能、性能和稳定性等。
信息系统的开发与管理
信息系统的开发与管理信息系统在现代社会中起着至关重要的作用。
它们帮助组织管理海量的数据、优化业务流程，并提供决策支持。
信息系统的开发与管理是一个复杂的过程，涉及多个环节和关键要素。
本文将探讨信息系统的开发与管理，从需求分析到系统维护，全面阐述这一过程的重要性和有效性。
1. 需求分析在信息系统的开发过程中，需求分析是至关重要的一步。
它确保系统能够满足用户的需求并解决问题。
需求分析包括对用户需求的调研和分析，明确系统功能和性能的要求。
此外，需求分析还考虑系统与其他系统的接口和数据交换。
只有深入了解并满足用户需求，才能开发出高质量的信息系统。
2. 系统设计系统设计是信息系统开发过程中的关键环节。
在这一阶段，开发团队将根据需求分析的结果，设计出符合要求的系统结构和架构。
系统设计涉及到技术选择、数据库设计、用户界面设计等方面。
合理的系统设计能够保证系统的可靠性、安全性和可扩展性。
3. 编码与测试在系统设计完成后，开发团队将开始编写代码并进行测试。
编码是将系统设计转化为实际可执行的程序代码的过程。
编码的质量和效率对系统的最终性能和用户体验有着重要影响。
在编码完成后，测试团队将对系统进行功能测试、性能测试和安全性测试，确保系统的稳定运行和满足用户需求。
4. 系统部署系统部署是将开发完成的系统投入使用的过程。
在这一阶段，开发团队需要配置服务器、安装软件并进行系统的初步调试。
系统部署还包括将系统数据从旧系统迁移到新系统中，确保数据的完整性和连续性。
正确的系统部署能够保障用户顺利过渡到新系统并获得良好的使用体验。
5. 系统维护系统维护是信息系统开发与管理的一个重要环节。
它包括对系统的日常监控、故障排除和改进。
保持系统的稳定性和安全性是系统维护的首要任务。
同时，根据用户的反馈和需求变化，开发团队需要及时对系统进行更新和优化，以提供更好的服务和用户体验。
信息系统的开发与管理需要多方面的专业知识和技能。
同时，团队合作和沟通也是成功的关键。
信息系统开发与项目安全管理规定
信息系统开发与项目安全管理规定第一章总则第一条为规范科技发展部信息系统开发相关安全控制，保障信息系统本身的安全性以及开发、测试和投产过程的安全性，规范信息系统获取、开发与维护过程中的职责定义与流程管理，特制定本规定。
第二条本规定适用于科技发展部范围内的信息系统获取、开发、实施、投产各过程及项目实施的管理。
第二章组织与职责第三条科技发展部风险管理组负责制定相关规定，并监督各部门落实情况。
第四条各部门安全组负责监督和检查本规定在本部门的落实情况。
第五条项目需求部门除提出功能需求外还负责在相关部门的协助下提出系统安全需求。
第六条项目建设部门承担具体信息系统设计、开发实施，负责进行系统安全需求分析。
保证系统设计、开发、测试、验收和投产实施阶段满足项目安全需求和现有的系统安全标准和规范。
组织系统安全需求、设计和投产评审。
第三章信息系统开发与项目安全管理规定第七条信息系统建设项目各阶段（尤其是需求设计、测试及投产等重要阶段）评审时，评审内容必须包括相应的安全要求，具体要求参见附件2：信息安全功能设计检查列表。
第八条系统安全评审时，应提交相应安全设计、实现或验证材料，对于评审中发现的问题相关责任部门应及时整改。
第九条对于公共可用系统及重要信息数据的完整性应进行保护，以防止未经授权的修改。
同时，网上公开信息的修改发布遵循业务部门的相关管理规定，只有经过授权流程后才能修改相应信息。
第十条安全需求分析（一）在项目的计划阶段，项目需求部门与项目建设部门讨论并明确系统安全需求分析，作为项目需求分析报告的组成部分。
（二）项目需求部门与项目建设部门应对系统进行风险分析，考虑业务处理相关流程的安全技术控制需求、生产系统及其相关在线系统运行过程中的安全要求，在满足相关法律、法规及规章、技术规范和标准等约束条件下，确定系统的安全需求。
（三）系统安全保护遵循适度保护的原则，需满足以下基本要求，同时实施与业务安全等级要求相应的安全机制：1.采取必要的技术手段，建立适当的安全管理控制机制，保证数据信息在处理、存储和传输过程中的完整性和安全性，防止数据信息被非法使用、篡改和复制。
iso27001控制域
iso27001控制域ISO 27001控制域是国际标准化组织（ISO）制定的信息安全管理体系（ISMS）的核心要素之一。
该标准规定了一个包含14个控制域和114个控制措施的框架，用于保护组织的信息资产及相关资源。
1. 安全政策（A.5）安全政策是组织制定和实施信息安全管理体系的基础。
它应明确规定信息安全目标、责任和权限，确保管理层对信息安全的重视，并为整个组织提供一个明确的方向。
2. 组织（A.6）组织控制域主要关注信息安全管理体系的建立和维护。
其中包括确定信息安全角色和责任、分配资源、制定安全规章制度以及开展内部审核和管理评审等。
3. 人力资源安全（A.7）人力资源安全控制域旨在确保组织的员工和相关方对信息安全的意识和责任。
它包括招聘、培训、绩效评估和合同管理等方面的控制措施，以确保员工在信息安全方面具备必要的能力和素质。
4. 资产管理（A.8）资产管理控制域关注组织的信息资产及其相关资源的保护。
该控制域要求组织对信息资产进行分类、标记、归档和备份，以确保其安全性和可用性。
5. 访问控制（A.9）访问控制控制域旨在防止未经授权的访问和使用信息资产。
它包括对物理和逻辑访问进行控制，确保只有授权的人员能够获得相应的权限和资源。
6. 密码策略（A.10）密码策略控制域重点关注密码的保护和管理。
该控制域要求组织制定密码策略，包括设定密码复杂度、定期更换密码、禁止共享密码等，以确保密码的安全性。
7. 物理与环境安全（A.11）物理与环境安全控制域要求组织采取适当的措施，保护信息资产免受物理和环境威胁。
这包括控制访问、防火墙、监控设备和灾难恢复计划等。
8. 通信与运营管理（A.12）通信与运营管理控制域关注组织的通信和运营过程的安全性。
它包括网络安全、电子邮件安全、供应商关系管理等，以确保组织的信息通信和运营过程的安全性。
9. 系统获取、开发和维护（A.13）系统获取、开发和维护控制域要求组织在系统开发和维护过程中考虑信息安全。
信息系统采购、开发和维护制度
信息系统采购、开发和维护制度11.1 系统安全需求11.1.1 系统的安全需求分析与范围第243条在系统开发的整个过程（特别是在系统需求阶段）都必须考虑安全需求，包括但不限于：1)系统架构2)用户认证3)访问控制和授权4)事务处理的机密性和完整性5)日志记录功能6)系统配臵7)法律法规和兼容性要求8)系统恢复第244条在系统的需求和设计阶段，需要对系统进行安全方面的评审。
第245条应该在开发的整个周期对安全需求实施的正确性进行阶段性检查，以确保其对应的安全措施按照要求被定义、设计、部署和测试。
第246条在使用商业软件或软件包前，必须按照上述安全需求进行评估。
对于软件的安全控制要求应该在评估之前定义好。
第247条软件必须通过用户的正式验收后才能投入生产。
软件在正式使用前必须经过安全方面的测试，测试内容必须包括所有设计文档中的安全要求。
第248条为了对用户的操作进行检查和审计，系统必须提供日志记录功能。
系统应提供只有日志审计人员可以访问的用来查看日志记录的审计接口。
日志文件必须设臵严格的访问控制，包括系统管理员、日志审核员在内所有角色都只能有查看权限。
11.2 应用系统中的安全11.2.1 数据输入的验证第249条所有接受数据输入的入口必须有相应的验证处理，包括但不限于：1)数据的长度2)数据的类型3)数据的范围4)字符的限制第250条根据业务需要，对于按照纸面信息输入的数据，系统应该提供“数据在输入被确认”之后才能提交的功能。
第251条系统应该对错误的输入数据提供有帮助的提示信息。
必须对数据输入验证功能进行全面的测试，以保证其正确性和有效性。
系统在使用过程中，应该明确定义参与数据输入各环节所有相关人员的职责。
11.2.2 内部处理的控制第252条应用系统的设计应该考虑以下因素，防止正确输入的数据因错误处理或人为因素等遭到破坏：1)程序应该有处理的校验机制2)程序应该有相应的例外处理机制3)对于有先后执行顺序的程序或程序模块，内部必须有执行顺序的限制机制第253条控制措施的选择应根据应用的性质和数据受损对业务造成的影响而定，可选择的措施包括但不限于：1)会话或批处理控制措施，在事务更新后协调相关数据文件的一致性2)验证系统生成数据的正确性3)检查数据完整性，特别是在计算机之间传输的数据4)计算记录和文件的哈希值以便验证5)确保程序以正确的顺序运行，在出现故障时终止，在问题解决前暂停处理11.2.3 消息验证第254条对需要确保消息内容完整性的应用（例如电子交易）应该使用消息验证。
BS7799 安全 标准简介
BS7799 标准简介BS7799是英国标准协会(British Standards Institute，BSI)于1995年2月制定的信息安全标准，1999年5月，BSI对BS 7799进行了修订改版，发展成为后来最主要的一个版本，2000年1月，BS 7799内容中的第一部分被ISO采纳，正式成为ISO/IEC 17799标准。
BS7799分两个部分第一部分，也就是纳入到ISO/IEC 17799:2000标准的部分，是信息安全管理实施细则(Code of Practice for Information Security Management)，主要供负责信息安全系统开发的人员作为参考使用，其中分十个标题，定义了127个安全控制。
BS7799-1:1999（ISO/IEC 17799:2000）中的十个内容标题分别是·安全策略Security policy·资产和资源的组织Organization of assets and resources·人员安全Personnel security·物理和环境安全Physical and environmental security·通信和操作管理Communication and operation management·访问控制Access control·系统开发和维护System development and maintenance·业务连续性管理Business continuity management·符合性Compliance第二部分，是建立信息安全管理体系(ISMS)的一套规范(Specification for Information Security Management Systems)，其中详细说明了建立、实施和维护信息安全管理系统的要求，指出实施机构应该遵循的风险评估标准，当然，如果要得到BSI最终的认证(对依据BS7799-2建立的ISMS进行认证)，还有一系列相应的注册认证过程。
信息系统开发的流程与需求分析方法
信息系统开发的流程与需求分析方法信息系统开发是一个复杂而庞大的工程，需要经过一系列的流程和方法来确保项目的成功实施。
本文将介绍信息系统开发的流程以及常用的需求分析方法，以帮助读者更好地理解和应用于实际项目中。
一、信息系统开发的流程信息系统开发的流程通常包括以下几个阶段：需求分析、系统设计、编码与测试、部署与维护。
下面将对每个阶段进行详细介绍。
1. 需求分析阶段需求分析是信息系统开发的第一步，它的目的是明确用户的需求和系统的功能。
在这个阶段，开发团队需要与用户进行深入的沟通和交流，了解用户的业务流程、需求和期望。
常用的需求收集方法包括面谈、问卷调查和观察等。
2. 系统设计阶段系统设计是在需求分析的基础上，根据用户需求和功能要求设计系统的框架和结构。
在这个阶段，开发团队需要制定系统的架构、数据库设计、界面设计等。
常用的系统设计方法包括结构化设计和面向对象设计等。
3. 编码与测试阶段编码与测试阶段是将系统设计转化为实际的代码，并进行测试和调试的过程。
开发团队需要按照设计的要求编写程序代码，并进行单元测试、集成测试和系统测试等。
常用的编码和测试方法包括结构化编程和测试驱动开发等。
4. 部署与维护阶段部署与维护阶段是将开发完成的系统部署到实际的生产环境中，并进行后续的维护和优化工作。
在这个阶段，开发团队需要协助用户进行系统的安装、数据迁移和培训等工作。
同时，还需要及时修复系统中出现的问题和进行性能优化等。
二、需求分析方法需求分析是信息系统开发中至关重要的一步，它直接关系到系统最终的质量和用户的满意度。
下面介绍几种常用的需求分析方法。
1. 数据流图数据流图是一种图形化的工具，用于描述系统中的数据流动和处理过程。
通过绘制数据流图，可以清晰地了解系统中各个功能模块之间的关系和数据的流向，从而帮助开发团队更好地理解用户的需求。
2. 数据字典数据字典是一种记录系统中数据定义和属性的工具，用于统一和规范数据的命名和描述。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
信息系统获取、开发与维护程序1.目的为确保安全成为所开发的信息系统一个有机组成部分，保证开发过程安全，特制定本程序。
2.范围
2.1适用于本公司所有信息系统的开发活动中，信息系统内在安全性的管
理。
本程序作为软件开发项目管理规定的补充，而不是作为软件开发项目管理的整体规范。
2.2开发过程中所形成的需求分析文档、设计文档、软件代码、测试文档
等技术信息的管理应遵从信息资产密级管理的有关规定，本程序不在另行规定
3.术语及定义
无
4.引用文件
4.1下列文件中的条款通过本规定的引用而成为本规定的条款。
凡是注日
期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励各部门研究是否可使用这些文件的最
新版本。
凡是不注日期的引用文件，其最新版本适用于本标准。
4.2ISO/IEC 27001:2005 信息技术-安全技术-信息安全管理体系要求
4.3ISO/IEC 17799:2005 信息技术-安全技术-信息安全管理实施细则
4.4信息资产密级管理规定
5.职责和权限
开发部是信息系统开发过程中的安全管理部门, 负责保证开发过程安全。
6.工作程序
6.1控制措施-对信息系统进行安全性需求分析与相关规格说明
6.1.1目标：在描述新系统或改进原有系统的业务需求时，应收
集、分析系统在安全性方面的需求，并在系统需求规格说明书详细
描述。
6.1.2安全性需求包括两方面的内容，一是对系统本身的安全需求，如
系统具备数据通信加密、用户身份鉴别等功能，在确定安全要求
时，要考虑系统中的自动安全控制和支持人工安全控制的要求；
二是对系统设计开发过程本身也要进行控制，例如在不同的设计
开发阶段的评审与验证，确保对程序源代码的保护、对设计人员
的控制等。
6.1.3安全要求在软件开发生命周期中的分布如下图所示：
6.1.4在使用新的应用程序或增强现有的应用程序时必须做安全性影响分
析, 由信息系统项目经理提交安全需求分析。
内容可包括以下
项：
1)确认需要保护的资产。
2)评估这些资产需要采取什么安全控制措施。
3)考虑是否在系统中加入自动安全控制措施还是建立人工安全控
制措施。
4)在软硬件采购时，应尽量使用经过专业评估和认证的产品。
6.2在应用中建立安全措施
6.2.1控制措施- 输入数据验证
6.2.1.1控制描述- 输入应用系统的数据应加以验证，以确保数据是
正确的。
6.2.1.2实施指南- 应该校验应用于业务交易、常备数据和参数表的
输入信息。
需要考虑下列(但不仅限于)内容：
1)输入校验，诸如边界校验或者限制特定输入数据范围的域，以
检测下列错误：
a)范围之外的值；
b)数据字段中的无效字符；
c)丢失或不完整的数据；
d)超过数据的上下容量限制；
e)未授权的或矛盾的控制数据；
f)业务流程、系统安全运行、法规政策等方面所要求的数据
校验；
2)定期评审关键字段或数据文件的内容，以证实其有效性和完整
性；
3)检查硬拷贝输入文档是否有任何未授权的变更 (输入文档的所
有变更均应予以授权)；
4)对输入数据验证错误后的处理程序；
5)测试输入数据合理性的程序；
6)定义在数据输入过程中所涉及的全部人员的职责。
7)创建在数据输入过程中所涉及的活动的日志。
8)其它信息-适当时，可以考虑对输入数据进行自动检查和验
证，以减少出错的风险和预防包括缓冲区溢出和代码注入等普
通的攻击。
6.2.2控制措施- 内部处理的控制
6.2.2.1控制描述- 应用中需要验证检查由于处理错误或故意行为造
成的信息讹误。
6.2.2.2实施指南- 应用系统的设计与实现应尽量减少处理故障时对
数据完整性的损坏。
需要考虑下列(但不仅限于)内容：
1)通过添加、修改和删除功能实现数据变更；
2)防止程序以错误次序运行；
3)使用适当的程序恢复故障，以确保数据的正确处理；
4)防范利用缓冲区超出/ 溢出进行的攻击。
6.2.2.3应准备适当的检查列表，将检查活动文档化，并应保证检查
结果的安全。
需要考虑下列(但不仅限于)检查例子：
1)验证系统生成的输入数据；
2)检查在中央计算机和远程计算机之间所下载或上载的数据或
软件的完整性、真实性或者其他任何安全特性；
3)记录文件字节大小；
4)检查以确保应用程序在正确时刻运行；
5)检查以确保程序以正确的次序运行并且在发生故障时终止，
以及在问题解决之前，停止进一步的处理；
6)创建处理时所涉及的活动的日志。
6.2.2.4其它信息-正确输入的数据可能被硬件错误、处理错误和故
意的行为所破坏。
所需的验证检查取决于应用系统的性质
和毁坏数据对业务的影响。
6.2.3控制措施- 消息完整性
6.2.2.5控制描述- 应用中应该识别确保消息真实性和保护消息完整
性的要求，实施适当的控制措施。
6.2.2.6实施指南- 应进行安全风险的评估以判定是否需要消息完整
性验证，并确定最合适的实施方法。
6.2.2.7其它信息- 密码技术可被用作一种合适的实现消息鉴别的手
段。
6.2.4控制措施- 输出数据验证
6.2.4.1控制措施-从应用系统输出的数据应加以验证，以确保对所
存储信息的处理是正确的且适于当前运行环境的。
6.2.4.2实施指南-输出验证可以包括(但不仅限于)以下内容：
1)合理性检查，以测试输出数据是否合理；
2)调节控制措施的数量，以确保处理所有数据；
3)为读者或后续的处理系统提供足够的信息，以确定信息的
准确性、完备性、精确性和分类；
4)对输出数据验证结果进行处理程序；
5)定义在数据输出过程中所涉及的全部人员的职责。
6)创建在数据输出验证过程中活动的日志。
6.2.4.3其它信息-一般来说，系统和应用是在假设已经进行了适当
的验证、确认和测试的条件下构建的，其输出总是正确
的。
然而，这种假设并不总是有效；例如，已经过测试的
系统仍可能在某些环境下产生不正确的输出
6.3开发和支持过程中的安全
6.3.1系统测试数据的保护
6.3.1.1控制措施- 测试数据应认真地加以选择、保护和控制。
6.3.1.2实施指南- 应避免使用包含个人信息或其它敏感信息的运行
数据库用于测试。
如果测试使用了个人或其他敏感信息，那
么在使用之前应去除或修改所有的敏感细节和内容。
当用于
测试时，应使用下列(但不仅限于)指南保护运行数据：
1)应用于运行应用系统的访问控制程序，还应用于测试应用系
统；
2)运行信息每次被拷贝到测试应用系统时应有独立的授权；
3)在测试完成之后，应立即从测试应用系统清除运行信息；
4)应记录运行信息的拷贝和使用日志以提供审核踪迹。
6.3.1.3其它信息- 系统验收测试常常要求相当多的尽可能接近运行
数据的测试数据。
6.3.2对程序源代码的访问控制
6.3.2.1 控制措施-应限制访问程序源代码。
6.3.2.2实施指南-对程序源代码和相关事项(诸如设计、说明书、确
认计划和验证计划)的访问应严格控制，以防引入非授权功
能和避免无意识的变更。
对于程序源代码的保存，通过代码
集中存储控制来实现，放在公司统一的配置管理库中。
应考
虑下列(但不仅限于)指南：
1)若有可能，在运行系统中不应保留源程序库；
2)程序源代码和配置管理库应进行规范管理；
3)应限制支持人员访问配置管理库；
4)更新配置项，向程序员发布程序源码应在获得适当的授权
5)应维护对配置库所有访问的审核日志；
6)维护配置库应该有规范的制度。
6.3.2.3其它信息-程序源代码是由程序员编写的代码，经编译(和链
接)后产生可执行代码。
特定程序语言不能正式区分源代码
和可执行代码，这是因为可执行代码是在它们被激活时产
生的。
6.3.3 外包软件开发
6.3.3.1 控制措施- 组织应管理和监视外包软件的开发。
6.3.3.2 实施指南-在外包软件开发时，应考虑下列(但不仅限
于)各
1)许可证安排、代码所有权和知识产权；
2)所完成工作的质量和准确性的认证；
3)第三方发生故障时的契约安排；
4)审核所完成的工作质量和准确性的访问权；
5)代码质量和安全功能的合同要求；
6)在安装前，测试恶意代码和特洛伊木马。
7.相关支持文件
8.记录
9.附录。