You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 1, 2020. It is now read-only.
@wolfeidau Thanks for opening this issue! We did consider some compliance implications while building the apps, but you bring up good points here:
SQS Queues - We could add an optional parameter to specify a KMS encryption key (could be default key or customer-managed key). If specified, we'd enable encryption on the SQS queue using the specified key.
We could handle SNS topics similar to SQS queues.
For S3 buckets, it depends on the app. We did consider this for the storage and backup app, but rather than adding encryption options to the app itself, we allowed the app to work with an existing S3 bucket. That way, you could configure the bucket however you want, rather than the app have to surface every possible option for S3 buckets. The search and analytics app does create an S3 bucket to use as a dead-letter queue for the Kinesis Firehose Delivery Stream. We may need to parameterize that as well to support encryption of that bucket.
Starting with encryption at rest where possible would be great. My ticket was just about ensuring this application has sane defaults and calling this out in the README.
Most people who work in security sensitive areas will understand encryption at rest where possible as a baseline.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Just wanted to know if you had considered enabling encryption for all the data stored?
Specifically the:
The text was updated successfully, but these errors were encountered: