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.

Das Ursprungs-Cloaking auf Netzwerkebene schützt Ihren Ursprung vor allen Angriffen, die direkt auf Ihren Ursprung abzielen. Ein Angreifer könnte jedoch eine CloudFront-Distribution mit Ihrem erkannten Ursprungs-Domainnamen konfigurieren und Ihren Ursprung mit Angriffen auf Anwendungsebene über seine CloudFront-Distribution angreifen, wodurch Ihre in Ihrer eigenen CloudFront-Distribution konfigurierten Sicherheitskontrollen effektiv umgangen werden.

Zusätzlich zur Vertuschung Ihres ursprünglichen Domainnamens (vermeiden Sie z. B. „ursprung.example.com“!) können Sie Zugriffskontrollen auf Anwendungsebene zwischen CloudFront und Ihrem Ursprung hinzufügen, um das oben genannte Risiko zu mindern. Dies kann je nach Herkunftstyp und Sicherheitsanforderung auf unterschiedliche Weise implementiert werden.

OAC ist eine Funktion von CloudFront, mit der Sie Anfragen an bestimmte Arten von Ursprüngen mithilfe des auf IAM-Richtlinien basierenden AWS Signature Version 4-Algorithmus (sigv4) nativ signieren können. Heute ist OAC kompatibel mit S3, MediaStore , MediaPackage, 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.

CloudFront veröffentlicht die IP-Adressen, die für den Aufbau von TCP-Verbindungen mit Ihrem Ursprung verwendet werden, mit dem Wert CLOUDFRONT_ORIGIN_FACING des Felds service. Sie können eine ACL auf der Firewall Ihres Ursprungs implementieren, um Datenverkehr zu blockieren, der nicht von den mit dem CloudFront-Ursprung verbundenen IP-Adressen stammt. Bei diesem Ansatz müssen Sie IP-Änderungen abonnieren, um Ihre ACL zu aktualisieren. In diesem Blogbeitrag erfahren Sie, wie Sie Ursprungs-Cloacking auf lokalen Webservern mithilfe von Firewalls von Drittanbietern implementieren.

Wenn Ihr Ursprung in einer Amazon-VPC gehostet wird, können Sie das Ursprungs-Cloaking einfach implementieren, indem Sie die AWS-verwaltete Präfixliste für Amazon CloudFront zu der Sicherheitsgruppe hinzufügen, die Ihrem Ursprung zugeordnet ist (EC2, NLB, ALB usw.).

In beiden Fällen wird empfohlen, sichere Verbindungen über TLS zwischen CloudFront und Ihrem Ursprung herzustellen.

Wenn sich Ihr Ursprung bei Ihnen vor Ort befindet, sollten Sie erwägen, AWS Direct Connect zwischen Ihrer lokalen Infrastruktur und AWS mithilfe einer öffentlichen virtuellen Schnittstelle auf der Direct-Connect-Verbindung einzurichten. Auf diese Weise wird der Datenverkehr zwischen Ihrem Ursprung und CloudFront in einem privat verwalteten Netzwerk transportiert, das über das Internet nicht erreichbar ist.