Welcome to another vital blog on Security for "Data in transit". In this blog, we will see how to ensure & enforce data transfer(requests) from S3 aligns with encryption policy.
When I started my AWS learning journey, I started with S3. By then it sounded too fancy for me (although it is Simple Storage Services). Details just bounced off my head and I never understood what people might do with this feature(Well, I thought S3 as a feature, rather a service :-) )
So, with the current knowledge, AWS S3 is just like your windows file server where you can store your files of any type under folder structures but in S3 it is just called as buckets. I hope this sets the background for beginners who would give this a read
Now, as we can store any file, audio, video or any object under prefixed bucket structures, as per the AWS Shared Responsibility Model, we need to ensure the data held in S3 are encrypted, while being stored in S3(at rest) or while being served as web requests(at transit)
Basic S3 data security
For any data stored in S3, most basic aspect of security is to "Block Public Access" either at account level or at "Bucket" level.
For S3 data at rest
At-rest, the data can be encrypted using server-side or client-side encryption, using AWS KMS Keys
For S3 data at transit
At transit, we can ensure that the requests are SSL ( https for web requests)
Let us see, how this can be set at bucket level. It is simple to implement via policies at bucket level.
Step 1
In order to demonstrate the use case, I need S3 bucket with some data in there. So the creation is as below
Step 2
Now, for serving requests for the data in S3 bucket, we need to ensure that requests are from SSL only. For this, easiest way to ensure security are,
1)Define S3 bucket policy, and
2)Create AWS Config Rule "s3-bucket-ssl-requests-only"
Step 3
Followed to that, When I evaluate config rule "s3-bucket-ssl-requests-only", this rule identifies all buckets that doesn't have compliance against this rule. This is because, configuration was set to act against all S3 buckets. Hence, in the below screenshot, 2 buckets retained in the account are reported as "Non-compliant"
Step 4
Mean while, let me create S3 bucket policy, which will literally deny any action against this Bucket, without SSL (which is enforced using boolean evaluation "aws:SecureTransport":"false")
Now, when the AWS Config rule "s3-bucket-ssl-requests-only" is re-evaluated, the bucket in this use case isn't reported
Step 5
Next, look into the remediation added to the rule. Remediation could be "Automatic" or "Manual". For "Manual" remediation, there are relevant remediation tasks listed in the configuration setup for each rule, along with the option to "Create JIRA Issue" and "Publish SNS Notification". But for this use case, select "AWSConfigRemediation-RestrictBucketSSLRequestsOnly"
Step 6
Next, if "Re-evaluate" is executed for this Rule(s3-bucket-ssl-requests-only", we could see the resources reported as compliant and also has removed from "Non-compliant" state after remediation
Before Remediation
After Remediation
Why AWS Config Rule?
Well, the answer relies on the question. It is a RULE !!. What happens is, a rule once defined, it verifies & lists the resources as non-compliant. Identification is key, isn't it? Second part is Remediation. All rules can be added a remediation, which already is listed under the "Rule Configuration" section and it "Remediation" could be "Automatic or Manual"
Notes
1) S3 Bucket policy actions should be just "s3:*" if ssl requests only should be allowed to the s3 bucket
2) When the policy is defined for "aws:SecureTransport":"false", then bucket(s) aren't reported as non-compliant; Or else, s3 buckets are listed as non-compliant under the AWS Config Rule evaluation. The Manual remediation "AWSConfigRemediation:RestrictBucketSSLRequestsOnly" will create a policy to adhere to this rule and then the bucket(s) are compliant.
So here it is, to setup secure requests serving from S3 !!
Top comments (0)