TLS in Transit, Encryption at Rest, Key Management, and Client-Side/Field-Level Encryption

1. “Encrypted” is incomplete without saying where and with which keys

AtlasMart customer data exists in several places at once: plaintext in application memory, bytes on a network connection, database buffers, WAL/logs or immutable files, snapshots, exports, backups, and observability tooling. Encryption in transit protects a network path; encryption at rest protects persistent media; client-side or field-level encryption can keep selected fields encrypted before they reach the database service. None of these automatically replaces authorization, tenant isolation, or redaction.

2. TLS must authenticate the endpoint

Transport Layer Security (TLS) provides confidentiality/integrity for the connection only when certificate validation and endpoint identity checks are correctly configured. A client that encrypts traffic to the wrong, attacker-controlled endpoint has not achieved the intended trust boundary. The client needs an appropriate trust anchor and must verify that the certificate identity matches the endpoint it intended to reach.

Distributed systems add inter-node paths, administrative APIs, backup traffic, monitoring exporters, and key-management calls. Each path needs an explicit trust model. Do not assume enabling a single “TLS” switch covers every listener or every client.

3. Key hierarchy and envelope-encryption mental model

Envelope encryption typically separates a data-encryption key (DEK) used for application data from a customer/master key (CMK) or key-encryption key held by a key management system. The CMK wraps the DEK; rotating the CMK can re-wrap DEKs without rewriting every data value. This reduces the amount of data directly protected by a high-value master key, but it creates operational dependencies: key authorization, rotation, backup/escrow policy, and disaster recovery must all work.

4. Field-level encryption changes query behavior

Encrypting a field before it reaches the server may protect it from database/server compromise, but server-side query/index operations can become limited. Deterministic schemes can preserve some equality-query behavior at the cost of leakage patterns such as equal plaintext mapping to equal ciphertext. Randomized encryption provides stronger concealment of repeated values but prevents ordinary server-side equality matching on ciphertext. Product-specific features differ, so record exact supported operations and editions rather than assuming “encrypted fields are queryable.”

MongoDB's current CSFLE documentation explicitly describes deterministic vs randomized field encryption and warns that randomized encryption prevents read operations that must evaluate the encrypted field. It also models a key vault containing DEKs wrapped by a customer master key.

5. AtlasMart lab: trust, key rotation, and key-loss failure

from dataclasses import dataclass

# This is a control-flow/key-lifecycle simulator, NOT cryptographic code.
@dataclass
class Key:
    key_id: str
    status: str

cmks={"cmk-v1":Key("cmk-v1","active"), "cmk-v2":Key("cmk-v2","active")}
deks={"dek-customer":{"wrapped_by":"cmk-v1","status":"active"}}

record={
    "customer_id":"c-7",
    "email_ciphertext":"ENC[dek-customer]:7fd2...",
    "email_key_id":"dek-customer",
    "country":"AZ",
}

def tls_validate(cert_hostname, requested_hostname, trusted_ca):
    return trusted_ca and cert_hostname == requested_hostname

def can_decrypt(rec):
    dek=deks.get(rec["email_key_id"])
    if not dek or dek["status"] != "active": return False, "DEK unavailable"
    cmk=cmks.get(dek["wrapped_by"])
    if not cmk or cmk.status != "active": return False, "CMK unavailable"
    return True, "key path available"

print("TLS IDENTITY VALIDATION")
print("valid endpoint:", tls_validate("db.atlasmart.internal","db.atlasmart.internal",True))
print("wrong hostname:", tls_validate("evil.internal","db.atlasmart.internal",True))
print("untrusted CA:", tls_validate("db.atlasmart.internal","db.atlasmart.internal",False))

print("\nDATA PATH")
print("client plaintext -> TLS-protected transit -> server memory plaintext -> storage ciphertext/volume policy")
print("field stored as:", record["email_ciphertext"], "key:", record["email_key_id"])
print("decrypt before rotation:", can_decrypt(record))

print("\nENVELOPE-KEY ROTATION MODEL")
# Re-wrap the DEK with a new CMK without changing the application ciphertext token.
deks["dek-customer"]["wrapped_by"]="cmk-v2"
print("DEK now wrapped by:", deks["dek-customer"]["wrapped_by"])
print("decrypt after rotation:", can_decrypt(record))

print("\nDELIBERATE KEY-LOSS FAILURE")
cmks["cmk-v2"].status="destroyed"
print("decrypt after CMK destruction:", can_decrypt(record))
print("backup restore is not useful if required keys are permanently unavailable")

print("\nQUERY TRADEOFF")
print("country remains queryable; randomized client-side ciphertext for email should not be treated as normal plaintext index material")

6. Storage, backups, and secrets still need boundaries

Disk/volume encryption protects stolen media but not an attacker using a running database process with valid decryption access. Client-side encryption can protect selected fields from the server but moves key access into the application tier. Backups must preserve confidentiality and restoreability, including keys or controlled access to them. Never place plaintext master keys in the same backup archive merely for convenience; that collapses the separation the key hierarchy was supposed to provide.

Observe certificate expiry, TLS handshake failures, protocol/cipher policy, KMS latency/errors, key version usage, decryption failures, rotation progress, backup encryption/key IDs, and unauthorized key-access attempts. The next lesson applies the same “explicit boundary” thinking to tenants.

References

Foundational claims use standards, specifications, primary research, or current official documentation where practical. Product references are optional implementation anchors; the mandatory labs are vendor-neutral.

• NIST SP 800-57 Part 1 Rev. 5 — General key-management principles and cryptographic key lifecycle guidance.
• NIST SP 800-52 Rev. 2 — TLS configuration guidance for protected network communications.
• PostgreSQL 18 connection/TLS configuration — Current official TLS-related server configuration terminology.
• MongoDB CSFLE encryption types — Current deterministic/randomized field-encryption behavior and query tradeoffs.
• MongoDB CSFLE encryption components — Current DEK, key-vault, CMK, and KMS component model.