AWS IAM概念

A忆梦三年A

已于 2024-07-05 10:53:43 修改

阅读量812

点赞数 21

文章标签： aws 云计算

于 2024-06-04 17:09:34 首次发布

本文链接：https://blog.csdn.net/hyxhshl402/article/details/139443846

版权

定义

Amazon Identity and Access Management (IAM) 是一种 Web 服务，可以帮助您安全地控制对 Amazon 资源的访问。

IAM 代表“身份和访问管理”，它在 AWS 内提供了一个集中的控制中心，并与所有其他 AWS 服务集成。
IAM 是所有 AWS 资源的 GateKeeper 或安全卫士。
IAM 提供 MFA（多因素身份验证）支持，允许您在整个组织中设置自定义密码轮换策略。

工作原理

1、人类用户或应用程序使用其登录凭证与 Amazon 进行身份验证。通过匹配登录凭证与受 Amazon Web Services 账户信任的主体（IAM 用户、联合用户、IAM 角色或应用程序）来进行身份验证。
2、请求授予主体对资源的访问权限。访问权限是根据授权请求而授予的。
3、获得授权后，主体可以对您 Amazon Web Services 账户里的资源采取行动或执行操作。

术语

IAM 资源（Resource）：IAM 资源存储在 IAM 中。您可以在 IAM 中添加、编辑和从中将其移除。(策略、实例配置文件、OIDC提供商等)
IAM 身份（Identity）：可以在策略中获得授权以执行操作和访问资源的 IAM 资源。身份包括用户、组及角色。
IAM 实体（Entity）：Amazon 用于身份验证的 IAM 资源。在基于资源的策略中，可以将实体指定为一个主体。
主体：使用 Amazon Web Services 账户根用户、IAM 用户或 IAM 角色登录并向 Amazon 发出请求的人员或应用程序。主体包括联合身份用户和代入的角色。
人类用户：也称为人类身份；是应用程序的人员、管理员、开发人员、操作员和使用者。
工作负载：一系列资源和代码，它们可提供商业价值，如应用程序或后端过程。可能包括应用程序、操作工具和组件。

IAM 身份

用户：任何个人最终用户，例如员工、系统架构师、CTO 等。
组：具有共享权限的类似人员的任何集合，例如系统管理员、人力资源员工、财务团队等。其指定组中的每个用户都将继承为该组设置的权限。
角色：任何需要被授予权限才能完成其工作的软件服务，例如——AWS Lambda 需要对 S3 的写入权限，或者需要从 RDS MySQL 数据库读取权限的 EC2 实例队列。

IAM 策略

策略是用于授予或限制访问权限的记录规则集。
策略是用 JSON 编写的，您可以使用自定义策略来满足您的特定需求，也可以使用 AWS 设置的默认策略。
策略是 AWS 中的一个对象，当与身份或资源相关联时，它定义了其权限。AWS 在 IAM 委托人（用户或角色）发出请求时评估这些策略。
借助 IAM 策略，您可以通过创建策略并将它们附加到 IAM 身份（用户、用户组或角色）或 AWS 资源来管理 AWS 中的访问。

声明中的信息可能包含以下实体
版本 – 指定要使用的策略语言版本。作为最佳实践，请使用最新的 2012-10-17 版本。
声明 – 将此主要策略元素用作以下元素的容器。您可以在策略中包含多个声明。
Sid – 包括一个可选的语句 ID 以区分您的语句。
Effect – 使用 Allow 或 Deny 指示策略是允许还是拒绝访问。
委托人 – 如果您创建基于资源的策略，则必须指明您希望允许或拒绝访问的账户、用户、角色或联合身份用户。如果您要创建 IAM 权限策略以附加到用户或角色，则不能包含此元素。主体隐含为该用户或角色。
操作 – 包括策略允许或拒绝的操作列表。
资源 – 如果您创建 IAM 权限策略，则必须指定操作适用的资源列表。如果您创建基于资源的策略，则此元素是可选的。如果您不包含此元素，则应用该操作的资源就是附加该策略的资源。
条件 - 指定策略授予权限的情况。

  "Version": "2012-10-17",
  "Statement": [
    {//为角色FirstStatement授权变更密码
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {//为角色SecondStatement授权获取所有存储桶的列表
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {//为角色ThirdStatement授权对confidential-data S3桶的开头为List和Get所有权限
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}//通过MFA验证的角色才能操作
    }
  ]
}

IAM 中的优先级

明确拒绝：拒绝访问特定资源，并且该裁决不能被否决。AWS 检查适用于您的请求上下文的每项策略。如果单个权限策略包含拒绝操作，AWS 将拒绝整个请求并停止评估。这称为显式拒绝。

以允许对 Amazon S3 和一些其他服务执行所有 Amazon 操作，但拒绝访问 DOC-EXAMPLE-BUCKET1 S3 存储桶。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PermissionsBoundarySomeServices",
            "Effect": "Allow",
            "Action": [
                "cloudwatch:*",
                "dynamodb:*",
                "ec2:*",
                "s3:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "PermissionsBoundaryNoConfidentialBucket",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET1",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*"
            ]
        }
    ]
}

显式允许：只要没有关联的显式拒绝，就允许访问特定资源。（使用NotAction）

用户未使用 MFA 登录时拒绝其访问非 IAM 操作

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "DenyAllUsersNotUsingMFA",
        "Effect": "Deny",
        "NotAction": "iam:*",
        "Resource": "*",
        "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }]
}

默认拒绝（或隐式拒绝）：IAM 身份开始时没有资源访问权限。相反，必须授予访问权限。

单个帐户中请求的评估逻辑遵循以下一般规则：

默认情况下，所有请求都被拒绝。
任何权限策略中的显式允许会覆盖此默认值。
组织 SCP、IAM 权限边界或会话策略的存在会覆盖允许。
如果存在一种或多种这些策略类型，则它们都必须允许该请求。否则，它被隐式拒绝。
任何策略中的显式拒绝都会覆盖任何允许。

只有组织中的服务控制策略 (SCP) 才能限制授予 root 用户的权限。

IAM 策略类型

以下策略类型按从最常用到不常用的顺序列出，可在 AWS 中使用。

RBAC策略

IAM 中使用的传统授权模型称为基于角色的访问控制。
RBAC 根据用户的工作职能定义权限，在 Amazon 之外称为角色。在这里插入图片描述

ABAC策略

基于属性的访问权限控制是一种授权策略，这些属性被称为“标签”。
您可以将标签附加到 IAM 资源（包括 IAM 实体（用户和角色））以及 Amazon 资源。

在这里插入图片描述

相比传统 RBAC 模型，ABAC 具备以下优势：

ABAC 权限随着创新扩展。它不再需要管理员更新现有策略以允许对新资源的访问。
ABAC 需要较少的策略。
使用 ABAC，团队可以进行更改和扩展。新资源的权限根据属性自动授予。
使用 ABAC 可以实现精细权限。
通过 ABAC 使用来自您公司目录的员工属性。您可以配置 SAML 或 OIDC 提供者，以将会话标签传递给 Amazon。

权限边界

使用托管策略作为 IAM 实体（用户或角色）的权限边界。
该策略定义了基于身份的策略可以授予实体的最大权限，但不授予权限。
权限边界不定义基于资源的策略可以授予实体的最大权限。

假设名为 ShirleyRodriguez 的 IAM 用户应仅允许管理 Amazon S3、Amazon CloudWatch 和 Amazon EC2。
策略设置 ShirleyRodriguez 的最大权限作为 Amazon S3、CloudWatch 和 Amazon EC2 中的所有操作。Shirley 无法在任何其他服务（包括 IAM）中执行操作，即使她有一个允许这样做的权限策略也是如此。

一句话来说就是权限边界规定了实体（用户/角色）能使用的最大权限。

组织 SCP

使用 AWS Organizations 服务控制策略 (SCP) 定义组织或组织单位 (OU) 的账户成员的最大权限。
SCP 限制基于身份的策略或基于资源的策略授予账户内实体（用户或角色）的权限，但不授予权限。

一句话来说就是 SCP规定了组织或组织单位能使用的最大权限。

访问控制列表 (ACL)

使用 ACL 来控制其他账户中的哪些主体可以访问 ACL 附加到的资源。
ACL 类似于基于资源的策略，尽管它们是唯一不使用 JSON 策略文档结构的策略类型。
ACL 是向指定委托人授予权限的跨账户权限策略。
ACL 不能向同一账户中的实体授予权限。

IAM 密钥详细信息

IAM 是不受地域限制的全球AWS服务。任何用户、组、角色或策略都可以全局访问。
具有完全管理员访问权限的根账户是用于注册 AWS 的账户。因此，建议使用公司的官方电子邮件地址用于创建 AWS 账户。
当您授予新用户编程访问权限时，他们会获得一个访问密钥 ID 和一个秘密访问密钥 ID。访问密钥仅用于 AWS CLI 和开发工具包，因此您不能使用它们来访问控制台。
您不能嵌套 IAM 组。单个 IAM 用户可以属于多个组，但无法创建子组以将一个 IAM 组嵌入到另一个 IAM 组中。
借助 IAM 策略，您可以轻松添加标签，帮助定义谁可以访问哪些资源。这些标签随后用于通过特定的 IAM 策略控制访问。例如，生产和开发 EC2 实例可能会被这样标记。这将确保只能访问开发实例的人无法访问生产实例。