Security is on the minds on many of our users. It’s on our minds as well, and we like to sleep well too…
When you evaluate the security of RightScale you should look at two sides of the question: what are the risks you are taking and what are the precautions RightScale is taking to protect you. Let me start with the risks you are taking and how you can mitigate some of them:
You may enter your AWS credentials into RightScale so the site can manage instances on your behalf. The risk is that we could launch instances on your account while you’re not watching, or we could terminate your instances at the wrong moment. We could also access private objects stored in S3. While these are definite risks, you are already trusting a 3rd party, namely Amazon, with exactly the same EC2 instances and S3 data. If you use a different hosting provider (such as Rackspace) you will have exactly the same issue. If there is any privacy or security guarantee that Amazon provides you that we are not providing, please let us know so we can evaluate it and offer the same.
One option you have with respect to your credentials is to separate your usage into two AWS accounts. Use one with RightScale for development, testing, etc; and then run production with the critical instances using a second account (yes, this is a bit difficult at the moment due to the scarcity of EC2 accounts, but you’re not running highly security sensitive services on the beta EC2 service, are you?).
You may store SSH keys to your instances in RightScale so that the site can perform convenient operations such as bundling or backup on your behalf. The risk is that we could gain root access to your instances at any time. There is a simple solution: don’t. You can create an SSH key pair using the EC2 command line tools and launch your critical instances using that. RightScale only has access to keys that you create within the site’s interface. You can also delete keys from the /root/.ssh/authorized_keys list at any time on a running instance, thereby preventing further access via RightScale. (Yes, we could have installed a root kit before you do that, if you want to think totally paranoid.) The bottom line is that again, you can cleanly prevent access to your critical production instances from RightScale if you choose to do so.
You may enter your credit card into RightScale to pay for the services. This is no different than entering them into any on-line merchant site. Our site is 100% SSL encrypted and we currently store your credit card info in our database using asymmetric encryption. This means that the keys to decrypt the CC info do not reside anywhere on the server. We currently download the encrypted info onto a dedicated machine with the decryption keys to process the charges. We are currently working to outsource the CC billing to paypal or an equivalent service.
The conclusion from the above is that RightScale really is no different from just about any hosting provider, including Amazon. Also, you can reduce your exposure in situations where you don’t need some of the automation provided by RightScale.
Let’s turn to what we are doing to protect your information on the site.
In my previous job I was chief architect and responsible for datacenter operations for seven years at Expertcity.com / Citrix Online during which we launched and ran a very successful outsourced remote access solution called GoToMyPC. This service was scrutinized and purchased by a large number of highly suspicious IT managers at major corporations, so I have more experience running such services than I probably would have liked to acquire… I’ve been working hard to make the RightScale site as secure as I can from a technical point of view, and also to instill the operational security procedures that are necessary to anyone working on RightScale.
The whole site is SSL encrypted and the user interface does not show the full credentials, thus it is not possible to “look over your shoulder” or copy/paste your credentials from your web browser.
All credentials are stored in encrypted form in the database. Clearly the app server has the decryption keys to be able to talk to S3/EC2 on your behalf, but this adds another hurdle and it makes the inevitable database copies (such as backups) a lot safer.
Access to the full user database is limited to our production and staging systems, and access to those is limited to the few people whose job function requires it. Developers use databases with test data only. Obvious stuff, but…
Overall we try to do everything reasonable to make the system as secure as we can. If you have questions or suggestions we’d love to hear them at email@example.com.