Database security checklist: access, encryption, exposure and patching

Most database breaches do not need clever exploits. They happen because a server listened on a public address without a password, an application account could do everything, or a backup file sat somewhere readable. Work through this list for every database you run, then repeat it after major changes.

1. Keep it off the internet

A database port should be reachable only from the hosts that need it: application servers, admin jump hosts, backup and monitoring systems. Both MongoDB and Redis document that they should run in a trusted network.

sudo ss -ltnp | grep -E ':(27017|6379|5432|3306)\b'     # what listens, on which address

• Bind to loopback and private interfaces only: net.bindIp in /etc/mongod.conf, bind in redis.conf. Both default to localhost; keep it that way unless remote clients need access.
• Add a host firewall rule that allows the port only from known source addresses, and a network firewall or security group in front of that.
• From a machine outside your network, confirm that the port is closed. Only scan hosts you own or are authorized to test.
• Use a VPN, SSH tunnel or bastion host for administration instead of opening ports to admin laptops.

2. Require authentication everywhere

• MongoDB: set security.authorization: enabled and create users before opening the port. Replica set members also need internal authentication (keyfile or X.509).
• Redis: protected mode is a fallback, not a control. Create ACL users, give every client its own credentials, and disable or password-protect the default user.
• Generate long random secrets (for example openssl rand -base64 32, or ACL GENPASS in Redis) and keep them in a secret store, never in source control or command lines.

3. Least privilege

Each application, job and person gets its own account with only the rights it needs. If one is leaked, the damage stays small and the audit trail shows who did what.

// MongoDB: read-write on one database only
use admin
db.createUser({ user: "appuser", pwd: passwordPrompt(), roles: [ { role: "readWrite", db: "shop" } ] })

# Redis: own key prefix, no dangerous commands
ACL SETUSER appuser on >CHANGE_ME ~app:* &app:* +@all -@dangerous

• Backups use a backup-only role (backup in MongoDB), monitoring uses a read-only one (clusterMonitor, or a Redis user limited to +info +ping).
• Keep superuser accounts (root, a full Redis admin) for emergencies, with the secret stored separately.
• Review users regularly and remove the ones for retired applications and people who left.

4. Encrypt traffic and data

Without TLS, passwords and data cross the network in clear text. Enable TLS on any connection that leaves a single trusted host.

# /etc/mongod.conf
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

# redis.conf (Redis built with TLS support)
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt

• Encrypt data at rest: database-native encryption where available, otherwise encrypted volumes (for example LUKS/dm-crypt).
• Clients must verify the server certificate. Disabling verification to make an error go away removes most of the protection.

5. Protect the backups

A backup holds the same data as the database, usually with weaker protection. Encrypt backup files, restrict who can read them, store at least one copy offline or immutable so ransomware on the database host cannot delete it, and test restores. See the 3-2-1 backup article for a full routine.

6. Patch and stay supported

• Subscribe to the vendor’s security announcements and check for CVEs regularly.
• Track the end-of-life dates of your major versions and upgrade before they expire; unsupported versions stop getting security fixes.
• Apply minor releases on a schedule, test them on staging first, and keep the OS patched too.

7. Harden the host and the service

• Run the database as a dedicated unprivileged system user (mongodb/mongod, redis), never as root.
• Restrict the data, log and configuration directories to that user. Config files that contain secrets should be mode 600.
• Turn off features you do not use: MongoDB can disable server-side JavaScript with --noscripting; Redis ACLs can block commands such as CONFIG, DEBUG and MODULE for everyone except admins.

8. Log, monitor and audit

• Collect authentication failures and admin actions centrally. MongoDB Enterprise includes an auditing facility; on other editions, rely on the server log and your platform’s logging.
• Alert on unusual connections, sudden drops in key or document counts, and failing backups.
• Write down who may access production data and why, and review it.

Quick self-check

1. Can anyone on the internet open a TCP connection to the database port? (Must be no.)
2. Does every client authenticate with its own user? (Must be yes.)
3. Can the application account drop databases or change configuration? (Should be no.)
4. Is traffic between application and database encrypted when it leaves the host? (Should be yes.)
5. Is there a restored-and-verified backup from the last month, with a copy off the host? (Must be yes.)
6. Is the server on a supported version with current security patches? (Must be yes.)

Official documentation

• MongoDB Manual: Security checklist
• Redis docs: Security
• MongoDB Manual: Configure mongod for TLS