

# 基礎設施保護
<a name="infrastructure-protection"></a>

基礎設施保護包括符合最佳實務和組織或監管義務所必需的控制方法，例如深度防禦。這些方法的使用對於雲端的成功持續營運至關重要。

基礎設施保護是資訊安全計畫的關鍵部分。它可以確保工作負載中的系統和服務受到保護，以防止意外和未經授權的存取以及潛在漏洞。例如，您將定義信任邊界 (例如，網路和帳戶邊界)、系統安全組態和維護 (例如，強化、最小化和修補)、作業系統身分驗證和授權 (例如，使用者、金鑰和存取層級)，以及其他適當的政策強制執行點 (例如，Web 應用程式防火牆和/或 API 閘道)。

 **區域、可用區域、AWS Local Zones 和 AWS Outposts**

確定您熟悉區域、可用區域、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) 和 [AWS Outposts](https://aws.amazon.com/outposts/)，這些都是 AWS 安全全球基礎設施的元件。

AWS 具有區域概念，是我們在全世界將資料中心叢集化的實體位置。我們會將邏輯資料中心的每個群組稱為可用區域 (AZ)。每個 AWS 區域由地理區域內多個隔離且實際上分開的 AZ 組成。如果您有資料落地需求，則可以選擇靠近您所需位置的 AWS 區域。您保留對資料實際所在區域的完全控制和擁有權，這有助於符合您的區域合規和資料落地需求。每個 AZ 都有獨立的電源、冷卻和實體安全性。如果應用程式跨 AZ 分割，則您可以獲得更好的隔離和保護，讓您免於停電、雷擊、龍捲風、地震等問題。AZ 與任何其他 AZ 實際上相距一段有意義的距離 (數公里)，但它們彼此的距離都在 100 公里 (60 英里) 內。AWS 區域中的所有 AZ 都是使用完全冗餘的專用都會光纖 (在 AZ 之間提供高輸送量、低延遲網路)，搭配高頻寬、低延遲聯網來互連。AZ 之間的所有流量都是加密的。專注於高可用性的 AWS 客戶可以將其應用程式設計為在多個 AZ 中執行，以實現更高的容錯。AWS區域符合最高階的安全性、合規和資料保護。

 

AWS Local Zones 將運算、儲存、資料庫和其他精選 AWS 服務置於更靠近最終使用者的位置。使用 AWS Local Zones，您可以輕鬆執行要求最終使用者十毫秒延遲的高要求應用程式，例如媒體和娛樂內容創作、即時遊戲、水庫模擬、電子設計自動化和機器學習。每個 AWS Local Zone 位置都是 AWS 區域的延伸，您可以在其中執行對延遲敏感的應用程式，方法為使用地理上接近最終使用者的 Amazon EC2、Amazon VPC、Amazon EBS、Amazon File Storage 和 Elastic Load Balancing 等 AWS 服務。AWSLocal Zones 會提供高頻寬、保護本機工作負載與在 AWS 區域中執行的工作負載之間的連線，進而允許您透過相同的 API 和工具集無縫連線到各種區域內服務。

 

 AWS Outposts 可將原生 AWS 服務、基礎設施和操作模式用於幾乎所有的資料中心、主機代管空間或內部部署設施。您可以跨內部部署設施和 AWS 雲端使用相同的 AWS API、工具和基礎設施，以提供真正一致的混合體驗。AWSOutposts 專為連線環境而設計，而且可以用來支援由於低延遲或本機資料處理需求而必須保留在內部部署的工作負載。

在 AWS 中，有多種方法可用於基礎設施保護。下列幾節介紹如何使用這些方法。

**Topics**
+ [保護網路](protecting-networks.md)
+ [保護運算](protecting-compute.md)

# 保護網路
<a name="protecting-networks"></a>

您的員工和客戶中的使用者可以位於任何地方。您需要從傳統模式轉變，這些模式信任可以存取您網路的任何人和任何事物。當您遵循在所有層套用安全性的原則時，您可以使用[零信任](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)方法。零信任安全是一種模式，其中應用程式元件或微型服務被認為是彼此獨立的，並且沒有任何元件或微型服務信任彼此。

仔細規劃和管理網路設計，可奠定如何為工作負載內的資源提供隔離和邊界的基礎。由於工作負載中的許多資源在 VPC 中運作並繼承安全屬性，因此自動化支援的檢測和保護機制適用於設計非常重要。同樣地，對於在 VPC 外部操作的工作負載，使用純邊緣服務和/或無伺服器，最佳實務適用於更簡化的方法。如需無伺服器安全的特定指引，請參閱 [AWS Well-Architected 無伺服器應用程式聚焦](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)。

**Topics**
+ [SEC05-BP01 建立網路層](sec_network_protection_create_layers.md)
+ [SEC05-BP02 控制網路層內的流量流程](sec_network_protection_layered.md)
+ [SEC05-BP03 實作以檢查為基礎的保護](sec_network_protection_inspection.md)
+ [SEC05-BP04 自動化網路保護](sec_network_auto_protect.md)

# SEC05-BP01 建立網路層
<a name="sec_network_protection_create_layers"></a>

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

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

 **常見的反模式：**
+  您在單一 VPC 或子網路中建立所有資源。
+  您建構網路層時未考量資料敏感性需求、元件行為或功能。
+  您將 VPC 和子網路作為所有網路層考量的預設值，而且未考慮 AWS 受管服務對拓樸的影響。

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

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

## 實作指引
<a name="implementation-guidance"></a>

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

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

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

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

### 實作步驟
<a name="implementation-steps"></a>

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

1.  對於回應網際網路請求的元件，請考慮使用負載平衡器或其他代理來提供公有端點。探索如何使用 CloudFront、[Amazon API Gateway](https://aws.amazon.com/api-gateway/)、Elastic Load Balancing 和 [AWS Amplify](https://aws.amazon.com/amplify/) 等受管服務轉移安全控制，以託管公有端點。

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

1.  對於全受管 AWS 服務，例如 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Kinesis](https://aws.amazon.com/kinesis/) 或 [Amazon SQS](https://aws.amazon.com/sqs/)，請考慮使用 VPC 端點作為透過私有 IP 位址存取的預設方式。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL02 規劃您的網路拓撲](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) 
+  [PERF04-BP01 了解聯網如何影響效能](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html) 

 **相關影片：**
+  [AWS re:Invent 2023 - AWS 聯網基礎](https://www.youtube.com/watch?v=8nNurTFy-h4) 

 **相關範例：**
+  [VPC 範例](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html) 
+  [透過使用 AWS Fargate、AWS PrivateLink 和 Network Load Balancer，在 Amazon ECS 上私有存取容器應用程式](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) 
+  [使用 Amazon CloudFront 在 Amazon S3 儲存貯體中透過 VPC 提供靜態內容](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html) 

# SEC05-BP02 控制網路層內的流量流程
<a name="sec_network_protection_layered"></a>

 在網路層內，使用進一步的分隔方式，將流量限於每個工作負載所需的流程。首先，專注於控制網際網路或其他外部系統到工作負載與您的環境之間的流量 (*南北*流量)。接著查看不同元件和系統之間的流量 (*東西*流量)。

 **預期成果：**您只允許工作負載的元件所需的網路流程互相通訊，以及與其用戶端和其相依的任何其他服務進行通訊。您的設計考量到公有與私有輸入和輸出之間的比較、資料分類、區域法規以及協定需求等因素。在設計*最低權限原則*的過程中，盡可能採用點對點流程，而非網路對等。

 **常見的反模式：**
+  您採用以周邊為基礎的網路安全方法，僅控制網路層邊界處的流量流程。
+  您假設網路層內的所有流量都經過驗證和授權。
+  您只對輸入流量或輸出流量實施控制，而不是對兩者都實施。
+  您只仰賴工作負載元件和網路控制項來驗證和授權流量。

 **建立此最佳實務的優勢：**此實務有助於降低網路內發生未經授權行動的風險，並且為您的工作負載增加一層額外的授權。透過執行流量流程控制，您就可以限制安全事件的影響範圍，並加快偵測和回應速度。

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

## 實作指引
<a name="implementation-guidance"></a>

 雖然網路層有助於在具有類似功能、資料敏感性層級和行為的工作負載元件周圍建立邊界，但您可以利用一些技術進一步區隔這些層內的元件，藉此建立遵循最低權限原則且更精細的流量控制層級。在 AWS 內，網路層主要是根據 Amazon VPC 內的 IP 位址範圍使用子網路定義。您也可以使用不同的 VPC 定義網路層，其用途包括根據業務領域將微型服務環境分組等。使用多個 VPC 時，使用 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 調解路由。雖然這可在第 4 層 (IP 位址和連接埠範圍) 使用安全群組和路由表提供流量控制，但您可以使用 [AWS PrivateLink](https://aws.amazon.com/privatelink/)、[Amazon Route 53 Resolver DNS 防火牆](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)、[AWS Network Firewall](https://aws.amazon.com/network-firewall/) 和 [AWS WAF](https://aws.amazon.com/waf/) 等其他服務進一步控制流量。

 針對連線啟動方、連接埠、協定和網路層等方面，了解並清查工作負載的資料流程和通訊需求。評估可用於建立連線和傳輸資料的協定，以選取符合您的防護需求的協定 (例如 HTTPS 而非 HTTP)。在網路邊界和每一層內擷取這些需求。確定這些需求後，探索僅允許必要的流量流經每個連線點的選項。一開始在 VPC 內使用*安全群組*會是合適的選擇，因為安全群組可以連接至使用彈性網路介面 (ENI) 的資源，例如 Amazon EC2 執行個體、Amazon ECS 任務、Amazon EKS Pod 或 Amazon RDS 資料庫。與第 4 層防火牆不同的是，安全群組可以設置一項規則來依識別碼允許來自另一個安全群組的流量，藉此盡量減少群組內的資源隨時間改變所需的更新。您也可以使用安全群組的傳入和傳出規則來篩選流量。

 當流量在 VPC 之間移動時，針對簡便路由使用 VPC 對等或針對複雜路由使用 AWS Transit Gateway 的情況很常見。使用這些方法可讓來源和目的地網路的 IP 位址範圍之間的流量更順暢。然而，如果您的工作負載只需要讓流量在不同 VPC 中的特定元件之間流動，則可考慮使用 [AWS PrivateLink](https://aws.amazon.com/privatelink/) 的點對點連線。若要這樣做，請確定哪些服務應作為生產者，哪些服務應作為取用者。為生產者部署相容的負載平衡器，對應地開啟 PrivateLink，然後接受取用者的連線請求。接著從取用者的 VPC 指派私有 IP 位址給生產者服務，取用者可使用該位址提出後續請求。這種方法減少了對等網路的需求。在評估 PrivateLink 的過程中，請納入資料處理和負載平衡的成本。

 安全群組和 PrivateLink 有助於控制工作負載的元件之間的流程，而另一項重要的考量則是如何控制允許您的資源存取哪些 DNS 網域 (如有的話)。根據您 VPC 的 DHCP 組態而定，您可以考慮兩種不同的 AWS 服務來達成此目的。大多數客戶會使用在 CIDR 範圍的 \$12 位址供 VPC 使用的預設 Route 53 Resolver DNS 服務 (也稱為 Amazon DNS 伺服器或 AmazonProvidedDNS)。使用此方法，您可以建立 DNS 防火牆規則，並將它們與 VPC 關聯，以確定要對您提供的網域清單執行哪些動作。

 如果您不使用 Route 53 Resolver，或是想要用網域篩選以外更深入的檢測和流程控制功能來輔助 Resolver，請考慮部署 AWS Network Firewall。此服務會使用無狀態或有狀態規則來檢測個別封包，以確定是否拒絕或允許流量。您可以採用類似的方法，使用 AWS WAF 篩選前往公有端點的傳入 Web 流量。如需有關這些服務的進一步指引，請參閱 [SEC05-BP03 實作檢測型防護措施](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html)。

### 實作步驟
<a name="implementation-steps"></a>

1.  識別工作負載元件之間的必要資料流程。

1.  藉由對傳入和傳出流量採用深度防禦方法，套用多項控制，包括使用安全群組和路由表。  

1.  使用防火牆對 VPC 上輸入、輸出和 VPC 之間的網路流量定義精細的控制，例如 Route 53 Resolver DNS 防火牆、AWS Network Firewall 和 AWS WAF。考慮使用 [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) 集中設定和管理整個組織的防火牆規則。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL03-BP01 選擇如何劃分工作負載](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html) 
+  [SEC09-BP02 強制傳輸中加密](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html) 

 **相關文件：**
+  [VPC 的安全最佳實務](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) 
+  [AWS 網路最佳化秘訣](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/) 
+  [AWS 上的網路安全指引](https://aws.amazon.com/solutions/guidance/network-security-on-aws/) 
+  [在 AWS 雲端 中保護您 VPC 的傳出網路流量](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html) 

 **相關工具：**
+  [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) 

 **相關影片：**
+  [適用於許多 VPC 的 AWS Transit Gateway 參考架構](https://youtu.be/9Nikqn_02Oc) 
+  [使用 Amazon CloudFront、AWS WAF 和 AWS Shield 的應用程式加速和保護](https://youtu.be/0xlwLEccRe0) 
+  [AWS re:Inforce 2023：防火牆和設置位置](https://www.youtube.com/watch?v=lTJxWAiQrHM) 

# SEC05-BP03 實作以檢查為基礎的保護
<a name="sec_network_protection_inspection"></a>

 在網路層之間設定流量檢測點，以確保傳輸中的資料符合預期的類別和模式。 分析流量流程、中繼資料和模式，以協助更有效地識別、偵測及回應事件。

 **預期成果：**在網路層之間穿梭的流量會經過檢測和授權。 允許和拒絕決策取決於明確的規則、威脅情報以及偏離基準行為的程度。 流量越接近敏感資料，防護就會越嚴格。

 **常見的反模式：**
+  僅仰賴以連接埠和通訊協定為準的防火牆規則。未善加利用情報系統。
+  根據可能隨時變更的特定目前威脅模式制訂防火牆規則。
+  僅檢測從私有子網路傳輸到公有子網路的流量，或從公有子網路傳輸到網際網路的流量。
+  沒有網路流量基準點可比較，以識別行為異常。

 **建立此最佳實務的優勢：**檢測系統可讓您制訂智慧型規則，例如，只有在流量資料內存在特定條件時，才允許或拒絕流量。根據最新的威脅情報，隨著威脅態勢隨時間的變化，從 AWS 和 合作夥伴的受管規則集中受益。 這可減輕維護規則和研究入侵指標的工作負擔，進而降低誤報的可能性。

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

## 實作指引
<a name="implementation-guidance"></a>

 使用 AWS Network Firewall、 或其他[防火牆](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls)和[入侵預防系統](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) （IPS） 精細控制具狀態和無狀態的網路流量 AWS Marketplace ，您可以在 [Gateway Load Balancer （GWLB）](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) 後方部署。AWS Network Firewall 支援 [Suricata 相容](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html)開放原始碼IPS規格，以協助保護您的工作負載。

 AWS Network Firewall 和廠商解決方案都支援GWLB不同的內嵌檢查部署模型。 例如，您可以按每個VPC基準執行檢查、集中在檢查 中VPC，或在混合模型中部署，其中東西流量會流經檢查，VPC而網際網路傳入會按每個檢查VPC。 另一個考量是解決方案是否支援取消包裝 Transport Layer Security （TLS），可針對任一方向啟動的流量進行深度封包檢查。如需這些組態的相關資訊和深入資訊，請參閱 [AWS Network Firewall 最佳實務指南](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/)。

 如果您使用的是執行 out-of-band檢查的解決方案，例如從以半透明模式操作的網路介面進行封包資料的 pcap 分析，您可以設定[VPC流量鏡像 ](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)。鏡像流量會計入介面的可用頻寬，並且您需支付與非鏡像流量相同的資料傳輸費用。您可以查看這些設備的虛擬版本是否可在 上使用[AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking)，這可能支援在 後方的內嵌部署GWLB。

 對於透過 HTTP型通訊協定進行交易的元件，請使用 Web 應用程式防火牆 （WAF） 保護您的應用程式免受常見威脅。 [AWS WAF](https://aws.amazon.com/waf) 是一種 Web 應用程式防火牆，可讓您在傳送至 Amazon API Gateway、Amazon CloudFront AWS AppSync 或 Application Load Balancer 之前，監控並封鎖符合您可設定規則的 HTTP（S） 請求。當您評估 Web 應用程式防火牆的部署時，請考慮進行深度封包檢查，因為有些 會要求您在流量檢查TLS之前終止。若要開始使用 AWS WAF，您可以[AWS 受管規則](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group)搭配自己的 使用，或使用現有的[合作夥伴整合 ](https://aws.amazon.com/waf/partners/)。

 您可以使用 集中管理整個 AWS 組織中的 AWS Network Firewall AWS WAF AWS Shield Advanced、 和 Amazon VPC安全群組[AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)。  

## 實作步驟
<a name="implementation-steps"></a>

1.  判斷您是否可以廣泛地範圍檢查規則，例如透過檢查 VPC，或者是否需要更精細的VPC每種方法。

1.  對於內嵌檢測解決方案：

   1.  如果使用 AWS Network Firewall，請建立規則、防火牆政策和防火牆本身。上述這些設定完成後，您可以[將流量路由至防火牆端點](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)以啟用檢測。  

   1.  如果搭配 Gateway Load Balancer （GWLB） 使用第三方設備，請在一或多個可用區域中部署和設定您的設備。然後，建立您的 GWLB、端點服務、端點，並設定流量的路由。

1.  對於 out-of-band檢查解決方案：

   1.  在應鏡像傳入和傳出流量的介面上開啟VPC流量鏡像。您可以使用 Amazon EventBridge 規則來叫用 AWS Lambda 函數，以在建立新資源時開啟介面上的流量鏡像。將流量鏡像工作階段指向處理流量的設備前方的 Network Load Balancer。

1.  對於傳入 Web 流量解決方案：

   1.  若要設定 AWS WAF，請先設定 Web 存取控制清單 （web ACL）。Web ACL是具有序列處理預設動作 （ALLOW 或 DENY） 的規則集合，可定義您的 WAF 如何處理流量。您可以在 Web 中建立自己的規則和群組，或使用 AWS 受管規則群組ACL。

   1.  設定 Web ACL 後，請將 Web ACL與 AWS 資源 （例如 Application Load Balancer、APIGateway REST API或 CloudFront 分佈） 建立關聯，以開始保護 Web 流量。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [什麼是流量鏡像？](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) 
+  [使用第三方安全設備實作內嵌流量檢測](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html) 
+  [AWS Network Firewall 具有路由的範例架構](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html) 
+  [Gateway AWS Load Balancer 和 的集中式檢查架構 AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/) 

 **相關範例：**
+  [部署 Gateway Load Balancer 的最佳實務](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) 
+  [TLS 加密輸出流量和 的檢查組態 AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/) 

 **相關工具：**
+  [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips) 

# SEC05-BP04 自動化網路保護
<a name="sec_network_auto_protect"></a>

 使用 DevOps實務自動化網路保護的部署，例如*基礎設施，例如程式碼* （IaC和 CI/CD 管道。 這些實務可協助您透過版本控制系統追蹤網路防護措施中的變更、縮短部署變更所需的時間，並協助您偵測網路防護措施是否偏離所需的組態。  

 **預期成果：**您會使用範本定義網路防護措施，並將其遞交至版本控制系統中。 當進行新的變更時，自動化管道會因此而啟動，以協調其測試和部署。 設置了政策檢查和其他靜態測試，可在部署前驗證變更。 您可以將變更部署到模擬環境中，以驗證控制是否如預期運作。 控制得到核准後，也會自動將其部署到實際執行環境中。

 **常見的反模式：**
+  仰賴個別工作負載團隊各自定義自己的整套網路堆疊、防護措施和自動化程序。 未集中發佈網路堆疊和防護措施的標準層面，供工作負載團隊取用。
+  仰賴中央網路團隊來定義網路、防護措施和自動化的所有層面。 未將網路堆疊和防護措施的工作負載特定層面委派給該工作負載的團隊。
+  集中和委派的情況在網路團隊與工作負載團隊之間達到適當的平衡，但未對 IaC 範本和 CI/CD 管道整體實施一致的測試和部署標準。 未在工具中擷取所需的組態，以致無法檢查範本是否遵循規範。

 **建立此最佳實務的優勢：**使用範本定義網路防護措施，可讓您使用版本控制系統追蹤和比較一段時間的變化。 使用自動化方式測試和部署變更可建立標準化和可預測性，提高成功部署的機會，並減少重複的手動組態。

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

## 實作指引
<a name="implementation-guidance"></a>

 [SEC05-BP02 控制網路層內的流量和](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html) [SEC05-BP03 實作檢查型保護](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html)中所述的一些網路保護控制項，隨附可依據最新威脅情報自動更新的受管規則系統。 保護 Web 端點的範例包括[AWS WAF 受管規則](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html)和[AWS Shield Advanced 自動應用程式層DDoS緩解。](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html)使用 [AWS Network Firewall 受管規則群組](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html)隨時掌握有關信譽不良網域清單和威脅特徵的最新資訊。

 除了受管規則之外，我們建議您使用 DevOps 實務來自動部署網路資源、保護和您指定的規則。 您可以在 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 或您選擇的其他*基礎設施即程式碼* (IaC) 工具中擷取這些定義，將它們遞交至版本控制系統，並使用 CI/CD 管道部署它們。 使用此方法取得 DevOps 管理網路控制項的傳統優點，例如更可預測的版本、使用 等工具進行自動化測試[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)，以及偵測部署環境與所需組態之間的偏離。

 根據您在 [SEC05-BP01 建立網路層](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html) 中所做的決策，您可能有建立專用VPCs於輸入、輸出和檢查流程的中央管理方法。 如[AWS 安全參考架構 （AWS SRA）](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture) 中所述，您可以在VPCs專用[網路基礎設施帳戶中](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)定義這些屬性。 您可以使用類似的技術集中定義其他帳戶中工作負載VPCs使用的 、其安全群組、 AWS Network Firewall 部署、Route 53 Resolver 規則和DNS防火牆組態，以及其他網路資源。 您可以透過 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) 將這些資源與其他帳戶共用。 使用此方法，您可以簡化對網路控制的自動測試並將該控制部署到網路帳戶的程序，同時只需管理一個目的地。 您可以在混合模式中，透過集中部署和共用特定控制，並將其他控制委派給個別工作負載團隊及其各自的帳戶，來執行上述操作。

## 實作步驟
<a name="implementation-steps"></a>

1.  建立擁有權來規範要集中定義網路和防護措施的哪些方面，以及您的工作負載團隊可以維護哪些方面。

1.  建立環境來測試變更，並將變更部署至您的網路及其防護措施。 例如，使用網路測試帳戶和網路實際執行帳戶。

1.  確定如何在版本控制系統中儲存和維護範本。 將儲存中央範本的儲存庫與工作負載儲存庫分開，而工作負載範本可以儲存在專屬於該工作負載的儲存庫中。

1.  建立 CI/CD 管道以測試和部署範本。 定義測試以檢查是否有組態錯誤，以及範本是否符合您公司的標準。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC01-BP06 自動化標準安全控制的部署](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls) 

 **相關文件：**
+  [AWS Security Reference Architecture - 網路帳戶](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) 

 **相關範例：**
+  [AWS 部署管道參考架構](https://pipelines.devops.aws.dev/) 
+  [NetDevSecOps 將 AWS 網路部署現代化](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/) 
+  [將 AWS CloudFormation 安全測試與 AWS Security Hub CSPM 和 AWS CodeBuild 報告整合](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/) 

 **相關工具：**
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 
+  [cfn\$1nag](https://github.com/stelligent/cfn_nag) 

# 保護運算
<a name="protecting-compute"></a>

運算資源包括 EC2 執行個體、容器、AWS Lambda 函數、資料庫服務、IoT 裝置等。這些運算資源類型中的每一種都需要不同的方法來保護。不過，這些運算資源類型共用您需要考慮的常用策略：深度防禦、漏洞管理、減少受攻擊面、組態和操作的自動化，以及遠距離執行動作。在本節中，您將找到有關保護關鍵服務之運算資源的一般指引。對於使用的每項 AWS 服務，請您務必檢查服務文件中的特定安全建議。

**Topics**
+ [SEC06-BP01 執行漏洞管理](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 從強化的影像佈建運算](sec_protect_compute_hardened_images.md)
+ [SEC06-BP03 減少手動管理和互動式存取](sec_protect_compute_reduce_manual_management.md)
+ [SEC06-BP04 驗證軟體完整性](sec_protect_compute_validate_software_integrity.md)
+ [SEC06-BP05 自動化運算保護](sec_protect_compute_auto_protection.md)

# SEC06-BP01 執行漏洞管理
<a name="sec_protect_compute_vulnerability_management"></a>

經常掃描和修補程式碼、相依性和基礎設施中的漏洞，以協助防禦新的威脅。

 **預期成果：**您擁有解決方案，可持續掃描工作負載以找出軟體漏洞、潛在缺陷和意料之外的網路暴露情形。您已建立流程和程序，可根據風險評估標準來識別、排定優先順序和修復這些漏洞。此外，您已為運算執行個體實作自動修補管理。您的漏洞管理計畫已整合至您的軟體開發生命週期，並且備有解決方案可在 CI/CD 管道中掃描原始程式碼。

 **常見的反模式：**
+  沒有漏洞管理計畫。
+  執行系統修補而不考慮嚴重性或避免風險。
+  使用已過廠商提供的結束生命週期日期的軟體。
+  在分析程式碼的安全問題之前將其部署至生產環境。

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

## 實作指引
<a name="implementation-guidance"></a>

 漏洞管理是維護安全可靠的雲端環境的關鍵層面。它是一整套全方位的程序，包括安全性掃描、識別問題並排定優先順序，以及修補程式操作，以解決找到的漏洞。自動化在此過程中扮演關鍵角色，因為它有助於持續掃描工作負載，以找出潛在問題和意料之外的網路暴露情形，以及提供補救措施。

 [AWS 共同責任模型](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html)是支援漏洞管理的基本概念。根據此模型，AWS 負責保護基本的基礎設施，包括執行 AWS 服務的硬體、軟體、網路和設備。另一方面，您負責保護與 Amazon EC2 執行個體和 Amazon S3 物件等服務相關聯的資料、安全組態和管理任務。

 AWS 提供一系列服務來支援漏洞管理計畫。[Amazon Inspector](https://aws.amazon.com/inspector/) 會持續掃描 AWS 工作負載，以找出軟體漏洞和意料之外的網路存取，而 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) 會協助管理所有 Amazon EC2 執行個體的修補工作。這些服務可與 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 整合，這個雲端安全狀態管理服務可自動化 AWS 安全檢查、將安全提醒集中在一起，並提供全方位的視角來了解組織的安全狀態。此外，[Amazon CodeGuru 安全工具](https://aws.amazon.com/codeguru/)會在開發階段使用靜態程式碼分析，以識別 Java 和 Python 應用程式中的潛在問題。

 透過將漏洞管理實務納入軟體開發生命週期，您就可以在漏洞進入實際執行環境之前主動解決漏洞，從而降低安全事件的風險，並將漏洞可能造成的影響降至最低。

### 實作步驟
<a name="implementation-steps"></a>

1.  **了解共同責任模型：**檢閱 AWS 共同責任模型，以了解您在雲端保護工作負載和資料的責任。AWS 負責保護基礎雲端基礎設施，而您負責保護您使用的應用程式、資料和服務。

1.  **實作漏洞掃描**：設定漏洞掃描服務 (例如 Amazon Inspector) 以自動掃描您的運算執行個體 (例如，虛擬機器、容器或無伺服器函數)，藉此找出軟體漏洞、潛在缺陷和意料之外的網路暴露情形。

1.  **建立漏洞管理程序：**定義流程和程序來識別漏洞、排定優先順序和修復漏洞。這可能包括設定定期漏洞掃描排程、建立風險評估條件，以及根據漏洞嚴重性定義修復時間表。

1.  **設定修補程式管理：**使用修補程式管理服務來自動化修補運算執行個體的程序，包括作業系統和應用程式。您可以設定服務來掃描執行個體以找出缺少的修補程式，並依照排程自動進行安裝。考慮使用 AWS Systems Manager Patch Manager 來提供此功能。

1.  **設定惡意軟體防護：**實作各種機制來偵測您環境中的惡意軟體。例如，您可以使用 [Amazon GuardDuty](https://aws.amazon.com/guardduty/) 等工具來分析和偵測 EC2 和 EBS 磁碟區中的惡意軟體並發出警示。GuardDuty 也可以掃描新上傳到 Amazon S3 的物件，以找出潛藏的惡意軟體或病毒，並採取行動來隔離它們，以防它們進入下游程序。

1.  **在 CI/CD 管道中整合漏洞掃描：**如果您使用 CI/CD 管道進行應用程式部署，請將漏洞掃描工具整合到您的管道中。Amazon CodeGuru 安全工具和開放原始碼選項等工具可掃描您的原始程式碼、相依性和成品，以找出潛在的安全問題。

1.  **設定安全監控服務：**設定安全監控服務 (例如 AWS Security Hub CSPM)，以全面檢視多種雲端服務的安全狀態。監控服務應從各種不同的來源收集安全調查結果，並以標準化格式呈現，以更容易排定優先順序和修復。

1.  **實作 Web 應用程式滲透測試**：如果您的應用程式是 Web 應用程式，且您的組織具備必要的技能或能夠取得外部協助，請考慮實作 Web 應用程式滲透測試，以找出應用程式中的潛在漏洞。

1.  **利用基礎設施即程式碼實現自動化**：使用基礎設施即程式碼 (IaC) 工具 (例如 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)) 將資源的部署和組態自動化，包括上述安全服務在內。此做法可協助您在多個帳戶和環境中建立更一致且標準化的資源架構。

1.  **監控並持續改進**：持續監控漏洞管理計畫的有效性，並視需要改進。檢閱安全調查結果、評估補救措施的有效性，並據以調整您的程序和工具。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Lambda 的安全概觀](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 
+ [ Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ 透過全新的 Amazon Inspector 改進、自動化雲端工作負載的漏洞管理](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ 使用 Amazon Inspector 和 AWS Systems Manager 自動化 AWS 中的漏洞管理和修復 – 第 1 部分](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)

 **相關影片：**
+  [保護無伺服器和容器服務的安全](https://youtu.be/kmSdyN9qiXY) 
+  [Amazon EC2 執行個體中繼資料服務的安全最佳實務](https://youtu.be/2B5bhZzayjI) 

# SEC06-BP02 從強化的影像佈建運算
<a name="sec_protect_compute_hardened_images"></a>

 透過從強化的映像部署，就可減少意外存取執行時期環境的機會。僅從受信任的登錄檔取得執行時期相依項 (例如容器映像和應用程式庫)，並驗證其簽章。建立自己的私有登錄檔來儲存受信任的映像和程式庫，以供您的建置和部署程序使用。

 **預期成果：**您的運算資源是從強化的基準映像佈建。您只會從受信任的登錄檔擷取外部相依項 (例如容器映像和應用程式庫)，並驗證其簽章。這些都會儲存在私有登錄檔中，以供您的建置和部署程序參考。您會定期掃描和更新映像與相依項，以協助防禦任何新發現的漏洞。

 **常見的反模式：**
+  從受信任的登錄檔取得映像和程式庫，但未先驗證其簽章或執行漏洞掃描，即逕行使用。
+  強化映像，但未定期測試映像以確認是否有新的漏洞或更新到最新版本。
+  安裝或未移除在預期的映像生命週期內不需要的軟體套件。
+  僅仰賴修補來讓實際執行運算資源保持最新狀態。單單是修補就仍有可能導致運算資源在經過一段時間後，偏離強化的標準。修補也可能無法移除威脅行為者在安全事件期間安裝的惡意軟體。

 **建立此最佳實務的優勢：**強化映像有助於減少您的執行時期環境中可能成為未經授權使用者或服務意外存取路徑的數目。此外還能在發生任何意外存取的情況時，縮小影響的範圍。

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

## 實作指引
<a name="implementation-guidance"></a>

 若要強化您的系統，請從作業系統、容器映像和應用程式庫的最新版本開始。套用已知問題的修補程式。移除任何不需要的應用程式、服務、裝置驅動程式、預設使用者和其他憑證，藉此盡可能縮減系統規模。採取任何其他必要的行動，例如，停用連接埠以建立只有工作負載所需資源和功能的環境。以此為基準，您就可以安裝用於監控工作負載或管理漏洞等操作所需的軟體、代理程式或其他程序。

 您可以使用受信任來源提供的指南來減輕強化系統的負擔，例如[網際網路安全中心 ](https://www.cisecurity.org/)（CIS） 和國防資訊系統局 （DISA） [安全技術實作指南 （STIGs）](https://public.cyber.mil/stigs/)。我們建議您從 AWS 或 APN合作夥伴發佈的 [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) （AMI） 開始，並使用AWS [EC2 Image Builder](https://aws.amazon.com/image-builder/) 根據適當的 CIS和 STIG控制項組合來自動化組態。

 雖然有可用的強化映像和EC2映像建置器配方會套用 CIS或 DISASTIG建議，但您可能會發現其組態阻止軟體順利執行。在這種情況下，您可以從非強化基本映像開始，安裝軟體，然後逐步套用CIS控制項來測試其影響。對於防止軟體執行的任何CIS控制項，請測試您是否可以在 DISA 中實作更精細的強化建議。追蹤您能夠成功套用的不同CIS控制項和DISASTIG組態。使用這些選項，相應地在 Image Builder 中定義您的EC2映像強化配方。

 對於容器化工作負載，來自 Docker 的強化影像可在 [Amazon Elastic Container Registry （ECR）](https://aws.amazon.com/ecr/) [公有儲存庫 ](https://gallery.ecr.aws/docker)上取得。您可以使用 EC2 Image Builder 搭配 來強化容器映像AMIs。

 與作業系統和容器映像類似，您可以透過 pip、npm、Maven 和 等工具，從公有儲存庫取得程式碼套件 （或*程式庫* ） NuGet。我們建議您藉由整合私有儲存庫 (例如在 [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 內) 與受信任的公有儲存庫來管理程式碼套件。此整合可以 up-to-date為您處理擷取、儲存和保留套件。然後，您的應用程式建置程序可以使用 Software Composition Analysis （SCA）、Static Application Security Testing （SAST） 和 Dynamic Application Security Testing （） 等技術，取得並測試這些套件的最新版本DAST。

 對於使用 的無伺服器工作負載 AWS Lambda， 可簡化使用 [Lambda 層管理套件相依性。](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)使用 Lambda 層設定一組跨不同函數共用的標準相依項，並放入獨立的封存中。您可以透過自己的建置程序來建立和維護層，為您的函數提供保留 的中央方式 up-to-date。

## 實作步驟
<a name="implementation-steps"></a>
+  強化作業系統。使用信任來源的基本映像作為建置強化 的基礎AMIs。使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/) 協助自訂安裝在映像上的軟體。
+  強化容器化資源。設定容器化資源以符合安全最佳實務。使用容器時，請在建置管道中實作[ECR映像掃描](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)，並定期針對映像儲存庫實作映像掃描，以便在CVEs容器中尋找。  
+  搭配 使用無伺服器實作時 AWS Lambda，請使用 [Lambda 層](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)來分隔應用程式函數程式碼和共用相依程式庫。為 Lambda 設定[程式碼簽署](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)，確保只有受信任的程式碼能夠在您的 Lambda 函數中執行。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [OPS05-BP05 執行修補程式管理](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html) 

 **相關影片：**
+  [深入探索 AWS Lambda 安全性](https://www.youtube.com/watch?v=FTwsMYXWGB0) 

 **相關範例：**
+  [AMI使用 EC2 Image Builder 快速建置 STIG合規](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/) 
+  [建置更好的容器映像](https://aws.amazon.com/blogs/containers/building-better-container-images/) 
+  [使用 Lambda 層簡化開發流程](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/) 
+  [使用無伺服器架構開發和部署 AWS Lambda 層](https://github.com/aws-samples/aws-serverless-lambda-layers) 
+  [使用開放原始碼 SCA、 SAST和 DAST 工具建置 end-to-end AWS DevSecOps CI/CD 管道](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/) 

# SEC06-BP03 減少手動管理和互動式存取
<a name="sec_protect_compute_reduce_manual_management"></a>

 盡可能使用自動化方式來執行部署、組態、維護和調查任務。在發生緊急程序的情況下或在安全 (沙盒) 環境中無法啟用自動化時，請考慮手動存取運算資源。

 **預期成果：**程式化的指令碼和自動化文件 (執行手冊) 會擷取運算資源上獲得授權的動作。這些執行手冊會自動啟動、透過變更偵測系統啟動，或是在需要人為判斷時手動啟動。只有在無法啟用自動化的緊急情況下，才能直接存取運算資源。所有手動活動都會加以記錄並納入審查程序中，以持續改善您的自動化功能。

 **常見的反模式：**
+  透過 SSH 或 RDP 等協定互動式存取 Amazon EC2 執行個體。
+  維護個別使用者登入，例如 `/etc/passwd` 或 Windows 本機使用者。
+  在多個使用者之間共用密碼或私有金鑰以存取執行個體。
+  手動安裝軟體和建立或更新組態檔案。
+  手動更新或修補軟體。
+  登入執行個體以對問題進行疑難排解。

 **建立此最佳實務的優勢：**透過自動化方式執行步驟，有助於降低意外變更和組態錯誤伴隨的操作風險。不再使用 Secure Shell (SSH) 和遠端桌面協定 (RDP) 進行互動式存取，因此縮小了運算資源的存取範圍。這樣也消除了常見的未經授權動作路徑。在自動化文件和程式化指令碼中寫入運算資源管理任務，提供了以更精細的細節程度定義和稽核完整的授權活動範圍的機制。

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

## 實作指引
<a name="implementation-guidance"></a>

 登入執行個體是系統管理的傳統方法。安裝伺服器作業系統後，使用者通常會手動登入以設定系統並安裝所需的軟體。在伺服器的生命週期內，使用者可能會登入以執行軟體更新、套用修補程式、變更組態及對問題進行疑難排解。

 但是，手動存取伴隨著許多風險。它需要伺服器監聽請求，例如 SSH 或 RDP 服務，而這些服務可能成為未經授權的存取路徑。此外，它也會增加執行手動步驟時發生人為錯誤的風險。這些都可能導致工作負載事件、資料損壞或銷毀，或其他安全問題。人為存取也需要設置防護措施來防止憑證共用行為，因而產生額外的管理負擔。  

 為了降低這些風險，您可以實作代理程式型遠端存取解決方案，例如 [AWS Systems Manager](https://aws.amazon.com/systems-manager/)。AWS Systems ManagerAgent (SSM Agent) 會啟動加密通道，因此不需仰賴偵聽外部發出的請求。請考慮設定 SSM Agent 以[透過 VPC 端點建立此通道](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)。

 Systems Manager 可讓您精細控制與受管執行個體互動的方式。您可以定義要執行的自動化程序、誰可以執行它們，以及何時可以執行。Systems Manager 不需互動式存取執行個體，即可套用修補程式、安裝軟體及進行組態變更。Systems Manager 還可提供對遠端 Shell 的存取權，並將工作階段期間調用的每個命令及其輸出記錄到日誌和 [Amazon S3](https://aws.amazon.com/s3/)。[AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 會記錄 Systems Manager API 的調用以供檢測。

### 實作步驟
<a name="implementation-steps"></a>

1.  在 Amazon EC2 執行個體上[安裝 AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) (SSM Agent)。查看是否包含 SSM Agent，且它會作為基本 AMI 組態的一部分自動啟動。

1.  確認與您的 EC2 執行個體設定檔關聯的 IAM 角色是否包含 `AmazonSSMManagedInstanceCore` [受管 IAM 政策](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html)。

1.  停用執行個體上執行的 SSH、RDP 及其他遠端存取服務。您可以藉由執行啟動範本的使用者資料區段中設定的指令碼，或使用 EC2 Image Builder 等工具建置自訂 AMI，以執行此操作。

1.  確認適用於 EC2 執行個體的安全群組輸入規則不允許在連接埠 22/tcp (SSH) 或連接埠 3389/tcp (RDP) 上的存取。使用 AWS Config 等服務實作偵測，並對設定錯誤的安全群組發出提醒。

1.  定義適當的自動化、執行手冊，並在 Systems Manager 中執行命令。使用 IAM 政策定義誰可以執行這些動作，以及允許執行這些動作的條件。在非實際執行環境中完整測試這些自動化程序。在必要時調用這些自動化程序，而非以互動方式存取執行個體。

1.  在必要時，使用 [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 提供對執行個體的互動式存取。開啟工作階段活動日誌記錄，以在 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 或 [Amazon S3](https://aws.amazon.com/s3/) 中維護稽核記錄。  

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL08-BP04 使用不可變基礎設施進行部署](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html) 

 **相關範例：**
+  [使用 AWS Systems Manager 取代 SSH 存取以減輕管理和安全負擔](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) 

 **相關工具：**
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 

 **相關影片：**
+  [在 AWS Systems Manager Session Manager 中控制使用者工作階段對執行個體的存取權](https://www.youtube.com/watch?v=nzjTIjFLiow) 

# SEC06-BP04 驗證軟體完整性
<a name="sec_protect_compute_validate_software_integrity"></a>

 使用加密驗證來驗證工作負載所使用之軟體成品 (包括映像) 的完整性。 以加密方式簽署您的軟體，以防範未經授權的變更在您的運算環境內執行。

 **預期成果：**所有成品都是從受信任的來源取得。廠商網站憑證經過驗證。 下載的成品已藉由簽章以加密方式驗證。自有軟體會由您的運算環境以加密方式簽署和驗證。

 **常見的反模式：**
+  信任信譽良好的廠商網站來取得軟體成品，但忽略憑證到期通知。 未先確認憑證是否有效，即逕行下載。
+  驗證廠商網站憑證，但未以加密方式驗證從這些網站下載的成品。
+  僅仰賴摘要或雜湊值來驗證軟體完整性。 雜湊值確定成品的原版未經修改，但未驗證其來源。
+  即使僅在您自己的部署中使用，也未簽署自有軟體、程式碼或程式庫。  

 **建立此最佳實務的優勢：**驗證您的工作負載所依賴之成品的完整性，有助於防止惡意軟體進入您的運算環境。 簽署您的軟體有助於防範運算環境中發生未經授權執行的情況。  藉由簽署和驗證程式碼來保護您的軟體供應鏈。

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

## 實作指引
<a name="implementation-guidance"></a>

 作業系統映像、容器映像和程式碼成品通常在散佈時會提供完整性檢查，例如透過摘要或雜湊值。 這些檢查可讓用戶端運算自有的承載雜湊值並確認其與發佈的雜湊值相同，藉此驗證完整性。 雖然這些檢查有助於驗證承載未遭到竄改，但不會驗證承載來自原始出處 (其*來源*)。 驗證來源需要使用受信任的授權機構發出的憑證來數位簽署成品。

 如果您在工作負載中使用下載的軟體或成品，請檢查提供者是否提供了用於驗證數位簽章的公有金鑰。 以下一些範例說明 AWS 如何提供公有金鑰，以及如何驗證我們發佈的軟體：
+  [EC2 Image Builder：驗證安裝下載的 AWS TOE簽章](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html) 
+  [AWS Systems Manager：驗證SSM客服人員的簽章](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html) 
+  [Amazon CloudWatch：驗證 CloudWatch 客服人員套件的簽章](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html) 

 將數位簽章驗證納入您用於取得和強化影像的程序，如 [SEC06-BP02 佈建來自強化影像的運算](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)中所述。

 您可以使用 [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) 協助您管理簽章驗證，以及您自有軟體和成品的程式碼簽署生命週期。 [AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) 兩者都提供與 Signer 的整合，可用來驗證程式碼和映像的簽章。 您可以使用「資源」區段中的範例，將 Signer 納入您的持續整合和交付 (CI/CD) 管道中，以便自動驗證簽章及自動簽署自有程式碼和映像。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [容器的加密簽署](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/) 
+  [使用 協助保護容器映像建置管道的最佳實務 AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/) 
+  [宣佈使用 AWS Signer 和 Amazon 進行容器映像簽署 EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/) 
+  [設定 的程式碼簽署 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) 
+  [Lambda 程式碼簽署的最佳實務和進階模式](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/) 
+  [使用 AWS Certificate Manager Private CA AWS Key Management Service 和非對稱金鑰進行程式碼簽署](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) 

 **相關範例：**
+  [使用 Amazon CodeCatalyst 和 自動化 Lambda 程式碼簽署 AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/) 
+  [使用 簽署和驗證OCI偽影 AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/) 

 **相關工具：**
+  [AWS Lambda](https://aws.amazon.com/lambda/) 
+  [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) 
+  [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) 
+  [AWS Key Management Service](https://aws.amazon.com/kms/) 
+  [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 

# SEC06-BP05 自動化運算保護
<a name="sec_protect_compute_auto_protection"></a>

 自動化運算保護操作以減少人工介入的需求。使用自動化掃描偵測運算資源內的潛在問題，並透過自動化的程式化回應或機群管理操作進行修復。 將自動化納入 CI/CD 程序，以部署具有最新相依項且值得信賴的工作負載。

 **預期成果：**自動化系統會執行運算資源的所有掃描和修補工作。您會使用自動化的驗證方式檢查軟體映像和相依項來自受信任的來源，且未遭到竄改。透過自動化方式檢查工作負載是否有最新的相依項，並且簽署工作負載以在 AWS 運算環境中建立可靠性。 偵測到不合規資源時，系統會啟動自動補救措施。  

 **常見的反模式：**
+  遵循不可變的基礎設施實務，但未備妥解決方案來因應緊急修補或取代實際執行系統。
+  使用自動化方式修復設定錯誤的資源，但未設置手動覆寫機制。 可能會發生需要調整需求的情況，且您可能需要暫停自動化程序，直到完成這些變更為止。

 **建立此最佳實務的優勢：**自動化可降低未經授權存取和使用您的運算資源的風險。 它有助於防止錯誤的組態進入實際執行環境，並且在發生組態錯誤時偵測到該錯誤並加以修復。 自動化還可協助偵測未經授權存取和使用運算資源的情況，進而縮短您回應的時間。 如此還能進一步縮小問題的整體影響範圍。

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

## 實作指引
<a name="implementation-guidance"></a>

 您可以套用「安全支柱」實務中所述的自動化方式，以保護您的運算資源。[SEC06-BP01 執行漏洞管理](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html)說明如何在您的 CI/CD 管道中使用 [Amazon Inspector](https://aws.amazon.com/inspector/)，以及如何運用它持續掃描您的執行時期環境，以找出已知的通用漏洞披露 (CVE)。 您可以透過自動化執行手冊，使用 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 套用修補程式或從全新映像重新部署，讓您的運算機群隨時擁有最新的軟體和程式庫。 使用這些技術可減少對手動程序和互動式存取運算資源的需求。 請參閱 [SEC06-BP03 減少手動管理和互動式存取](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html)以了解更多資訊。

 自動化在部署值得信賴的工作負載方面，也發揮了舉足輕重的作用，如 [SEC06-BP02 從強化的映像佈建運算](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)和 [SEC06-BP04 驗證軟體完整性](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html)中所述。 您可以使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/)、[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)、[AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 和 [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) 等服務來下載、驗證、建構和儲存強化且經核准的映像和程式碼相依項。  除了 Inspector 之外，這些都可在 CI/CD 程序中發揮作用。因此，只有在確認工作負載的相依項為最新狀態且來自受信任的來源時，工作負載才會進入實際執行環境。 您的工作負載也會經過簽署，如此一來，[AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 等 AWS 運算環境就能在確認其未遭到竄改後，再允許其執行。

 除了這些預防性控制之外，您還可以在偵測控制中針對運算資源使用自動化。 舉例來說，[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 提供 [NIST 800-53 Rev. 5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html) 標準，其中包括如下述的檢查：[[EC2.8] EC2 執行個體應使用執行個體中繼資料服務第 2 版 (IMDSv2)](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8)。 IMDSv2 會使用工作階段驗證技術，封鎖包含 X-Forwarded-For HTTP 標頭以及網路 TTL 1 的請求，藉此阻止來自外部來源的流量擷取有關 EC2 執行個體的資訊。Security Hub CSPM 中的這項檢查可偵測 EC2 執行個體何時使用 IMDSv1，並實施自動補救措施。請參閱 [SEC04-BP04 針對不合規資源實施補救措施](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html)，進一步了解自動化偵測和補救措施。

### 實作步驟
<a name="implementation-steps"></a>

1.  使用 [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html) 自動建立安全、合規且強化的 AMI。 您可以產生映像，並於當中納入來自 Center for Internet Security (CIS) Benchmarks 的控制，或來自基本 AWS 和 APN 合作夥伴映像的安全技術實作指南 (STIG) 標準。

1.  自動化組態管理。藉由使用組態管理服務或工具，在您的運算資源中自動強制執行和驗證安全組態。  

   1.  使用 [AWS Config](https://aws.amazon.com/config/) 自動化組態管理 

   1.  使用 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 自動化安全和合規狀態管理 

1.  自動修補或取代 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。AWSSystems Manager Patch Manager 可自動執行透過安全相關及其他更新來修補受管執行個體的程序。您可以使用修補程式管理員以套用適用於作業系統和應用程式的修補程式。

   1.  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 

1.  自動掃描運算資源以找出通用漏洞披露 (CVE)，並將安全掃描解決方案內嵌於您的建置管道中。

   1.  [Amazon Inspector](https://aws.amazon.com/inspector/) 

   1.  [ECR 映像掃描](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) 

1.  考慮使用 Amazon GuardDuty 執行自動化惡意軟體和威脅偵測，以保護運算資源。GuardDuty 還可在 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 函數於您的 AWS 環境中調用時，識別潛在問題。  

   1.  [Amazon GuardDuty](https://aws.amazon.com/guardduty/) 

1.  考慮 AWS 合作夥伴解決方案。AWS合作夥伴提供領先業界的產品，這些產品與您內部部署環境中的現有控制相當、相同或互相整合。這些產品可補充現有的 AWS 服務，讓您在雲端和內部部署環境中部署全方位的安全架構，以及擁有更流暢的體驗。

   1.  [基礎設施安全性](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC01-BP06 自動部署標準安全控制](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html) 

 **相關文件：**
+  [在您的 AWS 基礎設施內充分利用 IMDSv2 的優勢並停用 IMDSv1](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/) 

 **相關影片：**
+  [Amazon EC2 執行個體中繼資料服務的安全最佳實務](https://youtu.be/2B5bhZzayjI) 