Thales Solution Day：超前佈署 Open API 與雲端安全防護策略

隨著Internet的普及，運算體的邊界不再是一部部單機電腦，透過遠近不同電腦上不同軟體的聯繫、溝通串接，從而能實現更創新變化的資訊服務，並建立起企業新競爭力與商業價值，此為Open API技術應用勾勒出的新世界！

Open API雖能探索新應用與新市場，但若未能妥善防護，也將成為駭客攻擊、惡意程式入侵的便利管道，從而威脅企業，因此在興利的同時也須除弊，如何在善用雲端環境的同時也建構完備周全的防護，也成為不可或缺、難以迴避的一課。

有鑑於此，網路資訊與Thales、Red Hat及亞利安科技共同舉辦了「超前佈署Open API與雲端安全防護策略研討會」，期讓企業在探索新商業價值、建構新競爭力的同時，也能避開威脅侵害。

企業面對數位轉型應建立之資訊安全策略思維

「隨著數位轉型的發展，沒有邊際的網路使安全風險大幅攀升。」勤業眾信副總經理陳威棋說明資安防護的三個時代，首先是2008年至2012年的合規是時代，而後是2012年至2018年的風險時代，而2018年到現在乃至未來至2025年將是複雜時代。

近期API事件確實層出不窮，API面臨各種外部威脅，其因應手法是導入API資安管理框架、建立起API總覽圖，以及在框架中強化API開發安全，並且要包含訊息驗證與隱私保護，還有對第三方服務供應商的安全管理、API安全監控、API安全事件應變等等。

了解威脅與防護策略後，進一步也當了解雲端服務的風險與策略。陳威棋解釋，全球疫情影響下，居家工作、遠距辦公使雲端服務需求增加，因而配套的雲端防護需求也在提升。

對此，必須檢視雲端服務整體風險地圖，並依循雲端資安相關的法規與國際標準，如CSA的STAR、ISACA的CBOBIT 5等，各國區亦有不同的規範。透過規範的掌握，建立起雲端資訊治理安全框架，使雲端風險的控制面向(Control Domain)更全面完善。

最後，在雲端服務風險的管理策略上亦有穩健紮實的實施步驟，此包含六步，前兩步在於建立安全治理框架，中間的兩步在執行雲端安全的評估工作，末兩步則在於持續改善雲端安全的控管項。唯有如此，企業與組織方能在享受API便利的同時避免惡意攻擊於危害。

多雲世界的Bring Your Own Encryption(BYOE)資料保護策略

「傳統的圍牆式資料防護，在雲端世代到來後不再管用。」Thales大中華區資深技術顧問陳昶旭點名在雲端環境中實施資料防護的一大挑戰。而根據Thales委託IDC於全球進行的資料威脅調查，已經有50%的企業資料存於雲端，其中又有48%的資料屬於機敏資料，安全性堪慮。

調查也顯示資料上雲後資安挑戰遽增，26%受訪企業表示過去一年內曾發生過資安事故；或一年內雖未發生過事故但也有49%表示曾發生過資安事故；另外47%企業表示近一年來發生過資安事故或未能切實依循、通過資安稽核。

更重要的是，所有受訪企業都承認放置於雲端的企業機敏資料未全部加密防護，至多只有57%實施防護，言下之意尚有43%的機敏資料有直接暴露的風險。

針對落實雲端的資料防護Thales主張採行BYOE(自帶加密)框架，這包含原生加密、一體化的金鑰與政策管理等。特別是在加密的金鑰管理上必須彈性，以因應各種型態的雲端布建。

陳昶旭也分享一個布建案例，一個企業在歐洲與亞太區均有自屬的落地機房，同時也運用AWS於全球各地的多處公有雲，如馬尼拉、巴黎、東京、新加坡、法蘭克福等，每一處均有Thales的CM(CipherTrust Manager)，而兩處落地機房內則有Thales的Luna HSM設備，且構成高可用性(HA)架構，同時也建立起金鑰同步。

上述為落地機房與單一公有雲的搭配，實際上也可同時在不同業者的多處公有雲上實現資料防護，如Microsoft Azure、Google Cloud、IBM Cloud等。

最後企業當對採行BYOE技術進行考量，先評估環境是否適合，若不適合則可考慮採BYOK(自帶金鑰)，另外要確認雲端服務業者(CSP)是否支援企業自攜？是否有明確的資料控制、存取？是否有足夠的金鑰強度與生命週期管理證明，從而確保合規等。

另外要確認雲端服務商提供的環境，是否能限制雲端服務管理者、惡意軟體等存取對象，以未加密的明碼方式存取企業資料？企業是否希望以一致的控制方式來簡化多雲數據的安全性等，如此才能確保企業機敏資料不致外洩。

重新認識Open API–建立開放且安全的API生態系

「要實現開放且安全的API生態系，須先掌握與了解Open API平台」Red Hat解決方案架構師沈涵羚點出API資安的先期重點。

Open Shift的Open API平台本身包含多個部份，如開發者入口、管理、驗證伺服器、辨識供應商、API編作器(Composer)等，廣義而言也涉及外部的API閘道器(Gateway)，或底層運作的微服務容器平台，以及硬體防護、內部服務等。特別是API Composer能把API視為產品，以及實現多層次的API生命週期管理，如此API使用者可以訂閱不同的API產品，而API產品也可建構組合不同後端API。

而防護方面，在Red Hat OpenShift上提供了微服務的安全機制，使閘道容器間都具有雙向TLS認證，確保API呼叫的安全。而前面提到的硬體防護，在於OpenShift可支援Thales的HSM，使API使用者的授權驗證運作有更高的可信度。

進一步的，Open Shift提供的API管理可讓API模組化、防止單點故障、實現分散式的可擴展架構，以及策略式管理，同時與DevOps精神中的CI/CD管線整合。在開放者入口上，也能透Swagger設計出合乎Open API規範的API，並對API文件進行重要性的設定，以及能自動同步地區的API資訊。

沈涵羚也舉兩個應用案例，一是屬金融業的中國建設銀行，透過OpenShift的建立，提供第三方服務供應商(TSP)完整且自動的API串接服務，並能監督其運作使用。另一則是我國的公部門的台北市資料大平台、健保資料開放服務、以及財政部的電子發票整合服務平台，透過API的申請，即可在安全防護下介接與取用其開放的服務。

雲端世代中，系統架構應有的安全思維

「過往以前企業採行的傳統落地式資安防護模型，無法全然套用至雲端環境，取而代之的是共享職責的防護模型。」AWS Taiwan合作夥伴解決方案架構師王炘傑點出雲端資安防護與傳統防護的根本不同性。

所謂共享職責模型(Shared Responsibility Model)是由公有雲業者負責資訊基礎建設的防護，包含公有雲業者提供的各種服務也必須有防護，此稱為Security of the Cloud，而企業用戶自身須負責基礎建設之上的防護，稱為Security in the Cloud。

共享模型有多種實現方式，一是基礎建設方式，由AWS提供運算、儲存、網路等基礎服務及其防護，企業自身須負責作業系統、防火牆、用戶資料等防護；二是容器方式，由AWS的防護職責增加，須負責作業系統的防護，用戶仍負責防火牆、資料等；三是無伺服器(Serverless)方式，由AWS負責多數防護工作，用戶只須專注資料防護。

除防護模型外，雲端跨地的特性也使企業須比過去更重視國區的資訊法遵合規，對此AWS提出AWS Global Compliance Program，協助企業因應合規要求。進一步的，AWS提供許多基礎且層次性的防護服務，包含辨識、保護、偵測、回應、恢復等各階段的防護功能均具備。

更重要的是AWS具有眾多的防護夥伴，能與夥伴共同構築防護生態系，進而提供防護解決方案。其中在資料保護與加密方面即與Thales密切合作，期共同確保企業用戶在雲端的資料安全。