Docs Home → MongoDB Manual

Encryption at Rest静止时的加密

On this page本页内容

Encryption at rest, when used in conjunction with transport encryption and good security policies that protect relevant accounts, passwords, and encryption keys, can help ensure compliance with security and privacy standards, including HIPAA, PCI-DSS, and FERPA.静止加密与传输加密和保护相关帐户、密码和加密键的良好安全策略结合使用时，有助于确保遵守安全和隐私标准，包括HIPAA、PCI-DSS和FERPA。

Encrypted Storage Engine加密存储引擎

Note

Enterprise Feature企业功能

Available in MongoDB Enterprise only.仅在MongoDB Enterprise中可用。

Important

Available for the WiredTiger Storage Engine only.仅适用于WiredTiger存储引擎。

MongoDB Enterprise 3.2 introduces a native encryption option for the WiredTiger storage engine. This feature allows MongoDB to encrypt data files such that only parties with the decryption key can decode and read the data.MongoDB Enterprise 3.2为WiredTiger存储引擎引入了本机加密选项。此功能允许MongoDB对数据文件进行加密，以便只有拥有解密键的各方才能解码和读取数据。

Encryption Process加密过程

Note

Changed in version 4.0在4.0版中更改

MongoDB Enterprise on Windows no longer supports AES256-GCM. This cipher is now available only on Linux.Windows上的MongoDB Enterprise不再支持AES256-GCM。此密码现在仅在Linux上可用。

If encryption is enabled, the default encryption mode that MongoDB Enterprise uses is the AES256-CBC (or 256-bit Advanced Encryption Standard in Cipher Block Chaining mode) via OpenSSL. 如果启用了加密，MongoDB Enterprise使用的默认加密模式是通过OpenSSL的AES256-CBC（或密码块链接模式下的256位高级加密标准）。AES-256 uses a symmetric key; i.e. the same key to encrypt and decrypt text. AES-256使用对称键；即加密和解密文本的相同键。MongoDB Enterprise for Linux also supports authenticated encryption AES256-GCM (or 256-bit Advanced Encryption Standard in Galois/Counter Mode).MongoDB Enterprise for Linux还支持经过身份验证的加密AES256-GCM（或Galois/Counter模式下的256位高级加密标准）。

The Encrypted Storage Engine uses the certified cryptography provider of the underlying operating system to perform cryptographic operations. For example, a MongoDB installation on a Linux operating system uses the OpenSSL libcrypto FIPS-140 module.加密存储引擎使用基础操作系统的认证加密提供程序来执行加密操作。例如，在Linux操作系统上安装MongoDB使用OpenSSL libcrypto FIPS-140模块。

To run MongoDB in a FIPS-compliant mode:要在FIPS兼容模式下运行MongoDB，请执行以下操作：

  1. Configure the operating system to run in FIPS-enforcing mode.将操作系统配置为在FIPS强制模式下运行。
  2. Configure MongoDB to enable the net.tls.FIPSMode setting.配置MongoDB以启用net.tls.FIPSMode设置。
  3. Restart the mongod or mongos.重新启动mongod或mongos。
  4. Check the server log file to confirm that FIPS mode is enabled. If FIPS mode is enabled, the message FIPS 140-2 mode activated appears in the log file.检查服务器日志文件以确认FIPS模式已启用。如果启用了FIPS模式，则日志文件中会显示消息FIPS 140-2 mode activated。

For more information, see Configure MongoDB for FIPS.有关更多信息，请参阅为FIPS配置MongoDB。

Note

AES256-GCM and Filesystem BackupsAES256-GCM和文件系统备份

For encrypted storage engines that use AES256-GCM encryption mode, AES256-GCM requires that every process use a unique counter block value with the key.对于使用AES256-GCM加密模式的加密存储引擎，AES256-GCM要求每个进程使用唯一的计数器块值和键。

For encrypted storage engine configured with AES256-GCM cipher:对于配置有AES256-GCM密码的加密存储引擎：

  • Restoring from Hot Backup从热备份恢复
    Starting in 4.2, if you restore from files taken via "hot" backup (i.e. the mongod is running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.从4.2开始，如果你从通过“热”备份（即mongod正在运行）获取的文件中恢复，MongoDB可以在启动时检测到“脏”键，并自动滚动数据库键，以避免IV（初始化向量）重用。
  • Restoring from Cold Backup从冷备份恢复

    However, if you restore from files taken via "cold" backup (i.e. the mongod is not running), MongoDB cannot detect "dirty" keys on startup, and reuse of IV voids confidentiality and integrity guarantees.然而，如果您从通过“冷”备份获取的文件中恢复（即mongod没有运行），MongoDB在启动时无法检测到“脏”键，并且IV的重用将失去机密性和完整性保证。

    Starting in 4.2, to avoid the reuse of the keys after restoring from a cold filesystem snapshot, MongoDB adds a new command-line option --eseDatabaseKeyRollover. 从4.2开始，为了避免从冷文件系统快照恢复后重用键，MongoDB添加了一个新的命令行选项--eseDatabaseKeyRollover。When started with the --eseDatabaseKeyRollover option, the mongod instance rolls over the database keys configured with AES256-GCM cipher and exits.当使用--eseDatabaseKeyRollover选项启动时，mongod实例会滚动使用AES256-GCM密码配置的数据库键并退出。

Tip
  • In general, if using filesystem based backups for MongoDB Enterprise 4.2+, use the "hot" backup feature, if possible.通常，如果MongoDB Enterprise 4.2+使用基于文件系统的备份，请尽可能使用“热”备份功能。
  • For MongoDB Enterprise versions 4.0 and earlier, if you use AES256-GCM encryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").对于MongoDB Enterprise 4.0及更早版本，如果使用AES256-GCM加密模式，请不要复制数据文件或从文件系统快照（“热”或“冷”）进行恢复。

The data encryption process includes:数据加密过程包括：

  • Generating a master key.正在生成主键。
  • Generating keys for each database.正在为每个数据库生成键。
  • Encrypting data with the database keys.使用数据库键加密数据。
  • Encrypting the database keys with the master key.使用主键加密数据库键。

The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a filesystem perspective, and data only exists in an unencrypted state in memory and during transmission.加密在存储层中透明地进行；也就是说，从文件系统的角度来看，所有数据文件都是完全加密的，并且数据只以未加密的状态存在于内存中和传输过程中。

To encrypt all of MongoDB's network traffic, you can use TLS/SSL (Transport Layer Security/Secure Sockets Layer). See Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients.要加密MongoDB的所有网络流量，可以使用TLS/SSL（传输层安全/安全套接字层）。请参阅为TLS/SSL配置mongod和mongos和客户端的TLS/SSL。

Key Management键管理

Important

Secure management of the encryption keys is critical.加密键的安全管理至关重要。

The database keys are internal to the server and are only paged to disk in an encrypted format. MongoDB never pages the master key to disk under any circumstances.数据库键是服务器内部的，仅以加密格式分页到磁盘。MongoDB在任何情况下都不会将主键分页到磁盘。

Only the master key is external to the server (i.e. kept separate from the data and the database keys), and requires external management. To manage the master key, MongoDB's encrypted storage engine supports two key management options:只有主键在服务器外部（即与数据和数据库键分开），并且需要外部管理。为了管理主键，MongoDB的加密存储引擎支持两种键管理选项：

  • Integration with a third party key management appliance via the Key Management Interoperability Protocol (KMIP). 通过键管理互操作性协议（KMIP）与第三方键管理设备集成。Recommended

    Note

    For an integration with a third-party key management appliance using the KMIP, you should allow the following KMIP operations:对于使用KMIP与第三方键管理设备的集成，您应该允许以下KMIP操作：

    • Create (operation_create)
    • Get (operation_get)
    • Activate (operation_activate)
  • Local key management via a keyfile.通过键文件进行本地键管理。

To configure MongoDB for encryption and use one of the two key management options, see Configure Encryption.要配置MongoDB进行加密并使用两个键管理选项之一，请参阅配置加密。

Encryption and Replication加密和复制

Encryption is not a part of replication:加密不是复制的一部分：

  • Master keys and database keys are not replicated, and不复制主键和数据库键，并且
  • Data is not natively encrypted over the wire.数据不是通过有线进行本机加密的。

Although you could reuse the same key for the nodes, MongoDB recommends the use of individual keys for each node as well as the use of transport encryption.尽管您可以为节点重用相同的键，但MongoDB建议为每个节点使用单独的键以及使用传输加密。

For details, see Rotate Encryption Keys.有关详细信息，请参阅旋转加密键。

Audit Log审核日志

Available in MongoDB Enterprise only.仅在MongoDB Enterprise中可用。

Use KMIP Server to Manage Keys for Encrypting the MongoDB Audit Log使用KMIP服务器管理加密MongoDB审核日志的键

Starting in MongoDB 6.0 Enterprise, you can securely manage the keys for encrypting the MongoDB audit log using an external Key Management Interoperability Protocol (KMIP) server.从MongoDB 6.0 Enterprise开始，您可以使用外部键管理互操作性协议（KMIP）服务器安全地管理加密MongoDB审核日志的键。

KMIP simplifies the management of cryptographic keys and eliminates the use of non-standard key management processes.KMIP简化了加密键的管理，并消除了非标准键管理过程的使用。

The default KMIP protocol version is 1.2. You can configure MongoDB to use KMIP version 1.0 or 1.1 in the MongoDB server configuration file.默认的KMIP协议版本是1.2。您可以在MongoDB服务器配置文件中将MongoDB配置为使用KMIP 1.0或1.1版本。

To use a KMIP server with audit log encryption, configure these settings and parameters:要使用带有审核日志加密的KMIP服务器，请配置以下设置和参数：

For testing audit log encryption, you can also use the auditLog.localAuditKeyFile setting.为了测试审核日志加密，您还可以使用auditLog.localAuditKeyFile设置。

Starting in MongoDB 6.0, if you need to downgrade to an earlier MongoDB version, you must first disable audit log encryption by removing auditLog.auditEncryptionKeyIdentifier or auditLog.localAuditKeyFile. 从MongoDB 6.0开始，如果您需要降级到早期的MongoDB版本，则必须首先通过删除auditLog.auditEncryptionKeyIdentifier或auditLog.localAuditKeyFile来禁用审核日志加密。Existing encrypted audit logs remain encrypted, and you can keep any procedures you have developed for storage and processing of encrypted logs.现有的加密审核日志仍然是加密的，您可以保留为存储和处理加密日志而开发的任何过程。

Note

For audit log encryption, the audit log destination must be a file. 对于审核日志加密，审核日志目标必须是一个文件。syslog cannot be used as the destination.不能用作目标。

Unencrypted Audit Log and Process Log未加密的审核日志和进程日志

This section applies if you are not using an external Key Management Interoperability Protocol (KMIP) server to manage keys for encrypting the audit log as shown in the previous section.如果您没有使用外部键管理互操作性协议（KMIP）服务器来管理用于加密审核日志的键，则本节适用，如前一节所示。

The audit log file is not encrypted as a part of MongoDB's encrypted storage engine. 审计日志文件并没有作为MongoDB加密存储引擎的一部分进行加密。A mongod running with logging may output potentially sensitive information to log files as a part of normal operations, depending on the configured log verbosity.作为正常操作的一部分，运行日志记录的mongod可能会向日志文件输出潜在的敏感信息，具体取决于配置的日志详细程度。

Use the security.redactClientLogData setting to prevent potentially sensitive information from entering the mongod process log. 使用security.redactClientLogData设置可以防止潜在的敏感信息进入mongod进程日志。Setting redactClientLogData reduces detail in the log and may complicate log diagnostics.设置redactClientLogData会减少日志中的详细信息，并可能使日志诊断复杂化。

See the log redaction manual entry for more information.有关详细信息，请参阅日志编辑手册条目。

Application Level Encryption应用程序级加密

Application Level Encryption provides encryption on a per-field or per-document basis within the application layer.应用程序级加密在应用程序层内按字段或按文档提供加密。

New in version 4.2:4.2版新增：MongoDB 4.2-series drivers provides a client-side field level encryption framework. For more information, see Client-Side Field Level Encryption.MongoDB 4.2系列驱动程序提供了一个客户端字段级加密框架。有关详细信息，请参阅客户端字段级加密。

To encrypt full documents, write custom encryption and decryption routines or use a commercial solution.要加密完整文档，请编写自定义加密和解密例程或使用商业解决方案。

For a list of MongoDB's certified partners, refer to the Partners List.有关MongoDB认证合作伙伴的列表，请参阅合作伙伴列表。