In a small team, the production database password tends to be shared: it is in a chat, a wiki page, and the head of whoever set it up. That is convenient until someone leaves, a query slows the application, or a value changes and nobody knows why. You do not need an enterprise security programme to improve this. Five practices cover most of the risk.
1. Give the least access that still gets the job done
Most people who touch production data only need to read it. Separate view-only access from edit access, and keep the ability to change structure (add or drop columns, change connections) to a very small group. If a task needs temporary elevated access, grant it for that task and take it back.
2. Do not hand out database credentials
When every person holds the database password, you cannot revoke one person without changing it for everyone, and you cannot tell their queries from anyone else's. Put the connection in one central tool, store the credentials there, and give people access to the tool by role. Where possible, create a database user that is read-only for connections that only need to read.
3. Record every change
Log each data edit, schema change and permission change with who made it, when, and the old and new values. This turns "who changed this?" from an argument into a lookup. It also changes behaviour: people take more care when they know changes are visible.
4. Use company sign-in as the team grows
Single sign-on means access follows the company account. When someone leaves and their account is disabled, their access to production data ends at the same moment, without anyone remembering to remove them from another list. It also removes yet another password people reuse elsewhere.
5. Encrypt the connection
Database traffic across the internet or between offices should use TLS. If the database is not exposed publicly, an SSH tunnel through a bastion host is a common alternative. Either way, avoid opening the database port to the whole internet.
A quick self-check
- Could you disable one person's access in under a minute without affecting anyone else?
- If a value changed yesterday, can you find who changed it and what it was before?
- Are read-only users unable to edit even by accident?
- Is the production password absent from chats and documents?
- Is the connection to the database encrypted?
In Ruamhub
Ruamhub has Owner, Admin, Editor and Viewer roles, stores connection passwords in a secrets vault, supports read-only connections, TLS and SSH tunnel connections, and records changes in an audit log. OIDC single sign-on is available on the plans that include it. See the security page for details.