企業的下一個挑戰:如何為全公司的容器和大型應用程式提供最佳防護?


談到軟體容器防護,很重要的一點是,企業必須放眼大局,考慮容器如何影響企業整體資安需求以及開發營運 (DevOps) 未來的需要。好的方法能讓資安團隊建立一個面面俱到的資安策略,既可避免建構時期與執行時期發生資料外洩或遇到資安威脅,又不影響應用程式 DevOps 團隊的靈活性和速度。

雖然資安和 IT 人員必須解決 DevOps 快速靈活的腳步所衍生的資安問題,但卻面臨了企業組織及流程去集中化的挑戰。而既然工作負載和營運環境隨時都在變化,因此,網路資安問題並無單一解決之道,只能憑著手上現有的資訊來應變。為了應付當前的資安情勢,並且了解如何將容器環境納入資安防護,我們必須先問問自己幾個深入的關鍵問題。

工作負載的環境和以往有何不同?今日開發團隊的著眼點又在哪裡?(也就是:從虛擬機器到雲端,再到無伺服器環境、DevOps、微服務,以及根據交付與運轉時間為評量標準)。

許多年前,我們與客戶的對話大多圍繞在如何將傳統老舊的工作負載從資料中心移轉至雲端。在這「升級」的過程中,客戶必須考慮要在雲端內採用何種 IT 工具及資安防護才能讓營運流暢。許多客戶在移轉至雲端之前就已採購的一些傳統工具,在移轉至雲端之後將很難沿用,因為它們並非專為雲端而設計。

但近幾年來,這批將工作負載移轉至雲端的客戶,也開始採用一些雲端原生服務來開發新的專案和應用程式,並且在 Docker 容器以及 AWS Lambda、Azure Functions 和 Google Cloud Functions 等無伺服器環境開發新的應用程式。這些技術讓企業能夠採用 DevOps 營運流程,持續不斷開發各自獨立又互相配合的應用程式「零件」,以實現比開發大型應用程式更快的成果。這些新的開發計畫,也催生了所謂「持續整合/持續交付」(CI/CD) 流程的出現,透過 Git 來進行原始程式碼管理 (代管版本的 GitHub 或 BitBucket)、使用 Jenkins 或 Bamboo 來執行 DevOps 自動化,然後搭配 Kubernetes 來進行容器的自動化部署、擴充與管理。

這兩股動力正驅策者舊式傳統大型應用程式與雲端原生微服務的併行發展。而企業所面臨問題很簡單,就是:如何保障這一切的安全?以及,當規模擴大時如何做到這點?

另外值得一提的是,隨著 IT 的日益成熟,這些團隊也開始運用所謂的「基礎架構程式碼」(Infrastructure as Code,簡稱 IaC) 技術。換句話說,就是撰寫程式碼來將 IT 營運自動化。其中也包含了所謂的「安全程式碼」(Security as Code),也就是撰寫程式來將安全自動化。雲端營運團隊已開始擁抱自動化,並與應用程式開發團隊合作,協助讓 DevOps 的應用程式開發自動化並符合 IT 要求。一些像 Chef、Puppet、Ansible、Terraform 及 Saltstack 這類 IT 營運自動化技術,在我們的客戶之間都相當常見。

資安漏洞和威脅永遠不會消失,DevOps 團隊在資安方面對企業有哪些較大的影響?

根據跟我們從企業所接收到的訊息,企業本身的設計並無法建立大規模的防護來讓一大群 DevOps 團隊在應用程式「建構->交付->執行」的流程中持續獲得不間斷的資安防護。

一家典型的企業會有統一的 IT 及資安營運 (Security Ops) 團隊來服務企業內的眾多內部客戶,例如那些創造企業營收的事業單位。

所以,企業該如何讓這數十個、甚至數百個不斷重複著應用程式「建構->交付->執行」流程的 DevOps 團隊大規模地和 IT 及資安營運團隊互動?IT 及資安營運團隊該如何擁抱這些方法和技術,並且設法保障 CI/CD 流程與執行環境的安全?

一般來說,IT 團隊 (含資安團隊) 與事業單位之間的互動,大多侷限於高階主管層級 (至少副總裁以上),然而企業要在確保安全的情況下持續看到績效,雙方之間就需要一套更有效、更自動化的互動方法。

我們看到許多事業部門的 DevOps 團隊都在努力將資安融入專案當中,或自行購買一些只適用其個別專案的資安解決方案。這不僅得花費事業單位的個別預算,而且還要在資安經驗有限的情況下建置這些方案,更別說還得配合企業的整體資安要求,讓 IT 隨時掌握狀況。如此將使得企業內的資安防護零散、重複、缺乏一致性,不但增加成本和複雜性,同時也難以管理和支援。有時候,事業單位為了追求一己的交付速度,更可能犧牲了企業整體的資安規劃。這我們都曾經歷過,而且必須找到一個適當的平衡點。

事業單位應用程式團隊與企業 IT 及資安營運團隊之間,在工作上並非隨時維持著健康、平順的合作關係。摩擦在所難免,有時候,摩擦的根源來自於應用程式團隊遠比 IT 團隊更了解 DevOps 的實務運作、工具和相關技術,例如 Docker、Kubernetes 及各種無伺服器技術。我們就看過應用程式團隊在開會時花費了許多無謂的時間來試圖讓 IT 和資安營運團隊了解一些基礎觀念,更何況雙方還存在著工作方式的差異。而且當 IT 和資安營運團隊在面對容器與無伺服器環境卻不肯改變其現有的資安作法時,摩擦更會進一步升高。因此眼前最大的問題是,若 DevOps 團隊希望能有一套持續交付又兼顧全企業的方法,那麼就需要與 IT 和資安營運團隊密切合作,讓他們清楚 DevOps 所用的工具和方法以及微服務技術 (Docker、Kubernetes 等等),這樣雙方才能共同維持應用程式建構流程與執行環境的安全。此外,IT 和資安團隊也必須提升自我,了解 DevOps 及所有相關技術,以便成為企業的助力而非阻力,達成資安的要求。

所謂真正的「DevOps」,「Dev」部分應由應用程式團隊來負責,而「Ops」部分則最好是由「IT/資安」團隊來負責,雙方共同合作。基於這樣的觀察,我們認為未來企業在開發團隊與 IT/資安團隊的組織架構上,將經歷一番重大的變革,因為傳統的組織架構都偏向開發大型傳統應用程式而設計,無法滿足持續交付的要求。

對 IT/資安營運團隊來說,最好的作法就是透過一些自助式工具和實務方法來協助應用程式團隊一方面加快腳步、另一方面又能達成企業整體 IT 和資安的要求。

DevOps 團隊如何運用一些最佳資安實務來提升新興技術 (如容器環境及相關支援工具) 的安全?

老實說,這話題可寫成一本書了!不過我們還是試著從宏觀的角度來將這問題拆成「建構」、「交付」和「執行」三個部分。這樣的分法當然不算完整,不過卻不失為一個起手點。

資安團隊有絕佳的機會透過一致的方式在企業內導入以下服務,讓所有具備應用程式建構流程和執行環境的團隊都能受惠。

建構

  • 搜尋企業內所有原始碼儲存庫與 CI/CD 流程及相關負責人。
  • 靜態程式碼分析。
  • 惡意程式掃瞄。
  • 漏洞掃瞄。
  • 藉由映像掃瞄來評估其組態設定 (藉此提升映像安全)。
  • 查詢所有映像登錄資料庫內是否有入侵指標 (IoC)。
  • 機密偵測。
  • 在測試環境內執行自動化資安測試 (採用通用與客製化測試套件)。
  • 映像檢查證明 (Image Assertion) – 根據掃瞄、測試等結果,宣告映像可進入生命週期的下一階段。

透過資安評分卡,提供報表給應用程式團隊和資安團隊。

交付

  • 入境控管 – 根據資安政策、映像檢查證明以及映像是否經過簽署來判斷是否允許映像進入執行環境。
  • 容器漏洞防護 – 趨勢科技今年稍晚應該會推出這項功能。

執行

  • Docker 與 Kubernetes 執行時期防護,包括不正常的變更或組態設定等異常狀況偵測。
  • 強化 Kubernetes 和 Docker 安全。
  • 採用 Kubernetes 網路政策功能來執行微分段 (micro-segmentation) , 而非採用第三方解決方案,並且確保 Kubernetes 本身的安全。
  • 容器主機層次的防護 — 涵蓋惡意程式防護、漏洞防護、應用程式控管、一致性監控與記錄檔檢查,完整保護應用程式與主機本身。
  • Kubernetes Pod 層次的防護 (高權限的容器 – 每個 Pod 各一個)。這可以和任何其他容器一樣部署到 Kubernetes 環境,無需主機層次的代理程式。

針對無伺服器容器和無伺服器服務,應用程式防護是部署在每個映像或無伺服器功能當中 (應用程式安全程式庫將專注在 RASP、OWASP、惡意程式和應用程式執行路徑內的漏洞)。趨勢科技將在今年稍晚推出一項產品來解決這問題。

針對容器防護,趨勢科技提供了一套更強、更完整的完整生命週期方法。這套方法能協助應用程式團隊在 CI/CD 流程與執行環境當中達成法規及企業資安要求。趨勢科技憑藉著多樣化的資安功能、完整的自動化資源,以及世界級的威脅情報團隊,是今日企業應用程式與容器環境最佳的頂尖資安夥伴。

更多詳細資訊請參閱:www.trendmicro.com/containers

原文出處:The Next Enterprise Challenge: How Best to Secure Containers and Monolithic Apps Together, Company-wide 作者:趨勢科技混合雲防護產品管理總監 Adam Boyle