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

?

一、引言：

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

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

典型案例重現

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

緊急處理

云產品建議該客戶對使用的訪問密鑰馬上替換，客戶反饋APP上不好控制，特別iOS的app發布還要審核，周期太長；

客戶緊急發布公告，通知其用戶此功能暫時不可用，待升級后恢復。

影響

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

分析和總結

這次故障主要是由于員工誤刪除AK導致，有的同學就會說，能不能有個類似垃圾站的功能，還可以回收？其實云廠商一般都會提供一個類似的功能叫激活/禁用，應當遵循“先禁用再刪除”，以確保業務的正常持續；

此外，AK刪除導致服務端的故障，值得引起注意和自查的是，用戶作為管控和服務端使用的不同場景，是不是做了嚴格的區分？服務端使用和管控是否區分開等？員工和線上系統是否區分開？

App應用中硬編碼訪問密鑰，導致出現泄漏時，替換成本很大，不能馬上進行輪轉替換完成業務止損；其實App類業務不適合使用永久AK密鑰來訪問OpenAPI。

此外，應用反編譯，hack已經是多發事件了，代碼中存放永久密鑰，泄露的風險巨大！

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

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

1 、創建：訪問密鑰

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

2 、配置：合適的權限

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

3 、刪除：訪問密鑰

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

首先把原來訪問密鑰使用的地方替換為新的訪問密鑰，然后監控需要刪除的訪問密鑰的最后使用時間；

按照自己業務的狀況，確定老的訪問密鑰的失效時間，比如根據業務狀況確定7天為安全時間，即一把訪問密鑰7天沒有使用記錄就可以嘗試刪除老的密鑰；

所以在安全時間既要到達刪除的效果，又要在出現突發狀況下把刪除的訪問密鑰找回，云廠商都會提供一組這樣的操作禁用/激活，使用禁用代替刪除操作，禁用操作可以達到和刪除一樣的效果，但是可以滿足突發狀況下訪問密鑰的找回，即通過激活操作，把禁用的訪問密鑰恢復過來，就如同提供了一個垃圾箱的功能；

在訪問密鑰進行禁用后，持續觀察業務是否有異常，直到一個最終安全時間，比如7天，如果沒有任何老的訪問密鑰的使用記錄，就可以真實刪除了。

4、 泄露：密鑰輪轉

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

在需要輪轉的時候，再創建第二個訪問密鑰。

在使用訪問密鑰的所有應用程序或系統中，更新正在使用的訪問密鑰為新創建的第二個訪問密鑰。
說明?：可以在控制臺的用戶詳情頁的用戶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:\Users\USER_NAME\.alibabacloud\credentials），程序會自動創建指定類型和名稱的憑證。默認文件可以不存在，但解析錯誤會拋出異常。配置名小寫。不同的項目、工具之間可以共用這個配置文件，因為不在項目之內，也不會被意外提交到版本控制。 可以通過定義
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、 審計：定期分析訪問密鑰使用行為

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

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

?

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

異常訪問密鑰使用探測

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

廠商方案-操作審計

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

?

?

廠商方案-訪問日志審計

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

?

本地方案-自建分析引擎

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

?

統計分析

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

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

?

四、總結

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

禁止使用主賬號，

子賬號來隔離好；

密碼一次要記好，

AK保密要記牢；

泄露先別亂陣腳，

先禁再刪不可少；

兩把AK分配好，

定期審計很重要；

究極安全無密鑰。

?

原文鏈接

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

總結

以上是生活随笔為你收集整理的谈AK管理之基础篇 - 如何进行访问密钥的全生命周期管理？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。