AWS 身份及验证服务（四）

IAM

概述

• 集中管理访问AWS资源的访问权限和用户身份认证
• 支持联合访问管理，支持LADP第三方服务 （Identity Provider）
• 是非区域相关的服务，全局有效
• 创建用户、组和角色以应用策略
• 安全凭证类型包括： 电子邮件和密码、IAM用户名和密码、访问密匙、多重验证（MFA）、密匙对
• 密码策略管理和KMS加密解密管理
• 建议始终使用创建和管理IAM账户来进行操作
• IAM遵循最低特权原则，即所有权限被隐式拒绝，而显式拒绝拥有最高优先级
• IAM是权限与实体进行匹配的正式语句
  • 策略可以应用于任何实体，包括用户、组和角色
  • 策略可以一对多也可以多对一

委托人

• 委托人是允许与AWS资源交互的IAM实体，可以是人或应用程序，也可以是临时或永久的。

• 有三种委托人身份：根用户、IAM用户(组)和角色

  • 根用户
    • 第一次创建AWS时的登录主体，可以完全访问所有账户中的AWS资源与服务
    • 强烈建议不要将根账户用于任何的日常任务或是管理员
    • 必须安全的锁定根用户的用户凭证
    • 根用户也是Billing Account
    • 等同于Owner ，创建AWS账户的实体和Email地址
  • IAM用户
    • 可以通过IAM服务创建持久性身份，可以是个人或应用程序
    • IAM用户可以随时由IAM管理权限的主体创建
    • 需要提供与AWS交互的方法, 支持AWS控制台用户名密码、CLI或者SDK等方式管理IAM用户
    • 可以提供定制的URL用于IAM用户访问
    • 应该使用最小权限原则管理IAM用户
    • 最佳实践：创建对根账户拥有管理特权的独立IAM账户
  • IAM用户组
    • 用户的集合
    • 策略应用于整组
    • 一个用户可以属于多个组
    • 没有默认组
    • 不能嵌套组

• 角色
  • 在特定时间段内向特定角色授予特定权限
  • 这些角色通过AWS或第三方系统进行身份验证
  • 通常会将某个用户或组的权限关联到角色，以简化管理防止配置错误
  • 当一个角色开始承担任务时，AWS会提供AWS安全令牌（STS）的临时安全令牌似的他可以使用授权的AWS服务（STS 有效时间为15分钟-36小时）
  • IAM组无法使用角色
  • 每个账户只能创建最多1000个IAM角色
  • EC2应用程序角色
    • 传统授予应用程序权限会非常麻烦，需要安全使用某种凭证，并且还需要考虑安全的存储和访问这些凭证，
      • 如一个应用程序需要访问S3时，需要该程序使用IAM用户的密钥，而密钥又云需要存储在一个安全的位置被应用程序访问，这样会导致凭证轮换等存在很多问题，同时不利于敏捷开发。
      • 可以利用IAM 角色功能，当该应用程序的EC2启动时利用Config Profile分配该角色，程序利用API访问S3时该角色会获取一个临时令牌，用AWS工具包将临时令牌传递给API以允许访问，这种方法不需要考虑任何密钥管理和轮换。
    • 在实例运行过程中可以随时替换或分离角色
    • 每个EC2只能分配一个角色
    • 跨账户访问(Cross Account )
      • 将访问AWS资源授予其他AWS账户中的IAM用户
      • 通常用于与公司关联的第三方供应商或客户有限制的访问公司资源
    • 临时访问管理 ( Federation)
      • 对联合身份用户提供临时的访问权限
      • 主要用于第三方服务，而组织又不希望为它提供组织内长期凭证（如API管理）

认证

用户名/密码

• 人员登录Console的设置，可以设置密码策略执行复杂性要求和过期
• 最大支持128个字符
• 建议设置密码策略以确保使用强密码且经常更改
• IAM账户登录还必须提供账户ID或别名（URL包含）

访问密钥

• 密钥ID AKI（20字符）和访问密钥 SAK（40字符）的组合
• 通过API时使用密钥对REST调用，且SAK必须签署所有的API请求
• 签名有助于保护消息完整性，防止在传输过程中被篡改，以及防止重播 attack
• 支持Signature v4， 使用SAK派生进行签名
• 访问密钥需要放在安全的地方而不是嵌入代码中
• 每个IAM用户最多同时拥有2个激活的密钥
• 只在区域内有效

• 密钥对

  • 支持RSA 2048 SSH密钥
  • 首次访问时实例使用显式的私钥授予访问权限，公钥放入实例中，是登录EC2的首选方式
  • 密钥对还可用于CloudFront 为私人内容创建签名URL实现私有分发
  • 若密钥对丢失，不能被重新生成，但是可以进行替换
• 访问密钥+会话令牌 （STS）
  • 在服务被假定角色使用时，使用的临时令牌用于验证访问密钥，包括临时访问密钥对本身和一个会话令牌。
    • 访问ID
    • 访问密钥
    • 安全令牌
    • 超时时间
• 不用为访问创建专门的IAM账号
• 临时认证无需进行密钥rotation
• 配置超时 15min -36hr ，默认12小时

X.509

• 可用于签署基于SOAP的请求
• AWS账户可以创建X.509, IAM必须使用第三方软件才能创建X.509
• 可作为SSL/TLS服务器证书， 提交密钥到CA进行证书签名请求CSR
• 利用X.509为EC2创建定制的Linux AMI

多因素认证

• MFA是在密码/密钥之外为基础架构添加的额外安全层，通常需要从外部设备输入一次性密码OTP
• 支持硬件和软件的MFA认证
• 支持为API实施MFA认证
• MFA可以分配个任何IAM用户，尤其建议为根用户启用MFA
• 每个用户只能与一个MFA绑定

联合认证 （Identity Federation）

• IAM身份供应商IdP可以将IAM和外部身份联合起来由外部进行认证， 并将权限分配给IAM外进行认证的用户。
• IAM会返回与角色关联的临时令牌进行工作，以便验证用与调用AWS API的身份
  • 公共IdP
    • 采用 OIDC （OpenID Connect）集成
    • 主要是授权给主要的网络IdP认证用户，如Google，Facebook，Amazon等，称为Web Federation
  • 企业内部身份验证
    • 如企业自有的AD或LADP身份验证服务，支持SAML 2.0
• 注意： 默认创建IAM用户是不包含任何密码和密钥对，管理员需要手工指定

授权

• 指定委托人可以执行和不能执行操作的权限 ，通过策略定义。
• 策略是一个JSON文件，充分定义了一组权限的访问和操作AWS资源
  • Version： 可选项，以日期为格式
  • Effect - 允许或拒绝
  • Resource - 适用于特定权限的AWS基础架构的资源、数据主体，利用ARN来唯一指定资源
    • Amazon 资源名称 = Amazon Resource Name （ARN）
    • 一个AWS资源的唯一标识，当在全局环境中调用时指向唯一的一项资源
      • arn:<partition>:<service>:<region>:<account-id>:<resourcetype>:<resource>
      • 例如 arn:aws:rds:eu-west-1:1234567:db:mysql-db
  • Service - 适用的服务名称
  • Action - 指定服务的操作子集
  • Condition - 可选项定义一个或者多个限制权限允许操作的附加条件。

• 将策略和委托人联系
  • 用户策略
    • 显式声明的策略
    • 策略仅仅存在于所联系的用户中
  • 托管策略
    • 预置的策略
    • 独立于用户而存在的，策略可以与许多用户或用户组关联。
    • 建议使用预定义的托管策略保证在添加新功能时用户依旧保持正确的访问权限。
  • 最佳实践： 组策略
    • 通过将托管策略关联到一个用户组可以大大简化对多用户的策略管理。同样也为用户组策略和用户组托管管理策略。
• 用户权限
  • 无权限 - 新用户创建时的默认权限
  • 授权用户权限 - 根据需求对用户进行授权
  • 特权（Power）权限 - 可以访问所有AWS 服务，但是无法管理用户和组
  • 管理员权限 - 根用户权限

其他主要特点

密钥轮换

• 任何凭证的安全风险都会随着凭证使用时长而增加，所以定期对密钥进行更换非常必要。
  • 创建新的访问密钥
  • 重新配置所有应用程序使用新密钥
  • 禁用老密钥
  • 验证新密钥的所有应用程序操作
  • 删除老密钥

多权限问题

• 为了解决委托人在执行某个操作时，可能适用于已经配置的多个权限。
  • 请求默认被拒绝
  • 当所有政策中有明确的拒绝，则拒绝
  • 当所有政策中有明确的允许而没有明确的拒绝，则允许
  • 若没有明确拒绝或允许，则保留默认拒绝
  • 策略无法覆盖角色所默认拒绝的任何权限

AWS Directory Service

AD概念

• AD包含组织信息、用户、组、计算机和其它资源

MS AD Service

• 将MS AD作为托管服务运行
• 在Win2012R2上运行
• AD是跨2个可用区部署的高可用域控制器
• 支持数据复制和自动每日快照
• 无需安装软件，AWS处理所有的bug和update
• 不能将现有AD迁移进来，只能新建
• 适用于超过5000人的场景

AD Connector

• 可以使用AD Connector 连接现有本地AD
• 通过VPC VirtualPN或者Direct Connect 连接企业数据中心
• 使用现有凭证访问AWS 应用程序
• 基于RADIUS 现有 MFA解决方案集成
• 适用于混合云场景

Simple AD 服务

• 使用Samba 4服务器提供AD服务
• 支持常用AD功能，如用户账号和组身份
• 支持Linux 和 Windows EC2加入域
• 基于Kerberos的单一登录（SSO）和组策略
• 也提供了每日快照和基于时间点恢复
• 提供日志和审计功能
• 不支持与MS AD建立信任关系，不支持MFA、DNS动态更新、LDAP等高级功能
• 适用于不超过5000人的简单场景

AWS Security Token Service

概念

• 轻量级Web服务，获取临时、有限权限的凭证
• 身份代理认证
  • 利用身份代理服务创建临时凭证，用户获得一个临时URL访问AWS管理控制台（单点登录） ，支持
    • 跨AWS账户的IAM用户组
    • 当前账户中的IAM用户
    • 第三方请求
• 身份代理主要用于：
  • 查询STS
  • 确定Web请求的用户
  • 使用AWS凭证向AWS进行身份验证
  • 通过AWS STS API颁发临时凭证
• STS 返回
  • STS返回临时安全凭证给应用程序，其中包括了：
    • AccessKeyId
    • SecretAccessKey
    • SessionToken和时限（1到36小时）

常见场景

• 基于SAML的SSO联合认证
  • STS支持SAML 2.0的开放标准更快更容易实现联合，利用现有身份管理软件管理AWS的访问，无需编码
  • 身份供应商idP通过SAML2.0 使用HTTP-POST绑定启动Web SSO，通过新的URL简化SSO
  • 需要IAM创建SAML idP作为IAM信任策略的委托人
  • 步骤
    • 用户在应用程序内输入账号密码，应用程序将其发送给Identity Provider (Identity Broker)
    • Identity Provider (IdP)将用户名和密码发送到企业的LDAP目录进行验证
    • 验证成功后IdP发送一个SAML认证响应给应用程序
    • 应用程序使用AssumeRoleWithSAMLRequest API发送SMAL请求给STS
    • 应用程序使用临时凭证访问S3存储桶

• 基于Web的联合身份认证
  • 使用STS API AssumeRoleWIthWebIdentity
  • 支持Amazon、Google、Facebook的身份认证

• 跨账户访问
  • 跨账号访问权限（Cross Account Access），可以在AWS管理控制台上轻松地进行账号（角色）的切换，让用户在不同的开发账号（角色）、测试账号（角色）、生产账号（角色）中进行快捷的切换。
  • 示例 ： 让开发账号拥有一定的访问权限，让其访问生产账号中的S3资源。
    • 生产账号中的管理员需要在IAM中创建一个新的角色UpdateAPP，在角色中定义了策略（Policy），策略具体定义了允许特定的AWS账号ID访问名为productionapp的S3存储桶
    • 在开发账户中，管理员向开发人员组的成员授权切换角色的权限。向开发人员组授予针对UpdateApp角色调用AWS Security Token Service (AWS STS) AssumeRole API 的权限。
    • 用户请求切换角色
    • 可以在AWS控制台使用Switch Role的按钮切换到生产账号
    • 或者使用AWS API/CLI，使用AssumeRole函数获取UpdateAPP角色的凭证
    • AWS STS返回临时凭证
    • 临时凭证允许访问AWS资源，这样切换后的角色就可以访问productionapp的存储桶里的内容了。

AWS KMS （Key Management Service）

概述

• 托管型加密服务
• 采用双层密钥结构，通过主密钥对不同的数据密钥进行加密，数据密钥对应用程序进行加密
• 数据密钥是唯一的， 主密钥不能脱离KMS系统
• 仅支持对称加密。

CMK

• KMS使用客户主密钥（CMK）来加密和解密数据。CMK可以是客户托管的密钥也可以使AWS托管的密钥
• CMK不能以未加密的状态脱离AWS KMS，但是数据密钥可以。
• 默认情况下，启用KMS集成后，每个账户都会生成一个AWS托管的默认密钥，如果没有特别指定CMK，这个默认密钥就会作为CMK对资源进行加密。
• CMK密钥长度为256位，数据密钥为128位或256位
• CMK的创建需要有相应的权限，并定义IAM中哪些用户和角色可以管理和使用密钥，也可以允许其他AWS账户使用该密钥。
• CMK支持对最大4KB数据的加密和解密
• AWS可以选择自动进行每年的CMK轮换
• CMK删除可以设置7-30天的等待期，以确保没有任何影响
• 每个区域的每个账户最多可以创建1000个CMK

• 信封加密

  • CMK加密数据密钥加密后，会返回明文和加密版本
  • 明文版本用于对数据加密，完成后应立即从内存中删除
  • 加密版本可与加密数据一起存放
  • 加密上下文
    • 所有加密操作都支持附加上下文信息的可选Key/value对
    • 加密和解密操作必须先确定上下文相同，否则无法解密
    • 上下文可用细粒度授权和额外审计

安全实践

• 为密钥创建唯一的别名和描述
• 定义哪些IAM用户和角色可以管理密钥
• 选择让KMS每年轮换密钥
• 临时禁用和启用密钥
• 检查和审核CloudTrail日志中密钥的使用情况
• KMS只能在生成的区域使用，无法传输到另一区域

KMS+HSA

• AWS KMS提供简单的Web接口RESTful API，用户访问弹性、多租户的强化安全设备（HSA）
• 使用CMK构建基于HSA的加密上下文，仅可在HSA上访问，用于常驻HSA的加密操作
• KMS是一项分级服务，由面向Web的KMS主机和一个HSA梯队组成
• 客户对KMS所有请求通过SSL发出，在KMS主机上中止
• KMS主机使用协议和程序通过HSA完成相关的加密解密操作。

KMS加密EBS卷

AWS CloudHSM

• 在AWS云中部署专用的硬件安全模块，使用SafeNet Inc 的 Luna SA7000 HSM设备
• 提供防篡改的硬件模块内的安全密钥加密和存储，且不会将其暴露在设备的加密边界外

• CloudHSM主要针对专用的VPC中，为单租户提供HSM服务，支持对称和非对称加密

  • 使用 AWS CloudHSM 服务时，您需要创建 CloudHSM 集群。
  • 集群可以包含多个 HSM 实例，这些实例分布在一个区域的多个可用区中。
  • 集群中的 HSM 实例会自动同步并进行负载均衡。
  • 您可获得对集群中每个 HSM 实例的专用单租户访问权限。
  • 每个 HSM 实例在 Amazon Virtual Private Cloud (VPC) 中都显示为网络资源。向集群中添加 HSM 或将其从中删除只需调用 AWS CloudHSM API（或在命令行上使用 AWS CLI）即可完成。
  • 创建和初始化 CloudHSM 集群后，您可以在 EC2 实例上配置一个客户端，以允许您的应用程序通过经过身份验证的安全网络连接使用该集群。
  • Amazon 管理员可监控 HSM 的运行状况，但无权配置、管理和使用它们。
  • 您的应用程序将标准的加密 API 与应用程序实例上安装的 HSM 客户端软件配合使用，以向 HSM 发送加密请求。客户端软件可维护通向集群中所有 HSM 的安全通道，并在此通道上发送请求，而 HSM 执行相关操作并通过该安全通道返回结果。然后，客户端通过加密 API 将结果返回到应用程序。
• 建议配置高可用的HSM服务

Amazon Cognito 服务

• Cognito为移动和基于Web应用的程序提供身份和同步服务
• 与公共的IdP合作，如Google、Facebook和Amazon
  • 利用SDK访问IdP，并利用它进行身份识别和授权
  • IdP认证成功后会回传一个OAuth或OpenID Connect给Cognito，Cognito会给用户返回一个新的Cognito ID以及一组临时AWS凭证
  • Cognito 作为代理，需要创建一个身份池，用于AWS账户中特定的用户信息存储，即角色和权限
  • Cognito会有限的创建新角色对AWS资源进行访问，而最终用户实际只能访问到Cognito Sync服务和Mobile Analytics服务
• Cognito利用客户端SDK管理本地的SQLite存储作为读写缓存，并异步同步到云端，
  • 用户即使处于脱机状态依旧可以继续进行数据交互，但数据可能过时
  • 但多账户同步时必须得到Cognito的验证
  • Cognito身份只会同步和存储角色授权的自己的数据，且数据传输使用HTTPS加密