Azure Integration Services 登陸區域加速器的安全性考慮
良好的安全性是任何 Azure 應用程式的基石。 Azure Integration Services 面臨特定挑戰，因為有許多資源組成應用程式，而且每個資源都有自己的安全性考慮。 若要確保您瞭解每個服務的特定考慮，請參閱下列安全性基準：
設計考量
設計安全性模型時，有兩個不同的設計領域： 設計階段安全性 ，以及 執行時間安全性 。
設計階段安全性 牽涉到透過Azure 入口網站或管理 API 存取及建立 Azure 資源。 在 Azure 中，我們使用 Microsoft Entra ID 和角色型存取控制 （RBAC） 來達成此目的。
執行時間安全性 牽涉到在應用程式流程期間存取端點和資源 -例如，驗證和授權呼叫邏輯應用程式的使用者，或API 管理中的 API 作業。
如有需要，請儘早決定：
私人雲端 - 您的所有資源都位於 VNet 中，且只使用私人位址，而無法存取或從公用網際網路存取，可能可透過 VPN 或 ExpressRoute 存取內部部署資源。
公用雲端 - 您所有公開的資源都可以存取公用網際網路，但鎖定為限制從公用網際網路的存取。
混合式 - 有些資源是私人的，有些是公用的。
您所做的選擇會影響資源的成本，以及您可以為應用程式實作多少安全性。
一般安全性考慮包括：
使用 Azure 服務來保護輸入和輸出流量。
使用 Microsoft Entra ID 和 OAuth 2.0 來管理驗證。
使用 Azure 原則 強制執行治理原則。
鎖定資源的存取權（存取控制）。
加密傳輸中和待用資料。
記錄所有嘗試存取資源。
稽核資源的存取權。
設計建議
網路設計建議
查看 在可存取端點前面搭配 Web 應用程式防火牆 （WAF） 使用應用程式閘道 （Azure 應用程式閘道 或 Azure Front Door），這可協助您自動加密資料，並讓您更輕鬆地監視和設定端點。
Front Door 是一個應用程式傳遞網路，可為 Web 應用程式提供全域負載平衡和網站加速服務。 Front Door 提供第 7 層功能，例如 SSL 卸載、路徑型路由、快速容錯移轉和快取，以改善應用程式的效能和可用性。
流量管理員 是以 DNS 為基礎的流量負載平衡器，可讓您以最佳方式將流量分散到全球 Azure 區域的服務，同時提供高可用性和回應性。 因為流量管理員是 DNS 型負載平衡服務，所以只會在網域層級進行負載平衡。 因此，由於 DNS 快取和系統不接受 DNS TTL 的常見挑戰，因此無法像 Front Door 一樣快速地容錯移轉。
應用程式閘道 提供具有各種第 7 層負載平衡功能的受控應用程式傳遞控制器。 您可以使用 應用程式閘道，將 CPU 密集型 SSL 終止卸載至閘道，將 Web 服務器陣列的生產力優化。
Azure Load Balancer 是所有 UDP 和 TCP 通訊協定的高效能、超低延遲第 4 層輸入和輸出負載平衡服務。 Load Balancer 每秒會處理數百萬個要求。 Load Balancer 是區域備援，可確保跨可用性區域的高可用性。
使用 VNet 整合，為您的整合服務資源實作網路隔離，以將它們放在與使用 Azure 私人連結 和私人端點結合的隔離子網中。 如需此設計指導方針的檢閱，請參閱本系列中的網路拓撲和連線 一文。
使用 IP 篩選來鎖定您的端點，以便只能由已知的網路位址存取它們（這適用于未整合到 VNet 中的邏輯應用程式）。
如果您有公開可用的資源，請使用 DNS 混淆來阻止任何攻擊者;混淆表示自訂功能變數名稱或不會顯示資源用途或擁有者的特定 Azure 資源名稱。
加密設計建議
儲存資料時（例如，Azure 儲存體或 Azure SQL Server），一律啟用 待 用加密。 鎖定資料的存取權，在理想情況下只能存取服務和有限的系統管理員數目。 請記住，這也適用于記錄資料。 如需詳細資訊，請參閱 Azure 待用 資料加密和 Azure 加密概觀 。
在傳輸 中一律使用 加密（例如 TLS 流量）在資源之間傳輸資料時;絕對不要透過未加密的通道傳送資料。
使用 TLS 通訊協定時，請一律使用 TLS 1.2 或更新版本。
在 Azure 金鑰保存庫 中 保留秘密，然後將這些秘密連結至 應用程式設定 （Functions、Logic Apps）、 具名值 （API 管理），或 組態 專案（應用程式組態）。
實作金鑰輪替原則，以確保環境中使用的所有金鑰都會定期輪替，以防止使用危及金鑰的攻擊
針對邏輯應用程式， 請使用模糊化 來保護執行歷程記錄中的資料。
驗證和存取設計建議
指派存取權時，請一律遵循最低許可權原則：提供身分識別所需的最低許可權。 有時候，這牽涉到建立自訂的 Microsoft Entra 角色。 如果沒有具有所需最低許可權的內建角色，請考慮只使用這些許可權建立自訂角色。
盡可能使用受控識別，當資源需要存取服務時， 一律使用 受控識別 。 例如，如果您的邏輯應用程式工作流程需要存取金鑰保存庫擷取秘密，請使用 邏輯應用程式的受控識別 來達成此目的：受控識別提供更安全、更容易管理存取資源的機制，因為 Azure 代表您管理身分識別。
使用 OAuth 2.0 作為資源端點之間的驗證機制：
在 Logic Apps 或 Functions 中，啟用 Easy Auth，這需要所有外部呼叫者使用 OAuth 身分識別（通常是 Microsoft Entra ID，但可以是任何身分識別提供者）。
在API 管理中，使用 jwt 驗證原則元素來要求 OAuth 流程才能連線到端點。
在Azure 儲存體和金鑰保存庫中，設定存取原則以限制特定身分識別的存取。
治理設計建議
主動使用 Azure 原則 尋找安全性問題或瑕疵。 例如，沒有 IP 篩選的端點。
如果有，請使用 適用於雲端的 Microsoft Defender 來掃描您的資源，並找出潛在的弱點。
定期檢閱稽核記錄（在理想情況下使用自動化工具）來識別安全性攻擊，以及任何未經授權的資源存取。
請考慮使用滲透測試來識別安全性設計中的任何弱點。
使用自動化部署程式來設定安全性。 可能的話，請使用 AZURE DevOps 和 Terraform 之類的 CI/CD 管線，不僅要部署您的資源，還能設定安全性。 這可確保您的資源會在部署時自動受到保護。
後續步驟
檢閱重要的設計區域，以針對您的架構進行完整的考慮和建議。