免费智能真题库 > 历年试卷 > 软件评测师 > 2013年下半年 软件评测师 下午试卷 案例
  第4题      
  知识点：   安全性   安全性测试   ERP系统   网络环境   系统运行

 
【说明】
某企业最近上线了ERP系统，该系统运行的网络环境如图4-1所示。企业信息中心目前拟对该系统相关安全防护体系进行全面的安全性测试，以提供全面的安全测评报告。
 
问题：4.1   企业ERP系统上线后，企业主要业务的日常运作都高度依赖该系统的正常运行，因此ERP系统的稳定性与可靠性对企业至关重要。故障恢复与容灾备份措施是提高系统稳定性与可靠性的重要因素。对于故障恢复与容灾备份措施，参与测试的王工认为应从故障恢复、数据备份和容灾备份等三个方面进行测试。请用300字以内文字，对这三方面的测试内容进行简要说明。
 
问题：4.2   数据库服务器中目前主要存储ERP系统业务数据，后续还需要存储企业网站相关数据，当前ERP系统的用户认证方式包含口令认证方式，相应的用户权限和口令也存储在数据库二维表中。针对上述实际情况，参与测试的李工认为在对数据库权限进行测试时，除数据库账号保护及权限设置相关的常规测试外，还必须对敏感数据加密保护及对数据库访问方式进行相应测试。请用200字以内文字，对敏感数据加密保护和数据库访问方式两个方面的测试内容进行简要说明。
 
问题：4.3   为对抗来自外网或内网的主动攻击，系统通常会采用多种安全防护策略，请给出四种常见的安全防护策略并进行简要解释。结合一种在图4-1中明确标识出的安全防护策略机制，说明针对该机制的安全测试应包含哪些基本测试点。
 
 
 

   知识点讲解    
   · 安全性    · 安全性测试    · ERP系统    · 网络环境    · 系统运行
 
       安全性
        安全性是指软件产品在指定使用环境下，获得可接受的对人类、事务、软件、财产或环境有害的风险级别的能力。
 
       安全性测试
        测试应用程序的体系结构和设计可以消除很多与设计有关的漏洞，从而提高应用程序的整体安全性。设计时修复漏洞要比在开发后期解决问题更为简单，也更经济，因为开发后期可能要进行大量的重新工程处理。开发时如果考虑一些与目标部署环境相关的设计以及该环境定义的安全策略，可确保应用程序的部署更加平稳和安全。如果应用程序已创建完毕，安全测试可修复漏洞并完善未来的设计。
        一个完整的Web安全体系测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、参数操作、异常管理、审核和日志记录等几个方面入手。
               安全体系测试
                      部署与基础结构
                      检验底层网络和主机基础结构提供给应用程序的安全设置，然后检验运行环境要求的所有限制。此外，考虑部署的拓扑结构以及中间层应用程序服务器、外围区域以及内部防火墙对设计的影响。检验下列问题，确定可能存在的部署和基础结构问题。
                      . 网络是否提供了安全的通信。
                      数据在客户端与服务器（或服务器与服务器）之间传输时最易受到攻击。网络负责数据传输的完整性和私密性。如果必须保证数据安全，可使用适当的加密算法。此外，还必须确保网络设备安全。因为这是维护网络完整性所必需的。
                      . 部署拓扑结构是否包括内部防火墙。
                      如果内部防火墙将Web服务器与应用程序服务器（或数据库服务器）分隔开来，则需要考虑下列问题，确保设计能适应这种配置。
                      ①下游服务器如何验证Web服务器的身份；
                      ②如果使用域账户和Windows身份验证，防火墙是否打开了必要的端口；
                      ③是否使用分布式事务；
                      ④如果Web服务器使用DTC（Microsoft Distributed Transaction Coordinator）的服务来启动分布式事务，内部防火墙是否为DTC通信打开了必要的端口。
                      . 部署拓扑结构中是否包括远程应用程序服务器。
                      如果部署拓扑结构包括了一个物理远程中间层，则需要考虑下列问题。
                      ①是否使用企业服务。如果是，是否已限制了DCOM端口范围，内部防火墙是否打开了这些端口。
                      ②是否使用．NET远程处理。
                      ③远程处理用在受信服务器方案中，网络是否支持IPSec策略。
                      ④ASP.NET承载远程组件是否支持身份验证和授权。
                      ⑤是否使用Web服务，如果是，中间层Web服务如何验证Web应用程序的身份。Web应用程序是否通过在Web服务代理中配置凭据来使Web服务验证Web服务器的身份，如果否，Web服务如何明确调用者。
                      . 基础结构安全性要求的限制是什么。
                      设计是否假定主机基础结构安全限制要失效。例如，安全限制可能要求根据所需的服务、协议或账户特权来对设计进行权衡。需要考虑下列问题。
                      ①是否依赖可能不可用的服务或协议。开发和测试环境中可用的服务和协议可能在生产环境中不可用。
                      ②是否依赖敏感的账户特权。设计应尽量使用特权最少的进程、服务和用户账户。
                      ③要执行的操作是否要求可能不被许可的敏感特权。例如，应用程序是否要创建线程级模拟令牌来创建资源访问的服务身份。这项操作要求“作为操作系统的一部分”特权，而该特权不应授予Web服务器进程（因为可能增加进程被利用的风险）。如果需要此功能，设计应对更高级别的特权进行划分，例如，在进程外的企业服务应用程序中。
                      . 目标环境支持怎样的信任级别。
                      运行环境的代码访问安全信任级别决定了代码可访问的资源，以及它能执行的特权操作。请检查运行环境支持的信任级别。如果允许Web应用程序以完全信任级别运行，代码将能够访问操作系统安全性许可的任何资源。
                      如果Web应用程序必须以受限信任级别运行，则代码能访问的资源类型以及能执行的特权操作都将受到一定的限制。在部分信任案例中，设计应对特权代码进行沙盒（sandboxing）处理。此外，还应使用不同的程序集来分隔特权代码。这样，可以对特权代码和应用程序的其余部分单独配置特权代码，然后授予必要的附加代码访问权限。
                      注意：如果应用程序部署在共享服务器（或应用程序将由宿主公司运行），信任级别通常是个问题。此时，需要检查安全策略，然后确定Web应用程序的信任级别。
                      输入验证
                      需要对应用程序验证输入内容的方式进行检验，因为很多Web应用程序攻击都故意使用格式错误的输入。SQL注入、跨站点脚本（XSS）、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。下表中重点列出了常见的输入验证漏洞。
                      
                      常见的输入验证漏洞
                      测试时应考虑下列问题，以帮助发现潜在的输入验证安全问题。
                      . 如何验证输入。
                      设计指定的输入验证方法是什么？首先，设计必须展示策略。应用程序应对收到的所有输入进行约束、拒绝和净化。约束输入是最佳的方法，因为针对已知有效类型、模式和范围对数据进行验证，要比通过查找已知坏字符来验证数据简单得多。
                      测试时应考虑下列问题，帮助识别潜在的漏洞。
                      ①是否清楚入口点。
                      确保设计标出了应用程序的入口点，以便跟踪各个输入字段的操作。可考虑Web页输入、输入到组件和Web服务，以及从数据库输入。
                      ②是否清楚信任边界。
                      如果输入是从信任边界内受信源传递的，并非总要验证输入；但如果输入是从不受信任的源传递的，必须验证输入。
                      ③是否验证Web页输入。
                      不要将最终用户看作受信任的数据源。确保对正常和隐藏的表单字段、查询字符串和cookie都进行验证。
                      ④是否对传递到组件或Web服务的参数进行验证。
                      如果不进行验证，惟一的安全条件就是数据接收自当前信任边界之内。但是，如果使用深层防御策略，则需要使用多层验证。
                      ⑤是否验证从数据库中检索的数据。
                      这种形式的输入也应验证，特别是当其他应用程序也写入该数据库时。不要对其他应用程序的数据验证程度进行假设。
                      ⑥是否将方法集中起来。
                      对于相同类型的输入字段类型，检验使用的是否是相同的验证和筛选库，确保一致地执行验证规则。
                      ⑦是否依赖客户端的验证。
                      客户端验证可用于降低到服务器的回程数量，但不能依靠它来维护安全性，因为它很容易被忽略。需要在服务器验证所有的输入。
                      . 如何处理输入。
                      检查应用程序处理输入的方式，不同类型的处理可能导致不同类型的漏洞。例如，如果在SQL查询中使用输入，应用程序可能易受SQL注入的攻击。
                      测试中考虑下列问题，帮助发现潜在的漏洞。
                      ①应用程序是否易受规范化问题的影响。
                      检查应用程序是否使用基于输入的名称来制定安全决策。例如，应用程序是否接受用户名、文件名或URL。由于名称的表示方法多种多样，以上各项都极易造成规范化错误问题。如果应用程序接受输入作为名称，则应确保对它们进行验证并在处理之前将它们转换为规范的表示法。
                      ②应用程序是否易受SQL注入攻击。
                      密切注意形成SQL数据库查询的所有输入字段。确保对这些字段的类型、格式、长度和范围进行正确的验证。此外，检查查询的生成方式。如果使用参数化的存储过程，输入参数将被当作文本，而不会当作可执行代码。这是降低风险的一种有效措施。
                      ③应用程序是否易受XSS攻击。
                      如果在HTML输出流中包括输入字段，可能受到XSS攻击。确保对输入进行验证，并对输出进行编码。密切注意系统对接受一定范围HTML字符的输入字段的处理方法。
                      身份验证
                      检查应用程序验证调用者身份的方法，在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。下表重点列出了常见的身份验证漏洞。
                      
                      常见的身份验证漏洞
                      测试中需要考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞。
                      . 是否区分公共访问和受限访问。
                      如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，检查站点设计区分二者的方法。必须为受限的页和资源使用单独的子文件夹，然后在IIS中将它们配置为要求SSL来确保安全。这种方法允许只在需要的地方使用SSL来确保敏感数据和身法验证cookie的安全性，从而避免了因在整个站点中使用SSL而造成的附加性能负担。
                      . 是否明确服务账户要求。
                      设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务账户范围。设计中不能使用单个的、有高度特权的账户（有足够的权限连接多种不同类型的资源）。
                      ①设计是否要求特权最少的账户。
                      检查设计并准确标识各账户执行特定功能所需的特权，然后在任何情况下都使用特权最少的账户。
                      ②应用程序是否要维护服务账户凭据。
                      如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表（ACL）的注册表项。
                      . 如何验证调用者身份。
                      测试时考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。
                      ①是否在网络中传递明文凭据。如果使用表单或基本身份验证（或使用Web服务并在SOAP头中传递凭据），确保使用SSL来保护传输中的凭据。
                      ②是否实现自己的用户存储。如果是，检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存储中。实际上，必须保存密码的哈希值来进行身份验证。
                      如果根据SQL Server用户存储验证凭据，密切注意用户名和密码的输入。检查是否存在恶意注入的SQL字符。
                      ③是否使用表单身份验证。如果是，除使用SSL保护凭据外，还应使用SSL来保护身份验证cookie。此外，还要检查设计是否使用受限的会话生存期来抵御cookie重播攻击，并确保加密cookie。
                      . 如何验证数据库的身份。
                      如果应用程序要连接数据库，检查使用的身份验证机制、打算使用的账户（一个或多个），以及如何在数据库中授权应用程序。
                      明确下列问题有助于对数据库身份验证进行评价。
                      ①是否使用SQL身份验证。
                      在理想情况下，设计使用Windows身份验证来连接SQL Server，因为这种方法本身更加安全。如果使用SQL身份验证，检查在网络中和数据库连接字符串中确保凭据安全的方法。
                      如果网络基础结构不提供IPSec加密通道，确保在数据库中安装服务器证书来提供自动SQL凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含SQL账户的用户名和密码。
                      ②是否使用进程账户。
                      如果使用应用程序的进程账户并使用Windows身份验证连接SQL服务器，应在设计中使用特权最少的账户。本地ASP.NET账户便是为此提供的，尽管对于本地账户来说，用户需要在数据库服务器上创建一个相同的账户。
                      如果打算使用域账户，首先确保它是特权最少的账户，然后打开相关的端口来确保所有相关防火墙都支持Windows身份验证。
                      ③是否使用服务账户。
                      如果设计要求使用多个身份来支持数据库中的高粒度授权，则需要检查保存账户凭据（在理想情况下，这些凭据使用数据保护API（DPAPI）加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。
                      此外，还要检查使用哪些进程通过该服务账户创建模拟的安全上下文。该操作不应由Microsoft Windows 2000中的ASP.NET应用程序进程来完成，因为它将强制提升进程账户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。
                      ④是否考虑使用匿名Internet用户身份。
                      对于使用表单或Passport身份验证的应用程序而言，可为各个程序配置单独的匿名用户账户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。
                      ⑤是否使用原始用户身份。
                      如果设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份。
                      ⑥如何保存数据库连接字符串。
                      如果数据库连接字符串硬编码，或以明文形式保存在配置文件或COM+目录中，则很容易受到攻击。实际上，应加密它们，然后限制对加密数据的访问。
                      . 是否强制使用强账户管理措施。
                      如果应用程序使用Windows身份验证，Windows安全策略将强制使用强密码、受限登录和其他最佳账户管理策略。其他情况，则由应用程序层负责这些措施。测试要考虑与应用程序账户管理相关的下列问题。
                      ①应用程序是否强制使用强密码。
                      例如，ASP.NET Web页是否使用正则表达式来验证密码复杂性规则。
                      ②是否限制失败登录的次数。
                      这样做有助于对抗词典攻击。
                      ③是否在故障发生后公开过多的信息。
                      确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。
                      ④是否强制定期更改密码。
                      如果不强制定期更改密码，用户极有可能不更改自己的密码，结果风险更高。
                      ⑤是否能在泄露发生时迅速禁用账户。
                      如果账户泄露，是否能方便地禁用账户来防止攻击者继续使用账户。
                      ⑥应用程序是否记录登录企图。
                      记录失败的登录企图是检测攻击者试图侵入的有效方法。
                      授权
                      检查应用程序是如何向用户授权的。还要检验应用程序在数据库中是如何被授权的，以及如何控制系统级资源的访问。授权中的漏洞可能导致信息泄漏、数据篡改及特权提升。使用深层防御策略是一种重要的方法，它可应用于应用程序的授权策略中。下表重点列出了常见的授权漏洞。
                      
                      常见的授权漏洞
                      测试中需要考虑下列问题，帮助验证应用程序设计的授权策略。
                      . 如何向最终用户授权。
                      应在设计时从两种角度考虑授权。首先，考虑最终用户授权。哪些用户可访问哪些资源，并执行哪些操作。其次，如何防止恶意用户使用应用程序访问系统级资源。考虑下列问题，验证应用程序的授权策略。
                      ①是否使用深层防御策略。
                      确保设计不依赖于单个网关守卫来加强访问控制。考虑该网关守卫失败（或攻击者设法忽略它）时发生的情况。
                      ②使用了哪些网关守卫。
                      可能的选择有IISWeb权限、NTFS权限、ASP.NET文件授权（仅适用于Windows身份验证）、URL授权和用户权限请求。如果不使用某个特定类型，需要明确不使用的理由。
                      ③是否使用基于角色的方法。
                      如果是，如何维护角色列表，维护角色列表所需的管理界面安全性如何。
                      ④角色是否提供足够的特权隔离。
                      设计是否提供了适当的粒度，使不同用户角色的关联特权得到充分的隔离。避免出现仅为满足特定用户需要而授予角色较高特权的情况。
                      . 如何在数据库中授权应用程序。
                      在应用程序中连接数据库的账户必须有受限的能力，只需满足应用程序的要求即可，不要再高了。
                      应用程序是否使用存储过程来访问数据库呢？建议应用程序使用存储过程来访问数据库，因为一般用户只能授予应用程序登录访问特定存储过程的权限。可以限制登录不在数据库中直接执行创建/读取/更新/删除（CRUD）操作。
                      . 如何将访问限定于系统级资源。
                      设计应用程序时，应考虑应用程序在可访问系统级资源方面的限制。只能授予应用程序访问最低限度的资源。这是缓解风险的一种策略，可在应用程序遭受攻击时限制受损程度。考虑下列问题。
                      ①设计是否使用代码访问安全性。
                      代码访问安全性提供了一种资源约束模型，该模型可防止代码（和Web应用程序）访问特定类型的系统级资源。如果使用代码访问安全性，设计必将受到影响。明确是否在设计规划中包括代码访问安全性，然后通过对特权代码进行隔离和沙盒处理（sandboxing），并将资源访问代码置于自己独立的程序集中，从而进行相应的设计。
                      ②应用程序使用哪些身份。
                      设计必须明确应用程序使用的所有身份，包括进程身份和所有模拟身份（包括匿名Internet用户账户和服务身份）。此外，设计还要指出这些身份要访问的资源。
                      在部署时，可对系统级资源配置正确的ACL，确保应用程序的身份只能访问所需的资源。
                      配置管理
                      如果应用程序提供了可配置的管理界面，要检查确保管理界面安全的方法。此外，还要检查如何确保敏感配置数据的安全。下表显示了常见的配置管理漏洞。
                      
                      常见的配置管理漏洞
                      测试时考虑下列问题，帮助验证应用程序设计在配置管理方面的方法。
                      . 是否支持远程管理。
                      如果设计指定了远程管理，必须确保管理界面和配置存储的安全，因为这些操作本身非常敏感，而且通过管理界面访问的数据也很敏感。考虑与远程管理设计相关的下列问题。
                      ①是否使用强身份验证。
                      必须要求对所有管理界面用户进行身份验证。使用强身份验证，如Windows或客户端证书身份验证。
                      ②是否加密网络通信数据。
                      使用经过加密的信道，如IPSec或虚拟专用网络（VPN）连接提供的通道。不支持不安全通道中的远程管理。IPSec允许对可用来管理服务器的客户计算机的身份和数量进行限制。
                      . 是否保证配置存储的安全。
                      明确应用程序的配置存储，然后检查限制访问这些存储的方法，以及确保存储中数据安全的方法。
                      ①配置存储是否在Web空间中。
                      对于保存在Web空间文件中的配置数据，其安全性要低于保存在Web空间之外的数据。主机配置错误或未发现的Bug都可能导致攻击者通过HTTP检索，并下载配置文件。
                      ②配置存储中的数据是否安全。
                      确保在存储中加密关键的配置数据项（如数据库连接字符串、加密密钥和服务账户凭据）。
                      ③如何限制对配置存储的访问。
                      确保管理界面提供必要的授权，只有经过验证的管理员才可访问并操作这些数据。
                      . 是否隔离管理员特权。
                      如果管理界面支持不同的功能（如站点内容更新，服务账户重新配置和数据库连接详细信息），要确认管理界面支持基于角色的授权，从而区分内容开发人员和操作员或系统管理员。例如，不必许可更新静态Web站点的人改变客户的信用额度或重新配置数据库连接字符串。
                      敏感数据
                      检查应用程序对存储中、应用程序内存中以及网络中的敏感数据的处理方法。下表显示了与处理敏感数据相关的常见漏洞。
                      
                      敏感数据处理中的常见漏洞
                      测试中要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
                      . 是否存储机密信息。
                      机密信息包括了应用程序的配置数据，如账户密码和加密密钥。如果可能，明确其他避免保存机密信息的设计方法。如果要处理机密信息，由系统平台处理它们，尽可能不在应用程序中承担这一任务。如果确实要保存机密信息，则要考虑下列问题。
                      ①是否能避免存储机密信息。
                      如果使用其他的实施技术，是否能避免存储机密信息。例如，如果只需了解用户是否知道密码，则无需存储密码。或者，仅保存单向的密码哈希值。
                      此外，如果使用Windows身份验证，可通过嵌套凭据来避免存储连接字符串。
                      ②如何存储机密信息。
                      如果使用加密，如何确保加密密钥的安全。考虑使用系统平台提供的DPAPI加密，这种加密能替用户完成密钥管理。
                      ③在何处保存机密信息。
                      检查应用程序保存加密数据的方法。要获得尽可能高的安全性，应使用Windows ACL限制对加密数据的访问。确认应用程序不以明文或源代码形式存储机密信息。
                      如果使用本地安全机构（LSA），检索机密信息的代码必须使用管理员特权才可以运行，这将增加风险。另一种不要求扩展特权的方法是使用DPAPI。
                      ④如何处理机密信息。
                      检验应用程序访问机密信息的方法，以及它们以明文形式存留在内存中的时间。机密信息通常应根据需要检索，并尽快使用，然后丢弃。
                      ⑤是否在cookie中存储机密信息。
                      如果是，应确保cookie是加密的，且不会永久保存在客户计算机中。
                      . 如何存储敏感数据。
                      如果存储了敏感的应用程序数据（如客户信用卡详细信息），检查数据保护方法。
                      ①使用怎样的加密算法。
                      应使用强加密算法来加密。例如，使用较长的密钥（如Triple DES）。
                      ②如何确保加密密钥的安全性。
                      数据的安全性与加密密钥安全性同等重要。因此，检查确保密钥安全的方法。在理想状况下，使用DPAPI加密密钥并保存在受限位置（如注册表项中）来确保安全。
                      . 是否在网络中传递敏感数据。
                      如果通过网络传递敏感数据，应确保通过应用程序加密这些数据，或通过加密的通信链接来传递它们。
                      . 是否记录敏感数据。
                      检查应用程序（或主机）是否在明文日志文件中记录用户账户密码这样的敏感数据。通常，必须避免这样做。确保应用程序不在查询字符串中传递敏感数据，因为查询字符串会被记录，并可在客户端浏览器地址栏中直接看到。
                      会话管理
                      由于Web应用程序基于无状态的HTTP协议生成，因此会话管理是应用程序级任务。检查应用程序的会话管理方法，因为它将直接影响应用程序的整体安整。下表显示了与会话管理相关的常见漏洞。
                      
                      常见的会话管理漏洞
                      测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
                      . 如何交换会话标识符。
                      检查应用程序管理用户会话的会话标识符，以及这些会话标识符的交换方式。考虑下列问题。
                      ①是否通过未加密的通道传递会话标识符。
                      如果使用会话标识符（如cookie中包含的令牌）跟踪会话状态，检查是否仅通过加密的通道（如SSL）传递标识符或cookie。
                      ②是否加密会话cookie。
                      如果使用表单身份验证，确保应用程序使用“”元素中的protection="All"属性加密身份验证。建议同时使用SSL和这种方法，以便降低XSS攻击的风险，XSS攻击可设法窃取用户的身份验证cookie。
                      ③是否在查询字符串中传递会话标识符。
                      确保应用程序不在查询字符串中传递会话标识符。这些字符串可在客户端轻易修改，使用户能作为另一用户访问应用程序，访问其他用户的私有数据，并可能提升特权。
                      . 是否限制会话生存期。
                      检查应用程序认为会话标识符有效的时间。应用程序应限制这段时间的长度，以降低会话劫持和重播攻击的威胁。
                      . 如何确保会话状态存储的安全。
                      检查应用程序存储会话状态的方法。会话状态可存储在Web应用程序进程、ASP.NET会话状态服务，或SQL Server状态存储中。如果使用远程状态存储，请确保Web服务器到该远程存储的链接使用IPSec或SSL加密，以保护在网络中传输的数据。
                      加密
                      如果应用程序使用加密来提供安全性，检查加密的内容以及加密的使用方法。下表显示了与加密有关的常见漏洞。
                      
                      常见的加密漏洞
                      测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
                      . 为何使用特定的算法。
                      加密只有在正确使用时才能提供真正的安全保障。不同作业使用不同的算法。算法的程度也非常重要。考虑下列问题，评价所使用的加密算法。
                      ①是否开发自己的加密技术。
                      不应开发自己的加密技术。众所周知，加密算法和例程的开发非常难，而且很难成功。自定义实施的安全保护一般很弱，基本上不如久经考验的系统平台服务提供的安全措施。
                      ②是否使用合适的密钥大小来应用正确的算法。
                      检查应用程序使用的算法及使用该算法的目的。较大的密钥可提供较高的安全性，但会影响性能。对于在数据存储中长时间保存的永久数据，较强的加密非常重要。
                      . 如何确保加密密钥的安全性。
                      加密数据的安全与密钥的安全同等重要。要破解加密数据，攻击者必须能检索出密钥和密码文本。因此，需要检查设计，确保加密密钥和加密数据的安全。考虑下列评价问题。
                      ①如何确保加密密钥的安全。
                      如果使用DPAPI，将由系统平台为用户管理密钥。其他情况下，则由应用程序负责密钥管理。检查应用程序确保加密密钥安全的方法。一种较好的方法是，使用DPAPI加密其他加密形式所需的加密密钥。然后，安全地保存加密密钥，例如，将其放在配置了受限ACL的注册表项目下。
                      ②回收密钥的频率如何。
                      不能滥用密钥。同一密钥使用的时间越长，被发现的可能性就越高。设计是否考虑了怎样回收密钥、回收的频率，以及如何将它们分发并安置在服务器中。
                      参数操作
                      检查应用程序使用参数的方法。这些参数包括了在客户端和服务器间传递的表单字段、查询字符串、cookie、HTTP头和视图状态。如果使用像查询字符串这样的参数传递敏感数据（如会话标识符），恶意客户端可轻松使用简单的参数操作逃避服务器端检查。下表显示了常见的参数操作漏洞。
                      
                      常见的参数操作漏洞
                      测试中需要考虑下列问题，以帮助确保您的设计不受参数操作攻击影响。
                      . 是否验证所有的输入参数。
                      确保应用程序验证所有的输入参数，包括正常和隐藏的表单字段、查询字符串和cookie。
                      . 是否在参数中传递敏感数据。
                      如果应用程序在参数（如查询字符串或表单字段）中传递敏感数据，应检查应用程序使用这种方法而不是更安全的方法（传递会话标识符）的原因。例如，在加密的cookie中传递会话标识符。使用这些信息将会话与在服务器状态存储中维护的用户状态相关联。考虑下列评价问题。
                      ①是否加密包含敏感数据的cookie。
                      如果应用程序使用包含敏感数据的cookie，如用户名或角色列表，确保它是经过加密的。
                      ②是否在查询字符串或表单字段中传递敏感数据。
                      不能这样做，因为就操作查询字符串或表单字段中的数据而言，没有简便的方法可用。实际操作过程中，应考虑使用加密的会话标识符，然后将敏感数据保存在服务器的会话状态存储中。
                      ③是否保护视图状态。
                      如果Web页或控件使用视图状态在HTTP请求之间维持状态，确保视图状态经过加密，并使用消息验证代码（MAC）检查其完整性。用户可在计算机级配置该设置，也可按页配置。
                      . 是否为了安全问题而使用HTTP头数据。
                      确保Web应用程序不根据HTTP头中的信息制定安全决策，因为攻击者可轻松地操作头数据。不要依赖HTTP引用站点字段的值来检查源于页的请求是否由Web应用程序生成，这将带来漏洞。这种操作本身很不安全，因为引用站点字段可在客户端轻松更改。
                      异常管理
                      检查应用程序处理错误的方法。应前后一致地使用结构化的异常处理。同样，确保应用程序不在发生异常时公开太多信息。下表显示了两大异常管理漏洞。
                      
                      常见的异常管理漏洞
                      测试时应考虑下列问题，以确保设计不易受到异常管理安全漏洞的影响。
                      . 是否使用结构化的异常处理。
                      检查应用程序如何使用结构化的异常处理。设计应强制在整个应用程序中使用一致的结构化异常处理。这将创建更强大的应用程序，使应用程序不易处在暴露安全漏洞的不一致状态下。
                      . 是否向客户端公开了太多的信息。
                      确保恶意用户无法利用错误信息中的细节信息，考虑下列问题。
                      ①是否在服务器中捕获、处理和日志记录异常。
                      确保应用程序不会将内部异常情况传播到应用程序边界以外。异常应在服务器中捕获并记录日志。如果必要，应向客户端返回常规错误信息。
                      ②是否使用集中的异常管理系统。
                      在应用程序中一致处理并日志记录异常的最佳方法是，使用正式的异常处理系统。还可将该系统与操作组监视系统性能的监控系统相结合。
                      ③是否定义了一组自定义错误信息。
                      设计必须明确，应用程序在发生严重错误时使用自定义的错误信息。确保这些消息中不包含任何可能被恶意用户利用的敏感数据。
                      审核和日志记录
                      检查应用程序的审核和日志记录方法。除了防止抵赖之外，定期分析日志文件有助于识别入侵迹象。下表显示了常见的审核和日志记录漏洞。
                      
                      常见的审核和日志记录漏洞
                      测试中需要考虑下列问题，帮助验证应用程序审核和日志记录的方法。
                      . 是否明确了要审核的关键活动。
                      设计必须定义要审核的活动。考虑下列问题：
                      ①是否审核失败的登录尝试。
                      这允许用户检测入侵和密码破解企图。
                      ②是否审核其他关键操作。
                      确保审核其他关键事件，包括数据检索、网络通信和管理功能（如启用和禁用日志记录）。
                      . 是否考虑过如何流动原始调用者身份。
                      设计必须确保跨多个应用程序层来进行审核活动。为此，原始调用者的身份必须在每个层都可用。
                      ①是否跨应用程序层进行审核。
                      检验每个层是否都按预期计划对活动进行审核。
                      ②如何同步多个日志。
                      日志文件是证明个人犯罪行为和解决抵赖问题的法律程序所必需的。通常，在访问资源的时候，如果由访问资源的同一例程生成审核，则审核最具权威性。确认应用程序设计中与日志文件同步相关的问题，然后记录某种形式的请求标识符，确保多个日志文件条目可互相关联，并能关联至同一请求。
                      ③如何流动原始调用者身份。
                      如果不在操作系统级流动原始调用者身份（例如，由于此方法伸缩性有限），应明确应用程序如何流动原始调用者身份。对于跨层审核，这是必需的（对于授权来说，可能同样必需）。
                      此外，如果多个用户映射到同一应用程序角色，应确保应用程序记录原始调用者的身份。
                      . 是否考虑过保护日志文件管理策略。
                      检查应用程序设计是否考虑到日志文件的备份、存档和分析。日志文件必须定期存档来确保不被充满；如果充满，应开始回收。而且，还要经常分析日志文件来检测入侵迹象。此外，确保执行备份的账户都是特权最少的，确保仅为备份而公开的所有附加信道安全。
               应用及传输安全
               Web应用系统的安全性从使用的角度可分为应用级的安全与传输级的安全，安全性测试也可从这两个方面入手。
               应用级的安全测试的主要目的是查找Web应用系统自身程序设计中存在的安全隐患，主要测试区域如下。
               . 注册与登录：现在的Web应用系统基本采用先注册，后登录的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否存在大小写敏感，可以试多少次的限制，是否可以不登录而直接浏览某个页面等。
               . 在线超时：Web应用系统是否有超时的限制，也就是说，用户登录后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登录才能正常使用。
               . 操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件，是否可追踪。
               . 备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备的功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多机热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
               传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
               . HTTPS和SSL测试：默认的情况下，安全HTTP（Secure HTTP）通过安全套接字SSL（Secure Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。
               . 服务器端的脚本漏洞检验：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。这可以通过设计一些相应的测试案例来进行验证。
               . 防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题，但这里所涉及的只是对防火墙的功能、设置进行测试，以判断是否满足本Web系统的安全需求。
 
       ERP系统
               ERP的定义
               ERP（Enterprise Resource Planning，企业资源计划系统）的概念，是美国Gartner Group公司于1990年提出的，描述下一代制造商业系统和制造资源计划（MRPII）软件。除了MRP Ⅱ已有的生产资源计划，制造、财务、销售、采购等标准功能外，还包括质量管理，实验室管理，业务流程管理，产品数据管理，存货、分销与运输管理，人力资源管理和定期报告系统等功能。
               Gartner Group提出ERP具备的功能标准应包括四个方面。
               （1）超越MRP Ⅱ范围的集成功能。包括质量管理；试验室管理；流程作业管理；配方管理；产品数据管理；维护管理；管制报告和仓库管理。
               （2）支持混合方式的制造环境。包括既可支持离散又可支持流程的制造环境；按照面向对象的业务模型组合业务过程的能力和国际范围内的应用。
               （3）支持能动的监控能力，提高业务绩效。包括在整个企业内采用控制和工程方法；模拟功能；决策支持和用于生产及分析的图形能力。
               （4）支持开放的客户机／服务器计算环境。包括客户机／服务器体系结构；图形用户界面（GUI）；计算机辅助设计工程（CASE），面向对象技术；使用SQL对关系数据库查询；内部集成的工程系统、商业系统、数据采集和外部集成（EDI）。
               ERP把客户需求和企业内部的制造活动以及供应商的制造资源整合在一起，形成企业一个完整的供应链，其核心管理思想主要体现在以下3个方面。
               （1）体现对整个供应链资源进行管理的思想。
               （2）体现精益生产、敏捷制造和同步工程的思想。
               （3）体现事先计划与事前控制的思想。
               ERP是对MRP Ⅱ的超越，从本质上看，ERP仍然是以MRP Ⅱ为核心，但在功能和技术上却超越了传统的MRP Ⅱ，它是以顾客驱动的、基于时间的、面向整个供应链管理的企业资源计划。ERP采用的基础技术将同时给用户软件和硬件两方面的独立性从而更加容易升级。ERP的关键在于所有用户能够裁剪其应用，因而具有天然的易用性。
               ERP是一个对企业资源进行有效共享与利用的系统。ERP通过信息系统对信息进行充分整理、有效传递，使企业的资源在购、存、产、销、人、财、物等各个方面能够得到合理地配置与利用，从而实现企业经营效率的提高。从本质上讲，ERP是一套信息系统，是一种工具。ERP在系统设计中可集成某些管理思想与内容，可帮助企业提升管理水平。
               但是，ERP本身不是管理，它不可以取代管理。ERP本身不能解决企业的管理问题。企业的管理问题只能由管理者自己去解决。ERP可以是管理者解决企业管理问题的一种工具。不少企业因为错误地将ERP当成了管理本身，在ERP实施前未能认真地分析企业的管理问题，寻找解决途径，而过分地依赖ERP来解决问题。最后，不但老的问题得不到有效解决，还产生了许多新的问题，最终导致了ERP实施的失败。企业也因此而伤了元气。正确地认识ERP是什么与不是什么，就会在ERP实施之前认真分析企业在管理上存在的问题，了解ERP对解决这些问题的作用，充分细致地计划与落实利用ERP解决这些问题的程序，为ERP充分发挥效率提供基础。
               ERP应用成功的标志是：
               （1）系统运行集成化，软件的运作跨越多个部门。
               （2）业务流程合理化，各级业务部门根据完全优化后的流程重新构建。
               （3）绩效监控动态化，绩效系统能即时反馈以便纠正管理中存在的问题。
               （4）管理改善持续化，企业建立一个可以不断自我评价和不断改善管理的机制。
               新一代ERP的核心技术
               为了应对管理软件所面临的变化、知识、分布与集成这四大挑战，解决存在的需求与软件脱节和企业变化快与软件调整难的两大问题，新一代ERP应该采用下面四项核心技术，即软件体系结构、企业建模、集成框架与平台和工作流。
               基于体系结构的软件开发是管理软件发展的关键，体系结构是需求和设计之间反映决策信息的中间过程，软件开发通过问题定义→软件需求→软件体系结构→软件设计→软件实现几个步骤实现。可见，体系结构将软件系统的结构信息独立于算法与数据，创建满足系统需要的结构，其本质是模型的层次化。
               基于企业模型来构建是管理软件发展的核心。企业建模是认识企业、描述企业的最科学有效的手段，是准确了解企业需求、定义软件功能和流程的有效方法。它是用户、软件厂商、实施单位交流的媒介和基础平台。同时，企业建模是知识管理的基础，企业可重用的知识包含在企业模型和模板中，企业模型是企业知识的一种表现形式，也是实现企业知识积累的有效方法。基于软件体系结构和企业模型建立管理软件的业务架构已经成为管理软件开发公司重要的核心能力。
               集成框架和平台是企业管理软件发展的蓝图。通过集成平台，将各种软件集成在一个平台下，实现企业管理软件和其他信息系统的无缝集成，扩展软件的服务水平。
               工作流是提高企业管理软件柔性的重要使能技术。通过工作流来管理企业业务流程，使得管理软件中流程与功能分离，克服了传统的设计开发方法的不足——过程和功能集中在一起。软件开发需要经过三次分离：即数据库的分离——成功（理论具备完整的数据库模型），用户接口的分离——没有完全成功（缺乏模型指导）和流程的分离——正在进行（是大势所趋），而工作流正是流程分离的关键技术。
               软件体系结构、企业建模、工作流和集成框架和平台形成了管理软件开发实施的核心技术。同时，必须实现软件开发的标准化，标准化是实现软件管理软件高度可重用和柔性的基础支撑。
               新一代ERP的体系结构
               新一代ERP系统的体系结构如下图所示。它是基于企业模型和工作流系统来构建的，底层是操作系统、网络、数据库和基础组件平台组成的系统平台，作为整个系统的基础结构。中间层是由工作流系统、集成管理、公共应用服务组件等组成的应用平台。该平台作为ERP以及其他信息系统的构建平台。在这个基础结构之上建立ERP系统，通过ERP的各个功能组件组成核心业务组件框架，而各个行业的ERP系统可以在此基础上构建。并通过统一的企业入口向企业客户提供服务。
               
               新一代ERP的体系结构
               新一代ERP的实施过程包含四个主要阶段：企业（业务）战略规划、信息系统战略规划、信息系统实现和信息系统运行维护，并且这四个阶段是随着企业战略的不断调整和信息化工作的不断深入循环进行的。
               以企业模型作为底层支撑平台来实施信息化整体解决方案，利用企业建模过程中各阶段模型的演化来推进整体解决方案实施过程的演进，并通过模型演化过程中模型的一致性来保证整体解决方案的集成性和一致性。在实施过程的不同阶段，有着不同层次的企业模型作为实施的支撑，下面分别讨论各个阶段基于企业建模的实施步骤，以及各个层次的企业模型之间的映射关系和演化过程。
                      企业业务战略规划
                      面向信息系统实施的企业业务战略规划需要完成的工作包括企业定位、企业现状分析、制定业务目标与所采用的战略、确定达到目标的关键成功因素、为信息系统的规划和设计提供业务框架。
                      在这个阶段，首先要根据企业现状建立面向产品全生命周期、以业务过程为核心、集成包含企业组织结构、资源结构的需求层的企业模型。这个企业模型描述的核心是企业粗线条的业务模型，目标是对企业业务进行现状分析和诊断优化，我们称这个层次的企业模型为业务核心模型。
                      信息系统战略规划
                      在信息系统战略规划阶段需要完成的工作是从企业的业务系统框架到信息系统框架的转化。信息系统框架包含的内容是企业整体信息系统的功能结构、数据结构和集成框架，以及信息系统的实施策略、实施方法和实施计划。
                      基于企业建模的信息系统战略规划就是在模型上完成从需求层的业务核心模型到设计层的信息系统模型的抽取过程，如下图所示。根据建立并优化分析好的业务核心模型，从过程模型中根据功能抽离组织出信息系统需要实现的业务功能和功能结构，并且将过程中涉及的活动、活动之间的逻辑关系和活动之间的数据流映射成这些功能单元里面的功能操作、功能单元之间的交互关系以及整个信息系统中的数据流，这些功能单元将配置成最后运行的信息系统中的子系统或者系统组件。将过程模型中活动使用的和传递的各种可以用表单形式表达的数据抽取整理成为信息模型，描述数据结构和数据关系，同时功能单元之间交互的数据来源于这个信息模型。最后，再根据业务核心模型中描述的业务过程所关联的产品信息、组织信息和资源信息，可以确定未来数据库的系统结构、网络结构，构造信息系统各功能单元之间的集成框架。
                      
                      从业务核心模型到信息系统模型
                      信息系统实施
                      信息系统实施阶段根据实施信息系统战略规划确定的信息系统框架和实施方法、计划将信息系统搭建或者开发完毕，并且根据需要完成企业信息系统管理系统的开发。
                      系统实施相应可以分为三个方面：对已有系统的重新包装；对系统提供商提供的系统组件进行裁剪组合；对新系统／组件进行编码开发。
                      信息系统运行维护
                      信息系统运行阶段的工作包括技术与系统培训、运行管理制度制定、信息系统运行、系统日志建立、运行性能评价和信息系统调整等工作。
                      基于工作流模型的信息系统管理系统可以自动完成信息系统的运行和管理功能，并且工作流管理系统可以自动建立有效的系统日志和数据仓库，利用数据分析技术可以对日志数据进行挖掘分析，来评价信息系统的运行性能，及时发现信息系统存在的错误和潜在的问题，完成信息系统的维护工作。
 
       网络环境
        电子商务系统由三个部分组成，分别为企业内部网（Intranet）、企业外部网（Extranet）和Internet。以上三部分构成以企业的分布式计算为核心的信息系统的集合体。
        企业内部网是利用网络技术（包括TCP/IP协议以及其他协议等）构造的，面向企业内部的专用计算机网络系统。
        企业外部网与Intranet相对应，侧重于企业电子商务的外部环境以及与合作伙伴或外协厂的信息交换关系。
        电子商务以Intranet为基础，实现企业内部工作流的电子化，在初步建成企业内部的信息系统之后，再进一步完善企业电子商务的外部环境，将企业的信息系统同合作伙伴或外协厂等联系起来，将Intranet扩展到Extranet，完成企业与企业间的电子交换（包括EDI），其后再通过Internet向消费者提供联机（Online）服务。
 
       系统运行
               系统管理分类
               IT系统管理工作主要是优化IT部门的各类管理流程，并保证能够按照一定的服务级别，为业务部门（客户）高质量、低成本地提供IT服务。IT系统管理工作可以按照以下两个标准予以分类。
                      按系统类型分类
                      （1）信息系统，企业的信息处理基础平台，直接面向业务部门（客户），包括办公自动化系统、企业资源计划（ERP）、客户关系管理（CRM）、供应链管理（SCM）、数据仓库系统（Date Warehousing）、知识管理平台（KM）等。
                      （2）网络系统，作为企业的基础架构，是其他方面的核心支撑平台。包括企业内部网（Intranet）、IP地址管理、广域网（ISDN、虚拟专用网）、远程拨号系统等。
                      （3）运作系统，作为企业IT运行管理的各类系统，是IT部门的核心管理平台。包括备份／恢复系统、入侵检测、性能监控、安全管理、服务级别管理、帮助服务台、作业调度等。
                      （4）设施及设备，设施及设备管理是为了保证计算机处于适合其连续工作的环境中，并把灾难（人为或自然的）的影响降到最低限度。包括专门用来放置计算机设备的设施或房间。
                      对IT资产（计算机设备、通信设备、个人计算机和局域网设备）的恰当的环境保护；有效的环境控制机制：火灾探测和灭火系统、湿度控制系统、双层地板，隐藏的线路铺设、安全设置水管位置，使其远离敏感设备、以及不间断电源和后备电力供应等。
                      按流程类型分类
                      （1）侧重于IT部门的管理，从而保证能够高质量地为业务部门（客户）提供IT服务。这一部分主要是对公司整个IT活动的管理，包括IT财务管理、服务级别管理、IT资源管理、能力管理、系统安全管理、新系统转换、系统评价等职能。
                      （2）侧重于业务部门的IT支持及日常作业，从而保证业务部门（客户）IT服务的可用性和持续性。这一部分主要是业务部门IT支持服务，包括IT日常作业管理、帮助服务台管理、故障管理及用户支持、性能及可用性保障等。
                      （3）侧重于IT基础设施建设，主要是建设企业的局域网、广域网、Web架构、Internet连接等。
               系统管理规范化
               系统管理的规范化涉及到人员职责、操作流程等方面标准的制定，并进行有效的标准化。企业IT部门除了IT部门组织结构及职责之外，还应该详细制定各类运作管理规章制度，主要包括：日常作业调度手册、系统备份及恢复手册、性能监控及优化手册、输出管理手册、帮助服务台运作手册、常见故障处理方法、终端用户计算机使用制度等与用户息息相关的IT支持作业方面的规范制度。此外，还包括服务级别管理手册、安全管理制度、IT财务管理制度、IT服务计费及成本核算、IT资源及配置管理、新系统转换流程、IT能力规划管理等由IT部门执行的以提供高质量IT服务为目的的管理流程。
               系统运作报告
               系统运行过程中的关键操作、非正常操作、故障、性能监控、安全审计等信息，应该实时或随后形成系统运作报告，并进行分析以改进系统管理水平。
               是否有流程保证对所有不属于标准操作的操作性问题给予记录（在问题管理系统内）、分析和及时处理？
                      系统日常操作日志
                      系统日志应该记录足以形成数据的信息，为关键性的运作提供审核追踪记录，并且保存合理的时间段。利用日志工具定期对日志进行检查，以便监控例外情况并发现非正常的操作、未经授权的活动、作业完成情况、存储状况、CPU、内存利用水平等。
                      性能／能力规划报告
                      企业需要了解其IT能力能否满足其业务需要，因此它需要了解系统性能、能力和成本的历史数据，定期形成月度、年度性能报告，并进行趋势分析和资源限制评估，在此基础之上增加或调整其IT能力。
                      性能监控工具应该主动地监控、测量和报告系统的性能，包括平均响应时间、每日交易数、平均无故障时间、CPU、存储器等的使用状况、网络性能等，从而可以有预见性地响应变化的业务需求。
                      故障管理报告
                      企业应定期产生有关问题的统计数据，这些统计数据包括：事故出现次数、受影响的客户数、解决事故所需时间和成本、业务损失成本等，可以供管理层对反复发生的问题进行根本原因的分析，并寻找改进的机会。
                      另外，对于每次故障处理应该进行数据记录、归类，作为基础，它应包括以下内容。
                      .目录，确定与故障相关联的领域，比如硬件、软件等。
                      .影响度，故障对业务流程的影响程度。
                      .紧迫性，故障需要得到解决的紧急程度。
                      .优先级，综合考虑影响度、紧迫性、风险和可用资源后得出的解决故障的先后顺序。
                      .解决方法，故障解决的流程、处理方法。
                      这样有利于使用知识管理系统来协助解决问题。
                      安全审计日志
                      为了能够实时监测、记录和分析网络上和用户系统中发生的各类与安全有关的事件（如网络入侵、内部资料窃取、泄密行为等），并阻断严重的违规行为，就需要安全审计跟踪机制来实现在跟踪中记录有关安全的信息。审计是记录用户使用计算机网络系统进行所有活动的过程，它是提高安全性的重要工具。
                      审计记录应包括以下信息：事件发生的时间和地点；引发事件的用户；事件的类型；事件成功与否。常见的审计记录可能包括：活动的用户账号和访问特权；用户的活动情况，包括可疑的行为；未授权和未成功的访问企图；敏感命令的运行等。
                      系统运作报告使对IT的整个运行状况的评价得以实现，IT报告应具备涵盖所有IT领域的关键业绩指标，例如风险及问题、财务状况、系统利用率、系统性能、系统故障时间、服务级别执行情况、安全审计等，这也为IT运作绩效的改进提供了基础。
   题号导航      2013年下半年 软件评测师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第4题    在手机中做本题