Defense in depth protects a system with multiple layers of security. Each layer can slow or block an attacker if another control is breached. For an Atlas deployment, apply the strategy across network access, identity and permissions, and data encryption rather than relying on any one setting. section 20.7 section 20.8
Layer the controls around an Atlas cluster:
- Restrict network access with IP access lists that admit only trusted addresses or ranges. Isolate the cluster in a VPC; use a private endpoint when application-to-Atlas traffic should remain off the public internet. section 20.7
- Protect identities with federated SSO and MFA for the Atlas UI. For database connections, use SCRAM or X.509 authentication, then assign granular permissions through role-based access control (RBAC). section 20.7
- Protect data with customer-managed encryption keys through AWS KMS, GCP KMS, or Azure Key Vault. For highly sensitive fields, use client-side field-level encryption so Atlas does not see their plaintext values; consider Queryable Encryption for searchable encrypted data. section 20.7
Choose network controls according to the connection needed. Network peering links VPCs privately; a private endpoint provides a private link to Atlas and preserves a boundary in which Atlas cannot initiate connections back to your network. Network peering support depends on the cluster deployment. section 20.8
