Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe
Lernen Sie, wie falsch konfigurierte S3-Buckets, Azure-Blob-Container und GCS-Buckets zur Datenpreisgabe führen und wie Sie Bucket-Richtlinien und Zugriffskontrollen durchsetzen.
Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe ist eine kostenlose Security+ Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Security+ Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Grundlagen des Cloud-Objektspeichers
Cloud-Objektspeicher – AWS S3, Azure Blob Storage und Google Cloud Storage (GCS) – speichert Dateien als Objekte in flachen Namensräumen, die als Buckets oder Container bezeichnet werden. Anders als bei herkömmlichen Dateisystemen werden Berechtigungen über Richtlinien gesteuert, die an Buckets und Objekte angehängt sind, statt über Dateisystem-ACLs. Objektspeicher eignet sich ideal für große Datenmengen, erfordert jedoch eine sorgfältige Konfiguration der Berechtigungen, da ein einziger falsch konfigurierter Bucket Terabytes sensibler Daten im öffentlichen Internet offenlegen kann.
Fehlkonfigurationen öffentlicher Buckets
Die häufigste Schwachstelle bei Cloud-Speichern ist ein öffentlich zugänglicher Bucket – ein Speicher-Bucket, dessen Zugriffsrichtlinie anonymen Lesezugriff (oder Schreibzugriff) erlaubt. Diese Fehlkonfiguration hat zu Dutzenden großer Sicherheitsvorfälle geführt: Verizon (14 Millionen Kundendatensätze), FedEx (119.000 Pässe), Capital One (100 Millionen Kreditkartenanträge). Angreifer verwenden automatisierte Scanner, um öffentliche Buckets anhand aller bekannten AWS-Account-Namensmuster zu finden. Sobald die Fehlkonfiguration besteht, ist die Entdeckung daher problemlos möglich.
# Check if S3 bucket is publicly accessible
aws s3api get-bucket-policy --bucket my-bucket
aws s3api get-bucket-acl --bucket my-bucket
# Block all public access (AWS recommended default)
aws s3api put-public-access-block \
--bucket my-bucket \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'Bucket-Richtlinien und ACLs
Cloud-Speicher verwendet zwei Arten von Zugriffskontrollen, die miteinander in Konflikt geraten können. Bucket-Richtlinien sind JSON-Dokumente, die an den Bucket angehängt werden und festlegen, welche Principals welche Aktionen ausführen dürfen. Access Control Lists (ACLs) sind veraltete, objektbezogene Berechtigungsvergabe. AWS empfiehlt, ACLs zugunsten von Bucket-Richtlinien zu deaktivieren, um eine einheitliche Verwaltung zu gewährleisten. Wenn beide vorhanden sind, gilt die weitreichendste Richtlinie – eine übermäßig freizügige ACL kann also öffentlichen Zugriff gewähren, selbst wenn die Bucket-Richtlinie ihn einschränkt.
# S3 bucket policy example — restrict to specific account
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': { 'AWS': 'arn:aws:iam::123456789012:root' },
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/*'
}]
}
# All other principals implicitly deniedVerschlüsselung ruhender Daten im Objektspeicher
Cloud-Speicheranbieter bieten serverseitige Verschlüsselung für ruhende Objekte an. SSE-S3 (AWS) verwendet automatisch von AWS verwaltete Schlüssel. SSE-KMS verwendet kundenseitig verwaltete Schlüssel im AWS Key Management Service und bietet dadurch bessere Prüfpfade (jede Entschlüsselung wird in CloudTrail protokolliert) sowie Kontrolle über die Schlüsselrotation. SSE-C verwendet vom Kunden bereitgestellte Schlüssel, die vollständig außerhalb von AWS verwaltet werden. Für sensible Daten bietet SSE-KMS mit kundenseitig verwalteten Schlüsseln die stärkste Kontrolle und die besten Compliance-Nachweise.
# Enforce encryption on S3 bucket (deny unencrypted uploads)
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:PutObject',
'Resource': 'arn:aws:s3:::my-secure-bucket/*',
'Condition': {
'StringNotEquals': {
's3:x-amz-server-side-encryption': 'aws:kms'
}
}
}Verschlüsselung bei der Übertragung
Selbst ordnungsgemäß verschlüsselte ruhende Daten können offengelegt werden, wenn sie über unverschlüsselte Kanäle übertragen werden. Auf alle Cloud-Speicher-APIs sollte ausschließlich über HTTPS/TLS zugegriffen werden. Bei S3 können Bucket-Richtlinien HTTPS erzwingen, indem Anfragen mit aws:SecureTransport: false abgelehnt werden. Pre-signed URLs – temporäre authentifizierte URLs, die zeitlich begrenzten Zugriff auf Objekte gewähren – sollten immer HTTPS verwenden und mit kurzen Ablaufzeiten konfiguriert werden, um das Zeitfenster einer möglichen Offenlegung nach dem Abfangen zu minimieren.
# S3 bucket policy — deny HTTP (require HTTPS)
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:*',
'Resource': ['arn:aws:s3:::my-bucket', 'arn:aws:s3:::my-bucket/*'],
'Condition': {
'Bool': { 'aws:SecureTransport': 'false' }
}
}Datenklassifizierung und Speicherklassen
Nicht alle Daten erfordern dasselbe Schutzniveau. Sensible Daten (PII, PHI, Finanzunterlagen) müssen in verschlüsselten, zugriffsbeschränkten Buckets mit aktivierter Audit-Protokollierung gespeichert werden. Weniger sensible Daten können breiter zugänglich sein. Datenklassifizierungskennzeichnungen sollten beim Erstellen des Objekts angewendet und dazu verwendet werden, Daten automatisch in passend konfigurierte Speicherbereiche weiterzuleiten. Richtlinien, die Daten anhand von Klassifizierungs-Tags automatisch in sichereren Speicher verschieben, verringern das Risiko, dass sensible Daten in Buckets mit niedrigem Sicherheitsniveau landen.
Protokollierung und Überwachung des Zugriffs auf Cloud-Speicher
Die Zugriffsprotokollierung ist entscheidend, um nachträglich unbefugte Zugriffe zu erkennen und Compliance-Prüfungen zu ermöglichen. AWS S3 access logs und die CloudTrail data event logging protokollieren jeden API-Aufruf auf Objektebene – wer ein Objekt angefordert hat, von welcher IP-Adresse und zu welcher Zeit. Azure Blob diagnostic logging und GCS audit logs bieten vergleichbare Funktionen. Ohne diese Protokolle gibt es bei der Entdeckung eines Datenlecks keine forensischen Beweise, sodass sich das Ausmaß der Offenlegung nicht bestimmen lässt.
# Enable S3 access logging
aws s3api put-bucket-logging \
--bucket my-bucket \
--bucket-logging-status '{
"LoggingEnabled": {
"TargetBucket": "my-access-logs-bucket",
"TargetPrefix": "my-bucket-logs/"
}
}'Risiken beim kontenübergreifenden Zugriff
Cloud-Speicher wird häufig kontenübergreifend gemeinsam genutzt (Entwicklung, Staging, Produktion, Drittanbieterpartner). Ein unachtsam konfigurierter kontenübergreifender Zugriff kann übermäßige Berechtigungen gewähren. Zu den bewährten Vorgehensweisen gehören: explizite Account-IDs in Bucket-Richtlinien statt Wildcard-Principals zu verwenden, mit AWS Organizations SCPs einzuschränken, welchen externen Konten überhaupt Zugriff gewährt werden darf, kontenübergreifende Berechtigungen regelmäßig zu prüfen und für Datenübertragungen zwischen Konten AWS PrivateLink gegenüber dem öffentlichen Internet zu bevorzugen.
Versionierung und Löschschutz
Objektversionierung bewahrt alle Versionen eines Objekts auf, einschließlich gelöschter Versionen. Dies schützt vor versehentlichem Löschen, der Verschlüsselung von Objekten durch Ransomware und Insider-Bedrohungen. Für kritische Daten sollten Sie die Versionierung mit Object Lock (dem Äquivalent zu S3 Glacier Vault Lock) kombinieren – einer WORM-Richtlinie (Write Once, Read Many), die das Löschen oder Ändern während eines festgelegten Aufbewahrungszeitraums verhindert. Object Lock kann in der Finanz- und Gesundheitsbranche regulatorische Anforderungen an unveränderliche Datensätze erfüllen.
# Enable S3 versioning
aws s3api put-bucket-versioning \
--bucket my-critical-bucket \
--versioning-configuration Status=Enabled
# Enable Object Lock (immutable storage)
aws s3api put-object-lock-configuration \
--bucket my-critical-bucket \
--object-lock-configuration \
'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=365}}'Erkennung von Fehlkonfigurationen im Speicher durch CSPM
Cloud Security Posture Management (CSPM)-Tools überprüfen Cloud-Speicherkonfigurationen automatisch anhand von Sicherheitsbenchmarks. Zu den CSPM-Prüfungen gehören: Sind Buckets öffentlich zugänglich? Ist die Verschlüsselung ruhender Daten aktiviert? Ist die Protokollierung aktiviert? Ist die Versionierung für kritische Buckets aktiviert? Sind Bucket-Richtlinien übermäßig weitreichend? CSPM-Tools wie Prisma Cloud, Wiz und AWS Security Hub ermöglichen eine kontinuierliche Compliance-Überwachung und melden Konfigurationsabweichungen, bevor Angreifer sie entdecken.
Pre-signed URLs und temporärer Zugriff
Pre-signed URLs gewähren zeitlich begrenzten Zugriff auf bestimmte Objekte, ohne dass der Empfänger AWS-Anmeldedaten benötigt. Sie eignen sich zum Teilen von Dateien mit externen Parteien. Zu den Sicherheitsrisiken gehören URLs mit übermäßig langen Ablaufzeiten, die über das beabsichtigte Freigabefenster hinaus gültig bleiben, von Empfängern weitergeleitete URLs außerhalb des vorgesehenen Empfängerkreises sowie in URLs eingebettete Tokens, die in Serverprotokollen erscheinen. Legen Sie immer die kürzest mögliche Ablaufzeit fest und vermeiden Sie die Protokollierung von Pre-signed URLs.
# Generate a pre-signed URL (expires in 3600 seconds)
aws s3 presign s3://my-bucket/report.pdf \
--expires-in 3600
# Returns a URL valid for 1 hour
# After expiry, the URL returns 403 Forbidden
# Best practice: shortest expiry viable for the use caseKurztest
Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: Fehlkonfigurationen öffentlicher Buckets sind die häufigste Ursache für Datenlecks bei Cloud-Speichern, SSE-KMS bietet mit Audit-Protokollierung über CloudTrail die stärkste Kontrolle über die Verschlüsselung und die Kombination aus Objektversionierung und Object Lock schützt kritische Daten vor Ransomware und dem Löschen durch Insider. Als Nächstes behandeln wir Cloud-Identitäten mit IAM-Rollen und Servicekonten.
Häufig gestellte Fragen
Ist die Lektion „Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe“ kostenlos?
Ja — der vollständige Text von „Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Security+ Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe“?
Lernen Sie, wie falsch konfigurierte S3-Buckets, Azure-Blob-Container und GCS-Buckets zur Datenpreisgabe führen und wie Sie Bucket-Richtlinien und Zugriffskontrollen durchsetzen. Du übst Security+ Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Security+ Academy zu starten?
Keine Vorkenntnisse erforderlich. Security+ Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Security+ Academy-Lektion Code schreiben und ausführen?
Ja. Jede Security+ Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Modell der geteilten Verantwortung: IaaS, PaaS, SaaS
- Sicherheit von Cloud-Speichern und Risiken der Datenpreisgabe
- Cloud-Identität: IAM-Rollen und Servicekonten
- Cloud Security Posture Management (CSPM)