Separate storage-engine encryption, cloud-provider encryption, customer-managed keys, and client-side field encryption by trust boundary.

Storage Encryption and Key Management Boundaries in Self-Managed and Managed Environments

AtlasMart wants protection against stolen disks and cloud-storage snapshots, but it must not claim that Community Server has native at-rest encryption or that a storage key protects data from an already-authorized database administrator.

Advanced120–200 minutesAt-rest boundary labMongoDB 8.3.8 · mongosh 2.10.0 · PyMongo 4.17.0Last reviewed: September 2026

Learning objectives

Explain the WiredTiger/Enterprise and Atlas storage-encryption boundary without attributing native at-rest encryption to Community Server.

Distinguish a storage data-encryption key from the externally managed master/customer key that protects it.

Compare self-managed KMIP/local-key approaches with Atlas cloud-provider and customer-managed-key responsibilities.

Identify which backups/logs inherit storage encryption and where additional controls are required.

Prove the current lab edition before deciding whether an at-rest command applies.

Reproducible lab baseline

This lesson pins MongoDB Community Server 8.3.8 with mongodb/mongodb-community-server:8.3.8-ubuntu2204-slim, mongosh 2.10.0, and PyMongo 4.17.0 where driver behavior is used. Topology: one disposable Community standalone named atlasmart-ch23-l2. The mandatory lab is an edition/architecture exercise; native WiredTiger encryption-at-rest commands are discussed but not falsely executed against Community. Host publication is loopback-only on port 27182. Authentication/TLS state is stated next to the experiment. Default read/write concern and primary read preference are used unless noted. FCV is observed and never changed. The local KMS examples generate disposable 96-byte master keys at runtime and never embed a real cloud/KMIP credential. Atlas, Enterprise Advanced, AWS KMS, Azure Key Vault, GCP KMS, KMIP, and HSMs are optional production paths. Product runtime labs were not executed in the generation environment; ciphertext values, key identifiers, timings, storage amplification, and recovery results must be measured locally rather than copied as invented output.

1. Native storage encryption lives below BSON semantics

MongoDB Enterprise Advanced can encrypt WiredTiger data files at rest. Atlas also encrypts storage at the cloud-provider layer and can support customer-managed key configurations. This protects media and snapshot theft scenarios, but after the database process opens the encrypted storage engine it can serve plaintext to an authorized client. That is why storage encryption does not replace CSFLE/QE when database-server trust is the problem.

Deployment	Native/provider at-rest behavior	Customer-controlled key option	Mandatory Chapter 23 path
Community self-managed	No native MongoDB encrypted storage engine	use OS/storage controls separately; client-side encryption for fields	edition check + client-side labs
Enterprise Advanced self-managed	WiredTiger encrypted storage engine	KMIP or documented local-key options depending deployment	optional production path
Atlas	provider-level encryption by default	customer-managed keys with supported cloud KMS/configuration	optional managed path

2. Envelope encryption separates data keys from master-key custody

A common pattern is envelope encryption: data is encrypted by one or more data-encryption keys; those keys are wrapped by a master/customer key held outside the data files. MongoDB Enterprise storage encryption keeps the master-key boundary external to the MongoDB installation. If the encrypted data files and the master key are stored together with identical access controls, the operational value of that separation is weakened.

Artifact	Purpose	Backup implication
encrypted data files	hold ciphertext pages/journal state	back them up like normal data, but recovery also needs key access
storage DEKs/internal keys	encrypt database material	managed by the engine; protected by master key
master/customer key	unwraps storage keys	must survive disaster independently and securely
KMS/KMIP policy	authorizes unwrap/rotation	permissions and endpoint availability are recovery dependencies

3. Verify Community before applying Enterprise instructions

start the pinned Community image and record the edition evidence

docker rm -f atlasmart-ch23-l2 2>/dev/null || truedocker volume rm atlasmart-ch23-l2-db 2>/dev/null || truedocker run -d --name atlasmart-ch23-l2 \  -p 127.0.0.1:27182:27017 \  -v atlasmart-ch23-l2-db:/data/db \  mongodb/mongodb-community-server:8.3.8-ubuntu2204-slim \  --bind_ip_all --port 27017until mongosh "mongodb://127.0.0.1:27182/admin" --quiet --eval 'db.runCommand({ping:1}).ok' 2>/dev/null | grep -q 1; do sleep 1; donemongosh "mongodb://127.0.0.1:27182/admin" --quiet --eval '  printjson(db.adminCommand({buildInfo:1}));  printjson(db.adminCommand({getParameter:1,featureCompatibilityVersion:1}));' mongosh "mongodb://127.0.0.1:27182/admin" --quiet --eval '  const b=db.adminCommand({buildInfo:1});  printjson({version:b.version,modules:b.modules,gitVersion:b.gitVersion});  print("Do not pass --enableEncryption to this Community lab and call the result supported.");'

Enterprise-only example — do not run on the Community lab

A self-managed Enterprise deployment can be configured with the encrypted storage engine and an external key-management method. Exact options, KMIP certificates, local-key rules, FIPS requirements, and rotation procedures are production-sensitive and must be taken from the Enterprise documentation for the exact release. The mandatory lab stops at the edition boundary instead of pretending a Community flag enables the feature.

4. Managed encryption changes responsibility, not the need for recovery tests

Atlas manages provider-level storage encryption, while customer-managed-key configurations transfer some key-custody responsibility back to the customer. If a KMS key is disabled, deleted, mis-permissioned, or unavailable, database availability and recovery can be affected even though MongoDB data files still exist. Treat KMS policy, cloud account ownership, region, backup encryption, and key-deletion protection as disaster-recovery dependencies.

Never place a real KMS access key or KMIP private key in lesson source, shell history, or repository configuration.
Separate key-administration privileges from database-administration privileges where the threat model requires independent control.
Record which snapshots/backups are encrypted and which restore workflow re-establishes key access.
Do not claim that encrypted disks prevent a live authorized database process from returning plaintext.
If the goal is to hide selected values from MongoDB itself, move the trust boundary to CSFLE or Queryable Encryption.

5. Production judgment

Storage encryption is foundational for media confidentiality and compliance, but it solves a narrower problem than client-side field encryption. Document who controls the storage master key, who can change KMS policy, how backup restore obtains it, and what happens if the KMS is temporarily unreachable. Verify the exact edition before adopting a configuration. Chapter 23 now moves the key boundary into the application with explicit CSFLE, where Community can participate without falsely acquiring Enterprise storage features.

Check your understanding

Is native WiredTiger encryption at rest a Community Server feature?
Why keep a master key outside the database installation?
Does Atlas provider-level encryption mean applications no longer need TLS?
What can make customer-managed-key Atlas deployments unavailable?
When should CSFLE/QE be considered instead of storage encryption alone?

Review the answers

1. No. Outside Atlas, MongoDB native encrypted storage engine support is an Enterprise capability.

2. So compromise/theft of database files does not automatically include the key required to unwrap storage encryption keys.

3. No. At-rest and in-transit threats are different boundaries.

4. Loss, disablement, permission errors, or reachability failures for the required KMS key can disrupt key unwrap and recovery.

5. When the database/server administrator or database storage/query layer itself is outside the plaintext trust boundary for selected fields.

Authoritative references

Version-, edition-, driver-, topology-, and preview-sensitive encryption behavior was checked against current MongoDB documentation at generation time. Re-check these sources before applying the procedure to a later release.

Keep knowledge open

Help the academy stay free and grow.

If these tutorials save you time, a small donation supports new lessons, technical review, diagrams, examples, and long-term maintenance.

ETHEthereum / ERC-20 only

0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0

Send only Ethereum or ERC-20 compatible assets to this address.