S3-Zugriffskontrolle: Bucket-Richtlinien und ACLs

S3 bietet mehrere sich überschneidende Mechanismen zur Zugriffssteuerung: IAM-Richtlinien (identitätsbasiert; sie steuern, was Principals tun dürfen), Bucket-Richtlinien (ressourcenbasierte JSON-Richtlinien für den Bucket), Access Control Lists (ACLs) (veraltete, objekt- oder bucketbezogene Berechtigungen) und S3 Block Public Access (eine Überschreibung auf Konto- oder Bucket-Ebene, die unabhängig von anderen Richtlinien jeden öffentlichen Zugriff blockiert). Für die meisten Anwendungsfälle werden heute Bucket-Richtlinien zusammen mit Block Public Access empfohlen. ACLs gelten als veraltet.

Eine Bucket-Richtlinie ist ein JSON-Dokument, das direkt an den S3-Bucket angehängt wird. Sie legt fest, welche Prinzipale (IAM-Benutzer, Rollen, AWS-Konten, Services oder die Öffentlichkeit) welche Aktionen auf welchen Ressourcen (dem Bucket und/oder bestimmten Schlüsselpräfixen) ausführen dürfen. Bucket-Richtlinien unterstützen kontenübergreifenden Zugriff, ohne dass IAM-Rollen erforderlich sind: Sie können der IAM-Rolle eines anderen AWS-Kontos direkt in der Bucket-Richtlinie Lesezugriff auf bestimmte Objekte gewähren. Jeder Bucket kann eine Richtlinie haben; die maximale Größe beträgt 20 KB.

Um öffentliche Inhalte bereitzustellen, beispielsweise Assets einer statischen Website oder öffentliche Datensätze, können Sie Objekte über eine Bucket-Richtlinie öffentlich lesbar machen. Deaktivieren Sie zunächst Block Public Access auf Bucket-Ebene und fügen Sie dann eine Bucket-Richtlinienanweisung mit Principal: '*' und Action: s3:GetObject hinzu. Sowohl das Deaktivieren der Einstellung Block Public Access als auch das Allow in der Bucket-Richtlinie sind erforderlich; eines ohne das andere funktioniert nicht. Begrenzen Sie die Resource immer auf ein bestimmtes Präfix statt auf den gesamten Bucket, sofern nicht bewusst alle Objekte öffentlich sein sollen.

S3 Block Public Access ist ein Sicherheitsnetz mit vier Einstellungen, die Bucket-Richtlinien und ACLs außer Kraft setzen: BlockPublicAcls (lehnt Anfragen zum Festlegen öffentlicher ACLs ab), IgnorePublicAcls (ignoriert vorhandene öffentliche ACLs), BlockPublicPolicy (lehnt Bucket-Richtlinien ab, die öffentlichen Zugriff gewähren) und RestrictPublicBuckets (beschränkt den Zugriff anhand öffentlicher Richtlinien). Alle vier Einstellungen sind standardmäßig aktiviert. Sie können Block Public Access auch auf Kontoebene aktivieren; dadurch wird es unabhängig von den Einstellungen einzelner Buckets für alle Buckets blockiert. Das ist ideal, um eine versehentliche öffentliche Freigabe zu verhindern.

S3-ACLs sind der ursprüngliche Mechanismus zur Zugriffskontrolle und älter als IAM. Eine ACL gewährt AWS-Konten oder vordefinierten Gruppen (allen Benutzern, authentifizierten AWS-Benutzern, Log-Übermittlung) vordefinierte Berechtigungen (READ, WRITE, FULL_CONTROL). ACLs können auf Bucket-Ebene oder auf Ebene einzelner Objekte angewendet werden. AWS empfiehlt inzwischen, ACLs zu deaktivieren (die S3-Einstellung „Bucket Owner Enforced“ sorgt dafür, dass der Bucket-Eigentümer alle Objekte besitzt, und deaktiviert ACLs) und stattdessen Bucket-Richtlinien und IAM zu verwenden. ACLs werden in der SAA-C03-Prüfung weiterhin als Legacy-Konzept abgefragt.

Wenn Sie S3-Inhalte über CloudFront bereitstellen, soll der Bucket privat bleiben, während CloudFront Objekte abrufen kann. Verwenden Sie Origin Access Control (OAC), den modernen Ersatz für Origin Access Identity (OAI). OAC erstellt eine CloudFront-Identität, der Sie in der Bucket-Richtlinie die Berechtigung s3:GetObject gewähren, während Block Public Access aktiviert bleibt. Dadurch müssen Benutzer über CloudFront zugreifen, etwa für Caching, WAF und HTTPS, und können nicht direkt auf den Bucket zugreifen. Dies ist ein häufiges Muster für sichere Architekturen in der SAA-C03-Prüfung.

Es gibt zwei Möglichkeiten, einem anderen AWS-Konto Zugriff auf Ihren S3-Bucket zu gewähren. Option 1 — Bucket-Richtlinie: Fügen Sie eine Anweisung mit der ARN des externen Kontos als Principal und den gewünschten S3-Aktionen hinzu. Die IAM-Benutzer/-Rollen des externen Kontos benötigen weiterhin IAM-Berechtigungen, um S3 aufzurufen, und die Bucket-Richtlinie muss ihnen den Zugriff erlauben. Option 2 — IAM-Rolle mit Vertrauensrichtlinie: Erstellen Sie in Ihrem Konto eine Rolle, der das externe Konto vertraut; die Identitäten des externen Kontos übernehmen die Rolle und erhalten die Berechtigungen für Ihren Bucket. Eine Bucket-Richtlinie ist für schreibgeschützte Szenarien einfacher; Rollen eignen sich besser für operativen Zugriff.

Cross-Origin Resource Sharing (CORS) ermöglicht einer Webanwendung, die auf einer Domain gehostet wird, JavaScript-Fetch-Anfragen an einen S3-Bucket auf einer anderen Domain zu senden. Ohne CORS-Konfiguration blockieren Browser diese Anfragen aus Sicherheitsgründen. Sie fügen dem Bucket eine CORS-Konfiguration hinzu, die erlaubte Origins, HTTP-Methoden und Header festlegt. CORS wird häufig benötigt, wenn eine auf example.com gehostete React-SPA Bilder oder Dateien direkt über eine S3-Bucket-URL abruft.

Eine vorab signierte URL gewährt zeitlich begrenzten Zugriff auf ein privates S3-Objekt, für GET oder PUT, ohne Berechtigungen für Buckets oder Objekte zu ändern. Die URL enthält Ihre Anmeldedaten und eine Ablaufzeit. Jeder, der die URL besitzt, kann bis zu ihrem Ablauf auf das Objekt zugreifen. Verwenden Sie vorab signierte URLs, um authentifizierten Benutzern Ihrer App das Herunterladen privater Dateien zu ermöglichen, Clients das direkte Hochladen nach S3 ohne Ihr Backend zu erlauben oder Berichte temporär freizugeben. Die Ablaufzeit kann zwischen 1 Sekunde und 7 Tagen liegen; bei temporären STS-Anmeldedaten beträgt sie maximal 12 Stunden.

Verwenden Sie Bedingungen in Bucket-Richtlinien, um kontextbasierte Sicherheit hinzuzufügen. Häufige Muster: aws:SourceIp beschränkt den Zugriff auf bestimmte IP-Bereiche, beispielsweise VPC-Endpunkte oder Unternehmensnetzwerke; aws:SecureTransport: true erzwingt HTTPS, indem Anfragen über HTTP abgelehnt werden, eine Best Practice für alle Buckets mit sensiblen Daten; s3:x-amz-server-side-encryption stellt sicher, dass Objekte mit serverseitiger Verschlüsselung hochgeladen werden müssen; und aws:PrincipalOrgID beschränkt den Zugriff auf Prinzipale innerhalb Ihrer AWS-Organisation und verhindert so die Datenexfiltration in externe Konten.

Standardmäßig greifen EC2-Instances in einem privaten Subnetz über das Internet auf S3 zu, über ein NAT-Gateway. Dadurch entstehen NAT-Kosten und der Datenverkehr wird dem öffentlichen Internet ausgesetzt. S3-Gateway-Endpunkte bieten innerhalb einer VPC eine private Verbindung zu S3 ohne NAT-Gateway und ohne zusätzliche Kosten. Sie fügen den Gateway-Endpunkt Ihrer Routing-Tabelle hinzu; der Datenverkehr zu S3 wird automatisch über das private Netzwerk von AWS geleitet. Sie können außerdem mit aws:SourceVpce Bedingungen in Bucket-Richtlinien hinzufügen, um den Zugriff auf Anfragen zu beschränken, die ausschließlich über den Endpunkt erfolgen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Bucket-Richtlinien sind ressourcenbasierte JSON-Dokumente, die den kontenübergreifenden Zugriff und den Servicezugriff auf S3 steuern, S3 Block Public Access ist eine Sicherheitsübersteuerung, die eine versehentliche öffentliche Freigabe verhindert, und vorab signierte URLs, VPC-Endpunkte und CORS-Konfigurationen decken bestimmte Zugriffsmuster sicher ab. Als Nächstes behandeln wir S3-Versionierung, MFA Delete und Replikation.