What solution will address this issue with the LEAST operational overhead and will provide monitoring for potential future violations?
Enable SSE encryption on the S3 buckets and RDS database. Enable OS-based encryption of data on EBS volumes. Configure Amazon Inspector agents on EC2 instances to report on insecure encryption ciphers. Set up AWS Config rules to periodically check for non-encrypted S3 objects.
Configure the application to encrypt each file prior to storing on Amazon S3. Enable OS-based encryption of data on EBS volumes. Encrypt data on write to RDS. Run cron jobs on each instance to check for unencrypted data and notify via Amazon SNS. Use S3 Events to call an AWS Lambda function and verify if the file is encrypted.
Enable Secure Sockets Layer (SSL) on the load balancer, ensure that AWS Lambda is using SSL to communicate to the RDS database, and enable S3encryption. Configure the application to force SSL for incoming connections and configure RDS to only grant access if the session is encrypted. Configure Amazon Inspector agents on EC2 instances to report on insecure encryption ciphers.
Enable SSE encryption on the S3 buckets, EBS volumes, and the RDS database. Store RDS credentials in EC2 Parameter Store. Enable a policy on the S3 bucket to deny unencrypted puts. Set up AWS Config rules to periodically check for non-encrypted S3 objects and EBS volumes, and to ensure that RDS storage is encrypted.
Explanations:
While SSE encryption on S3 and RDS is a good step, enabling OS-based encryption for EBS volumes and configuring Amazon Inspector are unnecessary for addressing encryption at rest. AWS Config rules are useful for monitoring S3 objects but do not provide a comprehensive solution to enforce encryption across all services (e.g., EBS, RDS).
Encrypting files manually before storing them in S3 adds significant operational overhead and complexity. Additionally, cron jobs and manual notifications add unnecessary management burden. While Lambda can be used to check encryption, it’s not the most automated or scalable solution.
SSL encryption for in-transit data (e.g., for the load balancer and Lambda to RDS communication) does not address encryption at rest, which is the core issue. The solution is focused on securing data during transmission, but it does not address encryption for data stored in S3, EBS, or RDS at rest.
Enabling SSE encryption on S3, EBS, and RDS ensures encryption at rest for all relevant data. Storing RDS credentials in EC2 Parameter Store is a good practice for security. The policy on the S3 bucket to deny unencrypted puts is an effective way to enforce encryption, and AWS Config rules ensure compliance with encryption requirements for S3, EBS, and RDS. This solution meets the encryption at rest requirement with minimal operational overhead and includes monitoring for future violations.
I categorize that the answer is:
Enable SSE encryption on the S3 buckets, EBS volumes, and the RDS database. Store RDS credentials in EC2 Parameter Store. Enable a policy on the S3 bucket to deny unencrypted puts. Set up AWS Config rules to periodically check for non-encrypted S3 objects and EBS volumes, and to ensure that RDS storage is encrypted.