This lesson's interactive features are locked, please to keep using them
Secure Database Practices
A database is usually the most valuable file (or set of files) an attacker can steal. It has account records, orders, operational metadata, and relationships that become far more revealing when combined.
There are a lot of database technologies out there, and their security controls vary. SQLite, for example, is an embedded database stored in a local file. It has no database server listening on a port and no built-in network users to lock down. It's just a file on disk, so its main access boundary is the operating system.
Protect the Access
Many networked databases like PostgreSQL, MySQL, and MongoDB have their own user accounts and access controls. I don't want to beat this dead horse too much, but follow the principle of least privilege: only give each user or app the access it needs to do its job. If your application only needs to read and write a few tables, don't give it DROP TABLE or CREATE USER privileges. This limits the damage if an attacker steals the application's credentials.
Protect the Connection
If your database runs on a different host, keep it off the public internet and encrypt the connection when the network path isn't fully trusted. A private network limits who can reach the database, but TLS protects the traffic itself.
Protect Data at Rest
Full-disk encryption protects the storage layer when someone steals a locked physical disk or snapshot. Backup encryption protects backup files when they're copied. Keep your decryption keys separate from the data they protect!
Most good cloud database providers offer these security features out of the box. Make sure they're enabled and that your provider offers them.