As a general rule, if you get the database, you can assume remote code execution.
If you're a defender, I would go further and say you must assume it.
If you're a defender, I would go further and say you must assume it.
To get a dump you'd need to compromise two systems - a database server that has access to all the data, but in the data it stores and returns all the interesting columns are encrypted; and an app server that can decrypt data that it gets (and it has the keys only for the columns that this app server actually needs to use, if you have different classes of confidential data) but can't get all the data from the database freely, only a predefined subset in a limited and logged manner controlled by the database system.
Granted, if the attackers can get RCE on one of those systems then it's likely that with some effort they can get the other system as well in a similar manner, but still it's an useful defense in depth.
See the example vulnerable web service here: https://gist.github.com/emidln/a43b9fee4fc55273106c4b850f6b4...
Is the assumption that control over the db can pivot back to the server or that if there are basic issues with db access that there must be other exploitable issues (probably a fair assumption)?
> If you're a defender, I would go further and say you must assume it.
The assumptions you make when reacting to a known compromise are wildly different than what access an attacker actually has and what they might be able to do.
In general I am not sure if we wish to conflate systems security and cryptographic security - cryptographic security ideally should guard against system security failures. Although in practice I grant you that broad system failures which expose crypto secrets (code execution would fall into that) would lead to crypto failures as well.