AWS云计算技术架构探索系列之二-身份账户体系(IAM)

这篇具有很好参考价值的文章主要介绍了AWS云计算技术架构探索系列之二-身份账户体系(IAM)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、前言

       建立身份账户体系是我们上云的第一步,良好的账户体系设计,会为后续的管理带来极大的便捷性和扩展性,反之,则可能增加管理的复杂,以及账户使用的不安全。

     AWS设计了一套完备的身份账号体系,主要包括IAM(Identity and Access Management),以及Organizations,其中IAM,包括账号,用户组,用户,角色,策略等。其关系图如下:

aws根用户和iam用户,AWS,aws,云计算,IAM,架构,策略

  • 用户,用户是AWS的身份凭证,分为根用户和IAM用户。用户的识别包括用户名/密码,AK/SK。
  • 用户组,包含多个用户的组,方便用户策略的统一分配和管理。
  • 角色,定义了受信任实体的特定权限,且凭证在短期内有效。通俗的说,定义了A(受信实体)对于B(目标资源)有特定的权限(增删改查等动作),这个权限是通过短期凭证实现。
  • 策略,是对权限的定义,允许或者拒绝(Effect),对于哪些资源(resource),实施哪些动作(Action)。
  • 账户,即申请的AWS的账户,通过根用户管理其下所有IAM用户和资源,也是账单的承载单位。
  • 组织,对多个账号统一管理,包括整合账单和服务控制策略。

下面我来具体介绍:

二、用户和用户组

     用户是AWS的身份凭证,包括用户名/密码,AK/SK两种认证方式,用户名/密码用来登录控制台,AK/SK一般用户CLI,以及API访问。

     用户可以分为:

  •  根用户,一个账号默认有一个根用户,根用户作为账号的持有者,默认具备所有权限,类比管理系统的超级管理员。
  • IAM用户,根用户可以创建IAM用户,并为之设置策略,使其拥有相应的权限。
  • 联合用户,相对于AWS来说的第三方用户,比如公司系统的已有的用户,或者来自互联网提供商,如Facebook,Google等。这种用户模式,比较好的适配混合云的场景。

        对于只有几个人的小微企业,可能只需要根账户就能搞定一切。但是在大中企业中,技术岗位和人员有明确的分工,比如有应用开发者,数据库管理员,网络管理员,他们对不同资源有不同的权限要求,不可能将根用户给所有人的开放,此时就需要创建和分配不同的IAM用户,如下图所示:

aws根用户和iam用户,AWS,aws,云计算,IAM,架构,策略

      如果一个IAM用户的认证信息泄露,影响的范围仅在所分配的权限范围内,且可以通过根用户修改其登录凭证,及时止损。但是如果根用户认证信息泄露,那就可以随意删除和修改所有其他用户的认证信息以及权限,影响将非常大。

      那如何保护根用户信息呢,首先根用户只能掌握在少数账号管理人员手中,其他人是无法接触到的;其次,根用户启用MFA(Multi-Factor Authentication),它提供了额外的安全级别,可以通过购买第三方硬件(类似于银行的U盾),或者安装与 MFA 兼容的APP程序生成密钥。

     用户组是一组用户的集合,可以为组内的用户统一分配权限,方便用户的管理。

三、角色

      AWS的角色与传统的RBAC中的角色概念是不一样的,传统的RBAC中角色,是一组权限的集合,角色仅可以分配或者授权给某个用户。而AWS的角色首先也是一组权限的组合,同时还定义了受信任实体(即可分配的服务)。 比如:

        定义一个角色,EC2具有S3存储桶所有操作权限,受信任的实体就是"EC2服务",权限就是"S3存储桶所有操作权限"。当该角色分配给某个具体的EC2实例,该EC2实例就具备了S3存储桶的所有操作权限。

     角色的受信任实体可以有以下类型:

  1. AWS产品,如ec2,s3等。
  2. AWS账户,即其他的AWS账户。
  3. Web身份,Cognito 或任何 OpenID 提供商。
  4. SAML 2.0 身份联合。

     当角色授予给某个具体的受信任实体的实例后,该实例就具有了角色定义的权限。在实现过程,是通过调用STS( Security Token Service)的API,获取临时凭证,再通过临时凭证签署对AWS服务API调用。

   继续上面的例子, 其Role逻辑关系和实现过程,我用以下的图示表示:

aws根用户和iam用户,AWS,aws,云计算,IAM,架构,策略

 四、策略

       策略是权限的定义形式,AWS采用JSON表达式,如下:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::mybucket",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "10.0.0.1"
                }
            }
        }
    ]
}
  •  Effect,表示允许(Allow),拒绝(Deny)。
  • Action,表示对服务的具体操作类型。如样例中s3:*,表示对s3服务的所有操作。
  • Resource,表示具体的资源标识,如样例中,arn:aws:s3:::mybucket表示S3的具体存储桶。
  • Condition,表示附加的条件,如样例中,对源IP进行限制。

      其内容是, 允许或者拒绝(Effect),对于哪些资源(resource),实施哪些动作(Action)。当然AWS提供了策略生成器,可以通过配置的方式生成该文件。

    我们可以将一个或者多个策略附加给用户组,用户,角色。在策略定义以及执行的过程中,遵守以下原则:

  • 最小授权原则,所有策略的定义都应该遵循,在满足要求情况下,按照最小原则授权。
  • 拒绝优先原则,如果附加的多个策略有冲突,那么拒绝的策略优先。

对于附加用户组,用户,角色的策略,称之为基于身份的策略,该策略可以分为三种类型:

  • Amazon 托管策略,Amazon创建和托管的策略,该类型策略是无法修改的,并开放给所有账户,我们可以直接拿来用。
  • 客户托管策略,客户在自己的账号中创建和托管的策略,客户可以根据自己的需求,灵活定义策略,以便精确控制。
  • 内联策略,创建和管理的策略,直接嵌入在单个用户、组或角色中。

另外一种策略是附加在具体的资源上,称之为基于资源的策略。如下的策略就是附加在S3的DOC-EXAMPLE-BUCKET存储桶上其格式如下:

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddCannedAcl",
      "Effect":"Allow",
    "Principal": {"AWS": ["arn:aws:iam::111122223333:root","arn:aws:iam::444455556666:root"]},
      "Action":["s3:PutObject"],
      "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}}
    }
  ]
}

      与基于身份的策略相比较,基于资源策略的json表达式多了个Principal(委托人)字段,即该存储桶可以被两个账户实施PUT操作。

     基于资源策略都是内联策略,即在创建某个具体资源的时候附加的,并与之绑定。目前仅部分服务支持该类型策略,比如S3,SQS等。具体可以参见:

使用 IAM 的 Amazon 服务 - Amazon Identity and Access Management

那为什么要设计基于资源的策略呢?我们来看个场景。

aws根用户和iam用户,AWS,aws,云计算,IAM,架构,策略

     创建一个允许所有操作S3存储桶mybucket资源的策略,并分配给Role1,再将Role1附加到3个EC2上,这样这3个EC2就具备对S3存储桶mybucket所有操作权限。随着业务的调整,需求发生了变化,要求仅EC2 B能操作mybucket资源,其他两个不可以操作,如何实现呢?

    首先想到的是,将Role1角色从EC2 A,EC2 C上删掉,但是Role 1有可能不只是包含这一个策略,如果删掉了,会影响这两台实例对其他资源的权限。还可以将role 1分拆成两个,这种操作实际也很麻烦,role多了也不好管理和维护。此时就可以使用基于资源的策略,就能轻松的解决问题。

aws根用户和iam用户,AWS,aws,云计算,IAM,架构,策略

        在mybucket附加一个基于资源策略,拒绝EC2A,EC2C的操作,根据拒绝优先原则,策略叠加后,EC2 A,EC2C就无法访问。

五、账户

      账户是可以对所属资源进行管理,以及查看和管理账单信息,账户的持有者就是根用户,通过根用户实现对资源的管理。 

   当企业的规模比较小时,一个账户,多个IAM用户的模式就能满足资源管理的需求。但是当发展到一定规模,就会遇到管理瓶颈,以账户管理为例,主要有:

  1. 多个环境管理,有开发环境,测试环境,以及生产环境,这些环境的资源是隔离,权限也要隔离。同一个账户多IAM用户模式,很容易出现由于权限管控错误,导致生产事故的问题。
  2. 用户管理,员工离职或者入职,或者岗位变化等等,导致用户管理工作繁重。

针对这些问题,企业一般采用多身份账户体系策略,如下:

aws根用户和iam用户,AWS,aws,云计算,IAM,架构,策略

        每个环境创建一个对应账户,在该环境账户中,维护相应环境的资源,以及跨账户角色,允许身份账户对资源的访问。

   身份账户管理维护所有的IAM用户,通过分配可访问跨账户角色的策略,控制IAM对各个环境资源的访问权限。

     当某个员工加入,只需要在身份账户中创建一个IAM用户并分配策略,当该用户对访问的环境资源有需求变化时,通过变更策略即可搞定。这种多身份账户体系设计,即解决了各个环境的用户隔离,又通过对用户的统一管理,实现不同环境资源的访问。

六、组织

      当企业采用多账户体系策略时,就会涉及到多账户的管理,组织就是AWS提供管理多账户的服务,主要有以下功能:

1、整合账单,可以管理和支付所有成员账户的账号,同时也可以享受折扣优惠,降低成本。

2、服务控制策略(SCP),可以为所有的成员账户附加统一的服务策略,以便对成员账户管理。主要的是,这些策略对成员账户的根用户也生效,。

组织中,有且仅有一个管理账户,通过管理账户邀请成员账户加入。

七、总结

      本篇中系统的介绍了AWS身份账户体系的内容。主要包括用户,用户组,角色,策略,账户以及组织,其相关的知识点,通过以下的表格总结

名称 定义 核心内容
用户 用户是AWS的身份凭证

1、分为根用户,IAM用户,联合用户

2、根用户具备所有的权限,需要重点关注其信息安全,采用MFA机制

3、根据对权限不同要求,创建不同IAM用户

用户组 多个用户的组 统一分配策略,方便用户的管理
角色 受信任实体的特定权限,且凭证在短期内有效

1、角色的定义,包括受信任实体,以及策略

2、受信任实体包括AWS产品,AWS账户,WEB身份,SAML 2.0 身份联合

策略 权限的定义

1、策略的内容,允许或者拒绝(Effect),对于哪些资源(resource),实施哪些动作(Action)

2、策略分为基于身份的策略和基于资源的策略

账户 申请的AWS的账户

1、对所属资源进行管理,以及查看和管理账单信息

2、账户的持有者就是根用户

3、多账户策略为最佳实践

组织 多账户的管理

1、整合账单功能

2、服务控制策略(SCP)功能

  附件:

AWS云计算技术架构探索系列之一-开篇

AWS云计算技术架构探索系列之二-身份账户体系(IAM)

AWS云计算技术架构探索系列之三-计算

AWS云计算技术架构探索系列之四-存储

AWS云计算技术架构探索系列之五-网络

AWS云计算技术架构探索系列之六-数据库文章来源地址https://www.toymoban.com/news/detail-833591.html

到了这里,关于AWS云计算技术架构探索系列之二-身份账户体系(IAM)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 电商商业平台技术架构系列教程之:电商平台云计算与弹性伸缩

    作者:禅与计算机程序设计艺术 随着互联网的飞速发展,电子商务的蓬勃发展,电商平台越来越成为推动互联网企业转型升级、提升竞争力的重要工具。其规模也越来越庞大,运营成本也越来越高。如何快速、低成本地处理海量订单、海量用户数据、大量实时业务数据、流量

    2024年02月08日
    浏览(37)
  • 电商系统架构设计系列(六):电商的「账户系统」设计要特别考虑哪些问题?

    上篇文章中,我给你留了一个思考题: 电商的账户系统,该如何设计? 今天这篇文章,我们来说一下电商的账户系统。 账户系统负责记录和管理用户账户的余额,这个余额就是每个用户临时存在电商的钱,来源可能是用户充值或者退货退款等多种途径。 账户系统的用途也非

    2024年02月16日
    浏览(40)
  • 《区块链原理与技术》学习笔记(四) ——以太坊的基本架构、账户模型和智能合约

    《区块链原理与技术》学习笔记 第四部分 三、以太坊 1. 以太坊简介 1.1 以太坊发展的阶段 1.2 以太坊与比特币对比 2. 以太坊的基本架构及原理 2.1 基本概念 2.2 状态转移 2.3 基本架构 3. 账户模型与转账 3.1 账户模型 4. 智能合约 4.1 合约账户与数据存储 4.2 驱动智能合约 以太坊

    2024年02月13日
    浏览(46)
  • Amazon云计算AWS之[1]基础存储架构Dynamo

    面向服务的Amazon平台基本架构 为了保证其稳定性,Amazon的系统采用 完全的分布式、去中心化的架构 作为底层存储架构的Dynamo也同样 采用无中心的模式 Dynamo只 支持简单的键/值(key/value)方式的数据存储 ,不支持复杂的查询 Dynamo中 存储的是数据值的原始形式 ,即按位存储

    2024年04月26日
    浏览(49)
  • AWS CI/CD之二:配置CodeDeploy

    前面一篇文章介绍了CodeBuild中构建一个Java的Maven项目。在这个基础上面,我们继续AWS CI/CD工作流构建之路。 这里主要是利用CodePipeline配置之前的CodeBuild项目,以便生产出需要部署的jar文件和CodeDeploy需要用到相关脚本文件。打开CodePipeline主页,开始创建管道,如下图: 这次创

    2024年01月20日
    浏览(39)
  • 向量数据库X云计算驱动大模型落地电商行业,Zilliz联合AWS探索并贡献成熟解决方案

    近日,由Zilliz 联合亚马逊云科技举办的【向量数据库 X 云计算 驱动大模型落地电商行业】活动在上海落幕,获得业内专业人士的广泛好评。 众所周知,大模型技术的发展正加速对千行万业的改革和重塑,向量数据库作为大模型的海量记忆体、云计算作为大模型的大算力平台

    2024年02月08日
    浏览(40)
  • 探索云原生时代:技术驱动的业务架构革新

    云原生技术正重塑IT领域,本文深度剖析了其发展历程、核心概念、生态系统及实践案例,展望未来趋势,揭示了这一技术如何引领企业转型与创新。 关注【TechLeadCloud】,分享互联网架构、云服务技术的全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理

    2024年03月22日
    浏览(71)
  • AWS多账户单点登录 IAM Identity Center(AWS SSO)

    需求场景 多个aws账户,登陆麻烦且不安全,SSO单点功能并且外部身份提供者 — 如果您要管理外部身份提供者(IdP)(例如 Okta 或 Active Directory)中的用户。 官方文档:https://docs.aws.amazon.com/zh_cn/singlesignon/latest/userguide/getting-started.html 最佳实践:https://aws.amazon.com/cn/blogs/securi

    2024年02月12日
    浏览(49)
  • 删除AWS绑定的信用卡账户

    前言 想使用aws的免费一年的ec2服务,所以必须先绑定信用卡,试了绑定储蓄卡还不行。绑定信用卡的时候只需要写卡号,卡片到期日期以及户头名即可。买上面的服务都不需要输入密码就可以购买。如果你用的免费服务,如果到期1年之后有其他费用,会悄无声息的扣款你的

    2024年02月12日
    浏览(56)
  • 【分布式技术专题】「分布式技术架构」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)

    Tomcat的总体结构从外到内进行分布,最大范围的服务容器是Server组件,Service服务组件(可以有多个同时存在),Connector(连接器)、Container(容器服务),其他组件:Jasper(Jasper解析)、Naming(命名服务)、Session(会话管理)、Logging(日志管理)、JMX(Java 管理器扩展服务

    2024年01月24日
    浏览(45)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包