談AK管理之基礎篇 - 如何進行訪問密鑰的全生命週期管理？

簡介： 咱們也常有據說例如AK被外部攻擊者惡意獲取，或者員工無意從github泄露的案例，最終致使安全事故或生產事故的發生。AK的應用場景極爲普遍，所以作好AK的管理和治理就尤其重要了。本文將經過兩種AK使用不安全的典型案例，進行分析和介紹。

1、引言：

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

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

典型案例重現

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

緊急處理

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

影響

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

分析和總結

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

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

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

1 、建立：訪問密鑰

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

2 、配置：合適的權限

• 每一個不一樣的應用使用不一樣子用戶的訪問密鑰，這樣能夠作到應用級別資源和權限隔離；
• 每一個子用戶的權限是否是知足了最小可用原則，不擴大不要的權限；能夠在測試環境試着減小權限，看看測試是否是能正常，不正常的話大機率這個權限是不能去除的；
• 經過RAM訪問控制檯查詢，能夠看到某一個用戶所具備的權限Policy，以及Policy裏具體的權限描述。

3 、刪除：訪問密鑰

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

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

四、 泄露：密鑰輪轉

每一個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 文件

六、 審計：按期分析訪問密鑰使用行爲

經過規範訪問密鑰生命週期的管理操做，能夠解決大部分因爲不當操做致使的安全故障，可是不少安全問題，是須要分析訪問密鑰的使用數據才能發現的。

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

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

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

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

廠商方案-操做審計

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

廠商方案-訪問日誌審計

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

本地方案-自建分析引擎

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

統計分析

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

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

4、總結

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

禁止使用主帳號，

子帳號來隔離好；

密碼一次要記好，

AK保密要記牢；

泄露先別亂陣腳，

先禁再刪不可少；

兩把AK分配好，

按期審計很重要；

究極安全無密鑰。

原文連接本文爲阿里雲原創內容，未經容許不得轉載