MongoDB数据安全和保护--配置和策略（二）-数据库-火龙果软件工程

捐助

MongoDB数据安全和保护--配置和策略（二）

火龙果软件发布于 2014-10-17

2837 次浏览

安排策略

InfoSphere Guardium 支持您可以安排策略安装，这意味着您在夜间可以拥有与白天不同的一组规则。您可以将该规则添加到该策略的另一个副本中，以便在您知道正在进行某个维护作业时自动安排夜间要安装的内容。

建议：您可以创建一组功能用户并忽略这些用户的活动，但是，如果您想降低丢失可疑活动的可能性，那么可以使用 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 中称为 “元组”。

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

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

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

图 15. 添加访问规则

单击 Access Access rule 按钮以显示规则构建器屏幕。

为您的新规则提供一个名称，然后单击该元组字段 (Client IP/SrcApp/DB User/Server IP/Svc.Name) 的组构建器图标，如图 16 所示。

图 16. 单击该策略规则的连接元组字段的组构建器

单击您要为其创建组的 t 字段右侧的组构建器图标。

为元组的每个组件填充属性。您可以使用通配符指示任何内容都有资格进行此操作。在本例中，我们让功能用户 ID 遵循一个命名惯例，因此我们会使用该惯例。此外，我们还知道这些用户 ID 所进行的工作始终来自某个特定的客户端 IP，因此我们还将添加该内容。

图 17. 添加一个元组作为组成员

属性 1 是一个 ip，属性 2 是 %，属性 3 是 FUNC%，属性 4 是 %，而属性 5 是 %。

当您填充完一个成员的属性后，请单击 Add。该组应如图 18 所示。

图 18. 元组已添加到该组中

.70.144.253+%+%FUNC%+%+%t .

添加完成员后，请单击 Back。

从策略规则的元组字段中选择该组。

单击 Add Action 并从下拉菜单中选择 IGNORE S-TAP SESSION。单击 Apply。该规则现在应如图 19 所示。

图 19. 忽略功能用户（受信任用户）连接的 S-TAP 会话

该策略规则拥有 MongoDB Functional Users 连接组的 IGNORE S-TAP SESSION 操作。注意：我们取消选中了 Cont. to next rule。这是因为该会话没有理由进入下一个规则，因为我们已经选择忽略该用户和连接的所有活动。

单击 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 在内部发出的一些干扰命令，比如健康检查和服务器之间的通信。它使用了一个内置的组，名为 MongoDB Skip Commands。

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

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

在标签为 Command 的策略规则的部分中，从组下拉菜单中选择 MongoDB Skip Commands 组，如图 22 所示。

图 22. 从 Group 下拉菜单中选择 MongoDB Skip Commands

参见文本描述。

取消选中 Cont. to next rule 框（如果已选中）。因为没有任何进一步操作（这可能发生在该组中的任何命令上），因此该操作节省了处理时间。

在策略规则的底部，选择 SKIP LOGGING 作为您的操作并单击 Apply。

保存您的规则。

特权用户的详细监视

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

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

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

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

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

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

图 23. 侧重于 DB User 条件的策略规则摘要

BUser 字段拥有一个指定为条件的 MongoDBAdmins 组

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

图 24. “Continue to next” 规则可确保 Guardium 会在引发该规则的时候处理下一个规则

显示 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%。

图 26. 一组特定的命令，我们想要监视何时用于敏感数据

组包含 cloneCollection、find、insert、delete、mapreduce 和 insert。

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

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

图 27. 该策略会在特权用户使用特定命令访问敏感数据时发出警告

敏感对象组针对对象条件显示，而观察命令是针对命令条件显示，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 以及授予该用户的角色。

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

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

参见文本。

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

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

显示了添加 Sundari 的管理员

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

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

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

1.deleteIndexes

2.drop（捕获丢弃的集合）

3.dropDatabase

4.renameCollection

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

图 32. 我们要记录的命令组

参见上述文本中的命令列表

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

图 33. 在 Incident Management 选项卡上发生的更改命令的摘要

摘要显示 sundari 重命名了一个集合并丢弃了一个集合

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

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

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

先决条件：

创建一组您要对其发出警告的敏感数据对象。

确保您的系统配置针对所有检查引擎启用了 Inspect Returned Data 和 Log Records Affected。为此，请转到 Administration Console 选项卡，然后选择 Configuration > Inspection Engines 并选中相应的复选框，如图 34 所示。

图 34. 将 Guardium 配置为报告读取的文档数量

在检查引擎配置中，选中两个字段。

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

图 35. 过度发现警告规则（excessive finds alert rule）的定义

该组由 MongoDB 敏感对象组成。DB User 是一个句点。受记录影响的阈值为 200。操作是一个会话警告一次。

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

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

图 36. 多度发现警告

用户是 NO_AUTH。

MongoDB数据安全和保护--配置和策略(一）

2837 次浏览