EFS filesystems

Amazon EFS is a scalable file storage solution for use with both AWS services and on-premises resources. Given its shared nature and the potential for multiple resources to access it simultaneously, ensuring data protection and security for EFS is essential. Let’s explore advanced strategies for safeguarding data stored in EFS filesystems, focusing on backup mechanisms and encryption.

Backup

EFS backups are essential for data durability and recovery. AWS offers native backup solutions for EFS through AWS Backup. AWS Backup integrates seamlessly with EFS, allowing you to centrally manage and automate backups across various AWS services.

Encryption

Data security is critical, and EFS offers robust encryption options to secure data at rest and in transit:

• Encryption at rest: EFS features automatic encryption at rest, which can be enabled during filesystem creation or on existing filesystems. This transparently encrypts data before it is written to the storage layer, and decrypts it upon reading. By default, EFS uses the AWS KMS key for EFS (aws/efs), but you can use a custom KMS CMK for greater control.
• Encryption in transit: EFS supports TLS encryption for data in transit. Ensure encryption by using the TLS mount option when mounting EFS filesystems. It is recommended to enforce this with IAM policies for added security. For a practical demonstration, see the Filesystem policy subsection.
• CSE: For additional security, especially for highly sensitive data, consider implementing CSE using the AWS Encryption SDK to encrypt data before it reaches EFS and decrypt it client-side after reading. While this offers enhanced security, be mindful of potential latency and management overhead.

Filesystem policy

Filesystem policies are resource-based IAM policies that are directly attached to EFS filesystems. They work the same way as bucket policies work in S3 and can be used for implementing fine-grained access control over the actions users can perform within the mounted filesystem. This is particularly useful for enforcing organization-wide security policies, such as read-only access for certain groups or denying access to specific IP ranges.

Another use case is to restrict mounting actions to only allow encrypted connections. In the following filesystem policy example, the elasticfilesystem:ClientMount action is denied if secure transport (TLS) is not used, effectively enforcing encrypted mounts:
{
  “Id”: “efs-mount-encryption-policy”,
  “Statement”: [
    {
      “Sid”: “DenyUnencryptedMount”,
      “Effect”: “Deny”,
      “Principal”: “*”,
      “Action”: “elasticfilesystem:ClientMount”,
      “Resource”: “arn:aws:elasticfilesystem:us-east-1:111111111111:file-system/file-system-id”,
      “Condition”: {
        “Bool”: {
          “aws:SecureTransport”: “false”
        }
      }
    }
  ]
}