Securely storing password and encryption key on AWS

Question

I have an EC2 Webserver on AWS which has a MYSQL database. The login data is stored on AWS using the Secret Manager. I have added an IAM role for the Server to get access to the password and an encryption key which is stored in the Secret Manager on AWS. This implies that I use the Secret ARN to get the key. I have implemented a PHP script which uses this ARN as a secret name.

This way I do not need pure credentials for accessing the password and the encryption key.

The problem I thought about is the following scenario: Attacker A gets access to the webserver. As I have to use the hard coded ARN from Secret Manager as a Secret name, the attacker might change the PHP script and print out the resulting password and encryption key from AWS. Is there any way to stop this or should the security design be different for getting a key? I do not see a solution how I might prevent an attacker to get the password if he has access to the server.

Answer 1

Once you grant the EC2 instance permission to retrieve secrets anyone who can log into that server can perform that function as well. They wouldn't even need to change your PHP script, they could simply use the AWS CLI on the server to access the secrets.

What you can do is limit the attack surface to obtain access to that server. For example, place the web server in a private subnet and only allow web access through a load balancer. Lock down access by using SSM or a bastion host that is only accessible from your IP address. Employ a SIEM or other type of intrusion detection to alert you if something is occurring that is outside the normal activities.

Your architecture has a necessary vulnerability, through the use of defense in depth and compensating controls you can take steps to secure it.

Answer 2

The scenario you describe illustrates an important concept in information security: there is nowhere that you can hide a secret where your own code can access it, but an attacker who takes over your application (or is able to run their own code with the same privileges) can't access it. That's just fundamentally impossible.

Putting it another way: If you've got only one service that drives everything, worrying about what to do after an attacker gets control of your server is like worrying about what to do after your house gets hit by a nuke. It's game over. Some larger systems can implement security boundaries between components to contain damage, but that's usually only possible for mostly-independent services; otherwise, they need to mutually trust one another and taking over one of them gets you the whole lot.