参考文稿案例db audit

1、数据库审计白皮书Imperva数据库审计的白皮书日益要求正规企业扩大审计范围，将(IT)纳入数其中。审计尤其关心数据库中与某些企业应用程序相关的据，这些应用程序包括 SAP、Oracle E-Business Suite、PeopleSoft以及其他 Web 应用程序。法案 (SOX)、健康保险流通与责任法案 (HIPAA)、支付卡行业 (PCI) 标准和其他条例均要求实施最佳措施来保护敏感数据。在检验合规性中，审计会对数据库环境进行多方面检查，包括：用户管理、讨论审计求。下面，验证、责任划分、和审计。本文将集中。审计必须符合特定条件，从而满足审计的要给出审计会提出的五个关键问题，这些问题是为

2、了确定企业是否实施了最佳做法并合乎规章要求。而Imperva公司的SecureSphere 数据库监视网关，正是为了符合审计对数据库的种种详尽而严格的要求而设计的。SecureSphere 数据库监视网关是一系列数据库自动审计设备，适用于 MS-SQL、Oracle、DB2 、Informix和 Sybase环境。SecureSphere 网关部署为非网络器，可为应用程序包（如 Oracle E-Business Suite、SAP、PeopleSoft 和自定义 Web 应用程序）建立而且详细的数据库活动。此外还提供有一个的主机，用于监视数据库管理员的本地（如台、telnet、ssh）活动。

3、中心管理服务器可对多个分布式网关和进行统一管理。Imperva, Inc.第 1 页数据库审计白皮书数据库审计会提出什么问题？本文将提出五个关键问题，在数据库审计中，IT 专业下面列出这五个问题。必须对这些问题做出回答，以据此检查合规性。1.2.3.4.5.审计过程与被审计的数据库系统是否相互？审计审计审计审计是否设立了用户责任？是否包含了适当的详细信息？是否识别异于活动基准的的范围是否足够广泛？差异？所采用的审计机制不同，对这些问题的也随之变化。遗憾的是，许多数据库审计机制在设计之初，并没有考虑要满足规章审计的要求，因此也就不能对这些问题做出圆满解答。本文将探讨不同审计机制在这些问题上的优缺

4、点。其目的是要向读者提供一些必要的信息，使其在选择要部署的审计机制时，掌握充分的信息，从而满足合规性审计的要求。1) 审计是的吗？为了确保审计的公正性，整个审计过程必须于被审计的数据库服务器和数据库管理员。由于数据库管理计数据库服务器均在被审计的系统范围之内，因此不应让其对自身进行审计。例如，一个能够审的管理员可以轻易地篡改审计，从而掩盖的行为。同样，非管理员可以利用数据库漏洞，提升的权限并篡改审计。性对审计系统的设计提出了三个要求。1.审计责任应与数据库管理相分离。数据库管理员可以参与审计以帮助解释，但这种参与应该是受到的。2.审计数据的收集应于数据库软件自身功能。否则可能会出现前文所述的数

5、据库管理员或非管理员篡改自管审计的情况。3.外部审计方案可满足些外部方案会通过性，但更为重要的是要确保审计不依赖于任何数据库软件自身功能。某自身审计机制来收集审计数据。如上面第 2 项所述，自身审计功能可能存Imperva, Inc.第 2 页数据库审计白皮书在篡改漏洞。SecureSphere -审计SecureSphere 是一个基于网络的数据库审计设备。它为 MS-SQL、Oracle、DB2 和 Sybase 环境自动创建详细的审计。与数据库自身审计相比，SecureSphere 具有诸多优点：责任、提高数据库性能、操作自动化、异类数据库环境仍保持统一审计、Web 应用程序用户审计责任

6、。责任对于管理责任和审计数据收集，SecureSphere 能够保持完全的审计性。SecureSphere 可由与数据管理。SecureSphere 的界面友好易懂，审计库管理员完全的审计不需掌握很多数据库知识即可运用自如，采用基于的管理机制，还可以在需要时，让数据库管理员以只读权限参与审计过程。Imperva, Inc.第 3 页数据库审计白皮书基于网络的审计数据收集SecureSphere 从进出数据库的网络通信中提取详细的审计信息。其运行在隐蔽模式（无 IP 地址等）下，可完全避开的视线。所有网络活动均会被跟踪，不管是否存在数据库漏洞或管理员，审计记录均遭到篡改。基于主机的审计数据收集S

7、ecureSphere DBA 监视安全跟踪数据库服务器上的所有本地数据库活动。监视范围包括操作数据库台或者使用 ssh（安全 shell）或其他工具在数据库服务器上服务器启动用户会话的数据库管理SecureSphere 网关一样，SecureSphere也不依赖自身审计功能。该安装在数据库服务器上，是非常轻巧的主机，能够直接侦听本地活动，并将活动转发到网关。由于这些基于主机的活动将被在网关中，因此无论是否存在数据库漏洞或管理员，这些都遭到篡改。最后，如果主机由于某种而停止运行，网关会立即向相应一个高优先级警报。2) 责任人是谁？数据库审计必须将所审计数据库事务归于特定用户。例如，SOX 合规

8、审计机制要求必须对财务报告数据的每个更改及执行此更改的用户姓名。但是，当用户通过 Web 应用程序（例如 SAP、OracleE-Business Suite 或 PeopleSoft）数据库时，数据库软件自身审计日志根本无法获知具体用户。因此，即使自身审计日志发现性的数据库事务，也无法找到责任用户。审计 Web 应用程序的问题在于用户从不直接与数据库进行交互。而是由 Web 应用程序采用一种称为“池连接”的机制来代表用户数据库（图 1）。在池连接下，Web 应用程序验证每个用户，然后将所有用户通信合并为几个只标识了该 Web 应用程序帐户名称的数据库连接。由于根本没有建立单个用户的唯一连接，

9、因此数据库收到实际用户的任何。图 1：数据库自身审计系统的是应用程序名称，而不是实际的用户名。Imperva, Inc.第 4 页数据库审计白皮书通过避免对每个用户进行验证并为其建立唯一连接，Web 应用程序在性能上具备显著优势。但其结果是数据库审计将所有活动都关联到 Web 应用程序帐户名，而这明显审计对责任的要求。怎样才能消除这一盲点？可考虑采用以下四种方法：重写应用程序、计数据和外部数据库审计设备。数据库审计机制、Web 应用程序审重写应用程序重写 Web 应用数据库软件是最容易想到，但也可能是最不切实际的解决用户责任问题的方法。有两种常用的重写应用程序的方法也以采用：唯一帐户和。唯一帐

10、户我们所考虑的第法是重写 Web 应用程序软件，使每个用户唯一的数据库帐户。这样做的相应的用户名。好处是，所有标准数据库自身审计工具均可在但此方法也存在一些问题。每个事务的同时性能 - 为每个用户维护唯一连接所需的额外处理开销会显著降低 Web 应用程序的性能。这是使用池连接的主要。用户管理 建立唯一连接会将用户管理的责任转移给数据库管理员。这需要对组织责任进行重大更改。这种责任转移需要数据库管理员、新培训和新管理工具。第软件的限制 - 商业软件包（SAP、PeopleSoft 等）一般都是可由企业自定义的，对基本结构的修改很少达到此方法所需的修改程度。多数情况下，所能采取的最佳方法是要求软件

11、供应商在将来的版本中增加数据库用户审计功能。成本 - 如上所述的代码更改和用户管理变化会耗费大量用程序都划拨大量预算，才能完成这些更改。必须为每个要修改的应时间 - 对单个应用程序完成如上所述的广泛代码更改和用户管理变化工作也要花费几间。对于拥有数以百计应用程序的组织来说，这种转变可能要花费几年时间。时风险 - 广泛的代码更改，尤其是在用户登录方面，会给应用程序可用性带来巨大风险。对于执行关键任务的应用程序的更改，应在生产部署前进行全面的测试，并在部署后进行严密监视。毫无疑问，为每个数据库用户建立唯一连接是不可取的。另法是继续使用池连接，但在每个数据库请求中嵌入一个用户标识。必须对数据库重新编

12、程，以在审计中加入信息。“”方法对 Web 应用程序性能影响较小，且不需要转移用户管理责任。另一方面，此方法可能需要更加复杂的代码重写，涉及 Web 代码重写和数据库服务器代码重写。因此，该方法具有前面所述的其他所有与代码重写相关的缺点，包括：第软件限制、成本、时间和风险。Imperva, Inc.第 5 页数据库审计白皮书数据库解决方案一些数据库平台内置了可跟踪应用程序用户的机制。遗憾的是，特殊数据库请求包含到所有代码模块中，这些机制仍然需要重写 Web 应用程序。因此，该方法具有前述大部分重写缺点：第软件限制、成本、时间进度和风险。此外，解决方案从根本上是特定于供应商的。因此，拥有多个数据

13、库供应商的组织将无法解决涉及整个组织的问题，或者不得不设计和支持多个解决方案。Web 应用程序审计数据一些组织试图通过在数据库审计数据中补充 Web 应用程序审计数据来满足数据库责任审计要求。例如，如果可疑数据库事务来自于“应用程序帐户”，则审计可能会尝试检查具有相似时间戳的 Web 应用程序审计数据，以识别破坏者。这个办法听起来不错，但却不容易实现。任何时候，都可能有成百上千的用户同时登录到一个应用程序。虽然将应用程序的时间戳和数据库审计数据关联起来可减少潜在破坏者的数量，但通常不能确定最终破坏者。审计必须通过解读每个事务的详细信息（Web缺点。参数等），将特定 Web 请求与相应的数据库事

14、务相匹配。此处理方法有如下参数、专业性强 上述手动关联所需的广泛的 Web 应用代价高。成本高 手动关联的人力耗费极大，因此即使对单个应用程序也花费不菲。如果涉及多个应用数据库平台，则这种处理的成本会进一步增加。数据库设计专业知识不但难度大而且合规性不确定 - 审计接收到的数据库审计数据没有与用户相关联。承诺在发生可疑活动时可能会确定，这是无法令审计满意的。SecureSphere 通用用户跟踪SecureSphere 的通用用户跟踪技术通过同时跟踪 Web 应用数据库请求来确定审计责任。这使SecureSphere 可以开发一个用于所有数据库事务以及相应的 Web 事务的模型，这实际上是对

15、Web 应用程序的反向工程。然后，Web 应用程序跟踪机制实时捕获用户登录信息，并跟踪该用户的 Web 事务。这样 SecureSphere 就可实时将每个数据库请求与其相关 Web 事务和责任 Web 用户相关联。即使同时有多个 Web 用户启动同一 Web 事务，SecureSphere 也能借助事务的详细信息（Web 参数、参数等），将数据库事务确定地关联到正确的 Web 用户。Imperva, Inc.第 6 页数据库审计白皮书图 2：SecureSphere的通用用户跟踪技术将数据库活动与 Web 应用程序相关联SecureSphere 所进行的关联过程与上一部分（Web 应用程序审

16、计信息）所述的手动事后日志分析过程相似，只不过是自动的。但是，由于 SecureSphere 可实时鉴别用户，因此实现了事后分析所不能完成的高级审计功能。例如，可指定审计规则来跟踪来自特定用户或用户组的。同样，还可检测并未通过验证的对敏感表的。SecureSphere 没有前述其他用户责任解决方法的任何缺点。它不需要重写应用程序，不影响性能和用户管理，此外还支持异类数据库环境。因此，SecureSphere具有部署快捷、成本合理的优点，且给应用程序可用性带来任何风险。表 1：各种建立 Web 应用程序用户责任的数据库审计方法比较Imperva, Inc.第7 页性能用户管理成本第软件限制风险时

17、间是否实时外部审计设备(SecureSphere)无影响无影响低无无短是重写应用程序 -唯一连接影响转为 数据库管理高严重高长是重写应用程序 -影响很小无影响高严重高长是数据库 解决方案影响很小无影响高严重高长是Web 应用程序审计数据无影响无影响高无无无否数据库审计白皮书3) 审计是否包含了足够的细节？为了有效地重建以往数据库这一级别。假设有下面两条审计，审计需要详细的审计信息，详细到准确的和响应属性，有关名叫“JOHN”的客户服务中心。A. JOHN 向B. JOHN 向条库请求数据，数据库返回数据库请求所有客户的姓、名、电子邮件地址、号码和号，数据库返回 634577假定在正常工作中，J

18、ohn单个客户，则从第一条不甚详细的审计（例 A）中发现不了任何异常活动。但第二条较为详细的审计问 634577 位客户的个人信息（包括（例 B）则清楚地表明有可疑活动发生。因为没有理由要访号）。若要彻底了解该事务，审计需要全部相关细节。遗憾的是，详细的事务日志会使任何审计系统的处理器、磁盘和 I/O迅速地消耗殆尽。事实上，数据库自身审计所需的磁盘空间常常远大于实际数据所需的磁盘空间。多数外部审计解决方案都这一规模变化的问题。为了应对这些等规模环境或大规模环境下，它们仅，许多审计系统仅在小规模环境下必要的详细信息。而在中基本的事务属性。更糟糕的是，一些系统不的，而仅对做整体（如 John库 1

19、0 次）。这种方忽略重要的细节信息。不管规模大小，审计系统都必须数据库活动的详细信息。SecureSphere 分布式审计体系结构SecureSphere的分布式审计体系结构（图 3）不但可收集详细数据，而且具有随数据中心规模变大而扩展的能力。此体系结构包含三个要素。部署多个 SecureSphere 网关，以便将原始审计计算和能力调整到所需水平。SecureSphere MX 管理服务器负责协调分布式网关间的活动，使审计看到的是一个统一的数据中心视图。该管理服务器可有效地管理多个网关，使其如同一个网关一样。外部系统使系统的容量超过网关的能力。Imperva, Inc.第 8 页数据库审计白皮

20、书图 3：SecureSphere 的分布式审计体系结构不但可收集详细数据，而且具有随数据中心规模变大而扩展的能力。与其他方法相比，分布式审计体系结构具有显著优势。与数据库自身审计功能相比当审计要求升级时， 依靠数据库自身审计功能会显著降低数据库性能和可用SecureSphere 免除了主机数据库服务器的所有审计工作，这实际上提高了数据库性能和空间。能力。与其他外部审计解决方案相比其他外部审计解决方案或者建议收集有限的数据，或者要求对大规模部署环境下的分布式审计设备进行管理。有限的数据收集不能满足审计的要求，的设备管理会显著增加管理成本并降低审计的整体效率。SecureSphere 的管理服务

21、器可统一管理大规模部署环境下的多个网关。4) 审计系统能否识别差异？对于审计系统来说，仅提供按时间排列的所有数据库事务的列表是不够的。大多数数据库环境会生成大量信息，这会使这样的系统根本无法用作识别活动的工具。一个有效的审计系统应提供事件优先级视图，能够将差异与合法的或称“基准”用户活动。但是，多数自身审计方案或外部审计方案提供的是无优先级视图，这迫使审计进行代价高昂的手动日志检查处理。Imperva, Inc.第9 页数据库审计白皮书SecureSphere - 动态建模SecureSphere 的动态建模技术可监视实时数据库通信，从而创建经过验证的代表每个用户正常行为的基准模型。然后，通过

22、比较该模型与所观察的行为，SecureSphere 就可识别与模型存在差异的活动。例如，如果一个无需知道业务信息的数据库管理员突然检索了 10000 条客户则 SecureSphere 会设立一个标记。，动态建模的是统计学习算法，该算法可将模型中的随机过滤掉，并使系统随着时间的逐渐推移不断适应合法行为的变化。其他审计系统宣称具有“学习”能力，其实仅会在指定学习期限内不加区分地所有活动。市场上这些同类所采用的这种过分简单化的方法存在着两个问题。1.由于其他在单调期间将所有活动都包含到基准模型中，因此随机和可能的异常均成为基准的一部分。相反，SecureSphere 学习算将随机从模型中过滤掉。S

23、ecureSphere 具备数据库漏洞知识，因而能够将企图利用这些漏洞的异常过滤出来。2.一旦其他同类的指定单调期限结束，合规管理就必须不断地手动更新基准，以及时反映数据库活动的变化。如果这些在某一时间自动学习而成一个新的基准，则它们将丢失对基准所做过的所有手动更改。相反，SecureSphere 学习算法从着时间不断适应行为变化，且随时都可手动修改模型。停止其作用。每个模型都会随由于 SecureSphere 的动态建模技术能持续见效，因此除了标准的审计外，还可以配置差异能够触发实时警报。在实时警报的协助下，SecureSphere 管理员就可在必要时，立即对严重做出响应。5) 审计的范围是

24、否足够广泛？数据库审计的范围应足够广泛，以识别欲利用数据库平台软件（应用程序、操作系统等）或协议实现中存在的漏洞的任何企图。SQL Slammer 漏洞和 Windows RPC 漏洞就是众多此类漏洞的两个代表，者曾利用这些漏洞对世界范围内的数据库基础结构造成了严重破坏。我们需要专业防御系统 (IPS) 和协议验证方案来识别此类的。因此，为了向审计提供数据库活动的中是非常有必要的。完整情况，将从这些数据源收集来的数据整合到审计SecureSphere 防御系统和数据库协议验证除了上述详细事务功能外，SecureSphere 还集成了先进的数据库 IPS 和协议验证。这些技术整合在一起即可提供所

25、有数据库活动的全面而详尽的报告。数据库 IPSSecureSphere IPS 基于特征来识别以已知数据库平台软件漏洞为目标的。通过将与Snort® 兼容的特征数据库和由 Imperva 的国际安全研究机构 应用防御中心 (ADC) 开发的特定于数据库的特征相组合，SecureSphere 的独有 IPS 技术完全满足数据库部署的要求。Imperva, Inc.页第10数据库审计白皮书ADC 还利用上下文属性（如受影响的系统、风险、准确度和频率）对每个特征进行优化。用户可利用这些属性自定义 IPS 策略，使其符合特定环境。最后，Imperva 的数据中心安全更新服务每周自动进行特征更

26、新，以确保持断实施最新保护。数据库协议验证者可能会利用数据库协议漏洞来达到各种目的：验证的数据、绕过自身审计日志等。为了检测此类活动，SecureSphere 采用了业界独有的数据库协议验证技术。该技术采用了 Imperva 的应用防御中心 (ADC) 开发的一种独特的数据库协议结构模型，该模型用作对比当前协议消息和期望消息的基准。任何与期望消息不符的情况均会下来，并列入预配置报告供审计查看。数据库协议验证技术在业界是独一无二的，如下。数据库协议不符合任何开放标准。它们是每个数据库供应商所专有的，而且获得这些文档非常不容易，甚至根本无法获得。而 SecureSphere 协议模型只要通过广泛的基础研究即可获得。新的数据库软件版本中数据库协议经常有所修改，而且这种修改并不公开通知。为了持断向SecureSphere 客户提供所有协议支持，应用防御中心