It’s an occupational hazard working in security that there’s always breaking security news, a new breach somewhere, and teams are being pulled to respond to the latest threat – sadly sometimes this involves replying to hundreds of business partners about why “no, we’re not vulnerable to the latest Win3.11 solitaire vulnerability”.
To help implement a basic level of security within databases, I’ve put together my own best-practise list… while this isn’t meant to supplant any existing standard or best practices, I’ve been surprised to find a bunch of folks struggling to find a starting point which is fairly easy to defend to the organization at large.
1. All users must be authenticated using their own credentials from the organization’s central directory (be it Active Directory, 389ds, Okta or Google Workspace).
2. All database credentials used by applications must be rotated frequently – this is best achieved using a secrets manager with lightweight automation, or role-based auth where available.
3. The default access level for any user, regardless of role, should be read-only. If implementing granular access is challenging, any sensitive data (PII) should be masked.
4. Remove standing access to read-write/admin roles. Automation can be used to facilitate elevated engineering access when on call or actioning a current ticket, and others can request r/w access through an approval process where they specify which fields they need and why. If you’re a Jira user, take a look at the cool integrations you can easily build with Automation for Jira.
5. Users requiring read-write or db admin privileges must pass a MFA challenge during authentication to the database (not just MFA for VPN or ZTNA). Keeping the number of users with admin access to a minimum, and also implementing a control to limit admin reads to no more than 20 rows per query can reduce the severity of unauthorized access.
6. Database access by applications must originate from trusted IP’s/subnets/security groups. Access should limit read, delete and update privileges based on the purpose of the application, and add (where available) end-user identity to help with auditing and security investigations.