<div class="field field-name-field-image field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img src="https://www.ithome.com.tw/sites/default/files/shu_zhai_-hun_he_yun_an_quan_jia_gou_-9601.jpg" width="960" height="420" alt="" /></div></div></div><div class="field field-name-field-photo-source field-type-text field-label-hidden"><div class="field-items"><div class="field-item even">碁峯資訊</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>建置流程中的主要元素自動化，可大幅縮短開發團隊從設計到正式上線的時間。亦即更快完成功能開發、正式上線，會是相當好的成果。然而，這些自動化流程雖能免除大量手動處理程序，卻可能增加解決方案的弱點，也容易將不安全的程式碼導入正式上線環境。</p>
<p>本章將探討將安全措施納入開發與建置流程的方式，以克服這些挑戰。</p>
<p><span style="color: rgb(178, 34, 34);"><span style="font-size: 28px;"><strong>設計</strong></span></span></p>
<p>在設計階段，會由商業分析師、IT 與安全架構師，共同建立功能性與非功能性需求的待辦清單。這也是開發團隊為待辦事項與缺失之處排列優先順序的階段，這是遭遇的第一個摩擦。開發團隊面臨部署功能性的壓力，往往會調降預防作業與待辦事項中安全性功能或缺陷的優先權。</p>
<p>除了功能性與非功能性需求的定義外，識別濫用案例亦有助於後續測試期間檢測應用程式的商業邏輯漏洞。OWASP <a href="https://owaspsamm.org" target="_blank">SAMM 專案</a>將<a href="https://oreil.ly/mQu6p" target="_blank">誤用與濫用的案例</a>定義為：誤用與濫用案例乃描述意外與惡意的應用程式使用場景，說明攻擊者的做法。</p>
<p>濫用案例定義功能的濫用，亦稱商業邏輯攻擊（business logic attacks）。我們透過定義重要商業規則的功能性需求，來定義濫用案例，驗證應用程式是否正確施行商業規則。</p>
<blockquote><p><span style="color: rgb(255, 255, 255);"><strong><span style="background-color: rgb(0, 0, 0);"> 電子商務購物車的濫用案例 </span></strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>試想以下電子商務購物車場景，攻擊者試圖不當利用電子商務網站的商業邏輯獲得折扣。可以找出的濫用案例如下：</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>限時優惠濫用（Abuse of time-limited offers）</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>若網站提供限時促銷或折扣，攻擊者可以操控系統時鐘或利用其他技術延長促銷期間，在限時促銷優惠之外的時間繼續獲得較低費用。</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>操控品項價格（Manipulation of item prices）</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>試想電子商務網站消費者將商品放進購物籃、計算總價再結帳的過程。系統的商業邏輯是正確計算品項價格、套用折扣，再處理購物車。攻擊者會試圖從另一個角度操控定義，不當利用程式的缺陷，例如試圖截取並操控客戶端與伺服器間的通訊，改變購物車裡的商品價格，或者變更商品數量或單價，以利支付比實際價格更低的款項。</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>濫用有弱點的折扣程式碼（Abuse of weak discount codes）</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>許多網站為顧客提供折扣碼。有些網站僅驗證程式碼語法，而不是實際程式碼本身，等於說攻擊者只需要了解底層語法就能獲得折扣。</strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>這是三個可能的濫用案例，但其實還有更多。對商業邏輯的理解越深入，就越能發掘可以濫用的方式。</strong></span></p>
</blockquote>
<p>理想流程是由商業分析師確立功能性需求，再以此為基礎與安全架構師協同開發濫用案例，這些案例會觸發定義因應措施的需求。</p>
<p><span style="color: rgb(178, 34, 34);"><span style="font-size: 28px;"><strong>開發</strong></span></span></p>
<p>在開發階段，開發人員負責發展實際的程式碼，同時培訓實際撰寫安全程式碼。針對使用的程式語言建立安全程式碼撰寫實作指南，是不錯的作法，開發人員可以將許多靜態應用程式安全測試（SAST）的工具整合到 IDE 裡，在開發階段找出潛在弱點，手動撰寫安全程式碼或同儕審核，都是此階段找出潛在安全問題的有效手段，卡片支付產業資料安全標準<a href="https://oreil.ly/38sbi" target="_blank">（PCI DSS）v4</a>這類標準，就要求審核自訂與客製化的程式碼。<a href="https://oreil.ly/x4e0c" target="_blank">OWASP Code Review Guide</a>概述開發安全程式碼的審核流程必須考量的要素如下：</p>
<p><strong>風險（Risk）</strong></p>
<p>完整審核來源程式碼是不切實際的做法，團隊應以風險為基礎考量，選擇必須手動審核的元件與方法。</p>
<p><strong>目的與背景環境（Purpose and context）</strong></p>
<p>從風險管理的角度來看，理解應用程式的目的與背景環境也是一大重要考量。例如，支付服務所需的安全等級，顯然高於員工餐廳菜單網站。</p>
<p><strong>程式碼行數（Lines of code）</strong></p>
<p>程式碼行數定義所需工作量，也代表可能出錯的數量，因為程式碼行數越多，出錯的可能性也越高。</p>
<p><strong>程式語言（Programming language）</strong></p>
<p>有別於 C 或 C++ 這類語言，部分程式語言例如 Java、C# 由於其語言特性，較不易受到特定安全問題的影響。</p>
<p><strong>資源、時間與時限（Resources, time, and deadlines）</strong></p>
<p>時間當然是關鍵考量，因為手動審核所需的時間與程式碼的規模直接相關。</p>
<p>除了安全程式撰寫的實作，開發階段建立程式碼變更的可追溯性也很重要。開發團隊無論規模大小，常見做法是採用如 Git 等程式碼儲存庫工具，這不僅能確保程式碼變更的可追溯性，也能讓所有開發人員都能協同合作。</p>
<p><span style="color: rgb(178, 34, 34);"><span style="font-size: 28px;"><strong>建置與包裝</strong></span></span></p>
<p>在建置與包裝階段，開發人員會使用各種 script 與工具，自動化軟體的編譯、測試與包裝。我們運用技術，在 CI／CD 管道裡自動化安全測試。針對原始程式碼、容器組態與映像檔的測試表列如下：</p>
<p><strong>靜態應用程式安全測試（SAST）</strong></p>
<p>分析應用程式原始程式碼找出潛在安全弱點。這類測試有助於在應用程式部署前，檢測出常見程式碼的撰寫錯誤，例如緩衝區溢載或 SQL 注入等弱點。SAST 工具逐行掃描來源程式碼，尋找能指出安全性問題的模式或程式碼片段；找出弱點後，開發人員就能採取相應措施來修復。</p>
<p><strong>軟體組成分析（SCA）</strong></p>
<p>軟體開發生命週期中，採用開放原始碼的元件已是常態，開發團隊必須掌握這些元件在應用程式中的部署狀況，以及整合的元件是否含有安全漏洞。軟體組成分析（SCA）有助於識別軟體中可能暴露安全風險的漏洞或過時元件，還能偵測載用特定軟體引發的授權問題，或合規性違規議題。</p>
<blockquote><p><span style="color: rgb(255, 255, 255);"><strong><span style="background-color: rgb(0, 0, 0);"> 軟體物料清單 </span></strong></span></p>
<p><span style="color: rgb(105, 105, 105);"><strong>SCA 工具協助建立並維護軟體物料清單（SBOMs），包括使用到的所有第三方元件的版本與許可權等資訊。美國政府發布促進國家網路安全的執行命令後，SBOM 成為焦點，它要求想與美國政府做生意的公司，全面盤點組成應用程式的所有元件，以提高安全性等級；歐盟也在 EU Cyber Resilience Act裡列入 SBOM 要求。另一例是 2021年，在普遍使用的日誌記錄模組 Log4j 發現的重大漏洞「Log4Shell」，由於Log4j 在企業級產品與開放源碼軟體中的應用過於廣泛，導致許多企業組織難以追蹤其部署位置。想更了解 SBOM，請參閱<a href="https://www.cisa.gov/sbom" target="_blank"> CISA SBOM</a>。</strong></span></p>
</blockquote>
<p><strong>機密掃描（Secrets scan）</strong></p>
<p>開發人員經常把密碼或 API 金鑰這類機密直接寫在來源程式碼裡，這會產生遭對手不當利用的弱點。機密掃描旨在掃描程式碼的儲存庫、密碼及存取金鑰這類機敏資訊的其他資料來源，有各種工具與處理方式可以完成，例如可找出符合特定機敏資訊種類模式的正規表示式。一般而言，原始程式碼、容器映像檔、組態與基礎結構即服務裡，都會有機密資訊。</p>
<p><strong>安全組態檢查（Secure configuration check）</strong></p>
<p>程式碼編譯完成，通常就能部署在容器裡。容器映像檔與其組態會接受弱點掃描、驗證映像檔完整性，與確保遵循企業組織的資安政策與強化指南。許多企業組織以<a href="https://oreil.ly/nqxKg" target="_blank">CIS Benchmarks</a>作為強化指南的依據。</p>
<p>這個階段建置的人為產物，最終會儲存在人為產物儲存庫，以便後續處理時自動化部署至測試、預演與正式上線環境。</p>
<hr />
<p class="rtecenter"><img alt="" src="/sites/default/files/images/%E6%9B%B8%E6%91%98-%E6%B7%B7%E5%90%88%E9%9B%B2%E5%AE%89%E5%85%A8%E6%9E%B6%E6%A7%8B-600.jpg" style="width: 600px;" /></p>
<p><strong><span style="color: rgb(255, 255, 255);"><span style="background-color: rgb(51, 102, 255);"> 書名 </span></span> <span style="color: rgb(51, 102, 255);">混合雲安全架構｜零信任原則的安全設計方法與實作（Security Architecture for Hybrid Cloud）</span></strong></p>
<p>Mark Buckwell, Stefaan Van daele, Carsten Horst／著</p>
<p>歐萊禮、碁峯資訊出版</p>
<p>定價：780元</p>
<hr />
<p><span style="color: rgb(255, 255, 255);"><strong><span style="background-color: rgb(51, 102, 255);"> 作者簡介 </span></strong></span></p>
<p>Mark Buckwell 是擁有30年架構與交付安全解決方案經驗的雲端安全架構師、思想領袖、演說家與訓練師。</p>
<p>Stefaan Van daele 是IBM網路安全服務的區域CTO與安全架構師。</p>
<p>Carsten Horst 是安全架構師，也是具有25年經驗的IBM副合夥人。</p>
</div></div></div>
