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

SEC05-BP01 建立網路層

以工作負載元件的邏輯分組為基礎，根據其資料敏感性和存取需求將您的網路拓樸區分成不同層。將需要從網際網路進行傳入存取的元件 (例如公用 Web 端點) 和只需要內部存取的元件 (例如資料庫) 加以區分。

預期結果：您網路的圖層是整體 defense-in-depth安全方法的一部分，可補充工作負載的身分驗證和授權策略。根據資料敏感性和存取需求妥善區分的網路層，且具有適當的流量流程和控制機制。

常見的反模式：

建立此最佳實務的優勢：建立網路層是透過網路限制非必要路徑的第一步，尤其是前往關鍵系統和資料的路徑。這可讓未經授權的行為者更難存取您的網路並瀏覽至網路內的其他資源。分散的網路層有利於縮小檢測系統的分析範圍，例如針對入侵偵測或防範惡意軟體。這樣可減少誤報和不必要的處理負擔。

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

實作指引

在設計工作負載架構時，根據元件的責任將其劃分至不同層是常見的做法。例如，Web 應用程式可擁有呈現層、應用程式層和資料層。您可以在設計網路拓樸時採用類似的方法。基礎網路控制可協助強制執行工作負載的資料存取需求。例如，在三層 Web 應用程式架構中，您可以將靜態呈現層檔案存放在 Amazon S3 上，並從內容交付網路 （CDN） 提供這些檔案，例如 Amazon CloudFront。應用程式層可以具有 Application Load Balancer （ALB） 在 Amazon VPC 公有子網路 （類似非隔離區域或 DMZ） 中服務的公有端點，並將後端服務部署到私有子網路。託管資料庫和共用檔案系統等資源的資料層，可位於與應用程式層的資源所在位置不同的私有子網路。在每個層邊界 （CDN、公有子網路、私有子網路） 上，您可以部署控制項，僅允許授權流量周遊這些邊界。

類似於根據工作負載元件的功能用途建立網路層模型，請一併考量要處理的資料敏感性。以 Web 應用程式為例，雖然您所有的工作負載服務可能都位於應用程式層內，但不同的服務可能會處理不同敏感程度的資料。在此情況下，根據您的控制需求，使用多個私有子網路分割應用程式層、在相同的 VPCs中不同 AWS 帳戶，或甚至 AWS 帳戶 在每個資料敏感度層級VPCs中不同。

對網路層的進一步考量是工作負載元件的行為一致性。繼續以上述範例說明，在應用程式層中，您可能有接受來自最終使用者或外部系統整合輸入的服務，而導向這些服務的輸入在本質上比對其他服務的輸入帶有更高風險。範例包括檔案上傳、要執行的程式碼指令碼、電子郵件掃描等。將這些服務放置在其自己的網路層中，有助於在其周圍建立更強大的隔離邊界，並可防止其獨特行為造成檢測系統中的誤報提醒。

在設計過程中，請考慮使用 AWS 受管服務如何影響您的網路拓撲。探索 Amazon VPC Lattice 等 服務如何協助簡化跨網路層的工作負載元件互通性。使用 時AWS Lambda，除非有特定原因，否則請在VPC子網路中部署 。判斷VPC端點的位置，並AWS PrivateLink可以簡化遵守限制網際網路閘道存取的安全政策。

實作步驟

資源

相關的最佳實務：

相關影片：

相關範例：