「開放銀行的挑戰是第二、第三階段。」政大金融科技研究中心副主任陳恭再三強調。儘管API是跨產業間合作的利器,有助於資訊和流程整合的自動化,但是他指出,必須先釐清,Open API是一個技術上的專有名詞,指的是使用開放標準來制訂的API。在實作上,Open API的「Open」一詞,是「開放」之意,而非「公開」。所以,Open API不只包括了「公開的API」,也可以包括那些指在特定合作夥伴間、特定成員間,利用這些以開放標準訂定的API來串接的行為。

要考慮到這些不同類型的應用場景,陳恭表示,Open API就必須考慮到認證、授權、威脅偵測、資料保密和訊息正確性,以上要素缺一不可。

開放銀行的資安必需要考慮兩大議題,身分辨識與權限控管。對銀行端而言,不只需要辨識出使用者的身分,也要辨識第三方業者的應用程式來控管其權限。不過,在臺灣開放銀行發展的Open API三階段開放中,第一階段只涉及已經公開的商品資料,因此不用考慮消費者辨識和認證的議題。目前作法是第三方服務業者事先註冊,第三方應用程式經過審查(或取得銀行授權)後,以API Key來辨識身分。但是到了第二階段,就得進一步考慮更完整的Open API安全規範。

陳恭表示,涉及消費者帳戶與交易資料,除了辨識第三方程式,也不能將消費者的帳號與密碼交給第三方,「目前,國際間慣用的作法是採取OAuth 2委任存取授權方式,讓TSP來存取客戶資料。」

消費者先登入原本銀行的網銀,來進行對第三方程式授權,第三方程式就可以用授權後的Token通行證來存取銀行的API,並且這類Token還需限制API存取範圍和時間,甚至要提供隨時可撤銷授權的機制。授權過程中,還需要讓消費者清楚知道,第三方的程式要求讀取哪些權限。

簡單來說,OAuth 2授權可分成四個流程,首先,TSP的App得先向銀行註冊,銀行會提供一個特殊代號給TSP業者。第二,當使用者打開TSP業者的App來連結銀行時,這個App就可以用這個代號來告知銀行,自己的身分。第三,銀行的驗證伺服器透過白名單確認App的身分後,允許使用者進行網銀登入程序,來對App進行授權,並提供一個授權碼(Auth code)給App。第四,使用者不用再次登入銀行的系統,App可用這個Auth Code來換取特定服務的存取金鑰(Access Token),日後用這個存取金鑰來取得需要的金融資訊。

OAuth 2.0委任存取管理示意圖(圖片來源_陳恭)

「OAuth 2是電商、網路科技業者慣用的授權方式,但銀行圈對此技術不清楚,趁著(這次機會)推動Open API,可以讓銀行熟悉這項主流作法。」陳恭表示。

不過,OAuth 2主要聚焦授權機制,陳恭指出,在認證機制上較不足,沒有在網路通訊協定中採取更嚴謹的防範措施。所以,後來又發展出了OpenID Connect (OIDC),增加了ID Token,可以提供部分使用者資訊給授權者比對,避免中間人冒用。另外,API安全標準上,還有最新一套考量更多安全機制和風險控管功能的FAPI(Financial-Grade API,金融等級API)設計。目前,臺灣開放銀行發展上,初步看法是第二階段考慮引進OAuth 2的作法,其他更高標準安全規範,則看日後需求和風險考量時再考慮。

OAuth 2是針對Open API的安全標準,陳恭認為,也可以借鏡臺灣醫療資料交換的最新MyData應用,利用區塊鏈來進行涉及敏感性個資的授權管理。

陳恭剛與臺北市立聯合醫院資安長許世欣聯手,完成了一套照護資訊整合平臺,採用以太坊區塊鏈,來提供不可否認的電子簽章,可供病人將自身的敏感性醫療資料,授權給其他醫院的醫生、長照人員等調閱,甚至可以由子女代理年邁父母病患遠端授權,讓醫生取得病患過去醫療記錄,來輔助現場的診療。「目前這項區塊鏈授權,可以精細到每一筆資料的授權控制。」

陳恭表示,這一波開放銀行浪潮,有機會帶動API經濟的發展,不只是銀行,現在其他產業包括證券、保險,也開始想要了解Open API的可能性,甚至,他觀察:「開放銀行發展若有成果,未來,有機會擴大到臺灣所有持有資料的產業,都可能加入這波Open API的行列。」

不論是醫療資料和金融資料或其他民眾自己的個人資料,從資料角度來看,Open API可以打通了跨產業間的串連,讓使用者自己的資料得以流通,也都得面對個資法合規的挑戰,陳恭指出:「這正是MyData趨勢的課題。」甚至,政府手上的民眾資料也可以成為MyData的一環,透過合規安全的驗證和授權機制,成為Open API可以串接的來源之一。文⊙王宏仁

 相關報導  臺灣開放銀行關鍵第一步


Advertisement

更多 iThome相關內容