Increasing Your Security Posture when Using Amazon S3
The course is part of these learning pathsSee 1 more
This course has been designed to introduce you to the different security controls and methods that have been built into Amazon S3 to protect your data and enhance your overall security posture. You will learn about resource ownership, access control policies, S3 Access Points, Access Analyzer, and how to use Cross Origin Resource Sharing (CORS).
If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Understand resource ownership in Amazon S3
- Use policies to control access
- Scale access to shared buckets with S3 Access Points
- Use Access Analyzer to monitor access to buckets
- Learn what Cross Origin Resource Sharing (CORS) is and how to use it
This course is intended for anyone who is responsible for securing, designing, and managing Amazon S3, or who simply wants to learn more about security in Amazon S3.
To get the most out of this course, you should have a basic understanding of Amazon S3. It's also recommended that you have a solid understanding of AWS IAM policy syntax and structure.
Hello and welcome to this lecture which will look at S3 access points and how they can be used to share buckets at scale with ease. A big use case of using Amazon S3 is to store huge datasets of data that can be shared and accessed by different services, applications, and teams.
Managing access to this data through the use of IAM policies, bucket policies, and ACLs can lead to an administrative burden when working with access at scale, where each requester might require different permissions to your data, which can lead to large policies which can be confusing to decipher.
To help alleviate this issue, AWS released Amazon S3 access points, which helped to simplify the management of controlling and managing shared data at scale on S3. And S3 access point can be created configured and attached to a single bucket.
You can't use the same access points across multiple buckets, but you can have multiple access points attached to a single bucket. This allows you to create a different access point, each with its own set of permissions for each application or team that requires access to your shared bucket where your data resides.
Access Points only allow you to perform object operations only, for example, S3 GetObject and S3 PutObject. But it's not possible to use bucket operations, such as S3 DeleteBucket. Permissions assigned to each S3 access point work in conjunction with the underlying bucket policy, as I will explain shortly, and allow you to configure different permissions for different access points.
As a part of the access point configuration, you can decide if you only want to accept requests from a specific VPC, and therefore restrict access to your own private network. Alternatively, you can allow access from anywhere outside of your VPC.
If you do not need to open up access to your bucket to those outside of your VPC, so essentially public access, then you can configure different settings to restrict that public access for your access point. By default, for all newly created access points, all public access is blocked. In the next lecture, I will be discussing public access settings in detail.
One important point to note is that whatever controls and restrictions you configure for an access point, it will not affect any other access behavior from other controls you already have in place on the bucket. So your access point restrictions effect only those connections to your bucket that are accessed via the access point.
Another configurable and optional element of an access point is the Access Point Policy. And this allows you to add a JSON policy to define permissions when using the access point. When granting permissions within the access point policy, they can only be as permissive as the associated underlying bucket policy allows. This means that if the user Stuart was given permissions of S3 PutObject with an access policy, then the underlying bucket policy would also need to grant your access of S3 PutObjects. As a result, if you're going to use access points to help you maintain security at scale for your shared data set, then it is best to add a policy to the bucket to delegate access control to the access points.
The bucket policies shown here will allow full access to any access point associated with the bucket owners account to the S3 deepdive bucket and it's objects. As a result all access to this bucket can now be determined by the access policies that are attached to it.
Much like the S3 buckets access points also have an Amazon Resource Name an ARN depicting the region account number and access point name. As a result, it's not possible to have two access points with the same name in the same region.
Once you have created an access point for your bucket with predefined security controls, you can connect to your bucket access point via the AWS Management Console, AWS SDKs or the S3 REST APIs.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.