Clarifying point: I’ve never setup a backend service for ethereum, but I do have experience working with storage of keys in self sovereign identity.

In answering this, I’m going to make a few assumptions here that may not be true. Please correct them if they’re wrong.

1.) the keys used to sign transactions are for the owner of the backend server.

2.) the transaction signing needs to be automated so the backend server can sign at anytime. For example, a person isn’t required every time a transaction needs to be signed.

3.) you’re looking to pass the management of the keys off as long as you know it’s secure.

You could use a library to perform signing for you and store the keys in an encrypted keystore that shares memory with other applications. This is usually a good enough for things like wallets on smart phones, but in this case I wouldn’t recommend it. If the backend server is hacked and the attacker gets access to the file where keys are stored they’ll be able to steal them. I’d suggest going the HSM route if possible.

HSMs are typically the best options when handling an individual key. With that said, you may have problems signing transactions with an HSM because it won’t be able to support ethereum account key formats I suspect. This may not be a problem if you want to rebuild APIs in which case Azure Keyvaults now support Secp256k1 keys and I had heard AWS now has support as well. However, I’m not familiar enough with the web3.js sign API to say off the top of my head what the signature process is. In any case if at all possible it’s recommended that you use an HSM.

Hopefully that’s helpful to get you going at least.