While implementing data encryption is essential to protecting your data, it's important to recognize that there are multiple approaches to encryption, each with its own set of advantages and disadvantages that warrant careful consideration.
In this post, I’ll explore different options for encrypting data in Amazon FSx for NetApp ONTAP (FSx for ONTAP) and discuss their respective pros and cons.
Here’s what I’ll cover:
What are the challenges (and limitations) of security hardening FSx for ONTAP?
Leveraging NetApp Volume Encryption (NVE) for encryption at rest
NVE encryption with ONTAP-generated keys
NVE encryption with customer-generated keys (managed by AWS KMS)
Evaluating different key rotation options
Encryption in transit and the impact of client-side encryption
Performance considerations
Key aspects to consider
Recommendations
Understanding how encryption works across different AWS Regions or Availability Zones
Summary and key takeaways
What are the challenges (and limitations) of security hardening FSx for ONTAP?
FSx for ONTAP is a modern, high-performance file storage solution that provides built-in security features that deliver secure and reliable data management. It leverages the scalability and flexibility of AWS, combined with the capabilities of NetApp® ONTAP® storage to deliver a solution that meets a wide range of industry standards.
Even with the range of capabilities offered by FSx for ONTAP, there are still several challenges that you will likely face when attempting to harden your security:
- Evolving threat landscape and attack vectors: Determining optimal security strategies is complex due to the rapid evolution of cyber threats. This includes sophisticated attacks like advanced persistent threats (APTs), zero-day exploits targeting vulnerabilities in storage systems or protocols—Network File System (NFS) and Common Internet File System (CIFS)—and ransomware variants specifically designed to encrypt or corrupt data within cloud-based storage.
Understanding and mitigating these risks requires continuous threat intelligence, vulnerability scanning, and the implementation of layered security controls. This involves not only securing the FSx for ONTAP file system itself but also the surrounding AWS environment, including network access controls, identity and access management (IAM) roles, and encryption key management.
- Complex compliance requirements and audit trails: Complying with numerous regulatory requirements such as The General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act of 1996 (HIPAA), or Payment Card Industry Data Security Standard (PCI DSS), and widespread adherence to robust security protocols can present considerable difficulties.
This challenge involves implementing granular access controls, encryption both at rest and in transit, maintaining detailed audit logs of all file system operations, and regularly conducting security assessments and penetration testing. Additionally, organizations must be able to demonstrate compliance through reporting and documentation, which requires a thorough understanding of both the regulatory landscape and the technical implementation of security controls within FSx for ONTAP and the broader AWS ecosystem. This includes managing encryption keys in compliance with regulations and maintaining proper key rotation and access control.
Understanding the additional measures to take in FSx for ONTAP to further improve the security posture and harden the environment and their effective implementation is critical for maintaining a secure operating environment.
Leveraging NetApp Volume Encryption (NVE) for encryption at rest
As an AWS service, FSx for ONTAP uses the built-in AWS Key Management Service (AWS KMS) by default, encrypting the entire file system and all its volumes upon creation. With the new support for external Key Management Interoperability Protocol (KMIP) feature—an open protocol standard that extends how cryptographic keys can communicate—FSx for ONTAP can take encryption and security hardening even further and leverage advanced NetApp Volume Encryption (NVE) capabilities.
NVE is a NetApp technology for encrypting data at rest in ONTAP-based volumes. It can provide additional security features and capabilities, including enabling FlexCache® for FSx for ONTAP volumes that have been encrypted with NVE. It’s worth noting that after ONTAP version 9.14, we can also have unencrypted cache volumes from encrypted origins.
As an advanced encryption technology, it enables two distinct options for encryption at rest and cryptographic key rotation:
- NVE encryption with ONTAP-generated keys
- NVE encryption with customer-generated keys (managed by AWS KMS)
Below we explore how each encryption option available for FSx for ONTAP looks and evaluate different choices for key rotation.
NVE encryption with ONTAP-generated keys
With ONTAP-generated keys, the NVE encryption will use a distinct volume data encryption key (VDEK) to encrypt each volume. When a new volume is created for NVE, the ONTAP crypto module generates the key and sends it to the external key manager using the standard KMIP protocol, which is the first step to enable encryption features. The next step is for the external key manager to use that key to encrypt the volume data.
The diagram below shows the different components involved during these two steps that enable NVE encryption with ONTAP-generated keys:
NVE encryption with customer-generated keys (managed by AWS KMS)
With customer-generated keys, the NVE encryption will create a VDEK for each volume.
After the creation of the encryption key, there are four important steps that enable data encryption:
- The encrypted value of the VDEK is stored in a volume metadata file on the disk.
- Each storage pool contains a storage virtual machine (SVM) key encryption key (KEK). The SVM-KEK is used to wrap, i.e., encrypt, the VDEK. The SVM-KEK’s themselves are indirectly “wrapped” by the private data encryption key (pDEK), i.e., the database partition containing the SVM-KEK is encrypted by pDEK.
- The pDEK is encrypted using the customer-managed encryption key (CMEK) that is stored and managed in AWS KMS.
- The CMEK is generated using advanced encryption standard (AES) material by the customer key manager and imported into AWS KMS.
It’s worth noting that due to the pDEK’s role in protecting the SVM-KEK, which in turn envelops the VDEK(s), only one KMS-CMK key is required for each SVM.
In the diagram below we see how the different components related to each other during these four required steps required to enable NVE encryption with customer-generated keys.
Evaluating different key rotation options
The periodic rotation of the encryption key can continuously improve your security posture and reduce the chance of an exposed encryption key leading to a data leak.
Below are the main options to consider depending on the type of encryption key chosen:
- NVE encryption with ONTAP-generated keys
To perform a VDEK key rotation, the “rekey” command can be issued to rekey the volume. However, rekeying a volume is a very time-consuming process—one that can last anywhere from several hours to several days—that requires re-encrypting all the data with a new VDEK key. From a performance perspective, this process can have a minor impact, depending on how busy the file system is and the available compute power.
There are three simple steps to the process:
- The ONTAP CryptoMod will generate a new VDEK key
- The key will be communicated to the external key manager
- ONTAP will rekey the volume
- NVE encryption with customer-generated keys managed by AWS KMS
The key rotation for this type of encryption can happen in two methods, depending on whether internal or external encryption is being used:
- Key rotation with internal encryption: The AWS KMS customer-managed key (KMS-CMK) remains unchanged. Instead of rotating the CMEK, we will rotate the SVM-KEK instead which is used to wrap all the VDEK keys for the specific SVM. This approach enables key rotation without the necessity of re-encrypting the data in the volumes. If the FSx for ONTAP instance has multiple SVMs, this process must be repeated for each SVM.
- Key rotation with external encryption: The process starts by generating a fresh KMS-CMK using external key manager material. Once the new key is created, FSx for ONTAP will be directed to rekey a designated SVM-KEK with the new KMS-CMK key. The SVM-KEK serves as an envelope for all the VDEK keys associated with that particular SVM. This approach enables key rotation without the requirement to re-encrypt the data stored in the volumes. If the FSx for ONTAP instance contains multiple SVMs, this process must be repeated for each SVM.
Encryption in transit and the impact of client-side encryption
To achieve comprehensive data encryption, it's vital to consider two additional aspects beyond encryption at rest:
- Encryption in transit: This keeps data encrypted while it's being transferred between locations, such as from a client application to a server or between servers. This protects against unauthorized interception or eavesdropping during transmission. Typical methods for encryption in transit are: NFS encryption, CIFS encryption with Kerberos, Internet Protocol Security (IPSec) for Internet Small Computer System Interface (iSCSI), IPSec for NFS, and, starting with ONTAP version 9.15.1, NFS over Transport Layer Security (TLS).
- Client-side encryption: This involves encrypting data directly on the client device (e.g., a user's computer or mobile device) before any data is even sent to the server. This adds an extra layer of security, as the data is encrypted even before it leaves the client's control.
Performance considerations
While encryption in transit and client-side encryption offer enhanced security, it's crucial to be mindful of their potential impact on performance. Encryption and decryption processes require computational resources, which can introduce overhead and potentially affect the speed and responsiveness of applications.
Key aspects to consider:
- Encryption in transit:
- Small overhead on the performance in the CPU consumption, though not noticeable for NFS and CIFS clients.
- There is a slight impact on the client side.
- For IPSec, we expect to have an important performance impact for both iSCSI and NFS.
- Client-side encryption:
- There is no storage-side impact.
- It could impact client performance as it introduces additional computational overhead as the client device needs to perform encryption and decryption operations on the data before transmitting or storing it.
Recommendations
Before implementing encryption in transit (or client-side encryption) in a production environment, it's highly recommended to:
- Simulate your workload: Conduct thorough performance testing with a representative workload to assess the potential impact on system performance. Your testing results will give you insights into finding bottlenecks and other areas where you might be able to optimize.
- Consider trade-offs: Depending on your workload, there will be different trade-offs you can accept between your security stance and your performance requirements. In some cases, it might be necessary to fine-tune encryption settings or explore alternative encryption algorithms to strike the right balance.
- Monitor and optimize: Once encryption is implemented, continue to monitor how your system is performing. If you need to make any adjustments, do as needed to keep things running optimally.
Understanding how FSx for ONTAP encryption works across different AWS Regions and Availability Zones
Cross-Region replication for FSx for ONTAP provides flexibility by allowing you to establish replication to a secondary FSx for ONTAP instance in a different Region to increase resilience. That secondary FSx for ONTAP can either be configured in a single-Availability Zone (AZ) or in multiple AZs. In either scenario, the integrity of data and making sure it follows the same data protection requirements as the primary file system is crucial. Therefore, regardless of whether you opt for a single-AZ or multi-AZ configuration for your secondary file system, both the primary and secondary file systems should be encrypted.
You have the flexibility to use different encryption keys for each file system, and these keys can be managed within the same key management service instance or across separate AWS KMS instances. While the encryption configuration is fairly similar for both single or multi-AZ, one key point to remember is that if you wish to use the same encryption keys, the AWS KMS policy should be adjusted to grant the correct level of privileges for the Region and AZs you intend to use. This gives a high degree of flexibility for fine-grain customization of data access and protection controls to meet your requirements. In addition to file system encryption, the replication tunnel itself is also encrypted, adding another layer of protection to your data as it's transferred between regions.
- Cross-Region replication to a single-AZ FSx for ONTAP: This is cost-effective, but less resilient, cross-Region replication strategy. It uses NetApp SnapMirror® for continuous data replication to a single-AZ secondary file system, resulting in low RPO and RTO but a single point of failure. This approach is suitable for cost-sensitive, non-critical workload but should be evaluated carefully against your plans for business continuity and your compliance requirements. Operating under a single AZ can be impacted if there is ever the case where an entire AZ fails.
- Cross-Region replication to a multi-AZ FSx for ONTAP: This is a more resilient cross-Region replication strategy. It uses NetApp SnapMirror for continuous data replication to a multi-AZ secondary file system, resulting in low RPO and RTO, and eliminating the single point of failure risk. This approach is suitable for business-critical workloads and can address the requirements of many security strategies and business impact assessment of critical systems.
Summary and key takeaways
In this article, we explored the diverse encryption options available in FSx for ONTAP, encompassing both in-transit and at-rest encryption, and giving special attention to performance impact, key rotation methods, and the mechanics of encryption across different AWS Regions and Availability Zones.
Learn more about FSx for ONTAP here.
