Currently my web app stores user-uploaded ID scans in S3. I am concerned about an eventual data leak.

The S3 bucket is encrypted with server-side encryption (AES-256) but I figure the next obvious risk is an attacker gaining access to the AWS account itself. I have secured the root account with 2FA but there are several user accounts which have full access to S3 still (such as a Travis CI account).

The solution I am thinking of is periodically moving the ID scans to a different source with client-side encryption (where only I know the private key). That way if a leak happens, there will be only a small amount of data leaked.

Is this a common practice or are there better solutions in this situation?

1 Answer 1


The common way to store these more sensitive documents is to encrypt them with KMS.

Unlike the AES-256 encryption (which AWS themselves claim to be slightly legacy), KMS encryption requires a separate permission to decrypt and encrypt the files.

Create a Customer Managed Customer-Master-Key(CMK) in KMS, and upload the files encrypting them with CMK in question (using the kms:Encrypt permission).

Then whatever needs to decrypt the files (e.g. a Lambda function etc), needs to have the kms:Decrypt permission on the CMK in question.

Travis can have access to the bucket, but can never access the content of the files, as it should never be granted the kms:Decrypt on the key.

CMKs cost a tiny amount of money, but generally worth-it if you're getting folks to upload IDs into your app.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .