We are implementing a static site hosted in S3 behind CloudFront with OAI. Both CloudFront and S3 can have logging enabled and I'm trying to determine whether it is necessary/practical to have logging enabled for both.
The only S3 access that would not come from CloudFront should be site deployments from our CI/CD pipeline which may still be useful to log. It may be useful for that exact reason to find any unintended access that was not from CloudFront or deployments too? The downside of course is that there would be two sets of access logs that would mostly overlap and adding to the monthly bill.
We will need to make a decision on this, but curious what the consensus is out there.
Thanks,
John
If you are using CloudFront with origin Access Identity , then your bucket can be private to the world.
Only the OAI and any other users you want can have read access and denying any others access to the s3 bucket/files inside the bucket which host the static website.
Which means user around the world need to mandatorily come via cloud front and direct access to s3 bucket and it's files will be denied.
So if you have implemented it right , you do not need to have s3 access logging enabled.
However the value of security is only know once we face a disaster , just weigh in and take a decision.
References :
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
Related
How to make aws s3 bucket public but restrict it to specific domain and localhost:3000 (for testing purpose).
Basically the s3 files will be accessed by the react.js website and we don't want the s3 files to be accessed outside the wwww.example.com domain and localhost:3000
Tried couple of things but doesn't seem to work.
Bucket policy - Not configured and not sure what to specify
Let me know the changes to be done to make it work.
How to make aws s3 bucket public but strict it to specific domain
Its not possible. At best you could Restricting access to a specific HTTP referer, but its not bullet proof. AWS writes:
Therefore, do not use aws:Referer to prevent unauthorized parties from making direct AWS requests.
You need proper authoritative mechanism and place your website behind some login screen, if you want to control access to it.
I am beginner in using AWS and currently I am hosting the assets for a web application using a microservices-based architecture on a S3 bucket. I want to allow the browsers using the application to access the assets. But all over the internet, it is always stated that it's highly recommended to prevent public access to the S3 bucket.
How can I do that without CloudFront, which I won't be using since all of the users are in the same region ?
You cant use S3 for static hosting and follow AWS' best practice around S3 buckets being private - you need to pick one.
The recommended structure is a private S3 bucket, with a public CloudFront distribution in front, and an origin access identity to control access to the origin bucket. Honestly, if you do configure your bucket with just GET access and enable static web hosting its not terrible, but CloudFront offers a couple of significant benefits over S3 static website hosting:-
Private S3, public CloudFront is a better default security stance and your less likely to make several common mistakes - hence why you see this guidance all over the internet.
Hosting files over S3+CloudFront will on average reduce latency and increase download speed compared to just S3 alone even in the same region. There are many edge locations interconnected by super high speed connections all over the world. End users connecting via edge locations effectively take a shorter route to the origin S3 bucket than going directly to the regional S3 bucket over the public internet.
Using CloudFront will probably work out cheaper than S3 alone.
Flexability - CloudFront can access mutiple buckets (or load balencers) and serve different paths from different origins.
If you do go down the CF route (i recomend you do), for the extra effort you get many benefits.
Bare in mind CF respects any caching headers associated with your objects in S3, or uses defaults set on the CF distribution. Be careful setting long cache times on files - you can clear the cache (called an invalidation) in CF - but end users browsers that have downloaded the file will also likely respect the cache headers (this is where you can use "cache busting" query strings...).
I have an s3 bucket in which I am currently blocking request access via Referrer. I know Referrer can be easily manipulated to get access of the object but I am not concerned much about that for now.
But now I want some images to get access to social media platforms. ( I need them as og:image ).
I can't find anyway to give access to that specific images to specific platforms.
The way you can implement that by using Cloudfront on top of S3, you need to enable origin identity access to prevent direct access to s3, so all links need to be accessed only through CloudFront.
then you can enable blocking based on referrer
https://aws.amazon.com/blogs/security/how-to-prevent-hotlinking-by-using-aws-waf-amazon-cloudfront-and-referer-checking/
Also cloudfront can have aws waf firewall to have even more advanced rules
First i was hardcoded my aws "accessKey" and "securityKey" in client side JS file, but it was very insecure so i read about "aws-cognito", and implemented new JS in following manner :
Still i am confused with one thing that can someone hack into my s3 with "AWS-cognito-identity-poolID" that is hard-coded ? Or any other security steps should i take ?
Thanks,
Jaikey
Definition of Hack
I am not sure what hacking means in the context of your question.
I assume that you actually mean "that anyone can do something different than uploading a file" which includes deleting or accessing objects inside your bucket.
Your solution
As Ninad already mentioned above, you can use your current approach by enabling "Enable access to unauthenticated identities" [1]. You will then need to create two roles of which one is for "unauthenticated users". You could grant that role PutObject permissions to the S3 bucket. This would allow everyone who visits your page to upload objects to the S3 bucket. I think that is what you intend and it is fine from a security point of view since the IdentityPoolId is a public value (i.e. not confidential).
Another solution
I guess, you do not need to use Amazon Cognito to achieve what you want. It is probably sufficient to add a bucket policy to S3 which grants permission for PutObject to everyone.
Is this secure?
However, I would not recommend to enable direct public write access to your S3 bucket.
If someone would abuse your website by spamming your upload form, you will incure S3 charges for put operations and data storage.
It would be a better approach to send the data through Amazon CloudFront and apply a WAF with rate-based rules [2] or implement a custom rate limiting service in front of your S3 upload. This would ensure that you can react appropriately upon malicious activity.
References
[1] https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html
[2] https://aws.amazon.com/about-aws/whats-new/2019/08/lower-threshold-for-aws-waf-rate-based-rules/
Yes, s3 bucket is secure if you are using through "AWS-Cognito-Identity-Pool" at client side, also enable CORS which allow action only from specific domain that ensure if someone try direct upload or list bucket, will get "access-denied".
Also make sure that you have set the file r/w credentials of the hard-coded access so that it can only be read by the local node and nobody else. By the way, the answer is always a yes, it is only a matter how much someone is willing to engage themselves to "hack". Follow what people said here, and you are safe.
Say you want to host a static web site on S3 :
You create a bucket with name your-website.com and set it up for web hosting;
You add a CNAME in your domain's zone file to point to your S3 bucket.
Great. Everything works fine when you visit http://your-website.com. But you don't want the raw/"naked" endpoint to be accessible.
Is there any setting in the bucket to disable direct access to http://your-website.com.s3-website.your-region.amazonaws.com ?
The reason is that if your web site is accessible both through http://your-website.com and http://your-website.com.s3-website.your-region.amazonaws.com would hurt your SEO (duplicate content)
You mention your major concern is SEO. For that purpose, you could use a other techniques, that are probably easier to implement than the one you initially asked about.
One of the main techniques to deal with duplicate content is to use rel=canonical, which is probably fairly easy to implement. For more information, see http://googlewebmastercentral.blogspot.com.br/2013/04/5-common-mistakes-with-relcanonical.html
If you insist on the need to disable access to the bucket unless the client connects through your CNAME, your best bet is to use CloudFront. You disable the S3 website hosting option on your bucket, make your S3 bucket private (i.e., remove bucket policies or ACLs allowing public read), create a CloudFront distribution, define your bucket as the origin, configure a CNAME on your distribution, change your DNS records to point to your distribution instead of bucket, create an Origin Access Identity (OAI) on your distribution and grant access to your bucket for that OAI. Phew.
By doing all this, there's no way for a user to access the content on your S3 bucket (unless they have an AK/SK with permissions to read the bucket, and send a signed request, obviously). The only way will be through your domain.
For more detail on Origin Access Identity, see http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html