跨账户数据传输场景下AWS KMS哈希加加密防篡改方案咨询

Alright, let's walk through how to implement a hash + encryption combo for your two cross-account AWS scenarios to ensure your data stays unmodified after decryption. I'll break this down per scenario with actionable steps:

The goal here is to attach a tamper-proof hash (HMAC, not just a raw hash—since it uses a secret key to prevent forgery) to your logs, encrypt the logs + HMAC, and validate integrity once Account B receives and decrypts the data.

Step 1: Set up HMAC and Encryption in Account A #

• Generate a secure HMAC key: Use AWS Secrets Manager to store a symmetric HMAC key (AES-256 or SHA-256 compatible). This key must be accessible to both accounts (configure cross-account access in Secrets Manager's policy).
• Process logs before sending: Use a CloudWatch Logs subscription filter paired with a Lambda function (in Account A) to:
  1. Extract raw log entries.
  2. Compute an HMAC-SHA256 hash of the raw log content using the Secrets Manager key.
  3. Encrypt the raw log content + HMAC string using a KMS key (either a shared multi-account KMS key or Account B's KMS key—ensure Account A has kms:GenerateDataKey and kms:Encrypt permissions on this key).
  4. Send the encrypted payload (log data + HMAC) to Account B's Kinesis Stream.

Step 2: Configure Cross-Account Permissions #

• Kinesis Stream (Account B): Update its resource policy to allow Account A's Lambda execution role to call kinesis:PutRecord and kinesis:PutRecords.
• KMS Key: If using Account B's KMS key, add Account A's Lambda role to the key policy with kms:Encrypt and kms:GenerateDataKey permissions.
• Secrets Manager: Allow Account B's validation role to retrieve the HMAC key (add secretsmanager:GetSecretValue permission to the secret's policy).

Step 3: Validate Integrity in Account B #

• Use a Lambda function (triggered by Kinesis Stream events) to:
  1. Decrypt the payload using the KMS key (ensure the Lambda role has kms:Decrypt permissions).
  2. Split the decrypted payload into the original log content and the received HMAC.
  3. Recompute the HMAC-SHA256 of the log content using the same HMAC key from Secrets Manager.
  4. Compare the recomputed HMAC with the received one: if they match, the data is unmodified; discard or alert on mismatches.

For S3 cross-region/cross-account replication (CRR), we need to combine SSE-KMS encryption with HMAC-based integrity checks, since S3's built-in checksums (like ETag) don't prevent intentional tampering without a secret key.

Step 1: Prepare Source Bucket (Account A) #

• Add HMAC to objects: Use a Lambda function (triggered by s3:ObjectCreated events) to:
  1. Retrieve the newly uploaded object from Account A's S3 bucket.
  2. Compute HMAC-SHA256 of the object content using a Secrets Manager key (shared cross-account).
  3. Either:
     • Embed the HMAC as an S3 object metadata field (e.g., x-amz-meta-hmac), then re-encrypt the object with SSE-KMS (using a shared KMS key or Account B's key), OR
     • Package the object content + HMAC into a single file, encrypt it with the KMS key, and re-upload the encrypted package to the source bucket (more secure, as HMAC isn't exposed in metadata).
• Configure CRR: Set up a cross-account replication rule to copy objects (and their metadata, if using the first approach) to Account B's target bucket. Ensure the replication role has:
  • s3:GetObject and s3:GetObjectVersion permissions on the source bucket.
  • s3:PutObject permissions on the target bucket.

Step 2: Configure Cross-Account KMS/Secrets Permissions #

• KMS Key: If using Account B's KMS key, add Account A's replication role and Lambda role to the key policy with kms:Encrypt and kms:GenerateDataKey permissions. For the target side, ensure Account B's validation role has kms:Decrypt access.
• Secrets Manager: Grant Account B's validation role access to the shared HMAC key (add secretsmanager:GetSecretValue to the secret's policy).

Step 3: Validate Integrity in Account B #

• Use a Lambda function (triggered by s3:ObjectCreated events on the target bucket) to:
  1. Download and decrypt the object using the KMS key.
  2. Extract the original object content and the stored HMAC (either from metadata or the packaged file).
  3. Recompute the HMAC-SHA256 of the content using the shared HMAC key.
  4. Compare the recomputed HMAC with the stored one: a match confirms no tampering occurred during replication or transit.

Key General Notes #

• Always use HMAC (not raw SHA hashes)—raw hashes can be forged if an attacker modifies the data and recalculates the hash. HMAC requires a secret key, so only parties with the key can validate integrity.
• Manage HMAC keys securely in AWS Secrets Manager (never hardcode them in Lambda code or configs).
• For KMS, prefer multi-account KMS keys (created in one account, shared with the other) over cross-account access to single-account keys—it simplifies permission management.

内容的提问来源于stack exchange，提问作者Aravind Babu Konda