わたし
アウトライン
- AWSリソースへのアクセスとユーザー認証へのアクセスの集中管理
- 、関節のアクセス管理をサポートしていますLADPサードパーティのサービスをサポートします(IDプロバイダ)
- 非地域関連サービス、全体的な効果
- ポリシーを適用するには、ユーザー、グループ、およびロールを作成します。
- セキュリティ文書の種類は、次のとおりです。メールアドレスとパスワード、IAMユーザー名とパスワード、アクセスキー、多要素認証(MFA)、鍵のペアを
- KMSパスワードポリシーの管理と暗号化と復号化管理
- 我々は常に動作するIAMアカウントを作成し、管理するために使用することをお勧めします
- IAMは、最小特権の原則に従うつまり、すべての権限が暗黙的に拒否されている、と明示的に最も高い優先度を持っていることを拒否しました
- IAMは、権利の正式な声明や物理的な試合です
- 戦略は、ユーザー、グループ、および役割を含め、任意のエンティティに適用することができ
- 戦略は、多対多可能
校長
- AWS IAMエンティティのクライアントは、ヒトまたは一時的または永久的なアプリケーションのいずれか、リソースと相互作用させます。
-
3人の主要なアイデンティティがあります:rootユーザー、IAMユーザー(グループ)と役割が
- ルート
- AWSの本体初めてのログインを作成し、すべてのアカウントのAWSリソースとサービスへのフルアクセス
- 強く日常のタスク、または任意の管理者のアカウントをrootにないことをお勧めします
- あなたは安全にrootユーザーの資格情報をロックする必要があります
- rootユーザーもアカウントを課金されます
- エンティティと電子メールアドレスAWSアカウントを作成するには、所有者と同等
- IAMユーザー
- あなたは、個人またはアプリケーションかもしれIAMサービスを通じて持続的なアイデンティティを作成することができます
- IAMユーザーは、身体の管理権限でいつでも作成することができIAM
- AWSコンソールのユーザー名とパスワード、CLIまたはIAMユーザー管理SDKをサポートするために、AWSのインタラクティブなアプローチを提供する必要性など
- 私たちは、IAMユーザーアクセス用にカスタマイズされたURLを提供することができます
- あなたは、最小特権ユーザー管理の原則を使用する必要がありますIAM
- ベストプラクティス:rootアカウントの独立したIAMアカウントに管理者権限で作成
- IAMユーザーグループ
- ユーザーコレクション
- ポリシーは、グループ全体に適用されます
- ユーザーが複数のグループに属することができます
- デフォルトのグループはありません
- グループを入れ子にすることはできません。
- ルート
- 役割
- 特定の期間に特定の役割に特定の権限を付与します
- これらの役割は、AWSやサードパーティ製のシステムによって認証します
- あなたは、通常、構成エラーを防ぐために、管理を簡素化するためには、役割にユーザーまたはグループのアクセス権に関連付けられます
- 文字がタスクを取るようになったとき、彼はAWSサービス(36時間15分間有効STS)の使用を許可することができるように、AWS AWSは、一時的なセキュリティトークンのセキュリティトークン(STS)を提供します
- 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
- 公共IdP
- 注意: 默认创建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用户
- 第三方请求
- 利用身份代理服务创建临时凭证,用户获得一个临时URL访问AWS管理控制台(单点登录) ,支持
- 身份代理主要用于:
- 查询STS
- 确定Web请求的用户
- 使用AWS凭证向AWS进行身份验证
- 通过AWS STS API颁发临时凭证
- STS 返回
- STS返回临时安全凭证给应用程序,其中包括了:
- AccessKeyId
- SecretAccessKey
- SessionToken和时限(1到36小时)
- STS返回临时安全凭证给应用程序,其中包括了:
常见场景
- 基于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凭证
- エージェント、特定のユーザー情報が格納されているAWSアカウントのプールIDを作成する必要があり、つまり、ロールと権限などCognito
- Cognitoは、AWSリソースへのアクセスが制限された新しいロールを作成し、実際のエンドユーザーがCognitoシンクサービスとモバイル分析サービスにのみアクセスすることができます
- Cognitoは、読み取りキャッシュとして保存されたローカルクライアントSDKのSQLiteのを使用して管理し、非同期的にクラウドを同期させるために
- ユーザーがオフラインではまだデータを交換し続けることができますが、データが古いかもしれであっても、
- 複数のアカウントを同期するときしかし、それはCognito確認する必要があります
- Cognitoのアイデンティティは、HTTPSの暗号化を使用したロール認可、およびデータ伝送に独自のデータを同期して保存します