My question might be broad. Suppose that we trying to store our client's information data with a database on a server. The server may get a vulnerability and give access to a hacker to get access to the system admin user. Also, the hacker can reset administrator passwords. Currently, there are many databases like Oracle, SQL Server, MySQL and etc. For example, in SQLite with SQLcipher, if you access the database data file you cannot decrypt it easily without having the db password. On the other hand in SQL Server if you copy all database files (*.mdf) you can access all data in other systems without even knowing the database users and passwords. My question is which databases cannot be recovered easily with admin user without having db user information.
closed as unclear what you're asking by Steffen Ullrich, Xander, forest, Tobi Nary, Matthew Jan 9 at 15:02
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
If the attacker has full access on the database server AND has access to the server decrypting the data you lost with any of these database systems. I have heared about mainframes and custom built systems where the database is integrated into the operating system and you don't get any real admin-access but even for those an attacker with high enough privileges typically can set the read-limits high enough to read the whole database row by row and nothing off the shelf below 100.000 USD per year.
In your case with SQLite with SQLcipher you will need to store the decryption somewhere and because with SQLite it is typically the application server the attacker typically only needs access with the rights of the application/webserver to get all the data. Other database systems provide similar functionality like mentioned below but might be only available in certain editions like for Microsoft SQL Server in the Enterprise and Datacenter editions.
Ways to make it harder for the attacker:
- Harden your server (keep software up to date, firewall, secure settings for applications, restrict (maintenance-)access to certain ip-address-ranges, pentesting, don't run services as admin, rate limiting, ...)
- Don't store data you don't need to or in a form you don't need (no passwords in cleartext, sometimes you don't need the name of a person for processing but only unique identifiers, ...)
- Database encryption: Some databases provide different database encryption options like whole database, tables, columns for example see here. Beware that this might mean a big performance reduction. This causes the attacker to also need the encryption key but if he has full access on the database server he can also sniff the key sent to the database server except in the case of Client-Side Encryption but then he would only need sufficiant access to the server accessing the database.
- Limiting attack surface: You can put more sensitive data on separate servers with better security audits. For example for user names and passwords you can use a separate server with a single webservice with the functions "Check password for user id", "Add password for user id", "Remove password for user id" and an extra database server for those data which only accepts connections from this server. Because it has less functionality/code it is easier to audit and has less attack surface.
Of course you will too need other security measure not mentioned in your attack vector like physical access to server, encryption of harddisks/backup, ...