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加密