無密鑰通路阿裡雲OpenAPI實戰

​作者丨向榮（榮涵）

阿裡雲開放平台進階技術專家，主要負責阿裡雲OpenAPI通路密鑰（AccessKey），專注于給阿裡雲使用者提供高效，安全的通路密鑰，身份驗證服務。

名詞解釋

RAM（Resource Access Management）

通路控制是阿裡雲提供的一項管理使用者身份與資源通路權限的服務。使用RAM，您可以建立、管理RAM使用者（例如員工、系統或應用程式），并可以控制這些RAM使用者對資源的操作權限。當您的企業存在多使用者協同操作資源時，使用RAM可以讓您避免與其他使用者共享雲賬号密鑰，按需為使用者配置設定最小權限，進而降低企業資訊安全風險。

STS（Security Token Service，STS）

阿裡雲臨時安全令牌（Security Token Service，STS）是阿裡雲提供的一種臨時通路權限管理服務。

摘要

就像登陸阿裡雲網站需要輸入賬号和密碼一樣，我們通路阿裡雲産品或者服務提供的OpenAPI時，也需要這樣的密鑰體系，這就是OpenAPI的通路密鑰：AccessKey（AccessKey ID和AccessKey Secret）。是以，類似登陸的賬号和密碼洩露的安全問題，OpenAPI的通路密鑰同樣存在洩露的風險，本文介紹了一種不直接使用OpenAPI的通路密鑰的身份認證方式，可以有效避免因為通路密鑰的代碼中寫死或者存儲到配置檔案而引入的洩露風險。

前言

通路密鑰

通路密鑰是一個基本的2元組AccessKey（AccessKey ID和AccessKey Secret），AccessKey ID其實是做為一個索引來映射真實的密鑰，AccessKey會在用戶端和服務端共享，用戶端使用AccessKey ID對應的密鑰對請求的某些資訊進行簽名，然後把AccessKey ID和簽名，以及相關資訊都發給服務端，服務端做同樣的事情，然後比對簽名結果來辨別身份認證合法與否。

身份認證流程

接下來我們看看一般OpenAPI的通路時身份認證的工作過程。

大緻流程如下：

1. 使用者在阿裡雲上擷取通路密鑰
2. 使用者通過使用者中心控制台申請和擷取阿裡雲賬号所擁有的的通路密鑰，這個密鑰是使用者通路阿裡雲OpenAPI的密鑰，具有該賬戶下任何資源的完全權限，權限最大。
3. 使用者通過RAM控制台申請和擷取RAM子使用者所擁有的的通路密鑰，這個密鑰同樣是使用者通路阿裡雲API的密鑰，但隻具有該子使用者的權限，權限範圍取決于使用者給這個子使用者配置了多少權限，一般在生産環境建議使用此類密鑰，雖然子使用者可以做到細粒度的權限控制，但是一旦洩露，對使用者的資源也有很高的風險。
4. 使用者使用第一步擷取的OpenAPI通路密鑰把每次對雲産品OpenAPI的通路或者調用進行身份的簽名，并把簽名結果附帶在請求參數或者變量裡發送給阿裡雲網關。
5. 阿裡雲網關身份驗證通過後，将請求發送給雲産品的OpenAPI；

6. 雲産品将調用結果返給網關，并透傳給真實調用方。

   Signature = Base編碼(簽名算法(AccessKeySecret, UTF-8-Encoding-Of(StringToSign)))

阿裡雲實體身份

在介紹通路密鑰時，我們需要了解通路密鑰的類型和使用場景，然後看使用場景中的洩露風險。對于阿裡雲使用者來說，我們先說一下阿裡雲提供的兩種身份。

1. 阿裡雲賬戶：雲賬戶是阿裡雲的一種實體身份類型，也叫阿裡雲主賬号/阿裡雲主使用者，這個身份是使用者在阿裡雲上的唯一辨別，他是客戶所有資源的實際擁有者，他有賬号和密碼用來登入阿裡雲官網，同樣擁有阿裡雲OpenAPI通路密鑰（數量有限），這些密鑰時長期有效，除非使用者自己禁用或者删除。

2. 阿裡雲RAM子使用者：RAM使用者是RAM的一種實體身份類型，有确定的身份ID和身份憑證，它通常與某個确定的人或應用程式一一對應。類似于雲賬戶，他也擁有賬号密碼以及OpenAPI通路密鑰，這種通路密鑰也是長期有效的，除非使用者自己禁用或者删除。

   • 一個雲賬号下可以建立多個RAM使用者，對應企業内的員工、系統或應用程式。

• RAM使用者不擁有資源，沒有獨立的計量計費，這些使用者由所屬雲賬号統一控制和付費。

• RAM使用者歸屬于雲賬号，隻能在所屬雲賬号的空間下可見，而不是獨立的雲賬号。

• RAM使用者必須在獲得雲賬号的授權後才能登入控制台或使用API操作雲賬号下的資源。

從阿裡雲提供兩種身份描述和定義，我們可以看到他們具有相同的身份特性：

1. 這些身份都是實體身份類型（使用者身份）都有賬号和密碼來登入阿裡雲官網，
2. 用于相同類型的OpenAPI通路憑證：通路密鑰長期有效，且權限較大。

挑戰

對于阿裡雲實體身份的通路密鑰，如下洩露風險是顯而易見的：

1. 阿裡雲主賬戶對應的通路密鑰具有該賬戶下任何資源的完全權限，權限最大，主賬号的通路密鑰洩露出去的話會帶來極大的安全風險，擷取者可以随意操作該賬号下所有的資源，盜取重要資訊等，是以在生産環境強烈不建議使用此類密鑰；

2. 通過分出不同權限的阿裡雲RAM子賬号，将不同的權限分給不同的使用者，這樣一旦子賬号洩露也不會造成全局的資訊洩露。但是，由于子賬号在一般情況下是長期有效的，是以，子使用者的通路密鑰也是不能洩露的。

   既然風險比較大，那麼一般的洩露途徑會有哪些呢（客戶側洩露）？我們來看看了解到的一些客戶的一般使用方式：

3. 寫死在代碼裡：很多客戶對通路密鑰的安全意識不夠或者沒有意識到風險，為了使用友善，會直接把通路密鑰的二進制組寫在代碼裡，供程式使用；在現在反編譯和記憶體分析的技術已經很成熟的當下，寫死的方式無異于明文存儲密鑰，有巨大的洩露風險。
4. 第三方密鑰存儲：還有很多客戶了解通路密鑰的重要性，會使用第三方的密鑰存儲系統或者配置檔案，将原始的密鑰加密起來。這種方式的做法加延了密鑰洩露的鍊路，但本質上隻是原始密鑰洩露的風險轉移到另外一把密鑰上，比如第三方密鑰存儲系統的通路key，或者是加密的密鑰，歸根結底還是會存在“最後一把密鑰”的安全洩露風險。

無密鑰通路方案-基礎

針對通路密鑰的洩露高風險，我們有沒有一些方案既能克服“最後一把密鑰”的風險，又能很友善的進行可控的身份認證呢？很自然，我們會想出來的第一個方案：既然長期的通路密鑰權限大，我們能不能換一種短期且權限可控的通路密鑰呢，這就要介紹阿裡雲的另外一種身份類型和與之相對應的通路密鑰。

阿裡雲虛拟身份

RAM角色（RAM role）與RAM使用者一樣，都是RAM身份類型的一種，隻不過RAM角色是一種虛拟使用者，沒有确定的身份認證密鑰，需要被一個受信的實體使用者扮演才能正常使用。簡單說，可信實體扮演RAM角色，并使用角色令牌去通路RAM角色裡規定的資源以及資源上的OpenAPI。

• RAM角色：RAM角色有确定的身份，可以被賦予一組權限政策，但沒有确定的登入密碼或通路密鑰。RAM角色需要被一個受信的實體使用者扮演，扮演成功後實體使用者将獲得RAM角色的安全令牌，使用這個安全令牌就能以角色身份通路被授權的資源。

• 可信實體（Trusted entity）：角色的可信實體是指可以扮演角色的實體使用者身份。建立角色時必須指定可信實體，角色隻能被受信的實體扮演。可信實體可以是受信的阿裡雲賬号、受信的阿裡雲服務或身份提供商。

• 角色令牌（Role token）：角色令牌是角色身份的一種臨時通路密鑰。角色身份沒有确定的通路密鑰，當一個實體使用者要使用角色時，必須通過扮演角色來擷取對應的角色令牌，然後使用角色令牌來調用阿裡雲服務API。

對于虛拟身份類型（角色身份），對應的OpenAPI通路憑證就是上面說的角色令牌，是一種時效和權限可控的臨時通路密鑰。相對于阿裡雲實體身份的通路密鑰的長效控制機制，STS提供的是一種臨時通路授權。通過STS可以傳回臨時的通路密鑰和令牌，這些資訊可以直接發給臨時使用者用來通路阿裡雲服務。一般來說，從STS擷取的權限會受到更加嚴格的限制，并且擁有時間限制，是以這些資訊洩露之後對于系統的影響也很小。

阿裡雲使用者在RAM中，定義一個角色，并授權了可以扮演此角色的可信實體，比如某主賬戶下的子使用者賬号A，然後授權賬戶可以通路RAM的接口擷取臨時通路密鑰。賬戶A的通路流程就如下描述了。是以結合了STS通路密鑰的方案一如下描述。

1. 客戶的應用使用阿裡雲頒發給賬戶A的通路密鑰簽名通路RAMOpenAPI的請求，發給網關；
2. 阿裡雲網關在驗證身份和API的權限校驗通過後，将請求發送到RAM的OpenAPI，請求頒發STS臨時通路密鑰；
3. 阿裡雲RAM的OpenAPI頒發STS臨時通路密鑰；
4. 阿裡雲網關将申請的STS臨時通路密鑰傳回給調用方-雲客戶應用；
5. 雲客戶應用再将擷取的STS臨時通路密鑰分發給其自己的終端或者别的應用系統；
6. 9.步和我們在前言裡介紹的一樣，應用使用通路密鑰正常通路阿裡雲服務的OpenAPI，隻不過這裡使用的是STS臨時通路密鑰了。

無密鑰通路方案-進階

無密鑰通路方案-基礎方案裡，我們把權限較大的長期通路密鑰，替換成了STS臨時通路密鑰，由于STS在時間等屬性上有限制，這樣可以把原來洩露長期通路密鑰帶來的風險降低到短時間都次元，做到了一定程度的安全風險減小，但細心的同學還會發現，要擷取一個STS臨時通路密鑰，還是需要雲賬戶或者其RAM子使用者的長期通路密鑰，也還是沒有解決“最後一把密鑰”的問題。

既然阿裡雲RAM提供了角色功能，并能把這個角色授權給實體，這個是實體是賬戶或者服務，那可不可以把這個角色和某些特定實體關聯呢，比如某個IP，某個區域或者環境等。這種環境可以映射到什麼實體呢？我們看現階段客戶的應用絕大部分會運作在機器，docker容器或者某個運作環境（Serverless）裡，在這個特定的範圍裡，比如某個機上，是否可以實作免輸入長期通路密鑰而調用RAM的OpenAPI擷取STS臨時通路密鑰呢。我們接下來引入阿裡雲ECS的一個特殊角色來舉例。

執行個體RAM角色

ECS執行個體RAM（Resource Access Management）角色讓ECS執行個體扮演具有某些權限的角色，進而賦予執行個體一定的通路權限。執行個體RAM角色允許使用者将一個角色關聯到ECS執行個體，在執行個體内部基于STS臨時憑證（臨時憑證将周期性更新）通路其他雲産品的API。一方面可以保證AccessKey安全，另一方面也可以借助RAM實作權限的精細化控制和管理。關于角色的較長的描述，請參見

角色

。

首先，我們定一個特殊的角色，這個角色就是ECS執行個體角色，然後把這個角色授予這個特定的ECS執行個體，在這個執行個體裡的應用可以通過如下流程進行完整的阿裡雲OpenAPI通路。

1. 在已經授予了執行個體RAM角色的機器上的應用，可以向ECS的中繼資料服務請求STS臨時通路密鑰；

1. ECS中繼資料服務傳回已經擷取的STS臨時通路密鑰給客戶的應用

1. 客戶的應用可以把擷取的STS臨時通路密鑰分發給自己的其他應用；

2. 客戶的其他應用進而使用獲得的STS臨時通路密鑰正常通路阿裡雲服務的OpenAPI。

   除了ECS，阿裡雲的一些其他運作環境（ECI，ContainerService，FuntionCompute）都有類似的安全實作，在使用了此類安全實作後，使用者不在需要直接把通路密鑰AccessKey固化在執行個體中，如寫在配置檔案中，寫死在代碼中等不安全的存儲通路密鑰。

具體的配置和使用請參見

結語

本文提供介紹了阿裡雲關于去除OpenAPI通路密鑰本地存儲的安全方案及實作，這種方式既滿足了便捷調用OpenAPI的需求，又不需要直接把通路密鑰AccessKey固化在執行個體中，如寫在配置檔案中，有效的解決了固化通路密鑰這種方式權限過高，存在洩露資訊和難以維護等問題。