RightScale provides infrastructure management of IaaS and PaaS cloud resources. On behalf of our clients, we store and have access to potentially sensitive data, such as:
The data we maintain about our customers is typically considered intellectual property (I.P.) and is protected as such. RightScale will not divulge or share any customer I.P. without prior consent with third parties outside of our Cloud hosting partners, which are fundamental to service operations. RightScale will work with customers to ensure that best practices of specific asset classifications and generic Cloud security are implemented and, if required, independently verified.
The RightScale application uses private network connections provided by the cloud providers for all intra-cloud communications between the server instances in that cloud. All daemons listen on, and communicate over, the private interfaces. In addition, security groups are configured to restrict public traffic to use only allowed ports. All communication between customers and the RightScale application use either SSL or TLS to encrypt the transport. Where transport level encryption is not an efficient mechanism, application level encryption of the payload is performed.
When SSL/TLS is used to secure the transport, we use 2048 bit X.509 certificates, configured to reject weak ciphers and protocols. The Cloud controllers' server certificates are validated according to OpenSSL's built-in policy and trusted roots.
RightScale uses database column encryption to ensure the confidentiality and integrity of secrets we store on behalf of our customers. Sensitive columns are encrypted at the application layer with AES128-CBC, using the PKCS#5 passphrase-based KDF for key derivation.
We derive a unique key for every encrypted value; keys are never reused across rows or columns. The key for an individual value in our database is a function of several things: a 256-bit master secret, the name of the table and of the column being encrypted, and a row-specific pseudo-random salt. Initialization vectors are freshly generated every time a message is encrypted.
We never reuse a master secret across trust boundaries. For example, when we move the contents of a database from our production environment into our staging environment to perform performance or regression testing, we re-encrypt all of the records using a different master secret that only resides on machines in our staging environment. Besides re-encrypting, our sanitization procedure does many other things such as anonymizing email addresses, postal addresses, names, and other personal or proprietary information in the database. In addition, the sanitization process removes credentials except from a set of white-listed RightScale-specific accounts (i.e., all customer related credentials are removed).
A specific point about cloud credentials is that they are masked on display/read. Thus they cannot be read, but they can be changed by users with appropriate permissions (roles).
The following objects are protected by the database encryption just described:
Critical data that is on non-cloud systems and not stored in databases is protected using one of the following mechanisms:
Customer information is kept for its useful life. The type of data determines the retention period. For example, when users change their password, the validator that was previously stored is no longer available, and cannot be recovered. RightScale will honor any requests to terminate, return or securely delete any client-specific intellectual property assets as required. The details of this policy are documented in the Data Retention Policy.
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.