譯者 | 劉汪洋

審校 | 重樓

軟件的開發(fā)、部署和管理模式已經(jīng)因云原生架構(gòu)而發(fā)生了根本性的變革。盡管它在可擴展性、彈性和靈活性上提供了巨大優(yōu)勢，但同時也帶來了一些特有的安全挑戰(zhàn)。

這些挑戰(zhàn)與傳統(tǒng)單體應用的安全問題有著顯著的區(qū)別。對于開發(fā)人員而言，理解這些差異至關重要。尤其是在現(xiàn)代云原生應用程序中，既有傳統(tǒng)安全挑戰(zhàn)又有新興安全問題，這要求開發(fā)者進行全面應對。

本文將介紹六種用于構(gòu)建安全、彈性和可擴展的云原生應用程序的關鍵安全編程最佳實踐。這些實踐不僅是理想選擇，更是構(gòu)筑任何云原生應用程序綜合安全架構(gòu)的基石。

云原生應用的六大安全最佳實踐

• 零信任架構(gòu)
• 輸入驗證
• 網(wǎng)絡暴露控制
• 安全的文件存儲
• 最小權(quán)限原則
• 日志數(shù)據(jù)脫敏

零信任架構(gòu)

在云原生生態(tài)中，微服務的模塊化設計既有其優(yōu)勢，也伴隨著挑戰(zhàn)。在開發(fā)微服務時，我們不能預設它們在更廣泛應用程序中的具體使用方式。微服務的核心特征是可復用性和模塊化，這意味著最初為特定目的設計的微服務，可能在未來被用于具有完全不同安全要求的應用中。

因此，在云原生環(huán)境中，對每個微服務采用零信任的策略是至關重要的。這種方法保證各個服務之間不會盲目信任，進而無論如何使用，都能提升每個微服務的安全防護水平。零信任的兩個核心組成部分是微分段和服務間認證。

微分段是將應用程序拆分成更小、更易于管理的部分（即微服務），并為每個部分實施獨立的安全措施。這樣，即使某個部分受到攻擊，其影響也能被限制在最小范圍內(nèi)。比如，在云原生電商應用中，可將庫存管理、支付處理和用戶認證拆分為獨立微服務，并為每個服務實施合適的安全措施。

服務間認證不僅限于用戶驗證，它還確保了服務之間在交換數(shù)據(jù)前相互驗證身份。這可以通過相互 TLS（mTLS）等技術(shù)實現(xiàn)。比如，在電商平臺中，庫存微服務在請求支付微服務提供支付信息時，可以利用相互 TLS 進行雙方身份的驗證。

輸入驗證

攻擊手段，如 SQL 注入和文件路徑遍歷，常通過利用弱輸入驗證機制來實施。在一個包含多個 API 的云原生應用程序中，這種攻擊的風險更加突出。因此，對每個輸入進行嚴格的驗證和清洗是維護安全的關鍵。所有數(shù)據(jù)，無論來源于終端用戶、其他服務還是內(nèi)部數(shù)據(jù)庫，都應被視為潛在的安全威脅。

嚴格的 API 安全措施包括實施類型檢查、邊界驗證和建立白名單。類型檢查和邊界驗證要求驗證輸入數(shù)據(jù)的類型，確保它們符合預期，并為不同類型的輸入設定限制，防止溢出、下溢或其他基于惡意輸入的攻擊。

舉例來說，一個電商網(wǎng)站的“購買數(shù)量”字段應只接受正整數(shù)，拒絕負數(shù)或非數(shù)字字符，并可能設定最大數(shù)量限制（如 100），以防大量虛假或有害的訂單。

白名單機制涉及維護一個允許的輸入或值范圍列表，僅接受符合這些預設標準的輸入。例如，一個用于自定義功能的 API 若接受顏色輸入，則應使用白名單來限制特定的顏色代碼，如用 #FF0000 代表紅色。

網(wǎng)絡暴露控制

應用程序在互聯(lián)網(wǎng)上暴露的部分越多，其攻擊面就越廣。這對于云原生應用程序尤其重要，其功能通常分布在眾多松散耦合的服務之間。通過限制僅將互聯(lián)網(wǎng)訪問權(quán)限賦予必需組件，可以減少潛在的攻擊入口。關鍵的網(wǎng)絡暴露控制措施包括防火墻規(guī)則、虛擬私有云（VPC）的配置和管理配置漂移。

應用高級防火墻設置以封鎖所有不必要的端口，并通過網(wǎng)絡分段來隔離不同服務，最小化每項服務的暴露程度。例如，可以將支付網(wǎng)關與主應用服務隔離，確保即使一個服務被攻破，其他服務依然安全。

部署 VPC 以隔離應用程序的不同部分，包括為不同服務類型設置獨立的子網(wǎng)，并通過網(wǎng)絡訪問控制列表（ACL）來限制它們之間的流量。例如，可將電商應用劃分為用戶認證、產(chǎn)品目錄和支付處理等不同的 VPC。

監(jiān)控服務配置的漂移情況。通常，由于其他地方的變更，內(nèi)部服務可能無意間被公開暴露，例如為適應與無關的 API 請求的修改。對任何意外的配置更改設置警報，并及時處理任何漂移情況。

例如，假設一個僅供管理層使用的內(nèi)部報告服務，因無關的 API 變更而意外暴露給普通員工或公眾，配置漂移管理工具能夠提醒開發(fā)團隊這一變化，并促使他們立即進行修復。

安全文件存儲

在存儲數(shù)據(jù)時，尤其是涉及敏感信息的文件，需要采取更高級別的安全措施。雖然數(shù)據(jù)庫本身存在安全風險，但不當處理的文件存儲可能更加危險。存儲的文件，尤其是包含敏感數(shù)據(jù)的文件，應在不被訪問或使用時（即靜止狀態(tài)）進行加密。此外，還需要嚴格的訪問控制措施，以限制對這些文件的訪問權(quán)限。

安全文件存儲的實踐包括對文件進行靜態(tài)加密和實施基于角色的訪問控制（RBAC），同時也要特別注意臨時文件的安全管理，因為這些“臨時”文件可能并非真正的臨時。

為確保數(shù)據(jù)存儲的安全性，應始終采用由存儲平臺提供的內(nèi)置加密技術(shù)。即使攻擊者獲得了物理存儲設備，加密也使得數(shù)據(jù)無法被讀取。例如，在云存儲解決方案中，使用內(nèi)置的加密方法對用戶數(shù)據(jù)進行加密，然后再存儲。

實施基于角色的訪問控制來管理對存儲文件的訪問，并記錄所有訪問活動以形成審計跟蹤。例如，在醫(yī)療保健應用程序中，可能只允許某些醫(yī)療人員訪問病人記錄。

在處理或調(diào)試過程中產(chǎn)生的臨時文件需小心處理，以防它們不經(jīng)意間包含敏感信息。應實施自動化清理這些文件的程序，并確保它們不會超出必要時間存留。

例如，如果開發(fā)人員在排查用戶認證問題時生成了臨時日志，那么在問題解決后自動清除這些日志就至關重要，以確保敏感數(shù)據(jù)不會遺留。要記住，疏忽可能導致安全漏洞（即便是像微軟這樣的大公司也不能幸免），因此在清理過程中保持警覺至關重要。

最小權(quán)限原則

在云原生應用程序開發(fā)中實行最小權(quán)限原則是非常重要的。服務應僅具備執(zhí)行其功能所必需的權(quán)限，這樣可以最大限度地減少一個服務被攻破后用于攻擊系統(tǒng)其他部分的風險。在代碼中應用最小權(quán)限原則的具體做法包括限定權(quán)限范圍、使用臨時憑證和定期進行權(quán)限審計。

細化權(quán)限設置，確保其與每個組件的具體職責相匹配。例如，API的權(quán)限設置經(jīng)常被忽視。你的 API 真的需要讀寫權(quán)限嗎？如果是的話，可以考慮將其拆分為兩個不同的 API，并在每個 API 中僅授予必需的最小權(quán)限。

例如，一個用戶注冊服務（可能需要修改數(shù)據(jù)）應該擁有與僅提供數(shù)據(jù)報告的只讀服務不同的權(quán)限范圍。

對于需要更多權(quán)限的操作，使用短期憑證，并確保這些憑證在任務完成后立即失效。例如，在進行需要較高權(quán)限的備份操作時，可以使用臨時憑證，并在備份完成后立即使其失效。

定期且頻繁地進行審計，以識別權(quán)限設置過于寬松的情況，并采取糾正措施。自動化工具可以用于標記這些過度權(quán)限并提出改進建議。例如，定期使用自動化審計工具審查系統(tǒng)的角色和權(quán)限，突出顯示任何權(quán)限過大的情況，并采取相應措施將這些權(quán)限范圍縮小。

日志數(shù)據(jù)脫敏

日志記錄是監(jiān)控和調(diào)試的關鍵環(huán)節(jié)，但日志中可能含有敏感信息。數(shù)據(jù)脫敏能夠確保當敏感信息出現(xiàn)在日志中時，它們被替換為屏蔽版本，從而降低數(shù)據(jù)泄露風險。實施數(shù)據(jù)脫敏的關鍵步驟包括自動化編輯工具的使用、集中式日志管理和嚴格的日志保留政策。

采用專業(yè)軟件工具自動識別并編輯日志中的敏感信息。這些工具可以被編程來識別社會安全號碼、信用卡號碼或密碼等敏感信息的模式。例如，在金融應用中，確保在記錄日志前自動編輯掉信用卡信息，僅保留用于參考的最后四位數(shù)字。

部署集中化日志管理系統(tǒng)，匯總來自不同來源的日志。這不僅加強監(jiān)控，還確保脫敏和編輯策略在所有日志上統(tǒng)一應用，減少敏感數(shù)據(jù)泄露的風險。例如，在多個微服務的分布式云原生應用中，將所有服務的日志匯總到一個中心系統(tǒng)中，確保所有傳入日志統(tǒng)一應用數(shù)據(jù)脫敏規(guī)則。

制定嚴格的日志保留政策，并與任何合規(guī)要求保持一致。自動刪除超出保留期限的日志。例如，為了遵守歐盟通用數(shù)據(jù)保護條例（General Data Protection Regulation，簡稱 GDPR），設定包含個人數(shù)據(jù)的日志在 30 天后自動刪除，除非出于審計或法律原因需要保留。

朝著更優(yōu)秀的安全實踐邁進

構(gòu)建安全、彈性和可擴展的云原生應用程序需要與傳統(tǒng)應用開發(fā)不同的最佳實踐。關鍵是從零信任架構(gòu)到日志數(shù)據(jù)脫敏，將這些實踐盡早整合到開發(fā)生命周期中，使安全成為設計和部署過程中不可或缺的一部分。

同時，了解在實際開發(fā)環(huán)境中實施這些安全實踐所面臨的挑戰(zhàn)也非常重要。在快節(jié)奏的開發(fā)環(huán)境中，整合所有這些安全實踐看似一項艱巨任務。然而，開發(fā)者必須意識到相關風險。關鍵不是一蹴而就能達到完美，而是要優(yōu)先了解每種實踐，并根據(jù)特定應用程序的需求和背景，策略性地決定何時整合哪些實踐。

隨著網(wǎng)絡安全環(huán)境的不斷發(fā)展，我們保護這些復雜、分布式系統(tǒng)的策略也必須跟上。理解本文闡述的實踐和見解，對于你制定出具有洞察力和靈活性的云原生應用安全策略將大有裨益。

譯者介紹

劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個擁有 5 年開發(fā)經(jīng)驗的某大廠高級 Java 工程師，擁有多個主流技術(shù)博客平臺博客專家稱號。

原文標題：6 security best practices for cloud-native applications，作者：Yossi Pik