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

　　银行的隐患

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

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

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

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

　　T银行的系统面临新的跟踪、分析和及时报告各种审计情况的挑战，避免出现任何可能的违规局面。除了外部审计，T银行决定增设独立于其他部门的内部安全审计部门，因为T银行明白任何违规操作和不利的审计报告将意味着严重的商业损失，甚至是灾难性的失败。

　　系统架构与安全审计

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

　　目前，T银行最大的数据源是核心业务系统，这部分的数据资源放在System z平台的DB2上，外部审计公司也要求T银行在主机环境上开展审计工作，从而实现对安全审计的整合。

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

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

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

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

　　核心应用安全审计

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

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

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

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

　　关注审计细节

　　在T银行搭建数据库审计环境中，通过部署DB2 Audit 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，可以自动实施不同时间段的审计内容，控制审计的工作量，以保障对系统资源占用降到最低。

　　关注整合

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

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

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

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

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

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

　　● When：审计事件发生的时间

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

　　● On What：哪些对象（文件、数据库、打印机等）参与了该审计事件

　　● Where from：审计事件发起的源系统

　　● Where To：审计事件的目标系统

　　所以，信息关联的关键是看能否找到某个应用在不同子系统内部运行时的统一关键字，例如Original ID等。具体应用时需要灵活应对。

　　编辑点评:仔细“审计”

　　随着一系列审计法案和规则不断颁布，安全审计对现代企业IT架构提出了新的挑战，本文以商业银行的案例为背景，重点分析了针对系统操作人员的数据库安全审计解决方案。系统操作人员是企业级IT系统中经授权的关键审计对象，是保障企业信息安全的关键环节，而数据库是企业数据资源的核心。因此，部署企业级安全审计解决方案往往以数据库审计安全为首。

　　此外，本文涉及了安全审计的整合。目前针对子系统级别的审计方案较多，而如何将众多的子系统集中为统一的审计视图，为业务提供更全面的审计报告才是企业真正的需求。编辑的看法是，企业级整合审计解决方案的话题是开放的，根据不同行业需求和特点，有待不断讨论和完善。