資訊安全 API經濟 微服務 Open API 雲端服務 軟體即服務 無服務器

安全機制首要掌握全貌 5項共通規範杜絕潛在漏洞風險

API經濟蓄勢待發 前瞻資安框架防堵入侵

2020-01-22
隨著雲端服務,軟體即服務、無服務器和行動計算以及與第三方合作夥伴的大型平台整合,API的使用也在不斷增長,API更吸引了互聯網掠食者的追捧,當攻擊者違反API時,他們通常會獲得對其中應用程式服務的完全管理存取權限,這也變成應用程式介面相關的潛在漏洞。

 

日前金管會宣布,財金公司打造的金融開放API平臺已正式啟用,臺灣開放銀行發展達成第一個里程碑。金管會宣布的三階段開放措施中,第一階段是「公開資料查詢」、第二階段「消費者資訊查詢」與第三階段「交易面資訊」。這也代表第一階段的公開資料查詢API,正式對外開放了。

開放API架構設計的規範,共通性上是參考國際標準Open API Specification(OAS),遵循OAS規範的RESTful APIs、定義,使API互通介面不受程式語言限定,除了未來跟其他產業或政府開放資料之介接,這也讓臺灣這套Open API介接國際,甚至國外第三方業者都可以來用。再者,輕便性上採用RESTful風格設計API和Web設計慣用的JSON資料格式,消耗資源少且相容性高。

試想,當社群媒體入口蹦出銀行代銷保險產品,未來只要利用支付平台付款就可以累積雙邊紅利點數;透過政府eID,民眾可以用單一窗口進行稅務、醫療、教育等便民的資訊整合查詢;在便利商店Kiosk多媒體資訊站,民眾可以完成食衣住行的支付。未來銀行、支付平台、銷售通路、店家、政府、人民,因為數據的開放讓有價的資訊進行多邊交換,進而演繹出對消費者更便利的生活行為應用資訊。

換言之,網上服務透過API互相呼叫微服務(Microservices),開啟綜合式的服務平台的商機模式,API 經濟(API Economy)時代也蓄勢待發。

下階段Open API才是真正的挑戰

每個產業有獨特的應用場景,彼此需要一個共通的管道來成就新的資訊應用情境,Open API正是網路巨浪上可以將來自各產業眾多API一起串接的關鍵舵手,但二、三階段涉及個資保護,帶來的兩大關鍵問題,第一是銀行擁有比較完善資安與個資保護的意識與配備,當將銀行資料開放給第三方服務業者(TSP)後,金管會要用甚麼標準來評估管理TSP業者?另一個最重要的問題將是,萬一銀行的資料開放給業者後,發生企業最擔憂的個資外洩或是資安事件,責任歸屬的問題。

根據F5應用程式保護報告,隨著雲端服務,軟體即服務(SaaS)、無服務器和行動計算以及與第三方合作夥伴的大型平台整合,API的使用也在不斷增長,API更吸引了互聯網掠食者的追捧,當攻擊者違反API時,他們通常會獲得對其中應用程式服務的完全管理存取權限,這也變成應用程式介面(API)相關的潛在漏洞。這也是為什麼在第三階段施行細節尚未明定之前,政府先行公布了在資訊安全上重要的是五項共通規範,包括必備欄位格式檢查、採用TLS 1.2以上加密通訊協定、白名單表列HTTP請求、預防DDoS攻擊的連線限制和逾時中斷,以及必須使用HTTPS安全傳輸協議等連線加密,以確保API的安全。

API攻擊面將持續增長

政府機關倡導更多使用API,以促進企業和組織之間的開放資料交換。如《美國經濟和臨床健康健康信息技術法案》(HITECH Act)鼓勵透過API存取和交換電子健康記錄,而歐洲金融服務和支付供應商嚴重依賴API相互連接。令人憂心的是中國已經開始出現利用API來發動DDoS攻擊的案例,該手法較反射、放大式攻擊不同,主要是透過遠端控制來執行,例如以手機App控制汽車感知器的場合,易遭利用工具執行中間人攻擊。

用API的系統數量眾多,這意味著API必須每天管理數以萬計的連接和數百萬次操作的身份驗證和存取特權。在這些應用程序平台中,大量有價值的資料也使它們成為威脅活動如犯罪、駭客行為、間諜活動、戰爭的極具吸引力的目標。

API只是程式碼之間溝通的介面。基於WhiteHat應用程式安全統計資訊的代碼,每10萬行代碼(LOC)平均有39個漏洞。而這只是傳統應用程式。如果使用微服務架構實現接口(API),則每10萬個LOC大約180個漏洞。無論哪種方式,這都是漏洞的隱憂,API帶有與Web應用程序相同的漏洞。這意味著它在安全性方面需要與Web應用程序相同。

OWASP Top10 Mobile14安全問題列表中排名第一的是「平台使用不當」。此安全漏洞特別警告:「當使用不安全的編碼技術實現公開的服務或API時,任何公開的API調用都可以充當攻擊媒介」。查看這些安全事件,不難發現攻擊者透過蠻力攻擊或憑證被盜獲得存取權限。一旦身份驗證憑證被網路釣魚竊取,API便是一種透過機器人無聲息地清除帳戶的好方法,例如2018年3月Binance發生的事件,沒有API,用戶就無法存取成千上萬的客戶記錄。最後,許多此類API事件是注入攻擊的結果,注入攻擊仍然是應用程序安全性的問題。注入攻擊是輸入清理能力較弱的副作用,它使攻擊者可以直接向應用程式注入命令。

地端與雲端控管策略一致性

欲建立API安全控管措施之前,首先要先具備應用層的可視化能力,也就是得以解析封包內容,並且識別Web Service屬於RESTful API或SOAP規範。針對未來API經濟爆炸性成長,政府、金融以及企業等從API創建、發佈、管理、安全及透析,必須要擁有一個完整前瞻性的框架,這個框架不僅必須符合政府及金管會API Security五大規範,更近一步提供從安全角度的透析審視有價資訊,讓API開放的實質效益不會被惡意的駭客循路入侵,造成整個生態系的災難。

API經濟蓄勢待發,但同時也易遭利用發動攻擊。(photo: Wright Studio/shutterstock)

安全機制第一要件必須掌握全貌,如F5 Networks API Security Framework方案架構不僅符合API Security五大規範, F5 Networks更從資訊開放的端口就開始防禦所有可能的進階威脅包含OWASP TOP10攻擊、DDoS分散式阻斷攻擊、資源消耗惡意攻擊。

當您使用API越多,API Gateway就越關鍵。無論是從傳統的整體應用程式存取資料,還是要使用微服務構建新應用程式,不去防護API的閘道口,就如水能載舟也能覆舟的危險,高可靠性、高性能與高安全的API Security資安框架才能有效協助企業、政府在透過API發展新型態網路應用時,安全無虞並更加速資料的傳遞與效能及防禦所有可能的API進階威脅。

<本文作者:陳廣融現為F5 Networks 台灣區資深技術顧問。>

 


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!