3

I have a secure and private aws ec2 environment but I need to do some backups of mongodb, postgresql, so I have a separate ec2 instance for doing backup and occasionally allow 80 and 443 to allow install/update software on backup instance.

I use shell scripts to do backup job, it requires hardcoded password or credentials in scripts, I don't feel it secure enough to have all credentials saved into one place -- backup instance.

How to secure backup instance to avoid saving passwords/credentials in plain text, I also want to avoid saving passwords/credentials in memory or temporary files?

10
  • I mean you'll HAVE to have the password in memory to use it, so you're not going to be able to get away from storing it in memory.
    – user
    Dec 11, 2019 at 13:53
  • What about encrypting the backup for a public key, whose private part you only have offline on a secure system? The system that makes the backup and the system that stores the backup do not need to have any decryption keys at all. As for specific software, that might be a question for software recommendations stackexchange (or maybe serverfault, not sure; check their info page whether that is on topic there).
    – Luc
    Dec 11, 2019 at 13:53
  • @user too fast for me! I think I may have a suggestion that works around this issue, though :) (See my other comment just now)
    – Luc
    Dec 11, 2019 at 13:53
  • @Luc I was under the impression that he was piping the data out to another instance of mongodb or similar. You'd still need a method of authentication (that public key for example) to push data to the backup server, in which case an attacker could exfiltrate it and use it to push malicious backups. Having a kind of "one way" encryption like that would at least be more secure than directly connecting to a backup database at least.
    – user
    Dec 11, 2019 at 13:58
  • @user Your comment doesn't make much sense. If you have "one way" encryption, then how are you supposed to decrypt the data when you want to read it? You might have meant something different, but this is what you wrote. The public key is called public for a reason. An attacker cannot simply use your public key to impersonate you. That would be absurd and using asymmetric encryption would be pointless. This is where authentication techniques come in, such as a digital signature. Asymmetric cryptography is widely applied to generate a shared key, using a Diffie-Hellman key exchange algorithm. Dec 11, 2019 at 18:03

1 Answer 1

2
+50

Have you tried AWS Secrets Manager (or Parameter Store). It's built for exactly this purpose.

Create a separate IAM Role for the backup process, and grant the required EC2 instance that IAM role. Then modify your script to call Secrets Manager to obtain the credentials and and don't store those credentials anyway except in the memory of the running process. (i.e. purge it once the process is one).

In the background, the EC2 instance will have a metadata instance that issues tokens that the script can use to call Secrets Manager. Once it's able to call secrets manager, it can get the actual db credentials to call your DB. Even deeper, the meta-data service issues only temporary tokens for the IAM role, which makes this approach even better.

A more old-skool method, would be to generate the API Keys for the IAM role, and hard-code those credentials onto the ~/.aws/credentials location of your EC2. Then your AWS SDK will use it to call AWS Secrets Manager with the same concept.

Ultimately, the concept is the same, use an API key to call an API that returns the actual credentials used. That API call is logged (cloudtrail) and returns only those credentials necessary to the call.

1
  • Also, if OP doesn't have a secrets management solution (doesn't sound like it) Hashicorp Vault has integration with AWS and can issue temporary tokens for things like this. Dec 16, 2019 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .