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

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

您是否在您的應用部署環境里遇到過以下情節

將敏感信息(如數據庫連接串,含密碼,下同)存放到生產環境的服務器上的配置文件里。
將敏感信息做成配置文件打包在軟件工程的配置文件里，并發布到各類環境里。
在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服務鏈接的配置安全存放。

原文鏈接