浅谈企业核心应用的安全审计



浅谈企业核心应用的安全审计

url： http://www.cnetnews.com.cn/2008/0717/991883.shtml

作者： 朱闽 CNET科技资讯网7月17日国际
CNETNews.com.cn
2008-07-17 18:35:30

　　作者: 朱闽, 　出处:网界网,　责任编辑: 郭秋爽,　 2008-07-17 10:02

　　这篇文章以现代商业银行的应用为例，讨论安全审计解决方案，根据不同企业应用架构的不同，审计解决方案会很灵活。本文以国内某银行T为例，重点讨论其核心系统的安全审计。

　　本世纪初的一系列跨国公司财务丑闻，促生了萨班斯法案(Sarbanes-Oxley)等一系列涉及会计职业监管、公司治理、证券市场监管改革的重要法律法规的诞生。如今的IT环境随着业务的发展和延伸而越来越复杂，这种经济领域的重大变革必然对IT环境带来深远的影响。

　　人们常常谈论如何通过IT技术手段来满足企业业务需求，而反过来IT技术层面上可能的漏洞或隐患，会对业务造成巨大的损失。为此可以看到众多企业纷纷从IT技术应用中寻求企业级安全审计解决方案，而其必要性和重要性更是不言而喻。

　　这篇文章以现代商业银行的应用为例，讨论安全审计解决方案，需要说明的是，根据不同企业应用架构的不同，审计解决方案会很灵活。本文以国内某银行T为例，重点讨论其核心系统的安全审计。

　　银行的隐患

　　下面我们围绕假定的某银行T为背景展开讨论，银行T是一家典型的商业银行，拥有自己的核心系统，运行在大型企业级服务器上(IBMZ系列大型主机)，支持全国范围内的对公和对私的核心业务，这些业务包括传统的活期、定期存款业务，贷款业务，支票业务，转账业务，外汇业务等等。

　　另外，银行T还开通了各项中间业务和电子银行业务(支持电话、手机、网上银行业务等)，以及其他的对公对私业务达近百种。独立于核心系统之外，银行T拥有一套信用卡应用系统，完成信用卡相关业务交易。此外还有卡交换系统，基金交易系统，国债系统等，这些系统目前相对独立于核心系统，运行在其他硬件平台的Unix服务器，部分前端服务使用Windows操作系统。

　　目前，银行T准备上市，这意味着它将面临着越来越多的合规审查，审计公司派驻到银行T的审计人员，要求获得有效的完整审计数据，而这些审计人员没有大型计算机操作的技术背景，而且处于安全银行T也不会允许未授权人的操作。这样看来，外审人员只能请银行T的系统管理员来帮助完成审计报告。

　　但另一个棘手的问题时，和所有商业银行一样，大量的真实客户资料在银行T的系统环境中，在进行所有系统操作之前要确定操作人员的操作不会影响到系统的安全，不会接触到任何敏感的数据信息。此外，技术人员不了解审计业务，难以确认审计人员的需求。而银行T要上市，就一定要出据优良的审计报告，这样就成了一个矛盾。

　　银行T的系统面对新的跟踪、分析和及时报告各种审计情况的挑战，避免出现任何可能的违规局面。除了外部审计，银行T决定增设独立于其他部门的内部安全审计部门，因为银行T明白任何违规操作和不利的审计报告将意味着严重的商业损失，甚至是灾难性的失败。从监控者的角度，更是需要通过审计报告确认公司的合规操作，避免给投资者带来可能的损失，维护市场的公平秩序。从现有的情况看，建立和加强内外审计工作是银行T面临的一项重要任务。

　　第1页：银行的隐患

　　第2页：系统架构与安全审计

　　第3页：核心应用安全审计

　　第4页：关注审计细节

　　第5页：关注整合

　　作者: 朱闽, 　出处:网界网,　责任编辑: 郭秋爽,　 2008-07-17 10:02

　　这篇文章以现代商业银行的应用为例，讨论安全审计解决方案，根据不同企业应用架构的不同，审计解决方案会很灵活。本文以国内某银行T为例，重点讨论其核心系统的安全审计。

　　系统架构与安全审计

　　接下来我们看看有哪些可能的系统访问接口将成为重点看护的对象。为了分析的方便起见，我们把银行T系统访问接口进行简单分类——企业内部访问接口和企业外部访问接口。企业内部接口是银行内部操作人员访问系统时使用的，根据不同工作内容，角色分工和权限管理，银行T系统管理和安全部门给不同内部操作人员分配不同的权限，例如柜台操作人员，系统管理员，数据库管理员，安全审计人员被分配了对系统资源访问的不同权限。企业外部接口包括那些银行T的用户可以接入银行系统的所有访问入口，例如从互联网上通过Web方式查询自己的账户，进行转账操作，网上购物，在商家的POS机上划卡消费，通过电话或手机查询和消费，在AMT机上的操作等等。可见当今银行的业务种类繁多，门户也越来越多，各种可能的访问路径和操作都是审计人员监控的对象。

　　目前，银行T最大的数据源是核心业务系统，这部分的数据资源放在System Z平台的DB2上，外部审计公司也要求银行T在主机环境上开展审计工作，从而实现对安全审计的整合。更重要的，银行T也意识到，系统管理员和数据库系统的授权管理人员如DBA有很高的操作权限，有必要对其进行有效的监控和审计，防止出现可能的违规性操作，需要严格的内部安全监控。

　　银行T决定具体分析自己的审计需求，制定并实施安全审计解决方案，下面我们来具体分析如何通过在DB2 for z上部署相应的审计工具等来满足其审计需求。

　　目前银行T的系统基本情况为：对私业务和对公业务分别部署在两个Parallel Sysplex (PLEXA，PLEXB)上。银行T希望在对私和对公两个系统上都部署相应的审计工具，支持从多个数据源(同时从多个DB2 Number)方便的收集审计数据，在DB2子系统内有选择的审查对数据库表的插入、更新、删除和读操作。

　　另外银行T的内部审计人员没有System Z平台操作的技术，所以要求提供简单方便的用户图形化界面，通过缩短手工审计流程而节约大量审计时间和工作量;新的审计解决方案能够简化一般性的审计任务，例如能够方便的确定，某用户在某个特定时间段对哪些数据对象进行了哪些操作，提供详细的审计证据，这些不合法的操作也包括及时监控针对系统或数据库对象的未授权访问等。

　　此外，安全审计人员需要灵活的对审计信息进行过滤，生成有特殊审计目的的多种报告，而更好的解决方案应该提供扩展性支持，也就是支持将审计规则方便的应用在其他系统环境中，从而支持开放式的整合的审计需求。

　　第1页：银行的隐患

　　第2页：系统架构与安全审计

　　第3页：核心应用安全审计

　　第4页：关注审计细节

　　第5页：关注整合

　　作者: 朱闽, 　出处:网界网,　责任编辑: 郭秋爽,　 2008-07-17 10:02

　　这篇文章以现代商业银行的应用为例，讨论安全审计解决方案，根据不同企业应用架构的不同，审计解决方案会很灵活。本文以国内某银行T为例，重点讨论其核心系统的安全审计。

　　核心应用安全审计

　　在搭建数据库审计环境中，通过部署DB2Audit Management Expert for Z(AME)，实施针对子系统级的审计解决方案。AME提供了有效的方法来跟踪数据变化，及时发现谁在什么时间什么地点作了哪些操作，同时生成规范的审计报告，更理想的是AME提供了从多个角度对审计数据的分析，能够随时追溯以往的审计报告或审计数据，维护相对独立的审计系统，而不对生产环境造成过多的影响，保证对系统资源的消耗为最小。

　　AME通过客户端-服务器模式进行工作，这包括一个AME服务器、AME代理和客户端。根据具体的审计需求来确定开启和关闭相应Agent的时间段或周期，以及收集什么样的信息，根据这些审计规范在AME的客户端定制profile，这样Agent将按照事先定义好的profile自动开启，收集信息和关闭。

　　针对银行T生产环境的特点，理清和规划业务安全审计的具体需求如下：确定什么时间进行哪些不同的审计内容;针对那些用户或组的审计;不同时间区间可能发生的审计事件是什么;对审计人员的审计权限和范围界定;对那些关键性目标表进行审计;针对那些操作实施审计;是否具有时间上周期性审计的特点;对于临时性审计工作的具体范围;审计报告的管理。

　　在完整定义生产环境基本审计规范的基础上，AME进行自动化的工作，审计人员可以在事后追溯任何审计时间点的审计事件，同时生成相应的审计报告。

　　第1页：银行的隐患

　　第2页：系统架构与安全审计

　　第3页：核心应用安全审计

　　第4页：关注审计细节

　　第5页：关注整合

　　作者: 朱闽, 　出处:网界网,　责任编辑: 郭秋爽,　 2008-07-17 10:02

　　这篇文章以现代商业银行的应用为例，讨论安全审计解决方案，根据不同企业应用架构的不同，审计解决方案会很灵活。本文以国内某银行T为例，重点讨论其核心系统的安全审计。

　　随着萨班斯法案的出台，越来越多的企业对自身的信息应用安全高度关注。以某银行系统为例，已经开展了对自身核心应用的安全审计，具有很强的典型性。

　　关注审计细节

　　在上面的文章中，我们重点讨论了现代商业银行的应用实例。需要说明的是，根据不同企业应用架构的不同，审计解决方案会很灵活。事实上，在具体的核心系统的安全审计过程中，仍然具有大量的需要关注的问题。

　　如前文所述，在T银行搭建数据库审计环境中，通过部署DB2Audit Management Expert for Z(AME)，实施针对子系统级的审计解决方案。AME提供了有效的方法来跟踪数据变化，不仅能够进行准确的信息追踪，而且可以生成规范的审计报告，而这一切都可以自动地进行。

　　目前来看，AME支持的针对不同活动的审计包括：

　　因授权不足的DB2访问请求

　　显性的授权和撤销操作(GRANT and REVOKE)

　　创建, 修改, 删除表的操作(表属性为Audit all)

　　一个UOR内的首次修改审计对象，包括(SQL INSERT，UPDATE，DELETE)

　　一个UOR内的首次读操作(SQL SELECT)

　　修改授权ID

　　DB2 Utilities

　　DB2命令

　　五大技术要点

　　第一，关于审计报告生成。

　　安全审计工具的日志分析功能提供了分析报告生成功能，同时分为一般性报告和详细报告两种类型，非指定的默认状态为生成一般性报告。

　　一般性的审计可以直接通过客户端察看是否有系统报警信息，如果发生报警，可追溯查看详细的审计事件，直接生成和导出详细审计报告，详细审计报告以Excel的方式保存在审计人员自己的文件管理系统中作为存档，也可以和用户自定义的审计管理系统连接。

　　第二，审计数据源维护工作。

　　在安全审计实施规划阶段，根据审计业务的需求，审计数据量级以及系统存储资源情况，确定审计数据库的大小，因为安全审计工具维护自己的审计数据库，不会对系统其他数据库造成影响。

　　在确定审计数据库大小的基础上，可以规划以半年或更长的时间段为周期，对审计数据库做备份如System Backup，IMGCopy等，同时根据审计业务的需求，定期对审计数据库做清理。审计数据库的维护工作可以和其他系统维护工作相配合，以满足审计业务的需求为准进行合理的规划和实施。

　　第三，审计人员权限管理。

　　根据内部和外部审计的不同业务需求，建议区分内部和外部审计，对审计人员进行相应的权限分配，防止审计人员的误操作对系统可能带来的影响，比如一般性审计人员建议不授予审计日志分析的权限，防止非正常操作占用系统资源等。

　　第四，安全审计性能相关。

　　因为安全审计工具通过DB2 Trace或数据库日志获取审计信息，为了避免不必要的系统资源消耗，建议在制定审计规则的Profile的同时，考虑针对不同的时间段，应用不同的审计Profile,在生产系统高峰时间段，最小化不必要的审计工作，在非高峰时间或有内部人员对系统操作时间段，应用级别更高的审计Profile, 而审计报告建议选择在系统非高峰的时间进行生成操作

　　在安全审计软件的是运行期间，建议记录INFO级别的日志信息，而确定稳定运行后，建议修改为记录错误日志信息级别。

　　另外在日志分析功能模块中，工具除了提供一般的分析报告外，为了满足特殊详细的审计需求，可以选择生成详细审计报告。如果没有特殊审计分析需求，建议生成一般性日志分析报告，节约系统资源消耗，同时完全可以满足日常的日志分析需要。在使用日志分析功能的时候，请先通过日常审计报告，确定需要作分析的具体时间段，指定时间区间越短，对系统资源的消耗越少。

　　第五，方案实施问题。

　　定义好审计规则的Profile后，在实施步骤上，建议先在测试环境下部署运行，评估相关的系统开销，根据实际情况调整Profile的规则，稳定运行后再在生产环境上实施部署正式上线。

　　综合以上及其他具体审计需求，指定审计工作实施方案。可以利用DB2 AME有效而灵活的支持针对不同审计需求的定义和配置,能够更好的节约系统资源，通过合理的切换和激活AME Agent，可以自动实施不同时间段的审计内容，控制审计的工作量。保障对系统资源占用降低到最低。

　　第1页：银行的隐患

　　第2页：系统架构与安全审计

　　第3页：核心应用安全审计

　　第4页：关注审计细节

　　第5页：关注整合

　　作者: 朱闽, 　出处:网界网,　责任编辑: 郭秋爽,　 2008-07-17 10:02

　　这篇文章以现代商业银行的应用为例，讨论安全审计解决方案，根据不同企业应用架构的不同，审计解决方案会很灵活。本文以国内某银行T为例，重点讨论其核心系统的安全审计。

　　关注整合

　　至此，银行T完成了部署针对核心系统数据库的审计工作，同时，银行T也拥有针对其他子系统的审计功能，例如对通过Z/OS SMF记录Z/OS RACF信息，对开放平台上其他业务系统的增加审计功能等。现在的问题是，怎样把众多的针对子系统的审计模块进行整合，提供一个企业级审计的完整视图。

　　前面我们分析了在银行T系统应用架构上所有可能的内部和外部访问路径，在每条可能的访问路径上，在个子系统内部截取和跟踪授权信息等相关审计纪录，其中我们主要讨论了对核心业务系统DB2for Z子系统的如何部署审计解决方案。

　　下面我们要做得是提供完整的针对某个应用进行端到端的审计。例如，某客户从网上修改了自己的银行卡密码，然后用这张银行卡进行网上转账操作。这样一个简单的活动，我们需要记录什么时间，通过哪个网段，该用户进行了哪些操作，系统记录的每条审计记录，作为一个审计事件，该审计事件不仅发生在一个子系统内部，而是跨平台的多系统间操作，也就是针对应用层面的跟踪记录。

　　整合的工作大致包括三部分——收集信息，关联信息和生成审计报告。前面提到，子系统级别的信息收集可以实现，下面是如何才能对审计信息进行关联呢。一般的，审计事件所包含的信息遵循W7原则：

　　Who：哪个用户或应用启动了该审计事件

　　What：审计事件包含的活动内容

　　When：审计事件发生的时间

　　Where：审计事件发生在哪个系统

　　OnWhat：哪些对象(文件、数据库、打印机等)参与了该审计事件

　　Wherefrom：审计事件发起的源系统

　　WhereTo：审计事件的目标系统

　　所以信息关联的关键是看能否找到某个应用在不同子系统内部运行时的统一关键字，例如Original ID等。这里针对不同的需求，我们仅就目前比较成熟的企业级解决方案作以介绍。

　　比如TivoliIdentity Manager(TIM)针对企业用户管理解决方案，提供了用户管理的门户，实现多系统间用户权限管理的整合和同步，防止在某子系统对用户ID的授权修改，导致可能的安全隐患。同时作为用户管理系统只需要维护一个统一的用户管理界面，不需要分别到不同的子系统内部维护独立的用户管理系统。在TIM内部还可以定义工作流程控制模块，通过简单的操作来定义工作流程。

　　另外，被广泛使用的企业级合规性解决方案基于Tivoli Compliance Insight Manager(TCIM)软件，该解决方案不仅支持开放平台上(Windows、Unix操作系统)多种子系统作为数据源，也支持System Z平台上对Z/OS, DB2 for Z作为合规性审计的数据源。Tivoli Compliance Insight Manager能够从Z/OS SMF中获取所有和定义有关的记录，按照W7规则，通过友好的界面展现出来，同时提供了强大的报告生成功能.这样对于跨平台的企业客户，就不需要维护多个审计窗口，而通过TCIM统一整合审计记录，生成审计人员所关心的报告。

　　例如，根据TCIM报告总试图的一部分，配置“WHO”，“On What”的二维试图确定审计对象和关心的审计事件，同时发出审计预警。其中，我们设定数据集HANNE.PAYROLL为敏感数据集，在“on What”项中标记为“Payroll”， 同时在规则中标记Severity 70作为例外事件，这样，我们能够通过TCIM跟踪和整合所有对该数据集的操作。进一步的，如果我们查看Z/OS RACF和该数据集相关的记录信息，我们在“WHO”选定“Z/OS RACF Special - Production”，红色的标记为报警标志。查看详细信息，下图为其中一个审计事件的具体信息，TCIM从SMF中获取来自RACF的记录，该记录显示用户ZHU在某时间点成功读取了数据集HANNE.PAYROLL。

　　另外，我们前面重点讨论了AME对DB2子系统的审计，这里有必要说明AME和TCIM针对DB2子系统审计部分的区别和各自特点.对于对DB2子系统审计有较高信息量的需求，例如希望看到详细的针对某行纪录的修改信息，甚至包括修改前后的记录变化情况，而目前对于跨平台审计没有强烈需求，AME是很好的解决方案。因为AME的数据源包括DB2 Trace和DB2 Log不仅提供一般性全面的审计功能，而且提供日志分析功能，所以审计人员或系统管理人员，可是在必要的时候做DB2日志分析并提供日志分析报告作为一般性审计报告的补充和证据。另外AME提供自己的审计用户管理，和系统用户分离。

　　TCIM解决方案，更高专注于多系统审计，在System Z平台上直接的数据源是Z/OS SMF,所以它能够捕获SMF里和DB2及其他组件的信息，如RACF等。另外TCIM解决方案支持开放平台的多种数据源，在整合性上是首推的解决方案。

　　第1页：银行的隐患

　　第2页：系统架构与安全审计

　　第3页：核心应用安全审计

　　第4页：关注审计细节

　　第5页：关注整合