Information
Data in transit is data being accessed over the network, and therefore could be intercepted by someone else on the network or with access to the physical media the network uses. On an ethernet network, that could be someone with the ability to tap a cable, configure a switch to mirror traffic, or fool your client or a router into directing traffic to them before it moves on to the final destination.
Server-side encryption (SSE) is about data encryption at rest--that is, Amazon S3 encrypts your data at the object level as it writes it to disks in its data centers and decrypts it for you when you access it.
Amazon S3 offers 3 options of encrypting data at rest, depending on how you choose to manage the encryption keys:
* Use SSE with Amazon S3-Managed Keys
* Use SSE with AWS KMS-Managed Keys
* Use SSE with Customer-Provided Keys
At the time of object creation--that is, when you are uploading a new object or making a copy of an existing object--you can specify if you want Amazon S3 to encrypt your data by adding the "x-amz-server-side-encryptionheader" to the request. Set the value of the header to the encryption algorithm AES256 that Amazon S3 supports. Amazon S3 confirms that your object is stored using server-side encryption by returning the response header "x-amz-server-side-encryption".
No matter which of the three options you choose, you can create and attach a S3 bucket policy, that will deny any object creation S3 API (PUT Object, PUT Object - Copy, POST Object, Initiate Multipart Upload), if the request does not include the "x-amz-server-side-encryption" header requesting server-side encryption, and if the request was not done using SSL\TLS.
When it comes to data at rest, if kept unencrypted, there are a few threats that one can think of, especially when the data is stored in the cloud:
* the threat that attackers are able to compromise Amazon S3 and gain access to the data that is stored in the Amazon S3 buckets.
* the "insider threat" where a malicious or rogue administrator steals a physical disk drive or server that contains data a customer has in the Amazon S3 buckets.
* the threat that a government uses a subpoena or warrant to get access to a customer's data in Amazon S3 without their knowledge.
If data in transit is kept unencrypted:
* Malicious users may intercept or monitor plaintext data transmitting across unencrypted network and gain unauthorized access to that jeopardize the confidentiality of the sensitive data.
In all of these scenarios, encrypting data at rest and in transit, and properly managing the encryption keys can help mitigate the risk of unauthorized access to that data.
Solution
Perform the following to ensure all objects placed in S3 are encrypted in transit and at rest:
* Create a new file, add the following to it, and save it as policy.json:
{
"Version":"2012-10-17",
"Id":"PutObjPolicy",
"Statement":{
"Sid":"DenyUnEncryptedObjectUploads",
"Effect":"Deny",
"Principal":"*",
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::_<s3_bucket_name>_/*",
"Condition":{
"Null":{ "s3:x-amz-server-side-encryption":"true" },
"Bool": { "aws:SecureTransport": "false" }
}
}
}
* Attach the above bucket policy to each S3 bucket:
aws s3api put-bucket-policy --bucket _<s3_bucket_name>_ --policy file://policy.json