駭客攻擊手法不斷翻新。近日安全廠商發現，WAV音訊檔也可以被用來散佈惡意程式。

過去駭客經常將惡意程式藏在非文件檔案中，像是圖檔中散佈，這種攻擊手法稱為圖像隱碼術（Steganography）。以前看到的例子都是利用.JPEG或.PNG檔，不過最近包括賽門鐵克和BlackBerry的Cylance威脅研究中心研究人員，分別發現連WAV檔也被用作此類攻擊。

賽門鐵克6月公佈，近日名為Turla或Waterbug的俄國駭客組織發動多次攻擊，其中一次是將後門程式Meterpreter編碼成.WAV檔案型態，以避免防毒軟體的偵測。而在過去的研究中，Turla被認為和俄國政府有關。這也是安全研究界第一次發現圖像隱碼術（Steganography）使用.WAV檔。

周三Cylance部門研究人員也在一家企業電腦發現數次惡意行動，駭客將惡意檔案混在Wav檔案中。這些檔案乍看無害，但在不知情用戶執行時，可和原先已在用戶環境中的下載程式（loader）作用以釋放出惡意程式。其中一個.wav檔使用了最低有效位元（Least Significant Bit，LSB）手法，以僅4 byte資料和下載器互動後釋出Monero挖礦軟體XMRig，目的利用企業的CPU運算資源來挖礦。另外二個.wav檔則會釋放出Metaploit程式碼，可用來建立逆向shell，分別經由逆向TCP及逆向HTTP連線連向外部伺服器，以接受攻擊指令。

研究人員認為這些手法和現有駭客組織（包括賽門鐵克發現的Turla）很類似，顯示正在進行攻擊模擬，同時也代表駭客已發展出避免被偵測的新手法。

CNBC報導，由於近年來領導微軟推動雲端業務有成，微軟今年為執行長Satya Nadella調薪66%。

報導引述微軟近日向美國證管會申報的文件，微軟支付給Nadella的報酬為4290萬美元，比2018年的2584萬成長66%。其中包括股票獎勵2966萬及其他報酬，而薪水也從去年的150萬成長為233萬。

微軟文件指出，這是去年9月初微軟董事會檢視Nadella領導微軟成績後，調整獎勵方案的結果。理由包括Nadella於2014年被拔擢為執行長後到去年9月，微軟市值從3020億擴大為8500億美元。Nadella的策略性領導下，包括強化客戶信任，推動公司文化變革，並成功推進新科技和新市場。他強力執行智慧雲端（Intelligent Cloud）願景，使微軟在營收、營運收入和市值上，相較市場其他公司都更勝一籌。

6月結束的微軟2019年會計年度中，公司總營收達1258億美元，較2018年成長14%，商用雲端收入提高了43%來到381億，伺服器產品及雲端服務營收增長25%，Azure營收也有72%的成長。Windows商用產品及雲端服務營收比去年增加14%，Surface營收則成長23%來到57億美元。

微軟去年一度從蘋果手上，奪回全球市值最高的公司頭銜。周三微軟市值來到1.07兆美元。

美國聯邦通訊委員會（Federal Communications Commission，FCC）在本周三（10/16），以3票對2票通過了T-Mobile與Sprint的合併案，雖然正式的新聞稿預計要到月底才會出爐，不過已有多家媒體引述消息來源報導此事，且當中兩名反對此案的委員Jessica Rosenworcel及Geoffrey Starks，也已迫不及待地發表公開聲明。

美國第三大及第四大電信營運商Sprint與T-Mobile是在去年4月宣布，準備以股票交換的形式合併，合併後將以T-Mobile作為存續公司，預計可大幅縮小與Verizon及AT&T的距離。

原本外界並不看好這項合併案，因為它可能危及市場競爭，提高消費成本，不容易通過主管機關的審查。

然而，美國司法部在今年7月率先通過了這項合併案，條件是Sprint與T-Mobile必須要扶植衛星電視業者Dish Network成為美國第四大電信業者，Sprint與T-Mobile也必須同意要把部份資產讓渡給Dish Network，包括2萬個基地台、無線通訊頻譜，以及900萬名付費卡客戶等，以確保市場能夠維持競爭。

FCC的核准代表雙方的合併案又前進了一步。

然而，Rosenworcel指出，當市場因合併而變得更集中的時候，有大量的證據表明它將造成競爭減少，價格的提高，品質的下滑與革新變慢等後遺症。同樣反對該案的Starks也有同樣的看法，認為它將帶來更高的價格與更少的選擇。

不過，上述並不代表Sprint與T-Mobile能夠順利合併，因為現在已有16個州就此案提出了反壟斷訴訟，希望聯邦法院能夠阻止T-Mobile與Sprint的合併案。這兩家電信業者必須要能圓滿解決此一訴訟案才能完成合併，而該案則預計於今年底開庭審理。

由於窒礙難行，使得英國數位、文化、媒體暨體育大臣Nicky Morgan本周對外宣布，將不再執行要求色情網站驗證造訪者年紀的規定。

英國的《數位經濟法案2017》（Digital Economy Act 2017）中規定，色情網站必須負責稽核造訪者的年齡，禁止18歲以下的青少年瀏覽該站，要求造訪者直接在網路上提供身分證明或信用卡，或是在書報攤購買年齡認證卡，違反該規定的色情網站可能會被搜尋引擎下架、遭ISP業者封鎖，或是禁止使用支付服務。

不過，此一政策因為涉及了法令、執行與技術面上的難題，原本要在去年4月實施，繼之延後到今年7月，而今Morgan則承認不會再實施。

反對最烈的是隱私組織，認為這等於讓色情網站得知造訪者的身分，並營造了身分外洩的機會。此外，該政策的制定程序也違反了歐盟規定。

Morgan則說，雖然他們放棄了此一規定，但會藉由更廣泛的線上危害白皮書，來保護兒童在網路上的安全，準備設立一個新的網路監管機關，要求所有的網站或社交媒體承擔責任，而不僅針對色情網站。

資安公司Palo Alto Networks威脅情報小組Unit 42發現一種新型的Graboid挖礦綁架蠕蟲，目前已知這個蠕蟲已經感染了超過2,000臺不安全的Docker主機，用於挖掘Monero加密貨幣，研究人員提醒，雖然這個挖礦綁架蠕蟲沒有複雜技術或是程序，但是由於他有能力從C2（Command and Control）伺服器下載新腳本，因此可以簡單地轉換成勒索軟體或是任何惡意軟體，企業應提高保護自家Docker主機的能力。

過去也有以蠕蟲病毒的形式，來散布挖礦綁架惡意軟體的案例，但是這是第一次挖礦綁架蠕蟲被發現存在Docker社群版本中，使用容器進行傳播。研究人員表示，由於大多數傳統端點保護軟體，都不會檢查容器中的資料以及活動，因此這種惡意活動難以被發現。

整個攻擊鏈從攻擊者在網際網路中，選定一個不安全的Docker守護行程（Daemon）開始，在上面執行從Docker Hub拉取的惡意容器，並且從C2伺服器下載一些腳本以及容易受攻擊的主機列表，接著挑選下一個攻擊目標以傳播蠕蟲。Graboid會在容器中進行挖礦以及散布蠕蟲，每次迭代Graboid隨機挑選三個目標，在第一個目標安裝蠕蟲，停止第二個目標的礦工行動，並在第三個目標上啟動礦工，而這樣的機制讓採礦行為變得非常隨機。

也就是說，當被害者主機被感染時，惡意容器並不會立刻啟動，必須要等待另外一個受感染主機的訊號，挖礦程序才會被啟動，而正在挖礦的主機，也會隨機接收到其他受感染的主機停止挖礦的訊號。每臺受感染主機的礦工都由其他受感染的主機隨機控制，研究人員表示，他們不清楚這種隨機控制的設計動機，因為以規避偵測的角度來看，這樣的機制效果不佳，比較可能是設計不良或是有其他的目的。

Unit 42進行了模擬，來了解蠕蟲整體採礦的能力，包括蠕蟲散布的速度，以及每個礦工在受感染的主機上平均活動時間，研究人員提到，以2,000臺主機規模進行的實驗，蠕蟲病毒要花費大概60分鐘，才能感染其中1,400臺易受感染的主機，由於受感染主機上礦工隨機啟動和停止的挖礦行為，每個礦工約只有65％的時間處於活動狀態，每個礦工採礦周期平均僅持續250秒。

研究團隊分析了蠕蟲使用的主機列表，其中包含2,034臺易受攻擊的主機，57.4％的IP來自中國，而13％位於美國，在Graboid使用的15臺C2伺服器中，主機列表中列了其中的14臺，這表示攻擊者會控制易受感染主機的Docker守護行程，在上面安裝網頁伺服器容器，並將惡意載體放在上面。

Graboid攻擊會使用到的Docker映像檔pocosow/centos已經被下載超過一萬次，而gakeaws/nginx也已經被下載6,500次，Unit 42發現gakeaws還發布了另一個挖礦綁架映像檔gakeaws/mysql，其內容與gakeaws/nginx相同。不過這些有害映像檔，都在研究人員與Docker團隊聯絡後，全部被移除。

研究人員警告，當沒有適當的身份驗證機制，企業不應該把Docker守護行程暴露在網際網路上，而且其實在預設情況下，Docker社群版是不會暴露Docker守護行程的。企業應該使用Unix Socket來跟本地Docker守護行程溝通，或是使用SSH連接遠端Docker守護行程。

企業需注意在防火牆規則中加入白名單，限定流入流量的來源，並且不可從未知的註冊表或是未知使用名稱空拉取Docker映像檔，平時也該定期檢查系統是否存在未知的容器或是映像檔，也可以使用雲端安全解決方案，辨識惡意容器。

知名安全部落格KrebsonSecurity報導，專門銷售被竊信用卡資料的地下網站BriansClub上個月被駭，導致其4年來蒐集的2600萬筆信用卡資料外洩，交給金融機關用以追查而不再流入黑市中。

BriansClub站名取自資安專家Brian Krebs主持的Krebs on Security，但和本尊相反，這個網站專門蒐集網路上被駭得或從實體店家竊得的信用卡或現金卡資訊，是此類地下網站中最大網站之一，網頁上還有@2019 Crabs on Security的版權聲明。

上個月Brian Krebs接獲一份包含大量信用卡資訊的純文字檔，據信來自BriansClub網站。經過多名專家比對驗證，顯示資料的確來自這個網站。

這份遭外流的資料顯示從2015年起以每年數百萬筆的速度，累積超過2600萬筆資料，單是今年1到8月就增加760萬筆。研究人員推斷相信，BriansClub是轉售其他地下網站的資料來獲利。

研究人員分析，其中910萬筆已經由此網站賣出。若以美國官方公佈每張信用卡平均遭盜刷500美元來計算，總值超過40億美元。研究人員保守估計，這2600萬筆資料中，還有1400萬張信用卡還在有效期限內。

所有資料都已被分享給了發卡銀行及和金融業有合作關係的單位用以追查卡片、監控資訊流向，或用於重發卡片。

有鑒於Windows 7支援即將於明年1月截止，微軟催促用戶升級Windows 10同時，周三宣佈檢測應用程式和Windows相容性的桌面分析（Desktop Analytics）雲端服務正式提供上線。

桌面分析（Desktop Analytics）是整合微軟System Center Configuration Manager的雲端服務，旨在協助企業IT分析及評估app和Windows 10相容性。其原名為Windows Analytics，之後擴及Windows 10及Office 365 ProPlus，且和System Center Configuration Manager進一步整合，並改名為桌面分析服務。微軟還宣佈了Desktop App Assure服務，方便真的有app相容問題的企業上網申請解決，由微軟提供技術支援。

不過這項技術支援，僅提供採購Windows 10 Enterprise E3／E5、Microsoft 365 F1／E3／E5、Windows 10 Education A3／A5、Microsoft 365 A3／A5、Windows Virtual Desktop Access E3／E5的企業或學校單位，才能享有這項服務。

Desktop Analytics於今年3月釋出預覽版，7月釋出給大型企業及學校用戶。微軟表示，這段時間有數千家企業使用這項服務，來檢測數百萬台登錄的Windows終端系統。在從預覽版之後，微軟也為這項服務加入新功能，包括免除手動評估和Desktop Analytics相容的應用程式（如微軟發佈的系統元件），以及啟用階段就將Windows Analytics Upgrade Readiness時代下的資料，搬到Desktop Analytics上。另外，System Center Configuration Manager 1906版，也進一步整合Desktop Analytics，使測試中及上線的系統可以自動匯入Desktop Analytics的分析資料。

微軟並預告即將提供把管理員資料搬移到Desktop Analytics的功能，並且使Desktop Analytics整合到用戶端管理服務Microsoft Intune。

微軟表示.NET Core 3.0現在已經具備發展現代工作負載需要的技術，因此計畫將不再把.NET Framework上既存的技術移植到.NET Core 3.0上，並且將考慮會以MIT授權許可，開源不打算移植到.NET Core 3.0上的.NET Framework程式碼庫。

一開始.NET Core 1.0只擁有一個很小的API集合，僅包含約1.8萬個.NET Framework API，而透過.NET Standard 2.0，微軟試圖在.NET Framework、.NET Core和Xamarin之間共享程式碼，因此.NET Core 2.0提供了約3.8萬個.NET Frameworks API，微軟還建置了Windows相容套件包，而該套件包讓.NET Core又增加了2.1萬個.NET Framework API，前後約有6萬個API加入.NET Core。

而在最新發布的.NET Core 3.0中，微軟增加了WPF和WinForms，因此從.NET Framework移植到.NET Core的API總數超過了12萬個，而這個數量已經超過.NET Framework API數量的一半。微軟強調，.NET Core中還包含了6.2萬個.NET Framework中沒有的API，因此比較API的總數，目前.NET Core的API數量約達.NET Framework API的80％。

在Build 2019大會上，微軟也宣布過AppDomains、遠端處理、網頁表單、WCF伺服器以及Windows Workflow等功能，將不會移植到.NET Core上。目前也不再計畫把任何.NET Framework技術移植到.NET Core上。對於那些沒有移植的程式碼，微軟將會考慮在GitHub上以MIT授權開源，使其成為開放原始碼專案，像是目前已經存在的CoreWF和CoreWCF社群專案一樣。

微軟提到，未來.NET會基於.NET Core發展，藉由.NET Core 3.0，微軟可以隨時移植桌機、行動裝置、控制臺應用程式，甚至是網頁平臺與雲端服務需要的技術，而這些技術將不會出現在.NET Framework程式碼庫中。

國家通訊傳播委員會（NCC）在周三通過「行動寬頻業務競價作業注意事項」修正草案，對5G釋照的競價遊戲規則有更詳細的說明，12月10日將展開競價作業，預計明年1月完成釋照。

中華電信、遠傳電信、台灣大哥大、台灣之星、亞太電信五家電信業者，先前已向NCC提出申請參與競價，NCC準備在11月下旬完成書面審查，公布合格競價者名單，12月上旬開始競價作業，明年1月完成整個5G釋照程序。

而此次國內5G頻譜釋照，將釋出3.5GHz、28GHz及1800MHz三個頻譜，合計將釋出2790MHz的頻寬，其中的3.5GHz劃分為27個單位，每單位為10MHz頻寬，共釋出270MHz頻寬，而28GHz劃分為25個單位，每單位為100MHz，共釋出2500MHz頻寬，至於1800MHz，因多數已應用在4G服務，僅釋出20MHz頻寬。

相較於6年前4G首次釋照採用類似拍賣的方式，由各家業者出價競標，NCC指出，此次5G釋照方式參考國外的拍賣經驗，改良三年前4G第三波釋照的「多回合同時上升競價法」（SMRA），從業者的出價競標，改為業者提出需求頻寬，提升競價效率。

5G釋照競價作業將分為兩個階段進行，第一階段為數量競價，以多回合競價決定各業者能得到的單位數量，第二階段則是位置競價，決定各業者得標單位的頻率位置。第一階段結束至第二階段開始，兩階段間相隔7天。

在第一階段的數量競價部份，各家業者提出需要的單位，若需求的單位數超過供給的單位數量則進入第二回合，第二回合價將增加3%，若是需求仍大於供給再進入第三回合，回合價再增加3%，直到需求單位量和供給量相同為止，若連續兩回合沒有競價者提出需求頻寬，則結束數量競價。

為避免某些頻譜資源流標，在第一階段的數量競價中加入補充競價回合，若業者得到的需求數量已超過上限，仍可以參加補充競價回合，以突破上限限制取得更多單位數量。

NCC補充說明，每回合競價者取得的暫時得標頻寬，會依競價者提出需求頻寬的回合價，是否等於當前回合的回合價，或競價者的需求頻寬，是否等於前一回合的暫時得標頻寬等因素，決定競價者的排序，序位優先者取得暫時得標頻寬，如果序位相同，則由電腦抽籤決定。

第二階段的位置競標，先由各業者提出想要的位置排列組合，彼此重疊的位置經過協商後，若仍未取得共識，則依業者出價決定。

重點新聞（2019/10/10～2019/10/16）

  SUSE    OpenStack雲    退出   

SUSE決定拋棄OpenStack雲，停止開發及銷售該產品線，要全力投資應用交付產品

SUSE日前宣布了一項意外的消息，決定退出OpenStack雲市場。在紅帽被IBM併購後，SUSE成為全球最大的獨立開源公司，作為參與OpenStack IaaS雲計畫的先行者之一，SUSE於2012年進入OpenStack市場，是第一個推出企業級OpenStack發行版的業者，今年4月還推出了基於OpenStack Rocky版本的OpenStack Cloud 9。然而，時隔不到半年，SUSE決定結束與OpenStack長達7年的旅程。SUSE將停止推出SUSE OpenStack Cloud新版本，並停止銷售SUSE OpenStack雲。SUSE全球聯盟與營銷總裁Michael Miller指出，SUSE將斟酌參與OpenStack之外的特定OpenStack基金會項目，以滿足客戶和合作夥伴的需求，且工程師將繼續參與上游OpenStack的開發。對於為何決定退出，SUSE僅表示，因應市場的技術趨勢，最重要的是滿足客戶需求，將增加其於應用交付市場的投資。SUSE未來將聚焦基於K8s的應用交付產品。（詳全文）

  IDC    公有雲服務    調查   

IDC：2023年臺灣公有雲服務支出將逾11億美元

國際市場調查研究機構IDC日前公布，最新「全球半年度公有雲服務支出指南」，2019年亞太區（不含日本）公有雲服務和基礎設施支出將達到260億美元，相較2018年成長47.1%。該調查量化了企業於公有雲的支出，調查對象涵蓋20個行業，並分布於47個國家或地區。根據調查，亞太區公雲服務預計將在2018年至2023年期間，成長近3倍，2023年會達到761億美元，中國、澳洲及印度是亞太區公有雲發展的主要市場。臺灣公有雲服務支出則預計於2023年達到11.22億美元，預計五年複合成長率達11.83%。

亞洲市場以基礎設施即服務（IaaS）為最大類別的雲端服務，支出達50.2%，其次是軟體即服務（SaaS）占39.03％，平臺即服務（PaaS）為10.7％。不同於亞洲市場的支出結構，臺灣以SaaS的支出占比最大，占2019年總體公有雲支出達46.7％，IaaS緊追在後占46.4％，PaaS則僅有7％。臺灣市場三大雲端應用產業，分別是製造業、服務業和金融業，IDC認為，整體市場未來的發展仍有一定的成長動能。（詳全文）

  AWS    機器學習    執行實例    

AWS機器學習服務Amazon SageMaker新增支援EC2最快P3系列GPU執行實例

AWS機器學習服務Amazon SageMaker加入新的執行實例選項，EC2中P3系列的P3dn.24xlarge，該實例專為分散式、高效能且複雜的機器學習訓練所設計，可以加速該類型的訓練工作。P3dn.24xlarge為P3系列最快速的實例，其搭載了8個Nvidia V100 GPU，提供比其他P3執行實例多一倍的GPU記憶體。AWS表示，深度學習已具有從大量非結構化資料中，擷取特徵並建構複雜模型的能力，但訓練神經網路需要大量的運算能力，使得開發者轉而使用GPU加速運算。該新實例的vCPU也比其他實例多了5成，內建96個AWS訂製的第二代英特爾Xeon可擴展vCPU，儲存使用1.8 TB的本機NVMe型SSD。由於P3dn.24xlarge提供達100 Gbps的網路傳輸量，因此開發人員能夠利用16、32或 64個P3dn.24xlarge執行實例，進行分散式訓練，以縮短模型訓練時間。目前新實例僅在美國北維吉尼亞和奧勒岡區域，開放用於Amazon SageMaker服務。（詳全文）

  微軟    資料處理    無伺服器服務   

微軟為Azure Data Factory服務推出視覺化資料流處理功能Mapping Data Flows

微軟近日為簡化 ETL的混合式資料整合服務Azure Data Factory，加入新功能Mapping Data Flows，供企業用戶大規模且快速地轉換資料。Azure Data Factory為一項無伺服器服務，企業不需管理基礎設施，就可在雲環境中進行ETL工作，處理任何規模的資料。而新功能則是專為複雜且大規模的資料處理工作所設計，企業可藉由瀏覽器，在可存取的視覺化環境裡，建構彈性的資料工作流程，並由Azure Data Factory處理Spark運作的複雜作業。且該功能可處理無法預測的資料架構，還能維持輸入資料可變更的彈性，並簡化企業處理資料的工作，讓企業可專注於建構業務資料的邏輯。企業不需花費時間管理伺服器叢集外，也不需開發程式碼，即可快速地載入事實表格（fact table）、維持緩慢改變資料技術（slowly changing dimension）、聚集半結構化大數據資料，還有可使用模糊匹配來配對資料，以及為建模型準備資料。（詳全文）

  AWS    EC2     Arm系列    裸機    執行實例   

AWS在EC2的Arm系列推出裸機執行實例

AWS日前為EC2的執行實例A1系列增加裸機選項，稱之為a1.metal，使用Arm的AWS Graviton處理器。該新裸機實例提供16個邏輯處理器，32 GiB記憶體，而EBS頻寬則為2.5 Gbps。A1執行實例是新的EC2系列，適合處理橫向擴展的工作負載，像是網頁前端、容器化微服務或是快取隊列。因使用Arm的AWS Graviton處理器，可讓Arm開發人員在雲環境中，基於Arm基礎架構上進行建置和測試工作，而不需要模擬器或是交叉編譯。

新裸機實例的特性可讓企業直接利用實體資源，以及低階的硬體功能，像是虛擬環境通常不提供的效能計數器等。另外，也能讓應用程式在特殊原因或是授權限制下，在非虛擬化的環境中執行。Amazon ECS和Amazon EKS皆支援A1執行實例，Docker也在其企業版支援Arm架構，且大多數的Docker官方映像檔也都支援Arm。其他AWS服務，比如說，Amazon EBS、Amazon CloudWatch和Amazon Inspector等，都與A1執行實例整合。目前A1執行實例包括裸機，只在4個區域提供，歐洲法蘭克福，與亞洲東京、孟買以及雪梨。（詳全文）

  甲骨文    招募    雲端業務    

甲骨文計畫於全球招募2千名雲端事業員工，2020年前要新增逾20個雲端區域

甲骨文近年逐漸將雲端服務轉為其的關鍵業務，為與亞馬遜、微軟等雲端業者競爭，近日宣布一項招募計畫，將於全球招募約2千名員工，負責發展甲骨文雲端基礎架構的業務。職缺內容包含軟體開發、雲環境維運、業務營運等，以給予甲骨文雲端基礎架構的客戶支援。新員工將入職於西雅圖、舊金山、印度等地資料中心的軟體研發中心。甲骨文目前有16個雲端服務區域，並計畫在 2020 年底前，再新增20多個區域，分布在智利、日本、南非、沙烏地阿拉伯等國家。（詳全文）

  AWS    執行實例    SAP HANA   

AWS推出記憶體最高達24 TiB的EC2執行實例

AWS於EC2的高記憶體系列加入了擁有18 TiB以及24 TiB記憶體的執行實例，用戶可以使用這些高記憶體執行實例，執行大規模SAP HANA資料庫的安裝工作。這些高記憶體執行實例與其他EC2執行實例一樣，都能夠使用映像檔AMI（Amazon Machine Image）以及各種管理工具。這些高記憶體的執行實例，是可以在VPC（Virtual Private Cloud）中運作的裸機執行實例，在預設情況下為區塊類型儲存服務Elastic Block Store最佳化。

過去，最高的規格為u-12tb1.metal擁有12 TiB記憶體，專用EBS頻寬為14 Gbps。而新的u-18tb1.metal與u-24tb1.metal執行實例，則分別具有18 TiB以及24 TiB記憶體，存有8個插槽，使用第二代Xeon可擴展處理器，專用的EBS頻寬都提升為28 Gbps。AWS提到，加大的專用頻寬可以加快資料載入記憶體的速度，9 TB的資料只要花費45分鐘，相當於每秒3.4 GB。與既有的同系列實例一樣，新實例可以專用主機的形式，預訂3年使用。現階段，最新的執行實例只在美東的北維吉尼亞區域推出，之後會逐漸在各區域開放。（詳全文）

圖片來源／SUSE、微軟、甲骨文、AWS 

  更多Cloud動態  

1. Google在Coursera推出GKE與Compute Engine基礎架構兩專項課程，讓企業了解不同的基礎架構設計方法（詳全文）

2. SAP轉向雲端化的主要推手其CEO突宣佈年底離職，由雲端部門總裁及營運長接手，聯合掌舵公司營運（詳全文）

3. 芝加哥雲端稅上路3年半，前年課得4,340萬美元，美國其他地方政府相繼跟進徵稅（詳全文）

4. 中華電信和新北市警局合作雲端監錄系統邁入第六年，經統計，去年有4成刑事案件靠其協助破案（詳全文）

5. Amazon消費業務關掉最後一臺甲骨文資料庫，全部轉移到AWS雲（詳全文）

資料來源：iThome整理，2019年10月

微軟與阿里雲合作，於開放網頁基金會下開源了OAM（Open Application Model）專案，這是在Kubernetes上建置雲端原生應用程式的規範，用來定義完整代表應用程式的模型，與傳統PaaS應用程式模型最大的差異在於，OAM獨立於平臺，可同時保持標準以及各平臺的獨特性，還可在非Kubernetes環境開發實作。

Kubernetes目前已經成為主流容器調度工具，各公有雲平臺大量地推出Kubernetes服務，但是微軟提到，Kubernetes的核心資源，像是服務（Services）或是部署（Deployments）等各代表了整個應用程式的不同部分，而像是Helm Charts物件，代表了潛在可部署的應用程式，但是一旦部署完成，便沒有一個以應用程式為中心的模型，來定義執行中的應用程式，微軟認為，目前需要一個定義完整且一致的模型，來代表整個應用程式。

而OAM則是可以用來描述應用程式的規範，以便將應用程式描述從應用程式部署細節和託管基礎架構中分離。微軟提到，這樣的分離有多種好處，由於每個Kubernetes叢集都是不同的，從叢集運作細節分離應用程式定義，可使開發者更關注應用程式的關鍵元素，而非部署的運作細節。另一個分離的好處，便是允許平臺架構師重複使用元件，並讓應用程式開發者專注於將元件和程式碼整合在一起，以便更快速簡單地建置高可靠性應用程式。

在OAM中，應用程式由多個概念組成，第一是應用程式的元件，像是MySQL資料庫，開發人員也可以將自己的程式碼打包成元件，並且編寫Manifests描述元件與微服務之間的關係，這些元件成為平臺架構師可以重複使用的模組，模組中封裝了安全性和可擴展性部署的最佳實踐。

第二個概念則是配置檔案，應用程式營運人員可利用元件配置檔案，來實際部署應用程式的實例，微軟解釋，這些配置資源可以讓營運人員真正執行應用程式。最後一個重要概念則是Traits集合，用來描述應用程式環境的特徵，包括自動擴展以及Kubernetes Ingress等。

微軟提到，比起傳統的PaaS應用程式模型，OAM最重要的差異是與平臺無關，雖然最初的OAM實作Rudr是建立在Kubernetes之上，但事實上OAM並沒有與Kubernetes緊密綁定，因此在不同的環境像是小型裝置或是邊緣裝置的部署等，可以發展成不同的實作，或是在無伺服器的環境，用戶根本不需要了解Kubernetes的複雜性。

OAM還具有可擴充性，可讓平臺供應商透過Trait系統提供用戶平臺特別的功能，硬體廠商也可以透過類似的方法，以Trait系統提供硬體平臺的特別功能，OAM的設計讓應用程式擁有高可移植性，但是每個平臺又都能提供特別的功能，供開發人員在標準以及功能間自己取得平衡。

OAM根據開放網頁基金會協定開發，微軟提到，他們的目的就是要讓OAM發展成為供應商中立的規範，以實現開放治理和社群協作。目前OAM的開放Kubernetes實作Rudr已經在GitHub上開源。

「今年8月，英國開放銀行API用量首度達到了1億次！」英國CMA開放銀行業務領導人Bill Roberts興奮地在Email上告訴我。

2016年，英國政府為了活化國內金融市場，英國競爭及市場管理局（CMA）決定採取強制的開放銀行政策，要求英國前9大銀行，建立與採用統一的開放銀行API共同標準，並強制銀行將顧客資料透過這套開放API，提供給授權的第三方業者使用。Bill Roberts正是在CMA中推動這項政策的主要負責人。

英國政府這項開放銀行之舉，也成了全球關注焦點，甚至是各國開放銀行仿效的參考對象，臺灣也不例外，早在臺灣去年宣布開放銀行之初，儘管沒有採取和英國一樣的強制開放作法，但在實施上，處處借鏡英國經驗來自省。甚至，

金管會主委顧立雄指出，在第二、三階段涉及消費者個資的Open API，將參考英國和澳洲的經驗，來決定臺灣接下來要怎麼走。

去年12月，Bill Roberts首度來臺分享，揭露英國開放銀行的推動經驗，CMA在2016年9月，要求這9家銀行共同出資，成立了開放銀行實施組織（Open Banking Implementation Entity，OBIE），主要負責設計開放銀行API標準，也負責協助各銀行的導入。OBIE更找來挑戰者銀行、金融科技公司、第三方提供商、支付服務業者、PSD2（支付服務指令第二版）實施相關人員與消費者團體等各方代表，組成開放銀行諮詢小組，將非主流銀行和其他產業的聲音，也納入開放銀行的政策規畫中。

另外，由英國FCA（金融行為監理總署）負責審查第三方服務業者的資格。FCA依照資料敏感性，將開放的銀行資料分成兩種存取權，一是低風險的唯讀類資料，第三方服務業者可讀但不能更動。另一種則是屬於高風險的可讀可寫類資料，業者除了能讀取資料，還能更新原本銀行提供的資料，或是會提供支付行為需要寫入行為的第三方業者。Bill Roberts說，FCA會根據金融服務提供者所需讀取的銀行資料敏感性，採取不同的認證過程。

不同於臺灣只是界定出第三方服務業者TSP（Technical Service Provider）一種角色，英國OBIE則是以第三方合作夥伴TPP（Third-Party Provider），來指稱這群代表消費者處理帳戶資料或支付指令的第三方業者。而TPP可以跟第三方科技服務業者TSP合作，TPP的角色定位偏重業務角色，尤其是B2C模式，而後者的TSP則從技術角度來訂定，大多屬於B2B應用。甚至，英國將TPP又進一步細分為可讀取帳戶資料的AISP和可執行支付指令，對帳戶資料可讀可寫的PISP。

截至今年10月為止，英國9大銀行和數十家非主流銀行加入了開放銀行的串接，涵蓋了99％的英國金融市場。目前有80家活躍的TPP，將Open API應用到自家產品上，例如Yolt、Credit Kudos、CreditLadder等

在2018年7月，英國Open Banking的API平臺上線不久，已有3百萬次API呼叫量，經過1年，到了2019年8月，API累積呼叫次數，首度超過了1億次。已經體驗到Open Banking各種創新服務的消費者超過2百萬人。Bill Roberts更強調，更重要的是，上路至今，沒有發生過一次資料外洩事件或爭議。

趁著財金開放API平臺正式上線之際，我們也跨海二度採訪了這位英國開放銀行政策關鍵推手，整理如下：

Q.英國開放銀行發展目前最新成果？

英國9大銀行可以提供到App對App的串接，直接在手機上透過生物驗證授權來存取Open API，另有30家小型或挑戰者銀行也正式加入，另有60家銀行正在進行串接，整體來說，開放銀行政策已涵蓋了99％的英國金融市場。目前有300家TPP取得資格可以存取開放銀行的API。平臺上線之後，每個月的API用量成長約2成，到今年8月累計API呼叫次數達到了1億次。

Q.有哪些厲害的開放銀行應用？

最常見的是自動補足餘額服務，當使用者指定帳號的資金，低於預設的水位時，會自動將支票帳戶中資金，轉移到消費者慣用的存款帳戶中。如果月底錢用完了，TPP也可以提供貸款來確保消費者的信用，甚至可以保證比銀行利率更低，代表例子是Safety Net Credit。
另一種類型是產品比較服務，尤其像中小企業很難比較使用不同銀行帳戶付款的支出，因為這些支出大多各自按交易量來計費，有家Swoop Funding業者，可提供比較服務，可以比較網路費用或能源費用，甚至建議消費者更換更省錢的供應商。Credit Kudos服務則可以讓消費者以過去的消費記錄來證明自己的信用，用較低的利率借到錢。

Q.發生過爭議事件或消費者投訴嗎？

據我所知，截至目前，沒有發生過任何一起爭議、詐騙或資料外洩事件。在OBIE中設有專門負責爭議處理的機制。

Q.管理TSP的重點是？ 

個人金融資料的安全是最重要的事，但是，銀行不能以此為藉口，而要求他們採取繁瑣或不必要的安全驗證機制。我們還是希望做到跨不同AP的串接上，可以兼顧簡單、無摩擦又高度安全的整合。

Q.未來英國會從開放銀行，進一步發展成開放金融？

未來計畫目前還不明朗，FCA已經成立了一個諮詢小組，將在今年12月發布一份報告。同時，退休金儀表板計畫（The Pensions Dashboard project）會繼續營運，這可視為是CMA在開放金融的一個代表作。未來這個計畫可能擴大到那些非開放銀行主要範圍的項目，如現金存款帳戶和抵押貸款的資訊。未來考慮納入汽車保險，讓保險公司可透過遠距追蹤消費者開車的情況，來決定保額。

Q.未來還有哪些開放銀行的計畫？

英國開放銀行計畫將於明年結束，我們希望可以將過去三年累積的專業知識和資源，運用到開放金融上。文⊙王宏仁

「Open Banking是數位轉型而非數位化的議題，銀行必須要徹頭徹尾改變商業思維。」凱基銀行創新科技金融處資深副總經理周郭傑點出，銀行要擁抱開放銀行應有的關鍵心態。

作為臺灣開放銀行的先行者，凱基銀行早在2017年11月，即推出開放API服務「KGI inside」，也是臺灣第一家推出開放式API的銀行。

至今，凱基銀行已經與22家業者合作，進行API串接，開放出凱基自家的金融服務，甚至是以每個月3～4家業者合作的進度，持續成長。而在去年6月，凱基更上線了API管理平臺（APIM），來管理自家的API。

Bank 4.0新趨勢中強調，銀行的存在感式微，取而代之的是無所不在的金融服務，直接走進消費者的生活場域，來提供金融服務。但，周郭傑觀察，仍有許多銀行管理階層，不相信銀行能轉型，主因是「他們不相信銀行會消失。」

他解釋，現在銀行的管理階層，長年在法令、主管機關的監管下，也在內部種種的業務流程、內稽內控、自律規範上，累積了太豐富的經驗，他們非常清楚，一項金融新業務，需要面臨哪些問題，需要衝撞哪些限制。

但是銀行與金融業務是特許行業，管理上特別嚴格。這群管理階層心中認定，這種體制未來也不會改變。

所以，即便外界震天價響地談論「銀行會消失」，周郭傑提到，這群人心裡其實並不認同。因為，他們不相信，在金融業這麼嚴格的法令規範下，幾年內，科技業者有辦法進來，或是，等到科技業者可以進場時，付出的成本代價也跟銀行一樣高，他們一點都不擔心來自科技業的挑戰，也就不覺得銀行有轉型的必要性和迫切性。

周郭傑指出，這群人誤把無所不在金融服務背後的銀行「隱形」概念，與銀行「消失」畫上了等號。「必須把消失跟隱形的等號劃掉」，這是銀行思考Bank 4.0的第一個關鍵。「銀行隱形真正的意思是它還存在，只是我們看不到，人們依然依賴它所提供的金融服務。」

儘管科技業或許不會變成百分之百的金融業，但由這些科技業者所創造的數位平臺，越來越成為一般民眾數位生活最主要的場域。周郭傑認為，金融服務將隱身在這些科技業者所創造的平臺上。這是他認為，金融業無所不在後，最可能的狀況。

在過程中，科技業會變成消費者跟銀行之間最大的活動平臺，消費者可已經想像得到，未來的食衣住行都能透過數位平臺來採取實質的行動，而金融服務必須能進入這些平臺，才能融入生活場景。「要做到這件事情，金融業者就必須把它的產品數位化，且破碎化，透過Open API將金融服務，串接到科技業者的數位平臺上。」周郭傑指出。

在臺灣開放銀行三階段中，第一階段「公開資料查詢」已正式上路了，銀行公會也正在研擬第二階段「消費者資訊查詢」的自律規範內容。金管會主委顧立雄，甫在開放API平臺上線記者會中，揭露二、三階段規範的5大考量重點，包括了TSP業者管理方式、客戶權益保障、爭議處理、損害賠償機制及資訊安全標準等。

在TSP業者管理的部分，周郭傑認為，規範TSP業者，是從銀行的角度出發，還是站在培養TSP產業發展的角度出發？不只從API供應端，也就是銀行來制定標準，API的使用端，也就是TSP業者的聲音，也要同時帶進來。

他建議，應該要運用金融監理沙盒的實驗機制，讓TSP業者進行試點，透過這樣的機制，增加TSP業者串接不同種類API的機會，而在沙盒進行得不錯的，則可納入新的TSP管理辦法，讓規範漸漸趨於完整。

周郭傑認為，開放銀行必須要有更大的目標，大家想像中的TSP，在臺灣可能有上萬家，可提供的API多達數萬支，應該要在這樣的環境中，設想如何一步步來推動TSP管理。他認為，應考慮TSP業者的需求與各自現況，並依據它所使用的API種類與方式，採取分級管理。

甚至，周郭傑建議，「得把TSP視為一個產業來發展」，先肯定TSP業者的價值，看重他們的創新與速度，對改變金融產業的參考意義，接著就是透過Open API，將TSP所需的原物料，以高度數位化、便利、低門檻的方式，讓TSP可以盡快連結，創造出新的第三方產品服務。「若沒有考慮到這些發展，開放銀行最後恐怕流於形式而已」。

今年3月，財金公司成立了開放API研究暨應用發展委員會，並在委員會底下又成立開放API研究諮詢小組，同時往下設立技術分組與資安分組，共同制訂與推動開放API標準。

銀行圈對API並不陌生，早就用於串連各種合作夥伴。但是，「現有API沒有一套共通的規格和語言。」國泰世華銀行資訊總管理處副總經理王志峰特別強調。這也是作為開放API研究諮詢小組召集人的他，認為各家銀行在與第三方業者合作時，最大的問題。

由王志峰與15家銀行的代表，正站在臺灣開放銀行之路的第一線，一起為這個痛點找答案。 而在財金公司訂定API標準的過程中，每每會透過開放API研究諮詢小組會議，先與小組的銀行成員討論，希望找出可統一所有銀行的作法，也希望可以有更大的應用。

所以，從第一階段的開放API技術標準，就參考了國際Open API Initiative組織的OpenAPI Specification（OAS）作為Open API技術規格的一致性標準，並遵循OAS規範的RESTful API定義，使API互通介面不受程式語言限定。

除了參考國際標準，在API設計上，王志峰表示，國泰世華更是提供了自家內部開發API的實務經驗和標準，作為標準訂定時的參考。像是國泰世華已採用了可幫助開發人員設計、建構、記錄和使用RESTful Web服務的Swagger標準，後來也納入第一階段的標準中。

使用同一套Swagger框架來設計API，不論在API的功能規格、參數設計都有一套規範，任何一家TSP，不需要重新了解每一家銀行的API設計方式和定義就能開始串接，可以加快開發時間。甚至，財金還加上了API版本規範，更方便用來維護不同版本的API。

這意味著，以後第三方業者與銀行API的串接，會有一套更明確的共通介接作業方式，而不只是大方向的規範。

另一個好處，王志峰指出，這次等於統整了銀行彼此資料交換和串接的標準，銀行間彼此也可以快速透過Swagger設計的API，與其他人快速串接。等於是，所有銀行開發者間也有了一套共通的API溝通語言。

目前，在第一階段公開資料查詢API的支援上，已有API介接經驗的銀行，像是中信、台新、凱基、國泰世華都迅速完成支援，其他銀行也很快就跟上。但王志峰認為，第二階段API的導入難度會更高，不是所有銀行都能跟得上，他希望，可以透過更詳細的API訂定參考與經驗交流，協助小規模的銀行，提高對外API介接的能力。

資安標準上也會朝國際主流標準靠攏，舉例來說，到了第二、第三階段會採用資安要求更高的身分驗證機制，目前偏向採用國際常見的OAuth 2.0。王志峰解釋，原因是，接下來會涉及使用者資料，其中又分為身分證號碼（IDN）或是機敏性資料，像是信用卡卡號，就得考慮到要有加解密的作法。目前，已有銀行開始進行OAuth 2.0的串接驗證，國泰世華就是其中一家。王志峰提到，國泰會慢慢導入這樣的作法，讓自家金融服務能朝國際主流標準前進，他相信，各家銀行也應如此。

王志峰提到，Open Banking的精神，得回歸到資料所有權是客戶的觀點，銀行得基於客戶同意下，以安全的方式提供出客戶資料。他也認為，當TSP業者提供的服務備受客戶青睞時，客戶會選擇有與TSP合作的銀行，優先使用其金融服務。這也是國泰積極擁抱Open Banking的原因之一，「跟得上的銀行，比較不會在數位轉型風潮中被市場淘汰。」王志峰強調。

國泰也認為，Open Banking對銀行與TSP來說，應該是互惠關係。不僅是銀行單方面提供資料，銀行是各家TSP業者合作的集中處，也可以趁機吸收TSP的創新策略與服務。若以這角度來看，銀行本身的角色，不見得會邊緣化。

甚至，臺灣已有像聯合徵信中心、電子發票整合服務平臺，以及許多戶役政單位，國泰認為，這些都是國外沒有的機構或角色，是發展Open Banking的基礎建設，若他們未來也能加入開放的行列，臺灣在開放銀行之路會走得更快。

打造技術與服務中臺，分流核心系統交易量

儘管目前Open Banking的話題焦點是Open API、TSP業者管理等，但若要能徹底落實開放API，對銀行來說，還有一個更大的考驗，就是自身平臺系統的體質是否健全。

Open API要做得好，王志峰認為，銀行後面支援的平臺沒有做好準備，其實會很辛苦。所以，國泰世華第一個要解決的，就是資訊架構問題。過往，隨著各種業務需求的增加，直接在銀行核心系統不斷擴充功能，導致核心系統越來越龐大，但是，這些業務可能不見得是銀行的核心業務。王志峰提到，核心系統每天高達9成工作量都只是進行查詢，只有1成以下才是真正的交易。當銀行系統要支援不可預期的Open API需求時，「最大的瓶頸，還是銀行後臺核心系統的承載力。」

為了解決這個問題，國泰的作法是，將查詢或批次能處理的系統或服務轉移到中臺，核心系統只保留交易功能，藉此來分流，以提高核心系統的承載容量，並透過銀行中臺的橫向整合，「讓核心系統回歸它原來的功能」他強調。

甚至，國泰世華內部還特別定義出技術中臺和服務中臺的資訊架構概念，成立了一個中臺發展部，負責銀行中臺架構與服務的設計。王志峰提到，國泰內部IT，人人都能到這個部門學習中臺的開發方式與技能，隨著越來越多IT成員熟悉這些能力，就能發揮出中臺的綜效，這也是國泰轉型計畫的一部分。

打造中臺微服務與私有雲平臺，強化IT體質擁抱Open Banking

國泰從去年就開始打造銀行中臺微服務的原因，同時也一併引進了私有雲容器化平臺，也將銀行內部各系統的介接統一採用API，以利彈性縮放平臺上服務所需的運算資源。而銀行中臺也可以進行服務整合，同樣以API對外提供服務給第三方。

國泰世華銀行中台發展部經理黃一峯解釋，一般來說，支付API每秒可提供300次交易（TPS）就算很好的效能了，而國泰世華幾年前，開始協助合作通路錢包發展行動支付所需的API平臺，系統承載量可以達到每秒500筆以上（TPS）的交易，不只當時，也是目前業界最高者。

但，國泰沒有因此而停下腳步，還大動作升級IT架構來強化體質，國泰世華銀行中台發展部經理鄭正略表示，去年中，國泰開始導入微服務架構，來打造中台微服務，進一步將銀行的大型系統，拆解成一支支小型服務，更容易快速伸縮這些服務的規模。

正導入APIM管理自家API

目前，國泰也正在導入API管理平臺 （API Management，APIM），來管理自家的API。王志峰提到，因為國泰除了60多支的對外API，連銀行內部各系統介接，現在也都統一採用API進行跨系統呼叫，總數高達750多支API。「這麼做的原因是，希望內部系統的介接標準一致，即便哪天得換掉某一套系統，API串接仍保持一致，其他系統不用特別修改寫法就能繼續呼叫。」

架構調整後，王志峰透露，若從國泰內部系統來呼叫中臺的服務API，光是帳單服務現在可以提供到每秒4,000次呼叫的能力。他提到，這代表，國泰技術中臺的承載力提升了，而且容量可以橫向擴充，這樣的能力不只是這一支帳單服務獨有，其他服務也都可以具備。

這樣的架構，讓國泰更有能力將更多服務集中到中臺，目前，王志峰提到，國泰會優先將客戶在數位通路最需要的服務，集中到中臺上，讓前臺的數位通路，例如App，或是與其他服務介接時，能以最快的速度對外提供服務。未來，國泰將繼續將更多核心系統的服務，遷移到現在的中臺架構上，最後目標是，核心系統只負責單純的存、匯功能。

中國信託是早期力擁銀行API應用的先行者之一。早在2002年，中信就開始推行網路收單服務，將銀行服務用API串接的方式，與各業者展開合作。而隨著社群媒體的興起，中國信託開始將這概念延伸到客戶端，透過API與LINE BC（Business Connect）串接，提供中信客戶帳戶通知的服務，比如朋友之間的轉帳，轉帳成功後，收款方就能在LINE看到即時入帳通知。

近年，中信更大力推動Account Link（帳號連結扣款機制）整合，讓顧客將中信帳戶綁定到第三方支付或電子支付業者App後，直接在這些App進行支付或P2P轉帳。

「串接API這件事，不管從業務需求或客戶需求角度，中國信託早就發動了，大量運用到企業端與消費者端，來將中信的業務延伸出去。」中國信託金控數位金融處處長蘇美勳緩緩道出擁抱API背後的戰略思考。

她認為，關鍵考量是，服務必須真正帶來客戶體驗的具體改變，或是業務效益的創造。作為臺灣金融業Open API先行者的中國信託，早已累積多年經驗，清楚知道，推出什麼樣的API服務，客戶才會有感。「中信會從客戶角度篩選，並優先聚焦在這些服務的內容。」

在臺灣這波開放銀行政策，蘇美勳表示，中信在配合銀行公會的開放API策略上，會有自己的業務重點，不是全面性配合或全面性開放。中國信託會有一套自己的API策略。

所以，她坦言，在第一階段「公開資料查詢」，中信沒有開放很多API。中信評估後判斷，這類API如查詢API，可能對客戶體驗的差異不大，因此才將這類API的優先順序往後擺。「還是得從客戶角度來進行篩選。」蘇美勳強調。

中信Open API戰略關鍵，靠三原則慎選合作夥伴

而中信在API策略上，從其挑選合作夥伴的三大原則，不難看出決策的審慎態度。第一個原則是從市場趨勢為出發點，以中國信託投入研究的區塊鏈技術來說，中信長時間觀察市場趨勢之後發現，近兩三年，區塊鏈技術在金融的應用，已有幾個重要賽道成形，包括貿易融資、供應鏈融資、數位資產交易等主題，這將是金融產業未來重要的賽道，中信後續也會有相對應的API釋出。

中信第二個原則是「大大聯手」策略，蘇美勳強調這是關鍵策略。合作夥伴的規模、能力、受信賴的程度，都是考量點，更重要的是，合作夥伴的服務能否滿足中信大部分客戶的需求，以及對客戶帶來的影響得夠大。

第三個原則是，合作後回頭檢視API的客戶滿意度和交易量。對於客戶端的服務，蘇美勳舉例，像與第三方支付或電子支付業者合作Account Link服務，至今推出超過1年，數據顯示這些有與業者綁定帳戶的中信客戶，其存款基數、轉帳筆數、消費金額相較過去都提高了，甚至還比沒有使用此服務的客戶更高。

開放API，先了解客戶端與企業端真正需求

「這些數據顛覆了我們原有的想像。」蘇美勳眼神發光笑著說。她回憶，當初推出Account Link服務之前，中信內部曾有兩大猶豫。一是不確定客戶是否願意把他的帳戶資訊，綁定在第三方支付或電子支付業者？第二個疑慮是，客戶綁定中信帳戶到業者端後，原本在中信的存款，會不會因此而外流？

好在，訪談多位年輕客戶後，再次確認年輕族群對這類服務的需求量很大，加上政府積極推動行動支付產業，於是，中信看好其未來的市場發展，決定積極迎戰。後續的成果證明了中信的眼光，蘇美勳表示，對中信與合作方來說，此項業務都是雙贏。

而在企業端的服務上，中信也有自己關注的業務重點。在金融總會設立的金融科技創新園區，中信是園區裡的API供應商之一，在數位沙盒環境中，釋出了一批金融API，讓FinTech新創可以進行創新應用的實證，甚至是商轉。

中信更逐一訪談入駐金融科技創新園區的每一家新創，詢問他們需要什麼樣的金融API。最後發現，新創業者的需求大多與金流有關，於是，中信決定在數位沙盒開放出三大類API，一是紅利點數API，二是帳戶扣款API，三是區塊鏈金流API。蘇美勳提到，中信內部會研發區塊鏈金流相關產品，源自以區塊鏈FinTech業者的需求訪談，他們的服務拼圖普遍缺少金流那一片，需要有銀行願意在區塊鏈上扮演金流監督的角色。

已導入API管理平臺，正準備走向微服務與容器化

考慮到長期需求，中國信託IT更早在2017年，就率先導入了Axway的API管理平臺 （API Management，APIM），一來將API開發標準化，也透過集中化平臺來管理API。蘇美勳指出，在API管理平臺上，目前有超過60支在線上提供服務的API。光是社群上通知類API的用量，全年已破億次。

在API管理上，中信訂定了一套API開發的規範，不同團隊都得遵循同一套標準模式來開發API，就像工廠產線一樣，讓產出的API品質都能夠一致。中信IT與數金處的協作也採用敏捷開發，可快速迭代開發新功能回應市場需求，同時也確保品質，兼顧銀行系統的穩定。中信指出，現在開發一支API只需10天就能完成。

從去年，中信IT也歸納出不同業務之間的API共同需求，目前正在執行一個工程，試著將共用性質高的API獨立出來，變成一套可跨業務共用的基礎API，只有遇到業務特性不同之處，再來開發各自需要的API。

而為了因應API爆量需求，中信IT還有一個中信雲計畫，目標是讓自家基礎環境建設可像公有雲業者一樣，可以按需求彈性擴充。中信更透露，目前他們正準備走向微服務與容器化，希望可更進一步，做到快速彈性伸縮的程度。「即便，API用量無法預測，銀行能做得就是先準備好，才有能力去應付。」

第二階段應採取分級式管理制度

2年前，中信建置API管理平臺目的，就是統一管理原本分散各處的API，蘇美勳透露，中信原本要進一步開始API分類控管，細分不同的風險控管。不過，臺灣金融市場突然吹起的這一股開放API風潮，讓中信不得不放慢原本的腳步，來配合銀行公會的相關規範。

蘇美勳認為，目前最關鍵的議題是，第二階段「消費者資料查詢」，因涉及消費者個資，銀行與TSP業者之間的權利義務該如何釐清？以及TSP業者必須做到類銀行的資安控管，會到何種程度？銀行之間又要如何配合？她提到，如何拿捏中間的分寸，是此階段規範細節訂定的攻防之處。

舉例來說，中信指出，銀行與TSP業者合作的責任歸屬釐清，在第二階段的重要性。假設第三方業者外洩資料，過去作法中，中信透過合約由第三方賠付，但在銀行公會訂定的自律規範中，現在則要求銀行代償（先賠付），再來釐清責任，這對銀行來說，兩者的風險考量截然不同。此外，中信過去從來都沒有將客戶資訊交出去的經驗，為了因應第二階段消費者資料查詢開放帶來的新風險，目前中信也正在設計新的機制，因應風險等級的增加。

「得對TSP業者所提供的服務內容，就服務內容產生的風險等級，分層次訂定要求，不管是分級管理、分級風險控管，不同的資安相關標準，都得要有配套。」蘇美勳建議，應採取分級式管理制度。她認為，如果一體適用，用同樣嚴格的高規標準來要求TSP業者，反而會造成大家的困擾。原因是API串接在銀行現有業務合作已行之有年，「這些合作業者並非電支電票業者，難道也要納入同樣高規格的要求？」不過，她也認同，部分需要提供客戶帳戶資訊，比如代登代爬的TSP業者，甚至可能要適用比電支電票業者更高規格的要求。

在銀行開放API這條路上，先行的中國信託，走得很遠了，甚至設計出無涉個資的金融交易API，儘管慢下腳步來與產業同調，中信還是堅持自己一貫的策略，以顧客需求優先的API發展戰略。

開放銀行（Open Banking）這股風潮，從歐洲吹向了全球，臺灣也在今年跟上國際腳步，採取香港、新加坡模式，以自律自願作法，由銀行與第三方服務公司（TSP）合作方式推動，由銀行開放出API給TSP業者串接，共享金融機構的數據資料，也讓金融服務可以拓展到多元層面。

而台新銀行早在2017年，在歐盟PSD2、英國Open Banking計畫推行之際，就嗅到了這波趨勢，遲早會吹進臺灣，開始著手研究。台新金控資訊長孫一仕提到，當時台新內部研究開放Open API，考慮了兩種型態，一種是走英國Open Banking的模式，由政府主導，所有銀行一體適用的API；另一種型態，是藉由API形式，以開放合作的心態來做這件事。

在「開放銀行」一詞中，孫一仕更聚焦的是「開放」這件事，他認為，銀行願不願意把自家金融服務，開放給客戶或合作夥伴的心態，才是關鍵。他也強調，所有消費者的資料，都屬於消費者所有，這個「消費者資料所有權」的概念，不只銀行，電商、電信乃至各行各業都是一樣適用。

開放銀行將加速競合，資料分析能力將是銀行業另一競逐戰場

「Open Banking會帶來新契機，刺激銀行更努力找出顧客需要的服務，也會形成競合的時代。」孫一仕提到，臺灣開放銀行的進展，一旦進入第二階段的消費者資料查詢之後，理論上，只要銀行之間合意，台新銀行也能拿到國泰世華銀行、中國信託銀行、北富銀等銀行的資料，同樣地，其他銀行也能拿到台新銀行的資料。

當銀行都拿到了同樣的資料，這時，銀行要如何找出不可或缺的客戶價值，來提高客戶對銀行的黏著度？孫一仕認為：「當握有同樣的資料，比得就不是資料量多寡，而是分析能力。這將成為銀行業另一個新戰場，分析能力會是決勝關鍵。台新有信心在這種型態的競爭中取勝。」他自信地說。

不止銀行之間的競合，TSP業者與銀行的關係也是競合，某種程度來說，銀行本身也成了一種TSP，孫一仕表示，人人都得各憑本事，基於對客戶的了解，快速組合出客戶想要的服務與價值，「功力與速度，將會是致勝的兩大要素。」

靠Open API實現金融場景化，台新的生態圈戰略

在金融業浸淫多年，孫一仕觀察到，臺灣金融業的服務內容上，各家的戰法跟領域都非常接近，焦點無非是生態圈、情境銀行等。但他認為，將來的金融業服務，不會只從金融業掌控的管道提供給顧客，還需要創造非銀行管道，將金融服務傳遞到顧客的情境。「把金融服務無縫嵌入顧客的生活消費場景，這是未來大家競逐的方向，比誰做得快、好。」

而Open API對台新的生態圈戰略，孫一仕提到，是與合作夥伴合作，為共同客戶提供更好的服務，讓雙方共同服務到每一位客戶，「這樣B＋B2C的商業模式，是台新一以貫之的目標。」

早在去年11月底，台新銀行即與跨境購物網站Buy日貨合作，透過串接身分認證API，讓台新用戶可使用台新網銀的帳號身分，進到網站商城購物，不用再註冊購物網站帳號。同時，台新銀行也透過串接紅利點數兌換API，讓台新信用卡卡友，能在此購物網站使用信用卡紅利點數折抵消費。

不止如此，孫一仕提到，目前台新已開放出API，可提供支付相關服務給合作夥伴。未來，也會持續與不同TSP探索合作的模式，提供新服務給彼此的共同客戶。不過，他坦言，銀行要找到能夠串通的合作夥伴，以及能串通的場景，是要花心思的，甚至，技術更是一大挑戰。

台新今年6月上架APIM，採用微服務與容器架構

在技術層面，台新銀行也在2018年初，啟動了API管理平臺（API Management，APIM）專案，今年上半年進行建置，並且在6月就正式上線了。孫一仕解釋，他們預見未來API數量會越來越多，就決定自行建置APIM。

目前，在台新API管理平臺上，除了有台新原有API之外，第二組上架的API，就是台新在財金公司「開放API開發者平臺」上釋出的16支API。孫一仕表示，未來，不管是財金版的Open API，或是台新開放給合作夥伴的API，只要是台新對外的API，都會集中到APIM來管理，台新也會依特定的應用需求，持續擴充新API。

為了因應Open API可能帶來的爆量需求，台新在一開始建置API管理平臺時，就決定採用微服務（Microservices）與容器（Container）這類可高度擴展性的IT架構。

雖然台新已研究微服務2～3年之久，只有遇到特定目的時才導入，例如像APIM這類有擴展需求的新系統，台新才採用微服務與容器的新架構，或日後舊系統要大量擴充需求時，也考慮逐步導入。

「不為了微服務而微服務」，孫一仕認為，IT必須謹慎挑選適當的時機與應用，希望IT投資能反映到業務收益上，這是IT應該要負的責任。

開放銀行下階段，解決個資法與身份驗證問題是兩大關鍵

台新銀行作為財金公司開放API研究諮詢小組成員之一，在開放銀行後續第二階段、第三階段的推動中，孫一仕觀察，銀行要如何與TSP共創服務？第二階段的發展是關鍵。他點出目前法規面有兩大問題需解決，一個是個人資料保護法，另一道關卡則是身分驗證。

不同於過往銀行與第三方業者的合作大多是操作面整合，例如在顧客登入電商平臺後，直接在購買過程中掃描QR Code就可以付款。孫一仕表示，一旦要加值分析，需要資料，就會涉及個資法，「這是目前大家公認有點棘手的地方」，他說。

他也認為，如何在確保客戶權益的狀況下，與客戶建立良好溝通，確保資料只用在特定用途，並讓此特定用途對客戶帶來好處？如何找出一個好的價值，讓客戶願意提供資料？都會是法規面後續要解決的問題。

法規面的另一問題是身分驗證，孫一仕指出，當銀行與TSP業者合作，來到第二階段「消費者資訊查詢」，顧客透過TSP進入台新銀行取得自己帳戶的資料時，銀行如何確定，這個TSP存取行為來自顧客本人的授權？他透露，目前開放API研究諮詢小組中的技術小組，正在努力討論第二、第三階段身分驗證的機制，要透過電子化方式，解決第三方與銀行之間的身分認證。

不過，他個人則認為，得有一點程度的公權力，也就是需有一定法律效力或認可，才有辦法做到這件事。若能解決身分驗證的問題，在法律層面獲得客戶同意後，就會是合法的資料傳遞，就沒有違反個資法。

第二階段得先突破個資與身分認證問題，才能往挑戰更高的第三階段「交易面資訊」前進，他說。

此外，目前銀行與TSP合作，因最終責任還是在銀行，所以銀行必須去審核TSP的資訊安全。但，孫一仕坦言，如何審核TSP業者也有兩項課題，一是銀行有沒有這個能力？TSP審核需要成本，可能會成為小銀行的門檻。再者，對TSP來說，不可能只跟一家銀行合作串接API，他們也不可能一天到晚忙著因應來自不同銀行的資安審核。

「天平兩端必須平衡，不能讓TSP端的壓力太重，銀行端也是。得有公信力的單位來做這件事。」孫一仕認為，對銀行來說，還是得負起追蹤責任，但若能在時間、成本、技術上，透過一個銀行、TSP雙方都認可的機構來執行，大家前進的速度會更快。

「現在的消費者，有很大的自主權。」華南銀行副總經理許柏林坦言，連他自己都近20年沒有親自到銀行臨櫃提款，直接使用全臺到處都有的ATM或直接透過線上網銀轉帳。在數位金融的新世界，消費者不一定非要找知名銀行，或分行數量多的銀行。所以，「銀行得從四個角度來思考數位轉型，包括了通路、產品、行銷和異業結盟，華南也從這四項來思考數位通路的策略。」

例如在通路面，銀行得考慮如何更方便，產品上則是要不斷追求更好，行銷面則著重如何跟顧客對話，而最後一項異業結盟，關鍵就是得擁抱Open Banking趨勢。

尤其在數位金融來臨的浪潮下，銀行通路的改變最明顯。，根據華南銀行自己的數據，2016年底，顧客在ATM上的交易量遠大於網銀，手機行動銀行的交易量，更是遠遠落後於網路銀行和ATM，但是到了2017年第三季，個人行動銀行交易規模，開始超越ATM，2018年第一季更是出現黃金交叉，華南行動銀行交易量不只超越了網路銀行持續成長，網銀的用量也在這階段開始下滑。

他解釋，以前傳統銀行帳戶的優勢正是分行的通路，顧客所有活動大多得到銀行櫃臺，分行數量決定了顧客的方便性，但是未來的通路不是實體分行，「如何讓顧客感受到便利的關鍵，取決於銀行可以到多少地方來提供服務。」

尤其未來即將來臨的Bank 4.0趨勢是，金融服務無所不在，銀行希望顧客的所有的活動，都可以跟銀行往來，「要和各種生態圈串接的關鍵就是API。」許柏林指出。

過去，華南銀行已推出不少專用API來和不同的顧客串接，包括了消費扣款業務、全國繳費業務、微信支付業務、基金投資業務、或是與證券業串接的餘額、圈存、明細等，另外還有線上授權約定、帳單等多種API。不只與其他金融業者串接，還包括零售業者、便利商店、電信業者等。

許柏林指出，銀行擁有的顧客資料其實只有片段，因為金流與資訊流的運作常常是斷開的形式，但是，若透過API異業串接後，對銀行而言，有一個好處是，可以掌握更多顧客的資訊。而且串接的合作廠商越多，顧客更會覺得這家銀行就越方便。

另外，他認為，這些現有API所串接的應用，大多是集中式、單點式的應用，到了開放銀行之後，Open API可以發展成全面性的應用。「要走入金融無所不在的境界，得透過標準、安全的方式，來跟各行各業連結。」

不過，現在銀行的API欠缺了一套標準，所以，他坦言，銀行只能自己挑選大型、安全措施完善的TSP業者來串接。在API技術上，許柏林評估，這不是最難的事，法規面才是最大的挑戰，尤其目前臺灣在開放銀行的法規要求上不夠明確，還沒有一套清楚的遊戲規則可遵循。

舉例來說，目前銀行將資料提供給TSP業者之後，銀行跟TSP的關係該如何界定？許柏林指出，若是委外關係，銀行得負責TSP業者的資安水準跟資料管理。未來一旦發生個資外洩事件，消費者先對銀行求償，再由銀行與TSP分攤。所以，過去的作法上，銀行先對有意想要串接API的業者進行資格篩選，「只有具備足夠資安能力的大型業者才能獲得合作。」他強調。

發展Open API上，華南的策略是務實挑選釋出的API，許柏林用抓粽子頭來形容華南的策略，抓住一個主要環節，就能帶出後續一大串機會的作法。例如銀行薪資帳戶、證券帳戶，都是有機會發展成一整套衍生服務的粽子頭。或像是與大型企業的數位服務串連，就有機會進一步串連到這些大企業的客群，發展出類似供應鏈金融的服務。

開放銀行技術面和法規面仍有不少挑戰待克服

在技術面目前最大的挑戰是「客戶確認」。過去客戶會親自到分行櫃臺，透過真人直接確認，而現在則是透過第三方業者TSP來告訴銀行，他們獲得了客戶的授權。可是，許柏林表示：「技術上，如何知道這樣的授權有效、合理？」這是第二階段要解決的技術課題。

尤其在Open API上，更大的挑戰是異業整合，在法規上還有幾個議題需要處理。許柏林指出，第一，客戶同意的表示，如何合規？而且，客戶確認要如何達到有效性？據他觀察新加坡或澳洲的作法，主管機關訂定了一套「同意表示」的明確規範，就有助於業者採用。

另一個法規議題也是多數銀行都在意的責任分攤問題。發生資料外洩事件後，誰負責？責任如何分攤？

許柏林坦言，銀行沒辦法單靠委外關係或契約，要求對方做到像銀行內部系統那樣等級的安全設計，過去的作法是，除了篩選合作對象之外，也會在契約上約定各自負責，顧客資料離開銀行後的責任，各自分攤。

「當開放銀行將API串接的資格，放寬到一般客戶跟TSP，銀行風險可能會大大的提高。」就算是找來會計師對TSP進行查核，也很難控制銀行得面對的風險。例如螢幕拍照外洩的防範難度就很高。

準備改造十年IT老架構，開始打造微服務中臺

不過，與其等到法規面完善了才開始準備，華南銀行自己早就先開始因應未來可能的Open Banking應用需求，兩個改善自身IT體質的作法，一是擁抱雲端技術，第二是調整銀行核心業務的系統架構。目前華南也計畫擁抱微服務架構，幾個月前，展開了銀行中臺系統的大改造。

許柏林比喻，過去的應用系統是大型單體應用，要跨大服務容量，得複製全套系統來建立新主機才行，但是改用微服務架構後，可以針對其中一項功能性服務來進行擴充。

就像是過去為了提高產能，得複製整條生產線才行，可是一條生產線上有不同的裝配工作、組裝任務或運輸任務，若只是需要大量的組裝任務，在微服務的新架構下，只需要增加組裝部門的人手就好，不用整條生產線複製一套。

同樣的概念，可以運用到金融服務上，如果今天有一項活動，需要大量的轉帳交易，就可以直接擴充負責轉帳交易的那一組微服務，來滿足臨時暴增的需求。不過，華南銀行還需要一段時間，才能完成這個中臺架構大改造。但是，許柏林認為，數位金融的時代來了，各家銀行也都逐漸走向這種可以因應不同需求的新架構。尤其，「前端需求越來越多元，不同時間點的需求也不同，銀行需要一套更容易調度資源的新架構。」

數位金融和IT共組敏捷團隊，不用最新技術但求應用快速上市

在組織面上，華南銀行從400人的IT團隊中，指派一個百人團隊來配合數金部門的開發需求，Open API就是這個數金和IT聯隊共同負責的任務之一。另外，華南銀行也開始擁抱敏捷開發，「尤其是面對消費者、大環境變動快的數金部門，全面擁抱敏捷。」許柏林指出，華南數金部門目前約40人，採取1 比1的作法，搭配另一組40人的IT團隊，組成一個80人的敏捷團隊，另有60人負責基礎架構的維運。

華南在新技術的採用腳步上，「不一定在第一時間擁抱新科技，而是先觀察技術的成熟性，有實際應用出現後，才會考慮。」但是，許柏林的秘訣是「技術上等待成熟技術，而應用就要走在前面。」

所以，對許柏林旗下的數金團隊而言，他們不是在技術上求最快，而要在金融應用上比速度，找出對的應用和別人還沒想到的應用。「這就是數金業務團隊真正的價值，要有執行力和規畫力，從應變的角度來思考。」

「有些事，做了不一定成功，只是有點機會，但你不做，會損失更多。」許柏林強調，Open Banking浪潮就是這樣的趨勢，若銀行不願意合作，或抵制這個趨勢，在客戶心中的影響力，就會越來越小。

搭上臺灣開放銀行的風潮，在眾家與銀行合作的TSP業者中，跨行記帳App「麻布記帳Moneybook」大概是第一階段中，表現最亮眼的FinTech新創。

「透過財金的開放API平臺，麻布記帳在3個月內，就完成與20家銀行的簽約和API串連。過去，光是一家就得花上8個月時間才能談妥。」麻布記帳執行長陳振榮點出，Open Banking帶來的實質效益。

其實，麻布記帳是個九死一生的產品，在2014年初上線服務時，因可替客戶代登入銀行帳戶，而遭到銀行抵制，本來就要熄燈停業，卻在臉書粉絲頁與用戶告別時，引起廣大迴響，甚至有用戶願意付費來支持這個產品繼續營運，也讓當時的陳振榮，萌生接下麻布記帳的念頭。

然而，2017年10月，麻布記帳正式由陳振榮帶領的新團隊接手。不過，接手後才是挑戰的開始，除了產品打掉重練，所需的技術與資安規格之外，對法規的認識，是陳振榮認為遠比產品本身，難度更高的關鍵。

因為，陳振榮認為，FinTech這領域，其實是金融特許行業，它的遊戲規則跟跟網路產業是不一樣的，不能隨地踩線。他回憶，團隊進來這領域時，其實遇到非常多的「洗禮」。

他解釋，由於銀行的組織非常龐大，可能一個決策案要跨部門才能完成，「我們是一層一層從銀行的底，不斷往上溝通。」而除了與銀行溝通的過程中，得經過重重關卡，到了真正可以談商業合作時，銀行想到的第一件事情，就是資訊安全、消費者保護、風險控管、KYC。

「反覆地溝通直到銀行有意願合作，甚至資安補強到銀行覺得安全了，但到最後，銀行還是選擇不跟FinTech新創合作。」陳振榮坦言，與每一家想要合作的銀行這樣來回溝通的日子，麻布記帳持續了半年之久。

​

麻布記帳展示開放銀行第一階段成果之一，透過串接API的方式，與20家銀行合作取得各家完整外幣匯率，讓麻布記帳的用戶有兌換外幣需求時，無需自行一一查詢，在同一介面即可獲得最佳換匯資訊。（圖片來源／麻布記帳）

半年來與銀行溝通不順，轉而從主管機關著手才找對關鍵點

後來，麻布記帳發現，最重要的問題，原來是來自主管機關的態度。「銀行的心理障礙，來自於主管機關。」因為涉及風險，主管機關說可以做，銀行才敢做。因此，麻布記帳決定開啟與金融業主管機關的對話之窗，從法規面進行溝通。

一開始，麻布記帳的作法是，撥電話到銀行局詢問。後來，才發現原來金管會在金融科技園區FinTechSpace，有開放一個「監理門診」機制，每周都會有官方的監理人員，進到園區提供駐點諮詢服務，讓新創業者在開創新的金融服務過程時，了解會遇上哪些現行法規的侷限，又要如何配合法規進行修正，適應監理框架，讓產業能加速發展。「這是FinTech新創過去難以碰觸到的資源。」陳振榮提到，因為，我們不是銀行業者也不是金融機構，其實並不歸金管會管轄。

2019年2月20日，陳振榮記得特別清楚，這是他們展開的第一次監理門診，「終於可以跟主管機關溝通了！」但，第一次的會診的過程，並不如麻布記帳所想像，因為過去並沒有與主管機關溝通過的經驗，以致於在一開始，根本不知道要如何提出對的問題。

陳振榮舉例，如果FinTech新創是直接問主管機關，做某項服務到底有沒有風險，對消費者保護會不會有疑慮等問題，其實，主管機關是沒辦法從這些問題中，去評估你在提供此服務之後，消費者的權益是否會遭受到損害，或者是在資訊安全上，主管機關也不會了解你的資安做得如何，所以，FinTech新創得要把資安的風險，以及採取的解法告訴主管機關，他們才能回復，你可能有哪些部份需要加強，或是得符合哪一條法規等。

「必須在現有法規的限制下，找出可行的道路，若是有國外可運行的案例可以向主管機關說明，會更有說服力。」必須在完全準備好的狀態進行溝通，也是麻布記帳在監理門診的過程中，找到與金融業主管機關對話的語言。

而在臺灣開放銀行邁入里程碑的這刻，麻布記帳也展示了第一階段「公開資訊查詢」的成果。陳振榮提到，過去，光是洽談一家就得花上8個月的時間，現在，透過財金的開放API平臺，麻布記帳只花了3個月就完成與20家銀行的API介接，可提供消費者存款利率、匯率等資訊，來提供多達20家銀行的金融商品比較。

財金開放API平臺上線，但第三方服務業者仍要一一與每家銀行簽約

財金先前曾對TSP業者披露，第一階段已上架的API，包括了四大類，包括存款、貸款、投資理財、其他銀行服務，至少有18支API，其中存款類別又可細分成5項API，而貸款資訊4項、投資理財資訊2項，另有7項其他銀行服務API。TSP業者可以在開放API平臺，看到所有參與銀行上架的API。

儘管，財金公司提供了一份銀行與TSP串接的公版契約，但每家銀行仍有各自的要求和講究，例如有銀行要求陳振榮，每個月得到警察局申請良民證，所以，TSP目前仍然得逐一與各銀行簽約，才能獲得他們各自API的使用權。

從TSP業者展示的應用情境中還可發現，Open API不只是單向地，將銀行的資料釋出給TSP業者而已，TSP開始成為引導顧客消費更多銀行商品的導購平臺，甚至可以成為消費者使用不同金融服務的新入口。TSP將更多顧客和商品消費需求，透過Open API帶進了銀行，開放銀行雙向互惠的效益，開始在臺灣發酵。

考量日後與眾銀行打交道，決定砸重本導入ISO 27001和27701

而第二階段自律規範的要求，將會決定了什麼樣的TSP才有資格使用開放銀行API，目前還未確定是否要效法澳洲，用銀行資安標準來規範TSP，不過，已有TSP業者，如麻布記帳已開始準備用銀行資安標準來自我要求，陳振榮計畫導入國際資安標準ISO/IEC 27001和今年8月才發布的國際隱私資訊管理標準ISO/IEC 27701，目前麻布記帳正在進行ISO 27001的導入評估。

陳振榮坦言，初步盤點，他們現有的資安措施和機制，約已做到85％的ISO 27001要求，特別是在技術面規範大致符合，但作業管理面則仍需有不少補強，例如得汰換成新式門禁機制、採用可供稽核追蹤的印表機等，他初估，光是導入ISO 27001，就會增加20％的維運成本，但是，「為了日後與更多銀行串接API，這是一定要做的事。」他強調。

三星坦承Galaxy S10旗艦級手機的指紋辨識感測器有臭蟲，讓任何沒有註冊的指紋都可以解鎖手機。三星也承諾儘速修復。

《太陽報》首先報導這項消息。一名英國34歲的女性消費者日前購入三星Galaxy S10，很快為這款手機貼上購自eBay的坊間品牌手機螢幕保護貼，再以右手姆指註冊了指紋辨識。之後，這名消費者無意間發現她的左手拇指也能解鎖。隨後丈夫測試發現，他的兩隻拇指竟都能解鎖太太的Galaxy S10。這名女性之後檢查她妹妹的三星手機，發現也有相同問題。

這名消費者立即聯絡三星客服人員，對方遠端檢查S10手機設定後，坦承似乎是安全問題。消費者對媒體抱怨，如果其他人拿到她手機，很快就能找到她的銀行app把錢轉出去。

根據三星的客服支援app文件指出，有些矽膠手機殼的螢幕保護貼的紋路在註冊時連同指紋被認識，就會發生上述情形。三星建議消費者使用經核准、專為三星裝置設計的保護類產品。

路透社引述三星官方說法指出，公司正在調查此事，並承諾儘速釋出修補程式解決該問題。

報導也引述南韓純網路銀行Kakao Bank說法，呼籲使用者在臭蟲修復之前，最好關掉指紋辨識解鎖功能。

這不是Galaxy S10第一次發生烏龍解鎖事件。今年三月這款手機剛上市時，就有各家媒體測試發現其人臉辨識很不安全，用其他手機上的照片、影片甚至兄弟姐妹的臉，就能解鎖手機。

經過6個月的測試，瑞典硬體安全金鑰Yubico今天宣佈釋出Yubico Login for Windows Application app正式版，讓用戶可以YubiKey硬體金鑰，登入Windows 電腦的本機帳號。

YubiKey是市面受歡迎的硬體金鑰，旨在提供無密碼登入，用戶多半以YubiKey登入雲端服務帳號。Yubico Login app則可用於提供本機帳號的登入，不過以前只有Mac和Linux版，之前Windows支援也是最多使用者反映想要的功能。今年三月Yubico釋出原名Windows Logon Tool的Yubico Login for Windows Application app公開預覽版，今天則開放穩定版下載。

Yubico Login for Windows Application可在原有的Windows密碼外提供多一層防護，讓用戶可以多因素驗證（multifactor authentication，MFA）登入Windows 工作站本機帳號，最多可支援10個帳號，並強調容易製作備份YubiKey和回復遺失的YubiKey。

Yubico Login for Windows Application支援Windows 7、8.1及10，但無法用於Active Directory (AD)、Azure Active Directory (AAD)、及微軟帳號（如@outlook.com 、@hotmail.com與@live.com）登入。

Yubico現在也正在朝支援AD、Azure AD努力，該公司目前正在預覽測試YubiKey支援AAD登入，供企業測試以Windows機器無密碼登入AAD的帳號。