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

摘要: 若是您如今正开始着手准备解决本身的生产数据泄露问题,那么您可能须要看下这篇文档,了解如何能够从配置着手来改善下您目前的状况。html

您是否在您的应用部署环境里遇到过如下情节数据库

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

若是您的生产环境存在如下状况,而您如今又开始着手准备解决本身的生产数据泄露问题,那么您可能须要看下这篇文档,了解如何能够从配置着手来改善下您目前的状况。安全

理解这方面的潜在威胁,可穿梭阅读:服务器

理解这方面的要求,可穿梭阅读:架构

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

配置的发展简史和安全问题概述

大致来说,配置的发展史以下图示。
并发

  • 静态明文配置:最初的配置方式,将配置以明文文件或者环境变量方式放置在本地。
  • 基于配置中心的明文配置:随着微服务和配置中心技术兴起(阿里云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控制台写入加密配置流程如下图为例:

步骤详解:

  1. 用户在ACM控制台写人一个配置,并在控制台上设置其为加密配置
  2. ACM识别其为一个加密配置,须要依赖用户的KMS密钥。此时ACM会调用RAM,经过认证得到用户的以前受权ACM的一个能够读取KMS加密功能的最小权限角色。
  3. ACM使用该角色,经过调用KMS API,使用用户的KMS密钥对对用户存放在ACM控制台上的配置进行密文加密。
  4. ACM控制台将加密后的配置存放在ACM配置数据库中。

从以上过程当中,能够看出,

  • ACM保存的配置都是密文,并且自己不保存密钥,即便配置信息被泄露,也没法获取到配置明文。
  • ACM经过RAM受权来操做用户的KMS密钥,该受权的角色只容许ACM对配置加解密相关的操做受权,不会有其余权限(如删除密钥对等操做),最大程度杜绝额外的安全隐患。

理论上,以上环节中,用户在写入配置时,也能够彻底不依赖ACM的控制台功能,而经过KMS加密后,直接在控制台操做写入。固然,这会带来很大易用性问题。在ACM的加密配置写入流程设计中,经过和RAM角色受权打通来调用KMS,既保证了安全性,又为用户在建立配置时带来了极大的便利性,是一种很是平衡的折中方案。

应用经过ACM SDK读取加密配置流程

应用经过ACM SDK读取加密配置流程如下图为例:

步骤详解:

  1. 程序读取ACM配置ID
  2. 程序启动,读取ACM密文配置
  3. ACM Client识别该配置为密文配置,则KMS Client透明解密密文配置,返回明文配置
  4. 程序读取明文配置,连接数据库,明文配置不落盘,保证安全。

从以上过程当中,能够看出,

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

ACM 加密配置总结

从以上章节能够看出,ACM的加密配置在安全和易用性上作到了较好均衡。

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

以上作法较好的知足了如今主流的等保三级的合规目标,切实知足了大部分企业用户的安全需求。

衍生阅读:等保信息安全技术 信息系统安全等级保护基本要求 第三级

让您的配置在云上更加安全

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

  • 容器服务的配置安全存放。
  • ECS弹性伸缩的配置安全存放。
  • 其余各种PaaS服务连接的配置安全存放。

原文连接

相关文章
相关标签/搜索