人们常常谈论如何通过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平台操作的技术，所以要求提供简单方便的用户图形化界面，通过缩短手工审计流程而节约大量审计时间和工作量；新的审计解决方案能够简化一般性的审计任务，例如能够方便地确定某用户在某个特定时间段对哪些数据对象进行了哪些操作，提供详细的审计证据，不合法的操作也包括及时监控针对系统或数据库对象的未授权访问等。
此外，安全审计人员需要灵活地对审计信息进行过滤，生成有特殊审计目的的多种报告，而更好的解决方案应该提供扩展性支持，也就是支持将审计规则方便地应用在其他系统环境中，从而支持开放式的整合的审计需求。
| 共3页: 1 [2] [3] 下一页 | |||||
|
