一、引言：
上一期“談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安全問題，也正在成爲企業訪問密鑰管理的最佳實踐。
本文爲阿里雲原創內容，未經允許不得轉載。