Noname Security解決方案
數位化轉型開放API應用與API管理及安全
政府的數位轉型（數位發展部正式掛牌），施政重點在推動我國數位政策的創新與變革，整合電信、資訊、資安、網路與傳播五大領域，整體規劃數位發展政策，統籌基礎建設、環境整備及資源運用業務，確保國家資通安全、促進跨域數位轉型、提升全民數位韌性。
一、推動國家數位發展策略，統籌協調規劃施政計畫資源
二、普及通訊傳播領域關鍵基礎設施，強化通訊傳播網路韌性
三、前瞻規劃管理數位通傳資源，確保資源使用符合公共利益
四、深化數位應用，提升政府施政效能
五、連結國際民主網絡力量，強化網路發展數位韌性
六、發展資料運用，打造資料創新應用生態
七、加速產業數位創新與轉型，帶動數位相關產業發展
八、強化資通安全防護縱深，提升國家數位發展環境之防護韌性
數位化轉型同時需要API轉型
API 是數位化生活的核心。API 是一種有效率且對開發人員友好的方式，使軟體和資料資產具有靈活性、速度和可移植性的互動能力，這些特性讓更多人看見它的價值。因此許多數位化轉型計劃也加入了API 的運用，包括：
API 在現代IT 世界中無處不在，API 預估流量從來只會增長。然而， API 的強大和流行， API 安全問題卻讓許多資訊單位都在為這苦苦掙扎。這可能很複雜，因為一個應用程式可能由多個後端API 組成，並且每個API 都可以以多種不同的方式調用。
在保護API 方面，只靠傳統的網頁應用安全控制並不是個完整的解決方案。換句話說，資訊單位必須增加針對API 的特定控制來解決API 安全問題，添加威脅阻擋和補救機制，並持續提供針對API 量身定制的安全測試。
API 使用量將在2022 年繼續激增
隨著資訊單位在API 上開展業務，經歷了API 安全事件的顯著增加。Gartner 指出，到2022 年，API將成為Web 應用程式的主要攻擊媒介。IBM 指出，三分之二的雲端漏洞與API 設定錯誤有關。
Noname Security 即時保護API 並在存在弱點和設定錯誤被惡意利用之前偵測到它們。Noname API安全平台是一種out of band 解決方案，可與您的API 閘道器、負載均衡設備和WAF 整合，以提供更深入的可視化和安全性。
Noname Security 是唯一一家提供API 安全態勢管理、API Runtime 安全性，並在API 開發過程中增加安全性的API 安全平台。
API 管理和閘道器
API 部署技術棧中的兩個基本元素是API 管理（控制平面）和API 閘道器（資料平面）：
1. API 管理. 這包含版本控制、發布和共享描述API 中可用的方法和資料的模式。API 的其他管理方面包含了監控和儀表板，以確定API 是否正確執行。如果API 向公眾開放或組織正在使用API 為客戶提供服務，則還需要入職和用戶文件。
2. API 閘道器. 大多數的部署都有一個API 閘道器，它負責處理身份驗證、授權和流量管理，擔任控制點的角色。
API 管理和閘道器為部署API 提供了關鍵功能，但不可避免的是仍舊存在難以解決的重大安全漏洞。更困難的問題是，通常沒有一個利益一致的關係者負責API 與其安全性。根據組織的不同，利益可能涉及多個關係者。這些可以包括API/產品經理、開發團隊、網路團隊、基礎設施團隊、應用程式安全團隊和雲端團隊。
API 的安全挑戰
API 所需的一些安全控制與傳統應用程式安全所需的安全控制類似。然而，有幾個針對API 的安全挑戰，並無法透過傳統的Web 應用程式安全控制來充分解決。
傳統的應用程式安全控制只能提供API 部分保護
API 閘道器提供了對安全問題的一些可視化，因為它們充當流量和安全政策執行的關鍵位置。但是，並非所有API 調用都通過閘道器。組織通常對這些API 調用以及未通過API 閘道路由器的微服務API 調用視而不見。
記錄和監控通常不是很有效。組織通常僅在發生違反政策行為後才在API 中尋找身份認證威脅。此外，API 測試不同於應用程式測試。將一套普通的應用程式安全工具套用在API 並不能提供適當的保護。
舊有或殭屍API 也造成了一些問題。這些可能比組織的API 資訊安全計劃還早被上線。它們的狀態也可能是本應停用，但由於疏忽卻仍保持運作狀態的API。這些API通常找不到負責人，也在沒有任何可視化或安全控制的情況下運行著，只是等待被不當濫用。
API 安全需要通用的控制項， 結合動態和靜態測試
為了保護API，團隊必須實施幾個通用控制項。其中包括網路流量加密、辨識誰在調用API 的身份驗證、確定是否允許調用者所請求的授權、使用最簡單的速率限制以及用稽核日誌來確認是否一切正常。
動態和靜態測試也是必不可少的，因為在開發週期中越早發現安全漏洞和錯誤設定，修復它們的成本就越低。
API 原始碼需要靜態應用程式安全測試(SAST)。還建議使用軟體組合分析(SCA) 來了解原始碼的品質和測試覆蓋率。需要注意的是，SAST 在發現API 特定缺陷（例如授權問題）方面沒有很好的效果。
在動態方面，團隊可以使用手動和/或自動測試。手動測試可能非常完整，但這不能很好地擴展或不適合大多數敏捷開發過程。如果團隊使用帶有OpenAPI 規範的REST API，那麼導入自動化測試工具將會變得更好。然而，一般來說，自動化測試專為Web 應用程式設計的應用程式，通常無法為API 及其獨特的業務邏輯功能提供足夠的安全測試。
組織必須解決從程式碼到線上環境間整個API 生態系統的安全問題
保障API 安全是很複雜的工作，需要一種方案來涵蓋API 的所有方面，包括其開發、部署配置和Runtime 操作。三個推薦的作法包含了：
1. API 安全態勢. 使用資料分類評估每個API，包括舊有API 和影子API。確定哪些對業務重要與否。根據該清單，辨識原始碼、網路設定和安全政策中的錯誤設定和漏洞。將安全防護重心放在最高風險的區塊才是正確的。
2. 偵測與回應. 為Runtime API 威脅檢測部署基於行為的模型。實施自動化和半自動化以阻止和修復威脅.
3. 持續測試持續測試API 端點以在API 風險出現之前能辨別它們。透過API 特定的測試補充DevOps DAST、SAST、SCA 和其他現有工具，這些測試可以自動化並整合到CI/CD pipeline 中.
完整且主動的 API 安全平台
數位化轉型開放API應用與API管理及安全
政府的數位轉型（數位發展部正式掛牌），施政重點在推動我國數位政策的創新與變革，整合電信、資訊、資安、網路與傳播五大領域，整體規劃數位發展政策，統籌基礎建設、環境整備及資源運用業務，確保國家資通安全、促進跨域數位轉型、提升全民數位韌性。
一、推動國家數位發展策略，統籌協調規劃施政計畫資源
二、普及通訊傳播領域關鍵基礎設施，強化通訊傳播網路韌性
三、前瞻規劃管理數位通傳資源，確保資源使用符合公共利益
四、深化數位應用，提升政府施政效能
五、連結國際民主網絡力量，強化網路發展數位韌性
六、發展資料運用，打造資料創新應用生態
七、加速產業數位創新與轉型，帶動數位相關產業發展
八、強化資通安全防護縱深，提升國家數位發展環境之防護韌性
數位化轉型同時需要API轉型
API 是數位化生活的核心。API 是一種有效率且對開發人員友好的方式，使軟體和資料資產具有靈活性、速度和可移植性的互動能力，這些特性讓更多人看見它的價值。因此許多數位化轉型計劃也加入了API 的運用，包括：
- 公有雲服務
- 微服務應用程序設計
- Open banking
- 行動健康照護
- 新的業務和開發者生態系統
- 後勤系統數位化
- 大量使用- GraphQL, gRPC, webhooks
API 在現代IT 世界中無處不在，API 預估流量從來只會增長。然而， API 的強大和流行， API 安全問題卻讓許多資訊單位都在為這苦苦掙扎。這可能很複雜，因為一個應用程式可能由多個後端API 組成，並且每個API 都可以以多種不同的方式調用。
在保護API 方面，只靠傳統的網頁應用安全控制並不是個完整的解決方案。換句話說，資訊單位必須增加針對API 的特定控制來解決API 安全問題，添加威脅阻擋和補救機制，並持續提供針對API 量身定制的安全測試。
API 使用量將在2022 年繼續激增
隨著資訊單位在API 上開展業務，經歷了API 安全事件的顯著增加。Gartner 指出，到2022 年，API將成為Web 應用程式的主要攻擊媒介。IBM 指出，三分之二的雲端漏洞與API 設定錯誤有關。
Noname Security 即時保護API 並在存在弱點和設定錯誤被惡意利用之前偵測到它們。Noname API安全平台是一種out of band 解決方案，可與您的API 閘道器、負載均衡設備和WAF 整合，以提供更深入的可視化和安全性。
Noname Security 是唯一一家提供API 安全態勢管理、API Runtime 安全性，並在API 開發過程中增加安全性的API 安全平台。
API 管理和閘道器
API 部署技術棧中的兩個基本元素是API 管理（控制平面）和API 閘道器（資料平面）：
1. API 管理. 這包含版本控制、發布和共享描述API 中可用的方法和資料的模式。API 的其他管理方面包含了監控和儀表板，以確定API 是否正確執行。如果API 向公眾開放或組織正在使用API 為客戶提供服務，則還需要入職和用戶文件。
2. API 閘道器. 大多數的部署都有一個API 閘道器，它負責處理身份驗證、授權和流量管理，擔任控制點的角色。
API 管理和閘道器為部署API 提供了關鍵功能，但不可避免的是仍舊存在難以解決的重大安全漏洞。更困難的問題是，通常沒有一個利益一致的關係者負責API 與其安全性。根據組織的不同，利益可能涉及多個關係者。這些可以包括API/產品經理、開發團隊、網路團隊、基礎設施團隊、應用程式安全團隊和雲端團隊。
API 的安全挑戰
API 所需的一些安全控制與傳統應用程式安全所需的安全控制類似。然而，有幾個針對API 的安全挑戰，並無法透過傳統的Web 應用程式安全控制來充分解決。
傳統的應用程式安全控制只能提供API 部分保護
API 閘道器提供了對安全問題的一些可視化，因為它們充當流量和安全政策執行的關鍵位置。但是，並非所有API 調用都通過閘道器。組織通常對這些API 調用以及未通過API 閘道路由器的微服務API 調用視而不見。
記錄和監控通常不是很有效。組織通常僅在發生違反政策行為後才在API 中尋找身份認證威脅。此外，API 測試不同於應用程式測試。將一套普通的應用程式安全工具套用在API 並不能提供適當的保護。
舊有或殭屍API 也造成了一些問題。這些可能比組織的API 資訊安全計劃還早被上線。它們的狀態也可能是本應停用，但由於疏忽卻仍保持運作狀態的API。這些API通常找不到負責人，也在沒有任何可視化或安全控制的情況下運行著，只是等待被不當濫用。
API 安全需要通用的控制項， 結合動態和靜態測試
為了保護API，團隊必須實施幾個通用控制項。其中包括網路流量加密、辨識誰在調用API 的身份驗證、確定是否允許調用者所請求的授權、使用最簡單的速率限制以及用稽核日誌來確認是否一切正常。
動態和靜態測試也是必不可少的，因為在開發週期中越早發現安全漏洞和錯誤設定，修復它們的成本就越低。
API 原始碼需要靜態應用程式安全測試(SAST)。還建議使用軟體組合分析(SCA) 來了解原始碼的品質和測試覆蓋率。需要注意的是，SAST 在發現API 特定缺陷（例如授權問題）方面沒有很好的效果。
在動態方面，團隊可以使用手動和/或自動測試。手動測試可能非常完整，但這不能很好地擴展或不適合大多數敏捷開發過程。如果團隊使用帶有OpenAPI 規範的REST API，那麼導入自動化測試工具將會變得更好。然而，一般來說，自動化測試專為Web 應用程式設計的應用程式，通常無法為API 及其獨特的業務邏輯功能提供足夠的安全測試。
組織必須解決從程式碼到線上環境間整個API 生態系統的安全問題
保障API 安全是很複雜的工作，需要一種方案來涵蓋API 的所有方面，包括其開發、部署配置和Runtime 操作。三個推薦的作法包含了：
1. API 安全態勢. 使用資料分類評估每個API，包括舊有API 和影子API。確定哪些對業務重要與否。根據該清單，辨識原始碼、網路設定和安全政策中的錯誤設定和漏洞。將安全防護重心放在最高風險的區塊才是正確的。
2. 偵測與回應. 為Runtime API 威脅檢測部署基於行為的模型。實施自動化和半自動化以阻止和修復威脅.
3. 持續測試持續測試API 端點以在API 風險出現之前能辨別它們。透過API 特定的測試補充DevOps DAST、SAST、SCA 和其他現有工具，這些測試可以自動化並整合到CI/CD pipeline 中.
完整且主動的 API 安全平台
