Hello, and welcome to this lecture, which will highlight the key points made throughout the previous lectures of this course. I began discussing resource ownership, and here we learned that resources in S3 can be defined as buckets and objects. And by default, when a resource is created or uploaded to S3, the AWS account becomes the owner of that resource.

When an AWS account uploads an object within a bucket owned by a different account, the AWS account that performs the upload of that resource becomes the resource owner. And this behavior can be overridden by modifying the Object Ownership settings. This requires you to update the bucket policy to enforce all Amazon S3 PUT operations, include the bucket-owner-full-control canned ACL.

A canned ACL is a predefined grant that contains both grantees and permissions. Following this lecture, I then focused on using policies to control access. And in this lecture, I explained that access can be controlled using identity-based policies and resource-based policies.

Identity-based policies are attached to the IAM identity requiring the access, resource-based policies are associated with the resource rather than the identity, and resource-based policies for S3 can either be Access Control Lists or bucket policies. And a bucket policy is written in JSON.

You must specify a principle element when working with bucket policies, which defines the principal who is associated with the action and effect defined in the statement. Permissions defined within the statements of a bucket policy apply to the bucket and the objects that reside within the bucket.

S3 Access Control Lists allow you to control access to buckets in addition to specific objects within a bucket by groupings and AWS accounts. ACLs do not use a JSON format, and ACLs are far less granular than bucket policies and IAM policies, and they can be applied at the bucket level or the object level.

It's not possible to implicitly deny access using ACLs, and ACL permissions are based on the grantee, of which there are four, the bucket owner, everyone with public access, authenticated users, and the S3 Log delivery group.

ACL permissions for buckets include List, Write, Bucket ACL Read, and Bucket ACL Write. There is no write permission when working with object ACLs. And ACL permissions for objects include, read object, read object permissions, and write object permissions.

When using multiple policies, policy evaluation will review all of them together to determine the resulting access and will handle any permission conflict in accordance with the principle of least-privileged. An explicit Deny within any policy will deny access.

Following the lecture discussing permissions, I then looked at how you can scale access to shared buckets using access points. In this lecture, I covered the following points. S3 Access Points help to simplify the management of controlling and managing shared data at scale on S3.

An access point can only be attached to a single bucket. You can have multiple access points attached to a single bucket. Access points only allow you to perform object operations only. Permissions assigned to each S3 access point work in conjunction with the underlying bucket policy. And you can choose if you only want to accept requests from within your VPC for each access point and therefore restricting access to your own private network.

Alternatively, you can allow access from anywhere outside of your VPC. You can configure settings to restrict public access for your access point, and your access point restrictions affect only those connections to your bucket that are accessed via the access point. The access point policy allows you to define permissions when using the access point, and permissions can only be as permissive as the associated and underlying bucket policy.

It is recommended that you add a bucket policy to delegate access control to the access points. And it's not possible to have two access points within the same region. And you can connect to your bucket access point via the AWS Management Console, the AWS SDKs, or the S3 REST APIs.

Next up, I focused on how to protect your bucket from public access. And in this lecture, we learnt the following. When a bucket is created, it blocks public access by default. To change this setting you need to actively make changes to the permissions, and you can filter public access using different check boxes of access, and this allows you to allow some public access based on certain security controls and block others.

If you tried to allow any kind of public or cross-account access via the bucket policy or the ACL when Block all Public access setting was selected, then access would not be allowed. Following this lecture, I covered what the S3 Access Analyzer was designed for, and it closely related to the topic of the public access to your buckets.

The Access Analyzer is designed to alert you when any of your S3 buckets have been configured to allow either public access or buckets with access from other AWS accounts, including third-party AWS accounts. The Access Analyzer will identify the buckets affected and what level of access has been granted, and how that access is being given.

For any public buckets detected, you can take immediate action and with a single click, block public access to the bucket. Access Analyzer can save you from having overexposed buckets without you realizing, and also it updates its findings every 30 minutes. You can also download a report containing all the public information within that region and the public access or cross-account access that has being configured.

To use Access Analyzer within your regions, you must first create an account-level analyzer in IAM for each region that you want to review. In the final lecture, I looked at Cross-Origin Resource Sharing. And in this lecture, I discussed these points.

CORS allows specific resources on a web page to be requested from a different domain than its own. CORS support in S3 allows you to build client-side web applications and then access resources stored on S3. You must configure a CORS policy on the bucket for it to be used for CORS. And the element of the CORS policy includes, AllowedHeaders, which determines which headers are allowed in a preflight request through the Access-Control-Request-Headers header.

AllowedMethods, and this determines which operations can be carried out, for example, Put, Post, Delete, et cetera. AllowedOrigins. This determines which origin is allowed to carry out the CORS request. And ExposeHeaders, which defines a header in the response that is allowed to be made by customer applications. And the CORS policies can consist of one or more rules.

That now brings me to the end of this lecture and to the end of this course. And so you should now have a greater understanding of the different security controls that can be used within Amazon S3 to help you protect your data and buckets.

Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you can contact support@cloudacademy.com. Thank you for your time, and good luck with your continued learning of cloud computing, thank you.