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

摘要： 若是您如今正開始着手準備解決本身的生產數據泄露問題，那麼您可能須要看下這篇文檔，瞭解如何能夠從配置着手來改善下您目前的狀況。

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

• 將敏感信息(如數據庫鏈接串,含密碼,下同)存放到生產環境的服務器上的配置文件裏。
• 將敏感信息作成配置文件打包在軟件工程的配置文件裏，併發布到各種環境裏。
• 在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控制檯寫入加密配置流程如下圖爲例：

步驟詳解：

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服務連接的配置安全存放。

原文連接