實踐DevSecOps的關鍵心法

這篇文章內容是我受邀參加iThome所舉辦敏捷高峰會(Agile Summit 2022)的金融業敏捷對談(Panel Discussion),針對主持人的指定題所準備的。DevSecOps對大多數台灣的企業資訊主管是一個很新的議題,這點可以從今年iThome CIO大調查得到驗證。在這份調查所公布的企業新興技術雷達圖中可以看到,DevSecOps是列在崛起中的AP架構與開發技術,有實際導入經驗的企業必然還是少數。

圖1、導入DevSecOps需要規模化的改造企業PPT

DevSecOps對不同類型的導入企業主體其困難度其實是不同的。對網路原生的新創公司來說,若平常就很習慣運用公有雲的CI/CD自動化工具,要打造培養出具快速、穩定及安全能力的DevSecOps團隊是相對容易的。但是對傳統企業,特別是傳統銀行來說,這件事就像是要末代武士變成捍衛戰士,由人工加油變成空中加油一樣艱鉅,涉及到要改造人員心態、組織文化、工作流程及技術革新 (圖1)。同時這樣的變革最終必須要做到規模化,否則不上不下的狀態,只會讓銀行未蒙其利、先受其害。對傳統銀行來說,DevSecOps是龐大數位轉型進程中的一塊拼圖要談傳統銀行導入DevSecOps的心法,就不能去脈絡化不談數位轉型。

以下這四點我認為是傳統銀行資訊長在擘劃導入DevSecOps要注意的重點:

  • 轉型改變的核心永遠是人
  • 持續創造供需以趨動變革
  • 由新與小實驗快速的資安
  • 團隊自主成為學習型組織

轉型改變的核心永遠是人

首先,DevSecOps雖然涉及人員、流程及技術,但是最核心的還是人員。員工若沒有意願,不能自發性的認同,改掉企業傳統的穀倉式組織架構與漫長接力的瀑布式運作流程(圖2),最終企業為了導入DevSecOps採購的工具與花費時間改造的流程,最後還是會因為員工的陽奉陰違浪費掉。

圖2、傳統的企業架構與組織運作

DevSecOps如同Scrum、看板等方法論,是要打破企業傳統的穀倉式組織架構與漫長接力的瀑布式運作流程,以5~9人的產品融合團隊敏捷的運作。團隊要如同海豹部隊一樣,雖然團隊成員各有專業,但也能因應需要隨時相互支援,並改變為以對成果(Outcome)負責,而非傳統資訊專案僅是對產出(Output)負責(圖3)。尤其DevSecOps是要將資安閘門打破向左移分散,在DevSecOps對速度與規模化的要求下,這些工作將無法由資安團隊集中執行,勢必要轉變為由開發人員在第一線執行,這些巨大轉變需要參與DevSecOps的員工都能夠認同與實踐。

圖3、科技金融的企業架構與組織運作核心是對Outcome負責的產品導向的融合團隊

但員工的認同與實踐不是高階主管一聲令下就能達到,必須要讓員工能夠知道為何而戰。同時也不能躁進,必須要階段性的推進,確保在每個階段都夠讓員工看到這麼做的好處。接著我們就以本行的經驗為例,說明我們如何在企業數位轉型的脈絡中找到開始推動DevSecOps的時機。

本行的數位轉型方針是由資訊現代化、產品數位化及市場創新化的14個方針組成(圖4)。簡單來說,我們希望透過這14大方針的推動,第一銀行能夠但透過建構5大數位核心能力(5D),並打造能夠承載我們找到下一片綠洲(OASIS)的現代化資訊基礎建設,成功轉型為在雲端生態系(Ecosystem)中,具備精實敏捷(Lean Agile)與創新(Incubate Innovation)能力的科技金融(TechFin)企業。這不光是讓我們的員工知道為何而戰的手段,其實也是本行推行敏捷企業層級的待辦清單(Backlog),因為這些方針不可能同時執行,而必需要如同敏捷開發一樣迭代進行。

圖4、第一銀行數位轉型策略方針

持續創造供需以趨動變革

以本行的經驗為例,本行企業數位轉型的第一個迭代(數位轉型1.0)是從年輕客群的需求 Outside-in,驅動以小規模的產品敏捷團隊打造 iLEO數位品牌,這時資安的作法與過去並無太大不同。

歷經兩年多的努力,隨著客戶行為轉變與疫情的加速,讓全行體認到,必須要進行大規模的業務變革,搭配全面現代化的資訊架構才能夠真正滿足數位時代客戶。這時資安不單要左移嵌入在軟體開發流程,還需要更往左參與創新業務變革的資安架構設計。

我們希望經過數位轉型2.0後,本行可以真正成為軟體定義、AI決策及數據驅動科技金融公司,而此時資安本身也需要被數位轉型(圖5)。資安本身的數位轉型不是本次研討會探討的重點,所以我們還是把焦點放在數位轉型2.0帶出的敏捷資安議題。有興趣進一步了解的人,可以參考本人另一篇文章:數位轉型下的資訊安全

圖5、數位轉型三階段與資安

在數位轉型2.0的階段,如果轉型的正確,業務端將會產生較以往更大規模的價值創造需求,同時業務端也希望可以加速價值的交付。此時包括資訊與資安就會開始面臨到變革的壓力與挑戰。

資訊與資安團隊必須與產品融合團隊合作,逐步揚棄傳統的瀑布式應用程式開發方式,採取結合了設計思維、Scrum/看板及自動化DevSecOps的敏捷開發與運維方式,才可能滿足價值交付的速度要求。(圖6)

圖6、數位轉型2.0價值創造溪流

而DevSecOps更需要結合Cloud Ready的容器化基礎架構,讓企業架構維運發揮如虎添翼的效果。亦即大規模的業務變革需求驅動了傳統銀行全新世代的巨大資訊變革,兩者結合才能產生Inside-out的規模化價值創造。全新世代的資訊架構(圖7)將由傳統大型主機主導的大核心小周邊,轉變為敏前台、大中台、穩後台、小核心,也就是以微服務及容器化為應用組成及運作單元的Cloud Ready架構,也是DevOps/DevSecOps可以朝向持續整合及持續部署的技術核心關鍵。

圖7、數位轉型2.0技術架構

由新與小實驗快速的資安

當然傳統銀行要打造全新世代的Cloud Ready資訊架構絕對是一個浩大的工程,在施行時也必須要運用敏捷迭代的觀念逐步達成。本行的核心系統與資訊現代化目前規劃分成三個階段:短期架構先行、中期逐步瘦核及長期逐步轉核。在迭代的初期,也就是短期架構先行的階段,除了挑選外匯匯入來驗證Cloud Ready的架構與應用開發方式外,也同時開始實驗如何將資安左移融合到DevOps的流程中,驗證快速資安的概念如何落實。

圖8、核心系統與資訊現代化三階段

在建立DevSecOps時,不能只聽廠商提供的解決方案,然後就一股腦的照做,企業還是要有參考的架構。例如Gartner的DevSecOps toolchain列出了DevSecOps流程中每個階段應該採行的資安工具與活動。此外資訊長或資安長在導入DevSecOps時必須要有一個認知:DevSecOps的核心是在做"快速"的資安(圖9)。

DevSecOps的工具鏈所整合的工具與傳統的資安工具,從功能來比較其實並沒有太大的差別,所以若透過DevSecOps流程開發出來的是軟體A,透過傳統瀑布式軟體開發流程所開發出來的是軟體B,我們未必能導出A的弱點要比B來的少這樣的結論。但是因為導入DevSecOps與CI/CD的自動化流水線,透過責任共享及工具的自動化,我們就能達成高效率、高可靠性軟體交付目標,在發現有軟體漏洞時,就能夠更快速甚至自動化的應變,縮小因為軟體弱點造成的資安空窗期。

圖9、DevSecOps工具鏈與導入DevSecOps應注意的原則

團隊自主成為學習型組織

導入DevOps/DevSecOps是需要時間讓團隊逐步提高成熟度的。團隊本身必須要有評量指標知道自己目前的能力成熟度水準。透過這些指標與成熟度水準的提升,能讓團隊本身知道是否已建立起能夠同時滿足速度、品質及安全能力這些看似相互矛盾的困難挑戰。

Google的DORA Metrics評估的是DevOps的四項關鍵指標:部署頻率、改版交付時間、服務平均恢復時間(MTTR)及改版失敗率。部署頻率和改版交付時間是用來衡量開發團隊的開發速度。服務平均恢復時間和改版失敗率是用來衡量交付軟體的品質和穩定性。這四個指標都可以透過挖掘開發團隊使用的DevOps工具得出。

DSOMM是OWASP正在進行的專案,它是一套可以由GitHub下載的DevSecOps成熟度自評工具。透過DSOMM,團隊可以知道DevSecOps中各種活動的相依性,以及導入實施的難易度及價值,讓團隊可以依自身狀況排定實施優先序並逐步提高成熟度。

圖10、DevOps/DevSecOps的評估指標與成熟度模型

最後強調一點,產品導向的DevOps融合團隊是對Outcome負責,而非傳統的資訊系統專案是對Output負責,所以融合團隊除了以能力成熟度技術性指標來指引前進的方向,還要佐以文化變革、生態系平台及數位營收及成果等KPI來衡量團隊的發展(圖11)。

圖11、數位轉型2.0 KPI

One Reply to “實踐DevSecOps的關鍵心法”

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

用 WordPress.com 建立自己的網站
立即開始使用
%d 位部落客按了讚: