{"id":25383,"date":"2018-10-16T20:36:49","date_gmt":"2018-10-16T16:36:49","guid":{"rendered":"https:\/\/www.msp360.com\/resources\/?p=25383"},"modified":"2024-02-13T13:47:20","modified_gmt":"2024-02-13T09:47:20","slug":"aws-iam-policy","status":"publish","type":"post","link":"https:\/\/www.msp360.com\/resources\/blog\/aws-iam-policy\/","title":{"rendered":"AWS Security In-Depth Part 2: Basics of IAM Policies"},"content":{"rendered":"<p>This is the second in a three-part series on Amazon S3 Security In-Depth. <a href=\"https:\/\/www.msp360.com\/resources\/blog\/s3-access-control-tools\/\">In Part I of this series, we discussed the different mechanisms you can use to allow access to your Amazon S3 buckets and objects<\/a>. In Part II, we will take a deeper look at managing access to your S3 resources using AWS Identity and Access Management (IAM).<!--more--><\/p>\n<p>When thinking about IAM, there are two broad categories to consider: identities and <a href=\"https:\/\/www.msp360.com\/resources\/blog\/managing-iam-permissions-in-the-cloud-aws-vs-microsoft-azure-vs-google-cloud\/\">permissions<\/a>.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-25392 size-large\" src=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/scheme-2-1024x541.png\" alt=\"AWS Security: AWS IAM\" width=\"625\" height=\"330\" srcset=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/scheme-2-1024x541.png 1024w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/scheme-2-300x158.png 300w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/scheme-2-768x406.png 768w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/scheme-2-624x330.png 624w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/scheme-2.png 1443w\" sizes=\"auto, (max-width: 625px) 100vw, 625px\" \/><\/p>\n<p>Identities refer to the various mechanisms that AWS provides to identify who is requesting a particular AWS action, for authenticating that person or entity, and for organizing similar entities into groups. This topic includes <a href=\"https:\/\/www.msp360.com\/resources\/blog\/backup-with-iam-users\/\">IAM users<\/a> and groups, credentials, and roles. We will cover more about best practices for managing IAM identities in Part III of this series.<\/p>\n<p>Permissions refer to what a particular identity is allowed to do in the AWS account. Permissions are managed by writing identity-based policies, which are collections of statements. Writing identity-based policies within IAM is the main focus of this Part II of our series. Identity-based policies are used mostly within AWS Identity and Access Management (IAM), so we will refer to them as IAM policies throughout this post. However, the same syntax in IAM policies is also used for S3 bucket policies that were discussed in the previous part in this series.<\/p>\n<div class=\"call-to-action\">\n<div class=\"call-to-action__left\" style=\"width: 70%;\">\n<div class=\"call-to-action__tag\">FREE WHITEPAPER<\/div>\n<div class=\"call-to-action__title\">Mastering AWS IAM for Amazon S3<\/div>\n<div class=\"call-to-action__text\">Learn how to effectively manage the security of your Amazon S3 account to protect your and your clients' data<\/div>\n<!--HubSpot Call-to-Action Code --><span class=\"hs-cta-wrapper hs-cta-deferred\" id=\"hs-cta-wrapper-9120adb3-1267-4129-ad5a-d8f06b87d969\" data-portal=\"5442029\" data-id=\"9120adb3-1267-4129-ad5a-d8f06b87d969\"><span class=\"hs-cta-node hs-cta-9120adb3-1267-4129-ad5a-d8f06b87d969\" id=\"hs-cta-9120adb3-1267-4129-ad5a-d8f06b87d969\"><!--[if lte IE 8]><div id=\"hs-cta-ie-element\"><\/div><![endif]--><a href=\"https:\/\/cta-redirect.hubspot.com\/cta\/redirect\/5442029\/9120adb3-1267-4129-ad5a-d8f06b87d969\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" class=\"hs-cta-img\" id=\"hs-cta-img-9120adb3-1267-4129-ad5a-d8f06b87d969\" style=\"border-width:0px;\" src=\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/9120adb3-1267-4129-ad5a-d8f06b87d969.png\" alt=\"CTA\"><\/a><\/span><\/span><!-- end HubSpot Call-to-Action Code -->\n<\/div>\n<div class=\"call-to-action__right\" style=\"width: 30%;\"><img decoding=\"async\" src=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2019\/07\/Mastering-AWS-IAM-for-Amazon-S3.png\" alt=\"WP icon\" \/><\/div>\n<\/div>\n<p>In this post, we\u2019ll cover:<\/p>\n<ul>\n<li>The basics of IAM policies and statements, including a breakdown of the important elements;<\/li>\n<li>An example walkthrough of an IAM policy with multiple statements;<\/li>\n<li>Best practices for writing and managing IAM statements.<\/li>\n<\/ul>\n<div class=\"table-of-content \">\n\t\t\t\t<p>Table of Contents<\/p>\n\t\t\t\t<ul><\/ul>\n\t\t\t\t<\/div>\n<h2>AWS IAM Policies and Statements<\/h2>\n<p>IAM is an AWS service for managing both authentication and authorization in determining who can access which resources in your AWS account. At the core of IAM\u2019s authorization system is an IAM policy.<\/p>\n<p>Let\u2019s take a look at the example below of an IAM policy being created in the AWS console.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-25385 size-large\" src=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image4-1-1024x504.png\" alt=\"AWS console\" width=\"625\" height=\"308\" srcset=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image4-1-1024x504.png 1024w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image4-1-300x148.png 300w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image4-1-768x378.png 768w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image4-1-624x307.png 624w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image4-1.png 1267w\" sizes=\"auto, (max-width: 625px) 100vw, 625px\" \/><\/p>\n<p>The entire document from lines 1-15 is the IAM policy. An IAM policy is a JSON document with an optional \u201cVersion\u201d key plus a \u201cStatement\u201d key. The value of the \u201cStatement\u201d key is an array of IAM statements.<\/p>\n<p>There are two IAM statements in this example -- one is from lines 4-8, and the other is from lines 9-13. There is no limit on the number of IAM statements in an IAM policy, though there are limits on the number of characters in an IAM policy. The number of characters varies from 2,048 characters to 10,240 characters depending on the type of policy.<\/p>\n<p>There are three critical elements to an IAM statement. They are:<\/p>\n<ul>\n<li>Action<\/li>\n<li>Resource<\/li>\n<li>Effect<\/li>\n<\/ul>\n<p>We\u2019ll take a look at each of these separately.<\/p>\n<h3>IAM Statement Elements: Action<\/h3>\n<p>Action describes the API actions that the statement affects. Action is in the form of \u201c&lt;resource&gt;:&lt;verb&gt;\u201d, where the resource is a particular AWS service (e.g., s3, ec2, or dynamodb) and the verb is a particular action to take within that service (e.g. GetObject or CreateBucket). There are <a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/list_amazons3.html#amazons3-actions-as-permissions\" target=\"_blank\" rel=\"noopener noreferrer\">51 different actions within S3 alone<\/a>. When writing IAM statements for S3 access, some of the popular actions you will use are:<\/p>\n<ul>\n<li>s3:GetObject: For reading an object on S3;<\/li>\n<li>s3:PutObject: For writing an object to S3;<\/li>\n<li>s3:ListBucket: For reading the objects in an S3 bucket;<\/li>\n<li>s3:ListAllMyBuckets: For listing all of the S3 buckets in your AWS account.<\/li>\n<\/ul>\n<p>When writing actions, you can use an asterisk to act as a wildcard on your action. You can use the wildcard at the beginning, middle, or end of your action, or as the entire action if you want to write a statement about all actions. For example, each of the following is a valid action:<\/p>\n<ul>\n<li>s3:Get*: This would affect all <a href=\"https:\/\/www.msp360.com\/resources\/blog\/how-to-give-user-access-to-an-s3-folder\/\">S3 actions<\/a> that start with \u201cGet\u201d, such as \u201cGetObject\u201d, \u201cGetBucketPolicy\u201d, and \u201cGetBucketLocation\u201d.s3:*: This would affect all actions within the S3 service.*: This would affect all API actions across AWS, including all actions in S3 but also all actions in EC2, SQS, DynamoDB, etc.<\/li>\n<\/ul>\n<blockquote><p>You should be careful when using wildcards in your Actions to avoid unintentionally granting broad access. Check out the \u201cBe Careful with Wildcards\u201d piece in the Best Practices section below.<\/p><\/blockquote>\n<h3>IAM Statement Elements: Resource<\/h3>\n<p>The second critical part of an IAM statement is the Resource. \u00a0The resource element describes the AWS resources to which the statement applies.<\/p>\n<p>Every AWS resource is given an <a href=\"https:\/\/docs.aws.amazon.com\/general\/latest\/gr\/aws-arns-and-namespaces.html\" target=\"_blank\" rel=\"noopener noreferrer\">Amazon Resource Name<\/a>, or ARN. This ARN uniquely identifies a single AWS resource across all AWS accounts. An ARN is structured into 6 parts, each separated by a colon. As you move from left to right, each part gets more specific about the particular resource it identifies.<\/p>\n<p>The general structure is:<\/p>\n<div class=\"perfect-pullquote vcard pullquote-align-full pullquote-border-placement-left\"><blockquote><p>arn:partition:service:region:account-id:resource<\/p><\/blockquote><\/div>\n<p>Let\u2019s look at these pieces individually:<\/p>\n<ol>\n<li>arn: The first part is always \u201carn\u201d, regardless of the resource type.<\/li>\n<li>partition: The second part describes the partition of AWS you\u2019re using. This is usually \u201caws\u201d, but it may be different if you\u2019re using special regions of AWS, such as GovCloud (\u201caws-us-gov\u201d) or the China region (\u201caws-cn\u201d).<\/li>\n<li>service: The third part is the service you\u2019re using within AWS, such as \u201cs3\u201d, \u201cec2\u201d, or \u201csqs\u201d.<\/li>\n<li>region: The fourth part is the AWS region you\u2019re using if applicable. As of September 2018, AWS has 18 regions around the world, such as \u201cus-east-1\u201d for the Northern Virginia region in the United States, or \u201ceu-central-1\u201d for the Frankfurt, Germany region. For S3 resources, the region is not included in the ARN.<\/li>\n<li>account id: The fifth part is the account ID of the AWS account that owns the resource. For S3 resources, the account id is not included in the ARN.<\/li>\n<li>resource: The sixth and final part of the ARN is the resource name. This could be the name of an S3 bucket, an <a href=\"https:\/\/www.msp360.com\/resources\/blog\/ec2-instance-types\/\">EC2 instance<\/a> id, or an SQS queue name. Depending on the AWS service, the resource name may include a path to further identify a resource.<\/li>\n<\/ol>\n<p>Below are examples of ARNs for an S3 bucket, an EC2 instance, and an SQS queue, respectively.<\/p>\n<ul>\n<li>arn:aws:s3:::my_bucket<\/li>\n<li>arn:aws:ec2:us-east-1:123456789012:instance\/i-1234567890abcdef0<\/li>\n<li>arn:aws:sqs:us-east-1:123456789012:queue1<\/li>\n<\/ul>\n<p>Notice how the S3 bucket does not have a value for the region or account id. This is because S3 bucket names are globally unique and thus do not need region or account identifiers.<\/p>\n<p>One important note about S3 ARNs -- there\u2019s a key distinction between bucket resources and object resources. If you want to specify an S3 object, you must include a \u201c\/\u201d in the resource name to indicate the bucket and the object. For example, if you have a bucket named \u201cmy_bucket\u201d with a single object named \u201clogs.txt\u201d, the resource for the bucket would be \u201carn:aws:s3:::my_bucket\u201d, while the resource for the object would be \u201carn:aws:s3:::my_bucket\/logs.txt\u201d.<\/p>\n<p>When writing an IAM statement, you must specify one or more resources to which the statement will apply. This allows you to narrowly tailor your IAM statements -- one statement could provide broader permissions to a wide range of resources, while another statement could grant narrow permissions to one or two protected resources.<\/p>\n<h3>IAM Statement Elements: Effect<\/h3>\n<p>The final element required element of an IAM statement is the effect. Before looking into the effect, let\u2019s review the <a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/intro-structure.html#intro-structure-authorization\" target=\"_blank\" rel=\"noopener noreferrer\">authorization flow in IAM<\/a>.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-25386 size-full\" src=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/block-scheme.png\" alt=\"AWS authorization flow\" width=\"651\" height=\"476\" srcset=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/block-scheme.png 651w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/block-scheme-300x219.png 300w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/block-scheme-624x456.png 624w\" sizes=\"auto, (max-width: 651px) 100vw, 651px\" \/><\/p>\n<p>First, all API requests are denied by default. If you make a request that is not authenticated, it will be denied. An API request may be allowed if there is a specific statement that allows the API request for the requesting user. Finally, a request will be denied if there is a specific statement that denies the API request for the requesting user, even in the face of a statement that purports to allow the request.<\/p>\n<p>With this authorization flow in mind, let\u2019s return to the \u201cEffect\u201d portion of an IAM statement. The value for the \u201cEffect\u201d property can be \u201cAllow\u201d or \u201cDeny\u201d. A value of \u201cAllow\u201d will give the attached identity the ability to make the API request on the requested resources in the statement. A value of \u201cDeny\u201d will strictly deny the API request on the resources in the statement.<\/p>\n<p>In the next section, we\u2019ll put all of the elements together to show you how to write multiple IAM statements in an IAM policy.<\/p>\n<h3>Putting it all together: Writing IAM policies<\/h3>\n<p>Now that we know the basics of IAM statements, let\u2019s write our first IAM policy.<\/p>\n<p>Imagine we have the following scenario. We own an S3 bucket called \u201cMSP360-examples\u201d. We want to allow one of our users to list all of the objects in the bucket. We also want the user to generally be able to read and write freely to the bucket. However, there is a prefix of \u201csecrets\/\u201d in the bucket that contains sensitive information. We do not want the user to be able to read or write in the \u201csecrets\/\u201d prefix.<\/p>\n<p>You can use the AWS console, the AWS CLI, or numerous infrastructure-as-code tools to manage your IAM permissions. I\u2019m going to use the Access Manager built into the <a href=\"https:\/\/www.msp360.com\/explorer\/\">MSP360 Explorer<\/a> as it has an easy wizard for generating IAM statements.<\/p>\n<p>To manage IAM within MSP360 Explorer, click the \u201cAccess Manager\u201d button in the toolbar.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-25387 size-large\" src=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image2-1-1024x154.png\" alt=\"manage IAM within MSP360 Explorer\" width=\"625\" height=\"94\" srcset=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image2-1-1024x154.png 1024w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image2-1-300x45.png 300w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image2-1-768x115.png 768w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image2-1-624x94.png 624w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image2-1.png 1172w\" sizes=\"auto, (max-width: 625px) 100vw, 625px\" \/><\/p>\n<p>As we break down our needs, we can think about three statements for our policy:<\/p>\n<ul>\n<li>A statement to allow listing the objects in a bucket;<\/li>\n<li>A statement to allow read &amp; write access in the bucket;<\/li>\n<li>A statement to deny read and write access to objects that start with \u201csecrets\/*\u201d.<\/li>\n<\/ul>\n<p>We can see these three statements in the following policy in MSP360\u2019s Access Manager:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-25388 size-full\" src=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image3-1.png\" alt=\"MSP360\u2019s Access Manager statement\" width=\"788\" height=\"675\" srcset=\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image3-1.png 788w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image3-1-300x257.png 300w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image3-1-768x658.png 768w, https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/10\/image3-1-624x535.png 624w\" sizes=\"auto, (max-width: 788px) 100vw, 788px\" \/><\/p>\n<p>The text version of the IAM statement is as follows:<\/p>\n<pre>{\r\n  \"Statement\": [\r\n    {\r\n      \"Effect\": \"Allow\",\r\n      \"Action\": \"s3:ListBucket\",\r\n      \"Resource\": \"arn:aws:s3:::cloudberry-examples\",\r\n      \"Condition\": {}\r\n    },\r\n    {\r\n      \"Effect\": \"Allow\",\r\n      \"Action\": [\r\n        \"s3:GetObject\",\r\n        \"s3:PutObject\"\r\n      ],\r\n      \"Resource\": \"arn:aws:s3:::cloudberry-examples\/*\",\r\n      \"Condition\": {}\r\n    },\r\n    {\r\n      \"Effect\": \"Deny\",\r\n      \"Action\": [\r\n        \"s3:GetObject\",\r\n        \"s3:PutObject\"\r\n      ],\r\n      \"Resource\": \"arn:aws:s3:::cloudberry-examples\/secrets\/*\",\r\n      \"Condition\": {}\r\n    }\r\n  ]\r\n}\r\n<\/pre>\n<p>In the first statement, we allow access to the \u201cs3:ListBucket\u201d action on our \u201cMSP360-examples\u201d bucket resource. In the second statement, we allow access for the \u201cs3:GetObject\u201d and \u201cs3:PutObject\u201d actions on all objects in the \u201cMSP360-examples\u201d bucket. Notice how we indicated that it applied to the objects in the bucket by including a \u201c\/\u201d separator at the end of the resource name, then using an asterisk to indicate it\u2019s a wildcard.<\/p>\n<p>Finally, the last statement uses the \u201cDeny\u201d effect to explicitly deny \u201cs3:GetObject\u201d and \u201cs3:PutObject\u201d actions on all objects in the \u201csecrets\/\u201d prefix in our bucket. Note that this explicit<br \/>\n\u201cDeny\u201d overrides the permissions granted in the previous statement.<\/p>\n<p>In this example, you can see how you can write multiple statements in a single IAM policy. You also can see how an explicit Deny of a particular action can override a separate statement that Allows the same action.<\/p>\n<h2>S3 IAM Permission Best Practices<\/h2>\n<p>Now that we know the basics of IAM policies and statements, let\u2019s cover a few of the best practices.<\/p>\n<p>Before we dive into specific recommendations, the first and most important practice is to follow the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Principle_of_least_privilege\" target=\"_blank\" rel=\"noopener noreferrer\">Principle of Least Privilege<\/a>. This is a general best practice across information security in which a particular user should be given only the privileges which are required to perform its given function. When applied to S3 policies, it means don\u2019t give a user read and write permissions when only read permissions are needed and don\u2019t give access to an entire bucket if only a specific prefix is needed.<\/p>\n<p>With this general principle in mind, here are a few additional tips.<\/p>\n<h3>#1 Be Careful with Wildcards<\/h3>\n<p>You can use an asterisk -- \u201c*\u201d -- in the Action and Resource properties in your IAM statements. These asterisks may seem like an easy shortcut to quickly write your IAM statements, but they can easily create security holes.<\/p>\n<blockquote><p>Wildcard characters, such as * and ? can be used to provide the given action to all resources or items<\/p><\/blockquote>\n<p>I would avoid using wildcards in the Action property at all. It may be tempting to use \u201cs3:*\u201d to provide full access to S3, but, rarely, a user will need all of those permissions. There are only <a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/list_amazons3.html#amazons3-actions-as-permissions\" target=\"_blank\" rel=\"noopener noreferrer\">51 total actions within S3<\/a>, and only a few of them are relevant to most users. It\u2019s worth the extra time to be explicit about the actions you want to allow.<\/p>\n<p>In the Resources property, the story is more nuanced. If you are granting permissions on multiple objects in an S3 bucket, you will likely need to use a wildcard to specify a particular prefix that a user is allowed to access. It will be infeasible to list each of the specific objects that a user can access and would require frequent updates as new objects are added or deleted. For this reason, it is acceptable to use wildcards for specifying prefixes in S3 bucket resources. You should avoid using wildcards at any other part of the ARN, such as the bucket name.<\/p>\n<p>For example, using \u201carn:aws:s3:::cloudberry-examples\/uploads\/*\u201d to provide access to all objects under the \u201cuploads\/\u201d prefix is acceptable. Using \u201carn:aws:s3:::*\u201d to provide access to all S3 buckets in your account should be avoided.<\/p>\n<h3>#2 Split Bucket Statements from Object Statements<\/h3>\n<p>Each S3 action applies to either bucket resources or object resources.<\/p>\n<p>For example, the \u201cs3:ListBucket\u201d action applies to buckets only and allows a user to list all of the objects in the bucket. The \u201cs3:GetObject\u201d action applies to objects only and allows a user to read the content of an object and its associated metadata. AWS\u2019s <a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/list_amazons3.html#amazons3-actions-as-permissions\" target=\"_blank\" rel=\"noopener noreferrer\">list of S3 Actions<\/a> does a nice job of showing whether an action applies to buckets or objects.<\/p>\n<blockquote><p>When writing IAM policies, keep your bucket statements separate from your object statements. It will keep your statements narrowly tailored and will be easier to reason about the effects of making changes.<\/p><\/blockquote>\n<h3>#3 Use AWS Managed Policies<\/h3>\n<p>AWS provides <a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/access_policies_managed-vs-inline.html#aws-managed-policies\" target=\"_blank\" rel=\"noopener noreferrer\">AWS Managed Policies<\/a> which are policies created by AWS to fill a specific use case. Often you will need to provide some S3 access as part of using other AWS services, such as <a href=\"https:\/\/aws.amazon.com\/redshift\/\" target=\"_blank\" rel=\"noopener noreferrer\">Amazon Redshift<\/a> for data warehousing, <a href=\"https:\/\/aws.amazon.com\/sagemaker\/\" target=\"_blank\" rel=\"noopener noreferrer\">Amazon SageMaker<\/a> for machine learning, or <a href=\"https:\/\/aws.amazon.com\/lambda\/\" target=\"_blank\" rel=\"noopener noreferrer\">AWS Lambda<\/a> for event-driven compute. Using AWS managed policies with these services can help you get started quickly while still using least-privilege permissions.<\/p>\n<h2>Conclusion<\/h2>\n<p>Managing <a href=\"https:\/\/www.msp360.com\/resources\/blog\/how-to-give-user-access-to-an-s3-folder\/\">S3 permissions<\/a> correctly is vital, but it can be difficult to absorb all the different terminology when writing IAM policies. In this post, we explored the permissions side of IAM -- writing policies and statements and understanding the key elements of permission statements. After showing an example policy, we then discussed the best practices for writing S3 IAM statements.<\/p>\n<p>In the next part of this series, we will look at the identity aspect of IAM - authentication, users, groups, and roles.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This is the second in a three-part series on Amazon S3 Security In-Depth. In Part I of this series, we discussed the different mechanisms you can use to allow access to your Amazon S3 buckets and objects. In Part II, we will take a deeper look at managing access to your S3 resources using AWS [&hellip;]<\/p>\n","protected":false},"author":67,"featured_media":26036,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[877,885],"tags":[],"class_list":["post-25383","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-articles","category-other"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/25383","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/users\/67"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/comments?post=25383"}],"version-history":[{"count":5,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/25383\/revisions"}],"predecessor-version":[{"id":59037,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/25383\/revisions\/59037"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media\/26036"}],"wp:attachment":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media?parent=25383"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/categories?post=25383"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/tags?post=25383"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}