AWS CloudFront mit privatem Bucket

Worum gehts?

Hauptursache für Security Issues bei AWS sind Public Buckets. Hier ein Fall, bei dem Millionen von Datensätzen wegen eines “leaky AWS bucket” frei im Netz standen.

Security Hub, AWS Config und Cloud Custodian sind gute Hilfsmittel, Public Buckets zu finden. AWS Organizations und Service Controlled Policies können die Fehlkonfigurationen sogar verhindern. Wir zeigen, wie du die Bucket Security verbessern kannst.

Der S3 Bucket als Website

Für das Bereitstellen statischer Web-Inhalte bietet AWS seit langer Zeit Dienste an, die ohne das Betreiben eigener Server möglich sind. Das wird gern als Serverless tituliert.

Die Daten kommen in einen S3 Bucket und das Website Hosting Feature von S3 wird aktiviert. Nach Aktivieren einer Public Access Policy ist dann auf alle Inhalte anonymer Zugriff möglich.

Weiterhin muss die Einstellung Block All Public Access für den Bucket explizit deaktiviert sein. Aber selbst in der AWS Dokumentation für S3 Website Hosting wird darauf hingewiesen, dass dies keine empfohlene Einstellung ist. Die Hosting S3 Buckets tauchen in der S3 Übersicht als rot eingefärbte Einträge auf (igitt).

CloudFront als Content Delivery Network vor dem S3 Bucket

Amazons eigenes CDN namens CloudFront ermöglicht dann zusätzlich mit geringem Aufwand, diese Inhalte weltweit mit geringer Latenz bereitzustellen. Dabei wird der S3 Bucket als Datenbasis weiter verwendet.

CloudFront bietet auch damit die Möglichkeit, die Websiteinhalte mit HTTPS auszuliefern, was inzwischen ebenfalls unvermeidlich ist.

Das Caching minimiert die Zugriffe auf den Bucket. Das verringert Kosten und Latenzen.

Zusammenfassend sind folgende Punkte problematisch

S3 allein für Websitehosting:

- S3 Bucket für die Inhalte, Websitehosting skaliert aber nicht
- Höhere Latenzen für Clients aus anderen Regionen
- kein HTTPS
- Bucket muß dem Domänennamen entsprechen, DNS Record zeigt auf die Websitebucket URL

S3 mit CloudFront:

- CloudFront kann umgangen werden
- S3 hat weiterhin Public Access

Die Lösung

In vielen Dokumentationen sind die oben aufgeführten Schritte meistens so dokumentiert; in vielen Live Umgebungen wird das leider immer wieder in der Praxis so umgesetzt. Wir beraten unsere Kunden, diese Konfiguration nicht so beizubehalten und lösen es folgendermaßen:

Die Verbindung zwischen CloudFront und S3 kann mit zusätzlicher Konfiguration abgesichert werden. Dazu wird ein OAI (Object Access Identity) erstellt und in CloudFront hinzugefügt.

Beispiel in Terraform:

resource "aws_cloudfront_origin_access_identity" "origin_access_identity" {
  comment = "OAI for Domain ${local.apex_domain}"
}

Und wird dann in der CloudFront Ressource referenziert:

  origin {
    domain_name = var.content_bucket.bucket_regional_domain_name
    origin_id   = local.s3_origin_id

    s3_origin_config {
      origin_access_identity = aws_cloudfront_origin_access_identity.origin_access_identity.cloudfront_access_identity_path
    }
  }

Der S3 Bucket wird jetzt über die S3 API angesprochen, Website Hosting und Public Access sind nicht mehr nötig und werden nicht aktiviert.

Damit CloudFront zugreifen darf, wird die Bucket Policy um den Eintrag für den OAI ergänzt.

Beispiel als Terraform Policy Document:

data "aws_iam_policy_document" "oai_bucket_policy" {
  statement {
    sid    = "OaiBucketAccess"
    effect = "Allow"
    actions = [
      "s3:GetObject",
    ]
    principals {
      identifiers = [aws_cloudfront_origin_access_identity.origin_access_identity.iam_arn]
      type        = "AWS"
    }
    resources = ["${var.content_bucket.arn}/*"]
  }
}

Mit Lambda@Edge ist es möglich, Header hinzuzufügen oder Rewrite Regeln umzusetzen. Die im S3 Website Hosting enthaltene Funktionalität, der URL automatisch den Root Document Namen (index.html) anzuhängen, bietet CloudFront nur für den Documentroot, das heißt, die oberste Ebene. Lambda@Edge kann die Funktion nachbilden.

S3 Bucket ist abgesichert

Mit einem privaten Bucket ist keine irrtümliche Bereitstellung von Inhalten mehr möglich. Die Sicherheitseinstellungen entsprechen den AWS Best Practices.

Noch Fragen?

Dann kontaktiert uns gern!