Data protection in Amazon MWAA Serverless
The AWS shared responsibility model
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with 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 CloudTrail. For information about using CloudTrail trails to capture AWS activities, see Working with CloudTrail trails in the 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.
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 MWAA Serverless 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.
Data encryption
The following topics describe how Amazon MWAA Serverless protects your data at rest, and in transit. Use this information to learn how Amazon MWAA Serverless integrates with AWS KMS to encrypt data at rest, and how data is encrypted using Transport Layer Security (TLS) protocol in transit.
Encryption at rest
Amazon MWAA Serverless by default encrypts data at rest and uses the KMS key you provide while creating the workflow. If you do not provide a key, Amazon MWAA Serverless encrypts this data using service keys. If you choose to use a customer-managed KMS key, it must be in the same account as the other AWS resources and services you are using with your workflow.
To use a customer-managed KMS key, you must attach the required policy statement for CloudWatch access to your key policy and make the call to API using the KMS policy. Amazon MWAA Serverless attaches two grant to your customer-managed KMS key to encrypt data at rest.
Note
You pay for the storage and use of AWS-owned and customer-managed KMS keys on Amazon MWAA Serverless.
For more information, refer to AWS KMS Pricing
Encryption artifacts
You specify the encryption artifacts used for at rest encryption by providing a customer-managed key when you create your Amazon MWAA Serverless workflow. Amazon MWAA Serverless adds the grants needed to your specified key.
CloudWatch Logs: If you to use a customer-managed KMS key, you must add a key policy to your key to allow CloudWatch Logs to use your key. If you do not provide a customer-managed KMS key, CloudWatch Logs are encrypted using Server Side Encryption with service owned key.
Encryption in transit
Data in transit is data that may be intercepted as it travels the network.
Transport Layer Security (TLS) encrypts the Amazon MWAA Serverless objects in transit between your Amazon MWAA Serverless workflow components and other AWS services that integrate with Amazon MWAA Serverless, such as Amazon S3. For more information about Amazon S3 encryption, refer to Protecting data using encryption.
Key management
You can configure AWS KMS to automatically rotate your KMS keys. This rotates your keys once a year while saving old keys indefinitely so that your data can still be decrypted. For more information, refer to Rotate AWS KMS keys.
Using customer-managed keys for encryption
You can optionally provide a Customer managed key for data encryption on your workflow. You must create the customer managed KMS key in the same Region as your Amazon MWAA Serverless workflow instance and your Amazon S3 bucket where you store resources for your workflows.
Key support
| AWS KMS feature | Supported |
|---|---|
|
Yes |
|
|
No |
|
|
No |
Using Grants for Encryption
There are two resource-based access control mechanisms supported by AWS KMS for customer managed KMS key: a key policy and grant.
A key policy is used when the permission is mostly static and used in synchronous service mode. A grant is used when more dynamic and granular permissions are required, such as when a service needs to define different access permissions for itself or other accounts.
When you create an Amazon MWAA Serverless workflow and specify a customer managed KMS key, Amazon MWAA Serverless attaches the grant to your customer managed KMS key.
Amazon MWAA Serverless creates, and attaches, additional grants to a specified KMS key on your behalf. This includes policies to retire a grant if you delete your workflow, to use your customer managed KMS key for Client-Side Encryption (CSE), and for execution role that needs to access secrets protected by your customer managed key in Secrets Manager.
Grants
Amazon MWAA Serverless adds the following resource based policy grants on your behalf to a customer managed KMS key. These policies allow the grantee and the principal (Amazon MWAA Serverless) to perform actions defined in the policy.
Grant 1: Create data plane resources
Grant 2: For workflow execution
Sample polices
Execution role: To provide permissions to the Execution role permission for KMS keys, attach following add-on policies to the execution role.
Note that you can not use kms:viaService in the execution role since the execution role credentials are directly used to make encrypt/decrypt calls while execution of the workflow.
Trust relationship for the workflow execution role:
Add KMS resource policy for CloudWatch logs
Attaching key policies to a customer-managed key
If the customer managed KMS key you used for your Amazon MWAA Serverless workflow is not already configured to work with CloudWatch, you must update the key policy to allow for encrypted CloudWatch Logs. For more information, refer to the Encrypt log data in CloudWatch using AWS KMS.
The following example represents a key policy for CloudWatch Logs. Substitute the sample values provided for the region.
You could add a condition on kms:viaService to scope down the usage by adding the following statement to the key policy.
API Policies
This section applies only if you are using a customer-managed KMS key. Use the following add-on policies on the role that is calling these APIs when using a customer-managed KMS key.
CreateWorkflow API:
GetWorkflow and GetWorkflowRun
Note: only permission needed is kms:Decrypt. You can scope down to kms:viaService
StartWorkflowRun