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

摘要: 如果您现在正开始着手准备解决自己的生产数据泄露问题,那么您可能需要看下这篇文档,了解如何可以从配置着手来改善下您目前的情况。

您是否在您的应用部署环境里遇到过以下情节

  • 将敏感信息(如数据库连接串,含密码,下同)存放到生产环境的服务器上的配置文件里。
  • 将敏感信息做成配置文件打包在软件工程的配置文件里,并发布到各类环境里。
  • 在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服务链接的配置安全存放。

原文链接

原文地址:http://blog.51cto.com/13679539/2121259

时间: 2024-10-08 02:22:08

如何在阿里云上安全的存放您的配置的相关文章

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

摘要: 在之前文章中,其中一个遗留问题是如何存放访问ACM配置本身的敏感信息,比如要访问ACM本身需要的AccessKey ID(简称AK)或Secret AccessKey(简称SK)如何存放,即所谓敏感配置的"最后一公里"问题. 在<如何在阿里云上安全的存放您的配置>一文中,我们介绍了如何通过ACM存放您的敏感配置,并进行加密.这样做的目的有两个: 在应用程序或对应生产环境容器或系统中,无需持久化任何敏感数据信息(如数据库连接串,等),以防止生产环境或开发过程中的敏感信

云计算之路-阿里云上:SLB会话保持的一个坑

冒着被大家厌烦的风险,今天再发一篇"云计算之路-阿里云上".这是在前一篇发过之后真实发生的事情,我们觉得定位问题的过程值得分享.而且估计园子里不少朋友被这个问题骚扰过,我们有责任让大家知道问题的真正原因. 快下班之前,园区里另外一家公司的朋友说他们公司有的人不能正常访问园子--会出现HTTP Error 400错误,而其他人可以正常访问.这个问题立即引起了我们的警觉,因为之前也有园友反馈过同样的问题,当时什么也没动,后来就好了,以为是他们公司网络代理服务器的问题.由于我们从未遇到过这个

阿里云上Oracle 11g RAC安装配置手册

有印象的用户可能发现,阿里云早在2016年深圳云栖大会就官方发布了对Oracle RAC的支持,但是相关产品却一直没能同步推出,相信大家都翘首以盼了许久许久.一个好消息是,近期阿里云将紧密推出两款新产品:共享块存储和ECS多网卡.这两款产品将打通众多关键云下应用上云的最后一公里,为用户提供更多的便利.在我们能正式体验到新产品之前,阿里云技术服务团队也将云上的Oracle RAC安装配置手册放出,希望能给大家提供更多不同的体验和选择. 一.安装说明 阿里云上Oracle RAC的安装部署,重点需要

阿里云上如何搭建jenkins

一. 安装jdk 确保安装jenkins前jdk已经安装,如何安装见<如何在阿里云上部署war包到tomcat服务器> 二. 安装jenkins 使用以下命令安装jenkins: wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo rpm –import https://jenkins-ci.org/redhat/jenkins-ci.org.key yum install je

如何在阿里云上构建一个合适的Kubernetes集群

摘要: 声明 本文主要介绍如何在阿里云上构建一个K8S集群的实践,只是作为参考,大家可以根据实际情况做出调整. 集群规划 在实际案例中发现,有不少同学使用了很多的小规格的ECS来构建K8S集群,这样其实即没有达到省钱的目的,也没有很好的发挥K8S集群的优势. 声明 本文主要介绍如何在阿里云上构建一个K8S集群的实践,只是作为参考,大家可以根据实际情况做出调整. 集群规划 在实际案例中发现,有不少同学使用了很多的小规格的ECS来构建K8S集群,这样其实即没有达到省钱的目的,也没有很好的发挥K8S集

云计算之路-阿里云上-容器难容:自建docker swarm集群遭遇无法解决的问题

我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭遇了恐怖的路由服务(acsrouting)路由错乱问题 —— 请求被随机路由到集群中的任一容器,虽然后来阿里云修复了这个问题,但我们对容器服务失去了信心,走上了用阿里云服务器自建 docker swarm 集群的道路. 用上自建 docker swarm 集群之后,本以为可以在云上容器中过上安稳的日

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

远程登录阿里云上的MySQL

最近对云和服务器之类的感兴趣,想要将自己的数据什么的保存到远端服务器.研究了阿里云和百度云.今天算是有点进步吧. 我在阿里云上申请了个免费的云服务器(ECS),很可惜只能用5天.我也不太懂他的性能怎么样..反正能用吧.哈哈 上图吧. 1.主机终端管理:由于对Ubuntu 还算熟悉,我选了装ubuntu 的主机,在"更多操作"选项中,选择"连接终端",进入连接页面,按照提示输入"VNC"密码,就进入了主机系统,不过是命令行的终端 . 2.MySQL

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后