# Data protection in Amazon File Cache
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon File Cache. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Amazon File Cache or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
**Topics**
+ [Data encryption in Amazon File Cache](encryption.md)
# Data encryption in Amazon File Cache
Amazon File Cache supports two forms of data encryption for caches, encryption of data at rest and encryption in transit. Encryption of data at rest is automatically enabled when creating an Amazon File Cache cache. Encryption of data in transit is automatically enabled when you access an Amazon File Cache cache from [Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) that support this feature.
## When to use encryption
If your organization is subject to corporate or regulatory policies that require encryption of data and metadata at rest, we recommend creating an encrypted cache and mounting your cache using encryption of data in transit.
**Topics**
+ [When to use encryption](#whenencrypt)
+ [Encrypting data at rest](encryption-at-rest.md)
+ [Encrypting data in transit](encryption-in-transit.md)
+ [How Amazon File Cache uses AWS KMS](FileCacheKMS.md)
# Encrypting data at rest
Encryption of data at rest is automatically enabled when you create an Amazon File Cache resource through the AWS Management Console, the AWS CLI, or programmatically through the AWS API or one of the AWS SDKs. Your organization might require the encryption of all data that meets a specific classification or is associated with a particular application, workload, or environment. You can specify the AWS Key Management Service (AWS KMS) key to use for encrypting the data when you create an Amazon File Cache resource. For more information about creating a cache encrypted at rest using the console, see [Step 1: Create your cache](getting-started-step1.md).
**Note**
The AWS key management infrastructure uses Federal Information Processing Standards (FIPS) 140-2 approved cryptographic algorithms. The infrastructure is consistent with National Institute of Standards and Technology (NIST) 800-57 recommendations.
For more information, see [How Amazon File Cache uses AWS KMS](FileCacheKMS.md).
## How encryption at rest works
Data and metadata are automatically encrypted before being written to the cache. When you attach the encrypted volume to an instance, Amazon EC2 sends a `CreateGrant` request to AWS KMS, so that it can decrypt the data key. Amazon EC2 uses the plaintext data key in hypervisor memory to encrypt disk I/O to the volume. The plaintext data key persists in memory as long as the volume is attached to the instance.Similarly, as data and metadata are read, they are automatically decrypted before being presented to the application. These processes are handled transparently by Amazon File Cache, so you don't have to modify your applications.
Amazon File Cache uses industry-standard AES-256 encryption algorithm to encrypt cache data at rest. For more information, see [Cryptography Basics](https://docs.aws.amazon.com/kms/latest/developerguide/crypto-intro.html) in the *AWS Key Management Service Developer Guide*.
# Encrypting data in transit
Encryption of data in transit is automatically enabled when you access an Amazon File Cache resource from compute instances that support encryption in transit. To learn which EC2 instances support encryption in transit, see [Encryption in Transit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit) in the *Amazon EC2 User Guide*.
Amazon File Cache encrypts traffic between the cache and your S3 data repositories using HTTPS (TLS). Amazon File Cache does not encrypt traffic between the cache and your NFSv3 data repositories, as the NFSv3 protocol does not encrypt data at the protocol level. For encryption in transit between your on-premises file systems and Amazon File Cache, you can use a virtual private network (VPN) to ensure encrypted data transfers between your VPC and your on-premises network. If you're using Direct Connect, you can use Site-to-Site VPN to combine one or more Direct Connect dedicated network connections with Site-to-Site VPN. Additionally, you can use [MAC Security](https://docs.aws.amazon.com/directconnect/latest/UserGuide/MACsec.html) (MACsec) to encrypt your data from your corporate data center to the Direct Connect location. For more information, see [Encryption in Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/encryption-in-transit.html).
You can explicitly prohibit some or all users in your organization from creating Amazon File Cache resources linked to NFSv3 file systems using the `fsx:NfsDataRepositoryEncryptionInTransitEnabled` and `fsx:NfsDataRepositoryAuthenticationEnabled` context keys to control access to the `CreateFileCache` API action. The following is an example of an AWS Organizations Service control policy (SCP) that prohibits creation of a Amazon File Cache resource linked to an NFSv3 data repository:
For more information about IAM condition keys, see [Policy condition keys for File Cache](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-conditionkeys).
# How Amazon File Cache uses AWS KMS
Amazon File Cache integrates with AWS Key Management Service (AWS KMS) for key management for encrypting data at rest. File Cache uses AWS KMS keys to encrypt your cache in the following way:
+ **Encrypting data at rest** – Amazon File Cache encrypts data automatically before it is written to the cache, and automatically decrypts data as it is read. Data is encrypted using an XTS-AES-256 block cipher. You choose the KMS key that's used to encrypt and decrypt data, either the AWS managed key for Amazon File Cache, `aws/fsx`, or a customer managed key. You can enable, disable, or revoke grants on this KMS key. This KMS key can be one of the two following types:
+ **AWS managed key for Amazon File Cache** – This is the default KMS key, `aws/fsx`. You're not charged to create and store a KMS key, but there are usage charges. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).
+ **Customer managed key** – This is the most flexible KMS key to use, because you can configure its key policies and grants for multiple users or services. For more information on creating customer managed keys, see [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the* AWS Key Management Service Developer Guide.*
If you use a customer managed key as your KMS key for file data encryption and decryption, you can enable key rotation. When you enable key rotation, AWS KMS automatically rotates your key once per year. Additionally, with a customer managed key, you can choose when to disable, re-enable, delete, or revoke access to your customer managed key at any time.
**Important**
Amazon File Cache accepts only symmetric encryption KMS keys. You can't use asymmetric KMS keys with Amazon File Cache.
## Amazon File Cache key policies for AWS KMS
Key policies are the primary way to control access to KMS keys. For more information on key policies, see [Using key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) in the *AWS Key Management Service Developer Guide. *The following list describes all the AWS KMS–related permissions supported by Amazon File Cache for encrypted at rest caches:
+ **kms:Encrypt** – (Optional) Encrypts plaintext into ciphertext. This permission is included in the default key policy.
+ **kms:Decrypt** – (Required) Decrypts ciphertext. Ciphertext is plaintext that has been previously encrypted. This permission is included in the default key policy.
+ **kms:ReEncrypt** – (Optional) Encrypts data on the server side with a new KMS key, without exposing the plaintext of the data on the client side. The data is first decrypted and then re-encrypted. This permission is included in the default key policy.
+ **kms:GenerateDataKeyWithoutPlaintext** – (Required) Returns a data encryption key encrypted under a KMS key. This permission is included in the default key policy under **kms:GenerateDataKey\$1**.
+ **kms:CreateGrant** – (Required) Adds a grant to a key to specify who can use the key and under what conditions. Grants are alternate permission mechanisms to key policies. For more information on grants, see [Using grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide.* This permission is included in the default key policy.
+ **kms:DescribeKey** – (Required) Provides detailed information about the specified KMS key. This permission is included in the default key policy.
+ **kms:ListAliases** – (Optional) Lists all of the key aliases in the account. When you use the console to create an encrypted cache, this permission populates the list to select the KMS key. We recommend using this permission to provide the best user experience. This permission is included in the default key policy.