安全與合規

DevSecOps 成熟度模型(DSOMM)

DevSecOps 成熟度模型(DSOMM)

前言 隨著企業提升響應市場變化的速度,不管企業的規模為何,抑或屬於哪一種產業,DevOps 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下,由於傳統的安全治理較為繁瑣,也使企業在導入 DevOps 的過程中,從需求、設計、實作,到後續的監控和改善,較難看見充分的安全實踐,組織亦缺乏在每個流程階段,衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM? DSOMM 2 的全名為 DevSecOps Maturity Model(DevSecOps 成熟度模型),或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM(Software Assurance Maturity Model,軟體保證成熟度模型),SAMM 針對五個業務功能(治理、設計、實作、驗證、維運)定義了一系列的安全實踐及評量指標,協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型,而 DSOMM 則為更具體的 DevSecOps 實踐。

繼續閱讀
為你的自動化基礎設施拉上保險系列之四 - 主機弱點掃描

為你的自動化基礎設施拉上保險系列之四 - 主機弱點掃描

安全的運行環境對於雲端服務來說,是個重要的議題,而對於使用者來說更為重要。 因此,對實體或虛擬主機進行弱點檢查與監測,能為雲端服務提供一個安全的基礎,也能滿足組織對於資安的基本要求。然而,安全威脅多樣,且各式作業系統的組態設定又各有巧妙,要如何才能有效率地完成這個工作,對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定,主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作,它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時,應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查,也可能來自 OVAL 所識別的弱點測試。

繼續閱讀
為你的自動化基礎設施拉上保險系列之二

為你的自動化基礎設施拉上保險系列之二

Policy (政策) 政策! 是什麼東東 ? 提到政策,就會不小心想到治理、授權等等讓人頭皮發麻的詞。然而,政策在軟體服務中是相當常見的某種需求。簡單來說,軟體服務的政策是什麼呢? 一組管理軟體服務行為的規則。 舉凡,定義哪些是受信任的主機、使用者能夠存取哪些功能、網路路由、和服務可以部署到何處等,都能視為服務管理政策。所以當你試著實作 feature toggle、試著實作管理員和一般用戶等功能時,便已經涉及到服務政策的機制了。 傳統上的作法,工程師會在服務中實作相關的資料存取與檢查。先不論此類實作所耗費的額外運算資源,如果有多個團隊在實作多個服務,而都需要基於相同規則進行檢查時,要如何進行?如何能夠和服務管理政策管理者有更好的合作?落實管理政策與提供服務彼此之間如何不互相拉扯等待,而導致服務提供效率降低? 追根究柢,可以把問題濃縮成: 如何讓開發團隊專注在產品主功能開發,讓政策管理者能夠用一致的方法進行管理,而且兩者之間的更動不會輕易地影響對方? Open Policy Agent 為這個問題提供了一個新的解決方式! Open Policy Agent (OPA) Open Policy Agent(OPA, 讀音為 歐趴) 最初是由 Styra 所建立,後來貢獻到 CNCF。目前由 Styra、Google、Microsoft、和 VMWare 構成開源專案的主要貢獻者團隊,撰文的當下它也已經順利地從 CNCF 畢業了。OPA 實現了一個輕量的政策管理服務,因此可以作為服務的 sidecar 運行,也能作為獨立的政策管理服務運行於整體服務群內。軟體服務可以基於給定的資訊透過 RESTful API 的方式「查詢」相關政策的判斷結果。此舉成功地解耦了政策管理的相關實作,讓軟體服務可以專注於使用者功能,至於政策則可以透過一個獨立的服務來實現。政策的管理者與資源的提供者,可以透過統一的管理服務來更新相關政策,從而改變團隊的合作模式,並且可以更高效且一致地施行政策。

繼續閱讀
為你的自動化基礎設施拉上保險系列之一

為你的自動化基礎設施拉上保險系列之一

作為基礎設施的編撰工具,Pulumi 額外提供了基於屬性測試 (Property testing) 概念的 Policy as Code 工具 (“CrossGuard”)。基於這個工具,專案團隊或者是組織可以為所有採用 Pulumi 所撰寫的基礎設施程式,建立獨立於所有 IaC 專案的普遍規則 (比方說資源區域、數量、網路設定、IAM 等),團隊亦可基於此再添加關於專案的額外限制。透過建立完成的可測試規則,開發者可以在本地端、持續整合流水線、以及在最後佈署前(已經產生基於各公雲或基礎設施服務的組態檔時)進行測試確認,避免需要透過人工檢閱比對,或者是已經佈署完畢後再進行確效,所產生的人力或資源的浪費。 本篇文章作為 Policy as Code 系列文章的起頭,會採用 Python 建立一個簡單的 Policy as Code 專案,為稍後建立基礎設施全面性的規則作暖身。 在開始之前 擁有一個 GCP 的帳號,更重要的是,它必須設定好如何付 $$ 安裝 Google Cloud SDK,並且確認已經設定好 application-default Python 為 3.

繼續閱讀