摘要：典型的配置中心產(chǎn)品，包括如上文提到的阿里云早期稱為，攜程，百度的，或者，等。而最近，作為一款配置中心產(chǎn)品，阿里云應(yīng)用配置管理簡稱發(fā)布了一項加密配置功能，就旨在讓用戶更加安全的在配置中心存放配置。這在阿里云的安全體系中，通過的角色授權(quán)來實現(xiàn)。

摘要： 如果您現(xiàn)在正開始著手準備解決自己的生產(chǎn)數(shù)據(jù)泄露問題，那么您可能需要看下這篇文檔，了解如何可以從配置著手來改善下您目前的情況。

您是否在您的應(yīng)用部署環(huán)境里遇到過以下情節(jié)

將敏感信息(如數(shù)據(jù)庫連接串,含密碼,下同)存放到生產(chǎn)環(huán)境的服務(wù)器上的配置文件里。
將敏感信息做成配置文件打包在軟件工程的配置文件里，并發(fā)布到各類環(huán)境里。
在Docker編排時，將敏感信息直接存放到環(huán)境變量中。
如果您的生產(chǎn)環(huán)境存在以下情況，而您現(xiàn)在又開始著手準備解決自己的生產(chǎn)數(shù)據(jù)泄露問題，那么您可能需要看下這篇文檔，了解如何可以從配置著手來改善下您目前的情況。

理解這方面的潛在威脅，可穿梭閱讀:

云泄露：Verizon公司超1400萬用戶信息外泄
亞信安全盤點2017年十大數(shù)據(jù)泄露事件
理解這方面的要求，可穿梭閱讀：

等保信息安全技術(shù) 信息系統(tǒng)安全等級保護基本要求 第三級
注：等保一共五級，第三級定義為："信息系統(tǒng)受到破壞后，會對社會秩序和公共利益造成嚴重損害，或者對國家安全造成損害。國家信息安全監(jiān)管部門對該級信息系統(tǒng)安全等級保護工作進行監(jiān)督、檢查。該級別為現(xiàn)在大多數(shù)企業(yè)所采納。
配置的發(fā)展簡史和安全問題概述
大體來講，配置的發(fā)展史如下圖示。

靜態(tài)明文配置：最初的配置方式，將配置以明文文件或者環(huán)境變量方式放置在本地。
基于配置中心的明文配置：隨著微服務(wù)和配置中心技術(shù)興起(阿里云ACM - 早期稱為 Diamond，攜程Apollo，百度的Disconf，或者Spring Cloud Config，等)，配置開始往配置中心轉(zhuǎn)移。
基于配置中心的配置安全加強：配置中心開始集成各類安全工具，以做到配置增強，典型如AWS Parameter Store。
關(guān)于前兩個方式的問題簡述如下。

靜態(tài)明文配置的安全問題
在分布式互聯(lián)網(wǎng)架構(gòu)之前，早期的配置是存放在靜態(tài)文件中。例如，數(shù)據(jù)庫的連接信息(包含密碼)，通過手動打包的方式在各個環(huán)境(開發(fā)，測試，預(yù)發(fā)，生產(chǎn)，等)。如下圖所示：

而這種部署方式最大的問題是在配置文件中將存放大量的敏感信息，使得無論開發(fā)測試還是運維人員，獲得敏感數(shù)據(jù)的成本極低。雖然打包部署的方式一直在演化，如從靜態(tài)文件配置打靜態(tài)打包分環(huán)境部署，再到容器編排，但是本質(zhì)上靜態(tài)文件配置的方式?jīng)]有變化，而且隨著部署工具的自動化，其配置的安全問題反而暴露得更加嚴重，如：

多環(huán)境打包發(fā)布中，開發(fā)工程內(nèi)將包含應(yīng)用的所有敏感信息，敏感信息讓內(nèi)部員工極易獲得。
容器編排系統(tǒng)中，同樣將包含應(yīng)用的所有敏感信息，而且大多容器編排系統(tǒng)通過傳遞環(huán)境變量的方式來傳遞系統(tǒng)敏感信息，這些信息在容器容器內(nèi)是明文顯示，直接通過環(huán)境變量即能獲取。
基于配置中心的明文配置安全問題
隨著配置中心的興起，越來越多的應(yīng)用配置開始朝配置中心轉(zhuǎn)移。典型的配置中心產(chǎn)品，包括如上文提到的阿里云ACM(早期稱為 Diamond)，攜程Apollo，百度的Disconf，或者Spring Cloud Config，等。

配置中心對于配置文件的方式來講，其最大的好處是配置和發(fā)布解耦的同時，配置還可以動態(tài)修改和下發(fā)。關(guān)于配置中心其他的好處和各種場景，不是本文的重點，如用戶對場景感興趣，可參閱配置中心使用場景.

這里主要敘述下配置中心對配置安全方面產(chǎn)生的影響。配置中心存放配置的簡單示意圖如下圖所示。

配置中心對應(yīng)用配置在安全方面產(chǎn)生的影響主要有以下幾個：

配置不再需要明文存放在服務(wù)端。在應(yīng)用程序端，存放的是配置中心連接信息，而不帶任何敏感數(shù)據(jù)。所有配置具體信息都存放在配置中心處。在應(yīng)用程序側(cè)，可選擇配置信息全程走內(nèi)存，而不持久化到本地硬盤中，盡最大可能保證敏感信息不外泄。
與此同時，敏感信息存放被多帶帶剝離出來存放到了配置中心，所有配置信息可通過分級配置保證不同的管理員僅接觸到自己需要的那部分配置信息。
基于配置中心的配置管理從安全上解決了生產(chǎn)環(huán)境上解決敏感信息外泄的問題。但是造成的另外一個問題是對配置中心本身的安全性問題?？v觀以上幾款配置中心的產(chǎn)品設(shè)計，幾乎所有產(chǎn)品都是將實際配置明文存放。如果配置中心本身被攻破，上面集中存放的所有敏感信息將全部外泄。這在今天上云的時代，對于提供配置中心服務(wù)的云廠商而言，當(dāng)面向類似等保三級的安全合規(guī)審計的時候，這點挑戰(zhàn)尤其嚴峻。

ACM 的配置安全加固措施
基于配置中心的配置安全加強將日益成為配置中心安全方面的剛需。而最近，作為一款配置中心產(chǎn)品，阿里云應(yīng)用配置管理(簡稱ACM)發(fā)布了一項"加密配置"功能，就旨在讓用戶更加安全的在配置中心存放配置。以下章節(jié)描述其功能細節(jié)。

ACM 加密配置管理設(shè)計概要
阿里云應(yīng)用配置管理(簡稱ACM)在最近的發(fā)布版本中公布的一項針對配置安全的功能，主要是其過一系列和相關(guān)配置安全產(chǎn)品的打通來為用戶創(chuàng)建所謂"加密配置" (Security Configuration)，來徹底解決上述的配置中心配置安全性問題。ACM解決安全問題的思路和其他業(yè)界領(lǐng)先的配置中心產(chǎn)品(如AWS Parameter Store)類似，其并不是自身來獨立解決安全問題，而是和周邊的相關(guān)安全產(chǎn)品整合來聯(lián)合解決安全問題。當(dāng)然，自身足夠安全也很重要，但是為了避免既當(dāng)運動員又當(dāng)裁判，同時又避免讓用戶感覺雞蛋放在一個籃子里，選擇中立的安全產(chǎn)品進行整合客觀上顯得亦為重要。讓我們來詳細看看ACM是怎么做的。

在這方面，阿里云ACM是通過RAM，KMS三個產(chǎn)品聯(lián)合來解決這個問題。為了方便讀者理解這三個產(chǎn)品，以下列出產(chǎn)品傳送門：

應(yīng)用配置管理（Application Configuration Management，簡稱 ACM），其前身為淘寶內(nèi)部配置中心 Diamond，是一款應(yīng)用配置中心產(chǎn)品?；谠搼?yīng)用配置中心產(chǎn)品，您可以在微服務(wù)、DevOps、大數(shù)據(jù)等場景下極大地減輕配置管理的工作量，增強配置管理的服務(wù)能力。]。
密鑰管理服務(wù)（KeyManagementService）是一款安全易用的管理類服務(wù)。您無需花費大量成本來保護密鑰的保密性、完整性和可用性，借助密鑰管理服務(wù)，您可以安全、便捷的使用密鑰，專注于開發(fā)您需要的加解密功能場景。
訪問控制（Resource Access Management）是一個穩(wěn)定可靠的集中式訪問控制服務(wù)。您可以通過訪問控制將阿里云資源的訪問及管理權(quán)限分配給您的企業(yè)成員或合作伙伴。
以下簡述三個產(chǎn)品在ACM 加密配置中起到的作用。

ACM: 主要功能還是起到配置的存放和發(fā)放功能。但是在加密配置解決方案中，ACM將安全的功能大部分轉(zhuǎn)移到KMS中。ACM服務(wù)端中存放的配置是經(jīng)過KMS加密的配置，且ACM服務(wù)端本身并不直接提供解密功能，借此大大提高配置的安全性。在讀取加密配置的環(huán)節(jié)中，配置最終通過ACM客戶端調(diào)用KMS進行解密。
KMS：在加密配置管理中，主要為用戶提供加解密的服務(wù)。用戶基于KMS在ACM進行配置加解密時既可指定自己定制的密鑰對，也可以使用ACM提供的默認KMS的密鑰對，以簡化管理。
RAM：在阿里云的產(chǎn)品體系中，各個產(chǎn)品之間服務(wù)賬號各自獨立。也就是說，ACM控制臺本身是沒有辦法訪問用戶的KMS的密鑰配置的。然而在ACM控制臺上，由于方便配置管理，用戶需要在ACM控制臺上對配置進行加密操作，因此就需要ACM控制臺對用戶的KMS密鑰對有一定最小操作權(quán)限。這在阿里云的安全體系中，通過 RAM 的 角色授權(quán) 來實現(xiàn)。
通過以下章節(jié)我們來看看ACM在配置安全這塊是怎么做的。

ACM 加密配置原理解析
ACM 加密配置的核心思路是通過KMS來對配置進行加解密。以下詳述。

用戶開通流程
首先看下如果用戶要使用ACM的加密配置功能，需要走哪些流程。如下圖所示。

步驟說明如下：

開通 ACM, 這是必然的。
開通 KMS，這也是當(dāng)然的。
在RAM上授權(quán)ACM一個可以讀取用戶的KMS加密功能的最小權(quán)限角色。這步很關(guān)鍵，否則作為多帶帶產(chǎn)品，ACM是無法使用用戶KMS中的密鑰的。
用戶在ACM控制臺寫入加密配置流程
用戶在ACM控制臺寫入加密配置流程以下圖為例：

步驟詳解：

用戶在ACM控制臺寫人一個配置，并在控制臺上設(shè)置其為加密配置
ACM識別其為一個加密配置，需要依賴用戶的KMS密鑰。此時ACM會調(diào)用RAM，通過認證獲得用戶的之前授權(quán)ACM的一個可以讀取KMS加密功能的最小權(quán)限角色。
ACM使用該角色，通過調(diào)用KMS API，使用用戶的KMS密鑰對對用戶存放在ACM控制臺上的配置進行密文加密。
ACM控制臺將加密后的配置存放在ACM配置數(shù)據(jù)庫中。
從以上過程中，可以看出，

ACM保存的配置都是密文，而且本身不保存密鑰，即使配置信息被泄露，也無法獲取到配置明文。
ACM通過RAM授權(quán)來操作用戶的KMS密鑰，該授權(quán)的角色只允許ACM對配置加解密相關(guān)的操作授權(quán)，不會有其他權(quán)限(如刪除密鑰對等操作)，最大程度杜絕額外的安全隱患。
理論上，以上環(huán)節(jié)中，用戶在寫入配置時，也可以完全不依賴ACM的控制臺功能，而通過KMS加密后，直接在控制臺操作寫入。當(dāng)然，這會帶來很大易用性問題。在ACM的加密配置寫入流程設(shè)計中，通過和RAM角色授權(quán)打通來調(diào)用KMS，既保證了安全性，又為用戶在創(chuàng)建配置時帶來了極大的便利性，是一種非常平衡的折中方案。

應(yīng)用通過ACM SDK讀取加密配置流程
應(yīng)用通過ACM SDK讀取加密配置流程以下圖為例：

步驟詳解：

程序讀取ACM配置ID
程序啟動，讀取ACM密文配置
ACM Client識別該配置為密文配置，則KMS Client透明解密密文配置，返回明文配置
程序讀取明文配置，鏈接數(shù)據(jù)庫，明文配置不落盤，保證安全。
從以上過程中，可以看出，

在應(yīng)用側(cè)，其配置本身不含任何敏感數(shù)據(jù)，只包含一個ACM Client需要讀取的配置項。
在實際使用過程中，ACM SDK將打包ACM Client和KMS Client調(diào)用，具體調(diào)用信息對應(yīng)用程序透明。
ACM 加密配置總結(jié)
從以上章節(jié)可以看出，ACM的加密配置在安全和易用性上做到了較好均衡。

在易用性方面無論是配置寫入還是配置讀出，服務(wù)端和客戶端都做到了較好的透明。
在安全性方面，通過RAM和KMS集成，保證配置能以足夠安全的通道進行加密，并在存儲端密文存放。
以上做法較好的滿足了現(xiàn)在主流的等保三級的合規(guī)目標，切實滿足了大部分企業(yè)用戶的安全需求。

衍生閱讀：等保信息安全技術(shù) 信息系統(tǒng)安全等級保護基本要求 第三級

讓您的配置在云上更加安全
作為一款面向配置中心，專注于用戶配置的產(chǎn)品，ACM在上云時代首要目標將是保證用戶的配置安全。在這個基礎(chǔ)上，ACM將和更多的阿里云產(chǎn)品通過友好的整合方式來保護用戶配置安全，其場景將包含但不限于：

容器服務(wù)的配置安全存放。
ECS彈性伸縮的配置安全存放。
其他各類PaaS服務(wù)鏈接的配置安全存放。

原文鏈接