SEC09-BP03 驗證網路通訊 - 安全支柱
實作指引資源

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

SEC09-BP03 驗證網路通訊

使用支援身分驗證的通訊協定來驗證通訊的身分，例如 Transport Layer Security （TLS） 或 IPsec。

設計工作負載，以在每當服務、應用程式或使用者之間進行通訊時，使用安全、經驗證的網路協定。使用支援驗證和授權的網路協定可提供更強大的網路流量控制能力，並減少未經授權存取所造成的影響。

預期成果：設計出工作負載，讓其有明確定義的服務間資料平面和控制平面流量流程。在技術允許的情況下，流量流程要使用經過驗證和加密的網路協定。

常見的反模式：

  • 工作負載內有未經加密或驗證的流量流程。

  • 在多個使用者或實體之間重複使用驗證憑證。

  • 僅仰賴網路控制作為存取控制機制。

  • 建立自訂驗證機制，而非仰賴產業標準的驗證機制。

  • 服務元件或 中的其他資源之間流動過度寬鬆的流量VPC。

建立此最佳實務的優勢：

  • 將未經授權存取所造成的影響範圍限制在工作負載的某個部分。

  • 提供只會由已驗證實體執行動作的更高層級保證。

  • 透過清楚地定義並強制執行預期的資料傳輸介面來改善服務的去耦。

  • 透過請求歸因和明確定義的通訊介面，增強監控、日誌記錄和事件回應。

  • 將網路控制項與身分驗證和授權控制項結合，為您的工作負載提供 defense-in-depth。

未建立此最佳實務時的曝險等級：低

實作指引

您工作負載的網路流量模式可分為兩個類別：

  • 東西流量代表構成工作負載的服務之間的流量流程。

  • 南北流量代表工作負載和取用者之間的流量流程。

雖然加密南北流量是常見的做法，但是使用經過驗證的協定來保護東西流量則較不常見。現代安全實務的建議是，單靠網路設計並無法讓兩個實體之間建立信任的關係。當兩個服務可能位於一個共通的網路邊界內時，最佳實務仍是對這些服務之間的通訊進行加密、驗證和授權。

例如， AWS 服務APIs使用 AWS Signature 第 4 版 （SigV4） 簽章通訊協定來驗證來電者，無論請求來自哪個網路。此身分驗證可確保 AWS APIs可以驗證請求動作的身分，然後該身分可以與政策結合，以做出授權決定，以判斷是否應允許該動作。

Amazon VPC Lattice 和 Amazon API Gateway 等服務可讓您使用相同的 SigV4 簽章通訊協定，將身分驗證和授權新增至您工作負載中的東西流量。如果 AWS 環境外的資源需要與需要 SigV4-based身分驗證和授權的服務通訊，您可以在非AWS 資源上使用 AWS Identity and Access Management （IAM） Roles Anywhere 來取得臨時 AWS 憑證。使用這些憑證，便可透過 SigV4 簽署服務請求以授權存取。

驗證東西流量的另一個常見機制是TLS相互身分驗證 （m TLS）。許多物聯網 IoT） business-to-business、應用程式和微服務都使用 mTLS，透過使用用戶端和伺服器端 X.509 憑證來驗證TLS通訊的兩側身分。這些憑證可由 AWS Private Certificate Authority （） 發出AWS Private CA。您可以使用 Amazon API Gateway 等服務AWS App Mesh，並為工作負載間或內部通訊提供 mTLS 身分驗證。雖然 mTLS 提供TLS通訊兩側的身分驗證資訊，但它不會提供授權機制。

最後，2.0 OAuth 和 OpenID Connect （OIDC） 是兩種通訊協定，通常用於控制使用者對 服務的存取，但現在也越來越受流量歡迎 service-to-service。API Gateway JSON 提供 Web 權杖 （JWT） 授權方 ，允許工作負載使用從 OIDC或 2.0 身分提供者JWTs發行的 來限制對API路由OAuth的存取。OAuth2 範圍可以用作基本授權決策的來源，但授權檢查仍需要在應用程式層中實作，而且僅OAuth2範圍無法支援更複雜的授權需求。

實作步驟

  • 定義並記錄工作負載網路流程：實作 defense-in-depth策略的第一步是定義工作負載的流量流程。

    • 建立可清楚定義構成工作負載的不同服務間資料傳輸方式的資料流程圖。此圖是透過已驗證的網路通道強制執行這些流程的第一步。

    • 在開發和測試階段檢測您的工作負載，以驗證資料流程圖是否準確反映工作負載在執行時期的行為。

    • 執行威脅模型練習時，資料流程圖也很有用，如 SEC01-BP07 中所述，使用威脅模型 識別威脅並排定緩解優先順序。

  • 建立網路控制：考慮建立與資料流程一致的網路控制 AWS 功能。雖然網路邊界不應是唯一的安全控制，但它們在策略中提供 defense-in-depth一層來保護工作負載。

    • 使用安全群組建立定義和限制資源之間的資料流程。

    • 考慮使用 與支援 AWS 的第三方服務進行AWS PrivateLink通訊 AWS PrivateLink。透過 AWS PrivateLink 介面端點傳送的資料會保留在 AWS 網路骨幹內，不會周遊公有網際網路。

  • 在您的工作負載中跨服務實作身分驗證和授權：選擇最適合的一組 AWS 服務，以便在工作負載中提供已驗證的加密流量流程。

  • 監控未經授權的存取：持續監控是否有意外的通訊管道、嘗試存取受保護資源的未經授權主體，以及其他不當的存取模式。

    • 如果使用 VPC Lattice 來管理對服務的存取，請考慮啟用和監控 VPC Lattice 存取日誌。這些存取日誌包含請求實體的資訊、包括來源和目的地 的網路資訊VPC，以及請求中繼資料。

    • 考慮啟用VPC流程日誌來擷取網路流程上的中繼資料，並定期檢閱異常情況。

    • 請參閱AWS 安全事件回應指南和 AWS Well-Architected Framework 安全支柱的事件回應區段，以取得規劃、模擬和回應安全事件的更多指引。

資源

相關的最佳實務：

相關文件：

相關影片：

相關範例：