推薦先閱讀【以將來銀行為鏡,談大型系統整合的挑戰】為何團隊磨合衝擊百億純網銀開業(上)

從將來銀行IT整體建置過程來看,我們更能了解耽誤1個月時程的衝擊程度,以及將來銀行專案開發過程所遭遇的狀態。

籌備期先規畫資訊架構和資安架構

將來銀行在2018年底成立籌備處後,隔年4月,擁有科技和電商平臺經歷的資訊長周旺暾正式上任,也開始進行資訊系統架構和資安架構的規畫。

周旺暾表示,前端採取自行開發的作法,而後端系統則以採購套裝軟體為主,當時還訂出了兩大選商要求,一是只採購在臺灣仍有銀行實際運作中的產品,避免來自國外的套裝系統,來臺後出現水土不服的問題。二是盡量購買套裝的軟體,避免太多客製化,他解釋,除非是為了法規的要求,或是為了打造銀行特色產品,才會進行客製。

在資訊基礎架構的設計上,將來銀行採取全虛擬化的環境設計,所有系統,包括核心系統,甚至核心系統的資料庫,都決定部署在虛擬化環境中執行,只有少數法規要求部署的實體設備,例如HSM硬體加密設備,或聯徵中心指定規格設備,就依規定要求規格來建置。過去臺灣銀行產業很少採取全虛擬化的作法,周旺暾表示,廠商一開始也會擔心,但後來實際做了以後,沒有面臨技術困難,也不太需要修改到系統程式的情況。

API化是另一個周旺暾堅持要做的架構設計,這也有資安上的考量。他要求,所有後端系統之間只能透過API來串接,禁止採取目錄共享的作法,就算是系統內部的通訊,也要採取HTTPS協定來交換資料,若要拋檔,得使用加密的FTPS連線,而且所有API只能透過標準的指定埠,不能私另開通訊埠來交換資料。唯一例外的是客服電話語音和影音通訊有些專屬作法,但將來銀行把這類資料儲存在專屬系統環境中,系統也不能與其他系統進行未經授權的通訊。目前將來銀行內部系統間的通訊以HTTPS和FTPS為主,這也是微服務架構慣用的通訊方式。「這就幾乎做到接近微服務的架構,至少AP系統之間是採取API來對打,再搭配API閘道器來監控。」他解釋。

將來銀行先訂出API規範,再要求所採購系統的廠商配合來開發API,過去若有目錄共享交換資料的作法,也都改用API交換來取代,經過一年時間,30多套後端系統,連同核心系統,都可以提供API化的支援。

「堅持發展API化的原因,除了方便管控之外,另一個考量是未來的擴充性,若採取檔案共享的設計,未來擴充規模時會受限。」周旺暾解釋。目前將來銀行後端系統中有一個處理API使用的中臺,但還沒有進一步導入APIM管理系統,目前先採文件化管理API作法,將所有API規格和規範都清楚整理成文件,透過文件來管理各項API的使用,周旺暾表示:「先將API管理文件化,未來再套用管理工具。」

在籌備處期間,除了IT架構規畫之外,將來也展開一些業務面的規畫,例如在2019年11月時先開始設計未來的開戶流程。後端系統統包專案正式在2019年底啟動後,也後續展開各系統的採購招標作業。將來銀行核心系統採用的是Temenos的T24,這也是不少傳統銀行或數位銀行,如王道銀行所用的核心系統廠商。

3個月四大類工作並進,卻爆發團隊磨合問題

隔年,2020年1月31日,將來銀行正式登記為公司,開始大舉招募IT人力,過年後IT團隊到位,開始展開用戶端系統(行動銀行和網路銀行)的開發工作。但是,將來銀行當年4月才開始建置機房,許多硬體在4月大舉進駐後,花了約一個月完成機房和私有雲的建置。

在這一個月,將來銀行同時要進行機房,私有雲和後端系統3線工作,內部開發團隊也同時展開用戶端的開發,等於有4線工作同時進行。但也就在這一個月,周旺暾才猛然發現,開發團隊進度停滯,仍舊處在需求理解的階段,他進一步了解才發現了團隊磨合的問題。

即使緊急調整工作節奏,但團隊磨合問題的處理,周旺暾表示,仍耽擱了一個多月。

可是,原訂純網銀年底前上線的時程越來越近,金管會正式實地檢查時間是在9月,將來還規畫了兩次事前的UAT(使用者驗收測試)活動。開發時程縮短了,但業務流程還在持續發想中,後續新增的開發需求,越來越多。

到了5月到6月1日,進行的第一次UAT測試時,將來銀行初步先完成的純網銀系統功能,以開戶和轉帳功能為主,App畫面還很陽春,也正持續迭代增加更多功能中,當時的UAT測試以確認功能運作正常為主,測試規模較小。而在4、5月機房建置期間,後端系統更是同時陸續展開部署,統包廠商中華電信企分負責主導後端系統的SIT(系統整合測試)工作,尤其後端系統改採API化的溝通設計,都需要測試彼此的互通。

金管會9月正式檢查前進行兩次UAT測試,為何難測全?

一邊進行業務發想(需求變動),一邊建置後端軟硬體(基礎環境變動)、一邊開發前端系統(用戶端功能變動),又一邊要趕快開始進行後續的前後端整合後的UAT測試,可想而知,很難做到周全,甚至,周旺暾透露,初期開發階段,有一段時間,每2~3天就有新功能,會釋出一個新的部建(Build)版本,「的確會有一些SIT來不及測完,像是有些急件功能的回歸測試(Regression Testing)不足,就會有時發生改A壞B的情況。」回歸測試是用來測試,一項新功能程式完成後,對原有其他功能是否會帶來影響的測試,沒有全面測完回歸測試,就無法察覺新功能與哪一項舊功能發生了衝突。

周旺暾坦言,開發時程很趕的情況下,SIT做了,但可能不完整。未來將來銀行計畫進一步發展自動化測試,尤其是回歸測試的自動化測試。另外,還有些特殊的測試場景,無法單獨在後端系統SIT階段完成測試,例如將來銀行設計上,禁止SIT環境與外部連線,一些與外部系統如與聯徵中心的串接,只允許在前端系統的UAT環境中進行,因此後端系統要進行與外部串聯的SIT測試任務時,只能先用模擬器測試,最後再移到UAT環境中驗證模擬SIT測試的結果,才算完成了這項SIT測試。

目前將來銀行的測試標準流程是,開發人員或廠商完成UT(單元測試)後,由另一組人負責SIT,再找使用者來測UAT,安排不同人員來避免前一段沒做的情況。

經過第一次UAT測試後,因為開發能量嚴重不足,開發任務暴增,後來追捕了8~9名臨時開發人力,與內部團隊共同開發,整體開發人力達到40多人。在9月金管會正式進行開業前的檢查之前,將來也在8~9月完成了第二次UAT測試。

周旺暾表示,早在9月正式檢查前,已先向主管機關展示過App雛形,「9月正式檢查時,也做到法規要求項目。」但他坦言,主管機關針對操作流暢度、功能完整性等希望更進一步優化,建議例如更能避免消費者爭議的畫面調整等,或是有些後端系統的錯誤代碼,不能出現在使用者端畫面。金管會還要求將來銀行,必須自行再做完整的UAT測試。

將來在10月完成金管會建議項目的程式修改後,在UAT環境中驗證後,確認符合主管機關和法規的要求後,提出改善報告回報給金管會,並在11月凍結系統版本,不再增加新功能,進入優化階段,除非主管機關要求才新增。

開始導入零信任資安架構

在去年11月,將來銀行新任的資安主管,也就是曹志誠正式到任。當時,資訊系統專案完成了第三階段的交付,將來銀行取得所有設備和系統的控制權,也切斷了所有端對端的連線,不再允許任何VPN連線到將來銀行的環境中,或像是收回所有臨時帳號,重新設定帳號和權限。曹志誠也開始正式導入零信任資安架構的設計思維,將機房與辦公環境完全隔離。

曹志誠表示,將來銀行資安策略是採取縱深防禦搭配零信任架構,來設計整體資安架構,也會針對風險高低來採取不同等級的管控。例如顧客資料的存取和利用都會進行管制,開業後還會設置管制室,所有與顧客個資相關的操作,只能在這個房間進行,內有門禁和監控設備,也切斷對外網際網路連線不能上網,並禁止攜帶照相手機,操作人員只能操作與自己作業相關的工作,也有對應的管制,例如客服人員只能查詢客服相關的顧客個資,而且一天不能超過20次。顧客資料若要匯出作為行銷之用,也會經過去識別化處理才匯出。

另外,將來銀行把內部資訊系統的資安層級分三級,優先保護重要系統,並導入紅藍軍演練,所有系統部署時都進行弱點掃描,就連在內網層層防火牆內的單獨系統,上線前都進行弱點,修補完所有弱點才能部署。

將來銀行不只將辦公室工作環境的網與機房環境隔離,連機房內部也取分艙分層的隔離管理作法,例如有DMZ、對外介接層,AP層和最深的DB層等縱深設計,這也是一般銀行常見的作法,但在橫向管理上,他們則有所著墨。將來銀行一方面因為採取了全虛擬化架構,透過微分區(Micro Segmentation)機制來設定虛擬網路,以建立橫向的隔離,讓AP群之間互相看不到對方,另一方面也禁止AP間的共享目錄作法,所有跨系統間的資料交換只能透過API,這些API則會透過WAF防火牆和API閘道器來管控。

「零信任架構設計就是認為,任何環境都天生不安全的思維來建置安全措施。」周旺暾強調,這樣的架構如果不是第一天就做,後續要調整非常困難,這也是新銀行從頭開始的優勢。

設立專屬SOC團隊,開業後24小時監控

將來銀行早在去年6月,就成立了一個專屬SOC團隊,目前有9人,分2班輪值,開業後要做到24小時3班制輪值。這個SOC團隊,負責內部批次作業,監看內外部流量、SIEM平臺和Log分析,也負責內部電腦操作行為異常的監控與分析,將來很早就在每一臺電腦上導入EDR和DLP,留下各種行為的記錄,若出現異常行為就會通知主管,來確認是否為職務相關行為,不一定都會跳出禁止警告。或像是除了滲透測試,也定期舉辦紅藍軍演練,計畫輪流找不同廠商來演練,「透過不同廠商的演練攻擊,可以訓練我們的SOC團隊熟悉更多手法。」周旺暾說明。

先建DevOps,未來發展更完整的DevSecOps

將來開發團隊採用Azure DevOps本地端軟體,建立了一套DevOps工作流程,從程式碼交付、部建(Build)到發布(Release)都可以靠腳本程式自動執行,甚至是靠程式自動上架發布到App Store,透過腳本程式將要上架的程式碼版本先送到一個儲存庫後,再完成必要的上架核准流程後,就會自動上架到App Store,來避免人工上錯版的情況。目前將來銀行也在DevOps流程中,增加一些基礎的資安機制如程式碼掃描、弱點掃描機制。SIEM平臺也在累積資料,建立監控規則,未來要發展更多資安自動化的措施。「未來會增加更多資安機制,來做到更完整的DevSecOps。」周旺暾補充。

過去一年,堅持自主開發用戶端系統,周旺暾透露,用來追蹤開發議題(Issue)的Mantis追蹤系統,甚至一度出現了高達數千個需追蹤的議題,而非數百個,但這些議題的必要性或影響程度差異很大,有些的確是嚴重的臭蟲(Bug),有些則是影響不大的用字描述或頁面設計的優化問題,還有一些是原訂開發規格不符後來的需求,得重新檢討開發規格的提議。對此,將來也依據必要性來決定優先修補的排程,而不是開業前全部都處理。

因應主管機關要求,將來銀行在去年底又展開了兩次UAT測試,11月進行第三次完整UAT測試,還找來第三方協助測試,要確認法遵要求項目沒有疏漏,而到了12月的第四次UAT則是更大規模的測試,甚至進行全行業務流程的測試,一直測試到今年2月,尤其有些需要時間性的測試,例如利息撥放、跨年報表,顧客延遲付款後的通知機制等。2月時,將來銀行已提出開業上線版本的書審資料給金管會,到4月初尚未收到進一步需修正的通知,也在3月完成與財金公司1個月的遠端連線測試。

儘管新任總經理還沒到任,將來銀行未來方向仍有不確定性,但周旺暾表示:「我們就是繼續做該做的事。」就像純網銀開業版本已經提交,將來銀行開發團隊也建立了一個一個程式碼分支版本,展開下一階段功能的開發,甚至開始規畫上線後程式碼版本合併的作業方式。「接下來的挑戰,已經不是主管機關,而是市場了。」他這樣說。文⊙王宏仁、李靜宜

將來銀行IT系統建置時程表

2018年11月 將來銀行籌備處成立
2019年4月1日 資訊長上任,開始規畫資訊架構(包括全系統架構和後端30套系統架構,確定全虛擬化、API化原則),決定用戶端自主開發(行動App和網站版),後端系統則統包委外
2019年7月30日 獲得純網銀設立許可後,展開統包招標作業
2019年11月~12月 開始規畫開戶流程
2019年12月底 後端系統統包專案正式啟動(中華電信旗下子公司負責統包)
2020年1月31日 正式登記成立公司,開始大舉招募IT人力
2月過年後 內部IT人力陸續到職
3~4月 IT團隊到位(分為金融系統、開發、資安和基礎架構等部門),開發人力約30人(iOS團隊、Android團隊、Web開發、SA、測試等),展開用戶端(行動銀行、網路銀行)開發工作
4月 開始進行機房軟硬體建置
4月 發現團隊磨合問題,產出成果不理想,重新調整敏捷流程和聚焦
5月 完成機房與私有雲環境(全虛擬化)建置,後端系統陸續部署,開始介接系統
5月~6月1日 第一次UAT測試(以開戶和轉帳為主,規模較小)
6月 擴編臨時開發人員約7~8人
6月 成立專責SOC團隊,負責內部批次作業,監看內外部流量、SIEM和Log分析(包括EDR分析)
8~9月 第二次UAT測試
9月 金管會正式進行開業檢查,提出軟體、業務和流程面建議
10月 修正金管會建議改善項目,在UAT環境驗證改善結果,達成法遵要求項目。提出改善報告給金管會後,系統凍結版本,進入修正與優化階段,除非主管機關要求,不再增加新功能
11月 新任資安主管到任,資訊系統建置專案第3階段交付,將來銀行取得所有設備控制權,正式導入零信任資安架構
11月 進行第三次UAT完整測試,更找來第三方協助檢查,再次確認法遵要求項目皆無疏漏
2020年12月~2021年2月 進行全行業務流程實測和第四次UAT完整測試
2月 提出開業正式上線版的書審資料給金管會,金管會目前沒有提出需改進的要求
3月 完成財金公司1個月遠端測試(API相容性回歸測試和壓力測試)
4月 繼續進行各項系統測試和開業前準備,也建立App分支版本來開發未來新功能

資料來源:將來銀行,iThome整理,2021年4月

延伸閱讀

【以將來銀行為鏡,談大型系統整合的挑戰】為何團隊磨合衝擊百億純網銀開業(上)
https://www.ithome.com.tw/news/143871

【以將來銀行為鏡,談大型系統整合的挑戰】為何團隊磨合衝擊百億純網銀開業(下)【將來銀行IT系統建置時程表】
https://www.ithome.com.tw/news/143872

【觀點】開業不是最難,純網銀上線後才是真正的挑戰
https://www.ithome.com.tw/news/143869

熱門新聞

Advertisement