Course Outline (Part 15)

In the early 2010s, thousands of MongoDB databases were hacked and held for ransom. Why? Because developers were installing the database on public servers with default settings, leaving the front door wide open with no passwords required.

MongoDB has since changed its default settings to be highly secure out-of-the-box, but understanding how that security works is critical for any database administrator.

Database security relies on two primary pillars: Authentication (Who are you?) and Authorization (What are you allowed to do?).

1. Authentication (Who are you?)

Authentication is the process of verifying a user’s identity. If you cannot prove who you are, the database will refuse the connection.

MongoDB supports several enterprise-grade authentication mechanisms:

  • SCRAM (Salted Challenge Response Authentication Mechanism): This is the default username/password mechanism. It cryptographically hashes your password so it is never sent over the network in plain text.
  • x.509 Certificates: Uses cryptographic certificates instead of passwords, often used for server-to-server authentication.
  • LDAP / Active Directory: Enterprise integration for managing users through a central corporate directory.
  • AWS IAM: Allows applications running on AWS to authenticate using their native AWS identity.

2. Authorization (What are you allowed to do?)

Just because you are allowed inside the building (Authentication) doesn’t mean you have the keys to every room. Authorization determines what data a user can read or modify.

MongoDB uses Role-Based Access Control (RBAC).

Instead of assigning complex permissions to every single user, you assign permissions to a “Role” (like a job title), and then assign users to that Role.

Built-in User Roles

MongoDB provides several built-in roles that cover 99% of use cases:

  1. read: The user can only read data (find/aggregate) on the specified database. They cannot modify anything.
  2. readWrite: The standard role for application users. They can read data and perform all CRUD operations, but they cannot create indexes or manage other users.
  3. dbAdmin: Can perform administrative tasks like creating collections and building indexes, but ironically, they cannot read the actual data inside the collections.
  4. userAdmin: Can create new users and assign roles, but cannot read data.
  5. dbOwner: A combination of readWrite, dbAdmin, and userAdmin. This user has full control over a specific database.

The Super User (root)

There is a special role called root. A root user has complete, unrestricted access to every database and configuration setting on the entire server.

Security Rule: Your web application’s Node.js or Python backend should never connect to the database using a root user. It should connect using a user that only has readWrite access to its specific database.

3. Creating Users and Roles in the Shell

If you are running a local database, you manage users via the mongosh shell.

First, switch to the special admin database, which is where all user credentials are automatically stored:

use admin

Now, create a user with the createUser command:

db.createUser({
  user: "app_developer",
  pwd: "SuperSecretPassword123!",
  roles: [
    { role: "readWrite", db: "ecommerce_db" }
  ]
})

This creates a user named app_developer who only has permission to read and write to the ecommerce_db database.

4. Password Security

Passwords are only as secure as how they are stored and transmitted.

  • Do not hardcode passwords: Never type your database password directly into your application’s source code (e.g., in a server.js file). If you commit that file to GitHub, hackers will scrape it in seconds.
  • Use Environment Variables: Always store the database connection string (with the password) in a .env file that is strictly excluded from version control using a .gitignore file.
  • Strong Passwords: Database passwords are read by computers, not typed by humans. Make them incredibly long and complex (e.g., 32 random characters).

5. Network Encryption (TLS/SSL)

Even if you have a strong password, if you send that password over the internet in plain text, anyone snooping on the network traffic can read it.

TLS (Transport Layer Security) and its predecessor SSL encrypt the connection between your application server and the MongoDB server. It creates a secure, scrambled tunnel. Even if a hacker intercepts the traffic, all they will see is random mathematical noise.

Note: MongoDB Atlas enforces TLS/SSL by default. You literally cannot connect to Atlas without an encrypted connection.

6. Encryption at Rest

TLS protects data while it is moving across the internet (Data in Transit). But what happens if someone breaks into the data center and physically steals the hard drive containing your database?

Encryption at Rest solves this. The database engine encrypts the physical data files on the hard drive. Even if a thief steals the physical disk, they cannot read the files without the master decryption key (which is stored securely in a separate Key Management Service).

MongoDB Enterprise Advanced and MongoDB Atlas Dedicated tiers both support Encryption at Rest natively.

Security Best Practices Checklist

Before putting any MongoDB database into production, ensure you have checked every item on this list:

  • Enable Access Control: Run MongoDB with the --auth flag (enabled by default in modern versions and Atlas).
  • Use Principle of Least Privilege: Users and applications should only have the exact permissions they need to do their job, and nothing more.
  • Configure the Firewall (IP Whitelisting): Block all IP addresses except the specific IP of your application server.
  • Enable TLS/SSL: Never transmit database traffic over unencrypted networks.
  • Audit Logging: Enable auditing to track who accessed the database and what queries they ran (crucial for compliance like HIPAA or GDPR).
  • Keep Software Updated: Regularly update the MongoDB server to patch known security vulnerabilities.

Summary

Security is not an afterthought; it is a fundamental requirement.

  • You use Authentication (SCRAM) to verify identities.
  • You use Authorization (RBAC) to restrict access using Roles.
  • You use TLS/SSL to encrypt network traffic.
  • You follow the Principle of Least Privilege to ensure a hacked application server doesn’t compromise the entire database cluster.

In Module 15, we will discuss another critical aspect of database administration: what to do when disaster strikes and you need to Backup and Restore your data!

Discussion

Loading comments...