一、引言：
上一期“談AK管理之基礎篇”，我們講了如何規範的進行通路密鑰生命周期管理。通過分出不同權限的阿裡雲RAM子賬号，将不同的權限分給不同的使用者，這樣一旦子賬号洩露也不會造成全局的資訊洩露。但是，由于子賬号在一般情況下是長期有效的，是以，子使用者的通路密鑰也是不能洩露的。
二、洩露挑戰
AK通常的洩露途徑會有哪些呢？我們先從使用者的使用方式來分析和發現：
1. 寫死在代碼裡
很多使用者對通路密鑰的安全意識不夠或者沒有意識到風險，為了使用友善，會直接把通路密鑰的二進制組寫在代碼裡，供程式使用；在現在反編譯和記憶體分析的技術已經很成熟的當下，寫死的方式無異于明文存儲密鑰，有巨大的洩露風險。
2. 第三方密鑰存儲
還有很多客戶了解通路密鑰的重要性，會使用第三方的密鑰存儲系統或者配置檔案，将原始的密鑰加密起來。這種方式的做法加延了密鑰洩露的鍊路，但本質上隻是原始密鑰洩露的風險轉移到另外一把密鑰上，比如第三方密鑰存儲系統的通路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通路密鑰的方案一如下描述。
- 客戶的應用使用阿裡雲頒發給賬戶A的通路密鑰簽名通路RAMOpenAPI的請求，發給網關；
- 阿裡雲網關在驗證身份和API的權限校驗通過後，将請求發送到RAM的OpenAPI，請求頒發STS臨時通路密鑰；
- 阿裡雲RAM的OpenAPI頒發STS臨時通路密鑰；
- 阿裡雲網關将申請的STS臨時通路密鑰傳回給調用方-雲客戶應用；
- 雲客戶應用再将擷取的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通路。
- 在已經授予了執行個體RAM角色的機器上的應用，可以向ECS的中繼資料服務請求STS臨時通路密鑰；
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/{RAM角色名稱} - ECS中繼資料服務傳回已經擷取的STS臨時通路密鑰給客戶的應用
{
"AccessKeyId" : "STS.XXXXXXX",
"AccessKeySecret" : "XXXXXXX",
"Expiration" : "2019-09-24T09:05:00Z",
"SecurityToken" : "XXXXXXX",
"LastUpdated" : "2019-09-24T03:05:00Z",
"Code" : "Success"
} - 客戶的應用可以把擷取的STS臨時通路密鑰分發給自己的其他應用；
- 客戶的其他應用進而使用獲得的STS臨時通路密鑰正常通路阿裡雲服務的OpenAPI。
除了ECS，阿裡雲的一些其他運作環境（ECI，ContainerService，FuntionCompute）都有類似的安全實作，在使用了此類安全實作後，使用者不在需要直接把通路密鑰AccessKey固化在執行個體中，如寫在配置檔案中，寫死在代碼中等不安全的存儲通路密鑰。
五、總結
AK洩露問題導緻企業安全事故或生産事故已有大量的案例，實施無密鑰通路方案将會有效解決AK安全問題，也正在成為企業通路密鑰管理的最佳實踐。