Шифрование данных в состоянии покоя и TLS при передаче

Securing MongoDB data requires protection at two distinct points: encryption in transit (data moving between clients and MongoDB, or between replica set members) and encryption at rest (data stored on disk). Authentication controls who can connect, but even an authenticated user operating over an unencrypted connection exposes credentials and queries to network sniffing. Together, TLS and encryption at rest provide defence-in-depth.

TLS (Transport Layer Security) encrypts the network channel between MongoDB clients, drivers, and mongod/mongos instances. Enabling TLS prevents eavesdropping and man-in-the-middle attacks on the wire. MongoDB 4.2+ supports only TLS 1.1 and higher, with TLS 1.3 available on modern platforms. Always use TLS in any environment where network traffic could be intercepted — which includes cloud VPCs despite VPC-level isolation.

TLS is configured in the net.tls section of mongod.conf. Set mode: requireTLS to reject all unencrypted connections. You must provide a PEM file containing the server's certificate and private key. Optionally, provide a CAFile to require clients to present certificates signed by your CA (mutual TLS).

The official MongoDB Node.js driver enables TLS when the connection URI uses mongodb+srv:// (Atlas always uses TLS) or when the tls: true option is set. In self-hosted deployments, you may need to provide the CA file path so the driver can verify the server certificate. Use environment variables for certificate paths so they are not hardcoded in source code.

MongoDB offers four TLS modes during migration phases. disabled accepts only plain connections (development only). allowTLS accepts both TLS and plain (for backward compatibility). preferTLS defaults to TLS but accepts unencrypted connections. requireTLS rejects all non-TLS connections and is the only mode acceptable for production deployments.

MongoDB's default storage engine, WiredTiger, supports Encrypted Storage Engine (available in MongoDB Enterprise). It encrypts data files on disk using AES-256-CBC or AES-256-GCM. Even if an attacker gains access to the physical disk or a disk snapshot, they cannot read the data without the encryption key. This addresses compliance requirements such as GDPR, HIPAA, and PCI-DSS that mandate protection of data at rest.

MongoDB Atlas provides encryption at rest using cloud provider key management: AWS KMS, Azure Key Vault, or Google Cloud KMS. Customers can bring their own Customer Master Key (CMK), giving them full control — if you delete your CMK, Atlas cannot decrypt your data. Atlas's encryption at rest is enabled per project in the Security settings and applies to all clusters in that project.

Encryption is only as strong as the security of its keys. Follow these key management best practices: store encryption keys in a dedicated Key Management Service (KMS) rather than on the same server as the database; rotate encryption keys regularly (MongoDB supports key rotation without re-encrypting all data); use separate keys for development, staging, and production; and enable KMS audit logs to track all key access events.

TLS certificates expire, typically after 1–2 years. MongoDB supports online certificate rotation: you can deploy a new PEM file and send the rotateCertificates command to mongod, which picks up the new certificate for all new connections without restarting the process. Plan certificate renewal at least 30 days before expiry to avoid last-minute scrambles and production outages.

TLS and encryption at rest protect data on the wire and on disk, but network-level controls add another layer. In MongoDB Atlas, use IP Access List entries to whitelist only your application servers and developer IPs. For production, use VPC Peering or AWS PrivateLink so traffic between your application and Atlas never traverses the public internet, eliminating a large class of network-based attacks even before TLS is considered.

Once TLS is enabled, verify that all connections are encrypted by checking the connPoolStats or the MongoDB connection log. MongoDB logs TLS handshake failures so you can identify any legacy client still attempting plaintext connections. In Atlas, the Monitoring tab shows active connections and their TLS status, making it easy to confirm full enforcement before removing the allowTLS mode.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: requireTLS in mongod.conf enforces encrypted client connections and should be the only mode used in production, WiredTiger Encrypted Storage Engine protects data files on disk (Enterprise) while Atlas provides CMK-based cloud encryption, and network-level controls like IP allowlists and VPC peering add layers of protection beyond TLS. Next up we cover Client-Side Field Level Encryption.