内部审计-信息系统一般控制审计(ppt 153页)

信息系统审计 20 一级章节 第六章 信息系统一般控制审计 第一节 信息系统硬件 一、硬件获取 (一 ) 招标书 信息系统审计 21 1.组织环境 2.处理需求 3.硬件需求 4.系统软件 5.支持需求 6.适应需求 7.实施需求 8.约束条件 (二 ) 获取步骤 信息系统审计 22 (1)好转时间 发生故障时 ,帮助台或厂商从登录系统到解决问题所需的时间。 (2)响应时间 系统响应一个特定的用户查询所需的时间。 (3)吞吐量 单位时间内系统的有效工作量 ,吞吐量的衡量指标可以是每秒执行的指令。 (4)数或其他性能单位。 (5)负载 执行必要工作的能力 ,或系统在给定时间区间内能完成的工作量。 (6)兼容性 供应商提供的新系统对现有应用的运行支持能力。 (7)容量 新系统处理并发网络应用请求的数目 ,以及系统能够为每个用户处理的数据量。 (8)利用率 新系统可用时间与故障时间之比。 (三 ) 硬件获取过程的控制与审计 信息系统审计 23 二、硬件维护 三、硬件监控 (一 )硬件错误报告 (二 )可用性报告 (三 )利用率报告 四、硬件的容量管理 信息系统审计 24 第二节 信息系统软件 一、信息系统软件组成 (一 ) 操作系统 (二 ) 数据库管理系统 1.程序开发的难易程度 2.数据库管理系统的性能分析 3.对分布式应用的支持 信息系统审计 25 4.并行处理能力 5.可移植性和可扩展性 二、软件获取与实施 第三节 访问控制 一、制定访问控制的制度、程序和计划 信息系统审计 26 (一 ) 访问控制要求 (二 ) 形成访问控制策略文件 二、实施有效的识别和认证机制 三、实施有效的授权控制 (一 ) 管理用户账号 (二 ) 控制进程和服务 四、执行有效的审计和监督 1.制订并核准有效的事件应对计划 信息系统审计 27 2.有效记录并确认事件 3.正确分析事件并采取适当行动 五、物理访问控制 第四节 职责分离 一、制定职责分离的管理制度 信息系统审计 28 二、员工明确其岗位职责 三、对关键岗位进行监控 第五节 一般控制审计程序 一、系统环境控制审计 (一 )物理环境的检查 信息系统审计 29 (二 )逻辑环境的检查 (三 )硬件基础设施的检查 (四 )软件设施的检查 二、系统访问控制审计 (一 )逻辑访问控制审计 (1)验证逻辑访问路径。 (2)检查逻辑访问控制软件。 (3)检查身份识别与验证。 (4)检查逻辑访问授权。 信息系统审计 30 (5)检查远程访问控制。 (6)利用审计日志检测系统访问。 (二 )物理访问控制审计 三、系统网络架构控制审计 (一 )局域网风险与控制审计 (二 )客户机 /服务器架构安全审计 (三 )互联网安全控制审计 (四 )网络安全技术应用的审计 信息系统审计 31 (五 )网络基础架构审计 (1)审核网络拓扑图 ,确定网络结构及设施。 (2)审核对局域网的控制 ,保证体系结构的设计和选择遵循了适当的标准 ,以及获取和运行成本不 超过其效益 ,包括物理控制审核、环境控制审核、逻辑控制审核。 (3)远程访问审核。 (4)网络穿透测试。 (5)网络变更控制审核。 四、数据与数据库安全控制审计 (1)审核信息系统在数据处理、传输过程中的数据加密、数字签名、数字信封、数字证书认证等 安全策略控制是否完整有效 ,评价系统数据的机密性、完整性和可靠性。 信息系统审计 32 (2)审核数据库的存取管理、安全管理和数据库加密技术 ,评价数据库的安全性。 (3)审核数据库用户的角色、权限管理、身份验证和访问控制等安全控制 ,评价数据库的安全性。 (4)审核数据库的备份和恢复策略 ,检查备份数据存放、安全、维护管理 ,确保数据库的可用性。 五、灾难恢复与业务持续性审计 (1)评价被审计单位的业务持续性策略及其与业务目标的符合性、充分性和有效性。 (2)审核信息系统和终端用户以前所作测试的结果 ,验证业务持续性计划的有效性。 (3)审核异地应急措施及其内容、安全和环境控制 ,评估异地存储站点的适当性。 (4)审核应急措施、员工培训、测试结果 ,评估信息系统和终端用户在紧急情况下的有效反应能力 。 信息系统审计 33 (5)审核被审计单位对业务持续性计划的维护措施。 第七章 信息系统应用控制审计 第一节 数据输入控制 一、数据规划和设计 二、输入授权 信息系统审计 34 (1)在一批表格或源文件上签字 ,提供恰当的授权证据。 (2)在线访问控制 ,保证只有经授权的人可以访问数据或执行敏感的操作。 (3)唯一性口令 ,系统为每个用户分发相互区别的唯一口令 ,用户输入自己的口令来对系统实施授 权的操作并对数据变动承担责任。 (4)终端或客户工作站的识别 ,用于限制系统只接受由特定的终端、工作站和个人输入的信息。 三、校验审查 四、批控制和批平衡 (一 )批控制的类型 (1)总金额 :确认一个批次中被系统处理的项目总金额等于处理前项目金额之和。 信息系统审计 35 (2)总项目数 :确认一个批次中的每一个文件中的项目总数等于被处理的项目总数。 (3)总文件数 :确认一个批次中文件总数等于被处理的文件总数。 (4)杂数总和 :确认一个批次中的所有文件中的数值类字段的总和 (虽然不同类型字段加起来的值 并没有实际意义 )等于系统计算出来的总和。 (二 )批平衡的类型 (1)批注册 :通过注册项对批总计进行人工记录 ,并与系统报告的总计进行比较。 (2)控制账户 :使用控制账户是通过一个初始编辑文件来确定批总计。 (3)计算机一致 :批总计的计算机一致是通过输入记录批总计的批标题细目来执行的。 (4)系统将其与计算出来的总计进行比较 ,再决定接受或拒绝本批次。 信息系统审计 36 五、错误报告和错误处理方法 (1)仅拒绝有错误的事务。 (2)拒绝整批事务。 (3)暂停输入批次。 (4)整批接收并对错误事务做标志。 六、联机系统的输入完整性 七、内部审计与监测 信息系统审计 37 第二节 数据处理控制 一、规范的数据处理程序 二、数据确认和编辑检查程序 (1)顺序检查。 (2)极限检查。 (3)范围检查。 (4)有效性检查。 信息系统审计 38 (5)合理性检查。 (6)查表。 (7)存在性检查。 (8)击键校验。 (9)校验数位。 (10)完整性检查。 (11)重复检查。 (12)逻辑关系检查。 三、处理控制 信息系统审计 39 (1)人工重新计算 :可以对某一个事务进行采样 ,由人工进行重新计算 ,并将其与计算机的处理结果 相比较以确保计算机处理完成了预期的任务。 (2)编辑检查 :编辑检查可以是一个程序指令或一个子程序 ,它用来测试数据的准确性、完整性和 有效性。 (3)程序化控制 :可以通过软件来检查和纠正数据错误和处理错误。 (4)计算量的合理性检查 :应用程序能确认计算量的合理性 ,任何被确认为不合理的事务将被拒绝 并挂起以备进一步检查。 (5)计算量的极限检查 :如果某计算量没有被正确的键入 ,可以通过预定义范围限制的编辑检查来 进行控制。 (6)文件总数核对 :应当经常性地运行此控制 ,核对是通过使用一个人工维护账户、一个文件记录 或一个独立的控制文件来执行。 信息系统审计 40 (7)例外报告 :由识别不正确的事务或数据的程序产生的文档 ,通常报告的例外内容是预定义范围 之外 ,或是与特定的标准不一致的那些项目。 四、文件控制 (1)处理前和处理后的数据映象报告 :应当对事务处理前或处理后存入文件中的计算机数据进行记 录并出具报告 ,有了事务处理前后的两种数据映像 ,使得在计算机记录中追踪有影响的事务成为可 能。 (2)错误报告的维护和操作 :应当有控制程序来保证所有的错误报告被正确地核对与纠正 ,并适时 地提交。 (3)源文件保存期 :源文件应当保存一个足够的时间期间 ,以确保对数据检索、重组和验证的需要 。 (4)标签 :必须为可移动存储介质设定内外部标签 ,以保证适当的数据被调用和处理。 信息系统审计 41 (5)版本 :使用正确和适当的文件版本对于正确的处理是非常关键的。 (6)一对一检查 :确保每一个文件都与经计算机处理的详细文件清单相符合 ,这对于保证所有的文 件都已经被接受处理是非常必要的。 (7)预录输入 :特定的信息字段已被预印在空白的输入表单上以减少输入错误。 (8)文件更新和维护授权 :适当的文件更新和维护授权可以保证存储数据受到了充分的安全保护 , 保证数据是正确的和及时更新的。 (9)校验检查 :计算机中的数据传输应当在一种无错误的环境中进行 ,但当程序或重要的数据在传 输时 ,有必要增加额外的控制以防出现错误。 五、内部审计与监测 信息系统审计 42 第三节 数据输出控制 一、数据输出报告制度 二、输出报告的生成与分发 三、在安全的地方登记和存储重要表单 四、计算机生成可流通的通知、表单和签名 信息系统审计 43 第四节 数据接口控制 一、接口规划与设计 二、接口处理程序 (一 )完善数据转换机制 (二 )完善数据传输机制 (三 )完善错误处理机制 信息系统审计 44 (四 )完善接口权限控制策略 (五 )完善接口数据处理措施 (六 )完善接口变更流程 第五节 应用控制审计 一、事务流程分析 信息系统审计 45 二、风险评价模型分析应用控制 三、观察和测试用户操作程序 四、数据完整性测试 五、联机事务处理系统中的数据完整性 (1)原子性 :从一个用户的观点来看 ,一个事务在整体上要么是完整的 (即所有相关的数据库表都是 最新的 ),要么什么也不执行。 (2)一致性 :把数据库从一个一致性状态转换到另一个一致性状态时 ,要遵守数据的所有完整性约 束。 (3)隔离性 :每一个事务与其他事务相互隔离 ,因此 ,每一个事务只访问处于一致性状态的数据库数 信息系统审计 46 据。 (4)持久性 :如果给用户的事务报告是完整的 ,则对数据的任何变化都能恢复 ,即使是随后的软件或 硬件出现了故障。 六、测试应用系统 七、持续在线审计 (1)系统控制审计文件和内嵌审计模型 :该技术通过在组织的主机应用系统中内嵌经特别编写的审 计软件 ,使审计人员以可以选择的方式来监控应用系统的使用。 (2)快照 :这种方式记录一个事务从输入到输出各阶段的处理轨迹。 (3)审计钩 :该技术在应用系统中内嵌程序 “钩 ”,像标识符那样起作用 ,在错误或不规范事务失去 控制之前 ,提醒信息系统审计人员采取行动。 信息系统审计 47 (4)整体测试 :该技术在审计对象应用系统的文件中设置虚构的事务 ,信息系统审计人员可以使这 些为特定测试目的而虚构的事务与真实事务一起进入应用系统中运行。 (5)持续和间歇性模拟 :在一个事务的处理运行期间 ,计算机系统模拟应用程序指令的执行。 八、应用控制审计的一般程序 信息系统审计 48 图 71 一般审计程序 信息系统审计 49 九、输入控制审计 (1)对凭证顺序进行校验。 (2)审查是否设置会计科目代码与名称对照文件 ,并对其正确性进行审计。 (3)审查是否设置了对应关系参照文件。 (4)审查信息系统中是否存在数据合理性校验。 (5)审查信息系统是否设定了平衡校验。 (6)审查信息系统日志 ,察看信息系统用户是否制定并遵守输入管理的规则 ,数据输入是否按照输 入管理规则进行。 十、处理控制审计 信息系统审计 50 (1)查阅企业业务及系统文档选取企业主要的业务处理过程和处理控制。 (2)测试这些处理过程是否符合业务逻辑以及控制是否起到了应有的作用 :在系统中进行一些违反 业务逻辑的操作 ,如果操作结果与预期不一致可以检查程序代码。 (3)检查系统运行错误日志和交易日志。 (4)得出处理控制是否适当的结论。 十一、输出控制审计 (1)识别主要的输出项目。 (2)确定输出审核程序的恰当性 : 审查输出信息分发前对输出信息进行审核确认的程序 ; 审查 输出分发程序的恰当性 ; 评价用户部门验证输出信息完整准确的程序 ; 确定输出信息对用户 是否实用 ; 确定是否有恰当的人员执行输出审核。 信息系统审计 51 (3)审核输出总数核对程序。 (4)确定敏感数据项目是否被恰当控制。 (5)审核输出资料保留存放的过程。 (6)得出输出控制是否恰当的结论。 十二、接口审计 第八章 信息系统开发审计 信息系统审计 52 第一节 信息系统审计师在信息系统开发中的职责 (1)获取过程 确定信息系统需求 ,获取系统、软件产品或软件服务的活动。 (2)供应过程 确定信息系统提供者 ,向信息系统需求者提供系统、软件产品或软件服务的活动 。 (3)开发过程 确定信息系统开发者 ,定义并开发软件产品的活动。 (4)运作过程 确定信息系统操作者 ,在规定的环境中为用户提供运行计算机系统服务的活动。 (5)维护过程 确定信息系统维护者 ,提供维护软件产品服务的活动。 信息系统审计 53 第二节 传统的信息系统开发方法 (1)当系统开发生命周期的每一个阶段都可以由正式的程序和指南来确定时 ,审计师可以较深入地 了解开发过程中的风险 ,信息系统审计师对开发的控制作用显著增加了。 (2)信息系统审计师可以评价系统开发项目的所有相关阶段和领域 ,并独立地向管理层报告预定目 标的完成情况和相关程序的遵守情况。 (3)生命周期方法有助于信息系统审计师识别所选择评价的各个系统部分应当具有的属性 ,并基于 他们的技能和能力 ,进一步深入技术层面去发现存在的问题。 (4)信息系统审计师可以对生命周期开发阶段所使用的方法和技术进行评价。 信息系统审计 54 图 81 相关阶段 信息系统审计 55 表 81 传统的系统开发生命周期 SDLC各个阶段 总体描述 第一阶段 :可行性研究 确定实施系统在提高生产率或未来 降低成本方面的战略利益 ,确定和量 化新系统可以节约的成本 ,评价发生 在一个新系统上的成本回收期。这 个阶段的工作将为开发工作是否继 续进行到下一个阶段提供一个恰当 的理由 信息系统审计 56 表 81 传统的系统开发生命周期 第二阶段 :需求定义 一是定义需要解决的问题 ;二是定义 所需的解决方案及方案应当具有的 功能和质量要求。这个阶段要决定 是采用定制开发的方法 ,还是采用供 应商提供的软件包 ,如果要购买商品 化的软件包 ,就需要遵循一个预定义 的、文件化的获取过程。不论哪种 情况 ,用户都必须积极地参与其中 信息系统审计 57 表 81 传统的系统开发生命周期 第三阶段 (A):设计 (当决定自行开发软件时 ) 以需求定义为基础 ,建立一个系统基 线和子系统的规格说明 ,以描述系统 功能如何实现 ,各个部分之间接口如 何定义 ,系统如何使用已选择的硬件 、软件和网络设施等。一般而言 ,设 计也包括程序和数据库规格说明 ,以 及一个系统安全计划。另外 ,建立一 个正式的变动控制程序来预防将不 受控的新需求输入到开发过程中的 可能性 信息系统审计 58 表 81 传统的系统开发生命周期 第三阶段 (B):选择 (当决定购买现成软件包时 ) 以需求定义为基础 ,向软件供应商发 出请求建议书 (RFP)。商品软件的 选择除了要考虑软件功能性的需求 、操作性的支持和技术需求外 ,还要 考虑软件供应商的财务生存能力 ,并 与供应商签订软件源代码第三方保 全协议 (Escmw)。在综合以上各种 因素的基础上 ,选择最能满足组织需 要的软件供应商 信息系统审计 59 表 81 传统的系统开发生命周期 第四阶段 (A):开发 (当决定自行开发软件时 ) 使用设计规格说明书来设计编程和 规范化系统的支持操作过程。在这 个阶段 ,要进行各个层次的测试 ,以 验证和确认已经开发的内容 ,包括所 有的单元测试、系统测试 ,也包括用 户接受测试涉及的迭代工作 信息系统审计 60 表 81 传统的系统开发生命周期 第四阶段 (B):配置 (当决定购买现成软件包时 ) 如果决定选用商品化的软件包 ,需要 按照组织的要求对其进行剪裁。这 种剪裁最好是通过配置系统参数 ,而 不是通过修改程序源代码来实现。 现在的软件供应商提供的软件一般 都较灵活 ,通过对软件包中参数表进 行配置或控制某些功能的开关 ,就可 以使软件满足组织的特定需要。但 可能还要建立接口程序以满足与已 有系统进行连接的需要 信息系统审计 61 表 81 传统的系统开发生命周期 第五阶段 :实施 把新系统投入到实际运行中去。这 个阶段是在最终用户验收测试完成 、签署正式文件后进行。系统还需 要通过一些认证和鉴定过程 ,来评价 应用系统的有效性。这些鉴定过程 的主要目标有 :评价业务应用系统是 否将风险降低到一个适当的水平 ;在 符合预定目标和建立一个适当的内 部控制水平方面 ,是否提供了管理层 为确保系统有效性而应负的责任 信息系统审计 62 表 81 传统的系统开发生命周期 第六阶段 :维护 随着一个新系统或彻底修改的系统 的成功实施 ,应当建立正式的程序来 评估系统的充分性和评价成本效益 或投资回报。这样做可以使信息系 统项目组和最终用户部门吸取经验 教训 ,并就目前系统中存在的不足 , 为后续的系统开发项目管理提供改 进建议 信息系统审计 63 (1)无法预料的事件。 (2)按照这个方法的要求 ,对用户需求的准确定义是非常重要的 ,但在开发初期要从用户处获得一 个完整的、清晰的需求是很困难的。 (3)需要用户有足够的耐性。 (4)在软件正式开发完成前 ,组织业务环境的改变会引起用户需求的变化。 第三节 其他信息系统开发方法 一、原型法 信息系统审计 64 图 82 原型法的开发过程 (1)遵循人们认识事物的规律 ,采用循序渐进的过程去开发和认识系统。 信息系统审计 65 (2)将模拟手段引入系统分析 ,便于用户和系统分析人员之间的沟通。 (3)充分利用最新工具软件 ,减少系统开发时间和费用 ,提高效率。 (1)完成的系统在控制机制方面一般较弱。 (2)变更控制也变得更加复杂。 (3)对于大量运算、逻辑性强的程序模块 ,原型法很难构造出适宜模型 ,以供用户评价。 (4)对于大型系统如果没有系统地进行整体性划分 ,很难进行模拟。 二、面向对象开发方法 (Object-Oriented Software Develop- ment,OOSD) 信息系统审计 66 图 83 面向对象的系统开发过程 (1)对系统进行调查 ,并进行需求分析。 信息系统审计 67 (2)抽象地识别出对象及其行为、结构、属性、方法等 ,建立类之间的层次与链接关系 ,根据需求 与功能建立系统的分析模型。 (3)对面向对象分析阶段确定的分析模型进行进一步抽象、归类、整理 ,最终以范式的形式将它们 确定下来。 (4)用面向对象的程序设计语言将设计阶段整理的范式直接映射成应用程序软件。 (1)采用特定的软件工具 ,直接完成从对象客体的描述到软件结构之间的转换。 (2)解决了传统方法中客观世界描述工具和软件结构不一致的问题 ,缩短开发周期 ,解决了从分析 到设计到软件模块结构之间多次转换映射的繁杂过程。 (3)面向对象的方法中的继承机制 ,支持了模型与代码在一个系统中的重用 ,大大降低了软件系统 的复杂性 ,提高了开发效率。 (4)面向对象的封装性简化了开发过程。 (5)在一般情况下的开发 ,由于类的封装性、多态性的支持 ,无须对系统进行修改 ,这样减少了开发 信息系统审计 68 的工作量和错误的产生 ,增强系统对环境变化的适应性。 三、基于组件的开发方法 (Component-Based Development) (1)过程内客户端组件 :组件必须在一个容器内部运行 ,而不能独自运行 ,如网络浏览器。 (2)独立客户端组件 :将应用导出给其他软件的应用可以当做组件 ,如微软的 Office组件。 (3)独立服务器端组件 :运行在服务器上 ,能够以标准方式提供服务的过程可以当做组件。 (4)过程内服务器组件 :这些组件运行在服务器容器内部。 (1)减少开发时间。 (2)改善质量。 (3)能够从商家买到可证实的、经过测试的软件。 信息系统审计 69 (4)允许开发商更加关注业务功能。 (5)加强模块性。 (6)重用性。 (7)减少开发成本。 (8)支持多用户开发环境。 (9)允许在构造和购买的选择之间进行协调。 (10)便于系统重构 ,即重用设计和程序组件 ,更新现有系统 ,用于支持组织操作方式的主要变更。 四、基于 Web应用开发方法 (Web-Based Application Devel- opment) 信息系统审计 70 图 84 Web服务的基本架构 (1)应用的分布式。 (2)应用到应用的交互。 (3)平台无关性。 信息系统审计 71 五、快速应用开发方法 (RAD) (1)概念定义阶段 ,定义业务功能和系统所要支持的数据主题域 ,决定系统范围。 (2)功能设计阶段所采用的工作组 ,将系统数据和过程模型化 ,建立关键系统组件的原型。 (3)开发阶段完成物理数据库和应用系统的构建 ,建立转换系统 ,开发用户帮助 ,部署工作计划。 (4)安装阶段包括所有最终用户测试和培训、数据转换、应用系统实施。 六、敏捷开发 (Agile Development) (1)较低的管理成本和高质量的产出。 (2)尊重人性。 (3)沟通和反馈。 信息系统审计 72 (4)客户是上帝。 (5)保持活力。 第四节 信息系统开发团队、角色和责任 (1)高级管理层 (Senior Management) 承诺对项目负责并批准完成该项目所必需的资源 ,来自于 高层的承诺有助于推动项目的完成。 (2)用户管理层 (User Management) 拥有项目和最终系统的所有权 ,派遣合格的用户代表到项目 团队中 ,积极地参与系统的需求定义、验收测试和用户培训。 信息系统审计 73 (3)项目指导委员会 (Project Steering Committee) 项目指导委员会对项目工作提供总体指导 ,并 确保对项目有影响的各方都能参与到项目决策中来。 (4)项目发起人 (Project Sponsor) 为项目提供基金 ,并与项目经理配合工作以定义项目成功的衡 量标准。 (5)系统开发管理部门 为有效地开发、安装和运行所要求的应用系统 ,要对软件和硬件环境提 供必要的技术支持。 (6)项目经理 对项目进行日常管理工作 ,确保项目中的每一项活动与整体的方向保持一致。 (7)系统开发项目小组 目标是完成分配的开发任务。 (8)用户项目小组 目标是完成分配的工作任务 (主要是配合需求调查和进行验收测试 )。 (9)安全官员 基于公司安全政策和程序的数据分类 ,确保系统控制和支持过程可以提供有效的 保护水平 ;在系统开发的整个生命周期中 ,对如何在系统中引入适当的控制措施提供咨询意见 ;评 信息系统审计 74 价安全测试计划并在实施之前进行报告 ;为了鉴定合格 ,评估与系统安全相关的文件。 (10)质量保证 (Quality Assurance) 在每一个开发阶段期间和阶段结束时 ,评价阶段结果 ,并确认 与需求的符合性。 第五节 与软件开发相关的风险 (1)在项目内部 没有识别处理业务问题的正确需求或时机 ;没有在规定的时间内和在成本约束 的条件下管理好要交付的项目。 (2)和供应商之间 没有与供应商就需求和期望进行明确地沟通 ,导致供应商没有或不能按时以 信息系统审计 75 预期的成本交付合格的产品。 (3)在组织内部 组织中的利益相关者 (如股东、员工等 )不能提供项目所需要的输入和承诺的 资源 ,而且改变了原定的组织优先级和政策。 (4)和外部环境之间 客户、竞争者、立法部门、政府部门等外部实体的相关活动对项目的影 响 ;经济条件的变化对项目造成的影响。 (1)项目符合公司的业务目标。 (2)包括了有效的资源和时间估计的项目计划。 (3)如果不存在软件基线管理 ,那么就需要控制开发范围的膨胀 ,防止用户需求的不断变化使得开 发过程失去控制。 (4)管理层对软件设计和开发活动的追踪与监控。 (5)高级管理层对软件项目的设计和开发的支持。 信息系统审计 76 (6)在每一个项目阶段进行阶段性的审核和风险分析。 第六节 IT项目管理 一、 IT项目 (一 ) IT项目 (1)硬件系统环境设计 ,这包括网络环境的设计方案、施工方案、设备选型、采购计划和兼容性等 方面的内容。 信息系统审计 77 (2)设计软件系统方案 ,选择或开发应用软件系统。 (3)规划和整理数据资源并应用于软件系统中。 (4)建立信息系统的运行规则 ,并组织知识体系。 (5)为建设一个让使用者满意的信息系统 ,项目的实施者与项目使用者之间进行不断沟通 ,从项目 开始到项目结束。 (二 ) IT项目中的常见问题 (三 ) IT项目成功的标志 二、 IT项目管理 (一 ) IT项目进度管理 信息系统审计 78 (二 ) IT项目成本管理 (1)项目成本的构成 :项目定义与决策成本 ;项目设计成本 ;项目采购成本 ;项目实施成本。 (2)具体的项目成本科目 :人工成本 (各种劳力的成本 );物料成本 (消耗和占用的物料资源费用 );顾问 费用 (各种咨询和专家服务费用 );设备费用 (折旧、租赁费用等 );其他费用 (如保险、分包商的法定 利润等 );不可预见费 (为预防项目变更的管理储备 )。 (3)影响项目成本的因素 :耗用资源的数量和价格 ;项目工期 ;项目质量 ;项目范围。 (4)项目成本管理的控制目标 :基于 WBS、范围说明书、历史信息、资源信息和相关政策以及有 经验人员的资源计划 ;成本估算方法及其工具与技术 ;基于 WBS和进度计划的成本预算 ;项目成本 估算与预算的滚动 ;费用跟踪与偏差计算方法 ;纠偏与变更程序 ;项目成本绩效度量方法 ;沟通与评 估。 (三 ) IT项目质量管理 信息系统审计 79 (四 ) IT项目风险管理 (五 ) IT项目综合管理 (六 ) IT项目文档管理 第七节 IT项目管理及审计 一、 IT项目管理的组织与机制 (一 )组织与团队管理 信息系统审计 80 图 85 团队管理的过程 (二 )IT项目团队管理的特点 信息系统审计 81 (三 )组织设计的控制目标 二、 IT项目范围管理 信息系统审计 82 图 86 项目范围管理 信息系统审计 83 三、 IT项目管理审计 (一 )IT项目管理审计目标 (1)检查项目实施方法、程序是否科学合理。 (2)检查项目实施过程是否受到恰当的控制。 (3)检查实施过程中的文档是否符合规范。 (二 )审计范围 信息系统审计 84 第八节 软件开发过程的完善 一、 ISO 9126 (1)功能性 ,即软件是否满足客户的功能要求。 (2)可靠性 ,即软件是否能够一直在一个稳定的状态上满足可用性。 (3)效率 ,即衡量软件正常运行需要耗费多少物理资源。 (4)可维护性 ,即衡量对已经完成的软件进行调整需要多大的努力。 (5)可移植性 ,即衡量软件是否能够方便地布置到不同的运行环境。 二、软件能力成熟度模型 (CMM) 信息系统审计 85 图 87 CMM的级别 (1)机构缺乏明文的管理办法 ,软件工作没有稳定的环境 ,制订了计划又不执行 ,以反应式驱动工作 信息系统审计 86 开展。 (2)紧急情况下将已订的规程丢在一边 ,急于编码和测试。 (3)个别项目的成功依赖于某个有经验的管理人员。 (4)个别管理人员能顶住削减过程的压力 ,一旦他们离职则全然不同。 (5)规定的过程无法克服 ,缺乏有效的管理。 (6)现象往往表现为过程无一定之规 ,项目进度、预算、功能及产品质量无法保证 ,项目的实施不 可预测。 (1)建立了跟踪成本、进度和功能的基本项目管理过程。 (2)基于以往项目经验 ,制定了过程实施规范 ,使类似的项目可再次成功。 (3)能追踪成本、进度、功能 ,及时发现问题。 (1)制定了机构的标准过程文件 ,这是软件过程基础设施的重要组成部分。 信息系统审计 87 (2)建立了机构的软件工程过程组 SEPG,负责软件过程活动。 (3)制定和实施了人员培训大纲 ,保证人员能够胜任岗位知识和技能要求。 (4)针对特定项目 ,可将标准软件过程进行剪裁。 (5)项目成本、工期和功能已受控 ,质量可跟踪。 (6)管理者了解所有项目对技术进步的要求。 (1)已为产品和过程建立了量化的目标。 (2)对项目的过程活动 ,包括生产率和质量均做了度量。 (3)利用过程数据库收集和分析过程的信息。 (4)可量化评价项目过程和产品。 (5)可有效地控制过程和产品的性能 ,使其限制在规定的范围内。 (6)新应用领域的风险可知可控。 信息系统审计 88 (7)可预知产品的质量。 (1)集中注意于过程的持续改进。 (2)自知过程的薄弱环节 ,可预防缺陷的出现。 (3)可通过对当前过程的分析 ,对新技术或将出现的变更作出评价。 (4)重视探索创新活动 ,并将成功的创新推广。 (5)出现的缺陷得到分析 ,找出原因 ,防止再次发生。 三、软件能力成熟度模型集成 (CMMI) (1)CMMI强调了对需求的管理 ,有两个过程域说明对需求的控制 需求管理 REQM、需求开发 RD,而在 CMM中只有一个关键过程域需求管理 RM以及软件产品工程 SPE中的一个实践来说明对 需求的管理和控制。 信息系统审计 89 (2)CMMI加强了对工程过程的重视 ,提供了更加细致的要求和指导 ,而 CMM中却只有一个 SPE关 键过程来进行要求和指导 ;CMMI强调了度量 ,并且从项目的早期就已经进行了度量 ,在阶段式中 CMMI二级由一个过程域度量和分析 ,而在 CMM中没有专门的要求和指导。 (3)CMMI对比 CMM更加强调了对风险的管理 ,在 CMM中风险只是 “项目策划 ”SPP中的一个活 动 ,而在 CMMI中风险管理作为一个单独的过程域。 第九节 信息系统开发审计 一、系统规划阶段的审计 信息系统审计 90 二、可行性研究阶段的审计 三、需求分析阶段的审计 四、软件获取阶段的审计 五、系统设计和编码阶段的审计 (1)审查系统流程图是否符合总体设计 ,确认所有变更均事先与相关的用户讨论过并获得其认可 , 这些变更均经适当的批准。 (2)审查系统中所设计的输入、处理及输出控制是否适当。 (3)审查系统关键用户是否理解系统如何操作 ,并确定出他们在对屏幕格式及输出报告上参与设计 的等级。 信息系统审计 91 (4)评估审计轨迹是否能够充分跟踪系统事务处理。 (5)确认关键计算及处理程序的正确性。 (6)确认系统能识别错误的数据并能够适当处理。 (7)审查本阶段所开发程序的质保结果。 (8)证实所有对程序错误所提出的修正建议已被执行 ,所建议的审计轨迹或嵌入式审计模块已嵌入 适当的程序之中。 (9)核对源代码与编程规范的一致性 ,检查测试结果 ,对程序进行再测试。 (10)审查可能的控制漏洞 ,每个设计的控制是否进行 ,如果控制需要确定 ,审计人员需要提出建议 , 确保控制的有效性。 六、测试阶段的审计 信息系统审计 92 (1)检查用户参与测试的数据 ,如测试用例的开发 ,考虑重新运行关键测试。 (2)检查错误报告 ,判断报告对错误资料的识别和解释能力。 (3)审查周期性作业处理 (如月末、年末的报表处理等 )。 (4)询问终端用户 ,了解他们是否理解新方法、步骤和操作指令。 (5)审查系统和终端用户文档 ,判断其完整性与正确性。 (6)审查并行测试结果的正确性。 (7)进行访问测试 ,判断系统安全措施是否按设计要求有效执行。 (8)检查单元测试和系统测试计划 ,判断计划是否完整 ,是否已包含内部控制测试。 (9)审查记录的使用过程以及错误报告。 信息系统审计 93 七、安装阶段的审计 (1)在安装前 ,已取得适当的移交文件。 (2)审查用来为系统排程的程序及用来执行日常作业排程的参数。 (3)审查所有系统文档 ,判断其完整性及所有最近测试阶段所作的更新能否反映在文档中。 (4)在系统投入日常作业前确认所有数据的转换 ,保证其准确性和完整性。 八、系统安装后的审计 (1)确定系统的目标和需求是否已经达到。 (2)确定可行性研究中的成本收益是否已经衡量、分析并报告给管理层。 (3)审查已执行的程序变更需求 ,评估系统变更的类型。 信息系统审计 94 (4)审查系统中各种资源的利用率 ,包括计算机、外部设备、软件、人力、信息资源的利用情况 , 哪些得到充分利用 ,哪些还没有充分利用。 (5)审查系统内部控制机制 ,确定它们在按设计要求运作。 (6)审查操作人员的错误日志 ,决定系统是否存在固有的操作或者资源问题。 (7)审查输入及输出的余额并进行报告 ,证实系统准确地处理了数据。 (8)指出系统改进和扩展的方向。 第九章 信息系统运营与维护审计 信息系统审计 95 第一节 计算机硬件维护与管理 一、计算机硬件组成与结构 (一 )处理部件 (二 )输入 /输出部件 二、计算机硬件维护 三、计算机硬件监控过程 (1)硬件错误报告 标识出 CPU、输入输出、电源和存储故障。 (2)可用性报告 指出系统工作正常的时间段。 信息系统审计 96 (3)利用率报告 是系统自动形成的文件 ,记录了机器和外设的使用情况。 四、计算机硬件的能力管理 第二节 计算机软件维护与管理 一、信息系统结构和软件 二、计算机软件维护类别 信息系统审计 97 (一 )纠错性维护 (Corrective Maintenance) (二 )适应性维护 (Adaptive Maintenance) (三 )完善性维护 (Perfective Maintenance) (四 )预防性维护 (Preventive Maintenance) 信息系统审计 98 图 91 各类维护的比重 信息系统审计 99 三、计算机软件维护的实施 信息系统审计 100 图 92 软件维护工作流程 信息系统审计 101 四、系统软件版权与许可 (1)审查用于防范非授权使用和拷贝软件的策略和程序文件。 (2)审查所有标准的、已用的和许可的应用及系统软件列表。 (3)建立对软件安装的集中控制和自动分发 (包括取消用户安装软件的能力 )机制。 (4)要求所有的 PC均是无盘工作站 ,并只通过安全局域网来访问应用程序。 (5)在局域网中安装计量 (Metering)软件 ,并要求所有的 PC通过该计量软件来访问应用程序。 (6)定期扫描 PC,确保 PC中没有安装非授权的软件拷贝。 五、软件维护申请报告 (1)所需修改变动的性质。 信息系统审计 102 (2)申请修改的优先级。 (3)为满足某个维护申请报告所需的工作量。 (4)预计修改后的状况。 六、系统软件设置 (1)处理所用数据文件的版本。 (2)对敏感数据的程序访问。 (3)调度并运行的程序。 (4)操作系统的操作。 (5)数据库。 信息系统审计 103 (6)访问控制。 七、系统软件变更控制程序 八、维护档案记录 第三节 信息系统的运行与维护 一、计算机运行 信息系统审计 104 (一 )LIGHTS-OUT运行 (无人值守运行 ) (二 )输入 /输出控制功能 (I/O) (三 )数据录入人员 二、 IS运行的管理 (一 )控制功能 (二 )作业记账 (三 )作业调度 (四 )对资源的使用进行监控 信息系统审计 105 1.问题管理 2.事件管理 3.异常情况的检测和控制 (五 )程序变更控制 (六 )质量保证 (七 )IT服务管理 信息系统审计 106 第四节 信息系统变更管理 一、变更管理过程 (1)最终用户、员工、系统开发和维护人员都会提出变更请求 ,目的是解决问题 ,提高系统操作性 能 ,在任何情况下 ,变更请求都需要从适当的最终用户和系统管理层获得授权 (如变更控制小组、 配置控制委员会等 )。 (2)用户需要采用正式书面申请信函 ,如标准变化申请表、便笺、电子邮件等 ,向系统管理层表达 变更申请。 (3)变更申请表的格式、内容应该保证行动的所有变化都考虑在内 ,保证系统管理人员易于追溯到 申请的状态。 (4)变更主要是由于源程序错误和业务处理发生变化引起。 信息系统审计 107 (5)用户对系统测试结果和文档的充分性表示满意后 ,需要得到用户管理层的批准。 (6)所有变更请求和相关信息作为系统的永久文档由用户维护人员保留。 (7)如果 IT部门很小 ,处理的应用数也很少 ,很难进行职责划分 ,当变更程序的程序员也是系统的操 作者时 ,必须遵循变更管理步骤。 (8)在紧急变更的情况下 ,要能够使系统问题得到及时解决或紧急修补 ,以保证系统的完整性。 (9)为保证有效利用维护系统 ,所有相关文档都需要更新。 二、实施变更 三、文档化 四、测试变更后的程序 信息系统审计 108 (1)已存在的功能没有被变更破坏。 (2)系统性能没有被破坏。 (3)没有产生不安全的风险。 五、程序变更审计 (1)限制对程序库的访问。 (2)进行监督和审查。 (3)变更申请应该有报批流程并文档化。 (4)变更潜在影响应予以评估。 (5)变更申请应该以标准形式形成文档 ,并注意如下方面 :变更说明应该充分描述 ,进行成本分析 ,确 立完成日期 ;变更形式应该经过用户签名批准 ;变更形式需要程序管理员批准 ;工作应委派给分析 信息系统审计 109 员 ,程序员和程序组长进行监督。 (6)在审计期间 ,可抽查程序变化的一个样本追踪到维护表格 ,确定变化是否进行了授权 ,审查表格 是否进行了报批 ,比较表格上批准的日期和产品更新的日期。 (1)当用户提出系统变更需求时 ,应有授权、优先排序及跟踪的机制。 (2)在日常工作手册中 ,是否明确指出紧急变更程序。 (3)变更控制程序是否适时为用户及项目开发组所认可。 (4)变更控制日志是否确认所记录的变更都已完成。 (5)评估对产品源代码和可执行代码模块的安全访问限制是否充分。 (6)评估组织在处理紧急情况下的程序变更的流程是否合理。 (7)评估对使用紧急情况下登录的安全访问控制是否充分。 信息系统审计 110 (8)评估变更需求被记录在适当的申请文件中。 (9)确认现存文件均已反映变更后的系统环境。 (10)评估系统变更的测试程序的适当性。 (11)复核测试计划与测试结果等适当证据 ,确认该测试程序是依据组织相关标准而定的。 (12)复核保证源代码与可执行码完整性的程序。 (13)复核产品可执行模块 ,证实有且只有唯一与源代码对应的最新版本。 (14)复核整个变革管理流程在时间成本、效率方面、用户满意度上是否有需改善之处。 六、紧急变更 七、将变更移植到生产环境 信息系统审计 111 (1)在数据转换时存在控制。 (2)培训员工使用修改后的软件。 (3)为修改后的系统用户提供支持。 (4)减少在同一个时间更新所有点的风险 ,一旦发生错误必须要恢复。 八、变更风险 (非授权变更 ) (1)程序员访问了生产库。 (2)负责应用的用户不知道变化。 (3)变化需求表格和流程没有正式建立。 (4)管理层没有在变化表格上签字同意开始更新。 信息系统审计 112 (5)用户没有在变化更新前在变更表格上签字同意。 (6)没有合适的编程人员审查变化的源代码。 (7)管理层没有在变更表格上签字批准将代码更新到生产环境。 (8)程序员为了个人利益添加额外程序代码。 (9)软件供应商进行的修改没有被测试 ,或供应商被允许直接将修改更新到生产环境。 第五节 软件配置管理 信息系统审计 113 一、软件配置管理 (一 )配置管理的内容 1.配置标识 2.配置控制 3.统计配置状态 4.配置监控 (二 )配置管理的流程 1.制定配置管理的制度、程序和计划 2.维护配置的信息 信息系统审计 114 3.配置变更 4.监控配置 5.配置紧急变更的处理 (1)建立配置管理计划。 (2)将代码和相关文档基线化。 (3)分析并报告配置控制的结果。 (4)建立配置状态信息报告。 (5)建立发布流程。 (6)执行配置控制活动 ,例如识别和记录请求。 信息系统审计 115 (7)更新配置状态数据库。 (1)识别受变更请求影响的配置项并帮助评估影响。 (2)记录受到变更影响的配置项。 (3)根据授权记录实施变更。 (4)当实施授权变更和发布时登记配置项发生的变化。 (5)记录与发布相关的基线 ,以便能够在变更失败时按照已知的结果进行恢复。 二、软件发布管理 (一 )重要发布 (二 )小版本发布 信息系统审计 116 (三 )紧急软件补丁 (1)一致同意发布的内容。 (2)同意根据时间、地点、业务部门和客户划分阶段。 (3)建立高层发布进度。 (4)计划资源水平。 (5)同意角色和责任。 (6)建立备用计划。 (7)为发布的版本建立质量计划。 (8)计划支持部门和用户的接受度。 信息系统审计 117 三、程序库控制软件 (1)防止程序员访问产品源代码和对象库。 (2)防止整批的程序更新动作。 (3)要求控制人员或操作员来取出源代码并将其放到程序员的程序库里 ,要求程序员把要替换的源 代码交给控制人员或操作员 ,来更新目标代码程序库或进行测试。 (4)要求控制人员或操作员在完成测试后更新目标代码程序库的版本编号。 (5)对源代码实行只读访问控制。 (6)要求程序命名要采用唯一的标识方式以将测试版和正式版区别开来。 (7)在作业控制语言中加入筛选控制 ,以避免因误用程序名称而让正常作业执行了测试程序。 信息系统审计 118 (8)一旦错误发生时 ,可以将修改恢复。 四、执行码及源代码的完整性 五、源代码比较 第六节 IT服务管理 一、 IT服务管理产生的背景 信息系统审计 119 (一 )IT发展历程 信息系统审计 120 表 91IS/IT 发展各历程的特点 特点 发展阶段 技术层面 业务层面 信息系统层 面 IS核心能力 数据处理阶 段 主机集中计 算 业务自动化 由应用推动 技术的理解 能力 信息技术阶 段 分布式计算 竞争优势 参与市场网 络 业务的理解 能力 信息管理阶 段 网络计算 信息优势 IT基础设施 管理 适应性和变 革能力 信息系统审计 121 表 91IS/IT 发展各历程的特点 信息业务阶 段 普适计算 新业务优势 新业务开发 经营管理能 力 信息系统审计 122 (二 )IT服务管理产生背景 (1)IT基础架构与组织业务需求缺乏足够的整合。 (2)各 IT组件、各系统之间缺乏有效的协调和必要的继承。 (3)实施和运作这些 IT系统的成本很高 ,而发挥的效益却非常有限。 (三 )IT服务管理的发展历史 1.萌芽期 2.发展期 3.成熟期 二、 IT服务管理的定义 信息系统审计 123 (一 )IT的定义 (二 )什么是服务 (三 )IT服务 (四 )IT服务管理 (ITSM) 三、 ITIL 信息系统审计 124 图 93 ITIL的主体框架 (一 )IT服务管理实施规划 信息系统审计 1