> ...we have been taking steps to enhance our data security measures. Sharing details of security measures could only serve to potentially compromise those efforts.
Maybe they used ROT13 on the API key twice this time!
Future service designers: if your client is talking directly to AWS, then your attacker will, too. Take the week to write a CRUD frontend server that enforces the policy you want.
Another common mistake is having /.git/ available on the domain itself, often with PHP sites or backend-less SPAs this is common, giving full access to the source, including those API keys. Even major sites do this – The Hill until recently had their git repo, including API tokens and access keys for everything, publicly available.
separate integration repo containing encrypted keys + separate, manual managment/configuration of the decryption process is fine for most cases.
but yes, bare and in mainline and published, I will agree this is terrible.
see also:
Now, if your secrets are encrypted before being committed (using something like ansible vault) and the encryption key is not stored in the repo, that may be ok. However, you still need to be aware that any time you rotate that key, you also should to rotate every secret hidden behind that key.
There are lots of ways of doing this. git-crypt is one that is configuration management agnostic. Most CM tools have their own way of dealing with secrets and there are CM agnostic tools like git-crypt. I'm not personally familiar with anything besides ansible-vault, but this article seems to provide a pretty good summary of several options: https://www.threatstack.com/blog/cloud-security-best-practic...
Yeah and same for .svn and .cvs (which may happen to include your VCS credentials in that directory, too).