Storing your private key on a "security server"?

Question

One of the suggested security precautions when storing Bitcoin of users on a server is to store the private keys on a separate server:

The database storing the private keys or the seeds in case of HD wallets should be running on a separate instance and only accessible via the application server(AWS allows lots of configuration you can make in the virtual private cloud i.e. VPC to accomplish this).

I understand that if the PK is stored on a separate server then that server would also need to be compromised in order for the security of the actual keys to be compromised. However, since presumably, the main server will be sending withdrawal/transfer requests to the "security server" what stops a hijacker from effectively liquidating the entire wallet balance by using the main server to forward requests to the security server? In other words, what is gained by adding an extra server to the equation if the security server is expected to "honor" (and sign) requests it receives from the main server?

Answer 1

Usually we try to discourage storing private keys on a server at all unless absolutely necessary.

However, if necessary, just having the keys on a separate server increases the complexity of the attack, as it's an extra step. But, in addition to that, you may employ things like rate limits, limits on transaction size, whitelists on addresses that can be sent to, etc. If there is unusually high transaction volume, a site operator could be notified to step in and review the activity log. In essence, you're right, such a system does have the risk of a hacker who has completely exploited the application server just using the application server to forward requests. But we can slow them down to limit the extent of possible damage.