Ursprungs-Cloaking

Ursprungs-Cloaking ist eine Reihe von Techniken, die darauf abzielen, die Angriffsfläche von Webanwendungen zu reduzieren. Es hat sich bewährt, CloudFront als zentralen Einstiegspunkt für Webanwendungen zu verwenden, bei denen Sicherheitskontrollen wie Schutz vor DDoS-Angriffen und unerwünschten Bots angewendet werden. Das Cloaking des Ursprungs verhindert, dass böswillige Akteure CloudFront und seine Sicherheitskontrollen umgehen, um den Ursprung direkt anzugreifen. Dabei werden Firewallregeln verwendet, um jeglichen Datenverkehr zu blockieren, der nicht vom CloudFront-Einstiegspunkt kommt. Ursprungs-Cloaking kann auf mehreren Ebenen des OSI-Modells erreicht werden.

Wenn Ihr Ursprung es Ihnen ermöglicht, den eingehenden Netzwerkzugriff zu kontrollieren, fügen Sie Einschränkungen hinzu, um nur Datenverkehr aus dem CloudFront-Netzwerk zuzulassen.

Wenn es sich bei Ihrem Ursprung um eine EC2-Instance, einen Application Load Balancer oder einen Network Load Balancer handelt, können Sie Ihren Ursprung in einem privaten Subnetz in Ihrer VPC belassen und das VPC--Origins-Feature von CloudFront nutzen. Es ermöglicht Ihnen, den Zugriff ausschließlich auf CloudFront-Distributionen zu beschränken, die mit VPC Origins in Ihrem eigenen AWS-Konto konfiguriert sind.

Wenn Sie solche Ressourcen in einem öffentlichen Subnetz belassen müssen (z. B. wird auf Ihr ALB von mehreren CDNs zugegriffen) oder wenn Sie einen Ursprungstyp haben, der von den VPC Origins von CloudFront nicht unterstützt wird, können Sie den Zugriff auf CloudFront mithilfe von Sicherheitsgruppen einschränken. Sie müssen Ihren Ursprung einer Sicherheitsgruppe zuordnen, zu der Sie die von AWS verwaltete Präfixliste für Amazon CloudFront hinzufügen.

Wenn sich Ihr Ursprung bei Ihnen vor Ort befindet, können Sie den Zugriff auf CloudFront einschränken, indem Sie zulassen, dass die IP-Adressen von CloudFront aufgeführt werden, die in dieser IP-Liste zu finden sind, wenn Sie nach dem Wert CLOUDFRONT_ORIGIN_FACING des Dienstfelds filtern. Bei diesem Ansatz müssen Sie IP-Änderungen abonnieren, um Ihre ACL zu aktualisieren. In diesem Blogbeitrag erfahren Sie, wie Sie Ursprungs-Cloaking auf lokalen Webservern mithilfe von Firewalls von Drittanbietern implementieren. Für eine weitere Isolierung von Internet, sollten Sie erwägen, AWS Direct Connect zwischen Ihrer lokalen Infrastruktur und AWS mithilfe einer öffentlichen virtuellen Schnittstelle auf der Direct-Connect-Verbindung einzurichten.

Die Zugriffskontrolle auf Netzwerkebene ist ein Ausgangspunkt, reicht Ihnen aber möglicherweise nicht aus. Wenn beispielsweise jemand den Ursprungs-Domainnamen bei Ihnen vor Ort entdeckt, kann er eine CloudFront-Distribution in seinem eigenen AWS-Konto erstellen und Ihre eigene Distribution umgehen. Ein anderes Beispiel: Wenn Sie das VPC-Origin-Feature verwenden, möchten Sie möglicherweise Ihren Ursprung auf eine bestimmte CloudFront-Distribution in Ihrem AWS-Konto beschränken, anstatt sie für alle CloudFront-Distribution zugänglich zu machen, die mit VPC Origins in Ihrem AWS-Konto konfiguriert sind. In diesem Fall sollten Sie Hardening mit Zugriffssteuerung auf Anwendungsebene in Betracht ziehen.

Das Verbinden einiger Typen von Ursprüngen mit CloudFront wird mit Origin Access Control (OAC), einem Feature von CloudFront, das Anfragen an bestimmte Quelltypen nativ mithilfe des AWS Signature Version 4-Algorithmus (sigv4) sehr einfach auf IAM-Richtlinien basierend signiert. Heute ist OAC kompatibel mit S3, MediaStore , MediaPackage und Lambda-Funktions-URLs und S3 Object Lambda. Wenn OAC mit S3 verwendet wird, können Sie Ihren S3-Bucket privat halten und erhalten auf der Grundlage von S3-Bucket-Richtlinien exklusiven Zugriff auf CloudFront.

Wenn der Quelltyp von OAC nicht unterstützt wird, können Sie mithilfe von Edge-Funktionen Anfragen an Ihren Ursprung signieren. Beispielimplementierungen werden in den folgenden Blogs erklärt:

• Signieren von Anfragen mit Sigv4 und Lambda@Edge für AWS-API-Gateway
• Signieren von Anfragen mit MD5 und Lambda@Edge für NGINX-Server

Wenn Ihr Ursprung das Signieren von Anfragen nicht unterstützt oder Sie der Meinung sind, dass diese Ebene der Zugriffskontrolle für Ihre Anwendung nicht erforderlich ist, können Sie CloudFront so konfigurieren, dass ein benutzerdefinierter Header gesendet wird, der ein gemeinsames Secret mit Ihrem Ursprung enthält, das von Ihrem Ursprung validiert werden kann, um die Anfrage zu verarbeiten. Betrachten Sie die folgende Beispielimplementierung:

• ALB-basierter Ursprung. Sie können den geheimen Header auf einem ALB-basierten Ursprung mithilfe einer ALB-Regel oder mithilfe einer AWS WAF-Regel validieren, wenn Ihr ALB bereits mit einer AWS WAF-WebACL verknüpft ist.
• API-Gateway-basierter Ursprung. Sie können den geheimen Header auf einem API-Gateway mithilfe von API-Schlüsseln validieren.
• NGINX-basierter Ursprung. Unter der Annahme, dass CloudFront einen benutzerdefinierten Header x-CloudFront mit dem Wert abc123 sendet, können Sie den geheimen Header auf einem Nginx-basierten Webserver (Cloud-basiert oder lokal) validieren, indem Sie den folgenden Code in das Server-Tag der Nginx-Konfigurationsdatei /etc/nginx/nginx.conf hinzufügen:
  
  if ($http_x_cloudfront != "abc123") {
      return 403;
  }
• Apache-basierter Ursprung. Unter der Annahme, dass CloudFront einen benutzerdefinierten Header x-CloudFront mit dem Wert abc123 sendet, können Sie den geheimen Header auf einem Apache-basierten Webserver (Cloud-basiert oder On-Premises) validieren, indem Sie den folgenden Code in die Konfigurationsdatei httpd.conf (und in der Datei ssl.conf, falls verwendet) hinzufügen:
  
  RewriteEngine On
  RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
  RewriteRule ^ - [F]

In allen Fällen wird empfohlen, dieses gemeinsame Secret regelmäßig zu wechseln, um das Risiko eines Durchsickerns von Secrets zu verringern. In den oben geteilten Beispielimplementierungen enthalten sowohl die mit API Gateway als auch mit ALB eine Automatisierung für die Secret-Rotation.