金融業使用雲端實務手冊之彙整與見解
近來金管會推出了對金融業的雲端服務的務實手冊。這份文件一開始就提到這份手冊不具強制性，而是建議性。所以我們可以視為是一種指引(guideline)。
金融業的本質對於整個IT還是需要很強大的管控與風險控制。然而這與筆者一開始接觸到的雲端服務本質概述有著非常大的不同。雲端服務一開始是強調快速的創新與效能強化，在此"強大的管控與風險控制"的機制之下是否可能扼殺創新與效能呢?還是可以魚與熊掌兼得呢?有待各位使用的看官自行體會了。
第一章:雲端服務策略發展與治理
文件中這一句"謹慎評估以下影響成效的關鍵因素，並適時進行相關領域的評估與更新，以確保最大程度的保護組織利益。"從這裡還是可以看到金融業還是必須保護現有的效益還是最大指導，而不是有一種冒險的方式取得更大的效益。有一句話說Hight Risk High Reward，雖然不一定對。但是沒有某種程度的創新(當然有一種控制機制)，說要拿取更高的回報，基本上筆者是不信的。
雲適性評估
再來是針對自家系統做一些可適性評估。當然這個作業時間就要取決於各家金融機構的目標與策略了，這可分為技術面與財務面了。技術面的方式(戰術面)就是5R(Rehost、 Refactor、 Rearchitect、 Rebuild、 Replace)，但其實還有一R是retire，廢棄地端系統直接建立新的。因為該系統評估之後可能無法進行Cloud Native的作業，這一類的系統其企業經營得越大越久的一定一大堆。強行推上去雲端，其財務效益可能是負的。
文中提及的業務面評估、技術面評估讀者可以參閱筆者在TOGAF這一個Webinar，而財務面可以參閱FinOps webinar。而雲端服務業者的評估通常就是看哪一家原廠的CSP業務比較會嘴，跟高層的關係比較好，跟公司有良好合作紀錄的。反正三大雲(AWS/Azure/GCP)都是大公司，品質都有其保證，就看技術人員熟不熟，會不會用，學習曲線高不高了。
雲適性評估的參考指引中描述的要求 — “選擇合適之資料 處理及 儲存 地點”，三大雲也都符合其要求。老實說三大雲選擇機房的規則與標準比這份文件中所描述的更嚴格，評估的東西更多。
但是這一條"建議金融機構 可 要求雲端服務業者除在法律不允許之情況下，在當地法律要求其向第三方揭露資料時應通知金融機構。"三大雲在其他國家一定是不會洩漏給當地政府的。但是我們不要忘了，三大雲都是美國公司。美國爸爸的長臂管轄，世上除了少數國家之外，大概沒幾個國家能擋住，更別說是一般商業公司了。所以在使用雲端時也需要考量這一點，除非你放上去的資料已經先經過加密，連CSP都解不開。
使用單一雲與多雲都有其風險。單雲就是押寶同一間廠商，多雲就是系統的複雜性增加。單雲的衝擊對整體公司很大，但多雲的負擔就在技術團隊身上。其技術與系統複雜性可能會成指數型增加，過去傳統的IT/MIS人員的心態與技能可能已不再適用。
雲端服務治理制度
這一部分可參閱本部落格關於使用COBIT與ITIL來進行相關的治理。
權責劃分
有權責劃分是好的。但是劃分得太細就會造成穀倉效應，特別是金融體系的SoD(Separation of Duty)又特別細。這一點其實會對組織要實行DevOps/DevSecOps/SRE/FinOps等雲端相關的運作框架與實踐造成衝突，最後弄成一個四不像，再度扭曲了雲端的本質。
第二章 — 雲端風險評估方法
這一邊寫得是一個通則。更多的戰術性指導可以參閱本部落格雲端運算的風險一文。
第三章 — 雲端服務管理架構
一開始就說要DD(Due Diligence)。在這一塊選擇三大雲最保險，DD的工作就不用做太多。共享責任的部分，三大雲也完全符合這一塊。
在"契約與協議"這一部分中，由於金融業是特殊產業。所以三大雲幾乎可以完全依照文中所描述的進行契約訂定。
"定期審查與服務監督" — 由於雲端服務太多太細，使用人為的方式來監控是不太可能的。尤其一旦深化到Cloud Native的程度。另外定期審查這一件事在地端思維可以進行，但是組織開始進行DevOps/SRE框架與實踐。就不應該是"定期審查，而是持續(continuous)審查"。
最後是SLA。如果沒有達到，CSP通常只會賠付無法作業時的租賃費用。不太可能賠付營業損失(CSP沒有哪麼笨)，除非要另外協議。而且租賃費用可能會高到無法承擔，哪不如不搬。
另外CSP硬體的SLA絕對比世界上大多數的公司還要高，問題在於技術人員在架構設計上有沒有做好配置。筆者就看過有使用者不了解其雲端的運作機制，在某一個機房的機櫃的機器掛掉，該VM在另一個機櫃重啟，但裡面的服務技術人員沒有做好相對應的設計，就說雲端的SLA有問題。就不懂要怪誰。所以我們一定要了解CSP提供的SLA/HA機制到底是甚麼，在系統面上要怎麼配合。
更多關於三大雲的服務架構管理可參閱本部落格"CAF雲端採用框架比較 — Part 1"及其系列文章。
第四章 — 雲端人才培訓
這是人類有組織以來千古不變的老掉牙議題了，不只在雲端運算這一個議題上。組織不論面臨甚麼樣的機遇(如雲端運算)，都會有一場變革需要進行的。對組織來說，唯一不變的就是變。
整個組織都要有具備雲端意識(awarnesse)，這樣組織才能有就緒(readiness)準備。更多這一類的組織轉型方式可以在本部落格"企業的戰略旅程 — 我們現在在哪?"一文中有更多的描述。
不過依筆者的經驗，組織高層最需要先對雲端運算與地端的運作方式有著截然不同的運作思維。否則組織的上雲行動最終會在組織領導層錯誤意識下的決策中失敗。
第五章 — 雲端服務資安控管
基本上這把三大雲的資安Best Practices拿出來重複一次，因為資安本規範本來就有其框架、標準、最佳實踐，只是越多的安全規範可能會有更多的費用與限制。
例如倒底要用VPN或專線來跟地端相連，這是視乎組織對於成本與效能的權衡。而使用共享式的密鑰管理或專有的(Private HSM)也是可能是成本(包含金錢與Management overhead)的考量。
另外在"資料安全與隱私管理"，建立資料銷毀、資料遺失和資料外洩通報管理程序這一方面三大雲也有其標準機制供外界參閱。文中再一次提到"監控與定期查核雲端資料使用情形，預防客戶隱私及營運機密外洩"。這邊要在重複一次，因為很重要。在雲端中的變動性非常高度，定期查核可能無法對應IT環境在雲端中高度變動的需求。
為什麼雲端環境是高度變動的?因為唯有這樣，企業才能在每一次的變動(可大可小)中找出服務創新或效能增進的可能性。甚麼都不變意味著甚麼創新都沒有。
身分識別與存取控制的部分應該與一般地端沒有甚麼差別。差別在於可能會有一堆Application是用API串起來的，尤其是在多雲的環境中。
稽核軌跡與監控 — Audit log的量體在雲端世界中與地端是非常不同的，用人工的方式來進行基本上幾乎不可能。並且微服務的時代興起，這又將log推向一個異次元量級。沒有系統(特別是用AI/ML)輔助我們，要找出各個Component之間的關係與模式是不可能的。
這一章節中很可惜沒有提到零信任的議題，因為在雲端世界中所有的組件都是去耦合(Decouple)的。而零信任正是從雲端發展出來的。所以在威脅與弱點管理的部分，如果組織要進化到Cloud Native的地步，哪麼IDS/IPS這一類的ISO裝置可能不再是我們的重點。Application / Configuration可能才是需要注意的。
更多關於三大雲的資安管理可參閱本部落格”CAF雲端採用框架比較 — Part 1"及其系列文章。
第六章 — 雲端服務維運控管
對於資訊資產的管理基本上就是一個lifecycle。在這一個資產的生命週期的各個階段，組織應該如何應對。在這一章節中，我們又看到了"定期"這一詞。請改變我們的思維 — 是"持續"。
服務部署與監控 —
基本上它把DevOps/DevSecOps/SRE等框架與實踐的內容混在一起。基本上是把CI/CD pipeline、IaC、Configuration Management都提出來講。然而在"DevOps/DevSecOps/SRE等框架與實踐" 中，每一個組織文化與要求都可能不盡相同。例如在本部落格"服務可靠性工程的文化"一文中，SRE可能有幾種不同的形態。
最後在"資源管理(這通常是SRE團隊的事情)"這一節看得有點一頭霧水，這一句"以確保有足夠資源達成業務目標"。在雲端中，只要設定得當，資源幾乎無限(如果碰觸到CSP的Quota是另外一回事)。重點在於這個資源使用是不是得當，例如一台Server可以每秒處理1000個Request。開始Auto Scaling後，理論上應該是每台都要能處理相同的量能。不要Auto Scaling處裡的量能反而下降。
這一句"實施自動化監控和警報系統，即時追蹤資源狀態和服務指標，確保在出現異常時迅速執行應對措"。是地端運作的思維，也不符合SRE的運作精神。SRE要將此類事件最小化，運作方式要從 reactive to proactive。
第七章 — 雲端服務查核
筆者只能說，要實地到CSP的各機房查核是不可能的，因為你們不是美國政府。所以文章中提及的:
對於具 重大性 之 雲端 委外 服務，金融機構之查核重點項目 可 包含：
(a) 雲端服務所在機房之實體安全控管機制。
應該說想太多，如果CSP讓一個客戶這樣做了，其他客戶也一定群起要求。哪這樣CSP的機房安全性將毫無可言，其他客戶也不會使用其服務。比較有可能的是第三方查核，而且還是CSP配合獲或指定的。因為你們不是美國政府，一年才賺你多少錢，你們可能只佔CSP營業額的0.1%都不到。不要把自己的公司想得太偉大。
查核項目中的A — F項，CSP會讓你去看一堆它們的合規報告(例如SOC系列報告)就很好了。其他文件中提及的各領域查核，只要涉及機房實體、CSP內部的系統管理方式與政策、供應鏈管理這一些CSP自己的內部資料是不可能的。就像我們自己的公司，會把這些資料拿出來給客戶看嗎?
而屬於系統上的查核，CSP則是任客戶實行。像是以前做黑白箱測試都要先跟CSP申請，現在都不用，客戶何時想做就做。系統上的任何安全驗證，客戶也可以隨時隨地自行驗證。
再說一次，這一類的查核。只要涉及CSP自己內部的東西是不可能給客戶看的(因為你不是美國政府)。客戶最多看到外部的公開資料，以及與第三方查核單位配合的查核資料。最多最多能看到細部的查核資料就已經很了不起了。
第八章 — 雲端服務韌性管理
CSP在機房與其提供的服務上其BCP/DR絕對比世上大部分企業好很多。重點在於我們懂不懂如何設定，以及有沒有運用的知識。這些都關於企業的成本以及management overhead。例如，如果RTO/RPO的要求沒有太高(例如8小時內)。我們可不可以用cold site的價格撐起Hot site的DR運作，因為在地端這樣的運作方式代價高昂。
因為CSP提供的BCP/DR可以橫跨多的AZ甚至是多個Region，所以客戶系統的BCP/DR機制就要看成本要求與整體設計的機制。想要達成文件中建議的BCP/DR絕對沒有問題，問題在於要花多少$$$。如果Cross Region對營運很重要，哪麼畫這一筆錢絕對值得。因為就算是金融業要經營Cross Region的機房，其代價也絕對不小。
另外"資訊安全事件通報與管理機制" —
如果沒有付企業等級的服務費(代價高昂，台灣一般企業大都不想付)，通常客戶需要自行到CSP提供的Dashboard自行查看，或是由SI代為通知。
