阿里雲 AccessKey 洩露怎麼辦? 手把手教你規範配置 RAM 角色權限
不少技術團隊都遭遇過這樣的「午夜驚魂」:忽然收到阿里雲的奪命連環 call 或者短信通知,「您的賬號檢測到 AccessKey 洩露風險,部分資源正被高頻異常調用……」
登錄控制台一看,賬單已經爆了,服務器甚至被黑客批量創建去挖礦。
導致這一切的根源,往往是因為圖省事,直接在代碼、配置文件或 GitHub 公開倉庫里,硬編碼了具有最高權限的
主賬號 AccessKey(AK/SK)
。 主賬號的 AK 就像你家的萬能鑰匙,一旦泄露,整個雲上資產等於對黑客完全敞開。
今天不扯虛的理論,不講廢話。 直接手把手帶你建立兩道防線:
第一,AK 洩露後的 5 分鐘緊急止血;第二,如何用 RAM 角色(Role)徹底根除硬編碼 AK 的隱患。
第一階段:緊急止血! AccessKey 洩露的 5 分鐘應急流
如果你發現或者懷疑 AK 已經洩露,不要猶豫,立刻執行以下操作,多耽誤一分鐘都是真金白銀的損失。
步驟 1:全網禁用或刪除涉事 AK
立刻登錄阿里雲控制台,點擊右上角頭像 $\rightarrow$ 選擇 「AccessKey 管理」。
找到提示洩露的那個 AccessKey(無論是主賬號的還是子賬號的)。
先點擊 「禁用」。 此時所有使用該 AK 的外網請求會瞬間報錯 403。
確認沒有影響到核心生產業務後,果斷點擊 「刪除」。
步驟 2:排查黑客留下的「後門」
黑客拿到 AK 後,第一件事往往是利用自動化腳本批量創建資源。
去 ECS 實例列表、輕量應用服務器列表,切換各個地域(北京、上海、深圳、香港、美國等),看看有沒有莫名其妙多出來的服務器。 有的話,立刻徹底釋放。
去 操作審計(ActionTrail) 控制台,查詢過去 24 小時內,該 AK 都調用了哪些 API,把黑客動過手腳的資源一個不漏地揪出來。
第二階段:治本之策--規範配置 RAM 角色與最小權限
刪除了 AK,老的項目代碼直接崩了,因為它們需要權限去讀寫 OSS 或者是調用其他雲服務。
我們不能再建一個新的主賬號 AK 塞進去了。 正確的做法是:
使用 RAM 角色(RAM Role),讓運行在阿里雲上的程序自動、免密鑰獲取臨時權限。
下面我們以「讓雲服務器 ECS 上的程序能夠安全讀寫 OSS 存儲桶」為例,進行實戰配置。
步驟 1:創建 RAM 角色(憑空造一個「身份」
）
在控制台搜索並進入 「RAM 訪問控制」。
點擊左側菜單的 「角色」 $\rightarrow$ 「創建角色」。
選擇可信實體類型為 「阿里雲服務」,點擊下一步。
角色類型:選擇 「普通服務角色」。
角色名稱:起一個易懂的名字,比如 ECS-OSS-Reader-Role。
選擇受信服務:因為我們要把這個角色貼在雲服務器上,所以這裡選擇 「雲服務器」(ECS)。
點擊確定。
步驟 2:精確授權(不給多餘的權限)
剛創建的角色是一張白紙,沒有任何權限。 我們需要按照「最小權限原則」給它發許可證。
在角色列表裡找到剛才創建的 ECS-OSS-Reader-Role,點擊右側的 「添加權限」。
授權範圍:選擇整個阿里雲賬號(默認)。
選擇策略:如果只需讀取 OSS:搜索並勾選 AliyunOSSReadOnlyAccess(只讀訪問OSS)。 如果需要讀寫 OSS:搜索並勾選 AliyunOSSFullAccess(管理OSS)。
點擊確定。
步驟 3:把角色綁定到 ECS 雲服務器上
這一步非常關鍵,它相當於把這張「許可證」貼到了特定的服務器腦門上。
進入 「雲服務器 ECS」 控制台,找到運行你代碼的那台實例。
點擊右側的 「更多」 $\rightarrow$ 「實例設置」 $\rightarrow$ 「授予/收回 RAM 角色」。
在下拉菜單里,選擇你剛才創建的 ECS-OSS-Reader-Role。
點擊確定。
第三階段:代碼改造--徹底告別硬編碼 AK
現在,你的服務器已經具備了合法身份。 我們要去修改項目的代碼,把那幾行該死的
AccessKeyId
和
AccessKeySecret
徹底刪掉。
阿里雲的 SDK 具有
自動憑證輪轉注入
功能。 當代碼在綁定了 RAM 角色的 ECS 上運行時,SDK 會通過訪問服務器內部的一個特殊本地元數據地址
http
://100.100.100.200/latest/meta-data/
全自動獲取一個
每幾個小時就自動過期更換的臨時 Token
。
哪怕黑客潛入服務器偷走了這個 Token,幾小時後也會自動失效,根本無法用來作為持久後門。
以 Java SDK 訪問 OSS 為例:
老代碼(極度危險❌）：
Java
// 嚴禁這樣寫! 一旦代碼上
傳到公開代碼託管平台,全家桶瞬間升天
String accessKeyId = "LTAI5tXXXXXX";
String accessKeySecret = "Pn7yXXXXXX";
OSS ossClient = new OSSClientBuilder().build(endpoint, accessKeyId, accessKeySecret);
新代碼(雲原生安全 戰略推薦 ):
Java
Import com.aliyun.oss.OSS;
Import com.aliyun.oss.OSSClientBuilder;
Import com.aliyun.credentials.Client;
Import com.aliyun.credentials.models.Config;
// 完全不需要出現任何明文密鑰!
Config credentialConfig = new Config();
CredentialConfig.setType("ecs_ram_role"); // 指定憑證類型為 ECS 綁定的 RAM 角色
// 如果留空,SDK 會自動尋找當前服務器綁定的角色名
// CredentialConfig.setRoleName("ECS-OSS-Reader-Role");
Client credentialClient = new Client(credentialConfig);
// 使用臨時憑證構建 OSS 客戶端
OSS ossClient = new OSSClientBuilder().build(endpoint, credentialClient);
終極防線:如何杜絕下一次泄露?
絕對、絕對、絕對不要在任何公開代碼庫(如 GitHub、Gitee)提交包含明文 AK 的配置文件。 哪怕是私有倉庫也不行,很多泄露是因為員工把私有倉庫錯改成了公開。
善用 . Gitignore。 在項目初始化時,立刻把 application-prod.yml、config.json 等包含敏感信息的配置文件加入忽略列表。
本地開發怎麼搞? 如果本地電腦確實需要 AK 調試,把 AK 配置到你電腦系統的環境變量里(通過 export ALIBABA_CLOUD_ACCESS_KEY_ID="xxx"),在代碼中
通過 System.getenv() 去讀取。 這樣代碼里永遠都是乾淨的。
安全無小事。 今晚就去排查一下你維護的項目,把那些硬編碼的主賬號 AK 統統幹掉吧!
