Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Security > Standard Practices > Information Handling

Information Handling

Information Types

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:

  • Cloud credentials
  • ServerTemplates
  • RightScripts
  • System build parameters and input values

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.

Protecting Data in Transit

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.

Data Protection in Database

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).

Encrypted Objects

The following objects are protected by the database encryption just described:

  • Credential design objects: Name, Description, and Value
  • The private key material of any RightScale managed SSH key
  • The private key material of any EC2 SSH Key
  • Cookbook repo credentials
  • Workflow repo credentials
  • Any stored OAuth secret
  • User password verifier (we store a verifier, not the actual password)
  • Cloud credentials (those used to access the cloud endpoint API)
    • For AWS this is the Access Key ID, Secret Access Key, account number, EC2 cert, and EC2 key
    • For other clouds, the specific credentials used to access the API endpoint
  • Content of gateway events and event failures (e.g., the raw responses from cloud list calls)
  • Admin password that is set for the instance at launch. This value MAY or MAY NOT exist, it depends on the features of the specific cloud.

Non-database Data Protection for Non-Cloud systems

Critical data that is on non-cloud systems and not stored in databases is protected using one of the following mechanisms:

  • Full Disk Encryption
  • File/Folder level encryption
  • PEM file with passphrase

Data Retention

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.

You must to post a comment.
Last modified
03:30, 26 Jul 2013



This page has no classifications.



© 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.