Amazon SCS-C02: Datenschutz und S3 — Lernleitfaden

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Teil des AWS Security Specialty SCS-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

S3-Bucket-Richtlinien, Ressourcen-ARNs und explizite Deny-Anweisungen

Eine S3-Bucket-Richtlinie ist ein ressourcenbasiertes JSON-Dokument, das zusammen mit identitätsbasierten Richtlinien ausgewertet wird. Zwei Regeln bestimmen ihr Verhalten. Erstens hat eine explizite Deny-Anweisung immer Vorrang: Unabhängig davon, wie viele Allow-Anweisungen vorhanden sind, blockiert eine passende Deny-Anweisung die Anfrage. Zweitens muss das Resource-Element genau dem ARN-Muster der Aktion entsprechen. Aktionen auf Bucket-Ebene wie s3:ListBucket beziehen sich auf arn:aws:s3:::my-bucket, während Aktionen auf Objektebene wie s3:GetObject und s3:PutObject sich auf arn:aws:s3:::my-bucket/* beziehen. Eine häufige Fehlkonfiguration ist die Gewährung von s3:GetObject für arn:aws:s3:::my-bucket ohne das /*-Suffix – der API-Aufruf zielt auf eine Objekt-ARN, keine Anweisung stimmt überein, und die Anfrage wird standardmäßig abgelehnt.

Die folgende Richtlinie verweigert jeden Zugriff, der nicht über TLS erfolgt, und gewährt einer bestimmten Rolle Lesezugriff, wobei beide ARN-Formen korrekt verwendet werden.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Eine häufige Falle ist der Versuch, eine Ausnahme zu schaffen, indem man nach einer weitreichenden Deny-Anweisung eine spätere Allow-Anweisung hinzufügt. Richtlinienanweisungen sind nicht reihenfolgeabhängig, und die Auswertungslogik von IAM gibt Deny zurück, sobald eine passende Ablehnung existiert. Die korrekte Lösung besteht darin, die Deny-Anweisung einzugrenzen – zum Beispiel über NotPrincipal oder eine Condition – anstatt eine erlaubende Anweisung darunter anzuhängen.

Lebenszyklusregeln, Objekt-Ablauf und Vault Lock

S3-Lebenszyklusregeln automatisieren Übergänge zwischen Speicherklassen und den Ablauf von Objekten. Um Aufbewahrungsanforderungen zu erfüllen – wie das Entfernen von personenbezogenen Daten (PII) 30 Tage nach der Erfassung – fügen Sie eine Regel hinzu, die aktuelle Objektversionen nach 30 Tagen ablaufen lässt und nicht-aktuelle Versionen kurz danach endgültig löscht. Für zugehörige Metadaten, die in DynamoDB geschrieben werden, aktivieren Sie das DynamoDB TTL-Attribut, damit Elemente sich nach demselben Zeitplan selbst löschen. Die Kombination dieser beiden Mechanismen ist betrieblich effizient, da keine Lambda-Funktion, kein Scheduler und kein maßgeschneiderter Bereinigungscode erforderlich ist.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Für archivierte Daten mit regulatorischen Aufbewahrungspflichten bietet S3 Glacier Vault Lock eine separate WORM-Kontrolle auf Vault-Ebene. Sobald die Vault-Lock-Richtlinie festgelegt ist (ein zweistufiger Prozess aus Initiierung und Abschluss innerhalb von 24 Stunden), kann sie nicht mehr geändert werden, nicht einmal vom Root-Benutzer des Kontos. Dies unterscheidet sich von Object Lock, das auf der Ebene von S3-Objekten arbeitet.

Block Public Access und CloudFront OAC

S3 Block Public Access (BPA) ist ein Satz von vier Schaltern auf Konto- und Bucket-Ebene, die jede ACL oder Richtlinie außer Kraft setzen, die andernfalls öffentlichen Zugriff gewähren würde. Aktivieren Sie alle vier auf Kontoebene und erzwingen Sie dies mit einer SCP, die beispielsweise s3:PutBucketPublicAccessBlock verweigert, wenn dadurch die Einstellungen gelockert würden. Diese Tiefenverteidigung (Defense-in-Depth) verhindert, dass ein Entwickler versehentlich einen Bucket durch eine zu freizügige ACL wieder öffentlich macht.

Für öffentliche Inhalte, die über CloudFront bereitgestellt werden, ist das korrekte Muster Origin Access Control (OAC). OAC signiert Anfragen von CloudFront an S3 mit SigV4; die Bucket-Richtlinie erlaubt dann nur den Service-Prinzipal der CloudFront-Distribution. Sich allein auf CloudFront ohne OAC (oder die veraltete OAI) zu verlassen, lässt die S3-URL direkt zugänglich, was die Zugriffskontrollen und die WAF des CDN umgeht. Der Bucket muss privat bleiben, BPA aktiviert sein und die Richtlinie auf die ARN der Distribution beschränkt sein:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock und Cross-Region Replication

Object Lock erzwingt WORM-Semantik für einzelne Objekte und erfordert, dass die Versionierung aktiviert ist und Object Lock bei der Erstellung des Buckets eingeschaltet wird (es kann einem bestehenden Bucket später nicht ohne Kontaktaufnahme mit AWS hinzugefügt werden). Es gibt zwei Aufbewahrungsmodi:

• Governance-Modus: Privilegierte Prinzipale mit der Berechtigung s3:BypassGovernanceRetention können die Aufbewahrungsfrist verkürzen oder aufheben.

• Compliance-Modus: Kein Benutzer – einschließlich des Root-Benutzers des AWS-Kontos – kann das Objekt löschen, überschreiben oder seine Aufbewahrungsfrist vor deren Ablauf verkürzen. Ein Legal Hold (rechtliche Aufbewahrungspflicht) kann zusätzlich von Benutzern mit der Berechtigung s3:PutObjectLegalHold unabhängig davon angewendet und aufgehoben werden.

Der Compliance-Modus ist die richtige Wahl, wenn die Anforderung absolute Unveränderlichkeit gegenüber allen Identitäten ist. Um diese Garantie über Regionen hinweg zu erweitern, kombinieren Sie Object Lock mit S3 Replication. Replizierte Objekte behalten ihre Sperrkonfiguration im Ziel-Bucket bei (der ebenfalls Object Lock aktiviert haben muss), sodass ein regionsweites Ereignis oder ein böswilliger Löschversuch die aufbewahrte Kopie nicht gefährden kann.

Macie und Athena zur Erkennung und Untersuchung

Amazon Macie verwendet verwaltete und benutzerdefinierte Datenkennungen, um S3-Objekte auf PII (persönlich identifizierbare Informationen), PHI (geschützte Gesundheitsinformationen), Anmeldeinformationen und andere sensible Muster zu scannen. Es meldet Ergebnisse an den Security Hub und EventBridge und ermöglicht so eine automatisierte Behebung, wie z. B. das Verschieben von Objekten in Quarantäne mithilfe einer restriktiven, Tag-basierten Bucket-Richtlinie. Aktivieren Sie Macie in jeder Region, in der Kundendaten gespeichert werden, und delegieren Sie die Verwaltung über AWS Organizations für zentralisierte Ergebnisse.

Amazon Athena bietet serverloses SQL für Daten in S3 und ist das Standardwerkzeug zur Abfrage von CloudTrail-Datenereignissen auf Objektebene. Um zu untersuchen, wer auf ein bestimmtes S3-Objekt zugegriffen hat, aktivieren Sie CloudTrail-Datenereignisse für den Bucket, liefern Sie die Protokolle an einen zentralen S3-Bucket und fragen Sie diese mit Athena ab:

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Zusammengefasste Fallstricke und ihre Stammursachen

• Fehlendes /* bei Objekt-ARNs: API-Aufrufe auf Objektebene werden gegen bucket/key ausgewertet, nicht gegen den Bucket-ARN. Ohne /* passt keine Anweisung, und IAM gibt eine implizite Ablehnung (implicit deny) zurück – was sich in unerwarteten 403-Fehlern bei GetObject äußert, selbst wenn der „Bucket“ erlaubt zu sein scheint.

• Hinzufügen einer Erlaubnis (Allow) nach einer expliziten Ablehnung (Deny): Die IAM-Auswertung ist nicht reihenfolgeabhängig; jede passende Deny-Regel führt direkt zur Ablehnung (short-circuits). Die Lösung besteht darin, den Geltungsbereich der Ablehnung einzugrenzen (über Condition, NotPrincipal oder NotResource), anstatt freizügige Anweisungen anzuhängen.

• CloudFront ohne OAC oder eine restriktive Bucket-Richtlinie: Die S3-Origin-URL bleibt direkt erreichbar, wodurch signierte URLs, WAF-Regeln und Geo-Restriktionen umgangen werden. Aktivieren Sie immer BPA für den Origin-Bucket und beschränken Sie s3:GetObject über AWS:SourceArn auf den CloudFront-Service-Prinzipal.

• Annahme, dass Object Lock für einen bestehenden Bucket aktiviert werden kann: Object Lock muss bei der Erstellung des Buckets konfiguriert werden. Eine Nachrüstung erfordert das Erstellen eines neuen Buckets mit aktiviertem Object Lock und die Migration der Daten.

• Verwechslung von Governance- und Compliance-Modus: Der Governance-Modus hindert einen privilegierten Benutzer nicht daran, die Aufbewahrungseinstellungen zu entfernen; nur der Compliance-Modus blockiert selbst den Root-Account.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial speichert Kundenauszüge, Transaktionsprotokolle und langfristige Compliance-Archive in mehreren S3-Buckets in zwei AWS-Regionen. Ihre Umgebung nutzt CloudFront für Kundenportale, kontoübergreifende Protokollierung und automatisierte Lebenszyklusübergänge zu Archivspeicherklassen für die gesetzlich vorgeschriebene Aufbewahrung.

Herausforderung: Eine kürzlich durchgeführte interne Überprüfung ergab mehrere Buckets mit inkonsistenten Richtlinien, die PII preisgaben, keine unveränderliche Aufbewahrung für archivierte Datensätze vorsahen und keine zentralisierte Methode zur Erkennung sensibler Objekte über Konten und Regionen hinweg boten.

Empfohlener Ansatz:

1. Aktivieren Sie S3 Block Public Access auf Konto- und Bucket-Ebene und implementieren Sie CloudFront Origin Access Control (OAC); verschärfen Sie die Bucket-Richtlinie, um GetObject nur vom CloudFront-OAC-Prinzipal unter Verwendung präziser Ressourcen-ARNs zu erlauben, und fügen Sie explizite Ablehnungen (Deny) für alle Anfragen hinzu, die nicht über die OAC erfolgen.
2. Erzwingen Sie serverseitige Verschlüsselung mit AWS KMS, indem kms:Encrypt/kms:GenerateDataKey in einer Bucket-Richtlinie gefordert wird, und fügen Sie explizite Ablehnungen für PutObject-Anfragen hinzu, die nicht x-amz-server-side-encryption und den erforderlichen kms:context enthalten, um unverschlüsselte Uploads zu verhindern.
3. Konfigurieren Sie S3 Object Lock im Compliance-Modus für Buckets, die unveränderlich sein müssen, und aktivieren Sie die regionenübergreifende Replikation (Cross-Region Replication, CRR) mit Replikationsregeln, die die Metadaten der Objektsperre beibehalten, sodass replizierte Objekte in der DR-Region unveränderlich bleiben.
4. Erstellen Sie S3-Lebenszyklusregeln (Lifecycle Rules), um gealterte Objekte in S3-Glacier-Speicherklassen zu verschieben, und legen Sie das Ablaufen von Objekten für zulässige Aufbewahrungszeiträume fest; für Archive, die rechtlich unveränderlich sein müssen, legen Sie diese in Amazon S3 Glacier Vaults ab und wenden Sie Glacier Vault Lock-Richtlinien an, um eine Write-Once-Aufbewahrung zu erzwingen.
5. Implementieren Sie Amazon Macie kontoübergreifend, um PII zu entdecken und zu klassifizieren, aktivieren Sie S3 Inventory und fragen Sie die Ergebnisse mit Amazon Athena für investigative Abfragen ab, und lösen Sie eine automatisierte Behebung (Lambda/Step Functions) aus, um sensible Objekte zu markieren, unter Quarantäne zu stellen oder in gesperrte, verschlüsselte Buckets zu verschieben.

Begründung: Dieser mehrschichtige Ansatz setzt das Prinzip der geringsten Rechte (Least Privilege) und Verschlüsselung durch, bietet unveränderliche Aufbewahrung und regionenübergreifende Dauerhaftigkeit für Compliance-Zwecke und nutzt Macie/Athena für eine zentralisierte Erkennung und automatisierte Behebung – im Einklang mit den AWS Best Practices für Datenschutz und Lebenszyklusmanagement.

Amazon Macie: Automatisierte Erkennung, Klassifizierungsaufträge und Freigabelisten

Amazon Macie ist ein verwalteter Datensicherheitsdienst, der maschinelles Lernen und Mustererkennung einsetzt, um sensible Daten – personenbezogene Daten (PII), Zahlungskartennummern (PANs), Anmeldeinformationen und benutzerdefinierte, durch Regex definierte Datentypen – zu entdecken, die in Amazon S3 gespeichert sind. Macie arbeitet in zwei komplementären Modi, die häufig verwechselt werden.

Die automatisierte Erkennung sensibler Daten ist ein kostengünstiger, kontinuierlich laufender Prozess, der Stichproben von Objekten aus jedem Bucket im Konto (oder in einer Organisation, wenn Macie an ein Sicherheitskonto delegiert ist) nimmt. Er erstellt eine Sensitivitätsbewertung und ein Inventar für jeden Bucket. Dies ist der richtige Ausgangspunkt, wenn Sie Tausende von Buckets haben und noch nicht wissen, wo sich sensible Daten befinden, da Kosten und administrativer Aufwand minimiert werden, indem Stichproben genommen werden, anstatt jedes Objekt zu scannen.

Klassifizierungsaufträge (Aufträge zur Erkennung sensibler Daten) sind einmalige oder geplante Tiefenscans, die auf bestimmte Buckets abzielen. Sobald die automatisierte Erkennung einen Bucket als potenziell sensibel einstuft, erstellen Sie einen Klassifizierungsauftrag, der auf diesen Bucket beschränkt ist, um eine erschöpfende Analyse durchzuführen. Das kanonische Muster ist daher: Aktivieren Sie die automatisierte Erkennung organisationsweit und führen Sie anschließend Klassifizierungsaufträge nur für die markierten Buckets durch.

Freigabelisten (Allow Lists) sind der Mechanismus, um bekannte, unbedenkliche Übereinstimmungen zu unterdrücken. Wenn ein Data Lake synthetische Test-PANs enthält (zum Beispiel den bekannten Testkartenbereich 4111 1111 1111 1111), wird Macie jedes Vorkommen melden. Das Umschreiben oder Verschieben der Daten ist teuer und störend; der richtige Ansatz ist, eine Macie-Freigabeliste zu definieren – entweder eine Klartextliste mit exakten Werten oder eine Regex – und diese mit Ihren Klassifizierungsaufträgen und der Konfiguration für die automatisierte Erkennung zu verknüpfen. Übereinstimmungen mit der Freigabeliste werden von den Ergebnissen (Findings) ausgeschlossen, während echte PANs weiterhin Alarme auslösen.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten und Hunderten von S3-Buckets, in denen Transaktionsprotokolle, Kundendokumente und Langzeitarchive, die nach S3 Glacier verschoben wurden, gespeichert sind. Ihr Sicherheitsteam verfügt über grundlegende Verschlüsselungs- und Protokollierungsfunktionen, aber keine zentralisierte Erkennung sensibler Daten oder konsistente Aufbewahrungskontrollen über alle Konten hinweg.

Herausforderung: Ein kürzlich entdeckter, öffentlich zugänglicher Bucket enthielt archivierte Kundendatensätze mit PII (personenbezogenen Informationen), nachdem eine fehlerhafte Bucket-Richtlinie und ein Lifecycle-Übergang zu S3 Glacier erfolgt waren. Meridian muss nun alle sensiblen Daten finden, die Sicherheitslücken beheben und zukünftig eine konforme Aufbewahrung für die Archivierung durchsetzen.

Empfohlene Vorgehensweise:

1. Aktivieren Sie Amazon Macie für die gesamte AWS Organization und schalten Sie die automatisierte S3-Erkennung ein, damit Macie Buckets und Objekte kontinuierlich auf sensible Daten und riskante Konfigurationen überprüft.
2. Erstellen Sie Macie-Klassifizierungsaufträge, die auf alle S3-Buckets abzielen. Konfigurieren Sie benutzerdefinierte Bezeichner für sensible Daten für Sozialversicherungs- und Kontonummern und richten Sie Positivlisten (Allow Lists) ein, um bekannte Testdaten, Lieferantendateien und Service-Konten auszuschließen.
3. Verwenden Sie S3 Inventory, um Objekte in S3 Glacier aufzulisten. Führen Sie dann S3 Batch Operations aus, um nur die von Inventory für das Macie-Scanning markierten Objekte temporär wiederherzustellen, damit Klassifizierungsaufträge die in Glacier archivierten Inhalte überprüfen können.
4. Automatisieren Sie die Behebung, indem Sie Macie-Ergebnisse (Findings) an Amazon EventBridge und Security Hub senden. Lösen Sie Lambda-Funktionen aus, um sichere S3-Bucket-Richtlinien anzuwenden, S3 Block Public Access zu aktivieren, öffentliche ACLs zu entfernen und Buckets zur Überprüfung zu taggen.
5. Implementieren Sie dauerhafte Aufbewahrung und Prävention: Aktivieren Sie S3 Versioning und S3 Object Lock (Governance-/Compliance-Modus) für kritische Buckets, erzwingen Sie SSE-KMS mit CMKs über Bucket-Richtlinien und stellen Sie AWS Organizations SCPs bereit, um öffentliche ACLs zu blockieren und gegebenenfalls Verschlüsselung und Object Lock zu fordern.
6. Aktivieren Sie CloudTrail-Datenereignisse für S3 und leiten Sie die Ergebnisse zur Alarmierung und zur Planung regelmäßiger Macie-Klassifizierungsaufträge in ein SIEM ein, um eine kontinuierliche Abdeckung zu gewährleisten.

Begründung: Dieser Ansatz nutzt Macie für die automatisierte Erkennung und gezielte Klassifizierung (mit Positivlisten), stellt Glacier-Objekte nur bei Bedarf zur Überprüfung wieder her, automatisiert die Behebung über EventBridge/Lambda und erzwingt unveränderliche Aufbewahrung und Verschlüsselung mit Object Lock und KMS – was den AWS Best Practices für Erkennung, Behebung und präventive Kontrollen entspricht.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Die Behandlung von rohen Macie-Ergebnissen als absolute Wahrheit, ohne Positiv- oder Unterdrückungslisten zu konfigurieren, führt zu einer Flut von Warnmeldungen (Alert Fatigue) und kann echte Vorfälle im Rauschen synthetischer Daten verschleiern – deshalb ist das bloße „Vertrauen in die Ergebnisse“ in Umgebungen mit vielen Fehlalarmen (False Positives) der falsche Ansatz.

Integration von Macie-Ergebnissen mit EventBridge

Macie veröffentlicht jedes Ergebnis (Finding) in Amazon EventBridge über die Quelle aws.macie. Dies ermöglicht es Ihnen, Ergebnisse weiterzuleiten, ohne die Macie-API abfragen (pollen) zu müssen. Eine typische Regel leitet Policy-Ergebnisse zur Benachrichtigung des Bereitschaftsdienstes an SNS weiter und sendet SensitiveData-Ergebnisse zur Aggregation an AWS Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Die Ziele der Regel sind SNS-Themen, Security Hub oder eine Lambda-Funktion für benutzerdefinierte Behebungsmaßnahmen (zum Beispiel das automatische Anwenden einer restriktiven Bucket-Richtlinie auf den betreffenden Bucket).

Bucket-Richtlinienbedingungen für Organisationsgrenzen

S3 Block Public Access (BPA) blockiert nur Zugriffe, die aus dem öffentlichen Internet oder von anonymen Prinzipalen stammen. Es verhindert nicht, dass ein authentifizierter Prinzipal in einem anderen AWS-Konto oder einer anderen AWS Organization auf den Bucket zugreift, wenn eine Bucket-Richtlinie oder eine ACL einen solchen Zugriff gewährt. Sich allein auf BPA zu verlassen, ist daher falsch, wenn die Anforderung darin besteht, organisationsübergreifenden Zugriff zu verhindern – Sie müssen Bucket-Richtlinien mit Service Control Policies (SCPs) auf der Organizations-Ebene kombinieren.

Zwei IAM-Bedingungsschlüssel (Condition Keys) ermöglichen eine präzise Durchsetzung von Organisationsgrenzen:

• aws:ResourceOrgID: die Organisations-ID, der die Ressource gehört, auf die zugegriffen wird. Wird in Identitätsrichtlinien/SCPs verwendet, um Prinzipalen den Zugriff auf Ressourcen außerhalb Ihrer Organisation zu verweigern.

• aws:PrincipalOrgID: die Organisations-ID des aufrufenden Prinzipals. Wird in Bucket-Richtlinien verwendet, um den Zugriff von Prinzipalen außerhalb Ihrer Organisation zu verweigern.

• aws:SourceOrgPaths: der OU-Pfad des Quellprinzipals, der eine Eingrenzung auf eine bestimmte OU ermöglicht (z. B. darf nur die „Production“-OU in einen Compliance-Bucket schreiben).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Kombinieren Sie dies mit einer SCP, die s3:DeleteObject* für Ressourcen verweigert, bei denen aws:ResourceOrgID nicht mit Ihrer Organisation übereinstimmt, und eine organisationsübergreifende Exfiltration oder Löschung wird unmöglich, selbst wenn eine Bucket-Richtlinie versehentlich gelockert wird.

S3 Object Lock: Compliance-Modus und Versionierung

Object Lock erzwingt eine Write-Once-Read-Many (WORM)-Semantik für einzelne Objektversionen. Es erfordert, dass S3 Versioning für den Bucket aktiviert ist (Object Lock ohne Versionierung ist nicht möglich – die Sperre schützt eine bestimmte Versions-ID, nicht den Schlüssel).

• Governance-Modus: Benutzer mit der Berechtigung s3:BypassGovernanceRetention können die Aufbewahrungsfrist verkürzen oder aufheben. Geeignet für die Durchsetzung interner Richtlinien.

• Compliance-Modus: Kein Prinzipal, einschließlich des Root-Benutzers des AWS-Kontos, kann die Objektversion verkürzen, entfernen oder löschen, bis die Aufbewahrungsfrist abgelaufen ist. Dies ist die richtige Wahl für regulatorische Unveränderlichkeitsanforderungen (SEC 17a-4, FINRA, HIPAA-Archivierung).

Die Aufbewahrung kann pro Objekt (Datum Retain-Until) oder über eine standardmäßige Aufbewahrungskonfiguration auf Bucket-Ebene festgelegt werden. Legal Holds (gesetzliche Aufbewahrungsfristen) sind separate, unbefristete Sperren, die bestehen bleiben, bis sie von einem Prinzipal mit der Berechtigung s3:PutObjectLegalHold explizit entfernt werden.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: Beheben von Richtlinienfehlern vor Abschluss der Sperre

Vault Lock bei S3 Glacier erzwingt unveränderliche Tresorzugriffsrichtlinien (Vault Access Policies). Der Prozess besteht aus zwei Aufrufen: initiate-vault-lock versetzt die Richtlinie in einen in Bearbeitung befindlichen Zustand (in-progress) mit einem 24-Stunden-Fenster, und complete-vault-lock macht sie dauerhaft. Wenn während des 24-Stunden-Fensters ein Tippfehler entdeckt wird – zum Beispiel ein zu freizügiger Principal – ist die korrekte und kostengünstigste Behebung:

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock bricht die laufende Sperre kostenlos ab, sodass Sie den Vorgang mit der korrigierten Richtlinie neu initiieren können. Alternative „Lösungen“ – wie das Löschen und Neuerstellen des Tresors (was das Löschen aller 10 TB an Archiven und ein erneutes Hochladen erfordert, wodurch Abruf- und Übertragungsgebühren anfallen) oder das Warten auf den Abschluss der Sperre, um dann eine Umgehungslösung zu finden – sind verschwenderisch oder unmöglich. Sobald complete-vault-lock ausgeführt wird, ist die Richtlinie für immer unveränderlich; ein Abbruch ist nur während des „in-progress“-Fensters gültig.

Verwandte Falle: DNSSEC-Vertrauenskette (Chain of Trust)

Eine häufige domainübergreifende Falle betrifft Route 53 DNSSEC. Die Aktivierung der DNSSEC-Signierung für eine Hosted Zone einer Subdomain erzeugt einen Key Signing Key (KSK) und einen entsprechenden DS-Record. Dieser DS-Record muss in der übergeordneten Zone (parent zone) veröffentlicht werden. Ohne ihn können Resolver die Vertrauenskette nicht validieren und behandeln Antworten entweder als ungültig (bogus) oder fallen auf eine unsichere Auflösung zurück, was das DNS für validierende Clients unbrauchbar macht. Die Aktivierung der Signierung ohne den Export des DS-Records und dessen Einfügung beim Registrar oder in der übergeordneten Zone ist ein Zustand unvollständiger Konfiguration und keine funktionierende DNSSEC-Implementierung.

← Verschlüsselung · Alle Domänen · Netzwerk- und VPC-Sicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →