MongoDB 安全基础 101：每位开发者都应掌握的核心功能

MongoDB 提供了以三大核心原则为中心的全面安全框架：身份验证、授权与加密。

这些支柱构成了分层防御，确保单点失败不会危及整个系统。授权支柱遵循最小权限原则（PoLP），确保每个用户或应用仅拥有完成其任务所需的最低限度权限。

实施这种全面的分层方法，将显著增强整体安全态势，并大幅降低因错误配置或入侵而暴露的风险。

开启第一道关卡：身份验证

身份验证是最基础的安全步骤。它用于核验每一个尝试连接的主体身份。在 MongoDB 中，这通过启用默认为便于本地开发而关闭的安全功能来实现。

1. 了解默认配置

默认情况下，您的 MongoDB 部署只在本地主机上监听并允许未验证访问。此配置是有意为之，旨在为初始设置和本地试验提供最大便利。

对于任何生产部署，开发者需要关注两个设置：

• 身份验证状态： 默认禁用身份验证。 您可以使用--auth 或security.authorization 设置来启用授权。启用内部身份验证也会启用客户端授权。请注意，一旦启用访问控制，用户必须先通过身份验证。
• 网络绑定（bindIp）：默认情况下，MongoDB 可执行文件（mongod 与 mongos）仅绑定到localhost。此安全默认值将连接限制在同一台机器。对于生产环境，您必须在bindIp 设置中明确列出获准的应用服务器 IP 地址。若需要 IPv6 支持，可设置net.ipv6 配置项或使用 --ipv6 命令行选项，使可执行文件也绑定到本地主机的 IPv6 地址。务必仅限于授权的网络接口。

2. 如何启用身份验证

启用身份验证可将 MongoDB 从本地游乐场转变为安全的数据存储。这通常通过修改 MongoDB 配置文件（通常为mongod.conf）并重启服务器来完成。

配置文件设置： 在 security 部分设置 authorization 选项以启用该功能：

  authorization: enabled技术支持

首位用户： 启用身份验证后，在您创建管理用户之前，任何人都无法连接。这个关键的首位用户必须在 admin 数据库中创建，并授予其管理系统和创建其他用户所需的初始权限。

3. 用户与密码管理（createUser）

启用授权后，所有数据库访问都由用户及其关联角色管理。您可以使用 createUser 命令来定义这些身份。

语法与角色： 创建用户时，需要指定用户名、密码以及一个 roles 数组。角色定义其权限（例如在某个特定数据库上拥有 readWrite 权限）。

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // This function prompts for a password, which 
                                              // avoids storing the plain-text password in 
                                              // shell history and command logs.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)技术支持

SCRAM 标准： MongoDB 采用 加盐质询响应身份验证机制（SCRAM） 来安全处理密码。SCRAM 避免存储明文密码，而是使用强密码学哈希与加盐，使其能够抵御彩虹表等常见攻击手段。

4. 高级身份验证选项

对于具有严格合规要求或复杂基础设施的组织，MongoDB 支持与现有企业级身份验证系统集成：

• x.509 客户端证书： 允许客户端使用数字证书而非密码进行身份验证，提供强韧的身份校验层，常用于机器间信任。
• LDAP/Kerberos： 将 MongoDB 与 Active Directory 或 OpenLDAP 等外部服务集成，使用户可使用现有企业凭据访问数据库。
• OpenID Connect（OIDC）身份验证——员工与工作负载： 面向现代云原生与混合环境，MongoDB 支持身份联合，覆盖 员工（Workforce）（通过 Azure AD、Okta 等 IdP 获取用户访问）以及 工作负载（Workload）（使用云提供商身份进行机器到机器的身份验证，如 AWS IAM 或 Google Cloud 服务账号）。

授权：用 RBAC 定义角色

身份验证确认用户是谁；授权决定该用户能做什么。MongoDB 的基于角色的访问控制（RBAC）系统是管理权限的核心机制，确保用户与服务仅与其严格需要的数据与命令交互。

1. 基于角色的访问控制

在 MongoDB 的 RBAC 模型中，权限被打包为角色，这些角色分配给用户。您无需分配数百项独立权限，而是分配单个角色（例如 inventoryReader），其中已包含一组预定义权限（例如对 inventory.products 的读取）。这使得权限管理更具可扩展性与可审计性。

2. 每位开发者都常用的内置角色

MongoDB 提供了一套强大的内置角色，覆盖最常见的访问模式。以下是几个示例。完整列表请参考上方链接。

• read 与 readWrite（数据库级访问）： 这是应用用户最常见的角色。它们分别对指定数据库中所有非系统集合授予只读或读写操作权限。
• dbAdmin： 授予管理特定数据库所需的管理权限，如创建、删除与修改索引和集合。适用于开发团队或数据库维护脚本。
• clusterAdmin（运维访问）： 通常仅供运维（DevOps/Ops）人员使用的高权限角色。它授予管理整个 MongoDB 部署所需的权限，包括配置副本集、分片以及执行备份。应用开发者很少需要此角色。

3. 落实最小权限原则

现代数据库安全的基石是最小权限原则（PoLP）。它要求对每位用户（尤其是应用用户）仅授予执行其必要任务所需的最低权限，不多也不少。

最佳实践示例： 与其使用全局 readWrite 用户，不如创建面向应用的专用用户。比如，若您的库存服务只与 app_data 数据库交互，则应用用户应仅被授予对该单一数据库的 readWrite 访问。这种分区能防止受损服务越权访问其他数据库（如 billing 或 users）。

代码示例：创建最小权限用户

本示例创建一个用户（inventory_service），其读/写访问被严格限制在 app_data 数据库内。

use admin
db.createUser(
   {
     user: "inventory_service",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "app_data" }
     ]
   }
)技术支持

4. 创建自定义角色（当内置角色不够用时）

尽管内置角色功能强大，但合规或复杂的应用逻辑可能需要更细粒度的控制。在这种情况下，MongoDB 允许您使用 自定义角色，通过 db.createRole() 命令来定义。

定义细粒度权限： 自定义角色允许您精确指定可在资源上执行的特权操作（如 find、update、insert），且范围可限定为集群、数据库或集合级别。组织还可以利用字段级隐藏等技术，在公共集合中保护高度敏感的数据字段。

代码示例：创建自定义角色

本示例创建一个自定义角色（product_creator），其只能向 app_data 数据库中的 products 集合插入文档。

use app_data
db.createRole(
   {
     role: "product_creator",
     privileges: [
       {
         resource: { db: "app_data", collection: "products" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)技术支持

全面数据防护：网络隔离与加密

强有力的身份验证与授权可控制对数据库的访问，但全面安全还要求保护数据本身——无论是在网络传输中（in transit）还是落盘存储时（at rest）。

1. 使用 TLS/SSL 保护传输中的数据

无论是数据中心内部网络还是云外部网络，数据传输都必须加密，以防止窃听与中间人（MITM）攻击。MongoDB 使用传输层安全协议/安全套接字层（TLS/SSL）对客户端（如您的应用）与服务器之间的所有通信进行加密。

若未启用 TLS/SSL，用户凭据、查询参数和敏感结果将以明文传输，极易被拦截。启用 TLS/SSL 可确保数据在传输过程中被加扰并得到保护。

启用 TLS/SSL： 这主要通过配置来完成，您需要指定服务器用于身份校验与密钥交换的证书：

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem技术支持

• net.ssl.mode: requireTLS 强制所有传入连接使用 TLS/SSL，拒绝不安全的尝试。
• certificateKeyFile 指向您生成的 TLS/SSL 证书及证书颁发机构文件。

2. 防火墙与网络分段

网络分段通过限制可连接数据库的物理或虚拟接口，提供关键的防线。即便攻击者获得了网络访问，他们仍需突破您的外围防护。

• 通过 IP 白名单限制访问： 使用 bindIp 设置或配置网络防火墙，您可以将特定 IP 加入白名单。
• 最佳实践： MongoDB 服务器应仅对您的应用服务器、负载均衡器或代理层开放，绝不应直接暴露在公共互联网上。此分段可确保数据库受应用基础设施安全边界的保护。

3. 静态数据加密（存储引擎加密）

保护静态数据可确保即使物理磁盘或宿主环境遭到破坏，文件仍不可读。MongoDB 通过存储引擎加密实现这一点。

• 工作原理： WiredTiger 存储引擎可配置为对磁盘上的所有数据文件、配置文件和日志文件进行加密。数据在写入时透明加密、读取时透明解密，使用系统管理的加密密钥。
• 关键注意事项： 虽然这是至关重要的安全层，但原生静态加密通常是MongoDB Enterprise 功能，并依赖外部的密钥管理互操作协议（KMIP）服务器或本地密钥文件来管理加密密钥。

4. 客户端字段级加密（CSFLE）：开发者的黄金标准

静态加密保护整个数据库，而客户端字段级加密（CSFLE）则为开发者提供对敏感数据的精细掌控，允许在数据发送到数据库之前对特定字段进行加密。

• CSFLE 简介： 使用 CSFLE 时，加密发生在应用驱动之前，即在数据离开应用服务器之前。也就是说，MongoDB 服务器从未看到明文敏感数据；它只存储密文。敏感数据在服务器端始终保持加密状态，包括内存、服务器日志与存储中。
• 开发者最强有力的工具： CSFLE 是满足合规（如 GDPR、HIPAA）的黄金标准，因为即便数据库完全被攻破，敏感字段（如个人身份信息或金融信息）仍保持加密受护。开发者必须主动决定加密哪些内容，并将加密逻辑直接集成到应用代码中。

5. 在用加密：可查询加密

可查询加密（Queryable Encryption）是 CSFLE 的一项进阶能力，解决了对加密字段进行查询的难题。它使应用能够直接在密文上执行等值查询（例如查找某加密字段等于特定值的文档）。这样在保持 CSFLE 安全性的同时兼顾数据可用性，实现对在用数据的加密。

审计：事后分析工具

安全措施侧重预防，而审计侧重问责与检测。MongoDB 内置的审计框架可跟踪并记录与安全相关的事件，提供不可变更的记录，这对取证、合规与前瞻性威胁检测至关重要。

1. 什么是审计，为什么重要？

审计会记录针对数据库执行的每个关键操作，形成详细的历史记录。这包括：

• 身份验证事件： 成功与失败的登录尝试。
• 授权变更： 用户与角色的创建、修改或删除。
• 配置更改： 影响安全性的系统参数修改。

此日志对安全团队进行事后事件分析（“事后检视”工具）或满足监管合规要求都极为宝贵。

2. 配置与过滤

启用审计非常简单，通常只需在配置文件中添加一行即可激活，并指定日志的输出目标（文件、syslog 或控制台）。

auditLog:
  destination: file
  format: BSON
  path: /var/log/mongodb/audit.bson
  filter: '{ atype: { $in: [ "authenticate", "createRole", "dropUser" ] } }'技术支持

• 过滤： 审计系统支持使用类查询语法进行高度细粒度的过滤，这对控制日志量至关重要。开发者应将过滤聚焦在关键的安全相关事件，例如用户管理操作、安全配置变更与身份验证尝试。

总结与后续步骤

MongoDB 提供了全面的安全功能套件，若正确部署，可形成强大的纵深防御策略。作为开发者，您的首要任务是突破开发默认值，落实这些核心控制。

在任何应用上线生产之前，请牢记以下三条核心安全要求：

• 加密传输中的数据： 所有网络连接均使用 TLS/SSL（net.ssl.mode: requireTLS）。
• 加密静态数据： 使用卷或文件系统级加密，或使用 MongoDB 的 WiredTiger 存储引擎加密（适用于 MongoDB Enterprise）来保护磁盘上的数据库文件，防止未授权访问数据库文件。
• 加密在用数据： 对高度敏感的数据字段使用客户端字段级加密（CSFLE）与可查询加密，确保即使数据库运行中数据也保持加密。

安全是不断演进的学科。若需更深入与高级的配置，请参考官方文档：

• MongoDB 安全中心： 查阅部署加固与运营安全实践指南。
• 在用加密文档： 了解如何实施客户端字段级加密（CSFLE）及其进阶能力，以及可查询加密（QE），确保您的敏感数据在使用过程中仍保持机密且可高效查询。

我也建议您看看 Introduction to Using MongoDB for Data Science in Python 课程。