[ 云计算 | AWS ] IAM 详解以及如何在 AWS 中直接创建 IAM 账号

在这里插入图片描述

本章节主要介绍 IAM 相关知识点以及在 AWS 控制台窗口如何创建一台 Amazon IAM 账号。

一、什么是 IAM？

AWS Identity and Access Management (IAM) 是一种 Web 服务，可以帮助你安全地控制对 AWS 资源的访问。借助 IAM，你可以集中管理控制用户可访问哪些 AWS 资源的权限。可以使用 IAM 来控制谁通过了身份验证（准许登录）并获得授权（拥有权限）来使用资源。

IAM 是 Identity and Access Management 的缩写，即身份与访问管理，或称为身份管理与访问控制。

IAM 主要为了达到一个目的：让恰当的人或物，有恰当的权限，访问恰当的资源。其中“人或物”称为主体（Subject），“资源”称为客体（Object）。

传统的 IAM 一般包含如下几部分，常被称为4A或5A。

账号（Account）
认证（Authentication）
权限（Authorization）
应用（Application）
审计（Audit）

二、IAM 常见种类

在这里插入图片描述

2.1 EIAM

EIAM是 Employee Identity and Access Management 的缩写，指管理企业内部员工的IAM，主要解决员工使用的便捷性和企业管理的安全性相关问题。

在产品形态上，EIAM有以下特点：

需要集成企业的云应用、本地应用
需要集成不同的身份源
SSO和MFA很常用
不同企业所需的访问控制力度不同

2.2 CIAM

CIAM 是 Customer Identity and Access Management 的缩写，指管理企业外部客户/用户的IAM，主要解决用户数据的打通和开发成本与标准化相关问题。

在产品形态上，CIAM有以下特点：

在用户端常见到的是单点登录和授权登录
提供通用的组件给开发者直接使用
更强调高性能和高可用

2.3 云厂商 IAM

云厂商的IAM，有时称为RAM（Resource and Access Management），指管理企业云资源的 IAM，主要用于管理云资源的访问控制。

在产品形态上，云厂商IAM有以下特点：

强调授权的灵活性和企业管理的安全性
支持多种类型的账号进行认证或被调用
一般只关注管理自家的云资源

三、账号（Account）

账号是用户在系统中的数字化载体，用于标识用户并访问受保护的资源。一般每个系统都会有账号，且不同系统的账号数据结构各异。

针对账号模块，IAM 需要解决如下几个问题：

哪些账号/字段代表了用户？这些账号散落在哪里？（身份源）
我（IAM）如何将这些账号拿过来？（上游账号同步）
我（IAM）如何关联、映射、使用这些账号数据？（统一身份源）
哪些系统需要用到这些账号？我怎么把账号给它们？（下游账号同步）

三户模型

说到账户 这里要提一下 三户模型，并不是房子户型模型，其实以前我也不知道，后来研究学习才知道三户模型的来源，下面总结一下

三户模型最早是在增强型电信运营图（Enhanced Telecom Operations Map，eTOM）中提出，在电信行业中得到广泛使用。三户指客户（Customer）、用户（User）和账户(Account)。eTOM 引入是电信行业营销模型转向“以客户为中心”的理念而产生的成果。围绕客户建立用户和账户，这三个是相互关联的实体。近年来，金融行业也逐步接受和采用了三户模型。

在这里插入图片描述

三户的定义下如，供参考：

客户，指自然人或者法人。法人一般被称之为企业客户。如无特指，一般客户指个人客户。
用户，指通过注册的方式进入系统，使用系统提供的服务的实体，也称为登录账户，即用户在系统中登录凭证和个人信息。对应的，法人客户在系统中注册后，被称之为商户。
账户，这里特指支付账户，指用户在支付系统中用于交易的资金所有者权益的凭证。

四、认证（Authentication）

广义的认证是一种信用保证形式，指第三方公证机构对组织/个人的身份、能力、资质等的认可。

狭义的认证指的是证明“主体是谁”。IAM中的认证指的是狭义的认证，常见于主体申请访问资源时。

4.1 认证场景

IAM 中有三个主要的场景：

未认证的主体需要认证——登录
已认证的主体跳转到其他应用时自动认证——SSO，单点登录
已认证的主体访问敏感资源时需要二次认证——MFA，多因素认证

4.2 认证方式

身份鉴别的实质就是证明你就是你。宏观上讲，身份鉴别的方式有以下几类：

所知（What you know）：也就是通过只有你知道，而别人不知道的信息来验证你的身份。比如“天王盖地虎，宝塔镇河妖”这样的口谕，比如你的互联网邮箱的口令。在基于所知进行身份鉴别，除了平常要保管好“所知”之外，技术的关键还在于如何保证既能通过出示“所知”来证实自己身份，而这个“所知”又不会被窃取。

所有（What you have）：也就是通过只有你才持有的东西来验证你的是身份。比如：你持有的信用卡、身份证等。基于“所有”进行身份鉴别，首先要避免“所有“的丢失，同时鉴别技术要能防止“所有”被假冒。

所是（What you are）：也就是“天生具有”的东东来证实你的身份。比如指纹、人像、声纹、DNA等各种生物特征。基于“所是”进行身份鉴别，需特别关注一个问题，由于“所是”往往与生俱来，难以再造，因此，需特别防止在鉴别过程中泄露“所是”信息。

某种技术的复合运用，或者以上二者或三者的组合运用。认证方式和MFA息息相关，MFA（Multi-Factor Authentication，多因素认证）是指使用两种以上的认证来进行身份验证，以提高账号的安全性。

4.3 认证协议

认证协议主要用于在用户、业务系统、身份认证服务之间传递用户信息，告诉业务系统“此用户是谁”。

主流的认证协议/实现单点登录的方案有 Cookie、JWT、SAML、CAS、OIDC等，网上有很多资料，暂不赘述。

认证协议通常和单点登录息息相关，单点登录（Single Sign On，SSO）是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

4.4 认证源

认证源指的是用户在登录当前系统时，由第三方提供认证服务，系统信任第三方的认证结果。例如使用微信登录某APP，就是将微信作为认证源。

IAM 一般会根据场景提供 AD/LDAP、企业微信/钉钉、OA等不同的认证源方案。

五、授权（Authorization）

授权是将权力交付给用户或机构代为行使，此时使用户或机构获得访问资源的权限。

5.1 “授权”范围

我们以 RBAC 模型为例，授权其实要做三件事：

将操作和对象（也称资源）打包为权限，即图中的权限（PRMS，Pemission），包括操作（OPS，Operations）和对象（OBS，Objects）。
将权限分配给主体（狭义的授权），即图中的 Permission Assignment 和 User Assignment。
当主体访问资源时鉴权，鉴别用户的身份和判断权限。

在这里插入图片描述

(RBAC 模型)

5.2 权限分类

权限其实就是将操作和对象打包起来。根据不同场景、不同要求可以有不同的方案。

个人习惯将权限分为以下四种，控制的力度和精细度逐渐增加：

应用权限，控制主体能否访问某个应用，拥有权限就可以访问应用的所有内容，是最粗粒度的访问控制。

页面权限，控制页面层面的元素是否可见，包括页面、菜单、按钮等。做好页面权限一般可以满足企业内部大部分的需求。

操作权限，控制主体能否执行某个操作，例如可改新增、修改、删除等，一般和一个接口对应，在主体请求接口时判断。页面权限和操作权限也被统称为功能权限。

数据权限，控制数据的查询和展示，不同主体看到的数据不同，包括行权限和列权限。如果说功能权限是控制“能不能”，数据权限则是控制“有多少”。

5.3 权限模型

谈到授权，谈得最多的是权限模型。但需要注意，权限模型只是对权限进行分配的思路和方案，解决“如何将某些权限分配给某些主体”的问题，不是“授权”的全部。

具体使用哪种权限模型，需要根据场景和需求来定，不要拘泥于权限模型而忽略实际业务。

下面介绍常见的几种权限模型：

ACL（Access Control Lists，访问控制列表），通过将主体（用户或用户组）直接和权限（包含操作和资源）关联成列表，控制主体能访问哪些资源。
DAC（Discretionary Access Control，自主访问控制），可以通过ACL或ACM来实现，特点是拥有权限的主体可以将自身的权限赋予给其他主体或收回，常见于操作系统。
MAC（Mandatory Access Control，强制访问控制），通过对主体和客体进行安全标记（密级），来判断主体能否对客体进行相关操作，常见于军工行业。
RBAC（Role Based Access Control，基于角色的访问控制），通过引入“角色”的概念，将主体和权限之间的关系解耦，是常见、成熟、有效的权限模型。
ABAC（Attribute Based Access Control，基于属性的访问控制），通过动态计算一个或一组属性是否满足某种条件来进行授权判断，常用于公有云，不同场景下形态各异。

在这里插入图片描述

(ABAC 模型)

5.4 鉴权

IAM 中的“授权模块”还包括“鉴权”的部分，与“分配权限”（Assignment，也常称为授权）相对应。

鉴权是验证主体是否拥有访问客体的权限，完整的鉴权应该包括身份认证和权限决策两部分。

大多数情况下完成身份认证即完成了鉴权，这部分属于“认证”模块（英语中Authentication也有鉴权的意思）。

但在比较复杂的场景，比如使用 ABAC、零信任时，当主体访问资源时，决策点 PDP 需要根据属性或策略规则动态计算主体是否拥有足够的权限，并依据计算结果放行或拦截访问，此部分也应当属于鉴权。

六、应用

狭义的应用只是业务系统在IAM中的映射，即APP ID和APP Secret。

广义的应用是上文中账号、认证、授权的交互对象和载体，一般作为客体来使用。

6.1 预集成应用

由于应用之间的规范、协议各有差异，IAM往往会预集成一部分应用，提前对接好其账号、认证、授权等模块，方便客户开箱即用。

针对普通用户，IAM一般会提供统一的应用门户（仪表盘），显示企业内自己所拥有权限的所有应用，也可以手动添加自己的应用，方便用户日常使用。

七、审计

审计日志需要记录用户的所有操作，需要记录主体、操作、客体、类型、时间、地点、结果等内容。

根据不同的维度可以划分为不同的操作日志，如操作日志和登录/登出日志、用户日志和管理员日志、业务系统日志和IAM系统日志等。

审计相关的功能，不同规模、不同行业要求不同，通常国外比国内更严格、更强调合规。

八、在 AWS 中创建 IAM

下面进行讲解如何在 AWS 中进行创建 IAM 账号。

首先直接进入亚马逊云科技控制台，搜索IAM ，之后点击进入IAM 服务。

在这里插入图片描述

点击【添加用户】按钮

在这里插入图片描述

进入到创建用户步骤，这里主要是一些用户的信息，比如用户名，密码等。

在这里插入图片描述

点击创建组

在这里插入图片描述

如果未选择创建用户组，可以跳过此处

在这里插入图片描述

设置所创建的 IAM 账号所属的权限组

在这里插入图片描述

选择标签对，这里注意最好建议添加，在亚马逊最佳实践里面，打标签是个非常好的习惯

在这里插入图片描述

完成创建的提示：

在这里插入图片描述

点击返回用户列表后，可以在列表内看到刚刚创建的用户的相关信息。

在这里插入图片描述

[ 本文作者 ]   bluetata
[ 原文链接 ]   https://bluetata.blog.csdn.net/article/details/131523127
[ 最后更新 ]   07/03/2023 20:31
[ 版权声明 ]   如果您在非 CSDN 网站内看到这一行，
说明网络爬虫可能在本人还没有完整发布的时候就抓走了我的文章，
可能导致内容不完整，请去上述的原文链接查看原文。