緣起
最近抽業餘時間幫朋友看了一眼他的公司的一批阿裡雲賬号，發現一個極為嚴重的隐患，那就是有主賬号通路密鑰對（AK - AccessKeyId，SK - AccessKeySecret，後面統一簡稱AK-SK），且這個AK-SK是明文寫在公司App應用的配置檔案中，App用它來上傳下載下傳客戶的檔案。這意味着什麼？就是任何有心人都有可能拿到這個AK-SK，并且稍微有點開發知識就可以基于這個調用阿裡雲API做到所有的事情，包括亂開資源、給伺服器/資料庫加公網位址并登入讀取公司資料、删除釋放公司的雲資源、删除公司所有雲上的備份資料，進而給公司造成極其嚴重的後果。即使不懂開發，也有現成大量的阿裡雲管理工具，配置AK-SK進去即可擁有最高權限。公司應用到現在還未出問題實屬不易，需要盡快解決，下面記錄一下幫朋友解決該問題的過程。
初步嘗試
啟用MFA
考慮過給資源變更啟用MFA，這樣其他人沒有注冊手機來接收短信，就可以避免資源危險，但實際檢視和測試才發現MFA隻對控制台操作有效，是以MFA是否啟用，對我們這種情況沒有任何作用。
嘗試修改AK-SK權限
因為控制台上并沒有任何對主賬号的AK-SK設定權限的入口，是以向阿裡雲的專家求助，看他們是否能夠幫助我們在背景設定這個AK-SK的權限，讓它隻能對指定的資源通路，不要有這麼大的權限，但可惜的是阿裡雲方面表示他們也無這樣的設定入口，此路不通。
嘗試轉移AK-SK到某個RAM使用者下
同樣向阿裡雲專家詢問這樣是否可行，但阿裡雲方面表示也無法做到，一方面動客戶的資源是個雷區，阿裡雲不會這樣改動任何客戶的資源（除非客戶提工單要求提前釋放某些資源，或者對底層的資源做運維優化工作），另一方面也沒有主賬号AK-SK轉成子賬号AK-SK的途徑，畢竟這樣可能帶來系統上非常大的隐患，此路也不通。
修複方案
不管臨時措施怎麼樣，這個問題本身還是要解決的，在發現這一問題後第一時間拉相關開發，首先要從源頭把這個問題堵上，就是趕緊修改App代碼，這份代碼在這方面存在以下幾個問題：
- 不應該用主賬号的AK-SK，應該專門建立子賬号的AK-SK并隻賦予最小必要資源權限
- AK-SK這類的敏感配置資訊不應該明文存儲，至少應該做一層加密
- AK-SK就不應該出現在用戶端上，隻應該儲存在伺服器上，且在伺服器上也應該加密存儲
- 伺服器上應該盡量也不用AK-SK，如果是雲端的伺服器（ECS），那麼可以設定ECS RAM Role，避免直接使用AK-SK
- 用戶端需要直接通路雲資源（比如從OSS上傳下載下傳檔案），需要先向服務端請求加簽的URL，上傳下載下傳都可以先給URL簽名，然後用戶端直接對URL操作
- 用戶端應該盡量避免直接通路雲資源，除了一些檔案、流量、直播類的操作，如OSS、CDN、視訊直播等，其他的都應該發送請求到伺服器端完成
做相關的變更後，發現問題并不能迎刃而解，因為新版本的App應用需要在各個應用市場上架，這需要一定的時間，即使上架後外面已安裝的成千上萬的App使用者短時間内也不可能大部分都做了更新，因而這個已經建立的AK-SK還需要保持比較長一段時間，然後才能禁用或者删除
緩解措施
既然危險的AK-SK短時間不能禁掉，那也不能留着系統在如此高的風險下什麼都不做，不然在問題AK-SK禁用前，哪天真的被有心人盯上，導緻的問題會無法挽回。在聯系了阿裡雲同學确認無法針對AK-SK做任何限制之後，得要思考怎麼才能在禁用AK-SK之前盡量緩解這個問題，我們采取的措施如下：
所有的資料跨賬号備份
所幸的是目前賬号下的持久層并不複雜，主要是RDS和OSS兩種，沒有Mongo、Redis、NAS、大資料等等一些列其他産品，那麼我們主要針對這兩種資料做了跨賬号備份操作，跨賬号備份的原因是AK-SK能對目前賬号下的所有資源做操作，隻有把資料備份到其他賬号去，别人才無法徹底抹除我們的資料。
RDS的備份
在另一個賬号中購買開通DBS服務，使用DBS的跨賬号備份功能，實作對問題賬号的RDS資料的實時備份，達到秒級RPO的能力，萬一發生什麼問題，我們可以用DBS來恢複資料到之前任何一個時間點。
OSS的備份
在另一個賬号裡，使用OSS的線上遷移功能，把存量的和增量的OSS檔案遷移過去，這樣如果目前賬号的OSS被做了删除，所有的資料檔案還是能夠在另一個賬号裡找回來。
對目前賬号資源做實時監控和報警
雖然資料做了備份，但萬一整個系統運作環境被破壞了，資料雖然不丢，但業務不可避免的會停頓，重新部署驗證整個業務環境需要很多時間，這樣RTO也會變得非常大，這對公司也是無法接受的，那我們有沒有什麼辦法來知道是否有人對我們的賬号資源來做了什麼額外的事呢？答案是肯定的，就是用ActionTrail搭配SLS來一起實作。
ActionTrail的開通使用
ActionTrail支援資源建立、删除和修改的操作審計，且會記錄這些操作是來自于何處 - 使用者登入的操作還是通過哪個AK的操作，比如我用AK來建立了個SLB：
然後用登入賬号删除了SLB：
可以看出兩者的操作者的差別。
然後ActionTrail還支援另一項好用的功能，就是同步這些記錄檔到SLS中，如：
SLS中的事件查詢
還是和上個步驟中的測試一樣，因為我們在測試之前已經開通了SLS同步的功能，是以這兩個操作其實已經在日志中了。
- 控制台操作資源日志：
一次主賬号AK-SK疑似洩露處理過程 - 通過AK操作資源日志：
一次主賬号AK-SK疑似洩露處理過程
然後我們可以進一步在SLS中針對這些日志進行過濾（如隻關注指定AK的資源操作，因為控制台操作可控），對正常的業務操作帶來的資源變更進行忽略，但和業務無關的資源變動，就設定報警，及時提醒公司的團隊來登入處理 - 如果發生了來自于高危AK的不屬于業務的資源變更，那就說明可能AK-SK已經被有心人拿到并開始搗亂了，我們需要第一時間來采取應急措施 - 比如臨時禁止這個AK-SK，因為通路日志也包括來源IP，我們也可以請求司法機關的協助，讓對方停止侵害行為。
當然後面也可以用這個來監控問題AK在業務中的通路量情況，在通路完全消失或者低到一定程度後表明客戶基本上都已經更新到App新版本，那麼就可以禁用或者删除這個AK了。
ActionTrail的記錄檔的同步是秒級的，是以我們可以盡早的發現問題并采取應急措施。
總結
本文寫的是如何處理疑似主賬号AK-SK洩露的情況，雖然沒能第一時間徹底解決問題，但至少也做了一定的緩解，從資料的安全、監控報警方面采取了必要的措施，不用一直提心吊膽的在猜會發生什麼情況。但切記切記切記，一定一定不要用主賬号AK-SK做任何事情，甚至不要申請主賬号AK-SK才是最應該要做的事