Platform Security and Compliance
Table of Contents
- SOC2 Type 1 Compliance
- Secure Tenancy and Secure Data Plane
- Service is entirely resident in the user’s AWS accounts
- Secure Back Plane
- Control messages and data encryption
- Elastio service network isolation
SOC2 Type 1 Compliance
Security is paramount at Elastio as a company, and our mission is to protect your critical data. We have dedicated resources and financial investment to ongoing independent third-party evaluations. SOC 2 Type 1 compliance ensures that we safeguard customer data throughout our services and meet standards for strong operational effectiveness – a fundamental tenet of our offerings.
Secure Tenancy and Secure Data Plane
Elastio provides multiple security and compliance requirements while delivering access to our multi-tenant console. The options make use of a combination of AWS secure services and enterprise-grade encryption to protect the control messages and meta-data sent between the Elastio cloud connector that resides in the AWS account and the AWS console. Commands from the tenant and meta-data about Elastio operation in your AWS account are always encrypted in transit. Your backup data never leaves your account and is never accessible by the cloud connector or personnel.
Service is entirely resident in the user’s AWS accounts
Elastio secures user data in the user account, and data is never transferred to or accessible by Elastio. The data is encrypted at rest using Amazon KMS keys and in-flight and can be air-gapped in a separate account for additional isolation. Data is stored with AWS’s AES256 encryption. However, inside our ScaleZ™ vault, we encrypt each block of data transferred in with AES-GCM with the key secured on the client side. Each client has separate keys per object to isolate your data from complete compromise.
Secure Back Plane
Elastio uses a lightweight command-and-control channel between our SaaS and customer AWS accounts, built on AWS SQS queues and Lambda functions. The service requires access to specific AWS APIs, but this can be accomplished via PrivateLink if the VPC is isolated from the Internet. As part of our service deployment, the customer grants an Elastio-controlled tenant-specific IAM role the permissions Elastio needs to deploy the service, read from these queues, and invoke these lambdas. You can monitor the activity on these resources and can be assured that only the specific operations granted to our IAM role will be performed. There is never an IP network link between Elastio and the customer’s VPCs; all communication is via SQS messages and Lambda invocations. Clients will provide unique authentication credentials tied to our Role Based access in IAM. All communications are encrypted using the latest TLS protocols.
Each asset’s unique AES key is encrypted with the vault KMS key, so access to all of those per-asset keys is, in effect, controlled by access to the KMS key. Keys are never stored unencrypted; they are always encrypted in an AES envelope before storage.
Control messages and data encryption
Elastio enables S3 server-side encryption (SSE) as an additional layer of protection. All backup data is encrypted with a unique AES key per asset, on the client side, before being uploaded to S3. These keys are, in turn, protected by a per-vault key stored in the KMS, so only IAM roles with specific permission can access the KMS keys can decrypt data in the vault.
Because we use a unique AES key per asset, even a malicious client cannot use knowledge of one of these encryption keys to access backup data from another asset because the other asset uses a different key.
Elastio service network isolation
The Elastio service is self-sufficient and, once set up, does not depend on the tenant to perform backups and restores of any type, ransomware and malware scanning, or backup scheduling. This means an Elastio SaaS outage doesn’t stop scheduled backups. Nor does it stop the ransomware and malware scans. Customers can restore from backups in the event of an Elastio SaaS outage as well.