Cloud security: Keeping those keys safe
Jack Murgia, from Cloud Controllers, sent me an interesting query last week: “How does LabSlice ensure that the Amazon Web Services (AWS) Access Keys remain secure within the application?”
This is a great question, as the AWS Access Keys are the keys to the house for any business using the Amazon Web Services cloud. It’s true that our application stores more keys than most (we provide an AWS management service that utilizes our customers’ keys), but you will more than likely find keys used within your application, whether to upload files to cloud storage (S3) or within scripts that are launched by your application.
In fact, any cloud service provided by any vendor will ultimately involve some sort of key, certificate or credential authentication to give the application access to various cloud resources. So extend these ideas to the cloud of your choice…
We secure our cloud platform by:
- Leveraging the inbuilt security controls of our development platform: In our case we use the ASP.NET Membership Services to manage application authentication and password storage, declarative security to limit access to sensitive parts of the application (eg. those that utilize AWS keys) and page security definitions to ensure that only particular users have access to particular pages. None of these controls are specific to the cloud, but security at home starts by making sure you have locked your doors and closed your windows.
- Storing sensitive attributes in encrypted format on disk: Storing the AWS keys in encrypted format protects them from systems administrators and other management folk that may need to get console access to our application. It also ensures that the keys remain secure when nightly backups are taken and shipped to S3.
- Running all key transactions over HTTPS, not just the login page: This seems to be a new trend in security (likely due to FireSheep) and we decided to adopt it as well. It’s a useful additional control to protect those AWS transactions that are run under the context of our customers’ AWS Access Keys.
But this is about cloud security…
Notice that the security controls we use have little to do with cloud computing. So is there anything cloud-related that we do to improve security? Turns out there is. I have come across three useful controls that are very cloud specific and that both us and our customers are implementing:
1. Termination protection: This is a feature of the Amazon cloud that blocks APIs from terminating a machine. It’s somewhat of an operations control, to stop your administrator from mindlessly terminating a production machine. But it’s also a useful security control in case your Access Keys somehow leak out, or maybe to protect yourself against a malicious employee days before their own termination.
2. Access Key permissions: By default most keys used in the cloud give global access to everything. As cloud vendors mature, so do the restrictions on these keys. If you’re using keys for limited activities (say, to upload files to S3) then it’s a good idea to restrict permissions solely to those activities. Our customers also limit the AWS Access Key permissions of the keys they use on our system. For example, Cloud Controller’s policy (see below) specifically forbids the ability to take snapshots, which is a good way to reduce their attack surface whilst using our system.
3. Network access: Again, a specific control to Amazon, which can be mapped to your favorite provider. If you’re using Amazon then you would naturally want to use their Security Groups (firewall) to block public access to your RDP and SSH interfaces.
Notice the difference?
Whilst cloud does has its security controls, the vast majority of our efforts go into implementing and maintaining security using familiar techniques that have nothing to do with cloud computing. If you’re using the cloud then forget about cloud security. Go back to basics and learn about CIA and follow the OWASP Top 10 guide. Whilst cloud has valid security concerns, the vast majority of security compromises in the cloud will still end up due to a failure with the basics: Poor access control, vulnerability to command injection (eg. SQL) and inadequate logging and monitoring.
By Simon Ellis
- Moving Your Email To The Cloud? Beware Of Unintentional Data Spoliation! - September 22, 2016
- Problem In Customer Support – What Mobile App Developers Can Learn From AmEx - September 20, 2016
- Infographic: 12 Interesting Big Data Careers To Explore - September 19, 2016
- Digital Twin And The End Of The Dreaded Product Recall - September 13, 2016
- Write Once, Run Anywhere: The IoT Machine Learning Shift From Proprietary Technology To Data - September 12, 2016