天天看點

談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清單中,檢視通路密鑰的最後使用時間,以此初步判斷第二個通路密鑰是否已經被使用,原來的通路密鑰是否已經不用。

    談AK管理之基礎篇 - 如何進行通路密鑰的全生命周期管理?
  3. 禁用原來的通路密鑰。
  4. 驗證使用通路密鑰的所有應用程式或系統是否正常運作。
    • 如果運作正常,說明通路密鑰更新成功,您可以放心地删除原來的通路密鑰。
    • 如果運作異常,您需要暫時激活原來的通路密鑰,然後重複步驟2~4的操作,直至更新成功。
  1. 删除原來的通路密鑰。

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 審計:定期分析通路密鑰使用行為

通過規範通路密鑰生命周期的管理操作,可以解決大部分由于不當操作導緻的安全故障,但是很多安全問題,是需要分析通路密鑰的使用資料才能發現的。

  1. 通路密鑰存儲洩露探測:是不是寫死到代碼裡去了?可以借助代碼托管平台提供一些服務來檢測比如 Github Token scan
談AK管理之基礎篇 - 如何進行通路密鑰的全生命周期管理?

雲廠商也有類似一些方案幫助客戶做檢測,比如阿裡雲雲安全中心的

AK洩露檢測

談AK管理之基礎篇 - 如何進行通路密鑰的全生命周期管理?
  1. 異常通路密鑰使用探測

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

廠商方案-操作審計

開啟記錄檔審計,并将其

投遞至OSS和SLS

長期儲存和審計,将記錄檔存儲至OSS,異常情況時可以起到固證的作用;記錄檔投遞至SLS,幫助您在日志數量大的時候也能實作高效檢索。

談AK管理之基礎篇 - 如何進行通路密鑰的全生命周期管理?

廠商方案-通路日志審計

除了雲産品的記錄檔外,還有大量的雲産品使用通路日志,這一部分也往往是資料通路的主要部分,比如OSS的Bucket上資料的寫入,擷取,修改和删除等。這部分日志可以直接通過阿裡雲提供的

日志服務

來做到收集,存儲,統計和分析等,您在各個雲産品控制台開通日志功能後,即可執行日志服務相關操作。

本地方案-自建分析引擎

對一些記錄檔審計裡沒有記錄的産品的通路日志,也可以通過雲産品提供日志存儲功能把這些日志記錄并下載下傳下來,通過自己離線的計算,和定時比較,發現上述異常通路記錄。

統計分析

可以監控報警和分析的次元如下,可以通過下面相關次元的日常監控,來觀測是否在各個次元上出現了非預期的通路,如果出現就預示了通路密鑰可能已經出現洩漏,需要重點關注了:

    • 使用通路密鑰的IP是否是自有的機器的IP;
    • 使用通路密鑰的産品是否是自己購買過的;
    • 使用通路密鑰的region是否是自己預期的;
    • 使用通路密鑰的時間是不是服務自己的業務規律。

四、總結

本文從通路密鑰的生命周期管理進行了分析和介紹,希望對于您在雲上密鑰管理能夠有所啟發和幫助。最後,附上AK使用錦囊:

禁止使用主賬号,

子賬号來隔離好;

密碼一次要記好,

AK保密要記牢;

洩露先别亂陣腳,

先禁再删不可少;

兩把AK配置設定好,

定期審計很重要;

究極安全無密鑰。

繼續閱讀