摘要: 我们在文本中介绍了联合解决方案的基础，包括对 MongoDB 和 InfoSphere Guardium 的概述，还介绍了 InfoSphere Guardium 如何与 MongoDB 一起，在有关数据保护和合规性的方面提供巨大价值。此外，InfoSphere Guardiu ...

简介

本文的作者们来自 IBM、10gen、MongoDB 公司，他们将协作验证 InfoSphere Guardium 是否适用于 MongoDB。这是一个很不错的练习，因为我们已经对彼此的产品和用例非常了解。我们真的想编写一些内容，帮助熟悉关系型数据库和 InfoSphere Guardium 的人了解一些组织机构对某些类型的应用程序使用 MongoDB 的原因。从 InfoSphere Guardium 的角度看，我们的基础架构已经得到了扩展，涉及 MongoDB 中的不同消息协议，但是管理员和信息安全人员将会遵循相同的步骤对 MongoDB 进行审计和报告等。

我们还希望至少为 MongoDB 用户提供对 InfoSphere Guardium 中的一些功能的了解，帮助他们的组织机构实现审计和合规性目标、防止数据泄漏，并且帮助揭示有风险的活动，比如服务器端 JavaScript 的使用。

InfoSphere Guardium 中的新功能

1.尽管本文的侧重点是 MongoDB 支持，但是 InfoSphere Guardium 9.0 GPU 50 包含其他许多功能，其中包括：

2.将数据活动监视扩展到新内容以及扩展大数据和 NoSQL 平台，其中包括 MongoDB、Greenplum HD 和 Greenplum DB 和 Hortonworks 数据平台

3.增强报告功能以便加快企业级报告，以及使用新的联合查询功能来提高联合环境中审计流程的性能

4.缩短了发现时间，对数据库活动、异常以及策略违反情况进行快速分面搜索

5.通过更多内置的最佳实践查看器（报告）检测更多可疑的活动

6.在 64 位架构上支持 Guardium 设备，以便提高可伸缩性（计划在提供修补程序后，采用完整的安装映像的方式提供）

7.将所有代理（S-TAP、Guardium Installation Manager 以及 Discovery）整合成一个安装程序，以简化部署、缩短启动和运行的时间

8.利用报告的 3 次点击 API 分配来简化自动化操作和维护

在您的移动设备上随身携带 Guardium，以管理您的待办事项列表并照看整体的安全健康

完成目标令人兴奋，但需要更多的空间（与一篇文章相比）。因此，为了让某些主题的涉及面更广泛，并为其他主题提供分步说明，我们创建了一个文章系列（包含 3 篇文章）：

1、此系列文章的第 1 部分将介绍 MongoDB 和 InfoSphere Guardium，简要介绍 MongoDB 的安全最佳实践，并介绍联合解决方案的优势。本文还将介绍架构，并介绍如何让数据流入 InfoSphere Guardium 以及如何在 InfoSphere Guardium 设备中处理数据的步骤。

2、第 2 部分涉及为 MongoDB 配置 InfoSphere Guardium 监视代理的具体细节。本文还将介绍如何使用安全策略完成一些常见的用例，包括监视特权用户访问、更改和重复失败的登录。

3、第 3 部分将介绍使得 InfoSphere Guardium 成为企业普遍使用的数据安全和合规性解决方案的某些功能，其中包括阻止、查看、报告审计数据，以及创建自动化某个合规工作流程的审计流程。

MongoDB 简介

端点设备中数据的扩散、不断增长的用户量、不断增长的新计算模型（如云、社交业务）和大数据带来了数据访问和分析的需求（可以处理数量惊人的数据）。快速增长型 NoSQL 数据库的价值是能够更快速地处理应对这些趋势所需的大量数据，同时还能够通过动态架构提供更大的灵活性。例如，动态架构使得组织机构能够快速响应规则的变化。

MongoDB 会为您特别提供这些优势，同时还提供常规可操作数据存储所需的丰富查询功能。MongoDB 通过一个文档模型提供更高的开发人员效率和灵活性；还可以将它用于关系型或典型 NoSQL 数据库，或者与新的数据库一起使用。

图 1 显示了更高级别的 MongoDB 架构图，还介绍了对于理解非常重要的一些重要概念（如果您负责配置针对 MongoDB 的 InfoSphere Guardium）。（该图代表一个分片环境。MongoDB 也可以独立运行。）MongoDB 使用自动分片来获得水平可伸缩性，使用副本集来获得高可用性。客户端连接到 MongoDB 进程（分片环境中的 mongos），如果启用了安全性，那么可以选择对它们自身进行身份验证，在数据库中执行文档的插入、查询和更新。mongos 会将查询路由到相应的分片 (mongod)，以实现特殊命令。

图 1. MongoDB 架构提供一个可伸缩的环境

由于 MongoDB 使用了文档数据模型，所以它是被称为文档数据库的某种类型的 NoSQL 数据库。使用 JSON (JavaScript Object Notation) 采用分层方式建立文档模型，因此它们只包含名称-值对。这些值可以是单独的类型值、数组或文档本身（以及这些内容的组合），以匹配您在您的应用程序中拥有的任何对象。该模型可以提供快速查询，因为数据可以彼此靠近存储在文档中，而不是分布在多个表中并需要一个联接。清单 1 显示了 JSON 文档的一个示例。

清单 1. JSON 文档示例

{
"_id" : 1,
"name" : { "first" : "John", "last" : "Backus" },
"contribs" : [ "Fortran", "ALGOL", "Backus-Naur Form", "FP" ],
"awards" : [
           {
             "award" : "W.W. McDowell Award",
             "year" : 1967,
             "by" : "IEEE Computer Society"
           },
           { "award" : "Draper Prize",
             "year" : 1993,
             "by" : "National Academy of Engineering"
           }
]
}

本文档结构允许您使用在应用程序中建立对象模型的方式将数据存储在 MongoDB 中，因此它提供了充分的上市时间和极大的灵活性优势。（尤其在拥有动态的未预定义的架构时）。

在幕后，出于效率的考虑，文档采用二进制 JSON 格式 (BSON) 存储，但您永远无需处理 JSON 文档之外的任何内容。

表 1 将关系型概念和 MongoDB 概念进行了比较。

表 1. 将关系型概念映射到 MongoDB

Mongo 的其他功能旨在让您使用这个文档结构以及您喜欢的编程语言，无需花费大量时间管理数据库。高可用性、性能以及自动分片（分区）是采用某种应用程序无需担心的方式构建的，因此应用程序开发团队可以快速集中精力满足业务需求。

MongoDB 的安全建议

越来越多的企业开始了解 MongoDB 能够满足特定的应用程序需求，所以他们可能面临着满足安全性和合规性的要求，他们的组织机构中的更多已建立的数据库必须也能够满足这些要求。

MongoDB 拥有一系列出色的安全最佳实践，在他们的维基页面中已对此进行了概括。（您可以在参考资料中找到这些链接。）此外，为了解决一些基本的安全痛点，MongoDB 在其版本 2.4 中改进了以下安全措施：

1.对要求采用这种方法的企业进行 Kerberos 身份验证（仅适用于企业版），以便能够将此方法集成到他们的标准安全系统中

2.基于角色的访问控制系统，可进行更细粒度的控制

3.增强了客户端的 SSL 支持要求

重要提示：目前，InfoSphere Guardium 无法监视 SSL 用于客户端访问时的活动。

现在，让我们看一看网络配置、身份验证、角色使用方面的一些最佳实践，防止出现 JavaScript 注入攻击。

网络配置

为了降低 MongoDB 的安全风险，建议在受信任的环境中运行 MongoDB 及其所有组件，并且配合相应的防火墙控制、MongoDB 组件之间紧密绑定以及特定的 IP 端口。运行分片群集时，查询流量通常会通过一个单独的进程（称为 mongos）进行路由，当然，我们建议您监视所有经过 mongos 的活动。

如图 2 所示，特权用户或其他人有可能会直接进入分片中的 mongod 实例。因此，我们建议您不仅要使用防火墙尽可能地锁定对分片的访问，而且还要在分片上进行 InfoSphere Guardium 监视，以捕获该活动。由于您会在此系列文章的第 2 部分中掌握该内容，因此您可以在分片上将 Guardium 配置为忽略来自 mongos 的活动，因为该活动将被 InfoSphere Guardium 捕获。这样您就能够发回在分片上发生的任何其他活动。

实际上有很多设置监视的选项，但从效率角度来讲，这是一个比较合理的选项，同时还能为管理员提供必要的监视功能。

图 2. 一个推荐的配置

此外，有一个安全最佳实践，那就是使用非默认的端口运行。为了便于理解，我们使用了默认的端口配置（27017 作为 mongos，27018 作为分片服务器），但 InfoSphere Guardium 在使用非默认端口时也工作状况良好。

身份验证

一个明确的建议是在启用身份验证的情况下运行 MongoDB。（默认情况下，不启用身份验证。）从监视和审计的角度看，身份验证对于让 InfoSphere Guardium 能够选取数据库用户名也非常重要。如果您没有启用身份验证，那么您会在报告的 DB USER name 字段中看到字符串 “NO_AUTH”。（InfoSphere Guardium 在会话中间将会启动监视，在没有选取 DB 用户的情况下，您有可能看不到 NO_AUTH。）

从 MongoDB 角度看，2.4 版本之前的身份验证仅限使用在 Mongo 中托管的用户名和密码的基本身份验证，未集成到企业用户管理系统中。在执行身份验证之后，还有少量角色拥有只读或完全访问权限。在 2.4 企业版中，还添加了额外的功能，其中包括支持 Kerberos。

角色以及基于角色的访问

在 2.4 版本中，MongoDB 支持很多新角色，按照它们的作用域，大致可以将它们划分为服务器范围的角色和数据库范围的角色。在这种情况下，都有侧重于用户管理、群集管理和应用程序访问的角色。

为什么在报告中显示 SQL 标题？

默认的报告标题不使用 SQL 术语。因为 InfoSphere Guardium 由不同的组成部分组成，因此许多不同的数据库将会在企业中使用相同的策略和报告。但是，如果您拥有特定的 MongoDB 报告并且不希望在报告标题中包含 SQL，那么您可以自定义自己喜欢的报告标题。

由于这些角色中的一些角色基本上等同于超级用户，所以确保谨慎分发和监视这些角色很重要。

请注意，在使用 InfoSphere Guardium 时，您可以监视和审计对环境或任何逻辑数据库的 system.users 集合的更改，因此，您可以确保只颁发了适当的授权。图 3 显示了一个样例报告，在该报告中，您可以看到数据库用户 Indrani 向 Kathy 和 Sundari 授予了读/写角色，这相当于在 MongoDB 中的 system.users 集合上执行插入操作。

图 3. 显示授予的角色的审计报告示例（将文档插入到 system.users 中）

防止 JavaScript 注入攻击

传统的 SQL 注入类型的攻击对 MongoDB 来说不是大问题，因为它使用了 BSON（二进制 JSON）而不是字符串。但是，仍有一些情况需要注意，其中包括使用以下操作，这些使您能够直接在服务器上运行任意 JavaScript 表达式：

1.$where

2.db.eval()

3.mapReduce

4.group

降低风险的方法有很多（包括关闭所有服务器端脚本），但首先您需要能够确定使用上述这些操作的位置。在使用 InfoSphere Guardium 时，会记录这些操作中的 JavaScript 并将其报告为对象。这一点的意义是您可以设置在访问这些内容时要发生的改变或策略违反情况。这在测试环境中可能非常有用，可用于发现和确定对这些危险的使用，并在部署到生产环境之前进行必要的代码审查。图 4 中的样例报告（参见 大图）显示 $eval 正被报告为一个 JavaScript 对象。您还还可以查看全部命令文本，以便了解它们在上下文中的使用。如果这是您以后要监视的一些内容，那么您可以创建一个定期报告，该报告会告诉您再次使用这些操作中的某一个操作的时间。

图 4. 某些操作的 JavaScript（如 db.eval）以对象的形式记录在 InfoSphere Guardium 中

对 MongoDB 使用 InfoSphere Guardium 的优势

对于对真正的数据库审计感兴趣的任何组织机构以及可能需要满足法规要求（如支付卡行业 (PCI) 或萨班斯法案 (SOX) 要求）的组织机构来说，InfoSphere Guardium 都是对原生 MongoDB 功能的一个重要的有益补充。MongoDB 中的原生安全和身份验证功能与在其他数据库中一样，确实不足以满足世界上各种法规和合规性要求。这些要求中的大多数都要求提供更强有力的可问责性（accountability），因为它们能够记录和验证谁在什么时候对数据库事务执行了哪些操作。
InfoSphere Guardium 被部署在世界各地的大型和小型组织机构中，旨在解决各种数据库的数据保护问题和合规性问题。该解决方案非常灵活、功能非常强大且非常有效。MongoDB 用户可能希望看到的优势如下：

InfoSphere Guardium 记录非常详细和细化的信息，如图 5（参见 大图）中所示的样例报告所示，该样例包含客户端和服务器 IP、源程序、数据库用户（如果启用了授权）以及所有命令消息（当它流经电线时）的详细信息。在下面的示例中，Kerberos 被用作身份验证机制。

请注意，部分消息被解析和存储为一个 Verb（有时称为 Command）和 Object，这意味着这些实体是可以用于指定策略规则的项，如此系列的第 2 部分所示。例如，您可以指定一个规则，只要发出一个 find，就会触发该规则，或者任何人只要触碰敏感数据对象组中的一个对象，就会触发该规则。

图 5. 审计报告的示例

您可以审计数据库异常条件，比如失败的身份验证次数，这可能表示存在暴力攻击。此系列的第 2 部分将会介绍如何配置此项。

您可以有选择地记录对读取活动有影响的文档的数量，用这种方法对次数异常高的下载发出警报。此系列的第 2 部分将介绍这方面的一个示例。

您可以阻止本地用户访问，以防止出现管理员读取敏感内容的情况。您会在此系列的第 3 部分看到有关此内容的一个示例。

您可以为各种条件指定实时警报，并在此系列的第 2 部分了解到如何配置这些内容。组织机构有责任尽其所能地避免泄漏尴尬数据或已损坏的数据。证明合规性是您的责任的一部分，而且在发生违规时，您能够在几分钟或几小时（而不是几天或几周）内快速检测和反应，这可能意味着巨大损失和轻微不便之间的差别。实时警报以及在违反阈值时发出警报会帮助您在几秒钟或几分钟（而不是几天、几周甚至更长时间）之内检测到可疑行为。

可以使用电子邮件或通过 SNMP 将那些警报发送到另一个监视系统。还可以与 IBM QRadar 和 HP ArcSight 消息类型进行内置集成，自动将警报条件从 syslog 转发给这些系统。

必须将审计信息存储一定的时间，有时候甚至要存储几年。设计 InfoSphere Guardium 时需要考虑到这些需求的类型，并因为这种原因而提供安全存档功能。
最后，证明合规性可能非常耗时，甚至任务繁重，因为这些通常需要在一定程度上定期复查和注销。InfoSphere Guardium 不仅仅允许您创建满足审计要求所需的报告，而且还允许您拥有一个可靠的工作流功能，该功能可集成到您的业务流程中，并将所有注销和评论作为审计跟踪的一部分进行保存。

解决方案的架构

借助其不会带来干扰的架构（参见图 6），InfoSphere Guardium 提供了无需在 MongoDB 群集上更改配置的数据活动的完全可见性。

图 6. 高级架构

对于熟悉 InfoSphere Guardium 的人，可以在 MongoDB 服务器上安装 S-TAP（轻量级软件代理）。S-TAP 是一个轻量级的代理，它位于操作系统中。当 Mongo 服务器收到客户端的数据请求时，S-TAP 会复制网络数据包，并将它发送到硬化的、防篡改的硬件或软件设备（称为收集器），以便解析和分析它们，并将它们记录在 InfoSphere Guardium 存储库中。

InfoSphere Guardium 系统的真正智慧体现在收集器上。因为就是在这里，消息被分成众多组成部分，并记录到收集器上的内部存储库中，同时采取了所有必要的操作，如生成实时警报、记录活动或阻止特定的本地用户。通过将大量活动（解析和记录）卸载到硬化的收集器上，最大程度地减少了对 Mongo 应用程序的性能影响（在很多情况下不超过 2-4%），而且您可以有效地制定职责分离。

InfoSphere Guardium 基于角色的 Web 控制台对警报、报告定义、合规性工作流以及设置（如存档计划）进行集中管理，无需 MongoDB 管理员的参与，这提供了审计员所需的职责分离，并且简化了合规性活动。

消息从客户端流到 Guardium 收集器的高级示例

对于不熟悉 InfoSphere Guardium 的人，对数据流经系统有一个基本了解可以帮助您有效地理解和使用系统的其他部分，比如策略配置、报告和警报。

图 7. MongoDB 命令如何流到 InfoSphere Guardium 收集器

在我们描述该流程时可参阅图 7：

（未在图中显示。）当用户或应用程序登录到 MongoDB 时，就会启动一个新会话。InfoSphere Guardium 会始终记录会话的开始和结束，如果策略要求的话，还会记录在该会话中发生的活动。（在此系列的第 2 部分中，您会了解如何将安全策略配置为忽略在受信任连接的开始和结束之间发生的任何事情。）

用户或应用程序输入了一个 MongoDB 命令。

备注：MongoDB 客户端可能会对实际输入的内容进行某些转换（语法糖等）。InfoSphere Guardium 仅收集在电路上实际流过的内容。在本示例中，用户 Joe 输入了以下命令：

清单 2. 此示例中显示的 MongoDB 命令

test.CreditCard.insert({
    "Name" : "Sundari",
     "profile" : [
        {"CCN" : "11999002"},
        {"log" : ["new", "customer"]}
    ],
    });

BSON 消息流入 Mongo 服务器（如果是分片服务器，则为 mongos 服务器；如果是本地服务器，则为 mongod 服务器）并且在网络数据包中包含额外的信息（如数据库用户的名称、客户端 IP、服务器 IP 和时间戳）。

位于 mongo 服务器上的 S-TAP 会拦截并复制该消息。该消息通过 TCP/IP 流入正在端口 16016 上侦听的收集器。

在收集器上，分析引擎（有时称为 “嗅探器（sniffer）”）认识到这是一个 MongoDB 消息并对其进行相应地解析。在我们的示例语句中，该信息被记录到以下实体。

1.客户端/服务器实体：Joe 以 DB 用户的身份进行登录

2.命令实体：INSERT

3.对象实体：CreditCard

4.字段实体：Name

5.字段实体：profile.CCN

6.字段实体：profile.log

这对收集器上实际发生的事项进行了极大的简化，目的只是为了让您能够对此有一个基本了解。