IAM 策略类型:如何使用以及何时使用
AWS IAM Identity Policies
AWS Identity and Access Management (IAM) policies are JSON documents that define permissions and can be attached to IAM identities, which include users, groups, and roles. An IAM Identity policy dictates what actions an identity can perform, on which resources, and under what conditions.
Types of IAM Policies
Managed Policies - Predefined by AWS or created and managed by an administrator in your AWS account.
Inline Policies - Policies that are directly attached to a single IAM identity, providing a one-to-one relationship between policy and identity.
Use Case
Identity policies are often used to grant permission to perform actions on AWS resources. For example, an identity policy could allow a user to launch instances in Amazon EC2 or read files in an S3 bucket.
JSON Structure
An IAM policy is written in JSON and includes the following elements:
Version: The policy language version, usually "2012-10-17".
Statement: The core element, containing an array of individual statements.
Effect: Specifies whether the statement results in an ALLOW or DENY.
Action: Lists the actions permitted or denied by the policy.
Resource: Specifies the AWS resource(s) upon which the actions can take place.
Example
This policy allows the identity it is attached to list the contents of the specified S3 bucket.
AWS IAM Resource-based Policies
AWS IAM (Identity and Access Management) resource-based policies are attachments that allow you to specify access permissions directly on AWS resources, such as Amazon S3 buckets or AWS KMS keys. Unlike identity-based policies that attach to IAM users, groups, or roles to govern what actions those identities can perform, resource-based policies are attached to the resources themselves. This enables the resource to define who has access to it and what actions they are permitted to perform.
Resource-based policies are useful for granting cross-account access without the need to use roles or for specifying granular permissions directly on a resource. The most common type of resource-based policy is the Amazon S3 bucket policy, which can be used to publicly share objects in a bucket, grant access to another AWS account, or configure other advanced access scenarios.
Here is a simple structure that identifies the key elements:
For instance, a resource-based policy attached to an Amazon S3 bucket might grant read
access to a specific user or another AWS account, empowering them to retrieve objects stored in that bucket.
Use Case
One practical use case for a resource-based policy in AWS is to streamline cross-account access to an Amazon S3 bucket. For example, a company might store shared data in an S3 bucket that needs to be accessible by various departments, each operating under a separate AWS account. By attaching a resource-based policy directly to the S3 bucket, the bucket owner can grant specific permissions, such as s3:GetObject
, to IAM users, roles, or even entire AWS accounts from different departments. This method simplifies access management by eliminating the need for each account to create individual IAM roles for accessing the shared resource, thereby enhancing both efficiency and security in cross-account collaborations.
Example
Granting Cross-Account Read Access to an S3 Bucket
This example demonstrates how to create a resource-based policy (a bucket policy) to grant read-only access to an Amazon S3 bucket for a specific AWS account.
Key Elements:
Version: The version of the policy language; always include this to ensure the policy is interpreted correctly.
Effect: "Allow" grants the permissions described in the policy.
Principal: Identifies the AWS account, user, role, or service that receives the permission. In this case, it specifies the AWS account with ID
123456789012
.Action: Defines the specific actions allowed. Here,
s3:GetObject
permits retrieving objects from the bucket.Resource: Specifies the bucket and the objects within it that the policy applies to. The
*
wildcard means the policy applies to all objects in the bucketexample-bucket
.
AWS Service Control Policies (SCP)
AWS Service Control Policies (SCPs) are a type of policy that help manage permissions in AWS Organizations. SCPs allow administrators to set permission boundaries for all AWS accounts within an organization, or within specific Organizational Units (OUs), ensuring that accounts comply with the organization's access control policies.
Key Points:
Scope and Application: SCPs apply at the organizational, OU, or account level, not directly to users or roles. They limit permissions for all IAM entities (users and roles) within the targeted accounts.
Preventive Control: They act as a guardrail to prevent accounts from accessing resources or performing actions beyond the SCP's permissions, even if the entity's IAM policies would allow it.
Not Standalone: SCPs do not grant permissions but rather whitelist or blacklist permissions. An IAM entity must have permissions assigned via IAM policies, which are then filtered by SCPs.
Hierarchy: SCPs follow a hierarchy; if an SCP blocks an action at the higher level (e.g., organization level), lower levels (e.g., OU or account) cannot override this restriction.
Default SCP: By default, an AWS Organization has a FullAWSAccess SCP, allowing all actions across all accounts. It can be replaced or supplemented with more restrictive policies as needed.
Best Practices:
Least Privilege: Apply the principle of least privilege to SCPs, granting only the necessary permissions to meet your security and operational requirements.
Testing Policies: Before applying SCPs broadly, test them on a limited set of accounts or OUs to ensure they don't inadvertently block necessary actions.
Use Managed SCPs: AWS offers managed SCPs for common use cases, like preventing disabling of logging or deletion of certain resources. Using these can simplify policy management.
Monitor and Review: Regularly monitor access attempts that are denied due to SCPs, and review SCPs for necessary adjustments to adapt to changing organizational needs.
SCPs are a powerful tool in the AWS security and compliance toolkit, enabling organizations to enforce policy-based governance across their AWS environments effectively.
Session Policy
Session policies are not required, but they allow you to limit the scope of the fetched credentials without making changes to IAM roles. You can specify inline session policies right in your workflow file, or refer to an existing managed session policy by its ARN.
Inline session policies
An IAM policy in stringified JSON format that you want to use as an inline session policy. Depending on preferences, the JSON could be written on a single line like this:
Or we can have a nicely formatted JSON as well:
Managed session policies
The Amazon Resource Names (ARNs) of the IAM managed policies that you want to use as managed session policies. The policies must exist in the same account as the role. You can pass a single managed policy like this:
And we can pass multiple managed policies likes this:
参考资料
最后更新于