譯者 | 劉汪洋
審校 | 重樓
軟件的開發、部署和管理模式已經因云原生架構而發生了根本性的變革。盡管它在可擴展性、彈性和靈活性上提供了巨大優勢，但同時也帶來了一些特有的安全挑戰。
這些挑戰與傳統單體應用的安全問題有著顯著的區別。對于開發人員而言，理解這些差異至關重要。尤其是在現代云原生應用程序中，既有傳統安全挑戰又有新興安全問題，這要求開發者進行全面應對。
本文將介紹六種用于構建安全、彈性和可擴展的云原生應用程序的關鍵安全編程最佳實踐。這些實踐不僅是理想選擇，更是構筑任何云原生應用程序綜合安全架構的基石。
云原生應用的六大安全最佳實踐
- 零信任架構
- 輸入驗證
- 網絡暴露控制
- 安全的文件存儲
- 最小權限原則
- 日志數據脫敏
零信任架構
在云原生生態中，微服務的模塊化設計既有其優勢，也伴隨著挑戰。在開發微服務時，我們不能預設它們在更廣泛應用程序中的具體使用方式。微服務的核心特征是可復用性和模塊化，這意味著最初為特定目的設計的微服務，可能在未來被用于具有完全不同安全要求的應用中。
因此，在云原生環境中，對每個微服務采用零信任的策略是至關重要的。這種方法保證各個服務之間不會盲目信任，進而無論如何使用，都能提升每個微服務的安全防護水平。零信任的兩個核心組成部分是微分段和服務間認證。
微分段是將應用程序拆分成更小、更易于管理的部分（即微服務），并為每個部分實施獨立的安全措施。這樣，即使某個部分受到攻擊，其影響也能被限制在最小范圍內。比如，在云原生電商應用中，可將庫存管理、支付處理和用戶認證拆分為獨立微服務，并為每個服務實施合適的安全措施。
服務間認證不僅限于用戶驗證，它還確保了服務之間在交換數據前相互驗證身份。這可以通過相互 TLS（mTLS）等技術實現。比如，在電商平臺中，庫存微服務在請求支付微服務提供支付信息時，可以利用相互 TLS 進行雙方身份的驗證。
輸入驗證
攻擊手段，如 SQL 注入和文件路徑遍歷，常通過利用弱輸入驗證機制來實施。在一個包含多個 API 的云原生應用程序中，這種攻擊的風險更加突出。因此，對每個輸入進行嚴格的驗證和清洗是維護安全的關鍵。所有數據，無論來源于終端用戶、其他服務還是內部數據庫，都應被視為潛在的安全威脅。
嚴格的 API 安全措施包括實施類型檢查、邊界驗證和建立白名單。類型檢查和邊界驗證要求驗證輸入數據的類型，確保它們符合預期，并為不同類型的輸入設定限制，防止溢出、下溢或其他基于惡意輸入的攻擊。
舉例來說，一個電商網站的“購買數量”字段應只接受正整數，拒絕負數或非數字字符，并可能設定最大數量限制（如 100），以防大量虛假或有害的訂單。
白名單機制涉及維護一個允許的輸入或值范圍列表，僅接受符合這些預設標準的輸入。例如，一個用于自定義功能的 API 若接受顏色輸入，則應使用白名單來限制特定的顏色代碼，如用 #FF0000 代表紅色。
網絡暴露控制
應用程序在互聯網上暴露的部分越多，其攻擊面就越廣。這對于云原生應用程序尤其重要，其功能通常分布在眾多松散耦合的服務之間。通過限制僅將互聯網訪問權限賦予必需組件，可以減少潛在的攻擊入口。關鍵的網絡暴露控制措施包括防火墻規則、虛擬私有云（VPC）的配置和管理配置漂移。
應用高級防火墻設置以封鎖所有不必要的端口，并通過網絡分段來隔離不同服務，最小化每項服務的暴露程度。例如，可以將支付網關與主應用服務隔離，確保即使一個服務被攻破，其他服務依然安全。
部署 VPC 以隔離應用程序的不同部分，包括為不同服務類型設置獨立的子網，并通過網絡訪問控制列表（ACL）來限制它們之間的流量。例如，可將電商應用劃分為用戶認證、產品目錄和支付處理等不同的 VPC。
監控服務配置的漂移情況。通常，由于其他地方的變更，內部服務可能無意間被公開暴露，例如為適應與無關的 API 請求的修改。對任何意外的配置更改設置警報，并及時處理任何漂移情況。
例如，假設一個僅供管理層使用的內部報告服務，因無關的 API 變更而意外暴露給普通員工或公眾，配置漂移管理工具能夠提醒開發團隊這一變化，并促使他們立即進行修復。
安全文件存儲
在存儲數據時，尤其是涉及敏感信息的文件，需要采取更高級別的安全措施。雖然數據庫本身存在安全風險，但不當處理的文件存儲可能更加危險。存儲的文件，尤其是包含敏感數據的文件，應在不被訪問或使用時（即靜止狀態）進行加密。此外，還需要嚴格的訪問控制措施，以限制對這些文件的訪問權限。
安全文件存儲的實踐包括對文件進行靜態加密和實施基于角色的訪問控制（RBAC），同時也要特別注意臨時文件的安全管理，因為這些“臨時”文件可能并非真正的臨時。
為確保數據存儲的安全性，應始終采用由存儲平臺提供的內置加密技術。即使攻擊者獲得了物理存儲設備，加密也使得數據無法被讀取。例如，在云存儲解決方案中，使用內置的加密方法對用戶數據進行加密，然后再存儲。
實施基于角色的訪問控制來管理對存儲文件的訪問，并記錄所有訪問活動以形成審計跟蹤。例如，在醫療保健應用程序中，可能只允許某些醫療人員訪問病人記錄。
在處理或調試過程中產生的臨時文件需小心處理，以防它們不經意間包含敏感信息。應實施自動化清理這些文件的程序，并確保它們不會超出必要時間存留。
例如，如果開發人員在排查用戶認證問題時生成了臨時日志，那么在問題解決后自動清除這些日志就至關重要，以確保敏感數據不會遺留。要記住，疏忽可能導致安全漏洞（即便是像微軟這樣的大公司也不能幸免），因此在清理過程中保持警覺至關重要。
最小權限原則
在云原生應用程序開發中實行最小權限原則是非常重要的。服務應僅具備執行其功能所必需的權限，這樣可以最大限度地減少一個服務被攻破后用于攻擊系統其他部分的風險。在代碼中應用最小權限原則的具體做法包括限定權限范圍、使用臨時憑證和定期進行權限審計。
細化權限設置，確保其與每個組件的具體職責相匹配。例如，API的權限設置經常被忽視。你的 API 真的需要讀寫權限嗎？如果是的話，可以考慮將其拆分為兩個不同的 API，并在每個 API 中僅授予必需的最小權限。
例如，一個用戶注冊服務（可能需要修改數據）應該擁有與僅提供數據報告的只讀服務不同的權限范圍。
對于需要更多權限的操作，使用短期憑證，并確保這些憑證在任務完成后立即失效。例如，在進行需要較高權限的備份操作時，可以使用臨時憑證，并在備份完成后立即使其失效。
定期且頻繁地進行審計，以識別權限設置過于寬松的情況，并采取糾正措施。自動化工具可以用于標記這些過度權限并提出改進建議。例如，定期使用自動化審計工具審查系統的角色和權限，突出顯示任何權限過大的情況，并采取相應措施將這些權限范圍縮小。
日志數據脫敏
日志記錄是監控和調試的關鍵環節，但日志中可能含有敏感信息。數據脫敏能夠確保當敏感信息出現在日志中時，它們被替換為屏蔽版本，從而降低數據泄露風險。實施數據脫敏的關鍵步驟包括自動化編輯工具的使用、集中式日志管理和嚴格的日志保留政策。
采用專業軟件工具自動識別并編輯日志中的敏感信息。這些工具可以被編程來識別社會安全號碼、信用卡號碼或密碼等敏感信息的模式。例如，在金融應用中，確保在記錄日志前自動編輯掉信用卡信息，僅保留用于參考的最后四位數字。
部署集中化日志管理系統，匯總來自不同來源的日志。這不僅加強監控，還確保脫敏和編輯策略在所有日志上統一應用，減少敏感數據泄露的風險。例如，在多個微服務的分布式云原生應用中，將所有服務的日志匯總到一個中心系統中，確保所有傳入日志統一應用數據脫敏規則。
制定嚴格的日志保留政策，并與任何合規要求保持一致。自動刪除超出保留期限的日志。例如，為了遵守歐盟通用數據保護條例（General Data Protection Regulation，簡稱 GDPR），設定包含個人數據的日志在 30 天后自動刪除，除非出于審計或法律原因需要保留。
朝著更優秀的安全實踐邁進
構建安全、彈性和可擴展的云原生應用程序需要與傳統應用開發不同的最佳實踐。關鍵是從零信任架構到日志數據脫敏，將這些實踐盡早整合到開發生命周期中，使安全成為設計和部署過程中不可或缺的一部分。
同時，了解在實際開發環境中實施這些安全實踐所面臨的挑戰也非常重要。在快節奏的開發環境中，整合所有這些安全實踐看似一項艱巨任務。然而，開發者必須意識到相關風險。關鍵不是一蹴而就能達到完美，而是要優先了解每種實踐，并根據特定應用程序的需求和背景，策略性地決定何時整合哪些實踐。
隨著網絡安全環境的不斷發展，我們保護這些復雜、分布式系統的策略也必須跟上。理解本文闡述的實踐和見解，對于你制定出具有洞察力和靈活性的云原生應用安全策略將大有裨益。
譯者介紹
劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師，擁有多個主流技術博客平臺博客專家稱號。
原文標題：6 security best practices for cloud-native applications，作者：Yossi Pik
