【51CTO.com快譯】秘密管理是容器安全的重要組成部分。我們在本文中介紹管理秘密(即密碼、API密鑰和令牌等)的幾個優秀實踐，以便緩解容器安全風險和漏洞。

[[263604]]

1. 區別秘密和標識符

在容器環境下，秘密是指一旦暴露在未經授權的個人或實體面前，貴公司、客戶或應用程序將面臨風險的任何信息。隨著系統變得更復雜，涉及的秘密信息量隨之增加，涉及的風險也隨之加大。系統中的不定因素越多，面臨的風險就越大。

值得一提的是，并非所有信息都是秘密信息。一些信息(比如用戶名和TLS證書)是標識符，需要有選擇地加以共享。標識符并非完全沒有風險，但其風險遠低于秘密。然而，與標識符有關的密碼和密鑰應被視為秘密。

2. 建立信任圈

系統的某些部分可以完全信任(比如CPU、RAM、root用戶或擁有適當安全策略的秘密管理工具)。系統的一些部分只能選擇性地信任(比如被授予明確權限，以訪問受保護的某些秘密或S3等云服務的員工)。外部實體默認情況下不可信任。它們包括隨機用戶或WiFi熱點。透露給這些實體的秘密會泄密，因此導致風險。

3. 深入了解信任鏈

秘密流經系統時，它們觸及這些不同的實體。秘密所走的路徑是決定秘密是安全還是已泄密的關鍵。每一步都是“一環”，全部環連起來就組成了“一條鏈”。全面深入了解整條鏈很重要。這樣一來，你就可以建立信任鏈，確保只有信任圈內的實體才能訪問秘密。

4. 使用KMS加密數據

對機密數據而言，光使用防火墻不夠安全;受密碼保護的數據庫也不夠安全。它們離完全泄密只有一步之遙。相反，需要的是可以在多個層面加密數據的密鑰管理服務(KMS)。你應該能夠使用加密密鑰加密整個文件，并使用不同的加密密鑰加密該文件中的部分數據。

這樣一來，你只能共享數據的特定部分，而不必讓其余數據面臨風險。這限制了潛在威脅影響范圍。然而，在本地環境創建和管理加密密鑰很繁瑣。如果使用云原生容器應用程序，有必要使用基于云的加密服務，比如AWS KMS或類似的替代方案。它們擁有高級功能，可以自動化并極大地控制加密密鑰的創建和管理。

5. 經常輪換秘密

長期保持不變的秘密更有可能泄密。隨著更多的用戶訪問秘密，某人有可能處理不當，泄露給未經授權的實體。秘密可以通過日志和緩存數據泄露出去。它們可以共享用于調試;一旦調試完成，就不可更改或撤銷。它們可能被黑客破解。由于所有這些原因，秘密應經常輪換。

6. 自動創建密碼

創建密碼和訪問密鑰的方式對其安全性至關重要。人們手動創建密碼會帶來災難。據Troy Hunt聲稱，85%的密碼都不安全。消除糟糕密碼的方法是，使用機器自動生成的密碼，這些密碼具有獨特性，不易被破解。今天，大多數秘密管理工具都擁有密碼自動生成這項默認功能。

7. 負責任地存儲秘密

秘密管理工具對容器安全而言已變得不可或缺。它們的首要重心是防止秘密被保存在磁盤上、嵌入代碼中，或者嵌入到秘密管理器本身之外的系統的任何部分。這是個文化問題，很難在大團隊中實施。然而有必要使用秘密工具來創建密碼，并借助到期失效的令牌，使用同樣的工具共享密碼。

8. 發現未經授權的訪問

盡管你努力了，但在某個時候，秘密還是可能會泄密。在這種情況下，你的所有先前計劃將經受測試，盡早發現事件(這是你需要部署安全監控工具的原因)。

你還應準備好制定計劃，一旦發現泄密就迅速響應。假設你在泄密發生一小時后發現了情況。你能多快地禁止訪問惡意用戶或實體?在這里，全面控制系統中每個點的密碼和經過深思熟慮的架構必不可少。需要更改系統中的所有密碼，作為預防措施。這可以輕松實現嗎?一旦所有密碼更改，能不能通知合法用戶、能不能立即為他們授予訪問權限?萬一系統宕機，密碼管理器是否仍正常運行?

確保你能夠發現泄密，并已制定了管理上面列出的所有考量因素的計劃。

結論

容器為IT管理員和DevSecOps團隊帶來了新的安全挑戰。然而，如果了解潛在風險以及減輕這些風險的方法，你可以建立起更可靠、幾乎萬無一失的安全機制。

原文標題：8 Best Practices for Container Secrets Management，作者：Twain Taylor

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】