Cloud security: Is it raining in the cloud?

SC has a good write up on cloud computing security:

Cloud computing, as least as a concept, is being driven largely by economics. It is generally less costly to run applications, add capacity and increase storage in the cloud, rather than investing in new hardware and software, and bringing on additional staff and beefing up networking.

“Cloud computing will happen because it has too much of an economic incentive and developer support – applications can be quickly added and developers can have a single place to maintain source code,” says Vatsal Sonecha, VP, business development & product management at TriCipher.

Overall, incentives include application-deployment speed, lower costs and fast prototyping. These are strong drivers. So much so that Gartner predicts that by 2012, 80 percent of Fortune 1000 companies will pay for some cloud computing service, and 30 percent of them will pay for a cloud computing infrastructure.

That is not to say that entire data centers will be moving to the cloud, at least in the largest companies. But for certain solutions, the cost benefits are hard to ignore.

Read More. . . (off site)

Locking Down Access to Scalr Web Interface

I wanted to touch briefly on the security concerns for having Scalr accessible via the Internet. If you are running your own install of Scalr this is an important factor before even adding the first farm. For my own sake I will not getting into my exact setup, but instead talk about a few approaches to locking down access to Scalr.

Possibly the best approach is to limit access to Scalr interface to internal network requiring users to use OpenVPN or some other VPN solution to access internal resources which would include Scalr.  If you are hosting Scalr on an AWS instance be sure to set the security group to only allow the port you are running for VPN.  You can find a quick and dirty howto for OpenVPN on an EC2 instance at Google Books.

Another option is to use SSL and mod_access (Apache 1.3) or its renamed equivalent in Apache 2.2 mod_authz_host to limit those who have access to Scalr interface.  You should for sure at least use SSL to access Scalr.  You can also add a layer of authentication for good measure using Apache Basic Authentication.

Being that Scalr controls the rest of your AWS setup it is by far the one thing you want to lock down as much as possible.