SEC05-BP01 建立網路層 - AWS Well-Architected 架構
實作指引資源

SEC05-BP01 建立網路層

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

預期成果：您的網路層是整體安全深度防禦方法的一部分，可與工作負載的身分驗證和授權策略相輔相成。根據資料敏感性和存取需求妥善區分的網路層，且具有適當的流量流程和控制機制。

常見的反模式：

  • 您在單一 VPC 或子網路中建立所有資源。

  • 您建構網路層時未考量資料敏感性需求、元件行為或功能。

  • 您將 VPC 和子網路作為所有網路層考量的預設選項，而且未考慮 AWS 受管服務對拓樸的影響。

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

未建立此最佳實務時的風險暴露等級：高

實作指引

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

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

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

在設計過程中，請考慮使用 AWS 受管服務對網路拓樸的影響。探索像是 Amazon VPC Lattice 等服務如何讓您更輕鬆地跨網路層實現工作負載元件的互通性。使用 AWS Lambda 時，請在您的 VPC 子網路中部署，除非受到特定原因限制而無法這樣做。 判斷 VPC 端點和 AWS PrivateLink 可在哪些地方簡化遵循限制網際網路閘道存取的安全政策。

實作步驟

  1. 檢閱您的工作負載架構。根據元件和服務提供的功能、處理的資料敏感性以及其行為，將其邏輯分組。

  2. 對於回應網際網路請求的元件，請考慮使用負載平衡器或其他 Proxy 來提供公有端點。探索如何使用像是 CloudFront、Amazon API Gateway、Elastic Load Balancing 和 AWS Amplify 等受管服務轉移安全控制措施，以託管公有端點。

  3. 對於在運算環境中執行的元件 (例如 Amazon EC2 執行個體、AWS Fargate 容器或 Lambda 函數)，一開始即根據您的群組將這些元件部署到私有子網路中。

  4. 對於全受管 AWS 服務，例如 Amazon DynamoDB、Amazon Kinesis 或 Amazon SQS，請考慮使用 VPC 端點作為透過私有 IP 位址存取的預設方式。

資源

相關的最佳實務：

相關影片：

相關範例：