Hackers would do it from the operating system level - stop the database executable, then delete the files used to store the database. Likewise, many organizations store the backups on a network share, where a hacker could delete the files.
Permissions inside the database should be segregated. The credential used by the webserver should not have enough permissions to DROP DATABASE. Just the appropriate selects/updates/inserts.
Likewise, if you are storing backups on the same network (as opposed to a tape backup), network permissions should allow writes/creates but not deletes.
Why is deleting a row in a table a valid operation? Why is deleting a table in a schema a valid operation? Most likely they had full privileged access to the database.
Hackers would do it from the operating system level - stop the database executable, then delete the files used to store the database. Likewise, many organizations store the backups on a network share, where a hacker could delete the files.
Permissions inside the database should be segregated. The credential used by the webserver should not have enough permissions to DROP DATABASE. Just the appropriate selects/updates/inserts.
Likewise, if you are storing backups on the same network (as opposed to a tape backup), network permissions should allow writes/creates but not deletes.
Why is deleting a row in a table a valid operation? Why is deleting a table in a schema a valid operation? Most likely they had full privileged access to the database.
>had full privileged access to the database
Why does full access include the ability to delete read only data that should never ever be deleted for the rest of time?
It's like building a self destruct button that ignites the physical records. It's an unnecessary risk to make such a dangerous thing.
Well, you don't understand databases. Or software.
1 reply →