How Orca Security efficiently shares encrypted Amazon EBS Snapshots

Orca Security, an AWS Partner, is an independent cybersecurity software provider whose agent-less cloud security environment is trusted by hundreds of enterprises globally. Orca makes cloud security simple for enterprises moving to and scaling with AWS with its patented SideScanning™ technology and Unified Data Model.

Orca’s customers use Amazon Elastic Block Store (Amazon EBS) volumes for high-performance workloads. To make sure its customers’ volume performance is not affected while Orca performs security scanning of resources, Orca takes a snapshot of customers’ volumes, shares this snapshot with Orca’s account, and creates a volume from the shared snapshot in its own account for multi-purpose scanning.

For snapshots encrypted with customer managed keys, customers can provide access to Orca by managing the AWS Key Management Service (KMS) and AWS Identity and Access Management (IAM) policies. For snapshots encrypted with AWS managed keys, the key policies cannot be modified to provide Orca access. As such, Orca performs re-encryption using a customer managed key provided by its customers before resuming the scanning workflow. The repeated re-encryption process posed a challenge on the efficiency of Orca’s scanning workflow. In order to scale efficiently and maintain a high level of security, Orca Security needed a new approach.

In this post, we provide an overview of cross-account data access for encrypted EBS Snapshots and discuss the efficiency challenges faced by Orca Security when securely accessing EBS Snapshots encrypted with AWS managed keys. For those snapshots, we explore Orca’s need for re-encryption and its transition to a more efficient scanning method by setting the EBS default encryption key to a customer managed key. You can use this solution when faced with a similar need for providing secure cross-account access to your EBS Snapshots.

Overview of encryption key management supported by Amazon EBS

Amazon EBS supports two options for how the encryption keys can be managed. Customers choose between these key management options based on their regulatory compliance requirements, security policies, and the level of control they need over the encryption keys.

Customer managed keys are created and managed by customers using AWS KMS. With customer managed keys, customers have full control over the key lifecycle, including the creation, rotation, and deletion of their keys. This provides greater flexibility and control over key usage and access. The actions permitted for these keys are controlled by AWS IAM and AWS KMS key policies created and managed by the customer. Additionally, customers can use their own key material to create their keys. This can be useful in certain compliance scenarios where customers are required to have possession of the key material for their encryption keys.

AWS managed keys are AWS KMS keys in a customer’s account that are created, managed, and used on the customer’s behalf by an AWS service. With AWS managed keys, AWS handles key creation, rotation, and storage, making it simple for customers to encrypt their data without having to manage their own keys. As the name implies, each AWS service that creates these keys also manages the key lifecycle, rotation, and associated AWS KMS key policies for these keys.

Amazon EBS Snapshots inherit the same AWS KMS key as the source EBS volume. For snapshots encrypted with customer managed keys, customers can manage access to their customer managed keys using AWS KMS and IAM policies. As such, customers can provide Orca access to their snapshots using AWS KMS and IAM policies. Orca can then share the snapshots with their own account to continue with their scanning workflow. AWS managed key policies cannot be modified. As a result, customers cannot provide Orca access to their snapshots encrypted with AWS managed keys, creating a bottleneck for Orca to access snapshots from customers for scanning purposes.

Orca’s search to efficiently share resources at scale

When Amazon EBS Snapshots were encrypted with AWS managed keys, Orca first re-encrypted them to customer managed keys by making a copy of the snapshots, storing these snapshot copies in customers’ accounts, and then proceeding with their scanning workflow. Orca deletes the snapshots created after scanning completes to save storage costs for customers.  The workflow does not scale efficiently, because for each snapshot encrypted with AWS managed keys, 100% of the EBS data needs to be duplicated each time Orca performs a scan. At the time, Orca had two options for scanning snapshots encrypted with AWS managed keys:

• Option 1: Create just-in-time snapshots upon scanning needs

When Orca received a scanning need for Amazon EBS resources from its customers, Orca would create a snapshot, copy the snapshot and re-encrypt with a customer managed key provided by its customers, share the snapshot with an Orca account to create a volume for scanning, and then delete the snapshot after scanning. As a result, the copy of each snapshot became a full copy of the snapshot data, and these snapshots could not benefit from the incrementality of snapshot copying. This option doesn’t incur much additional cost to Orca customers because Orca would delete the snapshots upon completion of scanning. However, this involves ad-hoc operations that are not only manual, but also time-consuming.

• Option 2: Create snapshots in advance for eventual scanning needs

As soon as an EBS volume is created, Orca will create a snapshot of the volume and copy it for re-encryption with a customer managed key. Orca would keep these original snapshots and enable incremental snapshots from then on. Creating and copying incremental snapshots is significantly faster than copying full snapshots, but keeping the original snapshots incurs additional snapshot storage costs for Orca customers.

Orca chose Option 1 to keep additional snapshot storage costs at a minimum. Rather than a long-term solution that solves the scaling challenge, Option 1 was merely a temporary fix. Orca still needed to find a solution that could be utilized at scale to match its customers’ growing needs to protect more resources.

Figure 1: Orca’s initial scanning workflow for snapshots encrypted with AWS managed keys.

Although our focus in this discussion is primarily on Orca’s Amazon EBS scanning use case, it is important to acknowledge that Amazon EBS Snapshots are used as part of a disaster recovery strategy, to migrate data across AWS Regions and accounts, and as part of a resilient backup plan.

A simple solution to override default encryption keys

To form a long-term solution that can be utilized at scale, Orca Security, in collaboration with the Amazon EBS team, conducted a comprehensive analysis of various AWS customer use cases. Each use case presented unique complexities related to security, performance requirements, compliance regulations, and budget constraints. By thoroughly examining these use cases, Orca and the Amazon EBS team aimed to develop a solution that would address the specific needs and challenges.

During this examination, one potential solution emerged, which involved recommending customers transition from AWS managed keys to customer managed keys. Many customers use AWS managed keys because for each account in each Region, an AWS managed key is automatically set as the default KMS key for EBS encryption. When customers create encrypted EBS volumes, such as using CreateVolume or in the EBS block device mapping for RunInstances, they can just specify “encrypted” to “true” without specifying a KMS key. In this case, EBS will then use the default KMS key for encryption. For customers who want to switch to using customer managed keys, they can simply change the default KMS key type from AWS managed keys to customer managed keys.

Amazon EBS has a dedicated API, modify-ebs-default-kms-key-id, that customers can call to change their default KMS key. Customers can make the change through the AWS Command Line Interface (AWS CLI) or in the AWS Management Console. To change the default KMS key using the AWS Management Console, go to the EC2 dashboard and select Data protection and security under Account attributes. Stay on the Data protection and security page, then select Manage and change the Default encryption key to your sharable customer managed key.

Figure 2: AWS Management Console page showing how to change the default encryption key.

This solution entails the retention of the original AWS managed key encryption for existing volumes, while new volumes created – either without snapshots or from unencrypted snapshots, snapshots encrypted with the new default KMS key, and shared snapshots – will be encrypted with customer managed keys. An important advantage of this approach is that with one API call per account, access to snapshots created from EBS volumes can now be managed via AWS KMS and IAM policies, enabling Orca to quickly and efficiently access customer snapshots for scanning.

Figure 3: Orca’s scanning workflow after customers change their default KMS key for EBS encryption to customer managed keys.

For Orca, this streamlined approach significantly enhances the speed and efficiency of the scanning processes and mitigates additional costs incurred when managing multiple snapshots lineages. Note that the additional cost for the customer associated with this solution is minimal, offering Orca a highly efficient and cost-effective solution for its needs.

Conclusion

Enabling volume encryption with customer managed keys is a best practice if customers need to access Amazon EBS data from a separate account. Although AWS managed keys offer convenience, they may not offer the desired level of control and ownership over encryption keys that organizations seek. Using modify-ebs-default-kms-key-id is a simple way to change EBS encryption to a customer managed key, which provides customers with more flexibility when it comes to managing the key used to encrypt their data.

For Orca Security, helping its customers adopt customer managed keys enables Orca’s SideScanning™ capabilities to access encrypted volumes in a more efficient manner. This revamped approach has helped Orca scale and provide better support for its customers. This change was immediately noticed by Orca customers, who now benefit from quicker and more reliable protection from Orca’s technology.

Thank you for reading this post. If you have any comments or questions, we encourage you to share them in the comments section.