I am developing a custom server application that will access a database. I need to decide where I will store the credentials (and to address) to that server.
A common so
Lock it down. Prevent Mr. Evil from gaining root. I know, easy right?
Write a secure application and keep your application server locked down. Follow best practices there, and that's most of the work.
When I've setup databases in a secure environment, the only server that was on the same physical network with the database server was the application server. There were two ways to access the database server:
Therefore, in order to compromise the database server, they'd have to compromise the application server.
So, lock down the application server. Of course the only thing worse than being compromised is being compromised and not knowing about it. If you do discover a compromise, you need to fix the vulnerability if there was one. Forensics are important here (enable logs and monitor them). You also need a recovery plan in place.
Prevention, detection, correction, and recovery are paramount.
I am sharing, the way I had solved this.
But, honestly the only thing this did was over complicate simple things. After that, I created several users to the database, with different privileges.
Like
guest
can only to SELECT
mod
can only CREATE
, INSERT
, UPDATE
, DELETE
etc and switched the user, whenever authenticated users appeared.
With the combination of users and session, I have been able to escape the threats so far. But ofcourse the code vulnerability have to be tested thoroughly.
I don't think you're missing something simple. Either the server in question can connect to the database without your help, in which case it has to have the credentials; or it cannot connect without your supplying them. You can take various steps like the ones you've listed to make it harder for a compromised server to reveal the credentials to the database, but at the end of the day, if it has to have those credentials and supply them to the DB server to connect, they'll have to be stored on it somewhere — or at least, it will have to have some means of getting them, and so will be hackable in that sense.
Your best bet is to focus on finding out about intrusions (compromised servers) as quickly as possible, keeping good off-site, off-line backups for the worst case, putting up lots of barriers to intrusion in the first place, etc.