編輯部隨著 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 密切合作，期共同確保企業用戶在雲端的資料安全。
