LabEx
Beitreten

S3-Objekte mit einem KMS-Schlüssel schützen

AWSBeginner
Jetzt üben

Einführung

Eine Anwendung muss einen privaten Export lesen, der in S3 gespeichert ist. Du verschlüsselst neue Uploads mit einem kundenseitig verwalteten Schlüssel, gewährst dem Leser Zugriff und testest, wie Objekt- und Schlüsselberechtigungen tatsächliche Downloads beeinflussen.

Schließe zuerst Dateien in S3 speichern und abrufen, Einen privaten Export mit KMS verschlüsseln und entschlüsseln und deren IAM-Voraussetzungen ab. Diese neue VM stellt einen fiktiven Export, eine Sitzung für die Leserrolle und unabhängige Referenzressourcen bereit.

Bezug zu Zertifizierungen

Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.

Verschlüsselten Objektspeicher vorbereiten

In diesem Schritt erstellst du einen kundenseitig verwalteten KMS-Schlüssel und konfigurierst einen neuen Bucket so, dass er ihn standardmäßig verwendet. Ein Bucket enthält Objekte; jedes Objekt hat einen Schlüssel wie exports/private-export.json. Serverseitige Verschlüsselung mit KMS (SSE-KMS) ermöglicht S3, gespeicherte Objekte mit deinem ausgewählten Schlüssel zu verschlüsseln. Die Standardverschlüsselung gilt für neue Uploads, ohne dass jeder Client die Verschlüsselungsoptionen erneut angeben muss.

Verwende die bereitgestellte fiktive Datei private-export.json; die Rollensitzung export-reader beginnt ohne Objekt- oder Schlüsselzugriff. Erhalte den Referenzbucket, das Referenzobjekt und den Referenzschlüssel. Öffne AWS View neben Terminal, um Schlüssel- und Bucketzustand, Leserberechtigungen und sichere Byte-Vergleiche zu betrachten.

Beginne im Projektverzeichnis und bestätige die bereitgestellte Operatoridentität. cd wechselt das Verzeichnis; die Abfrage des Aufrufers gibt eine Identitäts-ARN zurück, ohne Zugangsdaten offenzulegen.

cd /home/labex/project

aws sts get-caller-identity --query Arn --output text

Erwarte den Benutzer labex-sec02-operator. Erstelle einen symmetrischen, kundenseitig verwalteten Schlüssel und einen lesbaren Alias. --query wählt die ARN aus, --output text entfernt die JSON-Anführungszeichen, und $(...) speichert das Ergebnis in einer Shellvariable.

KEY_ARN=$(aws kms create-key \
  --description labex-sec02-owned-export \
  --query KeyMetadata.Arn \
  --output text)

aws kms create-alias \
  --alias-name alias/labex-sec02-private-export \
  --target-key-id "$KEY_ARN"

Verwende einen temporären Bucketnamen mit einem Zeitstempel als Suffix, um Namenskonflikte zu vermeiden. Das Präfix labex-sec02-owned- unterscheidet deinen Bucket von der bereitgestellten Referenz. Diese Einheit verwendet us-east-1, sodass beim Erstellen des Buckets keine Standortbeschränkung angegeben werden muss.

BUCKET="labex-sec02-owned-$(date +%s)"

aws s3api create-bucket \
  --bucket "$BUCKET" \
  --region us-east-1 \
  --query Location \
  --output text

Konfiguriere SSE-KMS mit der genauen Schlüssel-ARN. Ein S3 Bucket Key kann wiederholte KMS-Anfragen reduzieren; hier bleibt er deaktiviert, damit jedes Objekt seinen eigenen KMS-Verschlüsselungskontext verwendet. Schreibe die Standardregel als gewöhnliche JSON-Datei. Das Here-Dokument ersetzt $KEY_ARN; file:// lädt die gespeicherte Konfiguration.

cat > bucket-encryption.json <<EOF
{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "$KEY_ARN"
      },
      "BucketKeyEnabled": false
    }
  ]
}
EOF

aws s3api put-bucket-encryption --bucket "$BUCKET" \
  --server-side-encryption-configuration file://bucket-encryption.json

aws s3api get-bucket-encryption \
  --bucket "$BUCKET" \
  --query ServerSideEncryptionConfiguration

Erwarte aws:kms, deine Schlüssel-ARN und BucketKeyEnabled: false. Behalte KEY_ARN und BUCKET in diesem Terminal für die folgenden Befehle bei. In AWS View ist der eigene Schlüssel aktiviert, und der Bucket enthält noch keine Objekte.

Einem Leser beide erforderlichen Berechtigungen geben

In diesem Schritt lädst du den Export hoch und lässt eine Rolle seine ursprünglichen Bytes wiederherstellen. Zum Hochladen ist kms:GenerateDataKey für den ausgewählten Schlüssel erforderlich. SSE-KMS verwendet einen Datenschlüssel, um Objektbytes zu verschlüsseln. KMS schützt diesen Datenschlüssel; S3 speichert das verschlüsselte Objekt und den verschlüsselten Datenschlüssel und fordert dann die Entschlüsselung an, wenn ein autorisierter Leser das Objekt herunterlädt. Schlüsselmaterial muss dabei nicht in der CLI-Ausgabe erscheinen.

Objekt- und Schlüsselberechtigungen für S3

Zum Lesen dieses SSE-KMS-Objekts sind sowohl Objektzugriff als auch die Berechtigung zur Schlüsselentschlüsselung erforderlich.

Lade die bereitgestellte Datei mit s3api put-object hoch. Die Bucketeinstellung liefert die Verschlüsselungsoptionen; --body private-export.json liest die benannte lokale Datei als Objektbytes. Verwende für den kleinen Export diese API für einen Upload in einem Teil.

aws s3api put-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json \
  --body private-export.json \
  --query '{Encryption:ServerSideEncryption,Key:SSEKMSKeyId,BucketKey:BucketKeyEnabled}'

aws s3api head-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json \
  --query '{Encryption:ServerSideEncryption,Key:SSEKMSKeyId,Bytes:ContentLength}'

Erwarte aws:kms, die ARN des eigenen Schlüssels und die ursprüngliche Dateigröße. Metadaten allein zeigen nicht, ob ein Leser entschlüsseln kann. Gewähre zuerst nur Objektzugriff. Eine Objekt-ARN enthält den Bucket und den Objektschlüssel; sie unterscheidet sich von einer Bucket-ARN. Das folgende Here-Dokument schreibt eine Richtliniendatei und ersetzt darin $BUCKET.

cat > read-object.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::$BUCKET/exports/private-export.json"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name ReadExportObject \
  --policy-document file://read-object.json

Wähle die vorbereitete Lesersitzung mit --profile export-reader aus. Dieser Versuch muss mit AccessDenied fehlschlagen: Die Rolle kann dieses Objekt lesen, hat aber noch keine KMS-Entschlüsselungsberechtigung.

aws \
  --profile export-reader s3api get-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json reader-export.json

Gewähre dieser Rolle nur kms:Decrypt für den genauen Schlüssel. Zum Herunterladen benötigt sie weder Schlüsselverwaltung noch kms:GenerateDataKey.

cat > decrypt-key.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "$KEY_ARN"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name DecryptExportKey \
  --policy-document file://decrypt-key.json

aws \
  --profile export-reader s3api get-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json reader-export.json \
  --query '{Encryption:ServerSideEncryption,Key:SSEKMSKeyId}'

chmod 600 reader-export.json

cmp private-export.json reader-export.json

cmp gibt nichts aus und meldet Erfolg, wenn die Byte-Inhalte übereinstimmen. AWS View sollte nun gespeicherten Chiffretext und eine GetObject-Anfrage des Lesers zeigen, deren zurückgegebene Bytes dem bereitgestellten Export entsprechen. Dies sind getrennte Beobachtungen: Verschlüsselte Speicherung schützt ruhende Daten, während begrenzte Berechtigungen den Abruf steuern.

Beispiel in AWS View nach der Berechtigung für den genauen Schlüssel: gespeicherter Chiffretext und die vom Leser wiederhergestellten ursprünglichen Bytes.

Berechtigungs- und Schlüsselzustandsfehler diagnostizieren

In diesem Schritt unterscheidest du eine fehlende Entschlüsselungsberechtigung von einem deaktivierten Schlüssel. Behalte die Objektberechtigung bei, damit sich jeweils nur eine Bedingung ändert.

Entferne die Schlüsselberechtigung des Lesers und versuche dann denselben Objektdownload erneut. Die Rolle hat weiterhin s3:GetObject, aber die Anfrage muss mit AccessDenied fehlschlagen.

aws iam delete-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name DecryptExportKey

aws \
  --profile export-reader s3api get-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json reader-export.json

Untersuche die verbleibende Objektrichtlinie. Sie sollte weiterhin nur dieses Exportobjekt nennen.

aws iam get-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name ReadExportObject \
  --query PolicyDocument

Stelle die Berechtigung für den genauen Schlüssel wieder her und deaktiviere deinen Schlüssel. Ein deaktivierter Schlüssel ist weiterhin vorhanden, kann aber keine kryptografischen Operationen durchführen. Ändere den unbeteiligten Referenzschlüssel nicht.

aws iam put-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name DecryptExportKey \
  --policy-document file://decrypt-key.json

aws kms disable-key --key-id "$KEY_ARN"

aws \
  --profile export-reader s3api get-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json reader-export.json

Erwarte einen Fehler aufgrund des deaktivierten Schlüssels. Eine IAM-Berechtigung kann einen deaktivierten Schlüssel nicht nutzbar machen. Bestätige seinen Zustand direkt beim Dienst, aktiviere ihn dann und rufe das Objekt erneut ab.

aws kms describe-key --key-id "$KEY_ARN" --query KeyMetadata.KeyState --output text

aws kms enable-key --key-id "$KEY_ARN"

aws \
  --profile export-reader s3api get-object \
  --bucket "$BUCKET" \
  --key exports/private-export.json reader-export.json \
  --query ServerSideEncryption \
  --output text

chmod 600 reader-export.json

cmp private-export.json reader-export.json

Erwarte aws:kms und einen erfolgreichen Vergleich. AWS View hält die fehlgeschlagenen Anfragen und die erfolgreiche Wiederherstellung zusammen fest, während Referenzbucket und Referenzschlüssel nutzbar bleiben. Beispiel in AWS View mit Fehlern durch eine entzogene Berechtigung und einen deaktivierten Schlüssel, gefolgt von einem erfolgreichen Lesezugriff.

Ein fehlgeschlagener Download kann eine ältere lokale Datei zurücklassen. Ihre bloße Existenz beweist daher nicht, dass die Anfrage erfolgreich war; die signierte Leseanfrage und der Vergleich belegen die Wiederherstellung.

Eigene Ressourcen entfernen und die Schlüssellöschung planen

In diesem Schritt bereinigst du genau die Ressourcen deines Exports. Schließe zuerst die vorherigen Funktionsprüfungen ab. Ein S3-Bucket muss vor der Löschung leer sein; für einen kundenseitig verwalteten KMS-Schlüssel gilt eine Löschwartefrist, statt dass er sofort verschwindet.

Lösche nur deinen benannten Export und dann seinen Bucket. Rufe den Bestand erfolgreich ab und bestätige, dass dein $BUCKET fehlt, während labex-sec02-reference erhalten bleibt.

aws s3api delete-object --bucket "$BUCKET" --key exports/private-export.json

aws s3api delete-bucket --bucket "$BUCKET"

aws s3api list-buckets --query 'Buckets[].Name'

Entferne die beiden Berechtigungen, die du hinzugefügt hast, und den eigenen Alias. Die bereitgestellte Leserrolle dient als vorbereitete Sitzungsressource; lösche weder sie noch die unbeteiligten Referenzressourcen.

aws iam delete-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name ReadExportObject

aws iam delete-role-policy \
  --role-name labex-sec02-export-reader \
  --policy-name DecryptExportKey

aws iam list-role-policies --role-name labex-sec02-export-reader --query PolicyNames

aws kms delete-alias --alias-name alias/labex-sec02-private-export

Plane die Löschung deines Schlüssels mit der Mindestfrist von sieben Tagen und lies dann seinen Zustand direkt beim Dienst aus. Die Planung macht ihn sofort unbrauchbar, beweist aber nicht, dass er bereits gelöscht wurde.

aws kms schedule-key-deletion \
  --key-id "$KEY_ARN" \
  --pending-window-in-days 7 \
  --query DeletionDate \
  --output text

aws kms describe-key --key-id "$KEY_ARN" --query KeyMetadata.KeyState --output text

aws kms describe-key \
  --key-id alias/labex-sec02-reference \
  --query KeyMetadata.KeyState \
  --output text

Erwarte PendingDeletion für deinen Schlüssel und Enabled für die Referenz. Entferne die benannten lokalen Dateien; diese Befehle lassen unbeteiligte Projektdateien unberührt.

rm -f private-export.json reader-export.json read-object.json decrypt-key.json bucket-encryption.json

Führe die Verifikation dieses Schritts vor dem Entfernen der temporären CLI-Profile aus. Erfolgreiche Bestandsabfragen direkt beim Dienst belegen die Bereinigung, nicht Authentifizierungsfehler.

rm -f /home/labex/.aws/credentials /home/labex/.aws/config

unset KEY_ARN BUCKET

Zusammenfassung

Du hast SSE-KMS als Bucketstandard konfiguriert, einen verschlüsselten Export hochgeladen und die ursprünglichen Bytes mit einer Rolle wiederhergestellt, die auf ein Objekt und einen Schlüssel begrenzt war. Sowohl das Entziehen von kms:Decrypt als auch das Deaktivieren des Schlüssels verhinderte das Lesen, ohne die Objektberechtigung zu ändern. Du hast den Zugriff wiederhergestellt, nur eigene S3-Ressourcen gelöscht und die Löschung des eigenen KMS-Schlüssels geplant, während Referenzbucket und Referenzschlüssel erhalten blieben.

Verwandt AWS Kurse
AWS-Grundlagen für Anfänger

AWS-Grundlagen für Anfänger

aws
AWS S3 für Anfänger

AWS S3 für Anfänger

aws
AWS IAM für Anfänger

AWS IAM für Anfänger

aws