周邊安全性 - AWS 規定指引
在單一網路帳戶中部署周邊服務在個別應用程式帳戶中部署周邊服務適用於周邊安全組態的其他 AWS 服務

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

周邊安全性

通過進行簡短的調查來影響 AWS 安全參考架構（AWS SRA）的 future。

本節擴展 AWS SRA 指引，以提供在 AWS 上建置安全周邊的建議。本節深入探討 AWS 周邊服務，以及它們如何融入 AWS SRA 定義的 OU。

在本指引的內容中，周邊定義為應用程式連線至網際網路的邊界。周邊的安全性包括安全內容交付、應用程式層保護和分散式拒絕服務 (DDoS) 緩解措施。AWS 周邊服務包括 Amazon CloudFront、AWS WAF、AWS Shield、Amazon Route 53 和 AWS Global Accelerator。這些服務旨在為 AWS 資源和內容交付提供安全、低延遲、高效能的存取。您可以將這些周邊服務與其他安全服務 (例如 Amazon GuardDuty 和 AWS Firewall Manager) 搭配使用，協助您為應用程式建立安全的周邊。

AWS 提供多種周邊安全性架構模式，以支援不同的組織需求。本節著重於兩種常見模式：在中央 (網路) 帳戶中部署周邊服務，以及將部分周邊服務部署到個別的工作負載 (應用程式) 帳戶。本節涵蓋兩種架構的優點及其主要考量事項。

在單一網路帳戶中部署周邊服務

下圖建立在基準 AWS SRA 的基礎上，以說明將周邊服務部署到網路帳戶的架構。

將周邊服務部署到網路帳戶

將周邊服務部署到單一網路帳戶有幾點優勢：

  • 此模式支援各種使用案例，例如高度監管的產業，其中要限制為由單一專業團隊管理組織內的周邊服務。

  • 該模式簡化了限制建立、修改和刪除聯網元件所需的組態。

  • 它簡化了偵測任務，因為在單一位置進行檢查，從而導致較少的日誌彙總點。

  • 您可以建立自訂最佳實務資源 (例如 CloudFront 政策和邊緣功能)，並在同一帳戶中跨分發共用這些資源。

  • 透過減少實作變更的位置，可簡化對組態錯誤敏感的關鍵業務資源 (例如內容交付網路 (CDN) 快取設定或 DNS 記錄) 的管理任務。

以下各節將深入探討每項服務，同時討論架構考量事項。

Amazon CloudFront

Amazon CloudFront 是專為高效能、安全性和開發人員便利而打造的內容交付網路 (CDN) 服務。對於面向網際網路的公用 HTTP 端點，我們建議您使用 CloudFront 來發佈面向網際網路的內容。 CloudFront 是一個反向代理，可作為全域應用程式的單一入口點。它也可以與 AWS WAF 和 Lambda @Edge 等邊緣函數和函數結合使用，協助為內容交付建立安全且可自訂的解決方案。 CloudFront

在此部署架構中，包括邊緣功能在內的所有 CloudFront 組態都會部署到 Network 帳戶中，並由集中式網路團隊管理。只有聯網團隊中授權的員工才有權存取此帳戶。想要變更 AWS WAF 的 CloudFront 組態或 Web 存取控制清單 (Web ACL) 的應用程式團隊應向聯網團隊申請這些變更。我們建議您建立工作流程，例如票證系統，以便應用程式團隊請求組態變更。

在此模式中，動態和靜態原始伺服器都位於個別的應用程式帳戶中，因此存取這些原始伺服器需要跨帳戶許可和跨帳戶角色。來自發 CloudFront 行版的記錄會設定為傳送至記錄封存帳戶。

AWS WAF

AWS WAF 是一種 Web 應用程式防火牆，可讓您監控轉送至受保護 Web 應用程式資源的 HTTP 和 HTTPS 請求。此服務可協助保護您的資源免於遭受常見的 Web 惡意探索和洪水式攻擊，以及抵禦更複雜的威脅，例如帳戶建立詐騙、未經授權存取使用者帳戶，以及嘗試逃避偵測的機器人。AWS WAF 可協助保護下列資源類型： CloudFront 分發、Amazon API 閘道 REST API、應用程式負載平衡器、AWS AppSync GraphQL API、Amazon Cognito 使用者集區、AWS 應用程式執行器服務和 AWS 驗證存取執行個體。

在此部署架構中，AWS WAF 會附加至網路帳戶中設定的 CloudFront 分發。使用設定 AWS WAF 時 CloudFront，周 CloudFront 邊覆蓋區會延伸到節點，而不是應用程式 VPC。這會使惡意流量的篩選更接近該流量的來源，並有助於限制惡意流量進入您的核心網路。

雖然 Web ACL 部署在網路帳戶中，但我們建議您使用 AWS Firewall Manager 來集中管理 Web ACL，並確保所有資源都合規。將安全工具帳戶設定為 Firewall Manager 的管理員帳戶。部署具有自動補救功能的 Firewall Manager 員策略，以強制帳戶中的所有（或選定） CloudFront 發佈都附加了 Web ACL。

您可以透過設定對 S3 儲存貯體的跨帳戶存取權，將完整的 AWS WAF 日誌傳送到日誌存檔帳戶中的 S3 儲存貯體。如需詳細資訊，請參閱關於此主題的 AWS Re:Post 文章。

AWS Shield 和 AWS Route 53 運作狀態檢查

AWS Shield Standard 和 AWS Shield Advanced 為網路和傳輸層 (第 3 層和第 4 層) 和應用程式層 (第 7 層) 中的 AWS 資源提供針對分散式拒絕服務 (DDoS) 攻擊的保護。Shield Standard 是自動附加的項目，除了已為 AWS WAF 和其他 AWS 服務支付的費用，無任何附加成本。Shield 牌進階為您的 Amazon EC2 執行個體、Elastic Load Balancing 負載平衡器、 CloudFront 分發和 Route 53 託管區域提供擴充的 DDoS 事件保護。如果您擁有高可見度的網站，或者您的應用程式容易發生頻繁的 DDoS 事件，請考慮 Shield Advanced 提供的其他功能。

本節著重於 Shield Advanced 組態，因為 Shield Standard 無法進行使用者設定。

若要設定 Shield 進階來保護您的 CloudFront 發行版，請訂閱網路帳戶以防 Shield 進階。在帳戶中，新增 Shield 應變小組 (SRT) 支援，並為 SRT 團隊在 DDoS 事件期間存取您的 Web ACL 提供必要的許可。您可以隨時聯絡 SRT，為您的應用程式建立和管理作用中 DDoS 事件期間的自訂緩解措施。事先設定存取權可讓 SRT 靈活地偵錯和修訂 Web ACL，而不必在事件期間管理許可。

使用具有自動補救功能的 Firewall Manager 員，將您的 CloudFront 分發新增為受保護 如果您有其他面向網際網路的資源，例如 Application Load Balancer，則可以考慮將它們新增為 Shield Advanced 受保護的資源。不過，如果您在資料流程中有多個 Shield Advanced 受保護的資源 (例如，您的 Application Load Balancer 是目標的來源 CloudFront)，建議您只使用入口點做為受保護的資源，以減少 Shield Advanced 的重複資料傳出 (DTO) 費用。

啟用主動參與功能，讓 SRT 主動監控受保護的資源，並視需要與您聯絡。若要有效地設定主動參與功能，請為您的應用程式建立 Route 53 運作狀態檢查，並將它們與 CloudFront 散佈產生關 Shield Advanced 會在評估事件時使用運作狀態檢查作為額外的資料點。應正確定義運作狀態檢查以減少偵測誤報。如需識別運作狀態檢查正確指標的詳細資訊，請參閱 AWS 文件中的將 Shield Advanced 與運作狀態檢查搭配使用的最佳實務。如果您偵測到 DDoS 嘗試，可以聯絡 SRT 並為您的支援計劃選擇可用的最高嚴重性。

AWS Certificate Manager 和 AWS Route 53

AWS Certificate Manager (ACM) 可協助您佈建、管理和續約公有和私有 SSL/TLS X.509 憑證。當您使用 ACM 管理憑證時，會使用強式加密和金鑰管理最佳事務來安全地保護和儲存憑證私有金鑰。

ACM 會部署在網路帳戶中，以產生用於 CloudFront 散發的公用 TLS 憑證。需要 TLS 憑證才能在檢視器和 CloudFront. 如需詳細資訊，請參閱CloudFront 文件。ACM 提供 DNS 或電子郵件驗證以驗證網域擁有權。建議您使用 DNS 驗證來取代電子郵件驗證，因為使用 Route 53 管理您的公有 DNS 記錄，您可以直接透過 ACM 更新自己的記錄。只要憑證使用中，而且保有 CNAME 記錄，ACM 便會自動續約經 DNS 驗證的憑證。

CloudFront 存取日誌和 AWS WAF 日誌

根據預設， CloudFront 存取日誌會儲存在網路帳戶中，而 AWS WAF 日誌會使用 Firewall Manager 員記錄選項彙總到安全工具帳戶中。我們建議您在日誌存檔帳戶中複寫這些日誌，以便集中式安全團隊可以存取這些日誌以進行監控。

設計考量

  • 在此架構中，單一聯網群組的大量相依性可能會影響您快速進行變更的能力。

  • 監控每個帳戶的服務配額。服務配額 (也稱為限制) 是您 AWS 帳戶的服務資源或操作數目最大值。如需詳細資訊，請參閱 AWS 文件中的 AWS 服務配額。

  • 為工作負載團隊提供特定指標可能會導致複雜性。

  • 應用程式團隊限制了對組態的存取，這可能會導致等待聯網團隊代表其實作變更的額外負荷。

  • 在單一帳戶中共用資源的團隊可能會競爭相同的資源和預算，這可能會產生資源配置挑戰。我們建議您採用適當的機制，以便從使用網路帳戶中已部署周邊服務的應用程式團隊收取費用。

在個別應用程式帳戶中部署周邊服務

下圖說明在個別應用程式帳戶中獨立部署和管理週邊服務的架構模式。

將周邊服務部署至個別應用程式帳戶

將周邊服務部署至應用程式帳戶可提供幾點優勢：

  • 此設計可為個別工作負載帳戶提供自主權，可依據其需求自訂服務組態。藉助此方法，可不再依賴專門的團隊來在共用帳戶中實作資源變更，並且可讓每個團隊中的開發人員獨立管理組態。

  • 每個帳戶都有自己的服務配額，因此應用程式擁有者不必在共用帳戶的配額內工作。

  • 此設計可將惡意活動限制在特定帳戶內，並防止攻擊擴散到其他工作負載，從而有助於遏制惡意活動的影響範圍。

  • 這樣可消除變更帶來的風險，因為影響範圍僅限於有問題的工作負載。也可以使用 IAM 來限制可實作變更的團隊，因此在工作負載團隊與中央聯網團隊之間進行邏輯分隔。

  • 透過分散網路輸入和輸出的實作，但採用共同的邏輯控制 (透過使用 AWS Firewall Manager 等服務)，您可以針對特定工作負載調整網路控制項，同時繼續達到最低標準的控制目標。

以下各節將深入探討每項服務，同時討論架構考量事項。

Amazon CloudFront

在此部署架構中，Amazon CloudFront 組態 (包括邊緣功能) 會在個別應用程式帳戶中進行管理和部署。這會驗證每個應用程式擁有者和工作負載帳戶是否具有依據其應用程式需求設定周邊服務的自主權。

動態和靜態來源位於相同的應用程式帳戶中，而且 CloudFront 發行版具有對這些來源的帳戶層級存取權。來自 CloudFront分發的日誌存儲在本地每個應用程序帳戶中。日誌可複寫至日誌存檔帳戶，以支援合規性和法規需求。

AWS WAF

在此部署架構中，AWS WAF 會附加至應用程式帳戶中設定的 CloudFront 分發。與之前的模式一樣，我們建議您使用 AWS Firewall Manager 集中管理 Web ACL，並確保所有資源都合規。應將共同的 AWS WAF 規則新增為預設值，例如 AWS 受管核心規則集和 Amazon IP 評價清單。這些規則會自動套用至應用程式帳戶中的任何合格資源。

除了 Firewall Manager 強制執行的規則之外，每個應用程式擁有者都可以將與其應用程式安全性相關的 AWS WAF 規則新增至 Web ACL。這可在每個應用程序帳戶中提供靈活性，同時仍保留安全工具帳戶的整體控制權。

使用 Firewall Manager 日誌記錄選項來集中管理日誌，以及將這些日誌傳送到安全工具帳戶中的 S3 儲存貯體。為每個應用程式團隊提供檢閱其應用程式之 AWS WAF 儀表板的存取權。您可以使用 Amazon 等服務來設置儀表板 QuickSight。如果確定任何誤報或需要 AWS WAF 規則的其他更新，可以將應用程式層級的 AWS WAF 規則新增至 Firewall Manager 部署的 Web ACL。日誌會複寫到日誌存檔帳戶，並且進行存檔以進行安全性調查。

AWS Global Accelerator

AWS Global Accelerator 可讓您建立加速器，以改善本機和全域使用者的應用程式效能。Global Accelerator 提供靜態 IP 地址，作為託管在一或多個 AWS 區域中之應用程式的固定進入點。可以將這些地址與區域 AWS 資源或端點建立關聯，例如 Application Load Balancer、Network Load Balancer、EC2 執行個體和彈性 IP 地址。這可讓流量盡可能接近使用者的 AWS 全域網路。

Global Accelerator 目前不支援跨帳戶原始伺服器。因此，它會部署到與原始伺服器端點相同的帳戶中。在每個應用程式帳戶中部署加速器，並將它們新增為相同帳戶中 AWS Shield Advanced 的受保護資源。Shield Advanced 緩解措施只允許有效流量到達 Global Accelerator 接聽程式端點。

AWS Shield Advanced 和 AWS Route 53 運作狀態檢查

若要設定 AWS Shield 進階來協助保護您的 CloudFront 分發，您需要訂閱每個應用程式帳戶以進行 Shield 構進階。您應該在帳戶層級設定諸如 Shield 應變小組 (SRT) 存取權以及主動參與等功能，因為這些功能應該在與資源相同的帳戶中進行設定。使用具有自動補救功能的 Firewall Manager 員，將您的 CloudFront 分發新增為受保護的資源，並將策略套用至每個帳號。每個 CloudFront 發行版的 Route 53 健康狀態檢查應部署在相同的帳戶中，並與資源相關聯。

Amazon Route 53 區域和 ACM

當您使用 Amazon 等服務時 CloudFront，應用程式帳戶需要存取託管根網域的帳戶，才能建立自訂子網域，並套用 Amazon Certificate Manager (ACM) 或第三方憑證發行的憑證。可以使用 Amazon Route 53 區域委派，將公有網域從中央共用服務帳戶委派給個別應用程式帳戶。區域委派可讓每個帳戶建立和管理應用程式特定的子網域，例如 API 或靜態子網域。每個帳戶中的 ACM 可讓每個應用程式帳戶依據自己的需求管理憑證審核和驗證程序 (組織驗證、延伸驗證或網域驗證)。

CloudFront 存取日誌、全域加速器流程日誌和 AWS WAF 日誌

在此模式中，我們會在個別應用程式帳戶的 S3 儲 CloudFront 存貯體中設定存取日誌和全域加速器流程日誌。想要分析日誌以進行效能調校或降低誤報率的開發人員可以直接存取這些日誌，而不需要請求存取中央日誌存檔。本機儲存的日誌也可以支援區域合規性要求，例如資料落地或 PII 混淆。

完整的 AWS WAF 日誌會使用 Firewall Manager 日誌記錄功能儲存在日誌存檔帳戶的 S3 儲存貯體中。應用程式團隊可以使用 Amazon 等服務設定的儀表板來檢視日誌 QuickSight。此外，每個應用程式團隊都可以從自己的帳戶存取採樣的 AWS WAF 日誌，以便快速偵錯。

建議您將日誌複寫到位於日誌存檔帳戶中的集中式資料湖。將日誌彙總到集中式資料湖中，這樣就可全面檢視 AWS WAF 資源和分佈的所有流量。這有助於安全團隊集中分析並回應全域安全威脅模式。

設計考量

  • 這種模式將網絡和安全管理的責任轉移到帳戶擁有者和開發人員，這可能會增加開發程序的負荷。

  • 可能存在不一致的決策。您應該建立有效的通訊、範本和訓練，以確保服務設定正確並遵循安全性建議。

  • 此過程依賴於自動化，並且要對基準安全控制項結合應用程式特定控制項提出明確期望。

  • 使用 Firewall Manager 和 AWS Config 等服務，確保部署的架構符合安全最佳實務。此外，還可以設定 AWS CloudTrail 監控以偵測任何錯誤設定。

  • 在集中位置彙總日誌和指標以進行分析可能會引入複雜性。

適用於周邊安全組態的其他 AWS 服務

動態原始伺服器：Application Load Balancer

您可以 CloudFront 將 Amazon 設定為使用應用程式負載平衡器來源進行動態內容交付。此設定可讓您依據各種因素 (例如請求路徑、主機名稱或查詢字串參數)，將請求路由到不同的 Application Load Balancer 原始伺服器。

Application Load Balancer 原始伺服器會部署在應用程式帳戶中。如果您的 CloudFront 發行版位於 Network 帳戶中，則必須為 CloudFront 散發設定跨帳戶權限，才能存取 Application Load Balancer 來源。Application Load Balancer 的日誌會傳送至日誌存檔帳戶。

若要協助防止使用者直接存取 Application Load Balancer CloudFront，請完成下列高階步驟：

  • 設定 CloudFront 以將自訂 HTTP 標頭新增至傳送至 Application Load Balancer 的要求，並將 Application Load Balancer 設定為僅轉寄包含自訂 HTTP 標頭的要求。

  • 使用應用 Application Load Balancer 安全性群組 CloudFront 中的 AWS 管理的前置詞清單。這會限制從屬於原點對向伺服器的 IP 位址傳送至 Application Load Balancer 器的入埠 HTTP/HTTPS 流量。 CloudFront

如需詳細資訊，請參閱文件中的限制對應用程式負載平衡器的存取 CloudFront。

靜態起源：Amazon S3 和 AWS Elemental MediaStore

您可以設定 CloudFront 為使用 Amazon S3 或 AWS Elemental MediaStore 來源進行靜態內容交付。這些原始伺服器會部署在應用程式帳戶中。如果您的發 CloudFront 行版位於 Network 帳戶中，則必須為 Network 帳戶中的 CloudFront 散佈設定跨帳戶權限，才能存取來源。

若要確認您的靜態原始端點只能透過公用網際網路存取， CloudFront 而不是直接透過公用網際網路存取，您可以使用原始存取控制 (OAC) 組態。如需有關限制存取的詳細資訊，請參閱文件中的限制對 Amazon S3 來源的存取和限制對 MediaStore 來源的存取。 CloudFront

AWS Firewall Manager

AWS Firewall Manager 可簡化多個帳戶和資源中的管理和維護任務，包括 AWS WAF、AWS Shield Advanced、Amazon VPC 安全群組、AWS Network Firewall 和 Amazon Route 53 Resolver DNS 防火牆，以此提供各種保護。

將安全工具帳戶委派為 Firewall Manager 預設管理員帳戶，並使用該帳戶在整個組織帳戶中集中管理 AWS WAF 規則和 Shield Advanced 保護。使用 Firewall Manager 集中管理共同的 AWS WAF 規則，同時讓每個應用程式團靈活地將應用程式特定規則新增至 Web ACL。這有助於強制執行組織範圍的安全政策，例如防範常見漏洞，同時允許應用程式團隊新增其應用程式專屬的 AWS WAF 規則。

使用 Firewall Manager 日誌記錄將 AWS WAF 日誌集中到安全工具帳戶中的 S3 儲存貯體，並將這些日誌複寫到日誌存檔帳戶，以便將其存檔進行安全調查。此外，將 Firewall Manager 與 AWS Security Hub 整合，以在 Security Hub 集中視覺化組態詳細資訊和 DDoS 通知。

如需其他建議，請參閱本指南安全工具帳戶一節中的 AWS Firewall Manager。

AWS Security Hub

Firewall Manager 和 Security Hub 之間的整合會傳送四種類型的問題清單至 Security Hub：

  • 未受 AWS WAF 規則妥善保護的資源

  • 未受 AWS Shield Advanced 妥善保護的資源

  • 表明 DDoS 攻擊正在進行的 Shield Advanced 問題清單

  • 未正確使用的安全群組

來自所有組織成員帳戶的這些問題清單會彙總到 Security Hub 委派的管理員 (安全工具) 帳戶中。安全工具帳戶會彙總、整理來自單一位置的安全性提醒或問題清單，以及排定其優先順序。使用 Amazon E CloudWatch vents 規則將發現項目傳送到工單系統或建立自動補救，例如封鎖惡意 IP 範圍。

如需其他建議，請參閱本指南安全工具帳戶一節中的 AWS Security Hub。

Amazon GuardDuty

您可以使用 Amazon 提供的威脅情報， GuardDuty 自動更新 Web ACL，以回應 GuardDuty 發現結果。例如，如果 GuardDuty 偵測到可疑活動，自動化可用於更新 AWS WAF IP 集中的項目，並將 AWS WAF Web ACL 套用至受影響的資源，以阻止來自可疑主機的通訊，同時執行其他調查和修復。安全工具帳戶是的委派管理員帳戶 GuardDuty。因此，您應該使用具有跨帳戶許可的 AWS Lambda 函數來更新應用程式帳戶中的 AWS WAF IP 集。

如需其他建議，請參閱本指南安全工具帳戶部分 GuardDuty中的 Amazon。

AWS Config

AWS Config 是 Firewall Manager 的先決條件，其部署在 AWS 帳戶中，包括網路帳戶和應用程式帳戶。此外，使用 AWS Config 規則來驗證部署的資源是否符合安全最佳實務。例如，您可以使用 AWS Config 規則來檢查每個 CloudFront 分發是否與 Web ACL 相關聯，或強制將所有 CloudFront 分發設定為將存取日誌交付到 S3 儲存貯體。

如需一般建議，請參閱本指南安全工具帳戶一節中的 AWS Config。