内容


MongoDB 的 InfoSphere Guardium 数据安全和保护,第 2 部分

配置和策略

保护新一代数据库

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: MongoDB 的 InfoSphere Guardium 数据安全和保护,第 2 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:MongoDB 的 InfoSphere Guardium 数据安全和保护,第 2 部分

敬请期待该系列的后续内容。

简介

此文章系列的 第 1 部分 介绍了 MongoDB 和 InfoSphere Guardium,提供了有关 InfoSphere Guardium 如何帮助您在更多应用程序中利用 MongoDB 让您感到更安全(因为它能够完全监视和审计数据活动)的一些背景信息。您了解了该解决方案的架构以及使用其原生功能保障 MongoDB 安全的一些建议,还了解了 InfoSphere Guardium 所带来的优势。

本文是此文章系列的第二篇文章,将详细介绍以下两个主题:

  • 在 MongoDB 节点上配置 S-TAP
  • 为各种典型的用例创建安全策略

第 3 部分将介绍其他一些功能,比如阻止用户、如何编写报告和访问审计数据,以及如何自动化合规性审计。

安装和配置

这一节将介绍设置和运行以及开始将 MongoDB 中的活动记录到 InfoSphere Guardium 收集器中所需的步骤。

  1. 在 MongoDB 节点上安装 S-TAP 代理。
  2. 使用正确的 MongoDB 端口配置 S-TAP 检查引擎。
  3. 验证您是否正在查看 MongoDB 流量。

开始之前

本文假定您安装了 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 要求使用企业版。)

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

  • InfoSphere Guardium 收集器的 IP 地址和用于连接它的 端口 (16016)
  • 分片服务器上 mongod 所使用的端口(默认值为 27018)和 IP 地址
  • 路由服务器 (mongo) 使用的端口(默认值为 27017)和 IP 地址

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

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

图 1. S-TAP 被配置为侦听 MongoDB 端口
mongo 上的 S-TAP 侦听 27017,在 mongod(分片)上侦听 27018。
mongo 上的 S-TAP 侦听 27017,在 mongod(分片)上侦听 27018。

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

  • 使用 Guardium Installation Manager (GIM)。借助 GIM,您实际上是在安装 GIM 代理和 S-TAP。通过使用 GIM,可以从 Web 控制器控制所有 S-TAP 升级和未来安装,无需再次访问服务器。由于管理和更新非常简单,所以大多数企业都会使用 GIM。有关 GIM 的详细信息,请参阅 InfoSphere Guardium 信息中心。有关的链接,请参阅 参考资料
  • 使用您从 Fix Central 下载的 S-TAP shell 安装程序。可以采用非交互式完成该操作,这样您就可以使用同一个命令在很多节点上安装。

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

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

图 2. 显示 S-TAP 与收集器正在通信的系统视图
显示 3 个显示为绿色的 mongo staps 屏幕
显示 3 个显示为绿色的 mongo staps 屏幕

配置检查引擎

接下来,您需要为每个 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(查询路由器服务器)检查引擎配置
显示端口范围 27017 到 27017 的 IE 配置屏幕
显示端口范围 27017 到 27017 的 IE 配置屏幕

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

图 4. Mongod(分片)检查引擎配置
显示端口范围 27018 到 27018 的 IE 配置屏幕。排除 clientIP 具有 mongos 的 IP 地址
显示端口范围 27018 到 27018 的 IE 配置屏幕。排除 clientIP 具有 mongos 的 IP 地址

使用 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 用户可以确保安装了将捕获所有流量并查看报告的策略。

  • 如果以用户身份登录,那么在 View 选项卡上,您会看到一个名为 Number of db per type 的条形图。您可以双击该报告下钻获取数据,以便查看是否有活动。
    图 5. 报告下钻
    双击 Mongodb 数据库类型以显示客户端 IP 的报告,然后双击该报告以到达 fullsql
    双击 Mongodb 数据库类型以显示客户端 IP 的报告,然后双击该报告以到达 fullsql
  • 如果您正在进行 Guardium 9.0.0.50 的全新安装,或者升级并安装了新的默认策略(名为 Default-Ignore Data Activity for Unknown Connections),那么您不会看到详细的活动。但是,您需要进入 Connection Profile List 报告,该报告将只显示任何未知连接的高级会话信息,其中包括来自 MongoDB 的那些连接的会话信息,此时这些连接应该全都是未知连接。作为一个用户,您可以在 DB Activities 下的 View 选项卡上找到该报告,如图 6 所示。
    图 6. Connection Profile List
    View >DB Activities>Connection profile list
    View >DB Activities>Connection profile list

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

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

图 7. Connection Profile List
查看上述列表主要内容的说明
查看上述列表主要内容的说明

如果您确定自己的策略配置正确,但仍然没看到流量,那么请确保您拥有报告的正确日期和时间范围。如果这也没有问题,那么可能是因为在您的 S-TAP 或检查引擎中包含一些不正确的配置,比如不正确的端口号。

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

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

表 1. 用于创建我们的样例策略规则的规则和组
规则顺序规则说明在规则中使用的组
13 分钟之内每个数据库每个用户登录失败的次数过多就会发出警告不需要。请参阅 在身份验证失败次数过多时发出实时警告
2忽略功能用户 ID 的详细活动在策略规则编辑器中对 ClientIP/Src App./DB User/Server IP/Svc.Name 字段使用 “元组” 组构建器。有关的详细信息,请参阅 忽略功能用户的活动
3SkipMongoDB 内部命令MongoDBSkipCommands(预先填充的组,您可以根据观察到的流量按需添加更多的组。)有关的详细信息,请参阅 过滤干扰命令
4 记录管理员用户活动的所有详细信息 管理员用户 - 创建您自己的管理员用户组,或者修改现有的管理员用户组。在本文中,我们创建了自己的管理员用户组。请参阅 特权用户的详细监视
5在特权用户访问敏感数据时发出警告。 管理员用户
MongoDB 敏感对象 – 创建您自己的 MongoDB 敏感对象

可选:添加您希望发出警告的一组特定命令。我们创建了一个名为 MongoDB WatchCommands 的命令。请参阅 在特权用户访问敏感数据时发出实时警告
6对 MongoDB Access Control 命令发出警告不需要使用组。记录对 system.users 集合的访问。请参阅 对 Data Control 命令发出实时警告
7记录集合更改是否违反策略MongoDB Change Commands - 创建您自己的 MongoDB 更改命令

可选:添加生产中一组对象或即将生产的一组对象(集合),对于这些对象来说,集合中的更改或丢弃集合可能会影响应用程序。请参阅 记录可能会影响应用程序的集合策略违反情况
8敏感文档读取次数过多MongoDB Sensitive Objects – 创建您自己的 MongoDB 敏感对象
请参阅 实时警告:对敏感数据的读取访问超过阈值

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

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

配置安全策略

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

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

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

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

  1. 单击 Tools 选项卡,并从左侧的菜单窗格中选择 Config & Control > Policy Builder
  2. 从 Policy Finder 中单击 New
    图 8. 创建新策略
    单击 new 按钮
    单击 new 按钮
  3. 提供相关说明,然后单击 Apply
    图 9. 为该策略提供一个说明
    单击 applybutton
    单击 applybutton

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

  4. 单击 Back

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

监视用例

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

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

有三种类型的规则:

  • Access:用于数据库客户端和服务器之间的交互。
  • Exception:用于数据库服务器向客户端返回的任何异常。请注意,如果您对 MongoDB 连接使用 write concern =0 或 -1(不安全),那么您将无法记录和报告任何插入、更新或移除(删除)返回的错误条件。
  • Extrusion:应用于返回的数据集。这是一个高级功能,在本文中我们不打算讨论这个问题。

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

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

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

  1. 从 Policy Finder 中选择您的新策略并单击 Edit Rules
    图 10. 编辑新策略的规则
    单击 Edit Rules 按钮
    单击 Edit Rules 按钮
  2. 在 Policy Rules 页面的底部,单击 Add Exception Rule
  3. 填写策略条件,以便从 Excpt. Type 字段的下拉菜单中指定 LOGIN_FAILED。包含最小计数(在本例中为 5)并重置间隔(在本例中为 3 分钟)。
    图 11. 指定引发登录失败规则的条件
    参见上面的文本描述。
    参见上面的文本描述。
  4. 在页面底部,单击 Add Action,然后从下拉菜单中选择 ALERT ONCE PER SESSION。该操作将在某人在 3 分钟内身份验证失败超过 5 次而无法成功实现身份验证时为每个会话生成一个警告。
    图 12. 选择一个会话一次警告
    参见上面的文本描述。
    参见上面的文本描述。
  5. 选择通知类型。在我们的示例中,我们选择了 SYSLOG 和默认的消息模板。单击 Add,然后单击 Apply
    图 13. 选择通知类型
    参见上面的文本描述。
    参见上面的文本描述。

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

图 14. 关于登录失败次数的警告(部分输出)
警告包含警告的名称以及生成警告的客户端和服务器 IP。
警告包含警告的名称以及生成警告的客户端和服务器 IP。

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

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

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

建议:您可以创建一组功能用户并忽略这些用户的活动,但是,如果您想降低丢失可疑活动的可能性,那么可以使用 connection information 来指定规则。例如,您可能想忽略来自客户端 IP 1.22.222.222 的功能用户的活动,但是,如果该用户 ID 正在通过其他任何 IP 访问该系统,那么您可能会希望记录该活动。

因此,我们将创建一个名为 “Functional MongoDB User Connections” 的组,并在我们的策略规则中使用该组。我们将会介绍填充该组的手动方法,以及通过使用 Connection Profile List 报告 的自动填充组的方法。

确切地说,该策略中访问规则字段的名称为 Client IP/SrcApp/DBUser/Server IP/Svc.Name。该特殊字段有多个组件,这些组件在 Guardium 中称为 “元组”。

您可以使用通配符替代该连接信息的任何部分。下面我们介绍一下通配符的工作原理。

  1. 从 Policy Finder 中选择您的新策略,然后单击 Edit Rules
  2. 在 Policy Rules 页面的底部,单击 Add Access Rule
    图 15. 添加访问规则
    单击 Access Access rule 按钮以显示规则构建器屏幕。
    单击 Access Access rule 按钮以显示规则构建器屏幕。
  3. 为您的新规则提供一个名称,然后单击该元组字段 (Client IP/SrcApp/DB User/Server IP/Svc.Name) 的组构建器图标,如图 16 所示。
    图 16. 单击该策略规则的连接元组字段的组构建器
    单击您要为其创建组的 t 字段右侧的组构建器图标。
    单击您要为其创建组的 t 字段右侧的组构建器图标。
  4. 为元组的每个组件填充属性。您可以使用通配符指示任何内容都有资格进行此操作。在本例中,我们让功能用户 ID 遵循一个命名惯例,因此我们会使用该惯例。此外,我们还知道这些用户 ID 所进行的工作始终来自某个特定的客户端 IP,因此我们还将添加该内容。
    图 17. 添加一个元组作为组成员
    属性 1 是一个 ip,属性 2 是 %,属性 3 是 FUNC%,属性 4 是 %,而属性 5 是 %。
    属性 1 是一个 ip,属性 2 是 %,属性 3 是 FUNC%,属性 4 是 %,而属性 5 是 %。
  5. 当您填充完一个成员的属性后,请单击 Add。该组应如图 18 所示。
    图 18. 元组已添加到该组中
    9.70.144.253+%+%FUNC%+%+%t .
    9.70.144.253+%+%FUNC%+%+%t .
  6. 添加完成员后,请单击 Back
  7. 从策略规则的元组字段中选择该组。
  8. 单击 Add Action 并从下拉菜单中选择 IGNORE S-TAP SESSION。单击 Apply。该规则现在应如图 19 所示。
    图 19. 忽略功能用户(受信任用户)连接的 S-TAP 会话
    该策略规则拥有 MongoDB Functional Users 连接组的 IGNORE S-TAP SESSION 操作。
    该策略规则拥有 MongoDB Functional Users 连接组的 IGNORE S-TAP SESSION 操作。
    注意:我们取消选中了 Cont. to next rule。这是因为该会话没有理由进入下一个规则,因为我们已经选择忽略该用户和连接的所有活动。
  9. 单击 Save

提示:让填充 Functional User Connections 组的过程自动进行

如果您的 MongoDB 流量已经受到监视,那么您可以使用内置的 Connection Profile List 报告自动化该过程。如果您以管理员身份进行登录,那么请转到 Daily Monitor 选项卡,并单击左侧菜单窗格中的 Connection Profiling List

您会看到类似于图 20 的一个报告。

图 20. Connection Profile List 示例
该图显示了报告的一部分,并显示了该元组列,在实时活动中已经填充了一些连接。
该图显示了报告的一部分,并显示了该元组列,在实时活动中已经填充了一些连接。

在该报告的底部,单击 Invoke 图标 (icon),以调用 API create_member_to_group_by_desc。在弹出窗口中,将描述字段更改为您要向其中添加此连接的组的名称,然后单击 Invoke now,如图 21 所示。

图 21. Connection Profile List 示例
描述字段被更改为 MongoDB Functional User 连接。
描述字段被更改为 MongoDB Functional User 连接。

过滤干扰命令

该规则将过滤掉 MongoDB 在内部发出的一些干扰命令,比如健康检查和服务器之间的通信。它使用了一个内置的组,名为 MongoDB Skip Commands。

  1. 从 Policy Finder 中选择您的策略并单击 Edit Rules
  2. 在 Policy Rules 页面的底部,单击 Add Access Rule
  3. 在标签为 Command 的策略规则的部分中,从组下拉菜单中选择 MongoDB Skip Commands 组,如图 22 所示。
    图 22. 从 Group 下拉菜单中选择 MongoDB Skip Commands
    参见文本描述。
    参见文本描述。
  4. 取消选中 Cont. to next rule 框(如果已选中)。因为没有任何进一步操作(这可能发生在该组中的任何命令上),因此该操作节省了处理时间。
  5. 在策略规则的底部,选择 SKIP LOGGING 作为您的操作并单击 Apply
  6. 保存您的规则。

特权用户的详细监视

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

由于这些角色中的一些角色基本上等同于超级用户,因此需要确保谨慎分发和监视这些角色,这一点非常重要。

一些组织机构要求详细监视管理用户(特权用户)的任何活动。为此要进行的策略规则操作是 LOG FULL DETAILS。无论在何时,只要使用 LOG FULL DETAILS,就会捕获每个操作的确切时间戳以及全部详细信息。确保您正确设定了您的内部 InfoSphere Guardium 存储库的大小以及设备上的缓冲区大小,以处理该工作负荷,在您的特权用户读取或写入很多文档时尤其如此。

先决条件:创建如上所述的一个 MongoDB 管理员用户组(其中包括您认为是 “特权用户” 的任何人)。

访问您的 MongoDB 策略,然后单击 Add Access Rule

向图 23 所示的规则的 DB User 字段中添加一个描述并添加您的管理员用户组。

图 23. 侧重于 DB User 条件的策略规则摘要
DB User 字段拥有一个指定为条件的 MongoDBAdmins 组
DB User 字段拥有一个指定为条件的 MongoDBAdmins 组

由于我们将在一些管理员用户活动上添加一个警告作为下一个规则,因此务必确保选中了 Cont.to next rule 复选框并选中了操作 LOG FULL DETAILS,如图 24 所示。

图 24. “Continue to next” 规则可确保 Guardium 会在引发该规则的时候处理下一个规则
显示 Cont. next rules 按钮被选中并且选择了 log full details 操作,apply 和 save 突出显示
显示 Cont. next rules 按钮被选中并且选择了 log full details 操作,apply 和 save 突出显示

如果您要测试策略规则,您必须安装该规则。转到 Tools > Policy Builder > Install and override

在特权用户访问敏感数据时发出实时警告

敏感字段

在 MongoDB 中,您还可以在字段级别对活动发出警告。例如,如果您知道您的文档集合只是用敏感数据(如驱动程序的许可证号)零星地进行了填充,并且您不希望对该集合中的文档的其他所有访问发出警告,那么您可能希望执行该操作。请注意,如果某个字段嵌入到该文档的多个深层级别,那么将记录该字段的圆点表示路径(dot notation path)。

db.CreditCard.insert({
    "Name" : "Sundari Voruganti",
    "code" : "WM2001_0",
    "product" : "Gold Card",
    "profile" : [
        {"CCN" : "11999002"},
        {"log" : ["new", "customer", "for", "now"]}
    ],
    "otherinfo" : "Contact Bob Saget"
});

在上面的示例中,Guardium 将存储 CreditCard 的一个对象和下列字段:Name、code、product、profile.CCN、profile.log 和 otherinfo。

您可以设置一个警告,该警告包含 %CCN%(用于信用卡字段)和 %DLN%(用于驱动程序的许可证字段),您还可以设置一个访问这些字段的警告。

警告是获取有关可疑或不合规则的活动的近乎实时的警告的一个好方法。警告被写入到 UI 的 Incident Management 选项卡(与其他策略违反情况相同),但也可以通过电子邮件将其发送或写入到 Syslog。如果写入到 Syslog,那么您可以将警告转发到安全智能和事件管理系统(比如 IBM QRadar 或 HP Arcsight),以便您的安全团队可以进行相应处理和调查。

先决条件:该策略规则依赖于两个组的存在情况,我们将这两个组分别命名为 “MongoDBAdmins” 和 “MongoDB Sensitive objects”。如果想限制对某个命令的警告,那么您还可以添加一个包含特定命令(比如 find 和 CopyCollection)的组。我们将创建和使用这个可选的组,我们称其为 “MongoDB WatchCommands”。它包含我们想要观察的多个命令,比如 find、update、insert、delete、cloneCollection 和 mapreduce。

图 25. 敏感对象组。对于 MongoDB 来说,集合就是对象
组包含 %credit% 和 %customer%。
组包含 %credit% 和 %customer%。
图 26. 一组特定的命令, 我们想要监视何时用于敏感数据
组包含 cloneCollection、find、insert、delete、mapreduce 和 insert。
组包含 cloneCollection、find、insert、delete、mapreduce 和 insert。

要创建您的策略规则,请从 Policy Finder 中选择您的策略,单击 Edit Rules,然后单击 Add Access Rule

我们的策略规则如图 27 所示。

图 27. 该策略会在特权用户使用特定命令访问敏感数据时发出警告
敏感对象组针对对象条件显示,而观察命令是针对命令条件显示,mongodbadmins 针对 db 用户,操作是一个会话警告一次。
敏感对象组针对对象条件显示,而观察命令是针对命令条件显示,mongodbadmins 针对 db 用户,操作是一个会话警告一次。

要测试新规则,请确保重新安装了该策略。

图 28 显示了警告的外观。

图 28. 在特权用户使用一个不允许的命令访问敏感数据时触发警告(警告摘要)
该警告显示了导致触发警告的特定命令。
该警告显示了导致触发警告的特定命令。

对 Data Control 命令发出实时警告

一个常见的要求是监视为用户提供访问权限以及特权的任何命令。在 MongoDB 中,管理员可以创建和添加用户,在 MongoDB 2.4 中,还可以为用户提供其他角色。有关 MongoDB 安全和角色的详细信息的链接,请参阅 参考资料

凭据和用户权限信息都存储在集合 system.users 中。

因此,例如,假定某个人按照以下方式创建了新用户:db.addUser({user:"sundari",pwd:"guardium",roles:["readWrite"]})

如图 29 中的报告所示,InfoSphere Guardium 会将该活动记录为对集合 system.users 的 insert 操作。该活动将包含两个对象:新用户的名称和 system.users 集合。

图 29. 显示对 system.users 集合的访问的审计报告的摘要
示例报告显示了插入用户 sundari 以及授予该用户的角色。
示例报告显示了插入用户 sundari 以及授予该用户的角色。

对于我们的策略规则,我们可能希望可以轻松地查看 system.users 集合上的任何活动。为此,您可以向记录对 system.users 集合的访问的策略中添加一个新的访问规则。图 30 显示了我们的策略规则,在该规则中,我们只是添加了对象 system.users 以及 Log Only 操作,并将我们的策略规则添加到了 UI 的 Incident Management 选项卡中。

图 30. 用于记录对 system.users 的更改的策略规则,因此可以在事件管理选项卡上看到它们
参见文本。
参见文本。

图 31 显示了一个事件的部分输出。

图 31. 管理员添加了 Sundari 用户,该用户显示在 Guardium UI 的事件管理选项卡上
显示了添加 Sundari 的管理员
显示了添加 Sundari 的管理员

注意:记录到事件管理的好处就是可以获得实时的事件记录。但是,如果这是需要定期审计的活动,那么您可能希望创建该活动的报告并将其发给审计人员。

记录可能会影响应用程序的集合更改的策略违反情况

一些组织机构的管理员和应用程序所有者可能希望记录数据库中可能会影响应用程序逻辑或性能的更改,比如丢弃或重命名某个集合,或者丢弃某个索引或数据库。您可以创建一个组,该组包含您要跟踪的命令。请注意,帮助程序方法可能会采用不同的方式在线路上流动。您要跟踪的命令包括:

  • deleteIndexes
  • drop(捕获丢弃的集合)
  • dropDatabase
  • renameCollection

如果您想避免对可能会导致许多丢弃和重命名操作的测试或 QA 活动触发该规则,那么您可能还需要添加一组 “冻结” 对象。

图 32. 我们要记录的命令组
参见上述文本中的命令列表
参见上述文本中的命令列表

随后,您可以添加一个包含该组的访问策略规则,并选择一个在触发该规则时要采取的操作。在我们的示例中,我记录了策略违反情况,但不生成警告。

图 33. 在 Incident Management 选项卡上发生的更改命令的摘要
摘要显示 sundari 重命名了一个集合并丢弃了一个集合
摘要显示 sundari 重命名了一个集合并丢弃了一个集合

实时警告:对敏感数据的读取访问超过阈值

很多组织机构都禁止其员工(以及黑客)检索过多的潜在敏感数据,如果出现这种情况,则会发出警告,以便他们可以快速地调查和确定是否发生了严重的违规行为。

执行该操作的一个方法是根据 “受影响的记录” 在 MongoDB 策略的访问规则中创建一个阈值。

先决条件:

  1. 创建一组您要对其发出警告的敏感数据对象。
  2. 确保您的系统配置针对所有检查引擎启用了 Inspect Returned DataLog Records Affected。为此,请转到 Administration Console 选项卡,然后选择 Configuration > Inspection Engines 并选中相应的复选框,如图 34 所示。
图 34. 将 Guardium 配置为报告读取的文档数量
在检查引擎配置中,选中两个字段。
在检查引擎配置中,选中两个字段。

图 35 显示了我们创建的策略规则,即在任何数据库用户对敏感数据对象的读取记录的数量超过 200 时发出警告。请确保在 DB User 字段中放置了一个句点,以计算受每个数据库用户影响的记录,而不是所有数据库用户的记录。

图 35. 过度发现警告规则(excessive finds alert rule)的定义
该组由 MongoDB 敏感对象组成。DB User 是一个句点。受记录影响的阈值为 200。操作是一个会话警告一次。
该组由 MongoDB 敏感对象组成。DB User 是一个句点。受记录影响的阈值为 200。操作是一个会话警告一次。

注意:该规则将在特定用户在该会话中该组的所有集合累计访问超过 200 个文档时发出警告。如果您想为每个集合设置特定的限制,那么应该对每个集合使用不同的规则。

图 36 中的警告显示一个不明身份的用户从信用卡集合中下载了超过 200 个文档。

图 36. 多度发现警告
用户是 NO_AUTH。
用户是 NO_AUTH。

结束语

在此文章系列(包含 3 个部分)的第 2 部分中,我们介绍了有关如何配置解决方案的详细信息,其中包括如何为查询路由器和分片配置特定的检查引擎。我们提供了关于如何验证 S-TAP 是否正在捕获 MongoDB 流量以及是否将其发送至收集器的一些建议。最后,我们还提供了一些样例策略规则,您可以根据您组织机构中的安全和法规要求在您自己的环境中使用这些策略规则。

在第 3 部分中,我们将介绍一个高级功能(阻止),还将介绍报告、审计浏览,以及如何自动化审计报告的注销和审计。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=972084
ArticleTitle=MongoDB 的 InfoSphere Guardium 数据安全和保护,第 2 部分: 配置和策略
publish-date=05222014