通過關注身份、數據和 API 來提高應用整合的安全性

應用程序整合包含跨雲和本地連接應用程序，要求系統公開數據和功能，增加隱私和安全風險。應用程序領導者必須在其應用程序整合戰略中改進訪問控制、數據安全和 API 保護。

概述

主要挑戰

·        當數位行銷、銷售或業務團隊中的整合商獨立創建應用程序之間的許多簡單整合時，很難將安全的應用程序整合作為一個整體交付。

·        作為應用程序整合的一部分，從記錄系統中公開數據，以及在本地和雲應用程序之間連接數據，都會增加傳輸中和靜態數據的隱私風險。

·        攻擊者已經開始發現和利用不安全的 API 來訪問應用程序和數據，這是一個重大威脅，應用程序整合通常包含創建 API 以開放對應用程序和數據的訪問。

·        整合平台即服務 (iPaaS) 產品、企業服務總線 (ESB) 產品和 API Getway等整合工具非常複雜，可能配置不正確或不安全，或者可能包含未修補的安全漏洞。

建議

作為負責應用程序整合的應用程序領導者，您應該：

·        與您的企業安全團隊合作，將身份管理應用於整個組織的整合。

·        通過評估風險，然後應用數據隱藏、標記化和加密等技術，避免在其中傳遞敏感數據。

·        應用 API 安全性來保護整個整合架構中的 API ，包括軟體即服務 (SaaS) API 的使用。

·        通過將認證、漏洞評估和平台營運考慮在內，評估供應商的整合產品（例如 iPaaS 和 ESB）的安全性。

介紹

負責整合的應用程序領導者被迫啟用由業務目標驅動的新技術投資；例如改善客戶體驗和遠端員工支援。這些新的投資越來越多地基於雲，推動了對本地和雲系統交換數據的需求，或者越來越多的雲到雲整合的需求。到 2020 年底，雲服務整合被列為最關鍵的整合場景。

然而，應用程序整合帶來了安全風險，例如當整合包含開放對記錄系統的訪問時，容易發生數據洩露的風險。數據洩露可能會造成毀滅性的財務和聲譽影響。

分析

與您的企業安全團隊合作，將身份管理應用於整個組織的整合

調查發現，42%的組織報告說明整合流程是由 LOB 人員（例如應用程序管理員、分析師或工程師）創建的，39%的組織報告說整合流程是由業務用戶創建的。這種整合的趨勢很可能會繼續，中央整合團隊將扮演“整合者”的角色。

整個組織中應用程序整合的激增導致了整合安全性被忽視的風險。當個人構建整合不考慮安全性時，這可能導致基礎設施暴露於未經授權的訪問或數據洩漏。為了避免這種風險，將安全性應用於由組織中的多個個人和團隊構建的整合流程至關重要，而不僅僅是一個中央整合團隊。

保護出站和雲到雲整合流程

確保整合安全的一個關鍵決策因素是選擇儲存憑據（例如用戶密碼和訪問 SaaS 服務的金鑰）的位置。有兩種選擇：

1.     將用戶密碼和金鑰硬編碼到應用程序整合中

2.     將整合工具連接到身份和訪問管理基礎架構

在這兩個選項之間做出決定時，請評估密碼或金鑰被洩露時的風險。考慮以下兩種情況：

1.     與使用用戶的用戶名和密碼訪問服務的雲服務的整合。

2.     與使用管理員或“系統”帳戶進行訪問的雲服務或本地系統的整合。例如，當 LOB團隊中的應用程序管理員希望連接到數據庫或基礎設施即服務 (IaaS) 雲服務（如 Amazon AWS）時。

在上面的第一個場景中，如果整合流程被破壞，那麼這個用戶（以及這個用戶單獨）可以訪問的任何東西都將可供攻擊者使用。但是，在第二種情況下，如果此整合流程受到損害，則影響可能會更大。

此風險評估指導選擇是否將應用程序整合流程接到企業範圍的身份和訪問管理 (IAM)。專門為整合流程創建用戶ID，這樣就不必使用最終用戶、管理員憑據或“系統帳戶”。

·        將基於角色的訪問控制 (RBAC) 應用於應用程序端點，以便根據用戶權限限制訪問。例如，強制LOB用戶只能訪問客戶數據的子集。

·        在整合工具和應用程序之間使用單點登錄，而不是硬編碼密碼。

與您組織的應用程序安全團隊合作以啟用這些IAM整合。

保護入站整合流程

整合場景通常包含需要訪問本地數據和應用程序的雲應用程序。在許多情況下，這是使用雲服務的功能來保護的，例如亞馬遜的 VPC（虛擬私有雲）或 Azure 虛擬網路（VNet）。

避免在未評估風險的情況下在整合流程中傳遞敏感數據

數據安全需求必須平衡風險與應用程序整合的業務需求。應將持續自適應風險和信任評估 (CARTA) 模型應用於數據安全。數據編輯、隱藏和標記化是可應用於傳輸敏感數據的整合流程的技術。這些技術的區別在於：

·        數據編輯是一種數據隱藏技術，它用選定的編輯字符（例如“X”）替換數據。它是保護非結構化數據元素（例如文檔的敏感部分）的一項重要技術。

·        數據隱藏包含生成虛構但語法有效的數據，以掩蓋數據整合中使用的敏感數據。例如，客戶電話號碼可以用生成的電話號碼進行數據隱藏，該電話號碼與 SaaS 應用程序中的字段的數據格式要求相匹配。

·        與數據隱藏不同，數據標記化和格式保留加密 (FPE) 被設計為可逆的。這使數據能夠作為整合流程的一部分流向目的地；對敏感數據（例如患者記錄）進行選擇性標記或加密。然後，在單獨的整合流程中可以替換原始數據。

應用 API 安全性來保護整個整合架構中的 API

API 戰略的首要業務目標是實現整合。這通常包含“支援 API”的記錄系統，以開放對數據的訪問。然而，已經有許多 API 被使用的例子。

保護 API 通常包含使用多種工具，包括 API Getway和 Web應用程序防火牆。一個關鍵步驟是創建 API 安全策略，描述應用於 API 訪問的安全步驟。但是，請避免創建許多不同的 API 安全策略，例如，為您的組織使用的每個 API 創建一個，這樣做會產生複雜性並且難以管理。相反，創建可重用的安全策略，可應用於不同的整合場景。

在需要對用於整合的 API 流量進行異常檢測的場景中，可以使用專門的 API 安全產品。

在保護 API 以進行整合時，還要考慮您的組織使用的 API，而不僅僅是您的組織提供的 API，第三方 API 的訪問也必須得到管理和保護。

評估供應商的整合產品的安全性

應用程序整合平台的趨勢是向雲和混合方向發展。這意味著即使組織希望部署本地應用程序整合平台，它也可能具有雲依賴性。這種雲“網路共享”可以採用基於雲的控制平面的形式，在這裡定義和管理整合流程，並且可以訪問分析。