Zadara Storage Security Brief

Avatar
yair hershko
Follow

 

Zadara Storage Security Brief

 

V12.04



Introduction

Surveys reveal time and again that security and data protection concerns are the top barriers to Cloud adoption.

At Zadara™ Storage we take these concerns seriously and have made security an integral part of our storage offering. We have architected security into our system and software from the ground up.

With multiple layers of security, our customers can enjoy full, end-to-end data privacy and protection, from Zadara’s physical storage infrastructure all the way to customers’ Cloud Servers.


Physical security

The Zadara Storage Clouds™ are physically located in the most secure data centers of the leading Public Cloud Providers. As of the writing of this document, Zadara Storage is installed at Equinix for Amazon Web Services (AWS), Rackspace, and OpSource. These data centers feature, at minimum, the following important physical security attributes:

  • Biometric access controls
  • 24x7 surveillance
  • Redundant power feeds and generators
  • Robust fire suppression
  • Carefully monitored climate control (to protect the servers that store customer data)


Access Control


Secure Communication

  • The Zadara Cloud Console and Zadara VPSA™ expose RESTful API calls via the HTTPS protocol. This requires 256-bit SSL-encrypted communication and securely identifies the Zadara web server with which the client is communicating.
  • The VPSA GUI client also communicates with the VPSA web server RESTful API via HTTPS to ensure the same level of security.

Identity Management

  • Each Zadara user creates an account within the Zadara Cloud Console. The user’s Cloud Console Password is not stored as plain text in the Cloud Console DB. Instead, a cryptographic hash value (using a one-way SHA-1 hash function) is stored for further Cloud Console login authentication.
  • When a user creates the first VPSA for a given Cloud Provider (i.e., AWS, Rackspace, OpSource, etc), a corresponding tenant is created within the Zadara Storage Cloud Identity Management Server (which is based on OpenStack Keystone).
  • The Cloud Console generates a random 128-bit Tenant Password for that tenant and provides the password, in encrypted form, to the Identity Management Server.
  • Thereafter, the Tenant Password is used by the Cloud Console and the VPSA for retrieving a Keystone API Token and establishing a session-based communication for managing the objects (i.e, VPSAs) belonging to that tenant.
  • For accessing the VPSA (via API or GUI), the Cloud Console provides (via email) an initial 5-character temporary access code. This code can be used only once. The user is requested to enter a strong VPSA User Password to replace the 5-character temporary access code.
  • The Zadara Cloud Console Password and VPSA User Password can be different. This enables support for different permission levels (roles) within an organization.
  • In the event a user forgets the VPSA password, an email will be sent to the user with a new temporary 5-digit access code. The existing VPSA User Password will protect access to the VPSA until the new access code is used.
  • A cryptographic hash value (using a one-way SHA-1 hash function) of the VPSA User Password is stored in the VPSA database for further VPSA login authentication.
  • Zadara Storage employs a session-based authentication mechanism as a means to identify a user for every HTTP request to a VPSA. The client initiates a session by logging in with the VPSA User Password. Upon successful authentication, a Secret API Token is sent back to the client application, for any subsequent REST API communication with the VPSA to identify the authenticated user and validate the session.
  • At any time, a user can generate a new Secret API Token, thus invalidating the previous token and any sessions using it.


Data Privacy

VPSA Architecture

The VPSA architecture provides the basic building blocks for granting complete data privacy for Zadara Users:

  • Each VPSA Virtual Controller is granted dedicated compute resources (RAM and CPU vCores) and dedicated networking resources (NIC VFs) to partition IO stack data handling per-user.
  • Physical drives are the basic storage allocation unit. As a result, only a single VPSA and hence a single User has access to any given physical drive.
  • Physical drives are exposed as iSCSI LUNs to the VPSA Virtual Controllers via a separate back-end network, which is not accessible from outside the Zadara Storage Cloud.
  • IQN-based SCSI LUN Masking is used to ensure that physical disk drives are exposed only to the authorized VPSA.
  • Each user can look up the physical location (by Storage Node Number) of the drives assigned to that user.
  • VPSA Virtual Volumes are presented as iSCSI LUNs and are ‘attached’ to selected Cloud Servers. Again, SCSI LUN Masking is used to prevent access to those Virtual Volumes from other Cloud Servers.

CHAP

  • VPSA requires the usage of Challenge-Handshake Authentication Protocol (CHAP) over iSCSI to authenticate a Cloud Server to a VPSA. CHAP requires that both the Cloud Server and VPSA know a shared CHAP Secret. This secret is never sent on the wire.
  • Each VPSA maintains its CHAP credentials. When a VPSA is created, it auto-generates a CHAP Username (corresponding to the VPSA name) and a random 12-character CHAP Secret.
  • A VPSA User can modify both CHAP Username and CHAP Secret at any time. Existing iSCSI connections will remain valid, but the new credentials will be required for establishing new connections.
  • A VPSA user must enter these values at the Cloud Server (iSCSI Initiator) side to be able to establish an iSCSI connection with the VPSA.
  • The VPSA uses a 128-bit Secret Key to encrypt the CHAP Secret, using the Advanced Encryption Standard (AES), before storing the CHAP Secret on disk. The Secret Key itself is stored in a separate location in the Zadara Storage Cloud. The VPSA retrieves the Secret Key from the Zadara Storage Cloud at runtime, decrypts the CHAP Secret and stores it in Kernel Space only. This means that core-dumping the user-mode process of the VPSA will not reveal the decrypted CHAP Secret.


Data Encryption


Zadara Storage supports Encryption of Data-at-Rest (DAR) and Data-in-Flight (DIF). Because data encryption requires compute overhead, we leave it up to Zadara users to evaluate the trade-off between security and performance. Hence both DAR and DIF encryption are optional features and are disabled by default.

Encryption of Data-at-Rest

  • Encryption management of Data-at-Rest is done at the VPSA Virtual Controller and is defined on a Volume-by-Volume basis, i.e. a user can decide that some Volumes are encrypted, while others are not.
  • A VPSA generates a unique random 128-bit Encryption Key per encrypted Volume, and uses the Advanced Encryption Standard (AES) to encrypt and decrypt the Volume data.
  • The Volume Encryption Keys are stored on disk as ciphertext, using AES with a 128-bit Master Encryption Key, which is generated from a user-supplied Master Encryption Password.
  • The Master Encryption Password is not saved on disk. Only its SHA1 hashsum is saved on disk, for verification purposes only. Since it is virtually impossible to restore the Master Encryption Password from the SHA1 hashsum, each user is fully responsible to retain and protect the Master Encryption Password. During VPSA operation, the Master Encryption Password itself is held in kernel memory of the VPSA. Core-dumping any User Mode process within the VPSA will not reveal the Master Encryption Key.
  • The above method ensures that encrypted Data-at-Rest cannot be accessed without explicitly knowing the user-supplied Master Encryption Password, thus providing full protection to Zadara users who opt for Data-at-Rest encryption.

Encryption of Data-in-Flight

  • For advanced security needs, Zadara Storage supports encryption of Data-in-Flight between the User Cloud Server and the VPSA using Internet Protocol Security (IPSec).
  • Zadara uses Internet Key Exchange (IKE) protocol to negotiate the IPSec encryption keys with a user's Cloud Server. The encryption keys used to encrypt the Data-in-Flight are stored in kernel memory only (of both the VPSA and Cloud Servers), and are never stored on disk in any form. Periodically, encryption keys are renegotiated by VPSA and Cloud Servers’ IKE daemons.
  • A user can configure the renegotiation trigger for each Cloud Server. For example, erncryption keys can be renegotiated every hour, every 10 Gb of sent/received data, etc.


Billing info

Zadara Storage's e-commerce site is PCI-DSS compliant.

Zadara Storage uses FreshBooks to collect credit card information and billing invoices and Authorize.net as its Payment Gateway. Credit card information is neither collected nor stored by Zadara Storage.


Both Freshbooks and Authorize.net serve thousands of businesses and have all the necessary security and compliance features and certifications, including TRUSTe, TrustWave, and others.

More information can be found at their sites:
http://www.freshbooks.com
http://www.authorize.net

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.