來源隱藏
概觀
來源隱藏是一套技術，旨在減少 Web 應用程式的受攻擊面。最好的做法是將 CloudFront 當作 Web 應用程式的單一進入點使用，在其中應用安全控制，例如防範 DDoS 攻擊和不樂見的機器人的保護措施。來源隱藏可阻止惡意人士繞過 CloudFront 及其安全控制，直接攻擊來源，並使用防火牆規則封鎖不是來自 CloudFront 進入點的任何流量。來源隱藏可以在 OSI 模型的多個層級上實現。
應用程式層
網路層上的來源隱藏可保護您的來源免受直接針對您的來源的所有攻擊。但是，攻擊者可以使用您探索到的來源網域名稱來設定 CloudFront 分發，並透過其 CloudFront 分發，對您的來源進行應用程式層攻擊，從而有效地繞過在您自己的 CloudFront 分發上設定的安全控制。
除了將您的來源網域名稱模糊化 (例如，避免 origin.example.com！) 之外，您可以在 CloudFront 和您的來源之間新增應用程序層存取控制，以緩解上述風險。這可以根據來源類型和安全需求，以不同的方式實作。
以簽署請求為基礎的存取控制
OAC 是 CloudFront 的功能，可讓您根據 IAM 政策，使用 AWS 第 4 版簽署程序演算法 (sigv4)，以原生方式簽署特定類型來源的請求。如今，OAC 與 S3、MediaStore、MediaPackage、Lambda 函數 URL 和 S3 Object Lambda 相容。當 OAC 與 S3 一起使用時，您可以將 S3 儲存貯體設為私密，並根據 S3 儲存貯體政策，對 CloudFront 進行專屬存取。
當 OAC 不支援來源類型時，您可以使用邊緣函數簽署對來源的請求。以下部落格文章說明範例實作：
以共用的私密金鑰為基礎的存取控制
如果您的來源不支援請求簽署，或者您認為應用程式不需要此層級的存取控制，則您可以將 CloudFront 設定為傳送包含與來源共用密碼的自訂標頭，您的來源可以驗證該標頭以處理請求。請考慮以下範例實作：
- 基於 ALB 的來源。如果您的 ALB 已與 AWS WAF WebACL 建立關聯，您可以使用 ALB 規則或使用 AWS WAF 規則，驗證基於 ALB 的來源上的密碼標頭。
- 基於 API Gateway 的來源。您可以使用 API 金鑰驗證 API Gateway 上的密碼標頭。
- 基於 NGINX 的來源。假設 CloudFront 傳送值為 abc123 的自訂標頭 X-CloudFront，則您可以在 /etc/nginx/nginx.conf Nginx 組態檔的伺服器標籤中加入下列程式碼，以驗證基於 Nginx 的 Web 伺服器 (基於雲端或基於內部部署) 上的密碼標頭：
if ($http_x_cloudfront != "abc123") {
return 403;
} - 基於 Apache 的來源。假設 CloudFront 傳送值為 abc123 的自訂標頭 X-CloudFront，則您可以在 httpd.conf 組態檔案 (若使用 ssl.conf 檔案，則也包含在內) 中加入下列程式碼，以驗證基於 Apache 的 Web 伺服器 (基於雲端或基於內部部署) 上的密碼標頭：
RewriteEngine On
RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
RewriteRule ^ - [F]
在所有情況下，我們都建議您定期輪換此共用密碼，以降低洩漏密碼的風險。在以上分享的範例實作中，使用 API Gateway 和 ALB 的實作都包含自動輪換密碼。
網路層
CloudFront 會以 service 欄位的 CLOUDFRONT_ORIGIN_FACING 值，發佈與來源建立 TCP 連線所使用的 IP 地址。您可以在來源的防火牆上實作 ACL，以封鎖非來自面向 CloudFront 來源 IP 的流量。使用這種方法，您需要訂閱 IP 變更以更新 ACL。請查看這篇部落格文章，了解如何在內部部署 Web 伺服器上使用第三方防火牆實作來源隱藏。
如果您的來源是在 Amazon VPC 中託管，您只需將 Amazon CloudFront 的 AWS 受管字首清單新增至附加到您來源 (EC2、NLB、ALB 等...) 的安全群組，就可以實作來源隱藏。
在這兩種情況下，建議在 CloudFront 和您的來源之間，透過 TLS 建立安全連線。
實體層
如果您的來源位於內部部署，請考慮使用 Direct Connect 連線上的公用虛擬介面，在內部部署基礎設施和 AWS 之間設定 AWS Direct Connect。如此一來，您的來源與 CloudFront 之間的流量會在私人管理的網路上傳輸，無法從網際網路存取。