Sergey Nivens - Fotolia
Our AWS encryption keys were exposed accidentally -- now what?
Exposing encryption keys is never a good thing, but knowing the steps to take after such an incident can help limit damage to an enterprise. Expert Dan Sullivan explains.
One of our developers accidentally put our AWS encryption keys on Github. Besides obviously changing the keys, what should we do to limit damage to our application infrastructure on AWS? Should we monitor Github to check if keys or other sensitive data is accidentally exposed?
Unfortunately, what you just experienced can happen all too easily. If AWS encryption keys -- or any encryption keys -- are stored in a directory under source control, someone could accidently push the keys along with source code to GitHub. Keys should always be stored separately from source code.
But what should be done in the event keys are exposed? You are right to change the keys and delete any key pairs that were exposed. Once deleted, anyone with the keys will not be able to use them.
Encryption keys are generated in pairs: a private key and a public key. The public key should be shared with anyone that needs to decrypt encrypted messages from you. When using key pairs to authenticate against a server, the server may store your public key. AWS takes care of this when you create an EC2 instance and specify a key pair. In the case of Linux instances, the private key is added to ~/.ssh/authorized_keys. The last step to manually creating an EC2 instance is verifying you have the private key of the key pair you assign to the instance. If you do not have that private key, you will not be able to authenticate against the server. This assumes you haven't created a local login mechanism on the server.
Organizations working with AWS or any other cloud provider should have a key management strategy. Private keys should be kept in secure storage with access limited to those who need them for their work. The National Institute for Standards and Technology has recommended best practices for key management. AWS also published a set of security best practices.
Scanning your code before storing in Github or other cloud repositories could help prevent a similar incident from happening again. Some enterprises use data loss protection applications to scan network traffic for data leaks and catch the accidental or malicious disclosure of private or sensitive information, such as Social Security numbers. If your company uses such a tool, consider configuring it to detect patterns found in key files, such as "-----BEGIN RSA PRIVATE KEY-----".
Not only can poor key management lead to compromised servers, but also if keys used to encrypt data are lost, the data encrypted with that key is lost as well.
There is no substitute for sound key management.
Ask the Expert
Want to ask Dan Sullivan a question about cloud security? Submit your questions now via email. (All questions are anonymous.)
Uncover the risks of cloud key management -- and how to solve them
Discover tips for safeguarding AWS access keys
Walk through an AWS and AWS EC2 security tutorial
Dig Deeper on Cloud security
Related Q&A from Dan Sullivan
How do AWS configuration management tools work?
When running AWS in our enterprise, it has been a challenge to keep tabs on active resources. Which native tools define and maintain configuration ... Continue Reading
What cloud security controls are best for due diligence?
With increasing use of cloud sending more enterprise data outside of the organization's control, due diligence is crucial. Expert Dan Sullivan offers... Continue Reading
When should I use Azure VM Scale Sets?
Microsoft Azure VM Scale Sets help cloud admins manage a collection of VMs as a single unit. But what workloads are they best suited for? Continue Reading