Secure Amazon S3

Learning Objectives

After completing this unit, you’ll be able to:

Explain the security features of Amazon S3.
Describe encryption on Amazon S3.
Distinguish between S3 bucket policies and AWS Identity and Access Management (IAM) policies.
Describe the function of versioning on Amazon S3.

You may be wondering: If all my objects can be accessed from anywhere, does that mean that everyone can access them? Does everyone have access to my cat photos?

Choose the Right Connectivity Option for Your Resources

Everything in Amazon S3 is private by default. This means that all S3 resources, such as buckets, folders, and objects can only be viewed by the user or AWS account that created that resource. Amazon S3 resources are all private and protected to begin with.

If you decide that you want everyone on the internet to see your cat photos, you can choose to make your buckets, folders, and objects public. Keep in mind that a public resource means that everyone on the internet can see it.

Most of the time, you don’t want your permissions to be all or nothing. Typically, you want to be more granular about the way you provide access to your resources.

Diagram shows three connectivity options for S3: default where only the owner has access to three video assets in a bucket and Anyone else is prohibited, Public where everyone has access, and Access Policy where granular permissions give the Owner and User A access but not User B.

To be more specific about who can do what with your S3 resources, Amazon S3 provides two main access management features: IAM policies and S3 bucket policies.

Understand IAM Policies

In AWS Identity and Access Management, you learned about creating and using IAM policies, and now you get to apply this to Amazon S3. When IAM policies are attached to IAM users, groups, and roles, the policies define which actions they can perform. IAM policies are not tied to any one AWS service and can be used to define access to nearly any AWS action.

You should use IAM policies for private buckets when:

You have many buckets with different permission requirements. Instead of defining many different S3 bucket policies, you can use IAM policies instead.
You want all policies to be in a centralized location. Using IAM policies allows you to manage all policy information in one location.

Understand S3 Bucket Policies

S3 bucket policies are similar to IAM policies, in that they are both defined using the same policy language in a JSON format. The difference is IAM policies are attached to users, groups, and roles, whereas S3 bucket policies are only attached to buckets. S3 bucket policies specify what actions are allowed or denied on the bucket.

For example, if you have a bucket called catphotobucket, you can attach an S3 bucket policy to it that allows another AWS account to put objects in that bucket.

Or if you wanted to allow anonymous viewers to read the objects in catphotobucket, then you can apply a policy to that bucket that allows anyone to read objects in the bucket using "Effect":Allow on the "Action:["s3:GetObject"]".

Here’s an example of what that S3 bucket policy might look like.

{
    "Version":"2012-10-17",
    "Statement":[
        {
            "Sid":"PublicRead",
            "Effect":"Allow",
            "Principal": "*",
            "Action":["s3:GetObject"],
            "Resource":["arn:aws:s3:::catphotobucket/*"]
        }
    ]
}

S3 Bucket policies can only be placed on buckets, and cannot be used for folders or objects. However, the policy that is placed on the bucket applies to every object in that bucket.

You should use S3 bucket policies when:

You need a simple way to do cross-account access to S3, without using IAM roles.
Your IAM policies bump up against the defined size limit. S3 bucket policies have a larger size limit.

Encrypt S3

Amazon S3 reinforces encryption in transit (as it travels to and from Amazon S3) and at rest. To protect data at rest, you can use:

Server-side encryption: This allows Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects.
Client-side encryption: Encrypt your data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and all related tools.

To encrypt in transit, you can use client-side encryption or Secure Sockets Layer (SSL).

Use Versioning to Preserve Objects

As you know, Amazon S3 identifies objects in part by using the object name. For example, when you upload a cat photo to S3, you may name the object cat.jpg and store it in a folder called cats. If you don’t use Amazon S3 versioning, anytime you upload an object called cat.jpg to the cats folder, it overwrites the original file.

This can be an issue for several reasons.

cat.jpg is a common name for a cat photo object. You or someone else who has access to that bucket might not have intended to overwrite it, and now that you have, you no longer have access to the original file.
You may want to preserve different versions of cat.jpg. Without versioning, if you wanted to create a new version of cat.jpg, you would need to upload the object and choose a different name for it. Having several objects all with slight differences in naming variations may cause confusion and clutter in your bucket.

So, what do you do? You use S3 versioning!

Versioning enables you to keep multiple versions of a single object in the same bucket. This allows you to preserve old versions of an object without having to use different naming constructs, in case you need to recover from accidental deletions, accidental overwrites, or even application failures. Let’s see how this works.

If you enable versioning for a bucket, Amazon S3 automatically generates a unique version ID for the object being stored. In one bucket, for example, you can have two objects with the same key, but different version IDs, such as catphoto.gif (version 111111) and catphoto.gif (version 121212).
Diagram showing two versions of an object named catphoto.gif with different version IDs.
Versioning-enabled buckets let you recover objects from accidental deletion or overwrite.

Deleting an object does not remove the object permanently. Instead, Amazon S3 puts a marker on the object that shows you tried to delete it. If you want to restore the object, you can remove this marker and it reinstates the object.
If you overwrite an object, it results in a new object version in the bucket. You still have access to previous versions of the object.

Understand Versioning States

Buckets can be in one of three states.

Unversioned (the default): No new or existing objects in the bucket have a version.
Versioning-enabled: This enables versioning for all objects in the bucket.
Versioning-suspended: This suspends versioning for new objects. All new objects in the bucket will not have a version. However, all existing objects keep their object versions.

The versioning state applies to all of the objects in that bucket. Keep in mind that storage costs are incurred for all objects in your bucket and all versions of those objects. To reduce your S3 bill, you may want to delete previous versions of your objects that are no longer in use.

Wrap Up

In this unit, you learned how to prevent unwanted access to S3 resources using access control, protect S3 data with encryption, prevent accidental overwrites and deletions with versioning. In the next unit, you learn how to take advantage of the many S3 storage classes.

도움말 검색