As many of you know I am a very big proponent of using the cloud with high automation. At my job we do this in a big way. However, one question always comes to mind, if you share your servers with other physical machines; how can one guarantee security?
In short you can't, but there are things you can do.
When I say you "can't" guarantee security, I mean that anyone could find a "local" exploit in the hypervisor, just look here if you think hypervisors are secure.
Then you must be thinking to yourself, I am basically screwed and will never be able to deploy in the cloud. You would be wrong. The high automation I prefer using (e.g. puppet) reports on changes to files which you control and you control what servers you automate via the PKI system. For very important systems, things like OSSEC are great tools.
One thing people should be very aware of is what Amazon calls "Security Groups". They are akin to a virtual firewall and even site between servers of the same layer. So by nature, if you have two servers in one security group, they will be unable to SSH to one another or even ping unless you explicitly allow it. That was a fantastic decision by Amazon and really helps security engineers facilitate a more secure environment.
Amazon in particular, in my opinion, has done an excellent job looking at security from the worst-case scenario. You can go from as locked down as a VPC cluster, to as open as a wide-open security group. It is your choice how good or bad at security you are. Also, since the Elastic Load Balancer product belongs to a security group, you get an extra layer of firewalls by only letting those load balancers to direct access the web servers (removing some external DDoS attacks). Amazon Web Services has also been verified as a PCI Level 1 Service Provider. I can say from experience that it is a very difficult thing to do and an extremely big commitment from Amazon do to on such a massive scale.
In a future posts I will write about how to best architect a cloud system for minimal failures and how to put your worst fears onto paper in the very important Recovery Time Objective/Recovery Point Objective Disaster Recovery document from a cloud setting.