如果你熟悉敏捷開發流程，那么你可能已經了解一些術語和方法。 “左移” 是一個最近越來越受關注的敏捷概念。這個短語指的是軟件開發生命周期中常見的從左到右的表示方式——當你在API項目的某個方面“左移”時，你就是在項目的最早期階段（概念開發和設計階段）投入資源。資源是有限的，所以在一個領域“左移”可能會讓你覺得會影響API項目的其他方面。
當你構建或集成一個新的API時，你可能會聽到有人建議你加強安全性。聽從這個建議。安全性不是一種取舍——它是必不可少的。當你在API設計過程中盡早融入安全性時，你就打造了一個更加耐用的產品，減少了后續干預的必要性。
想象一下，你正在購買一輛新車。它必須能夠帶你和家人去你們需要去的地方——基本功能是首要的。但雖然像加熱座椅和高性能發動機這樣的附加功能令人愉悅，安全性卻是不可妥協的。如果你知道一家汽車制造商的安全記錄遠比另一家更強，你的選擇就會非常明確。
將你的API視為一種產品，要求你從用戶的角度來看待它。就像你在考慮汽車的基本功能之外的內容一樣，你的用戶也會基于性能、附加功能和安全性來評估你的API。越來越多的API用戶意識到，API集成中的安全性就像汽車的安全性一樣重要。
當你的開發人員和用戶知道安全性和隱私從一開始就被融入到你的產品中時，他們會有更大的信心去創新和構建。在安全性上“左移”是對平穩API之旅的投資。
讓我們花點時間考慮一下軟件漏洞如何演變為安全事件。一般模式通常是這樣的：
然而，并非每個使用公司A API的公司都同樣容易受到攻擊。請注意，在導致這一漏洞的過程中發生了多少次人為錯誤！事實上，大多數安全漏洞和數據泄露事件都是由于人為錯誤造成的。
一個在開發周期的“右”端留待處理安全性的API項目通常更容易受到人為錯誤的影響。當你的安全策略全部基于現實世界的測試和修補時，通常只有在漏洞已經進入實際環境后你才會發現它們。采用“左移”的方法可以讓你有時間從頭到尾設計全面的API安全性。你的安全策略需要通過以下三種方式來應對人為錯誤：
我們將在下面更詳細地探討每一點。
為了實現更好的性能和可靠性，你已經在為數據和網絡架構做出決策。安全性應該得到同等的關注。在概念開發和設計的早期階段，你的安全重點應該放在架構上，以減少攻擊可能造成的潛在損害。
安全工程的兩個核心原則是：較小的攻擊面使得攻擊更易于防范，而數據隔離使得攻擊可能造成的損害不那么嚴重。對于一個API項目來說，這可能意味著設計兩個獨立的API來處理不同敏感級別的數據，或者只允許通過防火墻后的某些端點訪問。這些都是你希望在設計過程中早期做出的決策，以避免后期代價高昂的重構或不必要的復雜性。
除了“左移”之外，另一個你經常在安全討論中聽到的短語是“零信任”。它是在上述理念的基礎上擴展的，基于“永不信任，總是驗證”的原則，旨在為每個用戶提供最小可能的訪問權限。真正的零信任架構在組織層面難以實現，但朝這個方向邁出一步可以最大限度地降低風險。以下是你可以在API中采用的一些關鍵零信任原則：
對于以API為驅動的企業來說，其中一些做法特別具有挑戰性——因此，API通常成為攻擊者的目標。由于API旨在簡化數據共享，接近零信任需要一些額外的考慮：
保護API的下一步是將自動化安全工程融入開發流程中。僅靠代碼審查是一個糟糕的安全管理方式——它們被證明非常低效，甚至在識別出漏洞時，也會將解決這些問題的過程推遲到開發流程的后期，浪費了大量時間。開發團隊往往高估了在開發周期后期修復漏洞的能力，導致帶外修補程序發布和破壞性變更。
安全工程在系統層面進行時效果最好，這提高了可靠性，減少了中斷。我們上面概述的做法是一種方法；減少攻擊面、隔離數據并使隱私成為默認設置，這些都將轉化為更少的潛在漏洞。第二步是確保這些做法在你的API項目中始終如一地得到實施。這種方法有時被稱為DevSecOps，旨在以“免提”的方式將安全集成到代碼生命周期中。
DevSecOps的目標是減少人為錯誤的可能性。與代碼審查依賴個體來識別對高度復雜系統有影響的小細節不同，DevSecOps通過威脅建模、代碼分析和代碼審查工具、鏡像掃描等內嵌在軟件開發生命周期中的流程來自動化代碼合規性。當你部署這些工具時，你是在構建多層次的審查機制，這些機制應用客觀標準、綜合的漏洞跟蹤和強大的處理能力。
說自動化可以提高API安全性，這并不是對你工程團隊的否定——DevSecOps方法允許他們專注于設計和構建出色的產品，并大大降低了漏洞進入生產環境的可能性。DevSecOps方法將最需要深思熟慮的安全討論推向產品生命周期的早期階段，然后使用自動化工具在你構建過程中執行你選擇的標準。最終結果是更少的破壞性變更和API團隊的更少壓力。
無論你最終為API項目實施何種技術解決方案，必須記住，技術本身是不夠的。沒有任何技術解決方案是萬無一失的，尤其是在安全形勢不斷變化的情況下。為了跟上變化的步伐，你的組織思維也需要改變。
構建以安全為先的文化并不是要在員工中灌輸焦慮。相反，要賦予你的團隊知識，吸引他們參與關于風險的透明對話，并創建渠道來揭示和跟蹤漏洞。SolarWinds的首席信息安全官Tim Brown因他在2020年處理重大漏洞的方式而備受贊譽。在《每日海浪》的一次采訪中，他闡述了自己的理念：“我們可以向行業展示的最大教訓之一就是，通過承認所發生的事情并做出恢復，贏得尊重。你不需要隱瞞。”
構建以安全為先的文化是對長期的投資。當你就所有風險管理方面（包括技術和人為）進行公開討論時，你的員工可以更加自信地開展工作，知道有系統可以減少風險并主動應對問題。如果你能夠始終如一地及早解決安全問題，并明確采取行動以減少人為風險，你將增加API產品的穩定性，并減少組織的干擾。
安全工作永遠不會完成。你需要不斷重新審視你實施的做法，重新設計解決方案并重新培訓員工。不過請記住，安全性是你API項目的一個重要功能。就像你不斷迭代產品的其他功能一樣，你也需要在API安全性上不斷迭代，并將其融入到整個產品生命周期的設計審查過程中。
成功的API安全計劃的秘訣在于批判性思維。沒有硬性規定，也沒有保證的規則。行業最佳實踐是很好的指導方針，但它們只是一個起點。努力深入了解影響組織安全需求的獨特技術和人為因素。你需要與整個組織中的人員進行互動，從客戶支持到財務再到工程。傾聽他們的擔憂，了解他們如何使用你的API，并觀察他們如何處理已知的漏洞。然后建立適合你特定需求的安全實踐。
文章來源：Where Security Fits in Your API Design Process