seccloud
探索云世界
seccloud
阿里云信息安全管理团队致力于解决企业上云的身份与访问管理、安全合规性、数据保护、风险控制、资源管理等核心问题。欢迎加入我们——构建业界领先的云上企业信息安全管理标准。
本文介绍从 Google G Suite （作为IdP）到阿里云（作为SP）进行SSO联合登录的一种配置方法，用于帮助客户理解企业如何使用外部 IdP 与阿里云服务进行身份联合的端到端配置流程。 本文中涉及到 Google G Suite配置的部分属于建议，仅用于帮助理解阿里云身份联合的端到端配置，阿里云不提供 Google G Suite配置官方咨询服务。 示例配置的前提假设 假定您的企业正在使用Google G Suite进行日常工作，示例企业中假设G Suite的主域名(primary domain)为： secloud.club 关于您：假设您是G Suite管理员，同时也是阿里云账号管理员。 Alice是您企业的普通雇员，日常工作会使用G Suite域用户账号 alice@secloud.club 登录使用G Suite企业应用。 在 G Suite 中将阿里云配置为可信 SAML SP 配置阿里云作为 G Suite的可信 SP 的操作步骤如下： 您需要使用G Suite管理员账号登录到 G Suite Admin Console ，进入 Apps > APPS SETTINGS > SAML apps > Add a service/App to your domain，下面将阿里云作为一个SAML App进行配置： Step 1: 选择SETUP MY OWN CUSTOM APP Step 2: 下载Google IdP Metadata 下载的metadata文件将用于后续的阿里云账号侧的SSO配置 Step 3: 填写自定义App名称 这里将Application Name定义为 Aliyun Management Console. Step 4: 填写阿里云作为SP的必要信息 G Suite要求至少提供ACS URL和Entity ID这两个属性值。ACS URL是指阿里云账号作为SAML SP所对应的Assertion Consumer Service地址；Entity ID是指阿里云账号作为SAML SP的实体ID。 那么如何获取这两个信息呢？ 您需要使用阿里云账号登录访问阿里云RAM控制台 > 人员管理 > 设置 > 高级设置，在SSO登录设置下可以查看当前云账号的SAML 服务提供方元数据 URL。访问此URL即可获取当前云账号的SP Metadata XML文档。而ACS URL和Entity ID这两个属性值可以从SP Metadata XML对应的节点中获取，如下图所示： 在上述XML文件示例中，我们得到：Entity ID值：https://signin-intl.aliyun.com/58************67/saml/SSO ACS URL值：https://signin-intl.aliyun.com/saml/SSO 配置如下图所示： Step 5: 配置属性映射（Attribute Mapping） 这里使用G Suite的默认属性映射（将Primary Email映射为Name ID）即可，所以这一步不需要特殊配置，直接跳过。 此时您可以看到如下的提示信息： 说明G Suite作为IdP侧的SSO配置完成，然后需要在阿里云账号侧进行对应的SSO配置。 开启App的用户授权 在进行阿里云账号的SSO配置之前，您还需要设置哪些用户能使用这个App，这是因为新创建的SAML App默认对所有用户关闭授权。下面配置为对所有域用户(domain users)授权，如下图所示： 在如下的确认界面中再次确认开启对所有域用户的授权： 在RAM中将G Suite配置为可信SAML IdP 接下来您需要使用阿里云账号登录到RAM控制台，开始在阿里云账号侧进行相应的域别名及SSO配置： Step 1：为默认域名设置域别名 阿里云账号的默认域名为：<account-alias>.onaliyun.com，我们将G Suite域名（secloud.club）设置为云账号默认域名的域别名。 创建域别名的方法请参考RAM在线文档：创建域别名的方法。 Step 2：SAML单点登录(SSO)设置 由于在上一部分的G Suite配置过程中，我们已经下载了Google IdP Metadata文件，这里需要将该文件上传到阿里云。具体操作请参考RAM在线文档：SAML单点登录的设置。 授权Alice开始使用阿里云控制台进行工作 上述的配置完成后，下面就可以来测试了。假设Alice被任职负责阿里云OSS数据的管理。那么您作为阿里云账号管理员，需要先在阿里云的RAM中为Alice创建一个用户（要求与G Suite中的用户名相同）并授予合适的权限（这里可授予AliyunOSSFullAccess权限策略）。授权完成后，Alice就可以进行正常工作了。 Alice有两种方法登录到阿里云控制台： 方法1：登录到G Suite企业应用并跳转到阿里云控制台 由于上文已经在G Suite中配置了阿里云控制台(Aliyun Manangement Console)作为SAML App，所以Alice使用G Suite域用户账号登录到 G Suite企业应用 之后可以看到 Aliyun Manangement Console，直接点击该应用即可跳转到阿里云控制台，无需重新登录。 方法2：使用阿里云RAM用户登录 Alice也可以从阿里云 RAM用户登录URL 进行登录。当Alice输入 alice@secloud.club 之后，阿里云会自动跳转到Google登录URL，提示用户使用Google账号登录。登录成功后Google登录系统会自动跳转到阿里云控制台。 参考文档 [1] G Suite Administrator Help: Set up your own custom SAML application[2] 阿里云RAM在线文档 - 联合登录概述
最近，阿里云ResourceManager服务新增了“资源组管理”功能，以帮助客户解决企业内部多用户、多项目的资源分级管理难题。使用资源组管理，您可以对单个云账号下多个地域、多种资源进行统一的分组管理；您也可以给各个资源组设置完全独立的管理员，实现在资源组范围内的用户与权限管理；您还可以按资源组维度查看您的账单消费数据，以解决不同项目的分账问题。（如果您的企业拥有多个云账号，ResourceManager后续也将提供多账号管理能力，敬请期待） 下面我们一起来了解下ResourceManager的资源组管理。 基本概念 阿里云账户(Account) 云账户是云资源的容器，例如：阿里云ECS实例、RDS数据库实例、OSS存储桶等。 云账号是阿里云账户的身份标识。 云账号是阿里云多租户资源隔离的安全边界。 云账号是云资源属主(Owner)，对云资源拥有root权限。 云账号可以将其拥有的一组子权限集授予给RAM用户、用户组或RAM角色。 资源组(ResourceGroup, 简称RG) 一个云账户通常包含一个默认资源组和多个自定义的资源组。 一个资源只能唯一归属于某一个资源组。 任意时刻都可以向资源组添加或移除资源。 允许将资源从一个资源组移动到另一个资源组（但不允许跨账号）。 一个资源组可以包含不同地域的云资源。 支持在指定资源组范围（而不是云账户范围）对用户进行授权。 可以按应用/项目管理的视角对云资源进行分组：具有相同生命周期的资源（一起部署、升级或删除）一般会放在同一个分组。 同一账户内不同资源组中的资源可以进行关联，即允许不同生命周期的两个资源建立关联关系。比如，资源组1中的ECS实例可以加入资源组2中创建的VPC。 Account范围的授权管理 账户级别授权的含义是，给一个RAM用户附加一个Policy策略时，该策略的授权作用范围是指云账户内的所有资源（即所有资源组的资源）。大家所熟悉的经典RAM用户授权提供的就是账户级别的授权管理。 账户级别授权模型如下图所示： 比如给一个RAM用户授予ReadOnlyAccess策略，该策略针对账户下的所有资源（包括所有资源组）生效。 如果您只希望给RAM用户分配指定某个资源组内的资源权限，那么您需要使用资源组(RG)范围的授权管理，而不是Account范围的授权。注意，如果要取得分级管理的效果，Account范围的授权和RG范围的授权就不要同时使用。 RG范围的授权管理 资源组级别授权的含义是，当在某个资源组内添加一个RAM用户并附加一个Policy策略时，该策略的授权作用范围则仅仅是指该资源组内的所有资源。 资源组级别授权模型如下图所示： 如果您是资源组的管理员（资源组的创建者会被默认设置为管理员），您可以在资源组的成员管理中添加用户并授予访问策略Policy，此时的Policy授权作用范围就只会对当前资源组内的所有资源生效。 管理员视角的操作 账户管理员授权Alice为资源组管理员 账户管理员登录并进入ResourceManager控制台，如下图所示： 账号管理员创建资源组，给资源组分配资源，并设置已经存在的RAM用户（假设为Alice）为资源组管理员。 操作如下图所示：新增成员，选择Alice，并为Alice添加AdministratorAccess授权策略。此时，在资源组范围内拥有AdministratorAccess策略的Alice即成为该资源组的管理员。 资源组管理员Alice授予Bob日常运维操作权限 Alice作为资源组管理员，她可以自治管理资源组资源，并可以授权其他用户对该资源组的操作权限。 比如，Alice希望授权Bob拥有对该资源组中ECS实例的运维操作，那么Alice只需要在资源组的成员管理中，添加用户Bob并授权AliyunECSFullAccess，此时Bob便拥有了该资源组的ECS管理权限。 普通用户视角的操作 Bob登录阿里云进行日常运维操作 Bob 登录 后，进入ECS管理控制台，在控制台页面顶端(top-bar)，Bob可以选择进入自己拥有操作权限的那些资源组。假设某账号名下拥有10个资源组，但给Bob授权了其中的三个资源组（eg, “prod环境”、“test环境”、“staging环境”）的操作管理权限，那么Bob在ECS控制台中可以选择某个资源组（eg, “test环境”）进行相应的资源操作。 注意，Bob在top-bar页面上只能看到自己有操作权限的资源组列表，并可随时进行资源组的切换。 面向资源组的财务功能 财务管理（比如账单合并或分摊）通常是企业上云的一个痛点。阿里云的财务管理系统不仅提供了多个独立云账号的账单聚合能力（进入“财务云管理” -> “关联账号财务”），而且还提供了针对单账号内资源组粒度的消费详情（进入“财务云管理” -> “资源组报表”）。 一个账号内的不同资源组消费详情样例如下图所示： 结语 本文简要介绍了阿里云ResourceManager所提供的面向资源组的分级资源管理与授权管理功能。该功能不会收费，目前已在公共云上开放公测，欢迎大家试用并提交反馈。 关于企业云上资源管理的更多场景及其解决方案，请您进一步阅读阿里云的云账号结构管理模型的最佳实践指导 —— 您需要了解的云账号管理模型。
在企业上云的所有安全威胁之中，最严重的威胁莫过于账号密码或AK (Access Key)泄露。一旦泄露密码或AK，最坏情况可能导致你的企业破产，就像CodeSpaces因密码泄露而被勒索者删除AWS上所有数据及备份一样。 也许你会侥幸认为“这不会发生在我身上吧？”，未必！根据CSA 2016对AWS客户的安全威胁分析报告，特权账户密码/AK等敏感数据泄露已经成为云安全Top-12威胁之首。 很有可能，你的账号密码和AK早已落入他人之手。 那还有什么补救措施吗？有的，它就是RAM服务！RAM是阿里云为你企业上云所免费提供的身份管理与访问控制服务。通过RAM最佳实践，你可以从根本上降低或避免因为账号密码或AK泄露所导致的信息安全风险。 话不多说，即刻动手开启RAM最佳实践！ 禁止云账号密码共享 账号密码泄露的罪魁祸首之一就是多人共享云账号密码，很多人都知道的“秘密”就不是秘密了。共享账号密码的问题很多，除了更容易泄露之外，你也会无法限制每个人的权限，而且无法审计或追踪每个人都干了些什么。 解决云账号共享问题的办法就是为每个员工创建独立的RAM用户账号，让员工使用RAM用户账号进行日常工作。 进入RAM控制台开始管理你的用户。 开启MFA MFA (Multi-Factor Authentication) 是一种简单有效的最佳安全实践方法，它能够在用户名和密码之外再额外增加一层安全保护。启用 MFA 后，用户登录阿里云网站时，系统将要求输入用户名和密码（第一安全要素），然后要求输入来自MFA设备或手机短信的一次性验证码（第二安全要素）。这些多重要素结合将为您的账户提供更高的安全保护，密码泄露不再是问题。 为云账号开启MFA：打开“账号管理” -> “安全设置”，进入“虚拟MFA”进行设置。 为RAM用户开启MFA：打开“RAM控制台” -> “用户管理”，选择用户，进入用户详情页进行操作。 集中设置RAM用户登录安全策略 你可以在RAM中设置所有用户的密码强度及登录限制。比如，要求所有RAM用户的密码长度不低于10个字符，而且必须同时包含小写字母、大写字母、数字及特殊字符；密码每90天轮转；禁止最近3次密码重复使用；1小时内最多5次试错。不管多“高(变)级(态)”的安全需求，RAM几乎都可以满足! 此外，你还可以通过安全设置功能，设定RAM用户登录掩码以限制用户的登录源IP。进一步，你还可以控制登录Session过期时间，可以控制RAM用户是否可以自助管理密码、AK和MFA。 使用RAM小AK取代云账号大AK 云账号AK俗称“大AK”，它具有该账户的所有资源API访问权限，而且无法设置多因素认证！如果大AK一旦丢失，风险极不可控。因此强烈建议删除“大AK”，马上开始使用RAM用户AK（俗称“小AK”）来进行API调用。 进入AK控制台之后，阿里云会引导用户快速创建RAM用户AK。 限制RAM小AK的访问源IP地址 假设你的企业IP出口地址范围是42.120.72.0/22，根据你企业的安全管理策略，要求所有的数据访问请求必须来自于你的企业网络，要能确保万一AK泄露到外网那也不能访问你的云上数据。 首先，你可以创建一条自定义授权策略(DenyAccessPolicyWithIpConditions)，拒绝所指IP范围之外的所有请求。 然后，给RAM用户组(假设为oss-readers用户组)授权，如下图样例所示，包括允许访问OSS的授权策略和DenyAccessPolicyWithIpConditions策略。
问题描述 AK(AccessKey)是代表用户身份的钥匙，是用户访问阿里云API的身份认证密钥。如果部署在ECS实例中的应用程序需要访问各种阿里云服务API，用户通常会将AK保存在应用程序的配置文件中，使得应用程序能读取AK来调用阿里云服务API。这里存在两个问题：(1) 保密性问题。不管AK以何种形式存在于实例中，它都可能随着快照、镜像及镜像创建出来的实例被泄露。(2) 难运维性问题。由于AK存在于实例中，如果要更换AK（比如周期性轮转或切换用户身份），那么需要对每个实例和镜像进行更新并重新部署，这会极大增加对实例和镜像管理的复杂性。 针对保密性问题的通常解法是借助加解密(Crypto)或访问控制(Access Control)技术。 加密方案 由于AK本身也是一种密钥，而加解密技术通常不适合保护密钥本身，因为总有最后一把密钥(Last Key)是需要保护的，所以加密技术这里不适用。当然可能有少数区域的ECS实例提供了可信加密设备支持（比如HSM、TPM或SGX），但基于硬件来保护Last Key的方法是另一个专题，本文不做讨论。 访问控制方案 一种简单有效的AK保护做法是采用访问控制技术。比如，可以使用操作系统提供的访问控制机制来保护存放AK密钥的配置文件，比如 $ chmod 400 ~/.aliyuncli/credentials (只允许当前用户可读) 在用户登录管理严格的条件下，这种机制可以起到一定的保护作用。但由于AK本身没有加密，通过快照或镜像泄露之后就可能绕过访问控制机制，仍然可能泄漏。 针对难运维性问题就难解了，只要AK存在于实例文件中，对大量实例和镜像的管理复杂性就无法降低。 阿里云的技术方案 站在操作系统设计的角度，用户态中难解的问题，在内核态看来根本不是事。同样，ECS实例中难解的问题交给ECS管控来解，也不是难题。 阿里云ECS结合RAM (Resource Access Management)提供的访问控制能力，针对此问题提供了一个根本的解决方法 —— 通过给ECS实例配置RAM角色来避免AK泄露及运维难的问题。 技术原理 图1详细描述了如何给ECS实例配置RAM角色的工作原理： (图1) Step 1. 云账号(root)在RAM中创建一个ECS实例型的RAM-Role，并对角色授予合适的Policy权限。 Step 2. 启动ECS实例时，可以配置使用上一步骤中创建的RAM-Role。 以上两步的具体操作请参考通过控制台使用实例型RAM角色 或 通过API使用实例型RAM角色 所谓ECS实例型角色，它只是RAM服务角色中的一种类型，表示该角色是由客户创建并授权给该客户的ECS实例所使用。ECS服务在创建实例时：(i) 根据所配置的RAM角色，调用AssumeRole去访问STS请求获取该角色的StsToken；(ii) STS服务会验证ECS服务身份及该角色的授权类型，验证通过后颁发StsToken，否则拒绝请求。获取到StsToken后，ECS将通过Metadata服务提供给实例中的应用程序访问（HTTP访问地址：100.100.100.200 ）。StsToken过期时间通常为6小时，在过期之前ECS服务会自动维护StsToken的刷新。 Step 3. 获取StsToken。 ECS实例中的应用程序需要通过访问 ECS Metadata服务来获取相应的StsToken。比如， 在Linux中执行命令： $ curl http://100.100.100.200/latest/meta-data/ram/security-credentials/<roleName> 即可获取StsToken及过期时间等元数据信息。 Step 4. 使用StsToken调用云服务API。 如果你的应用程序使用了阿里云SDK，那么阿里云SDK已经支持从ECS Metadata服务中获取实例RAM角色的StsToken，开发者无需在SDK中配置任何AK相关敏感信息。详细使用方法，请参考阿里云SDK支持InstanceProfileCredentialsProvider。 Step 5. StsToken在有效期内及权限范围内都能正常访问云服务API。如果StsToken过期，那么需要从ECS Metadata服务中重新获取StsToken；如果StsToken权限不足，那么需要找管理员给实例RAM角色添加足够的权限。实例RAM角色的权限更新后，StsToken权限立即生效，用户无需重新启动ECS实例。 关于RAM的PassRole说明 在上文的技术图解1中，读者可以发现授权者和ECS实例操作者都是管理员。而对很多企业客户来说，授权者和ECS实例操作者通常都是不同的RAM用户，不同的人干不同的事，职责分离。 那么针对管理员与操作员分离的客户场景，我们需要对图解1进行一下扩展，得到如下的图解2： (图2) 除了增加Step 1.5之外，其它各步骤与图解1相同。 当RAM用户（假设仅有ECS权限，而并非RAM权限管理员）在创建ECS实例并配置RAM角色时，这个RAM用户必须要被授予对该角色的PassRole权限。ECS服务会强制检查当前用户是否拥有指定RAM-Role的 ram:PassRole 权限，否则无法成功创建ECS实例。这样做能确保只有被授权用户才能为ECS实例配置RAM角色，从而避免RAM角色权限被滥用。 Step 1.5 管理员给操作员增加一个PassRole权限。 管理员可以通过RAM按如下Policy样例创建一个自定义策略（注意替换rolename为自己的RAM角色名称），然后将这个自定义策略授权给操作员： { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "ram:PassRole", "Resource": "acs:ram:*:*:role/<rolename>" } ] } 至此，你已经通晓了ECS实例型角色的概念和技术原理，赶紧开启安全最佳实践吧，让你不再因为ECS实例中的AK泄露和管理难的问题而烦恼了。
在企业上云的所有安全威胁之中，最严重的威胁莫过于账号密码或AK (Access Key)泄露。一旦泄露密码或AK，最坏情况可能导致你的企业破产，就像CodeSpaces因密码泄露而被勒索者删除云上所有数据及备份一样。 也许你会侥幸认为“这不会发生在我身上吧？”，未必！根据CSA 2016对业界主流云服务商的客户安全威胁分析报告，发现特权账户密码/AK等敏感数据泄露已经成为云安全Top-12威胁之首。 很有可能，你的账号密码和AK早已落入他人之手。 那还有什么补救措施吗？有的，它就是RAM！RAM是阿里云为客户上云所免费提供的身份管理与访问控制服务。通过RAM提供的能力，客户可以在云上实施安全最佳实践，可以从根本上降低或避免因为账号密码或API密钥泄露所导致的IT或信息安全风险。 话不多说，即刻动手使用RAM开启您的安全最佳实践！ 禁止云账号密码共享 账号密码泄露的罪魁祸首之一就是多人共享云账号密码，很多人都知道的“秘密”就不是秘密了。共享账号密码的问题很多，除了更容易泄露之外，你也会无法限制每个人的权限，而且无法审计或追踪每个人都干了些什么。 解决云账号共享问题的办法就是为每个员工创建独立的RAM用户账号（相当于企业的域用户账号），让员工使用RAM用户账号进行日常工作。 进入RAM控制台开始管理你的用户。 如果您的企业已经有部署域账号系统，那么您可以将域用户同步到RAM用户目录（不要同步密码信息），并开启SSO单点登录，这样就能使用企业域账号来实现本地身份和云上身份的统一登录管理。具体方法请参考SSO实践文档。 给所有登录用户开启MFA MFA (Multi-Factor Authentication) 是一种简单有效的最佳安全实践方法，它能够在用户名和密码之外再额外增加一层安全保护。启用 MFA 后，用户登录阿里云网站时，系统将要求输入用户名和密码（第一安全要素），然后要求输入来自MFA应用的一次性验证码（第二安全要素）。这些多重要素结合将为您的账户提供更高的安全保护，密码泄露不再是问题。 为云账号开启MFA：打开“账号管理” -> “安全设置”，进入“虚拟MFA”进行设置。 为RAM用户开启MFA：打开“RAM控制台” -> “用户管理”，选择用户，进入用户详情页进行操作。 集中管理RAM用户的登录安全策略 你可以在RAM中设置所有用户的密码强度及登录限制。比如，要求所有RAM用户的密码长度不低于10个字符，而且必须同时包含小写字母、大写字母、数字及特殊字符；密码每90天轮转；禁止最近3次密码重复使用；1小时内最多5次试错。RAM几乎可以满足所有大企业IT的严苛用户安全治理要求。 此外，你还可以通过安全设置功能，设定RAM用户登录掩码以限制用户的登录源IP。进一步，你还可以控制登录Session过期时间，可以控制RAM用户是否可以自助管理密码、AK和MFA。 永远不要给云账号创建AK 为云账号创建的AK俗称“大AK”，因为云账号是超级管理员，具有该账户的所有资源操作权限，没有任何手段能限制这个超级管理员权限！如果大AK一旦丢失，风险极不可控。因此阿里云强烈建议客户禁用云账号“大AK”，替换方法是使用STS-Token（针对运行在云环境上的应用程序）或者是使用RAM用户“小AK”（针对运行在传统IT环境中的应用程序）。 使用STS-Token（动态API访问令牌）来取代AK（静态API密钥） 云应用开发者经常遇到的挑战就是如何在开发中管理云服务的访问密钥(AK)。这一直以来都是极其重要的课题。理想情况是让开发者永远不要碰密钥，让密钥永远不要出现在开发环境中，不要明文放在配置文件里，更不要check-in到代码库。 如果您的应用程序是部署在阿里云ECS上，那么针对此问题我们提供了一个根本的解决方法 —— 通过给ECS实例配置RAM角色来实现STS-Token取代静态AK配置，彻底避免AK泄露及安全运维的难题。解决方案的详细介绍请参考 使用动态的STS-Token取代静态的AK。 如果您的应用程序是部署在阿里云之外，那么你将无法享受这种高级安全解决方案。我们推荐你使用下面介绍的“RAM用户AK+限制条件”的方案。 使用RAM用户AK+条件限制 RAM用户的权限是可以被控制的，那么就意味着RAM用户AK泄露的风险是可控的。首先，您需要针对RAM用户实施最小授权原则，按需授权，一旦出现风险还可以随时撤销RAM用户权限。 仅解决RAM用户的最小授权问题还不够，AK一旦泄露，还是可能存在高风险（这个风险就要看“小AK”的权限到底有多“小”）。解决这个问题的方法之一就是限制应用程序的访问源IP地址。 假设你的企业IP出口地址范围是42.120.72.0/22，根据你企业的安全管理策略，要求所有的数据访问请求必须来自于你的企业网络，要能确保万一AK泄露到外网那也不能访问你的云上数据。 首先，你可以创建一条自定义授权策略(DenyAccessPolicyWithIpConditions)，拒绝所指IP范围之外的所有请求。 然后，给RAM用户组(假设为oss-readers用户组)授权，如下图样例所示，包括允许访问OSS的授权策略和DenyAccessPolicyWithIpConditions策略。 结语 本文介绍了阿里云提供的一些基本安全管理最佳实践能力，掌握并持续遵循这些最佳实践，您的云安全管理水平就可以到达60分了。上云切记，没有绝对安全，只有最佳实践！
摘要：越来越多的企业客户开始迁云，然而客户上云后所反馈最多的一类问题就是云资源的管理问题。究其原因，我们发现本质问题是企业上云的云账号规划问题。于是产出本文，首先介绍阿里云账号的基本概念及其功能，然后全面解释阿里云所提供的四种云资源管理基础模型，最后再提供一个案例分析，以帮助上云客户有效解决云资源的安全管理问题。 认识云账号 云账号又称租户账号，它是阿里云客户的身份标识。要正确理解一个云账号，我们需要从四个方面来看： 云账号是多租户资源隔离的基本主体。在云平台上，不同客户所购买的云资源是默认隔离的，比如，账号A在ECS上购买的虚拟机在默认时不会被其它云账号看见。 云账号是云资源的属主(ResourceOwner)。任何云资源都有唯一的属主，该属主就是云账号，属主将要确保对所租用资源的合规、合法使用。 云账号是云资源使用计量及财务结算主体。云账号具有独立的财务管理能力，比如申请信用额度、充值续费、账单结算、开具发票等。 云账号是云资源的权限管理员(root)。云账号是资源的属主，对资源拥有完全控制权限，而且可以将这些权限授予给其他用户。 多个云账号的财务关联 对于多个完全独立的云账号而言，每个云账号进行独立的财务结算可能会导致较高的管理成本。为此，阿里云提供了云财务管理功能，它支持将多个独立的云账号进行财务关联，可以对多个云账号进行合并计费、合并账单、以及共享资金和信用额度。对此有需求的客户可以访问 云财务管理控制台 。 注意：尽管云财务管理提供对多个账号的财务合并管理功能，但不同账号之家的资源仍然是完全隔离的。多账号的财务合并管理并不会打破多租户资源隔离这一基本原则。 云资源管理模型 Type-I：单账号模型 这是企业上云的原始模型。该模型仅仅依赖云账号所提供的基础功能，如下图所示： 适用场景： 单个项目上云 单用户使用与管理 仅适合于个人学习或测试场景 __注意：__由于该模型没有遵循最佳安全实践，我们不推荐任何企业客户使用，而强烈建议客户使用Type-III（单账号+RAM）模型来取代该模型。 Type-II：“多账号+合并财务管理”模型 该模型支持多个云账号以及多账号的合并财务管理，比较适合于多个独立项目或子公司上云的场景，不同项目或子公司的机器/网络资源无需互通，并且希望在财务方面能提供统一结算、合并账单、统一开票、共享资金和信用额度等功能。 模型描述如下图所示： 适用场景： 集团型企业，多个子公司上云 不同子公司资源隔离，网络或机器不需要互通 需要合并不同子公司的账单、支付和开票管理 每个子公司有独立的运维管理员 Type-III：“单账号+RAM”模型 该模型是对Type-I模型的安全增强。Type-I模型的主要缺点是多用户场景下不得不共享“主账号”或“大AK”而导致极大的安全风险。通常对一个企业客户来说，云资源的使用和运维管理都存在多用户场景，需要能支持多用户管理、细粒度授权管理与风险控制管理。RAM服务是阿里云提供的多用户管理与访问控制服务，它能很好的满足云计算业界最佳安全实践标准。模型描述如下图所示： 适用场景： 普通企业单项目上云 多用户运维管理，实现不同职责的权限分离 最佳安全实践，满足最小权限原则 Type-IV: “单账号+RAM+资源组管理”模型 由于我们越来越多的企业业务开始迁云，一个云账号下拥有上千个ECS实例、RDS实例以及PB级存储已成为普遍场景。由于缺少资源分组以及基于分组的自治权限管理，上文描述的Type-III模型将无法应对此类场景。Type-IV模型正是以解决此类大规模资源管理场景为目标，基于Type-III模型能力进行扩展，增加了资源管理服务，提供云资源的分组管理、分级授权管理、以及面向资源组的账单管理。模型描述如下图所示： 适用场景： 普通企业多项目上云 资源按项目进行分组管理 每个项目分组可以实现独立的分级权限管理 多用户运维，实现不同职责的权限分离 最佳安全实践，满足最小权限原则 按照项目分组维度查看账单 选择单账号，还是多账号？ 有了上述四种基础模型，很大程度上能直接满足大部分的客户场景。然而有的企业客户场景和需求比较复杂，而且业务模型也可能不断演变，所以有时候并不能给出一个绝对正确的方案。 比如，很多客户可能都会问到 —— “我的企业到底应该使用单个账号还是多个账号呢？” 但这个问题并没有一个千篇一律的标准答案。很多企业可能已经创建了多个账号，那么也许只能沿着多账号结构继续走下去（因为跨账号资源过户及数据迁移是一件更加挑战的事情）。如果你的企业正在规划上云的账号结构，那么如下建议可供参考。 __如果你的企业在财务管理或安全管理方面有如下诉求，那么建议使用多账号结构__: 不同BU (business unit) 或 CC (cost center) 之间的成本预算和账单消费要求100%的隔离，比如部门A的花费不能记在部门B的账上。 不同项目之间或运行环境之间需要做到最高级别的资源和安全隔离，比如要求“开发环境”与“生产环境”有严格的资源隔离和清晰的安全边界。 客户案例分析 我们提供的上述四种基本模型，很大程度上就能直接满足大部分的客户场景。然而有的企业客户场景和需求比较复杂，需要足够理解这四种模型的优劣之后才能得到有效的解决方案。 如下是一个真实的客户案例： 企业A有超过1万员工，有企业本地数据中心，信息安全系统健全，企业内部正在使用Windows AD进行员工域账号管理。企业有10个新项目要上云，平均每个项目大约需要50台ECS虚拟机及其它相关云资源，目前各个项目的资源不需要互通，但希望后续也能支持互通的可能性。希望每个项目能有独立的管理员，项目管理员能独立管理项目资源、项目成员及其权限管理。所有云资源操作人员要求使用企业本地域账号认证，禁止绕过企业本地身份认证系统而直接操作云资源。所有项目希望能合并记账，统一支付和账单管理。 针对这个客户场景，简单方案是采用Type-II模型（多账号+合并财务管理）。比如，一共申请11个云账号，每个项目对应一个云账号，最后一个云账号用于合并财务管理。然而，这一做法存在的问题有两个：(1) 如果企业未来需要实现不同项目的资源互通，尽管技术上存在可行性，但会导致相当高的管理成本；(2) 由于要实现与企业本地AD系统的身份联盟，那么就要在11个云账号下都开通RAM，域账号数据同步到每个RAM，并且还要为每个RAM都配置外部账号SSO，这也会导致相当高的技术管理成本。 因此我们会推荐采用Type-IV模型（单账号+RAM+资源组管理）来解决该客户场景问题：客户一共只需要申请1个云账号，开启RAM服务，企业域账号同步到RAM，并在RAM中开启使用外部账号SSO。在这个云账号下创建10个项目，为不同项目设置独立的管理员，那么管理员可以自治管理项目的资源和权限。云财务管理系统也将为客户提供基于资源组维度的账单管理和财务功能，因此可以更好地满足客户需要，真正有效地降低客户上云的安全管理成本。 结语 基于多租户的云资源管理与传统的企业资源管理有着本质的差别。上云之前，客户只有充分理解了云平台所提供的云资源管理模型和能力时，迁云才可能是一件充满无限魅力的事情。
看了乌云君的漏洞报告，“假如你娶了云存储，这些姿势以后就别用了”，有些震惊。企业要安全上云，还需提高自身的安全修养呀，否则可能都不知道是怎么死的。报告里提到的几个上云的“受害者”，我猜都是“豪”。在Code里硬编码AccessKey，也就算了；还把Code放在公开的Github上，也算是醉了。这无异于，把取款密码写在银行卡上，然后再把银行卡扔在大街上。 认识AccessKey（简称AK） 企业上云时，云平台会为企业提供一个仓库，企业在云上的资源（比如云存储、云虚拟机、云数据库、……）都会放在这个仓库里。AK是给企业应用程序开启这个仓库的门钥匙，它和人类用的密码是类似的。保管好AK不被泄露是客户必需的责任。还记得两年前的CodeSpaces是怎样破产的吗？就是因为上云之后AK泄露了，黑客勒索未遂，结果彻底删除CodeSpaces的所有数据以及数据备份。 为了安全地上云，企业客户需要了解一些正确的使用姿势。 姿势1：正确保护AK 密钥保护非常有挑战。最简单的一种保护方法是使用操作系统的访问控制机制来保护AK文件，比如：$ chmod 400 ~/.aliyuncli/credentials 。其次，使用密钥管理系统(KMS)来保管AK也是不错的选择，KMS通常会验证应用程序是否有正确的授权码以及源IP地址，在严格检查授权有效性之后才允许使用。最严格的保护方法要算银行类企业，它们通常会使用硬件安全模块(HSM)来保护AK，保存在这个模块里的密钥是只进不出，当模块感知到有人拿刀“切”芯片时就会冒烟自毁，所以不管多牛逼的“厨子”也是无能为力的。 姿势2：杜绝使用“大AK” AK是有“大”、“小”之分的。如果你还不知道，说明你使用的就是“大AK”。大AK，就是与云账号直接关联的AK，它代表的是云账号的所有权限。如果你在使用大AK —— 一旦这个大AK泄露，后果很严重，CodeSpaces的破产就是前车之鉴。 为了让企业应用程序能安全地工作，阿里云访问控制服务(RAM)允许云账号为应用程序创建一种“小AK”，这个小AK代表应用程序的身份，其访问权限可以被定制。根据最小权限原则，企业应该为应用程序提供刚好满足其功能所需的最小权限。 举个例子，如果应用程序只需要读取阿里云OSS的mybucket空间中hangzhou目录下的所有对象文件，那么就可以为小AK精确定制这一授权策略，如下： { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:GetObject", "Resource": "acs:oss:*:*:mybucket/hangzhou/*" } ] } 使用这种方法后，假若企业应用程序的“小AK”被泄露，最糟糕的情况就是黑客也能读取OSS目录mybucket/hangzhou/下的所有对象文件，而仓库里的其它资产仍然安全无恙。 姿势3：限制应用程序的访问源IP 为了彻底防止因AK泄露所导致的风险，阿里云提供了针对应用程序的访问源IP限制。企业可以根据需要来设定访问云上仓库的源IP地址列表，应用程序发送操作请求的源IP地址如果不符合要求，那么就会被拒绝。只有源IP地址正确时，权限检查才会通过。 还是接着上面的例子，假设企业应用程序部署在一个确定的IP地址范围，如 42.120.99.0/24，那么带IP限制条件的授权策略如下： { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:GetObject", "Resource": "acs:oss:*:*:mybucket/hangzhou/*", "Condition": { "IpAddress": { "acs:SourceIp": "42.120.88.0/24" } } } ] } 这样的话，即使黑客盗取了应用程序的“小AK”，然并卵。。。 姿势4：为iOS或Android应用颁发临时访问令牌(Token) 永远不要将AK写到iOS或Android应用里。虽然App应用是企业开发的，但安装App的iOS或Android设备并不受企业的控制，记住永远不要将秘密放在不受控制的地方。如果AK写到了App里，控制App设备的人总是可能猎取到AK，并且可能任意传播猎取的AK。一旦出现这种情况，开启源IP限制也于事无补，因为App用户的IP地址一般是无法确定的，开启源IP限制还会误伤其他正常用户。 对于这种场景，从安全角度看，只能给iOS或Android应用做临时授权，如5分钟自动失效；而且必须授予最小权限，如每一App用户能访问的子目录都是不一样的。只有做到“最小权限+最短时效”，数据安全风险才能得到有效的控制。 为此，阿里云提供了安全令牌服务(STS)来解决这类问题，基本思路如下图所示： 0. AppServer使用“小AK”，为“小AK”配置最小权限以及源IP限制。比如，AppServer的最小权限可能是这样 —— “不允许直接访问仓库里的OSS数据，只能访问STS来颁发Token，而且颁发出来的Token权限只能访问oss://mybucket/hangzhou/这个目录”。 1. 为每个App用户颁发满足“最小权限+最短时效”的Token。比如，App用户厨子只需访问oss://mybucket/hangzhou/<厨子>/ 这个目录，只需要访问1次，那么就为厨子的App颁发满足这一权限和最短时效的Token。 2. AppServer获取Token后，通过安全链路（如HTTPS）将Token传递给App。 3. App使用Token访问云上仓库（如OSS）。 下面我们来简单分析下安全性： (1) 如果AppServer被攻击，黑客获取小AK，然并卵。首先，这个小AK不具备直接访问OSS数据的权限，它只能被用于调用STS获取Token。其次，黑客如果先通过STS获取Token再用Token访问OSS的话，也不可行的，因为小AK是受源IP限制的，无法在公网上任意使用；即使黑客知道这个受信的IP列表，实施ip spoofing攻击的难度也很大，因为公网路由器基本上都会做reverse path filter。 (2) 如果App用户厨子是个Geek，她能猎取到的所有秘密也就是一个“最小权限+最短时效”的Token，然并卵。因为这个小Token只能访问厨子自己应该访问的数据，猎取到这个Token并不能进行提权攻击。如果她故意把这个Token泄露出去，那就是搬石头砸自己的脚。 所以，建议乌云君报告里提到的“敢聊”，可以试试阿里云的OSS + STS解决方案，绝对可以确保App用户的照片和语音等隐私数据不会泄露。 欲知更多安全姿势，请移步云产品安全最佳实践。 结语 有云的地方就有恩怨，有恩怨的地方就有江湖，云就是江湖。上云，还是要多备些安全锦囊，以防患于未然。 One More Thing ... 你懂的……
发表了文章
2018-11-17
发表了文章
2018-01-29
发表了文章
2018-01-19
发表了文章
2018-01-07
发表了文章
2018-01-06
发表了文章
2017-11-24
发表了文章
2016-06-23
