Phase 8: Security, Enterprise Auditing & Cryptographic Hardening¶

Audience: Principal Security Architect & Database Infrastructure Specialist
Source References: src/mongo/db/auth/, src/mongo/crypto/, src/mongo/db/storage/wiredtiger/wiredtiger_encryption.cpp

1. Authentication Internals: The SCRAM-SHA-256 Protocol¶

MongoDB defaults to SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism) to authenticate database users.

SCRAM-SHA-256 Cryptographic Handshake:
1. Client ──► Sends client-first-message:
              n=alice, r=rOprNGfwEbeRZeAssP (Client Nonce)

2. Server ──► Responds with server-first-message:
              r=rOprNGfwEbeRZeAssP%7Tefj (Combined Nonce)
              s=W22ZaJ0SNY7soEsUEuwa (Salt)
              i=15000 (PBKDF2 Iteration Count)

3. Client Computes Cryptographic Keys:
   - SaltedPassword = PBKDF2(HMAC-SHA256, Password, Salt, 15000)
   - ClientKey = HMAC(SaltedPassword, "Client Key")
   - StoredKey = SHA256(ClientKey)
   - AuthMessage = client-first + server-first + client-final-without-proof
   - ClientSignature = HMAC(StoredKey, AuthMessage)
   - ClientProof = ClientKey XOR ClientSignature

4. Client ──► Sends client-final-message with ClientProof.

5. Server Validates Proof:
   - Server reads StoredKey from admin.system.users.
   - Computes ExpectedClientKey = ClientProof XOR HMAC(StoredKey, AuthMessage).
   - Verifies SHA256(ExpectedClientKey) == StoredKey.
   - Grants Authenticated Session!

Security Invariant: The database server stores only StoredKey and ServerKey. The plaintext password or even SaltedPassword is never transmitted across the wire and never stored in the database.

2. Role-Based Access Control (RBAC) & Principle of Least Privilege¶

Privileges in MongoDB are combinations of Resources (databases, collections, or cluster components) and Actions (find, insert, update, killOp).

// Enterprise Least-Privilege Custom Role
db.getSiblingDB("admin").createRole({
    role: "OrderProcessingService",
    privileges: [
        {
            resource: { db: "ecommerce", collection: "orders" },
            actions: [ "find", "insert", "update" ]
        },
        {
            resource: { db: "ecommerce", collection: "inventory" },
            actions: [ "find" ]
        }
    ],
    roles: []
});

3. Client-Side Field Level Encryption (CSFLE) & Queryable Encryption¶

In traditional databases, encryption at rest protects against physical disk theft, but database administrators or compromised servers can read all customer data in memory.

3.1 CSFLE (Client-Side Field Level Encryption)¶

With CSFLE, sensitive fields (e.g., SSN, credit cards) are encrypted inside the client application driver using AES-256-GCM before the BSON document is sent over the network:

[Client Application] ──► Encrypts "ssn" via libmongocrypt ──► [Encrypted BSON over Wire]
                                                                        │
                                                                        ▼
                                                         [mongod Database Engine]
                                                         - Sees only binary ciphertext:
                                                           "ssn": BinData(6, "a8f3b9...")
                                                         - Memory & Disk store pure ciphertext!

3.2 Queryable Encryption (MongoDB 6.0+)¶

Standard encrypted data cannot be queried without decrypting the entire dataset. Queryable Encryption (QE) uses fast, homomorphic, structured encryption data structures to enable equality and range searches against encrypted ciphertext on the server without leaking the underlying data or encryption keys to mongod!

4. WiredTiger Encryption-at-Rest Architecture¶

WiredTiger provides native hardware-accelerated block-level encryption using AES-256-CBC or AES-256-GCM:

WiredTiger In-Memory Cache (Decrypted Working Set)
                │
                ▼ (Checkpoint / Flush via libwiredtiger)
     [ AES-256-GCM Encryption Engine ] ◄── Local Database Key (DEK)
                │
                ▼ (Encrypted Compressed Blocks)
       Physical NVMe Storage (collection-*.wt)

4.1 Key Hierarchy & KMIP / KMS Integration¶

Master Key (KEK - Key Encrypting Key): Managed externally in an enterprise Key Management Service (AWS KMS, GCP Cloud KMS, HashiCorp Vault via KMIP).
Database Key (DEK - Data Encrypting Key): Generated locally by mongod to encrypt WiredTiger blocks; encrypted by the KEK and stored in a local keystore.