开始之前

本文假定您安装了 InfoSphere Guardium 收集器并在网络上进行了配置。针对 MongoDB 的 InfoSphere Guardium 活动监视要求使用 V9 GPU 50 或更高版本。如果您是 InfoSphere Guardium 客户并有资格升级到 V9.0，那么您可以先从 Passport Advantage 下载 Guardium，然后再安装 GPU（您可以从 Fix Central 获取它）。

支持的 MongoDB 版本为 2.0、2.2 和 2.4。从数据安全的角度讲，建议您升级到 MongoDB 2.4 或更高版本，因为这些版本可提供简介中所述的安全增强功能。（Kerberos 要求使用企业版。）

记录以下信息，您需要使用这些信息来完成该解决方案的安装和配置：

1.InfoSphere Guardium 收集器的 IP 地址和用于连接它的 端口 (16016)

2.分片服务器上 mongod 所使用的端口（默认值为 27018）和 IP 地址

3.路由服务器 (mongo) 使用的端口（默认值为 27017）和 IP 地址

在 MongoDB 节点上安装 S-TAP 代理

如图 1 所示，我们建议在 mongod 分片服务器和路由服务器上安装 S-TAP，以便监视在 mongod 分片服务器上可能发生的任何管理员活动。

图 1. S-TAP 被配置为侦听 MongoDB 端口

S-TAP 是特定于操作系统的，因此您需要为每个相应的节点安装 Linux? S-TAP。可以采用两种不同的方法来完成此操作：

1.使用 Guardium Installation Manager (GIM)。借助 GIM，您实际上是在安装 GIM 代理和 S-TAP。通过使用 GIM，可以从 Web 控制器控制所有 S-TAP 升级和未来安装，无需再次访问服务器。由于管理和更新非常简单，所以大多数企业都会使用 GIM。有关 GIM 的详细信息，请参阅 InfoSphere Guardium 信息中心。有关的链接，请参阅 参考资料。

2.使用您从 Fix Central 下载的 S-TAP shell 安装程序。可以采用非交互式完成该操作，这样您就可以使用同一个命令在很多节点上安装。

该过程的详细信息不在本文的讨论范围之内，但是您可以参阅 InfoSphere Guardium 信息中心，获得有关的详细信息。

如果您的 S-TAP 被正确配置为连接到 InfoSphere Guardium 收集器，那么管理控制台中的系统视图将显示为绿色，如图 2 所示。

图 2. 显示 S-TAP 与收集器正在通信的系统视图

配置检查引擎

接下来，您需要为每个 S-TAP 配置检查引擎。检查引擎提供了您定义 S-TAP 使用哪个协议进行监视 (MongoDB) 以及要监视哪些端口的方式。默认情况下，如 图 1 所示，用于 mongo 的端口为 27017，而用于 mongod（分片）的端口为 27018。您的端口可能有所不同。

要配置检查引擎，请以管理员身份登录 InfoSphere Guardium，并导航到 Administration Console。从左侧的菜单窗格中，选择 Local Tap s> S-TAP Control。找到 Mongos 服务器的 S-TAP，单击 Modify，然后选择 Add Inspection engine 下列菜单。

输入所需的端口信息。您的 mongos 检查引擎配置应如图 3 所示。

图 3. Mongos（查询路由器服务器）检查引擎配置

在分片服务器上，配置看起来会稍有不同。因为您可能知道，大多数 “正常” 活动都是通过 mongos 进行路由，然后路由到分片服务器上的 mongods。如果您监视了分片服务器上的所有流量，那么 Guardium 收集器会从 mongos 以及该命令路由到的所有分片服务器收到同一个消息。为了避免这种 “双重计算”，同时仍然能够监视通过 mongos 的所有流量，可将分片服务器上的 STAP 配置为排除所有 mongos 流量。

图 4. Mongod（分片）检查引擎配置

使用 API 配置检查引擎

如果您有很多节点，那么您可能会希望使用 Guardium API 向指定的 S-TAP 中添加检查引擎。只能从该 S-TAP 的活动 Guardium 主机修改 S-TAP 配置，并且只能在 S-TAP 处于联机状态（在系统概述中显示绿色）时修改 S-TAP 配置。

对于 mongos：

grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=MongoDB 
ktapDbPort=27017 portMax=27017 portMin=27017 
stapHost=<ip of Mongos server where associated STAP is installed>

对于 mongod：

grdapi create_stap_inspection_engine protocol=MongoDB 
ktapDbPort=27018 portMax=27018 portMin=27018  
stapHost=<ip of mongod server where STAP is installed> 
client=0.0.0.0/0.0.0.0 excludeClient=<ip of Mongos>

验证是否正在捕获流量

有几种方法判断是否正在向 Guardium 收集器发送流量。有经验的 Guardium 用户可以确保安装了将捕获所有流量并查看报告的策略。

1.如果以用户身份登录，那么在 View 选项卡上，您会看到一个名为 Number of db per type 的条形图。您可以双击该报告下钻获取数据，以便查看是否有活动。

图 5. 报告下钻

2.如果您正在进行 Guardium 9.0.0.50 的全新安装，或者升级并安装了新的默认策略（名为 Default-Ignore Data Activity for Unknown Connections），那么您不会看到详细的活动。但是，您需要进入 Connection Profile List 报告，该报告将只显示任何未知连接的高级会话信息，其中包括来自 MongoDB 的那些连接的会话信息，此时这些连接应该全都是未知连接。作为一个用户，您可以在 DB Activities 下的 View 选项卡上找到该报告，如图 6 所示。

图 6. Connection Profile List

作为一名管理员，您会在 Daily Monitor 选项卡上找到该报告。

该报告如图 7 所示。它包含数据库用户名、客户端 IP 以及整个连接信息 “元组”，它标识了连接信息，比如客户端 IP、源应用程序、数据库用户名、服务器 IP 以及服务名称。

图 7. Connection Profile List

如果您确定自己的策略配置正确，但仍然没看到流量，那么请确保您拥有报告的正确日期和时间范围。如果这也没有问题，那么可能是因为在您的 S-TAP

创建要在策略和报告中使用的组

我们进行的一项重要的规划练习是创建组，创建组可以大大提高效率。例如，您可以创建管理员（特权用户）用户组、敏感数据对象组、特定命令（比如分配用户和全新的命令）组和其他任何事项。对于本文，我们将介绍一些监视用例，以及如何创建策略规则以处理那些用例。几乎所有这些规则都要求使用组。表 1 是我们将要创建的规则的摘要以及每个规则中要使用的组。

表 1. 用于创建我们的样例策略规则的规则和组

在此文章系列的第 3 部分中，我们将会介绍另一个高级功能，您可以使用策略规则及时阻止访问。该功能需要一个许可证才能进行高级活动监视。

要创建一个组，请访问 Group Builder。如果您以管理员的身份进行登录，请单击 Tools 选项卡，并从左侧菜单窗格中选择 Config & Control > Group Builder。在 我们的策略规则示例之一 中将会描述 Group Builder 界面的详细信息。

配置安全策略

基于规则的安全策略是 InfoSphere Guardium 工作原理的核心。正是通过这些规则，您可以指定 InfoSphere Guardium 要记录哪些流量、在哪些条件下会发出警告以及要阻止哪些连接。

9.0.0.50 的全新 InfoSphere Guardium 安装将会包含一个忽略所有流量的默认策略。该默认策略可帮助保护您的网络，防止在激活 S-TAP 和开始监视数据库时出现过载。

我们无法在本文中介绍所有各式各样的策略规则类型及其行为。我们选择了一些常用的监视用例，并介绍了如何为这些用例配置策略规则。我们将在本文的下一小节中介绍这些用例。

现在，让我们创建一个新的策略，您可以使用该策略开始添加规则。

单击 Tools 选项卡，并从左侧的菜单窗格中选择 Config & Control > Policy Builder。

从 Policy Finder 中单击 New。

图 8. 创建新策略

提供相关说明，然后单击 Apply。

图 9. 为该策略提供一个说明

可选：单击 Roles 以提示哪些角色可以使用这个新策略。例如，如果您选择管理员，那么具有管理员角色的任何人都可以在系统中使用该策略。

单击 Back。

现在，您可以通过添加所需的规则来编辑该策略。我们将在下一小节中介绍一些典型的规则。仅当您准备好验证某个新规则或一组规则的行为时，才应安装这个新策略。

监视用例

在这一小节中，我们将会介绍涉及其他用例的一些额外的策略规则，这些用例可能适用于您的组织机构，也可能不适用，但这些用例会让您了解一些启动方法。

如果以前从未使用过 InfoSphere Guardium，那么您需要了解的一个重要概念就是策略可以包含任意数量的规则。每个规则都有说明、条件（根据这些条件评估受监视的活动）以及在触发规则时将要启动的操作。

有三种类型的规则：

1.Access：用于数据库客户端和服务器之间的交互。

2.Exception：用于数据库服务器向客户端返回的任何异常。请注意，如果您对 MongoDB 连接使用 write concern =0 或 -1（不安全），那么您将无法记录和报告任何插入、更新或移除（删除）返回的错误条件。

3.Extrusion：应用于返回的数据集。这是一个高级功能，在本文中我们不打算讨论这个问题。

在身份验证失败次数过多时发出实时警告

防范可能通过算法生成密码的黑客的常见要求是：在某个会话中尝试失败的数量超过您定义的某个阈值时发出警告，比如在 3 分钟内尝试次数超过 5 次。

对于本规则，将会定义一个异常规则。

从 Policy Finder 中选择您的新策略并单击 Edit Rules。

图 10. 编辑新策略的规则

在 Policy Rules 页面的底部，单击 Add Exception Rule。

填写策略条件，以便从 Excpt. Type 字段的下拉菜单中指定 LOGIN_FAILED。包含最小计数（在本例中为 5）并重置间隔（在本例中为 3 分钟）。

图 11. 指定引发登录失败规则的条件

在页面底部，单击 Add Action，然后从下拉菜单中选择 ALERT ONCE PER SESSION。该操作将在某人在 3 分钟内身份验证失败超过 5 次而无法成功实现身份验证时为每个会话生成一个警告。

图 12. 选择一个会话一次警告

选择通知类型。在我们的示例中，我们选择了 SYSLOG 和默认的消息模板。单击 Add，然后单击 Apply。

图 13. 选择通知类型

警告示例：图 14 显示当您以管理员身份登录时 Incident Management 选项卡上的警告示例。

图 14. 关于登录失败次数的警告（部分输出）

忽略功能用户或连接的活动

一些组织机构拥有定期授权作业，执行一些类似于批量更新或加载的工作，这些工作需要在夜间或指定的批处理窗口中进行。这些应用程序通常是经过精挑细选的，并且在功能用户 ID 下运行。为了避免 InfoSphere Guardium 收集器中满都是与审计无关的活动，一些组织机构将使用一个名为 “Ignore S-TAP session” 的访问规则操作。

请注意，系统仍然会记录会话开始和结束信息（即，时间戳、客户端 IP、服务器 IP、用户名等等）。该规则只表示会忽略详细的命令活动。