Усиление безопасности и контрольный список для рабочей среды

Production readiness is not a feature — it is a checklist of disciplines applied before the first real user hits your system. A deployment that passes all functional tests but skips security hardening, monitoring, and backup verification is not production-ready. This final lesson walks through the critical production checklist for a MongoDB deployment, covering authentication, RBAC, TLS, encryption, monitoring, backup, and disaster recovery.

Verify that authentication is enabled and that no unauthenticated connections are possible. On self-hosted MongoDB, confirm security.authorization: enabled in mongod.conf. On Atlas, authentication is mandatory and cannot be disabled. Test by attempting to connect without credentials — the connection must be refused. Confirm that no user has the root or __system role in production application accounts.

Audit every database user. Each application service should have only the roles it needs on only the databases it needs to access. Run db.getUsers() for each database and check that no service account holds dbAdminAnyDatabase, readWriteAnyDatabase, or root. Create a user access matrix documenting which service connects with which user, which roles it holds, and why. This matrix is your single source of truth for access reviews.

Confirm that net.tls.mode: requireTLS is active and that all client connections are encrypted. Check the MongoDB log for TLS handshake failures that indicate clients still attempting plaintext connections. On Atlas, TLS is enabled by default and cannot be disabled. For self-hosted deployments, run db.adminCommand({ sslInfo: 1 }) (or check db.serverStatus().network) to verify TLS is active. Reject any deployment where TLS is in allowTLS mode in production.

MongoDB should not be directly accessible from the public internet. On Atlas, verify that the IP Access List does not contain 0.0.0.0/0 (allow all). Use VPC Peering or Private Link to route traffic privately. For self-hosted deployments, bind MongoDB to the private network interface only (net.bindIp: 127.0.0.1,10.0.0.5) and configure firewall rules to allow only application server IPs on port 27017.

Production deployments must have a verified, tested backup strategy. On Atlas, enable Continuous Cloud Backup which provides point-in-time recovery to any second within the retention window. For self-hosted, configure daily mongodump snapshots to S3 and test restoration monthly. The key word is tested — a backup that has never been restored is a backup you cannot trust. Run a quarterly disaster recovery drill.

A production MongoDB deployment needs monitoring on: hardware (CPU, disk I/O, network); MongoDB-specific (connections, opcounters, cache hit ratio, replication lag, lock percentages); and application-level (query latency P99, error rates). Atlas has built-in monitoring and alerting. Self-hosted deployments should integrate with Prometheus (mongodb_exporter) + Grafana or an equivalent. Set alerts before thresholds are exceeded, not after.

Before launch, establish a query performance baseline: enable the profiler at level 1, run representative load (using a tool like MongoDB's load generator or k6), and capture the P95 and P99 latencies for each critical endpoint. Store these baselines. After each deployment, re-run the load test and compare. Any P99 regression above 20% triggers investigation before the deployment reaches all users.

For applications handling PII, payment data, or health information, verify that encryption at rest is enabled. On Atlas, enable cloud provider KMS-based encryption in the Security settings. For self-hosted Enterprise deployments, confirm security.enableEncryption: true and a KMIP key manager is configured. Document which Customer Master Key protects which cluster and ensure the CMK itself has multi-person access controls to prevent lockout.

Enable audit logging to record every authentication, authorisation failure, and sensitive data access event. MongoDB Enterprise and Atlas provide audit log streams that you can route to a SIEM (Security Information and Event Management) system. Configure audit filters to capture: all authenticate actions, all createUser/dropUser/updateUser actions, and all operations on sensitive collections (users, payments). Retain audit logs for at least 1 year for compliance.

Document operational procedures in a runbook: how to connect to MongoDB in an emergency, how to restart a failed replica set member, how to perform a manual failover, how to restore from backup, and what the escalation path is. Practice these procedures in a staging environment. Set a Recovery Time Objective (RTO) — how long can the database be down — and a Recovery Point Objective (RPO) — how much data loss is acceptable. Atlas's continuous backup provides an RPO of seconds.

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

In this capstone's final lesson you completed the production readiness checklist: authentication, least-privilege RBAC, TLS, network isolation, backup + tested restore, monitoring, query performance baseline, encryption at rest, audit logging, and a written runbook. Congratulations — you have now completed the full MongoDB & NoSQL Databases track, from first document insert to sharded cluster production deployment. Take these skills and build something great!