如何在阿里云上安全的存放您的配置

摘要：如果您现在正开始着手准备解决自己的生产数据泄露问题，那么您可能需要看下这篇文档，了解如何可以从配置着手来改善下您目前的情况。 您是否在您的应用部署环境里遇到过以下情节

• 将敏感信息(如数据库连接串,含密码,下同)存放到生产环境的服务器上的配置文件里。
• 将敏感信息做成配置文件打包在软件工程的配置文件里，并发布到各类环境里。
• 在Docker编排时，将敏感信息直接存放到环境变量中。
  

如果您的生产环境存在以下情况，而您现在又开始着手准备解决自己的生产数据泄露问题，那么您可能需要看下这篇文档，了解如何可以从配置着手来改善下您目前的情况。 理解这方面的潜在威胁，可穿梭阅读:

• 云泄露：Verizon公司超1400万用户信息外泄
• 亚信安全盘点2017年十大数据泄露事件
  

理解这方面的要求，可穿梭阅读：

• 等保信息安全技术 信息系统安全等级保护基本要求 第三级
• 注：等保一共五级，第三级定义为："信息系统受到破坏后，会对社会秩序和公共利益造成严重损害，或者对国家安全造成损害。国家信息安全监管部门对该级信息系统安全等级保护工作进行监督、检查。该级别为现在大多数企业所采纳。
  

配置的发展简史和安全问题概述 大体来讲，配置的发展史如下图示。

• 静态明文配置：最初的配置方式，将配置以明文文件或者环境变量方式放置在本地。
• 基于配置中心的明文配置：随着微服务和配置中心技术兴起(阿里云ACM - 早期称为 Diamond，携程Apollo，百度的Disconf，或者Spring Cloud Config，等)，配置开始往配置中心转移。
• 基于配置中心的配置安全加强：配置中心开始集成各类安全工具，以做到配置增强，典型如AWS Parameter Store。
  

关于前两个方式的问题简述如下。 静态明文配置的安全问题 在分布式互联网架构之前，早期的配置是存放在静态文件中。例如，数据库的连接信息(包含密码)，通过手动打包的方式在各个环境(开发，测试，预发，生产，等)。如下图所示：
而这种部署方式最大的问题是在配置文件中将存放大量的敏感信息，使得无论开发测试还是运维人员，获得敏感数据的成本极低。虽然打包部署的方式一直在演化，如从静态文件配置打静态打包分环境部署，再到容器编排，但是本质上静态文件配置的方式没有变化，而且随着部署工具的自动化，其配置的安全问题反而暴露得更加严重，如：

• 多环境打包发布中，开发工程内将包含应用的所有敏感信息，敏感信息让内部员工极易获得。
• 容器编排系统中，同样将包含应用的所有敏感信息，而且大多容器编排系统通过传递环境变量的方式来传递系统敏感信息，这些信息在容器容器内是明文显示，直接通过环境变量即能获取。
  

基于配置中心的明文配置安全问题 随着配置中心的兴起，越来越多的应用配置开始朝配置中心转移。典型的配置中心产品，包括如上文提到的阿里云ACM(早期称为 Diamond)，携程Apollo，百度的Disconf，或者Spring Cloud Config，等。 配置中心对于配置文件的方式来讲，其最大的好处是配置和发布解耦的同时，配置还可以动态修改和下发。关于配置中心其他的好处和各种场景，不是本文的重点，如用户对场景感兴趣，可参阅配置中心使用场景. 这里主要叙述下配置中心对配置安全方面产生的影响。配置中心存放配置的简单示意图如下图所示。
配置中心对应用配置在安全方面产生的影响主要有以下几个：

• 配置不再需要明文存放在服务端。在应用程序端，存放的是配置中心连接信息，而不带任何敏感数据。所有配置具体信息都存放在配置中心处。在应用程序侧，可选择配置信息全程走内存，而不持久化到本地硬盘中，尽最大可能保证敏感信息不外泄。
• 与此同时，敏感信息存放被单独剥离出来存放到了配置中心，所有配置信息可通过分级配置保证不同的管理员仅接触到自己需要的那部分配置信息。
  

基于配置中心的配置管理从安全上解决了生产环境上解决敏感信息外泄的问题。但是造成的另外一个问题是对配置中心本身的安全性问题。纵观以上几款配置中心的产品设计，几乎所有产品都是将实际配置明文存放。如果配置中心本身被攻破，上面集中存放的所有敏感信息将全部外泄。这在今天上云的时代，对于提供配置中心服务的云厂商而言，当面向类似等保三级的安全合规审计的时候，这点挑战尤其严峻。 ACM 的配置安全加固措施 基于配置中心的配置安全加强将日益成为配置中心安全方面的刚需。而最近，作为一款配置中心产品，阿里云应用配置管理(简称ACM)发布了一项"加密配置"功能，就旨在让用户更加安全的在配置中心存放配置。以下章节描述其功能细节。 ACM 加密配置管理设计概要 阿里云应用配置管理(简称ACM)在最近的发布版本中公布的一项针对配置安全的功能，主要是其过一系列和相关配置安全产品的打通来为用户创建所谓"加密配置" (Security Configuration)，来彻底解决上述的配置中心配置安全性问题。ACM解决安全问题的思路和其他业界领先的配置中心产品(如AWS Parameter Store)类似，其并不是自身来独立解决安全问题，而是和周边的相关安全产品整合来联合解决安全问题。当然，自身足够安全也很重要，但是为了避免既当运动员又当裁判，同时又避免让用户感觉鸡蛋放在一个篮子里，选择中立的安全产品进行整合客观上显得亦为重要。让我们来详细看看ACM是怎么做的。 在这方面，阿里云ACM是通过RAM，KMS三个产品联合来解决这个问题。为了方便读者理解这三个产品，以下列出产品传送门：

• 应用配置管理（Application Configuration Management，简称 ACM），其前身为淘宝内部配置中心 Diamond，是一款应用配置中心产品。基于该应用配置中心产品，您可以在微服务、DevOps、大数据等场景下极大地减轻配置管理的工作量，增强配置管理的服务能力。]。
• 密钥管理服务（KeyManagementService）是一款安全易用的管理类服务。您无需花费大量成本来保护密钥的保密性、完整性和可用性，借助密钥管理服务，您可以安全、便捷的使用密钥，专注于开发您需要的加解密功能场景。
• 访问控制（Resource Access Management）是一个稳定可靠的集中式访问控制服务。您可以通过访问控制将阿里云资源的访问及管理权限分配给您的企业成员或合作伙伴。
  

以下简述三个产品在ACM 加密配置中起到的作用。

• ACM: 主要功能还是起到配置的存放和发放功能。但是在加密配置解决方案中，ACM将安全的功能大部分转移到KMS中。ACM服务端中存放的配置是经过KMS加密的配置，且ACM服务端本身并不直接提供解密功能，借此大大提高配置的安全性。在读取加密配置的环节中，配置最终通过ACM客户端调用KMS进行解密。
• KMS：在加密配置管理中，主要为用户提供加解密的服务。用户基于KMS在ACM进行配置加解密时既可指定自己定制的密钥对，也可以使用ACM提供的默认KMS的密钥对，以简化管理。
• RAM：在阿里云的产品体系中，各个产品之间服务账号各自独立。也就是说，ACM控制台本身是没有办法访问用户的KMS的密钥配置的。然而在ACM控制台上，由于方便配置管理，用户需要在ACM控制台上对配置进行加密操作，因此就需要ACM控制台对用户的KMS密钥对有一定最小操作权限。这在阿里云的安全体系中，通过 RAM 的角色授权来实现。
  

通过以下章节我们来看看ACM在配置安全这块是怎么做的。 ACM 加密配置原理解析 ACM 加密配置的核心思路是通过KMS来对配置进行加解密。以下详述。 用户开通流程 首先看下如果用户要使用ACM的加密配置功能，需要走哪些流程。如下图所示。
步骤说明如下：

• 开通 ACM, 这是必然的。
• 开通 KMS，这也是当然的。
• 在RAM上授权ACM一个可以读取用户的KMS加密功能的最小权限角色。这步很关键，否则作为单独产品，ACM是无法使用用户KMS中的密钥的。
  

用户在ACM控制台写入加密配置流程 用户在ACM控制台写入加密配置流程以下图为例：
步骤详解：

• 用户在ACM控制台写人一个配置，并在控制台上设置其为加密配置
• ACM识别其为一个加密配置，需要依赖用户的KMS密钥。此时ACM会调用RAM，通过认证获得用户的之前授权ACM的一个可以读取KMS加密功能的最小权限角色。
• ACM使用该角色，通过调用KMS API，使用用户的KMS密钥对对用户存放在ACM控制台上的配置进行密文加密。
• ACM控制台将加密后的配置存放在ACM配置数据库中。
  

从以上过程中，可以看出，

• ACM保存的配置都是密文，而且本身不保存密钥，即使配置信息被泄露，也无法获取到配置明文。
• ACM通过RAM授权来操作用户的KMS密钥，该授权的角色只允许ACM对配置加解密相关的操作授权，不会有其他权限(如删除密钥对等操作)，最大程度杜绝额外的安全隐患。
  

理论上，以上环节中，用户在写入配置时，也可以完全不依赖ACM的控制台功能，而通过KMS加密后，直接在控制台操作写入。当然，这会带来很大易用性问题。在ACM的加密配置写入流程设计中，通过和RAM角色授权打通来调用KMS，既保证了安全性，又为用户在创建配置时带来了极大的便利性，是一种非常平衡的折中方案。 应用通过ACM SDK读取加密配置流程 应用通过ACM SDK读取加密配置流程以下图为例：
步骤详解：

• 程序读取ACM配置ID
• 程序启动，读取ACM密文配置
• ACM Client识别该配置为密文配置，则KMS Client透明解密密文配置，返回明文配置
• 程序读取明文配置，链接数据库，明文配置不落盘，保证安全。
  

从以上过程中，可以看出，

• 在应用侧，其配置本身不含任何敏感数据，只包含一个ACM Client需要读取的配置项。
• 在实际使用过程中，ACM SDK将打包ACM Client和KMS Client调用，具体调用信息对应用程序透明。
  

ACM 加密配置总结 从以上章节可以看出，ACM的加密配置在安全和易用性上做到了较好均衡。

• 在易用性方面无论是配置写入还是配置读出，服务端和客户端都做到了较好的透明。
• 在安全性方面，通过RAM和KMS集成，保证配置能以足够安全的通道进行加密，并在存储端密文存放。
  

以上做法较好的满足了现在主流的等保三级的合规目标，切实满足了大部分企业用户的安全需求。 衍生阅读：等保信息安全技术 信息系统安全等级保护基本要求 第三级

让您的配置在云上更加安全 作为一款面向配置中心，专注于用户配置的产品，ACM在上云时代首要目标将是保证用户的配置安全。在这个基础上，ACM将和更多的阿里云产品通过友好的整合方式来保护用户配置安全，其场景将包含但不限于：

• 容器服务的配置安全存放。
• ECS弹性伸缩的配置安全存放。
• 其他各类PaaS服务链接的配置安全存放。
  

原文链接