作者介紹：
錢芳園
專注資料庫和資料庫自動化領域的工程師，擅長 MySQL、Redis 運維以及基于 go 語言的資料庫自動化開發。
一、背景
新一代去哪兒資料庫自動化平台設計整體架構如下：
架構說明：
【1】平台是分層建構，不同層級的子產品功能專注不同的功能，上圖隻是列出部分子產品。
【2】Server 是整個架構的初始化子產品，也是整個平台的管控節點。
【3】Meta 是整個架構的中繼資料中心。
【4】每個子產品都是獨立的存在，同一層級的子產品之間可以互相調用，低層級的子產品不能主動調用高層級的子產品。
根據自動化平台的規劃，平台需要部署一套 Agent 和各種 Plugin 在目标伺服器上，Agent 和 Plugin 具備執行各種指令、任務。但是 Agent/Plugin 需要與 Server 之間傳輸一些敏感資訊（密碼、秘鑰等），需要設計一套互動協定，防止敏感資訊洩露，確定資料傳輸的安全性。
二、目标
設計一套Agent/Plugin和Server之間的通信協定，需要實作以下目标：
- 滿足功能上的需求，可以接受請求，執行指令和任務。
- 確定敏感資訊傳輸的安全性。
- 對部分影響較大的請求進行認證。
- 盡可能不依賴外部服務。
三、分析
通訊方式
目前主流兩個服務之間的通訊方式有：http/https、tcp、udp、rcp。
| 通訊方式 | 協定層 | 優點 | 缺點 |
| tcp/udp | 傳輸層 | 完全可定制化的通訊協定，可以具備較高的安全性。 | 需要從底層實作一套複雜的通訊協定，開發成本非常高。 |
| rpc | 應用層 | 成熟的通訊協定，現有架構可以完整支援，可以在此基礎上完成二次開發，并且性能較高。 | 需要指定的用戶端才能通訊，調試不太友善，開發成本稍高。 |
| http/https | 應用層 | 成熟的通訊協定，現有架構可以完整支援，可以在此基礎上完成二次開發，并且用戶端較多，調試非常友善。 | 相比rcp，性能較低，開發成本較低。 |
目前 Agent / Plugin 和 Server 之間的通訊的性能要求不高，最主要的是滿足功能上的需求和防止敏感資訊洩露，友善開發、調試。故我們采用開發成本稍低的 http 協定。
需要加密的接口
Agent/Plugin和Server 之間通訊時，90% 的場景是擷取一些非敏感性資訊，例如：伺服器資訊、硬體資訊等。如果這些非敏感的資訊進行加密會大大浪費資源，增加雙方的負擔。故我們對含有非敏感資訊的接口不采用加密的通訊方式，僅對含有敏感資訊的接口進行加密傳輸。
加密協定
加密方式大緻分為對稱加密和非對稱加密。兩者主要的差別在于加密和解密的秘鑰是否是同一個。
- 對稱加密
對稱加密用的秘鑰既可以用來加密明文資料，也可以用來解密密文資料，故被稱之為對稱加密。一般情況下對稱加密的加密算法是公開的，一旦秘鑰洩露則密文就會很容破解，是以對稱加密的關鍵在于秘鑰的安全管理。
加密過程如下：
密文=Func(明文,秘鑰) 其中Func為加密算法。
解密過程如下：
明文=Func(密文,秘鑰) 其中 Func 為加密算法。
對稱加密算法主要有 AES、DES、3DES 等，由于 DES 和 3DES 在安全性方面不如 AES，故現在不再推薦使用 DES 和 3DES 。
| 名稱 | 密鑰長度 | 運算速度 | 安全性 | 資源消耗 | 是否推薦 |
| DES | 56位 | 較快 | 低 | 中 | 不推薦 |
| 3DES | 112位或168位 | 慢 | 中 | 高 | 不推薦 |
| AES | 128、192、256位 | 快 | 高 | 低 | 推薦 |
- 非對稱加密
非對稱加密有一對秘鑰，可以用其中任何一個秘鑰來加密，用另一個秘鑰來解密。一般情況下會把其中的一把秘鑰公開，可以使用這個秘鑰對任何資料進行加密，隻要另一把秘鑰不洩露就可以確定資料安全。為了區分這兩個秘鑰，可以公開的秘鑰稱為公鑰，不能公開的秘鑰稱為私鑰。
加密過程如下：
密文=Func(明文,公鑰) 其中Func為加密算法。
解密過程如下：
明文=Func(密文,私鑰) 其中Func為加密算法。
常見的非對稱加密算法有RSA、DSA等。
| 名稱 | 成熟度 | 安全性（取決于密鑰長度） | 運算速度 | 資源消耗 |
| RSA | 高 | 高 | 慢 | 高 |
| DSA | 高 | 高 | 慢 | 隻能用于數字簽名 |
| ECC | 低 | 高 | 快 | 低(計算量小,存儲空間占用小,帶寬要求低) |
RSA 加密算法是目前最有影響力的公鑰加密算法，并且被普遍認為是目前最優秀的公鑰方案 之一。RSA 是第一個能同時用于加密和數字簽名的算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被 ISO 推薦為公鑰資料加密标準。
對稱加密和非對稱加密算法比較：
| 加密方式 | 優勢 | 劣勢 |
| 對稱加密 | 速度快，資源消耗低 | 安全性不如非對稱加密 |
| 非對稱加密 | 安全性高 | 加解密速度低，資源消耗高 |
基于加密和解密速度上的考慮，目前Agent/Plugin和Server之間采用對稱加密算法。
流程設計
- 流程圖
圖示以Agent和 Server 認證過程為例。Agent 和 Server 之間都含有一個固定的 key，這個 key 是編碼在二進制代碼中，無法通路。
- 認證過程
1. agent 啟動時會收集自身和環境資訊，并向 server 注冊。
2. server 收到注冊請求之後，會針對本次請求的 agent 生成配置資訊。
- 随機生成一個securityKey(每個agent每次注冊都會生成新的securityKey)。
- 使用 securityKey 加密 agent 的原始配置資訊。
- 使用 key 加密 securityKey 。
3. server 将配置資訊（包含加密之後的 securityKey）發送給 agent。
4. agent 收到配置資訊後，使用對應的 key 解析 securityKey，然後使用 securityKey 解密出原始的配置資訊。
- 請求過程
1. server 生成 token。
- 生成包含 server 身份資訊在内的服務資訊。
- 使用 agent 對應的 securityKey 加密服務資訊。
- 使用加密之後的服務資訊生成 token 。
2. server 向 agent 下發指令請求，并附加 token。
3. agent 收到請求之後，進行檢查。
- 解析 token 并擷取服務資訊。
- 使用 securityKey 解密服務資訊，并擷取請求的身份資訊。
- 檢查身份資訊是否正确，如果檢查錯誤則直接拒絕請求。
4. agent 執行指令并傳回結果。
- 說明
1. agent 和 server 共有的 key
- key 隻用于加密和解密 sercurityKey，不用于其他用途，即使洩露也不會影響認證。
- agent 和 server 是二進制編譯部署，key 不存在與配置檔案中，key 不會在網絡中以任何形式傳輸。
- key不參與資料加密過程，即使 server 向 agent 請求時，key 不相同認證也會通過。
- 後面如果需要考慮替換掉 key，隻需要保證 agent 注冊的時候 server 與 agent 的 key 相同就可以注冊成功。
2. securityKey
- 每個 agent 專屬一個 securityKey 。
- 每個 agent 啟動注冊均會随機生成一個 securityKey ，如果存在舊的 securityKey 則會被覆寫。
- securityKey 是用來加密敏感資訊，防止敏感資訊。
- securityKey 僅在注冊過程中傳輸一次，并且隻存在于 agent 的記憶體中，不會以任何形式存在于檔案中。
3. token
token 中包含加密之後的server身份資訊，agent 認證時會做如下檢查：
- agent 檢查 token 身份資訊是否符合要求，如果身份資訊不符合要求則認證不予通過。
- agent 會将身份資訊與請求來源進行比較，如果不同則被認為 token 為非法
作者:錢芳園
來源:微信公衆号:Qunar技術沙龍
出處:https://mp.weixin.qq.com/s/Otj6O-xkSsq5cYG6VOSR2g