Direct access to databases is usually a privilege of DBAs and not end-users. Nonetheless, end-users have to access DBs in certain situations like generating sales reports, making ad-hoc queries, exporting data into spreadsheets and so on.
From the security perspective, this is clearly not ideal, as a typical application was never designed to be utilised this way.
Instead of saying ‘no’ to the business and losing our job, let’s overview the potential risks of direct database access. We also have a quick glance on the remediation options.
Risks of Direct Database Access
Default installations of Relational Database Management Systems (RDBMS) do not support advanced authentication features:
- Two-factor authentication and single sign-on (SSO) is not possible
- Users can choose weak passwords which never expire
- Password change is not user friendly
- Users are not locked out when many login attempts are failing
The good news is that many of these can be solved with an additional purchase and/or configuration. Oracle offers Oracle Advanced Security, MSSQL supports AD integration, and MariaDB also provides password policies and two-factor authentication.
Sadly these add-ons are not available on managed database services such as AWS RDS.
Business logic and its supporting security policy is usually enforced on the application layer. In other words, this is where access control decisions are made.
Unfortunately DBMSs are not aware of this high-level logic, and they lack of sophisticated access restrictions. When databases are accessed in a direct manner, we may find that:
- No fine-grained access control available, table level granularity only
- Time and GeoIP based restrictions cannot be applied
- Security concepts are unsupported (e.g. ‘need to know‘ principle, multilevel security)
- Problematic revocation of access rights
- Monitoring, reporting and auditing user permissions is a pain
On the plus side, database views or procedures can help with the granularity and ‘need to know’ problem. Revocation access and reporting on permissions can be scripted.
Logs are indispensable in many situations. They help identify brute-forcing login attempts and unauthorised access. In addition they provide non-repudiation of user activity.
Event logs are normally generated by the application. By skipping the application layer, the quality of event logs may differ:
- SQL queries are usually not logged for performance reasons
- Successful and unsuccessful login attempts are not recorded by default
SQL proxies like MySQLProxy or GreenSQL support logging without the performance hit. DBMS can also be configured to log relevant events (MySQL Enterprise, MSSQL) into flat-files or tables. Commercial database activity monitoring tools can also come to the rescue.
Although SSL is supported by modern DBMSs, this feature is not enabled by default. While an average user is well-aware to browse certain websites over HTTPS only, many of them are still happy to connect remote databases in clear-text.
Alternatively, stunnel or SSH tunneling can also protect against eavesdropping. Consider implementing a local jump host that is only accessible via VPN.
Bugs and Exploits
RDBMS are as susceptible to remote exploits as any other service. Remember when everyone was laughing at MySQL because of the bypassable authentication? Same with Oracle? How about the Slammer worm? And Denial of service attacks?
Unfortunately database services are not patched as frequently as they should be, mostly for availability reasons. So try launching read-only replicas to avoid attacks against availability. Use SQL proxies (see ‘Event Logging‘ above) or virtual patching to hide security holes.