When migrating to the cloud consider security and resource variability, the cultural shift for operations and the new cost model. Continue reading 4 Considerations Migrating to The Cloud
Security is on everyone’s mind when talking about the cloud. What are some important considerations?
For the web operations team:
- AWS has no perimeter security, should this be an overriding concern?
- How do I manage authentication keys?
- How do I harden my machine images?
Amazon’s security groups can provide strong security if used properly. Create security groups with specific minimum privileges, and do not expose your sensitive data – ie database to the internet directly, but only to other security groups. On the positive side, AWS security groups mean there is no single point to mount an attack against as with a traditional enterprises network security. What’s more there is no opportunity to accidentally erase network rules since they are defined in groups in AWS.
Authentication keys can be managed in a couple of different ways. One way is to build them into the AMI. From there any server spinup based on that AMI will be accessible by the owner of those credentials. Alternatively a more flexible approach would be to pass in the credentials when you spinup the server, allowing you to dynamically control who has access to that server.
Hardening your AMIs in EC2 is much like hardening any Unix or Linux server. Disable user accounts, ssh password authentication, and unnecessary services. Consider a tool like AppArmor to fence applications in and keep them out of areas they don’t belong. This can be an ongoing process that is repeated if the unfortunate happens and you are compromised.
You should also consider:
- AWS password recovery mechanism is not as secure as a traditional managed hosting provider. Use a very strong password to lock down your AWS account and monitor it’s usage.
- Consider encrypted filesystems for your database mount point. Pass in decryption key at server spinup time.
- Consider storing particularly sensitive data outside of the cloud and expose through SSL API call.
- Consider encrypting your backups. S3 security is not proven.
For CTOs and Operations Managers:
- Where is my data physically located?
- Should I rely entirely on one provider?
- What if my cloud provider does not sufficiently protect the network?
Although you do not know where your data is physically located in S3 and EC2, you have the choice of whether or not to encrypt your data and/or the entire filesystem. You also control access to the server. So from a technical standpoint it may not matter whether you control where the server is physically. Of course laws, standards and compliance rules may dictate otherwise.
You also don’t want to put all your eggs in one basket. There are all sorts of things that can happen to a provider, from going out of business, to lawsuits that directly or indirectly affect you to even political pressure as in the wikileaks case. A cloud provider may well choose the easier road and pull the plug rather than deal with any complicated legal entanglements. For all these reasons you should be keeping regular backups of your data either on in-house servers, or alternatively at a second provider.
As a further insurance option, consider host intrusion detection software. This will give you additional peace of mind against the potential of your cloud provider not sufficiently protecting their own network.
Additionally consider that:
- A simple password recovery mechanism in AWS is all that sits between you and a hacker to your infrastructure. Choose a very secure password, and monitor it’s usage.
- EC2 servers are not nearly as reliable as traditional physical servers. Test your deployment scripts, and your disaster recovery scenarios again and again.
- Responding to a compromise will be much easier in the cloud. Spinup the replacement server, and keep the EBS volume around for later analysis.
As with any new paradigm there is an element of the unknown and unproven which we are understandably concerned about. Cloud hosted servers and computing can be just as secure if not more secure than traditional managed servers, or servers you can physically touch in-house.
Cloud Computing holds a lot of promise, but there are also a lot of speed bumps in the road along the way.
In this six part series we’re going to cover a lot of ground. We don’t intend this series to be an overly technical nuts and bolts howto. Rather we will discuss high level issues and answer questions that come up for CTOs, business managers, and startup CEOs.
Some of the tantalizing issues we’ll address include:
- How do I make sure my application is built for the cloud with scalability baked into the architecture?
- I know disk performance is crucial for my database tier. How do I get the best disk performance with Amazon Web Services & EC2?
- How do I keep my AWS passwords, keys & certificates secure?
- Should I be doing offsite backups as well, or are snapshots enough?
- Cloud providers such as Amazon seem to have poor SLAs (service level agreements). How do I mitigate this using availability zones & regions?
- Cloud hosting environments like Amazons provide no perimeter security. How do I use security groups to ensure my setup is robust and bulletproof?
- Cloud deployments change the entire procurement process, handing a lot of control over to the web operations team. How do I ensure that finance and ops are working together, and a ceiling budget is set and implemented?
- Reliability of Amazon EC2 servers is much lower than traditional hosted servers. Failure is inevitable. How do we use this fact to our advantage, forcing discipline in the deployment and disaster recovery processes? How do I make sure my processes are scripted & firedrill tested?
- Snapshot backups and other data stored in S3 are somewhat less secure than I’d like. Should I use encryption to protect this data? When and where should I use encrypted filesystems to protect my more sensitive data?
- How can I best use availability zones and regions to geographically disperse my data and increase availability?
As we publish each of the individual articles in this series we’ll link them to the titles below. So check back soon!