¿Cómo puedo configurar las notificaciones del depósito de S3 en una cola en SQS donde se utilizan KMS tanto en el depósito como en la cola?
aws/s3 ).Cuando entro en la consola web de S3 e intento agregar un evento de notificación en mi depósito que se envía a mi cola en SQS, aparece este mensaje de error:
No se pueden validar las siguientes configuraciones de destino. El mensaje a la cola SSE no se pudo cifrar mediante KMS. (arn:aws:sqs:ca-central-1: ... : ...)
Ya intenté configurar mi Política de claves KMS para otorgar a la cuenta de servicio S3 los permisos que necesita.
{ "Sid": "Let S3 encrypt messages so that bucket notifications can be encrypted", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Encrypt" ], "Resource": "*" },¿Qué debo hacer para permitir las notificaciones de depósito en una cola cifrada?
Según la documentación , la segunda acción debería ser kms:Decrypt en lugar de kms:Encrypt .
Es un poco contrario a la intuición por qué se necesita kms:Decrypt . Podría estar pensando que, dado que la cola de SQS está cifrada, cuando el servicio S3 llama a la API SendMessage , necesita el permiso kms:Encrypt para asegurarse de que el servicio KMS pueda cifrar el mensaje, ¿verdad? No del todo, y he aquí por qué:
El mensaje no está cifrado directamente por la clave maestra (CMK). En su lugar, utiliza el cifrado de sobre y la clave de datos cifra los datos . ¿Por qué? Porque el tamaño máximo de los datos que una CMK simétrica puede cifrar mediante la API de cifrado es de 4096 bytes, mientras que el tamaño de un mensaje que admite el servicio SQS puede ser mucho mayor que 4 KB. Por lo tanto, no se necesita kms:Encrypt y, en su lugar, se requiere kms:GenerateDataKey para generar la clave de datos que se usa para cifrar el mensaje SQS.
En la sección "Configurar permisos de KMS para productores" de este documento de AWS , se explica por qué se necesita kms:Decrypt .
La llamada a
kms:Decryptes para verificar la integridad de la nueva clave de datos antes de usarla.
Para que quede muy claro, la API GenerateDataKey devuelve tanto la clave de datos de texto sin formato como la copia cifrada de la clave de datos. La clave de datos de texto sin formato se utiliza para cifrar el mensaje SQS y la clave de datos cifrados se almacenará junto con el mensaje en la cola. La única forma de verificar que la clave de datos cifrada es, de hecho, el texto cifrado de la clave de datos de texto sin formato es que el servicio necesita tener el permiso kms:Decrypt para descifrar el texto cifrado y asegurarse de que la salida sea exactamente igual a la clave de datos de texto sin formato devuelta. en la respuesta de la API GenerateDataKey.