創新安全性

  • 發行項

創新是組織在數位時代的命脈，且必須同時實踐和保護。 創新安全性可保護創新的流程和資料，以防止網路攻擊。 數位時代的創新使用 DevOps 或 DevSecOps 方法來開發應用程式，進而快速進行創新，而無須等待版本間數月或數年的傳統瀑布式運輸排程。

DevSecOps 活動

開發新功能和應用程式需要成功滿足三種不同的需求類型：

  • 業務開發 (Dev)：您的應用程式必須符合快速演變的業務或使用者需求。
  • 安全性 (Sec)：您的應用程式必須能隨時因應來自不斷變化的攻擊者攻擊，並發揮安全性防禦的創新功能。
  • IT 維運 (Ops)：您的應用程必須具有穩定性並可以有效率地執行。

將這三項需求一併結合後，接著建立共用文化特性至關重要，但通常極具挑戰性。 開發、IT 和安全性小組的領導人必須共同合作來推動這項變更。 如需詳細資訊，請參閱領導關鍵：融入文化特性 (英文)。

觀看下列影片，以深入瞭解 DevSecOps 方法的安全與快速創新。

什麼是 DevSecOps？

技術創新通常是在快速簡潔且敏捷開發方法的環境中開發，這種方法是將開發和維運融入 DevOps 流程中。 我們已了解將安全性整合至該流程至關重要，目的是降低創新流程、組織成長和組織中現有資產的風險。 將安全性整合至流程中時，會建立 DevSecOps 流程。

基於安全性的設計和測試左移 (shifting left)

隨著組織採用 DevOps 與其他快速的創新方法，安全性必須涵蓋至整個組織和其開發流程。 在流程中整合安全性延遲的成本很高，而且難以修正。

在時間表中左移安全性，以將其整合至構想、設計和實作流程及產品和服務的維運。 當將開發小組移至 DevOps 並採用雲端技術時，安全性必須是該轉換的一部分。

整個程式的安全性

在瀑布模型中，在開發完成後，安全性在傳統上是品質防線。

DevOps 擴展了傳統的開發模型 (人員、流程和技術) 以納入維運小組。 這項變更減少了開發和維運小組分開所造成的分歧。 同理，DevSecOps 會擴展 DevOps，以減少個別或不同安全性小組的分歧。

DevSecOps 是安全性與每個階段 DevOps 生命週期的整合，從構想、架構設計、反復應用程式開發和維運的流程。 小組必須同時與創新速度、可靠性和安全性復原能力的目標一致。 透過相互理解和尊重彼此的需求，小組將會先處理最重要的問題，不論問題來源為何。

雲端採用架構的組織方法提供組織中 DevSecOps 結構的進一步內容。 如需詳細資訊，請參閱了解應用程式安全性和 DevSecOps 功能。

為什麼選擇 DevSecOps？

DevOps 提供靈活度，而 DevSecOps 則提供安全的靈活度。

全球各地的每個組織都密切注意軟體發展，以透過創新獲得競爭優勢。 保護 DevOps 流程對於組織的成功非常重要。 攻擊者已注意自訂應用程式的改變，並在攻擊期間對自訂應用程式的攻擊會逐漸增加。 這些新的應用程式通常是有價值智慧財產的豐富來源，其中包含尚未上市產品的重要的新構想。

保護這項創新需要組織針對開發流程和裝載應用程式的基礎結構，解決潛在的安全性弱點和攻擊。 此方法適用於雲端和內部部署。

攻擊者機會

攻擊者可能會利用下列項目中的弱點：

  • 開發流程：攻擊者可能會發現應用程式設計流程中的弱點，例如使用弱式或無加密的方式進行通訊。 或者，攻擊者可能會發現執行設計時的弱點，例如，程式碼不會驗證輸入，並允許 SQL 插入等常見的攻擊。 此外，攻擊者可能會在程式碼中植入後門程式，以便稍後可以在您的環境或客戶的環境中惡意探索。
  • IT 基礎結構：攻擊者可能會使用標準攻擊，危害開發流程裝載的端點和基礎結構元素。 攻擊者也可能會進行多階段攻擊，使用遭竊的認證或惡意程式碼透過環境的其他部分存取開發基礎結構。 此外，軟體供應鏈攻擊的風險使得將安全性整合至流程，對下列兩項至關重要：
  • 保護您的組織：防止來源程式碼供應鏈中具有惡意程式碼和漏洞
  • 保護您的客戶：防止應用程式和系統中發生任何安全性問題，因為這可能會導致您的組織有信譽受損、責任或其他負面的業務衝擊

DevSecOps 旅程圖

大部分的組織會發現，任何指定工作負載或應用程式的 DevOps 或 DevSecOps 實際上皆是兩階段的流程，其中構想會先在安全空間中生成，然後再發行到實際執行環境並不斷更新。

下圖顯示這種創新工廠方法的生命週期：

DevSecOps 階段

安全創新是這兩個階段的整合式方法：

  • 構想生成，初步生成構想，接著準備就緒以供初始實際執行環境使用。 這個階段一開始會有新的構想，並且在第一個實際行版本符合最低可行產品 (MVP) 準則的情況下結束：
    • 開發：功能符合最低業務需求
    • 安全性：功能符合實際執行環境使用的法規合規性、安全性和保護需求
    • 維運：功能符合可作為實際執行環境系統的最低品質、效能和支援能力需求
  • DevOps：此階段是應用程式和工作負載持續進行的反復開發流程，可進行持續創新和產品改進

領導關鍵：融入文化特性

符合這三項需求需要將這三種文化特性一併結合，以確保所有小組成員都能重視所有類型的需求，並一同合作達成共同目標。

將這些文化特性和目標一併整合至實際的 DevSecOps 方法可能是一項挑戰，但值得投資。 許多組織都經歷與獨立作業的開發部門、IT 維運和安全性小組所發生高度不良分歧，進而造成下列問題：

  • 緩慢的價值傳遞與低度靈活性
  • 品質和效能問題
  • 安全性問題

雖然有幾個問題皆很常見，且在新的開發過程中是可預期的情況，但小組之間的衝突通常會大幅增加這些問題的數目和嚴重性。 發生衝突的原因通常是一或兩個小組有行政優勢，並重複否決其他小組的需求。 隨時間推移，忽略的問題會逐漸增加且嚴重性加劇。 若皆不解決問題，則 DevOps 流程將會持續惡化，導致必須加速決策制定以符合不斷演化的業務需求和客戶偏好。

解決這些問題的方式便是建立共用文化特性，以重視領導層支援的開發 (dev)、安全性 (sec) 和維運 (ops) 需求。 這種方法可讓您的小組更妥善地合作，並且在任何指定的短期衝刺期間解決最緊急的問題，不論是改善安全性、維運穩定性，還是加入重要的業務功能。

領導技巧

這些主要技巧可協助領導階層建立共用文化特性：

  1. 沒有人能贏得所有爭論：領導階層必須確保沒有單一思維方式主導所有決策，因為這會導致失衡而對業務造成負面影響。

  2. 力求持續改進，勿求完美：領導階層應訂定持續改進和持續學習的預期目標。 建立成功的 DevSecOps 流程並不是一朝一夕就可達成。 這是長期的過程，並會有顯著的進步。

  3. 嘉許共同專長和個人獨特價值：確保小組了解他們正朝著共同結果邁進，而每個人員皆能提供他人未具備的價值。 所有的需求類型都是關於建立和保護相同的業務價值。 開發流程正在嘗試建立新的價值，而維運和安全性流程正嘗試針對不同的風險案例保護和保留該價值。 整個組織中所有層級的領導人都應該傳達這項共同點，以及滿足立即和長期成功的所有類型需求重要性。

  4. 開發共用的理解：小組中的每位人員皆應對下列項目有基本理解：

    • 業務急迫性：小組應清楚了解處於風險的營收項目。 這項觀點包含目前的營收 (如果服務離線) 和受應用程式和功能傳遞延遲影響的未來潛在營收。 這應直接依據領導利害關係人的信號為準。
    • 可能的風險和威脅：根據威脅情報小組的輸入 (如有)，小組應建立應用程式組合將面臨的潛在威脅。
    • 可用性需求：小組應具備維運需求的共用理解，例如必要運作時間、應用程式的預期存留期，以及疑難排解和維護需求 (例如在服務上線時進行修補)。

  5. 示範和模擬所要的行為：領導階層應公開模擬想要小組進行的行為。 例如，表達謙卑，專注於學習，並重視其他專業領域。 其他的範例是開發經理討安全性和高品質應用程式的價值，或安全性經理討論快速創新和應用程式效能的價值。

  6. 監視安全性衝突的層級：安全性通常會產生減緩流程的衝突。 領導階層務必監視安全性所產生的衝突層級和類型：

    • 良性衝突：如同運動中的阻力可讓肌肉更強壯，在 DevOps 流程中納入適度的安全性衝突，便可在適當的時機強迫進行批判性思考，進而強化應用程式。 如果小組正在學習並使用這些學習內容來改善安全性，例如考量原因、攻擊者可能會嘗試危害應用程式的方式，以及尋找和修正重要的安全性錯誤（bug），則小組正依進度進行。
    • 不良衝突：找出對價值妨礙大於保護的衝突。 當工具產生的安全性錯誤有較高的誤判為真率或誤報時，或安全性修正問題的努力超過潛在攻擊的影響時，這種情況就往往會發生。

  7. 將安全性納入預算規劃：確保安全性預算會依比例分配至安全性的其他投資。 這類似於像演唱會等實體事件，其中事件預算包含實體安全性作為標準。 某些組織會針對安全性分配總成本的百分之十作為一般規則，確保皆套用一致的安全性最佳做法。

  8. 建立共同目標：確保應用程式工作負載的效能和成功標準反映開發、安全性和維運目標。

注意

在理想的情況下，這些小組應共同建立這些共同目標以最大化收購，不論針對整個組織或特定專案或應用程式。

識別 DevSecOps MVP

從構想轉換到實際執行期間，請務必確定能符合最低需求，或符合每個需求類型的最低可行產品 (MVP)：

  • 開發人員 (dev) 專注於能提供快速傳遞的業務需求，以符合使用者、客戶和商業領導人的預期。 識別最低需求，以確保能協助組織順利完成。
  • 安全性 (sec) 將焦點放在符合合規性義務，並防禦不斷向組織資源尋求非法獲益的攻擊者。 識別最低需求，以符合法規合規性需求、維持安全性態勢，以及確保安全性作業可以快速偵測和回應主動攻擊。
  • 維運 (ops) 專注於效能、品質和效率，以確保工作負載可以持續提供長期的價值。 識別最低需求，以確保工作負載可以執行且受支援，而在可預見的未來不需要進行大量架構或設計變更。

MVP 的定義會隨著時間而改變，且會有不同的工作負載類型，這是因為小組會根據自身經驗或其他組織吸取新知。

在流程中原生整合安全性

安全性需求必須專注於現有流程與工具的原生整合。 例如：

  • 設定活動 (例如威脅模擬) 應納入設計階段
  • 安全性掃描工具應納入持續整合和持續傳遞 (CI/CD) 系統，例如 Azure DevOps、GitHub 和 Jenkins
  • 安全性問題應使用相同的錯誤追蹤系統和流程 (例如優先順序配置) 來回報為其他錯誤。

如此一來，將安全性納入流程，應會在小組學習和流程成熟的過程中持續改進。 安全性檢閱和風險評估應可確保已將風險降低納入端對端開發流程、最終生產服務和基礎結構。

如需 DevSecOps 的詳細資訊，請參閱 DevSecOps 技術控制。

導覽旅程的訣竅

轉型需要在旅程中逐步建置以邁向理想階段。 許多組織都必須在此旅程上經過複雜的問題和挑戰。 本節將概述組織所面臨的一些常見問題。

  • 教育和文化變革是早期重要的步驟：凡事量力而行。 您所擁有的小組通常需要開發新的技能，並採用新的觀點來了解 DevSecOps 模型的其他部分。 此教育和文化變革需要時間、關注、執行贊助，並定期追蹤，以協助個人完全了解並看到變革的價值。 隨著文化特性和技能不斷變化，有時可能會利用個人的專業認同，創造出強大的抵抗潛力。 請務必了解並表達每位人員及其情況的原因、目標及變更方式。
  • 變革需要時間：直到您的小組適應採用新作法工作所帶來的影響之前，您僅能盡快推行。 小組在轉型時皆仍需要進行現有的作業。 務必仔細排列最重要事項的優先順序，以及管理此變革發生速度的預期情況。 專注於「爬行-行走-跑步」策略，其中最重要且基礎的元素最優先處理，這將協助您的組織達成目的。
  • 有限的資源：組織通常會及早面對挑戰，尋找安全性和應用程式開發領域的人才和技能便是其一。 當組織開始更有效地進行共同作業時，可能會發現隱藏的人才，例如具備開發背景的安全性思維或安全性專業的開發人員。
  • 應用程式、程式碼和基礎結構的不斷變化本質：應用程式的技術定義和組合基本上是隨著無伺服器、雲端服務、雲端 Api 和無程式碼應用程式等技術的引進而改變，例如 Power Apps。 這項轉變會改變開發做法、應用程式安全性，甚至讓非開發人員能夠建立應用程式。

注意

某些實作會將維運和安全性責任結合至現場可靠性工程師 (SRE) 角色。

雖然將這些責任融合成單一角色可能對某些組織是理想結束階段，但這通常是目前企業做法、文化特性、工具和技能組合的極大變更。

即使您是以 SRE 模型為目標，我們建議您先使用本指南中所述的實際快速勝利和累加進度，將安全性內嵌至 DevOps，以確保您能夠獲得良好的投資報酬率 (ROI) 並符合立即需求。 這會以累加方式將安全性責任新增至您的維運和開發人員，這會讓您的人員逐漸達到 SRE 的結束階段 (如果您的組織打算再稍後採用該模型)。

後續步驟

如需 DevSecOps 的詳細指引，請參閱 DevSecOps 技術控制。

如需 GitHub Advanced Security 如何將安全性納入持續整合和持續傳遞 (CI/CD) 管線的詳細資訊，請參閱關於 GitHub Advanced Security。

如需 Microsoft IT 組織如何實作 DevSecOps 的詳細資訊和工具，請參閱安全 DevOps 工具組。