簡介： 我們也常有聽説例如AK被外部攻擊者惡意獲取，或者員工無心從github泄露的案例，最終導致安全事故或生產事故的發生。AK的應用場景極為廣泛，因此做好AK的管理和治理就尤為重要了。本文將通過兩種AK使用不安全的典型案例，進行分析和介紹。

一、引言：

對於企業上雲的典型場景，雲賬號管理員一般會給員工、應用程序或系統服務創建一個相應的用户賬號。每個賬號都可以有獨立的身份認證密鑰，俗稱AK (AccessKey)，它用於阿里雲服務API的身份認證。既然是身份證明，證明你是某個雲賬號的合法擁有者，那麼一旦泄露後果着實嚴重。我們也常有聽説例如AK被外部攻擊者惡意獲取，或者員工無心從github泄露的案例，最終導致安全事故或生產事故的發生。AK的應用場景極為廣泛，因此做好AK的管理和治理就尤為重要了。本文將通過兩種AK使用不安全的典型案例，進行分析和介紹。

二、訪問密鑰誤刪，用户服務受阻

典型案例重現

2020年，某客户突然發現自己的一些項目的用户APP上傳數據出現失敗，這個上傳數據功能使用了該雲廠商上的某存儲服務，客户發起工單認為雲廠商的存儲服務有故障。經排查發現該用户的Region其他業務方的生產活動正常，未出現明顯異常；遂懷疑網絡問題，建議客户查詢網絡連接，此時客户提交App端的錯誤日誌，日誌中顯示是訪問密鑰沒有找到，在雲客服的指導下，並未發現有相同ID的密鑰存在，然後在操作審計的記錄中，發現該訪問密鑰是被其自己內部做了刪除操作。

緊急處理

1. 雲產品建議該客户對使用的訪問密鑰馬上替換，客户反饋APP上不好控制，特別iOS的app發佈還要審核，週期太長；
2. 客户緊急發佈公告，通知其用户此功能暫時不可用，待升級後恢復。

影響

影響顯而易見，對很多初創企業這樣的故障會輕則導致用户體驗差，重則關鍵功能不可用，對企業留存客户或者收入都會受到不同程度的影響。

分析和總結

1. 這次故障主要是由於員工誤刪除AK導致，有的同學就會説，能不能有個類似垃圾站的功能，還可以回收？其實雲廠商一般都會提供一個類似的功能叫激活/禁用，應當遵循“先禁用再刪除”，以確保業務的正常持續；
2. 此外，AK刪除導致服務端的故障，值得引起注意和自查的是，用户作為管控和服務端使用的不同場景，是不是做了嚴格的區分？服務端使用和管控是否區分開等？員工和線上系統是否區分開？
3. App應用中硬編碼訪問密鑰，導致出現泄漏時，替換成本很大，不能馬上進行輪轉替換完成業務止損；其實App類業務不適合使用永久AK密鑰來訪問OpenAPI。
4. 此外，應用反編譯，hack已經是多發事件了，代碼中存放永久密鑰，泄露的風險巨大！

三、規範的訪問密鑰生命週期管理操作，保障安全生產進行

上述真實的案例不僅帶給我們巨大的警示，那麼針對訪問密鑰究竟在哪些環節進行規範操作？又應當通過什麼辦法進行管理控制呢？

1 、創建：訪問密鑰

• 再次敲黑板，不推薦使用主賬號的訪問密鑰，原因很明顯，主賬號擁有的資源和權限太大，泄露後的風險不堪設想；
• 可以通過雲廠商的訪問控制等頁面查看，有沒有創建租户級別下的子用户，並實際使用的是這些子用户的訪問密鑰。

2 、配置：合適的權限

• 每個不同的應用使用不同子用户的訪問密鑰，這樣可以做到應用級別資源和權限隔離；
• 每個子用户的權限是不是滿足了最小可用原則，不擴大不要的權限；可以在測試環境試着減少權限，看看測試是不是能正常，不正常的話大概率這個權限是不能去除的；
• 通過RAM訪問控制枱查詢，可以看到某一個用户所具有的權限Policy，以及Policy裏具體的權限描述。

3 、刪除：訪問密鑰

訪問密鑰的刪除是不可恢復的，所以刪除是具有一定風險的，只有在安全確認這把訪問密鑰沒有任何使用記錄後，才能刪除，標準的流程如下：

1. 首先把原來訪問密鑰使用的地方替換為新的訪問密鑰，然後監控需要刪除的訪問密鑰的最後使用時間；
2. 按照自己業務的狀況，確定老的訪問密鑰的失效時間，比如根據業務狀況確定7天為安全時間，即一把訪問密鑰7天沒有使用記錄就可以嘗試刪除老的密鑰；
3. 所以在安全時間既要到達刪除的效果，又要在出現突發狀況下把刪除的訪問密鑰找回，雲廠商都會提供一組這樣的操作禁用/激活，使用禁用代替刪除操作，禁用操作可以達到和刪除一樣的效果，但是可以滿足突發狀況下訪問密鑰的找回，即通過激活操作，把禁用的訪問密鑰恢復過來，就如同提供了一個垃圾箱的功能；
4. 在訪問密鑰進行禁用後，持續觀察業務是否有異常，直到一個最終安全時間，比如7天，如果沒有任何老的訪問密鑰的使用記錄，就可以真實刪除了。

4、 泄露：密鑰輪轉

每個RAM用户最多可以創建兩個訪問密鑰。如果您的訪問密鑰已經使用3個月以上，建議您及時輪換訪問密鑰，降低訪問密鑰被泄露的風險。

1. 在需要輪轉的時候，再創建第二個訪問密鑰。
2. 在使用訪問密鑰的所有應用程序或系統中，更新正在使用的訪問密鑰為新創建的第二個訪問密鑰。
   説明 ：可以在控制枱的用户詳情頁的用户AccessKey列表中，查看訪問密鑰的最後使用時間，以此初步判斷第二個訪問密鑰是否已經被使用，原來的訪問密鑰是否已經不用。

3 禁用原來的訪問密鑰。

4 驗證使用訪問密鑰的所有應用程序或系統是否正常運行。

• 如果運行正常，説明訪問密鑰更新成功，您可以放心地刪除原來的訪問密鑰。
• 如果運行異常，您需要暫時激活原來的訪問密鑰，然後重複步驟2~4的操作，直至更新成功。

5 刪除原來的訪問密鑰。

5 開發：避免密鑰硬編碼到代碼

系統屬性

在系統屬性裏尋找環境憑證，如果定義了 alibabacloud.accessKeyId 和alibabacloud.accessKeyIdSecret 系統屬性且不為空，程序將使用它們創建默認憑證。

環境憑證

在環境變量裏尋找環境憑證，如果定義了
ALIBABA_CLOUD_ACCESS_KEY_ID和
ALIBABA_CLOUD_ACCESS_KEY_SECRET環境變量且不為空，程序將使用它們創建默認憑證。

配置文件

如果用户主目錄存在默認文件
~/.alibabacloud/credentials （Windows 為 C:UsersUSER_NAME.alibabacloudcredentials），程序會自動創建指定類型和名稱的憑證。默認文件可以不存在，但解析錯誤會拋出異常。配置名小寫。不同的項目、工具之間可以共用這個配置文件，因為不在項目之內，也不會被意外提交到版本控制。 可以通過定義
ALIBABA_CLOUD_CREDENTIALS_FILE 環境變量修改默認文件的路徑。不配置則使用默認配置 default，也可以設置環境變量 ALIBABA_CLOUD_PROFILE 使用配置。

[default]                          # 默認配置
enable = true                      # 啓用，沒有該選項默認不啓用
type = access_key                  # 認證方式為 access_key
access_key_id = foo                # Key
access_key_secret = bar            # Secret
 [client1]                          # 命名為 `client1` 的配置
type = ecs_ram_role                # 認證方式為 ecs_ram_role
role_name = EcsRamRoleTest         # Role Name
 [client2]                          # 命名為 `client2` 的配置
enable = false                     # 不啓用
type = ram_role_arn                # 認證方式為 ram_role_arn
region_id = cn-test                # 獲取session用的region
policy = test                      # 選填 指定權限
access_key_id = foo
access_key_secret = bar
role_arn = role_arn
role_session_name = session_name   # 選填
 [client3]                          # 命名為 `client3` 的配置
type = rsa_key_pair                # 認證方式為 rsa_key_pair
public_key_id = publicKeyId        # Public Key ID
private_key_file = /your/pk.pem    # Private Key 文件

6、 審計：定期分析訪問密鑰使用行為

通過規範訪問密鑰生命週期的管理操作，可以解決大部分由於不當操作導致的安全故障，但是很多安全問題，是需要分析訪問密鑰的使用數據才能發現的。

1. 訪問密鑰存儲泄露探測：是不是硬編碼到代碼裏去了？可以藉助代碼託管平台提供一些服務來檢測比如 Github Token scan；

雲廠商也有類似一些方案幫助客户做檢測，比如阿里云云安全中心的AK泄露檢測。

1. 異常訪問密鑰使用探測

這種分析主要是對密鑰本身的實際使用相關的數據，日誌等做分析，來看是否已經出現了異常。

廠商方案-操作審計

開啓操作日誌審計，並將其投遞至OSS和SLS長期保存和審計，將操作日誌存儲至OSS，異常情況時可以起到固證的作用；操作日誌投遞至SLS，幫助您在日誌數量大的時候也能實現高效檢索。

廠商方案-訪問日誌審計

除了雲產品的操作日誌外，還有大量的雲產品使用訪問日誌，這一部分也往往是數據訪問的主要部分，比如OSS的Bucket上數據的寫入，獲取，修改和刪除等。這部分日誌可以直接通過阿里雲提供的日誌服務來做到收集，存儲，統計和分析等，您在各個雲產品控制枱開通日誌功能後，即可執行日誌服務相關操作。

本地方案-自建分析引擎

對一些操作日誌審計裏沒有記錄的產品的訪問日誌，也可以通過雲產品提供日誌存儲功能把這些日誌記錄並下載下來，通過自己離線的計算，和定時比較，發現上述異常訪問記錄。

統計分析

可以監控報警和分析的維度如下，可以通過下面相關維度的日常監控，來觀測是否在各個維度上出現了非預期的訪問，如果出現就預示了訪問密鑰可能已經出現泄漏，需要重點關注了：

• 使用訪問密鑰的IP是否是自有的機器的IP；
• 使用訪問密鑰的產品是否是自己購買過的；
• 使用訪問密鑰的region是否是自己預期的；
• 使用訪問密鑰的時間是不是服務自己的業務規律。

四、總結

本文從訪問密鑰的生命週期管理進行了分析和介紹，希望對於您在雲上密鑰管理能夠有所啓發和幫助。最後，附上AK使用錦囊：

禁止使用主賬號，

子賬號來隔離好；

密碼一次要記好，

AK保密要記牢；

泄露先別亂陣腳，

先禁再刪不可少；

兩把AK分配好，

定期審計很重要；

究極安全無密鑰。

原文鏈接
本文為阿里雲原創內容，未經允許不得轉載